Received route with strange next-hop
Hello, I'm trying to redistribute routes from another routing daemon through synchronization of the kernel table using the kernel protocol in BIRD 2.0.4. However, I run into some problems that not all routes are imported by the BIRD router. The kernel routing table contains the following routing table: # ip route 10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.1 10.0.1.3 via 10.0.1.4 dev eth1 proto zebra metric 2 10.0.1.4 dev eth1 proto zebra scope link metric 1 10.0.4.0/24 via 10.0.0.2 dev eth0 proto bird metric 32 The interface eth1 has the address 10.0.1.1/32 in an ad-hoc routing domain, through OSPF-MDR (which is an extension of Quagga) it finds the direct neighbor 10.0.1.4 which is added as "10.0.1.4 dev eth1 proto zebra scope link metric 1". The neighbor 10.0.1.4 advertises that it can forward to 10.0.1.3 which is added as "10.0.1.3 via 10.0.1.4 dev eth1 proto zebra metric 2". The routing of OSPF-MDR works, in the sense that 10.0.1.1 can reach 10.0.1.3 and 10.0.1.4. However, when we try to import these routes from the protocol kernel into the Bird routing table, only the directly connected route to 10.0.1.4 shows while the route to 10.0.1.3 are not imported: # birdc show route BIRD 2.0.4 ready. Table master4: 10.0.1.4/32 unicast [kernel1 10:27:29.329] (10) dev eth1 10.0.4.0/24 unicast [babel1 10:27:23.461 from fe80::200:ff:feaa:4] (130/96) [00:00:00:00:0a:00:00:02] via 10.0.0.2 on eth0 10.0.0.0/24 unicast [direct1 10:27:21.870] * (240) dev eth0 unicast [babel1 10:27:23.461 from fe80::200:ff:feaa:4] (130/96) [00:00:00:00:0a:00:00:02] via 10.0.0.2 on eth0 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. I have attached the bird.conf file, as well as an image of the example topology. Above snippets and config file are taken from node n1 which is running both the OSPF-MDR router based on Quagga and BIRD Router. Any help would be much appreciated. Thanks in advance, Niels van Adrichem [cid:image001.png@01D50B0D.4706B540] 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.
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@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."
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@crfreenet.org> Sent: Thursday, May 16, 2019 5:43 PM To: Adrichem, N.L.M. (Niels) van <niels.vanadrichem@tno.nl> Cc: bird-users@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@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.
participants (2)
-
Adrichem, N.L.M. (Niels) van -
Ondrej Zajicek