Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

MPLS Pseudowires Configuration

Ethernet Pseudowire Overview

Starting in Junos OS Release 14.1X53 and Junos OS Release 16.1, an Ethernet pseudowire is used to carry Ethernet or 802.3 Protocol Data Units (PDUs) over an MPLS network enabling service providers to offer emulated Ethernet services over existing MPLS networks. Ethernet or 802.3 PDUs are encapsulated within the pseudowire to provide a point-to-point Ethernet service. For the point-to-point Ethernet service, the following fault management features are supported:

  • The IEEE 802.3ah standard for Operation, Administration, and Management (OAM). You can configure IEEE 802.3ah OAM link-fault management on Ethernet point-to-point direct links or links across Ethernet repeaters.

    Ethernet OAM link-fault management can be used for physical link-level fault detection and management. It uses a new, optional sublayer in the data link layer of the OSI model. Ethernet OAM can be implemented on any full-duplex point-to-point or emulated point-to-point Ethernet link. A system-wide implementation is not required; OAM can be deployed on particular interfaces of a router. Transmitted Ethernet OAM messages or OAM PDUs are of standard length, untagged Ethernet frames within the normal frame length limits in the range 64–1518 bytes.

  • Ethernet connectivity fault management (CFM) to monitor the physical link between two routers.

    • Connection protection using the continuity check protocol for fault monitoring . The continuity check protocol is a neighbor discovery and health check protocol that discovers and maintains adjacencies at the VLAN or link level.

    • Path protection using the linktrace protocol for path discovery and fault verification . Similar to IP traceroute, the linktrace protocol maps the path taken to a destination MAC address through one or more bridged networks between the source and destination.

Example: Ethernet Pseudowire Base Configuration

Requirements

The following is a list of the hardware and software requirements for this configuration.

  • One ACX Series router

  • Junos OS Release 12.2 or later

Overview of an Ethernet Pseudowire Base Configuration

The configuration shown here is the base configuration of an Ethernet pseudowire with Ethernet cross-connect for physical interface encapsulation on an ACX Series router. This configuration is for one provider edge router. To complete the configuration of an Ethernet pseudowire, you need to repeat this configuration on an other provider edge router in the Multiprotocol Label Switched (MPLS) network.

Configuring an Ethernet Pseudowire

Procedure

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them in 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:

Note:

To configure an Ethernet pseudowire with 802.1Q tagging for cross-connect logical interface encapsulation, include the vlan-ccc statement at the [edit interfaces ge-0/1/1 unit 0 encapsulation] hierarchy level instead of the ethernet-ccc statement shown in this example.

Step-by-Step Procedure
  1. Create two Gigabit Ethernet interfaces, set the encapsulation mode on one interface and MPLS on the other interface. Create the loopback (lo0) interface:

  2. Enable the MPLS and RSVP protocols on the interface configured with MPLS—ge-0/2/0.0:

  3. Configure LDP. If you configure RSVP for a pseudowire, you must also configure LDP:

  4. Configure a point-to-point label-switched path (LSP) and disable constrained-path LSP computation:

  5. Configure OSPF and enable traffic engineering on the MPLS interface—ge-0/2/0.0, and on the loopback (lo0) interface:

  6. Uniquely identify a Layer 2 circuit for the Ethernet pseudowire:

Results

Pseudowire Overview for ACX Series Universal Metro Routers

A pseudowire is a Layer 2 circuit or service, which emulates the essential attributes of a telecommunications service— such as a T1 line, over an MPLS packet-switched network. The pseudowire is intended to provide only the minimum necessary functionality to emulate the wire with the required degree of faithfulness for the given service definition. On the ACX Series routers, Ethernet, Asynchronous Transfer Mode (ATM), and time-division multiplexing (TDM) pseudowires are supported. The following pseudowire features are supported:

  • Pseudowire transport service carrying Layer 1 and Layer 2 information over an IP and MPLS network infrastructure. Only similar end points are supported on the ACX Series—for example, T1 to T1, ATM to ATM, and Ethernet to Ethernet.

  • Redundant pseudowires backup connections between PE routers and CE devices, maintaining Layer 2 circuits and services after certain types of failures. Pseudowire redundancy improves the reliability of certain types of networks (metro for example) where a single point of failure could interrupt service for multiple customers. The following pseudowire redundancy features are supported:

    • Maintenance of Layer 2 circuit services after certain types of failures with a standby pseudowire, which backs up the connection between PE routers and CE devices.

    • In case of failure, a protect interface, which backs up the primary interface. Network traffic uses the primary interface only so long as the primary interface functions. If the primary interface fails, traffic is switched to the protect interface.

    • Hot and cold standby enabling swift cut over to the backup or standby pseudowire.

  • Ethernet connectivity fault management (CFM), which can be used to monitor the physical link between two routers. The following major features of CFM for Ethernet pseudowires only are supported:

    • Connection protection using the continuity check protocol for fault monitoring. The continuity check protocol is a neighbor discovery and health check protocol that discovers and maintains adjacencies at the VLAN or link level.

    • Path protection using the linktrace protocol for path discovery and fault verification. Similar to IP traceroute, the linktrace protocol maps the path taken to a destination MAC address through one or more bridged networks between the source and destination.

Understanding Multisegment Pseudowire for FEC 129

Understanding Multisegment Pseudowire

A pseudowire is a Layer 2 circuit or service that emulates the essential attributes of a telecommunications service, such as a T1 line, over an MPLS packet-switched network (PSN). The pseudowire is intended to provide only the minimum necessary functionality to emulate the wire with the required resiliency requirements for the given service definition.

When a pseudowire originates and terminates on the edge of the same PSN, the pseudowire label is unchanged between the originating and terminating provider edge (T-PE) devices. This is called a single-segment pseudowire (SS-PW). Figure 1 illustrates an SS-PW established between two PE routers. The pseudowires between the PE1 and PE2 routers are located within the same autonomous system (AS).

