[c-nsp] MPLS TE auto-tunnel and ISIS metric
Adam Vitkovsky
adam.vitkovsky at swan.sk
Mon Oct 14 09:49:10 EDT 2013
Hi Peter,
I think if it's "onehop" the te-tunnels are actually established to the
next-hop IP address on all directly connected interfaces enabled with cmd:
"mpls ip" creating uniform overlay to the physical links.
Can you please check this assumption with cmd: "sh int tunnel <autotunnel#
on H<->E link >" and check for destination IP.
Also I don't know how you route your traffic into the tunnels.
I believe what is happening is that the path towards PE2 loopback is seen
via the "auto-routed" te-tunnels which all have the same metric, so SPF
would chose the direct link/te-tunnel between dist-1 and core-2.
adam
-----Original Message-----
From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
Peter Rathlev
Sent: Monday, October 14, 2013 2:07 PM
To: cisco-nsp
Subject: [c-nsp] MPLS TE auto-tunnel and ISIS metric
What does our MPLS TE auto-tunnels not follow the configured ISIS metric?
:-)
We have a lab setup like this:
+--------+ A D +--------+
| core-1 |---------| core-2 |-----> upstream
+--------\___ ___/--------+
C | B \ / E | F
| X |
G | H___/ \__I | J
+--------/ \--------+
| dist-1 | | dist-2 |
+--------+ +--------+
\ / <--- HSRP here
\ /
-----------------
|
+--------+
| client |
+--------+
We're testing failover times using MPLS TE auto-tunnels. All core and
distributions switches are Sup2T. Without any TE everything works as
expected and we see okay failover times, something like 75-100 ms on
link-down (H<->E) and a little more than this when reloading the direct
uplink device ("core-1").
Not we've tried configuring auto-tunnel backup like this:
mpls traffic-eng tunnels
mpls traffic-eng auto-tunnel backup
mpls traffic-eng auto-tunnel primary onehop mpls traffic-eng auto-tunnel
primary config mpls ip
Everything seems to work as expected except for one thing: The actual
forwarding doesn't follow the configured ISIS metric. Every link uses a
metric of 20000 except H<->E ("dist-1"<->"core-2") which uses 60000.
That way we can force traffic to flow via "core-1" even though the
destination is ultimately through "core-2". (Right now it's to test failover
times when reloading "core-1", but H<->E could be a bad link for some
reason.)
The MPLS TE tunnels seem to be built correctly. The relevant destination PE
is 192.0.2.6, somewhere upsteam of "core-2". Routing shows:
core-1#show ip route 192.0.2.6
Routing entry for 192.0.2.6/32
Known via "isis", distance 115, metric 61000, type level-1
Redistributing via isis
Last update from 192.0.2.34 on Tunnel65336, 00:37:55 ago
Routing Descriptor Blocks:
* 192.0.2.34, from 192.0.2.6, 00:37:55 ago, via Tunnel65336
Route metric is 61000, traffic share count is 1 core-1#
So next-hop is 192.0.2.34 ("core-2"). I would expect it to be "core-1"
somehow; even though traffic eventually has to cross "core-2" the first
next-hop should be "core-1". The tunnel itself:
core-1#show mpls traffic-eng tunnels Tunnel65336
Name: core-1_t65336 (Tunnel65336) Destination: 192.0.2.34
Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 1, type explicit __dynamic_tunnel65336 (Basis for Setup,
path weight 60000)
Config Parameters:
Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute announce: enabled LockDown: disabled Loadshare: 0 [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 : TenGigabitEthernet5/4, implicit-null
Next Hop : 198.51.100.221
FRR OutLabel : Tunnel65437, explicit-null
RSVP Signalling Info:
Src 192.0.2.35, Dst 192.0.2.34, Tun_Id 65336, Tun_Instance 812
RSVP Path Info:
My Address: 198.51.100.222
Explicit Route: 198.51.100.221 192.0.2.34
Record Route: NONE
Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits
RSVP Resv Info:
Record Route: 192.0.2.34(0)
Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits
Shortest Unconstrained Path Info:
Path Weight: 40000 (TE)
Explicit Route: 198.51.100.213 198.51.100.210 192.0.2.34
History:
Tunnel:
Time since created: 52 minutes, 42 seconds
Time since path change: 52 minutes, 42 seconds
Number of LSP IDs (Tun_Instances) used: 15
Current LSP: [ID: 812]
Uptime: 38 minutes, 41 seconds
Selection: reoptimization
Prior LSP: [ID: 805]
ID: path option 1 [805]
Removal Trigger: re-route path error
Last Error: RSVP:: Path Error from 192.0.2.35: Notify (code 25, value
3, flags 0) core-1#
The path mentioned in "Shortest Unconstrained Path Info" is the correct path
according to ISIS metric, i.e. "dist-1" -> "core-1" -> "core-2".
But MPLS forwarding says something different:
dist-1#show mpls forwarding-table 192.0.2.6 32 detail
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
33 18 192.0.2.6/32 0 Tu65336 point2point
MAC/Encaps=14/18, MRU=9216, Label Stack{18}, via Te5/4
D48CB5CBF34000190775DCC08847 00012000
No output feature configured
dist-1#
The "Te5/4" here is H<->E, the link we want to no use. CEF says the same
thing:
dist-1#show ip cef 192.0.2.6 255.255.255.255 internal 192.0.2.6/32, epoch 3,
RIB[I], refcount 7, per-destination sharing
sources: RIB, RR, LTE
feature space:
IPRM: 0x00028000
NetFlow: Origin AS 0, Peer AS 0, Mask Bits 0
Broker: linked, distributed at 1st priority
LFD: 192.0.2.6/32 1 local label
local label info: global/33
contains path extension list
disposition chain 0x17186848
label switch chain 0x17186848
subblocks:
1 RR source [heavily shared]
non-eos chain 18
ifnums:
Tunnel65336(41)
path 1335498C, path list 53F7CBD8, share 1/1, type attached nexthop, for
IPv4
MPLS short path extensions: MOI flags = 0x0 label 18
nexthop 192.0.2.34 Tunnel65336 label 18, adjacency IP midchain out of
Tunnel65336 133ECF20
output chain: label 18 TAG midchain out of Tunnel65336 133EEAC0 label
[implicit-null|implicit-null]
FRR Primary (0x13321620)
<primary: TAG adj out of TenGigabitEthernet5/4, addr 198.51.100.221
133EEE00>
<repair: TAG midchain out of Tunnel65437 133EF140 label 203 TAG adj out
of TenGigabitEthernet5/5, addr 198.51.100.213 133EC8A0> dist-1#
It has H<->E as primary path and C<->G as repair.
Typical interface configuration:
interface TenGigabitEthernet5/4
description core-2 Te5/4 [CDP]
mtu 9216
bandwidth 10000000
ip address 198.51.100.222 255.255.255.252 ip pim sparse-mode ip router
isis mpls traffic-eng tunnels mpls ip storm-control broadcast level 0.20
bfd interval 200 min_rx 100 multiplier 4 isis circuit-type level-1 isis
network point-to-point isis metric 60000 isis hello-multiplier 5 isis
hello-interval minimal isis csnp-interval 10 isis bfd hold-queue 256 in
ip rsvp bandwidth 5000000 end
Only difference among interfaces are IP addresses (of course) and metric,
with 20000 generally and 60000 in both directions for the link I want to not
use.
So why does MPLS (TE) not select the lowest ISIS cost for this? Am I doing
something completely wrong?
--
Peter
_______________________________________________
cisco-nsp mailing list cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
More information about the cisco-nsp
mailing list