Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Troubleshooting MPLS

Verify MPLS Interfaces

Purpose

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.

Action

To verify MPLS interfaces, enter the following Junos OS command-line interface (CLI) operational mode command:

Sample Output 1

command-name

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

Sample Output 2

command-name

Sample Output 3

command-name

Meaning

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.

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

command-name

Sample Output 2

command-name

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.

Verify the MPLS Configuration

Purpose

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.

Action

To verify the MPLS configuration, enter the following commands from the ingress, transit, and egress routers:

Sample Output 1

command-name

Sample Output 2

command-name

Meaning

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).

Checking the MPLS Layer

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 LayerChecking 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 LayerMPLS 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:

Verify the LSP

Purpose

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).

Action

To verify that the LSP is up, enter some or all of the following commands from the ingress router:

Sample Output 1
command-name
Sample Output 2
command-name
Sample Output 3
command-name
Sample Output 4
command-name

Meaning

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.

Verify the LSP Route on the Transit Router

Purpose

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.

Action

To verify the LSP route on the transit router, enter the following command from the transit router:

Sample Output 1
command-name
Sample Output 2
command-name

Meaning

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.

Verify the LSP Route on the Ingress Router

Purpose

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

Action

To verify the LSP route, enter the following command from the ingress router:

Sample Output 1
command-name
Sample Output 2
command-name

Meaning

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.

Verify MPLS Labels with the traceroute Command

Purpose

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.

Action

To verify MPLS labels, enter the following command from the ingress router:

Sample Output 1
command-name
Sample Output 2
command-name

Meaning

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.

Verify MPLS Labels with the ping Command

Purpose

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

Action

To verify MPLS labels, enter the following command from the ingress router to ping the egress router:

For example:

Sample Output 1
command-name
Sample Output 2
command-name

Meaning

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.

Take Appropriate Action

Problem

Description

Depending on the error you encountered in your investigation, you must take the appropriate action to correct the problem. In this example, an interface is incorrectly configured at the [edit protocols mpls] hierarchy level on egress router R6.

Solution

To correct the error in this example, follow these steps:

  1. Activate the interface in the MPLS protocol configuration on egress router R6:

  2. Verify and commit the configuration:

Sample Output
Meaning

The sample output shows that the incorrectly configured interface so-0/0/3.0 on egress router R6 is now activated at the [edit protocols mpls] hierarchy level. The LSP can now come up.

Verify the LSP Again

Purpose

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.

Action

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

Sample Output
command-name

Meaning

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.

Verify One-to-One Backup

Purpose

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

Action

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

Sample Output

command-name

The following sample output is from the ingress router R1 :

Meaning

The sample output from R1 shows that the FastReroute desired object was included in the Path messages for the LSP, allowing R1 to select the active path for the LSP and establish a detour path to avoid R2.

In line 8, Fast-reroute Detour Up shows that the detour is operational. Lines 6 and 7 indicate that transit routers R2 and R4 have established their detour paths.

R2, 10.0.12.14, includes (flag=9), indicating that node protection is available for the downstream node and link. R4, 10.0.24.2, includes (flag=1), indicating that link protection is available for the next downstream link. In this case, R4 can protect only the downstream link because the node is the egress router R5, which cannot be protected. For more information about flags, see the Junos User Guide.

The output for the show mpls lsp extensive command does not show the actual path of the detour. To see the actual links used by the detour paths, you must use the show rsvp session ingress detail command.

Sample Output

The following sample output is from the ingress router R1 in the network shown in One-to-One Backup Detours.

Meaning

The sample output from R1 shows the RSVP session of the main LSP. The detour path is established, Detour is Up. The physical path of the detour is displayed in Detour Explct route. The detour path uses R7 and R9 as transit routers to reach R5, the egress router.

Sample Output

The following sample output is from the first transit router R2 in the network shown in One-to-One Backup Detours:

Meaning

The sample output from R2 shows the detour is established (Detour is Up) and avoids R4, and the link connecting R4 and R5 (10.0.45.2). The detour path is through R7 (10.0.27.2) and R9 (10.0.79.2) to R5 (10.0.59.1), which is different from the explicit route for the detour from R1. R1 has the detour passing through the 10.0.17.14 link on R7, while R1 is using the 10.0.27.2 link. Both detours merge at R9 through the 10.0.79.2 link to R5 (10.0.59.1).

Sample Output

The following sample output is from the second transit router R4 in the network shown in One-to-One Backup Detours:

Meaning

