The command output shows two routes from the longer output of the show ipv6 route command

If the MPLS protocol is not configured correctly on the routers in your network, the interfaces are not able to perform MPLS switching.

Note:

For a labeled route to be resolved over an interface, family mpls must be configured at the [edit interfaces] hierarchy level for the route to be successfully resolved. When the interface is not configured with family mpls, labelled routes do not get resolved.

Sample Output 1 shows that all MPLS interfaces on all routers in the network are enabled (Up) and can perform MPLS switching. If you fail to configure the correct interface at the [edit protocols mpls] hierarchy level or include the family mpls statement at the [edit interfaces type-fpc/pic/port unit number ] hierarchy level, the interface cannot perform MPLS switching, and does not appear in the output for the show mpls interface command.

Administrative groups are not configured on any of the interfaces shown in the example network in MPLS Network Topology. However, if they were, the output would indicate which affinity class bits are enabled on the router.

Sample Output 2 shows that interface so-0/0/2.0 is missing and therefore might be incorrectly configured. For example, the interface might not be included at the [edit protocols mpls] hierarchy level, or the family mpls statement might not be included at the [edit interfaces type-fpc/pic/port unit number] hierarchy level. If the interface is configured correctly, RSVP might not have signaled over this interface yet. For more information on determining which interface is incorrectly configured, see Verify Protocol Families.

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

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.

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.

After you have checked the transit and ingress routers, use the traceroute command to verify the BGP next hop, and used the ping command to verify the active path, you can check for problems with the MPLS configuration at the [edit protocols mpls] and [edit interfaces] hierarchy levels.

Note:

For a labeled route to be resolved over an interface, family mpls must be configured at the [edit interfaces] hierarchy level for the route to be successfully resolved. When the interface is not configured with family mpls, labelled routes do not get resolved.

Sample Output 1 from the ingress, transit, and egress routers shows that the configuration of interfaces on egress router R6 is incorrect. Interface so-0/0/3.0 is included as inactive at the [edit protocols mpls] hierarchy level, when it should be active because it is the interface through which the LSP travels.

Sample Output 2 shows that interfaces are correctly configured for MPLS on egress router R6. The interfaces are also correctly configured on the ingress and transit routers (not shown).

Purpose

After you have configured the label-switched path (LSP), issued the show mpls lsp command, and determined that there is an error, you might find that the error is not in the physical, data link, Internet Protocol (IP), interior gateway protocol (IGP), or Resource Reservation Protocol (RSVP) layers. Continue investigating the problem at the MPLS layer of the network.

Figure 1 illustrates the MPLS layer of the layered MPLS model.

Figure 1: Checking the MPLS Layer

With the MPLS layer, you check whether the LSP is up and functioning correctly. If the network is not functioning at this layer, the LSP does not work as configured.

Figure 2 illustrates the MPLS network used in this topic.

Figure 2: MPLS Network Broken at the MPLS Layer

The network shown in Figure 2 is a fully meshed configuration where every directly connected interface can receive and send packets to every other similar interface. The LSP in this network is configured to run from ingress router R1, through transit router R3, to egress router R6. In addition, a reverse LSP is configured to run from R6 through R3 to R1, creating bidirectional traffic.

However, in this example, the reverse LSP is down without a path from R6 to R1.

The cross shown in Figure 2 indicates where the LSP is broken. Some possible reasons the LSP is broken might include an incorrectly configured MPLS protocol, or interfaces that are incorrectly configured for MPLS.

In the network shown in Figure 2, a configuration error on egress router R6 prevents the LSP from traversing the network as expected.

To check the MPLS layer, follow these steps:

Typically, you use the show mpls lsp extensive command to verify the LSP. However for quick verification of the LSP state, use the show mpls lsp command. If the LSP is down, use the extensive option (show mpls lsp extensive) as a follow-up. If your network has numerous LSPs, you might consider specifying the name of the LSP, using the name option (show mpls lsp name name or show mpls lsp name name extensive).

Sample Output 1 shows a brief description of the state of the LSP for the ingress, transit, and egress routers. Output from ingress router R1 and egress router R6 shows that both LSPs are down, R1-to-R6 and R6-toR1. With the configured LSPs on R1 and R6, we would expect egress LSP sessions on both R1 and R6. In addition, transit router R3 has no transit sessions.

Sample Output 2 shows all information about the LSPs, including all past state history and the reason why an LSP failed. Output from R1 and R6 indicates that there is no route to the destination because the Constrained Shortest Path First (CSPF) algorithm failed.

Sample Outputs 3 and 4 show examples of the output for the show mpls lsp name command with the extensive option. In this instance, the output is very similar to the show mpls lsp command because only one LSP is configured in the example network in MPLS Network Broken at the MPLS Layer. However, in a large network with many LSPs configured, the results would be quite different between the two commands.

If the LSP is up, the LSP route should appear in the mpls.0 routing table. MPLS maintains an MPLS path routing table (mpls.0), which contains a list of the next label-switched router in each LSP. This routing table is used on transit routers to route packets to the next router along an LSP. If routes are not present in the output for the transit router, check the MPLS protocol configuration on the ingress and egress routers.

Sample Output 1 from transit router R3 shows three route entries in the form of MPLS label entries. These MPLS labels are reserved MPLS labels defined in RFC 3032, and are always present in the mpls.0 routing table, regardless of the state of the LSP. The incoming labels assigned by RSVP to the upstream neighbor are missing from the output, indicating that the LSP is down. For more information on MPLS label entries, see Checklist for Verifying LSP Use.

