Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

MPLS OAM Configuration

Configuring the MPLS Transport Profile for OAM

MPLS Transport Profile Overview

RFC 5654, Requirements of an MPLS Transport Profile, describes the requirements for the MPLS Transport Profile (MPLS-TP) that extends capabilities for Operation, Administration, and Maintenance (OAM) when MPLS is used for transport services and transport network operations. These capabilities help in troubleshooting and maintenance of a pseudowire or label-switched path (LSP).

MPLS-TP mechanisms for OAM contain two main components:

  • Generic Associated Channel Label (GAL)—A special label that enables an exception mechanism that informs the egress label-switching router (LSR) that a packet it receives on an LSP belongs to an associated control channel or the control plane.

  • Generic Associated Channel Header (G-Ach)—A special header field that identifies the type of payload contained in the MPLS label-switched paths (LSPs). G-Ach has the same format as a pseudowire associated control channel header.

For more information about MPLS-TP, see RFC 5654, Requirements of an MPLS Transport Profile. For specific information about GAL and G-Ach, see RFC 5586, MPLS Generic Associated Channel.

The following capabilities are supported in the Junos OS implementation of MPLS-TP:

  • MPLS-TP OAM can send and receive packets with GAL and G-Ach, without IP encapsulation.

  • Two unidirectional RSVP LSPs between a pair of routers can be associated with each other to create an associated bidrectional LSP for binding a path for the GAL and G-Ach OAM messages. A single Bidirectional Forwarding Detection (BFD) session is established for the associated bidirectional LSP.

Example: Configuring the MPLS Transport Profile for OAM

This example shows how to configure the MPLS Transport Profile (MPLS-TP) for sending and receiving of OAM GAL and G-Ach messages across a label-switched path (LSP).

Requirements

This example uses the following hardware and software components:

  • Six devices that can be a combination of M Series, MX Series, and T Series routers

  • Junos OS Release 12.1 or later running on the devices

Overview

Junos OS Release 12.1 and later support MPLS Transport Profile (MPLS-TP) Operation, Administration, and Maintenance (OAM) capabilities. MPLS-TP introduces new capabilities for OAM when MPLS is used for transport services and transport network operations. This includes configuring Generic Associated Channel Label (GAL) and Generic Associated Channel Header (G-Ach) for OAM messages.

This example shows how to configure MPLS-TP OAM capability to send and receive GAL and G-Ach OAM messages without IP encapsulation. In addition, it also shows how to associate two unidirectional RSVP label-switched paths (LSPs) between a pair of routers to create an associated bidirectional LSP for binding a path for the GAL and G-Ach OAM messages.

Junos OS Release 12.1 and later support the following MPLS-TP capabilities:

  • MPLS-TP OAM capability and the infrastructure required for MPLS applications to send and receive packets with GAL and G-Ach, without IP encapsulation.

  • LSP-ping and Bidirectional Forwarding Detection (BFD) applications to send and receive packets using GAL and G-Ach, without IP encapsulation on transport LSPs.

  • The association of two unidirectional RSVP LSPs, between a pair of routers, with each other to create an associated bidirectional LSP for binding a path for the GAL and G-Ach OAM messages. The associated bidirectional LSP model is supported only for associating the primary paths. A single BFD session is established for the associated bidirectional LSP.

Junos OS Release 12.1 and later does not support the following MPLS-TP capabilities:

  • Point-to-multipoint RSVP LSPs and BGP LSPs

  • Loss Measurement and Delay Measurement

You can enable GAL and G-Ach OAM operation using the following configuration statements:

  • mpls-tp-mode—Include this statement at the [edit protocols mpls oam] hierarchy level to enable GAL and G-Ach OAM operation, without IP encapsulation, on all LSPs in the MPLS network.

    Include this statement at the [edit protocols mpls label-switched-path lsp-name oam] hierarchy level to enable GAL and G-Ach OAM operation without IP encapsulation on a specific LSP in the network.

    Note:

    Starting with Junos OS Release 16.1, MPLS-TP supports two additional channel types for the default LSPING (0x0008) channel type under the mpls-tp-mode statement. These additional channel types provide on-demand connectivity verification (CV) with and without IP/UDP encapsulation.

    • On-demand CV (0x0025)—This channel type is a new pseudowire channel type and is used for on-demand CV without IP/UDP encapsulation, where IP addressing is not available or non-IP encapsulation is preferred.

    • IPv4 (0x0021)—This channel type uses the IP/UDP encapsulation and provides interoperability support with other vendor devices using IP addressing.

    The GACH-TLV is used along with the default LSPING channel type. As per RFC 7026, GACH-TLV is deprecated for 0x0021 and 0x0025 channel types.

    To configure a channel type for MPLS-TP, include the lsping-channel-type channel-type statement at the [edit protocols mpls label-switched-path lsp-name oam mpls-tp-mode] and [edit protocols mpls oam mpls-tp-mode] hierarchy levels.

  • associate-lsp lsp-name from from-ip-address—Include this statement at the [edit protocols mpls label-switched-path lsp-name] hierarchy level to configure associated bidirectional LSPs on the two ends of the LSP.

    The from from-ip-address configuration for the LSP is optional. If omitted, it is derived from the to address of the ingress LSP configuration.

  • transit-lsp-association—Include this statement at the [edit protocols mpls]hierarchy level to associate two LSPs at a transit router.

    The association of the LSPs in the transit nodes is useful for the return LSP path for TTL-expired LSP ping packets or traceroute.

