[ Contents] [ Prev] [ Next] [ Index] [ Report an Error]

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 19 illustrates the RSVP layer of the layered MPLS model.

Figure 19: Checking the RSVP Layer

Image g015546.gif

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 20 illustrates the MPLS network used in this Find the appropriate term to place here instead of the word “chapter”..

Figure 20: MPLS Network Broken at the RSVP Layer

Image g015540.gif

The network shown in Figure 20 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 20 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 20, a configuration error on transit router R3 prevents the LSP from traversing the network as expected.

To check the RSVP layer, follow these steps:

  1. Verify the LSP
  2. Verify RSVP Sessions
  3. Verify RSVP Neighbors
  4. Verify RSVP Interfaces
  5. Verify the RSVP Protocol Configuration
  6. Take Appropriate Action
  7. Verify the LSP Again

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:

user@host> show mpls lsp extensive

Sample Output 1

user@R1> show mpls lsp extensive
Ingress LSP: 1 sessions

10.0.0.6
  From: 10.0.0.1, State: Dn, ActiveRoute: 0,  LSPname: R1-to-R6
  ActivePath: (none)
  LoadBalance: Random
  Encoding type: Packet, Switching type: Packet, GPID: IPv4
  Primary                    State: Dn
    2 Oct 27 15:06:05 10.1.13.2:  No Route toward dest [4 times]
    1 Oct 27 15:05:56 Originate Call
  Created: Wed Oct 27 15:05:55 2004
Total 1 displayed, Up 0,  Down 1

Egress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

user@R3> show mpls lsp extensive 
Ingress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

Egress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

user@R6> show mpls lsp extensive
Ingress LSP: 1 sessions

10.0.0.1
  From: 10.0.0.6, State: Dn, ActiveRoute: 0,  LSPname: R6-to-R1
  ActivePath: (none)
  LoadBalance: Random
  Encoding type: Packet, Switching type: Packet, GPID: IPv4
  Primary                    State: Dn
    Will be enqueued for recomputation in 22 second(s).
    1 Oct 27 14:59:12  CSPF failed: no route toward 10.0.0.1 [4 times]
  Created: Wed Oct 27 14:57:44 2004
Total 1 displayed, Up 0,  Down 1

Egress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

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:

user@host> show rsvp session

Sample Output 1

user@R1> show rsvp session 
Ingress RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

Egress RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

Transit RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

user@R3> show rsvp session 
Ingress RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

Egress RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

Transit RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

user@R6> show rsvp session  
Ingress RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

Egress RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

Transit RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

Sample Output 2

user@R1> show rsvp session
Ingress RSVP: 1 sessions
To              From            State Rt Style Labelin Labelout LSPname 
10.0.0.6        10.0.0.1        Up     1 1 FF       -   100768  R1-to-R6
Total 1 displayed,  Up 1 , Down 0

Egress RSVP: 1 sessions
To              From            State Rt Style Labelin Labelout LSPname 
10.0.0.1        10.0.0.6        Up     0 1 FF       3        -  R6-to-R1
Total 1 displayed,  Up 1 , Down 0

Transit RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

user@R3> show rsvp session  
Ingress RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

Egress RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

Transit RSVP:  2 sessions
To              From            State Rt Style Labelin Labelout LSPname 
10.0.0.1        10.0.0.6        Up     1 1 FF  100784        3  R6-to-R1
10.0.0.6        10.0.0.1        Up     1 1 FF  100768        3  R1-to-R6
Total 2 displayed,  Up 2 , Down 0

user@R6> show rsvp session       
Ingress RSVP: 1 sessions
To              From            State Rt Style Labelin Labelout LSPname 
10.0.0.1        10.0.0.6        Up     1 1 FF       -   100784  R6-to-R1
Total 1 displayed,  Up 1 , Down 0

Egress RSVP: 1 sessions
To              From            State Rt Style Labelin Labelout LSPname 
10.0.0.6        10.0.0.1        Up     0 1 FF       3        -  R1-to-R6
Total 1 displayed,  Up 1 , Down 0

Transit RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

Meaning

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

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:

user@host> show rsvp neighbor