In contrast, Sample Output 2 shows the MPLS labels and routes for a correctly configured LSP. The three reserved MPLS labels are present, and the four other entries represent the incoming labels assigned by RSVP to the upstream neighbor. These four entries represent two routes. There are two entries per route because the stack values in the MPLS header may be different. For each route, the second entry 100864 (S=0) and 100880 (S=0) indicates that the stack depth is not 1, and additional label values are included in the packet. In contrast, the first entry, 100864 and 100880 has an inferred S=1 value which indicates a stack depth of 1 and makes each label the last label in that particular packet. The dual entries indicate that this is the penultimate router. For more information on MPLS label stacking, see RFC 3032, MPLS Label Stack Encoding.

Check whether the LSP route is included in the active entries in the inet.3 routing table for the specified address.

Sample Output 1 shows entries in the inet.0 routing table only. The inet.3 routing table is missing from the output because the LSP is not working. The inet.0 routing table is used by interior gateway protocols (IGPs) and Border Gateway Protocol (BGP) to store routing information. In this case, the IGP is Intermediate System-to-Intermediate System (IS-IS). For more information on the inet.0 routing table, see the Junos MPLS Applications Configuration Guide.

If the LSP was working, we would expect to see entries that include the LSP in the inet.3 routing table. The inet.3 routing table is used on ingress routers to route BGP packets to the destination egress router. BGP uses the inet.3 routing table on the ingress router to help resolve next-hop addresses. BGP is configured in the example network shown in MPLS Network Broken at the MPLS Layer.

Sample Output 2 shows output you should receive when the LSP is up. The output shows both the inet.0 and inet.3 routing tables, indicating that LSPs R1-to-R6 and R6-to-R1 are available.

Display the route packets take to a BGP destination where the BGP next hop for that route is the LSP egress address. By default, BGP uses the inet.0 and the inet.3 routing tables to resolve the next-hop address. When the next-hop address of the BGP route is not the router ID of the egress router, traffic is mapped to IGP routes, not to the LSP. Use the traceroute command as a debugging tool to determine whether the LSP is being used to forward traffic.

Sample Output 1 shows that BGP traffic is not using the LSP, consequently MPLS labels do not appear in the output. Instead of using the LSP, BGP traffic is using the IGP (IS-IS, in the example network in MPLS Network Broken at the MPLS Layer) to reach the BGP next-hop LSP egress address. The Junos OS default behavior uses LSPs for BGP traffic when the BGP next hop equals the LSP egress address.

Sample Output 2 is an example of output for a correctly configured LSP. The output shows MPLS labels, indicating that BGP traffic is using the LSP to reach the BGP next hop.

When you ping a specific LSP, you check that echo requests are sent over the LSP as MPLS packets.

Sample Output 1 shows that the LSP does not have an active path to forward echo requests, indicating that the LSP is down.

Sample Output 2 is an example of output you should receive when the LSP is up and forwarding packets.

After taking the appropriate action to correct the error, the LSP needs to be checked again to confirm that the problem in the BGP layer has been resolved.

To verify the LSP again, enter the following command from the ingress, transit, and egress routers:

Sample Output 1 from ingress router R1 shows that LSP R1-to-R6 has an active route to R6 and the state is up.

Sample Output 2 from transit router R3 shows that there are two transit LSP sessions, one from R1 to R6 and the other from R6 to R1. Both LSPs are up.

Sample Output 3 from egress router R6 shows that the LSP is up and the active route is the primary route. The LSP is now traversing the network along the expected path, from R1 through R3 to R6, and the reverse LSP, from R6 through R3 to R1.

You can verify that one-to-one backup is established by examining the ingress router and the other routers in the network.

To verify one-to-one backup, enter the following Junos OS CLI operational mode commands:

Primary paths must always be used in the network if they are available, therefore an LSP always moves back to the primary path after a failure, unless the configuration is adjusted. For more information on adjusting the configuration to prevent a failed primary path from reestablishing, see Preventing Use of a Path That Previously Failed.

Sample output 1 shows that the LSP is operational and is using the primary path (via-r2) with R2 (10.0.12.14) and R4 (10.0.24.2) as transit routers. The priority values are the same for setup and hold, 6 6. Priority 0 is the highest (best) priority and 7 is the lowest (worst) priority. The Junos OS default for setup and hold priority is 7:0. Unless some LSPs are more important than others, preserving the default is a good practice. Configuring a setup priority that is better than the hold priority is not allowed, resulting in a failed commit in order to avoid preemption loops.

Purpose

After you have configured the LSP, issued the show mpls lsp extensive command, and determined that there is an error, you can start investigating the problem at the physical layer of the network.

Figure 3 illustrates the physical layer of the layered MPLS model.

Figure 3: Verifying the Physical Layer

With this layer, you must ensure that the routers are connected, and that the interfaces are up and configured correctly on the ingress, egress, and transit routers.

If the network is not functioning at this layer, the label-switched path (LSP) does not work as configured.

Figure 4 illustrates the MPLS network and the problem described in this topic.

Figure 4: MPLS Network Broken at the Physical Layer

The network shown in Figure 4 is a fully meshed configuration where every directly connected interface can receive and send packets to every other similar interface. The LSP in this network is configured to run from ingress router R1, through transit router R3, to egress router R6. In addition, a reverse LSP is configured to run from R6 through R3 to R1, creating bidirectional traffic.

