From f.rodriguez at lancaster.ac.uk Fri Aug 1 08:10:03 2008 From: f.rodriguez at lancaster.ac.uk (Francisco Rodriguez) Date: Fri, 1 Aug 2008 16:10:03 +0100 Subject: [Xorp-hackers] OSPF bug(s) in XORP-1.5 Message-ID: <003b01c8f3e8$acbabaa0$c5e05894@lancs.local> 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 From van_nam_78 at yahoo.com Sun Aug 3 03:11:54 2008 From: van_nam_78 at yahoo.com (Nguyen Van Nam) Date: Sun, 3 Aug 2008 03:11:54 -0700 (PDT) Subject: [Xorp-hackers] Detect LSDB change? Message-ID: <593755.39226.qm@web50207.mail.re2.yahoo.com> Hi all, Mon program needs a trigger of LSDB changes in XORPs . Could you please tell me which function i can use to do that? Thanks so much Nguyen Van Nam ----- Original Message ---- From: Bruce M Simpson To: Nguyen Van Nam Cc: xorp-hackers Sent: Tuesday, July 29, 2008 10:54:56 PM Subject: Re: [Xorp-hackers] Problem with writing a xorp process Hi, Please ignore my earlier comment about multiple callbacks, as it doesn't apply here. Nguyen Van Nam wrote: > Hi, > I use telnet localhost 19999 to verify xorp_finder. It is running. But > the error still occurs. > Note that: my source code is place at the module area_router.cc. > So what should I do now? Based on the screenshot you've posted,and the data so far, it seems as though the xorp_ospfv2 process is either not processing event callbacks or is not returning from them. Could you have introduced anything into the code which results in the EventLoop not being called? This seems to be the most likely root cause of the problem you're seeing. thanks, BMS -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080803/93783fd7/attachment.html From van_nam_78 at yahoo.com Sun Aug 3 03:15:18 2008 From: van_nam_78 at yahoo.com (Nguyen Van Nam) Date: Sun, 3 Aug 2008 03:15:18 -0700 (PDT) Subject: [Xorp-hackers] Delay in XORP? Message-ID: <541163.51261.qm@web50209.mail.re2.yahoo.com> Hi all, I want to use the delay function in XORP (like function sleep(ms) in C) but i don't know what exactly is this? Coul you please explain me? Thank you so much. Nguyen van Nam ----- Original Message ---- From: Bruce M Simpson To: Nguyen Van Nam Cc: xorp-hackers at xorp.org Sent: Wednesday, July 30, 2008 7:34:12 PM Subject: Re: [Xorp-hackers] Problem with writing a xorp process Nguyen Van Nam wrote: > Hi, > Thanks so much for your answer. > But could you please answer me another question? > I have implemented my code as in print_lsas modul. > In such a way, I defined my own EventLoop, my own XrlRouter, and i > wait_for_xrl_ router_is ready. > But I found the following error when i declared EventLoop evenloop. > [timer.cc] Assertion 'thetimerList==(!null)' failed. > Another time, could you please explain me? This assertion is only present in the TimerList constructor. Could you have done anything which caused the constructor to be called more than once? Are you using threads, for example (we don't support this) ? thanks BMS -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080803/d2a9f191/attachment.html From bms at incunabulum.net Sun Aug 3 09:52:11 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Sun, 03 Aug 2008 17:52:11 +0100 Subject: [Xorp-hackers] Detect LSDB change? In-Reply-To: <593755.39226.qm@web50207.mail.re2.yahoo.com> References: <593755.39226.qm@web50207.mail.re2.yahoo.com> Message-ID: <4895E23B.4080100@incunabulum.net> Nguyen Van Nam wrote: > Hi all, > Mon program needs a trigger of LSDB changes in XORPs . > Could you please tell me which function i can use to do that? You'd have to add an XRL client interface to support that, I don't believe the OSPF process currently has a mechanism for sending notifications of such events. Someone on the list (possibly me) should be happy to review such a patch for inclusion in XORP. thanks BMS From bms at incunabulum.net Sun Aug 3 09:53:14 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Sun, 03 Aug 2008 17:53:14 +0100 Subject: [Xorp-hackers] Delay in XORP? In-Reply-To: <541163.51261.qm@web50209.mail.re2.yahoo.com> References: <541163.51261.qm@web50209.mail.re2.yahoo.com> Message-ID: <4895E27A.7010200@incunabulum.net> Nguyen Van Nam wrote: > Hi all, > I want to use the delay function in XORP (like function sleep(ms) in C) > but i don't know what exactly is this? > Coul you please explain me? You cannot or should not do this directly for these reasons: * it may result in the EventLoop not being run; * it isn't portable code. Either run a bounded while loop around EventLoop::run(), or use TimerList::system_sleep(). thanks BMS From van_nam_78 at yahoo.com Sun Aug 3 12:46:30 2008 From: van_nam_78 at yahoo.com (Nguyen Van Nam) Date: Sun, 3 Aug 2008 12:46:30 -0700 (PDT) Subject: [Xorp-hackers] Conflict between processus, how to avoid? Message-ID: <39639.81138.qm@web50211.mail.re2.yahoo.com> Hi all, Thank you so much for your answers. In fact, i have implemented a XRL client interface to notify LSDB change. But I have encountered an error when I called another Xrl request to set interface cost, because this one cause the LSDB to be changed immediately so at the same time there are 2 processes running. In your experiences , how to avoid this? Thanks Nguyen van Nam ----- Original Message ---- From: Bruce M Simpson To: Nguyen Van Nam Cc: XORP DEVELOPERS Sent: Sunday, August 3, 2008 6:52:11 PM Subject: Re: Detect LSDB change? Nguyen Van Nam wrote: > Hi all, > Mon program needs a trigger of LSDB changes in XORPs . > Could you please tell me which function i can use to do that? You'd have to add an XRL client interface to support that, I don't believe the OSPF process currently has a mechanism for sending notifications of such events. Someone on the list (possibly me) should be happy to review such a patch for inclusion in XORP. thanks BMS -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080803/abea3d64/attachment.html From van_nam_78 at yahoo.com Sun Aug 3 12:59:17 2008 From: van_nam_78 at yahoo.com (Nguyen Van Nam) Date: Sun, 3 Aug 2008 12:59:17 -0700 (PDT) Subject: [Xorp-hackers] Conflict between processes, how to avoid? Message-ID: <793186.34538.qm@web50206.mail.re2.yahoo.com> Hi all, Thank you so much for your answers. In fact, i have implemented a XRL client interface to notify LSDB change. But I have encountered an error when I called another Xrl request to set interface cost, because this one cause the LSDB to be changed immediately so at the same time there are 2 processes running. In your experiences , how to avoid this? (Note that I have to called consecutively many times the function: set_interface_cost from my module, ) Thanks Nguyen van Nam ----- Original Message ---- From: Bruce M Simpson To: Nguyen Van Nam Cc: XORP DEVELOPERS Sent: Sunday, August 3, 2008 6:52:11 PM Subject: Re: Detect LSDB change? Nguyen Van Nam wrote: > Hi all, > Mon program needs a trigger of LSDB changes in XORPs . > Could you please tell me which function i can use to do that? You'd have to add an XRL client interface to support that, I don't believe the OSPF process currently has a mechanism for sending notifications of such events. Someone on the list (possibly me) should be happy to review such a patch for inclusion in XORP. thanks BMS -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080803/db37d422/attachment.html -------------- next part -------------- _______________________________________________ Xorp-hackers mailing list Xorp-hackers at icir.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From bms at incunabulum.net Sun Aug 3 15:01:06 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Sun, 03 Aug 2008 23:01:06 +0100 Subject: [Xorp-hackers] Detect LSDB change? In-Reply-To: <25909.83667.qm@web50208.mail.re2.yahoo.com> References: <25909.83667.qm@web50208.mail.re2.yahoo.com> Message-ID: <48962AA2.2050906@incunabulum.net> Nguyen Van Nam wrote: > Hi, > By the way, could you please shortly explain me the structure of LSDB > in XORP? Please refer to the API documentation for the Lsa class in the ospf process: http://www.xorp.org/releases/current/docs/kdoc/html/ospf/Lsa.html I would recommend installing a source code browser such as Red Hat's "Source Navigator" or KScope to refer to where Lsa is stored and held within the various stages of the OSPF process. thanks BMS P.S. Please Cc: queries such as this to the xorp-hackers@ list as I do not always have time to respond to each query personally, and so that other people may benefit from the discussion. Thanks. From bms at incunabulum.net Sun Aug 3 15:05:45 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Sun, 03 Aug 2008 23:05:45 +0100 Subject: [Xorp-hackers] Conflict between processes, how to avoid? In-Reply-To: <793186.34538.qm@web50206.mail.re2.yahoo.com> References: <793186.34538.qm@web50206.mail.re2.yahoo.com> Message-ID: <48962BB9.80600@incunabulum.net> Nguyen Van Nam wrote: > Hi all, > Thank you so much for your answers. > In fact, i have implemented a XRL client interface to notify LSDB change. > But I have encountered an error when I called another Xrl request to > set interface cost, because this one cause the LSDB to be changed > immediately so at the same time there are 2 processes running. In your > experiences , how to avoid this? XRLs can only be processed one at a time by any XORP process, as they are all single threaded. How exactly is the race condition manifesting in your program, and how is this a problem? It would be helpful for others if you point out exactly which error(s) you're seeing. It is not going to be possible to avoid having the Lsa database change from underneath the xorp_ospf process, obviously because setting the interface cost changes the cost of Lsas (and their corresponding routing table entries) which transit that interface. thanks BMS From bms at incunabulum.net Sun Aug 3 16:16:39 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Mon, 04 Aug 2008 00:16:39 +0100 Subject: [Xorp-hackers] Delay in XORP? In-Reply-To: <737321.87016.qm@web50210.mail.re2.yahoo.com> References: <737321.87016.qm@web50210.mail.re2.yahoo.com> Message-ID: <48963C57.3070507@incunabulum.net> Nguyen Van Nam wrote: > Hi, > I have done a test with TimerList like this: > TimerList _timerlist; > _timerList.system_sleep(100); > It produce an error: > error: no matching function for call to > 'TimerList::TimerList(XorpTimer&)' > ../libxorp/timer.hh:452: note: candidates are: > TimerList::TimerList(const TimerList&) > ../libxorp/timer.hh:215: note: > TimerList::TimerList(ClockBase*) > Why is that? Could you send me an example of calling this method? TimerList::system_sleep() is a class static method. BMS From van_nam_78 at yahoo.com Sun Aug 3 16:50:44 2008 From: van_nam_78 at yahoo.com (Nguyen Van Nam) Date: Sun, 3 Aug 2008 16:50:44 -0700 (PDT) Subject: [Xorp-hackers] Fw: Detect LSDB change? Message-ID: <786476.62892.qm@web50208.mail.re2.yahoo.com> ----- Forwarded Message ---- From: Bruce M Simpson To: Nguyen Van Nam Cc: xorp-hackers Sent: Monday, August 4, 2008 12:01:06 AM Subject: Re: Detect LSDB change? Nguyen Van Nam wrote: > Hi, > By the way, could you please shortly explain me the structure of LSDB > in XORP? Please refer to the API documentation for the Lsa class in the ospf process: http://www.xorp.org/releases/current/docs/kdoc/html/ospf/Lsa.html I would recommend installing a source code browser such as Red Hat's "Source Navigator" or KScope to refer to where Lsa is stored and held within the various stages of the OSPF process. thanks BMS P.S. Please Cc: queries such as this to the xorp-hackers@ list as I do not always have time to respond to each query personally, and so that other people may benefit from the discussion. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080803/8c7525e4/attachment.html From van_nam_78 at yahoo.com Sun Aug 3 16:50:58 2008 From: van_nam_78 at yahoo.com (Nguyen Van Nam) Date: Sun, 3 Aug 2008 16:50:58 -0700 (PDT) Subject: [Xorp-hackers] Fw: Conflict between processes, how to avoid? Message-ID: <632676.21345.qm@web50205.mail.re2.yahoo.com> ----- Forwarded Message ---- From: Bruce M Simpson To: Nguyen Van Nam Cc: XORP DEVELOPERS Sent: Monday, August 4, 2008 12:05:45 AM Subject: Re: [Xorp-hackers] Conflict between processes, how to avoid? Nguyen Van Nam wrote: > Hi all, > Thank you so much for your answers. > In fact, i have implemented a XRL client interface to notify LSDB change. > But I have encountered an error when I called another Xrl request to > set interface cost, because this one cause the LSDB to be changed > immediately so at the same time there are 2 processes running. In your > experiences , how to avoid this? XRLs can only be processed one at a time by any XORP process, as they are all single threaded. How exactly is the race condition manifesting in your program, and how is this a problem? It would be helpful for others if you point out exactly which error(s) you're seeing. It is not going to be possible to avoid having the Lsa database change from underneath the xorp_ospf process, obviously because setting the interface cost changes the cost of Lsas (and their corresponding routing table entries) which transit that interface. thanks BMS -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080803/e808fa44/attachment.html From atanu at xorp.org Tue Aug 5 15:32:27 2008 From: atanu at xorp.org (Atanu Ghosh) Date: Tue, 05 Aug 2008 15:32:27 -0700 Subject: [Xorp-hackers] OSPF bug(s) in XORP-1.5 In-Reply-To: Message from "Francisco Rodriguez" of "Fri, 01 Aug 2008 16:10:03 BST." <003b01c8f3e8$acbabaa0$c5e05894@lancs.local> Message-ID: <5934.1217975547@xorps.icir.org> 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 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 From van_nam_78 at yahoo.com Wed Aug 6 02:53:47 2008 From: van_nam_78 at yahoo.com (Nguyen Van Nam) Date: Wed, 6 Aug 2008 02:53:47 -0700 (PDT) Subject: [Xorp-hackers] How OSPF control Xrl requests at the same time? Message-ID: <966392.955.qm@web50203.mail.re2.yahoo.com> Hi all, Because eventloop can run only once at a time, so I have a question, how OSPF handle when there are many Xrl request arriving at the same time?? Thanks so much to explain me? Nguyen Van Nam ----- Original Message ---- From: Bruce M Simpson To: Nguyen Van Nam Cc: XORP DEVELOPERS Sent: Monday, August 4, 2008 12:05:45 AM Subject: Re: [Xorp-hackers] Conflict between processes, how to avoid? Nguyen Van Nam wrote: > Hi all, > Thank you so much for your answers. > In fact, i have implemented a XRL client interface to notify LSDB change. > But I have encountered an error when I called another Xrl request to > set interface cost, because this one cause the LSDB to be changed > immediately so at the same time there are 2 processes running. In your > experiences , how to avoid this? XRLs can only be processed one at a time by any XORP process, as they are all single threaded. How exactly is the race condition manifesting in your program, and how is this a problem? It would be helpful for others if you point out exactly which error(s) you're seeing. It is not going to be possible to avoid having the Lsa database change from underneath the xorp_ospf process, obviously because setting the interface cost changes the cost of Lsas (and their corresponding routing table entries) which transit that interface. thanks BMS -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080806/70dbf291/attachment.html From bms at incunabulum.net Wed Aug 6 15:28:24 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Wed, 06 Aug 2008 23:28:24 +0100 Subject: [Xorp-hackers] How OSPF control Xrl requests at the same time? In-Reply-To: <966392.955.qm@web50203.mail.re2.yahoo.com> References: <966392.955.qm@web50203.mail.re2.yahoo.com> Message-ID: <489A2588.2000707@incunabulum.net> Nguyen Van Nam wrote: > Hi all, > Because eventloop can run only once at a time, so I have a question, > how OSPF handle when there are many Xrl request arriving at the same > time?? They get processed in the order in which they arrive. From van_nam_78 at yahoo.com Thu Aug 7 08:56:07 2008 From: van_nam_78 at yahoo.com (Nguyen Van Nam) Date: Thu, 7 Aug 2008 08:56:07 -0700 (PDT) Subject: [Xorp-hackers] How OSPF control Xrl requests at the same time? Message-ID: <732025.93495.qm@web50204.mail.re2.yahoo.com> Hi , OK, it's FIFO but i want to know if XORP support this FIFO or the developer (when creating a new module) has to do that? Thanks NVNam ----- Original Message ---- From: Bruce M Simpson To: Nguyen Van Nam Cc: XORP DEVELOPERS Sent: Thursday, August 7, 2008 12:28:24 AM Subject: Re: How OSPF control Xrl requests at the same time? Nguyen Van Nam wrote: > Hi all, > Because eventloop can run only once at a time, so I have a question, > how OSPF handle when there are many Xrl request arriving at the same > time?? They get processed in the order in which they arrive. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080807/20f5f45f/attachment.html From bms at incunabulum.net Thu Aug 7 09:10:39 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Thu, 07 Aug 2008 17:10:39 +0100 Subject: [Xorp-hackers] How OSPF control Xrl requests at the same time? In-Reply-To: <732025.93495.qm@web50204.mail.re2.yahoo.com> References: <732025.93495.qm@web50204.mail.re2.yahoo.com> Message-ID: <489B1E7F.6060102@incunabulum.net> Nguyen Van Nam wrote: > Hi , > OK, it's FIFO but i want to know if XORP support this FIFO or the > developer (when creating a new module) has to do that? As long as the EventLoop runs, incoming requests will be processed. The queueing happens partly in the XRL code (buffers for reassembly) and partly in the host operating system (socket buffers). From f.rodriguez at lancaster.ac.uk Fri Aug 8 02:04:41 2008 From: f.rodriguez at lancaster.ac.uk (Francisco Rodriguez) Date: Fri, 8 Aug 2008 10:04:41 +0100 Subject: [Xorp-hackers] OSPF bug(s) in XORP-1.5 In-Reply-To: <5934.1217975547@xorps.icir.org> References: Message from "Francisco Rodriguez" of "Fri, 01 Aug 2008 16:10:03 BST." <003b01c8f3e8$acbabaa0$c5e05894@lancs.local> <5934.1217975547@xorps.icir.org> Message-ID: <003301c8f935$cb45eec0$c5e05894@lancs.local> 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 down" which effectively will cause XORP to detect a failure. But, if I enter the command "ifconfig 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 vif 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 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 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 From pavlin at ICSI.Berkeley.EDU Fri Aug 8 10:32:56 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Fri, 08 Aug 2008 10:32:56 -0700 Subject: [Xorp-hackers] OSPF bug(s) in XORP-1.5 In-Reply-To: <003301c8f935$cb45eec0$c5e05894@lancs.local> References: Message from "Francisco Rodriguez" of "Fri, 01 Aug 2008 16:10:03 BST." <003b01c8f3e8$acbabaa0$c5e05894@lancs.local> <5934.1217975547@xorps.icir.org> <003301c8f935$cb45eec0$c5e05894@lancs.local> Message-ID: <200808081733.m78HWusv026148@fruitcake.ICSI.Berkeley.EDU> 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 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 down" which effectively will cause XORP to detect a > failure. But, if I enter the command "ifconfig 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 vif 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 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 > 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 ] From pavlin at ICSI.Berkeley.EDU Tue Aug 12 21:17:06 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Tue, 12 Aug 2008 21:17:06 -0700 Subject: [Xorp-hackers] question on MLD querier -- rtalert extension header? In-Reply-To: <200807100528.m6A5SCbH000835@fruitcake.ICSI.Berkeley.EDU> References: <766FBB5D-A732-4ED1-9832-110D31A4B74B@cs.berkeley.edu> <200807070723.m677Mx46027430@fruitcake.ICSI.Berkeley.EDU> <55FC92A5-DA69-4ED2-8433-9DADB5ADC41D@cs.berkeley.edu> <200807100528.m6A5SCbH000835@fruitcake.ICSI.Berkeley.EDU> Message-ID: <200808130417.m7D4H6S7023452@fruitcake.ICSI.Berkeley.EDU> Kevin et al, I finally managed to debug the problem after installing OS (Debian) with Linux kernel 2.6.26. There were few (mostly compilation) errors which are now fixed in CVS. The original problem with the buggy inet6_opt_init() is still there, but you might want to have a look in Bugzilla entry #761 which contains a hack to get around it: http://bugzilla.xorp.org/bugzilla/show_bug.cgi?id=761 Hence, if you want to try XORP with 2.6.26 kernel you should get the latest code from CVS and then apply the hack from Bugzilla entry #761. Note that I haven't tested whether IPv6 multicast routing with that kernel actually works. Any feedbacks are welcome. Thanks, Pavlin Pavlin Radoslavov wrote: > Kevin Fall wrote: > > > Ok, this took me most of the day (unfortunately), but here it is: > > > > I am running on a Redhat linux system, and my problem was due to the issue > > discussed here: > > > > http://sourceware.org/bugzilla/show_bug.cgi?id=5760 > > > > Basically, inet6_opt_init() was setting the v6 extension header length to the > > value 1 instead of 0, even for small > > extensions like the HBH/RtAlert one. > > > > This is wrong. But the consequence is that the apparent size of the option + > > cmsg structure was > > too big. If cmsg_len is appropriately trimmed to the option size based on > > return values of inet_opt_XX, then the kernel (correctly) gives an EINVAL > > because it thinks > > the option is longer than the ancillary data provided to hold it :(. > > Thanks for the info. The problem appears to be in glibc and > according to the above Bugzilla entry it has been fixed in their > repository. > > I didn't understand your comment about cmsg_len. Are you suggesting > that its value should be set by using the return value of, say, > inet6_opt_init(), inet6_opt_append(), etc? > Currently, cmsg_len is set by using the following assignment: > cmsgp->cmsg_len = CMSG_LEN(...) > which is actually based on the sample code from RFC 3542. > > > Attached is the .config for you. I'm looking into the best way to fix this, > > but it would appear > > that verifying and whacking as necessary the header produced by > > inet6_opt_init would be a first step. > > It looks like the RFC3542 support for Linux has some issues. > The right solution for Router Alert problem would be to apply the > glibc fix for inet6_opt_init(). > > > I don't know whether the original issue (the "Invalid argument" > error) is related to the inet6_opt_init(), but anyway I just added a > Bugzilla entry on your behalf re. the "Invalid argument" issue you > were seeing: > http://bugzilla.xorp.org/bugzilla/show_bug.cgi?id=761 > > I wish I have the time to start playing with the 2.6.26 release > candidates. Unfortunately I would have to wait until Linux > kernel 2.6.26 is released and is available for Ubuntu before I try > to fix it. > This will also tell us whether the problem is RedHat specific or > applies to more than one distribution. > > In the mean time please add any additional information on the > subject to the new Bugzilla entry. > > > Pavlin > > > > thx, > > > > - K > > > > On Jul 7, 2008, at Jul 712:22 AMPDT, Pavlin Radoslavov wrote: > > > > >> It appears to me that MLD query messages do not include the HBH/ Router- > > >> Alert extension header. I believe this is incorrect. > > >> (queries need to be processed by non-querier multicast routers on the > > >> same subnet). Can somebody very/explain whether > > >> I have this correct? > > > > > > Yes, all MLD messages must include the IPv6 Router Alert option. > > > I just tested it on FreeBSD-7.0, and the Query messages actually > > > include the Router Alert extension header, so the problem is > > > probably OS-specific. > > > > > > If this option is missing in your setup, then this is a bug. In that > > > case please submit a Bugzilla entry with information how to > > > reproduce the problem, OS version, etc. > > > > > > Pavlin > > > (still waiting for your .config Linux kernel config file :) > > > > > > > _______________________________________________ > > Xorp-hackers mailing list > > Xorp-hackers at icir.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From daniel_ng11 at lycos.com Wed Aug 13 23:22:09 2008 From: daniel_ng11 at lycos.com (Daniel Ng) Date: Thu, 14 Aug 2008 02:22:09 -0400 (EDT) Subject: [Xorp-hackers] IPv4 Multicast Router on embedded Linux device? Message-ID: <20080814022209.HM.0000000000000E2@daniel_ng11.bos-mail-wwl24.lycos.com> An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080814/1a55c935/attachment.html From daniel.ngq at gmail.com Thu Aug 14 01:01:22 2008 From: daniel.ngq at gmail.com (Daniel ng) Date: Thu, 14 Aug 2008 18:01:22 +1000 Subject: [Xorp-hackers] Minimal XORP IPv4 Multicast for embedded Linux? Message-ID: <79097fba0808140101n6d83b1ebjc313e863a4409a38@mail.gmail.com> Hi, I'm looking for a reliable IPv4 Multicast Router implementation suitable for an embedded Linux device. Currently, my device runs Linux 2.6.14, with Quagga as its unicast routing engine. Would XORP run on this sort of system? To avoid using too much space, can I choose a minimal subset of the XORP modules to install? I only want IPv4 multicast routing and nothing else ie. no OSPF, no RIP. Would I have any interworking problems between XORP Multicast Routing and Quagga running OSPF/RIP? Currently, my Quagga implementation uses the uClibc mini C libraries. I believe XORP is in C++. Can XORP be compiled against a small version of the C++ libraries? Cheers, Daniel From van_nam_78 at yahoo.com Thu Aug 14 02:33:09 2008 From: van_nam_78 at yahoo.com (Nguyen Van Nam) Date: Thu, 14 Aug 2008 02:33:09 -0700 (PDT) Subject: [Xorp-hackers] Xrl Error? Message-ID: <640811.37733.qm@web50203.mail.re2.yahoo.com> Hi all, I have sent many Xrl request one after the other, but I found the following error: XifFinder+846 finder_client.cc messenger_birth_event . Assertion (0==_messenger) failed. Could you please tell me why? Thanks Nguyen Van Nam -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080814/cffa8583/attachment.html From bms at incunabulum.net Thu Aug 14 04:08:24 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Thu, 14 Aug 2008 12:08:24 +0100 Subject: [Xorp-hackers] [Xorp-users] Minimal XORP IPv4 Multicast for embedded Linux? In-Reply-To: <79097fba0808140101n6d83b1ebjc313e863a4409a38@mail.gmail.com> References: <79097fba0808140101n6d83b1ebjc313e863a4409a38@mail.gmail.com> Message-ID: <48A41228.5080506@incunabulum.net> Daniel ng wrote: > Hi, > > I'm looking for a reliable IPv4 Multicast Router implementation > suitable for an embedded Linux device. > > Currently, my device runs Linux 2.6.14, with Quagga as its unicast > routing engine. > > Would XORP run on this sort of system? > It's difficult to say without any details about memory, CPU, architecture etc. At a minimum, 256MB of memory is needed for the LiveCD on x86, although the binaries need to run out of RAM after being faulted-in from CD. It may be possible to squeeze some of XORP into a 64MB RAM footprint although this is dependent on changes to the build system, at the moment we do not support shared linking of XORP libraries for the router processes themselves -- other than system DLLs or 3rd party components. > To avoid using too much space, can I choose a minimal subset of the > XORP modules to install? > I only want IPv4 multicast routing and nothing else ie. no OSPF, no RIP. > What you install is up to you, I would suggest looking at the Windows .nsi installer file to see exactly which binary components are fundamental. > Would I have any interworking problems between XORP Multicast Routing > and Quagga running OSPF/RIP? > There shouldn't be, XORP has undergone some interop tests at UNH; please refer to the website for more details. > Currently, my Quagga implementation uses the uClibc mini C libraries. > I believe XORP is in C++. Can XORP be compiled against a small version > of the C++ libraries? > The only C++ runtime we regularly test against is the GNU libstdc++ runtime, feedback from folk about other libraries would be very welcome. thanks BMS From van_nam_78 at yahoo.com Thu Aug 14 06:29:47 2008 From: van_nam_78 at yahoo.com (Nguyen Van Nam) Date: Thu, 14 Aug 2008 06:29:47 -0700 (PDT) Subject: [Xorp-hackers] Error when using OSPF Xrl Client? Message-ID: <855619.7314.qm@web50201.mail.re2.yahoo.com> Hi all, When using OSPF XRl client to send a request: send_get_lsa(). I havc found the following error: xorp_rib, RIB, Received death event for protocol ... shutting down. Could u please help me to fix this? Thanks NVN -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080814/f584bd61/attachment.html From pavlin at ICSI.Berkeley.EDU Thu Aug 14 10:15:23 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Thu, 14 Aug 2008 10:15:23 -0700 Subject: [Xorp-hackers] [Xorp-users] Minimal XORP IPv4 Multicast for embedded Linux? In-Reply-To: <48A41228.5080506@incunabulum.net> References: <79097fba0808140101n6d83b1ebjc313e863a4409a38@mail.gmail.com> <48A41228.5080506@incunabulum.net> Message-ID: <200808141715.m7EHFNPL029675@fruitcake.ICSI.Berkeley.EDU> > > To avoid using too much space, can I choose a minimal subset of the > > XORP modules to install? > > I only want IPv4 multicast routing and nothing else ie. no OSPF, no RIP. > > > > What you install is up to you, I would suggest looking at the Windows > .nsi installer file to see exactly which binary components are fundamental. Off the top of my head, you need the following modules and associated binaries and template files: fea, rib, fib2mrib, rtrmgr, xorpsh, mld6igmp (xorp_igmp for IPv4 only), pim (xorp_pimsm4 for IPv4 only), cli/tools/send_cli_processor_xrl . The pragmatic approach that comes to mind how to select them would to be to compile vanilla XORP and install everything with "gmake install" under /usr/local/xorp . Then remove the directories you don't need (bgp, rip, etc), and the associated template files in etc/templates/ Hope that helps, Pavlin From daniel.ngq at gmail.com Thu Aug 14 17:22:00 2008 From: daniel.ngq at gmail.com (Daniel ng) Date: Fri, 15 Aug 2008 10:22:00 +1000 Subject: [Xorp-hackers] [Xorp-users] Minimal XORP IPv4 Multicast for embedded Linux? In-Reply-To: <48A411FD.9070505@icir.org> References: <79097fba0808140101n6d83b1ebjc313e863a4409a38@mail.gmail.com> <48A411FD.9070505@icir.org> Message-ID: <79097fba0808141722t2028f825i782a936c25469c5@mail.gmail.com> On Thu, Aug 14, 2008 at 9:07 PM, Bruce M. Simpson wrote: > It's difficult to say without any details about memory, CPU, architecture > etc. 32MB RAM, 32MB flash, PowerPC ie. not much! Quagga (with its OSPF module) complied against uClibc takes just 1MB of flash and about 2k of RAM. Can XORP with just IPv4 Multicast be shrunk to these sorts of sizes? From pavlin at ICSI.Berkeley.EDU Fri Aug 15 14:28:06 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Fri, 15 Aug 2008 14:28:06 -0700 Subject: [Xorp-hackers] [Xorp-users] Minimal XORP IPv4 Multicast for embedded Linux? In-Reply-To: <79097fba0808141722t2028f825i782a936c25469c5@mail.gmail.com> References: <79097fba0808140101n6d83b1ebjc313e863a4409a38@mail.gmail.com> <48A411FD.9070505@icir.org> <79097fba0808141722t2028f825i782a936c25469c5@mail.gmail.com> Message-ID: <200808152128.m7FLS6eZ028387@fruitcake.ICSI.Berkeley.EDU> Daniel ng wrote: > On Thu, Aug 14, 2008 at 9:07 PM, Bruce M. Simpson wrote: > > It's difficult to say without any details about memory, CPU, architecture > > etc. > > 32MB RAM, 32MB flash, PowerPC ie. not much! > > Quagga (with its OSPF module) complied against uClibc takes just 1MB > of flash and about 2k of RAM. > > Can XORP with just IPv4 Multicast be shrunk to these sorts of sizes? You would have to try and tell us :) By default XORP compiles with debug information enabled, which increases significantly the size. You might want to use: ./configure --enable-optimize --disable-debug --disable-ipv6 gmake clean && gmake After the compilation, you might be able to remove few extra KBs by using "strip" on each executable file you are going to use. Another thing to try is to set CFLAGS and CXXFLAGS environmental variables to, say, "-Os" which will optimize for size. E.g., use the following commands (in csh/tcsh) BEFORE running the above "./configure ..." command: setenv CFLAGS -Os setenv CXXFLAGS -Os Pavlin > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From dongnine at nate.com Mon Aug 18 04:32:58 2008 From: dongnine at nate.com (=?euc-kr?B?sPu1v7G4?=) Date: Mon, 18 Aug 2008 20:32:58 +0900 Subject: [Xorp-hackers] =?euc-kr?q?Question_about_adding_new_operational_c?= =?euc-kr?q?ommand?= Message-ID: <20080818203258269130$70719c8@pcmail.nate.com> An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080818/a9ba2e6e/attachment.html From bms at incunabulum.net Mon Aug 18 14:59:11 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Mon, 18 Aug 2008 22:59:11 +0100 Subject: [Xorp-hackers] Question about adding new operational command In-Reply-To: <20080818203258269130$70719c8@pcmail.nate.com> References: <20080818203258269130$70719c8@pcmail.nate.com> Message-ID: <48A9F0AF.1090009@incunabulum.net> ?????? wrote: > I am a beginner in XORP. I would like to add new command (traffic > control command) like ping and traceroute. > But I don't know how to do it,event though I alread read most of > documents. > Can anyone help me ? You need to look at the etc/templates/misc.cmds file. Assuming your new command is a shell command it should be easy to add to that file. thanks BMS From bms at incunabulum.net Tue Aug 19 04:45:40 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Tue, 19 Aug 2008 12:45:40 +0100 Subject: [Xorp-hackers] Question about adding new operational command In-Reply-To: <20080819204339299760$70719c8@pcmail.nate.com> References: <20080819204339299760$70719c8@pcmail.nate.com> Message-ID: <48AAB264.70002@incunabulum.net> ?????? wrote: > > I have one more question. > If we do like ./test.txt in linux shell, we can excute a test,txt file. > (There is some shell command in test file.) > > So I added a test command in misc.cmd file and execute test in xorpsh, > but there was error message :exited with exit status 127. ... The commands which you add need to be executable within the host operating system. The Router Manager doesn't know how to invoke shell scripts on its own. thanks BMS From greearb at candelatech.com Tue Aug 19 16:04:12 2008 From: greearb at candelatech.com (Ben Greear) Date: Tue, 19 Aug 2008 16:04:12 -0700 Subject: [Xorp-hackers] register_vif ifindex Message-ID: <48AB516C.60805@candelatech.com> It seems that register_vif uses the PifIndex of another 'real' port in the router. Should it perhaps use the pimreg port, or just have a 0 like the discard interface? root at lanforge-nec-demo> show mfea interface Interface State Vif/PifIndex Addr Flags 1.2.2 UP 0/84 10.1.2.2 MULTICAST BROADCAST KERN_UP 2.3.2 UP 1/86 10.2.3.2 MULTICAST BROADCAST KERN_UP br2 UP 2/73 10.2.2.2 MULTICAST BROADCAST KERN_UP my_discard DISABLED 3/0 KERN_UP register_vif UP 4/73 10.2.2.2 PIM_REGISTER KERN_UP root at lanforge-nec-demo> -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at ICSI.Berkeley.EDU Tue Aug 19 21:39:27 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Tue, 19 Aug 2008 21:39:27 -0700 Subject: [Xorp-hackers] register_vif ifindex In-Reply-To: <48AB516C.60805@candelatech.com> References: <48AB516C.60805@candelatech.com> Message-ID: <200808200439.m7K4dSgR009325@fruitcake.ICSI.Berkeley.EDU> Ben Greear wrote: > It seems that register_vif uses the PifIndex of another > 'real' port in the router. Should it perhaps use the pimreg > port, or just have a 0 like the discard interface? KAME-derived IPv6 kernels require that the register_vif has a valid physical interface index, hence it is not set to 0. Also, have in mind that the Linux-specific pimreg kernel interface is created _after_ the MFEA's setsockopt(MRT_ADD_VIF) for the VIFF_REGISTER multicast interface. I.e., it is not available when MfeaNode::add_pim_register_vif() is called. Pavlin > root at lanforge-nec-demo> show mfea interface > Interface State Vif/PifIndex Addr Flags > 1.2.2 UP 0/84 10.1.2.2 MULTICAST BROADCAST KERN_UP > 2.3.2 UP 1/86 10.2.3.2 MULTICAST BROADCAST KERN_UP > br2 UP 2/73 10.2.2.2 MULTICAST BROADCAST KERN_UP > my_discard DISABLED 3/0 KERN_UP > register_vif UP 4/73 10.2.2.2 PIM_REGISTER KERN_UP > root at lanforge-nec-demo> > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From f.rodriguez at lancaster.ac.uk Wed Aug 20 04:12:14 2008 From: f.rodriguez at lancaster.ac.uk (Francisco Rodriguez) Date: Wed, 20 Aug 2008 12:12:14 +0100 Subject: [Xorp-hackers] OSPF bug(s) in XORP-1.5 In-Reply-To: <200808081733.m78HWusv026148@fruitcake.ICSI.Berkeley.EDU> References: Message from "Francisco Rodriguez" of "Fri, 01 Aug 2008 16:10:03 BST." <003b01c8f3e8$acbabaa0$c5e05894@lancs.local> <5934.1217975547@xorps.icir.org> <003301c8f935$cb45eec0$c5e05894@lancs.local> <200808081733.m78HWusv026148@fruitcake.ICSI.Berkeley.EDU> Message-ID: <002a01c902b5$9989f0a0$c5e05894@lancs.local> Pavlin, First of all, thanks for the explanation provided in the previous e-mail, it helped me to clarify the normal behavior from the abnormal. Second, and apology for the delayed answer, but I couldn't test what you suggested me before, anyway here are my findings after considering your input. 1) When configuring system's network cards (ports) in XORP (Boot file or CLI), the interface's configuration disable option works fined at the different levels which are available (I.E. interface eth1 disable, interface eth1 vif eth1 disable, and interface eth1 vif eth1 address x.x.x.x disable). I have verified this by checking the interfaces status with "show interfaces" and "show ospf4 neighbor". 2) When configuring the system's network cards (ports) in XORP using system's default configuration, I have found the following: 2.1) when disabling the interface on systems shell using ifconfig down, XORP does recognizes that the interface has come down: root at Route-Server> show interfaces eth1.12/eth1.12: Flags: 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: 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> quit Route-Server:~# ifconfig eth1.12 down Route-Server:~# /usr/local/xorp-1.5/rtrmgr/./xorpsh root at Route-Server> show interfaces eth1.12: Flags:<> mtu 1500 speed 100 Mbps physical index 5 ether 52:54:0:12:35:52 eth1.13/eth1.13: Flags: 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.2.3 eth1.13/eth1.13 Full 192.168.2.3 128 31 So far, so good. 2.2) Then, after bringing up the interface, again in system's shell by entering ifconfig up, I found that XORP does recognizes that the interfaces is up again: Route-Server:~# ifconfig eth1.12 up Route-Server:~# /usr/local/xorp-1.5/rtrmgr/./xorpsh Welcome to XORP on Route-Server root at Route-Server> show interfaces eth1.12/eth1.12: Flags: mtu 1500 speed 100 Mbps inet6 fe80::5054:ff:fe12:3552 prefixlen 64 physical index 5 ether 52:54:0:12:35:52 eth1.13/eth1.13: Flags: 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 BUT, it doesn't load the IP address information as it can be noted above. So, due to this reason, OSPF doesn't consider such interface for any of its running processes. root at Route-Server> show ospf4 neighbor Address Interface State ID Pri Dead 192.168.2.3 eth1.13/eth1.13 Full 192.168.2.3 128 35 2.3) After, I flapped the interface by issuing a disable-enable on XORPSH (CLI), to try and see if in this way XORP does reload interface's IP information, which indeed it does! root at Route-Server# create interfaces interface eth1.12 disable true root at Route-Server# commit 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> show ospf4 neighbor Address Interface State ID Pri Dead 192.168.1.3 eth1.12/eth1.12 Full 192.168.1.3 128 37 192.168.2.3 eth1.13/eth1.13 Full 192.168.2.3 128 33 root at Route-Server> show interfaces eth1.12/eth1.12: Flags: 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: 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 >From previous, it seems that the issue comes from FEA and not from OSPF as I though initially. 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 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 down" which effectively will cause XORP to detect a > failure. But, if I enter the command "ifconfig 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 vif 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 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 > 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 ] From f.rodriguez at lancaster.ac.uk Wed Aug 20 12:54:51 2008 From: f.rodriguez at lancaster.ac.uk (Francisco Rodriguez) Date: Wed, 20 Aug 2008 20:54:51 +0100 Subject: [Xorp-hackers] OSPF bug(s) in XORP-1.5 In-Reply-To: <200808081733.m78HWusv026148@fruitcake.ICSI.Berkeley.EDU> References: Message from "Francisco Rodriguez" of "Fri, 01 Aug 2008 16:10:03 BST." <003b01c8f3e8$acbabaa0$c5e05894@lancs.local> <5934.1217975547@xorps.icir.org> <003301c8f935$cb45eec0$c5e05894@lancs.local> <200808081733.m78HWusv026148@fruitcake.ICSI.Berkeley.EDU> Message-ID: <000301c902fe$9bd3fd80$c5e05894@lancs.local> 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: 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: 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: 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: 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: 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: 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: 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: 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 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 down" which effectively will cause XORP to detect a > failure. But, if I enter the command "ifconfig 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 vif 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 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 > 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 ] From pavlin at ICSI.Berkeley.EDU Wed Aug 20 21:25:47 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Wed, 20 Aug 2008 21:25:47 -0700 Subject: [Xorp-hackers] OSPF bug(s) in XORP-1.5 In-Reply-To: <002a01c902b5$9989f0a0$c5e05894@lancs.local> References: Message from "Francisco Rodriguez" of "Fri, 01 Aug 2008 16:10:03 BST." <003b01c8f3e8$acbabaa0$c5e05894@lancs.local> <5934.1217975547@xorps.icir.org> <003301c8f935$cb45eec0$c5e05894@lancs.local> <200808081733.m78HWusv026148@fruitcake.ICSI.Berkeley.EDU> <002a01c902b5$9989f0a0$c5e05894@lancs.local> Message-ID: <200808210426.m7L4Pluv000779@fruitcake.ICSI.Berkeley.EDU> Francisco Rodriguez wrote: > 2) When configuring the system's network cards (ports) in XORP using > system's default configuration, I have found the following: > 2.1) when disabling the interface on systems shell using ifconfig > down, XORP does recognizes that the interface has come down: > root at Route-Server> show interfaces > eth1.12/eth1.12: Flags: 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: 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> quit > Route-Server:~# ifconfig eth1.12 down > Route-Server:~# /usr/local/xorp-1.5/rtrmgr/./xorpsh > root at Route-Server> show interfaces > eth1.12: Flags:<> mtu 1500 speed 100 Mbps > physical index 5 > ether 52:54:0:12:35:52 > eth1.13/eth1.13: Flags: 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.2.3 eth1.13/eth1.13 Full 192.168.2.3 128 31 > > So far, so good. > 2.2) Then, after bringing up the interface, again in system's shell > by entering ifconfig up, I found that XORP does recognizes that the > interfaces is up again: > Route-Server:~# ifconfig eth1.12 up > Route-Server:~# /usr/local/xorp-1.5/rtrmgr/./xorpsh > Welcome to XORP on Route-Server > root at Route-Server> show interfaces > eth1.12/eth1.12: Flags: mtu 1500 speed 100 Mbps > inet6 fe80::5054:ff:fe12:3552 prefixlen 64 > physical index 5 > ether 52:54:0:12:35:52 > eth1.13/eth1.13: Flags: 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 > > BUT, it doesn't load the IP address information as it can be noted above. I presume you are using VLANs (as you mentioned in your follow-up email). What OS distribution and kernel version are you using? I tried to replicate the problem on Ubuntu-8.04 with kernel 2.6.24-19-server, but I couldn't. Could you double-check by using the Linux "ip" command that when you took eth1.12 down, the IPv4 address was still configured in the kernel. For reference purpose, here is what I did (I was using Ubuntu within VMware Fusion). For simplicity I configured only the FEA, and I had already configured the VLAN in advance: ======== Interface configuration before starting XORP: pavlin at vm-ubuntu[3] ip addr 3: eth1: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:0c:29:c4:42:3f brd ff:ff:ff:ff:ff:ff inet 10.10.10.10/24 brd 10.10.10.255 scope global eth1 inet6 fe80::20c:29ff:fec4:423f/64 scope link valid_lft forever preferred_lft forever 4: vlan1 at eth1: mtu 1500 qdisc noqueue link/ether 00:0c:29:c4:42:3f brd ff:ff:ff:ff:ff:ff inet 10.10.20.20/24 brd 10.10.20.255 scope global vlan1 inet6 fe80::20c:29ff:fec4:423f/64 scope link valid_lft forever preferred_lft forever ======== XORP configuration: interfaces { interface vlan1 { default-system-config } } ======== pavlin at vm-ubuntu> show interfaces vlan1/vlan1: Flags: mtu 1500 speed unknown inet6 fe80::20c:29ff:fec4:423f prefixlen 64 inet 10.10.20.20 subnet 10.10.20.0/24 broadcast 10.10.20.255 physical index 4 ether 0:c:29:c4:42:3f ======== Take vlan1 down: root at vm-ubuntu[13] ifconfig vlan1 down root at vm-ubuntu[14] ip addr 3: eth1: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:0c:29:c4:42:3f brd ff:ff:ff:ff:ff:ff inet 10.10.10.10/24 brd 10.10.10.255 scope global eth1 inet6 fe80::20c:29ff:fec4:423f/64 scope link valid_lft forever preferred_lft forever 4: vlan1 at eth1: mtu 1500 qdisc noqueue link/ether 00:0c:29:c4:42:3f brd ff:ff:ff:ff:ff:ff inet 10.10.20.20/24 brd 10.10.20.255 scope global vlan1 pavlin at vm-ubuntu> show interfaces vlan1/vlan1: Flags: mtu 1500 speed unknown inet 10.10.20.20 subnet 10.10.20.0/24 broadcast 10.10.20.255 physical index 4 ether 0:c:29:c4:42:3f ======== Enable vlan1: root at vm-ubuntu[15] ifconfig vlan1 up root at vm-ubuntu[16] ip addr 3: eth1: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:0c:29:c4:42:3f brd ff:ff:ff:ff:ff:ff inet 10.10.10.10/24 brd 10.10.10.255 scope global eth1 inet6 fe80::20c:29ff:fec4:423f/64 scope link valid_lft forever preferred_lft forever 4: vlan1 at eth1: mtu 1500 qdisc noqueue link/ether 00:0c:29:c4:42:3f brd ff:ff:ff:ff:ff:ff inet 10.10.20.20/24 brd 10.10.20.255 scope global vlan1 inet6 fe80::20c:29ff:fec4:423f/64 scope link valid_lft forever preferred_lft forever pavlin at vm-ubuntu> show interfaces vlan1/vlan1: Flags: mtu 1500 speed unknown inet6 fe80::20c:29ff:fec4:423f prefixlen 64 inet 10.10.20.20 subnet 10.10.20.0/24 broadcast 10.10.20.255 physical index 4 ether 0:c:29:c4:42:3f Pavlin > So, due to this reason, OSPF doesn't consider such interface for any of its > running processes. > > root at Route-Server> show ospf4 neighbor > Address Interface State ID Pri Dead > 192.168.2.3 eth1.13/eth1.13 Full 192.168.2.3 128 35 > > 2.3) After, I flapped the interface by issuing a disable-enable on > XORPSH (CLI), to try and see if in this way XORP does reload interface's IP > information, which indeed it does! > > root at Route-Server# create interfaces interface eth1.12 disable true > root at Route-Server# commit > 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> show ospf4 neighbor > Address Interface State ID Pri Dead > 192.168.1.3 eth1.12/eth1.12 Full 192.168.1.3 128 37 > 192.168.2.3 eth1.13/eth1.13 Full 192.168.2.3 128 33 > root at Route-Server> show interfaces > eth1.12/eth1.12: Flags: 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: 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 > > From previous, it seems that the issue comes from FEA and not from OSPF as I > though initially. From pavlin at ICSI.Berkeley.EDU Wed Aug 20 21:51:25 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Wed, 20 Aug 2008 21:51:25 -0700 Subject: [Xorp-hackers] OSPF bug(s) in XORP-1.5 In-Reply-To: <000301c902fe$9bd3fd80$c5e05894@lancs.local> References: Message from "Francisco Rodriguez" of "Fri, 01 Aug 2008 16:10:03 BST." <003b01c8f3e8$acbabaa0$c5e05894@lancs.local> <5934.1217975547@xorps.icir.org> <003301c8f935$cb45eec0$c5e05894@lancs.local> <200808081733.m78HWusv026148@fruitcake.ICSI.Berkeley.EDU> <000301c902fe$9bd3fd80$c5e05894@lancs.local> Message-ID: <200808210451.m7L4pP82003145@fruitcake.ICSI.Berkeley.EDU> 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 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: 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: 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: 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: 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: 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: 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: 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: 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 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 down" which effectively will cause XORP to detect a > > failure. But, if I enter the command "ifconfig 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 vif 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 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 > > 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 From f.rodriguez at lancaster.ac.uk Thu Aug 21 04:19:59 2008 From: f.rodriguez at lancaster.ac.uk (Francisco Rodriguez) Date: Thu, 21 Aug 2008 12:19:59 +0100 Subject: [Xorp-hackers] OSPF bug(s) in XORP-1.5 In-Reply-To: <200808210451.m7L4pP82003145@fruitcake.ICSI.Berkeley.EDU> References: Message from "Francisco Rodriguez" of "Fri, 01 Aug 2008 16:10:03 BST." <003b01c8f3e8$acbabaa0$c5e05894@lancs.local> <5934.1217975547@xorps.icir.org> <003301c8f935$cb45eec0$c5e05894@lancs.local> <200808081733.m78HWusv026148@fruitcake.ICSI.Berkeley.EDU> <000301c902fe$9bd3fd80$c5e05894@lancs.local> <200808210451.m7L4pP82003145@fruitcake.ICSI.Berkeley.EDU> Message-ID: <002901c9037f$da6b12f0$c5e05894@lancs.local> Pavlin, I'm running my experiments using virtual machines using KVM(QEMU) software which run Debian x86_64 GNU/Linux with kernel 2.6.22-3-amd64. Your statement about which is the behavior that I had observed of XORP is right. I can't recall any other important detail about my experiments that I haven't metioned before. Except, for running my experiments what I did was to configured the interfaces in system's shell and then boot XORP RTRMGR. I've to mention that I didn't configured any FEA parameter at all. Here is the output that you asked me for on previous e-mail: root at Route-Server> show interfaces eth1.12/eth1.12: Flags: 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: 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> exit Route-Server:~# ifconfig eth1.12 down Route-Server:~# ip addr 3: eth1: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 52:54:00:12:35:52 brd ff:ff:ff:ff:ff:ff inet6 fe80::5054:ff:fe12:3552/64 scope link valid_lft forever preferred_lft forever 4: eth1.3 at eth1: mtu 1500 qdisc noqueue link/ether 52:54:00:12:35:52 brd ff:ff:ff:ff:ff:ff inet 10.100.100.1/24 brd 10.100.100.255 scope global eth1.3 inet6 fe80::5054:ff:fe12:3552/64 scope link valid_lft forever preferred_lft forever 5: eth1.12 at eth1: mtu 1500 qdisc noqueue link/ether 52:54:00:12:35:52 brd ff:ff:ff:ff:ff:ff inet 192.168.1.2/24 brd 192.168.1.255 scope global eth1.12 6: eth1.13 at eth1: mtu 1500 qdisc noqueue link/ether 52:54:00:12:35:52 brd ff:ff:ff:ff:ff:ff inet 192.168.2.2/24 brd 192.168.2.255 scope global eth1.13 inet6 fe80::5054:ff:fe12:3552/64 scope link valid_lft forever preferred_lft forever Route-Server:~# /usr/local/xorp-1.5/rtrmgr/./xorpsh Welcome to XORP on Route-Server root at Route-Server> show interfaces eth1.12: Flags:<> mtu 1500 speed 100 Mbps physical index 5 ether 52:54:0:12:35:52 eth1.13/eth1.13: Flags: 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> exit Route-Server:~# ifconfig eth1.12 up Route-Server:~# ip addr 3: eth1: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 52:54:00:12:35:52 brd ff:ff:ff:ff:ff:ff inet6 fe80::5054:ff:fe12:3552/64 scope link valid_lft forever preferred_lft forever 4: eth1.3 at eth1: mtu 1500 qdisc noqueue link/ether 52:54:00:12:35:52 brd ff:ff:ff:ff:ff:ff inet 10.100.100.1/24 brd 10.100.100.255 scope global eth1.3 inet6 fe80::5054:ff:fe12:3552/64 scope link valid_lft forever preferred_lft forever 5: eth1.12 at eth1: mtu 1500 qdisc noqueue link/ether 52:54:00:12:35:52 brd ff:ff:ff:ff:ff:ff inet 192.168.1.2/24 brd 192.168.1.255 scope global eth1.12 inet6 fe80::5054:ff:fe12:3552/64 scope link valid_lft forever preferred_lft forever 6: eth1.13 at eth1: mtu 1500 qdisc noqueue link/ether 52:54:00:12:35:52 brd ff:ff:ff:ff:ff:ff inet 192.168.2.2/24 brd 192.168.2.255 scope global eth1.13 inet6 fe80::5054:ff:fe12:3552/64 scope link valid_lft forever preferred_lft forever Route-Server:~# /usr/local/xorp-1.5/rtrmgr/./xorpsh Welcome to XORP on Route-Server root at Route-Server> show interfaces eth1.12/eth1.12: Flags: mtu 1500 speed 100 Mbps inet6 fe80::5054:ff:fe12:3552 prefixlen 64 physical index 5 ether 52:54:0:12:35:52 eth1.13/eth1.13: Flags: 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 As you can see, the IP address is in kernel. Please let me know if I can provide any additional information that you think might be important. Francisco -----Original Message----- From: Pavlin Radoslavov [mailto:pavlin at ICSI.Berkeley.EDU] Sent: 21 August 2008 05:51 To: Francisco Rodriguez Cc: 'Pavlin Radoslavov'; xorp-hackers at icir.org; atanu at xorp.org Subject: Re: [Xorp-hackers] OSPF bug(s) in XORP-1.5 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 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: 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: 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: 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: 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: 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: 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: 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: 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 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 down" which effectively will cause XORP to detect a > > failure. But, if I enter the command "ifconfig 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 vif 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 down" command will definitely disable the interface. > > This is the intended behavior. See the explanation in the beginning > of this email. > > Pavlin > From pavlin at ICSI.Berkeley.EDU Fri Aug 22 10:53:58 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Fri, 22 Aug 2008 10:53:58 -0700 Subject: [Xorp-hackers] OSPF bug(s) in XORP-1.5 In-Reply-To: <002901c9037f$da6b12f0$c5e05894@lancs.local> References: Message from "Francisco Rodriguez" of "Fri, 01 Aug 2008 16:10:03 BST." <003b01c8f3e8$acbabaa0$c5e05894@lancs.local> <5934.1217975547@xorps.icir.org> <003301c8f935$cb45eec0$c5e05894@lancs.local> <200808081733.m78HWusv026148@fruitcake.ICSI.Berkeley.EDU> <000301c902fe$9bd3fd80$c5e05894@lancs.local> <200808210451.m7L4pP82003145@fruitcake.ICSI.Berkeley.EDU> <002901c9037f$da6b12f0$c5e05894@lancs.local> Message-ID: <200808221753.m7MHrwmv019541@fruitcake.ICSI.Berkeley.EDU> Francisco Rodriguez wrote: > Pavlin, > > I'm running my experiments using virtual machines using KVM(QEMU) software > which run Debian x86_64 GNU/Linux with kernel 2.6.22-3-amd64. > > Your statement about which is the behavior that I had observed of XORP is > right. I can't recall any other important detail about my experiments that I > haven't metioned before. Except, for running my experiments what I did was > to configured the interfaces in system's shell and then boot XORP RTRMGR. > I've to mention that I didn't configured any FEA parameter at all. Francisco, My only explanation for what you are seeing is that this might be a kernel-specific problem. More specifically, if the kernel is not sending the right netlink upcall messages to the FEA, the IP address information might be lost when taking a VLAN down and up. Unfortunately, I don't have a Linux system with 2.6.22 kernel to verify that. Hence, could you do the following and send me the output. In this experiment you won't need XORP. 1. Start with a configured VLAN interface that is UP and use "ip addr" to capture the output. 2. Run "ip monitor all" in the same terminal as in (1) 3. Open another terminal and become a root. 4. Use the "ifconfig" command in the second terminal to take the VLAN interface down and then up: ifconfig vlan1 down ifconfig vlan1 up 5. Stop "ip monitor" in the first terminal, and use again "ip addr" to show the interface information. Please send me the output from the first terminal: the "ip addr" output at the beginning and the end of the experiment, and the "ip monitor all" captured output. For reference purpose, below is what I get on Ubuntu-8.10 with kernel 2.6.24-19-server. Thanks, Pavlin pavlin at vm-ubuntu[5] ip addr 3: eth1: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:0c:29:c4:42:3f brd ff:ff:ff:ff:ff:ff inet 10.10.10.10/24 brd 10.10.10.255 scope global eth1 inet6 fe80::20c:29ff:fec4:423f/64 scope link valid_lft forever preferred_lft forever 5: vlan1 at eth1: mtu 1500 qdisc noqueue link/ether 00:0c:29:c4:42:3f brd ff:ff:ff:ff:ff:ff inet 10.10.20.20/24 brd 10.10.20.255 scope global vlan1 inet6 fe80::20c:29ff:fec4:423f/64 scope link tentative valid_lft forever preferred_lft forever pavlin at vm-ubuntu[6] ip monitor all 5: vlan1 at eth1: mtu 1500 qdisc noqueue link/ether 00:0c:29:c4:42:3f brd ff:ff:ff:ff:ff:ff Deleted fe80::/64 dev vlan1 metric 256 mtu 1500 advmss 1440 hoplimit 4294967295 Deleted ff00::/8 dev vlan1 table local metric 256 mtu 1500 advmss 1440 hoplimit 4294967295 Deleted 5: vlan1 inet6 fe80::20c:29ff:fec4:423f/64 scope link tentative valid_lft forever preferred_lft forever 5: vlan1 at eth1: mtu 1500 qdisc noqueue link/ether 00:0c:29:c4:42:3f brd ff:ff:ff:ff:ff:ff broadcast 10.10.20.255 dev vlan1 table local proto kernel scope link src 10.10.20.20 10.10.20.0/24 dev vlan1 proto kernel scope link src 10.10.20.20 broadcast 10.10.20.0 dev vlan1 table local proto kernel scope link src 10.10.20.20 ff00::/8 dev vlan1 table local metric 256 mtu 1500 advmss 1440 hoplimit 4294967295 fe80::/64 dev vlan1 metric 256 mtu 1500 advmss 1440 hoplimit 4294967295 5: vlan1 at eth1: mtu 1500 link/ether 00:0c:29:c4:42:3f pavlin at vm-ubuntu[7] ip addr 3: eth1: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:0c:29:c4:42:3f brd ff:ff:ff:ff:ff:ff inet 10.10.10.10/24 brd 10.10.10.255 scope global eth1 inet6 fe80::20c:29ff:fec4:423f/64 scope link valid_lft forever preferred_lft forever 5: vlan1 at eth1: mtu 1500 qdisc noqueue link/ether 00:0c:29:c4:42:3f brd ff:ff:ff:ff:ff:ff inet 10.10.20.20/24 brd 10.10.20.255 scope global vlan1 inet6 fe80::20c:29ff:fec4:423f/64 scope link tentative valid_lft forever preferred_lft forever pavlin at vm-ubuntu[8] From f.rodriguez at lancaster.ac.uk Fri Aug 22 12:24:39 2008 From: f.rodriguez at lancaster.ac.uk (Francisco Rodriguez) Date: Fri, 22 Aug 2008 20:24:39 +0100 Subject: [Xorp-hackers] OSPF bug(s) in XORP-1.5 In-Reply-To: <200808221753.m7MHrwmv019541@fruitcake.ICSI.Berkeley.EDU> References: Message from "Francisco Rodriguez" of "Fri, 01 Aug 2008 16:10:03 BST." <003b01c8f3e8$acbabaa0$c5e05894@lancs.local> <5934.1217975547@xorps.icir.org> <003301c8f935$cb45eec0$c5e05894@lancs.local> <200808081733.m78HWusv026148@fruitcake.ICSI.Berkeley.EDU> <000301c902fe$9bd3fd80$c5e05894@lancs.local> <200808210451.m7L4pP82003145@fruitcake.ICSI.Berkeley.EDU> <002901c9037f$da6b12f0$c5e05894@lancs.local> <200808221753.m7MHrwmv019541@fruitcake.ICSI.Berkeley.EDU> Message-ID: <003801c9048c$b8a2a850$c5e05894@lancs.local> Pavlin, Here is the output of your request: (I have flapped VLAN eth1.12) Route-Server:~# ip addr 1: lo: mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 52:54:00:12:35:51 brd ff:ff:ff:ff:ff:ff inet 10.0.2.15/24 brd 10.0.2.255 scope global eth0 inet6 fe80::5054:ff:fe12:3551/64 scope link valid_lft forever preferred_lft forever 3: eth1: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 52:54:00:12:35:52 brd ff:ff:ff:ff:ff:ff inet6 fe80::5054:ff:fe12:3552/64 scope link valid_lft forever preferred_lft forever 4: eth1.3 at eth1: mtu 1500 qdisc noqueue link/ether 52:54:00:12:35:52 brd ff:ff:ff:ff:ff:ff inet 10.100.100.1/24 brd 10.100.100.255 scope global eth1.3 inet6 fe80::5054:ff:fe12:3552/64 scope link valid_lft forever preferred_lft forever 5: eth1.12 at eth1: mtu 1500 qdisc noqueue link/ether 52:54:00:12:35:52 brd ff:ff:ff:ff:ff:ff inet 192.168.1.2/24 brd 192.168.1.255 scope global eth1.12 inet6 fe80::5054:ff:fe12:3552/64 scope link valid_lft forever preferred_lft forever Route-Server:~# ip monitor all 5: eth1.12 at eth1: mtu 1500 qdisc noqueue link/ether 52:54:00:12:35:52 brd ff:ff:ff:ff:ff:ff Deleted fe80::/64 dev eth1.12 metric 256 expires 21263891sec mtu 1500 advmss 1440 hoplimit 4294967295 Deleted ff00::/8 dev eth1.12 metric 256 expires 21263891sec mtu 1500 advmss 1440 hoplimit 4294967295 Deleted 5: eth1.12 inet6 fe80::5054:ff:fe12:3552/64 scope link valid_lft forever preferred_lft forever Deleted local fe80::5054:ff:fe12:3552 via :: dev lo proto none metric 0 mtu 16436 advmss 16376 hoplimit 4294967295 Deleted 5: eth1.12 at eth1: mtu 1500 link/ether 52:54:00:12:35:52 5: eth1.12 at eth1: mtu 1500 qdisc noqueue link/ether 52:54:00:12:35:52 brd ff:ff:ff:ff:ff:ff broadcast 192.168.1.255 dev eth1.12 table local proto kernel scope link src 192.168.1.2 192.168.1.0/24 dev eth1.12 proto kernel scope link src 192.168.1.2 broadcast 192.168.1.0 dev eth1.12 table local proto kernel scope link src 192.168.1.2 ff00::/8 dev eth1.12 metric 256 mtu 1500 advmss 1440 hoplimit 4294967295 fe80::/64 dev eth1.12 metric 256 mtu 1500 advmss 1440 hoplimit 4294967295 5: eth1.12 at eth1: mtu 1500 link/ether 52:54:00:12:35:52 5: eth1.12 inet6 fe80::5054:ff:fe12:3552/64 scope link valid_lft forever preferred_lft forever local fe80::5054:ff:fe12:3552 via :: dev lo proto none metric 0 mtu 16436 advmss 16376 hoplimit 4294967295 Route-Server:~# ip addr 1: lo: mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 52:54:00:12:35:51 brd ff:ff:ff:ff:ff:ff inet 10.0.2.15/24 brd 10.0.2.255 scope global eth0 inet6 fe80::5054:ff:fe12:3551/64 scope link valid_lft forever preferred_lft forever 3: eth1: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 52:54:00:12:35:52 brd ff:ff:ff:ff:ff:ff inet6 fe80::5054:ff:fe12:3552/64 scope link valid_lft forever preferred_lft forever 4: eth1.3 at eth1: mtu 1500 qdisc noqueue link/ether 52:54:00:12:35:52 brd ff:ff:ff:ff:ff:ff inet 10.100.100.1/24 brd 10.100.100.255 scope global eth1.3 inet6 fe80::5054:ff:fe12:3552/64 scope link valid_lft forever preferred_lft forever 5: eth1.12 at eth1: mtu 1500 qdisc noqueue link/ether 52:54:00:12:35:52 brd ff:ff:ff:ff:ff:ff inet 192.168.1.2/24 brd 192.168.1.255 scope global eth1.12 inet6 fe80::5054:ff:fe12:3552/64 scope link valid_lft forever preferred_lft forever Route-Server:~# Any additional information required let me know. Cheers, Francisco -----Original Message----- From: Pavlin Radoslavov [mailto:pavlin at ICSI.Berkeley.EDU] Sent: 22 August 2008 18:54 To: Francisco Rodriguez Cc: 'Pavlin Radoslavov'; xorp-hackers at icir.org; atanu at xorp.org Subject: Re: [Xorp-hackers] OSPF bug(s) in XORP-1.5 Francisco Rodriguez wrote: > Pavlin, > > I'm running my experiments using virtual machines using KVM(QEMU) software > which run Debian x86_64 GNU/Linux with kernel 2.6.22-3-amd64. > > Your statement about which is the behavior that I had observed of XORP is > right. I can't recall any other important detail about my experiments that I > haven't metioned before. Except, for running my experiments what I did was > to configured the interfaces in system's shell and then boot XORP RTRMGR. > I've to mention that I didn't configured any FEA parameter at all. Francisco, My only explanation for what you are seeing is that this might be a kernel-specific problem. More specifically, if the kernel is not sending the right netlink upcall messages to the FEA, the IP address information might be lost when taking a VLAN down and up. Unfortunately, I don't have a Linux system with 2.6.22 kernel to verify that. Hence, could you do the following and send me the output. In this experiment you won't need XORP. 1. Start with a configured VLAN interface that is UP and use "ip addr" to capture the output. 2. Run "ip monitor all" in the same terminal as in (1) 3. Open another terminal and become a root. 4. Use the "ifconfig" command in the second terminal to take the VLAN interface down and then up: ifconfig vlan1 down ifconfig vlan1 up 5. Stop "ip monitor" in the first terminal, and use again "ip addr" to show the interface information. Please send me the output from the first terminal: the "ip addr" output at the beginning and the end of the experiment, and the "ip monitor all" captured output. For reference purpose, below is what I get on Ubuntu-8.10 with kernel 2.6.24-19-server. Thanks, Pavlin pavlin at vm-ubuntu[5] ip addr 3: eth1: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:0c:29:c4:42:3f brd ff:ff:ff:ff:ff:ff inet 10.10.10.10/24 brd 10.10.10.255 scope global eth1 inet6 fe80::20c:29ff:fec4:423f/64 scope link valid_lft forever preferred_lft forever 5: vlan1 at eth1: mtu 1500 qdisc noqueue link/ether 00:0c:29:c4:42:3f brd ff:ff:ff:ff:ff:ff inet 10.10.20.20/24 brd 10.10.20.255 scope global vlan1 inet6 fe80::20c:29ff:fec4:423f/64 scope link tentative valid_lft forever preferred_lft forever pavlin at vm-ubuntu[6] ip monitor all 5: vlan1 at eth1: mtu 1500 qdisc noqueue link/ether 00:0c:29:c4:42:3f brd ff:ff:ff:ff:ff:ff Deleted fe80::/64 dev vlan1 metric 256 mtu 1500 advmss 1440 hoplimit 4294967295 Deleted ff00::/8 dev vlan1 table local metric 256 mtu 1500 advmss 1440 hoplimit 4294967295 Deleted 5: vlan1 inet6 fe80::20c:29ff:fec4:423f/64 scope link tentative valid_lft forever preferred_lft forever 5: vlan1 at eth1: mtu 1500 qdisc noqueue link/ether 00:0c:29:c4:42:3f brd ff:ff:ff:ff:ff:ff broadcast 10.10.20.255 dev vlan1 table local proto kernel scope link src 10.10.20.20 10.10.20.0/24 dev vlan1 proto kernel scope link src 10.10.20.20 broadcast 10.10.20.0 dev vlan1 table local proto kernel scope link src 10.10.20.20 ff00::/8 dev vlan1 table local metric 256 mtu 1500 advmss 1440 hoplimit 4294967295 fe80::/64 dev vlan1 metric 256 mtu 1500 advmss 1440 hoplimit 4294967295 5: vlan1 at eth1: mtu 1500 link/ether 00:0c:29:c4:42:3f pavlin at vm-ubuntu[7] ip addr 3: eth1: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:0c:29:c4:42:3f brd ff:ff:ff:ff:ff:ff inet 10.10.10.10/24 brd 10.10.10.255 scope global eth1 inet6 fe80::20c:29ff:fec4:423f/64 scope link valid_lft forever preferred_lft forever 5: vlan1 at eth1: mtu 1500 qdisc noqueue link/ether 00:0c:29:c4:42:3f brd ff:ff:ff:ff:ff:ff inet 10.10.20.20/24 brd 10.10.20.255 scope global vlan1 inet6 fe80::20c:29ff:fec4:423f/64 scope link tentative valid_lft forever preferred_lft forever pavlin at vm-ubuntu[8] From pavlin at ICSI.Berkeley.EDU Fri Aug 22 19:46:39 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Fri, 22 Aug 2008 19:46:39 -0700 Subject: [Xorp-hackers] OSPF bug(s) in XORP-1.5 In-Reply-To: <003801c9048c$b8a2a850$c5e05894@lancs.local> References: Message from "Francisco Rodriguez" of "Fri, 01 Aug 2008 16:10:03 BST." <003b01c8f3e8$acbabaa0$c5e05894@lancs.local> <5934.1217975547@xorps.icir.org> <003301c8f935$cb45eec0$c5e05894@lancs.local> <200808081733.m78HWusv026148@fruitcake.ICSI.Berkeley.EDU> <000301c902fe$9bd3fd80$c5e05894@lancs.local> <200808210451.m7L4pP82003145@fruitcake.ICSI.Berkeley.EDU> <002901c9037f$da6b12f0$c5e05894@lancs.local> <200808221753.m7MHrwmv019541@fruitcake.ICSI.Berkeley.EDU> <003801c9048c$b8a2a850$c5e05894@lancs.local> Message-ID: <200808230247.m7N2kdj8008606@fruitcake.ICSI.Berkeley.EDU> Francisco Rodriguez wrote: > Pavlin, > > Here is the output of your request: > (I have flapped VLAN eth1.12) Thank you for the detailed info. I cross-referenced it vs. the output I was getting, but I don't see anything unusual. Indeed, in your output I see some extra stuff, but I don't think this is related. To debug the problem further I see the following three options: (a) You can try a newer kernel (e.g., 2.6.24 like the one I am using). This might fix the problem only if it is in the kernel, and we don't know that yet. (b) You can try to debug the problem by me telling you where to start looking for different things. E.g., I can tell you where to start putting XLOG statements in the FEA and then try to analyze the problem and what to do next. The downside of doing this is it can be a very slow and very time consuming process. (c) If you can provide me with a temporary login access to your machine, this might be the fastest and easiest way to chase the problem. Obviously I would need root permission to run "ifconfig" to enable/disable the VLAN, but you can use various mechanisms to give me root permission for that command only (e.g., sudo or temp. setuid for the binary). If you have already another Linux box running a different kernel (older kernel is also fine), you can quickly try (a) so you don't have to update/modify the box you are using currently. I would recommend first doing (a) anyway, so we can narrow the problem. After that I'd recommend (c) so we both can save time. Only if (c) is not an option for you, we should consider (b). Pavlin > Route-Server:~# ip addr > 1: lo: mtu 16436 qdisc noqueue > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo > inet6 ::1/128 scope host > valid_lft forever preferred_lft forever > 2: eth0: mtu 1500 qdisc pfifo_fast qlen > 1000 > link/ether 52:54:00:12:35:51 brd ff:ff:ff:ff:ff:ff > inet 10.0.2.15/24 brd 10.0.2.255 scope global eth0 > inet6 fe80::5054:ff:fe12:3551/64 scope link > valid_lft forever preferred_lft forever > 3: eth1: mtu 1500 qdisc pfifo_fast qlen > 1000 > link/ether 52:54:00:12:35:52 brd ff:ff:ff:ff:ff:ff > inet6 fe80::5054:ff:fe12:3552/64 scope link > valid_lft forever preferred_lft forever > 4: eth1.3 at eth1: mtu 1500 qdisc noqueue > link/ether 52:54:00:12:35:52 brd ff:ff:ff:ff:ff:ff > inet 10.100.100.1/24 brd 10.100.100.255 scope global eth1.3 > inet6 fe80::5054:ff:fe12:3552/64 scope link > valid_lft forever preferred_lft forever > 5: eth1.12 at eth1: mtu 1500 qdisc noqueue > link/ether 52:54:00:12:35:52 brd ff:ff:ff:ff:ff:ff > inet 192.168.1.2/24 brd 192.168.1.255 scope global eth1.12 > inet6 fe80::5054:ff:fe12:3552/64 scope link > valid_lft forever preferred_lft forever > > Route-Server:~# ip monitor all > 5: eth1.12 at eth1: mtu 1500 qdisc noqueue > link/ether 52:54:00:12:35:52 brd ff:ff:ff:ff:ff:ff > Deleted fe80::/64 dev eth1.12 metric 256 expires 21263891sec mtu 1500 > advmss 1440 hoplimit 4294967295 > Deleted ff00::/8 dev eth1.12 metric 256 expires 21263891sec mtu 1500 > advmss 1440 hoplimit 4294967295 > Deleted 5: eth1.12 inet6 fe80::5054:ff:fe12:3552/64 scope link > valid_lft forever preferred_lft forever > Deleted local fe80::5054:ff:fe12:3552 via :: dev lo proto none metric 0 > mtu 16436 advmss 16376 hoplimit 4294967295 > Deleted 5: eth1.12 at eth1: mtu 1500 > link/ether 52:54:00:12:35:52 > 5: eth1.12 at eth1: mtu 1500 qdisc noqueue > link/ether 52:54:00:12:35:52 brd ff:ff:ff:ff:ff:ff > broadcast 192.168.1.255 dev eth1.12 table local proto kernel scope link > src 192.168.1.2 > 192.168.1.0/24 dev eth1.12 proto kernel scope link src 192.168.1.2 > broadcast 192.168.1.0 dev eth1.12 table local proto kernel scope link > src 192.168.1.2 > ff00::/8 dev eth1.12 metric 256 mtu 1500 advmss 1440 hoplimit 4294967295 > fe80::/64 dev eth1.12 metric 256 mtu 1500 advmss 1440 hoplimit 4294967295 > 5: eth1.12 at eth1: mtu 1500 > link/ether 52:54:00:12:35:52 > 5: eth1.12 inet6 fe80::5054:ff:fe12:3552/64 scope link > valid_lft forever preferred_lft forever > local fe80::5054:ff:fe12:3552 via :: dev lo proto none metric 0 mtu 16436 > advmss 16376 hoplimit 4294967295 > > Route-Server:~# ip addr > 1: lo: mtu 16436 qdisc noqueue > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo > inet6 ::1/128 scope host > valid_lft forever preferred_lft forever > 2: eth0: mtu 1500 qdisc pfifo_fast qlen > 1000 > link/ether 52:54:00:12:35:51 brd ff:ff:ff:ff:ff:ff > inet 10.0.2.15/24 brd 10.0.2.255 scope global eth0 > inet6 fe80::5054:ff:fe12:3551/64 scope link > valid_lft forever preferred_lft forever > 3: eth1: mtu 1500 qdisc pfifo_fast qlen > 1000 > link/ether 52:54:00:12:35:52 brd ff:ff:ff:ff:ff:ff > inet6 fe80::5054:ff:fe12:3552/64 scope link > valid_lft forever preferred_lft forever > 4: eth1.3 at eth1: mtu 1500 qdisc noqueue > link/ether 52:54:00:12:35:52 brd ff:ff:ff:ff:ff:ff > inet 10.100.100.1/24 brd 10.100.100.255 scope global eth1.3 > inet6 fe80::5054:ff:fe12:3552/64 scope link > valid_lft forever preferred_lft forever > 5: eth1.12 at eth1: mtu 1500 qdisc noqueue > link/ether 52:54:00:12:35:52 brd ff:ff:ff:ff:ff:ff > inet 192.168.1.2/24 brd 192.168.1.255 scope global eth1.12 > inet6 fe80::5054:ff:fe12:3552/64 scope link > valid_lft forever preferred_lft forever > Route-Server:~# > > Any additional information required let me know. > > Cheers, > Francisco > > -----Original Message----- > From: Pavlin Radoslavov [mailto:pavlin at ICSI.Berkeley.EDU] > Sent: 22 August 2008 18:54 > To: Francisco Rodriguez > Cc: 'Pavlin Radoslavov'; xorp-hackers at icir.org; atanu at xorp.org > Subject: Re: [Xorp-hackers] OSPF bug(s) in XORP-1.5 > > Francisco Rodriguez wrote: > > > Pavlin, > > > > I'm running my experiments using virtual machines using KVM(QEMU) software > > which run Debian x86_64 GNU/Linux with kernel 2.6.22-3-amd64. > > > > Your statement about which is the behavior that I had observed of XORP is > > right. I can't recall any other important detail about my experiments that > I > > haven't metioned before. Except, for running my experiments what I did was > > to configured the interfaces in system's shell and then boot XORP RTRMGR. > > I've to mention that I didn't configured any FEA parameter at all. > > Francisco, > > My only explanation for what you are seeing is that this might be > a kernel-specific problem. More specifically, if the kernel is not > sending the right netlink upcall messages to the FEA, the IP address > information might be lost when taking a VLAN down and up. > Unfortunately, I don't have a Linux system with 2.6.22 kernel to > verify that. > Hence, could you do the following and send me the output. > In this experiment you won't need XORP. > > 1. Start with a configured VLAN interface that is UP and use > "ip addr" to capture the output. > 2. Run "ip monitor all" in the same terminal as in (1) > 3. Open another terminal and become a root. > 4. Use the "ifconfig" command in the second terminal to take the > VLAN interface down and then up: > ifconfig vlan1 down > ifconfig vlan1 up > 5. Stop "ip monitor" in the first terminal, and use again > "ip addr" to show the interface information. > > Please send me the output from the first terminal: > the "ip addr" output at the beginning and the end of the experiment, > and the "ip monitor all" captured output. > > For reference purpose, below is what I get on Ubuntu-8.10 with > kernel 2.6.24-19-server. > > Thanks, > Pavlin > > pavlin at vm-ubuntu[5] ip addr > > 3: eth1: mtu 1500 qdisc pfifo_fast qlen > 1000 > link/ether 00:0c:29:c4:42:3f brd ff:ff:ff:ff:ff:ff > inet 10.10.10.10/24 brd 10.10.10.255 scope global eth1 > inet6 fe80::20c:29ff:fec4:423f/64 scope link > valid_lft forever preferred_lft forever > 5: vlan1 at eth1: mtu 1500 qdisc noqueue > link/ether 00:0c:29:c4:42:3f brd ff:ff:ff:ff:ff:ff > inet 10.10.20.20/24 brd 10.10.20.255 scope global vlan1 > inet6 fe80::20c:29ff:fec4:423f/64 scope link tentative > valid_lft forever preferred_lft forever > pavlin at vm-ubuntu[6] ip monitor all > 5: vlan1 at eth1: mtu 1500 qdisc noqueue > link/ether 00:0c:29:c4:42:3f brd ff:ff:ff:ff:ff:ff > Deleted fe80::/64 dev vlan1 metric 256 mtu 1500 advmss 1440 hoplimit > 4294967295 > Deleted ff00::/8 dev vlan1 table local metric 256 mtu 1500 advmss 1440 > hoplimit 4294967295 > Deleted 5: vlan1 inet6 fe80::20c:29ff:fec4:423f/64 scope link tentative > valid_lft forever preferred_lft forever > 5: vlan1 at eth1: mtu 1500 qdisc noqueue > link/ether 00:0c:29:c4:42:3f brd ff:ff:ff:ff:ff:ff > broadcast 10.10.20.255 dev vlan1 table local proto kernel scope link src > 10.10.20.20 > 10.10.20.0/24 dev vlan1 proto kernel scope link src 10.10.20.20 > broadcast 10.10.20.0 dev vlan1 table local proto kernel scope link src > 10.10.20.20 > ff00::/8 dev vlan1 table local metric 256 mtu 1500 advmss 1440 hoplimit > 4294967295 > fe80::/64 dev vlan1 metric 256 mtu 1500 advmss 1440 hoplimit 4294967295 > 5: vlan1 at eth1: mtu 1500 > link/ether 00:0c:29:c4:42:3f > > pavlin at vm-ubuntu[7] ip addr > > 3: eth1: mtu 1500 qdisc pfifo_fast qlen > 1000 > link/ether 00:0c:29:c4:42:3f brd ff:ff:ff:ff:ff:ff > inet 10.10.10.10/24 brd 10.10.10.255 scope global eth1 > inet6 fe80::20c:29ff:fec4:423f/64 scope link > valid_lft forever preferred_lft forever > 5: vlan1 at eth1: mtu 1500 qdisc noqueue > link/ether 00:0c:29:c4:42:3f brd ff:ff:ff:ff:ff:ff > inet 10.10.20.20/24 brd 10.10.20.255 scope global vlan1 > inet6 fe80::20c:29ff:fec4:423f/64 scope link tentative > valid_lft forever preferred_lft forever > pavlin at vm-ubuntu[8] > > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From eshe168 at gmail.com Wed Aug 27 22:24:02 2008 From: eshe168 at gmail.com (=?GB2312?B?0e7Qocun?=) Date: Thu, 28 Aug 2008 13:24:02 +0800 Subject: [Xorp-hackers] about "commit" command! Message-ID: <56f9e0990808272224l790f1688ndee981432d17e891@mail.gmail.com> Hi, I found someting wrong in the RouterCLI::commit_func(). That is :string cmd_name = token_vector2line(command_global_name); But, I found the cmd_name is the empty string. please chech it. B.R. Xiaoshuai Yang From pavlin at ICSI.Berkeley.EDU Thu Aug 28 11:52:15 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Thu, 28 Aug 2008 11:52:15 -0700 Subject: [Xorp-hackers] about "commit" command! In-Reply-To: <56f9e0990808272224l790f1688ndee981432d17e891@mail.gmail.com> References: <56f9e0990808272224l790f1688ndee981432d17e891@mail.gmail.com> Message-ID: <200808281852.m7SIqFUY025404@fruitcake.ICSI.Berkeley.EDU> ??? wrote: > Hi, > > I found someting wrong in the RouterCLI::commit_func(). > > That is :string cmd_name = token_vector2line(command_global_name); > > But, I found the cmd_name is the empty string. > > please chech it. Bug fixed in CVS: Revision Changes Path 1.141 +9 -1; commitid: 265748b6f21241a7; xorp/rtrmgr/cli.cc Thanks, Pavlin > B.R. > Xiaoshuai Yang > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From greearb at candelatech.com Fri Aug 29 11:07:02 2008 From: greearb at candelatech.com (Ben Greear) Date: Fri, 29 Aug 2008 11:07:02 -0700 Subject: [Xorp-hackers] Question on remove interface error Message-ID: <48B83AC6.70004@candelatech.com> For some reason, my logic to remove interface config from xorp is failing. I'm not sure why yet, but in the end, I have this in one of the routers. The kernel no longer has most of these interfaces, which is why they are , I assume. root at wiser-2> show interfaces 2.3.2/2.3.2: Flags: mtu 1500 speed unknown inet 10.2.3.2 subnet 10.2.3.0/24 broadcast 10.2.3.255 physical index 136 ether 0:d0:a8:a5:9d:77 2.5.2/2.5.2: Flags: mtu 1500 speed unknown inet 10.2.5.2 subnet 10.2.5.0/24 broadcast 10.2.5.255 physical index 132 ether 0:13:de:5a:d2:c5 2.8.2/2.8.2: Flags: mtu 1500 speed unknown inet 10.2.8.2 subnet 10.2.8.0/24 broadcast 10.2.8.255 physical index 128 ether 0:4f:10:29:ad:cd 2.9.2/2.9.2: Flags: mtu 1500 speed unknown inet 10.2.9.2 subnet 10.2.9.0/24 broadcast 10.2.9.255 physical index 124 ether 0:3d:bd:ad:a5:a br2/br2: Flags: mtu 1500 speed unknown inet 10.2.2.2 subnet 10.2.2.0/24 broadcast 10.2.2.255 physical index 67 ether 0:71:8a:89:cd:9a my_discard/my_discard: Flags: mtu 0 speed unknown physical index 0 root at wiser-2> But, when I try to remove one of them (2.9.2), I get errors about 2.3.2 and 2.9.2 is not removed. This might be because of my own modifications, but if someone has any ideas, they are welcome! [root at wiser-2 lanforge]# xorpsh -c configure -c "delete protocols igmp interface 2.9.2" -c "delete protocols pimsm4 interface 2.9.2" -c "delete plumbing mfea4 interface 2.9.2" -c "delete protocols ospf4 area 0.0.0.0 interface 2.9.2" -c "delete interfaces interface 2.9.2" -c commit -c exit -c exit Welcome to XORP on wiser-2 root at wiser-2> configure Entering configuration mode. There are no other users in configuration mode. [edit] root at wiser-2# delete protocols igmp interface 2.9.2 Deleting: 2.9.2 { vif "2.9.2" { } } OK [edit] root at wiser-2# delete protocols pimsm4 interface 2.9.2 Deleting: 2.9.2 { vif "2.9.2" { dr-priority: 125 } } OK [edit] root at wiser-2# delete plumbing mfea4 interface 2.9.2 Deleting: 2.9.2 { vif "2.9.2" { } } OK [edit] root at wiser-2# delete protocols ospf4 area 0.0.0.0 interface 2.9.2 Deleting: 2.9.2 { vif "2.9.2" { address 10.2.9.2 { } } } OK [edit] root at wiser-2# delete interfaces interface 2.9.2 Deleting: 2.9.2 { vif "2.9.2" { address 10.2.9.2 { prefix-length: 24 } } } OK [edit] root at wiser-2# commit Commit Failed 102 Command failed Interface error on 2.3.2: interface not recognized[edit] root at wiser-2# exit ERROR: There are uncommitted changes. Use "commit" to commit the changes, or "exit discard" to discard them. root at wiser-2# exit ERROR: There are uncommitted changes. Use "commit" to commit the changes, or "exit discard" to discard them. root at wiser-2# [root at wiser-2 lanforge]# -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Fri Aug 29 12:26:02 2008 From: greearb at candelatech.com (Ben Greear) Date: Fri, 29 Aug 2008 12:26:02 -0700 Subject: [Xorp-hackers] Question on remove interface error In-Reply-To: <48B83AC6.70004@candelatech.com> References: <48B83AC6.70004@candelatech.com> Message-ID: <48B84D4A.4030504@candelatech.com> Ben Greear wrote: > For some reason, my logic to remove interface config from xorp > is failing. I'm not sure why yet, but in the end, I have this > in one of the routers. The kernel no longer has most of these interfaces, > which is why they are , I assume. I'm thinking this may be mostly related to my own changes to fea. There seems to be some confusion in fea about what interfaces are configured v/s what actually exist in the OS, probably because the xorpsh commands to remove interfaces happen after fea notices that the interface is deleted in the OS. I'll continue poking at this.... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com