The sample output from R4 shows the detour is established (Detour is Up) and avoids the link connecting R4 and R5 (10.0.45.2). The detour path is through R9 (10.0.49.2) to R5 (10.0.59.1). Some of the information is similar to that found in the output for R1 and R2. However, the explicit route for the detour is different, going through the link connecting R4 and R9 (so-0/0/3 or 10.0.49.2.

Sample Output

The following sample output is from R7, which is used in the detour path in the network shown in One-to-One Backup Detours:

Meaning

The sample output from R7 shows the same information as for a regular transit router used in the primary path of the LSP: the ingress address (192.168.1.1), the egress address (192.168.5.1 ), and the name of the LSP (r1-to-r5). Two detour paths are displayed; the first to avoid R4 (192.168.4.1) and the second to avoid R2 (192.168.2.1). Because R7 is used as a transit router by R2 and R4, R7 can merge the detour paths together as indicated by the identical Label out value (100368) for both detour paths. Whether R7 receives traffic from R4 with a label value of 100736 or from R2 with a label value of 100752, R7 forwards the packet to R5 with a label value of 100368.

Sample Output

The following sample output is from R9, which is a router used in the detour path in the network shown in One-to-One Backup Detours:

Meaning

The sample output from R9 shows that R9 is the penultimate router for the detour path, the explicit route includes only the egress link address (10.0.59.1), and the Label out value (3) indicates that R9 has performed penultimate-hop label popping. Also, the detour branch from 10.0.27.1 does not include path information because R7 has merged the detour paths from R2 and R4. Notice that the Label out value in the detour branch from 10.0.17.13 is 100368, the same value as the Label out value on R7.

Sample Output

The following sample output is from the egress router R5 in the network shown in One-to-One Backup Detours:

Meaning

The sample output from R5 shows the main LSP in the Record route field and the detours through the network.

Verify That the Primary Path Is Operational

Purpose

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.

Action

To verify that the primary path is operational, enter the following Junos OS command-line interface (CLI) operational mode commands:

Sample Output 1

command-name

Sample Output 2

command-name

Meaning

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.

Verify That the Secondary Path Is Established

Purpose

When the secondary path is configured with the standby statement, the secondary path should be up but not active; it will become active if the primary path fails. A secondary path configured without the standby statement will not come up unless the primary path fails. To test that the secondary path is correctly configured and would come up if the primary path were to fail, you must deactivate a link or node critical to the primary path, then issue the show mpls lsp lsp-path-name extensive command.

Action

To verify that the secondary path is established, enter the following Junos OS CLI operational mode command:

Sample Output

Sample Output

command-name

The following sample output shows a correctly configured secondary path before and after it comes up. In the example, interface fe-0/1/0 on R2 is deactivated, which brings down the primary path via-r2. The ingress router R1 switches traffic to the secondary path via-r7.

Meaning

The sample output from egress router R1 shows a correctly configured standby secondary path in a down state because the primary path is still up. Upon deactivation of an interface (interface fe-0/1/0 on R2) critical to the primary path, the primary path via-r2 goes down and the standby secondary path via-r7 comes up, allowing R1 to switch traffic to the standby secondary path.

Verifying the Physical Layer

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 LayerVerifying 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 LayerMPLS 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:

Verify the LSP

Purpose

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).

Action

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

Sample Output
command-name

Meaning

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.

Verify Router Connection

Purpose

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.

Action

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

Sample Output
command-name

Meaning

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.

Verify Interfaces

Purpose

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

Action

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

Sample Output
command-name

Meaning

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.

Take Appropriate Action

Problem

Description

Depending on the error you encountered in your investigation, you must take the appropriate action to correct the problem. In the example below, the family mpls statement, which was missing, is included in the configuration of ingress router R1.

Solution

To correct the error in this example, enter the following commands:

Sample Output
Meaning

The sample output from ingress router R1 shows that the family mpls statement is configured correctly for interface so-0/0/2.0, and that the LSP is now functioning as originally configured.

Verify the LSP Again

Purpose

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.

Action

To verify that the LSP is up and traversing the network as expected, enter the following command:

Sample Output 1
command-name
Sample Output 2
command-name

Meaning

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.

Verifying the IP and IGP Layers

Problem

Description

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 or data link layers. Continue investigating the problem at the IP and IGP layers of the network.

Figure 7 illustrates the IP and IGP layers of the layered MPLS model.

Figure 7: IP and IGP LayersIP and IGP Layers

Solution

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 LayersMPLS 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.

Verifying the IP Layer

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 LayerMPLS 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.

Verify the LSP

Purpose

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).

Action

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

Sample Output 1
command-name

Meaning

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.

Verify IP Addressing

Purpose

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).

Action

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

Sample Output
command-name

Meaning

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.

