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:[email protected]] 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 [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
