On Mon, Dec 20, 2021 at 04:47:23PM -0500, Andrey Kostin wrote: > Thanks for details, it looks a little illogical though. > I mentioned that the best BGP route is received from the same OSPF/LDP > neighbor in the same island.
Because it's oversimplified lab, just to demonstrate unexpected behaviour. In real life, OSPF/LDP route shall come from inside the island and ibgp-lu from the outside. > And it looks like it's using P2P IPs for > BGP session. Is there some reason why it's not run between loopback IPs? Sure, there is: I planned to use ibgp-lu to announce loopbacks reachability only, something like 'igp-on-steroids' scenario (not a real IGP, because with IGP you have no options for example, to filter some loopbacks over some links). > Just shot in the dark, maybe with sessions between loopbacks BGP would > rely on OSPF for next-hop resolution and it can change the behavior? > > Kind regards, > Andrey Kostin > > Alexandre Snarskii писал(а) 2021-12-20 12:31: > > On Mon, Dec 20, 2021 at 09:08:40AM -0500, Andrey Kostin wrote: > >> Hi Alexandre, > >> > >> Not sure that I completely understood the issue. When connectivity > >> between islands recovers, what is the primary route for regular BGP > >> routes' protocol next-hop? > > > > It's not the connectivity between islands, it's the connectivity > > within IGP island that recovers. Assume the following simple > > topology: > > > > A ========== B > > | | > > C ========== D > > > > Routers A and B form one IGP island, C and D - other, and there are > > two ibgp-lu links between islands with ldp->ibgp-lu->ldp > > redistribution. > > > > In normal situation, route A to B goes via direct link (igp/ldp), > > when link A-B breaks, A switches to ibgp-lu route from C. > > When link A-B recovers, A does not switch back to direct link and > > still uses A->C route (in best case it's just suboptimal, in worst > > case it results in routing loops). > > > >> Looks like it should be OSPF with route > >> preference lower than BGP and in this case it should be labeled by LDP > >> and propagated. Only if OSPF route for a protocol next-hop is not the > >> best, the next-hop from BGP-LU will be used. > > > > Unfortunately, it's expected behaviour, but not what I see in lab. > > Oversimplified: just two routers, one p2p link with all three ospf/ldp/ > > ibgp-lu enabled, > > > > show route xx.xxx.xxx.78/32 table inet.0 > > > > inet.0: > > xx.xxx.xxx.78/32 *[OSPF/10] 5d 04:58:59, metric 119 > > > to xxx.xx.xxx.21 via ae0.6 > > > > (so, ospf route is the best one in inet.0) > > > > show ldp database session xx.xxx.xxx.7 | match > > "database|xx.xxx.xxx.78/32" > > Input label database, xxx.xx.xxx.8:0--xx.xxx.xxx.7:0 > > 66742 xx.xxx.xxx.78/32 > > Output label database, xxx.xx.xxx.8:0--xx.xxx.xxx.7:0 > > 5743 xx.xxx.xxx.78/32 > > > > so the label is present and not filtered (.7 is the router-id of .21), > > > > show route xx.xxx.xxx.78/32 receive-protocol bgp xxx.xx.xxx.21 > > > > inet.3: 467 destinations, 1125 routes (467 active, 0 holddown, 0 > > hidden) > > Restart Complete > > Prefix Nexthop MED Lclpref AS path > > * xx.xxx.xxx.78/32 xxx.xx.xxx.21 19 100 I > > > > so, it's received and is the best route in inet.3 (best, because > > there are no ldp route in inet.3 at all: > > > > show route .. table inet.3 > > > > xx.xxx.xxx.78/32 *[BGP/10] 02:10:43, MED 19, localpref 100 > > AS path: I, validation-state: unverified > > > to xxx.xx.xxx.21 via ae0.6, Push 69954 > > > > ), and, finally, > > > > show ldp route extensive xx.xxx.xxx.78/32 > > Destination Next-hop intf/lsp/table > > Next-hop address > > xx.xxx.xxx.78/32 ae0.6 > > xxx.xx.xxx.21 > > Session ID xxx.xx.xxx.8:0--xx.xxx.xxx.7:0 > > > > xxx.xx.xxx.21 > > Bound to outgoing label 5743, Topology entry: 0x776dd88 > > Ingress route status: Inactive > > Route type: Egress route, BGP labeled route > > Route flags: Route deaggregate > > > > suggests that presence of ibgp-lu route prevented ldp route from being > > installed to inet.3 and being used. > > > > PS: idea from KB32600 (copy ibgp-lu route from inet.3 to inet.0 and > > then > > use "from protocol bgp rib inet.0" in ldp egress policy) does not work > > too. Well, in this case presence of ibgp-lu route does not prevent ldp > > route from being installed into inet.3 and used as best route (when > > present, of course), but when ldp/igp route is missed, route received > > with ibgp-lu not gets redistributed into ldp. > > > >> _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