Verify Neighbors or Adjacencies at the IP Layer

Purpose

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.

Action

To verify neighbors (OSPF) or adjacencies (IS-IS), enter the following commands from the ingress, transit, and egress routers:

Sample Output 1
command-name
Sample Output 2
command-name

Meaning

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.

Take Appropriate Action

Problem

Description

Depending on the error you encountered in your investigation, you must take the appropriate action to correct the problem. In this example, the IP address of an interface on transit router R2 is incorrectly configured.

Solution

To correct the error in this example, enter the following commands:

Sample Output
Meaning

The sample output shows that interface so-0/0/2 on ingress router R1 is now configured with the correct IP address. This correction results in unique subnet IP addresses for all interfaces in the MPLS network in MPLS Network Broken at the IP and IGP Layers, and the possibility that the LSP might come up.

Verify the LSP Again

Purpose

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.

Action

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

Sample Output 1
command-name
Sample Output 2
command-name
Sample Output 3
command-name

Meaning

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.

Verify the LSP Again

Purpose

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.

Action

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

Sample Output

command-name

Meaning

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.

Checking the RSVP Layer

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 LayerChecking 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 LayerMPLS 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:

Verify the LSP

Purpose

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).

Action

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

Sample Output 1
command-name

Meaning

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.

Verify RSVP Sessions

Purpose

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.

Action

To verify currently active RSVP sessions, enter the following command from the ingress, transit, and egress routers:

Sample Output 1
command-name
Sample Output 2
command-name

Meaning

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.

Verify RSVP Neighbors

Purpose

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.

Action

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

Sample Output 1
command-name
Sample Output 2
command-name

Meaning

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.

Verify RSVP Interfaces

Purpose

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

Action

To verify the status of RSVP interfaces, enter the following command from the ingress, transit, and egress routers:

Sample Output 1
command-name
Sample Output 2
command-name

Meaning

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.

Verify the RSVP Protocol Configuration

Purpose

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

Action

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

Sample Output
command-name

Meaning

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.

Take Appropriate Action

Problem

Description

Depending on the error you encountered in your investigation, you must take the appropriate action to correct the problem. In this example, an interface is missing from the configuration of router R3.

Solution

To correct the error in this example, follow these steps:

  1. Include the missing interface in the configuration of transit router R3:

  2. Verify and commit the configuration:

Sample Output
Meaning

The sample output shows that the missing interface so-0/0/3.0 on transit router R3 is now correctly included at the [edit protocols rsvp] hierarchy level. This results in the possibility that the LSP might come up.

Verify the LSP Again

Purpose

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.

Action

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

Sample Output 1
command-name
Sample Output 2
command-name
Sample Output 3
command-name

Meaning

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.

Determining LSP Statistics

Purpose

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

Action

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

Sample Output

command-name

Meaning

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.

Verifying LSP Use in Your Network

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 UseMPLS 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

Purpose

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.

Action

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

Sample Output
command-name

Meaning

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.

Verifying an LSP on a Transit Router

Purpose

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.

Action

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

Sample Output
command-name

Meaning

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.

Table 1: MPLS Label Range Allocations

Incoming Label

Status

0 through 15

Reserved by IETF

16 through 1023

Reserved for static LSP assignment

1024 through 9999

Reserved for internal use (for example, CCC labels)

10,000 through 99,999

Reserved for static LSP assignment

100,000 through 1,048,575

Reserved for dynamic label assignment

Verify That Load Balancing Is Working

Purpose

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.

Action

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:

Sample Output

command-name

The following sample output is for the configuration on ingress router R1:

Meaning

The sample output for the show configuration command on ingress router R1 shows that load balancing is correctly configured with the lbpp policy statement. Also, the lbpp policy is exported into the forwarding table at the [edit routing-options] hierarchy level.

Sample Output

The following sample output is from transit router R2:

Meaning

The sample output for the show route command issued on transit router R2 shows the two equal-cost paths (so-0/0/1 and so-0/0/2) through the network to the loopback address to R0 (192.168.0.1). Even though the right angle bracket (>) usually indicates the active route, in this instance it does not, as shown in the following four sample outputs.

Sample Output

The following sample output is from transit router R2:

Meaning

The sample output for the monitor interface traffic command issued on transit router R2 shows that output traffic is evenly distributed across the two interfaces so-0/0/1 and so-0/0/2.

Sample Output

The following sample output is from transit router R2:

Meaning

The sample output for the show mpls lsp statistics command issued on transit router R2 shows that output traffic is evenly distributed across the four LSPs configured on ingress router R6.

Sample Output

The following sample output is from transit router R2:

Meaning