Figure 1: L2VPN PseudowireL2VPN Pseudowire

In cases where it is impossible to establish a single pseudowire from a local to a remote PE, either because it is unfeasible or undesirable to establish a single control plane between the two PEs, a multisegment pseudowire (MS-PW) is used.

An MS-PW is a set of two or more contiguous SS-PWs that are made to function as a single point-to-point pseudowire. It is also known as switched pseudowire. MS-PWs can go across different regions or network domains. A region can be considered as an interior gateway protocol (IGP) area or a BGP autonomous system that belongs to the same or different administrative domain. An MS-PW spans multiple cores or ASs of the same or different carrier networks. A Layer 2 VPN MS-PW can include up to 254 pseudowire segments.

Figure 2 illustrates a set of two or more pseudowire segments that function as a single pseudowire. The end routers are called terminating PE (T-PE) routers, and the switching routers are called switching PE (S-PE) routers. The S-PE router terminates the tunnels of the preceding and succeeding pseudowire segments in an MS-PW. The S-PE router can switch the control and data planes of the preceding and succeeding pseudowire segments of the MS-PW. An MS-PW is declared to be up when all the single-segment pseudowires are up.

Figure 2: Multisegment PseudowireMultisegment Pseudowire

Using FEC 129 for Multisegment Pseudowire

Currently, there are two types of attachment circuit identifiers (AIIs) defined under FEC 129:

  • Type 1 AII

  • Type 2 AII

The support of an MS-PW for FEC 129 uses type 2 AII. A type 2 AII is globally unique by definition of RFC 5003.

Single-segment pseudowires (SS-PWs) using FEC 129 on an MPLS PSN can use both type 1 and type 2 AII. For an MS-PW using FEC 129, a pseudowire itself is identified as a pair of endpoints. This requires that the pseudowire endpoints be uniquely identified.

In the case of a dynamically placed MS-PW, there is a requirement for the identifiers of attachment circuits to be globally unique, for the purposes of reachability and manageability of the pseudowire. Thus, individual globally unique addresses are allocated to all the attachment circuits and S-PEs that make up an MS-PW.

Type 2 AII is composed of three fields:

  • Global_ID—Global identification, which is usually the AS number.

  • Prefix—IPv4 address, which is usually the router ID.

  • AC_ID—Local attachment circuit, which is a user-configurable value.

Since type 2 AII already contains the T-PE's IP address and it is globally unique, from the FEC 129 pseudowire signaling point of view, the combination (AGI, SAII, TAII) uniquely identifies an MS-PW across all interconnected pseudowire domains.

Establishing a Multisegment Pseudowire Overview

An MS-PW is established by dynamically and automatically selecting the predefined S-PEs and placing the MS-PW between two T-PE devices.

When S-PEs are dynamically selected, each S-PE is automatically discovered and selected using the BGP autodiscovery feature, without the requirement of provisioning the FEC 129 pseudowire-related information on all the S-PEs. BGP is used to propagate pseudowire address information throughout the PSN.

Since there is no manual provisioning of FEC 129 pseudowire information on the S-PEs, the Attachment Group Identifier (AGI) and Attachment Individual Identifier (AII) are reused automatically, and choosing the same set of S-PEs for the pseudowire in both the forwarding and reverse direction is achieved through the active and passive role of each T-PE device.

  • Active—The T-PE initiates an LDP label mapping message.

  • Passive—The T-PE does not initiate an LDP label mapping message until it receives a label mapping message initiated by the active T-PE. The passive T-PE sends its label mapping message to the same S-PE from where it received the label mapping message originated from its active T-PE. This ensures that the same set of S-PEs are used in the reverse direction.

Pseudowire Status Support for Multisegment Pseudowire

Pseudowire Status Behavior on T-PE

The following pseudowire status messages are relevant on the T-PE:

  • 0x00000010—Local PSN-facing pseudowire (egress) transmit fault.

  • 0x00000001—Generic nonforwarding fault code. This is set as the local fault code. The local fault code is set at the local T-PE, and LDP sends a pseudowire status TLV message with the same fault code to the remote T-PE.

  • Fault codes are bit-wise OR’ed and stored as remote pseudowire status codes.

Pseudowire Status Behavior on S-PE

The S-PE initiates the pseudowire status messages that indicate the pseudowire faults. The SP-PE in the pseudowire notification message hints where the fault was originated.

  • When a local fault is detected by the S-PE, a pseudowire status message is sent in both directions along the pseudowire. Since there are no attachment circuits on an S-PE, only the following status messages are relevant:

    • 0x00000008—Local PSN-facing pseudowire (ingress) receive fault.

    • 0x00000010—Local PSN-facing pseudowire (egress) transmit fault.

  • To indicate which SS-PW is at fault, an LDP SP-PE TLV is attached with the pseudowire status code in the LDP notification message. The pseudowire status is passed along from one pseudowire to another unchanged by the control plane switching function.

  • If an S-PE initiates a pseudowire status notification message with one particular pseudowire status bit, then for the pseudowire status code an S-PE receives, the same bit is processed locally and not forwarded until the S-PE's original status error is cleared.

  • An S-PE keeps only two pseudowire status codes for each SS-PW it is involved in – local pseudowire status code and remote pseudowire status code. The value of the remote pseudowire status code is the result of logic or operation of the pseudowire status codes in the chain of SS-PWs preceding this segment. This status code is incrementally updated by each S-PE upon receipt and communicated to the next S-PE. The local pseudowire status is generated locally based on its local pseudowire status.

  • Only transmit fault is detected at the SP-PE. When there is no MPLS LSP to reach the next segment, a local transmit fault is detected. The transmit fault is sent to the next downstream segment, and the receive fault is sent to the upstream segment.

  • Remote failures received on an S-PE are just passed along the MS-PW unchanged. Local failures are sent to both segments of the pseudowire that the S-PE is involved in.

