bird 1.6 seems to ignore ipv6 kernel routes on 4.19
Hi, I recently updated some virtual machine hosting nodes to Debian Buster from Stretch, and I'm having an interesting problem with IPv6 kernel routes. My example uses 1.6.6 but 1.6.7 shows the same behaviour, so I'm just wondering what I am missing. v4 is all working as expected. I tried a bird6.conf from a machine still running Debian Stretch, and that also did not import the kernel routes. I've tried this on a test VM with bird 1.6.3 and kernel 4.9.0 and it imports the routes as expected. I've set up a test VM in the lab with the following bird6.conf: -------------------------------------- root@os-test:~# grep -v ^# /etc/bird/bird6.conf router id 198.51.100.1; protocol kernel { scan time 60; learn; device routes; #import none; import all; } protocol device { scan time 60; } -------------------------------------- This is just the sample file with "learn", "import all" and "device routes" added to the kernel protocol. I have added a test kernel route: root@os-test:~# route -6 add 2a03:9804::/64 gw 2a03:9802:1000:aa::1 I would expect to see this in a "show route" output from birdc6, but I don't. I only see the default: root@os-test:~# birdc6 BIRD 1.6.6 ready. bird> show route ::/0 via 2a03:9802:1000:aa::1 on ens2 [kernel1 21:14:40] * (10) bird> If I add a protocol direct section, then I get device routes but still not indirect kernel routes. Some other stuff about the system, sorry if this hasn't pasted so well. root@os-test:~# uname -a Linux os-test.portfast.net 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) x86_64 GNU/Linux root@os-test:~# netstat -rn6 Kernel IPv6 routing table Destination Next Hop Flag Met Ref Use If ::1/128 :: U 256 2 0 lo 2a03:9802:1000:aa::/64 :: U 256 3 0 ens2 2a03:9804::/64 2a03:9802:1000:aa::1 UG 1 1 0 ens2 fe80::/64 :: U 256 1 0 ens2 ::/0 2a03:9802:1000:aa::1 UGH 1024 2 0 ens2 ::1/128 :: Un 0 4 0 lo 2a03:9802:1000:aa::2/128 :: Un 0 3 0 ens2 fe80::5054:ff:fe10:d040/128 :: Un 0 3 0 ens2 ff00::/8 :: U 256 2 0 ens2 ::/0 :: !n -1 1 0 lo Thanks, -- Tom Bird http://www.portfast.co.uk/ : AS8916 UK Limited company #6061075 : +44 1777 29 28 27
On Wed, Aug 21, 2019 at 02:35:13PM +0100, Tom Bird wrote:
Hi,
I recently updated some virtual machine hosting nodes to Debian Buster from Stretch, and I'm having an interesting problem with IPv6 kernel routes. My example uses 1.6.6 but 1.6.7 shows the same behaviour, so I'm just wondering what I am missing. v4 is all working as expected.
Hi It seems that it is related to adding routes using 'route' command instead of 'ip route' command. # ip r a 2001:db8:1:14::/64 via 2001:db8:1:1::14 # route -6 add 2001:db8:1:15::/64 gw 2001:db8:1:1::15 # ip r a 2001:db8:1:16::/64 via 2001:db8:1:1::16 metric 1 # ip -6 r l ... 2001:db8:1:14::/64 via 2001:db8:1:1::14 dev ve0 metric 1024 pref medium none 2001:db8:1:15::/64 via 2001:db8:1:1::15 dev ve0 metric 1 pref medium 2001:db8:1:16::/64 via 2001:db8:1:1::16 dev ve0 metric 1 pref medium ... bird> show route protocol kernel1 2001:db8:1:14::/64 via 2001:db8:1:1::14 on ve0 [kernel1 17:39:42] * (10) 2001:db8:1:16::/64 via 2001:db8:1:1::16 on ve0 [kernel1 17:42:50] * (10) Note the 'none' in route added by 'route' command. Perhaps such route has some strange attribute and that is why it is ignored by BIRD.
I tried a bird6.conf from a machine still running Debian Stretch, and that also did not import the kernel routes.
I've tried this on a test VM with bird 1.6.3 and kernel 4.9.0 and it imports the routes as expected.
Perhaps it may be difference in in kernel version? Different traslation of old route API calls? -- 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."
Hello!
I recently updated some virtual machine hosting nodes to Debian Buster from Stretch, and I'm having an interesting problem with IPv6 kernel routes. My example uses 1.6.6 but 1.6.7 shows the same behaviour, so I'm just wondering what I am missing. v4 is all working as expected.
Hi
It seems that it is related to adding routes using 'route' command instead of 'ip route' command.
# ip r a 2001:db8:1:14::/64 via 2001:db8:1:1::14 # route -6 add 2001:db8:1:15::/64 gw 2001:db8:1:1::15
This command uses the old ioctl(SIOCADDRT) API which in turn generates
none 2001:db8:1:15::/64 via 2001:db8:1:1::15 dev ve0 metric 1 pref medium
with rtm_type == RTN_UNKNOWN (0), which is obviously wrong.
# ip r a 2001:db8:1:16::/64 via 2001:db8:1:1::16 metric 1
This command uses the Netlink API.
2001:db8:1:16::/64 via 2001:db8:1:1::16 dev ve0 metric 1 pref medium
This route has rtm_type == RTN_UNICAST (1).
Note the 'none' in route added by 'route' command. Perhaps such route has some strange attribute and that is why it is ignored by BIRD.
This may have been recently broken in Linux kernel. As the route command is deprecated since at least 2011 in many distributions together with the linux kernel developers themselves, I suggest simply using the ip tool. For more information, look at https://wiki.linuxfoundation.org/networking/net-tools https://wiki.linuxfoundation.org/networking/iproute2 https://www.archlinux.org/news/deprecation-of-net-tools/ https://lists.debian.org/debian-devel/2009/03/msg00780.html Maria
Maria Jan Matejka <jan.matejka@nic.cz> writes:
Hello!
I recently updated some virtual machine hosting nodes to Debian Buster from Stretch, and I'm having an interesting problem with IPv6 kernel routes. My example uses 1.6.6 but 1.6.7 shows the same behaviour, so I'm just wondering what I am missing. v4 is all working as expected.
Hi
It seems that it is related to adding routes using 'route' command instead of 'ip route' command.
# ip r a 2001:db8:1:14::/64 via 2001:db8:1:1::14 # route -6 add 2001:db8:1:15::/64 gw 2001:db8:1:1::15
This command uses the old ioctl(SIOCADDRT) API which in turn generates
none 2001:db8:1:15::/64 via 2001:db8:1:1::15 dev ve0 metric 1 pref medium
with rtm_type == RTN_UNKNOWN (0), which is obviously wrong.
Looks like the kernel ioctl handler will copy the type if userspace sets it: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/... but 'route' doesn't set it: https://sourceforge.net/p/net-tools/code/ci/master/tree/lib/inet6_sr.c -Toke
On Wed, Aug 21, 2019 at 11:30:53PM +0200, Toke Høiland-Jørgensen wrote:
# ip r a 2001:db8:1:14::/64 via 2001:db8:1:1::14 # route -6 add 2001:db8:1:15::/64 gw 2001:db8:1:1::15
This command uses the old ioctl(SIOCADDRT) API which in turn generates
none 2001:db8:1:15::/64 via 2001:db8:1:1::15 dev ve0 metric 1 pref medium
with rtm_type == RTN_UNKNOWN (0), which is obviously wrong.
Looks like the kernel ioctl handler will copy the type if userspace sets it:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/...
but 'route' doesn't set it:
https://sourceforge.net/p/net-tools/code/ci/master/tree/lib/inet6_sr.c
Hi Thanks, i am wondering if that is a change in kernel, route command, or just nobody noticed it before. -- 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."
Ondrej Zajicek <santiago@crfreenet.org> writes:
On Wed, Aug 21, 2019 at 11:30:53PM +0200, Toke Høiland-Jørgensen wrote:
# ip r a 2001:db8:1:14::/64 via 2001:db8:1:1::14 # route -6 add 2001:db8:1:15::/64 gw 2001:db8:1:1::15
This command uses the old ioctl(SIOCADDRT) API which in turn generates
none 2001:db8:1:15::/64 via 2001:db8:1:1::15 dev ve0 metric 1 pref medium
with rtm_type == RTN_UNKNOWN (0), which is obviously wrong.
Looks like the kernel ioctl handler will copy the type if userspace sets it:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/...
but 'route' doesn't set it:
https://sourceforge.net/p/net-tools/code/ci/master/tree/lib/inet6_sr.c
Hi
Thanks, i am wondering if that is a change in kernel, route command, or just nobody noticed it before.
A bit of git archaeology points suggestively at this commit: https://git.kernel.org/torvalds/c/e8478e80e5a
From April 2018; so looks like it might actually be a regression in the kernel. I'll send a bug report to netdev...
-Toke
On 21/08/2019 16:50, Ondrej Zajicek wrote:
On Wed, Aug 21, 2019 at 02:35:13PM +0100, Tom Bird wrote:
Hi,
I recently updated some virtual machine hosting nodes to Debian Buster from Stretch, and I'm having an interesting problem with IPv6 kernel routes. My example uses 1.6.6 but 1.6.7 shows the same behaviour, so I'm just wondering what I am missing. v4 is all working as expected.
Hi
It seems that it is related to adding routes using 'route' command instead of 'ip route' command.
That's really interesting and you are right. This explains why my default route was getting into bird in my test environment (system init scripts won't be using the legacy route command). It has been a to-do of mine for some time to deprecate the old 'route' and 'ifconfig' in some of our internal scripts so I think today might be the day to do that.
Perhaps it may be difference in in kernel version? Different traslation of old route API calls?
It's still a valid route that the kernel acts on, so I would class this as a bug of some sort. It looks like this list is the place to report such things so I shall leave it here. Thanks very much for getting to the bottom of it. -- Tom Bird http://www.portfast.co.uk/ : AS8916 UK Limited company #6061075 : +44 1777 29 28 27
participants (4)
-
Maria Jan Matejka -
Ondrej Zajicek -
Toke Høiland-Jørgensen -
Tom Bird