Resolve a BGP next-hop with another BGP route

[Alarig Le Lay]

Hi Ondrej,

On 30/09/2019 01:52, Ondrej Zajicek wrote:
> On Sun, Sep 29, 2019 at 08:49:57PM +0200, Alarig Le Lay wrote:
>> Hello,
>>
>> It seems that bird can’t resolve the next-hop in that case. But there is
>> no issue when the next-hop is announced by OSPF.
> 
> Hello
> 
> Yes. Technically it is not because the other route is also BGP, but
> because the other route is also recursive / also has indirect next hop.
> BIRD implements only one level of indirection.
> 
> Is this a problem? Which use cases require more levels of indirections?

I think so. In this case it’s legit for me. I have some hypervisors with
few VMs (less than 100), so I’m routing each /32 IPv4 and /48 IPv6
addresses to each tap and doing BCP38 directly on the node. Those routes
are advertised to my edges by BGP.
(I will certainly do it differently when my FIB will be full of very
specific routes, but for now it’s working very well)

One of my customers wanted an additional range routed to his VM. So I
added it to our routing system (which does `ip route add ${range} via
${vm}` at startup hook) and as such, the next-hop is the VM itself.
The bird on the node learns the route well, I added the community to
advertise the prefix to my upstreams, and as soon as the VM is shut
down, I don’t receive any traffic on the range anymore.

But, the bird on one of my edges does not resolve the next-hop and as
such blackholes the traffic.

As a workaround I added a 'next hop self', but design wise, I don’t need
it here.
(I don’t need it on the other parts of my network either :p)

Regards,
-- 
Alarig