Previous Section  < Free Open Study >  Next Section

Chapter 11. Troubleshooting MPLS TE

This chapter covers the following topics:

The other chapters in this book cover various aspects of MPLS TE—signalling, forwarding, design, and deployment. However, this book would be seriously lacking if it didn't discuss troubleshooting as the final thing you need to understand before deploying MPLS TE. If you can deploy and design something, that's great, but if you can't troubleshoot it after you've rolled it out, you're just asking for trouble.

When it comes to troubleshooting, for any problem ranging from a car stalling when idling to MPLS TE tunnels not coming up, the basic rules for handling the problem are essentially the same:

  • Get organized— Gather the data required to solve the problem and become well versed in the tools available for gathering the required information. This chapter describes the commonly used show and debug commands that are used to troubleshoot MPLS TE problems, where to use these commands, and when to use them.

  • Be systematic— Don't jump to Step 3 without going through Steps 1 and 2 first.

  • Break up large problems into smaller ones— Use the "divide and conquer" approach when the problem is large enough to be broken into subproblems.

This chapter assumes that you are well versed in the various components of MPLS TE introduced throughout this book. Troubleshooting MPLS TE also requires in-depth knowledge of your Interior Gateway Protocol (IGP), either OSPF or IS-IS. The next component that is useful for troubleshooting MPLS TE problems is knowledge of how MPLS forwarding works with Cisco Express Forwarding (CEF) (introduced in Chapter 2, "MPLS Forwarding Basics"). Last but not least is familiarity with the Cisco command-line interface (CLI).

All the examples in this chapter are based on the sample topology shown in Figure 11-1.

Figure 11-1. IP Addressing Used in the Sample Network

graphics/11fig01.gif

Figure 11-1 shows the IP addressing used in this sample network. The router IDs (RIDs), which are also the loopback addresses, are in parentheses above or below the routers. For example, 7200a's RID is 4.4.4.4.

The subnet address of each link is of the form 10.0.x.y, and each link has a 24-bit mask. For example, the link between 7200a and 12008a is 10.0.3.0/24, the IP address of 7200a's side of the link is 10.0.3.4 (because 7200a's RID is 4.4.4.4), and 12008a's side of the link has the address 10.0.3.5 (because 12008a's RID is 5.5.5.5).

Most of the troubleshooting scenarios revolve around a single TE tunnel. 7200a is the headend of this tunnel, tunnel1, which is referred to as the primary tunnel. 7200c is the tunnel's tail. The rest of the LSRs shown are potential midpoints for this tunnel.

When there are no failures in the sample network, the primary tunnel path is 7200a12008a12008c7200c. This is shown in the highlighted text of Example 11-1.

Example 11-1 Configuration of the Primary Tunnel—tunnel1 on 7200a

7200a#show running-config interface tunnel1

Building configuration...



Current configuration : 425 bytes

!

interface Tunnel1

 description Primary tunnel 7200a->12008a->12008c->7200c

 ip unnumbered Loopback0

 no ip directed-broadcast

 tunnel destination 12.12.12.12

 tunnel mode mpls traffic-eng

 tunnel mpls traffic-eng autoroute announce

 tunnel mpls traffic-eng priority 7 7

 tunnel mpls traffic-eng bandwidth  100

 tunnel mpls traffic-eng path-option 5 explicit name primary

 tunnel mpls traffic-eng path-option 6 dynamic

end



7200a#show ip explicit-paths name primary

PATH primary (strict source route, path complete, generation 6)

    1: next-address 10.0.3.5

    2: next-address 10.0.5.11

    3: next-address 10.0.17.12

    4: next-address 12.12.12.12

7200a#show mpls traffic-eng tunnels tunnel1



Name: Primary tunnel 7200a->12008a->12... (Tunnel1) Destination: 12.12.12.12

  Status:

    Admin: up         Oper: up     Path: valid       Signalling: connected



    path option 5, type explicit primary (Basis for Setup, path weight 3)

    path option 6, type dynamic



  Config Parameters:

    Bandwidth: 100      kbps (Global)  Priority: 7  7   Affinity: 0x0/0xFFFF

    Metric Type: TE (default)

    AutoRoute:  enabled   LockDown: disabled  Loadshare: 100      bw-based

    auto-bw: disabled



  InLabel  :  -

  OutLabel : POS3/0, 12325

  RSVP Signalling Info:

       Src 4.4.4.4, Dst 12.12.12.12, Tun_Id 1, Tun_Instance 38

    RSVP Path Info:

      My Address: 4.4.4.4

      Explicit Route: 10.0.3.5 10.0.5.11 10.0.17.12 12.12.12.12

      Record   Route:   NONE

      Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits

    RSVP Resv Info:

      Record   Route:   NONE

      Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=Inf

  Shortest Unconstrained Path Info:

    Path Weight: 3 (TE)

    Explicit Route: 10.0.3.5 10.0.5.11 10.0.17.12 12.12.12.12

  History:

    Tunnel:

      Time since created: 4 hours, 52 minutes

      Time since path change: 9 minutes, 29 seconds

    Current LSP:

      Uptime: 9 minutes, 29 seconds

    Prior LSP:

      ID: path option 5 [34]

      Removal Trigger: path verification failed

The IGP used in the sample network is OSPF. As a result, some of the commands used during troubleshooting might be OSPF-specific. However, IS-IS commands are also shown where appropriate.
    Previous Section  < Free Open Study >  Next Section