Damn, if no one has a clue I guess we're condemned to wait for your JTAC results...
> Le 6 févr. 2015 à 14:08, Dragan Jovicic <[email protected]> a écrit : > > Hi, > > Yes, exactly like that, with route-filter specifying a prefix. > > Regards > > On Fri, Feb 6, 2015 at 1:55 PM, Olivier Benghozi <[email protected] > <mailto:[email protected]>> wrote: > 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] >> <mailto:[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] https://puck.nether.net/mailman/listinfo/juniper-nsp