However, in this example, traffic does not use the configured LSP. Instead traffic uses the alternate route from R1 through R2 to R6, and in the reverse direction, from R6 through R5 to R1.

When you become aware of a situation where an alternate route is used rather than the configured LSP, verify that the physical layer is functioning correctly. You might find that routers are not connected, or that interfaces are not up and configured correctly on the ingress, egress, or transit routers.

The cross shown in Figure 4 indicates where the LSP is broken because of a configuration error on ingress router R1.

To check the physical layer, follow these steps:

Typically, you use the show mpls lsp extensive command to verify the LSP. However, for quick verification of the LSP state, use the show mpls lsp command. If the LSP is down, use the extensive option (show mpls lsp extensive) as a follow-up. If your network has numerous LSPs, you might consider specifying the name of the LSP, using the name option (show mpls lsp name name or show mpls lsp name name extensive).

To determine whether the LSP is up, enter the following command from the ingress router:

The sample output from ingress router R1 shows that the LSP is using an alternate path rather than the configured path. The configured path for the LSP is R1 through R3 to R6, and for the reverse LSP, R6 through R3 to R1. The alternate path used by the LSP is R1 through R2 to R6, and for the reverse LSP, R6 through R5 to R1.

Confirm that the appropriate ingress, transit, and egress routers are functioning by examining whether the packets have been received and transmitted with 0% packet loss.

To determine that the routers are connected, enter the following command from the ingress and transit routers:

The sample output shows that ingress router R1 is receiving packets from transit router R3, and that the transit router is receiving packets from the egress router. Therefore, the routers in the LSP are connected.

Confirm that the interfaces are configured correctly with the family mpls statement.

To determine that the relevant interfaces are up and configured correctly, enter the following commands from the ingress, transit, and egress routers:

The sample output shows that interface so-0/0/2.0 on the ingress router does not have the family mpls statement configured at the [edit interfaces type-fpc/pic/port] hierarchy level, indicating that the interface is incorrectly configured to support the LSP. The LSP is configured correctly at the [edit protocols mpls] hierarchy level.

The output from the transit and egress routers (not shown) shows that the interfaces on those routers are configured correctly.

After taking the appropriate action to correct the error, the LSP needs to be checked again to confirm that the problem in the physical layer has been resolved.

Sample Output 1 from ingress router R1 shows that the LSP is now traversing the network along the expected path, from R1 through R3 to R6, and the reverse LSP, from R6 through R3 to R1.

Sample Output 2 from ingress router R1 shows that the LSP is forced to take the intended path because MPLS is deactivated on R1 interfaces so-0/0/0.0 and so-0/0/1.0. If these interfaces were not deactivated, even though the configuration is now correct, the LSP would still traverse the network through the alternate path.

At the IP and IGP layers, you must check the following:

• Interfaces have correct IP addressing, and the IGP neighbors or adjacencies are established.

• Open Shortest Path First (OSPF) or Intermediate System-to-Intermediate System (IS-IS) protocols are configured and running correctly.

  • If the OSPF protocol is configured, check the IP layer first, then the OSPF configuration, making sure that the protocol, interfaces, and traffic engineering are configured correctly.

  • If the IS-IS protocol is configured, it doesn’t matter whether you check IS-IS or IP first because both protocols are independent of each other. Verify that IS-IS adjacencies are up, and that the interfaces and IS-IS protocol are configured correctly.

    Note:

    The IS-IS protocol has traffic engineering enabled by default.

If the network is not functioning at the IP or IGP layers, the LSP does not work as configured.

Figure 8 illustrates the MPLS network used in this topic.

Figure 8: MPLS Network Broken at the IP and IGP Layers

The network shown in Figure 8 is a fully meshed configuration where every directly connected interface can receive and send packets to every other similar interface. The LSP in this network is configured to run from ingress router R1, through transit router R3, to egress router R6. In addition, a reverse LSP is configured to run from R6, through R3, to R1, creating bidirectional traffic. The crosses in Figure 8 indicate where the LSP is not working because of the following problems at the IP and IGP layer:

• An IP address is configured incorrectly on the ingress router (R1).

• The OSPF protocol is configured with a router ID (RID) but without the loopback (lo0) interface, and traffic engineering is missing from the transit router (R3).

• Levels in the IS-IS network are mismatched.

Purpose

You can check the IP layer before or after you check the interior gateway protocol (IGP) layer, depending on whether you have OSPF or IS-IS configured as the IGP. If your MPLS network is configured with OSPF as the IGP, you must first verify the IP layer, checking that the interfaces have correct IP addressing and that the OSPF neighbors are established before you check the OSPF layer.

If you have IS-IS configured as the IGP in your MPLS network, you can verify either the IP layer or the IS-IS protocol layer first. The order in which you check the IP or IS-IS layer does not affect the results.

Figure 9: MPLS Network Broken at the IP Layer

The cross in Figure 9 indicates where the LSP is broken because of the incorrect configuration of an IP address on ingress router R1.

After configuring the LSP, you must verify that the LSP is up. LSPs can be ingress, transit, or egress. Use the show mpls lsp command for quick verification of the LSP state, with the extensive option (show mpls lsp extensive) as a follow-up if the LSP is down. If your network has numerous LSPs, you might consider specifying the name of the LSP, using the name option (show mpls lsp name name or show mpls lsp name name extensive).

To verify that the LSP is up, enter the following command from the ingress router:

