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

[Richard A Steenbergen]

Question about the default metric of a route being redistributed from 
directly connected to isis...

Router A is connected to Router B (both Juniper) via a single link which
has an isis (level 2 only) interface metric of 10 on both sides. The
loopbacks are injected into isis via an interface passive command with
explicit metric of 0. Router B has an interface which is being
redistributed into isis using an export policy like so:

term DIRECT {
    from protocol direct;
    then accept;
}

But the observed metric value from router A on all of the routes being
"redistributed" in this way from router B is 20, even though the
interface metric between routers is only 10. The loopback route (which
isn't redistributed) has a correct value of 10. A show isis database
detail confirms that the other routers are receiving the "redistributed"
route with a metric of 10 before adding interface costs. After playing
around with it for a bit, I was able to reset this to 0 by changing the
above redistribution to:

term DIRECT {
    from protocol direct;
    then {
        metric 0;
        accept;
    }
}

Now the reason I noticed this in the first place was that there was also
a router A-C link where router C was doing the exact same thing, but
with a metric of 5 instead of 10, thus preventing router A from load
balancing properly. 

After looking through other routers doing the same thing, the common
pattern seems to be the type or speed of the directly connected
interface being redistributed, with xe's being given a cost 10, and
multi-xe ae's given costs 5 or 3. This pretty much screams some kind of
reference bandwidth, of say 100g being divided by 10g increments to get
10, 5, 3, though oddly enough it doesn't always match this pattern (for
example, I found a 2x10G AE being given metric 3). I do have isis
reference bandwidth configured, but with a value of 1000g not 100g
(mostly to set a high interface metric in the even that something is
accidentally left unconfigured), and changing the reference bandwidth
value seems to have no effect on the default isis route metrics. As far
as I knew reference bandwidth only affected the metric of interfaces
participating in isis, not the metric on the route as it is being
redistributed from directly connected into isis.

Maybe I'm being dense, but I really can't say that I've ever seen this
documented anywhere... Can anybody point to anything explaining this
behavior?

-- 
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)