Received route with strange next-hop

[Adrichem, N.L.M. (Niels) van]

Hi Ondrej,

It took me a while to continue this work, but the patch works flawlessly. Our "alien" routing protocol removes nexthop routes which become unavailable so the behavior you implemented is correct for us.

Thanks for your help,
Niels

-----Original Message-----
From: Ondrej Zajicek <santiago at crfreenet.org> 
Sent: Thursday, May 16, 2019 5:43 PM
To: Adrichem, N.L.M. (Niels) van <niels.vanadrichem at tno.nl>
Cc: bird-users at network.cz
Subject: Re: Received route with strange next-hop

On Wed, May 15, 2019 at 09:09:34AM +0000, Adrichem, N.L.M. (Niels) van wrote:
> Hello,
>
> Additionally, the bird.log file throws the following error:
> 2019-05-15 10:27:21.869 <INFO> Started
> 2019-05-15 10:27:21.902 <WARN> Missing broadcast address for interface 
> vxlan0
> 2019-05-15 10:27:29.329 <ERR> KRT: Received route 10.0.1.3/32 with 
> strange next-hop 10.0.1.4
> 

> It may be that kernel protocol rejects the route because the next-hop 
> is not in the interface its regular netmask (which is set to /32), 
> though I am not familiar enough with the source code to determine the 
> exact cause except that the error gets thrown from 
> sysdep/linux/netlink.c line 1643. However, I think the line should be 
> accepted since there is another routing rule confirming that the 
> next-hop is directly attached to device eth1. Given the explicit error 
> I don't think this is a configuration error (though I am open to learn 
> more), so I hope BIRD can be patched to solve this.

Hello

BIRD generally expects that next hop is resolvable through an address range associated with interfaces, not just through another direct/device route.

This is limitation compared to the Linux kernel which allows next hop resolvable through another direct/device route (but not through another regular route with next-hop).

We have some plans to redesign it in a more generic manner, but it is not a simple fix. As a workaround, attached patch (untested) should disable next hop checking for all alien routes.

--
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.