Mailing List Archive

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? 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.

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

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

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. And it looks like it's using P2P IPs for
BGP session. Is there some reason why it's not run between loopback IPs?
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 juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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 juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp