[j-nsp] labeled-unicast to ldp redistribution ?

[Alexandre Snarskii]

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