Redundant VPWS
Last updated
Last updated
Load vpws.redundancy.init.cfg
Configure a VPWS between R1 and CE8. (R1 is now acting as a CE).
Ensure that R1 has redundant connections for the VPWS to both R2 and R4.
The connection to R2 should be primary, and R4 should be standby.
R1 and CE8 are already configured with the 10.1.8.X/24 subnet.
Usually a psuedowire is not redundant. If a PE fails, there is no redundancy and the VPWS is hard down. To add redundancy to an L2 service it is a little more complicated than an L3 VPN service. With L3VPN we can use routing protocol knobs to control routing.
To add redundancy to an xconnect we can use the group priority feature. We can define multiple remote neighbors under the xconnect and specify them in the same group and give one a lower (better) priority than the other. The group is just a string, but it must match for all neighbors in the group.
On R6 we can see that there are two PWs. The PW to R4 is in the standby state. As long as the primary PW (to R2) is up, the PW to R4 will be in standby, waiting to take over.
We can also see this using show l2vpn service xconnect all
On R1, the router will see CE8’s MAC arriving via the link to R2, so all outgoing traffic will naturally use that link. This allows us to use active-active dual connections.
Let’s simulate a PE failure by shutting all interfaces on R2 down. This will prompt R6 to switchover to the standby PW for this xconnect.
Ping R1 from CE8. The MAC will flap over to the link facing R4. (Previously this was Gi5). This allows R1 to dynamically react to PE failure.
