Hello, I am trying to use BIRD for anycasting a /32 prefix via OSPF and I am not able to get the announcement to work. My idea is to have the server use the normal default gw for routing packets. Because of this I see no reason for importing routes from OSPF into the kernel routing table, I am only interested in exporting the anycast address that is configured on the loopback interface. I configure a /32 prefix on the loopback interface like so: === # ip address add yyy.yyy.yyy.yyy/32 dev lo === My bird.conf looks like this: === router id xxx.xxx.xxx.xxx; debug protocols all; protocol device {} protocol ospf { import none; # Default is import all export all; area 0.0.0.0 { interface "eth*" { authentication cryptographic; password "pass"; }; interface "lo" {}; }; } === It seems however that the address on lo (as well as eth0) is being "filtered out" by BIRD, as seen in debug mode: === # 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 [...] === I guess I am missing something obvious, any pointers would be much appreciated! -- Patrik Lundin
On 31/03/2015 06:41 μμ, Patrik Lundin wrote:
Hello,
I am trying to use BIRD for anycasting a /32 prefix via OSPF and I am not able to get the announcement to work.
My idea is to have the server use the normal default gw for routing packets. Because of this I see no reason for importing routes from OSPF into the kernel routing table, I am only interested in exporting the anycast address that is configured on the loopback interface.
I configure a /32 prefix on the loopback interface like so: === # ip address add yyy.yyy.yyy.yyy/32 dev lo ===
My bird.conf looks like this: === router id xxx.xxx.xxx.xxx;
debug protocols all;
protocol device {}
protocol ospf { import none; # Default is import all export all; area 0.0.0.0 { interface "eth*" { authentication cryptographic; password "pass"; }; interface "lo" {}; }; }
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; } Cheers, Pavlos
On Tue, Mar 31, 2015 at 10:43 PM, Pavlos Parissis <pavlos.parissis@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
On Wed, Apr 01, 2015 at 05:01:01PM +0200, Patrik Lundin wrote:
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.
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.
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. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
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
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
On Fri, Apr 10, 2015 at 10:37:01AM +0200, Andrea Costantino wrote:
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.
BDF would indeed be an interesting solution, and I notice BIRD has support for that protocol as well.
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.
Thanks a lot for the information, it is intersting to hear what is working for others! Regards, Patrik Lundin
On Fri, Apr 10, 2015 at 10:23:23AM +0200, Patrik Lundin wrote:
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.
...
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.
Just add 'dummy' to /etc/modules, it will be loaded and dummy0 will be created by default.
* 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.
That is because OSPFv2 uses IPv4 addresses where /31 signalize ptp link and /32 stub link, OSPFv3 uses IPv6 link-local addresses and there is /64 everywhere.
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!
There are two possibilities: 1) Shut down dummy interface (ip link set dummy0 down), OSPF should immediately stop propagating attached addresses. This is probably the cleanest solution. You could even have multiple dummy interfaces with different addresses for different services and disable them independently. 2) Shut down OSPF protocol (birdc disable ospf1), OSPF would immediately de-peer. It should be also immediate, although in unusual cases you have to wait for timeout. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On Fri, Apr 10, 2015 at 11:29:24AM +0200, Ondrej Zajicek wrote:
On Fri, Apr 10, 2015 at 10:23:23AM +0200, Patrik Lundin wrote:
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.
Just add 'dummy' to /etc/modules, it will be loaded and dummy0 will be created by default.
Ah, this explains why my current solution was creating an extra dummy1 interface, I did not realize just loading the module would create dummy0. Thanks for the tip!
* 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.
That is because OSPFv2 uses IPv4 addresses where /31 signalize ptp link and /32 stub link, OSPFv3 uses IPv6 link-local addresses and there is /64 everywhere.
Good to know, I was mostly pointing it out if anyone was wondering why my configuration differed somewhat between the protocols.
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!
There are two possibilities:
1) Shut down dummy interface (ip link set dummy0 down), OSPF should immediately stop propagating attached addresses. This is probably the cleanest solution. You could even have multiple dummy interfaces with different addresses for different services and disable them independently.
2) Shut down OSPF protocol (birdc disable ospf1), OSPF would immediately de-peer. It should be also immediate, although in unusual cases you have to wait for timeout.
Thanks for the ideas, once I have a second node available for testing I'll experiment with these solutions. Regards, Patrik Lundin
participants (4)
-
Andrea Costantino -
Ondrej Zajicek -
Patrik Lundin -
Pavlos Parissis