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

[Andrey Kostin]

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