[j-nsp] IS-IS not installing route into RIB

[Dragan Jovicic]

Hi,

Yes, exactly like that, with route-filter specifying a prefix.

Regards

On Fri, Feb 6, 2015 at 1:55 PM, Olivier Benghozi <
olivier.benghozi at 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 <draganj84 at 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.benghozi at 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 <draganj84 at 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 <alangra at gmail.com
>> <mailto:alangra at 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 <draganj84 at gmail.com
>> <mailto:draganj84 at 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.tinka at 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 at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>
>