Pseudowire TLV Support for MS-PW

MS-PW provides the following support for the LDP SP-PE TLV [RFC 6073]:

  • The LDP SP-PE TLVs for an MS-PW include:

    • Local IP address

    • Remote IP address

  • An SP-PE adds the LDP SP-PE TLV to the label mapping message. Each SP-PE appends the local LDP SP-PE TLV to the SP-PE list it received from the other segment.

  • The pseudowire status notification message includes the LDP SP-PE TLV when the notification is generated at the SP-PE.

Supported and Unsupported Features

Junos OS supports the following features with MS-PW:

  • MPLS PSN for each SS-PW that builds up the MS-PW.

  • The same pseudowire encapsulation for each SS-PW in an MS-PW – Ethernet or VLAN-CCC.

  • The generalized PWid FEC with T-LDP as an end-to-end pseudowire signaling protocol to set up each SS-PW.

  • MP-BGP to autodiscover the two endpoint PEs for each SS-PW associated with the MS-PW.

  • Standard MPLS operation to stitch two side-by-side SS-PWs to form an MS-PW.

  • Automatic discovery of S-PE so that the MS-PW can be dynamically placed.

  • Minimum provisioning of S-PE.

  • Operation, administration, and maintenance (OAM) mechanisms, including end-to-end MPLS ping or end-to-any-S-PE MPLS ping, MPLS path trace, end-to-end VCCV, and Bidirectional Forwarding Detection (BFD).

  • Pseudowire swithing point (SP) PE TLV for the MS-PW.

  • Composite next hop on MS-PW.

  • Pseudowire status TLV for MS-PW.

Junos OS does not support the following MS-PW functionality:

  • Mix of LDP FEC 128 and LDP FEC 129.

  • Static pseudowire where each label is provisioned staticially.

  • Graceful Routing Engine switchover.

  • Nonstop active routing.

  • Multihoming.

  • Partial connectivity verification (originating from an S-PE) in OAM.

Example: Configuring a Multisegment Pseudowire

This example shows how to configure a dynamic multisegment pseudowire (MS-PW), where the stitching provider edge (S-PE) devices are automatically and dynamically discovered by BGP, and pseudowires are signaled by LDP using FEC 129. This arrangement requires minimum provisioning on the S-PEs, thereby reducing the configuration burden that is associated with statically configured Layer 2 circuits while still using LDP as the underlying signaling protocol.

Requirements

This example uses the following hardware and software components:

  • Six routers that can be a combination of M Series Multiservice Edge Routers, MX Series 5G Universal Routing Platforms, T Series Core Routers, or PTX Series Packet Transport Routers.

    • Two remote PE devices configured as terminating PEs (T-PEs).

    • Two S-PEs configured as:

      • Route reflectors, in the case of interarea configuration.

      • AS boundary routers or route reflectors, in the case of inter-AS configuration.

  • Junos OS Release 13.3 or later running on all the devices.

Before you begin:

  1. Configure the device interfaces.

  2. Configure OSPF or any other IGP protocol.

  3. Configure BGP.

  4. Configure LDP.

  5. Configure MPLS.

Overview

Starting with Junos OS Release 13.3, you can configure an MS-PW using FEC 129 with LDP signaling and BGP autodiscovery in an MPLS packet-switched network (PSN). The MS-PW feature also provides operation, administration, and management (OAM) capabilities, such as ping, traceroute, and BFD, from the T-PE devices.

To enable autodiscovery of S-PEs in an MS-PW, include the auto-discovery-mspw statement at the [edit protocols bgp group group-name family l2vpn] hierarchy level.

The automatic selection of S-PE and dynamic setting up of an MS-PW rely heavily on BGP. BGP network layer reachability information (NLRI) constructed for the FEC 129 pseudowire to autodiscover the S-PE is called an MS-PW NLRI [draft-ietf-pwe3-dynamic-ms-pw-15.txt]. The MS-PW NLRI is essentially a prefix consisting of a route distinguisher (RD) and FEC 129 source attachment identifier (SAII). It is referred to as a BGP autodiscovery (BGP-AD) route and is encoded as RD:SAII.

Only T-PEs that are provisioned with type 2 AIIs initiate their own MS-PW NLRI respectively. Since a type 2 AII is globally unique, an MS-PW NLRI is used to identify a PE device to which the type 2 AII is provisioned. The difference between a type 1 AII and a type 2 AII requires that a new address family indicator (AFI) and subsequent address family identifier (SAFI) be defined in BGP to support an MS-PW. The proposed AFI and SAFI value pair used to identify the MS-PW NLRI is 25 and 6, respectively (pending IANA allocation).

The AFI and SAFI values support autodiscovery of S-PEs and should be configured on both T-PEs that originate the routes, and the S-PEs that participate in the signaling.

Figure 3 illustrates an inter-area MS-PW setup between two remote PE routers—T-PE1 and T-PE2. The Provider (P) routers are P1 and P2, and the S-PE routers are S-PE1 and S-PE2. The MS-PW is established between T-PE1 and T-PE2, and all the devices belong to the same AS—AS 100. Since S-PE1 and S-PE2 belong to the same AS, they act as route reflectors and are also known as RR 1 and RR 2, respectively.

Figure 4 illustrates an inter-AS MS-PW setup. The MS-PW is established between T-PE1 and T-PE2, where T-PE1, P1, and S-PE1 belong to AS 1, and S-PE2, P2, and T-PE2 belong to AS 2. Since S-PE1 and S-PE2 belong to different ASs, they are configured as ASBR routers and are also known as ASBR 1 and ASBR 2, respectively.

