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.
>
> Kind regards,
> Andrey Kostin
>
> Alexandre Snarskii via juniper-nsp писал(а) 2021-12-17 12:29:
> > Hi!
> >
> > Scenario: router is a part of ospf/ldp island and also have ibgp
> > labeled-unicast rib inet.3 link to other ospf/ldp island. In normal
> > situations, some routes are known through ospf/ldp, however, during
> > failures they may appear from ibgp-lu and redistributed to ldp just
> > fine. However, when failure ends and route is known via ospf/ldp again,
> > it's NOT actually in use. Instead, 'show ldp route extensive' shows
> > this route as:
> >
> > Ingress route status: Inactive
> > Route type: Egress route, BGP labeled route
> > Route flags: Route deaggregate
> >
> > and there are only ibgp route[s] in inet.3 table.
> >
> > Are there any way to make ldp ignore 'BGP labeled' flag and install
> > route to inet.3 ? (other than making all routes be known not only
> > via ospf/ldp but also via ibgp-lu too).
> >
> > _______________________________________________
> > 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
