For LDP-signaled pseudowires, including L2CIRCUIT and VPLS, a redundant pseudowire can act as a backup connection between PE routers and CE devices, thus maintaining Layer 2 circuit and VPLS services after certain types of failures. This feature can help improve the reliability of certain types of networks where a single point of failure could interrupt service for multiple customers.
This article demonstrates with an example how the redundant pseudowire feature can be configured on MX Series routers.
Note: Redundant pseudowires cannot reduce traffic loss to zero. However, they provide a way to gracefully recover from pseudowire failures such that services can be restarted within a known time limit.
When you configure redundant pseudowires to remote PE routers, you configure one to act as the primary pseudowire over which customer traffic will be transmitted and you configure another to act as the backup pseudowire in the event that the primary fails. You configure the two pseudowires statically, and allocate a separate label for the primary and backup neighbors.
Topology
+-------+ | R2 |ge-1/2/1 +------------+ PE2 +-------------+ | +---+---+ | | | |ge-1/3/1 +-----+ +---+---+ | +--------+ +--------+ | | ge-1/2/0| R1 | | | |ge-1/2/3 | | | CE1 +-----------+ PE1 | | | SW +-------------+ CE2 | +-----+ge-1/3/0 +---+---+ | +--------+ ge-1/3/3+--------+ 10.0.0.1/24 | +---+---+ |ge-1/3/2 10.0.0.2/24 | | R3 | | +------------+ PE3 +-------------+ +-------+ge-1/2/2
In the above topology:
CE facing interface configuration on R1/R2/R3
R1/R2/R3> show configuration interfaces ge-x/x/x unit 100 { encapsulation vlan-vpls; vlan-id 100; family vpls; }
VPLS configuration on R1 (pseudowire redundancy configured on this router)
R1> show configuration routing-instances test { instance-type vpls; interface ge-1/2/0.100; protocols { vpls { encapsulation-type ethernet-vlan; interface ge-1/2/0.100; no-tunnel-services; vpls-id 100; mtu 9192; neighbor 172.16.0.2 { backup-neighbor 172.16.0.3; } } } }
VPLS configuration on R2
R2> show configuration routing-instances test { instance-type vpls; interface ge-1/2/1.100; protocols { vpls { encapsulation-type ethernet-vlan; interface ge-1/2/1.100; no-tunnel-services; vpls-id 100; mtu 9192; neighbor 172.16.0.1; } } }
VPLS configuration on R3
R3> show configuration routing-instances test { instance-type vpls; interface ge-1/2/2.100; protocols { vpls { encapsulation-type ethernet-vlan; interface ge-1/2/2.100; no-tunnel-services; vpls-id 100; mtu 9192; neighbor 172.16.0.1; } } }
Output / Verification
R1> show vpls connectionsLayer-2 VPN connections: Legend for connection status (St) EI -- encapsulation invalid NC -- interface encapsulation not CCC/TCC/VPLSEM -- encapsulation mismatch WE -- interface and instance encaps not sameVC-Dn -- Virtual circuit down NP -- interface hardware not presentCM -- control-word mismatch -> -- only outbound connection is upCN -- circuit not provisioned <- -- only inbound connection is upOR -- out of range Up -- operationalOL -- no outgoing label Dn -- down LD -- local site signaled down CF -- call admission control failure RD -- remote site signaled down SC -- local and remote site ID collisionLN -- local site not designated LM -- local site ID not minimum designatedRN -- remote site not designated RM -- remote site ID not minimum designatedXX -- unknown connection status IL -- no incoming labelMM -- MTU mismatch MI -- Mesh-Group ID not availableBK -- Backup connection ST -- Standby connectionPF -- Profile parse failure PB -- Profile busyRS -- remote site standby SN -- Static NeighborLB -- Local site not best-site RB -- Remote site not best-siteVM -- VLAN ID mismatch HS -- Hot-standby Connection Legend for interface statusUp -- operational Dn -- down Instance: test VPLS-id: 100 Neighbor Type St Time last up # Up trans 172.16.0.2(vpls-id 100) rmt Up Aug 5 08:01:27 2019 1 <<<<< <Primary neighbor> >>>>> Remote PE: 172.16.0.2, Negotiated control-word: No Incoming label: 262145, Outgoing label: 262145 Negotiated PW status TLV: No Local interface: lsi.118489088, Status: Up, Encapsulation: VLAN Description: Intf - vpls test neighbor 172.16.0.2 vpls-id 100 Flow Label Transmit: No, Flow Label Receive: No 172.16.0.3(vpls-id 100) rmt BK << <Backup neighbor. In "Backup connection" status> >>>
R2> show vpls connections <SNIP> Instance: test VPLS-id: 100 Neighbor Type St Time last up # Up trans 172.16.0.1(vpls-id 100) rmt Up Aug 5 08:01:27 2019 1 <<<<< <primary neighbor> >>>>> Remote PE: 172.16.0.1, Negotiated control-word: No Incoming label: 262145, Outgoing label: 262145 Negotiated PW status TLV: No Local interface: lsi.68157440, Status: Up, Encapsulation: VLAN Description: Intf - vpls test neighbor 172.16.0.1 vpls-id 100 Flow Label Transmit: No, Flow Label Receive: No
R3> show vpls connections <SNIP> Instance: test VPLS-id: 100 Neighbor Type St Time last up # Up trans 172.16.0.1(vpls-id 100) rmt OL <<<<< <backup neighbor. In "no outgoing label" status> >>>>>
R3> show interfaces ge-1/2/2 <<<<< <On backup PE, CE facing interface is up. Loop prevention done on core side> >>>>> <<<<< <This is different from BGP signaled VPLS Multihoming, where interface is ccc-down> >>>>> Logical interface ge-1/2/2.100 (Index 413) (SNMP ifIndex 673) Flags: Up SNMP-Traps 0x0 VLAN-Tag [ 0x8100.100 ] Encapsulation: VLAN-VPLS Input packets : 12 Output packets: 0 Protocol vpls, MTU: 1522 Flags: Is-Primary
ce1> ping 10.0.0.2 <<<<< <ping between CEs works fine> >>>>> PING 10.0.0.2 (10.0.0.2): 56 data bytes64 bytes from 10.0.0.2: icmp_seq=0 ttl=64 time=47.888 ms64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.741 ms64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.853 ms64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.841 ms^C--- 10.0.0.2 ping statistics ---4 packets transmitted, 4 packets received, 0% packet lossround-trip min/avg/max/stddev = 0.741/12.581/47.888/20.385 ms
sw> show bridge mac-table Logical system : swRouting instance : defaultBridging domain : v100, VLAN : 100 MAC MAC Logical NH MAC active address flags interface Index property source 80:71:1f:c1:21:90 D ge-1/3/1.100 <<<<< <CE1 MAC learned from R2, primary neighbor> >>>>> 80:71:1f:c1:21:93 D ge-1/2/3.100
Other Parameter Options
Standby
R1#set routing-instances test protocols vpls neighbor 172.16.0.2 backup-neighbor 172.16.0.3 standby
Configures the pseudowire to the specified backup neighbor as the standby. When you configure this statement, traffic flows over both the active and standby pseudowires to the CE device. The CE device drops the traffic from the standby pseudowire, unless the active pseudowire fails. If the active pseudowire fails, the CE device automatically switches to the standby pseudowire.
R1>show vpls connections<SNIP> Instance: test VPLS-id: 100 Neighbor Type St Time last up # Up trans 172.16.0.2(vpls-id 100) rmt Up Aug 5 08:01:27 2019 1 Remote PE: 172.16.0.2, Negotiated control-word: No Incoming label: 262145, Outgoing label: 262145 Negotiated PW status TLV: No Local interface: lsi.118489088, Status: Up, Encapsulation: VLAN Description: Intf - vpls test neighbor 172.16.0.2 vpls-id 100 Flow Label Transmit: No, Flow Label Receive: No 172.16.0.3(vpls-id 100) rmt ST <<<<< <backup neighbor in "Standby connection" mode> >>>>>
R3> show vpls connections<SNIP> Instance: test VPLS-id: 100 Neighbor Type St Time last up # Up trans 172.16.0.1(vpls-id 100) rmt Up Aug 5 08:11:43 2019 1 <<<<< <backup neighbor comes up> >>>>> Remote PE: 172.16.0.1, Negotiated control-word: No Incoming label: 262145, Outgoing label: 262146 Negotiated PW status TLV: No Local interface: lsi.84934656, Status: Up, Encapsulation: VLAN Description: Intf - vpls test neighbor 172.16.0.1 vpls-id 100 Flow Label Transmit: No, Flow Label Receive: No
switchover-delay
R1#set routing-instances test protocols vpls neighbor 172.16.0.2 switchover-delay 5000
After the primary pseudowire goes down, switchover-delay specifies the delay (in milliseconds) to wait before the backup pseudowire takes over. The default is 10,000 milliseconds.
revert-time
R1#set routing-instances test protocols vpls neighbor 172.16.0.2 revert-time 60
With this option, you can specify a revert time for the redundant pseudowires when the primary neighbor comes back up from failure. Without the revert-time statement, by default, the virtual circuit (VC) traffic is not transitioned to the primary path upon restoration of the primary path.