[Xorp-hackers] OSPF bug(s) in XORP-1.5
Francisco Rodriguez
f.rodriguez at lancaster.ac.uk
Fri Aug 8 02:04:41 PDT 2008
Hi,
I have done further tests and realized which was the real problem.
OSPF appears to update correctly, although XORP in general might be affected
by the different ways in which you can simulate a network failure.
For example, I was trying to simulate a failure by just entering the command
"ifconfig <int1> down" which effectively will cause XORP to detect a
failure. But, if I enter the command "ifconfig <int1> up", then XORP will
detect the interface was coming up, but in this case the routing protocol
process (OSPF) have an inconvenient with that, and will not update its RIB
neither its neighbors as a consequence. It's important to mention that I
enter these commands in the system's shell, situation that XORP didn't liked
at all. Its better to log into XORP's shell (./xorpsh) and make the changes
there. Also, I noticed that there are different levels at which we should be
able to disable a physical port (interface, vif, address). I noticed that
the only way I was able to completely disable the whole interface was by
entering the command:
"create interfaces interface <int1> vif <int1> address <ip_address> disable
true".
Also I noticed that this command will only have effect when interface's
configuration didn't take system's default configuration settings
("default-system-config"). Furthermore, when using "default-system-config"
command and entering an interface disable command in XORP's shell, at
interface/vif level, it won't disable the interface/vif at all, but prevent
the use of such interface/vif by XORP processes. For this case, entering an
"ifconfig <int> down" command will definitely disable the interface.
Francisco
-----Original Message-----
From: atanu at icir.org [mailto:atanu at icir.org] On Behalf Of Atanu Ghosh
Sent: 05 August 2008 23:32
To: Francisco Rodriguez
Cc: xorp-hackers at icir.org
Subject: Re: [Xorp-hackers] OSPF bug(s) in XORP-1.5
Hi,
Could you run the command ospf/tools/print_lsas -S /tmp/saved.lsas on
Xorp3 and send me the file. The contents of the file are all the LSAs,
I will run a test program on the LSAs to see if the generated routes
match what you are reporting.
Atanu.
>>>>> "Francisco" == Francisco Rodriguez <f.rodriguez at lancaster.ac.uk>
writes:
Francisco> I have been running some OSPF tests using XORP-1.5
Francisco> version and I have seen some unusual OSPF behavior.
Francisco> I'm using a ring topology with 4 different PC's
Francisco> (kvm/qemu virtual machines running Linux Debian) all of
Francisco> them running XORP-1.5 as follows:
Francisco> Xorp
Francisco> / \
Francisco> / \
Francisco> Xorp1 Xorp2 (Ring Topology, all routers
Francisco> configured in the same OSPF Area)
Francisco> \ /
Francisco> \ /
Francisco> Xorp3
Francisco> If I simulate a failure (flap the interface) in router
Francisco> Xorp1, at first Xorp3 will be able to update its routing
Francisco> table properly from the other routers in the network, but
Francisco> once the faulty router recovers, Xorp4 would not be able
Francisco> to update its routing table to the previous state. The
Francisco> same will happen with Xorp. Furthermore, if I simulate
Francisco> another failure now in Xorp2, Xorp and Xorp3 will might
Francisco> end with none OSPF routes on its routing tables.
Francisco> It seems to me that OSPF is not sending the
Francisco> correspondent LSA packet when a failure occurs in the
Francisco> faulty router or that routers are not accepting such
Francisco> update. Another possibility that it comes to my mind is
Francisco> that XORP doesn't update its routing table after an OSPF
Francisco> unexpected event. Here is an output of Xorp3 after
Francisco> simulating a failure in Xorp1 and after Xorp1 recover,
Francisco> another failure in Xorp2:
Francisco> root at XORP3> show ospf4 neighbor
Francisco> Address Interface State ID Pri Dead
Francisco> 192.168.4.1 eth1/eth1 Full 192.168.2.3 128 30
Francisco> 192.168.3.1 eth2/eth2 Full 192.168.1.3 128 39
Francisco> root at XORP3> show route table ipv4 unicast final terse
Francisco> Destination P Prf Metric 1 Next hop
Francisco> 192.168.3.0/24 c 0 0 eth2/eth2
Francisco> 192.168.4.0/24 c 0 0 eth1/eth1
Francisco> root at XORP3> show ospf4 database
Francisco> OSPF link state database, Area 0.0.0.0
Francisco> Type ID Adv Rtr Seq Age Opt Cksum Len
Francisco> Router *192.168.3.2 192.168.3.2 0x8000004d 27 0x2
Francisco> 0x3e22 48
Francisco> Router 192.168.1.3 192.168.1.3 0x8000003c 33 0x2
Francisco> 0x6cf5 36
Francisco> Network 192.168.3.1 192.168.1.3 0x80000001 33 0x2
Francisco> 0xa4fe 32
Francisco> Router 172.16.0.2 172.16.0.2 0x8000000d 515 0x2 0x168f
Francisco> 60
Francisco> Network 192.168.2.2 172.16.0.2 0x80000001 515 0x2
Francisco> 0xc838 32
Francisco> Router 192.168.2.3 192.168.2.3 0x80000040 28 0x2
Francisco> 0x68f1 36
Francisco> Network 192.168.4.1 192.168.2.3 0x80000001 28 0x2
Francisco> 0x9b05 32
Francisco> Also I have noticed that sometimes when issuing the
Francisco> command: "clear ospf4 database". It might have unwanted
Francisco> effects on XORP; sometimes it might kill OSPFv2 process.
Francisco> When this has happened, sometimes I can see the following
Francisco> output:
Francisco> [ 2008/08/01 15:15:23 WARNING clear_database OSPF ]
Francisco> Attempt to clear database
Francisco> [ 2008/08/01 15:15:23 ERROR clear_database:2655 OSPF
Francisco> +154 clear_database.cc main ] Failed to clear database
Francisco> ERROR: Command
Francisco> "/usr/local/xorp-1.5/ospf/tools/clear_database": exited
Francisco> with exit status 255.
Francisco> root at XORP3> show ospf4 neighbor
Francisco> [ 2008/08/01 15:16:07 WARNING print_neighbours OSPF ]
Francisco> Attempt to get neighbour list failed
Francisco> [ 2008/08/01 15:16:07 ERROR print_neighbours:2656 OSPF
Francisco> +413 print_neighbours.cc main ] Failed to get neighbour
Francisco> list
Francisco> ERROR: Command
Francisco> "/usr/local/xorp-1.5/ospf/tools/print_neighbours": exited
Francisco> with exit status 255
Francisco> Any further information required, please let me know.
Francisco> Cheers,
Francisco> Francisco
Francisco> -------------------------
Francisco> Francisco Rodríguez
Francisco> Computing Department
Francisco> InfoLab 21
Francisco> South Drive
Francisco> Lancaster University
Francisco> Lancaster LA1 4WA, UK
Francisco> -------------------------
Francisco> _______________________________________________
Francisco> Xorp-hackers mailing list Xorp-hackers at icir.org
Francisco>
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
More information about the Xorp-hackers
mailing list