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 <[email protected]>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:[email protected]] 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 [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/
