[j-nsp] ISIS metric of redistributed directly connected routes

[Richard A Steenbergen]

On Mon, Mar 02, 2009 at 09:29:22AM +0100, Hannes Gredler wrote:
> hi richard,
> 
> guessing the "correct" export metric of a direct route
> is a bit of philosophical question ;-) - let me explain:
> 
> since JUNOS does not know which end(point) of the subnet you are
> interested in, it advertises the worst case, which is the cost
> to reach the far-end, the cost of "crossing" the interface.
> 
> for loopback interfaces (which do not have a notion of far-end)
> the "local" cost (0) is advertised.

So it guesses this based on what, a hardcoded reference bandwidth of
100g? That would explain the behavior I'm seeing, if combined with an
implementation which didn't automatically update when the speed of an ae
changes.

I do see value in setting a cost on a non-igp speaking interface which
is simply being redistributed, I use this for traffic engineering 
purposes all the time (which is why I carry the edge interfaces in igp 
in the first place, instead of just a loopback+NHS). But assigning an 
arbitrary cost to non-igp speaking interfaces by default seems wrong, 
especially when it is assigned based on interface speed and may cause 
load balancing between equal cost paths to not work. Also, this doesn't 
seem to happen when redistributing static routes which are routed to a 
physical interface, which seems like another inconsistent application of 
metrics which would cause inconsistent load balancing.

Is this documented anywhere though? I really don't think I've ever seen
that, nobody else who I asked expected to see this behavior, and Cisco
seems to set the cost to 0 on all interfaces which aren't speaking the
igp or don't have an explicit metric assigned to them. Now that I know
whats going on at least I can disable this behavior via policy, but it
seems like if you're going to do it then a) it should be better
documented, and b) a show route detail/extensive on the direct route
should show the cost it has assigned (since the only way to see this was
to look at the isis database for the individual routes in question, to
figure out why they didn't match). And maybe throw in c) ae bandwidth
changes should auto-update the cost, and d) the reference-bandwidth
should be configurable, for good measure. :)

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)