OSPF getting forwarding address wrong

Tore Anderson tore at fud.no
Mon Jan 13 11:44:48 CET 2014


Hi,

My anycast nodes exports the availability of their services by
configuring /32s configured on the loopback intefaces. These are in turn
exported to the OSPF protocol running on bond0:

$ birdc 'show interfaces'
BIRD 1.3.11 ready.
lo up (index=1)
	MultiAccess AdminUp LinkUp Loopback Ignored MTU=65536
	192.0.2.1/32 (Primary, scope univ)
	127.0.0.1/8 (Unselected, scope host)
	192.0.2.2/32 (Unselected, scope univ)
	192.0.2.5/32 (Unselected, scope univ)
	192.0.2.3/32 (Unselected, scope univ)
	192.0.2.4/32 (Unselected, scope univ)
	192.0.2.6/32 (Unselected, scope univ)
[..skipping DOWN ifs...]
bond0 up (index=6)
	MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500
	192.0.2.114/28 (Primary, scope univ)

Now, there are something strange going on here. Sometimes, and I have
not yet been able to understand when or how or why it happens, the
resulting Type-7 LSAs that get sent to the upstream router has a
forwarding address that is one of the other service addresses configured
on "lo", instead of the actual address on "bond0". The upstream router
(running JUNOS) doesn't install these routes in its forwarding table,
which means that the anycasted service doesn't attract the traffic as it
should. This is what the router sees:

tore at rtr> show ospf database lsa-id 192.0.2.1 extensive       

Area 1.2.3.4
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
NSSA     192.0.2.1      192.0.2.114    0x8000122a  1145  0x8  0x90ab  36  
  mask 255.255.255.255
  Topology default (ID 0)
    Type: 2, Metric: 10000, Fwd addr: 192.0.2.114, Tag: 0.0.0.0
  Aging timer 00:40:55
  Installed 00:19:04 ago, expires in 00:40:55, sent 00:19:02 ago
  Last changed 13w5d 21:57:44 ago, Change count: 1
  Standby flood status Idle

{master:0}
tore at rtr> show ospf database lsa-id 192.0.2.2 extensive       

Area 1.2.3.4
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
NSSA     192.0.2.2      192.0.2.114    0x800000e8  1388  0x8  0x51a9  36  
  mask 255.255.255.255
  Topology default (ID 0)
    Type: 2, Metric: 10000, Fwd addr: 192.0.2.6, Tag: 0.0.0.0
  Aging timer 00:36:51
  Installed 00:23:07 ago, expires in 00:36:52, sent 00:23:05 ago
  Last changed 4d 19:56:46 ago, Change count: 1
  Standby flood status Idle

I have confirmed with tcpdump running on the anycast node that the
forwarding address in the LS-Update packets sent by BIRD is indeed
192.0.2.6.

So at the time of writing, I have the following:

LSA-ID 192.0.2.1: forwarding address 192.0.2.114 (works fine)
LSA-ID 192.0.2.2: forwarding address 192.0.2.6 (doesn't work)
LSA-ID 192.0.2.3: forwarding address 192.0.2.6 (doesn't work)
LSA-ID 192.0.2.4: forwarding address 192.0.2.6 (doesn't work)
LSA-ID 192.0.2.5: forwarding address 192.0.2.6 (doesn't work)
LSA-ID 192.0.2.6: forwarding address 192.0.2.114 (works fine)

The only way I've found to actually fix this is to remove and re-add
the address:

$ ip address del 87.238.33.2/32 dev lo
$ ip address add 87.238.33.2/32 dev lo

This causes BIRD to re-send the LS-Update with 192.0.2.114 and now the
JUNOS route installs it to its FIB and the anycast service starts
receiving traffic. The remaining three addresses remain defective.

Question is: Why is this happening? Bug, or am I doing something
wrong?

Tore



More information about the Bird-users mailing list