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

[dip]

i agree in this case probably better option would be to use auto tunnel
mesh which should satisfy what you are looking for . Key thing to me would
be that you can define the path-option to follow the shortest IGP path with
FRR . So tunnel will follow the IGP path like you want and if a link is
gone tunnel will re adjust ..obviously the config lines may be little more
than originally you were looking for ..

Sample Config
!
mpls traffic-eng tunnels
mpls traffic-eng auto-tunnel backup
mpls traffic-eng auto-tunnel mesh
mpls traffic-eng path-selection metric igp
!
interface Auto-Template1
 ip unnumbered Loopback0
 mpls ip
 tunnel mode mpls traffic-eng
 tunnel destination access-list 90
 tunnel mpls traffic-eng autoroute announce
 tunnel mpls traffic-eng path-option 1 dynamic
 tunnel mpls traffic-eng fast-reroute
!

Thanks
Dip





On Thu, Oct 17, 2013 at 3:13 AM, Adam Vitkovsky <adam.vitkovsky at swan.sk>wrote:

> I believe you should be able to influence how the auto tunnel-mesh is
> created using "mesh groups" where you can use "attribute-set" to specify
> which link affinities to avoid/use.
>
> adam
> -----Original Message-----
> From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
> Peter Rathlev
> Sent: Thursday, October 17, 2013 9:04 AM
> To: dip
> Cc: cisco-nsp
> Subject: Re: [c-nsp] MPLS TE auto-tunnel and ISIS metric
>
> On Wed, 2013-10-16 at 20:50 -0600, dip wrote:
> > let me ask you this first ,is the destination 192.0.2.6 is a loopback
> > on Core-2 or its a different physical device attached behind Core-2 ?
> > If its a loopback on core-2 then i would suggest to put a different
> > router attached to core-2 for accurate testing .
>
> It's a router behind core-2 which supplies a default gateway in the VRF we
> test in. My current plan is just to have traffic run through a device that
> I
> can reload/power-off/destroy and see the the auto-tunnels do their magic.
> Since I only have one connection out of the setup I need to be able to use
> cost to make traffic flow along some specific path, otherwise I'd have to
> reload the device with the exit and there would be no repair path.
>
> In a production setup I could easily imagine a link that had gone "bad"
> one way or the other (like dropping 0.1% of packets) that I would want to
> route around unless it was the only link. Or maybe we would need to service
> that specific link. If auto-tunnels won't let us handle situations like
> these it's not worth much. :-)
>
> We can of course generate these tunnels manually, that's just a whole lot
> more configuration than those three global-config lines.
>
> --
> 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/
>
>