The sample output for the show route forwarding-table destination command issued on transit router R2 shows ulst in the Type field, which indicates that load balancing is working. The two unicast (ucst) entries in the Type field are the two next hops for the LSPs.

Sample Output

The following sample output is from transit router R2:

Meaning

The sample output for the show route forwarding-table | find mpls command issued on transit router R2 shows the MPLS routing table that contains the labels received and used by this router to forward packets to the next-hop router. This routing table is used mostly on transit routers to route packets to the next router along an LSP. The first three labels in the Destination column (Label 0, Label 1, and Label 2) are automatically entered by MPLS when the protocol is enabled. These labels are reserved MPLS labels defined in RFC 3032. 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 remaining five labels in the Destination column are nonreserved labels that the router uses to forward traffic, and the last column Netif, shows the interfaces used to send the labeled traffic. For nonreserved labels, the second Type column shows the operation performed on matching packets. In this example, all non-reserved packets are swapped for outgoing packet labels. For example, packets with the label 100112 have their label swapped for 100032 before they are pushed out of interface so-0/0/1.0.

Verify the Operation of Uneven Bandwidth Load Balancing

Purpose

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.

Action

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

Sample Output

command-name

Meaning

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.

Use the traceroute Command to Verify MPLS Labels

Purpose

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

Action

To verify MPLS labels, enter the following Junos OS CLI operational mode command, where host-name is the IP address or the name of the remote host:

Sample Output 1

command-name

Sample Output 2

command-name

Meaning

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).

Troubleshooting GMPLS and GRE Tunnel

Problem

Description

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.

CAUTION:

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.

Sample Output

Sample Output

The following sample output for the show interfaces command shows the encapsulation type and header, the maximum speed, packets through the logical interface, the destination, and logical address.

The following are various requirements when you configure a GMPLS LSP using a GRE tunnel:

  • The data channel must start and end on the same type of interface.

  • The control channel can be a GRE tunnel that starts and ends on the same or different interface type.

  • The GRE tunnel must be configured indirectly with the peer-interface peer-name statement at the [edit protocol ospf] hierarchy level.

  • The GRE interface must be disabled at the [edit protocols ospf] and [edit protocols rsvp] hierarchy levels.

  • Data and control channels must be defined correctly in the LMP configuration .

  • It is optional to disable Constrained Shortest Path First (CSPF) with the no-cspf statement.

This case focuses on the incorrect configuration of the endpoints of the GRE tunnel. However, you can use a similar process and commands to diagnose other GRE tunnel problems. Figure 13 illustrates a network topology with MPLS tunneled through a GRE interface.

Figure 13: GMPLS Network TopologyGMPLS Network Topology

The MPLS network topology in Figure 13 shows Juniper Networks routers configured with a GRE tunnel that consists of the following components:

  • A strict GMPLS LSP path from the ingress router to the egress router.

  • On the ingress router, CSPF disabled with the no-cspf statement at the [edit protocol mpls label-switched-path lsp-name] hierarchy level.

  • Traffic-engineering links and control channels within the peer statement at the [edit protocols link-management] hierarchy level on all routers.

  • OSPF and OSPF traffic engineering configured on all routers.

  • A reference to the peer-interface in both OSPF and RSVP on all routers.

  • A switching-type problem between R2 and R3.

Symptom

The LSP in the network shown in Figure 13 is down, as indicated by the output from the show mpls lsp and show rsvp session commands, which display very similar information. The show mpls lsp command shows all LSPs configured on the router, as well as all transit and egress LSPs. The show rsvp session command displays summary information about RSVP sessions. You can use either command to verify the state of the LSP. In this case, LSP gmpls-r1-to-r3 is down (Dn).

Sample Output

Cause

The cause of the problem with the GMPLS LSP is the configuration of different interface types at both ends of the GMPLS data channel.

Troubleshooting Commands

The Junos OS includes commands that are useful when troubleshooting a problem. This topic provides a brief description of each command, followed by sample output, and a discussion of the output in relation to the problem.

You can use the following commands when troubleshooting a GMPLS problem:

Sample Output

Use the show mpls lsp extensive command on transit router R1 to display detailed information about all LSPs transiting, terminating, and configured on the router.

Meaning

The sample output for the show mpls lsp extensive command shows an error message (MPLS label allocation failure) in the log section of the output. This LSP event indicates that the MPLS protocol or the family mpls statement were not configured properly. When the LSP event is preceded by an IP address, the address is typically the router that has the MPLS configuration error. In this case, it appears that the router with the lo0 address of 192.168.4.1 (R3) has an MPLS configuration error.

Sample Output