Figure 3: Interarea Multisegment PseudowireInterarea Multisegment Pseudowire
Figure 4: Inter-AS Multisegment PseudowireInter-AS Multisegment Pseudowire

The following sections provide information about how an MS-PW is established in an interarea and inter-AS scenario.

Minimum Configuration Requirements on S-PE

In order to dynamically discover both ends of an SS-PW and set up a T-LDP session dynamically, the following is required:

  • For interarea MS-PW, each S-PE plays both an ABR and BGP route reflector role.

    In the interarea case, as seen in Figure 3, the S-PE plays a BGP route reflector role and reflects the BGP-AD route to its client. A BGP-AD route advertised by one T-PE eventually reaches its remote T-PE. Because of the next-hop-self set by each S-PE, the S-PE or T-PE that receives a BGP-AD route can always discover the S-PE that advertises the BGP-AD in its local AS or local area through the BGP next hop.

  • For inter-AS MS-PW, each S-PE plays either an ASBR or a BGP route reflector role.

    In an MS-PW, the two T-PEs initiate a BGP-AD route respectively. When the S-PE receives the BGP-AD route through either the IBGP session with the T-PE or through a regular BGP-RR, it sets the next-hop-self before re-advertising the BGP-AD route to one or more of its EBGP peers in the inter-AS case, as seen in Figure 4.

  • Each S-PE must set next-hop-self when re-advertising or reflecting a BGP-AD route for the MS-PW.

Active and Passive Role of T-PE

To ensure that the same set of S-PEs are being used for a MS-PW in both directions, the two T-PEs play different roles in terms of FEC 129 signaling. This is to avoid different paths being chosen by T-PE1 and T-PE2 when each S-PE is dynamically selected for an MS-PW.

When an MS-PW is signaled using FEC 129, each T-PE might independently start signaling the MS-PW. The signaling procedure can result in an attempt to set up each direction of the MS-PW through different S-PEs.

To avoid this situation, one of the T-PEs must start the pseudowire signaling (active role), while the other waits to receive the LDP label mapping before sending the respective pseudowire LDP label mapping message (passive role). When the MS-PW path is dynamically placed, the active T-PE (the Source T-PE) and the passive T-PE (the Target T-PE) must be identified before signaling is initiated for a given MS-PW. The determination of which T-PE assumes the active role is done based on the SAII value, where the T-PE that has a larger SAII value plays the active role.

In this example, the SAII values of T-PE1 and T-PE 2 are 800:800:800 and 700:700:700, respectively. Since T-PE1 has a higher SAII value, it assumes the active role and T-PE2 assumes the passive role.

Directions for Establishing an MS-PW

The directions used by the S-PE for setting up the MS-PW are:

  • Forwarding direction—From an active T-PE to a passive T-PE.

    In this direction, the S-PEs perform a BGP-AD route lookup to determine the next-hop S-PE to send the label mapping message.

  • Reverse direction—From a passive T-PE to an active T-PE.

    In this direction, the S-PEs do not perform a BGP-AD route lookup, because the label mapping messages are received from the T-PEs, and the stitching routes are installed in the S-PEs.

In this example, the MS-PW is established in the forwarding direction from T-PE1 to T-PE2. When the MS-PW is placed from T-PE2 to T-PE1, the MS-PW is established in the reverse direction.

Autodiscovery and Dynamic Selection of S-PE

A new AFI and SAFI value is defined in BGP to support the MS-PWs based on type 2 AII. This new address family supports autodiscovery of S-PEs. This address family must be configured on both the TPEs and SPEs.

It is the responsibility of the Layer 2 VPN component to dynamically select the next S-PE to use along the MS-PW in the forwarding direction.

  • In the forwarding direction, the selection of the next S-PE is based on the BGP-AD route advertised by the BGP and pseudowire FEC information sent by the LDP. The BGP-AD route is initiated by the passive T-PE (T-PE2) in the reverse direction while the pseudowire FEC information is sent by LDP from the active T-PE (T-PE1) in the forwarding direction.

  • In the reverse direction, the next S-PE (S-PE2) or the active T-PE (T-PE1) is obtained by looking up the S-PE (S-PE1) that it used to set up the pseudowire in the forwarding direction.

Provisioning a T-PE

To support FEC 129 type 2 AII, the T-PE needs to configure its remote T-PE's IP address, a global ID, and an attachment circuit ID. Explicit paths where a set of S-PEs to use is explicitly specified on a T-PE is not supported. This eliminates the need to provision each S-PE with a type 2 AII.

Stitching an MS-PW

An S-PE performs the following MPLS label operations before forwarding the received label mapping message to the next S-PE:

  1. Pops the MPLS tunnel label.

  2. Pops the VC label.

  3. Pushes a new VC label.

  4. Pushes an MPLS tunnel label used for the next segment.

Establishing an MS-PW

After completing the necessary configuration, an MS-PW is established in the following manner:

  1. The SAII values are exchanged between T-PE1 and T-PE2 using BGP.

    T-PE1 assumes the active T-PE role, because it is configured with a higher SAII value. T-PE2 becomes the passive T-PE.

  2. T-PE1 receives the BGP-AD route originated by T-PE2. It compares the AII values obtained from T-PE2 in the received BGP-AD route against the AII values provisioned locally.

  3. If the AII values match, T-PE1 performs a BGP-AD route lookup to elect the first S-PE (S-PE1).

  4. T-PE1 sends an LDP label mapping message to S-PE1.

  5. Using the BGP-AD route originated from T-PE2, and the LDP label mapping message received from T-PE1, S-PE1 selects the next S-PE (S-PE2) in the forwarding direction.

    To do this, S-PE1 compares SAII obtained from the BGP-AD route against the TAI from the LDP label mapping message.

  6. If the AII values match, S-PE1 finds S-PE2 through the BGP next hop associated with the BGP-AD route.

  7. The process of selecting S-PE goes on until the last S-PE establishes a T-LDP session with T-PE2. When T-PE2 receives the LDP label mapping message from the last S-PE (S-PE2), it initiates its own label mapping message and sends it back to S-PE2.

  8. When all the label mapping messages are received on S-PE1 and S-PE2, the S-PEs install the stitching routes. Thus, when the MS-PW is established in the reverse direction, the S-PEs need not perform BGP-AD route lookup to determine its next hop as it did in the forwarding direction.

