OSPF anycast prefix being filtered

[Patrik Lundin]

On Tue, Mar 31, 2015 at 10:43 PM, Pavlos Parissis
<pavlos.parissis at gmail.com> wrote:
>
> You need to enable direct protocol as well which will import routes
> to the routing table of Bird, here is an example conf
>
> define ANYCAST_NETWORKS =
>    [
>        10.252.12.0/24{32,32}
>
>    ];
> protocol direct direct1 {
>     interface "lo";
>         debug all;
>         export none;
>         import where net ~ ANYCAST_NETWORKS;
> }
>

Thank you for the input!

The reason I was trying to avoid the "direct" protocol is because of this
description in the docs (http://bird.network.cz/?get_doc&f=bird-6.html#ss6.4):
===
"The question is whether it is a good idea to have such device routes
in BIRD routing table. OS kernel usually handles device routes for
directly connected networks by itself so we don't need (and don't want)
to export these routes to the kernel protocol. OSPF protocol creates
device routes for its interfaces itself and BGP protocol is usually
used for exporting aggregate routes."
===

I specifically noticed that OSPF is supposed to create routes for its
own interfaces.

It turns out the "filtered out" messages were not relevant to my problem.
The issue was caused by a OSPF network type mismatch. While I was
using the BIRD default of point-to-point, the upstream router was
configured for broadcast. After the upstream router was changed to use a
point-to-point network type everything started to work.

It would be nice to know what the meaning of the "filtered out" lines are,
but they do not seem to affect the route announcement.

For reference, my working configuration now looks like this:
===
router id xxx.xxx.xxx.xxx;

protocol device {}

protocol ospf {
    import none; # Default is import all
    area 0.0.0.0 {
        interface "eth*" {
            authentication cryptographic;
            password "pass";
        };
        interface "lo" {};
    };
}
===

... and the output (after adding "debug protocols all;"):
===
# bird -d
bird: device1: Initializing
bird: ospf1: Initializing
bird: device1: Starting
bird: device1: Scanning interfaces
bird: device1: Connected to table master
bird: device1: State changed to feed
bird: ospf1: Starting
bird: ospf1: Adding area 0.0.0.0
bird: ospf1: Connected to table master
bird: ospf1: State changed to feed
bird: Started
bird: device1: State changed to up
bird: ospf1 < interface lo goes up
bird: ospf1 < primary address yyy.yyy.yyy.yyy/32 on interface lo added
bird: ospf1: Adding interface lo (yyy.yyy.yyy.yyy/32) to area 0.0.0.0
bird: ospf1 < secondary address 127.0.0.0/8 on interface lo added
bird: ospf1 < interface eth0 goes up
bird: ospf1 < primary address zzz.zzz.zzz.zzz/30 on interface eth0 added
bird: ospf1: Adding interface eth0 (zzz.zzz.zzz.zzz/30) to area 0.0.0.0
bird: ospf1: State changed to up
bird: ospf1: Changing state of iface eth0 from down to ptp
bird: ospf1: Scheduling router-LSA origination for area 0.0.0.0
bird: ospf1: HELLO packet sent via eth0
bird: ospf1: Changing state of iface lo from down to waiting
bird: ospf1: Scheduling router-LSA origination for area 0.0.0.0
bird: ospf1: Originating router-LSA for area 0.0.0.0
bird: ospf1: Scheduling routing table calculation
bird: ospf1: Starting routing table calculation
bird: ospf1: Starting routing table calculation for area 0.0.0.0
bird: ospf1: Starting routing table calculation for inter-area (area 0.0.0.0)
bird: ospf1: Starting routing table calculation for ext routes
bird: ospf1: Starting routing table synchronisation
bird: ospf1 > filtered out zzz.zzz.zzz.zzz/30 dev eth0
bird: ospf1 > filtered out yyy.yyy.yyy.yyy/32 dev lo
[...]
===

Soon after BIRD has been started my traceroute now successfully finds
is way to the server.

-- 
Patrik Lundin