Injecting OSPF learned routes (only)

[ico]

Hello Nico,

I wrestled with this too. The reason you see those routes is this: If 
you configure an interface in OSPF, OSPF uses its own mechanism for 
learning link routes (direct routes?) from kernel. Those routes get into 
some bird's routing table together with all other routes from OSPF. And 
everything is exported into kernel.

So my solution is to use differences between routes learned from 
neighbors and local link routes: link routes don't have a gateway.
So I filter out all routes without gateway in export filter like this:

protocol kernel krnl4 {
     ipv4 {
         export filter {
             # export to kernel only routes with gateway
             if gw.mask(0) = 0.0.0.0 then accept;
             reject;
         };
         import filter {
             # no default gw from kernel, want default gw from ospf
             if net = 0.0.0.0/0 then reject;
             accept;
         };
     };
     learn;
}

I don't know how to filter routes with a gateway properly, but 
"gw.mask(0) = 0.0.0.0" works for me. Maybe there is some better way to 
do this?

I hope this helps you.

ico

On 27. 2. 2024 4:30, Nico Schottelius via Bird-users wrote:
> 
> Good morning bird users,
> 
> I am a bit puzzled about properly adding OSPF learned routes into the
> kernel and let me show you why:
> 
> If I use a filter such as:
> 
> filter static_and_bgp_and_ospf {
>    if(source = RTS_STATIC || source = RTS_BGP || source = RTS_OSPF) then accept;
>    reject;
> }
> 
> And configure the kernel to use it like this:
> 
> protocol kernel kernel_v4 {
>          ipv4 { export filter static_and_bgp_and_ospf; };
> }
> 
> protocol kernel kernel_v6 {
>          ipv6 { export filter static_and_bgp_and_ospf; };
> }
> 
> 
> Then I get route duplications in the kernel:
> 
> [04:29] server123.place10:~# ip r | grep 147.78.195.224/27
> 147.78.195.224/27 dev eth1 proto kernel scope link src 147.78.195.254
> 147.78.195.224/27 dev eth1 proto bird scope link metric 32
> 
> The reason for that semes:
> 
> - server123 has the route because of an interface address
> - other hosts in the network also have an interface in that network
> 
> While this is not necessarily a big problem, it seems wrong to inject
> the route, because we learned it from OSPF, even though we already had
> it in the first place.
> 
> How do you usually handle inserting OSPF learned routes? Do you just
> have them duplicate or do you have some logic that resembles..
> 
>       "If I already have that route and I receive it again from outside
>        (such as OSPF), do not inject it again"
> 
> ?
> 
> Looking forward to read how you handle this logic!
> 
> Best regards from Seoul,
> 
> Nico
> 
> --
> Sustainable and modern Infrastructures by ungleich.ch