DGTL Tscent 409

#CiscoLive
Troubleshooting MPLS TE
Tunnels
IOS & IOS-XE
Matt Snow – Enterprise R&S Technical Consulting Engineer
DGTL-TSCENT-409
#CiscoLive
Agenda
• MPLS TE Introduction & Overview
• Case Study 1: Path Calculation
• Case Study 2: L3VPN Traffic Blackholing
• Case Study 3: L2VPN Traffic Blackholing +
Auto-Tunnels
#CiscoLive DGTL-TSCENT-409 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 3
MPLS TE Introduction
& Overview
MPLS TE Intro
• MPLS TE allows us to influence the path of traffic through an MPLS
environment using parameters other than solely the IGP metric
within the core
Ø For instance: explicit paths, bandwidth requirements, affinity / path color
• MPLS TE tunnels create unidirectional LSPs from head-end to tail-
end
TE Tunnel Establishment
• Prerequisites:
Ø mpls traffic-eng tunnels configured globally and on core
interfaces
Ø ip rsvp bandwidth configured on core interfaces
Ø mpls traffic-eng router-id <Loopback> configured under IGP
process (OSPF or IS-IS)
Ø mpls traffic-eng [level-1|level-2] under IS-IS process, or
mpls traffic-eng area <area-id> under OSPF process
• In order to bring up an MPLS TE tunnel, the Path Calculation and
LSP Signaling must be successful
Path Calculation
• Performed by the head-end router
• CSPF (Constrained Shortest Path First) is the algorithm by which TE
tunnel paths are calculated
Ø Ituses tunnel constraint info in conjunction with MPLS TE topology info
that has been advertised within the link-state IGP (OSPF or IS-IS)
• Links which do not meet the tunnel constraints are ignored
• If path calculation is successful, it is followed by LSP signaling
LSP Signaling
• RSVP is responsible for signaling labels for TE tunnels
• The PATH message is initiated at the head-end toward its next hop
on the path
• Each intermediate router sends a PATH message toward its next
hop until the tail-end is reached
• Finally, starting with the tail-end, the reservation (RESV) message is
sent by each router to the previous hop on the path going back to
the head-end to allocate labels
Case Study Topology
Case Study 1:
Path Calculation
TE Tunnel Down
• When a TE tunnel will not come up, we must determine whether it
is the path calculation or LSP signaling that is failing
• In this case study, we will look at a situation in which a particular TE
tunnel is failing to come up due to a path calculation problem
Example Scenario
interface Tunnel1435
ip unnumbered Loopback0
mpls traffic-eng tunnels
tunnel mode mpls traffic-eng
tunnel destination 5.5.5.5
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng priority 7 7
tunnel mpls traffic-eng bandwidth 300000
tunnel mpls traffic-eng path-option 1 explicit name R1->R4->R3->R5
R1-PE#sh ip explicit-paths name R1->R4->R3->R5

PATH R1->R4->R3->R5 (strict source route, path complete, generation 104)
1: next-address 10.1.4.4
Checking Path Calculation
R1-PE#show mpls traffic-eng tunnels tunnel 1435
Name: R1-PE_t1435 (Tunnel1435) Destination: 5.5.5.5

Status:
Admin: up Oper: down Path: not valid Signalling: Down
path option 1, type explicit R1->R4->R3->R5
Config Parameters:
Bandwidth: 300000 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
<SNIP>
Prior LSP: [ID: 2608]
ID: path option 1 [2670]
Removal Trigger: path error
Last Error: CTRL:: Can't use link 10.3.5.3 on node 3.3.3.3
Checking Path Calculation (cont.)
Debug mpls traffic-eng path lookup + debug mpls traffic-eng path spf:
*May 19 19:36:53.010: TE-PCALC-VERIFY: Verify:
TE-PCALC-VERIFY: 0001.3333.3333.00, 10.3.5.3 points to
TE-PCALC-VERIFY: 0001.5555.5555.00, 10.3.5.5
*May 19 19:36:53.011: Link 10.3.5.3 forward bw avail=250000, bw req=300000, current bw generation=157, link bw generation=0 path bw=300000 bw_delta=300000
*May 19 19:36:53.011: TE-PCALC-SPF: REJECT(forward bw available too small) ip_address 10.3.5.3 bw 250000 req 300000
<SNIP>
*May 19 19:36:53.014: TE-PCALC-VERIFY: 1.1.1.1_2677->5.5.5.5_1435 {7}: Verify Failed: Can't use link 10.3.5.3 on node 3.3.3.3
<SNIP>
*May 19 19:36:53.017: TE-PCALC-API: 1.1.1.1_2677->5.5.5.5_1435 {7}: P2P LSP Path Lookup result: failed
Checking the TE Topology
R1-PE#show mpls traffic-eng topology 3.3.3.3
IGP Id: 0001.3333.3333.00, MPLS TE Id:3.3.3.3 Router Node (isis level-2) id 27

