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.
