[Xorp-hackers] OSPF bug(s) in XORP-1.5
Francisco Rodriguez
f.rodriguez at lancaster.ac.uk
Wed Aug 20 12:54:51 PDT 2008
Pavlin,
I have noticed that the behavior that I described in the previous e-mail is
only presented when disabling a VLAN interface (eth1.12), and not a main
interface (i.e. eth1).
Here is the output of such failure:
root at Route-Server> show interfaces
eth1.12/eth1.12: Flags:<ENABLED,BROADCAST,MULTICAST> mtu 1500 speed 100 Mbps
inet6 fe80::5054:ff:fe12:3552 prefixlen 64
inet 192.168.1.2 subnet 192.168.1.0/24 broadcast 192.168.1.255
physical index 5
ether 52:54:0:12:35:52
eth1.13/eth1.13: Flags:<ENABLED,BROADCAST,MULTICAST> mtu 1500 speed 100 Mbps
inet6 fe80::5054:ff:fe12:3552 prefixlen 64
inet 192.168.2.2 subnet 192.168.2.0/24 broadcast 192.168.2.255
physical index 6
ether 52:54:0:12:35:52
root at Route-Server> show ospf4 neighbor
Address Interface State ID Pri Dead
192.168.1.3 eth1.12/eth1.12 Full 192.168.1.3 128 39
192.168.2.3 eth1.13/eth1.13 Full 192.168.2.3 128
35root at Route-Server> show interfaces
eth1.12/eth1.12: Flags:<ENABLED,BROADCAST,MULTICAST> mtu 1500 speed 100 Mbps
inet6 fe80::5054:ff:fe12:3552 prefixlen 64
inet 192.168.1.2 subnet 192.168.1.0/24 broadcast 192.168.1.255
physical index 5
ether 52:54:0:12:35:52
eth1.13/eth1.13: Flags:<ENABLED,BROADCAST,MULTICAST> mtu 1500 speed 100 Mbps
inet6 fe80::5054:ff:fe12:3552 prefixlen 64
inet 192.168.2.2 subnet 192.168.2.0/24 broadcast 192.168.2.255
physical index 6
ether 52:54:0:12:35:52
root at Route-Server# create interfaces interface eth1.12 disable true
root at Route-Server# commit
root at Route-Server# exit
root at Route-Server> show interfaces
eth1.12/eth1.12: Flags:<ENABLED,BROADCAST,MULTICAST> mtu 1500 speed 100 Mbps
inet6 fe80::5054:ff:fe12:3552 prefixlen 64
inet 192.168.1.2 subnet 192.168.1.0/24 broadcast 192.168.1.255
physical index 5
ether 52:54:0:12:35:52
eth1.13/eth1.13: Flags:<ENABLED,BROADCAST,MULTICAST> mtu 1500 speed 100 Mbps
inet6 fe80::5054:ff:fe12:3552 prefixlen 64
inet 192.168.2.2 subnet 192.168.2.0/24 broadcast 192.168.2.255
physical index 6
ether 52:54:0:12:35:52
root at Route-Server> show ospf4 neighbor
Address Interface State ID Pri Dead
192.168.1.3 eth1.12/eth1.12 Full 192.168.1.3 128 39
192.168.2.3 eth1.13/eth1.13 Full 192.168.2.3 128 35
root at Route-Server> configure
root at Route-Server# show interfaces
interface "eth1.12" {
description: "Network 192.168.1.0/24 for DVR01 Route Server"
disable: true
default-system-config
}
interface "eth1.13" {
description: "Network 192.168.2.0/24 for DVR01 Route Server"
default-system-config
}
Now if I try to enable-disable the interface again I have the same results:
root at Route-Server# create interfaces interface eth1.12 disable false
root at Route-Server# commit
root at Route-Server# exit
root at Route-Server# create interfaces interface eth1.12 disable true
root at Route-Server# commit
root at Route-Server# show interfaces
interface "eth1.12" {
description: "Network 192.168.1.0/24 for DVR01 Route Server"
disable: true
default-system-config
}
interface "eth1.13" {
description: "Network 192.168.2.0/24 for DVR01 Route Server"
default-system-config
}
[edit]
root at Route-Server# exit
root at Route-Server> show interfaces
eth1.12/eth1.12: Flags:<ENABLED,BROADCAST,MULTICAST> mtu 1500 speed 100 Mbps
inet6 fe80::5054:ff:fe12:3552 prefixlen 64
inet 192.168.1.2 subnet 192.168.1.0/24 broadcast 192.168.1.255
physical index 5
ether 52:54:0:12:35:52
eth1.13/eth1.13: Flags:<ENABLED,BROADCAST,MULTICAST> mtu 1500 speed 100 Mbps
inet6 fe80::5054:ff:fe12:3552 prefixlen 64
inet 192.168.2.2 subnet 192.168.2.0/24 broadcast 192.168.2.255
physical index 6
ether 52:54:0:12:35:52
root at Route-Server> show ospf4 neighbor
Address Interface State ID Pri Dead
192.168.1.3 eth1.12/eth1.12 Full 192.168.1.3 128 35
192.168.2.3 eth1.13/eth1.13 Full 192.168.2.3 128 31
As described in previous e-mail, it seems to be a FEA problem.
Cheers,
Francisco
-----Original Message-----
From: Pavlin Radoslavov [mailto:pavlin at ICSI.Berkeley.EDU]
Sent: 08 August 2008 18:33
To: Francisco Rodriguez
Cc: atanu at xorp.org; xorp-hackers at icir.org
Subject: Re: [Xorp-hackers] OSPF bug(s) in XORP-1.5
Francisco,
At the high level, the interface configuration should work as
follows:
* If you use the "default-system-config" statement, all the
configuration information and changes should come from the
underlying system. However, if you "disable" an
interface/vif/address by using xorpsh, the "disable" state will have
effect only inside XORP; i.e., it will not be propagated to the
kernel.
This behavior is intentional by design.
In this setup if you use "ifconfig" to change interface status,
this change should be proparaged to the FEA and the rest of the
XORP processes.
* If you explicitly configure an interface/vif/address through XORP,
then the the configuration information/changes should come through
XORP. In that case you should *not* use "ifconfig" to change the
interface.
Making changes from both xorpsh and ifconfig can lead to
possible configuration inconsistency.
See additional comments inline.
Francisco Rodriguez <f.rodriguez at lancaster.ac.uk> wrote:
>
> 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
Could you confirm that in this experiment you explicitly configure
the interface in xorpsh and did not use the default-system-config
statement.
If you did not use the default-system-config, and you used
"ifconfig" to manipulate the interface, then all bets are off (see
above).
However, if the FEA detected the interface coming up, the rest of
the XORP processes (incl. OSPF) should also detect that.
Could you confirm that "show interfaces" indeed shows that the
interface/vif/address are all UP.
This will tell us whether the problem is in the FEA or OSPF.
> 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".
I presume that in this experiment you did not use the
"default-system-config" statement.
In that case if you disable an interface, then all vifs and
addresses below it will be disabled. Same applies for disabling a
vif.
Could you run again the "show interfaces" command to help us
identify where the problem is.
> 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.
This is the intended behavior. See the explanation in the beginning
of this email.
Pavlin
> 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 ]
More information about the Xorp-hackers
mailing list