The sample output from ingress router R1 shows that an MPLS label allocation failure occurred and the Constrained Shortest Path First (CSPF) algorithm failed, resulting in no route to destination 10.0.0.6 on R6.

When you investigate the IP layer, you verify that interfaces have correct IP addressing, and that OSPF neighbors or IS-IS adjacencies are established. In this example, an IP address is configured incorrectly on the ingress router (R1).

To verify IP addressing, enter the following command from the ingress, transit, and egress routers:

The sample output shows that the IP addresses for interface so-0/0/2.0 on R1 and interface so-0/0/2.0 on R3 are identical. Interface IP addresses within a network must be unique for the interface to be identified correctly.

If the IP addressing is configured incorrectly then the OSPF neighbors or IS-IS adjacencies both need to be checked to determine if one or both of them are established.

Sample Output 1 from the ingress, transit, and egress routers shows that R1 and R3 are not established OSPF neighbors. Considering that the two interfaces so-0/0/2.0 (R1 and R3) are configured with identical IP addresses, you would expect this. The OSPF protocol routes IP packets based solely on the destination IP address contained in the IP packet header. Therefore, identical IP addresses in the autonomous system (AS) result in neighbors not establishing.

Sample Output 2 from the ingress, transit, and egress routers shows that R1 and R3 have established an IS-IS adjacency despite the identical IP addresses configured on interfaces so-0/0/2.0 on R1 and R3. The IS-IS protocol behaves differently from the OSPF protocol because it does not rely on IP to establish an adjacency. However, if the LSP is not up, it is still useful to check the IP subnet addressing in case there is a mistake in that layer. Correcting the addressing error might bring the LSP back up.

After taking the appropriate action to correct the error, the LSP needs to be checked again to confirm that the problem in the OSPF protocol has been resolved.

Sample Output 1 from ingress router R1 shows that LSP R1-to-R6 has an active route to R6 and the state is up. The output shows that the egress LSP session R6-to-R1 received and sent a recovery label.

Sample Output 2 from transit router R3 shows that there are two transit LSP sessions, one from R1 to R6 and the other from R6 to R1. Both LSPs are up.

Sample Output 3 from egress router R6 shows that the LSP is up and the active route is the primary route. The LSP is now traversing the network along the expected path, from R1 through R3 to R6, and the reverse LSP, from R6 through R3 to R1.

After taking the appropriate action to correct the error, the LSP needs to be checked again to confirm that the problem in the IS-IS protocol has been resolved.

To verify that the LSP is up and traversing the network as expected, enter the following command from the ingress, egress, and transit routers:

The sample output from ingress router R1 and egress router R6 shows that the LSP is now traversing the network along the expected path, from R1 through R3 to R6, and the reverse LSP, from R6 through R3 to R1. In addition, the sample output from transit router R3 shows that there are two transit LSP sessions, one from R1 to R6, and the other from R6 to R1.

Purpose

After you have configured the label-switched path (LSP), issued the show mpls lsp extensive command, and determined that there is an error, you might find that the error is not in the physical, data link, or Internet Protocol (IP) and interior gateway protocol (IGP) layers. Continue investigating the problem at the RSVP layer of the network.

Figure 10 illustrates the RSVP layer of the layered MPLS model.

Figure 10: Checking the RSVP Layer

With this layer, you check that dynamic RSVP signaling is occurring as expected, neighbors are connected, and interfaces are configured correctly for RSVP. Check the ingress, egress, and transit routers.

If the network is not functioning at this layer, the LSP does not work as configured.

Figure 11 illustrates the MPLS network used in this topic.

Figure 11: MPLS Network Broken at the RSVP Layer

The network shown in Figure 11 is a fully meshed configuration where every directly connected interface can receive and send packets to every other similar interface. The LSP in this network is configured to run from ingress router R1, through transit router R3, to egress router R6. In addition, a reverse LSP is configured to run from R6 through R3 to R1, creating bidirectional traffic.

However, in this example, the LSP is down without a path in either direction, from R1 to R6 or from R6 to R1.

The crosses shown in Figure 11 indicate where the LSP is broken. Some possible reasons the LSP is broken might include that dynamic RSVP signaling is not occurring as expected, neighbors are not connected, or interfaces are incorrectly configured for RSVP.

In the network in Figure 11, a configuration error on transit router R3 prevents the LSP from traversing the network as expected.

To check the RSVP layer, follow these steps:

Typically, you use the show mpls lsp extensive command to verify the LSP. However for quick verification of the LSP state, use the show mpls lsp command. If the LSP is down, use the extensive option (show mpls lsp extensive) as a follow-up. If your network has numerous LSPs, you might consider specifying the name of the LSP, using the name option (show mpls lsp name name or show mpls lsp name name extensive).

To determine whether the LSP is up, enter the following command from the ingress router:

The sample output shows that the LSP is down in both directions, from R1 to R6, and from R6 to R1. The output from R1 shows that R1 is using a no-cspf LSP since it tried to originate the call without being able to reach the destination. The output from R6 shows that the Constrained Shortest Path First (CSPF) algorithm failed, resulting in no route to destination 10.0.0.1.

When an RSVP session is successfully created, the LSP is set up along the paths created by the RSVP session. If the RSVP session is unsuccessful, the LSP does not work as configured.

Sample Output 1 from all routers shows that no RSVP sessions were successfully created, even though the LSP R6-to-R1 is configured.

