Hello Rob, thanks for sharing, seems like all Junos versions above 17.3R3 are affected.
BTW another entertaining bug affects the LAG load balancer. Ever tried adding an additional interface to an existing LACP LAG on Junos 18.2? The LAG load balancer will immediately send traffic through the newly added interface even if there is no working LACP session on that interface (for example because the other side hasn't added that interface yet to their LAG). The end result is that everything that gets hashed onto the newly added interface will get blackholed. Something tells me that Junos 18.2 isn't the only version affected by this. All of the changes and work that is being done on the RPD code and other parts of Junos is completely worthless to me if folks at Juniper don't start writing regression tests. Regards Karl ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ *From:* Rob Foehl [mailto:r...@loonybin.net] *Sent:* Thu, Sep 27, 2018 12:20 AM CEST *To:* Ivan Malyarchuk *Cc:* juniper-nsp@puck.nether.net *Subject:* [j-nsp] "set routing-options protect core" breaks local-preference > On Mon, 10 Sep 2018, Ivan Malyarchuk wrote: > >> Hi. We also find something wrong with "protect core". >> Seems like Junos 18.1 and 18.2 (running on MX204 in our case) makes one >> #Multipath equal-cost group with ALL paths except one worst AND one with >> worst path - as backup. >> >> I think it must create #Multipath forwarding-only route with one best >> (active, with weight of nexthop 0x1, find in detail output) and one "second >> best" path as backup (with weight 0x4000). However I cant find any public PR >> or Known Issues references in 18.x release notes nor in prsearch. > > Just hit this issue with 17.4R2 on a newly installed RE-S-X6-64G. PIC works > fine as long as all routes are equivalent local preference; as soon as one > arrives with a lower preference, the #Multipath entry appears with all higher > preference routes installed as equivalent active routes and the lower > preference as the sole inactive: > > #Multipath Preference: 255 > [...] > Protocol next hop: [X] > Indirect next hop: 0x940dc00 1048575 INH Session ID: 0x143 > Weight 0x1 > Protocol next hop: [Y] > Indirect next hop: 0x940da00 1048574 INH Session ID: 0x142 > Weight 0x1 > Protocol next hop: [Z] > Indirect next hop: 0x9411800 1048624 INH Session ID: 0x161 > Weight 0x4000 > State: <ForwardingOnly Int Ext> > Inactive reason: Forwarding use only > > In this case, [X] has a greater IGP cost than [Y], and the BGP decision is > correct, but [X] is still installed in the forwarding table as an active > route. > > Anyone have any PRs or existing tickets they'd be willing to share (off-list > is fine) for purposes of sending JTAC in the right direction? > > -Rob > _______________________________________________ > 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
