AToM/L2VPN/VPLS
PW (PseudoWire) architecture is described in RFC 3985.
LDP for PWs is defined in RFC 4447.
EoMPLS (Ethernet over MPLS) is defined in RFC 4448.
L2TPv3 (Layer 2 Tunneling Protocol v3) is defined in RFC 3931.
L2VPN
- AToM
- requires MPLS connectivity from end to end
- source ip address is the one used for LDP
- L2TPv3
- requires IP connectivity from end to end
- source ip address is configured manually
If you are transferring Vlans and STP packets over the L2VPN connection, then you might need to disable STP for those specific vlans when using any type of PVST. Alternatively you can try to match vlans on either side.
L2TPv3
L2TPv3 is protocol 115.
Supported protocols over L2TPv3
- Frame-Relay
- Ethernet
- VLAN
- HDLC
- PPP
- IPv6
The L2TPv3 keepalive mechanism consists of an exchange of L2TP hello messages.
The interface keepalive feature is automatically disabled on the interface to which xconnect is applied, except for Frame-Relay encapsulation.
The IP local interface must be a loopback interface.
To convert an interface with AToM xconnect to L2TPv3 xconnect, remove the xconnect configuration from the interface and then configure L2TPv3.
Each L2TPv3 tunneled packet includes the entire Layer 2 frame of the payload:
- 20 bytes (IP packet header)
- 12 bytes (L2TPv3 session header)
- 4 bytes (if sequencing is enabled)
- payload (the complete frame received on the AC)
You can have either dynamic or static pseudowires (where no signaling is required for session establishment).
IOS
pseudowire-class L2TP-PWCLASS
encapsulation l2tpv3
ip local interface Loopback0
!
interface X
xconnect 2.2.2.2 12 pw-class L2TP-PWCLASS
IOS-XR
l2vpn
pw-class L2TP-PWCLASS
encapsulation l2tpv3
protocol l2tpv3
ipv4 source 2.2.2.2
!
xconnect group R2-R1-XCONGRP
p2p R2-R1-P2P
interface X
neighbor 1.1.1.1 pw-id 12
pw-class L2TP-PWCLASS
In IOS-XR, you have to define the signaling protocol, while in IOS it's enabled by default.
IOS
R6#sh l2tun tunnel all
L2TP Tunnel Information Total tunnels 1 sessions 1
Tunnel id 1787404852 is up, remote id is 3119273419, 1 active sessions
Remotely initiated tunnel
Tunnel state is established, time since change 00:00:14
Tunnel transport is IP (115)
Remote tunnel name is R2
Internet Address 2.2.2.2, port 0
Local tunnel name is R1
Internet Address 1.1.1.1, port 0
L2TP class for tunnel is l2tp_default_class
Counters, taking last clear into account:
0 packets sent, 0 received
0 bytes sent, 0 received
Last clearing of counters never
Counters, ignoring last clear:
0 packets sent, 0 received
0 bytes sent, 0 received
Control Ns 2, Nr 3
Local RWS 1024 (default), Remote RWS 512
Control channel Congestion Control is disabled
Tunnel PMTU checking disabled
Retransmission time 1, max 2 seconds
Unsent queuesize 0, max 0
Resend queuesize 0, max 1
Total resends 1, ZLB ACKs sent 1
Total out-of-order dropped pkts 0
Total out-of-order reorder pkts 0
Total peer authentication failures 0
Current no session pak queue check 0 of 5
Retransmit time distribution: 0 1 0 0 0 0 0 0 0
Control message authentication is disabled
Static PWs require you to define sessions & cookie parameters under the neighbor where the PW is pointing to. Using static PWs allows the traffic to pass over the PW as soon as possible (avoiding session parameter negotiation).
IOS
pseudowire-class L2TP-CLASS
encapsulation l2tpv3
protocol none
ip local interface Loopback0
!
interface POS2/0
xconnect 2.2.2.2 12 encapsulation l2tpv3 manual pw-class L2TP-CLASS
l2tp id 1 2
l2tp cookie local 4 4660
l2tp cookie remote 8 4660 22136
You need to define "protocol none" under the pw-class, otherwise you won't be able to do the static configuration.
IOS-XR
l2vpn
xconnect group A-XCONGRP
p2p A-P2P
neighbor 1.1.1.1 pw-id 100
l2tp static local cookie size 4 value 0x1234
l2tp static local session 1
l2tp static remote cookie size 8 value 0x1234 0x5678
l2tp static remote session 2
Local/remote values must be reversed on the other side.
When you use a static L2TPv3 session, you cannot perform interworking.
Authentication
- L2TPv3 Control Message Hashing (new method)
- hash is computed of entire message
- all message types are hashed
- L2TP Control Channel Authentication (old method)
- hash is computed of Challenge AVP message only
- only SCCRP and SCCCN messages are hashed
IOS
l2tp-class OLDAUTH-L2TP-CLASS
authentication
hostname USER
password PASS
!
l2tp-class NEWAUTH-L2TP-CLASS
digest secret 0 PASS hash SHA1
!
pseudowire-class L2TP-PWCLASS
encapsulation l2tpv3
protocol l2tpv3 XXX-L2TP-CLASS
ip local interface Loopback0
IOS-XR
l2tp-class OLDAUTH-L2TP-CLASS
authentication
hostname USER
password PASS
!
l2tp-class NEWAUTH-L2TP-CLASS
digest hash SHA1
digest secret PASS
!
l2vpn
pw-class L2TP-PWCLASS
encapsulation l2tpv3
protocol l2tpv3 class XXX-L2TP-CLASS
ipv4 source 2.2.2.2
In IOS-XR, the L2TP class used for authentication (and other parameters) is configured outside the l2vpn configuration, in the global configuration.
AToM
- A working LSP must exist between the PEs.
- If the configuration is correct, then a targeted LDP adjacency will be formed between the PEs and the pseudowire will come up (unless the PEs do not agree on some parameters).
- The PW-ID must agree on both sides.
- MTUs must agree on both ACs for the PW to come up (IOS-XR MTU includes the L2 header).
- The tLDP session is used to exchange labels for the pseudowire.
- The PW label is used to differentiate the local ACs, like the VPN label is used to differentiate the local VRFs.
Interfaces at both sides of a local AC must have a common encapsulation (ppp, hdlc, frame-relay) in order for the local AC to come up.
When you change the encapsulation of an interface, any xconnect configuration is removed.
You have to exit from the xconnect or pw-class config mode in order to have it activated.
If you have to change the MTU of the local AC in order to agree with the remote AC, then you must do the same for the interface on the other side of the local AC, to account for any IGPs passing over.
Besides dynamic pseudowires (based on LDP), you can also create static pseudowires by having the labels statically defined on each PE.
Logging
Configure the following if you want to enable logging of various PW events.
IOS
xconnect logging pseudowire status
IOS-XR
l2vpn
logging
bridge-domain
pseudowire
vfi
You can use the "clear xconnect" command if you want to reset a pseudowire.
IOS
R1#clear xconnect ?
all All xconnect entries
interface All xconnects by interface
peer All xconnects by Peer IP address
PPP Pseudowires
When using xconnect for PPP L2VPN connectivity, then the PPP process of the local AC is disabled.
no xconnect configured
Serial2/0 is up, line protocol is up
Hardware is M4T
MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation PPP, LCP Open
xconnect configured
Serial2/0 is up, line protocol is up
Hardware is M4T
MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation PPP, LCP Closed, crc 16, loopback not set
Frame-Relay
Each PW can be assigned to a single PVC/DLCI.
If you need to transfer all DLCIs of a port, then you have to use HDLC as the interface encapsulation and do the usual xconnect under the interface.
Frame-relay config on the other side of each AC doesn't have to agree, as long as the DLCIs are communicated correctly across the MPLS network.
IOS might require to have frame-relay switching enabled on the PE (IOS-XR and GNS3 don't require it).
A PVC that is transferred across the PW is shown as "switched" under "show frame-relay pvc", while another PVC that terminates locally is shown as "local".
Remember to configure appropriately the IGP network type on the interfaces, if the default isn't the right one.
Wireshark might not decode correctly the FRoMPLS encapsulation.
IOS
interface Serial2/0
encapsulation frame-relay
frame-relay intf-type dce
!
pseudowire-class FRoMPLS-PWCLASS
encapsulation mpls
!
connect FRCON Serial2/0 100 l2transport
xconnect 9.9.9.9 19 pw-class FRoMPLS-PWCLASS
IOS-XR
interface POS0/0/0/0.100 l2transport
pvc 100
!
interface POS0/0/0/0
encapsulation frame-relay
frame-relay intf-type dce
!
l2vpn
pw-class FRoMPLS-PWCLASS
encapsulation mpls
!
xconnect group FR-XCONGRP
p2p R9R1-P2P
interface POS0/0/0/0.100
neighbor 1.1.1.1 pw-id 19
pw-class FRoMPLS-PWCLASS
IOS
R1#sh connection
ID Name Segment 1 Segment State
================================================================================
2 FRCON Se2/0 100 9.9.9.9 19 UP
R1#sh mpls l2transport vc 19
Local intf Local circuit Dest address VC ID Status
------------- -------------------------- --------------- ---------- ----------
Se2/0 FR DLCI 100 9.9.9.9 19 UP
Ethernet Pseudowires
- Tagged mode (vlan mode)
- VC type 5
- VC type 4 (if vlan tag is to be transfered too)
- Raw mode (port mode)
- VC type 5
Configuration
IOS
pseudowire-class EoMPLS-PWCLASS
encapsulation mpls
!
interface X
xconnect 9.9.9.9 19 pw-class EoMPLS-PWCLASS
IOS-XR
interface X l2transport
!
l2vpn
pw-class EoMPLS-PWCLASS
encapsulation mpls
!
xconnect group R9R1-XCONGRP
p2p R9R1-P2P
interface X
neighbor 1.1.1.1 pw-id 19
pw-class EoMPLS-PWCLASS
In IOS-XR, you have to define as "l2transport" the interface used as AC in the xconnect. If there is existing configuration under the interface, it's better to remove the whole interface, make it L2 and then re-apply the old config (if it's still required.)
Verification
IOS
R1#sh mpls l2 vc
Local intf Local circuit Dest address VC ID Status
------------- -------------------------- --------------- ---------- ----------
Fa1/0 Ethernet 9.9.9.9 19 UP
R1#sh mpls l2 vc detail
Local interface: Fa1/0 up, line protocol up, Ethernet up
Destination address: 9.9.9.9, VC ID: 19, VC status: up
Output interface: Fa0/0.12, imposed label stack {26 16100}
Preferred path: not configured
Default path: active
Next hop: 10.1.2.2
Create time: 00:20:14, last status change time: 00:20:14
Signaling protocol: LDP, peer 9.9.9.9:0 up
Targeted Hello: 1.1.1.1(LDP Id) -> 9.9.9.9, LDP is UP
Status TLV support (local/remote) : enabled/supported
LDP route watch : enabled
Label/status state machine : established, LruRru
Last local dataplane status rcvd: No fault
Last local SSS circuit status rcvd: No fault
Last local SSS circuit status sent: No fault
Last local LDP TLV status sent: No fault
Last remote LDP TLV status rcvd: No fault
Last remote LDP ADJ status rcvd: No fault
MPLS VC labels: local 28, remote 16100
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Remote interface description:
Sequencing: receive disabled, send disabled
Control Word: Off (configured: autosense)
VC statistics:
transit packet totals: receive 169, send 771
transit byte totals: receive 21479, send 80640
transit packet drops: receive 0, seq error 0, send 0
"imposed label stack" shows the complete label stack (Transport label + PW label) used by the local PE to reach the remote PE.
"MPLS VC labels" shows the PW labels exchanged by the PEs.
The status you see next to "Label/status state machine" translates to the following:
- L=Local, R=Remote
- r=ready, n=not ready
- u=up, d=down
In VC statistics, the send direction counts the traffic from the AC to the PW, while the receive direction counts the traffic from the PW to the AC.
IOS-XR
R9#sh l2vpn xconnect detail
Group R9R1-XCONGRP, XC R9R1-P2P, state is up; Interworking none
AC: TenGigE0/0/0/9, state is up
Type Ethernet
MTU 1500; XC ID 0x40002; interworking none
Statistics:
packets: received 2324, sent 4514
bytes: received 1745, sent 4668
PW: neighbor 1.1.1.1, PW ID 19, state is up ( established )
PW class EoMPLS-PWCLASS, XC ID 0xc0000001
Encapsulation MPLS, protocol LDP
Source address 9.9.9.9
PW type Ethernet, control word disabled, interworking none
PW backup disable delay 0 sec
Sequencing not set
Load Balance Hashing: src-dst-ip
Flow Label flags configured (Tx=1,Rx=1), negotiated (Tx=0,Rx=0)
PW Status TLV in use
MPLS Local Remote
------------ ------------------------------ -----------------------------
Label 16100 28
Group ID 0x1c0 0x0
Interface TenGigE0/0/0/9 ** AC **
MTU 1500 1500
Control word disabled disabled
PW type Ethernet Ethernet
VCCV CV type 0x2 0x2
(LSP ping verification) (LSP ping verification)
VCCV CC type 0x6 0x2
(router alert label) (router alert label)
(TTL expiry)
------------ ------------------------------ -----------------------------
Incoming Status (PW Status TLV):
Status code: 0x0 (Up) in Notification message
Outgoing Status (PW Status TLV):
Status code: 0x0 (Up) in Notification message
MIB cpwVcIndex: 3221225473
Create time: 27/12/2013 03:23:01
Last time status changed: 27/12/2013 03:26:49
Statistics:
packets: received 4514, sent 2324
bytes: received 4668, sent 1745
IOS
R1#sh xconnect all
Legend: XC ST=Xconnect State S1=Segment1 State S2=Segment2 State
UP=Up DN=Down AD=Admin Down IA=Inactive
SB=Standby HS=Hot Standby RV=Recovering NH=No Hardware
XC ST Segment 1 S1 Segment 2 S2
------+---------------------------------+--+---------------------------------+--
UP ac Fa1/0(Ethernet) UP mpls 9.9.9.9:19 UP
IOS
R1#sh xconnect all detail
Legend: XC ST=Xconnect State S1=Segment1 State S2=Segment2 State
UP=Up DN=Down AD=Admin Down IA=Inactive
SB=Standby HS=Hot Standby RV=Recovering NH=No Hardware
XC ST Segment 1 S1 Segment 2 S2
------+---------------------------------+--+---------------------------------+--
UP ac Fa1/0(Ethernet) UP mpls 9.9.9.9:19 UP
Interworking: none Local VC label 28
Remote VC label 16100
pw-class: EoMPLS-PWCLASS
IOS-XR
R9#sh l2vpn xconnect
Legend: ST = State, UP = Up, DN = Down, AD = Admin Down, UR = Unresolved,
SB = Standby, SR = Standby Ready, (PP) = Partially Programmed
XConnect Segment 1 Segment 2
Group Name ST Description ST Description ST
------------------------ ----------------------- ----------------------
R9R1-XCONGRP R9R1-P2P UP Te0/0/0/9 UP 1.1.1.1 19 UP
---------------------------------------------------------------------------
When viewing the LFIB, the direction is the opposite from L3VPNs, pointing towards the AC this time.
IOS
R1#sh mpls forwarding-table
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
28 No Label l2ckt(19) 19658 Fa1/0 point2point
IOS-XR
R9#sh mpls forwarding
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
16100 Pop PW(1.1.1.1:19) Te0/0/0/9 point2point 464883
You can also use ping and traceroute in order to verify the PW (although it won't help you much in case of a core problem). In IOS-XR, mpls oam must first be activated.
IOS
R1#ping mpls pseudowire 9.9.9.9 19 segment 1 verbose repeat 1
Sending 1, 100-byte MPLS Echos to 9.9.9.9,
timeout is 2 seconds, send interval is 0 msec:
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
! size 100, reply addr 10.8.9.9, return code 3[Labels: 16100 Exp: 0]
Rx Interface: 10.8.9.9
local 1.1.1.1 remote 9.9.9.9 vc id 19
Success rate is 100 percent (1/1), round-trip min/avg/max = 1/1/1 ms
IOS
R1#traceroute mpls pseudowire 9.9.9.9 19 segment
Tracing MS-PW segments within range [1-1] peer address 9.9.9.9 and timeout 2 seconds
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
! 1 10.8.9.9 1 ms [Labels: 16100 Exp: 0]
local 1.1.1.1 remote 9.9.9.9 vc id 19
Static PWs
You can also use static pseudowires (without tLDP between PEs) if you manually define the local/remote labels to be used.
IOS
mpls label range 100 200 static 201 300
!
interface X
xconnect 1.1.1.1 22 encapsulation mpls manual pw-class STATICPW-PWCLASS
mpls label 201 202
IOS-XR
l2vpn
xconnect group XCONGRP
p2p LS-P2P
neighbor 1.1.1.1 pw-id 22
mpls static label local 201 remote 202
In IOS-XR, labels 16 to 15999 are reserved (by default) for static L2VPN pseudowires.
Interworking
Interworking is actually a transforming function that is required to interconnect two heterogeneous ACs, by providing the translation between the different L2 encapsulations.
There are 3 main modes:
- Ethernet (bridged)
- ethernet frames are extracted from the AC and sent over the PW
- non-ethernet frames are dropped
- ethernet frames with vlan tags, have their tags removed and then send over the PW
- Vlan
- ethernet frames are extracted from the AC and sent over the PW
- non-ethernet frames are dropped
- ethernet frames with vlan tags, are send with their tags over the PW
- IP (routed)
- ipv4 packets are extracted from the AC and sent over the PW
- non-ipv4 packets are dropped
Supported modes/technologies:
- Ethernet/Vlan to Frame-Relay
- MPLS/L2TPv3
- Ethernet/IP
- Ethernet/Vlan to PPP
- MPLS
- IP
- Ethernet to Vlan
- MPLS/L2TPv3
- Ethernet/IP
- Frame-Relay to PPP
- MPLS/L2TPv3
- IP
When doing interworking with frame-relay, you can't use inverse-arp (because there is no ip address on the other side of the local AC, neither at the other side of the remote AC), so you'll have to either use static mapping or change the frame-relay configuration to point-to-point.
In frame-relay interworking the PE router reports the PVC status to the CE router, based on the status of the pseudowire with the remote PE. Also the status of the local PVC detected by the PE router will be reflected into the pseudowire status towards the remote PE.
For ethernet, the PE acts like a proxy-ARP server to all ARP requests from the CE router. Sometimes you might need to clear the arp table on the CE after making changes on the PE.
For PPP, proxy IPCP is automatically enabled on the PE router when IP interworking is configured on the pseudowire.
Most of the times, you must configure all IGPs for point-to-point operation between the CE routers when configuring an Ethernet to non-Ethernet interworking setup.
Although it might not be applicable in the lab, generally you should take care of the AC MTU so that it doesn't exceed the core MTU.
IOS
pseudowire-class EoMPLS-IW-PWCLASS
encapsulation mpls
interworking ip
IOS-XR
l2vpn
xconnect group A-XCONGRP
p2p A-P2P
interworking ipv4
The rest of the configuration is the same as in normal L2VPN setup.
Interworking doesn't apply in VPLS.
PW Redundancy
IOS
Ethernet
interface FastEthernet1/0
xconnect 9.9.9.9 19 pw-class EoMPLS-IW-PWCLASS
backup peer 8.8.8.8 18 pw-class EoMPLS-IW-PWCLASS
Frame-Relay
connect FRCON Serial2/0 100 l2transport
xconnect 9.9.9.9 19 pw-class FRoMPLS-PWCLASS
backup peer 8.8.8.8 18 pw-class FRoMPLS-PWCLASS
The "backup peer" command is configured on the PE which will handle the redundancy.
Configure the following if you want to enable logging of the PW redundancy events.
IOS
xconnect logging redundancy
The PW status is signaled between the PEs, if it's supported (it's enabled by default).
IOS
R1#sh xconnect all
Legend: XC ST=Xconnect State S1=Segment1 State S2=Segment2 State
UP=Up DN=Down AD=Admin Down IA=Inactive
SB=Standby HS=Hot Standby RV=Recovering NH=No Hardware
XC ST Segment 1 S1 Segment 2 S2
------+---------------------------------+--+---------------------------------+--
UP pri ac Fa1/0(Ethernet) UP mpls 9.9.9.9:19 UP
IA sec ac Fa1/0(Ethernet) UP mpls 5.5.5.5:15 SB
R1#sh mpls l2transport vc
Local intf Local circuit Dest address VC ID Status
------------- -------------------------- --------------- ---------- ----------
Fa1/0 Ethernet 5.5.5.5 15 STANDBY
Fa1/0 Ethernet 9.9.9.9 19 UP
R1#sh mpls l2transport vc 15 detail
Local interface: Fa1/0 up, line protocol up, Ethernet up
Destination address: 5.5.5.5, VC ID: 15, VC status: standby
Output interface: Fa0/0.12, imposed label stack {17 27}
Preferred path: not configured
Default path: active
Next hop: 10.1.2.2
Create time: 00:04:30, last status change time: 00:03:36
Signaling protocol: LDP, peer 5.5.5.5:0 up
Targeted Hello: 1.1.1.1(LDP Id) -> 5.5.5.5, LDP is UP
Status TLV support (local/remote) : enabled/supported
LDP route watch : enabled
Label/status state machine : established, LrdRru
Last local dataplane status rcvd: No fault
Last local SSS circuit status rcvd: DOWN(UP, standby)
Last local SSS circuit status sent: No fault
Last local LDP TLV status sent: DOWN(standby)
Last remote LDP TLV status rcvd: No fault
Last remote LDP ADJ status rcvd: No fault
MPLS VC labels: local 32, remote 27
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Remote interface description:
Sequencing: receive disabled, send disabled
Control Word: On (configured: autosense)
VC statistics:
transit packet totals: receive 116, send 0
transit byte totals: receive 8221, send 0
transit packet drops: receive 0, seq error 0, send 0
R1#ping mpls pseudowire 5.5.5.5 15
%Total number of MS-PW segments is less than segment number; Adjusting the segment number to 1
Sending 5, 100-byte MPLS Echos to 5.5.5.5,
timeout is 2 seconds, send interval is 0 msec:
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 72/78/88 ms
You can configure the topology as "dual-homed" under the pw-class, if you want to have both primary and backup pseudowires appear as active simultaneously. In any case, traffic will continue to pass through the primary PW only.
IOS
pseudowire-class EOMPLS-PWCLASS
encapsulation mpls
status peer topology dual-homed
Keep in mind that the xconnect output is based on the configuration, while the mpls l2vc output is based on the result.
IOS
R1#sh xconnect all
Legend: XC ST=Xconnect State S1=Segment1 State S2=Segment2 State
UP=Up DN=Down AD=Admin Down IA=Inactive
SB=Standby HS=Hot Standby RV=Recovering NH=No Hardware
XC ST Segment 1 S1 Segment 2 S2
------+---------------------------------+--+---------------------------------+--
UP pri ac Fa1/0(Ethernet) UP mpls 9.9.9.9:19 UP
IA sec ac Fa1/0(Ethernet) UP mpls 5.5.5.5:15 SB
R1#sh mpls l2 vc
Local intf Local circuit Dest address VC ID Status
------------- -------------------------- --------------- ---------- ----------
Fa1/0 Ethernet 5.5.5.5 15 UP
Fa1/0 Ethernet 9.9.9.9 19 UP
Links
IOS-XR l2vpn configuration
Everything must be configured under the "l2vpn" hierarchy, including the pw-classes.
VPWS
IOS-XR
l2vpn
xconnect group A-XCONGRP
p2p A-P2P
interface X
!
neighbor Y pw-id k
pw-class Z
VPLS
IOS-XR
l2vpn
bridge group A-BRGRP
bridge-domain A-BRDOM
interface X1
interface X2
!
vfi A-VFI
neighbor Y1 pw-id k1
pw-class Z
neighbor Y2 pw-id k2
pw-class Z
xconnect/bridge groups are used solely for configuration grouping; you can put all bridge-domains under the same bridge group and all the p2ps under the same xconnect group.
You can have a neighbor directly under the bridge-domain, if you want to make this an access pseudowire. For core pseudowires (which will be 99% the case) you need to define the neighbor under the vfi.
Below you can find some useful commands for verification and troubleshooting.
Check AToM (AC/PW details, status, MTU, traffic, etc.)
IOS-XR
ASR9k#sh l2vpn xconnect ?
brief Encapsulation brief
detail Detailed information
encapsulation Filter on encapsulation
group Filter on group
groups All groups information
interface Filter on interface
mp2mp MP2MP Information
mspw ms_pw Information
neighbor Filter on neighbor
private Private information
pw-class Filter on pseudowire class
state Filter on xconnect state
summary Summary information
type Filter on xconnect type
| Output Modifiers
Check VPLS (AC/PW details, status, MTU, traffic, split-horizon, L2 features like storm-control, unicast/multicast/broadcast flooding, etc.)
IOS-XR
ASR9k#sh l2vpn bridge-domain ?
autodiscovery BGP/Radius autodiscovery information
bd-name Filter on bridge domain name
brief Brief information
detail Detailed information
group Filter on bridge domain group name
hardware Hardware information
interface Filter on interface
neighbor Filter on neighbor
objects Display bridge-domain objects information
pbb Provider backbone bridge information
private Private information
summary Bridge domain summary information
| Output Modifiers
Check VPLS (mac-addresses and various L2 features like DHCP snooping, ARP inspection, etc.)
IOS-XR
ASR9k#sh l2vpn forwarding bridge-domain ?
WORD Specify Bridge group name:Bridge domain name
debug Include debug information
detail Detailed information
hardware Read from hardware
location Specify a location
mac-address MAC address information
mroute multicast route information
pbb Provider backbone bridge information
private Include private information
L2transport ethertype
When configuring a l2transport interface in IOS-XR you have the following options regarding its tagging/ethertype:
- dot1q single vlan
- ethertype 0x8100 (default)
- dot1q double vlan (QinQ)
- ethertype 0x8100 (default)
- ethertype 0x9100
- ethertype 0x9200
- dot1ad single vlan
- ethertype 0x88a8 (default)
- dot1ad double vlan
- ethertype 0x88a8 (default)
dot1q refers to 802.1q, while dot1ad refers to 802.1ad (which is the standard).
H-VPLS
Instead of having a full-mesh of core pseudowires from end to end, you partition the network into smaller access domains (containing U-PEs and CEs) and a core domain (containing N-PEs and Ps).
N=Network
U= User
- core domain
- core PWs between all N-PEs
- access domains
- access PWs between each U-PE and a core N-PE
Configuration-wise the idea is the same as above:
- CE
- no change
- U-PE
- one (or two) p2p PW from the U-PE to one (or two) N-PE
- N-PE
- full-mesh of p2p PWs between all N-PEs
- P
- just MPLS switching
Example N-PE Config
IOS-XR
l2vpn
bridge group A-BRGRP
bridge-domain A-BRDOM
neighbor U-PE1 pw-id k1
pw-class Z
!
vfi A-VFI
neighbor N-PE2 pw-id k1
pw-class Z
neighbor N-PE3 pw-id k2
pw-class Z
The above N-PE is responsible for switching the traffic from the access PW (coming from U-PE1) to the core PWs (going to N-PE2 and N-PE3) and vice versa, based on the usual mac learning.
Remember that access PWs go outside the VFI and core PWs go inside the VFI, while everything goes under the bridge-domain.
Local Switching
Vlan to Vlan
IOS
interface FastEthernet0/0.1
encapsulation dot1q 1
!
interface FastEthernet0/0.2
encapsulation dot1q 2
!
connect VLAN2VLAN FastEthernet0/0.1 FastEthernet0/0.2
IOS-XR
interface TenGigE0/0/0/0.1 l2transport
dot1q vlan 100
!
interface TenGigE0/0/0/0.2 l2transport
dot1q vlan 200
!
l2vpn
xconnect group XCONGRP
p2p LS-P2P
interface TenGigE0/0/0/0.1
interface TenGigE0/0/0/0.2
Frame-Relay to Frame-Relay
IOS
frame-relay switching
!
interface Serial2/0
encapsulation frame-relay
frame-relay interface-dlci 100 switched
frame-relay intf-type dce
!
interface Serial2/1
encapsulation frame-relay
frame-relay interface-dlci 200 switched
frame-relay intf-type dce
!
connect FR2FR serial2/0 100 serial2/1 200
L2TPv3 Local Switching
IOS
pseudowire-class L2TP-1-CLASS
encapsulation l2tpv3
ip local interface Loopback0
!
pseudowire-class L2TP-11-CLASS
encapsulation l2tpv3
ip local interface Loopback1
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface Loopback1
ip address 11.11.11.11 255.255.255.255
!
interface FastEthernet0/0
xconnect 11.11.11.11 111 pw-class L2TP-1-CLASS
!
interface FastEthernet0/1
xconnect 1.1.1.1 111 pw-class L2TP-11-CLASS
2 loopbacks are required for L2TPv3 local switching to work.
IOS
R1#sh xconnect all
Legend: XC ST=Xconnect State S1=Segment1 State S2=Segment2 State
UP=Up DN=Down AD=Admin Down IA=Inactive
SB=Standby HS=Hot Standby RV=Recovering NH=No Hardware
XC ST Segment 1 S1 Segment 2 S2
------+---------------------------------+--+---------------------------------+--
UP ac Fa0/1(Ethernet) UP l2tp 1.1.1.1:111 UP
UP ac Fa0/0(Ethernet) UP l2tp 11.11.11.11:111 UP
R1#sh l2tun tunnel sum
L2TP Tunnel Information Total tunnels 2 sessions 2
LocTunID RemTunID Remote Name State Remote Address Sessn L2TP Class/
Count VPDN Group
1280397094 3308679294 R1 est 11.11.11.11 1 l2tp_default_cl
3308679294 1280397094 R1 est 1.1.1.1 1 l2tp_default_cl
L2VPN/AToM over GRE
Configuration Steps
- create a GRE tunnel with destination the remote L2VPN PE
- enable MPLS on the GRE tunnel
- route the PW through the GRE tunnel (using IGP, static route, preferred-path)
R2 (IOS)
interface Tunnel0
ip unnumbered Loopback0
mpls ip
tunnel source 2.2.29.2
tunnel destination 2.2.79.7
!
ip route 2.2.0.7 255.255.255.255 Tunnel0
!
interface Ethernet1/0
xconnect 2.2.0.7 27 pw-class PWCLASS
R7 (IOS)
interface Tunnel0
ip unnumbered Loopback0
mpls ip
tunnel source 2.2.79.7
tunnel destination 2.2.29.2
!
ip route 2.2.0.2 255.255.255.255 Tunnel0
!
interface Ethernet1/0
xconnect 2.2.0.2 27 pw-class PWCLASS
IOS-XR
interface tunnel-ip0
ipv4 address 10.10.10.1/24
tunnel mode gre ipv4
tunnel source 11.11.11.1
tunnel destination 12.12.12.2
!
mpls ldp
interface tunnel-ip0
!
l2vpn
xconnect group XCONGRP
p2p P2P
neighbor 2.2.2.2 pw-id 12
The other end of the tunnel is also the remote PE where the PW terminates.
You must also enable an IGP on the tunnel (or create a static route for a different hop), in order to drive the PW destination across it. Be careful of recursive routing (tunnel destination must not go through the tunnel itself).
In latest IOS-XR, you can also use the preferred tunnel-path feature in order to map the PW to a specific GRE tunnel, instead of pointing the PW to the remote PE router..
IOS-XR
l2vpn
pw-class GRE-PWCLASS
encapsulation mpls
preferred-path interface tunnel-ip0
Only PE-to-PE tunnels are supported when using preferred-path.
IOS supports something similar, but in very specific hardware and software.
PW Switching or Multisegment PW
An L2VPN multisegment PW (MS-PW, also known as switched PW) is a set of two or more PW segments that function as a single PW. They can be inside a single AS or they can span multiple AS.
The end routers are called terminating PE routers (T-PEs) and the switching routers are called S-PE routers.
S-PE's role is to
- terminate the tunnels of the preceding and succeeding PW segments
- switch the control and data planes of the preceding and succeeding PW segments
An MS-PW is declared to be up when all the single-segment PWs are up.
Interworking must be configured only at the edge PEs, not on the S-PEs.
In an MS-PW spanning PE-1 <=> S-PE-2 <=> S-PE-3 <=> PE-4, the configuration would be the following:
IOS
PE-1
interface X
xconnect S-PE-2 12 encapsulation mpls
S-PE-2
l2 vfi MS123-VFI point-to-point
neighbor PE-1 12 encapsulation mpls
neighbor S-PE-3 23 encapsulation mpls
S-PE-3
l2 vfi MS234-VFI point-to-point
neighbor S-PE-2 23 encapsulation mpls
neighbor PE-4 34 encapsulation mpls
PE-4
interface X
xconnect S-PE-3 34 encapsulation mpls
BGP-Based VPLS Autodiscovery
It enables each VPLS PE router to discover "automatically" the other PE routers that are part of the same VPLS domain using BGP.
BGP uses the L2VPN RIB to store endpoint provisioning information, which is updated each time a L2 VFI is configured. When BGP distributes the endpoint provisioning information in an update message to all its BGP neighbors, the endpoint information is used to configure a PW mesh between these neighbors.
In older releases, VPLS Autodiscovery is not supported with L2TPv3 or Inter-AS topologies.
You can configure both autodiscovered and manually configured PWs in the same VFI, but not for the same peer PE. If you need to do that, then configure appropriately the RT values to prevent each peer from receiving discovery data for that VPLS.
You will want to configure extra static VPLS neighbors for:
- PEs that do not participate in the autodiscovery process (in order to join the VPLS)
- PEs that have been configured with the Tunnel Selection feature
- U-PEs in H-VPLS configurations that do not participate in the autodiscovery process and have split-horizon forwarding disabled
The same RT is not allowed in multiple VFIs in the same PE router.
In older releases, the BGP peer address must be a /32 address bound to the peer's LDP router-id.
Split-horizon should not be disabled on autodiscovered neighbors.
Route reflectors can be used to reflect the BGP VPLS prefixes without having VPLS explicitly configured on them.
IOS
l2 vfi VPLSAUTO-VFI autodiscovery
vpn id 100
!
router bgp 1
no bgp default ipv4-unicast
neighbor 2.2.2.2 remote-as 1
neighbor 2.2.2.2 update-source Loopback0
!
address-family l2vpn vpls
neighbor 2.2.2.2 activate
neighbor 2.2.2.2 send-community extended
exit-address-family
The same vpn id must be configured on all PEs that are part of the same VPN.
It's good practice to also use "bgp update-delay 1" in order to minimize the initial update time.
There are various options you can configure under the l2 vfi, with the RT being the most important.
IOS
l2 vfi VPLSAUTO-VFI autodiscovery
vpn id X
vpls-id X:Y
rd X:Y
route-target import/export X:Y
l2 router-id x.x.x.x
Default values:
- vpls-id: ASN:vpn-id
- rd: ASN:vpn-id
- route-target: lower 6 bytes of rd and vpls-id
- l2 router-id: LDP router-id
VPLS ID is a BGP extended community value that identifies the VPLS domain. It must be the same between PEs of the same VPN and unique between different VFIs of the same PE. In case of Inter-AS VPLS, it must be defined manually and be the same on all PEs of the same VPLS domain, since ASNs are different.
No comments:
Post a Comment