In contrast to Sample Output 1and to illustrate correct output, Sample Output 2 shows the output from the ingress, transit, and egress routers when the RSVP configuration is correct, and the LSP is traversing the network as configured. R1 and R6 both show an ingress and egress RSVP session, with the LSP R1-to-R6, and the reverse LSP R6-to-R1. Transit router R3 shows two transit RSVP sessions.

Display a list of RSVP neighbors that were learned dynamically when exchanging RSVP packets. Once a neighbor is learned, it is never removed from the list of RSVP neighbors unless the RSVP configuration is removed from the router.

Sample Output 1 shows that R1 and R6 have one RSVP neighbor each, R3. However, the values in the Up/Dn field are different. R1 has a value of 1/0 and R6 has a value of 1/1, indicating that R1 is an active neighbor with R3, but R6 is not. When the up count is one more than the down count, the neighbor is active; if the values are equal, the neighbor is down. The values for R6 are equal, 1/1, indicating that the neighbor R3 is down.

Transit router R3 knows about two neighbors, R1 and R6. The Up/Dn field indicates that R1 is an active neighbor and R6 is down. At this point it is not possible to determine if the problem resides with R3 or R6, because both neighbors are not active.

In contrast to Sample Output 1 and to illustrate correct output, Sample Output 2 shows the correct neighbor relationship between transit router R3 and egress router R6. The Up/Dn field shows the up count to be one more than the down count, 1/0, indicating that the neighbors are active.

Display the status of each interface on which RSVP is enabled to determine where the configuration error occurred.

Sample Output 1 shows that even though each router has interfaces that are up and have RSVP active, there are no reservations (Active resv) on any of the routers. In this example, we would expect at least one reservation on the ingress and egress routers, and two reservations on the transit router.

In addition, interface so-0/0/3 on transit router R3 is not included in the configuration. The inclusion of this interface is critical to the success of the LSP.

In contrast to Sample Output 1 and to illustrate correct output, Sample Output 2 shows the relevant interfaces with active reservations.

After you have checked RSVP sessions, interfaces, neighbors, and determined that there might be a configuration error, verify the RSVP protocol configuration.

To verify the RSVP configuration, enter the following command from the ingress, transit, and egress routers:

The sample output shows that R3 has interface so-0/0/3.0 missing from the RSVP protocol configuration. This interface is critical for the correct functioning of the LSP.

After taking the appropriate action to correct the error, the LSP needs to be checked again to confirm that the problem in the MPLS layer has been resolved.

Sample Output 1 from ingress router R1 shows that LSP R1-to-R6 has an active route to R6 and the state is up.

Sample Output 2 from transit router R3 shows that there are two transit LSP sessions, one from R1 to R6 and the other from R6 to R1. Both LSPs are up.

Sample Output 3 from egress router R6 shows that the LSP is up and the active route is the primary route. The LSP is now traversing the network along the expected path, from R1 through R3 to R6, and the reverse LSP, from R6 through R3 to R1.

Display detailed information about RSVP objects to assist the diagnosis of an LSP problem.

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

The sample output shows that there is one ingress and one egress RSVP session. The ingress session has a source address of 10.0.0.1 (R1), and the session is up, with one active route. The LSP name is R1-to-R6 and it is the primary path for the LSP.

The recovery label (100064) is sent by a graceful restart router to its neighbor to recover a forwarding state. It is probably the old label that the router advertised before it went down.

This session is using the fixed filter (FF) reservation style (Resv style). Since this is an ingress router, there is no inbound label. The outbound label (provided by the next downstream router) is 100064.

The Time Left field provides the number of seconds remaining in the RSVP session, and the Tspec object provides information about the controlled load rate (rate) and maximum burst size (peak), an infinite value (Infbps) for the guaranteed delivery option, and the indication that packets smaller than 20 bytes are treated as 20 bytes, while packets larger than 1500 bytes are treated as 1500 bytes.

The port number is the IPv4 tunnel ID, while the sender/receiver port number is the LSP ID. The IPv4 tunnel ID is unique for the life of the LSP, while the sender/receiver LSP ID can change, for example, with an SE style reservation.

The PATH rcvfrom field includes the source of the path message. Since this is the ingress router, the local client originated the path message.

The PATH sentto field includes the path message destination (10.1.13.2) and outgoing interface (so-0/0/2.0). The RESV rcvfrom field includes both the source of the Resv message received (10.1.13.2) and the incoming interface (so-0/0/2.0).

The RSVP explicit route and the route record values are identical: 10.1.13.2 and 10.1.36.2. In most cases, the explicit route and the record route values are identical. Differences indicate that some path rerouting has occurred, typically during Fast-Reroute.

The Total fields indicate the total number of ingress, egress, and transit RSVP sessions, with the total being equal to the sum of the up and down sessions. In this example, there is one ingress session, one egress session, and no transit RSVP sessions.

Purpose

When you verify the valid use of an LSP on the ingress and transit routers in your network, you can determine if there is a problem with Multiprotocol Label Switching (MPLS) in your network. Figure 12 describes the example network used in this topic.

Figure 12: MPLS Topology for Verifying LSP Use

The MPLS network in Figure 12 illustrates a router-only network with SONET interfaces that consist of the following components:

• A full-mesh interior Border Gateway Protocol (IBGP) topology, using AS 65432

• MPLS and Resource Reservation Protocol (RSVP) enabled on all routers

• A send-statics policy on routers R1 and R6 that allows a new route to be advertised into the network

• An LSP between routers R1 and R6

The network shown in Figure 12 is a Border Gateway Protocol (BGP) full-mesh network. Since route reflectors and confederations are not used to propagate BGP learned routes, each router must have a BGP session with every other router running BGP.