Sample Output 1

user@R1> show rsvp neighbor 
RSVP neighbor: 1 learned
Address            Idle Up/Dn LastChange HelloInt HelloTx/Rx MsgRcvd
10.1.13.2            10   1/0         9:22        9    64/64   32

user@R3> show rsvp neighbor 
RSVP neighbor: 2 learned
Address            Idle Up/Dn LastChange HelloInt HelloTx/Rx MsgRcvd
10.1.13.1             0  1/0       28:20        9   190/190  41
10.1.36.2         16:50   1/1        15:37        9   105/78   38

user@R6> show rsvp neighbor 
RSVP neighbor: 1 learned
Address            Idle Up/Dn LastChange HelloInt HelloTx/Rx MsgRcvd
10.1.36.1         17:30   1/1        16:15        9   104/78   39

Sample Output 2

user@R3> show rsvp neighbor 
RSVP neighbor: 2 learned
Address            Idle Up/Dn LastChange HelloInt HelloTx/Rx MsgRcvd
10.1.13.1             5   1/0         9:14        9    63/63   33
10.1.36.2             5   1/0         9:05        9    62/62   32

user@R6> show rsvp neighbor  
RSVP neighbor: 1 learned
Address            Idle Up/Dn LastChange HelloInt HelloTx/Rx MsgRcvd
10.1.36.1             5   1/0        8:54        9    61/61   32

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. Continue investigating the problem in Verify RSVP Interfaces.

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:

user@host> show rsvp interface

Sample Output 1

user@R1> show rsvp interface
RSVP interface: 3 active
                   Active  Subscr- Static      Available   Reserved    Highwater
Interface   State  resv   iption  BW          BW          BW          mark
so-0/0/0.0  Up         0   100%  155.52Mbps  155.52Mbps  0bps        0bps       
so-0/0/1.0  Up         0   100%  155.52Mbps  155.52Mbps  0bps        0bps       
so-0/0/2.0  Up          0    100%  155.52Mbps  155.52Mbps  0bps        0bps       

user@R3> show rsvp interface  
RSVP interface: 3 active
                   Active  Subscr- Static      Available   Reserved    Highwater
Interface   State  resv    iption  BW          BW          BW          mark
so-0/0/0.0  Up         0   100%  155.52Mbps  155.52Mbps  0bps        0bps       
so-0/0/1.0  Up         0   100%  155.52Mbps  155.52Mbps  0bps        0bps       
so-0/0/2.0  Up          0    100%  155.52Mbps  155.52Mbps  0bps        0bps       
<<< Missing interface so-0/0/3.0

user@R6> show rsvp interface 
RSVP interface: 4 active
                   Active  Subscr- Static      Available   Reserved    Highwater
Interface   State  resv    iption  BW          BW          BW          mark
so-0/0/0.0  Up         0   100%  155.52Mbps  155.52Mbps  0bps        0bps       
so-0/0/1.0  Up         0   100%  155.52Mbps  155.52Mbps  0bps        0bps       
so-0/0/2.0  Up         0   100%  155.52Mbps  155.52Mbps  0bps        0bps       
so-0/0/3.0  Up          0    100%  155.52Mbps  155.52Mbps  0bps        0bps 

Sample Output 2

user@R1> show rsvp interface
RSVP interface: 3 active
                  Active Subscr- Static      Available   Reserved    Highwater
Interface   State resv   iption  BW          BW          BW          mark
so-0/0/0.0  Up         0   100%  155.52Mbps  155.52Mbps  0bps        0bps       
so-0/0/1.0  Up         0   100%  155.52Mbps  155.52Mbps  0bps        0bps       
so-0/0/2.0  Up          1    100%  155.52Mbps  155.52Mbps  0bps        0bps       

user@R3> show rsvp interface                   
RSVP interface: 4 active
                  Active Subscr- Static      Available   Reserved    Highwater
Interface   State resv   iption  BW          BW          BW          mark
so-0/0/0.0  Up         0   100%  155.52Mbps  155.52Mbps  0bps        0bps       
so-0/0/1.0  Up         0   100%  155.52Mbps  155.52Mbps  0bps        0bps       
so-0/0/2.0  Up          1    100%  155.52Mbps  155.52Mbps  0bps        0bps       
so-0/0/3.0  Up          1    100%  155.52Mbps  155.52Mbps  0bps        0bps       

