Example 1123 IGP Shortest Path from 7200a to 7200c

7200a#show ip route 12.12.12.12

Routing entry for 12.12.12.12/32

Known via "ospf 100", distance 110, metric 4, type intra area Last update from 10.0.3.5 on P0S3/0, 04:39:01 ago Routing Descriptor Blocks:

* 10.0.3.5, from 12.12.12.12, 04:39:01 ago, via P0S3/C Route metric is 4, traffic share count is 1

7 2 00a#traceroute 12.12.12.12

Type escape sequence to abort. Tracing the route to 12.12.12.12

1

10,

0.

,3.5 0 msec 0 msec 0 msec

2

10,

0.

,5.11 0 msec 0 msec 0 msec

Notice in the highlighted text of the traceroute output that there is no label information for each hop. Not having labels in the traceroute output is not always a guarantee that there are no tunnels on the way to the destination. You could have many one-hop tunnels from 7200a to 7200c that make the traffic from 72008^^7200c follow the non-

IGP best path and still don't show labels in the output of a traceroute from 7200a to 7200c. However, if you see labels in a traceroute, and you see the traceroute taking a path that does not come across as the IGP shortest path, this should make you suspicious of midpoint tunnels that have autoroute or FA configured on them.

Of course, you also see labels in a traceroute if you have LDP/TDP turned on somewhere in the path. Example 11-24 shows a traceroute from 7200a to 7200c when the traffic is going down a TE tunnel that has autoroute configured on 12008a, causing the packets from 7200a to take the non-IGP shortest path. Traceroute provides you with information about the path that the packet takes to reach the destination. Traceroute is safe to use only if you know that nothing downstream will make the traceroute packets take the non-IGP best path. Although show mpls traffic-eng topology path destination tunnel-dest shows you what CSPF thinks is the shortest unconstrained path to the destination, there is no substitute in such cases for knowing what path a packet should take in the absence of MPLS TE.

Was this article helpful?

0 0

Post a comment