Software versions:
IOS XE 15.5
IOS XR 5.3
The topology for this demo:
In this post we will be taking a look at the L2 VPN capabilities not leveraging MPLS. I simply have disabled MPLS globally, I plan on covering VXLAN and OTV in upcoming posts. This post will be the last of the Provider side configuration for L2, VXLAN and OTV are customer side.
The beauty of L2TPv3, when configured, can tunnel L2 traffic over an IP enabled network, like the internet. Like OTV and VXLAN, it doesn't have to be configured on the SP side either, it can be configured on the customer side as well. Like MPLS L2 VPN, L2TPv3 is just another encapsulation. We replace the MPLS configuration with IP reachability, for a base configuration, we leverage the "xconnect" syntax under the interface. No "service instances" are supported here, just Port (unmuxed) VLAN and QinQ (muxed). Unmuxed means any traffic can come in and be transported, muxed means a "tag" is referenced and used to forward the traffic.
L2TPv3 does support advanced configuration, like pseudowire based configuration, l2vpn xconnect contextual setup, redundancy, authentication and several more. We're going to start off like we did for MPLS L2 VPN, with the basic stuff and get more complicated as we go. There aren't as many design decisions or scaling options like MPLS supports, so not as many posts to cover the material, we will use OTV to scale out to E-LAN and E-TREE. OTV and VXLAN based configurations would be analogous to a Managed CE device, in the case that the provider doens't have MPLS deployed in the core.
Since L2TPv3 is a P2P deployment model, R1 and R6 are the first 2 routers used, I will, for redundancy setup a backup tunnel from R1 to R5 to connect R10 to R13.
The base configuration is very simple, but automatically gave me issues when I first configured it, which is identical to MPLS encap'd scenarios. There was no indication there was a problem, it was a verification check that revealed the issue. Turns out, in my testing that a "pw-class" is needed to be configured which sets the encapsulation to "l2tpv3" and sets the source IP to loopback 0. I Include R1 and R6 configuration below.
R1
interface GigabitEthernet2.10
encapsulation dot1Q 10
xconnect 192.168.1.6 10 encapsulation l2tpv3 pw-class CCIE
!
pseudowire-class CCIE
encapsulation l2tpv3
ip local interface Loopback0
R6
interface GigabitEthernet2.10
encapsulation dot1Q 10
xconnect 192.168.1.1 10 encapsulation l2tpv3 pw-class CCIE
!
pseudowire-class CCIE
encapsulation l2tpv3
ip local interface Loopback0
Pretty basic setup right? Now onto the base verification.
R1#sh l2tp
L2TP Tunnel and Session Information Total tunnels 1 sessions 1
LocTunID RemTunID Remote Name State Remote Address Sessn L2TP Class/
Count VPDN Group
3662734289 3595601473 R6 est 192.168.1.6 1 l2tp_default_class
LocID RemID TunID Username, Intf/ State Last Chg Uniq ID
Vcid, Circuit
3341189904 2811485826 3662734289 10, Gi2.10:10 est 00:24:26 0
This output shows that we have an active tunnel up and running, we're peered with R6 and we also see that VC-ID 10 is being used.
R1#sh l2tp tunnel
L2TP Tunnel Information Total tunnels 1 sessions 1
LocTunID RemTunID Remote Name State Remote Address Sessn L2TP Class/
Count VPDN Group
3662734289 3595601473 R6 est 192.168.1.6 1 l2tp_default_class
R1#sh l2tp tunnel packets
L2TP Tunnel Information Total tunnels 1 sessions 1
LocTunID Pkts-In Pkts-Out Bytes-In Bytes-Out
3662734289 483 479 40994 40762
We can see how many packets in/out and how bytes in/out on this tunnel.
R1#sh l2tp tunnel state
L2TP Tunnel Information Total tunnels 1 sessions 1
LocTunID RemTunID Local Name Remote Name State Last-Chg
3662734289 3595601473 R1 R6 est 00:25:10
This output shows the tunnel state as "est" or established.
R1#sh l2tp tunnel transport
L2TP Tunnel Information Total tunnels 1 sessions 1
LocTunID Type Prot Local Address Port Remote Address Port
3662734289 IP 115 192.168.1.1 0 192.168.1.6 0
We can see the transport output, L2TP uses protocol 115 and is connected between R1 and R6.
Let's take a look at a basic debug to see the setup details
L2TP tnl 08104:DA50E3D1: Tx -> SCCRQ loc DA50E3D1 rem 00000000
L2TP tnl 08104:DA50E3D1: Rx <- SCCRP loc DA50E3D1 rem D6508641
L2TP tnl 08104:DA50E3D1: Tx -> SCCCN loc DA50E3D1 rem D6508641
L2TP _____:08104:C7268310: Tx -> ICRQ loc C7268310 rem 00000000 ser C33C29E2
L2TP _____:08104:C7268310: Rx <- ICRP loc C7268310 rem A793DE82 ser C33C29E2
L2TP _____:08104:C7268310: Tx -> ICCN loc C7268310 rem A793DE82 ser C33C29E2
L2TP _____:08104:C7268310: Tx -> SLI loc C7268310 rem A793DE82 ser C33C29E2
L2TP _____:08104:C7268310: Tx -> ZLB A loc C7268310 rem A793DE82 ser C33C29E2
L2TP _____:08104:C7268310: Rx <- SLI loc C7268310 rem A793DE82 ser C33C29E2
This can also be reviewed in Wireshark and I recommend you see both for a complete picture.
We need to breakdown the control messages so we know what is going on. You'll see in the RFC, the AVP and Control Connection Protocol specs, the AVP is the attribute value pairs
L2TP tnl 08104:DA50E3D1: Tx -> SCCRQ loc DA50E3D1 rem 00000000
Start-Control-Connection-Request (SCCRQ): control message used to initiate a control connection between two LCCEs. It is sent by either the LAC or the LNS to begin the control connection establishment process.
The following AVPs MUST be present in the SCCRQ:
Message Type
Host Name
Router ID
Assigned Control Connection ID
Pseudowire Capabilities List
The following AVPs MAY be present in the SCCRQ:
Random Vector
Control Message Authentication Nonce
Message Digest
Control Connection Tie Breaker
Vendor Name
Receive Window Size
Preferred Language
L2TP tnl 08104:DA50E3D1: Rx <- SCCRP loc DA50E3D1 rem D6508641
Start-Control-Connection-Request (SCCRP): control message sent in reply to a received SCCRQ message. The SCCRP is used to indicate that the SCCRQ was accepted and that establishment of the control connection should continue.
The following AVPs MUST be present in the SCCRP:
Message Type
Host Name
Router ID
Assigned Control Connection ID
Pseudowire Capabilities List
The following AVPs MAY be present in the SCCRP:
Random Vector
Control Message Authentication Nonce
Message Digest
Vendor Name
Receive Window Size
Preferred Language
L2TP tnl 08104:DA50E3D1: Tx -> SCCCN loc DA50E3D1 rem D6508641
Start-Control-Connection-Connected (SCCCN:
control message sent in reply to an SCCRP. The SCCCN
completes the control connection establishment process.
The following AVP MUST be present in the SCCCN:
Message Type
The following AVP MAY be present in the SCCCN:
Random Vector
Message Digest
Stop-Control-Connection-Notification (StopCCN):
control message
sent by either LCCE to inform its peer that the control connection is
being shut down and that the control connection should be closed. In
addition, all active sessions are implicitly cleared (without sending
any explicit session control messages). The reason for issuing this
request is indicated in the Result Code AVP. There is no explicit
reply to the message, only the implicit ACK that is received by the
reliable control message delivery layer.
The following AVPs MUST be present in the StopCCN:
Message Type
Result Code
Result Code AVP (Attribute Type 1) Values
-----------------------------------------
General Error Codes
13 - Session not established due to losing tie breaker (L2TPv3).
14 - Session not established due to unsupported PW type (L2TPv3).
15 - Session not established, sequencing required w/ut valid L2-Specific Sublayer (L2TPv3).
16 - Finite state machine error or timeout.
The following AVPs MAY be present in the StopCCN:
Random Vector
Message Digest
Assigned Control Connection ID
L2TP _____:08104:C7268310: Tx -> ICRQ loc C7268310 rem 00000000 ser C33C29E2
Incoming-Call-Request (ICRQ): Control message sent by an LCCE
to a peer when an incoming call is detected (although the ICRQ may
also be sent as a result of a local event). It is the first in a
three-message exchange used for establishing a session via an L2TP
control connection.
The ICRQ is used to indicate that a session is to be established
between an LCCE and a peer. The sender of an ICRQ provides the peer
with parameter information for the session. However, the sender
makes no demands about how the session is terminated at the peer
(i.e., whether the L2 traffic is processed locally, forwarded, etc.).
The following AVPs MUST be present in the ICRQ:
Message Type
Local Session ID
Remote Session ID
Serial Number
Pseudowire Type
Remote End ID
Circuit Status
The following AVPs MAY be present in the ICRQ:
Random Vector
Message Digest
Assigned Cookie
Session Tie Breaker
L2-Specific Sublayer
Data Sequencing
Tx Connect Speed
Rx Connect Speed
Physical Channel ID
L2TP _____:08104:C7268310: Rx <- ICRP loc C7268310 rem A793DE82 ser C33C29E2
Incoming-Call-Reply (ICRP): is the control message sent by an LCCE in
response to a received ICRQ. It is the second in the three-message
exchange used for establishing sessions within an L2TP control
connection.
The ICRP is used to indicate that the ICRQ was successful and that
the peer should establish (i.e., answer) the incoming call if it has
not already done so. It also allows the sender to indicate specific
parameters about the L2TP session.
The following AVPs MUST be present in the ICRP:
Message Type
Local Session ID
Remote Session ID
Circuit Status
The following AVPs MAY be present in the ICRP:
Random Vector
Message Digest
Assigned Cookie
L2-Specific Sublayer
Data Sequencing
Tx Connect Speed
Rx Connect Speed
Physical Channel ID
L2TP _____:08104:C7268310: Tx -> ICCN loc C7268310 rem A793DE82 ser C33C29E2
Incoming-Call-Connected (ICCN): is the control message sent by the
LCCE that originally sent an ICRQ upon receiving an ICRP from its
peer. It is the final message in the three-message exchange used for
establishing L2TP sessions.
The ICCN is used to indicate that the ICRP was accepted, that the
call has been established, and that the L2TP session should move to
the established state. It also allows the sender to indicate
specific parameters about the established call (parameters that may
not have been available at the time the ICRQ was issued).
The following AVPs MUST be present in the ICCN:
Message Type
Local Session ID
Remote Session ID
The following AVPs MAY be present in the ICCN:
Random Vector
Message Digest
L2-Specific Sublayer
Data Sequencing
Tx Connect Speed
Rx Connect Speed
Circuit Status
L2TP _____:08104:C7268310: Tx -> SLI loc C7268310 rem A793DE82 ser C33C29E2
Set-Link-Info: control message is sent by an LCCE to convey link
or circuit status change information regarding the circuit associated
with this L2TP session. For example, if PPP renegotiates LCP at an
LNS or between an LAC and a Remote System, or if a forwarded Frame
Relay VC transitions to Active or Inactive at an LAC, an SLI message
SHOULD be sent to indicate this event. Precise details of when the
SLI is sent, what PW type-specific AVPs must be present, and how
those AVPs should be interpreted by the receiving peer are outside
the scope of this document. These details should be described in the
associated pseudowire-specific documents that require use of this
message.
The following AVPs MUST be present in the SLI:
Message Type
Local Session ID
Remote Session ID
The following AVPs MAY be present in the SLI:
Random Vector
Message Digest
Circuit Status
L2TP _____:08104:C7268310: Tx -> ZLB A loc C7268310 rem A793DE82 ser C33C29E2
Zero-Length Body (ZLB): Control message with only an L2TP header. ZLB messages are used
only to acknowledge messages on the L2TP reliable control
connection.
L2TP _____:08104:C7268310: Rx <- SLI loc C7268310 rem A793DE82 ser C33C29E2
Now lets verify that R10 and R13 are EIGRP peered.
R10#sh ip eigrp nei
EIGRP-IPv4 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 172.16.10.13 Gi1.10 12 06:24:26 82 492 0 614
All is well, we are currently peered.
