MPLS - Troubleshooting Guide

TM

Advanced Services

Advanced Service MPLS - Troubleshooting Guide Version 1.0

Corporate Headquarters Cisco 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com Tel: 408 526-4000 800 553-NETS (6387) Fax: 408 526-4100

Contents Contents ........................................................... .............................................................................................................................. ...............................................................................2 ............2 Figures ............................................................. ................................................................................................................................... ...............................................................................5 .........5 Introduction ................................................................. ....................................................................................................................................6 ...................................................................6 Document Purpose ...................................................................................................................6 ...................................................................................................................6 Motivation .............................................................. ..................................................................................................................................6 ....................................................................6 Intended Audience ............................................................................................. ....................................................................................................................6 .......................6 Organisation ...................................................................... ..............................................................................................................................6 ........................................................6 Part 1: Technology Description .................................................................. ....................................................................................................7 ..................................7 MPLS and MPLS/VPN M PLS/VPN Introduction Introductio n ..............................................................................................8 ..............................................................................................8 MPLS Features ..........................................................................................................................8 ..........................................................................................................................8 MPLS Architecture ........................................................................................................... ....................................................................................................................8 .........8 What Are MPLS Labels? .............................................................. ........................................................................................................ .......................................... 10 What Are MPLS VPNs? ............................................................... .......................................................................................................... ........................................... 11 MP-BGP .......................................................................................................................... ................................................................................................................................... ......... 12 What Is The MPLS VPN Architecture? ................................................................................. ................................................................................. 13 How Is The T he Routing Between C E-PE and PE-PE? .............................................................. 14 What Is Multi-VRF CE (VRF-Lite)? .................................................................................. ........................................................................................ ...... 16 What Are the Effects of o f MPLS VPNs on Packet Forwarding? ........................................... 16 MTU issues .................................................................................................................... ............................................................................................................................. ......... 16 MPLS Traffic Engineering Introduction .................................................................................... 17 What is MPLS MPL S TE? ................................................................................................................. 17 Why use MPLS TE? ......................................................................................................... ............................................................................................................... ...... 17 CBR (Constraint-Based (Constraint- Based Routing) ......................................................................................... ......................................................................................... 18 Traditional RSVP ..................................................................................... .................................................................................................................... ............................... 19 RSVP-TE .............................................................................................................. .................................................................................................................................. .................... 20 Fast Reroute (FRR) ................................................................................................................ ................................................................................................................ 20 Auto Tunnel M esh and Backup ............................................................................................ 22 AToM Introduction ...................................................................................................................... ...................................................................................................................... 23 Why implement AToM? ......................................................................................................... ......................................................................................................... 23 Transport Types ...................................................................................... ..................................................................................................................... ............................... 23 How AToM works? ................................................................................................................. ................................................................................................................. 24 July 10

Advanced Service A printed copy of this document is considered uncontrolled.

2

Contents Contents ........................................................... .............................................................................................................................. ...............................................................................2 ............2 Figures ............................................................. ................................................................................................................................... ...............................................................................5 .........5 Introduction ................................................................. ....................................................................................................................................6 ...................................................................6 Document Purpose ...................................................................................................................6 ...................................................................................................................6 Motivation .............................................................. ..................................................................................................................................6 ....................................................................6 Intended Audience ............................................................................................. ....................................................................................................................6 .......................6 Organisation ...................................................................... ..............................................................................................................................6 ........................................................6 Part 1: Technology Description .................................................................. ....................................................................................................7 ..................................7 MPLS and MPLS/VPN M PLS/VPN Introduction Introductio n ..............................................................................................8 ..............................................................................................8 MPLS Features ..........................................................................................................................8 ..........................................................................................................................8 MPLS Architecture ........................................................................................................... ....................................................................................................................8 .........8 What Are MPLS Labels? .............................................................. ........................................................................................................ .......................................... 10 What Are MPLS VPNs? ............................................................... .......................................................................................................... ........................................... 11 MP-BGP .......................................................................................................................... ................................................................................................................................... ......... 12 What Is The MPLS VPN Architecture? ................................................................................. ................................................................................. 13 How Is The T he Routing Between C E-PE and PE-PE? .............................................................. 14 What Is Multi-VRF CE (VRF-Lite)? .................................................................................. ........................................................................................ ...... 16 What Are the Effects of o f MPLS VPNs on Packet Forwarding? ........................................... 16 MTU issues .................................................................................................................... ............................................................................................................................. ......... 16 MPLS Traffic Engineering Introduction .................................................................................... 17 What is MPLS MPL S TE? ................................................................................................................. 17 Why use MPLS TE? ......................................................................................................... ............................................................................................................... ...... 17 CBR (Constraint-Based (Constraint- Based Routing) ......................................................................................... ......................................................................................... 18 Traditional RSVP ..................................................................................... .................................................................................................................... ............................... 19 RSVP-TE .............................................................................................................. .................................................................................................................................. .................... 20 Fast Reroute (FRR) ................................................................................................................ ................................................................................................................ 20 Auto Tunnel M esh and Backup ............................................................................................ 22 AToM Introduction ...................................................................................................................... ...................................................................................................................... 23 Why implement AToM? ......................................................................................................... ......................................................................................................... 23 Transport Types ...................................................................................... ..................................................................................................................... ............................... 23 How AToM works? ................................................................................................................. ................................................................................................................. 24 July 10


2

Part 2: Troubleshooting T roubleshooting Methodology M ethodology ..................................................................... ...................................................................................... ................. 26 Essential MPLS/VPN MPLS/V PN configs ..................................................................................................... ..................................................................................................... 27 Essential TE configs ........................................................ .............................................................................................................. ...................................................... 28 Essential AToM configs ........................................................................................................ ........................................................................................................ 29 Part 3: Some M PLS Commands................................................................................................. 30 A Simplistic Topology to be used as an example for the Troubleshooting .................... 39 Part 4: List of Show Commands ................................................................................................ ................................................................................................ 40 Troubleshooting Summary ............................................................................................... ........................................................................................................ ......... 41 MPLS and MPLS/VPN MPLS/V PN Troubleshooting Troubleshoo ting ........................................................... ............................................................................... .................... 41 MPLS/TE and FRR Troubleshooting .................................................................................... .................................................................................... 43 AToM Troubleshooting ............................................................... .......................................................................................................... ........................................... 45 Troubleshooting commands ............................................................ ...................................................................................................... .......................................... 46 MPLS and MPLS/VPN ............................................................................................................ ............................................................................................................ 46 MPLS/TE and FRR ............................................................ .................................................................................................................. ...................................................... 64 AToM ....................................................................................................................................... ....................................................................................................................................... 88 Tracing a LSP end to end ............................................................ ...................................................................................................... .......................................... 89 Part 5: Failure Scenarios ............................................................................. ............................................................................................................ ............................... 94 Troubleshooting Scenarios .............................................................. ........................................................................................................ .......................................... 95 Mis-configuration ................................................................................................................... ................................................................................................................... 95 Some MPLS and MPLS/VPN issues ................................................................................... ................................................................................... 109 PE Node Failure....................................................................................... Failure.................................................................................................................... ............................. 114 PE-CE Link Failure F ailure ........................................................... ............................................................................................................... .................................................... 115 RR Node Failure ................................................................................................................... ................................................................................................................... 116 Link Failure ......................................................................................................... ........................................................................................................................... .................. 117 P Node Failure ......................................................................................... ...................................................................................................................... ............................. 130 AToM issues ............................................................................................ ......................................................................................................................... ............................. 139 Conclusion .......................................................................................................................... ................................................................................................................................. ....... 141 Part 6: Appendix ..................................................................... ........................................................................................................................ ................................................... 143 Appendix I ..................................................................................................... .................................................................................................................................. ............................. 144 Troubleshooting GSR forwarding ...................................................................................... ...................................................................................... 144 Debug commands of interest for Control Plane ........................................................ ............................................................... ....... 146 Debug commands of interest for Data Plane ............................................................. .................................................................... ....... 155 Debug commands of interest for MPLS and MPLS/VPN ................................................. 155 July 10


3

Debug commands of interest for AToM ............................................................................ 155 How to measure packet loss............................................................................................... 156 Useful MIBs and how to poll them ..................................................................................... 159 Appendix II ................................................................................................................................. 162 Configuration used in lab .................................................................................................... 162 Glossary ..................................................................................................................................... 171 References ................................................................................................................................. 173 About This MPLS - Troubleshooting Guide ........................................................................... 175 History ................................................................................................................................... 175 Review ................................................................................................................................... 175

July 10


4

Figures

Figure 1 – Information Base

9

Figure 2 - Interactions between MPLS applications

11

Figure 3 – Routing look up using CEF and BGP prefixes

12

Figure 4 - Non BGP Route Propagation - Outbound

15

Figure 5 - Non BGP Route Propagation - Inbound

15

Figure 6 - Primary Tunnel Path

21

Figure 7 - Backup Tunnel - Node Protection

21

Figure 8 - Backup Tunnel - Link Protection

22

Figure 9 - AToM - Label exchanging

24

Figure 10 - AToM - frame forwarding

25

Figure 11 - Topology used in lab for capturing output

39

Figure 12 - Lab topology for LINK and NODE failures scenarios

July 10

140


5

Introduction

Document Purpose This document serves as a generic troubleshooting resource for operational staff when diagnosing and identifying faults in the MPLS network, focusing the following technologies: 

MPLS label exchanging (via LDP).



MPLS VPN (via MP-BGP).



MPLS TE and FRR (via RSVP).



AToM – Any Transport over MPLS (via IGP and LDP).

This document will particularly focus on troubleshooting aspect of MPLS environment (LDP, VPN, TE and AToM) and will not describe specific MPLS implementation or design. A brief overview will be provided, however the reader is encouraged to read the reference material for a comprehensive overview.

Motivation Troubleshooting can sometimes be perceived as a black art and thus Cisco Advanced Services is focused to provide with a clear outline for troubleshooting issues relating to some MPLS deployment including traffic Engineering. This document is primarily aimed to help Operational Support Staff, firstly to debug and diagnose issues, and also to collect necessary information that will be required in the event a Cisco TAC Service Request is opened.

Intended Audience The intended audience for this document is: 

Operational stuff.



Cisco Advanced Services Teams.

Organisation Part 1: A brief summary of the MPLS T echnology: MPLS, LDP, MP-BGP, RSVP and AToM Part 2: Troubleshooting Methodology: step-by-step checking list per technology Part 3: List of the MPLS commands used in the lab topology Part 4: List of the show commands to check the network status Part 5: Examples of some issue and how to identify them based on show commands Part 6: Appendixes

July 10


6

TM

Part 1: Technology Description

MPLS and MPLS/VPN Introduction Before basic MPLS functionality is explained, these three foundations of traditional IP routing need to be highlighted: 





Routing protocols are used on all devices to distribute routing information. Each router analyses the Layer 3 header of each packet compared to the local routing table and makes a decision about where to forward the packet. Regardless of the routing protocol, routers forward packets contingent on a destination address-based routing lookup. The routing lookup is performed independently on every router in the network.

MPLS Features MPLS is a packet-forwarding technology that uses appended labels (tags) to make for warding decisions for packets. 



Within the MPLS network, the Layer 3 header analysis is done just once (when the packet enters the MPLS domain). Labels are appended to the packet, and then the packet is forwarded into the MPLS domain. Simple label inspection integrated with CEF switching drives subsequent packet forwarding.

MPLS was designed to support efficiently forwarding packets across the network core based on a simplified header. Label switching is performed regardless of the Layer 3 routing protocol. 

MPLS decreases the forwarding overhead on the core routers.



MPLS supports multiple useful applications such as those li sted here:



-

Unicast and Multicast IP routing.

-

VPN (Virtual Private Network).

-

TE (Traffic Engineering).

-

QoS (Quality of Services).

-

AToM (Any Transport Over MPLS).

MPLS supports the forwarding of non-IP protocols, because MPLS technologies are applicable to any network layer protocol.

MPLS Architecture MPLS consists of these two major components: 

Control Plane.



Data Plane.

July 10


8

Control Plane The control plane builds a routing table (RIB – Routing Information Base) based on the routing pr otocol. The control plane uses a label exchange protocol to create and maintain labels internally, and to exchange these labels with other devices. The label exchange protocols include MPLS LDP or TDP, BGP (used by MPLS VPN) and RSVP (used by MPLS TE to accomplish label exchange). The control plane also builds two forwarding tables, a FIB from the information in the RIB, and a LFIB (Label Forwarding Information Base) table based on the label exchange protocol and the RIB. The LFIB table includes label values and associations with the outgoing interface for every network pr efix.

Data Plane Data Plane is a simple forwarding engine that is independent of the type of routing protocol or label exchange protocol being used. The data plane forwards packets to the appropriate interface based on the information in the LFIB or the FIB tables.

Figure 1 – Information Base

MPLS Terminology 



LSR (Label Switch Router): A device that implements label distribution procedures and primarily forwards packets based on labels. Typically known as a P (Provider) router. Edge LSR: An LSR on the edge of an MPLS domain that implements label distribution procedures, forwards packets based on labels, and primarily inserts labels on packets or remove labels for non-MPLS devices. Typically known as a PE (Provider Edge) ro uter.

July 10


9

What Are MPLS Labels? MPLS uses a 4-byte, fixed-length (32-bit) level field that contains the information that follows: 

20-bit label.



3-bit experimental field (typically used to carry IP precedence value).



1-bit bottom-of-stack indicator (indicates whether this is the last label before the IP header).



8-bit TTL (equal to the TTL in the IP header).

An MPLS label is a locally significant identifier that is used by network core devices to make forwarding decisions for a packet. Labels define the destination and services for each packet, and identify a FEC (Forwarding Equivalence Class). The label put on a particular packet represents the FEC to which the packet is assigned. Each LSR in the network makes an independent, local decision regarding which value to use to represent an FEC. This mapping is known as a label binding. 

FEC is a group of packets forwarded:

-

In the same manner.

-

Over the same path.

-

With the same forwarding treatment.

MPLS uses FEC-based forwarding to evolve connectionless IP networks to connection-oriented networks. MPLS technology is intended to be used anywhere regardless of Layer 1 media and Layer 2 encapsulation. 

Frame-mode MPLS is MPLS over a frame-based Layer 2 encapsulation:



The label is inserted between the Layer 2 and Layer 3 headers.

Cell-mode MPLS is MPLS over ATM:

-

The fields in the ATM header are used as the label.

If ATM is being used as a WAN link and the ATM switches do not act as LSRs, this is a frame-mode MPLS.

What Are MPLS Label Operations? An LSR can perform these functions: 

Insert (impose or push) a label or a stack of labels on ingress edge LSR.



Swap a label with a next-hop label or a stack of labels in the core.



Remove (pop) a label on egress edge LSR.

MPLS Applications MPLS can be used in different applications, as outlined here: 

Unicast IP routing is the most common application for MPLS.



Multicast IP routing is treated separately because of different forwarding requirements.



MPLS TE is an add-on to MPLS that provides better and more intelligent link use.



Differentiated QoS can also be provided with MPLS.



MPLS VPNs are implemented using labels to allow overlapping address space between VPNs.



AToM is a solution for transporting Layer-2 packets over an IP or MPLS backbone.

July 10


10

What Are MPLS VPNs? MPLS enables highly scaleable VPN services to be supported. For each MPLS VPN user, the network appears to function as a private IP backbone over which the user can reach other sites within the VPN organisation, but not the sites of any other VPN organisation. MPLS VPNs are a common application for service providers. Building VPNs in Layer 3 allows delivery of targeted services to a group of users represented by a VPN. Customer networks are learned via an IGP (OSPF, BGP, RIPv2, static and recently ISIS and EIGRP) from a customer, or via BGP from other MPLS backbone routers (Inter AS- MPLS/VPNs). MPLS VPNs use two labels: 



The top label points to the egress router. The second label identifies the outgoing interface on the egress router or a routing table where a routing lookup is performed.

LDP is needed in the top label to link edge LSRs with a single label-switched Path (LSP) tunnel. MP-BGP (Multiprotocol BGP) is used in the second label to propagate VPN routing information and labels across the MPLS domain. LSPs are unidirectional: Return traffic uses a different LSP (usually the reverse path because most routing protocols provide symmetrical routing). An LSP can take a different path from the one chosen by an IP routing protocol (MPLS TE).

What Are The Interactions Between MPLS Application? Figure 2 - Interactions between MPLS applications

The Figure 2 shows the overall architecture when multiple applications are used. Regardless of the application, the functionality is always split into the control plane and the data (forwarding) plane, as discussed here: 

The applications may use a different routing protocol and a different label exchange protocol in the control plane.



The applications all use a co mmon label-switching data (forwarding) plane.



Edge LSR Layer 3 data planes may differ to support label imposition and disposition.



In general, a label is assigned to an FEC.

July 10


11

MP-BGP The BGP-4 is capable of carrying routing information only for IPv4. The Multiprotocol Extension BGP (MP-BGP) defines extensions to BGP to carry routing information for multiple Network Layer protocols (e.g. IPv6, IPX, CLNS, VPNv4, multicast, etc …). Multiprotocol Reachable NLRI (MP_REACH_NLRI) is a new non-transitive and optional BGP attribute that is used for the following purposes: 





To advertise a feasible route to a peer. To permit a router to advertise the Network Layer Address of the router that should be used as the next-hop to the destinations listed in the Network Layer Reachability Information field of the MP_NLRI attribute. To allow a given router to report some or all of the SNPAs (Subnetwork Points of Attachment) that exist within the local system.

The attribute contains one or more triples: 

Address Family Information.



Next-hop Information.



Network Layer Reachability Information.

The Address Family carries the identity of the Network Layer Protocol associated with the Network Address that follows.

Figure 3 – Routing look up using CEF and BGP prefixes

For BGP prefixes the routing look up occurs twice: 



1

First to identify BGP-next-hop. Second time to identify how to reach BGP-next-hop, usually is a remote PE. This IP prefix should 1 be learnt via an internal gateway protocol such as IS-IS .

It can‟t be learnt via BGP, ot herwise you will have an unstable network with flapping prefixes on routing table.

July 10


12

What Is The MPLS VPN Architecture? The MPLS VPN architecture offers service providers a peer-to-peer VPN architecture that combines the best features of overlay VPNs (support for overlapping customer address spaces) with the best features of peer-to-peer VPNs. 





PE routers participate in customer routing, guaranteeing optimum routing between customer sites. PE routers carry a separate set of routes for each customer, resulting in perfect isolation between customers. Customers can use overlapping addr esses.

The architecture of a PE router in an MPLS VPN is very similar to the architecture of a POP with customer-dedicated PE routers used in the dedicated-router peer-to-peer VPN model. The only difference is that the whole architecture is condensed into one physical device with the PE router in an MPLS VPN. Each customer is assigned an independent routing table (virtual routing table of VRF) that corresponds to customer dedicated PE router in the traditional peer-to-peer model. Routing across the provider backbone is performed by another routing process that uses a global IP routing table corresponding to the intra-POP P router in the traditional peer-to-peer model.

What Are Route Distinguishers (RD)? The RD is used only to transform non-unique 32-bit customer IPv4 addresses into unique 96-bit VPNv4 2 addresses . VPNv4 addresses are exchanged only between PE routers; they are never used between CE routers. Between PE routers, BGP must therefore support the exchange of traditional IPv4 prefixes and the exchange of VPNv4 prefixes. A BGP session between PE router is consequently called an MP-BGP session. The RD has no special meaning or role in MPLS VPN architecture; its only function is to make overlapping IPv4 addresses globally unique. The RD value has a local significance on the router where it is configured in order to distinguish a FIB table per VPN routing table (VRF table).

Is The RD Enough? Simple VPN topologies require only one RD per customer, raising the possibility that the RD could serve as a VPN identifier. This design, however, would not allow implementation of more complex VPN topologies, such as when a customer site belongs to multiple VPNs, such as Management VPNs, Central Services VPNs, Hub&Spoken VPNs.

What Are Route-Targets (RTs)? RTs were introduced into the MPLS VPN architecture to support identifying a site that participates in more than one VPN. RTs are attributes that are attached to a VPNv4 BGP route to indicate its VPN membership. The extended BGP communities of routing updates are used to carry the RT of the update, thus identifying to which VPN the update belongs. Extended BGP communities are 64-bit values. The semantics of the extended BGP community are encoded in the high-order 16bits of the value, making those bits useful for a number of different applications, such as MPLS VPN RTs.

2

In an IP version 6 implementation, the theory is the same.

July 10


13

RTs: How Do They Work? MPLS VPN RTs are attached to a customer route at the moment that it is converted from an IPv4 route to a VPNv4 route by the PE router. The RTs attached to the route are called export RTs and are configured separately for each virtual routing table in a PE router. Export RTs identify a set of VPNs in which sites associated with the virtual routing table belong. When the VPNv4 routes are propagated to other PE routers, those routers need to select the routes to import into their virtual routing tables. This selection is based on import RTs. Each virtual routing table in a PE router can have a number of configured import RTs that identify the set of VPNs from which the virtual routing table is accepting routes.

How Have Complex VPNs Redefined The Meaning of VPNs? With the introduction of complex VPN topologies, the definition of a VPN has needed to be changed. A VPN is simply a collection of sites sharing common routing information. In traditional switched WAN terms (for example, in X.25 terminology), such a concept would be called a closed user group (CUG). In the classic VPN, all sites connected to a VPN shared a common routing view. In complex VPNs, however, a site can be part of more than one VPN. This results in differing routing requirements for sites that belong to a single VPN and those that belong to more than one VPN. These routing requirements have to be supported with multiple virtual routing tables on the PE routers. 





A Virtual routing table in a PE router can be used only for sites with identical connectivity requirements. Complex VPN topologies require more than one virtual routing table per VPN. As each virtual routing table requires a distinct RD value, the number of RDs in the MPLS VPN network increases.

How Is The Routing Between CE-PE and PE-PE? Outbound Propagation IGP speaking CE routers identify the correct instance of IGP on the PE router when an inbound PE interface is associated with a VRF. This association allows CE routers to announce their networks to the appropriate per-VRF routing table. MP-BGP is used in the MPLS VPN backbone to carry VPN routes (prefixed with the RD) as 96-bit VPNv4 routes between the PE routers. The backbone BGP process looks exactly like a standard iBGP setup from the perspective of the VRF. The per-VRF IGP routes therefore must be redistributed into the per-VRF instance of the BGP process to allow them to be propagated through the backbone MP-BGP process to other PE routers (see Figure 4).

Inbound Propagation The MP-iBGP routers, although they are inserted in the per-VRF IP routing table, are NOT propagated to IGP speaking CE routers automatically. To propagate these MP-iBGP routes to the IGP speaking CE routers, you must manually configure the redistribution between per-VRF instance of BGP and per-VRF instance of IGP (see Figure 5).

July 10


14

Figure 4 - Non BGP Route Propagation - Outbound

2

1 5

3

4

Figure 5 - Non BGP Route Propagation - Inbound

10

8 6

9

7

For troubleshooting we will follow these steps which are in detail in

July 10


15

What Is Multi-VRF CE (VRF-Lite)? Multi-VRF CE (VRF-lite) is an application based on VRF implementation. 

VRF-lite supports multiple overlapping and independent VRFs on the CE router.



There is no MPLS functionality on the CE router.



No label exchange between the CE and PE router.



No labelled packet flow between the CE and PE router.

What Are the Effects of MPLS VPNs on Packet Forwarding? 

The VPN label of the BGP route is understood only by the egress PE router.



An end-to-end LSP tunnel is required between the ingress and egress PE routers.



BGP next-hop addresses must be IGP routes.



-

LDP labels will be assigned to addresses in the global routing table.

-

LDP labels are not assigned to BGP routes (BGP routes receive VPN labels).

BGP next-hops announced in IGP must not be summarised in the core network.



Summarisation breaks the LSP tunnel.

Customers can use overlapping addresses.

For successful propagation of MPLS VPN packets access an MPLS backbone, there must be an unbroken LSP tunnel between PE routers. This is because the second label in the stack is recognised only by the egress PE router that has originated it, and will not be understood by any other router should it ever become exposed.

MTU issues One way of preventing labelled packets from exceeding the maximum size (and being fragmented as a result) is to increase the MTU size of labelled packets for all segments in the LSP tunnel. The problem will typically occur on LAN switches, where it is more likely that a device does not support oversized packets (also called jumbo frames or, sometimes, giants or baby giants). Some devices support jumbo frames, and some need to be configured to support them. The MPLS MTU size is increased automatically on WAN interfaces and needs to be increased manually on LAN interfaces. The MPLS MTU size has to be increased on all LSRs attached to a LAN segment. Additionally, the LAN switches used to implement switched LAN segments need to be configured to support jumbo frames. A different approach is needed if a LAN switch does not support jumbo frames. The problem may be even worse for networks that do not allow ICMP MTU discovery messages to be forwarded to sources of packets and if the Don‟t Fragment bit (DF bit) is strictly used. This situation can be encountered where firewalls are used.

http://www.cisco.com/en/US/products/hw/switches/ps700/products_configuration_example09186a008010 edab.shtml

July 10


16

MPLS Traffic Engineering Introduction The following section is by no means a comprehensive description of MPLS Traffic Engineering. Each of the topics covered therein try to give the reader a good high level view. Readers are encouraged to refer to the reference material for a complete discussion of the respective topic.

What is MPLS TE? Aside from being an acronym for Traffic Engineering, the concept of TE is essentially manipulating network traffic to fit the underlying network. The main objectives of TE are to choose paths for data traffic which are efficient and reliable while optimising network resources and traffic performance. Therefore TE will compute a path from a particular node to another given node such that the path does not violate any constraints (bandwidth/administrative requirements) and is optimal (note, this doesn‟t mean it is the lowest metric path, rather by some scalar metric). Once such a path is computed, TE is responsible for establishing and maintaining forwarding along this path. The Traffic Engineering addresses the key issues as follows: 

Fast Convergence for core link and core node failure.



Minimise network delay under fault conditions.



Maintain diverse paths between PE1 and PE2 routers.



Reduce the overall cost of operations by more efficient use of bandwidth resources.



Prevent a situation where some parts of a service provider network are over utilised (congested), while other parts remain under utilised.



Implement traffic protection against failures.



Enhance SLA in combination with QoS.

Why use MPLS TE? If we had unlimited bandwidth which resulted in no congestion, we wouldn‟t need MPLS TE, but the fact of the matter is that in reality networks have to consider MPLS TE for it: 

Optimises network utilisation.



Handles unexpected congestion.



Handles link and node failures, main reason for MPLS/TE deployment.

How does MPLS TE optimise network utilisation? MPLS is an integration of Layer 2 and Layer 3 technologies. By making traditional Layer 2 features available to Layer 3, MPLS enables traffic engineering. Thus, it can be offered in a network what now can be achieved only by overlaying a Layer 3 network on a Layer 2 network. MPLS traffic engineering automatically establishes and maintains LSPs across the backbone, using RSVP. The path used by a given LSP at any point in time is determined based on the LSP resource requirements and network resources, such as bandwidth.

July 10


17

MPLS TE is built on the following mechanisms: 

Tunnel interfaces.



An MPLS TE path calculation module.



RSVP with traffic engineering extensions.



An MPLS TE link management module.

How does MPLS TE handle unexpected congestion? One approach to engineer a backbone is to define a mesh of tunnels from every ingress device to every egress device. The MPLS TE path calculation and signalling modules determine the path taken by the LSPs for these tunnels, subject to resource availability and the dynamic state of the network. The IGP, operating at an ingress device, determines which traffic should go to which egress device, and steers that traffic into the tunnel from ingress to egress. Sometimes, a flow from an ingress device to egress device is so large that it cannot fit over a single link, so it cannot be carried by a single tunnel. In this case multiple tunnels between a given ingress and egress can be configured, and the flow is load shared among them.

How does MPLS TE handle unexpected link and node failures? Failures in the network happen, if they didn‟t then a lot of us would be out of a job. There are usually two kinds of failures in the network; link failures and node failures. When such failures occur in the network it is imperative to mitigate packet loss and disruption to users of the network. MPLS TE provides a mechanism known as Fast Reroute (FRR) or MPLS TE Protection to deal with fast recovery in such failure scenarios.

CBR (Constraint-Based Routing) In traditional networks, the IGP calculates paths through the network based on the network topology alone. Routing is destination-based, and all traffic to a given destination from a given source uses the same path through the network. That path is based simply on what the IGP regards as the “least cost” between the two points (source and destination). For Constraint-based routing (also referred as CSPF – Constrained Shortest Path First), either IS-IS or OSPF with extensions is used to carry resource information like available bandwidth on the link. Both linkstate protocols use new attributes to describe the nature of each link with respect to the constraints. It is calculated at the edge of a network, modified Dijkstra‟s algorithm at tu nnel headend. The output is a sequence of IP interface addresses (next-hop routers) between tunnel endpoints. However, this list of routers is known only to the router at the headend of the tunnel that is attempting to build the tunnel. Somehow, this now explicit path must be communicated to the intermediate routers. It is not up to the intermediate routers to make their own CSPF calculations: they merely abide by the path that is provided to them by the headend router. Therefore, some signalling protocol is required to confirm the path, to check and apply the bandwidth reservations, and finally to apply the MPLS labels to form the MPLS LSP through the routers. RSVP is used to confirm and reserve the path and apply the labels that identify the tunnel. LDP or TDP is used to apply the labels for underlying MPLS network. RSVP plays a significant role in path setup for LSP tunnels and supports both unicast and multicast applications.

July 10


18

Traditional RSVP The IETF specified RSVP as a signalling protocol for the INTSERV architecture. RSVP enables application to signal per-flow QoS requirements to the network. Service parameters are used to specifically quantify there requirements for admission control. RSVP signals resource reservation requests along the routed path available within the network. It does not perform its own routing; instead, it is designed to use the Internet‟s current robust routing protocols. Like other IP traffic, it depends on the underlying routing protocol to determine the path for both its data and its control traffic. The RSVP daemon in a router communicates with two local decision modules before making a resource reservation: 



Admission control: Determines whether the node has sufficient available resources to supply the requested QoS. Policy control: Determines whether the user has administrative permission to make the reservation. If either check fails, the RSVP daemon sends an error notification to the application process that originated the request.

The RSVP process can be broken down into five distinct steps: 









Data senders send RSVP PATH control messages the same way they send regular data traffic. There messages describe the data they are sending or intend to send. Each RSVP router intercepts the PATH messages, saves the previous hop IP address, writes its own address as the previous hop, and sends the updated message along the same route the application data is using. Receiver stations select a subset of the sessions for which they are receiving PATH information and request RSVP resource reservations from the previous hop router using an RSVP RESV message. The RSVP RESV messages going from a receiver to a sender takes an exact reserve path when compared to the path taken b y the RSVP PATH message. The RSVP routers determine whether they can honour those RESV requests. If they cannot, they refuse the reservations. If they can, they merge reservation requests being received and request a reservation from the previous hop router. The senders receive reservation requests from the next-hop routers indication that reservations are in place. Note that the actual r eservation allocation is made by the RESV messages.

The RSVP messages type used in the path setup is as following: 

Path: Messages run from Sender (Headend in case of TE) toward Receiver (Tail in case of T E).



Resv: Messages run from Receiver toward Sender.



PathTear: When call has finished this message is send to free up the resources on network.



ResvErr: When an error occurs during reservation task.



PathErr: When an error occurs related to Path discovering or failure.

July 10


19

RSVP-TE RSVP-TE extends the available RSVP protocol to support LSP path signalling. RSVP-TE uses RSVPs available signalling messages, making certain modifications to support TE. Some important extensions include the following: 









Label reservation support: To use RSVP for LSP tunnel signalling, RSVP needs to support label reservations and installation. Unlike normal RSVP flows, TE-RSVP uses RSVP for label reservations for flows without any bandwidth reservations. A new type of FlowSpec object is added for this purpose. TE-RSVP also manages labels to reserve labels for flows. Source routing support: LSP tunnels use explicit source routing. Explicit source routing is implemented in RSVP by introducing a new object, SRO. RSVP host support: In TE-RSVP. RSVP PATH and RESV messages are originated by the network head-end routers. This is unlike the original RSVP, in which RSVP PATH and RESV messages are generated by applications in end-hosts. Support for identification of the ER-LSP-based TE tunnel: New types of Filter_Spec and Sender_Template objects are used to carry the tunnel identifier. The Session Object is also allowed to carry a null IP protocol number because an LSP tunnel is likely to carry IP packets of many different protocol numbers. Support for new reservation removal algorithm: A new RSVP message, RESV Tear Confirm, is added. This message is added to reliably tear down an established TE tunnel.

A summary of the RSVP Objects that were added or modified to support TE is following: 

Label: It performs label distribution; carried by RESV message.



Label Request: It is used to request label allocation; carried by PATH message.



Source Route: It specifies the explicit source router; carried by P ATH message.



Record Route: It is used to record the path taken by the RSVP message; carried by PATH and RESV messages.



Session Attribute: It specifies the holding priority and setup priority; carried by PATH.



Session: It can carry a null IP pr otocol number; carried by PATH message.



Filter_Spec: It can carry a tunnel identifier to enable ER_LSP identification; carried by RESV message.

Fast Reroute (FRR) Fast Reroute (also called as MPLS TE Protection) is the MPLS TE ability to steer traffic away from the IGP-derived shortest path helps mitigate packet loss associated with link or node failures in the network. In an event path failed the headend reroutes calculating a new path for an LSP after its existing path goes down. However, during the time required to perform this basic reroute, there can be significant traffic loss; the packet loss is potentially worse than with regular IP routing if you are autorouting over the TE tunnel. This is because it is firstly needed to signal a new TE LSP through RSVP and run SPF for destinations that need to be routed over the tunnel. It is desirable to be able to deal with a link or node failure in a way that has less loss than the basic headend LSP reroute. Normally, when a link or node fails, this failure is signalled to the headends that had LSPs going through the failed link or node. The headends affected attempt to find new paths across the network for these tunnels. Local protection is the term used when the backup or protected tunnel is built to cover only a segment of the primary LSP. Local protection requires the backup LSP to be presignalled.

July 10


20

In local protection, the backup LSP is routed around a failed link (in link protection) or node (in node protection), and primary LSPs that would have gone through that failed link or node are instead encapsulated in the backup LSP. Note: “In a MPLS -TE tunnel configuration when there are multiple path-option statements under tunnel configuration, and a link/node failure causes headend to pick the next path option in the list; this action is not considered a protection. The reason is no backup resources are pre-computed or signalled before failure. Configuring multiple path options is merely a way to influence basic LSP rerouting. Unless the backup resources are signalled before any failure, there can be no fast protection.

Link failure is catered for using “N-Hop” backup tunnels, a backup tunnel that terminates on the router that is the “next-hop” from the router that is attached to the protected link. Node failure is catered for using “NN-Hop” (Next-Next-Hop) backup tunnels, which are tunnels that terminates on the routers “next -next-hop”. NN-Hop backup tunnels are preferred for protection over NHop tunnels if multiple backup tunnels exist on a protected interface. A point of Local Repair (PLR) is the point at which the failure is rerouted around and is also the head-end of a backup tunnel. A Merge Point (MP) is where the tail of the backup tunnel ter minates. A MP is 1-Hop away for Link Protection and 2-Hop away for Node Protection. (See Figure 6, Figure 7 and Figure 8 as examples).

Figure 6 - Primary Tunnel Path P1

Head End PE4

P2

Middle Points Point

P3

PE6

P30

PE5

P31

Tail End

P32

PE7



The path showed in Blue arrow indicates the primary tunnel path from PE4 toward PE7.



PE4 is the Head End.



PE7 is the Tail End.



P2, P3, and P32 are the Middle Points.

Figure 7 - Backup Tunnel - Node Protection P1

PE4

P2

Next-Next -Hop

P3

PE6

P32

PE7

P30

PE5

P31



The path showed in Red arrow indicates the backup tunnel which protects P2 failure.



P3 is the Merge point between primary and backup tunnel (for this case).

July 10


21

Figure 8 - Backup Tunnel - Link Protection Next-Hop

Link Protected

PE4

P1

P2

P3

PE6

P32

PE7

P30

PE5





P31

The path showed in Green arrow indicates the backup tunnel which protects link failure between PE4 and P2. P2 is the Merge point between primary and backup tunnel (for this case).

Auto Tunnel Mesh and Backup MPLS Traffic Engineering AutoTunnel Mesh Group allows a network administrator to configure traffic engineer (TE) label-switched paths (LSPs) by using a few command-line interface (CLI) commands. In a network topology where edge TE label switch routers (LSRs) are connected by core LSRs, the mesh group feature automatically constructs a mesh of TE LSPs among the PE routers.

Benefits of Autotunnel Mesh Group 



Minimise the initial configuration of the network. It is configured one template interface per mesh and it will be propagated to all mesh tunnel interfaces, as needed. Minimise future configurations resulting from network growth. The feature eliminates the need to reconfigure each existing TE LSR to establish a full mesh of TE LSPs whenever a new PE router is added to the network.



Enable existing routers to set up TE LSPs to new PE ro uters.



Enable the construction of a mesh of TE LSPs among the PE routers automatically.

July 10


22

AToM Introduction There is an ever-increasing demand for the transport of Layer-2 and Layer 3 over a common backbone. Any Transport over MPLS (AToM) allows an MPLS network to provide end-to-end transport for Layer 2 frames and cells. It provides support for Ethernet, PPP, HDCL, Frame Relay and ATM.

Why implement AToM? Initially, VPNs were built using leased lines. Later, service providers offered Layer 2 VPNs that were based on point-to-point data link layer connectivity, using ATM or Frame Relay virtual cir cuits. Customers built their own Layer 3 networks to accommodate IP traffic. To maintaining separate networks for Layer 2 VPNs and Internet traffic is difficult and costly. So service providers want a single IP-based network to provide both Layer 2 and Layer 3 services. AToM benefits service providers that offer Layer 2 connectivity to customers with traditional offerings such as ATM, Frame Relay, and serial or PPP services. Additionally, it serves providers who are specializing in Ethernet connectivity in metropolitan areas. Services for Layer 2 VPNs also appeal to the enterprise customers of service providers – customers who may already run many of these networks and want just point-to-point connectivity. The upgrade from a real Layer 2 ATM or Frame-Relay-based network to an MPLS-based network that provides the ATM or Frame Relay services by using AToM is transparent to customers. Unlike the Layer 3 IP-based VPNs using MPLS, the service provider does not participate in the Layer 3 routing of the customer. The service provider provides Layer 2 connectivity only.

Transport Types AToM enables the following types of Layer 2 frames and cells to be directed across an MPLS backbone: 

Ethernet and Ethernet VLAN.



ATM Adaptation Layer 5 (AAL5) and ATM Cell Relay.



Frame Relay: PVC-to-PVC mode (frame-relay switching has to be enabled) and port-to-port mode (uses encapsulation HDCL).



PPP.



HDLC.

MTU issues Unlike IP, most Layer 2 protocols do NOT allo w fragmentation of frames. This fact has two implications: 





AToM transport of Frame Relay, Ethernet, and AAL5 DOES NOT allow packets to be fragmented and reassembled. All intermediate links between the ingress PE router and the egress PE router must be able to carry the largest Layer 2 frame that has been received, including the imposed label stack and the 3 4-byte control word (if it is used). The ingress PE interface and the egress PE interface must have the same MTU value.

3

The control word is an optional 32bits fields. It is divided into four fields. The two of these field are used depend on which Layer 2 is encapsulated. July 10


23

How AToM works? AToM is used to forward Layer 2 frames. Frames are received on an ingress interface by the ingress PE router. At this point, the frame is a raw Layer 2 frame. The ingress PE router encapsulates it into MPLS and tunnels it across the backbone to the egress PE router. The egress PE router decapsulates the packet and reproduces the raw Layer 2 frame on the egress interface.

Label exchanging Figure 9 - AToM - Label exchanging

VC 17 21

22

23 pop

The IGP and LDP in combination are used to create an LSP from ingress PE router to egress PE router. The Figure 9 shows the label assignment and advertisement. The egress PE router advertises the pop level for its own loopback address. The backbone router that it closest to it advertises label value 23. The next router advertises value 22, and the last label advertisement shown is value 21. An LSP from ingress router to egress route is now established. The egress PE router now allocates a local label to be the VC label for the specific circuit in this example. It selects the label value 17 for this. The VC label is advertised to the ingress PE router using the directed LDP session between them. The ingress PE router now forms a label stack. The topmost label, the tunnel label, has the value 21 and is used to guide the packets to the egress PE router. The second label, the VC label, has the value 17 and is used by the egress PE router to propagate the packet out on the correct interface.

July 10


24

Frame Forwarding The ingress PE receives a Frame Relay frame on DLCI 101 on the incoming interface (Figure 10). The DLCI is mapped to the AToM tunnel across the backbone. The Frame Relay frame is therefore encapsulated into MPLS using the label stack with label 21 as the topmost level and label 17 as the second label. The packet is then forwarded along the LSP. The topmost label is used for label swapping in the next hop. The top label is changed to the value 22. In the next hop, label swapping results in label 23 being the top label. In the router just before the egress router, the incoming label value 23 indicates pop. That label therefore performs penultimate hop popping (PHP). The topmost label is removed, and the packet is propagated to the egress PE router with the label value 17, the VC label, which is now the only label left.

Figure 10 - AToM - frame forwarding

17 DLCI 101 17 21

17 22 17 23

17

17

DLCI 202

When the PE router receives the packet with label value 17, that label value instructs the PE router to deencapsulate the packet and send it out on the associated Frame Relay DCLI. In this case the DLCI value is 202. The Frame Relay frame i s now reconstructed and transmitted.

July 10


25

TM

Part 2: Troubleshooting Methodology

Essential MPLS/VPN configs MPLS LDP configuration In all routers in the core network the following tasks should be performed as the first thing: 

Turn on CEF.



Enable LDP protocol (either globally or per interface configuration mode).



Enable MPLS in all interfaces facing core (PE-P, and P-P) .

VRF configuration Only on PEs routers: 

Create a VRF name.



Assign RD to the VRF.



Specify export and import RT



Assign interface to VRF

MP-BGP On RR routers: 

Configure globally the MP-BGP neighbours (all PEs).



Active MP-BGP neighbours under address-family VPNv4.



Configure MP-BGP parameters (community propagation, route-reflector, …)

On PE routers: 

Configure globally the MP-BGP neighbours (Route-reflector).



Active MP-BGP neighbours under address-family VPNv4.



Configure MP-BGP parameters (community propagation, filtering, …)

PE-CE routing On PEs routers: 



Configuring PE-CE routing selecting VRF routing context. If BGP is not the protocol in used between PE-CE, you should enable redistribution in both direction between PE-CE routing protocol and BGP (under address family context in both routing protocols).

July 10


27

Essential TE configs MPLS TE tunnel configuration In all routers in the core network the following tasks should be performed before enabling MPLS-T E: 

Turn on MPLS tunnels.



Turn on CEF.



Turn on IS-IS or OSPF.

In all routers in the core network the following tasks should be performed to enable MPLS TE: 

Configuring a Device to Support T unnels.



Configuring and Interface to Support RSVP-based Tunnel Signalling and IGP flooding.



Configuring IS-IS for MPLS TE.

At Head-end tunnel the following tasks should be performed to create and use the MPLS TE tunnel: 

Configuring an MPLS TE Tunnel.



In case of Auto-tunnel an ACL should be created listing all IP destinations (Remote PEs).

Configuring an MPLS TE Tunnel to be used by an IGP.

MPLS TE FRR configuration In all routers in the core network the following tasks should be performed to pre-compute the backup tunnels. 

Enable MPLS-TE backup tunnel support.

-

In case of static interface tunnel configuration a backup interface should be created and a trigger should be configured on physical interface in order to activate the interface tunnel backup.

At Head-end tunnel the following task should be performed in order to enable FRR feature: 

In interface tunnel (or auto-template) enable fast-reroute feature.

July 10


28

Essential AToM configs On PE 

The PE routers must have a /32 address assigned to their loopbacks.



MPLS must be enabled in the core.



Make sure MTU is large enough in the core.



Enable layer 2 frame transport in both endpoint PE routers.



Make sure MTU is same on b oth endpoint interfaces.

July 10


29

TM

Part 3: Some MPLS Commands

ip cef mpls label protocol ldp

IP cef must be enabled for the router to be able to build the label database. It enables ldp to be used as a default label protocol on all interfaces which have mpls enabled. (Optional) By default, the mpls ip propagate-ttl command is enabled and the IP TTL value is copied to the MPLS TTL field during label imposition. Disabling TTL propagation of forwarded packets allows the structure of the MPLS network to be hidden from customers, but not the provider. (Optional) It specifies a preferred interface for determining the LSP router-id. When executed without the force keyword, the mpls ldp router-id command modifies the method for determining the LDP router ID by causing selection of the IP address of the specified interface argument (provided that the interface is operational) the next time it is necessary to select an LDP router ID. The effect of the command is delayed until the next time it is necessary to select an LDP router ID, which is t ypically the next time the interface whose address is the current LDP router ID is shut down or the address itself is not configured.

no tag-switching ip propagate-ttl forwarded

tag-switching tdp router-id loopback0

interface tag-switching ip

Interface configuration mode It enables mpls on interface applying the label protocol enabled in global configuration mode in it is not explicit specified under interface configuration mode.

ip vrf rd : route-target export :

It creates a VRF. It creates a local virtual routing and forwarding tables a VRF. It creates a BGP extended community. This specifies a set of prefixes should be imported in remote PEs. It specifies a set of prefixes based on extended community value should be imported to local VRF database. (Optional) It extends the criteria of prefixes, based on route-map configuration, which should have extra route-target communities to be imported in remote PEs. (Optional) It refines the selection on prefixes should be imported to local VRF based on route-map configuration. The prefixes should attend the routetarget import criteria and import-map criteria to be imported. The import map command does not replace the need for a route-target import in the VRF configuration. You use the import map command to further filter prefixes that match a route-target import statement in that VRF. (Optional) It limits the number of prefixes imported to local VRF.

route-target import : export-map

import-map

maximum route

July 10

Advanced Service

31

A printed copy of this document is considered uncontrolled.

interface ip vrf forwarding p

Interface configuration mode It enables mpls on interface applying the label protocol enabled in global configuration mode in it is not explicit specified under interface configuration mode. When an interface is assigned to a vrf the IP address configuration is removed. So, the ip address has to be re-configured after the ip vrf forwarding command performed.

ip address

MP-BGP configuration route bgp 25135 bgp always-compared-med no bgp default ipv4-unicast

bgp log-neighbor-changes

bgp deterministic-med

bgp bestpath med missing-as-worst

timers bgp 10 30

neighbor neighbor neighbor neighbor neighbor

peer-group remote-as password update-source loopback 0 peer-group

Create/enter BGP/MP-BGP processes It enables the comparison of MED for paths from neighbours in different autonomous systems. IPv4 address family routing information is advertised by default for each BGP routing session configured with the neighbour remote-as command, unless you first configure the no bgp default ipv4-unicast command before configuring the neighbour remote-as command. It enables logging of BGP neighbor status changes (up or down) and resets for troubleshooting network connectivity problems and measuring network stability. By default, Cisco IOS software does not enforce the deterministic comparison of the MED variable between all paths received from the same AS. In order to get the same result of the selection algorithm independently of the order the updates are received, this command should be enabled. By default, Cisco assigns a value of 0 to routes which didn‟t have MED attribute configured. In BGP algorithms when compares MED, the lower value is the best. To avoid missing MED to be considered the best path, we should enable this command to assigns the highest value. There is an issue here: some IOS releases use different values (CSCef34800). - 31S assigns a value of 4294967294 (IOS running in PEs) - 12.3 assigns a value of 4294967295 (IOS running in RRs) The first value defines the keepalive and the second value the hold-down timers. This is negotiating per TCP session; the timers to be used as a reference in BGP session will be the lowest configured between two BGP peers. It creates a peer-group (neighbour configuration template) It assigns the neigh bour‟s AS for neighbours assigned to this peer -group. It enables a MD-5 password It defined the IP source address in all BGP packet created by local router. It assigns a BGP neighbour to a peer-group template.

July 10


32

interface ip vrf forwarding p

Interface configuration mode It enables mpls on interface applying the label protocol enabled in global configuration mode in it is not explicit specified under interface configuration mode. When an interface is assigned to a vrf the IP address configuration is removed. So, the ip address has to be re-configured after the ip vrf forwarding command performed.

ip address

MP-BGP configuration route bgp 25135 bgp always-compared-med no bgp default ipv4-unicast

bgp log-neighbor-changes

bgp deterministic-med

bgp bestpath med missing-as-worst

timers bgp 10 30

neighbor neighbor neighbor neighbor neighbor

peer-group remote-as password update-source loopback 0 peer-group

Create/enter BGP/MP-BGP processes It enables the comparison of MED for paths from neighbours in different autonomous systems. IPv4 address family routing information is advertised by default for each BGP routing session configured with the neighbour remote-as command, unless you first configure the no bgp default ipv4-unicast command before configuring the neighbour remote-as command. It enables logging of BGP neighbor status changes (up or down) and resets for troubleshooting network connectivity problems and measuring network stability. By default, Cisco IOS software does not enforce the deterministic comparison of the MED variable between all paths received from the same AS. In order to get the same result of the selection algorithm independently of the order the updates are received, this command should be enabled. By default, Cisco assigns a value of 0 to routes which didn‟t have MED attribute configured. In BGP algorithms when compares MED, the lower value is the best. To avoid missing MED to be considered the best path, we should enable this command to assigns the highest value. There is an issue here: some IOS releases use different values (CSCef34800). - 31S assigns a value of 4294967294 (IOS running in PEs) - 12.3 assigns a value of 4294967295 (IOS running in RRs) The first value defines the keepalive and the second value the hold-down timers. This is negotiating per TCP session; the timers to be used as a reference in BGP session will be the lowest configured between two BGP peers. It creates a peer-group (neighbour configuration template) It assigns the neigh bour‟s AS for neighbours assigned to this peer -group. It enables a MD-5 password It defined the IP source address in all BGP packet created by local router. It assigns a BGP neighbour to a peer-group template.

July 10

Advanced Service

32


address-family vpnv4

neighbor activate neighbor send-community both neighbor advertisement-interval 0

neighbor route-reflector-client

neighbor peer-group

It defines the MP-BGP session. All commands related to MP-BGP session should be configured under this address-family. The BGP global is related only for TCP session. It activate the BGP session. It enables the local router to send the standard community and extended community (RT, SOO, OSPF information, and so on). By the default IOS software waits between 30 seconds for eBGP peering to sending BGP routing updates. For iBGP peering waits between 5 seconds to sending BGP routing. This command should be performed only in Route-reflectors in order to reflect all iBGP prefixes learn to other iBGP neighbours. This avoids the need of full mesh configuration. It assigns a BGP neighbour to a peer-group template.

PE-CE configuration ip route vrf router ospf vrf redistribute bgp 25135 subnets network area ... router bgp 25135 address-family ip vrf neighbor neighbor neighbor neighbor

remote-as update-source route-map [in|out] filter-list [in|out]

neighbor prefix-list [in|out] neighbor allowas-in <#>

redistribute [static|connected] redistribute ospf vrf match internal external1 external2 default-information originate

It defines a static route in a vrf context. It defines an OSPF configuration in a vrf context. You should redistribute BGP prefixes in order to local CE learns remote prefixes. Do NOT forget the keyword subnets, otherwise the subnetworks will not be redistributed, only classfull prefixes (such as 10.0.0.0/8). It defines a BGP configuration in a vrf context.

It defines an incoming or outgoing filter based on route-map configuration. It defines an incoming or outgoing filter based on as-path access-list configuration. It defines an incoming or outgoing filter based on prefix-list It allows the neighbour to readvertise prefixes containing duplicate AS numbers (information in AS-PATH attribute). The value specifies the number of times to allow the readvertisement. It is recommended in hub-spoken scenario. It redistributes the vrf prefixes into MP-BGP vrf database. It allows redistributing a default-route in routing table onto BGP database.

July 10


33

address-family vpnv4

neighbor activate neighbor send-community both neighbor advertisement-interval 0

neighbor route-reflector-client

neighbor peer-group

It defines the MP-BGP session. All commands related to MP-BGP session should be configured under this address-family. The BGP global is related only for TCP session. It activate the BGP session. It enables the local router to send the standard community and extended community (RT, SOO, OSPF information, and so on). By the default IOS software waits between 30 seconds for eBGP peering to sending BGP routing updates. For iBGP peering waits between 5 seconds to sending BGP routing. This command should be performed only in Route-reflectors in order to reflect all iBGP prefixes learn to other iBGP neighbours. This avoids the need of full mesh configuration. It assigns a BGP neighbour to a peer-group template.

PE-CE configuration ip route vrf router ospf vrf redistribute bgp 25135 subnets network area ... router bgp 25135 address-family ip vrf neighbor neighbor neighbor neighbor

remote-as update-source route-map [in|out] filter-list [in|out]

neighbor prefix-list [in|out] neighbor allowas-in <#>

redistribute [static|connected] redistribute ospf vrf match internal external1 external2 default-information originate

It defines a static route in a vrf context. It defines an OSPF configuration in a vrf context. You should redistribute BGP prefixes in order to local CE learns remote prefixes. Do NOT forget the keyword subnets, otherwise the subnetworks will not be redistributed, only classfull prefixes (such as 10.0.0.0/8). It defines a BGP configuration in a vrf context.

It defines an incoming or outgoing filter based on route-map configuration. It defines an incoming or outgoing filter based on as-path access-list configuration. It defines an incoming or outgoing filter based on prefix-list It allows the neighbour to readvertise prefixes containing duplicate AS numbers (information in AS-PATH attribute). The value specifies the number of times to allow the readvertisement. It is recommended in hub-spoken scenario. It redistributes the vrf prefixes into MP-BGP vrf database. It allows redistributing a default-route in routing table onto BGP database.

July 10

Advanced Service

33


maximum-path import 8

It specifies the number of redundant paths that can be configured as back up multipaths per a VRF prefix. A VRF will import only one path (the best path) per prefix from the source VRF table, unless the prefix is exported with a different route-target. If the best path goes down, the destination will not be reachable until the next import event occurs, and then a new best path will be i mported into the VRF table. The import event runs every 15 seconds by default. The import keyword allows to a VRF table to accept multiple redundant paths in addition to the best path. This feature should be used when there are multiple paths with identical next hops available to ensure optimal convergence times. A typical application of this configuration option is to configure redundant paths in a network that has multiple route reflectors for redundancy. P.S.: Note Configuring redundant paths with the import keyword can increase CPU and memory utilization significantly, especially in a network where there are many prefixes to learn and a large number of configured VRFs. It is recommended that this feature is only configured as necessary and that the minimum number of redundant paths is configured.

ip as-path access-list <#> [permit|deny] ... ip prefix-list [permit|deny]/{ge}{le} ...

route-map [permit|deny] match ... set ...

It defines a set of rules/selection based on BGP as-path attribute information. It defines a set of selection based on IP prefixes. Where: „Len‟ defines the bit-count to be compared against value (similar to wildcard in access-list). If neither „ge‟ nor „le‟ keywords are defined, “ len” also specifies the prefix mask. ge and le keywords defines the range of the mask. Ge specifies the minimum and le the maximum value for the mask. If “ge” is defined and “le” not, the maximum value is 32. If “le” is defined and “ge” not, the “len” defines the minimum value. It defines a set of rules/selection based on many values/attributes.

July 10


34

maximum-path import 8

It specifies the number of redundant paths that can be configured as back up multipaths per a VRF prefix. A VRF will import only one path (the best path) per prefix from the source VRF table, unless the prefix is exported with a different route-target. If the best path goes down, the destination will not be reachable until the next import event occurs, and then a new best path will be i mported into the VRF table. The import event runs every 15 seconds by default. The import keyword allows to a VRF table to accept multiple redundant paths in addition to the best path. This feature should be used when there are multiple paths with identical next hops available to ensure optimal convergence times. A typical application of this configuration option is to configure redundant paths in a network that has multiple route reflectors for redundancy. P.S.: Note Configuring redundant paths with the import keyword can increase CPU and memory utilization significantly, especially in a network where there are many prefixes to learn and a large number of configured VRFs. It is recommended that this feature is only configured as necessary and that the minimum number of redundant paths is configured.

ip as-path access-list <#> [permit|deny] ... ip prefix-list [permit|deny]/{ge}{le} ...

route-map [permit|deny] match ... set ...

It defines a set of rules/selection based on BGP as-path attribute information. It defines a set of selection based on IP prefixes. Where: „Len‟ defines the bit-count to be compared against value (similar to wildcard in access-list). If neither „ge‟ nor „le‟ keywords are defined, “ len” also specifies the prefix mask. ge and le keywords defines the range of the mask. Ge specifies the minimum and le the maximum value for the mask. If “ge” is defined and “le” not, the maximum value is 32. If “le” is defined and “ge” not, the “len” defines the minimum value. It defines a set of rules/selection based on many values/attributes.

July 10

Advanced Service

34


mpls traffic-eng tunnels mpls traffic-eng reoptimize timers frequency 3600

no mpls traffic-eng auto-bw timers frequency 0

mpls traffic-eng reoptimize events link-up no mpls traffic-eng topology holddown sigerr 0

mpls traffic-eng auto-tunnel mesh mpls traffic-eng auto-tunnel min 1 max 999 mpls traffic-eng auto-tunnel backup mpls traffic-eng auto-tunnel backup config unnumbered-interface loopback 0 mpls traffic-eng auto-tunnel backup timers removal unused 3600 3600

mpls traffic-eng auto-tunnel backup tunnel-num min 60000 max 64000

It enables MPLS traffic engineer tunnel on a device. (Optional) It controls the frequency with which tunnels with established LSPs are checked for better LSP. 3600 seconds is the default value. A value of 0 disables reoptimisation. (Optional) To control the frequency at which tunnels with established LSPs are checked for better LSPs, use this commands. A value of 0 disables reoptimisation. The default value is 3600 seconds (1 hour). (Optional) It turns on automatic reoptimisation of MPLS- TE when certain events occur, such as when an interface becomes operational. (P Routers only) When this feature is disabled, tunnel path calculations will ignore a link on which there is a traffic engineering error until either 10 seconds have elapsed or a topology update is received from the IGP. A router that is at the headend for TE tunnels might receive a RSVP No Route error message for an existing tunnel or for one being signalled due to the failure of a link the tunnel traverses before the router receives a topology update from the IGP routing protocol announcing that the link is down. In such a case, the headend router ignores the link in subsequent tunnel path calculations to avoid generating paths that include the link and are likely to fail when signalled. It enables autotunnel mesh group globally. (Optional) It configures a range of mesh primary tunnel interface numbers. Valid values are from 1 to 65535. It enables the capability of automatically building NHOP and NNHOP backup tunnels. (Optional) It enables IP processing without an explicit address. (Optional) It configures how frequently a timer will scan backup autotunnels and remove tunnels that are not being used. By default the t imer scans backup autotunnels and removes tunnels that are not being used is every 3600 seconds (60 minutes). (Optional) It configures the range of mesh secondary tunnel interface numbers. Valid values are from 1 to 65535.

July 10


35

mpls traffic-eng tunnels mpls traffic-eng reoptimize timers frequency 3600

no mpls traffic-eng auto-bw timers frequency 0

mpls traffic-eng reoptimize events link-up no mpls traffic-eng topology holddown sigerr 0

mpls traffic-eng auto-tunnel mesh mpls traffic-eng auto-tunnel min 1 max 999 mpls traffic-eng auto-tunnel backup mpls traffic-eng auto-tunnel backup config unnumbered-interface loopback 0 mpls traffic-eng auto-tunnel backup timers removal unused 3600 3600

mpls traffic-eng auto-tunnel backup tunnel-num min 60000 max 64000

It enables MPLS traffic engineer tunnel on a device. (Optional) It controls the frequency with which tunnels with established LSPs are checked for better LSP. 3600 seconds is the default value. A value of 0 disables reoptimisation. (Optional) To control the frequency at which tunnels with established LSPs are checked for better LSPs, use this commands. A value of 0 disables reoptimisation. The default value is 3600 seconds (1 hour). (Optional) It turns on automatic reoptimisation of MPLS- TE when certain events occur, such as when an interface becomes operational. (P Routers only) When this feature is disabled, tunnel path calculations will ignore a link on which there is a traffic engineering error until either 10 seconds have elapsed or a topology update is received from the IGP. A router that is at the headend for TE tunnels might receive a RSVP No Route error message for an existing tunnel or for one being signalled due to the failure of a link the tunnel traverses before the router receives a topology update from the IGP routing protocol announcing that the link is down. In such a case, the headend router ignores the link in subsequent tunnel path calculations to avoid generating paths that include the link and are likely to fail when signalled. It enables autotunnel mesh group globally. (Optional) It configures a range of mesh primary tunnel interface numbers. Valid values are from 1 to 65535. It enables the capability of automatically building NHOP and NNHOP backup tunnels. (Optional) It enables IP processing without an explicit address. (Optional) It configures how frequently a timer will scan backup autotunnels and remove tunnels that are not being used. By default the t imer scans backup autotunnels and removes tunnels that are not being used is every 3600 seconds (60 minutes). (Optional) It configures the range of mesh secondary tunnel interface numbers. Valid values are from 1 to 65535.

July 10

Advanced Service

35


interface mpls traffic-eng tunnels ip rsvp bandwidth 155000 155000

Interface configuration mode It enables MPLS traffic engineer on this interface. It enables RSVP for IP on an interface and specify amount of bandwidth to be reserved. The first value represents the total of bandwidth can be allocated by RSVP for this interface. The second value represents the max amount of bandwidth per flow (per tunnel) which can be allocated.

router isis is-type level-2-only metric-style wide

ISIS configuration mode It enable this router creates level-2 adjacency only (backbone). It configures a router to generate and accept only new-style TLVs (To enable to propagate TE information). It specifies the traffic engineering router identifier for the node to be the IP address associated with interface loopback0. It turns on MPLS traffic engineering for ISIS level-2 (backbone area).

mpls traffic-eng router-id Loopback0 mpls traffic-eng level-2 ip rsvp signalling initial-retransmit delay 760

ip rsvp signalling refresh reduction ack-delay 500 ip rsvp signalling refresh reduction

(Optional) It configures the minimum amount of time that a RSVP configured router waits for an ACK message before retransmitting the same message. The default value is 1000 ms (1.0 sec). If an ACK is not received for a state, the first retransmit occurs after the initial retransmit interval. If no ACK is received after the first retransmit, a second retransmit occurs. The message continues to be retransmitted, with the gap between successive retransmits being twice the previous interval, until an ACK is received. Then the message drops into normal refresh schedule if it needs to be refreshed (Path and Resv messages), or is processed (Error or Tear messages). If no ACK is received after five retransmits, the message is discarded as required. (Optional) It configures the maximum amount of time that a RSVP configured router holds on to an ACK message before sending it. (Optional) It enables RSVP refresh reduction. RSVP refresh reduction (RFC2961) is a set of extensions to reduce the messaging load imposed by RSVP and to help it scale to support larger numbers of flo ws. Refresh reduction requires the cooperation of the neighbour to operate; for this purpose, the neighbour must also support the standard. If the router detects that a directly connected neighbour is not supporting the refresh reduction standard, refresh reduction will not be used on this link irrespective of this command.

July 10


36

interface mpls traffic-eng tunnels ip rsvp bandwidth 155000 155000

Interface configuration mode It enables MPLS traffic engineer on this interface. It enables RSVP for IP on an interface and specify amount of bandwidth to be reserved. The first value represents the total of bandwidth can be allocated by RSVP for this interface. The second value represents the max amount of bandwidth per flow (per tunnel) which can be allocated.

router isis is-type level-2-only metric-style wide

ISIS configuration mode It enable this router creates level-2 adjacency only (backbone). It configures a router to generate and accept only new-style TLVs (To enable to propagate TE information). It specifies the traffic engineering router identifier for the node to be the IP address associated with interface loopback0. It turns on MPLS traffic engineering for ISIS level-2 (backbone area).

mpls traffic-eng router-id Loopback0 mpls traffic-eng level-2 ip rsvp signalling initial-retransmit delay 760

ip rsvp signalling refresh reduction ack-delay 500 ip rsvp signalling refresh reduction

(Optional) It configures the minimum amount of time that a RSVP configured router waits for an ACK message before retransmitting the same message. The default value is 1000 ms (1.0 sec). If an ACK is not received for a state, the first retransmit occurs after the initial retransmit interval. If no ACK is received after the first retransmit, a second retransmit occurs. The message continues to be retransmitted, with the gap between successive retransmits being twice the previous interval, until an ACK is received. Then the message drops into normal refresh schedule if it needs to be refreshed (Path and Resv messages), or is processed (Error or Tear messages). If no ACK is received after five retransmits, the message is discarded as required. (Optional) It configures the maximum amount of time that a RSVP configured router holds on to an ACK message before sending it. (Optional) It enables RSVP refresh reduction. RSVP refresh reduction (RFC2961) is a set of extensions to reduce the messaging load imposed by RSVP and to help it scale to support larger numbers of flo ws. Refresh reduction requires the cooperation of the neighbour to operate; for this purpose, the neighbour must also support the standard. If the router detects that a directly connected neighbour is not supporting the refresh reduction standard, refresh reduction will not be used on this link irrespective of this command.

July 10

Advanced Service

36


interface Auto-Template1 ip unnumbered Loopback0 tunnel destination access-list 41

tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng priority 4 4

tunnel mpls traffic-eng bandwidth 100 tunnel mpls traffic-eng path-option 1 dynamic

tunnel mpls traffic-eng record-route tunnel mpls traffic-eng fast-reroute tunnel mpls traffic-eng auto-bw collect-bw

tunnel mpls traffic-eng interface down delay 0

It creates a template interface. The interface number could be from the value of 1 to 25. It enables IP processing on an interface without assigning an explicit IP address to the interface. It specifies the access-list that the template interface uses for obtaining the mesh tunnel interface destination address (Remote PEs‟ loopback – one primary tunnel per destination IP address). The value argument is the number of the access-list. It sets the MPLS TE encapsulation mode for the tunnel interface. It specifies to send data traffic to this tunnel since the IP destination is the IP of Tail End or beyond of it. It configures the setup and reservation priority for an MPLS TE tunnel. The first value is the setup-priority; it is the priority used when an LSP is signalled for this tunnel and determines which existing tunnels can be preempted any LSP with a non-0 priority. The second value is the hold-priority, it is the priority associated with an LSP for this tunnel and determines if it should be pre -empted by other LSPs that are being signalled. Valid values are from 0 to 7, where a lower number indicates a higher priority. To configure bandwidth required for an MPLS traffic engineering tunnel. The default bandwidth required is 0. It configures a path option for an MPLS TE tunnel. The dynamic keyword specifies that the path of the LSP is dynamically calculated. Instead of dynamic keyword, the explicit keyword can be defined to specify an IP explicit path. The value 1 means the path-number argument which defines among others which value path should be used for this particular interface. The lower value is consider first to define the path. (Optional) If it is enabled on the headend LSR, the interface addresses for the LSP are included in the RRO object of the resv message. It enables an MPLS TE tunnel to use an established backup tunnel if there is a link or node failure. It configures a tunnel for automatic bandwidth adjustment and for control of the manner in which the bandwidth for a tunnel is adjusted. The collect-bw keyword collects output rate information for the tunnel, but does not adjust the tunnel‟s bandwidth. It forces a tunnel to go down as soon as the headend router detects that the label-switched path (LSP) is down.

July 10


37

interface Auto-Template1 ip unnumbered Loopback0 tunnel destination access-list 41

tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng priority 4 4

tunnel mpls traffic-eng bandwidth 100 tunnel mpls traffic-eng path-option 1 dynamic

tunnel mpls traffic-eng record-route tunnel mpls traffic-eng fast-reroute tunnel mpls traffic-eng auto-bw collect-bw

tunnel mpls traffic-eng interface down delay 0

It creates a template interface. The interface number could be from the value of 1 to 25. It enables IP processing on an interface without assigning an explicit IP address to the interface. It specifies the access-list that the template interface uses for obtaining the mesh tunnel interface destination address (Remote PEs‟ loopback – one primary tunnel per destination IP address). The value argument is the number of the access-list. It sets the MPLS TE encapsulation mode for the tunnel interface. It specifies to send data traffic to this tunnel since the IP destination is the IP of Tail End or beyond of it. It configures the setup and reservation priority for an MPLS TE tunnel. The first value is the setup-priority; it is the priority used when an LSP is signalled for this tunnel and determines which existing tunnels can be preempted any LSP with a non-0 priority. The second value is the hold-priority, it is the priority associated with an LSP for this tunnel and determines if it should be pre -empted by other LSPs that are being signalled. Valid values are from 0 to 7, where a lower number indicates a higher priority. To configure bandwidth required for an MPLS traffic engineering tunnel. The default bandwidth required is 0. It configures a path option for an MPLS TE tunnel. The dynamic keyword specifies that the path of the LSP is dynamically calculated. Instead of dynamic keyword, the explicit keyword can be defined to specify an IP explicit path. The value 1 means the path-number argument which defines among others which value path should be used for this particular interface. The lower value is consider first to define the path. (Optional) If it is enabled on the headend LSR, the interface addresses for the LSP are included in the RRO object of the resv message. It enables an MPLS TE tunnel to use an established backup tunnel if there is a link or node failure. It configures a tunnel for automatic bandwidth adjustment and for control of the manner in which the bandwidth for a tunnel is adjusted. The collect-bw keyword collects output rate information for the tunnel, but does not adjust the tunnel‟s bandwidth. It forces a tunnel to go down as soon as the headend router detects that the label-switched path (LSP) is down.

July 10

Advanced Service

37


AToM interface atm . point-to-point pvc / l2transport encapsulation aal0 xconnect encapsulation mpls

It creates a sub-interface It defines a PVC identification for this ATM circuit Defined the type of AAL layer on ATM, for this particular case uses AAL0 It defines the AToM circuit when the has to be same as configured on remote PE.

July 10


38

AToM interface atm . point-to-point pvc / l2transport encapsulation aal0 xconnect encapsulation mpls

It creates a sub-interface It defines a PVC identification for this ATM circuit Defined the type of AAL layer on ATM, for this particular case uses AAL0 It defines the AToM circuit when the has to be same as configured on remote PE.

July 10

Advanced Service

38


A Simplistic Topology to be used as an example for the Troubleshooting Figure 11 - Topology used in lab for capturing output

172.17.0.8

Loopback 0 Interfaces .1st host of sub-network /30 Links which do not have ISIS metric specified are using the default value (metric = 10)

172.17.7.83 6509-1 . s1/0

s0/0

. 172.17.0.4

s2/0

PE4 .s1/0

0 0 / 3 3 . 2 . 9 . 1 7 2 1

s1/0

.

s2/0. s1/0 s0/0

172.17.7.84

PE5

s0/0

s2/0

s0/0

RR2 s0/0 s0/0 172.19.29.8/30

P30

P31

/ 3 0 . 0 0 2 0 0 3 . 1 9 . 1 = 7 2 t r i c 1 e M

/ 3 0 2 . 0 3 1 s3/0 6 . . . 1 7 2 1

172.16.130.0/30 s0/0

s3/0 172.17.0.31 s1/0

.

0 / 3 0 . 3 6 . 6 1 . 7 2 1 s0/0

10.33.31.4/30

s1/0

6509-3 . s2/0

.s2/0 172.17.0.6 PE6 .

s1/0

172.17.0.9

. 172.17.0.30 s2/0

3 0 8 . / 5 . 3 9 . 1 7 2 1

172.17.8.51

172.17.0.3 .s3/0 P3 .s2/0

s1/0

/ 3 0 . 0 3 . 0 0 0 0 9 1 . 1 7 2 r i c = 1 t e M

3 0 0 / 1 . 0 0 3 . 0 9 . 1 = 1 7 2 r i c 1 e t M

0 / 3 3 . 0 1 . 9 . 1 7 2 1 s0/0

s0/0

s2/0

3 0 0 / 5 . 4 0 4 . 6 9 . 1 = 7 2 e t r i c 1 M

172.17.0.5

s3/0

.172.17.0.2 s3/0 . P2 s1/0 .

s0/0

s1/0

.

. / 3 0 . 0 s2/0 . 2 1 s1/0 9 . 1 . 7 2 1

0 / 3 0 . 2 4 . 9 1 . 7 2 1

s2/0

RR1 .s0/0

172.17.0.1 P1

/ 3 0 1 . 4 0 . 3 4 . 1 0

3 0 0 . / . 3 1 0 . 4 1 0

172.16.18.0/30

s1/0

.

172.19.131.0/30

s2/0

172.17.0.32 s3/0 . P32

/ 3 0 7 . 0 0 6 . 6 4 6 . 1 = 7 2 e t r i c 1 M

3 0 0 / 1 . 3 . 3 3 . 1 0

3 0 . / 7 0 s1/0 1 3 . 1 . 9 2 7 s0/0 172.17.0.7 1 s2/0

PE7 .

3 0 8 / 1 . 3 . 3 . 3 1 0 s0/0

10.40.31.8/30

s1/0

172.17.8.52

6509-2

6509-4

July 10


39

A Simplistic Topology to be used as an example for the Troubleshooting Figure 11 - Topology used in lab for capturing output

172.17.0.8

Loopback 0 Interfaces .1st host of sub-network /30 Links which do not have ISIS metric specified are using the default value (metric = 10)

172.17.7.83 6509-1 . s1/0

s0/0

. 172.17.0.4

s2/0

PE4 .s1/0

0. 0 / 3 s2/0 . 2 . 1 s1/0 . 1 . 9 7 2 1

0 / 3 4 . 0 2 . 9 1 . 7 2 1

s2/0

3 0 . 0 / 2 . 3 9 . 1 7 2 1

s1/0

s1/0 s0/0

172.17.7.84

PE5

s0/0

s2/0

s0/0

RR2 s0/0 s0/0 172.19.29.8/30

P31

/ 3 0 2 . 0 0 0 0 3 . 1 9 1 . = 7 2 t r i c 1 e M

/ 3 0 2 . 0 3 P30 s3/0 6 . 1 1 . . 7 2 1

172.16.130.0/30 s0/0

s3/0 172.17.0.31 s1/0

.

0 / 3 . 6 0 3 . 6 1 . 7 2 1

10.33.31.4/30

s1/0

6509-3 . s2/0

.s2/0 172.17.0.6

s0/0

PE6 .

s1/0

172.17.0.9

. 172.17.0.30 .

0 8 / 3 3 . 5 . 1 . 9 7 2 1

172.17.8.51

172.17.0.3 .s3/0 P3 .s2/0

s1/0

/ 3 0 0 . . 3 0 0 0 0 9 1 . 1 7 2 r i c = 1 t e M

3 0 0 / 1 . 0 0 3 . 9 0 1 . = 1 7 2 r i c 1 e t M

0 / 3 3 . 0 . 1 9 . 1 7 2 1 s0/0

s2/0

172.17.0.5

s3/0

s0/0

s2/0

3 0 0 / 5 . 4 0 4 . 6 9 1 . = 7 2 e t r i c 1 M

s2/0.

.

.172.17.0.2 s3/0 . P2 s1/0 .

s0/0

s1/0

RR1 .s0/0

172.17.0.1 P1

3 0 . 4 / . 3 1 0 4 . 1 0

3 0 0 / 1 . 3 . 0 4 . 1 0

172.16.18.0/30

s1/0

.

172.19.131.0/30

s2/0

172.17.0.32 s3/0 . P32

/ 3 0 7 . 0 0 . 6 6 4 6 . 1 = 7 2 t r i c 1 e M

3 0 . / 7 0 s1/0 3 1 . 1 9 2 . 172.17.0.7 7 s0/0 1

3 0 . 0 / 1 3 3 . . 3 1 0

3 0 . 8 / 3 1

PE7 .s2/0 . 3 3 . 1 0

s0/0

10.40.31.8/30

s1/0

172.17.8.52

6509-2

6509-4

July 10


TM

Part 4: List of Show Commands

39

TM

Part 4: List of Show Commands

Troubleshooting Summary Two troubleshooting domains: 



Control Plane 

Label Distribution (LDP/TDP/RSVP/BGP labels)



Label Information Base (LIB)

Forwarding Plane 

FIB-CEF for unlabeled packet (IP packets)



LFIB-MPLS forwarding table for labelled packets

MPLS and MPLS/VPN Troubleshooting MPLS/LPD checking show cef interface brief show mpls interface | i (Interface| ) show mpls ldp discovery show mpls ldp neighbor show mpls ldp bindings show mpls forwarding vrf show ip cef vrf

VRF checking show ip vrf show ip vrf interface show run | i ip vrf { }|^ rd |route-target|^ import|^ export show route-map show access-list [ <#> | ] show ip prefix-list show ip as-path-access-list <#> show ip community-list <#> show ip extcommunity-list <#>

CE-PE routing checking show ip protocol vrf show ip route vrf sh run | b address-family ipv4 vrf show ip route vrf [static|connected] show ip bgp vrf summary show ip bgp vrf neighbor show ip bgp vrf

July 10 A printed copy of this document is considered uncontrolled.

show ip bgp vrf show ip bgp vrf neighbor advertised-routes show ip bgp vrf neighbor routes show ip ospf int brief show ip ospf neighbor show ip ospf database show ip ospf database router

MP-BGP checking show ip bgp vpn all summary show ip bgp vpn all label show ip bgp vpn all show ip bgp vpn vrf show ip bgp vpn rd show ip bgp vpn vrf show ip bgp vpn rd show ip bgp vpn all dampening show ip bgp vpn all dampening [flat-stat| ] show ip bgp vrf all neighbor advertised-routes show ip bgp vrf all neighbor route sh run | i router bgp | address-family ipv4 vrf|redistribute|neighbor show route-map show access-list [ <#> | ] show ip prefix-list show ip as-path-access-list <#> show ip community-list <#>

Path verification ! On PEs ping mpls ipv4 / trace mpls ipv4 / ping vrf trace vrf

! On CEs and ping mpls ipv4 / trace mpls ipv4 /


MPLS/TE and FRR Troubleshooting Data Plane verification 1.

Identify the destination show ip route vrf show ip route show int | i rate|BW trace mpls traffic tunnel <#>

2.

Checking labels in Data Plane show ip cef vrf show ip cef

3.

Comparing labels with Control Plane information show ip rsvp reservation detail filter destination show ip bgp vpn vrf

Control Plane verification 1.

Checking the status of Interface tunnel show mpls traffic-eng auto-tunnel mesh | i show mpls traffic-eng auto-tunnel mesh | i show ip int bri | i Tunnel

2.

Checking if CEF is enabled in all Core routers (Ps and PEs). show mpls traffic-eng tunnels | i Explicit show ip int bri | i show ip interface | i switching

3.

Checking if MPLS, LDP and MPLS-TE are enabled in all Core routers. sh mpls int | i (Interface| )

4.

Checking if “MPLS traffic-eng” and “MPLS Traffic-eng auto-tunnel” are enabled in all Core routers (Ps and PEs). show mpls traffic-eng tunnels brief

5.

Check if ISIS is enabled on traffic-eng in all Core routers (Ps and PEs). 

Level-2 is enabled on Traffic-eng.



Metric wide enabled in Level-2 area.



All interfaces are enabled in Level-2 area.

sh clns protocol | i metrics sh clns interface sh isis mpls traffic-eng tunnel sh isis mpls traffic-eng adjacency-log


sh isis topology sh isis database .00-00 verbose sh isis mpls traffic-eng advertisements

6.

Check if RSVP is enabled on all interfaces facing Core routers (Ps and PEs). 

Check if the amount of Bandwidth enable on RSVP (Global and per flow) is enough for all TE Tunnels request.

sh ip rsvp interface [] sh ip rsvp neighbor sh ip rsvp installed [] sh ip rsvp installed detail [] | b Destination is sh ip rsvp reservation detail filter destination sh ip rsvp reser detail filter dst [source ] sh ip rsvp host [receivers|senders] sh ip rsvp reservation

7.

Check Head-End of the Tunnel the auto-te mplate interface (Only in Head-End). 

The Access-list selecting all remotes PE should be provided.



The “autoroute announce” should be enable.



The path-option should be valid.

sh mpls traffic-eng auto-tunnel mesh sh ip access sh mpls traffic-eng tunnel sh mpls traff topo igp-id isis .00 | b .00 sh mpls traffic-eng topology path sh mpls traffic-eng topology path destination sh mpls traffic-eng tunnels role [all|head|middle|remote|tail] sh mpls traffic-eng tunnels accounting sh mpls traffic-eng link-management bandwidth-allocation [] sh mpls traffic-eng link-management [admission-control|adverstisements] sh mpls traffic-eng link-management [igp-neighbors| int ]

8.

Check Fast-ReRoute. 

Check what is the backup tunnel create for a particular primary tunnel.



Check RSVP reservation.



Check interface tunnel details.

sh ip rsvp fast-reroute [bw-protect] sh ip rsvp fast [detail] filter [destination ] [source ] sh mpls traffic-eng tunnels protection sh mpls traffic-eng tunnels sh mpls traffic-eng fast-reroute database

In this next section will be presented the output commands and highlighting how to verify each item mentioned above.


AToM Troubleshooting show mpls l2transport vc show mpls l2transport vc detail show mpls l2transport summary


Troubleshooting commands In this section will be present the output commands. These outputs were extracted from the lab topology present in previous section. This will be the guide line what we should expect in normal operation.

MPLS and MPLS/VPN PE-4# show cef interface brief Interface

IP-Address

Status

Switching

Serial0/0

172.19.24.2

up

CEF

Serial1/0

172.19.45.1

up

CEF

Serial2/0

10.40.31.5

up

CEF

Null0

unassigned

up

no CEF

Loopback0

172.17.0.4

up

-

Loopback1

4.4.4.4

up

-

Auto-Template1

unassigned

up

-

OSPF_SL0

unassigned

down

-

Tunnel1

unassigned

up

CEF

Tunnel2

unassigned

up

CEF

Tunnel3

unassigned

up

CEF

Tunnel60000

unassigned

up

CEF

Tunnel60001

unassigned

up

CEF

Tunnel60002

unassigned

up

CEF

The first thing we have to check on MPLS network is if CEF is enabled in all interfaces facing core.

PE-4 #show mpls interf Interface

IP

Tunnel

Operational

Serial0/0

Yes (ldp)

Yes

Yes

Serial1/0

Yes (ldp)

Yes

Yes

Secondly we have to check if the right label protocol is enabled in all interfaces facing core. It most likely should be ldp protocol.

PE-4# sh mpl ldp discovery Local LDP Identifier: 172.17.0.4:0 Discovery Sources:

:0 means per platform allocation. (recommended mode of label allocation in frame-mode).

Interfaces:

Serial0/0 (ldp): xmit/recv LDP Id: 172.17.0.2:0 Serial1/0 (ldp): xmit/recv LDP Id: 172.17.0.5:0 It identifies neighbouring discover per interface.


PE-4# show mpl ldp neigh Peer LDP Ident: 172.17.0.5:0; Local LDP Ident 172.17.0.4:0 TCP connection: 172.17.0.5.54266 - 172.17.0.4.646 State: Oper; Msgs sent/rcvd: 4067/4059; Downstream Up time: 2d10h LDP discovery sources:

Serial1/0, Src IP addr: 172.19.45.2

Neighbour‟s Prefixes (all interfaces in global routing table).

Addresses bound to peer LDP Ident:

172.19.53.10

172.17.0.5

172.19.45.2

Peer LDP Ident: 172.17.0.2:0; Local LDP Ident 172.17.0.4:0 TCP connection: 172.17.0.2.646 - 172.17.0.4.42241 State: Oper; Msgs sent/rcvd: 4054/4069; Downstream Up time: 2d10h LDP discovery sources:

Serial0/0, Src IP addr: 172.19.24.1 Addresses bound to peer LDP Ident:

172.19.12.2

172.17.0.2

172.19.23.1

172.19.31.1

172.19.24.1 It shows TCP connection status between neighbors. PE-4# sh mpl ldp bindings tib entry: 172.16.18.0/30, rev 40 local binding:

tag: 30

remote binding: tsr: 172.17.0.2:0, tag: 28 remote binding: tsr: 172.17.0.5:0, tag: 40

This defines either 172.17.0.2 neighbour is the destionation of 172.17.0.2/32 prefix, or this neighbour is in MPLS border, beyond it it is an IP network only (edge LSR).

tib entry: 172.17.0.2/32, rev 8 local binding:

tag: 16

remote binding: tsr: 172.17.0.2:0, tag: imp-null remote binding: tsr: 172.17.0.5:0, tag: 26


tag: imp-null

172.17.0.4/32 is a Loopback 0 IP address, local ip address prefix, so PE-4 is sending a POP label flag to its neighbours.

remote binding: tsr: 172.17.0.5:0, tag: 16 remote binding: tsr: 172.17.0.2:0, tag: 25


tag: imp-null

remote binding: tsr: 172.17.0.5:0, tag: imp-null remote binding: tsr: 172.17.0.2:0, tag: 26 . . . [output omitted]

Label to be 172.19.45,0/30 is a serial address which connects PE-4 to 172.17.0.5 neighbor (PE-5), so it is a local ip address prefix to PE-4 and PE-5. Then, both are sending POP label flag to their neighbours.

It shows LIB (Label control plane database).

In the next page we will analyse in detail a global prefix in LIB, FIB and LFIB databases.


In frame-mode, labels are allocated independently, i.e. it is based on pr efixes in global routing table. These labels are advertised to all LDP neighbours. RIB has to be checked per prefix to identify the best path to populate LFIB. (It i s similar to what happens with RIP prefixes per example; not all paths learnt going to FIB, only the best information.) PE-4# sh mpl ldp bind 172.16.18.0 30 tib entry: 172.16.18.0/30, rev 40 local binding:

tag: 30

remote binding: tsr: 172.17.0.2:0, tag: 28 remote binding: tsr: 172.17.0.5:0, tag: 40 It shows the LIB (label control plane database). Checking RIB and/or FIB this is the best path to reach 172.17.18.0/30

PE-4# sh ip route 172.17.0.2 Routing entry for 172.17.0.2/32 Known via "isis", distance 115, metric 10, type level-2

Each neighbour advertises their own labels. In this case PE4 received two advertisements for 172.16.18.0/30 prefix.

Redistributing via isis Last update from 172.19.24.1 on Serial0/0, 2d11h ago Routing Descriptor Blocks: * 172.19.24.1, from 172.17.0.2, via Serial0/0 Route metric is 10, traffic share count is 1

To check 172.17.0.2 and 182.19.24.1 are prefixes from neighbour which discovered in s0/0 interface.

PE-4# sh ip route 172.16.18.0 Routing entry for 172.16.18.0/30 Known via "isis", distance 115, metric 30, type level-2 Redistributing via isis Last update from 172.19.24.1 on Serial0/0, 2d11h ago Routing Descriptor Blocks: * 172.19.24.1, from 172.17.0.1, via Serial0/0

These labels should match with the information provided in LIB, as showed above.

Route metric is 30, traffic share count is 1

It shows the RIB information (IP routing database).

PE-4# sh mpl forwarding-table 172.16.18.0 Local

Outgoing

Prefix

Bytes tag

Outgoing

tag

tag or VC

or Tunnel Id

switched

interface

30

28

172.16.18.0/30

0

Se0/0

Next Hop point2point

It shows the LFIB (label data plane database).

PE-4# sh ip cef 172.16.18.0 det 172.16.18.0/30, version 29, epoch 0, cached adjacency to Serial0/0 0 packets, 0 bytes tag information set, all rewrites owned local tag: 30 fast tag rewrite with Se0/0, point2point, tags imposed {28} via 172.19.24.1, Serial0/0, 0 dependencies next hop 172.19.24.1, Serial0/0 valid cached adjacency tag rewrite with Se0/0, point2point, tags imposed { 28}


Label to be imposed in label data packet going to serial 0/0 interface.

PE-4# sh mpl forwarding-table Local

Outgoing

Prefix

Bytes tag

Outgoing

Next Hop

tag

tag or VC

or Tunnel Id

switched

interface

16

Pop tag

172.17.0.2/32

0

Se0/0

point2point

17

Pop tag

172.19.12.0/30

0

Se0/0

point2point

26

31

172.17.0.32/32

0

Se0/0

point2point

35

Untagged [T] 172.16.67.0/30

0

Tu2

point2point

. . .

. . .

Aggregate

43

4.4.4.4/32[V]

0

44

26

172.16.132.0/30

0

Se0/0

point2point

45

29

172.16.130.0/30

0

Se0/0

point2point

46

38

172.17.0.30/32

0

Se0/0

point2point

47

56

172.19.29.80/30

0

Se0/0

point2point

48

57

172.17.0.9/32

0

Se0/0

point2point

49

0

l2ckt(100)

161019

none

point2point

. . .

Show mpls forwarding command outgoing label explanation 

Pop tag Remove the topmost label



Untagged Send as a standard IP packet



Aggregate Remove the label and do a FIB lookup (in general it is a vpn prefix, also indicated as [V] after the ipv4 prefix)



0 Explicit null (by default Cisco uses implicit null, to enable explicit null you have to use the “mpls ldp explicit-null” command in global configuration mode. This command is useful in MPLS QoS scenarios to implement “short pipe mode” architecture, i.e. the QoS implemented in Service Provides does not affect the QoS implemented on Customer network.).


Administrative AD Distance (AD).

In the next two pages we will analyse in detail two VRF prefixes in LIB, FIB and LFIB databases. PE-4# sh ip route vrf VPN

VRF prefixes leart via remote PE. (via MP-iBGP – AD=200).

[output omitted]

AD

5.0.0.0/32 is subnetted, 1 subnets

5.5.5.5 [200/100] via 172.17.0.5, 13:42:19

B

172.17.0.0/32 is subnetted, 4 subnets

172.17.8.84 [110/97] via 10.40.31.6, 02:36:04, Serial2/0

O

[output omitted]

PE-4# sh ip bgp vpn vrf VPN label Network

Next Hop

In label/Out label

VRF prefixes leart via local CE. (via CE-PE routing, in this case OSPF). If it were learnt via eBGP the AD would be 20.

Route Distinguisher: 25135:133001804 (VPN) 4.4.4.4/32

0.0.0.0

47/aggregate(VPN)

5.5.5.5/32

172.17.0.5

nolabel/47

172.17.0.5

nolabel/47

Path #1 [output omitted]

172.17.8.84/32 Path #2 Path #3

172.17.0.5

52/58

172.17.0.5

52/58

10.40.31.6

52/nolabel

Label learnt via MP-BGP, from MP-BGP neighbour.

Label allocated locally and advertise to all MP-BGP, neighbours.

Remember BGP is a distance vector protocol, only selects the best path per prefix to advertise to neighbour. Beside by default, it populates the FIB/LFIB using the best path only, unless maximum-path is being applied. PE-4# sh ip bgp vpn vrf VPN 172.17.8.84 BGP routing table entry for 25135:133001804:172.17.8.84/32, version 637111 Bestpath Modifiers: missing-med-worst, always-compare-med, deterministic-med Paths: (3 available, best #3, table VPN) Flag: 0x800 Advertised to update-groups:

Path #1

1 Local, imported path from 25135:133001805:172.17.8.84/32 172.17.0.5 (metric 620) from 172.17.0.8 (172.17.0.8) Origin incomplete, metric 49, localpref 100, valid, internal Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200 RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:5.5.5.5:512 Originator: 172.17.0.5, Cluster list: 0.0.0.1,

Path #2

mpls labels in/out 52/58 Local, imported path from 25135:133001805:172.17.8.84/32 172.17.0.5 (metric 620) from 172.17.0.9 (172.17.0.9) Origin incomplete, metric 49, localpref 100, valid, internal Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200 RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:5.5.5.5:512

Path #3

Originator: 172.17.0.5, Cluster list: 0.0.0.1, mpls labels in/out 52/58

Local

Best Path. Path to be adverstised and to populate the FIB/LFIB

10.40.31.6 (via VPN) from 0.0.0.0 (172.17.0.4) Origin incomplete,metric 97,localpref 100,weight 32768,valid, sourced, best Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200 RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:4.4.4.4:512, mpls labels in/out 52/nolabel July 10 A printed copy of this document is considered uncontrolled.

PE-4# sh ip cef vrf VPN 172.17.8.84 detail 172.17.8.84/32, version 14, epoch 0, cached adjacency to Serial2/0 0 packets, 0 bytes tag information set, all rewrites owned local tag: 52

Why it does not imposed labels?

via 10.40.31.6, Serial2/0, 0 dependencies next hop 10.40.31.6, Serial2/0 valid cached adjacency tag rewrite with Se2/0, point2point, tags imposed {}

PE-4# sh ip bgp vpn vrf VPN 5.5.5.5 BGP routing table entry for 25135:133001804:5.5.5.5/32, version 471214 Bestpath Modifiers: missing-med-worst, always-compare-med, deterministic-med

Path #1

Paths: (2 available, best #1, table VPN) Not advertised to any peer Local, imported path from 25135:133001805:5.5.5.5/32

172.17.0.5 (metric 620) from 172.17.0.8 (172.17.0.8) Origin IGP, metric 100, localpref 100, valid, internal, best Extended Community: RT:25135:18 RT:212.183.144.1:18

Path #2

Originator: 172.17.0.5, Cluster list: 0.0.0.1, mpls labels in/out nolabel/47 Local, imported path from 25135:133001805:5.5.5.5/32

Best Path. Path to be adverstised and to populate the FIB/LFIB

172.17.0.5 (metric 620) from 172.17.0.9 (172.17.0.9) Origin IGP, metric 100, localpref 100, valid, internal Extended Community: RT:25135:18 RT:212.183.144.1:18 Originator: 172.17.0.5, Cluster list: 0.0.0.1, mpls labels in/out nolabel/47

PE-4# sh ip cef vrf VPN 5.5.5.5 detail 5.5.5.5/32, version 31, epoch 0, cached adjacency to Tunnel1 0 packets, 0 bytes tag information set, all rewrites owned

Why it does imposed labels in this case?

local tag: VPN route head fast tag rewrite with Tu1, point2point, tags imposed {57 47} via 172.17.0.5, 0 dependencies, recursive next hop 172.17.0.5, Tunnel1 via 172.17.0.5/32 (Default) valid cached adjacency tag rewrite with Tu1, point2point, tags imposed {57 47}

VPN data packets go toward CEs which pass though out MPLS backbone will be imposed to labels. VPN data packets go toward CEs which goes to local CE will not have any labels imposed.

How do we know which label is which? Checking the BGP database, above we can confirm that 47 is vrf label allocated by MP-BGP. Then “57” label is LDP or MPLS/TE label (This checking will be explained in detail in MPLS/TE section). However from this output we can confirm the Tunnel 1 interface is the outgoing interface, which can indicate a MPLS/TE label.


PE-4# sh ip vrf Name

Default RD

VPN

Interfaces

25135:133001804

Lo1 Se2/0

It shows the vrf list created locally and what interfaces belong to vrf.

PE-4# sh ip vrf int Interface Protocol

IP-Address

VRF

Lo1

4.4.4.4

VPN

up

Se2/0

10.40.31.5

VPN

up

It shows which vrf each interface belongs to.

PE-4# sh run | i ip vrf VPN|^ rd |^ route-target|^ import|^ export|ip vrf ip vrf VPN rd 25135:133001804 route-target export 25135:18

„^‟ : means line which starts with once space following by route-target.

route-target export 212.183.144.1:18 route-target import 25135:18 route-target import 212.183.144.1:18

Using these filters, we can select only the IOS commands applied to vrf.

PE-4# sh route-map vpn route-map vpn, deny, sequence 10 Match clauses: ip address prefix-lists: vpn Set clauses: Policy routing matches: 0 packets, 0 bytes route-map vpn, permit, sequence 20 Match clauses: Set clauses: Policy routing matches: 0 packets, 0 bytes

PE-4# show ip prefix-list vpn ip prefix-list vpn: 4 entries seq 5 permit 4.4.4.4/32 seq 10 permit 5.5.5.5/32 seq 20 permit 7.7.7.7/32

PE-4# sh ip as-path-access-list 100

It selects BGP prefixes which in as-path attribute value starts with the AS value 25000. (This means the next AS hop to forward the path).

AS path access list 100 permit ^25000 permit ^$

It selects BGP prefixes which in as-path attribute is empty (This means only prefixes created in local-AS).

PE-4# sh ip extcommunity-list Extended community standard list 1 permit RT:1:1

It selects MP-BGP prefixes which RT value is 1:1 or 25135:133001804

permit RT:25135:133001804


PE-4# sh run | b address-family ipv4 vrf VPN address-family ipv4 vrf VPN redistribute ospf 1 vrf VPN maximum-paths import 4 no auto-summary no synchronization network 4.4.4.4 mask 255.255.255.255 route-map metric exit-address-family

PE-4# show ip route vrf VPN static PE-4#show ip route vrf VPN connect 4.0.0.0/32 is subnetted, 1 subnets C

4.4.4.4 is directly connected, Loopback1 10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks

C

10.40.31.4/30 is directly connected, Serial2/0

PE-7# sh ip bgp vpn vrf VPN sum BGP router identifier 172.17.0.7, local AS number 25135 BGP table version is 637020, main routing table version 637020 15 network entries using 1995 bytes of memory 43 path entries using 2924 bytes of memory 25/23 BGP path/bestpath attribute entries using 3300 bytes of memory 3 BGP rrinfo entries using 72 bytes of memory 1 BGP AS-PATH entries using 24 bytes of memory 5 BGP extended community entries using 264 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 8579 total bytes of memory

Any figures here means the BGP connection is being established. Active or Idle status means TCP connection issue.

BGP activity 37/4 prefixes, 100/21 paths, scan interval 15 secs Neighbor

V

10.33.31.10

4

AS MsgRcvd MsgSent

1

5537

7182

TblVer

636990

InQ OutQ Up/Down

0

0 15:22:00

State/PfxRcd

1

PE-7# sh ip bgp vpn vrf VPN neighbor 10.33.31.10 BGP neighbor is 10.33.31.10,

vrf VPN,

remote AS 1, external link

BGP version 4, remote router ID 172.17.8.52 BGP state = Established, up for 15:22:21 Last read 00:00:00, last write 00:00:00, hold time is 30, keepalive interval is 10 seconds Configured hold time is 30, keepalive interval is 10 seconds Minimum holdtime from neighbor is 0 seconds

Neighbor capabilities: Route refresh: advertised and received(new) Address family IPv4 Unicast: advertised and received [output omitted]


BGP capability been negotiated during Open sent and confirmed state.

PE-4# sho ip bgp vpn all BGP table version is 656741, local router ID is 172.17.0.4 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network

Next Hop

Metric LocPrf Weight Path

Route Distinguisher: 25135:133001804 (default for vrf VPN) *>i10.33.31.0/30

172.17.0.6

96

100

0 ?

* i

172.17.0.6

96

100

0 ?

* i

172.17.0.7

96

100

0 ?

* i

172.17.0.7

96

100

0 ?

[output omitted]

Route Distinguisher: 25135:133001805 *>i5.5.5.5/32

172.17.0.5

100

100

0 i

* i

172.17.0.5

100

100

0 i

*>i10.40.31.0/30

172.17.0.5

96

100

0 ?

* i

172.17.0.5

96

100

0 ?

RD created locally as there is a vrf assigned to it.

RD learnt from MPBGP neighbour as there is no vrf assigned to it.

[output omitted]

PE-7# sh ip bgp vpn vrf VPN neighbor 10.33.31.10 adv BGP table version is 640970, local router ID is 172.17.0.7 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network

Next Hop


Route Distinguisher: 25135:133001807 (default for vrf VPN) *> 10.33.31.0/30

10.33.31.10

96

32768 ?

*> 10.33.31.4/30

10.33.31.10

144

32768 ?

*> 10.33.31.8/30

0.0.0.0

0

32768 ?

*>i10.40.31.0/30

172.17.0.5

96

100

0 ?

*>i10.40.31.4/30

172.17.0.4

0

100

0 ?

*>i10.40.31.8/30

172.17.0.5

0

100

0 ?

*> 172.17.8.52/32

10.33.31.10

49

*>i172.17.8.84/32

172.17.0.5

49

32768 ? 100

0 ?

Total of prefixes adverstised to this neighbour

Total number of prefixes 8 PE-7# sh ip bgp vpn vrf VPN neighbor 10.33.31.10 route BGP table version is 640980, local router ID is 172.17.0.7 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network

Next Hop


Route Distinguisher: 25135:133001807 (default for vrf VPN) *> 10.33.31.0/24

10.33.31.10

0

Total number of prefixes 1


0 1 i

Total of prefixes learnt (and accept) from this neighbour.

CE-PE routing troubleshooting is the same way as traditional IP backbone. What has changed then? Only in PEs you have to add in the IOS show/debug commands the vrf i nformation in almost all commands.

PE-4# sh ip ospf int bri Interface

PID

Se2/0

1

Sl0

1

Area

IP Address/Mask

Cost

State Nbrs F/C

0

10.40.31.5/30

48

P2P

1/1

0

0.0.0.0/0

1

DOWN

0/0

PE-4# sh ip ospf neighbo Neighbor ID

Pri

State

172.17.8.83

0

FULL/

-

Dead Time

Address

Interface

00:00:38

10.40.31.6

Serial2/0

In P2P link we should expect FULL state. In broadcast link, if the local router is neither a DR nor BDR it could be 2-way

PE-4# sh ip ospf database LSA 1 (router links), we should expect one LSA per router in an Area. The Link ID is the router-id. In this case there are 4 routers in Area 0

OSPF Router with ID (4.4.4.4) (Process ID 1)

Router Link States (Area 0) Checksum Link count

Link ID

ADV Router

Age

Seq#

4.4.4.4

4.4.4.4

1354

0x80000074 0xA3C8

2

5.5.5.5

5.5.5.5

1991

0x80000076 0xED6B

2

172.17.8.83

172.17.8.83

34

0x80000075 0xCF4

5

172.17.8.84

172.17.8.84

1887

0x80000076 0x6C84

5

LSA 3 (summary Net links), we should expect one LSA per prefix which comes from another OSPF area. Link ID

Summary Net Link States (Area 0) ADV Router

Age

Seq#

4.4.4.4

1098

0x8000001D 0x15F4

5.5.5.5

726

0x8000001D 0xF60F

4.4.4.4

1618

0x8000001D 0xBFD

5.5.5.5

466

0x80000073 0x406E

4.4.4.4

1618

0x8000001D 0xE222

10.33.31.8

5.5.5.5

466

0x80000073 0x1892

172.17.8.51

4.4.4.4

1618

0x8000001D 0xC199LSA 5 (AS External links), we

172.17.8.51

5.5.5.5

466

0x80000073 0xF60Ashould expect one LSA per

172.17.8.52

4.4.4.4

1618

0x8000001D 0xB7A2prefix which comes from

172.17.8.52

5.5.5.5

466

0x80000073 0xEC13

10.33.31.3

Link-ID is the IP prefix 10.33.31.3 Adv Router is the ABR. 10.33.31.4

P.S.: Summary links DOES not mean OSPF prefixes10.33.31.4 10.33.31.8 summared.

Checksum

LSA 2 (network links), we this example there is not network link in area 0. If we have, it would be one per broadcast link. The Link ID is the DR‟s router-id.

another IP routing process (via redistribution command).

Type-5 AS External Link States

Link-ID is the IP prefix Adv Router is the ASBR.

Link ID

ADV Router

Age

Seq#

Checksum Tag

10.33.31.0

4.4.4.4

1100

0x8000001D 0xF42B

3489686063

10.33.31.0

5.5.5.5

728

0x8000001D 0xD645

3489686063

Link Count means the number of local links (local interfaces) the local router is advertising. One P2P interface is count as 2 local links.


PE-4# sh ip ospf database router 172.17.8.83 OSPF Router with ID (4.4.4.4) (Process ID 1) Router Link States (Area 0) LS age: 1080

Link type: There are 5 OSPF link types:

Options: (No TOS-capability, DC)

Stub Link Broadcast Link Point-to-Point Link Virtual Link Loopback Link All link type counts as one Link, except Point-to-Point links counts as t wo Links.

LS Type: Router Links Link State ID: 172.17.8.83 Advertising Router: 172.17.8.83 LS Seq Number: 80000075 Checksum: 0xCF4 Length: 84 Number of Links: 5

Link count #1

Link connected to: a Stub Network (Link ID) Network/subnet number: 172.17.8.83

This is a loopback interface.

(Link Data) Network Mask: 255.255.255.255 Number of TOS metrics: 0 TOS 0 Metrics: 1

Link count #2 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 172.17.8.84 (Link Data) Router Interface address: 10.40.31.1

These two links are aan P2P interface. interface

Number of TOS metrics: 0

Link count #3

TOS 0 Metrics: 48 Link connected to: a Stub Network (Link ID) Network/subnet number: 10.40.31.0 (Link Data) Network Mask: 255.255.255.252 Number of TOS metrics: 0 TOS 0 Metrics: 48

Link count #4 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 4.4.4.4 (Link Data) Router Interface address: 10.40.31.6 Number of TOS metrics: 0

Link count #5

TOS 0 Metrics: 48 Link connected to: a Stub Network (Link ID) Network/subnet number: 10.40.31.4

These two links are aan P2P interface. interface In OSPF the P2P interfaces (such as PPP and HDLC encapsulation) will be account as 2 links: one to represent the neighbour‟s ip address and another for sub-network and mask.

(Link Data) Network Mask: 255.255.255.252 Number of TOS metrics: 0 TOS 0 Metrics: 48

The router-id of the router which generated this LSA-1 is 172.17.8.83. and three ip address interfaces advertised: 2 serial point-to-point links and 1 loopback interface.


What are new in MPLS/VPN troubleshooting comparing to traditional IP Routing are MP-iBGP exchanges. We have to check the two-way redistribution under address-family between CE-PE routing and MP-BGP beside the IP VRF configuration if it is exporting and importing the right RDs. PE-4# sh ip bgp vpn all sum BGP router identifier 172.17.0.4, local AS number 25135 BGP table version is 673771, main routing table version 673771 34 network entries using 4522 bytes of memory 82 path entries using 5576 bytes of memory 24/23 BGP path/bestpath attribute entries using 3168 bytes of memory 3 BGP rrinfo entries using 72 bytes of memory 1 BGP AS-PATH entries using 24 bytes of memory 5 BGP extended community entries using 264 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 13626 total bytes of memory BGP activity 43/9 prefixes, 142/60 paths, scan interval 15 secs AS MsgRcvd MsgSent

TblVer

Total of VPNv4 prefixes received by this neighbour.

Neighbor

V

InQ OutQ Up/Down State/PfxRcd

172.17.0.8

4 25135

248264

77603

673771

0

0 2d17h

19

172.17.0.9

4 25135

248263

77602

673771

0

0 2d17h

19

Checking these 19 prefixes: PE-4# sh ip bgp vpn all neigh 172.17.0.8 route BGP table version is 674441, local router ID is 172.17.0.4 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network

Next Hop


Route Distinguisher: 25135:133001804 (default for vrf VPN) *>i5.5.5.5/32

172.17.0.5

100

100

0 i

*>i6.6.6.6/32

172.17.0.6

100

100

0 i

*>i7.7.7.7/32

172.17.0.7

100

100

0 i

*>i10.33.31.0/30

172.17.0.6

96

100

0 ?

* i

172.17.0.7

96

100

0 ?

*>i10.33.31.0/24

172.17.0.7

0

100

0 1 i

*>i10.33.31.4/30

172.17.0.6

0

100

0 ?

* i

172.17.0.7

144

100

0 ?

*>i10.33.31.8/30

172.17.0.7

0

100

0 ?

* i

172.17.0.6

144

100

0 ?

* i10.40.31.0/30

172.17.0.5

96

100

0 ?

* i10.40.31.4/30

172.17.0.5

144

100

0 ?

* i10.40.31.8/30

172.17.0.5

0

100

0 ?

*>i172.17.8.51/32

172.17.0.6

49

100

0 ?

* i

172.17.0.7

97

100

0 ?

*>i172.17.8.52/32

172.17.0.7

49

100

0 ?

* i

172.17.0.6

97

100

0 ?

* i172.17.8.83/32

172.17.0.5

97

100

0 ?

* i172.17.8.84/32

172.17.0.5

49

100

0 ?


From those 19 prefixes learnt from this neighbour these are what were imported onto VRF VPN.


172.17.0.5

100

100

0 i

*>i10.40.31.0/30

172.17.0.5

96

100

0 ?

*>i10.40.31.4/30

172.17.0.5

144

100

0 ?

*>i10.40.31.8/30

172.17.0.5

0

100

0 ?

*>i172.17.8.83/32

172.17.0.5

97

100

0 ?

*>i172.17.8.84/32

172.17.0.5

49

100

0 ?


172.17.0.6

100

100

0 i

*>i10.33.31.0/30

172.17.0.6

96

100

0 ?

*>i10.33.31.4/30

172.17.0.6

0

100

0 ?

*>i10.33.31.8/30

172.17.0.6

144

100

0 ?

*>i172.17.8.51/32

172.17.0.6

49

100

0 ?

*>i172.17.8.52/32

172.17.0.6

97

100

0 ?

These are the 19 VPNv4 prefixes learnt from the MPBGP


172.17.0.7

100

100

0 i

*>i10.33.31.0/30

172.17.0.7

96

100

0 ?

*>i10.33.31.0/24

172.17.0.7

0

100

0 1 i

*>i10.33.31.4/30

172.17.0.7

144

100

0 ?

*>i10.33.31.8/30

172.17.0.7

0

100

0 ?

*>i172.17.8.51/32

172.17.0.7

97

100

0 ?

*>i172.17.8.52/32

172.17.0.7

49

100

0 ?

Total number of prefixes 38

So, what is in “Route Distinguisher: 25135:133001804 (default for vrf VPN)” database, highlighted in red text? It is based on import criteria (route-target import and import map command applied under ip vrf configuration).

PE-4# sh ip bgp vpn all neigh 172.17.0.8 advertised-routes BGP table version is 677933, local router ID is 172.17.0.4 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network

Next Hop


Route Distinguisher: 25135:133001804 (default for vrf VPN)

*> 4.4.4.4/32

0.0.0.0

100

32768 i

*> 10.40.31.0/30

10.40.31.6

96

32768 ?

*> 10.40.31.4/30

0.0.0.0

0

32768 ?

*> 10.40.31.8/30

10.40.31.6

144

32768 ?

*> 172.17.8.83/32

10.40.31.6

49

32768 ?

*> 172.17.8.84/32

10.40.31.6

97

32768 ?

Total of VPNv4 prefixes advertised to this neighbour.

Total number of prefixes 6 Remember, BGP advertises ONLY the best path per each prefix. In case of the best path prefix been learnt via iBGP neighbour it will NOT be advertised to other iBGP neighbour (AS split-horizon rule), except in Route-reflector implementation. Only eBGP and local prefixes as best path will be advertised to iBGP neighbour.


Let‟s check if it neighbour is receiving and advertising the same set of prefixes. It should be the same if there aren‟t filters applied inbound direction (neighbour … filter | prefix -list | route-map commands).

RR1# sh ip bgp vpn all n 172.17.0.4 adv BGP table version is 227134, local router ID is 172.17.0.8 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network

Next Hop


Route Distinguisher: 25135:133001804

*>i4.4.4.4/32

172.17.0.4

100

100

0 i

*>i10.40.31.0/30

172.17.0.4

96

100

0 ?

*>i10.40.31.4/30

172.17.0.4

0

100

0 ?

*>i10.40.31.8/30

172.17.0.4

144

100

0 ?

*>i172.17.8.83/32

172.17.0.4

49

100

0 ?

*>i172.17.8.84/32

172.17.0.4

97

100

0 ?


172.17.0.5

100

100

0 i

*>i10.40.31.0/30

172.17.0.5

96

100

0 ?

*>i10.40.31.4/30

172.17.0.5

144

100

0 ?

*>i10.40.31.8/30

172.17.0.5

0

100

0 ?

*>i172.17.8.83/32

172.17.0.5

97

100

0 ?

*>i172.17.8.84/32

172.17.0.5

49

100

0 ?


172.17.0.6

100

100

0 i

*>i10.33.31.0/30

172.17.0.6

96

100

0 ?

Network

Next Hop


*>i10.33.31.4/30

172.17.0.6

0

100

0 ?

*>i10.33.31.8/30

172.17.0.6

144

100

0 ?

*>i172.17.8.51/32

172.17.0.6

49

100

0 ?

*>i172.17.8.52/32

172.17.0.6

97

100

0 ?

These are the same 19 VPNv4 prefixes which PE-4 learnt from RR1 (see output on previous page).


172.17.0.7

100

100

0 i

*>i10.33.31.0/30

172.17.0.7

96

100

0 ?

*>i10.33.31.0/24

172.17.0.7

0

100

0 1 i

*>i10.33.31.4/30

172.17.0.7

144

100

0 ?

*>i10.33.31.8/30

172.17.0.7

0

100

0 ?

*>i172.17.8.51/32

172.17.0.7

97

100

0 ?

*>i172.17.8.52/32

172.17.0.7

49

100

0 ?

Total number of prefixes 25 So, why 25 VPNv4 prefixes and not 19 VPNv4 prefixes (as seen 2 pages before – “PE-4# sh ip bgp vpn all” output)? The way the peer-group is configured in the RR, the RR creates only one BGP update packet and replaces the IP head (destination IP address) to send this same BGP payload information to all its neighbours which belongs to this peer-group. So, it‟s up to neighbour ignore their own updates (in case of PE-4 it is highlighted here in red text).


RR1# sh ip bgp vpn all n 172.17.0.4 route BGP table version is 226954, local router ID is 172.17.0.8 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Route Distinguisher: 25135:133001804

*>i4.4.4.4/32 *>i10.40.31.0/30 *>i10.40.31.4/30 *>i10.40.31.8/30 *>i172.17.8.83/32 *>i172.17.8.84/32

172.17.0.4 172.17.0.4 172.17.0.4 172.17.0.4 172.17.0.4 172.17.0.4


100 96 0 144 49 97

100 100 100 100 100 100

0 0 0 0 0 0

i ? ? ? ? ?

Total of VPNv4 prefixes received from this neighbour.

Total number of prefixes 6 Now, let analyse the last topic, BGP import prefixes. There are two steps: 



Import VPNv4 prefixes to BGP vrf database based on import RT. From BGP vrf database select the best path of IPv4 prefix to FIB vrf database. (Once the VPNv4 is imported to BGP vrf database the RD information is removed).

By default it is imported one only path per VPNv4 prefix onto BGP vrf and only one IPv4 path per prefix onto FIB vrf database. It can be defined as maximum-paths import 8 in same address-family vrfs. This means it can be imported onto BGP vrf database up to 8 paths per VPNv4 pref ix. Each PE advertises VPNv4 prefixes using unique RD and there are four route-reflectors to reflect the best VPNv4 prefixes to all remote PEs. Then, the maximum number of VPNv4 prefixes can be imported are up to 4 prefixes (one VPNv4 path per route-reflector). Remember, BGP peer advertises only the best path per VPNv4 prefix independently the maximum-path command. In this lab we have only two route-reflectors, so it can be imported up two VPNv4 prefixes onto BGP vrf database. The next output shows the full bgp database and an explanation where the prefixes come from on BGP vrf database. PE-4# sh ip bgp vpn all BGP table version is 694263, local router ID is 172.17.0.4 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 25135:133001804 (default for vrf VPN)

*> 4.4.4.4/32 *>i5.5.5.5/32 This prefix was * i *>i6.6.6.6/32 learn via RR2 and * i had a RD value 25135:133001806 *>i7.7.7.7/32 * i *>i10.33.31.0/30 * i * i * i *>i10.33.31.0/24 This prefix was * i learn via RR2 and *>i10.33.31.4/30 had a RD value * i 25135:133001807 * i * i

0.0.0.0 172.17.0.5 172.17.0.5 172.17.0.6 172.17.0.6 172.17.0.7 172.17.0.7 172.17.0.6 172.17.0.6 172.17.0.7 172.17.0.7 172.17.0.7 172.17.0.7 172.17.0.6 172.17.0.6 172.17.0.7 172.17.0.7

100 100 100 100 100 100 100 96 96 96 96 0 0 0 0 144 144

100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100


32768 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

i i i i i i i ? ? ? ? 1 i 1 i ? ? ? ?

This prefix was learn via RR1 and had a RD value 25135:133001806

This prefix was learn via RR1 and had a RD value 25135:133001807

*>i10.33.31.8/30 172.17.0.7 * i 172.17.0.7 * i 172.17.0.6 * i 172.17.0.6 *> 10.40.31.0/30 10.40.31.6 * i 172.17.0.5 * i 172.17.0.5 *> 10.40.31.4/30 0.0.0.0 * i 172.17.0.5 * i 172.17.0.5 * i10.40.31.8/30 172.17.0.5 * i 172.17.0.5 *> 10.40.31.6 *>i172.17.8.51/32 172.17.0.6 * i 172.17.0.6 * i 172.17.0.7 * i 172.17.0.7 * i172.17.8.52/32 172.17.0.7 *>i 172.17.0.7 * i 172.17.0.6 * i 172.17.0.6 *> 172.17.8.83/32 10.40.31.6 * i 172.17.0.5 * i 172.17.0.5 Textblue The bluetext are are * i172.17.8.84/32 172.17.0.5 prefixes the prefixes * i 172.17.0.5 10.40.31.6 advertised by RR1 *> Route Distinguisher: 25135:133001805 *>i5.5.5.5/32 172.17.0.5 * i 172.17.0.5 *>i10.40.31.0/30 172.17.0.5 * i 172.17.0.5 *>i10.40.31.4/30 172.17.0.5 * i 172.17.0.5 *>i10.40.31.8/30 172.17.0.5 * i 172.17.0.5 *>i172.17.8.83/32 172.17.0.5 * i 172.17.0.5 *>i172.17.8.84/32 172.17.0.5 * i 172.17.0.5 Route Distinguisher: 25135:133001806 *>i6.6.6.6/32 172.17.0.6 * i 172.17.0.6 *>i10.33.31.0/30 172.17.0.6 * i 172.17.0.6 *>i10.33.31.4/30 172.17.0.6 * i 172.17.0.6 *>i10.33.31.8/30 172.17.0.6 * i 172.17.0.6 *>i172.17.8.51/32 172.17.0.6 * i 172.17.0.6 *>i172.17.8.52/32 172.17.0.6 * i 172.17.0.6 Route Distinguisher: 25135:133001807 * i7.7.7.7/32 172.17.0.7 The green text are *>i 172.17.0.7 the prefixes * i10.33.31.0/30 172.17.0.7 advertised by RR2 *>i 172.17.0.7 *>i10.33.31.0/24 172.17.0.7 * i 172.17.0.7 * i10.33.31.4/30 172.17.0.7 *>i 172.17.0.7 * i10.33.31.8/30 172.17.0.7 *>i 172.17.0.7 * i172.17.8.51/32 172.17.0.7 *>i 172.17.0.7 * i172.17.8.52/32 172.17.0.7 *>i 172.17.0.7

0 0 144 144 96 96 96 0 144 144 0 0 144 49 49 97 97 49 49 97 97 49 97 97 49 49 97

100 100 100 100

0 0 0 0 32768 0 0 32768 0 0 0 0 32768 0 0 0 0 0 0 0 0 32768 0 0 0 0 32768

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

100 100 96 96 144 144 0 0 97 97 49 49

100 100 100 100 100 100 100 100 100 100 100 100

0 0 0 0 0 0 0 0 0 0 0 0

i i ? ? ? ? ? ? ? ? ? ?

100 100 96 96 0 0 144 144 49 49 97 97

100 100 100 100 100 100 100 100 100 100 100 100

0 0 0 0 0 0 0 0 0 0 0 0

i i ? ? ? ? ? ? ? ? ? ?

This Prefixes are from PE6‟s VPN vrf. They were exported with RT 25135:18 value.

100 100 96 96 0 0 144 144 0 0 97 97 49 49

100 100 100 100 100 100 100 100 100 100 100 100 100 100

0 0 0 0 0 0 0 0 0 0 0 0 0 0

i i ? ? 1 i 1 i ? ? ? ? ? ? ? ?


100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100



Where other prefixes in vrf VPN come from? They are generated locally (in PE-4) or they come from CEPE routing. If it is a non-BGP protocol it should be redistributed onto BGP. The local prefixes can be identified by the next-hop value, it should be 0.0.0.0. The CE-PE prefixes are identified by the next-hop information, which is OSPF neighbour ip address (10.40.31.6). It follows the OSPF prefixes: PE-4# sh ip route vrf VPN ospf Routing Table: VPN 172.17.0.0/32 is subnetted, 4 subnets O

172.17.8.84 [110/97] via 10.40.31.6, 06:20:14, Serial2/0

O

172.17.8.83 [110/49] via 10.40.31.6, 06:20:14, Serial2/0 10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks

O

10.40.31.8/30 [110/144] via 10.40.31.6, 06:20:14, Serial2/0

O

10.40.31.0/30 [110/96] via 10.40.31.6, 06:20:14, Serial2/0

PE-4# sh ip bgp vpn all 10.33.31.0/30 BGP routing table entry for 25135:133001804:10.33.31.0/30, version 706505 Bestpath Modifiers: missing-med-worst, always-compare-med, deterministic-med Paths: (4 available, best #1, table VPN) Flag: 0x800 Not advertised to any peer

Finally, this appointed out what is the path will be used on FIB vrf table.

Local, imported path from 25135:133001806:10.33.31.0/30 172.17.0.6 (metric 30) from 172.17.0.8 (172.17.0.8) Origin incomplete, metric 96, localpref 100, valid, internal, best Due to maximumpath import command we have here two paths imported for the same VPNv4 prefix 25135:133001806 :10.33.31.0/30

Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200 RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:6.6.6.6:512 Originator: 172.17.0.6, Cluster list: 0.0.0.1, mpls labels in/out nolabel/47 Local, imported path from 25135:133001806:10.33.31.0/30 172.17.0.6 (metric 30) from 172.17.0.9 (172.17.0.9) Origin incomplete, metric 96, localpref 100, valid, internal Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200 RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:6.6.6.6:512 Originator: 172.17.0.6, Cluster list: 0.0.0.1, mpls labels in/out nolabel/47 Local, imported path from 25135:133001807:10.33.31.0/30 172.17.0.7 (metric 630) from 172.17.0.8 (172.17.0.8) Origin incomplete, metric 96, localpref 100, valid, internal Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200

nd 2nd

of the 2 set VPNv4 VPN prefix.prefixes The blue text was learnt via routerreflector 1 (172.17.0.8) and the green text was learnt via router-reflector 2 (172.17.0.9)

RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:7.7.7.7:512 Originator: 172.17.0.7, Cluster list: 0.0.0.1, mpls labels in/out nolabel/48 Local, imported path from 25135:133001807:10.33.31.0/30 172.17.0.7 (metric 630) from 172.17.0.9 (172.17.0.9) Origin incomplete, metric 96, localpref 100, valid, internal Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200 RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:7.7.7.7:512 Originator: 172.17.0.7, Cluster list: 0.0.0.1, mpls labels in/out nolabel/48


RT value, reason why these prefixes were imported onto BGP vrf VPN table.

BGP routing table entry for 25135:133001806:10.33.31.0/30, version 706457

Bestpath Modifiers: missing-med-worst, always-compare-med, deterministic-med Paths: (2 available, best #1, no table) Flag: 0x800 Not advertised to any peer


Local 172.17.0.6 (metric 30) from 172.17.0.8 (172.17.0.8) Origin incomplete, metric 96, localpref 100, valid, internal, best Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200 RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:6.6.6.6:512 Originator: 172.17.0.6, Cluster list: 0.0.0.1, mpls labels in/out nolabel/47 Local 172.17.0.6 (metric 30) from 172.17.0.9 (172.17.0.9) Origin incomplete, metric 96, localpref 100, valid, internal Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200 RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:6.6.6.6:512 Originator: 172.17.0.6, Cluster list: 0.0.0.1, mpls labels in/out nolabel/47 BGP routing table entry for 25135:133001807:10.33.31.0/30, version 706467

Bestpath Modifiers: missing-med-worst, always-compare-med, deterministic-med Paths: (2 available, best #2, no table) Flag: 0x800 Not advertised to any peer

Local 172.17.0.7 (metric 630) from 172.17.0.8 (172.17.0.8) Origin incomplete, metric 96, localpref 100, valid, internal, best Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200 RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:7.7.7.7:512 Originator: 172.17.0.7, Cluster list: 0.0.0.1, mpls labels in/out nolabel/48 Local 172.17.0.7 (metric 630) from 172.17.0.9 (172.17.0.9) Origin incomplete, metric 96, localpref 100, valid, internal Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200 RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:7.7.7.7:512 Originator: 172.17.0.7, Cluster list: 0.0.0.1, mpls labels in/out nolabel/48 This Prefixes are from PE7‟s VPN vrf. They were exported with RT 25135:18 value.

PE-4# sh ip route vrf VPN 10.33.31.0 Routing entry for 10.33.31.0/30 Known via "bgp 25135", distance 200, metric 96, type internal

BGP next-hop (remote PE)

Redistributing via ospf 1 Advertised by ospf 1 metric 60 metric-type 1 subnets route-map vpn Last update from 172.17.0.6 20:32:11 ago Routing Descriptor Blocks: * 172.17.0.6 (Default-IP-Routing-Table), from 172.17.0.8, 20:32:11 ago Route metric is 96, traffic share count is 1 AS Hops 0, BGP network version 0


BGP neighbour which adversited this prefix (RR1).

MPLS/TE and FRR Identify the destination Step 1.

From a source PE identify the remote PE PE-4# sh ip route vrf VPN 172.17.8.52 Routing entry for 172.17.8.52/32 Known via "bgp 25135", distance 200, metric 49, type internal Redistributing via ospf 1 Advertised by ospf 1 metric 60 metric-type 1 subnets route-map vpn Last update from 172.17.0.7 1d23h ago Routing Descriptor Blocks: * 172.17.0.7 (Default-IP-Routing-Table), from 172.17.0.8, 1d23h ago Route metric is 49, traffic share count is 1 AS Hops 0, BGP network version 0

It shows what the destination PE is (BGP next-hop) based on an IP address generated from a Remote CE. PE-4# sh ip route 172.17.0.7 Routing entry for 172.17.0.7/32 Known via "isis", distance 115, metric 670, type level-2 Redistributing via isis Last update from 172.17.0.7 on Tunnel3, 23:12:02 ago Routing Descriptor Blocks: * 172.17.0.7, from 172.17.0.7, via Tunnel3 Route metric is 670, traffic share count is 1

The second look up in routing table is to identify what the r oute is to reach the BGP next-hop (remote PE). PE-4# sh int tun 3 | i rate|BW MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec, rely 255/255, load 1/255 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec

Step 2.

Checking the label stack in Data plane Database PE-4# sh ip cef vrf VPN 172.17.8.52

Label in the Top of “Label Stack” - MPLS/TE label Leart via RSVP

172.17.8.52/32, version 22, epoch 0, cached adjacency to Tunnel3 0 packets, 0 bytes tag information set, all rewrites owned local tag: VPN route head fast tag rewrite with Tu3, point2point, tags imposed { 58 50} via 172.17.0.7, 0 dependencies, recursive valid cached adjacency

Label in the Bottom of “Label Stack” MPLS/VPN laabel

tag rewrite with Tu3, point2point, tags imposed { 58 50}

Leart via MP-BGP

next hop 172.17.0.7, Tunnel3 via 172.17.0.7/32 (Default)


This packet will use two labels to cross the MPLS network, as shows above. This example is a VPN service using a MPLS/TE backbone, so it is needed at least two labels: one for VPN and another for MPLS/TE. How do we identify the labels? Which one is which? PE-4# sh ip cef 172.17.0.7 172.17.0.7/32, version 102, epoch 0, cached adjacency to Tunnel3 0 packets, 0 bytes tag information set, all rewrites owned

RSVP Label, learnt via RSVP neighbor

local tag: 22 fast tag rewrite with Tu3, point2point, tags imposed {58} via 172.17.0.7, Tunnel3, 4 dependencies next hop 172.17.0.7, Tunnel3 valid cached adjacency tag rewrite with Tu3, point2point, tags imposed {58}

With one of these two commands (above - in Control Plane, below in Dat a Plane) you can verify that “58” is the label for MPLS/TE.

Step 3.

Checking the labels in Control plane Database PE-4# sh ip rsvp reservation detail filter desti 172.17.0.7 Reservation: Tun Dest:

172.17.0.7

Tun Sender: 172.17.0.4

Tun ID: 3

Ext Tun ID: 172.17.0.4

LSP ID: 6053

Next Hop: 172.19.24.1 on Serial0/0

RSVP Label, learnt via RSVP neighbor

Label: 58 (outgoing) . . . [output omitted]

PE-4# sh ip bgp vpn vrf VPN 172.17.8.52 BGP routing table entry for 25135:133001804:172.17.8.52/32, version 509952 Bestpath Modifiers: missing-med-worst, always-compare-med, deterministic-med In MP-BGP database, you Paths: (4 available, best #1, table VPN) Flag: 0x800 Not advertised to any peer

have to look for what the preferential path is. It will be always identify with the keyword “best”

Local, imported path from 25135:133001807:172.17.8.52/32

172.17.0.7 (metric 670) from 172.17.0.8 (172.17.0.8) Origin incomplete, metric 49, localpref 100, valid, internal, best Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200 RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:7.7.7.7:512 Originator: 172.17.0.7, Cluster list: 0.0.0.1, mpls labels in/out nolabel/50 Local, imported path from 25135:133001807:172.17.8.52/32 172.17.0.7 (metric 670) from 172.17.0.9 (172.17.0.9)

MPLS/VPN Label, learnt via remote PE flooded via MP-BGP neighbour (routereflector)

Origin incomplete, metric 49, localpref 100, valid, internal Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200 RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:7.7.7.7:512 Originator: 172.17.0.7, Cluster list: 0.0.0.1, mpls labels in/out nolabel/50 . . . [output omitted]


Is the path taking the right route? Step 1.

Checking Interface Tunnel status PE-4# sh mpl traffic-eng auto-tunnel mesh Auto-Template1: Using access-list 41 to clone the following tunnel interfaces: Destination

Interface

-----------

---------

172.17.0.5

Tunnel1

172.17.0.6

Tunnel2

172.17.0.7

Tunnel3

Mesh tunnel interface numbers: min 1 max 999

It shows the primary tunnels created and identifies the tail-end for each primary tunnel created.

PE-4# sh mpl traffic-eng auto-tunnel mesh 172.17.0.7

Tunnel3

PE-4# sh mpl traffic-eng auto-tunnel mesh 172.17.0.7

| i 172.17.0.7

| i Tunnel3

Tunnel3

PE-4# sh ip int bri Interface Protocol

IP-Address

OK? Method Status

Serial0/0

172.19.24.2

YES NVRAM

up

up

Serial1/0

172.19.45.1

YES NVRAM

up

up

Serial2/0

10.40.31.5

YES NVRAM

up

up

Auto-Template1

172.17.0.4

YES unset

up

up

Loopback0

172.17.0.4

YES NVRAM

up

up

Loopback1

4.4.4.4

YES NVRAM

up

up

Tunnel1

172.17.0.4

YES unset

up

up

Tunnel2

172.17.0.4

YES unset

up

up

Tunnel3

172.17.0.4

YES unset

up

up

Tunnel60000

172.17.0.4

YES unset

up

up

Tunnel60001

172.17.0.4

YES unset

up

up

Tunnel60002

172.17.0.4

YES unset

up

up

Tunnel 1, Tunnel2 and Tunnel3 are primary tunnels. Tunnel60000, Tunnel60001 and Tunne60002 are backup tunnels.


PE-4# sh ip int bri | i Tunnel

Step 2.

Tunnel1

172.17.0.4

YES unset

up

up

Tunnel2

172.17.0.4

YES unset

up

up

Tunnel3

172.17.0.4

YES unset

up

up

Tunnel60000

172.17.0.4

YES unset

up

up

Tunnel60001

172.17.0.4

YES unset

up

up

Tunnel60002

172.17.0.4

YES unset

up

up

Tunnel60003

172.17.0.4

YES unset

up

up

Checking if CEF is enabled on a particular physical interface PE-4# sh mpl traffic-eng tu tu3 | i Explicit Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.2 Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.2

PE-4# sh ip int bri | i 172.19.24.2 Serial0/0

172.19.24.2

YES NVRAM

up

up

These two commands help you to identify the local physical exit interface for this interface Tunnel. The 4 first command you identify the next ip address (next hop ). In the second command, based on this ip address, you can identify what the local physical interface is.

PE-4# sh ip int s0/0 | i switching IP fast switching is enabled IP fast switching on the same interface is enabled IP Flow switching is disabled IP CEF switching is enabled IP CEF Fast switching turbo vector IP multicast fast switching is enabled IP multicast distributed fast switching is disabled

Check if CEF is enabled o n a physical interface.

Step 3.

Checking LDP and MPLS-TE are enabled on interfaces PE-4# sh mpl int Interface

IP

Tunnel

Operational

Serial0/0

Yes (ldp)

Yes

Yes

Serial1/0

Yes (ldp)

Yes

Yes

Both interfaces facing Core P routers are operational in both MPLS (LDP) and MPLS-TE.

PE-4# sh mpl int | i (Interface|Serial0/0) Interface

IP

Tunnel

Operational

Serial0/0

Yes (ldp)

Yes

Yes

4

Remember all subnet-network in the core (between Ps, PEs and P-PEs) are /30, then knowing the neighbour ip address, you will know the local ip address. July 10 A printed copy of this document is considered uncontrolled.

Checking if “MPLS traffic-eng” and “MPLS Traffic-eng auto-tunnel” are enabled in all PEs and Ps

Step 4.

PE-4# sh mpl traffic-eng tunnels brief Signalling Summary:

LSP Tunnels Process:

running

RSVP Process:

running

Forwarding:

enabled

auto-tunnel: backup Enabled

(4 ), id-range:60000-64000

onehop Disabled (0 ), id-range:65336-65435 mesh

Enabled

(3 ), id-range:1-999

Periodic reoptimization:

every 3600 seconds, next in 2546 seconds

Periodic FRR Promotion:

Not Running

Periodic auto-tunnel: backup notinuse scan:


Periodic auto-bw collection:


TUNNEL NAME STATE/PROT

DESTINATION

UP IF

DOWN IF

PE-4_t1

172.17.0.5

-

Se1/0

up/up

PE-4_t2

172.17.0.6

-

Se0/0

up/up

PE-4_t3

172.17.0.7

-

Se0/0

up/up

PE-4_t60000

172.17.0.5

-

Se0/0

up/up

PE-4_t60001

172.17.0.2

-

Se1/0

up/up

. . . [ output omitted ] Displayed 7 (of 7) heads, 18 (of 18) midpoints, 7 (of 7) tails

It shows MPLS-TE parameters.

Checking if “MPLS traffic-eng” and “MPLS Traffic-eng auto-tunnel” are enabled in all PEs and Ps

Step 5.

PE-4# sh clns int serial0/0 Serial0/0 is up, line protocol is up Checksums enabled, MTU 1500, Encapsulation HDLC ERPDUs enabled, min. interval 10 msec. CLNS fast switching enabled CLNS SSE switching disabled DEC compatibility mode OFF for this interface Next ESH/ISH in 1 seconds Routing Protocol: IS-IS Circuit Type: level-1-2 Interface number 0x1, local circuit ID 0x101 Neighbor System-ID: P2

Level-2 Metric: 10, Priority: 64, Circuit ID: PE-4.00 Level-2 IPv6 Metric: 10 Number of active level-2 adjacencies: 1, if state UP Next IS-IS Hello in 1 seconds if state UP

It verifies if a particular interface has ISIS enabled showing ISIS parameters. July 10 A printed copy of this document is considered uncontrolled.

PE-4# sh clns protocol | i metrics Generate narrow metrics: none Accept narrow metrics:

none

Generate wide metrics:

level-1-2

Accept wide metrics:

level-1-2

It verifies the metric style in use per ISIS level.

PE-4#sh isis mpls traffic-eng adjacency-log IS-IS MPLS TE log When

Neighbor ID

IP Address

Interface Status Level

3d05h

PE-5.00

172.19.45.2

Se1/0

Up

level-2

03:55:38

P2.00

172.19.24.1

Se0/0

Up

level-2

It verifies interfaces enabled in ISIS and ISIS neighbourship (MPLS-TE perspective) created through these interfaces.

PE-4# sh isis mpls traffic-eng tunnel System Id

Tunnel Name

BW Metric

Nexthop Nexthop

PE-5.00

Tunnel1

20000000

172.17.0.5

PE-6.00

Tunnel2

20000000

172.17.0.6

PE-7.00

Tunnel3

20000000

172.17.0.7

Metric

Mode

It shows the Head-End tunnels (primary tunnels).

PE-4# sh isis mpls traffic-eng downstream-tree PE-7 Level-2 System PE-7.00

with metric 630

It shows the total cost to reach this ISIS TE neighbour

PE-4#sh isis top IS-IS paths to level-2 routers System Id

Metric

Next-Hop

Interface

SNPA

P1

20

P2

Se0/0

*HDLC*

P2

10

P2

Se0/0

*HDLC*

P3

20

P2

Se0/0

*HDLC*

PE-4

--

PE-5

620

PE-5

Tu1

*MPLS TE-Tunnel*

PE-6

30

PE-6

Tu2

*MPLS TE-Tunnel*

PE-7

630

PE-7

Tu3

*MPLS TE-Tunnel*

RR1

30

P2

Se0/0

*HDLC*

RR2

630

P2

Se0/0

*HDLC*

P30

620

P2

Se0/0

*HDLC*

P31

610

P2

Se0/0

*HDLC*

P32

620

P2

Se0/0

*HDLC*


PE-4# sh isis data PE-4.00-00 verbo IS-IS Level-2 LSP PE-4.00-00 LSPID

LSP Seq Num

PE-4.00-00

* 0x00000018

Auth:

LSP Checksum

LSP Holdtime

ATT/P/OL

0x9B99

64183

0/0/0

Length: 17

Area Address: 10 NLPID:

0xCC

Hostname: PE-4 Router ID:

172.17.0.4

IP Address:

172.17.0.4

Metric: 10

IS-Extended P2.00

Affinity: 0x00000000 Interface IP Address: 172.19.24.2 Neighbor IP Address: 172.19.24.1 Physical BW: 2048 kbits/sec Reservable Global Pool BW: 155000 kbits/sec Global Pool BW Unreserved: [0]:

155000 kbits/sec, [1]:

155000 kbits/sec

[2]:

155000 kbits/sec, [3]:

155000 kbits/sec

[4]:

154998 kbits/sec, [5]:

154998 kbits/sec

[6]:

154998 kbits/sec, [7]:

154998 kbits/sec

Metric: 640

IS-Extended PE-5.00

Affinity: 0x00000000 Interface IP Address: 172.19.45.1 Neighbor IP Address: 172.19.45.2

These figures show the amount of Bandwidth available after reservation for this priority and lower. Because of “tunnel “tunnel mpls traffic-eng auto-bw collectbw” bw” command applied under interface tunnel configuration, Instead of reserving the maximum bandwidth (100Kbits) it is reserved the amount of the traffic rate being utilised per interface tunnel. PS.: high number means low priority.

Physical BW: 2048 kbits/sec Reservable Global Pool BW: 155000 kbits/sec Global Pool BW Unreserved: [0]:

155000 kbits/sec, [1]:

155000 kbits/sec

[2]:

155000 kbits/sec, [3]:

155000 kbits/sec

[4]:

155000 kbits/sec, [5]:

155000 kbits/sec

[6]:

155000 kbits/sec, [7]:

155000 kbits/sec

Metric: 0

IP 172.17.0.4/32

Metric: 10

IP 172.19.24.0/30

Metric: 640

IP 172.19.45.0/30

PE-4#sh isis mpl traffic-eng advertisements System ID: PE-4.00 Router ID: 172.17.0.4

Link Count: 2 Link[1] Neighbor System ID: P2.00 (P2P link) Interface IP address: 172.19.24.2 Neighbor IP Address: 172.19.24.1 Admin. Weight te: 10 igp: 10 Physical BW: 2048 kbits/sec Reservable Global Pool BW: 155000 kbits/sec Reservable Sub Pool BW: 0 kbits/sec Global Pool BW unreserved:


[0]: 155000 kbits/sec, [1]: 155000 kbits/sec [2]: 155000 kbits/sec, [3]: 155000 kbits/sec

[4]: 154998 kbits/sec, [5]: 154998 kbits/sec [6]: 154998 kbits/sec, [7]: 154998 kbits/sec Sub Pool BW unreserved: [0]: 0 kbits/sec, [1]: 0 kbits/sec [2]: 0 kbits/sec, [3]: 0 kbits/sec [4]: 0 kbits/sec, [5]: 0 kbits/sec [6]: 0 kbits/sec, [7]: 0 kbits/sec

These figures show the amount of Bandwidth available after reservation for this priority and lower.

Physical BW: 2048 kbits/sec

Because of “tunnel mpls traffic-eng auto-bw collectbw” command applied under interface tunnel configuration, Instead of reserving the maximum bandwidth (100Kbits) it is reserved the amount of the traffic rate being utilised per interface tunnel.

Reservable Global Pool BW: 155000 kbits/sec

PS.: high number means low priority.

Affinity Bits: 0x00000000

Link[2] Neighbor System ID: PE-5.00 (P2P link) Interface IP address: 172.19.45.1 Neighbor IP Address: 172.19.45.2 Admin. Weight te: 640 igp: 640

. . . [output omitted]

ISIS-LSP related to TE parameters generated locally.

PE-4# sh isis mpl traffic-eng advertisements System ID: PE-4.00 Router ID: 172.17.0.4 Link Count: 2

Link[1] Neighbor System ID: P2.00 (P2P link) Interface IP address: 172.19.24.2 Neighbor IP Address: 172.19.24.1 Admin. Weight te: 10 igp: 10 Physical BW: 2048 kbits/sec Reservable Global Pool BW: 155000 kbits/sec Reservable Sub Pool BW: 0 kbits/sec Global Pool BW unreserved: [0]: 155000 kbits/sec, [1]: 155000 kbits/sec [2]: 155000 kbits/sec, [3]: 155000 kbits/sec

[4]: 154700 kbits/sec, [5]: 154700 kbits/sec [6]: 154700 kbits/sec, [7]: 154700 kbits/sec Sub Pool BW unreserved: [0]: 0 kbits/sec, [1]: 0 kbits/sec [2]: 0 kbits/sec, [3]: 0 kbits/sec [4]: 0 kbits/sec, [5]: 0 kbits/sec [6]: 0 kbits/sec, [7]: 0 kbits/sec Affinity Bits: 0x00000000 . . . [output omitted]


These figures show the amount of Bandwidth available after reservation for this priority and lower. Results without “tunnel mpls traffic-eng auto-bw collectbw” command

Step 6.

Checking RSVP status PE-4# sh ip rsvp int interface

rsvp

allocated

i/f max

flow max sub max

Se0/0

ena

300K

155M

155M

0

Se1/0

ena

0

155M

155M

0

Tu60000

ena

0

0

0

0

Tu60001

ena

0

0

0

0

Tu60002

ena

0

0

0

0

Tu60003

ena

0

0

0

0

Tu60004

ena

0

0

0

0

This value (bandwidth to be considered in resource reservation – reservation – “ip rsvp bandwidth” interface command) should be always higher than the bandwidth configured on interface tunnel otherwise the reservation will fail for this physical interface.

Both interfaces facing Core P routers are operational for RSVP. Interface S0/0 shows there is 200K of bandwidth allocated, as all tunnels are requesting 100k of bandwidth, we can say there are three tunnels using this resource. PE-4# sh ip rsvp interface serial 0/0 interface

rsvp

allocated

i/f max

flow max sub max

Se0/0

ena

300K

155M

155M

0

PE-4# sh ip rsvp neighbor 172.19.24.1

RSVP

172.19.45.2

RSVP

Here we can identify which tunnels are using the physical resource.

It displays RSVP neighbour-ship created. PE-4# sh ip rsvp installed RSVP: Serial0/0 BPS

To

From

Protoc DPort

Sport

0

172.17.0.2

172.17.0.5

0

60003

1

1K

172.17.0.5

172.17.0.4

0

1

478

0

172.17.0.5

172.17.0.4

0

60000

8950

0

172.17.0.6

172.17.0.4

0

2

6911

0

172.17.0.7

172.17.0.4

0

3

6103

0

172.17.0.31

172.17.0.4

0

60001

8948

Figures due to tunnel mpls traffic-eng auto-bw collect-bw tunnel interface comm ommand and is is a lied. ied.

RSVP: Serial1/0 has no installed reservations RSVP: Tunnel60000 has no installed reservations . . . [ output omitted ]

Here we can identify which tunnels are using the physical resource.

PE-4# sh ip rsvp installed RSVP: Serial0/0 BPS

To

From

Protoc DPort

Sport

0

172.17.0.2

172.17.0.6

0

60001

7514

0

172.17.0.3

172.17.0.6

0

60000

7514

0

172.17.0.3

172.17.0.7

0

60001

7517

0

172.17.0.5

172.17.0.4

0

60000

168

100K

172.17.0.6

172.17.0.4

0

2

2518

0

172.17.0.6

172.17.0.7

0

60000

7523

0

172.17.0.6

172.17.0.32

0

60003

4687

100K

172.17.0.7

172.17.0.4

0

3

7463

. . . [ output omitted ]

It shows RSVP allocation per interface, per tunnel.


Case when “tunnel “tunnel mpls traffic-eng auto-bw collect-bw” tunnel interface command is NOT applied.

PE-4# sh ip rsvp installed | i (RSVP|100K) RSVP: Serial0/0 100K

172.17.0.6

172.17.0.4

0

2

2518

100K

172.17.0.7

172.17.0.4

0

3

7463

172.17.0.4

0

1

9437

RSVP: Serial1/0 100K

172.17.0.5

RSVP: Tunnel60000 has no installed reservations RSVP: Tunnel60001 has no installed reservations RSVP: Tunnel60002 has no installed reservations RSVP: Tunnel60003 has no installed reservations

PE-4# sh ip rsvp installed detail serial 0/0 | b Destination is 172.17.0.7 RSVP Reservation. Destination is 172.17.0.7. Source is 172.17.0.4, Protocol is 0

, Destination port is 3, Source port is 7168

Traffic Control ID handle: 0600044C Created: 18:46:21 UTC Sat Mar 17 2007 Admitted flowspec: Reserved bandwidth: 100K bits/sec, Maximum burst: 1K bytes, Peak rate: 100K bits/sec Min Policed Unit: 0 bytes, Max Pkt Size: 0 bytes Resource provider for this flow: None Conversation supports 1 reservations [0x100044D] Data given reserved service: 0 packets (0 bytes) Data given best-effort service: 0 packets (0 bytes) Reserved traffic classified for 1949 seconds Long-term average bitrate (bits/sec): 0 reserved, 0 best-effort Policy: INSTALL. Policy source(s): MPLS/TE Outstanding query. . . . [ output omitted ]

It shows all RSVP reservation information for a particular physical interface, starting from the MPLS TE tunnel which the IP destination is 172.17.0.7.

PE-4# sh ip rsvp reservation detail filter desti 172.17.0.7 Reservation: Tun Dest:

172.17.0.7


Tun ID: 3

Ext Tun ID: 172.17.0.4

LSP ID: 6107

Next Hop: 172.19.24.1 on Serial0/0

Label: 58 (outgoing) Reservation Style is Shared-Explicit, QoS Service is Controlled-Load Resv ID handle: 05000410. Created: 15:54:47 UTC Sat Mar 17 2007 Average Bitrate is 100K bits/sec, Maximum Burst is 1K bytes Min Policed Unit: 0 bytes, Max Pkt Size: 0 bytes RRO: 172.17.0.2/32, Flags:0x21 (Local Prot Avail/to NHOP, Node-id) Label subobject: Flags 0x1, C-Type 1, Label 58 172.19.23.1/32, Flags:0x1 (Local Prot Avail/to NHOP) Label subobject: Flags 0x1, C-Type 1, Label 58 172.17.0.3/32, Flags:0x29 (Local Prot Avail/to NNHOP, Node-id)


Label subobject: Flags 0x1, C-Type 1, Label 55 172.19.32.1/32, Flags:0x9 (Local Prot Avail/to NNHOP) Label subobject: Flags 0x1, C-Type 1, Label 55 172.17.0.32/32, Flags:0x21 (Local Prot Avail/to NHOP, Node-id) Label subobject: Flags 0x1, C-Type 1, Label 52 172.19.137.1/32, Flags:0x1 (Local Prot Avail/to NHOP) Label subobject: Flags 0x1, C-Type 1, Label 52 172.17.0.7/32, Flags:0x20 (No Local Protection, Node-id) Label subobject: Flags 0x1, C-Type 1, Label 0 172.19.137.2/32, Flags:0x0 (No Local Protection) Label subobject: Flags 0x1, C-Type 1, Label 0 Status: Policy: Accepted. Policy source(s): MPLS/TE

PE-4# sh ip rsvp reservation detail filter dst-port 3 source 172.17.0.4 Reservation: Tun Dest:

172.17.0.7


Tun ID: 3

Ext Tun ID: 172.17.0.4

LSP ID: 6107

Next Hop: 172.19.24.1 on Serial0/0 Label: 58 (outgoing) Reservation Style is Shared-Explicit, QoS Service is Controlled-Load Resv ID handle: 05000410. Created: 15:54:47 UTC Sat Mar 17 2007 Average Bitrate is 100K bits/sec, Maximum Burst is 1K bytes Min Policed Unit: 0 bytes, Max Pkt Size: 0 bytes RRO: 172.17.0.2/32, Flags:0x21 (Local Prot Avail/to NHOP, Node-id) Label subobject: Flags 0x1, C-Type 1, Label 58 172.19.23.1/32, Flags:0x1 (Local Prot Avail/to NHOP) Label subobject: Flags 0x1, C-Type 1, Label 58 172.17.0.3/32, Flags:0x29 (Local Prot Avail/to NNHOP, Node-id) Label subobject: Flags 0x1, C-Type 1, Label 55 172.19.32.1/32, Flags:0x9 (Local Prot Avail/to NNHOP) Label subobject: Flags 0x1, C-Type 1, Label 55 172.17.0.32/32, Flags:0x21 (Local Prot Avail/to NHOP, Node-id) Label subobject: Flags 0x1, C-Type 1, Label 52 172.19.137.1/32, Flags:0x1 (Local Prot Avail/to NHOP) Label subobject: Flags 0x1, C-Type 1, Label 52 172.17.0.7/32, Flags:0x20 (No Local Protection, Node-id) Label subobject: Flags 0x1, C-Type 1, Label 0 172.19.137.2/32, Flags:0x0 (No Local Protection) Label subobject: Flags 0x1, C-Type 1, Label 0 Status: Policy: Accepted. Policy source(s): MPLS/TE

In these last two commands, commands, you can chase the label from the source to the destination. destination. This LSP labels should be the same as showed in show mpls traffic tunnel command.


PE-4# sh ip rsvp host receivers To

From

Pro DPort Sport Next Hop

I/F

Fi Serv BPS

172.17.0.4

172.17.0.5

0

1

5507

none

none

SE LOAD 4K

0

1

7913

none

none

SE LOAD 0

0

1

4927

none

none

SE LOAD 0

0

60000 7495

none

none

SE LOAD 0

0

60000 7515

none

none

SE LOAD 0

0

60001 7496

none

none

SE LOAD 0

0

60003 4670

none

none

SE LOAD 0

Mode(s): Host LSP-Tunnel 172.17.0.4

172.17.0.6


172.17.0.7


172.17.0.2


172.17.0.5


172.17.0.3


172.17.0.31

Mode(s): Host LSP-Tunnel

List of Tunnels where PE4 is a tail End

PE-4# sh ip rsvp host senders To

From

Pro DPort Sport Prev Hop

I/F

BPS

172.17.0.2

172.17.0.4

0

60001 167

none

none

0

0

60002 167

none

none

0

0

1

none

none

100K

0

60000 168

none

none

0

0

2

2518

none

none

100K

0

3

7463

none

none

100K

0

60003 85

none

none

0


172.17.0.4


172.17.0.4

9437


172.17.0.4


172.17.0.4


172.17.0.4


172.17.0.4

Mode(s): Host LSP-Tunnel

List of Tunnels where PE4 is a Head End.

PE-4# sh ip rsvp reservation To

From

Pro DPort Sport Next Hop

I/F

Fi Serv BPS

172.17.0.2

172.17.0.4

0

60001 167

172.19.45.2

Se1/0

SE LOAD 0

172.17.0.2

172.17.0.6

0

60001 7514

172.19.24.1

Se0/0

SE LOAD 0

172.17.0.3

172.17.0.6

0

60000 7514

172.19.24.1

Se0/0

SE LOAD 0

172.17.0.3

172.17.0.7

0

60001 7517

172.19.24.1

Se0/0

SE LOAD 0

172.17.0.3

172.17.0.4

0

60002 167

172.19.45.2

Se1/0

SE LOAD 0

172.17.0.4

172.17.0.5

0

1

5507

none

none

SE LOAD 4K

172.17.0.4

172.17.0.6

0

1

7913

none

none

SE LOAD 0

172.17.0.4

172.17.0.7

0

1

4927

none

none

SE LOAD 0


It shows the Reservation Requests from Downstream.


PE-4# sh ip rsvp counters interface s1/0 Serial1/0

Recv

Path

Xmit

Recv

51

48

2

0

PathTear

47

56

ResvConf

0

0

17893

17881

Hello

0

0

IntegrityRespon

0

I_AM_DSBM

0

PathError

Ack

Resv

Xmit 94

96

0

13

26

27

0

0

17782

17784

IntegrityChalle

0

0

0

DSBM_WILLING

0

0

0

Errors

0

0

ResvError ResvTear RTearConf Srefresh

PE-4# sh ip rsvp counters summary All Interfaces

Recv

Path

Xmit

Recv

100

98

188

192

10

0

0

25

PathTear

105

114

44

36

ResvConf

0

0

0

0

35794

35795

35579

35579

Hello

0

0

IntegrityChalle

0

0

IntegrityRespon

0

0

DSBM_WILLING

0

0

I_AM_DSBM

0

0

Errors

0

0

Error Distribution

Recv

Xmit

Authentication

0

0

Other

0

0

PathError

Ack

Recv Msg Queues

Resv

ResvError ResvTear RTearConf Srefresh

Current

Max

RSVP

0

8

Hello (per-I/F)

0

0

Awaiting Authentication

0

0

If the network is stable these figures shouldn‟t increment.

Step 7.

Xmit

Checking Head End status PE-4# sh mpl traffic-eng auto-tunnel mesh Auto-Template1: Using access-list 41 to clone the following tunnel interfaces: Destination

Interface

-----------

---------

172.17.0.5

Tunnel1

172.17.0.6

Tunnel2

172.17.0.7

Tunnel3

Mesh tunnel interface numbers: min 1 max 999

Verify ACL number which area applied in auto-template. PE-4# sh ip access 41 Standard IP access list 41 permit 172.17.0.5 (1 match) permit 172.17.0.7 (1 match) permit 172.17.0.6 (1 match)

Verify ACL configuration. Make sure all destinations are listed in this ACL.


First check: Check if this is the destination you want to analyse. PE-4# sh mpl traffic-eng tunnels tunnel 1 Second check: Check the status (up up).

(Tunnel1) Destination: 172.17.0.5

Name: PE-4_t1 Status:

Admin: up

Oper: up

Path: valid

Signalling: connected

path option 1, type dynamic (Basis for Setup, path weight 1040) Third check: Check if the path is valid.

Config Parameters:

Bandwidth: 100

kbps (Global)

Priority: 4

4

Affinity: 0x0/0xFFFF

Metric Type: TE (default) AutoRoute:

enabled

LockDown: disabled

auto-bw: (86400/82153) 2

Loadshare: 100

bw-based

Bandwidth Requested: 100

Active Path Option Parameters: State: dynamic path option 1 is active BandwidthOverride: disabled InLabel

:

Last check: Verbatim: disabled Check outLabel to track the LSP (also the FRR information such as Interface number

LockDown: disabled

-

OutLabel : Serial0/0, 51 FRR OutLabel : Tunnel60002, 59 RSVP Signalling Info:

Fourth check: Check if this is expected path (confirm checking the topology).

Src 172.17.0.4, Dst 172.17.0.5, Tun_Id 1, Tun_Instance 9719 RSVP Path Info: My Address: 172.17.0.4

Explicit Route: 172.19.24.1 172.19.12.1 172.19.30.2 172.16.130.2 172.19.53.10 172.17.0.5 Record

Route:

NONE

Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits RSVP Resv Info: Record

Route:

172.17.0.2(51) 172.17.0.1(59)

Fifth check: LSP labels end-to-end.

172.17.0.30(55) 172.17.0.31(43) 172.17.0.5(0) Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits Shortest Unconstrained Path Info: Path Weight: 640 (TE) Explicit Route: 172.19.45.2 172.17.0.5 History: Tunnel:

Time since created: 1 hours, 9 minutes

Additional check: Check how long this tunnel is operational and the last path changed.

Time since path change: 1 hours, 9 minutes Number of LSP IDs (Tun_Instances) used: 2 Current LSP: Uptime: 1 hours, 9 minutes

It shows if the tunnel is operational, if it is protected, the backup tunnel interface, the path selected dynamically. Also the LSP label a long the path (from the source to destination). Note the priority for primary tunnel is 4 4, as it is configured. The priority of backup tunnel is 7 7 (lowest priority). Another difference between primary and backup tunnels is the bandwidth request (100kbps for primary tunnels as configured, and 0kbps for backup tunnels).


PE-4# sh mpls traf topo igp-id isis 0000.0000.0004.00 | b 0000.0000.0002.00 link[0]: Point-to-Point, Nbr IGP Id: 0000.0000.0002.00, nbr_node_id:3, gen:39 frag_id 0, Intf Address:172.19.24.2, Nbr Intf Address:172.19.24.1 TE metric:10, IGP metric:10, attribute_flags:0x0 SRLGs: None physical_bw: 2048 (kbps), max_reservable_bw_global: 155000 (kbps) max_reservable_bw_sub: 0 (kbps) Global Pool

Sub Pool

Total Allocated

Reservable

Reservable

BW (kbps)

BW (kbps)

BW (kbps)

---------------

-----------

----------

bw[0]:

0

155000

bw[1]:

0

155000

bw[2]:

0

155000

Bandwidth available after 0 reservation for this priority and lower. 0

bw[3]:

0

155000

0 PS.: high number means low priority.

bw[4]:

300

0

154700

0

bw[5]:

0

154700

0

bw[6]:

0

154700

0

bw[7]:

0

154700

0


It shows the bandwidth reservation per interface, per priority. PE-4# show mpls traffic-eng topology path tunnel 2 Query Parameters: Destination: 172.17.0.7 Bandwidth: 100

Priorities: 4 (setup), 4 (hold) Affinity: 0x0 (value), 0xFFFF (mask) Query Results: Min Bandwidth Along Path: 154800 (kbps) Max Bandwidth Along Path: 154900 (kbps) Hop

0: 172.19.45.1

: affinity 00000000, bandwidth 154900 (kbps)

Hop

1: 172.19.53.10


Hop

2: 172.19.131.1


Hop

3: 172.19.137.1


Hop

4: 172.17.0.7

It shows the path to reach the Tail end. In this case PE4



PE5  P31



P32  PE7

PE-4# sh mpl traffic-eng topology path destination 172.17.0.7 Query Parameters: Destination: 172.17.0.7 Bandwidth: 0

Priorities: 0 (setup), 0 (hold) Affinity: 0x0 (value), 0xFFFFFFFF (mask) Query Results: Min Bandwidth Along Path: 155000 (kbps) Max Bandwidth Along Path: 155000 (kbps)

Hop 0: 172.19.24.2


Hop 1: 172.19.23.1


Hop 2: 172.16.36.1


Hop 3: 172.16.67.1



Hop 4: 172.17.0.7 PE-4# show mpls traffic-eng autoroute MPLS TE autorouting enabled destination 0000.0000.0005.00, area isis

Tunnel1

level-2, has 1 tunnels

(load balancing metric 20000000, nexthop 172.17.0.5) (flags: Announce)

destination 0000.0000.0006.00, area isis

Tunnel3



destination 0000.0000.0007.00, area isis

Tunnel2



It shows tunnels that are announced to IGP, including interface, destination, and bandwidth. It refers primary tunnels. PE-4# sh mpl traffic-eng tunnels statistics Tunnel1 (Destination 172.17.0.5; Name PE-4_t1) Management statistics: Path:

0 no path, 0 path no longer valid, 0 missing ip exp path 2 path changes 0 loose path reoptimizations, triggered by PathErrors

State:

1 transitions, 0 admin down, 0 oper down

Signalling statistics: Opens:

2 succeeded, 0 timed out, 0 bad path spec 0 other aborts

Errors: 0 no b/w, 0 no route, 0 admin 0 bad exp route, 0 rec route loop, 0 frr activated 0 other Tunnel2 (Destination 172.17.0.7; Name PE-4_t2) Management statistics: Path:

0 no path, 0 path no longer valid, 0 missing ip exp path 1 path changes 0 loose path reoptimizations, triggered by PathErrors

State:

1 transitions, 0 admin down, 0 oper down

Signalling statistics: Opens:

1 succeeded, 0 timed out, 0 bad path spec 0 other aborts

Errors: 0 no b/w, 0 no route, 0 admin 0 bad exp route, 0 rec route loop, 0 frr activated . . . [ output omitted ] 172.17.0.5 60004 (Destination 172.17.0.32; Name PE-5_t60004) 172.17.0.6 60003 (Destination 172.17.0.2; Name PE-6_t60003) 172.17.0.6 60002 (Destination 172.17.0.3; Name PE-6_t60002) 172.17.0.6 2 (Destination 172.17.0.4; Name PE-6_t2) 172.17.0.6 60000 (Destination 172.17.0.7; Name PE-6_t60000) 172.17.0.6 60001 (Destination 172.17.0.32; Name PE-6_t60001) 172.17.0.7 60003 (Destination 172.17.0.3; Name PE-7_t60003) 172.17.0.7 1 (Destination 172.17.0.4; Name PE-7_t1) . . . [ output omitted ]


PE-4# sh mpl traffic-eng tunnels role tail LSP Tunnel P2_t60000 is signalled, connection is up InLabel

: Serial1/0, implicit-null

OutLabel :

-

RSVP Signalling Info: Src 172.17.0.2, Dst 172.17.0.4, Tun_Id 60000, Tun_Instance 52 RSVP Path Info: My Address: 172.17.0.4 Explicit Route: Record

NONE

Route:

NONE


Route:

NONE

Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits LSP Tunnel P3_t60001 is signalled, connection is up InLabel

: Serial1/0, implicit-null

OutLabel :

-

RSVP Signalling Info: Src 172.17.0.3, Dst 172.17.0.4, Tun_Id 60001, Tun_Instance 52 RSVP Path Info: My Address: 172.17.0.4 Explicit Route: Record

NONE

Route:

NONE


Route:

NONE

Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits . . . [ output omitted ]

PE-4# sh mpl traffic-eng tunnels accounting Tunnel1 (Destination 172.17.0.5; Name PE-4_t1) 5 minute output rate 2 kbits/sec, 1 packets/sec Tunnel2 (Destination 172.17.0.7; Name PE-4_t2) 5 minute output rate 0 kbits/sec, 0 packets/sec Tunnel3 (Destination 172.17.0.6; Name PE-4_t3) 5 minute output rate 0 kbits/sec, 0 packets/sec Tunnel60000 (Destination 172.17.0.2; Name PE-4_t60000) 5 minute output rate 0 kbits/sec, 0 packets/sec Tunnel60001 (Destination 172.17.0.3; Name PE-4_t60001) 5 minute output rate 0 kbits/sec, 0 packets/sec Tunnel60002 (Destination 172.17.0.1; Name PE-4_t60002) 5 minute output rate 0 kbits/sec, 0 packets/sec Tunnel60003 (Destination 172.17.0.5; Name PE-4_t60003) 5 minute output rate 0 kbits/sec, 0 packets/sec Totals for 7 Tunnels 5 minute output rate 2 kbits/sec, 1 packets/sec


PE-4# sh mpl traffic-eng link-management bandwidth-allocation serial 1/0 System Information:: Links Count:

2

Bandwidth Hold Time:

max. 15 seconds

Link ID::

It displays how many interfaces are enabled on RSVP.

Se1/0 (172.19.45.1)

Link Status: SRLGs:

None

Physical Bandwidth:

2048 kbits/sec

Max Res Global BW:

155000 kbits/sec (reserved: 0% in, 0% out)

Max Res Sub BW:


BW Descriptors:

1

MPLS TE Link State:

MPLS TE on, RSVP on, admin-up, flooded

Inbound Admission:

allow-all

Outbound Admission:

allow-if-room

Admin. Weight:

640 (IGP)

IGP Neighbor Count:

1

It shows the threshold when a new LSP will be generated and flooded to whole backbone

Up Thresholds: (default)

15 30 45 60 75 80 85 90 95 96 97 98 99 100

Down Thresholds: (default)

100 99 98 97 96 95 90 85 80 75 60 45 30 15

Downstream Global Pool Bandwidth Information (kbits/sec): KEEP PRIORITY

BW HELD

BW TOTAL HELD

BW LOCKED

BW TOTAL LOCKED

0

0

0

0

0

1

0

0

0

0

2

0

0

0

0

3

0

0

0

0

4

0

0

100

100

5

0

0

0

100

6

0

0

0

100

7

0

0

0

100

Downstream Sub Pool Bandwidth Information (kbits/sec):

Total of the tunnels this router is aware of.

KEEP PRIORITY

BW HELD

BW TOTAL HELD

BW LOCKED

0

0

0

0

BW TOTAL LOCKED 0 global pool. “G” means “R” means bandwidth is reserved. “H” means bandwidth is temporarily being held for a path message.


PE-4# sh mpl traffic-eng link-management admission-control System Information::

U stream interface

Tunnels Count:

36

Tunnels Selected:

36

Downstream interface

TUNNEL ID

UP IF

DOWN IF

PRIORITY STATE

BW (kbps)

172.17.0.1 60001_78

Se0/0

Se1/0

7/7

Resv Admitted

0

G


Tunnel id: + _.

172.17.0.3 60001_52

Se1/0

-

7/7

Resv Admitted

0

G

172.17.0.3 60002_58

Se0/0

Se1/0

7/7

Resv Admitted

0

G

172.17.0.3 60003_58

Se0/0

Se1/0

7/7

Resv Admitted

0

G

172.17.0.4 1_9721

-

Se1/0

4/4

Resv Admitted

100

RG

172.17.0.4 2_1367

-

Se0/0

4/4

Resv Admitted

100

RG


Backup tunnel does not allocate bandwidth. Only the primary tunnel interface requests bandwidth.


PE-4# sh mpl traffic-eng link-management advertisements Flooding Status:

ready

Configured Areas:

1

IGP Area[1] ID::

isis

level-2

System Information:: Flooding Protocol:

ISIS

Header Information:: IGP System ID:

0000.0000.0004.00

MPLS TE Router ID:

172.17.0.4

Flooded Links:

2

Link ID::

0

Link Subnet Type:

Point-to-Point

Link IP Address:

172.19.24.2

IGP Neighbor:

ID 0000.0000.0002.00, IP 172.19.24.1

TE metric:

10

IGP metric:

10

SRLGs:

None

Physical Bandwidth:

2048 kbits/sec

Res. Global BW:

155000 kbits/sec

Res. Sub BW:

0 kbits/sec

These figures should match with “show mpls traffic-eng topology igp-id isis .00

Downstream:: Global Pool

Sub Pool

-----------

----------

Reservable Bandwidth[0]:

155000

0 kbits/sec


155000

0 kbits/sec


155000

0 kbits/sec


155000

0 kbits/sec


154800

0 kbits/sec


154800

0 kbits/sec


154800

0 kbits/sec


154800

0 kbits/sec

Attribute Flags:

Link ID::

0x00000000

1

Link Subnet Type:

Point-to-Point

Link IP Address:

172.19.45.1

IGP Neighbor:

ID 0000.0000.0005.00, IP 172.19.45.2

TE metric:

640

IGP metric:

640

SRLGs:

None

Physical Bandwidth:

2048 kbits/sec

Res. Global BW:

155000 kbits/sec

Res. Sub BW:

0 kbits/sec

Downstream:: . . . [ output omitted ]


PE-4# sh mpl traffic-eng link-management igp-neighbors Link ID::

Se0/0

Neighbor ID: Link ID::

0000.0000.0002.00 (area: isis

level-2, IP: 172.19.24.1)

0000.0000.0005.00 (area: isis

level-2, IP: 172.19.45.2)

Se1/0

Neighbor ID:

It shows MPLS-TE ISIS neighbours.

PE-4# sh mpl traffic-eng link-management statistics System Information:: LSP Admission Statistics: Path:

85 setup requests, 85 admits, 0 rejects, 0 setup errors 43 tear requests, 0 preempts, 0 tear errors

Resv:


Link ID::

Se0/0 (172.19.24.2)

Link Admission Statistics: Up Path:


Up Resv:


Down Path:


Down Resv:


Link ID::

Se1/0 (172.19.45.1)

Link Admission Statistics: Up Path:



PE-4# sh mpl traffic-eng link-management interfaces s0/0 System Information:: Links Count:

Link ID::

2

Se0/0 (172.19.24.2)

Link Status: SRLGs:

None

Physical Bandwidth:

2048 kbits/sec

Max Res Global BW:


Max Res Sub BW:


MPLS TE Link State:

MPLS TE on, RSVP on, admin-up, flooded

Inbound Admission:

allow-all

Outbound Admission:

allow-if-room

Admin. Weight:

10 (IGP)

IGP Neighbor Count:

1

IGP Neighbor:

ID 0000.0000.0002.00, IP 172.19.24.1 (Up)

Flooding Status for each configured area [1]:

IGP Area[1]:

isis

level-2:

flooded


Step 8.

If the state is “active” means the primary tunnel is down and the backup is being used.

FAST REROUTE CHECKING

N-Nhop means Link protection.

PE-4# sh ip rsv fast-reroute Primary

Protect BW

Backup

Tunnel

I/F

Tunnel:Label

------

------- --------

------------- ------ -----

PE-4_t1

Se0/0

100K:G

Tu60003:56

Ready

any-unl N-Nhop

PE-4_t2

Se0/0

100K:G

Tu60002:41

Ready

any-unl N-Nhop

PE-4_t3

Se0/0 100K:G

BPS:Type

Tu60002:42

State

Level

Type ------

Ready any-unl N-Nhop

PE-4# sh ip rsvp fast bw-protect Primary

Protect BW

Backup

Tunnel

I/F

Tunnel:Label

------

------- --------

BPS:Type

State

BW-P

------------- ------ -----

PE-4_t1

Se0/0 100K:G

Tu60003:56

Ready OFF

N-Nhop

PE-4_t2

Se0/0 100K:G

Tu60002:41

Ready OFF

N-Nhop

PE-4_t3 Se0/0 100K:G Tu60002:42 Ready OFF This output shows the status of backup bandwidth protection.

N-Nhop

PE-4# sh mpl traffic-eng tunnels tunnel 3 protection PE-4_t3 LSP Head, Tunnel3, Admin: up, Oper: up Src 172.17.0.4, Dest 172.17.0.7, Instance 7169 Fast Reroute Protection: Requested Outbound: FRR Ready

Backup Tu60002 to LSP nnhop Tu60002: out i/f: Se1/0, label: 53 LSP signalling info: Original: out i/f: Se0/0, label: 44, nhop: 172.19.24.1 nnhop: 172.17.0.3, nnhop rtr id: 172.17.0.3

With FRR: out i/f: Tu60002, label: 42 LSP bw: 100 kbps, Backup level: any-unlim, type: any pool Path Protection: None

It shows the backup tunnel interface which is protecting a primary tunnel interface. PE-4# sh mpl traffic-eng tunnels backup PE-4_t60000

LSP Head, Tunnel60000, Admin: up, Oper: up Src 172.17.0.4, Dest 172.17.0.5, Instance 20 Fast Reroute Backup Provided:

Protected i/fs: Se1/0 Protected lsps: 0 Backup BW: any pool unlimited; inuse: 0 kbps PE-4_t60001

LSP Head, Tunnel60001, Admin: up, Oper: up Src 172.17.0.4, Dest 172.17.0.2, Instance 1 Fast Reroute Backup Provided: Protected i/fs: Se0/0 Protected lsps: 0 Backup BW: any pool unlimited; inuse: 0 kbps . . . [ output omitted ]

It shows the physical link which is protected by a specific backup tunnel. July 10 A printed copy of this document is considered uncontrolled.

Type ------

PE-4# sh mpl traffic-eng tunnels tunnel 60002 Name: PE-4_t60002


Status:

Admin: up

Oper: up

Path: valid


path option 1, type explicit __dynamic_tunnel60002 (Basis for Setup, path weight 1260) Config Parameters: Bandwidth: 0

kbps (Global)

Priority: 7

7



disabled

LockDown: disabled

Loadshare: 0

bw-based

auto-bw: disabled Active Path Option Parameters:

State: explicit path option 1 is active BandwidthOverride: disabled

InLabel

:

LockDown: disabled

-

OutLabel : Serial1/0, 53

Verbatim: disabled

This is the Tail end of Backup tunnel. In this case it is P3. This is a node protection. In this case the node protected is P2.

RSVP Signalling Info: Src 172.17.0.4, Dst 172.17.0.3, Tun_Id 60002, Tun_Instance 1 RSVP Path Info: My Address: 172.17.0.4 Explicit Route: 172.19.45.2 172.19.53.9 172.19.131.2 172.19.32.1

172.17.0.3 Record

Route:

NONE


Route:

NONE

Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits Shortest Unconstrained Path Info:

Path of Backup Tunnel in case of failures (failure link between PE4 or node failure, P2 node)

Path Weight: 20 (TE) Explicit Route: 172.19.24.1 172.19.23.2 172.17.0.3 History: Tunnel: Time since created: 3 hours, 1 minutes Time since path change: 3 hours, 1 minutes Number of LSP IDs (Tun_Instances) used: 1 Current LSP: Uptime: 3 hours, 1 minutes

It shows the information of backup tunnel interface.


Path when there is NO failure.

PE-4# sh ip rsv fast-reroute detail filter dest 172.17.0.7 source 172.17.0.4 PATH: Tun Dest:

172.17.0.7


Tun ID: 3

Ext Tun ID: 172.17.0.4

LSP ID: 7169

Path refreshes: sent:

to

NHOP 172.19.24.1 on Serial0/0

Session Attr: Setup Prio: 4, Holding Prio: 4 Flags: (0x7) Local Prot desired, Label Recording, SE Style Session Name: PE-4_t3 ERO: (incoming) 172.17.0.4 (Strict IPv4 Prefix, 8 bytes, /32) 172.19.24.1 (Strict IPv4 Prefix, 8 bytes, /32) 172.19.23.2 (Strict IPv4 Prefix, 8 bytes, /32) 172.19.32.2 (Strict IPv4 Prefix, 8 bytes, /32) 172.19.137.2 (Strict IPv4 Prefix, 8 bytes, /32) 172.17.0.7 (Strict IPv4 Prefix, 8 bytes, /32) ERO: (outgoing) 172.19.24.1 (Strict IPv4 Prefix, 8 bytes, /32) 172.19.23.2 (Strict IPv4 Prefix, 8 bytes, /32) 172.19.32.2 (Strict IPv4 Prefix, 8 bytes, /32) 172.19.137.2 (Strict IPv4 Prefix, 8 bytes, /32) 172.17.0.7 (Strict IPv4 Prefix, 8 bytes, /32) RRO: Empty Traffic params - Rate: 100K bits/sec, Max. burst: 1K bytes Min Policed Unit: 0 bytes, Max Pkt Size 4294967295 bytes Fast-Reroute Backup info: Inbound

FRR: Not active

Outbound FRR: Ready -- backup tunnel selected Backup Tunnel: Tu60002

(label 42)

Bkup Sender Template: Tun Sender: 172.19.45.1

LSP ID: 7169

Bkup FilerSpec: Tun Sender: 172.19.45.1, LSP ID: 7169 Path ID handle: 03000420. Incoming policy: Accepted. Policy source(s): MPLS/TE Status: Proxied Output on Serial0/0. Policy status: Forwarding. Handle: 0200041E Policy source(s): MPLS/T

It shows if the backup tunnel is in used (if yes mean there is a physical link failure).


PE-4# sh mpl traffic-eng fast-reroute database Tunnel head end item frr information: Protected tunnel

In-label Out intf/label

FRR intf/label

Status

Tunnel3

Tun hd

Se0/0:Untagged

Tu60002:42

ready

Tunnel2

Tun hd

Se0/0:Untagged

Tu60002:41

ready

Tunnel1

Tun hd

Se0/0:Untagged

Tu60003:56

ready

Prefix item frr information: Prefix

Tunnel


FRR intf/label

Status

172.17.0.6/32

Tu2

46

Se0/0:Pop tag

Tu60002:41

ready

172.17.0.7/32

Tu3

47

Se0/0:Pop tag

Tu60002:42

ready

172.16.67.0/30

Tu2

48

Se0/0:Untagged

Tu60002:41

ready

6.6.6.6/32

vpn

vpn

Se0/0:25

Tu60002:41

ready

7.7.7.7/32

vpn

vpn

Se0/0:25

Tu60002:42

ready

172.17.8.51/32

vpn

vpn

Se0/0:29

Tu60002:41

ready

172.17.8.52/32

vpn

vpn

Se0/0:30

Tu60002:42

ready

10.33.31.0/30

vpn

vpn

Se0/0:26

Tu60002:41

ready

10.33.31.4/30

vpn

vpn

Se0/0:27

Tu60002:41

ready

10.33.31.8/30

vpn

vpn

Se0/0:28

Tu60002:42

ready

172.17.0.5/32

Tu1

16

Se0/0:Pop tag

Tu60003:56

ready

5.5.5.5/32

vpn

vpn

Se0/0:26

Tu60003:56

ready

FRR intf/label

Status

LSP midpoint item frr information: LSP identifier


PE-4# sh mpl traffic-eng fast-reroute database detail PE-4#sh mpl traffic-eng fast-reroute database detail LFIB FRR Database Summary: Total Clusters:

1

Total Groups:

2

Total Items:

15

Link 2: Se0/0 (Up, 2 groups) Group 16: Se0/0->Tu60002 (Up, 12 members) Prefix 172.17.0.6/32, Tu2, ready Input label 46, Output label Se0/0:Pop tag, FRR label Tu60002:41

Prefix 172.17.0.7/32, Tu3, ready Input label 47, Output label Se0/0:Pop tag, FRR label Tu60002:42 Protected tunnel Tunnel3, ready Input label Tun hd, Output label Se0/0:Untagged, FRR label Tu60002:42 Protected tunnel Tunnel2, ready Input label Tun hd, Output label Se0/0:Untagged, FRR label Tu60002:41 Prefix 172.16.67.0/30, Tu2, ready Input label 48, Output label Se0/0:Untagged, FRR label Tu60002:41 Prefix 6.6.6.6/32, vpn, ready Input label vpn, Output label Se0/0:25, FRR label Tu60002:41 . . . [ output omitted ]


AToM PE-4# sh mpl l2transport binding 100 Destination Address: 172.17.0.7, VC ID: 100 Local Label:

49

Cbit: 1,

VC Type: HDLC,

MTU: 1500,

GroupID: 0

Interface Desc: >>>> link to CE1

VCCV Capabilities: Type 1, Type 2 Remote Label: 50 Cbit: 1,

VC Type: HDLC,

MTU: 1500,

GroupID: 0


VCCV Capabilities: Type 1, Type 2

It displays the status of vc-id 100. PE-4# sh mpl l2transport binding 172.17.0.7 Destination Address: 172.17.0.7, Local Label:

VC ID: 100

49

Cbit: 1,

VC Type: HDLC,

MTU: 1500,

GroupID: 0


VCCV Capabilities: Type 1, Type 2 Remote Label: 50 Cbit: 1,

VC Type: HDLC,

MTU: 1500,

GroupID: 0


VCCV Capabilities: Type 1, Type 2

PE-4# sh mpl l2transport summary Destination address: 172.17.0.7, total number of vc: 1 0 unknown, 1 up, 0 down, 0 admin down, 0 recovering

1 active vc on MPLS interface Tu3 It displays the statistics of layer 2 vpns. In this lab there is only one vc created between PE4 and PE7. PE-4#sh mpl l2transport vc 100 detail Local interface: Se2/0 up, line protocol up, HDLC up Destination address: 172.17.0.7, VC ID: 100, VC status: up Preferred path: not configured Default path: active Next hop: point2point Output interface: Tu3, imposed label stack {43 50} Create time: 04:19:36, last status change time: 04:19:29 Signaling protocol: LDP, peer 172.17.0.7:0 up MPLS VC labels: local 49, remote 50 Group ID: local 0, remote 0 MTU: local 1500, remote 1500 Remote interface description: >>>> link to CE4 Sequencing: receive disabled, send disabled VC statistics: packet totals: receive 3786, send 3368 byte totals:

receive 301794, send 277477

packet drops:

receive 0, seq error 0, send 0


Tracing a LSP end to end Firstly we will check will is the path taken from CE-1 to reach CE-4. CE-1# trace 172.17.8.52 Type escape sequence to abort. Tracing the route to 172.17.8.52 1 10.40.31.5 20 msec 20 msec 24 msec 2 172.19.24.1 28 msec 36 msec 12 msec 3 172.19.31.2 28 msec 20 msec 32 msec 4 172.19.131.2 20 msec 20 msec 20 msec 5 10.33.31.9 20 msec 20 msec 20 msec 6 10.33.31.10 20 msec *

LDP or RSVP label for LSP tunnel from PE4- to PE7.

20 msec

This path is: CE-1  PE4  P2  P31  P32  PE7  CE-4 Let‟s check this from PE4. PE-4# trace vrf VPN 10.33.31.10

VPN label (learn via MP-BGP

Type escape sequence to abort. Tracing the route to 10.33.31.10

1 172.19.24.1 [MPLS: Labels 43/49 Exp 0] 40 msec 40 msec 32 msec 2 172.19.31.2 [MPLS: Labels 40/49 Exp 0] 48 msec 40 msec 28 msec 3 172.19.131.2 [MPLS: Labels 37/49 Exp 0] 40 msec 36 msec 32 msec 4 172.19.137.2 [MPLS: Labels 49 Exp 0] 40 msec 36 msec 32 msec 5 10.33.31.9 44 msec 40 msec 40 msec P1

CE1

PE4

P2

P3

PE6

P32

PE7

43 49 IP

IP

P30

40 49 IP PE5

P31

37 4 IP

4 IP

CE4

IP

PE-4# sh ip cef vrf VPN 10.33.31.8 10.33.31.8/30, version 39, epoch 0, cached adjacency to Tunnel3 0 packets, 0 bytes tag information set, all rewrites owned

LDP or RSVP label for LSP tunnel from PE4- to PE7.

local tag: VPN route head fast tag rewrite with Tu3, point2point, tags imposed {43 49}

via 172.17.0.7, 0 dependencies, recursive next hop 172.17.0.7, Tunnel3 via 172.17.0.7/32 (Default) valid cached adjacency tag rewrite with Tu3, point2point, tags imposed { 43 49}

Let‟s check the VPN label. The subnetwork of 10.33.31.10 is 10.33.31.8/30.


VPN label (learn via MP-BGP

PE-4# sh ip bgp vpn all labels | i 10.33.31.8 10.33.31.8/30

172.17.0.7

nolabel/49

10.33.31.8/30

172.17.0.7

nolabel/49

You can also with the follo wing command: PE-4# sh ip bgp vpn all 10.33.31.8 BGP routing table entry for 25135:133001804:10.33.31.8/30, version 894 Bestpath Modifiers: missing-med-worst, always-compare-med, deterministic-med Paths: (2 available, best #1, table VPN) Not advertised to any peer Local, imported path from 25135:133001807:10.33.31.8/30 172.17.0.7 (metric 630) from 172.17.0.8 (172.17.0.8) Origin incomplete, metric 0, localpref 100, valid, internal, best Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200 RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:7.7.7.7:512 Originator: 172.17.0.7, Cluster list: 0.0.0.1, mpls labels in/out nolabel/ 49 Local, imported path from 25135:133001807:10.33.31.8/30 172.17.0.7 (metric 630) from 172.17.0.9 (172.17.0.9) Origin incomplete, metric 0, localpref 100, valid, internal Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200 RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:7.7.7.7:512 Originator: 172.17.0.7, Cluster list: 0.0.0.1, mpls labels in/out nolabel/ 49 BGP routing table entry for 25135:133001807:10.33.31.8/30, version 892 Bestpath Modifiers: missing-med-worst, always-compare-med, deterministic-med Paths: (2 available, best #2, no table) Not advertised to any peer Local 172.17.0.7 (metric 630) from 172.17.0.9 (172.17.0.9) Origin incomplete, metric 0, localpref 100, valid, internal Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200 RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:7.7.7.7:512 Originator: 172.17.0.7, Cluster list: 0.0.0.1, mpls labels in/out nolabel/ 49 Local 172.17.0.7 (metric 630) from 172.17.0.8 (172.17.0.8) Origin incomplete, metric 0, localpref 100, valid, internal, best Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200 RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:7.7.7.7:512 Originator: 172.17.0.7, Cluster list: 0.0.0.1, mpls labels in/out nolabel/ 49

Let‟s check the RSVP label or LDP label. The label which builds up a LSP tunnel from PE-4 to PE7. In this particular case the LSP is built up based on the VPNv4 next-hop, which is 172.17.0.7. You find this information on “sh ip bgp vpn all labels | i 10.33.31.8” output command.


PE-4# sh ip cef 172.17.0.7 detail 172.17.0.7/32, version 41, epoch 0, cached adjacency to Tunnel3 0 packets, 0 bytes tag information set, shared, all rewrites owned local tag: 27 fast tag rewrite with Tu3, point2point, tags imposed {43} via 172.17.0.7, Tunnel3, 3 dependencies next hop 172.17.0.7, Tunnel3 valid cached adjacency tag rewrite with Tu3, point2point, tags imposed {43} This output says the exit interface is Tunnel3, which means the label learnt here is from RSVP. PE-4# sh mpl traf tun tun 3 Name: PE-4_t3


Status: Admin: up

Oper: up

Path: valid


path option 1, type dynamic (Basis for Setup, path weight 630) Config Parameters: Bandwidth: 100

kbps (Global)

Priority: 4

4



enabled

LockDown: disabled

auto-bw: (86400/63578) 0

Loadshare: 100

bw-based


Active Path Option Parameters: State: dynamic path option 1 is active BandwidthOverride: disabled InLabel

:

LockDown: disabled

Verbatim: disabled

-

OutLabel : Serial0/0, 43

This is the RSVP label.

FRR OutLabel : Tunnel60002, 40 RSVP Signalling Info: Src 172.17.0.4, Dst 172.17.0.7, Tun_Id 3, Tun_Instance 5407 RSVP Path Info: My Address: 172.17.0.4 Explicit Route: 172.19.24.1 172.19.31.2 172.19.131.2 172.19.137.2 172.17.0.7 Record

Route:


Route:

172.17.0.2(43) 172.19.31.1(43) 172.17.0.31(40) 172.19.131.1(40) 172.17.0.32(37) 172.19.137.1(37) 172.17.0.7(0) 172.19.137.2(0)

[output ommitted]

You can also get the RSVP label from the following command:


With this command you can also get the LSP tunnel from PE-4 to PE7. This set of label should match with the output shown in traceroute 2 page before.

PE-4# sh ip rsvp reservation detail filter destination 172.17.0.7 Reservation: Tun Dest:

172.17.0.7


Tun ID: 3

Ext Tun ID: 172.17.0.4

LSP ID: 5407

Next Hop: 172.19.24.1 on Serial0/0 Label: 43 (outgoing) Reservation Style is Shared-Explicit, QoS Service is Controlled-Load Resv ID handle: 01000445. Created: 09:09:13 UTC Fri Jul 13 2007 Average Bitrate is 100K bits/sec, Maximum Burst is 1K bytes Min Policed Unit: 0 bytes, Max Pkt Size: 0 bytes RRO: 172.17.0.2/32, Flags:0x20 (No Local Protection, Node-id) Label subobject: Flags 0x1, C-Type 1, Label 43 172.19.31.1/32, Flags:0x0 (No Local Protection) Label subobject: Flags 0x1, C-Type 1, Label 43 172.17.0.31/32, Flags:0x20 (No Local Protection, Node-id) Label subobject: Flags 0x1, C-Type 1, Label 40 172.19.131.1/32, Flags:0x0 (No Local Protection) Label subobject: Flags 0x1, C-Type 1, Label 40 172.17.0.32/32, Flags:0x20 (No Local Protection, Node-id) Label subobject: Flags 0x1, C-Type 1, Label 37 172.19.137.1/32, Flags:0x0 (No Local Protection) Label subobject: Flags 0x1, C-Type 1, Label 37 172.17.0.7/32, Flags:0x20 (No Local Protection, Node-id) Label subobject: Flags 0x1, C-Type 1, Label 0 172.19.137.2/32, Flags:0x0 (No Local Protection) Label subobject: Flags 0x1, C-Type 1, Label 0 Status: Policy: Accepted. Policy source(s): MPLS/TE

Let‟s go to the next router in this pat h, which is P2 (172.19.24.2). As P2 told to PE4 (via RSVP) to use label 43, then we will look up in LFIB an incoming label 43 (figure in the first column of the output). P2# sh mpl forwarding-table | i 43 30

20

172.17.0.8/32

43

40

172.17.0.4 3 [5407] 484533

Label for incoming labelled packet Incoming label.

Outgoing label.

608143

Se0/0 Se2/0

point2point point2point

This is the outgoing label for this LSP. Which should match with the output in the trace command.

Let‟s to the same for the next hop, which is P31 (172.19.31.2) . P31# sh mpl forwarding-table | i 40 31

16

172.17.0.4/32

336408

40

37

172.17.0.4 3 [5407] 486261

Se2/0 Se1/0


point2point point2point

Because P32 is the PHP, we will have here a pop tag Let‟s to the same for the next hop, which is P 32 (172.19.131.2) . P32#

sh mpl forwarding-table | i 37

37

Pop tag

172.17.0.4 3 [5407] 463873

Se3/0

point2point

41

38

172.17.0.5 2 [3337] 0

Se2/0

point2point

42

37

172.17.0.7 1 [2002] 0

Se1/0

point2point

54

56

172.17.0.7 2 [9988] 73748

Se2/0

point2point

Ad the last PE: PE-7# sh ip bgp vpn all labels | i 10.33.31.8 10.33.31.8/30

0.0.0.0

49/aggregate(VPN)

PE-7# sh ip route vrf VPN 10.33.31.8 Routing entry for 10.33.31.8/30 Known via "connected", distance 0, metric 0 (connected, via interface) Redistributing via bgp 25135 Advertised by bgp 25135 Routing Descriptor Blocks: * directly connected, via Serial2/0 Route metric is 0, traffic share count is 1

From here it will normal an IP packet without any labels.

Conclusion: the LSP tunnel created from PE4 to PE7 is 43



40  37  explicit null.

As this is using the Traffic engineer tunnel all these labels were learnt/propagated via RSVP.


TM

Part 5: Failure Scenarios


Troubleshooting Scenarios Describe what would happen when the fault is fixed. As an example we will concentrate in only one primary tunnel which has as a Head End PE4 and tail End PE7.

Mis-configuration ISIS metrics Step 1.

Identify the primary tunnel PE-4# sh mpls traffic-eng auto-tunnel mesh | i 172.17.0.7 172.17.0.7

Tunnel3

Using as a filter the destination IP address, it provides only the output we are interested to check.

Step 2.

Identify the status of the primary tunnel PE-4# sh mpl traffic-eng tunnels tu 3 | i Path

Admin: up

Oper: up

Path: valid


Active Path Option Parameters: RSVP Path Info: Shortest Unconstrained Path Info: Path Weight: 670 (TE)

Step 3.

Identify the path used in the primary tunnel PE-4# sh mpl traffic-eng tunnels tu 3 | b Explicit Route Explicit Route: 172.19.24.1 172.19.23.2 172.16.36.2 172.16.67.2 172.17.0.7 Record

Route:

NONE


Route:

172.17.0.2(48) 172.17.0.3(50) 172.17.0.6(40) 172.17.0.7(0)



Checking in the diagram if this route is the expect path: PE4



P2   P3   PE6   PE7.

P1

Head End

PE4

Middle Points Point

P2

P3

PE6

P30

PE5

Step 4.

P31

Tail End

P32

PE7

Identify the backup tunnels PE-4# sh mpl traffic-eng tunnels | i Src 172.17.0.4, Dst 172.17.0.3, Src 172.17.0.4, Dst 172.17.0.3, Tun_Id 60002, Tun_Instance 167

This output shows the backup tunnel interface in use to protect (P2) – NNHOP.

PE-4# sh mpl traffic-eng tunnels | i Src 172.17.0.4, Dst 172.17.0.2, Src 172.17.0.4, Dst 172.17.0.2, Tun_Id 60001, Tun_Instance 167

This output shows the backup tunnel interface in use to protect the link between PE4 and P2. – NHOP.

PE-4# sh mpl traffic-eng tunnels tunnel 3 protection PE-4_t3 LSP Head, Tunnel3, Admin: up, Oper: up

This is a node protection (NNHOP).

Src 172.17.0.4, Dest 172.17.0.7, Instance 7463 Fast Reroute Protection: Requested

The node protected here is P2 (as the next hop is P3). Look in the previous output to understand why P2 is the node rotected.

Outbound: FRR Ready Backup Tu60002 to LSP nnhop Tu60002: out i/f: Se1/0, label: 57 LSP signalling info:

Original: out i/f: Se0/0, label: 48, nhop: 172.19.24.1 nnhop: 172.17.0.3, nnhop rtr id: 172.17.0.3 With FRR: out i/f: Tu60002, label: 50 LSP bw: 100 kbps, Backup level: any-unlim, type: any pool Path Protection: None

This backup tunnel is a node protection (nnhop). PE-4# sh mpl traffic-eng tunnels tunnel 60002 | i Path|Explicit Route Admin: up

Oper: up

Path: valid


Active Path Option Parameters: RSVP Path Info: Explicit Route: 172.19.45.2 172.19.53.9 172.19.131.2 172.19.137.2 Shortest Unconstrained Path Info: Path Weight: 20 (TE) Explicit Route: 172.19.24.1 172.19.23.2 172.17.0.3


Verify the Path used for this backup tunnel: PE4 Node Protected for this tunnel PE-4 – T60002 PE4



PE5   P31   P32

P1

P2



PE7   PE6.

Next-Next -Hop P3

PE6

P32

PE7

P30

PE5

P31

Is this path expected? Why the cSPF algorithm chose this path? Let‟s check the ISIS metric for this path.

PE-4# sh cln int | i Serial|Metric Serial0/0 is up, line protocol is up Level-2 Metric: 10, Priority: 64, Circuit ID: PE-4.00 Level-2 IPv6 Metric: 10 Serial1/0 is up, line protocol is up Level-2 Metric: 640, Priority: 64, Circuit ID: PE-4.01 Level-2 IPv6 Metric: 10 Serial2/0 is up, line protocol is up

PE-5# sh cln int | i (line protocol|Metric) Serial0/0 is up, line protocol is up Level-2 Metric: 10, Priority: 64, Circuit ID: PE-5.00 Level-2 IPv6 Metric: 10 Serial1/0 is up, line protocol is up Level-2 Metric: 640, Priority: 64, Circuit ID: PE-5.01 Level-2 IPv6 Metric: 10 Serial2/0 is up, line protocol is up Auto-Template1 is up, line protocol is up Loopback0 is up, line protocol is up Loopback1 is up, line protocol is up Tunnel1 is up, line protocol is up Tunnel2 is up, line protocol is up Tunnel3 is up, line protocol is up Tunnel60000 is up, line protocol is up Tunnel60001 is up, line protocol is up Tunnel60002 is up, line protocol is up Tunnel60003 is up, line protocol is up

P31# sh cln int | i line protocol|Metric Serial0/0 is up, line protocol is up Level-2 Metric: 10, Priority: 64, Circuit ID: P31.00 Level-2 IPv6 Metric: 10 Serial1/0 is up, line protocol is up Level-2 Metric: 10, Priority: 64, Circuit ID: P31.01 Level-2 IPv6 Metric: 10


Serial2/0 is up, line protocol is up Level-2 Metric: 1000, Priority: 64, Circuit ID: P31.02 Level-2 IPv6 Metric: 10 Serial3/0 is up, line protocol is up Level-2 Metric: 10, Priority: 64, Circuit ID: P31.03 Level-2 IPv6 Metric: 10 Serial4/0 is up, line protocol is down Level-2 Metric: 10, Priority: 64, Circuit ID: P31.04 Level-2 IPv6 Metric: 10 Loopback0 is up, line protocol is up Tunnel60000 is up, line protocol is up Tunnel60001 is up, line protocol is up Tunnel60002 is up, line protocol is up Tunnel60003 is up, line protocol is up

P32#sh cln int | i line protocol|Metric Serial0/0 is up, line protocol is up Level-2 Metric: 10, Priority: 64, Circuit ID: P32.00 Level-2 IPv6 Metric: 10 Serial1/0 is up, line protocol is up Level-2 Metric: 10, Priority: 64, Circuit ID: P32.01 Level-2 IPv6 Metric: 10

Serial2/0 is up, line protocol is up Level-2 Metric: 1000, Priority: 64, Circuit ID: P32.02 Level-2 IPv6 Metric: 10 Serial3/0 is up, line protocol is up Level-2 Metric: 10, Priority: 64, Circuit ID: P32.03 Level-2 IPv6 Metric: 10 Serial4/0 is up, line protocol is down Loopback0 is up, line protocol is up Tunnel60000 is up, line protocol is up . . . [ output omitted ]

PE-7# sh cln int | i line protocol|Metric Serial0/0 is up, line protocol is up Level-2 Metric: 10, Priority: 64, Circuit ID: PE-7.00 Level-2 IPv6 Metric: 10

Serial1/0 is up, line protocol is up Level-2 Metric: 640, Priority: 64, Circuit ID: PE-7.01 Level-2 IPv6 Metric: 10 Serial2/0 is up, line protocol is up Auto-Template1 is up, line protocol is up Loopback0 is up, line protocol is up Loopback1 is up, line protocol is up Tunnel1 is up, line protocol is up . . . [ output omitted ]

As you can see this is the shortest path to reach P3 in case P2 failures.


Step 5.

Identify the backup tunnels, link protect between P2 and P3 P2# sh mpls traffic-eng tunnels backup | i Tunnel|Se1/0 LSP Head, Tunnel60000, Admin: up, Oper: up LSP Head, Tunnel60001, Admin: up, Oper: up LSP Head, Tunnel60002, Admin: up, Oper: up Protected i/fs: Se1/0 LSP Head, Tunnel60003, Admin: up, Oper: up Protected i/fs: Se1/0

Serial1/0 interface is the link between P2 and P3. This output shows two backup tunnel for Serial 1/0 interface. Next command will clarify the type of these backup tunnels (NHOP or NNHOP), P2# sh mpl traffic-eng tunnels tun 60003 backup P2_t60003 LSP Head, Tunnel60003, Admin: up, Oper: up Src 172.17.0.2, Dest 172.17.0.6, Instance 7498 Fast Reroute Backup Provided: Protected i/fs: Se1/0 Protected lsps: 2 Backup BW: any pool unlimited; inuse: 200 kbps

P2# sh mpl traffic-eng tunnels tun 60002 backup P2_t60002 LSP Head, Tunnel60002, Admin: up, Oper: up Src 172.17.0.2, Dest 172.17.0.3, Instance 1 Fast Reroute Backup Provided: Protected i/fs: Se1/0 Protected lsps: 0 Backup BW: any pool unlimited; inuse: 0 kbps

Do the same for the rest of the hops to identify the backup tunnels (link and node protection) along the path from PE4 toward PE7.

Step 6.

After changing the ISIS metrics between rings from 1000 to 600 (among Ps only) PE-4# sh mpl traffic auto-tunn mesh | i 172.17.0.7 172.17.0.7

Tunnel3

This output confirm primary tunnel which is being used to reach 172.17.0.7. PE-4# sh mpl traffic-eng tunnels tunnel 3 | b Explicit Route Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.2 172.17.0.7 Record

Route:

NONE


Route:

172.17.0.2(65) 172.17.0.3(55) 172.17.0.32(67) 172.17.0.7(0)

Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits Shortest Unconstrained Path Info: Path Weight: 630 (TE) Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.2 172.17.0.7 . . . [ output omitted ]


Checking in the diagram in this route the expect path: PE4



P2   P3   P32   PE7.

P1

Head End

PE4

P2

P3

Middle Points Point

PE6

P30

PE5

P31

Tail End

PE7

P32

PE-4# sh mpl traffic-eng tunnels tu3 protect PE-4_t3

This tunnel is a Node protection.

LSP Head, Tunnel3, Admin: up, Oper: up Src 172.17.0.4, Dest 172.17.0.7, Instance 7483 Fast Reroute Protection: Requested Outbound: FRR Ready Backup Tu60002 to LSP nnhop Tu60002: out i/f: Se1/0, label: 46 LSP signalling info:

Original: out i/f: Se0/0, label: 65, nhop: 172.19.24.1 nnhop: 172.17.0.3, nnhop rtr id: 172.17.0.3 With FRR: out i/f: Tu60002, label: 55 LSP bw: 100 kbps, Backup level: any-unlim, type: any pool Path Protection: None

PE-4# sh mpl traffic tunnel tu60002 | b Explicit Route Explicit Route: 172.19.45.2 172.19.53.9 172.19.131.2 172.19.32.1 172.17.0.3 Record

Route:

NONE


Route:

NONE

Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits . . . [ output omitted ]




PE5   P31



P32   P3.

P1

Node Protected for this tunnel PE-4 – T60002

Next-Next -Hop

PE4

P2

P3

PE6

P32

PE7

P30

PE5

P31


PE-4# sh mpl traffic-eng tunnels backup | i Tunnel|172.17.0.2 LSP Head, Tunnel60000, Admin: up, Oper: up LSP Head, Tunnel60001, Admin: up, Oper: up Src 172.17.0.4, Dest 172.17.0.2, Instance 186 LSP Head, Tunnel60002, Admin: up, Oper: up LSP Head, Tunnel60003, Admin: up, Oper: up LSP Head, Tunnel60004, Admin: up, Oper: up

This filter on the command shows straight way what is the backup tunnel for the link between PE4 and P2. To identify you should have Destination IP address P2 ‟s loopback, which means NHOP tunnel .

PE-4# sh mpl traffic tunnel tu60001 | b Explicit Route Explicit Route: 172.19.45.2 172.19.53.9 172.19.31.1 172.17.0.2 Record

Route:

NONE


Route:

NONE

Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits Shortest Unconstrained Path Info: Path Weight: 10 (TE) Explicit Route: 172.19.24.1 172.17.0.2 . . . [ output omitted ]


PE4

PE5   P31

P1

Next-Hop

Link Protected



P2

P3

PE6

P32

PE7

P30

PE5

P31




P2.

RSVP bandwidth PE-4# sh ip int bri Interface Protocol

IP-Address

OK? Method Status

Serial0/0

172.19.24.2

YES NVRAM

up

up

Serial1/0

172.19.45.1

YES NVRAM

up

up

Serial2/0

10.40.31.5

YES NVRAM

up

up

Auto-Template1

172.17.0.4

YES unset

up

up

Loopback0

172.17.0.4

YES NVRAM

up

up

Loopback1

4.4.4.4

YES NVRAM

up

up

Tunnel1

172.17.0.4

YES unset

up

up

Tunnel2

172.17.0.4

YES unset

up

down

Tunnel3

172.17.0.4

YES unset

up

up

Tunnel60000

172.17.0.4

YES unset

up

up

Tunnel60001

172.17.0.4

YES unset

up

up

Tunnel60002

172.17.0.4

YES unset

up

up

Tunnel60003

172.17.0.4

YES unset

up

up

PE-4# sh mpl tra tu tu2 Name: PE-4_t2


Status:

Admin: up

Oper: down Path: valid

Signalling: RSVP signalling proceeding

path option 1, type dynamic (Basis for Setup, path weight 40)

Status changed after reducing Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF bandwidth Metric Type: TE (default) availablility in AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based the path.

Config Parameters:

auto-bw: (86400/46462) 0


Before, P2 was allocating State: dynamic path option 1 is active bandwidth for BandwidthOverride: disabled LockDown: disabled Verbatim: disabled two tunnels: RSVP Signalling Info: PE4-PE7 and Src 172.17.0.4, Dst 172.17.0.6, Tun_Id 2, Tun_Instance 6753 PE4-PE7. Active Path Option Parameters:

Shortest Unconstrained Path Info: Path Weight: 30 (TE) Explicit Route: 172.19.24.1 172.19.23.2 172.16.36.2 172.17.0.6 History: Tunnel: Time since created: 13 hours, 29 minutes Time since path change: 1 minutes, 18 seconds Number of LSP IDs (Tun_Instances) used: 29 Current LSP: Setup Time: 3 minutes, 41 seconds remaining Prior LSP: ID: path option 1 [6752] Removal Trigger: path error


Now P2 has capacity only for one tunnel. So, one of the tunnels went down.

We can manually force the router recalculates all constraint path. We DO NOT recommend using this command in life network, especially in critical hours. This makes all primary tunnels go down for a couple a minutes. PE-4# clear mpls traffic-eng auto-tunnel mesh PE-4# sh ip int bri Interface Protocol

IP-Address

OK? Method Status

Serial0/0

172.19.24.2

YES NVRAM

up

up

Serial1/0

172.19.45.1

YES NVRAM

up

up

Serial2/0

10.40.31.5

YES NVRAM

up

up

Auto-Template1

172.17.0.4

YES unset

up

up

Loopback0

172.17.0.4

YES NVRAM

up

up

Loopback1

4.4.4.4

YES NVRAM

up

up

Tunnel1

172.17.0.4

YES unset

up

up

Tunnel2

172.17.0.4

YES unset

up

up

Tunnel3

172.17.0.4

YES unset

up

down

Tunnel60000

172.17.0.4

YES unset

up

up

Tunnel60001

172.17.0.4

YES unset

up

up

Tunnel60002

172.17.0.4

YES unset

up

up

Tunnel60003

172.17.0.4

YES unset

up

up

After a couple of seconds the Tunnel 3 is still down. Let‟s check the tunnel status.

PE-4# sh mpl tra tu t3 Name: PE-4_t3


Status:

Admin: up

Signalling: RSVP signalling proceeding

Oper: down Path: valid

path option 1, type dynamic (Basis for Setup, path weight 670) Config Parameters: Bandwidth: 100

kbps (Global)

Priority: 4

4


enabled

LockDown: disabled

auto-bw: (86400/86384) 0

It is trying to find a path of Affinity: 0x0/0xFFFF this tunnel.

Loadshare: 100

bw-based


Active Path Option Parameters: State: dynamic path option 1 is active BandwidthOverride: disabled

LockDown: disabled

Verbatim: disabled

RSVP Signalling Info: Src 172.17.0.4, Dst 172.17.0.7, Tun_Id 3, Tun_Instance 2198 Shortest Unconstrained Path Info: Path Weight: 630 (TE) Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.2 172.17.0.7 History: Tunnel: Time since created: 11 seconds Number of LSP IDs (Tun_Instances) used: 1 Current LSP: Setup Time: 4 minutes, 48 seconds remaining

After a minute later the Tunnel 3 is up.


PE-4# sh mpl tra tu t3 Admin: up Oper: up

Path: valid Signalling: connected path option 1, type dynamic (Basis for Setup, path weight 680) Config Parameters: Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based auto-bw: (86400/67664) 0 Bandwidth Requested: 100 Active Path Option Parameters: State: dynamic path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled InLabel : OutLabel : Serial1/0, 55 FRR OutLabel : Tunnel60004, 52 RSVP Signalling Info: Src 172.17.0.4, Dst 172.17.0.7, Tun_Id 3, Tun_Instance 2204 RSVP Path Info: My Address: 172.17.0.4 Explicit Route: 172.19.45.2 172.19.53.9 172.16.130.1 172.16.132.2

172.19.137.2 172.17.0.7 Record Route: Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits RSVP Resv Info: Record Route: 172.17.0.5(55) 172.19.53.10(55) 172.17.0.31(52) 172.16.130.2(52) 172.17.0.30(50) 172.16.132.1(50) 172.17.0.32(48) 172.19.137.1(48) 172.17.0.7(0) 172.19.137.2(0) Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits Shortest Unconstrained Path Info: Path Weight: 630 (TE) Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.2 172.17.0.7 History: Tunnel: Time since created: 5 hours, 13 minutes Time since path change: 6 seconds Number of LSP IDs (Tun_Instances) used: 7 Current LSP: Uptime: 6 seconds Selection: reoptimization Prior LSP: ID: path option 1 [2198]

Removal Trigger: path error Checking the next path: PE4   PE5   P31   P30   P32 P1

PE4

P2

P3

PE6

P32

PE7

P30

PE5

P31




P7

Let‟s check the RSVP status in P2 and P31. P2# sh ip rsvp int interface

rsvp

allocated

i/f max

flow max sub max

Se0/0 Se1/0 Se2/0

ena ena ena

0 100K 100K

0 100K 100K

0 100K 100K

0 0 0

Se3/0 Tu60000 Tu60001 Tu60002 Tu60003 Tu60004 Tu60005 Tu60006

ena ena ena ena ena ena ena ena

300K 0 0 0 0 0 0 0

155M 0 0 0 0 0 0 0

155M 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0

S1/0 and S2/0 have full filled all bandwidth capacity for RSVP. So, there is not a bandwidth capacity available for RSVP reservation when tunnel 3 has re uested. S0/0 connects to P1 which does not have RSVP enabled.

P2# sh ip rsvp installed RSVP: Serial0/0 has no installed reservations RSVP: Serial1/0 BPS To 0 172.17.0.3 0 172.17.0.3 100K 172.17.0.6 0 172.17.0.7 0 172.17.0.32 RSVP: Serial2/0 BPS To 0 172.17.0.4 100K 172.17.0.5 0 172.17.0.5 0 172.17.0.5 0 172.17.0.6 0 172.17.0.31 0 172.17.0.31 0 172.17.0.31 0 172.17.0.32 RSVP: Serial3/0 BPS To 100K 172.17.0.4 100K 172.17.0.4 100K 172.17.0.4 0 172.17.0.4 0 172.17.0.5

S0/0 does NOT have bandwidth for RSVP reservation.

From 172.17.0.1 172.17.0.31 172.17.0.4 172.17.0.31 172.17.0.5

Protoc 0 0 0 0 0

DPort 60000 60005 2 60004 60004

Sport 1 1 8822 1 1

From 172.17.0.2 172.17.0.6 172.17.0.4 172.17.0.2 172.17.0.2 172.17.0.5 172.17.0.4 172.17.0.7 172.17.0.2

Protoc 0 0 0 0 0 0 0 0 0

DPort 60000 3 60000 60001 60003 60002 60004 60004 60006

Sport 1 9469 20 1 2249 1 1 1 2141

From 172.17.0.5 172.17.0.6 172.17.0.7 172.17.0.5 172.17.0.31

Protoc 0 0 0 0 0

DPort 1 2 2 60000 60000

Sport 3666 514 5455 27 1

S1/0 connects to P3 and has 100k bandwidth allocated. S2/0 connects to P31 and has 100k bandwidth allocated.


P31# sh ip rsvp int interface

rsvp

allocated

i/f max

flow max sub max

Se0/0 Se1/0

ena ena

300K 0

155M 0

155M 0

0 0

Se2/0 Se3/0

ena ena

200K 200K

155M 155M

155M 155M

0 0


Then, S0/0 interface which connects to P30 is the best option. RSVP is not enabled in S1/0 interface which connects to P32.

P31 has the same limitation, S1/0 interface has not RSVP enable.

After correct the RSVP in P2 and P31. Only after the optimization timer has expired, an new path was estabilished. The new Path is PE4 P2 P3 P32 PE7 July 10 A printed copy of this document is considered uncontrolled.

PE-4# sh mpls traff tu tu3 Name: PE-4_t3 Status:


Admin: up

Oper: up

Path: valid


path option 1, type dynamic (Basis for Setup, path weight 630) Config Parameters: Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based auto-bw: (86400/64526) 0 Bandwidth Requested: 100 Active Path Option Parameters: State: dynamic path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled InLabel : OutLabel : Serial0/0, 50 FRR OutLabel : Tunnel60002, 42 RSVP Signalling Info: Src 172.17.0.4, Dst 172.17.0.7, Tun_Id 3, Tun_Instance 2206 RSVP Path Info: My Address: 172.17.0.4 Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.2

172.17.0.7 Record Route: Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits RSVP Resv Info: Record Route: 172.17.0.2(50) 172.19.23.1(50) 172.17.0.3(42) 172.19.32.1(42) 172.17.0.32(50) 172.19.137.1(50) 172.17.0.7(0) 172.19.137.2(0) Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits Shortest Unconstrained Path Info: Path Weight: 630 (TE) Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.2 172.17.0.7 History: Tunnel: Time since created: 6 hours, 5 minutes Time since path change: 1 minutes, 38 seconds Number of LSP IDs (Tun_Instances) used: 11 Current LSP: Uptime: 1 minutes, 41 seconds Selection: reoptimization Prior LSP: ID: path option 1 [2204]

Removal Trigger: reoptimization completed P1

PE4

P2

P3

PE6

P32

PE7

P30

PE5

P31


ISIS disabled for TE PE-4# sh mpl tra tu tu3 Name: PE-4_t3 Status:

Admin: up


Oper: up

Path: valid


path option 1, type dynamic (Basis for Setup, path weight 670) Config Parameters: Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based auto-bw: (86400/63952) 0 Bandwidth Requested: 100 Active Path Option Parameters: State: dynamic path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled

Again, the Tunnel 3 is not using the best path we would expect.

InLabel : OutLabel : Serial1/0, 53 RSVP Signalling Info: Src 172.17.0.4, Dst 172.17.0.7, Tun_Id 3, Tun_Instance 2217 RSVP Path Info: My Address: 172.17.0.4 Explicit Route: 172.19.45.2 172.19.53.9 172.19.131.2 172.19.137.2

172.17.0.7 Record Route: Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits RSVP Resv Info: Record Route: 172.17.0.5(53) 172.19.53.10(53) 172.17.0.31(41) 172.19.131.1(41) 172.17.0.32(53) 172.19.137.1(53) 172.17.0.7(0) 172.19.137.2(0) Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits Shortest Unconstrained Path Info: Path Weight: 670 (TE) Explicit Route: 172.19.45.2 172.19.53.9 172.19.131.2 172.19.137.2

172.17.0.7 History: Tunnel: Time since created: 6 hours, 15 minutes Time since path change: 54 seconds Number of LSP IDs (Tun_Instances) used: 21 Current LSP: Uptime: 57 seconds Selection: reoptimization Prior LSP: ID: path option 1 [2206]

Removal Trigger: re-route path verification failed


Look at this time, the unconstrained Path Info does NOT show the path we would expect either. This could be a sign at least one of the routers in the BEST path has not ISIS enabled for TE.

Let‟s check the status in P2. P2# sh ip rsvp int interface Se0/0 Se1/0 Se2/0 Se3/0 Tu60000 Tu60001 Tu60002 Tu60003 Tu60004 Tu60005 Tu60006

rsvp ena ena ena ena ena ena ena ena ena ena ena

allocated 0 0 0 0 0 0 0 0 0 0 0

i/f max 155M 155M 155M 155M 0 0 0 0 0 0 0

flow max sub max 155M 0 155M 0 155M 0 155M 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

P2# sh isis mpls traffic-eng advertisements System ID: P2.00 Router ID: 172.17.0.2 Link Count: 0

There is not constraint link, and then ISIS is not enabled for MPLS/TE in backbone area (level-2 links). Re-enable ISIS level-2 for MPLS/TE the tunnel 3 path will be changed after the next reoptimisation.

MPLS TE is disabled Another reason interface tunnel 3 is not using P2 as a path could be MPLS/TE is not enabled in P2. In case you should get the following outputs. P2# sh mpl int Interface Serial0/0 Serial1/0 Serial2/0 Serial3/0

IP Yes Yes Yes Yes

(ldp) (ldp) (ldp) (ldp)

Tunnel Yes Yes Yes Yes

Operational Yes Yes Yes Yes

This command do not show if MPLS/TE is enabled or not. P2# sh mpl traffic-eng tunnels summary Signalling Summary:

LSP Tunnels Process:

not running, disabled

This message indicates that mpls traffic-eng global command is not enabled in this router.

RSVP Process: running Forwarding: enabled Head: 7 interfaces, 0 active signalling attempts, 0 established 22 activations, 22 deactivations Midpoints: 0, Tails: 0 auto-tunnel: backup Enabled (7 ), id-range:60000-64000 onehop Disabled (0 ), id-range:65336-65435 mesh Enabled (0 ), id-range:1-999 . . . [ output omitted ]

As MPLS traffic-eng is not enabled globally, the ISIS will NOT be to create the constraint links. P2# sh isis mpl traffic-eng advertisements System ID: P2.00 Router ID: 172.17.0.2 Link Count: 0


Some MPLS and MPLS/VPN issues CEF disabled – Labels will be not allocated Symptoms: CE traffic will be droped when reach P router as it will be not labelled and P will not have any information about CE prefixes. You will be enabled to see all ldp outputs including LIB, but you will not see anything in L FIB due to it needs CEF enabled. PE-4# sh mpl ldp bindings tib entry: 172.16.18.0/30, rev 64 remote binding: tsr: 172.17.0.2:0, remote binding: tsr: 172.17.0.5:0, tib entry: 172.16.36.0/30, rev 65 remote binding: tsr: 172.17.0.2:0, remote binding: tsr: 172.17.0.5:0, tib entry: 172.16.67.0/30, rev 66 remote binding: tsr: 172.17.0.5:0, remote binding: tsr: 172.17.0.2:0, tib entry: 172.17.0.3/32, rev 71 remote binding: tsr: 172.17.0.2:0, . . . [ output omitted ]

tag: 28 tag: 40 tag: 18 tag: 38 tag: 41 tag: 38 tag: 16

PE-4# sh mpl forwarding-table Tag switching is not operational. CEF or tag switching has not been enabled. Local Outgoing Prefix Bytes tag tag tag or VC or Tunnel Id switched

Outgoing interface

Next Hop

PE-4# sh cef int CEF not running

Issues with LDP adjacency Possible cause: LDP-id is not been propagated via IGP, if LDP-id is configured to use loopback address. Neighbor does not have LDP enabled. ACL applied on interface which denies LDP packets (LDP uses TCP and UDP). PE-4# sh mpl int Interface Serial0/0

IP Yes (ldp)

Serial1/0

Yes (ldp)

Tunnel Yes Yes

Operational Yes Yes

PE-4# sh mpl ldp discovery Local LDP Identifier: 172.17.0.4:0 Discovery Sources: Interfaces: Serial0/0 (ldp): xmit/recv LDP Id: 172.17.0.2:0

No LDP received on Serial 1/0 interface

Serial1/0 (ldp): xmit July 10 A printed copy of this document is considered uncontrolled.

CE prefixes are in FIB vrf but not in BGP vrf database Possible cause: CE-PE routing prefixes are not redistributed under BGP address-family vrf.

PE-4# sh ip route vrf VPN ospf Routing Table: VPN 172.17.0.0/32 is subnetted, 4 subnets O 172.17.8.84 [110/97] via 10.40.31.6, 00:00:09, Serial2/0 O 172.17.8.83 [110/49] via 10.40.31.6, 00:00:09, Serial2/0 10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks O 10.40.31.0/30 [110/96] via 10.40.31.6, 00:00:09, Serial2/0 PE-4#

PE-4# sh ip bgp vpn vrf VPN 172.17.8.84 % Network not in table PE-4#

PE-4# sh ip bgp vpn vrf VPN 172.17.8.83 % Network not in table PE-4#

PE-4# sh ip bgp vpn vrf VPN 10.40.31.0 % Network not in table

Remote CE prefixes are not received Symptoms: Prefixes maybe in Generic BGP database, however they are not in BGP vrf database. Possible cause: The vrf is not importing the right RT.

PE-4# sh ip route vrf VPN Routing Table: VPN Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR Gateway of last resort is not set

C O O C O

4.0.0.0/32 is subnetted, 1 subnets 4.4.4.4 is directly connected, Loopback1 172.17.0.0/32 is subnetted, 2 subnets 172.17.8.84 [110/97] via 10.40.31.6, 00:04:26, Serial2/0 172.17.8.83 [110/49] via 10.40.31.6, 00:04:26, Serial2/0 10.0.0.0/30 is subnetted, 2 subnets 10.40.31.4 is directly connected, Serial2/0 10.40.31.0 [110/96] via 10.40.31.6, 00:04:26, Serial2/0


PE-4# sh ip bgp vpn vrf VPN BGP table version is 527, local router ID is 172.17.0.4 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 25135:133001804 (default for vrf VPN) *> 4.4.4.4/32 0.0.0.0 100 32768 i *> 10.40.31.0/30 10.40.31.6 96 32768 ? *> 10.40.31.4/30 0.0.0.0 0 32768 ? *> 172.17.8.83/32 10.40.31.6 49 32768 ? *> 172.17.8.84/32 10.40.31.6 97 32768 ?

PE-4# sh ip bgp vpn all BGP table version is 886, local router ID is 172.17.0.4 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Route Distinguisher: 0:0 *> 4.4.4.4/32 0.0.0.0 *>i5.5.5.5/32 172.17.0.5 *>i6.6.6.6/32 172.17.0.6 *>i7.7.7.7/32 172.17.0.7 *>i10.33.31.0/30 172.17.0.6 * i 172.17.0.7 *>i10.33.31.0/24 172.17.0.7 *>i10.33.31.4/30 172.17.0.6 * i 172.17.0.7 . . . [ output omitted ]

Metric LocPrf Weight Path 100 100 100 100 96 96 0 0 144

100 100 100 100 100 100 100 100

32768 0 0 0 0 0 0 0 0

i i i i ? ? 1 i ? ?

PE-4# sh run | i ip vrf|^ route-target import|^ import-map ip vrf IMCH

Neither route-target import nor import-map

ip vrf VPN ip vrf rrr

route-target import 212.183.144.1:18 ip vrf forwarding VPN ip vrf forwarding VPN

Because there is at least a vrf importing 212.182.144.1:18 route-target, we can see these prefixes on “global bgp database” otherwise the BGP process will drop these pr efixes.

PE-4# sh ip bgp vpn all 10.33.31.0 BGP routing table entry for 25135:133001806:10.33.31.0/30, version 1227 Bestpath Modifiers: missing-med-worst, always-compare-med, deterministic-med Paths: (2 available, best #1, no table) Flag: 0x820 Not advertised to any peer Local 172.17.0.6 (metric 30) from 172.17.0.8 (172.17.0.8) Origin incomplete, metric 96, localpref 100, valid, internal, best Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200 RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:6.6.6.6:512 Originator: 172.17.0.6, Cluster list: 0.0.0.1, mpls labels in/out nolabel/47 Local


In case there is not any vrf importing this RT it will not be any VPNv4 prefixes BGP global database. In this lab we have only one VRF which is exporting and importing the same route-target: 212.183.144.1:18 and 25135:18. Without any import the BGP global database will be empty even those the RRs are advertising all VPNv4 prefixes.

PE-4# sh run | i ip vrf VPN| route-target| e ip vrf forwarding ip vrf VPN route-target export 25135:18 route-target export 212.183.144.1:18

It did not accept any VPNv4 prefixes. Reasons:

PE-4# sh ip bgp vpn all sum BGP router identifier 172.17.0.4, local AS number 25135 BGP table version is 4018, main routing table version 4018 5 network entries using 665 bytes of memory 5 path entries using 340 bytes of memory 11/5 BGP path/bestpath attribute entries using 1452 bytes of memory 1 BGP rrinfo entries using 24 bytes of memory 3 BGP extended community entries using 144 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 2625 total bytes of memory BGP activity 103/98 prefixes, 257/252 paths, scan interval 15 secs Neighbor State/PfxRcd

V

AS MsgRcvd MsgSent

172.17.0.8 172.17.0.9

4 25135 4 25135

279840 279840

TblVer

87206 87206

4018 4018

There isn‟t vrf import prefixes which RT value advertised by these neighbours. Or there is a inbound filter denying all prefixes, such as routemap, prefix-list assigned to these neighbours. Or RR is not adversiting prefixes to PE-4.

InQ OutQ Up/Down

0 0

0 00:51:02 0 00:51:02

0 0

PE-4# sh ip bgp vpn all BGP table version is 4018, local router ID is 172.17.0.4 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 25135:133001804 (default for vrf VPN) *> 4.4.4.4/32 0.0.0.0 100 32768 i *> 10.40.31.0/30 10.40.31.6 96 32768 ? *> 10.40.31.4/30 0.0.0.0 0 32768 ? *> 172.17.8.83/32 10.40.31.6 49 32768 ? *> 172.17.8.84/32 10.40.31.6 97 32768 ?

RR1# sh ip bgp vpn all

Local prefixes only: learnt via local CE or genered via local BGP process (next-hop = 0.0.0.0

nei 172.17.0.4 adv

BGP table version is 253918, local router ID is 172.17.0.8 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Route Distinguisher: 25135:133001804 *>i4.4.4.4/32 172.17.0.4 *>i10.40.31.0/30 172.17.0.4 *>i10.40.31.4/30 172.17.0.4 *>i172.17.8.83/32 172.17.0.4 . . . [ output omitted ]

Metric LocPrf Weight Path 100 96 0 49

100 100 100 100


0 0 0 0

i ? ? ?

Route-reflector is not advertising VPNv4 prefixes Possible cause: Local PE has inbound filtering denying all VPNv4 prefixes. Route-reflector does not have route-reflector-client assigned to the neighbour. Route-reflector is not learning VPNv4 prefixes from other remote PEs.

RR1# sh ip bgp vpn all sum BGP router identifier 172.17.0.8, local AS number 25135 BGP table version is 208, main routing table version 208 19 network entries using 2527 bytes of memory 19 path entries using 1292 bytes of memory 17/16 BGP path/bestpath attribute entries using 2244 bytes of memory 1 BGP AS-PATH entries using 24 bytes of memory 4 BGP extended community entries using 204 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 6291 total bytes of memory BGP activity 97/78 prefixes, 110/91 paths, scan interval 15 secs AS MsgRcvd MsgSent

TblVer

Only 172.17.0.9 is configured as routereflector-client. However this neighbour is not adversiting any prefixes to RR1. All other neighbours now are normal iBGP.

Neighbor State/PfxRcd

V

InQ OutQ Up/Down

172.17.0.4 172.17.0.5 172.17.0.6 172.17.0.7

4 4 4 4

25135 25135 25135 25135

78 87354 92716 92754

278 280837 280837 280837

203 203 203 203

0 0 0 0

0 0 0 0

00:01:46 00:01:47 00:01:45 00:01:49

5 1 6 7

172.17.0.9 RR1#

4 25135

281058

280857

208

0

0 00:00:15

0

RR1# sh ip bgp vpn all n 172.17.0.4 adv Total number of prefixes 0

PE-4# sh ip bgp vpn all sum BGP router identifier 172.17.0.4, local AS number 25135 BGP table version is 4018, main routing table version 4018 5 network entries using 665 bytes of memory 5 path entries using 340 bytes of memory 16/5 BGP path/bestpath attribute entries using 2112 bytes of memory 2 BGP rrinfo entries using 48 bytes of memory No prefixes 4 BGP extended community entries using 204 bytes of memory received/learnt/accept. 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 3369 total bytes of memory BGP activity 103/98 prefixes, 257/252 paths, scan interval 15 secs Neighbor State/PfxRcd 172.17.0.8 172.17.0.9

V

AS MsgRcvd MsgSent

4 25135 4 25135

280902 281289

87435 87395

TblVer 4018 4018

InQ OutQ Up/Down 0 0


0 00:06:25 0 01:22:39

0 0

PE Node Failure If the destination PE failure the primary tunnel can not be established, then this will affect the services MPLS/VPN and AToM. Status before PE-7 failures:

Loopback 0 of CE-4

CE-1# sh ip route 172.17.8.52 Routing entry for 172.17.8.52/32 Known via "ospf 1", distance 110, metric 108, type inter area Last update from 10.40.31.5 on Serial1/0, 00:25:58 ago Routing Descriptor Blocks: * 10.40.31.5, from 4.4.4.4, 00:25:58 ago, via Serial1/0 Route metric is 108, traffic share count is 1

CE-1# trace 172.17.8.52 Type escape sequence to abort. Tracing the route to 172.17.8.52

Link between PE7 and CE-4 1 2 3 4 5

10.40.31.5 20 msec 20 msec 20 msec 172.19.24.1 36 msec 20 msec 20 msec 172.19.23.2 16 msec 32 msec 20 msec 172.19.32.2 16 msec 20 msec 16 msec 10.33.31.9 20 msec 20 msec 20 msec

6 10.33.31.10 20 msec *

20 msec

PE-4# sh ip route vrf VPN 172.17.8.52 Routing entry for 172.17.8.52/32 BGP next-hop: Known via "bgp 25135", distance 200, metric 49, type internal PE-7 Redistributing via ospf 1 and CE-4 Advertised by ospf 1 metric 60 metric-type 1 subnets route-map vpn Last update from 172.17.0.7 00:00:11 ago Routing Descriptor Blocks: * 172.17.0.7 (Default-IP-Routing-Table), from 172.17.0.8, 00:00:11 ago Route metric is 49, traffic share count is 1 AS Hops 0, BGP network version 0

Status as soon as PE7 reloads. PE-4# sh ip route vrf VPN 172.17.8.52 Routing entry for 172.17.8.52/32 BGP next-hop: Known via "bgp 25135", distance 200, metric 97, type internal PE-6 Redistributing via ospf 1 and CE-4 Advertised by ospf 1 metric 60 metric-type 1 subnets route-map vpn Last update from 172.17.0.6 00:01:21 ago Routing Descriptor Blocks: * 172.17.0.6 (Default-IP-Routing-Table), from 172.17.0.8, 00:01:21 ago Route metric is 97, traffic share count is 1 AS Hops 0, BGP network version 0


Tunnel which destines to PE7 is down. PE-4# sh ip int bri Interface Protocol Serial0/0 Serial1/0 Serial2/0 Auto-Template1 Loopback0 Loopback1 Tunnel1 Tunnel2

IP-Address

OK? Method Status

172.19.24.2 172.19.45.1 10.40.31.5 172.17.0.4 172.17.0.4 4.4.4.4 172.17.0.4 172.17.0.4

YES YES YES YES YES YES YES YES

NVRAM NVRAM NVRAM unset NVRAM NVRAM unset unset

up up up up up up up up

up up up up up up up up

Tunnel3

172.17.0.4

YES unset

up

down

Tunnel60000 Tunnel60001 Tunnel60002

172.17.0.4 172.17.0.4 172.17.0.4

YES unset YES unset YES unset

up up up

up up up

CE-1# ping Protocol [ip]: Target IP address: 172.17.8.52 Repeat count [5]: 10000 Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 10000, 100-byte ICMP Echos to 172.17.8.52, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! . . . [ output omitted ] Success rate is 99 percent (9998/10000), round-trip min/avg/max = 8/22/440 ms

Two packets were lost. However in real lab scenario there is not packet loss.

CE-1# sh ip route 172.17.8.52 Routing entry for 172.17.8.52/32 Known via "ospf 1", distance 110, metric 108, type inter area Last update from 10.40.31.5 on Serial1/0, 00:46:40 ago Routing Descriptor Blocks: * 10.40.31.5, from 4.4.4.4, 00:46:40 ago, via Serial1/0 Route metric is 108, traffic share count is 1

From CE-1 perspective, there is no change of on the prefix (metric and neighbour).

PE-CE Link Failure This case is the same as PE Node failure affecting the services directly: MPLS/VPN and AToM.


RR Node Failure This case of failure will not affect TE as the Destination tunnel IP addresses are learnt via ISIS. Status before RR failure: PE-4# sh ip route vrf VPN 172.17.8.52 Routing entry for 172.17.8.52/32 Known via "bgp 25135", distance 200, metric 49, type internal Redistributing via ospf 1 RR1 Advertised by ospf 1 metric 60 metric-type 1 subnets route-map vpn Last update from 172.17.0.7 00:01:16 ago Routing Descriptor Blocks: * 172.17.0.7 (Default-IP-Routing-Table), from 172.17.0.8, 00:01:16 ago Route metric is 49, traffic share count is 1 AS Hops 0, BGP network version 0

PE-4# trace vrf VPN 172.17.8.52 Type escape sequence to abort. Tracing the route to 172.17.8.52

1 2 3 4 5

172.19.24.1 [MPLS: Labels 55/34 Exp 0] 48 172.19.23.2 [MPLS: Labels 53/34 Exp 0] 28 172.19.32.2 [MPLS: Labels 48/34 Exp 0] 32 10.33.31.9 [MPLS: Label 34 Exp 0] 28 msec 10.33.31.10 44 msec * 48 msec

msec 32 msec 28 msec 32 28 msec

msec 52 msec msec 48 msec msec 32 msec 32 msec Path did not change after RR failure

Status as soon as RR failure: PE-4# traceroute

vrf VPN 172.17.8.52

Type escape sequence to abort. Tracing the route to 172.17.8.52

1 2 3 4 5

172.19.24.1 [MPLS: Labels 55/34 Exp 0] 20 172.19.23.2 [MPLS: Labels 53/34 Exp 0] 28 172.19.32.2 [MPLS: Labels 48/34 Exp 0] 28 10.33.31.9 [MPLS: Label 34 Exp 0] 24 msec 10.33.31.10 20 msec * 28 msec

msec 32 msec 28 msec 56 20 msec

msec 28 msec msec 20 msec msec 20 msec 44 msec

PE-4# sh ip route vrf VPN 172.17.8.52 Routing entry for 172.17.8.52/32 Known via "bgp 25135", distance 200, metric 49, type internal Redistributing via ospf 1 RR2 Advertised by ospf 1 metric 60 metric-type 1 subnets route-map vpn Last update from 172.17.0.7 00:00:42 ago Routing Descriptor Blocks: * 172.17.0.7 (Default-IP-Routing-Table), from 172.17.0.9, 00:00:42 ago Route metric is 49, traffic share count is 1 AS Hops 0, BGP network version 0

RR is not in data path. Control plane database replaces the BGP prefixes using the backup information already in BGP vrf database (due to maximum-path import 8 command, prefixes learnt via other routereflector will be in BGP vrf database). PE-4# ping vrf VPN Protocol [ip]: Target IP address: 172.17.8.52 Repeat count [5]: 10000 Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 10000, 100-byte ICMP Echos to 172.17.8.52, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! . . . [ output omitted ]

Success rate is 100 percent (10000/10000), round-trip min/avg/max = 20/33/48 ms July 10 A printed copy of this document is considered uncontrolled.

The following failure scenarios were created based on lab topology as per Figure 12 in page 140.

Link Failure Checking the status before failures: PE4-PEXKS01#sh mpls traffic-en auto-tunnel mesh | i 172.17.0.7 172.17.0.7 Tunnel2 In this case, the primary tunnel from PE4 to PE7 is tunnel 2. PE4-PEXKS01# sh mpl traffic-eng tun tun 2 Load for five secs: 0%/0%; one minute: 0%; five minutes: 0% Time source is NTP, 11:53:53.019 GMT Fri Mar 2 2007 Name: PE4-PEXKS01_t2 (Tunnel2) Destination: 172.17.0.7 Status:

Admin: up

Oper: up

Path: valid

Tunnel Operational and Path Valid


path option 1, type dynamic (Basis for Setup, path weight 1401) Config Parameters: Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based auto-bw: (86400/84510) 0 Bandwidth Requested: 100 Active Path Option Parameters: State: dynamic path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled InLabel : OutLabel : GigabitEthernet3/2, 82 Path: PE4 P2P3P32PE7 FRR OutLabel : Tunnel60006, 112 RSVP Signalling Info: Src 172.17.0.4, Dst 172.17.0.7, Tun_Id 2, Tun_Instance 3069 RSVP Path Info: My Address: 172.17.0.4 Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.1

172.17.0.7 Record Route: Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits RSVP Resv Info: Record Route: 172.17.0.2(82) 172.19.23.1( 82) Check these labels with trace mpls traffic-eng 172.17.0.3(112) 172.19.32.1( 112) command. 172.17.0.32(112) 172.19.137.2( 112) 172.17.0.7(0) 172.19.137.1( 0) Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits Shortest Unconstrained Path Info: Path Weight: 1401 (TE) Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.1 172.17.0.7 History: Tunnel: Time since created: 23 hours, 24 minutes Time since path change: 27 minutes, 56 seconds Number of LSP IDs (Tun_Instances) used: 2831 Current LSP: Uptime: 27 minutes, 56 seconds Prior LSP: ID: path option 1 [3062] Removal Trigger: path option updated


Verifying the data path: PE4-PEXKS01# trace mpl tra tu 2 Tracing MPLS TE Label Switched Path on Tunnel2, timeout is 2 seconds Codes: '!' '.' 'R' 'M'

-

success, 'Q' - request not transmitted, timeout, 'U' - unreachable, downstream router but not target, malformed request

Type escape sequence to abort. 0 172.19.24.2 MRU 4470 [Labels: 82 Exp: 0] R 1 172.19.24.1 MRU 4470 [Labels: 112 Exp: 0] 3 ms R 2 172.19.23.2 MRU 4470 [Labels: 112 Exp: 0] 4 ms R 3 172.19.32.2 MRU 4474 [ implicit-null] 5 ms ! 4 172.19.137.1 2 ms

Check the labels are the same as describe in the output of previous command (show mpls traff tu tu2). Checking these labels in other routers along t his path: P2# sh mpl forw | i 82 66

40

172.17.0.53/32

9827251

Gi2/0/4

172.19.31.2

82

112

172.17.0.4 2 [3069] 92245

Gi3/0/0

84 89

82 106

172.17.0.31 60000 [5530] 0 172.17.0.6 2 [6278] 28118225

Gi2/0/2 172.19.24.2 Gi2/0/4 172.19.31.2

172.19.23.2

The labelled packet comes from PE4 which uses tunnel2 (PE4 primary tunnel toward to PE7) should use label 82. Then based on this information we are checking which label will be used to forward the packet to the next hop. P3# sh mpl forw | i 112 49

45

10.59.27.112/30

0

Gi3/0/0

112 112 172.17.0.4 2 [3069] 96047 Gi2/0/4 By coincidence in P3 the incoming label is the same as outgoing label.

172.19.23.1

172.19.32.2

P32> sh mpl forw | i 112 61

49 58

10.59.27.112/30 10.59.27.112/30

0 0

Gi3/0 PO2/0

172.19.32.1 point2point

112 Pop tag 172.17.0.4 2 [3069] 106274 Gi3/2 172.19.137.1 Due to P32 is a Penultimate Hop Popping (PHP) from this point toward to PE7, the packet which belongs to PE4-tunnel 2 will not have MPLS/TE label. PE4-PEXKS01# sh mpl traff tun tu 2 protection Load for five secs: 1%/0%; one minute: 0%; five minutes: 0% Time source is NTP, 11:58:21.219 GMT Fri Mar 2 2007 PE4-PEXKS01_t2 LSP Head, Tunnel2, Admin: up, Oper: up Src 172.17.0.4, Dest 172.17.0.7, Instance 3069 Fast Reroute Protection: Requested Outbound: FRR Ready Backup Tu60006 to LSP nnhop Tu60006: out i/f: Gi3/3, label: 249 LSP signalling info: Tail-end for this backup tunnel (2 Original: out i/f: Gi3/2, label: 82, nhop: 172.19.24.1 hops way from nnhop: 172.17.0.3, nnhop rtr id: 172.17.0.3 With FRR: out i/f: Tu60006, label: 112 LSP bw: 100 kbps, Backup level: any-unlim, type: any pool Path Protection: None

Tunnel 60006 is the backup tunnel for PE4-tunnel 2 in case of P2-node failure and also in case of link failure between PE4 and P2.


PE4-PEXKS01# sh mpl traf tu tu 60006 Load for five secs: 0%/0%; one minute: 0%; five minutes: 0% Time source is NTP, 11:59:45.383 GMT Fri Mar 2 2007 Name: PE4-PEXKS01_t60006 Status:

Admin: up


Oper: up

Path: valid


path option 1, type explicit __dynamic_tunnel60006 (Basis for Setup, path weight 1401) Config Parameters: Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: disabled LockDown: disabled Loadshare: 0 bw-based auto-bw: disabled Active Path Option Parameters: State: explicit path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled InLabel : OutLabel : GigabitEthernet3/3, 249 RSVP Signalling Info: Src 172.17.0.4, Dst 172.17.0.3, Tun_Id 60006, Tun_Instance 1 RSVP Path Info: My Address: 172.17.0.4 Explicit Route: 172.19.45.2 172.19.53.10 172.16.131.2 172.19.32.1

172.17.0.3 Record Route: NONE Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits RSVP Resv Info: Record Route: NONE Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits Shortest Unconstrained Path Info: Path Weight: 680 (TE) Explicit Route: 172.19.24.1 172.19.23.2 172.17.0.3 History: Tunnel: Time since created: 37 minutes, 37 seconds Time since path change: 37 minutes, 11 seconds Number of LSP IDs (Tun_Instances) used: 1 Current LSP: Uptime: 37 minutes, 11 seconds

Backup tunnel path: PE4



PE4  P31  P32




P3



PE5   P31



P32   P3.

P1

Node Protected for this tunnel PE-4 – T60006

Next-Next -Hop

PE4

P2

P3

PE6

P32

PE7

P30

PE5

P31


Link failure between P2 and PE4:

2nd checking: Status did NOT change!

PE4-PEXKS01# sh mpl traff tun tu 2 Load for five secs: 1%/0%; one minute: 1%; five minutes: 0% Time source is NTP, 12:05:02.097 GMT Fri Mar 2 2007 Name: PE4-PEXKS01_t2 (Tunnel2) Destination: 172.17.0.7 Status: Admin: up Oper: up Path: valid Signalling: connected path option 1, type dynamic (Basis for Setup, path weight 1401) Change in required resources detected: reroute pending Currently Signalled Parameters: Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF 4th checking: In back ground it is Metric Type: TE (default)

path option 1 reoptimization in progress

being calculated the new path for primary tunnel. This occurs due to the dynamic path configuration and reoptimaztion path being Affinity: 0x0/0xFFFF enabled.

Config Parameters: Bandwidth: 100 kbps (Global) Priority: 4 4 Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based auto-bw: (86400/83841) 0 Bandwidth Requested: 100 Active Path Option Parameters: State: dynamic path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled st

1 checking: Backup InLabel : tunnel in used. Check OutLabel : GigabitEthernet3/2, 82 the trace mpls FRR OutLabel : Tunnel60006, 112 (in use) command output in the RSVP Signalling Info: next path. Src 172.17.0.4, Dst 172.17.0.7, Tun_Id 2, Tun_Instance 3069 RSVP Path Info: My Address: 172.17.0.4 Explicit Route: 172.17.0.3 172.19.32.2 172.19.137.1 172.17.0.7 Record Route: Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits RSVP Resv Info: 3rd checking: Check the Record

Route:

172.17.0.2(82) 172.19.23.1(82) 172.17.0.3(112) 172.19.32.1(112) 172.17.0.32(112) 172.19.137.2(112) 172.17.0.7(0) 172.19.137.1(0)

primary tunnel path did NOT change even though the link PE4  P2 is down. When the backup tunnel is in

Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100used kbits we can NOT check the Shortest Unconstrained Path Info: full path in only one show Path Weight: 1960 (TE) command. Explicit Route: 172.19.45.2 172.19.53.10 172.16.131.2 172.19.137.1 172.17.0.7 History: Tunnel: Time since created: 23 hours, 36 minutes Time since path change: 39 minutes, 4 seconds Number of LSP IDs (Tun_Instances) used: 2853 Current LSP: Uptime: 39 minutes, 4 seconds Reopt. LSP: Uptime: 1 seconds Prior LSP: ID: path option 1 [3062] Removal Trigger: path option updated


PE4-PEXKS01# trace mpl tra tu 2 Tracing MPLS TE Label Switched Path on Tunnel2, timeout is 2 seconds

The backupCodes: tunnel label is the top of label stack.

'!' '.' 'R' 'M'

-


These 4 “112” value are the same. It is in the bottom of the label stack. It is being encapsulated into backup tunnel.

Type escape sequence to abort. 0 172.19.45.1 MRU 4466 [Labels: 249/ 112 Exp: 0/0] U 1 172.19.45.2 MRU 4470 [Labels: 117/ 112 Exp: 0/0] 5 ms U 2 172.19.53.10 MRU 4470 [Labels: 110/ 112 Exp: 0/0] 2 ms R 3 172.16.131.2 MRU 4474 [Labels: 112 Exp: 0] 3 ms

R 4 172.19.32.1 MRU 4470 [Labels: 112 Exp: 0] 3 ms

P3 node

R 5 172.19.32.2 MRU 4474 [implicit-null] 4 ms ! 6 172.19.137.1 5 ms

The path is: PE4



PE5  P31 P32  P3  P32

Why the packet passed P32



PE7

P3 link twice? P1

Next-Next -Hop

PE4

P2

P3

PE6

P32

PE7

P30

PE5

P31

The final destination of backup tunnel is P3. So, P3 is the rendezvous point between backup tunnel and the original path of primary tunnel after the failure.

A couple of seconds later the primary tunnel has the new path. PE4-PEXKS01# trace mpl tra tu 2 Tracing MPLS TE Label Switched Path on Tunnel2, timeout is 2 seconds Codes: '!' '.' 'R' 'M'

-



The path is PE4  PE5 the PE4-tunnel2.



P31



P32



PE7. As you have checked, P3 is not longer a hop for

Let‟s check the new information of PE4 -tunnel 2 information.


PE4-PEXKS01# sh mpl traff tun tu 2 Load for five secs: 1%/0%; one minute: 0%; five minutes: 0% Time source is NTP, 12:06:33.772 GMT Fri Mar 2 2007 Name: PE4-PEXKS01_t2 (Tunnel2) Destination: 172.17.0.7 Status:

Admin: up

Oper: up

Path: valid


path option 1, type dynamic (Basis for Setup, path weight 1960) Config Parameters: Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF Tunnel NEVER Metric Type: TE (default) went down. AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based auto-bw: (86400/83749) 0 Bandwidth Requested: 100 Active Path Option Parameters: State: dynamic path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled InLabel : OutLabel : GigabitEthernet3/3, 25 New path RSVP Signalling Info: Src 172.17.0.4, Dst 172.17.0.7, Tun_Id 2, Tun_Instance 3148 RSVP Path Info: My Address: 172.17.0.4 Explicit Route: 172.19.45.2 172.19.53.10 172.16.131.2 172.19.137.1

172.17.0.7 Record Route: Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits New LSP labels RSVP Resv Info: – Check with Record Route: 172.17.0.5(25) 172.19.53.9( 25) previous 172.17.0.31(81) 172.16.131.1( 81) command (trace 172.17.0.32(86) 172.19.137.2( 86) mpls traffic172.17.0.7(0) 172.19.137.1( 0) Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits eng). Shortest Unconstrained Path Info: Path Weight: 1960 (TE) Explicit Route: 172.19.45.2 172.19.53.10 172.16.131.2 172.19.137.1 172.17.0.7 History: Tunnel: Tunnel NEVER Time since created: 23 hours, 37 minutes went down. Time since path change: 1 minutes, 29 seconds These figures can prove only Number of LSP IDs (Tun_Instances) used: 2856 the path has Current LSP: changed. Uptime: 1 minutes, 32 seconds Selection: reoptimization Prior LSP: ID: path option 1 [3069]

Removal Trigger: re-route path error P1

PE4

P2

P3

PE6

P32

PE7

P30

PE5

P31


Link failure between P2 and P3 PE4-PEXKS01# sh mpl traff tun tu 2 Load for five secs: 0%/0%; one minute: 0%; five minutes: 0% Time source is NTP, 12:27:15.007 GMT Fri Mar 2 2007 Name: PE4-PEXKS01_t2 (Tunnel2) Destination: 172.17.0.7 Status: Admin: up Oper: up Path: valid Signalling: connected path option 1, type dynamic (Basis for Setup, path weight 1401)

Change in required resources detected: reroute pending Currently Signalled Parameters: Bandwidth: 100 kbps (Global) 0x0/0xFFFF Metric Type: TE (default)

Priority: 4


4

Affinity:

In back ground it is being calculated the new path for primary tunnel.

Config Parameters: Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based auto-bw: (86400/82508) 1418 Bandwidth Requested: 100 Active Path Option Parameters: State: dynamic path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled InLabel : OutLabel : GigabitEthernet3/2, 124 No information this FRR OutLabel : Tunnel60006, 108 backup tunnel being in RSVP Signalling Info: used. Src 172.17.0.4, Dst 172.17.0.7, Tun_Id 2, Tun_Instance 3158 RSVP Path Info: My Address: 172.17.0.4 Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.1 172.17.0.7 Record Route: Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits RSVP Resv Info: Record Route: 172.17.0.2(124) 172.19.23.1(124) 172.17.0.3(108) 172.19.32.1(108) 172.17.0.32(96) 172.19.137.2(96) 172.17.0.7(0) 172.19.137.1(0) Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits Shortest Unconstrained Path Info: Path Weight: 1401 (TE) Explicit Route: 172.19.24.1 172.19.31.2 172.16.131.2 172.19.137.1 172.17.0.7 History: Tunnel: Time since created: 23 hours, 58 minutes Time since path change: 16 minutes, 59 seconds Number of LSP IDs (Tun_Instances) used: 2897 Current LSP: Uptime: 17 minutes, 2 seconds Selection: reoptimization Reopt. LSP: Setup Time: 4 minutes, 55 seconds remaining Prior LSP: ID: path option 1 [3148] Removal Trigger: reoptimization completed


PE4-PEXKS01# trace mpl tra tu 2 Tracing MPLS TE Label Switched Path on Tunnel2, timeout is 2 seconds Codes: '!' '.' 'R' 'M'

-

success, 'Q' - request not transmitted, timeout, 'U' - unreachable, The backup tunnel label downstream router but not target, is the top of label stack. malformed request

Type escape sequence to abort. 0 172.19.24.2 MRU 4470 [Labels: 124 Exp: 0] R 1 172.19.24.1 MRU 4466 [Labels: 84/96 Exp: 0/0] 4 ms U 2 172.19.31.2 MRU 4474 [Labels: 96 Exp: 0] 1 ms R 3 172.16.131.2 MRU 4474 [implicit-null] 2 ms ! 4 172.19.137.1 3 ms

P31 is PHP, so it is being removed the backup label of label stack.

The backup tunnel activated here is P3-node protection. The rendezvous point between primary and backup P3 link twice? tunnels is P32. Why the packet didn‟t pass P32 P1

PE4

P2

Node protected.

P3

PE6

P32

PE7

P30

PE5

P31

The rendezvous point between primary and backup tunnels is P32. After the path re-calculation . . . Note the path is the same, however there is only one label per hop. PE4-PEXKS01# trace mpl tra tu 2 Tracing MPLS TE Label Switched Path on Tunnel2, timeout is 2 seconds Codes: '!' '.' 'R' 'M'

-


Type escape sequence to abort. 0 172.19.24.2 MRU 4470 [Labels: 91 Exp: R 1 172.19.24.1 MRU 4470 [Labels: 91 Exp: R 2 172.19.31.2 MRU 4470 [Labels: 94 Exp: R 3 172.16.131.2 MRU 4474 [ implicit-null] ! 4 172.19.137.1 3 ms

0] 0] 4 ms 0] 1 ms 2 ms

P1

PE4

P2

P3

PE6

P32

PE7

P30

PE5

P31


PE4-PEXKS01# sh mpl traff tun tu 2 Load for five secs: 0%/0%; one minute: 1%; five minutes: 0% Time source is NTP, 12:28:08.869 GMT Fri Mar 2 2007 Name: PE4-PEXKS01_t2 Status:

Admin: up


Oper: up

Path: valid


path option 1, type dynamic (Basis for Setup, path weight 1401) Config Parameters: Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based auto-bw: (86400/82454) 1418 Bandwidth Requested: 100 Active Path Option Parameters:

State: dynamic path option 1 is active BandwidthOverride: disabled

LockDown: disabled

Verbatim: disabled

InLabel : OutLabel : GigabitEthernet3/2, 91 FRR OutLabel : Tunnel60007, 91 RSVP Signalling Info: Src 172.17.0.4, Dst 172.17.0.7, Tun_Id 2, Tun_Instance 3192 RSVP Path Info: My Address: 172.17.0.4 Explicit Route: 172.19.24.1 172.19.31.2 172.16.131.2 172.19.137.1

172.17.0.7 Record Route: Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits RSVP Resv Info: Record Route: 172.17.0.2(91) 172.19.31.1( 91) 172.17.0.31(91) 172.16.131.1( 91) New Path information 172.17.0.32(94) 172.19.137.2( 94) 172.17.0.7(0) 172.19.137.1( 0) Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits Shortest Unconstrained Path Info: Path Weight: 1401 (TE) Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.1 172.17.0.7 History: Tunnel: Time since created: 23 hours, 59 minutes Time since path change: 35 seconds Number of LSP IDs (Tun_Instances) used: 2898 Current LSP: Uptime: 38 seconds Selection: reoptimization Prior LSP: ID: path option 1 [3158]

Removal Trigger: re-route path error


Link failure between P3 and P32 Before link failure: PE4-PEXKS01# trace mpl tra tu 2 Tracing MPLS TE Label Switched Path on Tunnel2, timeout is 2 seconds Codes: '!' - success, 'Q' - request not transmitted, '.' - timeout, 'U' - unreachable, 'R' - downstream router but not target, 'M' - malformed request Type escape sequence to abort. 0 172.19.24.2 MRU 4470 [Labels: 141 Exp: 0] R 1 172.19.24.1 MRU 4470 [Labels: 142 Exp: 0] 4 ms R 2 172.19.23.2 MRU 4470 [Labels: 112 Exp: 0] 1 ms R 3 172.19.32.2 MRU 4474 [ implicit-null] 2 ms ! 4 172.19.137.1 3 ms

PE4  P2  P3  P32  PE7

After link failure: PE4-PEXKS01# trace mpl tra tu 2 Tracing MPLS TE Label Switched Path on Tunnel2, timeout is 2 seconds Codes: '!' - success, 'Q' - request not transmitted, '.' - timeout, 'U' - unreachable, 'R' - downstream router but not target, 'M' - malformed request Because P32 is the last Type escape sequence to abort. node to reach PE7 for the 0 172.19.24.2 MRU 4470 [Labels: 141 Exp: 0] primary tunnel, we do R 1 172.19.24.1 MRU 4470 [Labels: 142 Exp: 0] 4 ms NOT see two labels in R 2 172.19.23.2 MRU 4470 [Labels: 102 Exp: 0] 2 ms label stack.

U 3 172.16.36.2 MRU 4474 [implicit-null] 3 ms ! 4 172.16.67.2 4 ms P1

PE4

P2

P3

PE6

P32

PE7

P30

PE5

P31

After reoptimisation: PE4-PEXKS01# trace mpl tra tu 2 Tracing MPLS TE Label Switched Path on Tunnel2, timeout is 2 seconds Codes: '!' - success, 'Q' - request not transmitted, '.' - timeout, 'U' - unreachable, 'R' - downstream router but not target, 'M' - malformed request New Path PE4  P2 P31  P32 PE7 Type escape sequence to abort. 0 172.19.24.2 MRU 4470 [Labels: 100 Exp: 0] R 1 172.19.24.1 MRU 4470 [Labels: 97 Exp: 0] 1 ms R 2 172.19.31.2 MRU 4470 [Labels: 94 Exp: 0] 2 ms R 3 172.16.131.2 MRU 4474 [ implicit-null] 3 ms ! 4 172.19.137.1 4 ms


PE4-PEXKS01# sh mpl tra tu tu2 Load for five secs: 1%/0%; one minute: 1%; five minutes: 1% Time source is NTP, 12:52:50.286 GMT Fri Mar 2 2007

Name: PE4-PEXKS01_t2 (Tunnel2) Destination: 172.17.0.7 Status: Admin: up Oper: up Path: valid Signalling: connected path option 1, type dynamic (Basis for Setup, path weight 1401) Config Parameters: Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based auto-bw: (86400/86072) 0 Bandwidth Requested: 100 Active Path Option Parameters: State: dynamic path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled

InLabel : OutLabel : GigabitEthernet3/2, 141 FRR OutLabel : Tunnel60006, 142 RSVP Signalling Info: Src 172.17.0.4, Dst 172.17.0.7, Tun_Id 2, Tun_Instance 3240 RSVP Path Info: My Address: 172.17.0.4 LSP labels before link Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.1 failure. The same result

172.17.0.7

as the first trace mpls traffic-eng output in the Record Route: Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 previous kbits page. RSVP Resv Info: Record Route:

172.17.0.2(141) 172.19.23.1(141) 172.17.0.3(142) 172.19.32.1(142) 172.17.0.32(112) 172.19.137.2(112) 172.17.0.7(0) 172.19.137.1(0) Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits Shortest Unconstrained Path Info: Path Weight: 1401 (TE) Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.1 172.17.0.7 History: Tunnel: Time since created: 1 days, 23 minutes Time since path change: 1 minutes, 49 seconds Number of LSP IDs (Tun_Instances) used: 2949 Current LSP: Uptime: 1 minutes, 49 seconds Prior LSP: ID: path option 1 [3238] Removal Trigger: path option updated

The primary tunnel details before link failure.


Output during new path calculation, meanwhile the backup tunnel is be used: PE4-PEXKS01# sh mpl tra tu tu2 Load for five secs: 0%/0%; one minute: 0%; five minutes: 0% Time source is NTP, 13:07:29.591 GMT Fri Mar 2 2007 Name: PE4-PEXKS01_t2 (Tunnel2) Destination: 172.17.0.7 Status: Admin: up Oper: up Path: valid Signalling: connected path option 1, type dynamic (Basis for Setup, path weight 1401)

Change in required resources detected: reroute pending Currently Signalled Parameters: Bandwidth: 100 kbps (Global) Metric Type: TE (default)

Priority: 4

4


path option 1 reoptimization in progress . . . [ output omitted ]

As soon as the new path was defined: PE4-PEXKS01# sh mpl tra tu tu2 Load for five secs: 0%/0%; one minute: 0%; five minutes: 0% Time source is NTP, 13:07:51.831 GMT Fri Mar 2 2007 Name: PE4-PEXKS01_t2 (Tunnel2) Destination: 172.17.0.7 Status: Admin: up Oper: up Path: valid Signalling: connected path option 1, type dynamic (Basis for Setup, path weight 1401) path option 1, delayed clean in progress

Change in required resources detected: reroute pending Currently Signalled Parameters: Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF Metric Type: TE (default) Config Parameters: Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based auto-bw: (86400/85170) 0 Bandwidth Requested: 100 Active Path Option Parameters: State: dynamic path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled InLabel : OutLabel : GigabitEthernet3/2, 100 FRR OutLabel : Tunnel60007, 97 RSVP Signalling Info: Src 172.17.0.4, Dst 172.17.0.7, Tun_Id 2, Tun_Instance 3275 RSVP Path Info: My Address: 172.17.0.4 Explicit Route: 172.19.24.1 172.19.31.2 172.16.131.2 172.19.137.1 172.17.0.7 LSP labels new path Record Route: calculation due to link Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits failure. The same result RSVP Resv Info: as the third trace mpls Record Route: 172.17.0.2(100) 172.19.31.1(100) traffic-eng output in two 172.17.0.31(97) 172.16.131.1(97) page before. 172.17.0.32(94) 172.19.137.2(94) 172.17.0.7(0) 172.19.137.1(0) Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits Shortest Unconstrained Path Info: Path Weight: 1401 (TE) Explicit Route: 172.19.24.1 172.19.31.2 172.16.131.2 172.19.137.1 172.17.0.7 History: Tunnel:

Time since created: 1 days, 38 minutes Time since path change: 1 seconds Number of LSP IDs (Tun_Instances) used: 2980 Current LSP:

Uptime: 4 seconds . . . [ output omitted ]


Link failure between P32 and P7 Before link failure: PE4-PEXKS01# trace mpl tra tu 2 Tracing MPLS TE Label Switched Path on Tunnel2, timeout is 2 seconds Codes: '!' '.' 'R' 'M'

-


Type escape sequence to abort. 0 172.19.24.2 MRU 4470 [Labels: 106 Exp: R 1 172.19.24.1 MRU 4470 [Labels: 107 Exp: R 2 172.19.23.2 MRU 4470 [Labels: 124 Exp: R 3 172.19.32.2 MRU 4474 [ implicit-null] 1 ! 4 172.19.137.1 2 ms

0] 0] 3 ms 0] 4 ms ms

Path: PE4 P2  P3  P32  PE7

After link failure meanwhile the backup tunnel is being used: PE4-PEXKS01# trace mpl tra tu 2 Tracing MPLS TE Label Switched Path on Tunnel2, timeout is 2 seconds Codes: '!' '.' 'R' 'M'

-


Type escape sequence to abort. 0 172.19.24.2 MRU 4470 [Labels: 106 Exp: 0] R 1 172.19.24.1 MRU 4470 [Labels: 107 Exp: 0] 4 ms R 2 172.19.23.2 MRU 4470 [Labels: 124 Exp: 0] 1 ms

Link P32 P3 twice. Because P32 is PHP for the primary tunnel, we do NOT see two labels in label stack.

R 3 172.19.32.2 MRU 4470 [Labels: 104 Exp: 0] 1 ms R 4 172.19.32.1 MRU 4470 [Labels: 129 Exp: 0] 2 ms U 5 172.16.36.2 MRU 4474 [implicit-null] 3 ms ! 6 172.16.67.2 4 ms P1

PE4

P2

P3

PE6

P32

PE7

P30

PE5

P31


P Node Failure P2 failure Information before failure: PE4-PEXKS01# sh mpl traf tu tu 2 Load for five secs: 0%/0%; one minute: 0%; five minutes: 0% Time source is NTP, 13:17:25.224 GMT Fri Mar 2 2007 Name: PE4-PEXKS01_t2 Status:

Admin: up


Oper: up

Path: valid


path option 1, type dynamic (Basis for Setup, path weight 1401) Config Parameters: Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based auto-bw: (86400/86097) 0 Bandwidth Requested: 100 Active Path Option Parameters:


LockDown: disabled

Verbatim: disabled

InLabel : OutLabel : GigabitEthernet3/2, 63 FRR OutLabel : Tunnel60006, 90 RSVP Signalling Info: Src 172.17.0.4, Dst 172.17.0.7, Tun_Id 2, Tun_Instance 3294 RSVP Path Info: My Address: 172.17.0.4 Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.1

172.17.0.7 Record Route: Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits RSVP Resv Info: Record Route: 172.17.0.2(63) 172.19.23.1( 63) 172.17.0.3(90) 172.19.32.1( 90) 172.17.0.32(98) 172.19.137.2( 98) 172.17.0.7(0) 172.19.137.1( 0) Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits Shortest Unconstrained Path Info: Path Weight: 1401 (TE) Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.1 172.17.0.7 History: Tunnel: Time since created: 1 days, 48 minutes Time since path change: 23 seconds Number of LSP IDs (Tun_Instances) used: 3001 Current LSP: Uptime: 23 seconds Prior LSP: ID: path option 1 [3288] Removal Trigger: path option updated


PE4-PEXKS01# sh mpl traf tu tu 2 protection Load for five secs: 1%/0%; one minute: 0%; five minutes: 0% Time source is NTP, 13:18:07.368 GMT Fri Mar 2 2007 PE4-PEXKS01_t2 LSP Head, Tunnel2, Admin: up, Oper: up Src 172.17.0.4, Dest 172.17.0.7, Instance 3294 Fast Reroute Protection: Requested

Outbound: FRR Ready Backup Tu60006 to LSP nnhop Tu60006: out i/f: Gi3/3, label: 54 LSP signalling info: Original: out i/f: Gi3/2, label: 63, nhop: 172.19.24.1 nnhop: 172.17.0.3, nnhop rtr id: 172.17.0.3 With FRR: out i/f: Tu60006, label: 90 LSP bw: 100 kbps, Backup level: any-unlim, type: any pool Path Protection: None

PE4-PEXKS01# trace mpl tra tu 2 Tracing MPLS TE Label Switched Path on Tunnel2, timeout is 2 seconds Codes: '!' '.' 'R' 'M'

-



During P2 was reload we have the following result of traceroute, however the data traffic still was using the original path, as the line card didn‟t go down . This behaviour was checked with traffic generator. No packet loss. Due to this characteristic the backup tunnel was NOT used and before the line card went down, the primary tunnel had the new path. PE4-PEXKS01# trace mpl tra tu 2 Tracing MPLS TE Label Switched Path on Tunnel2, timeout is 2 seconds Codes: '!' '.' 'R' 'M'

-


Type escape sequence to abort. 0 172.19.24.2 MRU 4470 [Labels: 63 Exp: 0] . 1 * R 2 172.19.23.2 1 ms R 3 172.19.32.2 2 ms ! 4 172.19.137.1 3 ms


PE4-PEXKS01# sh mpl traf tu tu 2 Load for five secs: 1%/0%; one minute: 0%; five minutes: 0% Time source is NTP, 13:19:10.232 GMT Fri Mar 2 2007 Name: PE4-PEXKS01_t2 (Tunnel2) Destination: 172.17.0.7 Status:

Admin: up

Oper: up

Path: valid



Change in required resources detected: reroute pending Currently Signalled Parameters: Bandwidth: 100 kbps (Global) 0x0/0xFFFF Metric Type: TE (default)


Even though Data Plane the path can still Priority: 4 4 in Affinity:

be used; Control Plane received a signal to recalculate a new path. In the next pages there are some debug commands to identify this signal (ISIS flag; there is not RSVP flag for this ariticula case.

Config Parameters: Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based auto-bw: (86400/85992) 0 Bandwidth Requested: 100 Active Path Option Parameters: State: dynamic path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled InLabel : OutLabel : GigabitEthernet3/2, 63

FRR OutLabel : Tunnel60006, 90

Even though it is running the path calculation the backup tunnel is NOT in used. The data traffic is still using the path via P2 as the line card did NOT go down yet. We can NOT identify this behaviour using trace mpls command.

RSVP Signalling Info: Src 172.17.0.4, Dst 172.17.0.7, Tun_Id 2, Tun_Instance 3294 RSVP Path Info: My Address: 172.17.0.4 Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.1

172.17.0.7 Record Route: Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits RSVP Resv Info: Record Route: 172.17.0.2(63) 172.19.23.1(63) 172.17.0.3(90) 172.19.32.1( 90) 172.17.0.32(98) 172.19.137.2( 98) 172.17.0.7(0) 172.19.137.1( 0) Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits Shortest Unconstrained Path Info: Path Weight: 1960 (TE) Explicit Route: 172.19.45.2 172.19.53.10 172.16.131.2 172.19.137.1 172.17.0.7 History: Tunnel: Time since created: 1 days, 50 minutes Time since path change: 2 minutes, 8 seconds Number of LSP IDs (Tun_Instances) used: 3005 Current LSP: Uptime: 2 minutes, 8 seconds Reopt. LSP: Setup Time: 4 minutes, 57 seconds remaining Prior LSP: ID: path option 1 [3288] Removal Trigger: path option updated


After path calculation: PE4-PEXKS01# trace mpl tra tu 2 Tracing MPLS TE Label Switched Path on Tunnel2, timeout is 2 seconds Codes: '!' '.' 'R' 'M'

-


Type escape sequence to abort. 0 172.19.45.1 MRU 4470 [Labels: 26 Exp: 0] R 1 172.19.45.2 MRU 4470 [Labels: 97 Exp: 0] 3 ms R 2 172.19.53.10 MRU 4470 [Labels: 104 Exp: 0] 0 ms R 3 172.16.131.2 MRU 4474 [ implicit-null] 1 ms ! 4 172.19.137.1 2 ms P1

PE4

P2

P3

PE6

P32

PE7

P30

PE5

P31

PE4-PEXKS01# sh mpl traf tu tu 2 | b Explicit Route Explicit Route: 172.19.45.2 172.19.53.10 172.16.131.2 172.19.137.1 172.17.0.7 Record Route: Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits RSVP Resv Info: Record Route: 172.17.0.5(26) 172.19.53.9( 26) 172.17.0.31(97) 172.16.131.1( 97) 172.17.0.32(104) 172.19.137.2( 104) 172.17.0.7(0) 172.19.137.1( 0) Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits Shortest Unconstrained Path Info: Path Weight: 1960 (TE) Explicit Route: 172.19.45.2 172.19.53.10 172.16.131.2 172.19.137.1 172.17.0.7 History: Tunnel: Time since created: 1 days, 50 minutes Time since path change: 0 seconds Number of LSP IDs (Tun_Instances) used: 3005 Current LSP: Uptime: 3 seconds Selection: reoptimization Prior LSP: ID: path option 1 [3294] Removal Trigger: re-route path verification failed


PE4-PEXKS01# PE4-PEXKS01# PE4-PEXKS01# PE4-PEXKS01#

debug debug debug debug

isis isis isis isis

update-packets mpls traffic-eng events spf-triggers mpls traffig-eng adver

PE4-PEXKS01# 002614: Mar 2 18:08:37.094 GMT: %LDP-5-NBRCHG: LDP Neighbor 172.17.0.2:0 is

DOWN (TCP connection closed by peer) 002615: Mar 2 18:08:37.098 GMT: %MPLS_TE-5-LSP: LSP 172.17.0.4 60000_3635: DOWN: path verification failed 002616: Mar 2 18:08:37.098 GMT: %MPLS_TE-5-TUN: Tun60000: installed LSP nil for 60000_3635 (popt 1), path verification failed 002617: Mar 2 18:08:37.098 GMT: %MPLS_TE-5-TUN: Tun60000: LSP path change nil for 60000_3635, path verification failed 002618: Mar 2 18:08:37.098 GMT: %MPLS_TE-5-LSP: LSP 172.17.0.4 60002_2075: DOWN: path verification failed 002619: Mar 2 18:08:37.098 GMT: %MPLS_TE-5-TUN: Tun60002: installed LSP nil for 60002_2075 (popt 1), path verification failed 002620: Mar 2 18:08:37.098 GMT: %MPLS_TE-5-TUN: Tun60002: LSP path change nil for 60002_2075, path verification failed 002621: Mar 2 18:08:37.098 GMT: %MPLS_TE-5-LSP: LSP 172.17.0.4 60003_2075: DOWN: path verification failed 002622: Mar 2 18:08:37.098 GMT: %MPLS_TE-5-TUN: Tun60003: installed LSP nil for 60003_2075 (popt 1), path verification failed 002623: Mar 2 18:08:37.098 GMT: %MPLS_TE-5-TUN: Tun60003: LSP path change nil for 60003_2075, path verification failed 002624: Mar 2 18:08:37.098 GMT: %MPLS_TE-5-LSP: LSP 172.17.0.4 60005_884: DOWN: path verification failed 002625: Mar 2 18:08:37.098 GMT: %MPLS_TE-5-TUN: Tun60005: installed LSP nil for 60005_884 (popt 1), path verification failed 002626: Mar 2 18:08:37.098 GMT: %MPLS_TE-5-TUN: Tun60005: LSP path change nil for 60005_884, path verification failed 002627: Mar 2 18:08:37.102 GMT: RT: isis's 172.17.0.7/32 (via 0.0.0.115)

metric changed from distance/metric [-1408172025/1401] to [115/1960] 002628: Mar 2 18:08:37.102 GMT: RT: isis's 172.17.0.6/32 (via 0.0.0.115) metric changed from distance/metric [-1408172026/1320] to [115/2041] 002629: Mar 2 18:08:37.102 GMT: RT: del 172.17.0.106/32 via 172.19.24.1, isis metric [115/1361] 002630: Mar 2 18:08:37.102 GMT: RT: add 172.17.0.106/32 via 172.19.45.2, isis metric [115/1920] 002631: Mar 2 18:08:37.102 GMT: RT: del 172.17.0.105/32 via 172.19.24.1, isis metric [115/1280] 002632: Mar 2 18:08:37.102 GMT: RT: add 172.17.0.105/32 via 172.19.45.2, isis metric [115/2560] 002633: Mar 2 18:08:37.102 GMT: RT: del 172.17.0.100/32 via 172.19.24.1, isis metric [115/1320] 002634: Mar 2 18:08:37.102 GMT: RT: add 172.17.0.100/32 via 172.19.45.2, isis metric [115/2041] 002635: Mar 2 18:08:37.102 GMT: RT: del 172.17.0.97/32 via 172.19.24.1, isis metric [115/1320] 002636: Mar 2 18:08:37.102 GMT: RT: add 172.17.0.97/32 via 172.19.45.2, isis metric [115/2041] 002637: Mar 2 18:08:37.102 GMT: RT: del 172.17.0.32/32 via 172.19.24.1, isis metric [115/761] 002638: Mar 2 18:08:37.102 GMT: RT: add 172.17.0.32/32 via 172.19.45.2, isis metric [115/1320] 002639: Mar 2 18:08:37.102 GMT: RT: del 172.17.0.31/32 via 172.19.24.1, isis metric [115/721] 002640: Mar 2 18:08:37.102 GMT: RT: add 172.17.0.31/32 via 172.19.45.2, isis metric [115/1280] 002641: Mar 2 18:08:37.102 GMT: RT: del 172.17.0.30/32 via 172.19.24.1, isis metric [115/761]


002642: Mar 2 18:08:37.102 GMT: metric [115/1320] 002643: Mar 2 18:08:37.102 GMT: metric [115/1761] 002644: Mar 2 18:08:37.102 GMT: metric [115/2320] 002645: Mar 2 18:08:37.102 GMT: metric [115/1680] 002646: Mar 2 18:08:37.106 GMT: metric [115/2401] 002647: Mar 2 18:08:37.106 GMT: metric [115/680] 002648: Mar 2 18:08:37.106 GMT: metric [115/1401] 002649: Mar 2 18:08:37.106 GMT: metric [115/640] 002650: Mar 2 18:08:37.106 GMT: 002651: Mar 2 18:08:37.106 GMT: metric [115/680] 002652: Mar 2 18:08:37.106 GMT: metric [115/1401] 002653: Mar 2 18:08:37.106 GMT: isis metric [115/791] 002654: Mar 2 18:08:37.106 GMT: isis metric [115/1512] 002655: Mar 2 18:08:37.106 GMT: metric [115/791] 002656: Mar 2 18:08:37.106 GMT: metric [115/1512] 002657: Mar 2 18:08:37.106 GMT: metric [115/791] 002658: Mar 2 18:08:37.106 GMT: metric [115/1512] 002659: Mar 2 18:08:37.106 GMT: metric [115/790] 002660: Mar 2 18:08:37.106 GMT: metric [115/1511] 002661: Mar 2 18:08:37.106 GMT: metric [115/740] 002662: Mar 2 18:08:37.106 GMT: metric [115/1611] 002663: Mar 2 18:08:37.106 GMT: metric [115/780] 002664: Mar 2 18:08:37.106 GMT: metric [115/1501] 002665: Mar 2 18:08:37.106 GMT: metric [115/790] 002666: Mar 2 18:08:37.106 GMT: metric [115/1511] 002667: Mar 2 18:08:37.106 GMT: metric [115/1960] PE4-PEXKS01# 002668: Mar 2 18:08:37.106 GMT: metric [115/2 600] 002669: Mar 2 18:08:37.106 GMT: metric [115/1320] 002670: Mar 2 18:08:37.106 GMT: 002671: Mar 2 18:08:38.114 GMT: 172.17.0.6 to 172.17.0.7 002672: Mar 2 18:08:38.114 GMT: 10.59.255.253 to 10.59.255.254

RT: add 172.17.0.30/32 via 172.19.45.2, isis RT: del 172.17.0.9/32 via 172.19.24.1, isis RT: add 172.17.0.9/32 via 172.19.45.2, isis RT: del 172.17.0.8/32 via 172.19.24.1, isis RT: add 172.17.0.8/32 via 172.19.45.2, isis RT: del 172.17.0.3/32 via 172.19.24.1, isis RT: add 172.17.0.3/32 via 172.19.45.2, isis RT: del 172.17.0.2/32 via 172.19.24.1, isis RT: delete subnet route to 172.17.0.2/32 RT: del 172.17.0.1/32 via 172.19.24.1, isis RT: add 172.17.0.1/32 via 172.19.45.2, isis RT: del 194.164.243.141/32 via 172.19.24.1, RT: add 194.164.243.141/32 via 172.19.45.2, RT: del 64.103.126.92/32 via 172.19.24.1, isis RT: add 64.103.126.92/32 via 172.19.45.2, isis RT: del 64.103.126.85/32 via 172.19.24.1, isis RT: add 64.103.126.85/32 via 172.19.45.2, isis RT: del 10.59.255.254/32 via 172.19.24.1, isis RT: add 10.59.255.254/32 via 172.19.45.2, isis RT: del 10.59.255.253/32 via 172.19.24.1, isis RT: add 10.59.255.253/32 via 172.19.45.2, isis RT: del 10.59.95.2/32 via 172.19.24.1, isis RT: add 10.59.95.2/32 via 172.19.45.2, isis RT: del 10.59.95.1/32 via 172.19.24.1, isis RT: add 10.59.95.1/32 via 172.19.45.2, isis RT: del 172.16.67.0/30 via 172.17.0.6, isis

RT: add 172.16.67.0/30 via 172.17.0.7, isis

RT: del 172.17.18.0/24 via 172.17.0.6, isis RT: RT(VOIP): 10.18.115.0/24 gateway changed from RT(VOIP): 10.220.132.0/23 gateway changed from


002673: Mar 2 18:08:38.114 GMT: RT(edn): 10.0.0.0/8 gateway changed from 172.17.0.6 to 172.17.0.7 002674: Mar 2 18:08:38.114 GMT: RT(6509_mgmt): 172.17.8.48/28 gateway changed from 172.17.0.6 to 172.17.0.7 002675: Mar 2 18:08:38.114 GMT: RT(6509_mgmt): 172.17.9.224/28 gateway changed from 172.17.0.6 to 172.17.0.7 002676: Mar 2 18:08:38.114 GMT: RT(CN5_BE): 10.18.119.0/24 gateway changed from 172.17.0.6 to 172.17.0.7 002677: Mar 2 18:08:38.114 GMT: RT(VPN): 10.18.118.0/24 gateway changed from 172.17.0.6 to 172.17.0.7 002678: Mar 2 18:08:38.114 GMT: RT(sigtran_blue): 10.18.116.0/24 gateway changed from 172.17.0.6 to 172.17.0.7 002679: Mar 2 18:08:38.114 GMT: RT(AX4000): 50.50.50.0/24 gateway changed from 172.17.0.6 to 172.17.0.7 002680: Mar 2 18:08:38.114 GMT: RT(AX4000): 50.50.51.0/24 gateway changed from 172.17.0.6 to 172.17.0.7 002681: Mar 2 18:08:38.114 GMT: RT(SmartBits): 30.30.30.0/24 gateway changed from 172.17.0.6 to 172.17.0.7 002682: Mar 2 18:08:38.114 GMT: RT(ospftest): 90.90.90.0/24 gateway changed from 172.17.0.6 to 172.17.0.7

Power-off P2 route As soon as P2 is powered-off: PE4-PEXKS01# sh mpl tra tu tu2 Load for five secs: 3%/0%; one minute: 1%; five minutes: 0% Time source is NTP, 18:52:31.458 GMT Fri Mar 2 2007 Name: PE4-PEXKS01_t2 Status:

Admin: up


Oper: up

Path: valid



Change in required resources detected: reroute pending Currently Signalled Parameters: Bandwidth: 100 kbps (Global) Metric Type: TE (default)

Priority: 4

4


path option 1 reoptimization in progress Config Parameters: Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based auto-bw: (86400/86087) 6 Bandwidth Requested: 100 Active Path Option Parameters: State: dynamic path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled InLabel : OutLabel : GigabitEthernet3/2, 110

FRR OutLabel : Tunnel60006, 86 (in use)

Backup tunnel in used.

RSVP Signalling Info: Src 172.17.0.4, Dst 172.17.0.7, Tun_Id 2, Tun_Instance 3952 RSVP Path Info: My Address: 172.17.0.4 Explicit Route: 172.17.0.3 172.19.32.2 172.19.137.1 172.17.0.7 Record Route: Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits


RSVP Resv Info: Record Route:

172.17.0.2(110) 172.19.23.1(110) 172.17.0.3(86) 172.19.32.1( 86) 172.17.0.32(78) 172.19.137.2( 78) 172.17.0.7(0) 172.19.137.1( 0) Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits Shortest Unconstrained Path Info: Path Weight: 1960 (TE) Explicit Route: 172.19.45.2 172.19.53.10 172.16.131.2 172.19.137.1 172.17.0.7 History: Tunnel: Time since created: 1 days, 6 hours, 23 minutes Time since path change: 1 minutes, 25 seconds Number of LSP IDs (Tun_Instances) used: 3662 Current LSP: Uptime: 1 minutes, 25 seconds Reopt. LSP: Setup Time: 4 minutes, 54 seconds remaining Prior LSP: ID: path option 1 [3915] Removal Trigger: path option updated

After path re-calculation PE4-PEXKS01# tra mpl tra tu 2 Tracing MPLS TE Label Switched Path on Tunnel2, timeout is 2 seconds Codes: '!' '.' 'R' 'M'

-


Type escape sequence to abort. 0 172.19.45.1 MRU 4470 [Labels: 49 Exp: 0] R 1 172.19.45.2 MRU 4470 [Labels: 79 Exp: 0] 4 ms R 2 172.19.53.10 MRU 4470 [Labels: 80 Exp: 0] 1 ms R 3 172.16.131.2 MRU 4474 [implicit-null] 2 ms ! 4 172.19.137.1 2 ms


PE4-PEXKS01# sh mpl tra tu tu2 Load for five secs: 1%/0%; one minute: 1%; five minutes: 0% Time source is NTP, 19:13:33.301 GMT Fri Mar 2 2007 Name: PE4-PEXKS01_t2 Status:


Admin: up Oper: up Path: valid Signalling: connected path option 1, type dynamic (Basis for Setup, path weight 1960) path option 1 reoptimization in progress Config Parameters: Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based auto-bw: (86400/84825) 3785 Bandwidth Requested: 100 Active Path Option Parameters:


LockDown: disabled

Verbatim: disabled

InLabel : OutLabel : GigabitEthernet3/3, 49

FRR OutLabel : Tunnel60003, 79 RSVP Signalling Info: Src 172.17.0.4, Dst 172.17.0.7, Tun_Id 2, Tun_Instance 3957 RSVP Path Info: My Address: 172.17.0.4

Explicit Route: 172.19.45.2 172.19.53.10 172.16.131.2 172.19.137.1 172.17.0.7 Record Route: Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits RSVP Resv Info: Record Route: 172.17.0.5(49) 172.19.53.9( 49) 172.17.0.31(79) 172.16.131.1( 79) 172.17.0.32(80) 172.19.137.2( 80) 172.17.0.7(0) 172.19.137.1( 0) Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits Shortest Unconstrained Path Info: Path Weight: 1401 (TE) Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.1 172.17.0.7 History: Tunnel: Time since created: 1 days, 6 hours, 44 minutes Time since path change: 20 minutes, 43 seconds Number of LSP IDs (Tun_Instances) used: 3703 Current LSP: Uptime: 20 minutes, 46 seconds Selection: reoptimization Reopt. LSP: Setup Time: 4 minutes, 44 seconds remaining Prior LSP: ID: path option 1 [3952] Removal Trigger: re-route path error


AToM issues PE-7# sh mpl l2transport vc 100 Local intf ------------Se2/0

Local circuit Dest address VC ID Status -------------------------- --------------- ---------- ---------HDLC 172.17.0.4 100 DOWN

This output shows the virtual cirtuit created from this PE (PE7) to the remote PE (PE-4) is down. As the neighbour is reachable (172.17.0.4 reachability is OK), we can conclude the Layer 2 VPN is not configured in the remote site, or it is using a different VC-id . In this particular example, the remote site should have a VC-id 100 created with a destination IP address PE7 ip address.

The configuration should be: PE-7# sh run int s2/0 Building configuration... Current configuration : 157 bytes ! interface Serial2/0 description >>>> link to CE4 no ip address no ip directed-broadcast no cdp enable xconnect 172.17.0.4 100 encapsulation mpls end

PE-4# sh run int s2/0 Building configuration... Current configuration : 157 bytes ! interface Serial2/0 description >>>> link to CE1 no ip address no ip directed-broadcast no cdp enable xconnect 172.17.0.7 100 encapsulation mpls end


Figure 12 - Lab topology for LINK and NODE failures scenarios

F 6 E

AX4000

5 E1 CHOC3-E1

POS CHOC48 POS STM16

2

172.17.7.83 2/2 1/2

4 G E

6509-1

172.16.18.0/30

6509-3

2/0/0

RR1

1/1

6 1 / / 3 1

8 9 . 0 / 3

172.17.0.4 PE4

172.17.0.2 2/0/2 3/2

3/3

172.19.53.8/30 .103/2

PE5

3/0/0.99 10.40.31.9 3 / 0 / 0

3 / 0 / 8

3/2

3/ 1 3/0/2 .9

3/0/0

172.17.0.3 P3

1 7 2 . 1 9 . 3 1 . 0 /3 0

3/0/3

172.17.0.5

3/0/0 172.19.23.0/30

2/0/4

0 3 / 0 . 5 4 . 9 1 . 2 7 1

6 . 1

2 / 1 0 / 3 7 2 .1 9 . 1 3 .0 / 3 2 0 / 0 / 3

2 1 / 1 7 2 / 1 . 1 9 .3 0 . 0 /3 0

P2

172.19.24.0/30

1 0 7 3 3/3 / 2 0 0/1 0/2 . 1 0 . 6 0/1 3 . 1 1 . 3 172.19.29.8./30 6 2 1 . 0 . 172.17.0.9 2 / 3 7 0 1 0/ 2

172.17.0.31 P31

3/3

172.19.131.0/30

3/2

1 8 9 . 0 / 3

3/0

172.17.0.6 3/1

PE6

4/0/1

0/2 1 7 2 .1 9 . 3 2 .0 /3 0

P30

RR2

172.16.36.0/30

3 / 3

3 / 1 1 / 6

3 . 3 5 . 3 . 1 0 3 1 . 3 3 . 0

2/0/4

172.17.0.30

3/0

2/2

8 9 n a l v

P1 1 0 / 0 2 / / 3 0 . 2 1 9 . 1 2 . 1 / 0 7 / 1 2

1/2

1/1

5/8

172.17.0.1

1 5 . 1 3 . 0 4 . 0 1

10.40.31.10 vlan99

3 / 2 172.17.8.51 0

0/1

172.17.0.8

8 9 n a l v 6 . 1 3 . 0 4 . 0

3/0

s t m 1 / 4

4 E / G 1 m t s

0 2 / 3

10GE

GE POS STM1 FE

3 1

E F

STM1 or STM4

packet generator (to ports under test)

0 3 / 0 . 7 6 . 6 1 . 2 7 1

3/0

172.17.0.32

3/3

P32

n G 0 3 / 2 8 . 5 9 . 9 5 . 0 1

s t e g r a t t s e t S O Q 0/2

172.19.137.0/30 3/0/2

172.17.0.7 PE7

3/2

3 / 0 / 3

3 / 0 / 9

5/8

1/1 5 /1 3 5 /1 4 1/2 2/2 172.17.7.84

4 / 0 / 3

3 / 0 / 0

1/1

3/0/0.99 10.33.31.9

10.33.31.10 vlan99

172.17.8.52 1/2

6509-2

6509-4

2/2

July 10


Conclusion This Troubleshothing guide aim to present a methodology to understand and how to fix some misconfiguration and failure scenarios may occur on MPLS network. 

Symptons may appear as the F orwarding Problem.



Whether it is an actual Forwarding Problem (packet drops?) or Control Plane Problem.



Whether it is an MPLS VPN, or MPLS or TE problem.



Adhere to step-by-step systematic approach to troubleshooting.

In summary, you have kept in mind: 

RIB – Routing Information Base (Routing Table)

show ip route 

FIB – Forwarding Information Base (CEF table derived from the RIB)

show ip cef 

LIB – Label Information Base (Label database containing the label bindings)

show mpls label binding 

LFIB – Forwarding Label Information Base (Label bindings used that is derived from the FIB & LIB)

show mpls forwarding

140

Conclusion This Troubleshothing guide aim to present a methodology to understand and how to fix some misconfiguration and failure scenarios may occur on MPLS network. 

Symptons may appear as the F orwarding Problem.



Whether it is an actual Forwarding Problem (packet drops?) or Control Plane Problem.



Whether it is an MPLS VPN, or MPLS or TE problem.



Adhere to step-by-step systematic approach to troubleshooting.

In summary, you have kept in mind: 

RIB – Routing Information Base (Routing Table)

show ip route 

FIB – Forwarding Information Base (CEF table derived from the RIB)

show ip cef 

LIB – Label Information Base (Label database containing the label bindings)

show mpls label binding 

LFIB – Forwarding Label Information Base (Label bindings used that is derived from the FIB & LIB)

show mpls forwarding 

To view the FIB for IP-to-IP and IP-to-MPLS use:

show ip cef 

To view the LFIB for MPLS-to-MPLS and MPLS -to-IP use:

show mpls forwarding Control Plane verification 

Ensure CEF is enabled global

show ip cef summary 

Ensure CEF is enabled on the interface (no ip route-cache cef - interface level)

show ip cef 

Ensure LDP/TDP is enabled on the interfaces and the protocol matches with the neighbour routers

show mpls interface show mpls ldp discovery 

Check the LDP neighbour adjacency

show mpls ldp neighbor 

Ensure reachability to LDP router ID Ping from LDP router ID to the neighbour’s LDP router ID



For LDP over ATM issues verify the control VC

show mpls interfaces detail 

Ensure that the advertisement of labels has not been disabled

mpls ldp advertise-labels July 10


141

Common Control Plane Issues 



Label distribution protocol does not match No route to the neighbor‟s LDP router -ID learned via IGP



LDP communication filtered



Mismatch with LDP authentication

As Best Practice, always use the same router-id for each technology (BGP, Multicast, IGP, LDP, TE etc)

Forwarding Plane verification 

Ensure the next-hop for the VPNv4 peering session is in the MPLS forwarding table

show mpls forwarding ALWAYS CHECK THE CONFIGURATION

July 10


142

TM

Part 6: Appendix

Appendix I

Troubleshooting GSR forwarding Packet forwarding: FIB/LFIB on RP, LC and ASIC PEXBE01# attach 3 LC-Slot3> en LC-Slot3# sh mpls traffic-eng fast-reroute data Tunnel head end item frr information: Protected tunnel


FRR intf/label

Status

Tunnel2

Tun hd

Gi3/1:Untagged

Tu60001:tag-impl ready

Tunnel11

Tun hd

Gi3/1:Untagged


Tunnel15

Tun hd

Gi3/1:Untagged


Tunnel23

Tun hd

Gi3/1:Untagged


Tunnel33

Tun hd

Gi3/1:Untagged


Tunnel10

Tun hd

Gi3/1:Untagged

Tu60006:870

ready

Tunnel22

Tun hd

Gi3/1:Untagged

Tu60006:872

ready

Tunnel43

Tun hd

Gi3/1:Untagged

Tu60006:869

ready

LC-Slot3# sh mpls forwarding-table Local

Outgoing

Prefix

Bytes tag

Outgoing

Next Hop

tag

tag or VC

or Tunnel Id

switched

interface

16

Untagged

l2ckt(329506200)

0

none

point2point

17

Untagged

l2ckt(329506201)

0

none

point2point

22

Untagged

l2ckt(329546200)

0

none

point2point

77

539

172.17.1.116/30

0

Gi3/1

172.17.1.10

79

326

172.17.2.168/30

0

Gi3/1

172.17.1.10

80

Untagged

l2ckt(329555300)

0

none

point2point

153

Untagged

l2ckt(2294240432) 0

none

point2point

154

Pop tag

172.17.0.5/32

0

Gi3/0

172.17.3.10

155

Pop tag

172.17.16.16/30

0

Gi3/1

172.17.1.10

163

29

172.17.0.27/32

0

Gi3/1

172.17.1.10

164

22

172.17.0.20/32

0

Gi3/1

172.17.1.10

167

Pop tag

172.17.0.2/32

0

Tu2

point2point

168

Pop tag

172.17.0.21/32

0

Tu43

point2point

171

Pop tag

172.17.0.16/32

0

Tu7

point2point

185

Untagged

10.197.4.0/23[V]

0

Gi7/0/1.256 10.197.1.52

July 10


144

LC-Slot3# sh mpls alpha-lfib Start address of TFIB root: 0x28084000 Default PLU leaf:

0x28083FF0 (1047731 refs)

Default tag rewrite in TLU: 0x2008FBC0 (549 refs incl. one from default leaf) Tag

PLU Loc

16

Value

Leaf Address (PLU/CPU)

leaf-bit

0x28084040 0x01810766

0x00810766/0x30083B30

Clear

17

0x28084044 0x00010764

0x00010764/0x24083B20

Clear

18

0x28084048 0x0081075C

0x0081075C/0x28083AE0

Clear

22

0x28084058 0x0181065A

0x0081065A/0x300832D0

Clear

23

0x2808405C 0x000107EA

0x000107EA/0x24083F50

Clear

24

0x28084060 0x01010774

0x00010774/0x2C083BA0

Clear

25

0x28084064 0x01810774

0x00810774/0x30083BA0

Clear

26

0x28084068 0x00010772

0x00010772/0x24083B90

Clear

27

0x2808406C 0x00810772

0x00810772/0x28083B90

Clear

28

0x28084070 0x00810782

0x00810782/0x28083C10

Clear

29

0x28084074 0x01010782

0x00010782/0x2C083C10

Clear

30

0x28084078 0x01810782

0x00810782/0x30083C10

Clear

31

0x2808407C 0x00010780

0x00010780/0x24083C00

Clear

32

0x28084080 0x00810780

0x00810780/0x28083C00

Clear

LC-Slot3# sh mpls hardware-lfib Start address of TFIB root: 0x28084000 Default PLU leaf:

0x28083FF0 (1047734 refs)

Default tag rewrite in TLU: 0x2008FBC0 (546 refs incl. one from default leaf) Tag

PLU Loc

16

Value

Leaf Address (PLU/CPU)

leaf-bit

0x28084040 0x01810766

0x00810766/0x30083B30

Clear

17

0x28084044 0x00010764

0x00010764/0x24083B20

Clear

18

0x28084048 0x0081075C

0x0081075C/0x28083AE0

Clear

22

0x28084058 0x0181065A

0x0081065A/0x300832D0

Clear

23

0x2808405C 0x000107EA

0x000107EA/0x24083F50

Clear

24

0x28084060 0x01010774

0x00010774/0x2C083BA0

Clear

25

0x28084064 0x01810774

0x00810774/0x30083BA0

Clear

26

0x28084068 0x00010772

0x00010772/0x24083B90

Clear

27

0x2808406C 0x00810772

0x00810772/0x28083B90

Clear

28

0x28084070 0x00810782

0x00810782/0x28083C10

Clear

29

0x28084074 0x01010782

0x00010782/0x2C083C10

Clear

30

0x28084078 0x01810782

0x00810782/0x30083C10

Clear

31

0x2808407C 0x00010780

0x00010780/0x24083C00

Clear

32

0x28084080 0x00810780

0x00810780/0x28083C00

Clear

33

0x28084084 0x01010780

0x00010780/0x2C083C00

Clear

34

0x28084088 0x01810780

0x00810780/0x30083C00

Clear

35

0x2808408C 0x0001077E

0x0001077E/0x24083BF0

Clear

36

0x28084090 0x0081077E

0x0081077E/0x28083BF0

Clear

July 10


145

Debug commands of interest for Control Plane debug mpls ldp advertisements debug mpls ldp bindings debug mpls ldp igp debug mpls ldp message debug mpls ldp session debug mpls traffic-eng path debug isis mpls traffic-eng debug isis update-packets debug isis spf-triggers debug isis mpls traffig-eng events debug isis mpls traffig-eng advertisements debug ip rsvp fast-reroute debug ip rsvp path detail debug ip rsvp resv detail debug ip rsvp rsvp signalling

PE4-PEXKS01# PE4-PEXKS01# PE4-PEXKS01# PE4-PEXKS01# PE4-PEXKS01#

debug debug debug debug

ip ip ip ip

rsvp rsvp rsvp rsvp

fast-reroute resv path signalling

002297: Mar

2 17:35:21.702 GMT: RSVP: Sending Srefresh message to 172.19.24.1

002298: Mar


PE4-PEXKS01# 002299: Mar


PE4-PEXKS01#

002300: Mar 2 17:35:25.273 GMT: RSVP: session 172.17.0.7_2[172.17.0.4]: Received Resv message from 172.19.45.2 (on GigabitEthernet3/3) 002301: Mar 2 17:35:25.273 GMT: RSVP: 172.17.0.4_3803->172.17.0.7_2[172.17.0.4]: Successfully parsed Resv message from 172.19.45.2 (on GigabitEthernet3/3) 002302: Mar 2 17:35:25.273 GMT: RSVP: 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: reservation not found--new one

002303: Mar 2 17:35:25.273 GMT: RSVP-RESV: Admitting new reservation: 9BC75C8 002304: Mar

2 17:35:25.273 GMT: %MPLS_TE-5-LSP: LSP 172.17.0.4 2_3803: UP

002305: Mar 2 17:35:25.273 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_

frr_event_resv_arrive: Event: Resv Arrived 002306: Mar 2 17:35:25.273 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_event_resv_arrive: Action: LSP has no backup, try to get one

002307: Mar 2 17:35:25.273 GMT: RSVP-FRR 172.17.0.4_3803->172.17.0.7_2[172.17.0.4]: rsvp_frr_parse_ero_rro: Looking in RRO for NHOP & NNHOP Addrs/Labels: 002308: Mar 2 17:35:25.273 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Looking in RRO, starting at index 0, skipping 172.17.0.4's addrs 002309: Mar 2 17:35:25.273 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Get RRO subobject at index 0

002310: Mar 2 17:35:25.273 GMT: RSVP-FRR 172.17.0.4_3803->172.17.0.7_2[172.17.0.4]: rsvp_frr_get_rro_subobject_at_index: Returning address 172.17.0.5 Label 00000031 flags 20 July 10


146

002311: Mar 2 17:35:25.273 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_find_rro_next_rrr_id: PCALC Success 002312: Mar 2 17:35:25.273 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Succeeded, returning RRR ID 172.17.0.5 ADDR 172.17.0.5 Label 0x31 002313: Mar 2 17:35:25.273 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Looking in RRO, starting at index 2, skipping 172.17.0.5's addrs 002314: Mar 2 17:35:25.273 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Get RRO subobject at index 2 002315: Mar 2 17:35:25.273 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_ frr_get_rro_subobject_at_index: Returning address 172.19.53.9 Label 00000031 flags 00 002316: Mar 2 17:35:25.273 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_find_rro_next_rrr_id: PCALC Success 002317: Mar 2 17:35:25.273 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Get RRO subobject at index 4 002318: Mar 2 17:35:25.273 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_get_rro_subobject_at_index: Returning address 172.17.0.31 Label 0000004E flags 21 002319: Mar 2 17:35:25.273 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_find_rro_next_rrr_id: PCALC Success 002320: Mar 2 17:35:25.273 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Succeeded, returning RRR ID 172.17.0.31 ADDR 172.17.0.31 Label 0x4E

002321: Mar 2 17:35:25.273 GMT: RSVP-FRR: rsvp_frr_parse_ero_rro: In RRO, found: NHOP Addr 172.17.0.5 N-NHOP Addr 172.17.0.31 NHOP RRR ID 172.17.0.5 N-NHOP RRR ID 172.17.0.31 002322: Mar

2 17:35:25.277 GMT: NHOP Label

0x31 N-NHOP Label

0x4E

002323: Mar 2 17:35:25.277 GMT: RSVP-FRR 172.17.0.4_3803->172.17.0.7_2[172.17.0.4]: rsvp_frr_prepare: Look for N-NHOP Bkup Tun to 172.17.0.31 protecting GigabitEthernet3/3 with > 100 kbs avail 002324: Mar 2 17:35:25.277 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_prepare: No such N-NHOP Backup Tunnel Found 002325: Mar 2 17:35:25.277 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_prepare: Look for NHOP Bkup Tun to 172.17.0.5 protecting GigabitEthernet3/3 with > 100 kbs avail 002326: Mar 2 17:35:25.277 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_prepare: Notify auto-tunnel for backup creation 002327: Mar 2 17:35:25.277 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_remove_lsp: clearing 0 kbs 002328: Mar 2 17:35:25.277 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_set_backup: prepare failed 002329: Mar

2 17:35:25.277 GMT: RSVP-RESV: reservation was installed: 9BC75C8

002330: Mar 2 17:35:25.277 GMT: %MPLS_TE-5-TUN: Tun2: installed LSP 2_3803 (popt 1) for 2_3744 (popt 1), reopt. LSP is up

002331: Mar 2 17:35:25.277 GMT: RSVP-FRR 172.17.0.4_3803->172.17.0.7_2[172.17.0.4]: rsvp_frr_get_tunnel_info: Tunnel info requested by auto-tunnel backup 002332: Mar 2 17:35:25.277 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_parse_ero_rro: Looking in RRO for NHOP & NNHOP Addrs/Labels: 002333: Mar 2 17:35:25.277 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Looking in RRO, starting at index 0, skipping 172.17.0.4's addrs 002334: Mar 2 17:35:25.277 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Get RRO subobject at index 0 002335: Mar 2 17:35:25.277 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_get_rro_subobject_at_index: Returning address 172.17.0.5 Label 00000031 flags 20 002336: Mar 2 17:35:25.277 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_find_rro_next_rrr_id: PCALC Success

July 10


147

002337: Mar 2 17:35:25.277 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Succeeded, returning RRR ID 172.17.0.5 ADDR 172.17.0.5 Label 0x31 002338: Mar 2 17:35:25.277 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Looking in RRO, starting at index 2, skipping 172.17.0.5's addrs 002339: Mar 2 17:35:25.277 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Get RRO subobject at index 2 002340: Mar 2 17:35:25.277 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_get_rro_subobject_at_index: Returning address 172.19.53.9 Label 00000031 flags 00 002341: Mar 2 17:35:25.277 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_find_rro_next_rrr_id: PCALC Success 002342: Mar 2 17:35:25.277 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Get RRO subobject at index 4 002343: Mar 2 17:35:25.277 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_get_rro_subobject_at_index: Returning address 172.17.0.31 Label 0000004E flags 21 002344: Mar 2 17:35:25.277 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_find_rro_next_rrr_id: PCALC Success 002345: Mar 2 17:35:25.277 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Succeeded, returning RRR ID 172.17.0.31 ADDR 172.17.0.31 Label 0x4E 002346: Mar found:

2 17:35:25.277 GMT: RSVP-FRR: rsvp_frr_parse_ero_rro: In RRO,

NHOP Addr

172.17.0.5

NHOP RRR ID 172.17.0.5

N-NHOP Addr

172.17.0.31

N-NHOP RRR ID 172.17.0.31



0x31 N-NHOP Label

0x4E

002348: Mar 2 17:35:25.277 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_get_tunnel_info: Tunnel info: Protected I/F: GigabitEthernet3/3, NHOP Router ID: 172.17.0.5, N-NHOP Router ID: 172.17.0.31 002349: Mar

2 17:35:25.793 GMT: RSVP: Sending Ack message to 172.19.45.2

002350: Mar 2 17:35:26.025 GMT: RSVP: session 172.17.0.7_2[172.17.0.4]: Received Resv message from 172.19.45.2 (on GigabitEthernet3/3) 002351: Mar 2 17:35:26.025 GMT: RSVP: 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: Successfully parsed Resv message from 172.19.45.2 (on GigabitEthernet3/3) 002352: Mar 2 17:35:26.025 GMT: RSVP: 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: No change in reservation 002353: Mar


002354: Mar 2 17:35:26.925 GMT: RSVP-FRR: rsvp_frr_tpdb_node_change: topology data base node change: event: 4 PE4-PEXKS01#

002355: Mar 2 17:35:26.925 GMT: %MPLS_TE-5-TUN: Tun2: installed LSP 2_3803 (popt 1) for 2_3744 (popt 1), reopt. LSP is up PE4-PEXKS01# 002356: Mar


002357: Mar 2 17:35:28.272 GMT: %MPLS_TE-5-TUN: Tun2: installed LSP 2_3803 (popt 1) for 2_3744 (popt 1), reopt. LSP is up

002358: Mar 2 17:35:28.272 GMT: %MPLS_TE-5-TUN: Tun2: LSP path change 2_3803 for 2_3744, reroute path verification failed PE4-PEXKS01# 002359: Mar 2 17:35:28.756 GMT: RSVP-FRR: rsvp_frr_tpdb_node_change: topology data base node change: event: 4 002360: Mar 2 17:35:29.992 GMT: %CLNS-5-ADJCHANGE: ISIS: Adjacency to P2 (GigabitEthernet3/2) Down, hold time expired PE4-PEXKS01# 002361: Mar 2 17:35:29.996 GMT: RSVP-FRR: rsvp_frr_tpdb_node_change: topology data base node change: event: 4

July 10


148

002362: Mar 2 17:35:30.308 GMT: RSVP: session 172.17.0.6_1[172.17.0.4]: Received Resv mes sage from 172.19.45.2 (on GigabitEthernet3/3) 002363: Mar 2 17:35:30.308 GMT: RSVP: 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: Successfully parsed Resv message from 172.19.45.2 (on GigabitEthernet3/3) 002364: Mar 2 17:35:30.308 GMT: RSVP: 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: reservation not found--new one 002365: Mar

2 17:35:30.308 GMT: RSVP-RESV: Admitting new reservation: 9BC79D0

002366: Mar

2 17:35:30.312 GMT: %MPLS_TE-5-LSP: LSP 172.17.0.4 1_2685: UP

002367: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_event_resv_arrive: Event: Resv Arrived 002368: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_event_resv_arrive: Action: LSP has no backup, try to get one 002369: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_parse_ero_rro: Looking in RRO for NHOP & NNHOP Addrs/Labels: 002370: Mar 2 17:35:30.312 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Looking in RRO, starting at index 0, skipping 172.17.0.4's addrs 002371: Mar 2 17:35:30.312 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Get RRO subobject at index 0 002372: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_get_rro_subobject_at_index: Returning address 172.17.0.5 Label 00000035 flags 20 002373: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_find_rro_next_rrr_id: PCALC Success 002374: Mar 2 17:35:30.312 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Succeeded, returning RRR ID 172.17.0.5 ADDR 172.17.0.5 Label 0x35 002375: Mar 2 17:35:30.312 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Looking in RRO, starting at index 2, skipping 172.17.0.5's addrs 002376: Mar 2 17:35:30.312 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Get RRO subobject at index 2 002377: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_get_rro_subobject_at_index: Returning address 172.19.53.9 Label 00000035 flags 00 002378: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_find_rro_next_rrr_id: PCALC Success 002379: Mar 2 17:35:30.312 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Get RRO subobject at index 4 002380: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_get_rro_subobject_at_index: Returning address 172.17.0.31 Label 00000051 flags 29 002381: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_find_rro_next_rrr_id: PCALC Success 002382: Mar 2 17:35:30.312 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Succeeded, returning RRR ID 172.17.0.31 ADDR 172.17.0.31 Label 0x51 002383: Mar found:


NHOP Addr

172.17.0.5

NHOP RRR ID 172.17.0.5 002384: Mar

N-NHOP Addr

172.17.0.31



0x35 N-NHOP Label

0x51

002385: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_prepare: Look for N-NHOP Bkup Tun to 172.17.0.31 protecting GigabitEthernet3/3 with > 100 kbs avail 002386: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_prepare: No such N-NHOP Backup Tunnel Found

July 10


149

002387: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_prepare: Look for NHOP Bkup Tun to 172.17.0.5 protecting GigabitEthernet3/3 with > 100 kbs avail 002388: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_prepare: Notify auto-tunnel for backup creation 002389: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_remove_lsp: clearing 0 kbs 002390: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_set_backup: prepare failed 002391: Mar

2 17:35:30.312 GMT: RSVP-RESV: reservation was installed: 9BC79D0

002392: Mar 2 17:35:30.312 GMT: %MPLS_TE-5-TUN: Tun1: installed LSP 1_2685 (popt 1) for 1_2626 (popt 1), reopt. LSP is up 002393: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_ frr_get_tunnel_info: Tunnel info requested by auto-tunnel backup 002394: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_parse_ero_rro: Looking in RRO for NHOP & NNHOP Addrs/Labels: 002395: Mar 2 17:35:30.312 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Looking in RRO, starting at index 0, skipping 172.17.0.4's addrs 002396: Mar 2 17:35:30.312 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Get RRO subobject at index 0 002397: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_get_rro_subobject_at_index: Returning address 172.17.0.5 Label 00000035 flags 20 002398: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_find_rro_next_rrr_id: PCALC Success 002399: Mar 2 17:35:30.312 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Succeeded, returning RRR ID 172.17.0.5 ADDR 172.17.0.5 Label 0x35 002400: Mar 2 17:35:30.312 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Looking in RRO, starting at index 2, skipping 172.17.0.5's addrs 002401: Mar 2 17:35:30.312 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Get RRO subobject at index 2 002402: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_get_rro_subobject_at_index: Returning address 172.19.53.9 Label 00000035 flags 00 002403: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_find_rro_next_rrr_id: PCALC Success 002404: Mar 2 17:35:30.312 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Get RRO subobject at index 4 002405: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_get_rro_subobject_at_index: Returning address 172.17.0.31 Label 00000051 flags 29 002406: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_find_rro_next_rrr_id: PCALC Success 002407: Mar 2 17:35:30.312 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Succeeded, returning RRR ID 172.17.0.31 ADDR 172.17.0.31 Label 0x51 002408: Mar found:


NHOP Addr

172.17.0.5

NHOP RRR ID 172.17.0.5

N-NHOP Addr

172.17.0.31




0x35 N-NHOP Label

0x51

002410: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_ frr_get_tunnel_info: Tunnel info: Protected I/F: GigabitEthernet3/3, NHOP Router ID: 172.17.0.5, N-NHOP Router ID: 172.17.0.31

July 10


150

002411: Mar


002412: Mar 2 17:35:31.060 GMT: RSVP: session 172.17.0.6_1[172.17.0.4]: Received Resv message from 172.19.45.2 (on GigabitEthernet3/3) 002413: Mar 2 17:35:31.060 GMT: RSVP: 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: Successfully parsed Resv message from 172.19.45.2 (on GigabitEthernet3/3) PE4-PEXKS01# 002414: Mar 2 17:35:31.060 GMT: RSVP: 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: No change in reservation 002415: Mar


002416: Mar 2 17:35:32.843 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_ frr_parse_ero_rro: Looking in RRO for NHOP & NNHOP Addrs/Labels: 002417: Mar 2 17:35:32.843 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Looking in RRO, starting at index 0, skipping 172.17.0.4's addrs 002418: Mar 2 17:35:32.843 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Get RRO subobject at index 0 002419: Mar 2 17:35:32.843 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_get_rro_subobject_at_index: Returning address 172.17.0.5 Label 00000031 flags 20 002420: Mar 2 17:35:32.843 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_find_rro_next_rrr_id: PCALC Success 002421: Mar 2 17:35:32.843 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Succeeded, returning RRR ID 172.17.0.5 ADDR 172.17.0.5 Label 0x31 002422: Mar 2 17:35:32.843 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Looking in RRO, starting at index 2, skipping 172.17.0.5's addrs 002423: Mar 2 17:35:32.843 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Get RRO subobject at index 2002424: Mar 2 17:35:32.843 GMT: RSVP-FRR 172.17.0.4_3803->172.17.0.7_2[172.17.0.4]: rsvp_frr_get_rro_subobject_at_index: Returning address 172.19.53.9 Label 00000031 flags 00 002425: Mar 2 17:35:32.843 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_find_rro_next_rrr_id: PCALC Success 002426: Mar 2 17:35:32.843 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Get RRO subobject at index 4002427: Mar 2 17:35:32.843 GMT: RSVP-FRR 172.17.0.4_3803->172.17.0.7_2[172.17.0.4]: rsvp_frr_get_rro_subobject_at_index: Returning address 172.17.0.31 Label 0000004E flags 21 PE4-PEXKS01# 002428: Mar 2 17:35:32.843 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_find_rro_next_rrr_id: PCALC Success 002429: Mar 2 17:35:32.843 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Succeeded, returning RRR ID 172.17.0.31 ADDR 172.17.0.31 Label 0x4E 002430: Mar found:


NHOP Addr

172.17.0.5

NHOP RRR ID 172.17.0.5 002431: Mar

N-NHOP Addr

172.17.0.31



0x31 N-NHOP Label

0x4E

002432: Mar 2 17:35:33.071 GMT: RSVP-FRR: rsvp_frr_tpdb_node_change: topology data base node change: event: 4002433: Mar 2 17:35:33.075 GMT: %MPLS_TE-5-TUN: Tun1: installed LSP 1_2685 (popt 1) for 1_2626 (popt 1), reopt. LSP is up 002434: Mar 2 17:35:33.311 GMT: %MPLS_TE-5-TUN: Tun1: installed LSP 1_2685 (popt 1) for 1_2626 (popt 1), reopt. LSP is up

002435: Mar 2 17:35:33.311 GMT: %MPLS_TE-5-TUN: Tun1: LSP path change 1_2685 for 1_2626, reroute path verification failed 002436: Mar 2 17:35:33.767 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_parse_ero_rro: Looking in RRO for NHOP & NNHOP Addrs/Labels: 002437: Mar 2 17:35:33.767 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Looking in RRO, starting at index 0, skipping 172.17.0.4's addrs

July 10


151

002438: Mar 2 17:35:33.767 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Get RRO subobject at index 0 002439: Mar 2 17:35:33.767 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_get_rro_subobject_at_index: Returning address 172.17.0.5 Label 00000031 flags 20 002440: Mar 2 17:35:33.767 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_find_rro_next_rrr_id: PCALC Success 002441: Mar 2 17:35:33.767 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Succeeded, returning RRR ID 172.17.0.5 ADDR 172.17.0.5 Label 0x31 002442: Mar 2 17:35:33.767 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Looking in RRO, starting at index 2, skipping 172.17.0.5's addrs 002443: Mar 2 17:35:33.767 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Get RRO subobject at index 2 002444: Mar 2 17:35:33.767 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_get_rro_subobject_at_index: Returning address 172.19.53.9 Label 00000031 flags 00 002445: Mar 2 17:35:33.771 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_find_rro_next_rrr_id: PCALC Success 002446: Mar 2 17:35:33.771 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Get RRO subobject at index 4 002447: Mar 2 17:35:33.771 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_get_rro_subobject_at_index: Returning address 172.17.0.31 Label 0000004E flags 21 PE4-PEXKS01# 002448: Mar 2 17:35:33.771 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_find_rro_next_rrr_id: PCALC Success 002449: Mar 2 17:35:33.771 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Succeeded, returning RRR ID 172.17.0.31 ADDR 172.17.0.31 Label 0x4E 002450: Mar found:


NHOP Addr

172.17.0.5

NHOP RRR ID 172.17.0.5 002451: Mar

N-NHOP Addr

172.17.0.31



0x31 N-NHOP Label

0x4E



PE4-PEXKS01# 002470: Mar 2 17:35:38.270 GMT: RSVP: 172.17.0.4_3744>172.17.0.7_2[172.17.0.4]: Expiring sender host PATH state, reason: Local application requested tear (0:3744) 002471: Mar 2 17:35:38.270 GMT: RSVP-FRR 172.17.0.4_3744>172.17.0.7_2[172.17.0.4]: rsvp_frr_event_lsp_down: Event: psb or rsb Expiring 002472: Mar 2 17:35:38.270 GMT: RSVP-FRR 172.17.0.4_3744>172.17.0.7_2[172.17.0.4]: rsvp_frr_event_lsp_down: Action: LSP is ready, clear backup 002473: Mar 2 17:35:38.270 GMT: RSVP-FRR 172.17.0.4_3744>172.17.0.7_2[172.17.0.4]: rsvp_frr_remove_lsp: clearing 100 kbs 002474: Mar 2 17:35:38.270 GMT: RSVP-FRR 172.17.0.4_3744>172.17.0.7_2[172.17.0.4]: rsvp_frr_remove_lsp: reducing 100 kbs on Tunnel60006 002475: Mar 2 17:35:38.270 GMT: RSVP-FRR 172.17.0.4_3744>172.17.0.7_2[172.17.0.4]: rsvp_frr_event_lsp_down: Event: psb or rsb Expiring 002476: Mar 2 17:35:38.270 GMT: RSVP-FRR 172.17.0.4_3744>172.17.0.7_2[172.17.0.4]: rsvp_frr_event_lsp_down: Action: LSP has no backup, ignore event 002477: Mar 2 17:35:38.270 GMT: RSVP: 172.17.0.4_3744>172.17.0.7_2[172.17.0.4]: Expiring GigabitEthernet3/2 RESV state, reason: Local application requested tear (0:3744) PE4-PEXKS01# 002478: Mar 2 17:35:38.270 GMT: RSVP-FRR: rsvp_frr_tpdb_node_change: topology data base node change: event: 4

July 10


152

002479: Mar 2 17:35:38.294 GMT: RSVP: 172.17.0.4_3744>172.17.0.7_2[172.17.0.4]: Sending PathTear message to 172.19.24.1 002480: Mar 2 17:35:38.814 GMT: RSVP: 172.17.0.4_3744>172.17.0.7_2[172.17.0.4]: Sending PathTear message to 172.19.24.1 PE4-PEXKS01# 002481: Mar 2 17:35:39.834 GMT: RSVP: 172.17.0.4_3744>172.17.0.7_2[172.17.0.4]: Sending PathTear message to 172.19.24.1 PE4-PEXKS01# 002482: Mar 2 17:35:41.854 GMT: RSVP: 172.17.0.4_3744>172.17.0.7_2[172.17.0.4]: Sending PathTear message to 172.19.24.1 PE4-PEXKS01# 002483: Mar 2 17:35:43.309 GMT: RSVP: 172.17.0.4_2626>172.17.0.6_1[172.17.0.4]: Expiring sender host PATH state, reason: Local application requested tear (0:2626) 002484: Mar 2 17:35:43.309 GMT: RSVP-FRR 172.17.0.4_2626>172.17.0.6_1[172.17.0.4]: rsvp_frr_event_lsp_down: Event: psb or rsb Expiring 002485: Mar 2 17:35:43.309 GMT: RSVP-FRR 172.17.0.4_2626>172.17.0.6_1[172.17.0.4]: rsvp_frr_event_lsp_down: Action: LSP is ready, clear backup 002486: Mar 2 17:35:43.309 GMT: RSVP-FRR 172.17.0.4_2626>172.17.0.6_1[172.17.0.4]: rsvp_frr_remove_lsp: clearing 100 kbs 002487: Mar 2 17:35:43.309 GMT: RSVP-FRR 172.17.0.4_2626>172.17.0.6_1[172.17.0.4]: rsvp_frr_remove_lsp: reducing 100 kbs on Tunnel60006 002488: Mar 2 17:35:43.309 GMT: RSVP-FRR 172.17.0.4_2626>172.17.0.6_1[172.17.0.4]: rsvp_frr_event_lsp_down: Event: psb or rsb Expiring 002489: Mar 2 17:35:43.309 GMT: RSVP-FRR 172.17.0.4_2626>172.17.0.6_1[172.17.0.4]: rsvp_ frr_event_lsp_down: Action: LSP has no backup, ignore event 002490: Mar 2 17:35:43.309 GMT: RSVP: 172.17.0.4_2626>172.17.0.6_1[172.17.0.4]: Expiring GigabitEthernet3/2 RESV state, reason: Local application requested tear (0:2626) PE4-PEXKS01# 002491: Mar 2 17:35:43.333 GMT: RSVP: 172.17.0.4_2626>172.17.0.6_1[172.17.0.4]: Sending PathTear message to 172.19.24.1 002492: Mar 2 17:35:43.853 GMT: RSVP: 172.17.0.4_2626>172.17.0.6_1[172.17.0.4]: Sending PathTear message to 172.19.24.1 PE4-PEXKS01# 002493: Mar 2 17:35:44.873 GMT: RSVP: 172.17.0.4_2626>172.17.0.6_1[172.17.0.4]: Sending PathTear message to 172.19.24.1 002494: Mar 2 17:35:45.873 GMT: RSVP: 172.17.0.4_3744>172.17.0.7_2[172.17.0.4]: Sending PathTear message to 172.19.24.1 PE4-PEXKS01# 002495: Mar 2 17:35:46.893 GMT: RSVP: 172.17.0.4_2626>172.17.0.6_1[172.17.0.4]: Sending PathTear message to 172.19.24.1 PE4-PEXKS01# 002496: Mar 2 17:35:48.792 GMT: RSVP: 172.17.0.4_1097>172.17.0.31_60004[172.17.0.4]: Resv state is being refreshed for 0x52271 nbr: 172.19.45.2 002497: Mar 2 17:35:48.792 GMT: RSVP: 172.17.0.1_29>172.17.0.4_60009[172.17.0.1]: Path state is being refreshed for 0x52282 nbr: 172.19.45.2 002498: Mar 2 17:35:48.792 GMT: RSVP: 172.17.0.31_4855>172.17.0.4_60005[172.17.0.31]: Path state is being refreshed for 0x52286 nbr: 172.19.45.2 002499: Mar 2 17:35:48.792 GMT: RSVP: 172.17.0.4_1>172.17.0.31_60007[172.17.0.4]: Resv state is being refreshed for 0x52299 nbr: 172.19.45.2 002500: Mar 2 17:35:48.792 GMT: RSVP: 172.17.0.4_1>172.17.0.1_60008[172.17.0.4]: Resv state is being refreshed for 0x523C4 nbr: 172.19.45.2

July 10


153

002501: Mar 2 17:35:48.792 GMT: RSVP: 172.17.0.4_3057>172.17.0.3_60001[172.17.0.4]: Resv state is being refreshed for 0x52581 nbr: 172.19.45.2 002502: Mar 2 17:35:48.792 GMT: RSVP: 172.17.0.4_306>172.17.0.3_60006[172.17.0.4]: Resv state is being refreshed for 0x52582 nbr: 172.19.45.2 002503: Mar 2 17:35:48.792 GMT: RSVP: 172.17.0.3_1>172.17.0.4_60006[172.17.0.3]: Path state is being refreshed for 0x52585 nbr: 172.19.45.2 002509: Mar


002510: Mar


002511: Mar 2 17:35:50.912 GMT: RSVP: 172.17.0.4_2626>172.17.0.6_1[172.17.0.4]: Sending PathTear message to 172.19.24.1 002512: Mar


002513: Mar


002514: Mar


002515: Mar 2 17:35:53.891 GMT: RSVP: 172.17.0.4_3744->172.17.0.7_2[172.17.0.4]: Sending PathTear message to 172.19.24.1 002516: Mar


002517: Mar 2 17:35:59.470 GMT: %RPGE-6-RX_LOS: Interface GigabitEthernet3/2: Detected RX Loss of Signal 002518: Mar 2 17:35:59.474 GMT: %LINK-3-UPDOWN: Interface GigabitEthernet3/2, changed state to down 002519: Mar 2 17:35:59.474 GMT: RSVP-FRR 172.17.0.6_9113>172.17.0.4_1[172.17.0.6]: rsvp_frr_event_input_if_dn: Event: input ifc GigabitEthernet3/2 is down 002520: Mar 2 17:35:59.474 GMT: RSVP-FRR 172.17.0.6_9113>172.17.0.4_1[172.17.0.6]: rsvp_frr_event_input_if_dn: Action: enabled FRR on input for this LSP 002521: Mar 2 17:35:59.474 GMT: RSVP: 172.17.0.6_9113>172.17.0.4_1[172.17.0.6]: PATH not cleaned up (on GigabitEthernet3/2), fast reroute in progress 002522: Mar 2 17:35:59.474 GMT: RSVP-FRR 172.17.0.7_4656>172.17.0.4_1[172.17.0.7]: rsvp_frr_event_input_if_dn: Event: input ifc GigabitEthernet3/2 is down 002523: Mar 2 17:35:59.474 GMT: RSVP-FRR 172.17.0.7_4656>172.17.0.4_1[172.17.0.7]: rsvp_frr_event_input_if_dn: Action: enabled FRR on input for this LSP 002524: Mar 2 17:35:59.474 GMT: RSVP: 172.17.0.7_4656>172.17.0.4_1[172.17.0.7]: PATH not cleaned up (on GigabitEthernet3/2), fast reroute in progress 002525: Mar 2 17:35:59.486 GMT: %RPGE-6-LINK_STATUS_DOWN: Interface GigabitEthernet4/0/0: Detected RX Link Status Down 002526: Mar 2 17:35:59.818 GMT: %RPGE-6-GBIC_TX_FAULT: Interface GigabitEthernet4/0/0: GBIC TX Fault Detected 002527: Mar 2 17:36:00.410 GMT: %RPGE-6-GBIC_TX_FAULT: Interface GigabitEthernet3/2: GBIC TX Fault OK 002528: Mar 2 17:36:00.474 GMT: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet3/2, changed state to down 002529: Mar 2 17:36:01.486 GMT: %LINK-3-UPDOWN: Interface GigabitEthernet4/0/0, changed state to down 002530: Mar 2 17:36:01.890 GMT: RSVP: 172.17.0.4_2626>172.17.0.6_1[172.17.0.4]: Sending PathTear message to 172.19.24.1 002531: Mar


PE4-PEXKS01# 002532: Mar 2 17:36:02.486 GMT: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEt hernet4/0/0, changed state to down

July 10


154

Debug commands of interest for Data Plane debug mpls packets tunnels <#> debug ip cef receive

Debug commands of interest for MPLS and MPLS/VPN debug mpls ldp adver debug mpls lfib debug mpls bgp debug ip ospf packet debug clns packets

Debug commands of interest for AToM Debug mpls l2transport

July 10


155

How to measure packet loss TTCP Sender: Sender: ROUTER01 (10.33.252.231) Receiver: Receiver: 6509-2 (10.40.31.2) Path: Path: ROUTER01  6509-4  PE7  P32  P31  CE2 Check possible paths so TTCP will be seen to use the possible "slow" paths: ROUTER01# tracer 10.40.31.2 Type escape sequence to abort. Tracing the route to 10.40.31.2 1 10.33.33.3 0 msec 10.33.33.4 0 msec 10.33.33.3 0 msec 2 10.33.31.9 0 msec 10.33.31.5 0 msec 10.33.31.9 0 msec 3 172.16.36.1 0 msec 172.19.137.2 4 msec 172.16.36.1 0 msec 4 172.16.131.1 0 msec 10.40.31.5 0 msec 172.16.131.1 4 msec 5 10.40.31.6 0 msec 10.40.31.9 0 msec 10.40.31.6 0 msec 6 10.40.31.10 0 msec 10.40.3.4 0 msec *

Start CE2 in Receive mode; using default parameters, except that we do want to see stats (last question): CE2# ttcp transmit or receive [receive]: perform tcp half close [n]: receive buflen [8192]: bufalign [16384]: bufoffset [0]: port [5001]: sinkmode [y]: rcvwndsize [4128]: delayed ACK [y]: show tcp information at end [n]: y ttcp-r: buflen=8192, align=16384/0, port=5001 rcvwndsize=4128, delayedack=yes

tcp

The vty session is now "hung" until TTCP sender finshes sending.

July 10


156

Start ROUTER01 in sending mode; default all parameters except "t", target IP and stats Y. Default parameters sending 2024 x 8192 = 16Mbytes Remember, TCP mechanisms (slow start and congestion avoindance), so TCP will back off if congestion ROUTER01# ttcp transmit or receive [receive]: t Target IP address: 10.40.31.2 perform tcp half close [n]: send buflen [8192]: send nbuf [2048]: bufalign [16384]: bufoffset [0]: port [5001]: sinkmode [y]: buffering on writes [y]: show tcp information at end [n]: y

### TTCP establishes the connection, and a message pops up at both ends (ROUTER01) ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001

tcp

-> 10.40.31.2

ttcp-t: connect (mss 536, sndwnd 4128, rcvwnd 4128)

(CE2) ttcp-r: accept from 10.33.33.75 (mss 536, sndwnd 4128, rcvwnd 4128)

Now, the 16 MBytes are sent from ROUTER01



6509-2 and 6509-2 sends TCP ACKs only.

Check the time taken and hopefully it fineshes. Results at ROUTER01: ignore the TCP session details, details, just look at the time taken in the first line of output output ttcp-t: 16777216 bytes in 9308 ms (9.308 real seconds) (~1759 kB/s) +++ ttcp-t: 2048 I/O calls ttcp-t: 0 sleeps (0 ms total) (0 ms average) Connection state is ESTAB, I/O status: 1, unread input bytes: 0

Total of time for transmission. Sender respective.

Local host: 10.33.33.75, Local port: 32483 Foreign host: 10.40.31.2, Foreign port: 5001 Enqueued packets for retransmit: 4, input: 0

mis-ordered: 0 (0 bytes)

Event Timers (current time is 0x58FF050): Timer

Starts

Wakeups

Next

12798

0

0x58FF17B

TimeWait

0

0

0x0

AckHold

0

0

0x0

SendWnd

0

0

0x0

KeepAlive

0

0

0x0

GiveUp

0

0

0x0

PmtuAger

0

0

0x0

DeadWait

0

0

0x0

Retrans

iss: 2600288481

snduna: 2617063938

sndnxt: sndnxt: 2617065698

July 10

sndwnd:

4128


157

irs: 3904303256

rcvnxt: 3904303257

rcvwnd:

4128

delrcvwnd:

0

SRTT: 300 ms, RTTO: 303 ms, RTV: 3 ms, KRTT: 0 ms minRTT: 0 ms, maxRTT: 300 ms, ACK hold: 200 ms Flags: higher precedence, retransmission timeout Datagrams (max data segment is 536 bytes): Rcvd: 30718 ( out of order: 0), with data: 0, total data bytes: 0 Sent: 32770 ( retransmit: 0, fastretransmit: 0), with data: 32768, total data bytes: 16777216

(Results at 6509-2 end) ttcp-r: 16777216 bytes in 9316 ms (9.316 real seconds) (~1757 kB/s) +++

Total of time for ttcp-r: 13072 I/O calls transmission. ttcp-r: 0 sleeps (0 ms total) (0 ms average) Connection state is CLOSEWAIT, I/O status: 7, unread input bytes: 0Receiver respective. Local host: 10.40.31.2, Local port: 5001 Foreign host: 10.33.33.75, Foreign port: 32483 Enqueued packets for retransmit: 0, input: 0

mis-ordered: 0 (0 bytes)

Event Timers (current time is 0x23A34543C): Timer Starts Wakeups Next Retrans 1 0 0x0 TimeWait 0 0 0x0 AckHold 12798 0 0x0 SendWnd 0 0 0x0 KeepAlive 32770 0 0x23A353E9C GiveUp 0 0 0x0 PmtuAger 0 0 0x0 DeadWait 0 0 0x0 iss: 3904303256 irs: 2600288481

snduna: 3904303257 rcvnxt: 2617065699

sndnxt: 3904303257 rcvwnd: 3976

sndwnd: delrcvwnd:

4128 152

SRTT: 37 ms, RTTO: 1837 ms, RTV: 1800 ms, KRTT: 0 ms minRTT: 0 ms, maxRTT: 300 ms, ACK hold: 200 ms Flags: passive open, retransmission timeout, keepalive running nagle, path mtu capable, gen tcbs Datagrams (max data segment is 536 bytes): Rcvd: 32771 ( out of order: 0), with data: 32768, total data bytes: 16777216 Sent: 30722 ( retransmit: 0), with data: 0, total data bytes: 0

In problem cases, the time taken will vary to be greater than the benchmark shown and Rcvd "out of order" at the Receiver-End. Advise: Advise: to keep stats of benchmarks so that you know what is "normal". Don't worry about seeing 536 bytes or 1436 bytes as the TCP MSS size. This will affect throughput but the end devices are configured possibly not to do MTUD or just don't advertise any MSS. This is not a fault in the network or in the end device, just an option. Reason for using 6509 and not GSR is that 6509 is within a VRF/VPN and you need to prove the performance delivered to end systems. systems. No use telling end user that "the core core network is OK". 6509, 7200, 7500, 12000 12000 have TTCP available, 3640: no TTCP

July 10


158

Useful MIBs and how to poll them In this test nodes are configured to accept snmp from 172.17.18.X. Be careful not to ask for too large a chunk of MIB.

Access the server and perform the command showed as follows: root@server01 # cd /opt/apps/InCharge6/IP/smarts/bin

This is an example of walking the RFC1573/RFC2233 ifMIB "interface MIB". Smarts s/w includes its own Solaris executable snmp tools called "sm_XXXXX". In our case we want to get back a formatted report of parts of a node's MIB tree. "mibwalk" is not an SNMP command but is a sequence of "snmp-get-next" commands and "get-bulk" commands In the example we are using community j8fyxjnh. We are NOT using SNMPv3 a uthentication and engine-ids. We are using snmpv2c. We ask for a walk of an OID value and the SNMP gets will make the target box (172.17.0.5) respond with all the subordinate fields including ifName and ifHCInOctets etc.

Server will have created 3 files using the IP-address and a suffix: .walk

includes hex of character strings = difficult for human to read

.snap includes the format of each variable (eg COUNTER-32 for 32-but counter, COUNTER-64 for HC counters) .mimic (easiest for human to read) ./sm_snmpwalk --community=j8fyxjnh --oid=.1.3.6.1.2.1.31

172.17.0.5

Saving MIB walk to file(s) '172.17.0.5.walk' '172.17.0.5.mimic' '172.17.0.5.snap' ... End of MIB walk

Now we want to display the results but to understand we need to know the variables represent. For this you need to display the particular MIB's OID file. This is the ifName root@server01 # cat 172.17.0.5.mimic | more Note that each interface has its own ifName .1.3.6.1.2.1.31.1.1.1.1.1: Et0 .1.3.6.1.2.1.31.1.1.1.1.2: PO0/0

Interface of index 3.

.1.3.6.1.2.1.31.1.1.1.1.3: PO0/1 .1.3.6.1.2.1.31.1.1.1.1.4: PO0/2 .1.3.6.1.2.1.31.1.1.1.1.5: PO0/3 .1.3.6.1.2.1.31.1.1.1.1.6: AT1/0

Value of the query

.1.3.6.1.2.1.31.1.1.1.1.7: AT1/1

In this case it is ifName value for interface index 9. In this case it is the ATM 1/3

.1.3.6.1.2.1.31.1.1.1.1.8: AT1/2 .1.3.6.1.2.1.31.1.1.1.1.9: AT1/3 .1.3.6.1.2.1.31.1.1.1.1.10: AT1/4 .1.3.6.1.2.1.31.1.1.1.1.11: AT1/5 .1.3.6.1.2.1.31.1.1.1.1.12: AT1/6

This is the ifHCInOctest

July 10


159

.1.3.6.1.2.1.31.1.1.1.6.1: 186302666 .1.3.6.1.2.1.31.1.1.1.6.2: 0 .1.3.6.1.2.1.31.1.1.1.6.3: 0


.1.3.6.1.2.1.31.1.1.1.6.4: 0 .1.3.6.1.2.1.31.1.1.1.6.5: 0 .1.3.6.1.2.1.31.1.1.1.6.6: 0 .1.3.6.1.2.1.31.1.1.1.6.7: 0


.1.3.6.1.2.1.31.1.1.1.6.8: 0 .1.3.6.1.2.1.31.1.1.1.6.9: 0 .1.3.6.1.2.1.31.1.1.1.6.10: 0 .1.3.6.1.2.1.31.1.1.1.6.11: 19342489088

Value of the query

.1.3.6.1.2.1.31.1.1.1.6.12: 0

In this case it is ifHCInOctest value for interface index 16.

.1.3.6.1.2.1.31.1.1.1.6.13: 0 .1.3.6.1.2.1.31.1.1.1.6.14: 6611579242127 .1.3.6.1.2.1.31.1.1.1.6.15: 4771349347637 .1.3.6.1.2.1.31.1.1.1.6.16: 1236953229021

You can check it using a Cisco tool: Cisco web page SNMP Object Navigator  enter



Login



Support



Tools&Resources



http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en

Then, look for the OID file to tell what each variable OID number means.

Many MIB variables are based on ifIndex, each main and subinterface has a unique ifIndex, you need to know which ifIndex = what interface ask the router.

PE5-PEXKS02# sh snmp mib ifmib ifindex gig 3/0/0 Interface = GigabitEthernet3/0/0, Ifindex = 14

Poll the ifName MIB to obtain the ifIndex values root@server01 # ./sm_snmpwalk --community=j8fyxjnh -oid=.1.3.6.1.2.1.31.1.1.1.1 172.17.0.5 Saving MIB walk to file(s) '172.17.0.5.walk' '172.17.0.5.mimic' '172.17.0.5.snap' ... End of MIB walk

root@server01 # cat 172.17.0.5.mimic | more .1.3.6.1.2.1.31.1.1.1.1.1: Et0 .1.3.6.1.2.1.31.1.1.1.1.2: PO0/0 .1.3.6.1.2.1.31.1.1.1.1.3: PO0/1 .1.3.6.1.2.1.31.1.1.1.1.4: PO0/2 .1.3.6.1.2.1.31.1.1.1.1.5: PO0/3 .1.3.6.1.2.1.31.1.1.1.1.6: AT1/0 .1.3.6.1.2.1.31.1.1.1.1.7: AT1/1 .1.3.6.1.2.1.31.1.1.1.1.8: AT1/2 .1.3.6.1.2.1.31.1.1.1.1.9: AT1/3 .1.3.6.1.2.1.31.1.1.1.1.10: AT1/4 .1.3.6.1.2.1.31.1.1.1.1.11: AT1/5

July 10


160

.1.3.6.1.2.1.31.1.1.1.1.12: AT1/6 .1.3.6.1.2.1.31.1.1.1.1.13: AT1/7 .1.3.6.1.2.1.31.1.1.1.1.14: Gi3/0/0 .1.3.6.1.2.1.31.1.1.1.1.15: Gi3/0/1

The server tools are very comprehensive: root@server01 # ./sm_snmpwalk -help Usage:

sm_snmpwalk [options...]

Arguments: *

Host or IP address.

Options: --fmt=

Output format, one of "walk", "mimic", "snap" or "all"; default "all". Also -w, -m , -n or -a.

--timeout=

Timeout, in milliseconds; default 5000 (5 seconds). Also -t .

--retries=

Number of Retries; default 5. Also -r .

--community=

Community string; default "public". Also -c .

To obtain every MIB from the target, don't specify the oid root@server01 #./sm_snmpwalk --community=j8fyxjnh

172.17.0.5

Files will be large: root@server01 # ls -l 172.17.0.5* -rw-r--r--

1 root

other

3590905 Mar 21 11:15 172.17.0.5.mimic

-rw-r--r--

1 root

other

4207167 Mar 21 11:15 172.17.0.5.snap

-rw-r--r--

1 root

other

3548827 Mar 21 11:15 172.17.0.5.walk

More technical information about SNMP and MIB: http://www.cisco.com/en/US/tech/tk648/tk362/tech_white_papers_list.html http://carsten.familie-doh.de/mibtree/root.html http://www.snmpsource.com/ http://www.stllinux.org/meeting_notes/1996/1017/sld008.html

July 10


161

Appendix II

Configuration used in lab PE4 service nagle no service pad service tcp-keepalives-in service timestamps debug datetime msec localtime show-timezone service timestamps log datetime msec localtime show-timezone service password-encryption service sequence-numbers ! hostname PE-4 ! boot-start-marker boot-end-marker enable secret 5 $1$HUkw$FgrxXJK0CW1oyylI8y3vJ0 ! ip subnet-zero ip routing protocol purge interface ip cef no ip domain-lookup ip vrf VPN rd 25135:133001804 route-target export 25135:18 route-target export 212.183.144.1:18 route-target import 25135:18 route-target import 212.183.144.1:18 ! mpls label protocol ldp mpls ldp neighbor 172.17.0.2 password 7 00071A150754 mpls ldp neighbor 172.17.0.5 password 7 05080F1C2243 mpls traffic-eng tunnels mpls traffic-eng auto-tunnel backup mpls traffic-eng auto-tunnel backup config unnumbered-interface Loopback0 mpls traffic-eng auto-tunnel backup timers removal unused 3600 0 mpls traffic-eng auto-tunnel backup tunnel-num min 60000 max 64000 mpls traffic-eng auto-tunnel mesh mpls traffic-eng auto-tunnel mesh tunnel-num min 1 max 999 tag-switching tdp router-id Loopback0 !

July 10


162

key chain ISIS key 1 key-string 7 1043101D0A10 ! interface Loopback0 ip address 172.17.0.4 255.255.255.255 no ip directed-broadcast ! interface Loopback1 ip vrf forwarding VPN ip address 4.4.4.4 255.255.255.255 no ip directed-broadcast ! interface Auto-Template1 ip unnumbered Loopback0 no ip directed-broadcast tunnel destination access-list 41 tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng priority 4 4 tunnel mpls traffic-eng bandwidth

100

tunnel mpls traffic-eng path-option 1 dynamic tunnel mpls traffic-eng fast-reroute tunnel mpls traffic-eng auto-bw collect-bw ! interface Serial0/0 description >>>> link to P2 ip address 172.19.24.2 255.255.255.252 no ip directed-broadcast ip router isis mpls traffic-eng tunnels tag-switching ip no fair-queue isis authentication mode md5 isis authentication key-chain ISIS ip rsvp bandwidth 155000 155000 ! interface Serial1/0 description >>>> link to PE5 ip address 172.19.45.1 255.255.255.252 no ip directed-broadcast ip router isis mpls traffic-eng tunnels tag-switching ip isis metric 100 level-1 isis metric 640 level-2 isis authentication mode md5 isis authentication key-chain ISIS ip rsvp bandwidth 155000 155000

July 10


163

interface Serial2/0 description >>>> link to CE1 no ip address no ip directed-broadcast no cdp enable xconnect 172.17.0.7 100 encapsulation mpls ! router ospf 1 vrf VPN router-id 4.4.4.4 log-adjacency-changes area 0 sham-link 4.4.4.4 5.5.5.5 redistribute bgp 25135 metric 60 metric-type 1 subnets route-map vpn network 10.0.0.0 0.255.255.255 area 0 ! router isis net 10.0000.0000.0004.00 is-type level-2-only authentication mode md5 level-2 authentication key-chain ISIS ispf level-2 metric-style wide external overload signalling set-overload-bit on-startup 180 max-lsp-lifetime 65535 lsp-refresh-interval 65000 spf-interval 5 1 50 prc-interval 5 1 50 lsp-gen-interval 5 1 50 log-adjacency-changes mpls traffic-eng router-id Loopback0 mpls traffic-eng level-2 passive-interface Loopback0 ! router bgp 25135 bgp always-compare-med no bgp default ipv4-unicast bgp log-neighbor-changes bgp deterministic-med bgp bestpath med missing-as-worst timers bgp 10 30 neighbor mpbgp peer-group neighbor mpbgp remote-as 25135 neighbor mpbgp password 7 070C285F4D06 neighbor mpbgp update-source Loopback0 neighbor 172.17.0.8 peer-group mpbgp neighbor 172.17.0.9 peer-group mpbgp ! address-family vpnv4 neighbor mpbgp activate

July 10


164

neighbor mpbgp send-community both neighbor 172.17.0.8 peer-group mpbgp neighbor 172.17.0.9 peer-group mpbgp exit-address-family ! address-family ipv4 vrf VPN redistribute ospf 1 vrf VPN maximum-paths import 4 no auto-summary no synchronization network 4.4.4.4 mask 255.255.255.255 route-map metric exit-address-family ! ip classless ip rsvp signalling initial-retransmit-delay 750 ip rsvp signalling refresh reduction ack-delay 500 ip rsvp signalling refresh reduction ! ip prefix-list vpn seq 5 permit 4.4.4.4/32 ip prefix-list vpn seq 10 permit 5.5.5.5/32 ip prefix-list vpn seq 15 permit 6.6.6.6/32 ip prefix-list vpn seq 20 permit 7.7.7.7/32 ! ip access-list standard all permit 10.0.0.0 0.255.255.255 access-list 1 permit 172.17.0.0 0.0.0.255 access-list 41 permit 172.17.0.5 access-list 41 permit 172.17.0.7 access-list 41 permit 172.17.0.6 route-map metric permit 10 set metric 100 ! route-map vpn deny 10 match ip address prefix-list vpn ! route-map vpn permit 20 ! control-plane ! line con 0 exec-timeout 60 0 privilege level 15 logging synchronous line aux 0 line vty 0 4 privilege level 15 logging synchronous no login end

July 10


165

P2 version 12.0 service nagle no service pad service tcp-keepalives-in service timestamps debug datetime msec localtime show-timezone service timestamps log datetime msec localtime show-timezone service password-encryption service sequence-numbers ! hostname P2 ! boot-start-marker boot-end-marker ! no logging on enable secret 5 $1$uTdy$GJINJn/02YFW3fT104OG5. ! ip subnet-zero ip routing protocol purge interface ip cef no ip domain-lookup mpls label protocol ldp mpls ldp neighbor 172.17.0.4 password 7 00071A150754 mpls ldp neighbor 172.17.0.3 password 7 094F471A1A0A mpls ldp neighbor 172.17.0.31 password 7 0822455D0A16 mpls ldp neighbor 172.17.0.1 password 7 00071A150754 mpls traffic-eng tunnels mpls traffic-eng auto-tunnel backup mpls traffic-eng auto-tunnel backup config unnumbered-interface Loopback0 mpls traffic-eng auto-tunnel backup timers removal unused 3600 0 mpls traffic-eng auto-tunnel backup tunnel-num min 60000 max 64000 mpls traffic-eng auto-tunnel mesh mpls traffic-eng auto-tunnel mesh tunnel-num min 1 max 999 mpls traffic-eng reoptimize timers frequency 30 tag-switching tdp router-id Loopback0 ! key chain ISIS key 1 key-string 7 110400011815 ! interface Loopback0 ip address 172.17.0.2 255.255.255.255 no ip directed-broadcast ! interface Serial0/0 description >>>> link to P1 ip address 172.19.12.2 255.255.255.252

July 10


166

no ip directed-broadcast ip router isis mpls traffic-eng tunnels tag-switching ip no fair-queue isis authentication mode md5 isis authentication key-chain ISIS ip rsvp bandwidth 155000 155000 ! interface Serial1/0 description >>>> link to P3 ip address 172.19.23.1 255.255.255.252 no ip directed-broadcast ip router isis mpls traffic-eng tunnels mpls traffic-eng backup-path Tunnel40 tag-switching ip isis authentication mode md5 isis authentication key-chain ISIS ip rsvp bandwidth 155000 155000 ! interface Serial2/0 description >>>> link to P31 ip address 172.19.31.1 255.255.255.252 no ip directed-broadcast ip router isis mpls traffic-eng tunnels tag-switching ip fair-queue 64 256 63 isis metric 1000 level-2 isis authentication mode md5 isis authentication key-chain ISIS ip rsvp bandwidth 155000 155000 ! interface Serial3/0 description >>>> link to PE4 ip address 172.19.24.1 255.255.255.252 no ip directed-broadcast ip router isis mpls traffic-eng tunnels tag-switching ip fair-queue 64 256 63 isis authentication mode md5 isis authentication key-chain ISIS ip rsvp bandwidth 155000 155000 ! router isis net 10.0000.0000.0002.00 is-type level-2-only

July 10


167

authentication mode md5 level-2 authentication key-chain ISIS ispf level-2 metric-style wide level-2 external overload signalling set-overload-bit on-startup 180 max-lsp-lifetime 65535 lsp-refresh-interval 65000 spf-interval 5 1 50 prc-interval 5 1 50 lsp-gen-interval 5 1 50 log-adjacency-changes mpls traffic-eng router-id Loopback0 mpls traffic-eng level-2 passive-interface Loopback0 ! ip classless ip rsvp signalling initial-retransmit-delay 750 ip rsvp signalling refresh reduction ack-delay 500 ip rsvp signalling refresh reduction ! control-plane line con 0 exec-timeout 60 0 privilege level 15 logging synchronous line aux 0 line vty 0 4 privilege level 15 logging synchronous no login ! no cns aaa enable end

RR1 service nagle no service pad service tcp-keepalives-in service timestamps debug datetime msec localtime show-timezone service timestamps log datetime msec localtime show-timezone service password-encryption service sequence-numbers ! hostname RR1 ! boot-start-marker boot-end-marker

July 10


168

enable secret 5 $1$tOku$A7DT/0Bv7IvSGM9psLuiU/ ! ip subnet-zero ip routing protocol purge interface ip cef no ip domain-lookup mpls label protocol ldp mpls traffic-eng tunnels mpls traffic-eng reoptimize timers frequency 30 tag-switching tdp router-id Loopback0 ! key chain ISIS key 1 key-string 7 110400011815 ! interface Loopback0 ip address 172.17.0.8 255.255.255.255 no ip directed-broadcast ! interface Serial0/0 description >>>> link to P1 ip address 172.16.18.2 255.255.255.252 no ip directed-broadcast ip router isis tag-switching ip no fair-queue isis authentication mode md5 isis authentication key-chain ISIS ! router isis net 10.0000.0000.0008.00 is-type level-2-only authentication mode md5 level-2 authentication key-chain ISIS ispf level-2 metric-style wide level-2 external overload signalling set-overload-bit on-startup 180 max-lsp-lifetime 65535 lsp-refresh-interval 65000 spf-interval 5 1 50 prc-interval 5 1 50 lsp-gen-interval 5 1 50 log-adjacency-changes mpls traffic-eng router-id Loopback0 mpls traffic-eng level-2 passive-interface Loopback0 ! router bgp 25135

July 10


169

bgp always-compare-med no bgp default ipv4-unicast bgp cluster-id 1 bgp log-neighbor-changes bgp deterministic-med bgp bestpath med missing-as-worst timers bgp 10 30 neighbor mpbgp_client peer-group neighbor mpbgp_client remote-as 25135 neighbor mpbgp_client password 7 104D000A0618 neighbor mpbgp_client update-source Loopback0 neighbor 172.17.0.4 peer-group mpbgp_client neighbor 172.17.0.5 peer-group mpbgp_client neighbor 172.17.0.6 peer-group mpbgp_client neighbor 172.17.0.7 peer-group mpbgp_client neighbor 172.17.0.9 remote-as 25135 neighbor 172.17.0.9 password 7 02050D480809 neighbor 172.17.0.9 update-source Loopback0 ! address-family ipv4 neighbor mpbgp_client activate no auto-summary no synchronization exit-address-family ! address-family vpnv4 neighbor mpbgp_client activate neighbor mpbgp_client send-community both neighbor mpbgp_client route-reflector-client neighbor 172.17.0.4 peer-group mpbgp_client neighbor 172.17.0.5 peer-group mpbgp_client neighbor 172.17.0.6 peer-group mpbgp_client neighbor 172.17.0.7 peer-group mpbgp_client neighbor 172.17.0.9 activate neighbor 172.17.0.9 send-community both exit-address-family ! ip classless control-plane line con 0 exec-timeout 60 0 privilege level 15 logging synchronous line aux 0 line vty 0 4 privilege level 15 logging synchronous no login end

July 10


170

Glossary Term

Definition

AAL

ATM Adaptation Layer

ATM

Asynchronous Transfer Mode

AToM

Any Transport over MPLS

BGP

Border Gateway Protocol

CBR

Constraint-Based Routing

CE

Customer Edge Router

CEF

Cisco Express Forwarding – Cisco latest packet switching method.

CLI

Command-Line Interface

CLNS

Connection Less Network Service

Control Plane

Where control information, such as routing and label information is exchanged.

cSPF

Constrained Shortest Path First

Data Plane / Forwarding Plane

Where the actual forwarding occurs. This can only exist after the control plane has been established.

DiffServ

Differentiated Services (One of the Model defined in QoS Architecture)

FEC

Forward Equivalence Class

FIB

Forwarding Information Base – The table that is created by enabled CEF.

FRR

Fast Re-Route

IETF

Internet Engineering Task Force

IGP

Interior Gateway Protocol

IntServ

Integrated Services (One of the Model defined in QoS Architecture)

IP

Internet Protocol

IS-IS

Intermediate System to Intermediate System

Label

MPLS header that is used for switch a packet

LDP

Label Distribution Protocol

LFIB

Label Forwarding Information Base – The table where the various label bindings that an LSR receives over the LDP protocol are stored. It forms the basis of populating the FIB and LFIB tables.

LSP

Label Switch Path

LSR

Label Switch Router

MP-BGP

Multi-Protocol BGP

MPLS

Multi Protocol Label Switching

N-HOP

Next-Hop – Designation for “Link Protection” in FRR

NLRI

Network Layer Reachability Information

NN-HOP

Next-Next-Hop – Designation for “Node Protection” in FRR

OSPF

Open Shortest Path First

P

Provider Router

PE

Provider Edge Router

July 10


171

PHP

Penultimate Hop Popping

RIP

Routing Information Base

RD

Route Distinguished

RSVP

Resource Reservation Protocol

SNPA

Sub-network Points of Attachment

TDP

Tag Distribution Protocol

TE

Traffic Engineering

TTL

Time To Live

VPN

Virtual Private Network

VRF

Virtual Route Forwarding

Please refer to the CCO I nternetworking Terms and Acronyms Guide at http://www.cisco.com/univercd/cc/td/doc/cisintwk/ita/index.htm for additional terms.

July 10


172

References Book Cisco Press 

Traffic Engineer with MPLS

Eric Osborne and Ajay Simha



IP Quality of Service

Srinivas Vegesna

Cisco Official Training Course 

MPLST v2.0 - Implementing Cisco MPLS Traffic Engineering and Other Features

2004



MPLS v2.2 - Implement Cisco MPLS

2006

RFC (http://rfc.net/rfc.html) RFC2702 – Requirements for Traffic Engineering Over MPLS RFC3473 – Generalised Multi-Protocol Label Switching (GMPLS) Signalling RSVP-TE Extensions RFC4205 – ISIS Extensions in Support of Generalized Multi-Protocols Label Switching RFC4420 – Encoding of Attributes for MPLS LSP Establishment using RSVP-TE RFC2283 – Multiprotocol Extensions for BGP-4 RFC2858 – Multiprotocol Extensions for BGP-4

URL 

Configuring MPLS Label Switching

http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps1831/products_configuration_guide_ chapter09186a00800ca6ce.html



Configuring a Basic MPLS VPN

http://www.cisco.com/en/US/partner/tech/tk436/tk428/technologies_configuration_example09186 a00800a6c11.shtml



BGP Multipath Load Sharing in an MPLS-VPN

http://www.cisco.com/en/US/partner/products/ps6017/products_feature_guide09186a00804181b 4.html



Configuring a MPLS TE using IS-IS

http://www.cisco.com/en/US/partner/tech/tk436/tk428/technologies_configuration_example09186 a0080093fcb.shtml

July 10


173



RSVP Extension for MPLS/TE Signalling - RFC3473

http://rfc.net/rfc3473.html



RSVP Extension for MPLS/TE Signalling - RFC4208

http://rfc.net/rfc4208.html



FRR - Fast ReRoute - Link and Node Protection

http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps1829/products_feature_guide09186a 0080264560.html



MPLS Traffic Engineering - Autotunnel Mesh Group

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120s/120s29/ gsamg2.pdf



MPLS VPN Inter AS – Solution

http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps1829/products_feature_guide09186a 0080265adc.html



MPLS Traffic-eng configuration guide

http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_command_reference_chapte r09186a008017cf43.html http://www.cisco.com/en/US/products/ps6922/products_command_reference_chapter09186a008 06c0fd1.html#wp1021058

July 10


174

About This MPLS - Troubleshooting Guide Author:

Lizabete Ponte Advanced Service

Change Authority:

Lizabete Ponte

Reference Number:

History Version No.

Issue Date

Status

1.0

July 2010

1 version

st

Reason for Change First release

Review Version No.

Reviewer’s Details

Date

Change Forecast: High

This document will be kept under revision control.

July 10


175

MPLS - Troubleshooting Guide

Recommend Documents