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

[Peter Rathlev]

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 (192.0.2.35)
  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 192.0.2.35, destination 192.0.2.34         <-----
  Tunnel protocol/transport Label Switching
<snip>

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

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

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

-- 
Peter