Use the show rsvp session detail command to display detailed information about RSVP sessions.

Meaning

The sample output for the show rsvp session detail command shows that LSP gmpls-r1-to-r3 is down (LSPstate: Dn). The route record is incomplete, indicating a problem with the explicit route 100.100.100.100 93.93.93.93. The address 100.100.100.100 is the data channel on R2 so-0/0/0, and the address 93.93.93.93 is the data channel on R3.

Sample Output

Use the show link-management peer command to display MPLS peer link information.

Meaning

The sample output from all routers in the example network in Figure 13 for the show link-management peer command shows that all control channels are up and active. A detailed analysis of the output shows the following information:

  • Name of the peer, tester2 or tester3, which is the same on neighboring routers for ease of troubleshooting.

  • Internal identifier for the peer, 48428 for tester2 and 48429 for tester3. The internal identifier is a range of values from 0 through 64,000.

  • The state of the peer, which can be up or down. In this case, all peers are up.

  • The address to which a control channel is established, for example, 10.35.1.5.

  • The state of the control channel, which can be up, down, or active.

  • The traffic-engineered links that are managed by their peer, indicating that control channel gre.0 is managed by tester3.

Sample Output

Use the show link-management te-link command to display the resources used to set up Multiprotocol Label Switching (MPLS) traffic-engineered forwarding paths.

Meaning

The sample output for the show link-management te-link command issued on the three routers in the network in Figure 13 shows the resources allocated to the traffic-engineered links te-tester2 and te-tester3. The resources are the SONET interfaces so-0/0/0 and so-0/0/1. On R1 and R2, the SONET interfaces are used for the LSP gmpls-r1-to-r3, as indicated by Yes in the Used field.However, the SONET interface so-0/0/1 on R3 is down (Dn) and is not used for the LSP (Used No). Further investigation is required to discover why the SONET interface on R3 is down.

Sample Outut

Use the show log filename command to display the contents of the specified log file. In this case, the log file rsvp.log is configured at the [edit protocols rsvp traceoptions] hierarchy level. When the log file is configured, you must issue the monitor start filename command to begin logging messages to the file.

Note:

The find Error option entered after the pipe ( | ) searches the output for an instance of the term Error.

Sample Output

Meaning

The sample output from the egress router R3 for the show log rsvp.log command is a snippet taken from the log file. The snippet shows a Link Management Protocol (LMP) resource request for the LSP gmpls-r1-to-r3. The request has problems with the encoding type (SDH/SONET), indicating a possible error with the SONET interface connecting R2 and R3. Further investigation of the configuration of the LMP on R2 and R3 is required.

Sample Output

Use the show configuration statement-path command to display a specific configuration hierarchy; in this instance, link-management.

Meaning

The sample output from transit router R2 and ingress router R3 for the show configuration protocols link-management command shows that the interface type on the two routers is different. The resource allocated to te-tester3 on transit router R2 is a SONET interface, while the resource allocated to te-tester3 on egress router R3 is an ATM interface. The interface type on each end of the data or control channels must be of the same type. In this case, both ends should be SONET or ATM.

Solution

Solution

The solution to the problem of different interface or encapsulation types at either end of the GMPLS LSP is to make sure that the interface type is the same at both ends. In this case, the ATM interface was deleted from the link-management configuration on R3, and a SONET interface was configured instead.

The following commands illustrate the correct configuration and commands to verify that the GMPLS LSP is up and using the data channel:

Sample Output

Meaning

The sample output for the show protocols link-management, show mpls lsp, and show link-management te-link commands from ingress router R3 show that the problem is solved. LMP is correctly configured, and the LSP gmpls-r1-to-r3 is up and using the data channel so-0/0/1.

Conclusion

In conclusion, both ends of a GMPLS data channel must be the same encapsulation or interface type. This case illustrates the correct configuration of the data channel. The principles are the same for the control channel.

Router Configurations

Output that shows the configurations of the ingress router in the network. The no-more option entered after the pipe ( | ) prevents the output from being paginated if the output is longer than the length of the terminal screen.

Sample Output

The following sample output is for ingress router R1:

Sample Output

The following sample output is for transit router R2:

Sample Output

The following sample output is for egress router R3:

Determining LSP Status

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 TopologyMPLS Network Topology

To determine the LSP state, follow these steps:

Check the Status of the LSP

Purpose

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

Action

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

Sample Output
command-name

Meaning

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 Status About the LSP

Purpose

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

Action

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

Sample Output
command-name

Meaning

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.

Checking That RSVP Path Messages Are Sent and Received

Purpose

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.

Action

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

Sample Output

command-name

Meaning

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.