Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Verifying the MPLS Configuration

 

After configuring MPLS on your network, you must verify the correct configuration of both the MPLS and RSVP protocols. Incorrect configuration of either protocol prevents successful LSP creation.

Figure 1 illustrates the network with the example configurations used in this topic.

Figure 1: MPLS Network Topology
MPLS Network Topology

To verify the MPLS configuration, follow these steps:

Verify the RSVP Protocol

Purpose

If the RSVP protocol is not enabled on the routers in your network, the interface cannot signal LSPs.

Action

To verify that the RSVP protocol is enabled, enter the following Junos OS CLI command:

Sample Output

Meaning

The sample output shows that the RSVP protocol is enabled on R1. The supported RSVP protocol is version 1, as defined in RFC 2205.

The RSVP refresh timer is set to 30 seconds, indicating that every 30 seconds, plus or minus 50 percent, the router will refresh the RSVP state with its directly connected neighbors by sending either a Path or a Resv message. The variable refresh time helps prevent harmonic oscillations in network traffic caused by periodic protocol updates.

The keepalive multiplier, K(keep multiplier), is input to a formula that helps determine the lifetime of an RSVP session. The session lifetime is reset each time the state is updated. The lifetime represents the duration of an RSVP session that does not receive any state updates (Path or Resv messages). The formula is:

RSVP session lifetime = (keep-multiplier + 0.5) * 1.5 * refresh-time

The RSVP preemption state is currently configured for normal preemption, indicating that only an LSP with a stronger priority can preempt an existing session; that is, the setup value of the new LSP is lower than the hold value of the existing LSP. Other options include aggressive preemption, which always preempts when there is insufficient bandwidth, and disabled, which prevents any preemption, regardless of LSP priority values.

Graceful restart is currently disabled and Restart helper mode is enabled. There are four combinations for Graceful restart and restart helper mode:

  1. Both Graceful restart and Restart helper mode are enabled.

  2. Graceful restart is enabled but Restart helper mode is disabled. An LSR with this configuration can restart gracefully but cannot help a neighbor with its restart and recovery procedures.

  3. Graceful restart is disabled but Restart helper mode is enabled. An LSR with this configuration can only help a restarting neighbor. It cannot restart gracefully itself.

  4. Graceful restart and Restart helper mode are both disabled. This configuration completely disables RSVP graceful restart (including restart and recovery procedures and helper mode). It is the same as an LSR that is not supported by RSVP graceful restart.

Restart time is the estimated time (in milliseconds) for an LSR to restart the RSVP traffic engineering component. In the example output, the restart time is 0 milliseconds, indicating that it is disabled.

The output is identical for all routers in the network shown in MPLS Network Topology.



Verify RSVP Interfaces

Purpose

If the RSVP protocol is not configured correctly on the routers in your network, the interfaces cannot signal LSPs.

Action

To verify RSVP interfaces, enter the following Junos OS CLI operational mode command:

Sample Output 1

Sample Output 2

Sample Output 3

Meaning

Sample Output 1 shows that all interfaces on all routers in the network are enabled with RSVP, including the management interface (fxp0). The output for all routers in the network includes similar information, so we will examine R6 in detail.

R6 has five interfaces enabled with RSVP (Up). Interface so-0/1/1.0 has a single active RSVP reservation (Active resv) that did not change the default subscription percentage of 100 percent (Subscription). Interface so-0/1/1.0 did not assign a static bandwidth (Static BW) to the logical unit and therefore inherited 100 percent of the physical interface rate as the bandwidth available (Available BW) for RSVP sessions. Interface so-0/1/1.0 has no bandwidth assigned (Reserved BW), and no RSVP bandwidth allocation at any single instant in time (Highwater mark).

Sample Output 2 shows that interface so-0/0/3.0 is missing. If you do not configure the correct interface at the [edit protocols rsvp] hierarchy level, the interface cannot signal LSPs, and does not appear in the output for the show rsvp interface command.

Sample Output 3 shows that the RSVP protocol is not configured at the [edit protocols rsvp] hierarchy level.



Verify Protocol Families

Purpose

If a logical interface does not have MPLS enabled, it cannot perform MPLS switching. This step allows you to quickly determine which interfaces are configured with MPLS and other protocol families.

Action

To verify the protocol families configured on the routers in your network, enter the following Junos OS CLI operational mode command:

Sample Output 1

Sample Output 2

Meaning

Sample Output 1 shows the interface, the administrative status of the link (Admin), the data link layer status of the link (Link), the protocol families configured on the interface (Proto), and the local and remote addresses on the interface.

All interfaces on all routes in the network shown in MPLS Network Topology are administratively enabled and functioning at the data link layer with MPLS and IS-IS, and have an inet address. All are configured with an IPv4 protocol family (inet), and have the IS-IS (iso) and MPLS (mpls) protocol families configured at the [edit interfaces type-fpc/pic/port unit number] hierarchy level.

Sample Output 2 shows that interface so-0/0/2.0 on R6 does not have the mpls statement included at the [edit interfaces type-fpc/pic/port unit number] hierarchy level.