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 10 illustrates the physical layer of the layered MPLS model.
Figure 10: Verifying the Physical Layer
With this layer, you must ensure that the routers are connected, and that the interfaces are up and configured correctly on the ingress, egress, and transit routers.
If the network is not functioning at this layer, the label-switched path (LSP) does not work as configured.
Figure 11 illustrates the MPLS network and the problem described in this Find appropriate term to place here instead of the word ”chapter”..
Figure 11: MPLS Network Broken at the Physical 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, 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 11 indicates where the LSP is broken because of a configuration error on ingress router R1.
To check the physical layer, follow these steps:
Typically, you use the show mpls lsp extensive command to verify the LSP. However, for quick verification of the LSP state, use the show mpls lsp command. If the LSP is down, use the extensive option (show mpls lsp extensive) as a follow-up. If your network has numerous LSPs, you might consider specifying the name of the LSP, using the name option (show mpls lsp name name or show mpls lsp name name extensive).
To determine whether the LSP is up, enter the following command from the ingress router:
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
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 20)
10.1.12.2 S 10.1.26.2 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
10.1.12.2 10.1.26.2
99 Sep 18 14:19:04 CSPF: computation result accepted
98 Sep 18 14:19:04 CSPF: link down/deleted
10.1.13.1(R1.00/10.0.0.1)->10.1.13.2(R3.00/10.0.0.3)
97 Sep 18 14:19:01 Record Route: 10.1.12.2 10.1.26.2
96 Sep 18 14:19:01 Up
95 Sep 18 14:19:01 Clear Call
94 Sep 18 14:19:01 CSPF: computation result accepted
93 Sep 18 14:19:01 MPLS label allocation failure
92 Sep 18 14:19:01 Down
91 Aug 17 12:22:52 Selected as active path
90 Aug 17 12:22:52 Record Route: 10.1.13.2 10.1.36.2
89 Aug 17 12:22:52 Up
[...Output truncated...]
Created: Sat Jul 10 18:18:44 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: 144, Since: Tue Aug 17 12:23:14 2004
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 39024 protocol 0
PATH rcvfrom: 10.1.15.2 (so-0/0/1.0) 67333 pkts
Adspec: received MTU 1500
PATH sentto: localclient
RESV rcvfrom: localclient
Record route: 10.1.56.2 10.1.15.2 <self>
Total 1 displayed, Up 1, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
The sample output from ingress router R1 shows that the LSP is using an alternate path rather than the configured path. The configured path for the LSP is R1 through R3 to R6, and for the reverse LSP, R6 through R3 to R1. The alternate path used by the LSP is R1 through R2 to R6, and for the reverse LSP, R6 through R5 to R1.
Confirm that the appropriate ingress, transit, and egress routers are functioning by examining whether the packets have been received and transmitted with 0% packet loss.
To determine that the routers are connected, enter the following command from the ingress and transit routers:
user@R1> ping 10.0.0.3 count 3 PING 10.0.0.3 (10.0.0.3): 56 data bytes 64 bytes from 10.0.0.3: icmp_seq=0 ttl=254 time=0.859 ms 64 bytes from 10.0.0.3: icmp_seq=1 ttl=254 time=0.746 ms 64 bytes from 10.0.0.3: icmp_seq=2 ttl=254 time=0.776 ms --- 10.0.0.3 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.746/0.794/0.859/0.048 ms user@R3> ping 10.0.0.6 count 3 PING 10.0.0.6 (10.0.0.6): 56 data bytes 64 bytes from 10.0.0.6: icmp_seq=0 ttl=255 time=0.968 ms 64 bytes from 10.0.0.6: icmp_seq=1 ttl=255 time=3.221 ms 64 bytes from 10.0.0.6: icmp_seq=2 ttl=255 time=0.749 ms --- 10.0.0.6 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.749/1.646/3.221/1.117 ms
The sample output shows that ingress router R1 is receiving packets from transit router R3, and that the transit router is receiving packets from the egress router. Therefore, the routers in the LSP are connected.
Confirm that the interfaces are configured correctly with the family mpls statement.
To determine that the relevant interfaces are up and configured correctly, enter the following commands from the ingress, transit, and egress routers:
user@R1> show interfaces so* terse
Interface Admin Link Proto Local Remote
so-0/0/0 up up
so-0/0/0.0 up up inet 10.1.12.1/30
iso
mpls
so-0/0/1 up up
so-0/0/1.0 up up inet 10.1.15.1/30
iso
mpls
so-0/0/2 up up
so-0/0/2.0 up up inet 10.1.13.1/30
iso <<< family mpls is missing
so-0/0/3 up down
user@R1> show configuration interfaces so-0/0/2
unit 0 {
family inet {
address 10.1.13.1/30;
}
family iso; <<< family mpls is missing
}
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.
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.
To correct the error in this example, enter the following commands:
Sample Output
[edit interfaces so-0/0/2 unit 0]
user@R1# set family mpls
[edit interfaces so-0/0/2 unit 0]
user@R1# show
family inet {
address 10.1.13.1/30;
}
family iso;
family mpls;
[edit interfaces so-0/0/2 unit 0]
user@R1# commit
commit complete
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.
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.
To verify that the LSP is up and traversing the network as expected, enter the following command:
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
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 20)
10.1.13.2 S 10.1.36.2 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
10.1.13.2 10.1.36.2
112 Sep 21 16:27:33 Record Route: 10.1.13.2 10.1.36.2
111 Sep 21 16:27:33 Up
110 Sep 21 16:27:33 CSPF: computation result accepted
109 Sep 21 16:27:33 CSPF: link down/deleted 10.1.12.1(R1.00/10.0.0.1)->10.1.12.2(R2.00/10.0.0.2)
108 Sep 21 16:27:33 CSPF: link down/deleted 10.1.15.1(R1.00/10.0.0.1)->10.1.15.2(R5.00/10.0.0.5)
[Output truncated...]
Created: Sat Jul 10 18:18:44 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: 149, Since: Tue Sep 21 16:29:43 2004
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 2 receiver 39024 protocol 0
PATH rcvfrom: 10.1.13.2 (so-0/0/2.0) 7 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
[edit protocols mpls]
user@R1# show
label-switched-path R1-to-R6 {
to 10.0.0.6;
}
interface fxp0.0 {
disable;
}
inactive: interface so-0/0/0.0;
inactive: interface so-0/0/1.0;
interface so-0/0/2.0;
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.
