[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