Hi, Yes, exactly like that, with route-filter specifying a prefix.
Regards On Fri, Feb 6, 2015 at 1:55 PM, Olivier Benghozi < olivier.bengh...@wifirst.fr> 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 <dragan...@gmail.com> 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 < > olivier.bengh...@wifirst.fr> 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 <dragan...@gmail.com> 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 <alan...@gmail.com >> <mailto:alan...@gmail.com>> 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 <dragan...@gmail.com >> <mailto:dragan...@gmail.com>> >> >> 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 <mark.ti...@seacom.mu> >> 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 juniper-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/juniper-nsp >> > > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp