Redundant Spoke Pseudowire Connections

Redundant spoke pseudowires to PE peers can be configured from a MTU to provide backup connectivity into a VPLS core.

The addition of a redundant spoke pseudowire is optional. By default, the spoke pseudowire to the primary peer is used to forward packets. In the event of a network failure over the primary pseudowire, the spoke pseudowire to the secondary peer is used to provide redundant VPLS connectivity. An example network is shown in the following figure.

Click to expand in new window
Example H-VPLS Network with Redundant Spokes

When both the primary and secondary pseudowires are established, the MTU is responsible for blocking the secondary pseudowire. Any packets received on the secondary pseudowire while the primary pseudowire is active are discarded. This behavior prevents packet-forwarding loops within the L2 VPN.

Since the MTU is responsible for choosing which pseudowire to the VPLS is active, the MTU is uniquely responsible for preventing network loops. The MTU uses only one spoke pseudowire per VPLS and only the label stack associated with the active pseudowire is programmed into the hardware. If the active pseudowire fails, then the label stack for the active pseudowire is removed from hardware. The secondary pseudowire label stack is then installed in the hardware providing a redundant VPLS link from the MTU into the VPLS core. Customer connectivity through the MTU should experience minimal disruption.

A recent IETF draft has proposed using the Status TLV defined in RFC 4447, Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP), to signal that a pseudowire is actively being used to forward traffic. The draft proposes a new Active/Standby bit to indicate that a pseudowire is operational but is being blocked due to redundancy considerations. Until this proposed encoding progresses in the IETF, the ExtremeXOS software will use the existing Not Forwarding bit defined in RFC 4447 to indicate a blocked or standby condition.

When a failover occurs from a primary pseudowire to a secondary pseudowire, the spoke node clears its FDB (forwarding database) database of MAC addresses learned over the primary pseudowire. It then begins learning MAC addresses over the new active pseudowire. To inform its peers to clear their learned MAC database, the PE node can send a MAC address withdrawal message (if this feature is enabled) to the other VPLS full-mesh core nodes. Upon receipt of the MAC address withdrawal message, each core node clears its database. In this manner, other core nodes re-learn MAC addresses from the correct pseudowire or port.

Packets can be received out-of-order by the VPLS destination device during certain pseudowire failover events. In the redundant VPLS spoke configuration, when a pseudowire fails, traffic is immediately redirected to the backup or secondary core node. For a very short period of time, there may be transit packets that are simultaneously in route via both the primary pseudowire and secondary pseudowire. No attempt to prevent mis-ordered packets from being received is made.

The command to configure the VPLS peer from an MTU to a PE and from a PE to an MTU is fundamentally the same. However, the optional primary and secondary pseudowire keywords are only applicable on the MTU since the MTU is responsible for preventing loops within the VPLS. A switch cannot be configured with a primary and a secondary pseudowire to the same peer within a VPLS. This is an invalid configuration since it provides no redundant protection for a failed PE peer.