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

Adam Vitkovsky adam.vitkovsky at swan.sk
Thu Oct 17 05:13:50 EDT 2013


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/



More information about the cisco-nsp mailing list