Hi, Distance & path vector protocols (RIP, BGP) directly use RIB in JunOS as storage for the routes (unlike Cisco, where there's a BGP table before the RIB by example). In link-state protocols there's nothing such as a "route", only link-state information stored in a separate database, whose information is later translated to routes toward the RIB (even if OSPF LSA type 5/7 are probably closer to routes).
My understanding is that: - you have a route a.b.c.d/y as a static to <whatever> on your router. - this route is exported to the ISIS process (there's not really any ISIS process, everything is in rpd process, but whatever), and becomes a 135 TLV attached to the LSP the router is generating for itself toward the other ones. - in the ISIS process, there's also another received LSP from another router (the other one generating the static) for the same prefix, also as a 135 TLV. - in the ISIS process, when translating LSPs to routes, your own LSP wins for this prefix. The received LSP looses for it. The winning one is the one generated locally. Nothing is exported to the RIB, a routing process doesn't reexport to the RIB the route it imported from the RIB. The behavior is really cisco-like in those conditions... Olivier > 6 feb. 2015 at 10:57, Dragan Jovicic <[email protected]> wrote : > > Hi all, > > I meant to say that I myself might have not be clear enough about the > problem I'm describing. Sorry if that sounded a bit off - I know Mark is a > stellar contributor. > > In any case, it is a single-topology, no-ipv6, single L2 domain with all > routers receiving correct LSP. The prefix is included in TLV 135, all > routers have correct information. > > Same static route is redistributed in both ISIS and BGP. > > From what I know about JUNOS, it should install a valid route from ISIS RIB > into inet.0. It will not be active route (due to static /5), but it will be > there. In this case however it isn't. > > This behavior is not observed when routes are different, as expected. > Unfortunately, we can't change preference of routes in production to test > this live. > > We opened the case with our support, from some talk around it seems as it > is a bug so far, unless we're missing on something major here. > > > Much regards. > > > > On Fri, Feb 6, 2015 at 10:45 AM, Alan Gravett <[email protected] > <mailto:[email protected]>> wrote: > >> Hi Dragan, >> >> Mark rarely misses the point from what I have seen with his contributions >> on this list. >> >> I have some initial suggestions inline with your own text so that it may >> begin to >> make sense. >> >> On Fri, Feb 6, 2015 at 11:10 AM, Dragan Jovicic <[email protected] >> <mailto:[email protected]>> >> wrote: >> >>> Hi, >>> I think you are missing a point. >>> >>> ISIS route should still be in routing table, just not preferred (static /5 >>>> isis /18). >>> >>> The issue here is that only static is found in routing table. I hope it is >>> clearer? >>> >>> I tested on two different routers, injecting static route into both ISIS >>> and BGP. All routers in domain display both ISIS and BGP learned routes, >>> but ISIS is prefered. >>> >> >> This may have to do with the differences between Link-state and other >> algorithms. >> What happens when you change the route preference for IS-IS to be higher >> than >> BGP? >> >> >>> >>> However, on the two routers where the route is injected (a static discard >>> route), only local static and BGP learned route is showed. That doesn't >>> make sense. >>> >> >> I would also be curious to know what happens if the two routers are >> advertising >> different static routes - but am almost sure the behavior would be >> different. (you >> would see what you have been expecting in the current scenario) >> >> Regards, >> >> Alan >> >>> >>> Regards >>> >>> On Fri, Feb 6, 2015 at 9:41 AM, Mark Tinka <[email protected]> wrote: >>> >>>> >>>> On 6/Feb/15 09:28, Dragan Jovicic wrote: >>>> >>>>> Hi, >>>>> The route is not in routing table of those two routers. >>>>> Every other router installs redistributed route, except those two which >>>>> are >>>>> redistributing the route. Those two only show static/5 route, not ISIS >>>>> form >>>>> other neighbor. >>>>> >>>>> show isis route does not show that prefix is calculated, so it is not >>> in >>>>> ISIS RIB hence not in inet.0. >>>>> >>>>> But LSP shows redistributed route. Once one of the hosts removes it's >>>>> static route, only then is new ISIS route installed. >>>>> >>>>> I suppose the behavior I expected was to install ISIS route form other >>>>> neighbor as well, albeit as inactive. >>>>> >>>> >>>> As static routes are better than routes learned from dynamic routing >>>> protocols, this is expected behaviour unless you tune the preference of >>>> either your static route or IS-IS on the affected router. >>>> >>>> Mark. _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
