Importing routes with "strange next-hop" from the kernel

[Baptiste Jonglez]

Hi,

To save some IP space, we are playing a lot with /32 routes, which
sometimes leads to unusual network setups.

Specifically, we've hit this issue with Bird:

  http://marc.info/?l=bird-users&m=133465758907527&w=2

Basically, bird refuses to import a route from the kernel if the next-hop
is not in a directly connected network.  For instance, with a routing
table like this:

  XX.XX.XX.32 dev eth1.101  proto static  scope link  src XX.XX.XX.1 
  XX.XX.XX.64/28 via 91.216.110.32 dev eth1.101  proto static

bird will import the first route, but not the second one, spamming logs
with "KRT: Received route XX.XX.XX.64/28 with strange next-hop XX.XX.XX.32".

This is probably a good idea in most cases, but there are setups where
these kind of routes make sense.


The workaround described in the above thread ("ip addr add XX.XX.XX.1 peer
XX.XX.XX.32") does not always apply, since we may want to have multiple
/32 peers directly reachable on a given interface.

We found another workaround (note the "onlink" flag and the "via" part):

  ip route add XX.XX.XX.32/32 via XX.XX.XX.32 dev eth1.101 onlink proto static

This basically tells the kernel that the route we added is indeed in a
connected network, so that Bird is happy.
Note that subsequent routes using this /32 as next-hop also need the
"onlink" flag:

  ip route add XX.XX.XX.64/28 via XX.XX.XX.32 dev eth1.101 proto static onlink


In the hope that it will help someone someday,
Baptiste
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20140421/201e0b96/attachment.asc>