<SNIP>
link[1]: Broadcast, DR: 0001.3333.3333.04, nbr_node_id:25, gen:95, nbr_p:7EFED366D268
frag_id: 0, Intf Address: 10.3.5.3
TE metric: 10, IGP metric: 10, attribute flags: 0x0
SRLGs: None
physical_bw: 1000000 (kbps), max_reservable_bw_global: 750000 (kbps)
max_reservable_bw_sub: 0 (kbps)
Global Pool Sub Pool

Total Allocated Reservable Reservable
BW (kbps) BW (kbps) BW (kbps)
--------------- ----------- ----------
bw[0]: 0 750000 0 There are other TE tunnels in this topology which
bw[1]: 0 750000 0
bw[2]: 0 750000 0 are reserving a combined total of 500000 kbps
bw[3]: 0 750000 0
bw[4]: 0 750000 0 already on R3’s link toward R5.
bw[5]: 0 750000 0
bw[6]: 0 750000 0
bw[7]: 500000 250000 0
Possible Resolutions
• Define a different path for the tunnel, or try a dynamic path option
Ø Ifpath calculation still fails with a dynamic path option, then it would
indicate we do not have any available path that can satisfy the specified
constraints
• Reduce the required bandwidth for the tunnel
• Lower the setup and hold priority values for the tunnel (Note: this
would cause at least one other tunnel to go down if we make no
changes to the required bandwidth)
Summary
• It is important to understand the TE topology, especially when using
explicit path options, as we must avoid situations in which the path
cannot satisfy the constraints configured on the tunnel
Case Study 2:
L3VPN Traffic Blackholing
Non-End-to-End TE Tunnels
• When running TE tunnels that are not directly from ingress PE to
egress PE, it is possible to run into a traffic blackholing scenario
• In this case study we will look at this type of issue occurring on an
L3VPN MPLS TE circuit, and we will discuss what causes this to
happen and how to resolve it
Checking the LSP
R1-PE#show ip bgp vpnv4 vrf A 8.8.8.8
BGP routing table entry for 1:1:8.8.8.8/32, version 77
Paths: (1 available, best #1, table A)
<SNIP>
5.5.5.5 (via default) from 3.3.3.3 (3.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:100:100
Originator: 5.5.5.5, Cluster list: 3.3.3.3
mpls labels in/out nolabel/28
R1-PE#show ip route 5.5.5.5

Routing entry for 5.5.5.5/32
Known via "static", distance 1, metric 0 (connected)
Routing Descriptor Blocks:
* directly connected, via Tunnel16
Route metric is 0, traffic share count is 1
R1-PE#show mpls traffic-eng tunnels tunnel 16

Status:
Admin: up Oper: up Path: valid Signalling: connected
<SNIP>
InLabel : -
OutLabel : GigabitEthernet5, 32
R7-CE#ping 8.8.8.8 source lo0 Next Hop : 10.1.4.4
Type escape sequence to abort. <SNIP>
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 7.7.7.7 R1-PE#show mpls forwarding-table 5.5.5.5 detail
..... Local Outgoing Prefix Bytes Label Outgoing Next Hop
Success rate is 0 percent (0/5) Label Label or Tunnel Id Switched interface
28 Pop Label 5.5.5.5/32 0 Tu16 point2point
MAC/Encaps=14/18, MRU=1500, Label Stack{32}, via Gi5
<SNIP>
Checking the LSP (cont.)
R4-P#show mpls traffic-eng tunnels name R1-PE_t16
P2P TUNNELS/LSPs:
LSP Tunnel R1-PE_t16 is signalled, connection is up

InLabel : GigabitEthernet2, 32
Prev Hop : 10.1.4.1
OutLabel : GigabitEthernet6, implicit-null
Next Hop : 10.4.6.6
RSVP Signalling Info:
Src 1.1.1.1, Dst 6.6.6.6, Tun_Id 16, Tun_Instance 53
R6 does not know
RSVP Path Info: about this VPNv4 label
My Address: 10.4.6.4
Explicit Route: 10.4.6.6 6.6.6.6
<SNIP>
Summary
Problem: Resolution:
• R4 pops the TE label because it is • In order for R6 to forward the
the penultimate hop for the tunnel packet to R5 after receiving it on
from R1 to R6 Tunnel 16, the packet must come
in with R6’s local label for
• Because R6 receives a packet with
forwarding to R5
an unrecognized VPNv4 label, it is
unable to forward it and the packet • To resolve this, we can form a
is dropped targeted LDP session over the
tunnel between R1 and R6,
allowing R6 to advertise an LDP
label to R1 for R5’s loopback
Resolution
R1-PE#conf t
R1-PE(config)#interface tunnel 16
R1-PE(config-if)#mpls ip
R6-PE#conf t
R6-PE(config)#mpls ldp neighbor 1.1.1.1 targeted
OR
R6-PE(config)#mpls ldp discovery targeted-hello accept
R1-PE#sh mpls forwarding-table 5.5.5.5 detail

R6-PE#sh mpls forwarding-table 5.5.5.5
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
28 26 5.5.5.5/32 0 Tu16 point2point
26 Pop Label 5.5.5.5/32 612144 Gi4 10.5.6.5
MAC/Encaps=14/22, MRU=1496, Label Stack{32 26}, via Gi5
Resolution (cont.)
R7-CE#ping 8.8.8.8 source lo0

Type escape sequence to abort.
Packet sent with a source address of 7.7.7.7 Here we have a three-label stack:
!!!!!
Success rate is 100 percent (5/5), <SNIP> Ø Outer: TE Label
Ø Middle: LDP Label
Ø Inner: VPNv4 Label
Summary
• When the TE tunnel is not end-to-end (from ingress PE to egress
PE), we must make sure the tail-end router signals an LDP label
over the TE tunnel to the head-end in order to prevent an
incomplete LSP scenario
Case Study 3:
L2VPN Traffic Blackholing
+ Auto-Tunnels
TE Auto-Tunnels
• Auto-tunnels can be configured to dynamically create one-hop
primary TE tunnels along with backup tunnels for link protection
• However there is potential to run into a similar traffic blackholing
scenario to the one we saw previously
• In this case study we will look at this type of issue occurring on an
L2VPN MPLS TE circuit
Auto-Tunnel Base Config
• Primary Tunnels:
mpls traffic-eng auto-tunnel primary onehop
mpls traffic-eng auto-tunnel primary tunnel-num min <num> max <num>
mpls traffic-eng auto-tunnel primary config unnumbered-interface <Loopback>
• Backup Tunnels:
mpls traffic-eng auto-tunnel backup nhop-only
mpls traffic-eng auto-tunnel backup tunnel-num min <num> max <num>
mpls traffic-eng auto-tunnel primary config unnumbered-interface <Loopback>
Checking the LSP
R2-PE#show mpls l2transport vc 10
Local intf Local circuit Dest address VC ID Status
------------- -------------------------- --------------- ---------- ----------
VFI 10 vfi 6.6.6.6 10 DOWN
R2-PE#ping mpls ipv4 6.6.6.6/32

Sending 5, 72-byte MPLS Echos to 6.6.6.6/32,
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
<SNIP>
QQQQQ
Success rate is 0 percent (0/5)
R2-PE#show ip route 6.6.6.6

Routing entry for 6.6.6.6/32
Known via "isis", distance 115, metric 30, type level-2
Redistributing via isis CORE
There is a problem with the
Last update from 4.4.4.4 on Tunnel1001, 00:14:08 ago LSP which is preventing the
Routing Descriptor Blocks:
* 4.4.4.4, from 6.6.6.6, 00:14:08 ago, via Tunnel1001 pseudowire from coming up
Route metric is 30, traffic share count is 1
R7-CE#ping vrf VPLS 10.78.10.8

Type escape sequence to abort.
.....
Success rate is 0 percent (0/5)
Checking the LSP (cont.)
R2-PE#sh mpls traffic-eng tunnels tunnel 1001

Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 1, type explicit __dynamic_tunnel1001 (Basis for Setup, path weight 10)
<SNIP>
InLabel : -
OutLabel : GigabitEthernet5, implicit-null
Next Hop : 10.2.4.4
FRR OutLabel : Tunnel2001, implicit-null
RSVP Signalling Info:
Src 2.2.2.2, Dst 4.4.4.4, Tun_Id 1001, Tun_Instance 9116
RSVP Path Info:
My Address: 10.2.4.2
Explicit Route: 10.2.4.4 4.4.4.4

Label
41
Label
No Label
or Tunnel Id
6.6.6.6/32
Switched
0
interface
Tu1001 point2point The forwarding toward R6 is via
MAC/Encaps=14/14, MRU=1504, Label Stack{}, via Gi5 the one-hop tunnel to R4, but the
label stack is only the pop label
for Tunnel 1001
Summary
Problem: Resolution:
• Similar to what we saw • We need a way for R2 and R6
previously, there is an to learn labels for each other
incomplete LSP because the so they can forward through R4
TE tunnel in this case is one- using the one-hop tunnels
hop, not end-to-end
• This will involve signaling labels
• Here it is causing the VPLS over the one-hop tunnels to R4
pseudowire to not come up in so it is able to then advertise
the first place them between R2 and R6
Resolution
We could also configure mpls ip

in the auto-tunnel config on R4
R4-P#conf t
R4-P(config)#mpls ldp discovery targeted-hello accept
R2-PE#conf t R6-PE#conf t
R2-PE(config)#mpls traffic-eng auto-tunnel primary config mpls ip R6-PE(config)#mpls traffic-eng auto-tunnel primary config mpls ip
Resolution (cont.)
R2-PE#sh mpls l2transport vc 10
Local intf Local circuit Dest address VC ID Status
R2 now has an LDP label that it ------------- -------------------------- --------------- ---------- ----------
VFI 10 vfi 6.6.6.6 10 UP
can use to reach R6 via the one-
hop tunnel to R4 Local Outgoing Prefix Bytes Label Outgoing Next Hop
41 36 6.6.6.6/32 0 Tu1001 point2point
MAC/Encaps=14/18, MRU=1500, Label Stack{36}, via Gi5
R2-PE#ping mpls ipv4 6.6.6.6/32

Sending 5, 72-byte MPLS Echos to 6.6.6.6/32,
<SNIP>
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/4/8 ms
Total Time Elapsed 42 ms
R7-CE#ping vrf VPLS 10.78.10.8 R4-P#sh mpls forwarding-table 6.6.6.6 detail

Type escape sequence to abort. Local Outgoing Prefix Bytes Label Outgoing Next Hop
Sending 5, 100-byte ICMP Echos to 10.78.10.8, timeout is 2 seconds: Label Label or Tunnel Id Switched interface
!!!!! 36 Pop Label 6.6.6.6/32 22940 Tu1004 point2point
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/4 ms MAC/Encaps=14/14, MRU=1504, Label Stack{}, via Gi6
Summary
• One-hop TE auto-tunnels are inherently not end-to-end in the
absence of a direct link from PE to PE, so in a situation like this we
must make sure they are configured to signal LDP labels in order to
prevent an incomplete LSP scenario
Thank you
#CiscoLive
#CiscoLive

DGTL Tscent 409

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

DGTL Tscent 409

Загружено:

Авторское право:

Доступные форматы

#CiscoLive

Matt Snow – Enterprise R&S Technical Consulting Engineer

R1-PE#sh ip explicit-paths name R1->R4->R3->R5

R1-PE#show mpls traffic-eng tunnels tunnel 1435

Name: R1-PE_t1435 (Tunnel1435) Destination: 5.5.5.5

R1-PE#show mpls traffic-eng topology 3.3.3.3

IGP Id: 0001.3333.3333.00, MPLS TE Id:3.3.3.3 Router Node (isis level-2) id 27

Global Pool Sub Pool

R1-PE#show ip route 5.5.5.5

R1-PE#show mpls traffic-eng tunnels tunnel 16

R4-P#show mpls traffic-eng tunnels name R1-PE_t16

LSP Tunnel R1-PE_t16 is signalled, connection is up

R6-PE(config)#mpls ldp discovery targeted-hello accept

R1-PE#sh mpls forwarding-table 5.5.5.5 detail

R7-CE#ping 8.8.8.8 source lo0

R2-PE#ping mpls ipv4 6.6.6.6/32

R2-PE#show ip route 6.6.6.6

R7-CE#ping vrf VPLS 10.78.10.8

Name: R2-PE_t1001 (Tunnel1001) Destination: 4.4.4.4

R2-PE#sh mpls forwarding-table 6.6.6.6 detail

We could also configure mpls ip

R2-PE#ping mpls ipv4 6.6.6.6/32

R7-CE#ping vrf VPLS 10.78.10.8 R4-P#sh mpls forwarding-table 6.6.6.6 detail

Вам также может понравиться