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/
