[Xorp-hackers] OSPF bug(s) in XORP-1.5

[Francisco Rodriguez]

I have been running some OSPF tests using XORP-1.5 version and I have seen
some unusual OSPF behavior. 

I’m using a ring topology with 4 different PC’s (kvm/qemu virtual machines
running Linux Debian) all of them running XORP-1.5 as follows:

		Xorp
	           /           \
	         /               \
	   Xorp1        Xorp2   (Ring Topology, all routers configured in
the same OSPF Area)
	         \               / 	
	           \           /
	             Xorp3 


If I simulate a failure (flap the interface) in router Xorp1, at first Xorp3
will be able to update its routing table properly from the other routers in
the network, but once the faulty router recovers, Xorp4 would not be able to
update its routing table to the previous state. The same will happen with
Xorp.  Furthermore, if I simulate another failure now in Xorp2, Xorp and
Xorp3 will might end with none OSPF routes on its routing tables.

It seems to me that OSPF is not sending the correspondent LSA packet when a
failure occurs in the faulty router or that routers are not accepting such
update. Another possibility that it comes to my mind is that XORP doesn’t
update its routing table after an OSPF unexpected event. Here is an output
of Xorp3 after simulating a failure in Xorp1 and after Xorp1 recover,
another failure in Xorp2:
root at XORP3> show ospf4 neighbor 
  Address         Interface             State      ID              Pri  Dead
192.168.4.1      eth1/eth1              Full      192.168.2.3      128    30
192.168.3.1      eth2/eth2              Full      192.168.1.3      128    39
root at XORP3> show route table ipv4 unicast final terse 
Destination        P Prf  Metric 1  Next hop          
192.168.3.0/24     c   0         0  eth2/eth2
192.168.4.0/24     c   0         0  eth1/eth1
root at XORP3> show ospf4 database 
   OSPF link state database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router  *192.168.3.2      192.168.3.2      0x8000004d    27  0x2  0x3e22  48
Router   192.168.1.3      192.168.1.3      0x8000003c    33  0x2  0x6cf5  36
Network  192.168.3.1      192.168.1.3      0x80000001    33  0x2  0xa4fe  32
Router   172.16.0.2       172.16.0.2       0x8000000d   515  0x2  0x168f  60
Network  192.168.2.2      172.16.0.2       0x80000001   515  0x2  0xc838  32
Router   192.168.2.3      192.168.2.3      0x80000040    28  0x2  0x68f1  36
Network  192.168.4.1      192.168.2.3      0x80000001    28  0x2  0x9b05  32

Also I have noticed that sometimes when issuing the command: “clear ospf4
database”. It might have unwanted effects on XORP; sometimes it might kill
OSPFv2 process.  When this has happened, sometimes I can see the following
output:
[ 2008/08/01 15:15:23 WARNING clear_database OSPF ] Attempt to clear
database
[ 2008/08/01 15:15:23  ERROR clear_database:2655 OSPF +154 clear_database.cc
main ] Failed to clear database
ERROR: Command "/usr/local/xorp-1.5/ospf/tools/clear_database": exited with
exit status 255.

root at XORP3> show ospf4 neighbor 
[ 2008/08/01 15:16:07 WARNING print_neighbours OSPF ] Attempt to get
neighbour list failed
[ 2008/08/01 15:16:07  ERROR print_neighbours:2656 OSPF +413
print_neighbours.cc main ] Failed to get neighbour list
ERROR: Command "/usr/local/xorp-1.5/ospf/tools/print_neighbours": exited
with exit status 255


Any further information required, please let me know.

Cheers,
Francisco

-------------------------
Francisco Rodríguez
Computing Department
InfoLab 21
South Drive
Lancaster University
Lancaster LA1 4WA, UK
-------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080801/b81db95b/attachment-0001.html