user@R6> show rsvp interface 
RSVP interface: 4 active
                  Active Subscr- Static      Available   Reserved    Highwater
Interface   State resv   iption  BW          BW          BW          mark
so-0/0/0.0  Up         0   100%  155.52Mbps  155.52Mbps  0bps        0bps       
so-0/0/1.0  Up         0   100%  155.52Mbps  155.52Mbps  0bps        0bps       
so-0/0/2.0  Up         0   100%  155.52Mbps  155.52Mbps  0bps        0bps       
so-0/0/3.0  Up          1    100%  155.52Mbps  155.52Mbps  0bps        0bps 

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:

user@host> show configuration protocols rsvp

Sample Output

user@R1> show configuration protocols rsvp 
interface so-0/0/0.0;
interface so-0/0/1.0;
interface so-0/0/2.0;
interface fxp0.0 {
    disable;
}

user@R3> show configuration protocols rsvp  
interface so-0/0/0.0;
interface so-0/0/1.0;
interface so-0/0/2.0; <<< Missing interface so-0/0/3.0
interface fxp0.0 {
    disable;
}

user@R6> show configuration protocols rsvp 
interface so-0/0/0.0;
interface so-0/0/1.0;
interface so-0/0/2.0;
interface so-0/0/3.0;
interface fxp0.0 {
    disable;
}

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

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:
    user@R3> edit
    user@R3# edit protocols rsvp
    [edit protocols rsvp]
    user@R3# show
    user@R3# set interface so-0/0/3.0
  2. Verify and commit the configuration:
    [edit protocols rsvp]
    user@R3# show
    user@R3# commit

Sample Output

user@R3> edit 
Entering configuration mode

[edit]
user@R3# edit protocols rsvp 

[edit protocols rsvp]
user@R3# show  
interface so-0/0/0.0;
interface so-0/0/1.0;
interface so-0/0/2.0; <<< Missing interface so-0/0/3.0
interface fxp0.0 {
    disable;
}
[edit protocols rsvp]
user@R3# set interface so-0/0/3.0 

[edit protocols rsvp]
user@R3# show 
interface so-0/0/0.0;
interface so-0/0/1.0;
interface so-0/0/2.0;
interface fxp0.0 {
    disable;
}
interface so-0/0/3.0; <<< Interface now included in the configuration

[edit protocols rsvp]
user@R3# commit  
commit complete

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:

user@host> show mpls lsp extensive

Sample Output 1

user@R1> show mpls lsp extensive
Ingress LSP: 1 sessions

10.0.0.6
  From: 10.0.0.1, State: Up,  ActiveRoute: 1 ,  LSPname: R1-to-R6
  ActivePath:  (primary)
  LoadBalance: Random
  Encoding type: Packet, Switching type: Packet, GPID: IPv4
 *Primary                    State: Up
    Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
          10.1.13.2 10.1.36.2
    5 Oct 27 15:28:57 Selected as active path
    4 Oct 27 15:28:57  Record Route:  10.1.13.2 10.1.36.2
    3 Oct 27 15:28:57 Up
    2 Oct 27 15:28:44 10.1.13.2: No Route toward dest[35 times]
    1 Oct 27 15:05:56 Originate Call
  Created: Wed Oct 27 15:05:56 2004
Total 1 displayed, Up 1, Down 0

Egress LSP: 1 sessions

10.0.0.1
  From: 10.0.0.6, LSPstate: Up, ActiveRoute: 0
  LSPname: R6-to-R1, LSPpath: Primary
  Suggested label received: -, Suggested label sent: -
  Recovery label received: -, Recovery label sent: -
  Resv style: 1 FF, Label in: 3, Label out: -
  Time left:  136, Since: Wed Oct 27 15:29:20 2004
  Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
  Port number: sender 1 receiver 39092 protocol 0
  PATH rcvfrom: 10.1.13.2 (so-0/0/2.0) 6 pkts
  Adspec: received MTU 1500 
  PATH sentto: localclient
  RESV rcvfrom: localclient 
  Record route: 10.1.36.2 10.1.13.2 <self>  