OAM Support for an MS-PW

After the MS-PW is established, the following OAM capabilities can be executed from the T-PE devices:

  • Ping

    • End-to-End Connectivity Verification Between T-PEs

      If T-PE1, S-PEs, and T-PE2 support Control Word (CW), the pseudowire control plane automatically negotiates the use of the CW. Virtual Circuit Connectivity Verification (VCCV) Control Channel (CC) Type 3 will function correctly whether or not the CW is enabled on the pseudowire. However, VCCV Type 1, which is used for end-to-end verification only, is only supported if the CW is enabled.

      The following is a sample:

      Ping from T-P1 to T-PE2

      or

    • Partial Connectivity Verification from T-PE to Any S-PE

      To trace part of an MS-PW, the TTL of the pseudowire label can be used to force the VCCV message to pop out at an intermediate node. When the TTL expires, the S-PE can determine that the packet is a VCCV packet either by checking the CW or by checking for a valid IP header with UDP destination port 3502 (if the CW is not in use). The packet should then be diverted to VCCV processing.

      If T-PE1 sends a VCCV message with the TTL of the pseudowire label equal to 1, the TTL expires at the S-PE. T-PE1 can thus verify the first segment of the pseudowire.

      The VCCV packet is built according to RFC 4379. All the information necessary to build the VCCV LSP ping packet is collected by inspecting the S-PE TLVs. This use of the TTL is subject to the caution expressed in RFC 5085. If a penultimate LSR between S-PEs or between an S-PE and a T-PE manipulates the pseudowire label TTL, the VCCV message might not emerge from the MS-PW at the correct S-PE.

      The following is a sample:

      Ping from T-PE1 to S-PE

      The bottom-label-ttl value is 1 for S-PE1 and 2 for S-PE2.

      The bottom-label-ttl statement sets the correct VC label TTL, so the packets are popped to the correct SS-PW for VCCV processing.

    Note:

    Junos OS supports VCCV Type 1 and Type 3 for the MS-PW OAM capability. VCCV Type 2 is not supported.

  • Traceroute

    Traceroute tests each S-PE along the path of the MS-PW in a single operation similar to LSP trace. This operation is able to determine the actual data path of the MS-PW, and is used for dynamically signaled MS-PWs.

  • Bidirectional Forwarding Detection

    Bidirectional Forwarding Detection (BFD) is a detection protocol designed to provide fast forwarding path failure detection times for all media types, encapsulations, topologies, and routing protocols. In addition to fast forwarding path failure detection, BFD provides a consistent failure detection method for network administrators. The router or switch can be configured to log a system log (syslog) message when BFD goes down.

Configuration

Configuring an Interarea MS-PW

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.

T-PE1

P1

S-PE1 (RR 1)

S-PE2 (RR 2)

P2

T-PE2

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.

To configure T-PE1 in the interarea scenario:

Note:

Repeat this procedure for the T-PE2 device in the MPLS domain, after modifying the appropriate interface names, addresses, and other parameters.

  1. Configure the T-PE1 interfaces.

  2. Set the autonomous system number.

  3. Enable MPLS on all the interfaces of T-PE1, excluding the management interface.

  4. Enable autodiscovery of intermediate S-PEs that make up the MS-PW using BGP.

  5. Configure the BGP group for T-PE1.

  6. Assign local and neighbor addresses to the mspw group for T-PE1 to peer with S-PE1.

  7. Configure OSPF on all the interfaces of T-PE1, excluding the management interface.

  8. Configure LDP on all the interfaces of T-PE1, excluding the management interface.

  9. Configure the Layer 2 VPN routing instance on T-PE1.

  10. Assign the interface name for the mspw routing instance.

  11. Configure the route distinguisher for the mspw routing instance.

  12. Configure the Layer 2 VPN ID community for FEC 129 MS-PW.

  13. Configure a VPN routing and forwarding (VRF) target for the mspw routing instance.

  14. Configure the source attachment identifier (SAI) value using Layer 2 VPN as the routing protocol for the mspw routing instance.

  15. Assign the interface name that connects the CE1 site to the VPN, and configure the target attachment identifier (TAI) value using Layer 2 VPN as the routing protocol for the mspw routing instance.

  16. (Optional) Configure T-PE1 to send MS-PW status TLVs.

  17. (Optional) Configure OAM capabilities for the VPN.

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.

To configure S-PE1 (RR 1) in the interarea scenario:

Note:

Repeat this procedure for the S-PE2 (RR 2) device in the MPLS domain, after modifying the appropriate interface names, addresses, and other parameters.

  1. Configure the S-PE1 interfaces.

  2. Set the autonomous system number.

  3. Enable MPLS on all the interfaces of T-PE1, excluding the management interface.

  4. Enable autodiscovery of S-PE using BGP.

  5. Configure the BGP group for S-PE1.

  6. Configure S-PE1 to act as a route reflector.

  7. Assign local and neighbor addresses to the mspw group for S-PE1 to peer with T-PE1 and S-PE2.

  8. Configure OSPF on all the interfaces of S-PE1, excluding the management interface.

  9. Configure LDP on all the interfaces of S-PE1, excluding the management interface.

  10. Define the policy for enabling next-hop-self and accepting BGP traffic on S-PE1.

Results

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

T-PE1

