Hi Dragan, aH, I didn't know you also had this issue; it stinks. By the way how does your ISIS export policy look like, do you use "from protocol static" when exporting this prefix to ISIS ?
Olivier > Le 6 févr. 2015 à 13:47, Dragan Jovicic <[email protected]> a écrit : > > Hi, > > Yeah we discussed that it might be logic similar to what you described. The > problem with that is, on those two routers we have 2 routes: a static - > locally originated, and a BGP route (same static route is redistributed in > both ISIS and BGP as mentioned). Once static is lost (via link LoS), BGP > route is the one and only that remains in a table, not ISIS route, even > though BGP is less preferred. Only when BGP route is lost, ISIS is installed. > This part doesn't make sense. > > As to why we have it like that is another matter, but ISIS not installing > route in inet.0 table presents a problem as BGP route is preferred. > > Regards > > > On Fri, Feb 6, 2015 at 12:21 PM, Olivier Benghozi > <[email protected] <mailto:[email protected]>> wrote: > 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] > > <mailto:[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]> <mailto:[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]> <mailto:[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] > >>> <mailto:[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] > <mailto:[email protected]> > https://puck.nether.net/mailman/listinfo/juniper-nsp > <https://puck.nether.net/mailman/listinfo/juniper-nsp> _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
