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@network.cz [mailto:bird-users-bounces@network.cz] Per conto di Patrik Lundin Inviato: venerdì 10 aprile 2015 10:23 A: Ondrej Zajicek Cc: bird-users@network.cz Oggetto: Re: OSPF anycast prefix being filtered On Wed, Apr 1, 2015 at 5:12 PM, Ondrej Zajicek <santiago@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