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

[dip]

Peter,

you should be able to see the configs with the help of "show derived config
interface Tu65336" , one thing you would notice is that they are created
with explicit path option not dynamic path option  and thats why you see
that  its not following shortest path based on your IGP metric.Though it
will detect that there is a better path ..So if you do "show mpls
traffic-eng tunnels tunnel XYZ" , it should tell you the shortest
unconstrained Path which is probably what you want it to follow .


Thanks
Dip


On Mon, Oct 14, 2013 at 10:53 AM, Peter Rathlev <peter at rathlev.dk> wrote:

> 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
>
> _______________________________________________
> 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/
>