In this example, R0 is the ingress router and R4 is the egress router. R1, R2, R3, and R5 are transit routers. The associated bidirectional LSP is established between the transit routers for sending and receiving the GAL and G-Ach OAM messages.

Figure 1 shows the topology used in this example.

Topology
Figure 1: MPLS-TP OAM Associated Bidirectional LSPsMPLS-TP OAM Associated Bidirectional LSPs

Configuration

CLI Quick Configuration
Note:

This example shows the configuration on all devices and shows step-by-step procedures for configuring the ingress router, R0, and transit router R1. Repeat the step-by-step procedure described for the ingress router, R0, on the egress router, R4. Repeat the step-by-step procedure for the transit router, R1, on the other transit routers, R2, R3, and R5. Be sure to modify the appropriate interface names, addresses, and other parameters appropriately.

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.

Router R0

Router R1

Router R2

Router R3

Router R4

Router R5

Configuring Device R0
Step-by-Step Procedure

To configure the ingress router, R0:

  1. Configure the interfaces.

  2. Configure MPLS on the interfaces.

  3. Configure an interior gateway protocol, such as OSPF.

  4. Configure a signaling protocol, such as RSVP.

  5. Configure the LSP.

  6. Enable GAL and G-Ach OAM operation without IP encapsulation on the LSPs.

  7. Configure associated bidirectional LSPs on the two ends of the LSP.

  8. After you are done configuring the device, commit the configuration.

Results

Confirm your configuration by issuing the show interfaces and show protocols commands.

Configuring Device R1
Step-by-Step Procedure

To configure the transit router, R1:

  1. Configure the interfaces.

  2. Configure MPLS on the interfaces.

  3. Configure an interior gateway protocol, such as OSPF.

  4. Configure a signaling protocol, such as RSVP.

  5. Configure the association of the two LSPs on the transit router.

  6. If you are done configuring the device, commit the configuration.

Results

Confirm your configuration by issuing the show interfaces and show protocols commands.

Verification

Confirm that the configuration is working properly.

Verifying Associated Bidirectional LSPs
Purpose

Verify that the associated bidirectional LSP configuration is working properly.

Action
Meaning

The output of the show mpls lsp, show mpls detail, and show mpls bidirectional commands displays the details of the associated bidirectional LSPs and the LSP association information.

Configuring OAM Ingress Policies for LDP

Using the ingress-policy statement, you can configure an Operation, Administration, and Management (OAM) policy to choose which forwarding equivalence classes (FECs) need to have OAM enabled. If the FEC passes through the policy or if the FEC is explicitly configured, OAM is enabled for a FEC. For FECs chosen using a policy, the BFD parameters configured under [edit protocols ldp oam bfd-liveness-detection] are applied.

You configure the OAM ingress policy at the [edit policy-options] hierarchy level. To configure an OAM ingress policy, include the ingress-policy statement:

You can configure this statement at the following hierarchy levels:

  • [edit protocols ldp oam]

  • [edit logical-systems logical-system-name protocols ldp oam]

Note:

ACX Series routers do not support [edit logical-systems] hierarchy level.

Tracing MPLS and LSP Packets and Operations

To trace MPLS and LSP packets and operations, include the traceoptions statement:

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

You can specify the following MPLS-specific flags in the MPLS traceoptions statement:

  • all—Trace all operations.

  • connection—Trace all circuit cross-connect (CCC) activity.

  • connection-detail—Trace detailed CCC activity.

  • cspf—Trace CSPF computations.

  • cspf-link—Trace links visited during CSPF computations.

  • cspf-node—Trace nodes visited during CSPF computations.

  • error—Trace MPLS error conditions.

  • graceful-restart—Trace MPLS graceful restart events.

  • lsping—Trace LSP ping packets and return codes.

  • nsr-synchronization—Trace nonstop routing (NSR) synchronization events.

  • nsr-synchronization-detail—Trace NSR synchronization events in detail.

  • state—Trace all LSP state transitions.

  • static—Trace static label-switched path.

When you configure trace options to track an MPLS LSP using the cspf option, the CSPF log displays information about the MPLS LSP using the term “generalized MPLS” (GMPLS). For example, a message in the CSPF log might state that the “link passes GMPLS constraints”. Generalized MPLS (GMPLS) is a superset of MPLS, so this message is normal and does not affect proper MPLS LSP operation.

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
16.1
Starting with Junos OS Release 16.1, MPLS-TP supports two additional channel types for the default LSPING (0x0008) channel type under the mpls-tp-mode statement.