S-PE1 (RR 1)

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

Configuring an Inter-AS MS-PW

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.

T-PE1

P1

S-PE1 (ASBR 1)

S-PE2 (ASBR 2)

P2

T-PE2

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.

To configure the T-PE1 router in the inter-AS scenario:

Note:

Repeat this procedure for the T-PE2 device in the MPLS domain, after modifying the appropriate interface names, addresses, and other parameters.

  1. Configure the T-PE1 interfaces.

  2. Set the autonomous system number.

  3. Enable MPLS on all the interfaces of T-PE1, excluding the management interface.

  4. Enable autodiscovery of intermediate S-PEs that make up the MS-PW using BGP.

  5. Configure the BGP group for T-PE1.

  6. Assign local and neighbor addresses to the mspw group for T-PE1 to peer with S-PE1.

  7. Configure OSPF on all the interfaces of T-PE1, excluding the management interface.

  8. Configure LDP on all the interfaces of T-PE1, excluding the management interface.

  9. Configure the Layer 2 VPN routing instance on T-PE1.

  10. Assign the interface name for the mspw routing instance.

  11. Configure the route distinguisher for the mspw routing instance.

  12. Configure the Layer 2 VPN ID community for FEC 129 MS-PW.

  13. Configure a VPN routing and forwarding (VRF) target for the mspw routing instance.

  14. Configure the source attachment identifier (SAI) value using Layer 2 VPN as the routing protocol for the mspw routing instance.

  15. Assign the interface name that connects the CE1 site to the VPN, and configure the target attachment identifier (TAI) value using Layer 2 VPN as the routing protocol for the mspw routing instance.

  16. (Optional) Configure T-PE1 to send MS-PW status TLVs.

  17. (Optional) Configure OAM capabilities for the VPN.

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.

To configure S-PE1 (ASBR 1) in the inter-AS scenario:

Note:

Repeat this procedure for the S-PE2 (ASBR 2) device in the MPLS domain, after modifying the appropriate interface names, addresses, and other parameters.

  1. Configure S-PE1 (ASBR 1) interfaces.

  2. Set the autonomous system number.

  3. Enable MPLS on all the interfaces of S-PE1 (ASBR 1), excluding the management interface.

  4. Enable autodiscovery of S-PE using BGP.

  5. Configure the IBGP group for S-PE1 (ASBR 1) to peer with T-PE1.

  6. Configure the IBGP group parameters.

  7. Configure the EBGP group for S-PE1 (ASBR 1) to peer with S-PE2 (ASBR 2).

  8. Configure the EBGP group parameters.

  9. Configure OSPF on all the interfaces of S-PE1 (ASBR 1), excluding the management interface.

  10. Configure LDP on all the interfaces of S-PE1 (ASBR 1), excluding the management interface.

  11. Define the policy for enabling next-hop-self on S-PE1 (ASBR 1).

Results

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

T-PE1

S-PE1 (RR 1)

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

Verification

Confirm that the configuration is working properly.

Verifying the Routes

Purpose

Verify that the expected routes are learned.

Action

From operational mode, run the show route command for the bgp.l2vpn.1, ldp.l2vpn.1, mpls.0, and ms-pw.l2vpn.1 routing tables.

From operational mode, run the show route table bgp.l2vpn.1 command.

From operational mode, run the show route table ldp.l2vpn.1 command.

From operational mode, run the show route table mpls.0 command.

From operational mode, run the show route table ms-pw.l2vpn.1 command.

Meaning

The output shows all the learned routes, including the autodiscovery (AD) routes.

The AD2 prefix format is RD:SAII-type2, where:

  • RD is the route distinguisher value.

  • SAII-type2 is the type 2 source attachment identifier value.

The PW2 prefix format is Neighbor_Addr:C:PWtype:l2vpn-id:SAII-type2:TAII-type2, where:

  • Neighbor_Addr is the loopback address of neighboring S-PE device.

  • C indicates if Control Word (CW) is enabled or not.

    • C is CtrlWord if CW is set.

    • C is NoCtrlWord if CW is not set.

  • PWtype indicates the type of the pseudowire.

    • PWtype is 4 if it is in Ethernet tagged mode.

    • PWtype is 5 if it is Ethernet only.

  • l2vpn-id is the Layer 2 VPN ID for the MS-PW routing instance.

  • SAII-type2 is the type 2 source attachment identifier value.

  • TAII-type2 is the type 2 target attachment identifier value.

Verifying the LDP Database

Purpose

Verify the MS-PW labels received by T-PE1 from S-PE1 and sent from T-PE1 to S-PE1.

Action

From operational mode, run the show ldp database command.

Meaning

The labels with FEC129 prefix are related to the MS-PW.

Checking the MS-PW Connections on T-PE1

Purpose

Make sure that all of the FEC 129 MS-PW connections come up correctly.

Action

From operational mode, run the show l2vpn connections extensive command.

Check the following fields in the output to verify that MS-PW is established between the T-PE devices:

  • Target-attachment-id—Check if the TAI value is the SAI value of T-PE2.

  • Remote PE—Check if the T-PE2 loopback address is listed.

  • Negotiated PW status TLV—Ensure that the value is Yes.

  • Pseudowire Switching Points—Check if the switching points are listed from S-PE1 to S-PE2 and from S-PE2 to T-PE2.

Meaning

MS-PW is established between T-PE1 and T-PE2 in the forwarding direction.

Checking the MS-PW Connections on S-PE1

Purpose

Make sure that all of the FEC 129 MS-PW connections come up correctly for the mspw routing instance.

Action

From operational mode, run the show l2vpn connections instance __MSPW__ extensive command.

