[c-nsp] MPLS TE auto-tunnel and ISIS metric

Peter Rathlev peter at rathlev.dk
Mon Oct 14 12:53:35 EDT 2013

On Mon, 2013-10-14 at 15:49 +0200, Adam Vitkovsky wrote:
> 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. 

Tunnel destination is the neighbor loopback, not the adjacent interface
address which I would probably have expected:

dist-1#show interface Tunnel65336
Tunnel65336 is up, line protocol is up 
  Hardware is Tunnel
  Interface is unnumbered. Using address of Loopback0 (
  MTU 17892 bytes, BW 100 Kbit, DLY 50000 usec, 
     reliability 255/255, txload 7/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel source, destination         <-----
  Tunnel protocol/transport Label Switching

> Also I don't know how you route your traffic into the tunnels.

These automagic tunnels seem to be built with "autoroute announce". Of
course I can't see the actual configuration the device uses:

dist-1#show running-config interface Tu65336
Building configuration...

Current configuration : 5 bytes

but "show mpls traffic-eng tunnels Tu65336" says "AutoRoute announce:

> 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. 

That sounds plausible. But it's also not very smart IMHO. The tunnel
should follow the "Shortest Unconstrained Path" that RSVP finds. I would
expect IOS to have some very savvy way of avoiding loops in an overlay
topology like this and still select the "right" path.

Thanks for the comments. :-)


More information about the cisco-nsp mailing list