Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Example: Configuring Pseudowire Redundancy in a Mobile Backhaul Scenario

This example shows how to configure pseudowire redundancy where Layer 2 and Layer 3 segments are interconnected in a mobile backhaul scenario.

Requirements

This example can be configured using the following hardware and software components:

  • Junos OS Release 13.2 or later

  • ACX5000 line of routers as the access (A) routers

  • MX Series 5G Universal Routing Platforms or M Series Multiservice Edge Routers for the Provider Edge (PE) Routers

  • PTX Series Packet Transport Routers acting as transit label-switched routers

  • T Series Core Routers for the Core Routers

Note:

The PE routers could also be T Series Core Routers but that is not typical. Depending on your scaling requirements, the core routers could also be MX Series 5G Universal Routing Platforms or M Series Multiservice Edge Routers. The Customer Edge (CE) devices could be other routers or switches from Juniper Networks or another vendor.

No special configuration beyond device initialization is required before configuring this example.

Overview

Device CE1 is a simple edge router with an IPv4 interface and a static route pointing to the PE devices. Device A1 establishes two virtual circuits (VCs) toward Device PE1 and Device PE2 by making use of the hot-standby statement. Device PE1 and Device PE2 terminate these VCs and enforce a policy condition over the logical tunnel IPv4 subnet. Device PE3 performs as a Layer 3 VPN provider edge device by having an IPv4 interface in a Layer 3 VPN shared with Device PE1 and Device PE2.

CLI Quick Configuration shows the configuration for all of the devices in Figure 1.

The section #configuration544__pw-redund-mobile-example-step-by-step describes the steps on Device A1 and Device PE1.

Figure 1: Pseudowire Redundancy in a Mobile Backhaul Example TopologyPseudowire Redundancy in a Mobile Backhaul Example Topology

Configuration

Procedure

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Device CE1

Device A1

Device PE1

Device PE2

Device PE3