Total 1 displayed, Up 1, Down 0

Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

Sample Output 2

user@R3> show mpls lsp extensive
Ingress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

Egress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

Transit LSP: 2 sessions

10.0.0.1
  From: 10.0.0.6, LSPstate: Up, ActiveRoute: 1
  LSPname: R6-to-R1, LSPpath: Primary
  Suggested label received: -, Suggested label sent: -
  Recovery label received: -, Recovery label sent: 3
  Resv style: 1 FF, Label in: 100672, Label out: 3
  Time left:  152, Since: Wed Oct 27 15:16:39 2004
  Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
  Port number: sender 1 receiver 39092 protocol 0
  PATH rcvfrom: 10.1.36.2 (so-0/0/3.0) 7 pkts
  Adspec: received MTU 1500 sent MTU 1500
  PATH sentto: 10.1.13.1 (so-0/0/2.0) 7 pkts
  RESV rcvfrom: 10.1.13.1 (so-0/0/2.0) 7 pkts
  Explct route: 10.1.13.1 
  Record route: 10.1.36.2 <self> 10.1.13.1  

10.0.0.6
  From: 10.0.0.1, LSPstate: Up, ActiveRoute: 1
  LSPname: R1-to-R6, LSPpath: Primary
  Suggested label received: -, Suggested label sent: -
  Recovery label received: -, Recovery label sent: 3
  Resv style: 1 FF, Label in: 100656, Label out: 3
  Time left:  129, Since: Wed Oct 27 14:53:14 2004
  Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
  Port number: sender 1 receiver 47977 protocol 0
  PATH rcvfrom: 10.1.13.1 (so-0/0/2.0) 40 pkts
  Adspec: received MTU 1500 sent MTU 1500
  PATH sentto: 10.1.36.2 (so-0/0/3.0) 7 pkts
  RESV rcvfrom: 10.1.36.2 (so-0/0/3.0) 7 pkts
  Record route: 10.1.13.1 <self> 10.1.36.2  
Total 2 displayed, Up 2, Down 0

Sample Output 3

user@R6> show mpls lsp extensive
Ingress LSP: 1 sessions

10.0.0.1
  From: 10.0.0.6, State: Up,  ActiveRoute: 1 ,  LSPname: R6-to-R1
  ActivePath:  (primary)
  LoadBalance: Random
  Encoding type: Packet, Switching type: Packet, GPID: IPv4
 *Primary                     State: Up
    Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 20)
 10.1.36.1 S 10.1.13.1 S 
    Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
          10.1.36.1 10.1.13.1
    6 Oct 27 15:22:06 Selected as active path
    5 Oct 27 15:22:06 Record Route:  10.1.36.1 10.1.13.1
    4 Oct 27 15:22:06 Up
    3 Oct 27 15:22:06 Originate Call
    2 Oct 27 15:22:06 CSPF: computation result accepted
    1 Oct 27 15:21:36 CSPF failed: no route toward 10.0.0.1[50 times]
  Created: Wed Oct 27 14:57:45 2004
Total 1 displayed, Up 1, Down 0

Egress LSP: 1 sessions

10.0.0.6
  From: 10.0.0.1, LSPstate: Up, ActiveRoute: 0
  LSPname: R1-to-R6, LSPpath: Primary
  Suggested label received: -, Suggested label sent: -
  Recovery label received: -, Recovery label sent: -
  Resv style: 1 FF, Label in: 3, Label out: -
  Time left:  119, Since: Wed Oct 27 15:21:43 2004
  Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
  Port number: sender 1 receiver 47977 protocol 0
  PATH rcvfrom: 10.1.36.1 (so-0/0/3.0) 7 pkts
  Adspec: received MTU 1500 
  PATH sentto: localclient
  RESV rcvfrom: localclient 
  Record route: 10.1.13.1 10.1.36.1 <self>  
Total 1 displayed, Up 1, Down 0

Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

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.


[ Contents] [ Prev] [ Next] [ Index] [ Report an Error]