OSPF weird behaviour

[Eugene M. Zheganin]

Hi.

I'm running bird in a large (well, meaning enterprise large, not ISP
large) network. I'm using mostly 1.3.11/1.4.0 versions, and FreeBSD on
all of the servers that are running bird. My network consists of several
network hubs, that local branche offices are attached to. These hubs
reside in large cities, and most of them are running some dynamic
routing protocols aside from OSPF (BGP and RIP). Of course I'm writing
this post not to share this useless information, but to describe a
problem that I have. This problem involves two network sites, lets call
them A and B. A consists of several networks and several routers, this
is a largest site in my network, and site B consists of two bird routers
running FreeBSD with VRRP/CARP (one active in each moment) and two
dozens of branch offices, running mostly FreeBSD/quagga (they were
deployed before I started using bird), and some of them running Cisco
IOS/RIP. Site A and B are connected via a gre tunnel and OSPF in it.

The problem is, that in some random moment site A receives a route
announce from site B containing a route that clearly belongs to a site
A. I know this behavior is typical to distance-vector protocol, not for
a link state protocol, and it's kind of an impossible situation, but
this is exactly what I'm seeing in birdc. The router at site A indicates
that it received a route from router at B via OSPF, but in the same time
the B router claims that this route clearly points to A.

for instance:

A:

# birdc
BIRD 1.3.11 ready.
bird> show route for 192.168.7.0
192.168.7.0/24     via 172.16.0.95 on gre13 [ospfv4 10:08] ! E2
(150/10/10000) [192.168.21.2]
                   via 192.168.3.22 on vlan1 [kernel1 10:17] (10)
(I manually deleted a 192.168.7.0/24 route from kernel and added one via
192.168.3.22 to solve this temporarily, so OSPF route is this troubled
announce)

# ifconfig gre13
gre13: flags=b051<UP,POINTOPOINT,RUNNING,LINK0,LINK1,MULTICAST> metric 0
mtu 1476
        tunnel inet 89.250.210.69 --> 94.159.37.114
        inet 172.16.0.94 --> 172.16.0.95 netmask 0xffffffff
        inet6 fe80::21a:64ff:fe21:8e80%gre13 prefixlen 64 scopeid 0x1f
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

B:

[emz at moscow-alpha:~]# birdc
BIRD 1.4.0 ready.
bird> show route 192.168.7.0/24
192.168.7.0/24     via 172.16.0.94 on gre0 [ospfv4 08:08:30] * E2
(150/20/10000) [192.168.3.22]
bird>

# ifconfig gre0
gre0: flags=b051<UP,POINTOPOINT,RUNNING,LINK0,LINK1,MULTICAST> metric 0
mtu 1476
        tunnel inet 94.159.37.114 --> 89.250.210.69
        inet 172.16.0.95 --> 172.16.0.94 netmask 0xffffffff
        inet6 fe80::21a:64ff:fe21:96d5%gre0 prefixlen 64 tentative
scopeid 0x8
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

I know that this information isn't enough to diagnose the problem, and I
wanted to know what should I get to help diagnose this. I should say
also, that at this time I get like 100 megabytes per day of bird logs
consisting mostly of 'OSPF: LSA disappeared [...]' messages, and, since
I get this issue one or two times per month, running bird with full OSPF
debug will produce even more.

Thanks.
Eugene.