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
Advanced Service A printed copy of this document is considered uncontrolled.
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
Advanced Service A printed copy of this document is considered uncontrolled.
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
Advanced Service A printed copy of this document is considered uncontrolled.
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
Advanced Service A printed copy of this document is considered uncontrolled.
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
Advanced Service A printed copy of this document is considered uncontrolled.
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
Advanced Service A printed copy of this document is considered uncontrolled.
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
Advanced Service A printed copy of this document is considered uncontrolled.
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
Advanced Service A printed copy of this document is considered uncontrolled.
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
Advanced Service A printed copy of this document is considered uncontrolled.
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
Advanced Service A printed copy of this document is considered uncontrolled.
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
Advanced Service A printed copy of this document is considered uncontrolled.
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
Advanced Service A printed copy of this document is considered uncontrolled.
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
Advanced Service A printed copy of this document is considered uncontrolled.
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
Advanced Service A printed copy of this document is considered uncontrolled.
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
Advanced Service A printed copy of this document is considered uncontrolled.
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
Advanced Service A printed copy of this document is considered uncontrolled.
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
Advanced Service A printed copy of this document is considered uncontrolled.
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
Advanced Service A printed copy of this document is considered uncontrolled.
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
Advanced Service A printed copy of this document is considered uncontrolled.
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
Advanced Service A printed copy of this document is considered uncontrolled.
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
Advanced Service A printed copy of this document is considered uncontrolled.
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
Advanced Service A printed copy of this document is considered uncontrolled.
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
Advanced Service A printed copy of this document is considered uncontrolled.
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
Advanced Service A printed copy of this document is considered uncontrolled.
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
Advanced Service A printed copy of this document is considered uncontrolled.
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
Advanced Service A printed copy of this document is considered uncontrolled.
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
Advanced Service A printed copy of this document is considered uncontrolled.
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
A printed copy of this document is considered uncontrolled.
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 A printed copy of this document is considered uncontrolled.
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
A printed copy of this document is considered uncontrolled.
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 A printed copy of this document is considered uncontrolled.
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
A printed copy of this document is considered uncontrolled.
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 A printed copy of this document is considered uncontrolled.
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
A printed copy of this document is considered uncontrolled.
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 A printed copy of this document is considered uncontrolled.
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
A printed copy of this document is considered uncontrolled.
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 A printed copy of this document is considered uncontrolled.
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
A printed copy of this document is considered uncontrolled.
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 A printed copy of this document is considered uncontrolled.
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 printed copy of this document is considered uncontrolled.
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
Advanced Service A printed copy of this document is considered uncontrolled.
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
Advanced Service A printed copy of this document is considered uncontrolled.
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 /
July 10 A printed copy of this document is considered uncontrolled.
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
July 10 A printed copy of this document is considered uncontrolled.
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.
July 10 A printed copy of this document is considered uncontrolled.
AToM Troubleshooting show mpls l2transport vc show mpls l2transport vc detail show mpls l2transport summary
July 10 A printed copy of this document is considered uncontrolled.
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.
July 10 A printed copy of this document is considered uncontrolled.
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
tib entry: 172.17.0.4/32, rev 4 local binding:
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
tib entry: 172.19.45.0/30, rev 5 local binding:
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.
July 10 A printed copy of this document is considered uncontrolled.
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}
July 10 A printed copy of this document is considered uncontrolled.
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.).
July 10 A printed copy of this document is considered uncontrolled.
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.
July 10 A printed copy of this document is considered uncontrolled.
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
July 10 A printed copy of this document is considered uncontrolled.
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]
July 10 A printed copy of this document is considered uncontrolled.
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
Metric LocPrf Weight Path
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
Metric LocPrf Weight Path
Route Distinguisher: 25135:133001807 (default for vrf VPN) *> 10.33.31.0/24
10.33.31.10
0
Total number of prefixes 1
July 10 A printed copy of this document is considered uncontrolled.
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.
July 10 A printed copy of this document is considered uncontrolled.
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.
July 10 A printed copy of this document is considered uncontrolled.
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
Metric LocPrf Weight Path
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 ?
July 10 A printed copy of this document is considered uncontrolled.
From those 19 prefixes learnt from this neighbour these are what were imported onto VRF VPN.
Route Distinguisher: 25135:133001805 *>i5.5.5.5/32
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 ?
Route Distinguisher: 25135:133001806 *>i6.6.6.6/32
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
Route Distinguisher: 25135:133001807 *>i7.7.7.7/32
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
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 ?
*> 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.
July 10 A printed copy of this document is considered uncontrolled.
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
Metric LocPrf Weight Path
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 ?
Route Distinguisher: 25135:133001805 *>i5.5.5.5/32
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 ?
Route Distinguisher: 25135:133001806 *>i6.6.6.6/32
172.17.0.6
100
100
0 i
*>i10.33.31.0/30
172.17.0.6
96
100
0 ?
Network
Next Hop
Metric LocPrf Weight Path
*>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).
Route Distinguisher: 25135:133001807 *>i7.7.7.7/32
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).
July 10 A printed copy of this document is considered uncontrolled.
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
Metric LocPrf Weight Path
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
July 10 A printed copy of this document is considered uncontrolled.
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 ? ? ? ? ? ? ? ?
This Prefixes are from PE7‟s VPN vrf. They were exported with RT 25135:18 value.
100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100
July 10 A printed copy of this document is considered uncontrolled.
This Prefixes are from PE5‟s VPN vrf. They were exported with RT 25135:18 value.
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
July 10 A printed copy of this document is considered uncontrolled.
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
This Prefixes are from PE6‟s VPN vrf. They were exported with RT 25135:18 value.
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
July 10 A printed copy of this document is considered uncontrolled.
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)
July 10 A printed copy of this document is considered uncontrolled.
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]
July 10 A printed copy of this document is considered uncontrolled.
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.
July 10 A printed copy of this document is considered uncontrolled.
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:
every 3600 seconds, next in 2643 seconds
Periodic auto-bw collection:
every 300 seconds, next in 184 seconds
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*
July 10 A printed copy of this document is considered uncontrolled.
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:
July 10 A printed copy of this document is considered uncontrolled.
[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]
July 10 A printed copy of this document is considered uncontrolled.
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.
July 10 A printed copy of this document is considered uncontrolled.
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 Sender: 172.17.0.4
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)
July 10 A printed copy of this document is considered uncontrolled.
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 Sender: 172.17.0.4
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.
July 10 A printed copy of this document is considered uncontrolled.
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
Mode(s): Host LSP-Tunnel 172.17.0.4
172.17.0.7
Mode(s): Host LSP-Tunnel 172.17.0.4
172.17.0.2
Mode(s): Host LSP-Tunnel 172.17.0.4
172.17.0.5
Mode(s): Host LSP-Tunnel 172.17.0.4
172.17.0.3
Mode(s): Host LSP-Tunnel 172.17.0.4
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
Mode(s): Host LSP-Tunnel 172.17.0.3
172.17.0.4
Mode(s): Host LSP-Tunnel 172.17.0.5
172.17.0.4
9437
Mode(s): Host LSP-Tunnel 172.17.0.5
172.17.0.4
Mode(s): Host LSP-Tunnel 172.17.0.6
172.17.0.4
Mode(s): Host LSP-Tunnel 172.17.0.7
172.17.0.4
Mode(s): Host LSP-Tunnel 172.17.0.31
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
. . . [ output omitted ]
It shows the Reservation Requests from Downstream.
July 10 A printed copy of this document is considered uncontrolled.
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.
July 10 A printed copy of this document is considered uncontrolled.
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).
July 10 A printed copy of this document is considered uncontrolled.
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
. . . [ output omitted ]
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
: affinity 00000000, bandwidth 154800 (kbps)
Hop
2: 172.19.131.1
: affinity 00000000, bandwidth 154800 (kbps)
Hop
3: 172.19.137.1
: affinity 00000000, bandwidth 154800 (kbps)
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
: affinity 00000000, bandwidth 155000 (kbps)
Hop 1: 172.19.23.1
: affinity 00000000, bandwidth 155000 (kbps)
Hop 2: 172.16.36.1
: affinity 00000000, bandwidth 155000 (kbps)
Hop 3: 172.16.67.1
: affinity 00000000, bandwidth 155000 (kbps)
July 10 A printed copy of this document is considered uncontrolled.
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
level-2, has 1 tunnels
(load balancing metric 20000000, nexthop 172.17.0.6) (flags: Announce)
destination 0000.0000.0007.00, area isis
Tunnel2
level-2, has 1 tunnels
(load balancing metric 20000000, nexthop 172.17.0.7) (flags: Announce)
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 ]
July 10 A printed copy of this document is considered uncontrolled.
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
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 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
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 . . . [ 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
July 10 A printed copy of this document is considered uncontrolled.
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:
0 kbits/sec (reserved: 100% in, 100% out)
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.
. . . [ output omitted ]
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
. . . [ output omitted ]
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
. . . [ output omitted ]
Backup tunnel does not allocate bandwidth. Only the primary tunnel interface requests bandwidth.
July 10 A printed copy of this document is considered uncontrolled.
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
Reservable Bandwidth[1]:
155000
0 kbits/sec
Reservable Bandwidth[2]:
155000
0 kbits/sec
Reservable Bandwidth[3]:
155000
0 kbits/sec
Reservable Bandwidth[4]:
154800
0 kbits/sec
Reservable Bandwidth[5]:
154800
0 kbits/sec
Reservable Bandwidth[6]:
154800
0 kbits/sec
Reservable Bandwidth[7]:
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 ]
July 10 A printed copy of this document is considered uncontrolled.
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:
90 setup requests, 90 admits, 0 rejects, 0 setup errors 33 tear requests, 0 preempts, 0 tear errors
Link ID::
Se0/0 (172.19.24.2)
Link Admission Statistics: Up Path:
34 setup requests, 34 admits, 0 rejects, 0 setup errors 16 tear requests, 0 preempts, 0 tear errors
Up Resv:
30 setup requests, 30 admits, 0 rejects, 0 setup errors 18 tear requests, 0 preempts, 0 tear errors
Down Path:
32 setup requests, 32 admits, 0 rejects, 0 setup errors 18 tear requests, 0 preempts, 0 tear errors
Down Resv:
46 setup requests, 46 admits, 0 rejects, 0 setup errors 12 tear requests, 0 preempts, 0 tear errors
Link ID::
Se1/0 (172.19.45.1)
Link Admission Statistics: Up Path:
31 setup requests, 31 admits, 0 rejects, 0 setup errors 14 tear requests, 0 preempts, 0 tear errors
. . . [ output omitted ]
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:
155000 kbits/sec (reserved: 0% in, 0% out)
Max Res Sub BW:
0 kbits/sec (reserved: 100% in, 100% out)
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
July 10 A printed copy of this document is considered uncontrolled.
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
(Tunnel60002) Destination: 172.17.0.3
Status:
Admin: up
Oper: up
Path: valid
Signalling: connected
path option 1, type explicit __dynamic_tunnel60002 (Basis for Setup, path weight 1260) 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
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
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 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.
July 10 A printed copy of this document is considered uncontrolled.
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 Sender: 172.17.0.4
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).
July 10 A printed copy of this document is considered uncontrolled.
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
In-label Out intf/label
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
In-label Out intf/label
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 ]
July 10 A printed copy of this document is considered uncontrolled.
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
Interface Desc: >>>> link to CE4
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
Interface Desc: >>>> link to CE1
VCCV Capabilities: Type 1, Type 2 Remote Label: 50 Cbit: 1,
VC Type: HDLC,
MTU: 1500,
GroupID: 0
Interface Desc: >>>> link to CE4
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
July 10 A printed copy of this document is considered uncontrolled.
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.
July 10 A printed copy of this document is considered uncontrolled.
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.
July 10 A printed copy of this document is considered uncontrolled.
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
(Tunnel3) Destination: 172.17.0.7
Status: Admin: up
Oper: up
Path: valid
Signalling: connected
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
auto-bw: (86400/63578) 0
Loadshare: 100
bw-based
Bandwidth Requested: 100
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:
Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits RSVP Resv Info: Record
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:
July 10 A printed copy of this document is considered uncontrolled.
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 Sender: 172.17.0.4
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
July 10 A printed copy of this document is considered uncontrolled.
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.
July 10 A printed copy of this document is considered uncontrolled.
TM
Part 5: Failure Scenarios
July 10 A printed copy of this document is considered uncontrolled.
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
Signalling: connected
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
Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits RSVP Resv Info: Record
Route:
172.17.0.2(48) 172.17.0.3(50) 172.17.0.6(40) 172.17.0.7(0)
. . . [ output omitted ]
July 10 A printed copy of this document is considered uncontrolled.
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
Signalling: connected
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
July 10 A printed copy of this document is considered uncontrolled.
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
July 10 A printed copy of this document is considered uncontrolled.
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.
July 10 A printed copy of this document is considered uncontrolled.
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
Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits RSVP Resv Info: Record
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 ]
July 10 A printed copy of this document is considered uncontrolled.
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
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 . . . [ output omitted ]
Checking in the diagram in this route the expect path: PE4
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
July 10 A printed copy of this document is considered uncontrolled.
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
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: 10 (TE) Explicit Route: 172.19.24.1 172.17.0.2 . . . [ output omitted ]
Checking in the diagram in this route the expect path: PE4
PE4
PE5 P31
P1
Next-Hop
Link Protected
P2
P3
PE6
P32
PE7
P30
PE5
P31
July 10 A printed copy of this document is considered uncontrolled.
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
(Tunnel2) Destination: 172.17.0.6
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
Bandwidth Requested: 100
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
July 10 A printed copy of this document is considered uncontrolled.
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
(Tunnel3) Destination: 172.17.0.7
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
Metric Type: TE (default) AutoRoute:
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
Bandwidth Requested: 100
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.
July 10 A printed copy of this document is considered uncontrolled.
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
July 10 A printed copy of this document is considered uncontrolled.
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.
. . . [ output omitted ]
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
. . . [ output omitted ]
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:
(Tunnel3) Destination: 172.17.0.7
Admin: up
Oper: up
Path: valid
Signalling: connected
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
July 10 A printed copy of this document is considered uncontrolled.
ISIS disabled for TE PE-4# sh mpl tra tu tu3 Name: PE-4_t3 Status:
Admin: up
(Tunnel3) Destination: 172.17.0.7
Oper: up
Path: valid
Signalling: connected
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
July 10 A printed copy of this document is considered uncontrolled.
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
July 10 A printed copy of this document is considered uncontrolled.
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
July 10 A printed copy of this document is considered uncontrolled.
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
July 10 A printed copy of this document is considered uncontrolled.
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
July 10 A printed copy of this document is considered uncontrolled.
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
July 10 A printed copy of this document is considered uncontrolled.
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
July 10 A printed copy of this document is considered uncontrolled.
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.
July 10 A printed copy of this document is considered uncontrolled.
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
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/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 P2P3P32PE7 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
July 10 A printed copy of this document is considered uncontrolled.
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.
July 10 A printed copy of this document is considered uncontrolled.
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
(Tunnel60006) Destination: 172.17.0.3
Oper: up
Path: valid
Signalling: connected
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
Checking in the diagram in this route the expect path: PE4
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
July 10 A printed copy of this document is considered uncontrolled.
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
July 10 A printed copy of this document is considered uncontrolled.
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'
-
success, 'Q' - request not transmitted, timeout, 'U' - unreachable, downstream router but not target, malformed request
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'
-
success, 'Q' - request not transmitted, timeout, 'U' - unreachable, downstream router but not target, malformed request
Type escape sequence to abort. 0 172.19.45.1 MRU 4470 [Labels: 25 Exp: 0] R 1 172.19.45.2 MRU 4470 [Labels: 81 Exp: 0] 3 ms R 2 172.19.53.10 MRU 4470 [Labels: 86 Exp: 0] 4 ms R 3 172.16.131.2 MRU 4474 [ implicit-null] 4 ms ! 4 172.19.137.1 1 ms
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.
July 10 A printed copy of this document is considered uncontrolled.
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
Signalling: connected
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
July 10 A printed copy of this document is considered uncontrolled.
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
path option 1 reoptimization in progress
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
July 10 A printed copy of this document is considered uncontrolled.
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'
-
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: 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
July 10 A printed copy of this document is considered uncontrolled.
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
(Tunnel2) Destination: 172.17.0.7
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/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
July 10 A printed copy of this document is considered uncontrolled.
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
July 10 A printed copy of this document is considered uncontrolled.
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.
July 10 A printed copy of this document is considered uncontrolled.
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
Affinity: 0x0/0xFFFF
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 ]
July 10 A printed copy of this document is considered uncontrolled.
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'
-
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: 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'
-
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: 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
July 10 A printed copy of this document is considered uncontrolled.
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
(Tunnel2) Destination: 172.17.0.7
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/86097) 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 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
July 10 A printed copy of this document is considered uncontrolled.
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'
-
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: 63 Exp: 0] R 1 172.19.24.1 MRU 4470 [Labels: 90 Exp: 0] 4 ms R 2 172.19.23.2 MRU 4470 [Labels: 98 Exp: 0] 1 ms R 3 172.19.32.2 MRU 4474 [ implicit-null] 2 ms ! 4 172.19.137.1 3 ms
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'
-
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: 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
July 10 A printed copy of this document is considered uncontrolled.
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
Signalling: connected
path option 1, type dynamic (Basis for Setup, path weight 0)
Change in required resources detected: reroute pending Currently Signalled Parameters: Bandwidth: 100 kbps (Global) 0x0/0xFFFF Metric Type: TE (default)
path option 1 reoptimization in progress
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
July 10 A printed copy of this document is considered uncontrolled.
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'
-
success, 'Q' - request not transmitted, timeout, 'U' - unreachable, downstream router but not target, malformed request
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
July 10 A printed copy of this document is considered uncontrolled.
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]
July 10 A printed copy of this document is considered uncontrolled.
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
July 10 A printed copy of this document is considered uncontrolled.
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
(Tunnel2) Destination: 172.17.0.7
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
Affinity: 0x0/0xFFFF
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
July 10 A printed copy of this document is considered uncontrolled.
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'
-
success, 'Q' - request not transmitted, timeout, 'U' - unreachable, downstream router but not target, malformed request
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
July 10 A printed copy of this document is considered uncontrolled.
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:
(Tunnel2) Destination: 172.17.0.7
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:
State: dynamic path option 1 is active BandwidthOverride: disabled
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
July 10 A printed copy of this document is considered uncontrolled.
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
July 10 A printed copy of this document is considered uncontrolled.
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
Advanced Service A printed copy of this document is considered uncontrolled.
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
Advanced Service A printed copy of this document is considered uncontrolled.
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
Advanced Service A printed copy of this document is considered uncontrolled.
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
In-label Out intf/label
FRR intf/label
Status
Tunnel2
Tun hd
Gi3/1:Untagged
Tu60001:tag-impl ready
Tunnel11
Tun hd
Gi3/1:Untagged
Tu60002:tag-impl ready
Tunnel15
Tun hd
Gi3/1:Untagged
Tu60003:tag-impl ready
Tunnel23
Tun hd
Gi3/1:Untagged
Tu60004:tag-impl ready
Tunnel33
Tun hd
Gi3/1:Untagged
Tu60005:tag-impl ready
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