Check the following fields in the output to verify that MS-PW is established between the T-PE devices:

  • Target-attachment-id—Check if the TAI value is the SAI value of T-PE2.

  • Remote PE—Check if the T-PE1 and S-PE2 loopback addresses are listed.

  • Negotiated PW status TLV—Ensure that the value is Yes.

  • Pseudowire Switching Points—Check if the switching points are listed from S-PE2 to T-PE2.

Meaning

MS-PW is established between T-PE1 and T-PE2 in the forwarding direction.

Checking the MS-PW Connections on S-PE2

Purpose

Make sure that all of the FEC 129 MS-PW connections come up correctly for the mspw routing instance.

Action

From operational mode, run the show l2vpn connections instance __MSPW__ extensive command.

Check the following fields in the output to verify that MS-PW is established between the T-PE devices:

  • Target-attachment-id—Check if the TAI value is the SAI value of T-PE1.

  • Remote PE—Check if the S-PE1 and T-PE2 loopback addresses are listed.

  • Negotiated PW status TLV—Ensure that the value is Yes.

  • Pseudowire Switching Points—Check if the switching points are listed from S-PE1 to T-PE1.

Meaning

MS-PW is established between T-PE1 and T-PE2 in the reverse direction.

Checking the MS-PW Connections on T-PE2

Purpose

Make sure that all of the FEC 129 MS-PW connections come up correctly.

Action

From operational mode, run the show l2vpn connections extensive command.

Check the following fields in the output to verify that MS-PW is established between the T-PE devices:

  • Target-attachment-id—Check if the TAI value is the SAI value of T-PE1.

  • Remote PE—Check if the T-PE1 loopback address is listed.

  • Negotiated PW status TLV—Ensure that the value is Yes.

  • Pseudowire Switching Points—Check if the switching points are listed from S-PE2 to S-PE1 and from S-PE1 to T-PE1.

Meaning

MS-PW is established between T-PE1 and T-PE2 in the reverse direction.

Troubleshooting

To troubleshoot the MS-PW connection, see:

Ping

Problem

How to check the connectivity between the T-PE devices and between a T-PE device and an intermediary device.

Solution

Verify that T-PE1 can ping T-PE2. The ping mpls l2vpn fec129 command accepts SAIs and TAIs as integers or IP addresses and also allows you to use the CE-facing interface instead of the other parameters (instance, local-id, remote-id, remote-pe-address).

Checking Connectivity Between T-PE1 and T-PE2

Checking Connectivity Between T-PE1 and S-PE2

Bidirectional Forwarding Detection

Problem

How to use BFD to troubleshoot the MS-PW connection from the T-PE device.

Solution

From operational mode, verify the show bfd session extensive command output.

Traceroute

Problem

How to verify that MS-PW was established.

Solution

From operational mode, verify traceroute output.

MPLS Stitching For Virtual Machine Connection

By using MPLS, the stitching feature of Junos OS provides connectivity between virtual machines that reside either on opposite sides of data center routers or in different data centers. An external controller, programmed in the data-plane, assigns MPLS labels to both virtual machines and servers. Then, the signaled MPLS labels are used between the data center routers, generating static link switched paths (LSPs), resolved over either BGP labeled unicast, RSVP or LDP, to provide the routes dictated by the labels.

When Would I Use Stitching?

There are several ways to connect virtual machines. One option when you have virtual machines on opposite sides of a router (or different data centers) is to use MPLS stitching. A typical topology for using MPLS stitching is shown in Figure 5.

Figure 5: Virtual Machines on Either Side of RoutersVirtual Machines on Either Side of Routers

The above topology consists of the following MPLS layers: VMs | Servers | ToRs | Router ...... Router | ToRs | Servers | VMs

Note:

The label on the left is the top of the label stack.

How Does MPLS Stitching Work?

With stitching, the MPLS static allocation of labels demultiplexes incoming traffic onto any device/entity in the next layer in the direction of traffic flow. Essentially, there is a label hierarchy that picks up labels for the correct top-of-rack switch, server, and virtual machine that receives traffic. Static label assignments are done between the top-of-rack switches and the virtual machines.

For example, imagine that traffic is sent from VM1 to VM3 in Figure 5. When traffic exits Server1, its label stack is L1 | L2 | L3 where:

  • L1 represents the egress top-of-rack switch ToR1.

  • L2 represents the physical server, Server2, towards which the egress-side ToR will forward the traffic.

  • L3: represents the virtual machine on Server2 to which the Server2 should deliver the traffic.

Traffic arriving at ToR1 needs to be sent to ToR2. Since ToR1 and ToR2 are not directly connected, traffic must flow from ToR1 to ToR2 using label-switching starting on the outermost (top) label. Stitching has been added to static-LSP functionality to SWAP L1 to a l-BGP label that ToR2 advertises to ToR1. The label stack now must contain another label at the top to enable forwarding of the labeled packets between ToR1 and ToR2. An L-Top label is added if L-BGP is resolved over RSVP/LDP. If static LSP is resolved over L-BGP, then the top label is swapped with the L-BGP label and there is no L-Top label. When the traffic exits ToR1, the stack is: L-top | L-BGP | L2 | L3.

Traffic from ToR1 to ToR2 is then label switched over any signaled LSP.

When traffic arrives at ToR2, the top label is removed with PHP (popped) and the label stack becomes L-BGP | L2 | L3. Since L-BGP is a implicit null label, ToR2 pops the static LSP label L2 that corresponds to the egress server and then forwards the packet to the egress server using the static-LSP configuration on ToR2, which corresponds to a single-hop implicit-NULL LSP.

The outgoing stack becomes L3 and the next-hop is the egress server Server2.

When traffic arrives at the egress server Server2, Server2 pops L3 and delivers the packet to VM3.

How Do I Configure Stitching?