To verify LSP use in your network, follow these steps:

• Verifying an LSP on the Ingress Router
• Verifying an LSP on a Transit Router

You can verify the availability of an LSP when it is up by examining the inet.3 routing table on the ingress router. The inet.3 routing table contains the host address of each LSP's egress router. This routing table is used on ingress routers to route BGP packets to the destination egress router. BGP uses the inet.3 routing table on the ingress router to help resolve next-hop addresses.

To verify an LSP on an ingress router, enter the following Junos OS command-line interface (CLI) operational mode command:

The sample output shows the inet.3 routing table. By default, only BGP and MPLS virtual private networks (VPNs) can use the inet.3 route table to resolve next-hop information. One destination is listed in the route table, 10.0.0.6. This destination (10.0.0.6) is signaled by RSVP, and is the current active path, as indicated by the asterisk (*). The protocol preference for this route is 7, and the metric associated with it is 20. The label-switched path is R1-to-R6, through interface so-0/0/2.0, which is the physical next-hop transit interface.

Typically, the penultimate router in the LSP either pops the packet’s label or changes the label to a value of 0. If the penultimate router pops the top label and an IPv4 packet is underneath, the egress router routes the IPv4 packet, consulting the IP routing table inet.0 to determine how to forward the packet. If another type of label (such as one created by Label Distribution Protocol (LDP) tunneling or VPNs, but not IPv4) is underneath the top label, the egress router does not examine the inet.0 routing table. Instead, it examines the mpls.0 routing table for forwarding decisions.

If the penultimate router changes the packet’s label to a value of 0, the egress router strips off the 0 label, indicating that an IPv4 packet follows. The packet is examined by the inet.0 routing table for forwarding decisions.

When a transit or egress router receives an MPLS packet, information in the MPLS forwarding table is used to determine the next transit router in the LSP or whether this router is the egress router.

When BGP resolves a next-hop prefix, it examines both the inet.0 and inet.3 routing tables, seeking the next hop with the lowest preference; for example, RSVP preference 7 is preferred over OSPF preference 10. The RSVP signaled LSP is used to reach the BGP next hop. This is the default when the BGP next hop equals the LSP egress address. Once the BGP next hop is resolved through an LSP, the BGP traffic uses the LSP to forward BGP transit traffic.

You can verify the availability of an LSP when it is up by examining the mpls.0 routing table on a transit router. MPLS maintains the mpls.0 routing table, which contains a list of the next label-switched router in each LSP. This routing table is used on transit routers to route packets to the next router along an LSP.

To verify an LSP on a transit router, enter the following Junos OS CLI operational mode command:

The sample output from transit router R3 shows route entries in the form of MPLS label entries, indicating that there is only one active route, even though there are five active entries.

The first three MPLS labels are reserved MPLS labels defined in RFC 3032. Packets received with these label values are sent to the Routing Engine for processing. Label 0 is the IPv4 explicit null label. Label 1 is the MPLS equivalent of the IP Router Alert label and Label 2 is the IPv6 explicit null label.

The two entries with the 100064 label are for the same LSP, R1-to-R6. There are two entries because the stack values in the MPLS header may be different. The second entry, 100064 (S=0), indicates that the stack depth is not 1 and additional label values are included in the packet. In contrast, the first entry of 100064 has an inferred S=1 which indicates a stack depth of 1 and makes it the last label in the packet. The dual entry indicates that this is the penultimate router. For more information on MPLS label stacking, see RFC 3032, MPLS Label Stack Encoding.

The incoming label is the MPLS header of the MPLS packet, and is assigned by RSVP to the upstream neighbor. Juniper Networks routers dynamically assign labels for RSVP traffic-engineered LSPs in the range from 100,000 through 1,048,575.

The router assigns labels starting at label 100,000, in increments of 16. The sequence of label assignments is 100,000, 100,016, 100,032, 100,048, and so on. At the end of the assigned labels, the label numbers start over at 100001, incrementing in units of 16. Juniper Networks reserves labels for various purposes. Table 1 lists the various label range allocations for incoming labels.

After configuring load balancing, check that traffic is load-balanced equally across paths. In this section, the command output reflects the load-balancing configuration of the example network shown in Load-Balancing Network Topology. The clear commands are used to reset LSP and interface counters to zero so that the values reflect the operation of the load-balancing configuration.

To verify load balancing across interfaces and LSPs, use the following command on the ingress router:

To verify load balancing across interfaces and LSPs, use the following commands on a transit router:

When a router is performing unequal-cost load balancing between LSPs paths, the show route detail command displays a balance field associated with each next hop being used.

To verify that an RSVP LSP is unevenly load-balanced, use the following Junos OS CLI operational mode commands:

The sample output from ingress router R1 shows that traffic is distributed according to the LSP bandwidth configuration, as indicated by the Balance: xx% field. For example, lsp1 has 10 Mbps of bandwidth configured, as reflected in the Balance: 10% field.

You can use the traceroute command to verify that packets are being sent over the LSP.

Sample Output 1 shows that MPLS labels are used to forward packets through the network. Included in the output is a label value (MPLS Label=100048), the time-to-live value (TTL=1), and the stack bit value (S=1).

The MPLS Label field is used to identify the packet to a particular LSP. It is a 20-bit field, with a maximum value of (2^^20-1), or approximately 1,000,000.

