BGP routes not being propagated to kernel via OSPF

Mon Mar 9 17:56:33 CET 2020

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 <brian.topping at gmail.com> 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 <brian.topping at gmail.com> 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 at 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 at 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 at 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
>> 
>> 
> 