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
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 SCCCNcompletes 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 DigestStop-Control-Connection-Notification (StopCCN):
control messagesent 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 CodeResult 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 IDIncoming-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 IDL2TP _____:08104:C7268310: Rx <- ICRP loc C7268310 rem A793DE82 ser C33C29E2Incoming-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 IDL2TP _____:08104:C7268310: Tx -> ICCN loc C7268310 rem A793DE82 ser C33C29E2Incoming-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 IDThe following AVPs MAY be present in the ICCN: Random Vector Message Digest L2-Specific Sublayer Data Sequencing Tx Connect Speed Rx Connect Speed Circuit StatusL2TP _____:08104:C7268310: Tx -> SLI loc C7268310 rem A793DE82 ser C33C29E2Set-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 StatusL2TP _____:08104:C7268310: Tx -> ZLB A loc C7268310 rem A793DE82 ser C33C29E2Zero-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 C33C29E2Now lets verify that R10 and R13 are EIGRP peered.R10#sh ip eigrp neiEIGRP-IPv4 Neighbors for AS(1)H Address Interface Hold Uptime SRTT RTO Q Seq(sec) (ms) Cnt Num0 172.16.10.13 Gi1.10 12 06:24:26 82 492 0 614All is well, we are currently peered.