The TTL value contains a limit on the number of hops that this MPLS packet can travel through the network (1). It is decremented at each hop, and if the TTL value drops below one, the packet is discarded.

The bottom of the stack bit value (S=1) indicates that is the last label in the stack and that this MPLS packet has one label associated with it. The MPLS implementation in the Junos OS supports a stacking depth of 3 on the M-series routers and up to 5 on the T-series platforms. For more information on MPLS label stacking, see RFC 3032, MPLS Label Stack Encoding.

MPLS labels appear in Sample Output 1 because the traceroute command is issued to a BGP destination where the BGP next hop for that route is the LSP egress address. The Junos OS default behavior uses LSPs for BGP traffic when the BGP next hop equals the LSP egress address.

Sample Output 2 shows that MPLS labels do not appear in the output for the traceroute command. If the BGP next hop does not equal the LSP egress address or the destination is an IGP route, the BGP traffic does not use the LSP. Instead of using the LSP, the BGP traffic is using the IGP (IS-IS, in this case) to reach the egress address (R6).

The logical control channel for GMPLS must be a point-to-point link and must have some form of IP reachability. On broadcast interfaces or when there are multiple hops between control channel peers, use a GRE tunnel for the control channel. For more detailed information on GMPLS and GRE tunnels see the Junos MPLS Applications Configuration Guide and the Junos User Guide.

A tunnel PIC is not required to configure a GRE tunnel for the GMPLS control channel. Instead, use the software-based gre interface, rather than the hardware-based gr-fpc/pic/port interface.

Due to restrictions to the software-based gre interface, the GMPLS control channel is the only supported use of the software-based gre interface. Any other use is expressly unsupported and might cause an application failure.

The following example shows a basic gre interface configuration. In this case, the tunnel source is the loopback address of the local router and the destination address is the loopback destination of the remote router. Traffic that has a next hop of the tunnel destination will use the tunnel. The tunnel is not automatically used by all the traffic passing through the interface. Only traffic with the tunnel destination as the next hop uses the tunnel.

Display detailed information about Resource Reservation Protocol (RSVP) objects and the label-switched path (LSP) history to pinpoint a problem with the LSP.

Figure 14 illustrates the network topology used in this topic.

Figure 14: MPLS Network Topology

To determine the LSP state, follow these steps:

• Check the Status of the LSP
• Display Extensive Status About the LSP

Display the status of the label-switched pathe (LSP).

To determine the LSP status, on the ingress router, enter the following Junos OS command-line interface (CLI) operational mode command:

The sample output is from the ingress router (R1), and shows ingress, egress, and transit LSP information. Ingress information is for the sessions that originate from this router, egress information is for sessions that terminate on this router, and transit information is for sessions that transit through this router.

There is one ingress route from R1 (10.0.0.1) to R6 (10.0.0.6). This route is currently up, and is an active route installed in the routing table (Rt). The LSP R1-to-R6 is the primary path (P) as opposed to the secondary path, and is indicated by an asterisk (*). The route to R6 does not contain a named path (ActivePath).

There is one egress LSP from R6 to R1. The State is up, with no routes installed in the routing table. RSVP reservation style (Style) consists of two parts. The first is the number of active reservations (1). The second is the reservation style, which is FF (fixed filter). The reservation style can be FF, SE (shared explicit), or WF (wildcard filter). There are three incoming labels (Labelin) and no labels going out (Labelout) for this LSP.

There are no transit LSPs.

For more information on checking the LSP state, see Checklist for Working with the Layered MPLS Troubleshooting Model.

Display extensive information about LSPs, including all past state history and the reasons why an LSP might have failed.

To display extensive information about LSPs, on the ingress router, enter the following Junos OS CLI operational mode command:

The sample output is from the ingress router (R1), and shows ingress, egress, and transit LSP information in detail, including all past state history and the reasons why an LSP failed. Ingress information is for sessions that originate from this router, egress information is for sessions that terminate on this router, and transit information is for sessions that transit through this router.

There is one ingress route from R1 (10.0.0.1) to R6 (10.0.0.6). This route is currently up (State), with one route actively using the LSP, R1-to-R6. The LSP active path is the primary path. Even if the LSP does not contain a primary or secondary keyword, the router still treats the LSP as a primary LSP, indicating that if the LSP fails, the router will attempt to signal inactive LSPs at 30-second intervals, by default.

Load balancing is Random, which is the default, indicating that when selecting the physical path for an LSP, the router randomly selects among equal-cost paths that have an equal hop count. Other options that you can configure are Least-fill and Most-fill. Least-fill places the LSP over the least utilized link of the equal-cost paths with equal hop count. Most-fill places the LSP over the most utilized link of the equal-cost paths sharing an equal hop count. Utilization is based on the percentage of available bandwidth.

The Encoding type field shows Generalized MPLS (GMPLS) signaling parameters (Packet), indicating IPv4. The Switching type is Packet, and the Generalized Payload Identifier (GPID) is IPv4.

The primary path is the active path, as indicated by an asterisk (*). The state of the LSP is Up.

The Explicit Route Object (ERO) includes the Constrained Shortest Path First (CSPF) cost (20) for the physical path that the LSP follows. The presence of the CSPF metric indicates that this is a CSPF LSP. The absence of the CSPF metric indicates a no-CSPF LSP.

The field 10.1.13.2 S indicates the actual ERO. The RSVP signaling messages went to 10.1.13.2 strictly (as a next hop) and finished at 10.1.36.2 strictly. All ERO addresses are strict hops when the LSP is a CSPF LSP. Loose hops can only display in a no-CSPF LSP.

