Here they are R0 router id 198.51.100.10; protocol kernel { scan time 60; import all; export all; # Actually insert routes into the kernel routing table } protocol device { scan time 60; } protocol ospf TEST_OSPF { tick 2; rfc1583compat yes; import all; export all; ecmp yes; merge external; area 0.0.0.0 { interface "eth0" { stub yes; }; interface "eth1" { rx buffer large; }; }; }; R1 router id 198.51.100.11; protocol kernel { scan time 60; import all; export all; # Actually insert routes into the kernel routing table } protocol device { scan time 60; } protocol ospf TEST_OSPF { tick 2; rfc1583compat yes; import all; export all; ecmp yes; merge external; area 0.0.0.0 { interface "eth0" { rx buffer large; }; interface "eth1" { rx buffer large; }; }; }; On 08/29/2016 12:55 PM, Baptiste Jonglez wrote:

Please show your configuration, especially the kernel protocol. You need an appropriate export filter.

On Thu, Aug 25, 2016 at 05:22:33PM +0300, Volodymyr Samodid wrote:

...

Hi community, i played with bird6 and ospf3 and faced with issue. In my schema bird does not install route to the kernel, but propagates route to another ospfv3 routers. That leads to routing loop.

Here is simple schema:

eth0 ------- R0 ------- eth1 ------- bridge ------ eth0 ------- R1

ospfv3 made adjacency

R0 bird> show ospf neighbors TEST_OSPF: Router ID Pri State DTime Interface Router IP 198.51.100.11 1 Full/BDR 00:34 eth1 fe80::602c:e2ff:fe96:9c41

R1 bird> show ospf neighbors TEST_OSPF: Router ID Pri State DTime Interface Router IP 198.51.100.10 1 Full/DR 00:34 eth0 fe80::88e0:e3ff:fe08:7842

Now add ipv6 address to eth1 on R0

R0# ip a add 2001:DB8::1/64 dev eth1

on R1, got next

bird> >>> TEST_OSPF > added [best] 2001:db8::/64 dev eth0 bird> show route 2001:db8::/64 dev eth0 [TEST_OSPF 13:58:11] * I (150/10) [198.51.100.11]

R1# ip -6 ro s fe80::/64 dev eth0 proto kernel metric 256 pref medium

added ipv6 address to eth0 on R0

R0# ip a add 2001:DB8:1::1/64 dev eth0

on R1 bird> >>> TEST_OSPF > added [best] 2001:db8:1::/64 via fe80::88e0:e3ff:fe08:7842 on eth0

...

...

...

kernel1 < added 2001:db8:1::/64 via fe80::88e0:e3ff:fe08:7842 on eth0 bird> show route 2001:db8::/64 dev eth0 [TEST_OSPF 13:58:11] * I (150/10) [198.51.100.11] 2001:db8:1::/64 via fe80::88e0:e3ff:fe08:7842 on eth0 [TEST_OSPF 14:05:31] * I (150/20) [198.51.100.10]

R1# ip -6 ro s 2001:db8:1::/64 via fe80::88e0:e3ff:fe08:7842 dev eth0 proto bird metric 1024 pref medium fe80::/64 dev eth0 proto kernel metric 256 pref medium

R1## ip monitor route 2001:db8:1::/64 via fe80::88e0:e3ff:fe08:7842 dev eth0 proto bird metric 1024 pref medium

I can add such route manual. R1# ip ro add 2001:db8::/64 dev eth0

-- С уважением, Самодед Владимир SVAJ-RIPE|SVA88-UANIC

On Tue, Sep 13, 2016 at 10:07:54PM +0300, Volodymyr Samodid wrote:

I found misconfiguration in that schema.

"device routes" option for kernel protocol allows install such route.

Hi Generally, if you add local IP address/prefix, Linux kernel will add appropraite device route itself [1]. That is the reason why BIRD kernel protocol avoids to interfere with device routes unless explicitly enabled. I have no idea why the device route was not added by Linux in your case. # ip a add 2001:DB8::1/64 dev eth0 # ip -6 r l 2001:db8::/64 dev eth0 proto kernel metric 256 fe80::/64 dev eth0 proto kernel metric 256 Actually, i have one idea that could explain the behavior - if you added 2001:DB8::1/64 on both R0 and R1 while OSPF is already active and associated, the sequence could look like: 1) first you add the prefix (call it N) on say R1 2) N is immediately propagated by OSPF to R0, where OSPF generates a regular route for N (directed to R1) and that is pushed to kernel. 3) After that, you add the prefix N on R0 4) Linux kernel on R0 genrerates device route for N 5) Now, you have two routes for N in Linux kernel routing table, one regular route from OSPF, one device from kernel. 6) BIRD on R0 notices new local IP address with prefix N, OSPF recomputes its routing table and replaces regular route for N directed to R1 with device route for N. 7) BIRD kernel protocol tries to remove old regular route for N from kernel routing table. New device route is not pushed due to 'device routes' option disabled. 8) Now a Linux kernel bug comes - instead of removing regular BIRD route for N, it removes its own device route. I noticed this bug just several days ago. Route remove request contains a protocol field, which should filter applicable routes for removal. This works on IPv4, but is ignored on IPv6. 9) During periodic scan, BIRD notices that there is a regular BIRD route for N in the kernel routing table, (which should not be here and should be removed in the previous step) and removes it again, successfully. 10) You end with no route for N in Linux kernel table. I am currently working on kernel protocol option that allows to workaround the issue by using explicit kernel metric for all BIRD 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."