Configure Hot-Standby Pseudowire Redundancy in H-VPLS

The benefits of hot-standby pseudowire for H-VPLS include the following:

• Rapid recovery to a rerouted path when the active path has a failure.

• Reduced traffic disruption during the transition.

Figure 1 shows a simplified 2-level hierarchical VPLS (H-VPLS) network with an active pseudowire connecting the primary hub HL3-1 to spokes HL4-1 and HL4-2. A standby pseudowire connects the backup hub HL3-2 to spokes HL4-1 and HL4-2. When the primary pseudowire fails, the standby pseudowire takes over.

With the hot-standby enabled, both the primary and backup hub have programmed active and standby pseudowire paths to spoke devices in the Packet Forwarding Engine. Likewise, the spoke devices have programmed active and standby pseudowire paths. Having both active and pseudowire paths preprogrammed on the Packet Forwarding Engine reduces the amount of traffic that gets discarded during transition. Both the active and standby pseudowire can send and receive traffic. So we must give special consideration to preventing traffic loops when spoke devices send unknown traffic. To configure hot-standby in an H-VPLS network, configure the following statements on all hub-and-spoke devices:

On the hub devices:

• Include the pseudowire-status-tlv statement at the [edit routing-instances routing-instance-name protocols vpls mesh-group mesh-group-name neighbor address ] hierarchy. PE devices use the pseudowire status type length variable (TLV) to communicate the pseudowire status.

• Include the hot-standby-vc-on statement at the [edit routing-instances routing-instance-name protocols vpls mesh-group mesh-group-name neighbor address pseudowire-status-tlv] hierarchy on the hub devices.

  This allows the backup hub device managing the standby pseudowire to preprogram pseudowire paths to the spoke devices.

• Include the load-balance per-packet statement at the [edit policy-options policy-statement policy-name term term-name then] hierarchy and apply the routing policy to all routes in the forwarding table.

On the spoke devices:

• Include the pseudowire-status-tlv statement at the [edit routing-instances routing-instance-name protocols vpls neighbor address ] hierarchy. PE devices use the pseudowire status type length variable (TLV) to communicate the pseudowire status.

• Include the hot-standby statement at the [edit routing-instances routing-instance-name protocols vpls neighbor address backup-neighbor address] hierarchy on the spoke devices. Enabling hot-standby allows the spoke devices to preprogram the routes and next hops of the standby pseudowire.

• Include the vpls-hot-standby-convergence statement at the [ routing-options forwarding-table] hierarchy on the spoke device. When you enable vpls-hot-standby-convergence, the Junos device sends advertising messages with different labels on the active and standby pseudowire. The spoke device can then differentiate the return messages coming back from the active and standby pseudowire.

• Include the load-balance per-packet statement at the [edit policy-options policy-statement policy-name term term-name then] hierarchy level and apply the routing policy to all routes in the forwarding table.

• (Optional) In some cases, you may want to include a switchover-delay at the [edit routing-instances routing-instance-name protocols vpls mesh-group mesh-group-name neighbor address ] hierarchy on the spoke device. This is the time that the device waits before switching to the backup neighbor after detecting a failure in the primary pseudowire connection. We recommend a delay of 60 seconds.

The following sample hot-standby configuration shows how to configure the hub-and-spoke devices.

Figure 1: H-VPLS Hub-And-Spoke Model