The received Record Route Object (RRO) has the following protection flags:

• 0x01—Local protection available. The link downstream of this node is protected by a local repair mechanism. This flag can only be set if the Local protection flag was set in the SESSION_ATTRIBUTE object of the corresponding path message.

• 0x02—Local protection in use. A local repair mechanism is in use to maintain this tunnel (usually because of an outage of the link it was routed over previously).

• 0x04— Bandwidth protection. The downstream router has a backup path providing the same bandwidth guarantee as the protected LSP for the protected section.

• 0x08—Node protection. The downstream router has a backup path providing protection against link and node failure on the corresponding path section. If the downstream router can set up only a link-protection backup path, the “Local protection available” bit is set but the “Node protection” bit is cleared.

• 0x10—Preemption pending. The preempting node sets this flag if a pending preemption is in progress for the traffic engineered LSP. This indicates to the ingress label edge router (LER) of this LSP that it should be rerouted.

For more information on protection flags, see the Junos Routing Protocols and Policies Command Reference.

The field 10.1.13.2.10.1.36.2 is the actual received record route (RRO). Note that the addresses in the RRO field match those in the ERO field. This is the normal case for CSPF LSPs. If the RRO and ERO addresses do not match for a CSPF LSP, the LSP has to reroute or detour.

The lines numbered 91 through 42 contain the 49 most recent entries to the history log. Each line is time stamped. The most recent entries have the largest log history number and are at the top of the log, indicating that line 91 is the most recent history log entry. When you read the log, start with the oldest entry (42) to the most recent (91).

The history log was started on July 10, and displays the following sequence of activities: an LSP was selected as active, was found to be down, MPLS label allocation failed several times, was deleted several times, was preempted because of an ResvTear, was deselected as active, and was cleared. In the end, the router computed a CSPF ERO, signaled the call, the LSP came up with the listed RRO (line 90), and was listed as active.

For more information on error messages, see the Junos MPLS Network Operations Guide Log Reference.

The total number of ingress LSPs displayed is 1, with 1 up and 0 down. The number in the Up field plus the number in the Down field should equal the total.

There is one egress LSP session from R6 to R1. The State is up, with no routes installed in the routing table. RSVP reservation style (Style) consists of two parts. The first is the number of active reservations (1). The second is the reservation style, which is FF (fixed filter). The reservation style can be FF, SE (shared explicit), or WF (wildcard filter). There are three incoming labels (Labelin) and no labels going out (Labelout) for this LSP.

There are no transit LSPs.

For more information on checking the LSP state, see Checklist for Working with the Layered MPLS Troubleshooting Model.

The presence or absence of various RSVP messages can help determine if there is a problem with Multiprotocol Label Switching (MPLS) in your network. For example, if path messages occur in the output without Resv messages, it might indicate that label-switched paths (LSPs) are not being created.

To check that RSVP Path messages are sent and received, enter the following Junos OS command-line interface (CLI) operational mode command:

The sample output shows RSVP messages sent and received. The total number of RSVP Path messages is 11,4532 sent and 80,185 received. Within the last 5 seconds, no messages have been sent or received.

A total of 5 PathErr messages were sent and 10 received. When path errors occur (usually because of parameter problems in a path message), the router sends a unicast PathErr message to the sender that issued the path message. In this case, R1 sent at least 10 path messages with an error, as indicated by the 10 PathErr messages that R1 has received. The downstream router sent R1 five path messages with an error, as indicated by the five PathErr messages that R1 has sent. PathErr messages transmit in the opposite direction to path messages.

A total of 12 PathTear messages were sent and 6 received, none in the last 5 seconds. In contrast to PathErr messages, PathTear messages travel in the same direction as path messages. Since path messages are both sent and received, PathTear messages are also sent and received. However, if only path messages are sent, then only the PathTear messages that are sent appear in the output.

A total of 80,515 reservation (Resv) messages with the fixed filter (FF) reservation style were sent and 111,476 received, none in the last 5 seconds. An FF reservation style indicates that within each session, each receiver establishes its own reservation with each upstream sender, and that all selected senders are listed. No messages for the wildcard filter (WF) or shared explicit (SE) reservation styles are sent or received. For more information on RSVP reservation styles, see the Junos MPLS Applications Configuration Guide.

Other RSVP message types are not sent or received. For information on the ResvErr, ResvTear, and Resvconf message types, see the Junos MPLS Applications Configuration Guide.

Ack and summary refresh (SRefresh) messages do not appear in the output. Ack and summary refresh messages are defined in RFC 2961 and are part of the RSVP extensions. Ack messages are used to reduce the amount of RSVP control traffic in the network.

A total of 915,851 hello messages were sent and 915,881 received, with none transmitted or received in the last 5 seconds. The RSVP hello interval is 9 seconds. If more than one hello message is sent or received in the last 5 seconds, it implies that more than one interface supports RSVP.

EndtoEnd RSVP messages are legacy RSVP messages that are not used for RSVP traffic engineering. These counters increment only when RSVP forwards legacy RSVP messages issued by a virtual private network (VPN) customer for transit across the backbone to the other site(s) in the VPN. They are called end-to-end messages because they are intended for the opposite side of the network and only have meaning at the two ends of the provider network.

The Errors section of the output shows statistics about RSVP packets with errors. A total of 15 PathErr to client packets were sent to the Routing Engine. The total combines the sent and received PathErr packets.