R: OSPF anycast prefix being filtered

[Andrea Costantino]

A quick hack would be to simply bring down BIRD on the box in maintenance. Without BFD it will take 40 sec with standard config.for OSPF, while if you use BDF or tweak timers, it could be improved to subsecond or bunch of seconds, respectively.

I manage a pool of Anycast DNS in different POPs, with both BIRD and Quagga (for having some "bug" protection would one fail), and the quick and dirty solution for managing upgrade, downtime etc. is to bring down the daemon (BIRD or Quagga) on the affected node and wait a minute.

If I need to do a site wide maintenance, I simply passive the OSPF interface on both upstream router and in a matter of second all traffic moves to another POP.

Ciao,
A.


-----Messaggio originale-----
Da: bird-users-bounces at network.cz [mailto:bird-users-bounces at network.cz] Per conto di Patrik Lundin
Inviato: venerdì 10 aprile 2015 10:23
A: Ondrej Zajicek
Cc: bird-users at network.cz
Oggetto: Re: OSPF anycast prefix being filtered

On Wed, Apr 1, 2015 at 5:12 PM, Ondrej Zajicek <santiago at crfreenet.org> wrote:
> On Wed, Apr 01, 2015 at 05:01:01PM +0200, Patrik Lundin wrote:
>>
>> I specifically noticed that OSPF is supposed to create routes for its
>> own interfaces.
>
> Yes it is supposed to do that. Although handling of 'lo' is kind of
> special case and in some circumstances does not work as expected. In that
> case it is often useful to try dummy interface instead of lo interface.
>

I thought I should report back on my continued adventures. Like you said using
the lo interface seemed to work for IPv4, but I noticed bird6 would
not pick up a
/128 prefix assigned to lo in the same way.

I found this had been discussed earlier:
http://marc.info/?l=bird-users&m=130087394302820&w=2

Because of this I decided to abandon the use of lo altogether, and
just use dummy
interfaces which worked fine for both protocols.

My configuration now looks like this:

Address configuration:
===
# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback
up ip link add type dummy
up ip link set dev dummy0 up
up ip addr add xxx.xxx.xxx.xxx/32 dev dummy0
up ip addr add yyyy:yyyy:yyyy:yyyy::yyyy/128 dev dummy0

# The primary network interface
auto eth0
iface eth0 inet dhcp
===

bird configuration:
===
# cat /etc/bird/bird.conf
router id zzz.zzz.zzz.zzz;

protocol device {}

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

bird6 configuration:
===
# cat /etc/bird/bird6.conf
router id zzz.zzz.zzz.zzz;

protocol device {}

protocol ospf {
    import none; # Default is import all
    area 0.0.0.0 {
        interface "eth0" { type ptp; };
        interface "dummy0" { stub; };
    };
}
===

Some things to note:

* I have not decided on the best way to create the dummy interfaces,
the solution above
was just a quick hack but it seems to work well.

* While bird defaults to a "ptp" link type for eth0, bird6 defaults to
"broadcast".

* The dummy0 interface defaults to being a stub interface in bird,
while it requires
configuration in bird6.

The above configuration works well, the main thing I am still not sure
about if is there is
a "best" way to take a specific anycast node out of rotation if it
needs maintenance. Anyone
have any experience with this? General ideas are appreciated as well!

>> 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.
>
> 'filtered out' lines are related to 'import none', e.g. routes were not
> imported from OSPF to master routing table.
>

Thank you for the information!

Regards,
Patrik Lundin