[Xorp-hackers] OSPF bug(s) in XORP-1.5
Pavlin Radoslavov
pavlin at ICSI.Berkeley.EDU
Wed Aug 20 21:51:25 PDT 2008
Francisco,
In the example below it appears to me the issue is that setting
"disable" to true for "default-system-config" interface is no-op.
FYI, I tried it with VLAN and regular interface, and I observed same
behariov.
In my original email I wrote:
* 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.
After I checked with the source code implementation, it appears that
the second sentence above (about the "disable" flag) is incorrect.
Currently, if "default-system-config" is set for an interface, all
the state will come from the UNIX kernel, and the "disable" XORP
flag is ignored.
In other words, I believe what you see below is correct (it is
consistent with the above correction).
Please let me know if I missed something from your experiment and
description.
I am still puzzled by the disappearance of the IP address (from your
previous email), but as I described in my previous email I couldn't
reproduce it.
Thanks,
Pavlin
Francisco Rodriguez <f.rodriguez at lancaster.ac.uk> wrote:
> 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 ]
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
More information about the Xorp-hackers
mailing list