The new keyword stitch has been added under transit to resolve the remote next-hop. For example, instead of set protocols mpls static-label-switched-path static-to-ToR2 transit 1000000 next-hop 10.9.82.47, a top-of-rack switch redirects packets to another top-of-rack switch with set protocols mpls static-label-switched-path static-to-ToR2 transit 1000000 stitch. The show mpls static-lsp command has been extended to show the LSP state as 'InProgress' whenever the LSP is waiting for protocol next-hop resolution by resolver.

See the complete example for stitching at Using MPLS Stitching with BGP to Connect Virtual Machines for more information.

Which Switches Support Stitching?

See Feature Explorer for the list of switches that support the MPLS Stitching For Virtual Machine Connections feature.

Q&A

Q: Is link and node protection for the next-hop provided by MPLS stitching?

A: Link and node protection for the next-hop of transit LSP stitched to L-BGP LSP are not needed. That is provided by L-BGP LSP.

TDM Pseudowires Overview

A TDM pseudowire acts as Layer 2 circuit or service for T1 and E1 circuit signals across an MPLS packet-switched network. On ACX Series routers, you configure a TDM pseudowire with Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP) on the ACX Series built-in channelized T1 and E1 interfaces. When you configure a TDM pseudowire, the network between the customer edge (CE) routers appears transparent to the CE routers, making it seem that the CE routers are directly connected. With the SAToP configuration on the provider edge (PE) router’s T1 and E1 interfaces, the interworking function (IWF) forms a payload (frame) that contains the CE router’s T1 and E1 Layer 1 data and control word. This data is transported to the remote PE over the pseudowire. The remote PE removes all the Layer 2 and MPLS headers added in the network cloud and forwards the control word and the Layer 1 data to the remote IWF, which in turn forwards the data to the remote CE router.

Example: TDM Pseudowire Base Configuration

Requirements

The following is a list of the hardware and software requirements for this configuration.

  • One ACX Series router

  • Junos OS Release 12.2 or later

Overview of a TDM Pseudowire Base Configuration

The configuration shown here is the base configuration of an TDM pseudowire with T1 framing on an ACX Series router. This configuration is for one provider edge router. To complete the TDM pseudowire configuration, you need to repeat this configuration on an other provider edge router in the Multiprotocol Label Switched (MPLS) network.

Configuring an TDM Pseudowire

Procedure

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them in 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:

Note:

To configure a TDM pseudowire with E1 framing, include the e1 statement at the [edit chassis fpc 0 pic 0 framing] hierarchy level instead of the t1 statement shown in this example.

Step-by-Step Procedure
  1. Configure the framing format:

  2. Create a T1 interface on a channelized T1 interface (ct1) and enable full channelization with the no-partition statement. On the logical T1 interface, set the Structure-Agnostic TDM over Packet (SAToP) encapsulation mode.

  3. Create a Gigabit Ethernet interface and enable MPLS on that interface. Create the loopback (lo0) interface:

  4. Enable the MPLS and RSVP protocols on the MPLS interface—ge-0/2/0.0:

  5. Configure LDP. If you configure RSVP for a pseudowire, you must also configure LDP:

  6. Configure a point-to-point label-switched path (LSP) and disable constrained-path LSP computation:

  7. Configure OSPF and enable traffic engineering on the MPLS interface—ge-0/2/0.0, and on the loopback (lo0) interface:

  8. Uniquely identify a Layer 2 circuit for the TDM pseudowire:

Results

Configuring Load Balancing for Ethernet Pseudowires

You can configure load balancing for IPv4 traffic over Layer 2 Ethernet pseudowires. You can also configure load balancing for Ethernet pseudowires based on IP information. The option to include IP information in the hash key provides support for Ethernet circuit cross-connect (CCC) connections.

Note:

This feature is supported only on M120, M320, MX Series, and T Series routers.

To configure load balancing for IPv4 traffic over Layer 2 Ethernet pseudowires, include the ether-pseudowire statement at the [edit forwarding-options hash-key family mpls payload] hierarchy level:

Note:

You must also configure either the label-1 or the no-labels statement at the [edit forwarding-options hash-key family mpls] hierarchy level.

You can also configure load balancing for Ethernet pseudowires based on IP information. This functionality provides support for load balancing for Ethernet cross-circuit connect (CCC) connections. To include IP information in the hash key, include the ip statement at the [edit forwarding-options hash-key family mpls payload] hierarchy level:

Note:

You must also configure either the label-1 or no-labels statement at the [edit forwarding-options hash-key family mpls] hierarchy level.

You can configure load balancing for IPv4 traffic over Ethernet pseudowires to include only Layer 3 IP information in the hash key. To include only Layer 3 IP information, include the layer-3-only option at the [edit forwarding-options family mpls hash-key payload ip] hierarchy level:

Note:

You must also configure either the label-1 or no-labels statement at the [edit forwarding-options hash-key family mpls] hierarchy level.

Configuring Load Balancing Based on MAC Addresses

The hash key mechanism for load-balancing uses Layer 2 media access control (MAC) information such as frame source and destination address. To load-balance traffic based on Layer 2 MAC information, include the family multiservice statement at the [edit forwarding-options hash-key] hierarchy level:

To include the destination-address MAC information in the hash key, include the destination-mac option. To include the source-address MAC information in the hash key, include the source-mac option.

Note:

Any packets that have the same source and destination address will be sent over the same path.

Note:

You can configure per-packet load balancing to optimize VPLS traffic flows across multiple paths.

Note:

Aggregated Ethernet member links will now use the physical MAC address as the source MAC address in 802.3ah OAM packets.

Note:

ACX Series routers do not support VPLS.

Release History Table
Release
Description
14.1X53
Starting in Junos OS Release 14.1X53 and Junos OS Release 16.1, an Ethernet pseudowire is used to carry Ethernet or 802.3 Protocol Data Units (PDUs) over an MPLS network enabling service providers to offer emulated Ethernet services over existing MPLS networks.