As a followup to this thread, I don’t know why I didn’t try this to start with, but installing 2.0.4 on the router having problems cleared it up with no change to configuration.
I did try to upgrade to 2.0.5 and the problem returned. Now that I know for sure that this is a problem in BIRD (either with a regression or some change that is required by spec but not clear how to configure for), I will try to diff the sources and see what might have caused this. Regards, Brian > On Feb 19, 2020, at 3:43 PM, Brian Topping <[email protected]> wrote: > > If it helps, I uploaded the output from `debug backbone all` && `restart > backbone` to > https://gist.github.com/briantopping/7313d6bda963ea01b6d1288fda4942e8 > >> On Feb 17, 2020, at 12:17 AM, Brian Topping <[email protected]> wrote: >> >> Greetings, I have a network with four routers on an OSPF backbone. Only one >> of the four routers cannot export the type 5 LSA entries to the kernel. I >> cannot figure out why. I wonder if I might kindly ask some guidance. >> >> The routers (including the problem router) are all BIRD 2.0.7 with the >> router with IP 10.10.4.1 running 2.0.4. The kernels are Linux 4.20.x. >> >> Here is the OSPF for a working router: >> >>> protocol ospf backbone { >>> ipv4 { >>> export all; >>> import filter { if net = 0.0.0.0/0 then reject; else accept; }; >>> }; >>> area 0.0.0.0 { >>> interface "eno2" {}; >>> interface "vti*" { >>> type nbma; >>> strict nonbroadcast yes; >>> neighbors { >>> 10.9.254.2 eligible; >>> }; >>> }; >>> }; >>> } >> >> >> >> The OSPF configuration of the router having problems. They are virtually >> identical with the exception of the interfaces: >> >>> protocol ospf backbone { >>> ipv4 { >>> export all; >>> import filter { if net = 0.0.0.0/0 then reject; else accept; }; >>> }; >>> area 0.0.0.0 { >>> interface "bond0" { >>> }; >>> interface "vti*" { >>> type nbma; >>> neighbors { >>> 10.9.255.1 eligible; >>> 10.9.254.1 eligible; >>> }; >>> }; >>> }; >>> } >> >> >> All the routers have *identical* LSADBs on each router (not shown). master4 >> is correct on the working routers: >>> [root@gw02 ~]# birdc show route >>> BIRD 2.0.7 ready. >>> Table master4: >>> 0.0.0.0/0 unicast [bgp_handy_125 02:07:43.248] * (100) [AS30475i] >>> via c.d.143.125 on eno1 >>> unicast [bgp_handy_126 02:07:43.661] (100) [AS30475i] >>> via c.d.143.126 on eno1 >>> a.b.96.0/32 unicast [backbone 02:07:46.207] E2 (150/10/10000) >>> [c.d.143.113] >>> via 10.10.0.41 on eno2 >>> a.b.96.9/32 unicast [backbone 02:07:46.207] E2 (150/10/10000) >>> [c.d.143.113] >>> via 10.10.0.41 on eno2 >>> a.b.96.8/32 unicast [backbone 02:07:46.207] E2 (150/10/10000) >>> [c.d.143.113] >>> via 10.10.0.41 on eno2 >>> a.b.96.11/32 unicast [backbone 02:07:46.207] E2 (150/10/10000) >>> [c.d.143.113] >>> via 10.10.0.41 on eno2 >>> 10.10.0.0/22 unicast [backbone 02:07:46.207] I (150/10) >>> [c.d.143.113] >>> dev eno2 >>> 10.9.254.2/32 unicast [backbone 02:08:16.208] I (150/10) [10.10.4.21] >>> via 10.9.254.2 on vti3 >>> 10.9.254.0/24 unicast [backbone 02:08:16.208] I (150/10) [10.10.4.21] >>> dev vti3 >>> 10.9.255.2/32 unicast [backbone 02:08:16.208] I (150/10) [10.10.4.21] >>> via 10.9.254.2 on vti3 >>> 192.168.10.0/24 unicast [backbone 02:08:16.208] I (150/30) [10.10.4.1] >>> via 10.9.254.2 on vti3 >>> 10.10.4.0/22 unicast [backbone 02:08:16.208] I (150/20) [10.10.4.1] >>> via 10.9.254.2 on vti3 >>> 10.9.255.0/24 unicast [backbone 02:08:16.208] I (150/20) >>> [c.d.143.113] >>> via 10.9.254.2 on vti3 weight 1 >>> via 10.10.0.41 on eno2 weight 1 >>> a.b.97.1/32 unicast [backbone 02:07:46.207] E2 (150/10/10000) >>> [c.d.143.113] >>> via 10.10.0.41 on eno2 >>> a.b.96.10/32 unicast [backbone 02:07:46.207] E2 (150/10/10000) >>> [c.d.143.113] >>> via 10.10.0.41 on eno2 >>> a.b.96.0/24 blackhole [public_nets_proto 02:07:35.107] * (500) >>> unicast [backbone 02:07:46.207] E2 (150/10/10000) >>> [c.d.143.113] >>> via 10.10.0.41 on eno2 >>> a.b.97.0/24 blackhole [public_nets_proto 02:07:35.107] * (500) >>> unicast [backbone 02:07:46.207] E2 (150/10/10000) >>> [c.d.143.113] >>> via 10.10.0.41 on eno2 >>> [root@gw02 ~]# birdc show route a.b.96.0/32 all >>> BIRD 2.0.7 ready. >>> Table master4: >>> a.b.96.0/32 unicast [backbone 02:07:46.207] E2 (150/10/10000) >>> [c.d.143.113] >>> via 10.10.0.41 on eno2 >>> Type: OSPF-E2 univ >>> OSPF.metric1: 10 >>> OSPF.metric2: 10000 >>> OSPF.tag: 0x00000000 >>> OSPF.router_id: c.d.143.113 >> >> The router with problems does *not* have a correct copy of master4 table, it >> is missing all of the LSA type 5 entries. So of course they cannot be >> exported to kernel on that router: >>> [root@centos01 ~]# birdc show route >>> BIRD 2.0.7 ready. >>> Table master4: >>> 10.9.254.2/32 unicast [backbone 22:53:52.605] I (150/0) [10.10.4.21] >>> dev bond0 >>> 10.9.254.0/24 unicast [backbone 00:08:15.604] I (150/10) [10.10.4.21] >>> dev bond0 >>> 10.9.255.2/32 unicast [backbone 23:56:54.605] I (150/0) [10.10.4.21] >>> dev bond0 >>> 192.168.10.0/24 unicast [backbone 22:54:32.604] I (150/20) [10.10.4.1] >>> via 10.10.4.1 on bond0 >>> 10.10.4.0/22 unicast [backbone 22:54:32.604] I (150/10) [10.10.4.1] >>> dev bond0 >>> 10.9.255.0/24 unicast [backbone 23:57:39.604] I (150/10) >>> [c.d.143.113] >>> dev bond0 >> >> >> What I cannot figure out is why the OSPF entries are not imported to master4 >> on this single machine. >> >> Thanks kindly for any thoughts. >> >> Brian >> >> >