Device CE2

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Device A1:

  1. Configure the interfaces.

    Enable MPLS on the core-facing interfaces. The ISO address family is also enabled, because IS-IS is used as the interior gateway protocol (IGP) in the provider network.

    On the customer-facing interface, you do not need to enable MPLS. On this interface, enable CCC encapsulation and address family CCC.

  2. Configure the RSVP on the core-facing interfaces and on the loopback interface.

    RSVP is used in the Layer 3 domain.

  3. Configure LDP on the core-facing interfaces and on the loopback interface.

    LDP is used in Layer 2 domain.

  4. Configure MPLS on the core-facing interfaces.

  5. Configure an interior gateway protocol, such as IS-IS or OSPF, on the core-facing interfaces and on the loopback interface.

  6. On the interface that faces the customer edge, configure the Layer 2 circuit.

    Configure the hot-standby statement on those routers with both active and standby virtual circuits (VCs) (Device A1 in our topology). You must include the pseudowire-status-tlv statement on access routers. Without the status TLV signaling, the standby flag cannot be advertised to remote provider edge (PE) devices.

    The revert-time statement and the maximum option should also be configured on access routers. Without the revert-time statement, traffic of all the VCs will not be transitioned to the primary path upon completion of the restoration. If a revert-time delay is defined but a maximum delay is not, then VCs are restored immediately upon the revert timer's expiration. The maximum option allows the VCs to be restored in a scattered fashion rather than all at once.

  7. To have the unilist next hop get pushed to other access routers, configure per-packet load balancing.

  8. Apply the per-packet load balancing policy.

  9. Configure the autonomous system (AS) ID and the router ID.

    Similarly, configure any other access devices.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Device PE1:

  1. Configure the interfaces.

    Enable MPLS on the core-facing interfaces.

  2. On Device PE1 and Device PE2, which are aggregation routers, configure a pair of logical tunnel interfaces to represent LT(x) and LT(y).

    The solution uses logical tunnel (lt-) paired interfaces for stitching the Layer 2 and Layer 3 domains.

    A Layer 2 pseudowire terminates on one of the logical tunnel interfaces, LT(x), defined with the circuit cross-connect (CCC) address family. A Layer 3 VPN terminates the second logical tunnel interface, LT(y), defined with the IPv4 (inet) address family. LT(x) and LT(y) are paired.

  3. (Optional) Associate a unique VRRP address with both Device PE1 and Device PE2.

    In this case, both Device PE1 and Device PE2 assume the primary state for the defined VIP IPv4 address, so no VRRP hello message are exchanged between the routers.

  4. Configure IS-IS or another IGP.

  5. Configure the MPLS on the core-facing interfaces.

  6. Configure label-switched paths to the other PE devices.

    BGP is a policy-driven protocol, so also configure and apply any needed routing policies. For example, you might want to export static routes into BGP.

  7. Configure LDP on the core-facing interfaces and on the loopback interface.

  8. Configure RSVP on the core-facing interfaces and on the loopback interface.

  9. Configure internal BGP (IBGP).

  10. Configure the Layer 2 circuit on the logical tunnel interface.

    Configure the hot-standby-vc-on statement if you want a hot standby pseudowire to be established upon arrival of PW_FWD_STDBY status TLV.

  11. Define a pair of conditions to be applied to the egress policy defined within the Layer 3 VPN instance.

    In both condition primary and condition standby, the matching route corresponds to the interface lt-1/2/0.600 (y), as this is the format in which egress routes appear in routing table mpls.0 to represent any given pseudowire.

    The difference between these conditions is in the standby attribute. Upon arrival of the PW_FWD_STDBY status TLV to Device PE1 or Device PE2, Junos OS matches condition standby, and in consequence, only term standby within the l3vpn policy will be executed. On the other hand, if the PW_FWD_STDBY status TLV is not present, the policy only matches condition primary, which then executes term primary in the l3vpn policy. Also, for logical tunnel-based CCC services, you must specify the logical tunnel interface, LT(y), that is associated with the logical tunnel CCC interface, LT(x). (See Understanding Pseudowire Redundancy Mobile Backhaul Scenarios.)

    Finally, for CCC-based conditions, Junos OS only allows mpls.0 as the matching routing table. For the address attribute, Junos OS only allows strings with a logical interface unit format (for example, lt-0/0/0.0).

  12. Configure the Layer 3 VPN export policy.

    If the Layer 2 virtual circuit (VC) is primary, the corresponding provider edge (PE) routing device advertises the attachment circuit’s (AC’s) subnet with the higher local preference. All aggregation PE devices initially advertise the AC’s subnet with the same local preference.

    This routing policy allows a higher local preference value to be advertised if the Layer 2 VC is active.

  13. Configure the Layer 3 VPN community members.

  14. Configure the Layer 3 VPN import policy, based on the Layer 3 VPN community.

  15. Configure OSPF export policy, based on the Layer 3 VPN community.

  16. (Optional) Configure a firewall filter to check the path taken by traffic.

  17. Configure the routing instance.

    This routing instance is in the Layer 2 domain where Device PE1 and Device PE2 are interconnected to the metro ring over multiaccess media (Ethernet). You must include the vrf-table-label' statement on Device PE1 and Device PE2 to enable advertisement of the direct subnet prefix corresponding to the logical tunnel (lt-) interface toward the Layer 3 domain.

    Device PE1 and Device PE2 use OSPF for Layer 3 VPN communication with Device CE1.

  18. Configure the autonomous system (AS) ID and router ID.

    Similarly, configure Device PE2.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show firewall, show protocols, show policy-options, show routing-options, and show routing-instances commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Device A1

Device PE1

If you are done configuring the devices, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Checking Layer 2 Circuits

Purpose

Upon Layer 2 virtual circuit (VC) establishment, the output of the show l2circuit connections command shows the active and the hot-standby VC. In addition, control-plane details are shown for the hot-standby VC.

Action

From operational mode, enter the show l2circuit connections extensive command.

Meaning

From the perspective of Device PE1 and Device PE2, a single Layer 2 circuit is established toward access routers, so there is no standby device information in the CLI output of the show l2circuit connections command. Note that no timing and flapping information is provided for the VC acting as the hot-standby. Junos OS only allows these counters to be tracked for the active VC.

Checking the Policy Conditions

Purpose

On the PE devices, verify the state of the different conditions defined as part of the Layer3 VPN's egress policy, where 10.41.0.0/24 corresponds to the logical tunnel (y) subnet.

Action

From operational mode, enter the show policy conditions detail command.