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@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.