From jonirucoeith at gmail.com Tue Oct 2 13:21:55 2007 From: jonirucoeith at gmail.com (Jon) Date: Tue, 2 Oct 2007 22:21:55 +0200 Subject: [Xorp-hackers] Problems with ppp Message-ID: <471f67780710021321m28983e59tea37ed6ce1f6b4f0@mail.gmail.com> Hello, I have a setup where I use ppp towards an external satcom device. As long as the satcom unit is powered up, all is well, the ppp interface is recognised by XORP. BUT, if I turn it off... problems arise. The ppp device is removed from the system, and XORP removes the vif associated. When I turn the satcom back on again, the ppp interface is re-established, BUT it gets a new interface index. XORP does not seem to take any notice of it. Has anybody solved this? Either by making the ppp device permanent, or by getting the XORP to re-discover the interface? Thanks in advance, Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20071002/e8915299/attachment.html From greearb at candelatech.com Tue Oct 2 18:58:58 2007 From: greearb at candelatech.com (Ben Greear) Date: Tue, 02 Oct 2007 18:58:58 -0700 Subject: [Xorp-hackers] How to debug OSPF interface migration? Message-ID: <4702F762.10905@candelatech.com> I'm still trying to get interface add/deletion working with OSPF. First, my initial setup is router '8' connected to router 1 and router 1 connected to router 2. These are the only 3 OSPF routers running. The router-id is calculated as: 127.1.0.[router-id], for reference. When I first start the routers, they negotiate up and seem to work fine. However, when I migrate the link from 8 - 1 to 8 - 2, it no longer works. It seems that router 8 still thinks it is talking to router 1 (notice the ID that it thinks it is Loading). I migrate the links with commands like: # remove interface from router 1 configure delete protocols ospf4 area 0.0.0.0 interface rddVR44 commit delete interfaces interface rddVR44 commit exit exit # Add interface to router 2 configure set interfaces interface rddVR44 vif rddVR44 address 10.4.0.7 prefix-length 24 commit set protocols ospf4 area 0.0.0.0 interface rddVR44 vif rddVR44 address 10.4.0.7 interface-cost 1 commit exit exit # This 'resets' a port in router 2, in this case it isn't really making changes # but my code is a bit lazy currently. I think Xorp is smarter # doesn't actually do anything. configure delete interfaces interface rddVR45 vif rddVR45 set interfaces interface rddVR45 vif rddVR45 address 10.4.0.2 prefix-length 24 commit delete protocols ospf4 area 0.0.0.0 interface rddVR45 vif rddVR45 set protocols ospf4 area 0.0.0.0 interface rddVR45 vif rddVR45 address 10.4.0.2 commit exit exit When this is complete, it seems router-8 still thinks it is connected to router 1, but it is really connected to router 2. According to router 2, router 8 is in 'Init' mode. [root at lanforge-33-46 lanforge]# export XORP_FINDER_SERVER_PORT=20008; xorpsh Welcome to XORP on lanforge-33-46 root at lanforge-33-46> show ospf4 neighbor Address Interface State ID Pri Dead 10.4.0.7 rddVR45/rddVR45 Loading 127.1.0.1 128 35 root at lanforge-33-46> quit [root at lanforge-33-46 lanforge]# export XORP_FINDER_SERVER_PORT=20002; xorpsh Welcome to XORP on lanforge-33-46 root at lanforge-33-46> show ospf4 neighbor Address Interface State ID Pri Dead 10.0.0.2 rddVR0/rddVR0 Full 127.1.0.1 128 38 10.4.0.2 rddVR44/rddVR44 Init 127.1.0.8 128 38 root at lanforge-33-46> quit [root at lanforge-33-46 lanforge]# export XORP_FINDER_SERVER_PORT=20001; xorpsh Welcome to XORP on lanforge-33-46 root at lanforge-33-46> show ospf4 neighbor Address Interface State ID Pri Dead 10.0.0.1 rddVR1/rddVR1 Full 127.1.0.2 128 31 I'm not to sure how to debug this farther, so please let me know if you want logs, packet traces, etc. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From arjun at ceeyes.com Tue Oct 2 21:08:51 2007 From: arjun at ceeyes.com (arjun at ceeyes.com) Date: Wed, 3 Oct 2007 00:08:51 -0400 Subject: [Xorp-hackers] xorp-rip Message-ID: <380-22007103348519@M2W010.mail2web.com> Hi all! I want to understand completely and custumize the xorp-rip source code according to my needs so plz guide me and give detailed steps in order to do it. Regards, Arjun -------------------------------------------------------------------- mail2web.com ? What can On Demand Business Solutions do for you? http://link.mail2web.com/Business/SharePoint From arjun at ceeyes.com Tue Oct 2 21:10:15 2007 From: arjun at ceeyes.com (arjun at ceeyes.com) Date: Wed, 3 Oct 2007 00:10:15 -0400 Subject: [Xorp-hackers] xorp-rip Message-ID: <380-22007103341015744@M2W007.mail2web.com> Hi all! I want to understand completely and custumize the xorp-rip source code according to my needs so plz guide me and give detailed steps in order to do it. Regards, Arjun -------------------------------------------------------------------- mail2web.com ? Enhanced email for the mobile individual based on Microsoft? Exchange - http://link.mail2web.com/Personal/EnhancedEmail From arjun at ceeyes.com Tue Oct 2 22:36:23 2007 From: arjun at ceeyes.com (arjun at ceeyes.com) Date: Wed, 3 Oct 2007 01:36:23 -0400 Subject: [Xorp-hackers] xorp-simulator Message-ID: <380-22007103353623370@M2W039.mail2web.com> Hi 2 all! Is there any simulator for xorp. Regards Arjun -------------------------------------------------------------------- mail2web.com - Microsoft? Exchange solutions from a leading provider - http://link.mail2web.com/Business/Exchange From luca.giraudo at gmail.com Wed Oct 3 06:40:15 2007 From: luca.giraudo at gmail.com (Luca Giraudo) Date: Wed, 3 Oct 2007 15:40:15 +0200 Subject: [Xorp-hackers] Multicast Programming Message-ID: <33404c390710030640y1e6dbb35s3317e5d43a6a8357@mail.gmail.com> I have a PC with 2 ethernet cards and I want to receive multicast packets from both the cards: so I have to bind the UDP socket to every IP address on the PC (10.1.0.39 and 192.168.0.1). I try to do: ... const IPv4 local_addr = IPv4Constants::any //equivalent to INADDR_ANY _xrl_socket4_client.send_udp_open_bind_join(_socket4_target.c_str(), xrl_router().instance_name(), local_addr, default_udp_port, default_multicast_group, ttl, reuse, callback(this, &XrlPolidistNode::send_udp_open_bind_join_cb)); ... The error from rtrmgr is this: [ 2007/10/03 14:12:11 WARNING xorp_fea XrlFeaTarget ] Handling method for socket4/0.1/udp_open_bind_join failed: XrlCmdError 102 Command failed Cannot open, bind and join an UDP socket to address ZERO: the address must belong to a local interface The solution to this problem is to bind to a specific ipv4 address (I bind to 10.1.0.39), but if I bind the socket on a specific address I can't receive multicast packets from the other card, also when I join the multicast group on this interface. In the end, I try also to bind the same socket on both the addresses, but the second time there is an error, probably because it's possible to call once the bind on the same socket. Someone could help me? Thanks, Luca Giraudo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20071003/a7c0ed17/attachment.html From xonia10 at yahoo.es Wed Oct 3 07:53:48 2007 From: xonia10 at yahoo.es (Sonia) Date: Wed, 3 Oct 2007 16:53:48 +0200 (CEST) Subject: [Xorp-hackers] Xorp for embedded applications Message-ID: <230496.40969.qm@web23110.mail.ird.yahoo.com> Hi all, Recently I wrote to this list asking for help to reduce the size of xorp binaries in order to make them fit in an embedded platform. http://mailman.icsi.berkeley.edu/pipermail/xorp-hackers/2007-September/001180.html First of all, thank you Pavlin for your quick answer! As said in the previous post, we only need some functionalities of xorp. Specifically we want to implement the feature of multicast router, so as Pavlin said, we need only some of the binaries of xorp (xorp_igmp, xorp_finder, xorp_fea and the template files). We don't mind to have few binaries in our system, but the size of them is prohibitive (We have 4MB of Flash). For example, we've tried disabling IPv6, but adding the compilation flag doesn't remove all the functions related to IPv6 and the size is not reduced. We think also that it could be very interesting to use shared libraries, or to have the choice to make a single binary with the selected features. Obviously we focus on embedded world. I don't know if there is some work on this. Although we would like to contribute to it, unfortunatly we don't have time. To sum up, we ask for ideas to reduce the size of the binaries or if anyone is interested in doing this work we're considering to make a donation. Please, any suggestion will be welcome!! Thank you very much for your attention!! Best regards, Sonia ____________________________________________________________________________________ S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html From greearb at candelatech.com Wed Oct 3 10:14:22 2007 From: greearb at candelatech.com (Ben Greear) Date: Wed, 03 Oct 2007 10:14:22 -0700 Subject: [Xorp-hackers] Xorp for embedded applications In-Reply-To: <230496.40969.qm@web23110.mail.ird.yahoo.com> References: <230496.40969.qm@web23110.mail.ird.yahoo.com> Message-ID: <4703CDEE.4080109@candelatech.com> Sonia wrote: > Hi all, > > Recently I wrote to this list asking for help to > reduce the size of xorp binaries in order to make them > fit in an embedded platform. > > http://mailman.icsi.berkeley.edu/pipermail/xorp-hackers/2007-September/001180.html > > First of all, thank you Pavlin for your quick answer! > > As said in the previous post, we only need some > functionalities of xorp. Specifically we want to > implement the feature of multicast router, so as > Pavlin said, we need only some of the binaries of xorp > (xorp_igmp, xorp_finder, xorp_fea and the template > files). > > We don't mind to have few binaries in our system, but > the size of them is prohibitive (We have 4MB of > Flash). For example, we've tried disabling IPv6, but > adding the compilation flag doesn't remove all the > functions related to IPv6 and the size is not reduced. > > We think also that it could be very interesting to use > shared libraries, or to have the choice to make a > single binary with the selected features. Obviously we > focus on embedded world. > > I don't know if there is some work on this. Although > we would like to contribute to it, unfortunatly we > don't have time. > > To sum up, we ask for ideas to reduce the size of the > binaries or if anyone is interested in doing this work > we're considering to make a donation. Once you strip the executables and use shared libraries, I think if you want to make it smaller, you'll need to start modifying code. Xorp uses lots of templates and these tend to bloat executable size. You might be able to replace some of the template code with regular classes. There is also a lot of mostly trivial classes..like for each of the xlr commands (I think that terminology is right). These classes could be re-written to become methods of a larger class. You could remove much of the inline implementations in header files and move that to .cc files. This is generally trivial work that does not require a real understanding of the code. The stl, especially the string class, does much of it's work inline as well. If you replace the string class with something simpler that does not inline everything, you will likely save a lot of space. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Wed Oct 3 11:39:18 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 03 Oct 2007 11:39:18 -0700 Subject: [Xorp-hackers] Problems with ppp In-Reply-To: Message from Jon of "Tue, 02 Oct 2007 22:21:55 +0200." <471f67780710021321m28983e59tea37ed6ce1f6b4f0@mail.gmail.com> Message-ID: <200710031839.l93IdIY2020345@possum.icir.org> > I have a setup where I use ppp towards an external satcom device. > > As long as the satcom unit is powered up, all is well, the ppp interface is > recognised by XORP. > > BUT, if I turn it off... problems arise. The ppp device is removed from the > system, and XORP removes the vif associated. > > When I turn the satcom back on again, the ppp interface is re-established, > BUT it gets a new interface index. > > XORP does not seem to take any notice of it. > > Has anybody solved this? Either by making the ppp device permanent, or by > getting the XORP to re-discover the interface? There are some known issues when it comes to the FEA to pick-up changes that come from beneath it (i.e., the kernel). We are in the process of addressing those issues. To help us with the testing, could you send your original configuration (the "interfaces" section only should be sufficient). Feel free to mask sensitive information like IP addresses. Also, could you tell us what OS are you using. It will be great if you send some instructions how to emulate the deletion/re-eestablishment of the ppp interface by using some UNIX commands. In the mean time, if you have an external mechanism (i.e., outside XORP) to detect that the ppp interface is deleted, you could try to use that mechanism to run a script. That script should use xorpsh to reconfigure XORP by explicitly deleting and then explicitly creating the ppp interface inside the XORP configuration. Hopefully this will help XORP to pick-up the right interface index. Thanks, Pavlin From pavlin at icir.org Wed Oct 3 11:53:08 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 03 Oct 2007 11:53:08 -0700 Subject: [Xorp-hackers] xorp-rip In-Reply-To: Message from "arjun@ceeyes.com" of "Wed, 03 Oct 2007 00:08:51 EDT." <380-22007103348519@M2W010.mail2web.com> Message-ID: <200710031853.l93Ir8Wu020534@possum.icir.org> arjun at ceeyes.com wrote: > > Hi all! > > I want to understand completely and custumize the xorp-rip source code > according to my needs > so plz guide me and give detailed steps in order to do it. In general, the XORP Web site has a number of design documents that can help you to start with the XORP architecture. The XORP User Manual provides information about how to configure XORP (incl. RIP). If you want to "understand completely and custumize the xorp-rip source code", you need to dive into the source code itself :) Hope that helps, Pavlin From pavlin at icir.org Wed Oct 3 12:12:32 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 03 Oct 2007 12:12:32 -0700 Subject: [Xorp-hackers] xorp-simulator In-Reply-To: Message from "arjun@ceeyes.com" of "Wed, 03 Oct 2007 01:36:23 EDT." <380-22007103353623370@M2W039.mail2web.com> Message-ID: <200710031912.l93JCWZA020795@possum.icir.org> arjun at ceeyes.com wrote: > Hi 2 all! > > Is there any simulator for xorp. No, but we hope to have one in the future (it is on our TODO list). Regards, Pavlin From pavlin at icir.org Wed Oct 3 12:31:05 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 03 Oct 2007 12:31:05 -0700 Subject: [Xorp-hackers] Multicast Programming In-Reply-To: Message from "Luca Giraudo" of "Wed, 03 Oct 2007 15:40:15 +0200." <33404c390710030640y1e6dbb35s3317e5d43a6a8357@mail.gmail.com> Message-ID: <200710031931.l93JV5gS021082@possum.icir.org> Luca Giraudo wrote: > I have a PC with 2 ethernet cards and I want to receive multicast packets > from both the cards: so I have to bind the UDP socket to every IP address on > the PC (10.1.0.39 and 192.168.0.1). > > I try to do: > > ... > > const IPv4 local_addr = IPv4Constants::any //equivalent to INADDR_ANY > > _xrl_socket4_client.send_udp_open_bind_join(_socket4_target.c_str(), > xrl_router().instance_name(), > local_addr, default_udp_port, default_multicast_group, ttl, > reuse, > callback(this, > &XrlPolidistNode::send_udp_open_bind_join_cb)); > > > ... > > The error from rtrmgr is this: > > [ 2007/10/03 14:12:11 WARNING xorp_fea XrlFeaTarget ] Handling method for > socket4/0.1/udp_open_bind_join failed: XrlCmdError 102 Command failed Cannot > open, bind and join an UDP socket to address ZERO: the address must belong > to a local interface > > The solution to this problem is to bind to a specific ipv4 address (I bind > to 10.1.0.39), but if I bind the socket on a specific address I can't > receive multicast packets from the other card, also when I join the > multicast group on this interface. > > In the end, I try also to bind the same socket on both the addresses, but > the second time there is an error, probably because it's possible to call > once the bind on the same socket. > > Someone could help me? If we ignore XORP for a moment, the UNIX multicast semantics are that when you join a multicast group, you have to specify the interface to join (in IPv4 the interface is specified by one of its IP addresses; in IPv6 the interface index is used to specify it). In other words, there is no "wildcard" API mechanism to join all interfaces at the same time. The XORP XRL API is similar in that aspect, so yes you need to join explicitly on each interface. The difference is that the XORP API combines several system operations together, so from your protocol's perspective they appear atomic. E.g., udp_open_and_bind will open the socket and bind it to an address. In your case what you can do is: * Use udp_open_and_bind to open the socket and bind it to ANY. BTW, I would recommend to use IPv4::ZERO() or IPv4::ANY() instead of IPv4Constants::any. They are the same thing, but it is just question of being consistent with the rest of the XORP code. * Use udp_join_group to join the same multicast group on each interface you need. Please let me know if it doesn't work for you. Regards, Pavlin From pavlin at icir.org Wed Oct 3 15:02:31 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 03 Oct 2007 15:02:31 -0700 Subject: [Xorp-hackers] Xorp for embedded applications In-Reply-To: Message from Ben Greear of "Wed, 03 Oct 2007 10:14:22 PDT." <4703CDEE.4080109@candelatech.com> Message-ID: <200710032202.l93M2VBu022523@possum.icir.org> Ben Greear wrote: > Sonia wrote: > > Hi all, > > > > Recently I wrote to this list asking for help to > > reduce the size of xorp binaries in order to make them > > fit in an embedded platform. > > > > http://mailman.icsi.berkeley.edu/pipermail/xorp-hackers/2007-September/001180.html > > > > First of all, thank you Pavlin for your quick answer! > > > > As said in the previous post, we only need some > > functionalities of xorp. Specifically we want to > > implement the feature of multicast router, so as > > Pavlin said, we need only some of the binaries of xorp > > (xorp_igmp, xorp_finder, xorp_fea and the template > > files). This is off-topic, but I should clarify it here: If I remember correctly, in your original email you said you need IGMP. If you need "multicast router", then you need to add xorp_pimsm4 as well. Binary xorp_igmp implements the router-side of IGMP, but this itself is not useful. > > We don't mind to have few binaries in our system, but > > the size of them is prohibitive (We have 4MB of > > Flash). For example, we've tried disabling IPv6, but > > adding the compilation flag doesn't remove all the > > functions related to IPv6 and the size is not reduced. > > > > We think also that it could be very interesting to use > > shared libraries, or to have the choice to make a > > single binary with the selected features. Obviously we > > focus on embedded world. > > > > I don't know if there is some work on this. Although > > we would like to contribute to it, unfortunatly we > > don't have time. > > > > To sum up, we ask for ideas to reduce the size of the > > binaries or if anyone is interested in doing this work > > we're considering to make a donation. > > Once you strip the executables and use shared libraries, > I think if you want to make it smaller, you'll need > to start modifying code. Xorp uses lots of templates > and these tend to bloat executable size. You > might be able to replace some of the template code > with regular classes. > > There is also a lot of mostly trivial classes..like for > each of the xlr commands (I think that terminology is right). > > These classes could be re-written to become methods of a larger class. > > You could remove much of the inline implementations in header files > and move that to .cc files. This is generally trivial work that does > not require a real understanding of the code. > > The stl, especially the string class, does much of it's work inline > as well. If you replace the string class with something simpler > that does not inline everything, you will likely save a lot of space. > > Thanks, > Ben I should mention first that originally when we started XORP we weren't looking into the embedded device space. Hence, so far the optimization of the binary executable size and the process runtime size haven't been priority. You could try experimenting with Ben's suggestions above, and myself I would be interested to know how much each of them makes difference. In addition, you could try various C/C++ compiler flags to see whether any of them will help. For example, there are some gcc flags related to inlined code. -fno-implicit-inline-templates -fno-implement-inlines -fno-default-inline -fno-inline Check the gcc/g++ manual page whether any of them are applicable. It might be worth reading the whole manual page to see if there are any other candidates. Before doing so you might want to try first the latest code from CVS and to see whether the (refactored) FEA is smaller than the FEA from XORP-1.4. There might not be any notable difference (or the size could be worse), but is worth trying it. Nevertheless, we are (slowly) changing things in the direction of reducing the binary size. For example, we intend to start using shared libraries (at least for the FEA), but we haven't done that yet. In any case we need to perform more systematic audition of the code to address the memory size issues. Good luck! Pavlin From greearb at candelatech.com Wed Oct 3 16:17:54 2007 From: greearb at candelatech.com (Ben Greear) Date: Wed, 03 Oct 2007 16:17:54 -0700 Subject: [Xorp-hackers] Some patches for various things. Message-ID: <47042322.8090203@candelatech.com> Here are some more small patches. At some time during the last few weeks I added these to try to work around problems related to dynamically adding/deleting interfaces & ospf configuration. It's possible subsequent fixes from Xorp developers have made these un-needed. Treat a duplicate remove as OK instead of an error. This fixed some problem with reloading config files... RCS file: /cvs/xorp/fea/iftree.cc,v retrieving revision 1.51 diff -u -r1.51 iftree.cc --- fea/iftree.cc 27 Sep 2007 00:33:33 -0000 1.51 +++ fea/iftree.cc 3 Oct 2007 23:08:13 -0000 @@ -1079,7 +1079,7 @@ IfTreeAddr4* ap = find_addr(addr); if (ap == NULL) - return (XORP_ERROR); + return XORP_OK; // Already deleted it seems... (XORP_ERROR); ap->mark(DELETED); return (XORP_OK); } I prefer the log files to show the locations as file:line instead of the old +line format. RCS file: /cvs/xorp/libxorp/xlog.h,v retrieving revision 1.16 diff -u -r1.16 xlog.h --- libxorp/xlog.h 20 Apr 2007 19:06:21 -0000 1.16 +++ libxorp/xlog.h 3 Oct 2007 23:08:14 -0000 @@ -101,8 +101,8 @@ #define XLOG_FN(fn, fmt...) \ do { \ char xlog_where_buf[8000]; \ - snprintf(xlog_where_buf, sizeof(xlog_where_buf), "+%d %s %s", \ - __LINE__, __FILE__, __FUNCTION__); \ + snprintf(xlog_where_buf, sizeof(xlog_where_buf), "%s:%d %s", \ + __FILE__, __LINE__, __FUNCTION__); \ xlog_##fn(_XLOG_MODULE_NAME, xlog_where_buf, fmt); \ } while (0) This fixed an error in ospf. I don't know if this is still needed, or even if it was ever the right thing to do. Perhaps the OSPF folks could take a look and this... RCS file: /cvs/xorp/ospf/peer_manager.cc,v retrieving revision 1.146 diff -u -r1.146 peer_manager.cc --- ospf/peer_manager.cc 3 Oct 2007 21:23:53 -0000 1.146 +++ ospf/peer_manager.cc 3 Oct 2007 23:08:16 -0000 @@ -369,9 +369,12 @@ debug_msg("Interface %s Vif %s\n", interface.c_str(), vif.c_str()); string concat = interface + "/" + vif; - if (0 != _pmap.count(concat)) - xorp_throw(BadPeer, - c_format("Mapping for %s already exists", concat.c_str())); + if (0 != _pmap.count(concat)) { + // Don't think we really need to error here, just return what we already have. --Ben + //xorp_throw(BadPeer, + // c_format("Mapping for %s already exists", concat.c_str())); + return _pmap[concat]; + } OspfTypes::PeerID peerid = _next_peerid++; _pmap[concat] = peerid; Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Wed Oct 3 17:52:26 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 03 Oct 2007 17:52:26 -0700 Subject: [Xorp-hackers] Some patches for various things. In-Reply-To: Message from Ben Greear of "Wed, 03 Oct 2007 16:17:54 PDT." <47042322.8090203@candelatech.com> Message-ID: <200710040052.l940qQGm033941@possum.icir.org> Ben Greear wrote: > Here are some more small patches. At some time during the last > few weeks I added these to try to work around problems related to > dynamically adding/deleting interfaces & ospf configuration. It's > possible subsequent fixes from Xorp developers have made these un-needed. > > > Treat a duplicate remove as OK instead of an error. > This fixed some problem with reloading config files... > > RCS file: /cvs/xorp/fea/iftree.cc,v > retrieving revision 1.51 > diff -u -r1.51 iftree.cc > --- fea/iftree.cc 27 Sep 2007 00:33:33 -0000 1.51 > +++ fea/iftree.cc 3 Oct 2007 23:08:13 -0000 > @@ -1079,7 +1079,7 @@ > IfTreeAddr4* ap = find_addr(addr); > > if (ap == NULL) > - return (XORP_ERROR); > + return XORP_OK; // Already deleted it seems... (XORP_ERROR); > ap->mark(DELETED); > return (XORP_OK); > } This is a question of semantics. Currently, trying to delete an IfTree item (interface, vif and IP address) that doesn't exist is considered an error. Some of the usage of this is to capture errors/bugs elsewhere in the code. Could you send instructions how to replicate the problem with reloading config files. Only then we can debug the issue and see whether the real problem is somewhere else or whether it really requires change of semantics. Yes, there were some recent fixes to the FEA regarding modifying the interface configuration, but there are no guarantees they actually addressed the problem you had seen before. > I prefer the log files to show the locations as file:line > instead of the old +line format. > > RCS file: /cvs/xorp/libxorp/xlog.h,v > retrieving revision 1.16 > diff -u -r1.16 xlog.h > --- libxorp/xlog.h 20 Apr 2007 19:06:21 -0000 1.16 > +++ libxorp/xlog.h 3 Oct 2007 23:08:14 -0000 > @@ -101,8 +101,8 @@ > #define XLOG_FN(fn, fmt...) \ > do { \ > char xlog_where_buf[8000]; \ > - snprintf(xlog_where_buf, sizeof(xlog_where_buf), "+%d %s %s", \ > - __LINE__, __FILE__, __FUNCTION__); \ > + snprintf(xlog_where_buf, sizeof(xlog_where_buf), "%s:%d %s", \ > + __FILE__, __LINE__, __FUNCTION__); \ > xlog_##fn(_XLOG_MODULE_NAME, xlog_where_buf, fmt); \ > } while (0) The reason the log message has the format "+line file" is that you can cut-and-paste and open directly the file in an editor like emacs or vi. E.g.: emacs +101 libxorp/xlog.h OR vi +101 libxorp/xlog.h will open and show directly the above code. [Cudos to Orion Hodson for adding this nifty trick which I didn't know before :)] Could you provide an example when the "file:line" format can be useful (apart of probably looking more aesthetic :) ) I will leave the OSPF patch to Atanu. Thanks, Pavlin > > This fixed an error in ospf. I don't know if this is still needed, > or even if it was ever the right thing to do. Perhaps the OSPF > folks could take a look and this... > > RCS file: /cvs/xorp/ospf/peer_manager.cc,v > retrieving revision 1.146 > diff -u -r1.146 peer_manager.cc > --- ospf/peer_manager.cc 3 Oct 2007 21:23:53 -0000 1.146 > +++ ospf/peer_manager.cc 3 Oct 2007 23:08:16 -0000 > @@ -369,9 +369,12 @@ > debug_msg("Interface %s Vif %s\n", interface.c_str(), vif.c_str()); > string concat = interface + "/" + vif; > > - if (0 != _pmap.count(concat)) > - xorp_throw(BadPeer, > - c_format("Mapping for %s already exists", concat.c_str())); > + if (0 != _pmap.count(concat)) { > + // Don't think we really need to error here, just return what we already have. --Ben > + //xorp_throw(BadPeer, > + // c_format("Mapping for %s already exists", concat.c_str())); > + return _pmap[concat]; > + } > > OspfTypes::PeerID peerid = _next_peerid++; > _pmap[concat] = peerid; > > > Thanks, > Ben > > > -- > 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 luca.giraudo at gmail.com Thu Oct 4 01:22:12 2007 From: luca.giraudo at gmail.com (Luca Giraudo) Date: Thu, 4 Oct 2007 10:22:12 +0200 Subject: [Xorp-hackers] Multicast Programming In-Reply-To: <200710031931.l93JV5gS021082@possum.icir.org> References: <33404c390710030640y1e6dbb35s3317e5d43a6a8357@mail.gmail.com> <200710031931.l93JV5gS021082@possum.icir.org> Message-ID: <33404c390710040122q10d1eaa3j5d89bc33d66eff96@mail.gmail.com> I have modified the function to use the udp_open_and_bind with IPv4::ANY(). Now it works. So the most important thing is to utilise IPv4::ANY() instead of IPv4Constants::any. Thanks, Luca Giraudo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20071004/ca633199/attachment.html From pavlin at icir.org Thu Oct 4 02:53:39 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 04 Oct 2007 02:53:39 -0700 Subject: [Xorp-hackers] Multicast Programming In-Reply-To: Message from "Luca Giraudo" of "Thu, 04 Oct 2007 10:22:12 +0200." <33404c390710040122q10d1eaa3j5d89bc33d66eff96@mail.gmail.com> Message-ID: <200710040953.l949rdfY042129@possum.icir.org> Luca Giraudo wrote: > I have modified the function to use the udp_open_and_bind with IPv4::ANY(). > Now it works. So the most important thing is to utilise IPv4::ANY() instead > of IPv4Constants::any. Could you clarify your last sentence. IPv4::ANY() and IPv4Constants::any are practically same, so technically it shouldn't make any difference which one you use (except that the former is recommended for consistency reasons). Also, could you confirm that you were able to use udp_join_group to join the same multicast group on each interface you need. Without udp_join_group you won't receive the multicast packets. Thanks, Pavlin From luca.giraudo at gmail.com Thu Oct 4 05:15:28 2007 From: luca.giraudo at gmail.com (Luca Giraudo) Date: Thu, 4 Oct 2007 14:15:28 +0200 Subject: [Xorp-hackers] Multicast Programming In-Reply-To: <200710040953.l949rdfY042129@possum.icir.org> References: <33404c390710040122q10d1eaa3j5d89bc33d66eff96@mail.gmail.com> <200710040953.l949rdfY042129@possum.icir.org> Message-ID: <33404c390710040515o7059cf01gc825e23f17174f22@mail.gmail.com> The process is able to receive multicast packets from every interface if I do the next operations: * udp_open_and_bind to IPv4::ANY * udp_join_group on every configured IPv4 address on the PC (obtained by calling finder://fea/ifmgr/0.1/get_configured_interface_names -> finder://fea/ifmgr/0.1/get_configured_vif_names -> finder://fea/ifmgr/0.1/get_configured_vif_addresses4) In the first version of the demon I utilised udp_open_bind_join (with parameter IPv4Constants::any), but this doesn't work because it's impossible to join the multicast group on IPv4Constants::any (or IPv4::ANY) that isn't a local interface (error: ... the address must belong to a local interface); the solution is to call the bind and the join separately. In this way I can receive packets on every interface and I can send packets from every interface (finder://fea/socket4/0.1/send_from_multicast_if). In the previous e-mail I didn't describe well the process behaviour, sorry. Luca Giraudo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20071004/3618e33b/attachment-0001.html From greearb at candelatech.com Thu Oct 4 08:36:13 2007 From: greearb at candelatech.com (Ben Greear) Date: Thu, 04 Oct 2007 08:36:13 -0700 Subject: [Xorp-hackers] Some patches for various things. In-Reply-To: <200710040052.l940qQGm033941@possum.icir.org> References: <200710040052.l940qQGm033941@possum.icir.org> Message-ID: <4705086D.2090404@candelatech.com> Pavlin Radoslavov wrote: > Ben Greear wrote: > > >> Here are some more small patches. At some time during the last >> few weeks I added these to try to work around problems related to >> dynamically adding/deleting interfaces & ospf configuration. It's >> possible subsequent fixes from Xorp developers have made these un-needed. >> >> >> Treat a duplicate remove as OK instead of an error. >> This fixed some problem with reloading config files... >> >> RCS file: /cvs/xorp/fea/iftree.cc,v >> retrieving revision 1.51 >> diff -u -r1.51 iftree.cc >> --- fea/iftree.cc 27 Sep 2007 00:33:33 -0000 1.51 >> +++ fea/iftree.cc 3 Oct 2007 23:08:13 -0000 >> @@ -1079,7 +1079,7 @@ >> IfTreeAddr4* ap = find_addr(addr); >> >> if (ap == NULL) >> - return (XORP_ERROR); >> + return XORP_OK; // Already deleted it seems... (XORP_ERROR); >> ap->mark(DELETED); >> return (XORP_OK); >> } >> > > This is a question of semantics. Currently, trying to delete an IfTree > item (interface, vif and IP address) that doesn't exist is > considered an error. Some of the usage of this is to capture > errors/bugs elsewhere in the code. > > Could you send instructions how to replicate the problem with > reloading config files. Only then we can debug the issue and see > whether the real problem is somewhere else or whether it really > requires change of semantics. > Yes, there were some recent fixes to the FEA regarding modifying the > interface configuration, but there are no guarantees they actually > addressed the problem you had seen before. > Ok, I'll back this out and re-run my tests to see if it still errors out. > > The reason the log message has the format "+line file" is that you > can cut-and-paste and open directly the file in an editor like emacs > Ok, no problem. I didn't realize there was a use for the format.. > > Could you provide an example when the "file:line" format can be > useful (apart of probably looking more aesthetic :) ) > The current format makes my eyes bleed :) Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From atanu at ICSI.Berkeley.EDU Thu Oct 4 11:56:23 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Thu, 04 Oct 2007 11:56:23 -0700 Subject: [Xorp-hackers] Some patches for various things. In-Reply-To: Message from Ben Greear of "Wed, 03 Oct 2007 16:17:54 PDT." <47042322.8090203@candelatech.com> Message-ID: <85815.1191524183@tigger.icir.org> >>>>> "Ben" == Ben Greear writes: Ben> Here are some more small patches. At some time during the last Ben> few weeks I added these to try to work around problems related Ben> to dynamically adding/deleting interfaces & ospf configuration. Ben> It's possible subsequent fixes from Xorp developers have made Ben> these un-needed. Ben> Treat a duplicate remove as OK instead of an error. This fixed Ben> some problem with reloading config files... Ben> RCS file: /cvs/xorp/fea/iftree.cc,v retrieving revision 1.51 Ben> diff -u -r1.51 iftree.cc --- fea/iftree.cc 27 Sep 2007 00:33:33 Ben> -0000 1.51 +++ fea/iftree.cc 3 Oct 2007 23:08:13 -0000 @@ Ben> -1079,7 +1079,7 @@ IfTreeAddr4* ap = find_addr(addr); Ben> if (ap == NULL) - return (XORP_ERROR); + return XORP_OK; // Ben> Already deleted it seems... (XORP_ERROR); ap-> mark(DELETED); Ben> return (XORP_OK); } Ben> I prefer the log files to show the locations as file:line Ben> instead of the old +line format. Ben> RCS file: /cvs/xorp/libxorp/xlog.h,v retrieving revision 1.16 Ben> diff -u -r1.16 xlog.h --- libxorp/xlog.h 20 Apr 2007 19:06:21 Ben> -0000 1.16 +++ libxorp/xlog.h 3 Oct 2007 23:08:14 -0000 @@ Ben> -101,8 +101,8 @@ #define XLOG_FN(fn, fmt...) \ do { \ char Ben> xlog_where_buf[8000]; \ - snprintf(xlog_where_buf, Ben> sizeof(xlog_where_buf), "+%d %s %s", \ - __LINE__, __FILE__, Ben> __FUNCTION__); \ + snprintf(xlog_where_buf, Ben> sizeof(xlog_where_buf), "%s:%d %s", \ + __FILE__, __LINE__, Ben> __FUNCTION__); \ xlog_##fn(_XLOG_MODULE_NAME, xlog_where_buf, Ben> fmt); \ } while (0) Ben> This fixed an error in ospf. I don't know if this is still Ben> needed, or even if it was ever the right thing to do. Perhaps Ben> the OSPF folks could take a look and this... Ben> RCS file: /cvs/xorp/ospf/peer_manager.cc,v retrieving revision Ben> 1.146 diff -u -r1.146 peer_manager.cc --- ospf/peer_manager.cc Ben> 3 Oct 2007 21:23:53 -0000 1.146 +++ ospf/peer_manager.cc 3 Oct Ben> 2007 23:08:16 -0000 @@ -369,9 +369,12 @@ debug_msg("Interface Ben> %s Vif %s\n", interface.c_str(), vif.c_str()); string concat = Ben> interface + "/" + vif; Ben> - if (0 != _pmap.count(concat)) - xorp_throw(BadPeer, - Ben> c_format("Mapping for %s already exists", concat.c_str())); + Ben> if (0 != _pmap.count(concat)) { + // Don't think we really need Ben> to error here, just return what we already have. --Ben + Ben> //xorp_throw(BadPeer, + // c_format("Mapping for %s already Ben> exists", concat.c_str())); + return _pmap[concat]; + } Ben> OspfTypes::PeerID peerid = _next_peerid++; _pmap[concat] = Ben> peerid; Ben> Thanks, Ben Ben> -- Ben Greear Candela Technologies Ben> Inc http://www.candelatech.com Ben> _______________________________________________ Xorp-hackers Ben> mailing list Xorp-hackers at icir.org Ben> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From atanu at ICSI.Berkeley.EDU Thu Oct 4 12:06:12 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Thu, 04 Oct 2007 12:06:12 -0700 Subject: [Xorp-hackers] Some patches for various things. In-Reply-To: Message from Ben Greear of "Wed, 03 Oct 2007 16:17:54 PDT." <47042322.8090203@candelatech.com> Message-ID: <88804.1191524772@tigger.icir.org> >>>>> "Ben" == Ben Greear writes: Ben> Here are some more small patches. At some time during the last Ben> few weeks I added these to try to work around problems related to Ben> dynamically adding/deleting interfaces & ospf configuration. It's Ben> possible subsequent fixes from Xorp developers have made these un-needed. Ben> This fixed an error in ospf. I don't know if this is still needed, Ben> or even if it was ever the right thing to do. Perhaps the OSPF Ben> folks could take a look and this... Ben> RCS file: /cvs/xorp/ospf/peer_manager.cc,v Ben> retrieving revision 1.146 Ben> diff -u -r1.146 peer_manager.cc Ben> --- ospf/peer_manager.cc 3 Oct 2007 21:23:53 -0000 1.146 Ben> +++ ospf/peer_manager.cc 3 Oct 2007 23:08:16 -0000 Ben> @@ -369,9 +369,12 @@ Ben> debug_msg("Interface %s Vif %s\n", interface.c_str(), vif.c_str()); Ben> string concat = interface + "/" + vif; Ben> - if (0 != _pmap.count(concat)) Ben> - xorp_throw(BadPeer, Ben> - c_format("Mapping for %s already exists", concat.c_str())); Ben> + if (0 != _pmap.count(concat)) { Ben> + // Don't think we really need to error here, just return what we already have. --Ben Ben> + //xorp_throw(BadPeer, Ben> + // c_format("Mapping for %s already exists", concat.c_str())); Ben> + return _pmap[concat]; Ben> + } Ben> OspfTypes::PeerID peerid = _next_peerid++; Ben> _pmap[concat] = peerid; If you see this BadPeer message then there is a problem somewhere else. If you can provide me with a simple way of reproducing the problem I will take a look. Atanu. p.s. Sorry about the previous empty email. From pavlin at icir.org Thu Oct 4 13:01:25 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 04 Oct 2007 13:01:25 -0700 Subject: [Xorp-hackers] Multicast Programming In-Reply-To: Message from "Luca Giraudo" of "Thu, 04 Oct 2007 14:15:28 +0200." <33404c390710040515o7059cf01gc825e23f17174f22@mail.gmail.com> Message-ID: <200710042001.l94K1P5f047998@possum.icir.org> Luca Giraudo wrote: > The process is able to receive multicast packets from every interface if I > do the next operations: > * udp_open_and_bind to IPv4::ANY > * udp_join_group on every configured IPv4 address on the PC (obtained by > calling finder://fea/ifmgr/0.1/get_configured_interface_names -> > finder://fea/ifmgr/0.1/get_configured_vif_names -> > finder://fea/ifmgr/0.1/get_configured_vif_addresses4) > > In the first version of the demon I utilised udp_open_bind_join (with > parameter IPv4Constants::any), but this doesn't work because it's impossible > to join the multicast group on IPv4Constants::any (or IPv4::ANY) that isn't > a local interface (error: ... the address must belong to a local interface); > the solution is to call the bind and the join separately. > > In this way I can receive packets on every interface and I can send packets > from every interface (finder://fea/socket4/0.1/send_from_multicast_if). In > the previous e-mail I didn't describe well the process behaviour, sorry. I am glad that now it is working for you. Regarding obtaining the interface/vif names and the configured addresses, yes you could use the get_configured_* XRLs you mentioned above. However, you won't obtain other important information (e.g., whether an interface/vif is enabled, etc), and you won't get any updates when any of that information changes. The recommended (and much better solution) is to use the libfeaclient mechanism. You could check the static_routes implementation re. how it is used (hint: search for IfMgr and iftree), but unfortunately there is no documentation (yet) about the details. Of course, you could always add the libfeaclient mechanism at some later stage when you need to polish your implementation. Regards, Pavlin From greearb at candelatech.com Thu Oct 4 18:02:49 2007 From: greearb at candelatech.com (Ben Greear) Date: Thu, 04 Oct 2007 18:02:49 -0700 Subject: [Xorp-hackers] OSPF & migrating remote routers. Message-ID: <47058D39.3020803@candelatech.com> The current implementation of OSPF, if the remote router-id changes, but the remote interface IP doesn't change, then OSPF doesn't notice that there is a new peer because it searches on the interface IPs instead of the router-id. With the patch below, it searches by router-id on broadcast interfaces too, and then it works in my case (I'm using ethernet-like interfaces.) What is the reason for searching by anything other than router-id, regardless of the interface type? Thanks, Ben RCS file: /cvs/xorp/ospf/peer.cc,v retrieving revision 1.289 diff -u -r1.289 peer.cc --- peer.cc 5 Oct 2007 00:06:59 -0000 1.289 +++ peer.cc 5 Oct 2007 00:58:56 -0000 @@ -1487,13 +1487,13 @@ { typename list *>::iterator n; switch(get_linktype()) { - case OspfTypes::BROADCAST: case OspfTypes::NBMA: case OspfTypes::PointToMultiPoint: for(n = _neighbours.begin(); n != _neighbours.end(); n++) if ((*n)->get_neighbour_address() == src) return *n; break; + case OspfTypes::BROADCAST: case OspfTypes::VirtualLink: case OspfTypes::PointToPoint: for(n = _neighbours.begin(); n != _neighbours.end(); n++) -- Ben Greear Candela Technologies Inc http://www.candelatech.com From atanu at ICSI.Berkeley.EDU Thu Oct 4 18:20:04 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Thu, 04 Oct 2007 18:20:04 -0700 Subject: [Xorp-hackers] OSPF & migrating remote routers. In-Reply-To: Message from Ben Greear of "Thu, 04 Oct 2007 18:02:49 PDT." <47058D39.3020803@candelatech.com> Message-ID: <83007.1191547204@tigger.icir.org> Hi, >>>>> "Ben" == Ben Greear writes: Ben> The current implementation of OSPF, if the remote router-id Ben> changes, but the remote interface IP doesn't change, then OSPF Ben> doesn't notice that there is a new peer because it searches Ben> on the interface IPs instead of the router-id. Ben> With the patch below, it searches by router-id on broadcast Ben> interfaces too, and then it works in my case (I'm using Ben> ethernet-like interfaces.) Ben> What is the reason for searching by anything other than router-id, Ben> regardless of the interface type? The specification RFC 2328: ---------------------------------------- At this point, an attempt is made to match the source of the Hello Packet to one of the receiving interface's neighbors. If the receiving interface connects to a broadcast, Point-to- MultiPoint or NBMA network the source is identified by the IP source address found in the Hello's IP header. If the receiving interface connects to a point-to-point link or a virtual link, the source is identified by the Router ID found in the Hello's OSPF packet header. The interface's current list of neighbors is contained in the interface's data structure. If a matching neighbor structure cannot be found, (i.e., this is the first time the neighbor has been detected), one is created. The initial state of a newly created neighbor is set to Down. ---------------------------------------- Atanu. Ben> Thanks, Ben> Ben Ben> RCS file: /cvs/xorp/ospf/peer.cc,v Ben> retrieving revision 1.289 Ben> diff -u -r1.289 peer.cc Ben> --- peer.cc 5 Oct 2007 00:06:59 -0000 1.289 Ben> +++ peer.cc 5 Oct 2007 00:58:56 -0000 Ben> @@ -1487,13 +1487,13 @@ Ben> { Ben> typename list *>::iterator n; Ben> switch(get_linktype()) { Ben> - case OspfTypes::BROADCAST: Ben> case OspfTypes::NBMA: Ben> case OspfTypes::PointToMultiPoint: Ben> for(n = _neighbours.begin(); n != _neighbours.end(); n++) Ben> if ((*n)->get_neighbour_address() == src) Ben> return *n; Ben> break; Ben> + case OspfTypes::BROADCAST: Ben> case OspfTypes::VirtualLink: Ben> case OspfTypes::PointToPoint: Ben> for(n = _neighbours.begin(); n != _neighbours.end(); n++) Ben> -- Ben> Ben Greear Ben> Candela Technologies Inc http://www.candelatech.com Ben> _______________________________________________ Ben> Xorp-hackers mailing list Ben> Xorp-hackers at icir.org Ben> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From greearb at candelatech.com Thu Oct 4 20:36:50 2007 From: greearb at candelatech.com (Ben Greear) Date: Thu, 04 Oct 2007 20:36:50 -0700 Subject: [Xorp-hackers] OSPF & migrating remote routers. In-Reply-To: <83007.1191547204@tigger.icir.org> References: <83007.1191547204@tigger.icir.org> Message-ID: <4705B152.4020602@candelatech.com> Atanu Ghosh wrote: > Hi, > > >>>>>> "Ben" == Ben Greear writes: >>>>>> > > Ben> The current implementation of OSPF, if the remote router-id > Ben> changes, but the remote interface IP doesn't change, then OSPF > Ben> doesn't notice that there is a new peer because it searches > Ben> on the interface IPs instead of the router-id. > > Ben> With the patch below, it searches by router-id on broadcast > Ben> interfaces too, and then it works in my case (I'm using > Ben> ethernet-like interfaces.) > > Ben> What is the reason for searching by anything other than router-id, > Ben> regardless of the interface type? > > The specification RFC 2328: > ---------------------------------------- > At this point, an attempt is made to match the source of the > Hello Packet to one of the receiving interface's neighbors. If > the receiving interface connects to a broadcast, Point-to- > MultiPoint or NBMA network the source is identified by the IP > source address found in the Hello's IP header. If the receiving > interface connects to a point-to-point link or a virtual link, > the source is identified by the Router ID found in the Hello's > OSPF packet header. The interface's current list of neighbors > is contained in the interface's data structure. If a matching > neighbor structure cannot be found, (i.e., this is the first > time the neighbor has been detected), one is created. The > initial state of a newly created neighbor is set to Down. > ---------------------------------------- > The next paragraph down talks about setting the neighbor's id to that of the router-id found in the hello packet. If the new ID is different from the old ID, surely you have to go back to initial state, even though the RFC doesn't say anything about this. Otherwise, it seems like you could be using stale state for a new router that just came up with the old IP address (this is indeed what I see). Can you think of any positive reason to use the interface's IP as opposed to the router-id, other than that is what the RFC suggests? If you don't want to change the code, I can just use my private build, but perhaps it might be worth thinking about fudging the RFC in this case, or at least allowing one to configure this new behaviour in the config file. Thanks, Ben > Atanu. > > Ben> Thanks, > Ben> Ben > > Ben> RCS file: /cvs/xorp/ospf/peer.cc,v > Ben> retrieving revision 1.289 > Ben> diff -u -r1.289 peer.cc > Ben> --- peer.cc 5 Oct 2007 00:06:59 -0000 1.289 > Ben> +++ peer.cc 5 Oct 2007 00:58:56 -0000 > Ben> @@ -1487,13 +1487,13 @@ > Ben> { > Ben> typename list *>::iterator n; > Ben> switch(get_linktype()) { > Ben> - case OspfTypes::BROADCAST: > Ben> case OspfTypes::NBMA: > Ben> case OspfTypes::PointToMultiPoint: > Ben> for(n = _neighbours.begin(); n != _neighbours.end(); n++) > Ben> if ((*n)->get_neighbour_address() == src) > Ben> return *n; > Ben> break; > Ben> + case OspfTypes::BROADCAST: > Ben> case OspfTypes::VirtualLink: > Ben> case OspfTypes::PointToPoint: > Ben> for(n = _neighbours.begin(); n != _neighbours.end(); n++) > > Ben> -- > Ben> Ben Greear > Ben> Candela Technologies Inc http://www.candelatech.com > > Ben> _______________________________________________ > Ben> Xorp-hackers mailing list > Ben> Xorp-hackers at icir.org > Ben> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From zhj.zhao at gmail.com Mon Oct 8 01:13:56 2007 From: zhj.zhao at gmail.com (jerry zhao) Date: Mon, 8 Oct 2007 10:13:56 +0200 Subject: [Xorp-hackers] buffer state of router Message-ID: Hello everyone, I want to ask a question about router software. Now I am doing something about video streaming. Sometimes there is congestion because of buffer overflow of router. So I want to know the buffer state of router so that I can control the sever how many date it should send. Does anyone know whether there is a router software or router product that can send the buffer state to the server? Any advice is appreciated. Thanks Best regards Jerry -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20071008/f432d15e/attachment.html From zec at icir.org Mon Oct 8 01:39:28 2007 From: zec at icir.org (Marko Zec) Date: Mon, 8 Oct 2007 10:39:28 +0200 Subject: [Xorp-hackers] buffer state of router In-Reply-To: References: Message-ID: <200710081039.28798.zec@icir.org> On Monday 08 October 2007 10:13:56 jerry zhao wrote: > Hello everyone, > I want to ask a question about router software. Now I am doing > something about video streaming. Sometimes there is congestion > because of buffer overflow of router. So I want to know the buffer > state of router so that I can control the sever how many date it > should send. Does anyone know whether there is a router software or > router product that can send the buffer state to the server? Any > advice is appreciated. Thanks XCP -> http://www.isi.edu/isi-xcp/ From Stephen.Pope at ubs.com Mon Oct 8 22:34:13 2007 From: Stephen.Pope at ubs.com (Stephen C. Pope) Date: Mon, 08 Oct 2007 23:34:13 -0600 Subject: [Xorp-hackers] PIM auto-RP sparse-dense-mode? Message-ID: <470B12D5.1060708@ubs.com> Dear Xorp hackers, I find my self in a situation where I need to convince a Jupiter router on the other end of a long-distance layer 2 connection running 802.1q trunking that I have a router, but in fact all I have is a linux box. XORP is helping me out in this matter, but one thing I lack is a PIM sparse-dense-mode implementation to keep the router happy. Without PIM sparse-dense-mode, I'll have to resort to having static joins configured on the router, which I dread ;-). Per chance, has anyone whipped up a PIM sparse-dense-mode implementation for XORP? Specifically, I need to be able to support auto-RP and placing my xorp PIM protocol into discovery-only mode (I only have to handle sources and RPs upstream, so I really only need to listen to 224.0.1.40). A cursory scan of the archives and bugzilla didn't turn up anything on this topic. Any implementations or other hints or guidance would be appreciated! Stephen Pope Prediction Company LLC/UBS AG stephen.pope at ubs.com Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mails are not encrypted and cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From pavlin at icir.org Tue Oct 9 00:42:50 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 09 Oct 2007 00:42:50 -0700 Subject: [Xorp-hackers] PIM auto-RP sparse-dense-mode? In-Reply-To: Message from "Stephen C. Pope" of "Mon, 08 Oct 2007 23:34:13 MDT." <470B12D5.1060708@ubs.com> Message-ID: <200710090742.l997goBT023839@possum.icir.org> > I find my self in a situation where I need to convince a Jupiter router > on the other end of a long-distance layer 2 connection running 802.1q > trunking that I have a router, but in fact all I have is a linux box. > > XORP is helping me out in this matter, but one thing I lack is a PIM > sparse-dense-mode implementation to keep the router happy. Without PIM > sparse-dense-mode, I'll have to resort to having static joins configured > on the router, which I dread ;-). > > Per chance, has anyone whipped up a PIM sparse-dense-mode implementation > for XORP? Specifically, I need to be able to support auto-RP and placing > my xorp PIM protocol into discovery-only mode (I only have to handle > sources and RPs upstream, so I really only need to listen to > 224.0.1.40). A cursory scan of the archives and bugzilla didn't turn up > anything on this topic. > > Any implementations or other hints or guidance would be appreciated! The auto-RP mechanism for dynamic distribution of the group-to-RP mapping is a legacy protocol that was developed for PIM-SMv1. It comes from Cisco and there is no public document/specification that describes it (i.e., no RFC or even an Internet Draft). My guess is that Juniper implemented it only because they wanted to interoperate as much as possible with Cisco (and for that purpose they had to implement legacy stuff like this as well). When dynamic mapping is needed, the Bootstrap mechanism should be used instead of auto-RP. The Bootstrap mechanism has been developed along with PIM-SMv2 so it is quite mature. It has been implemented by practically every vendor that implements PIM-SMv2 (including Cisco, Juniper and XORP). My recommendation is that you get rid of the legacy Auto-RP deployment in your network and use the Bootstrap mechanism instead. You might not be very excited by the thoughts of reconfiguring your routers, but you will be rewarded in the long-term. Well, I understand that this switch might not be possible for various reasons (e.g., out of your control, etc). In that case, a possible work-around would be to use Static RP configuration with XORP. I assume you know the group-to-RP mapping information that is distributed by auto-RP (or you can learn it in some way such as running tcpdump and decoding the auto-RP packets). Then make sure that you configure XORP with _exactly_ same Cand-RP information in the "static-rps" section, otherwise the result is unpredictable (black holes, loops, etc, depending on your topology). This work-around will let you use XORP in the auto-RP setup, but it assumes that the Cand-RP set is very stable and doesn't change over time. Otherwise, as I mentioned above, it might generate issues you really don't want to deal with. Another possible solution, which is really ad-hoc and requires some level of programming is to provide glue between auto-RP and the static-rps setup in XORP. For example, write a script that uses, say, tcpdump to capture the auto-RP packets and then decode them to obtain the Cand-RP set. Then the script can use "xorpsh" in non-interactive mode to reconfigure XORP's static-rps setup on-the-fly. However, you should have in mind that in both cases you should use XORP only as a leaf router for the simple reason that it doesn't have PIM-DM (yet) so you cannot use it to forward the auto-RP packets to the rest of the network. I would be very much interested to know the solution you choose (incl. the reasons for the particular choice), and how well it worked (or didn't work). Your experience will be very valuable for other folks that might be in similar situation. Thanks, Pavlin From Stephen.Pope at ubs.com Tue Oct 9 14:10:10 2007 From: Stephen.Pope at ubs.com (Stephen C. Pope) Date: Tue, 09 Oct 2007 15:10:10 -0600 Subject: [Xorp-hackers] PIM auto-RP sparse-dense-mode? In-Reply-To: <200710090742.l997goBT023839@possum.icir.org> References: <200710090742.l997goBT023839@possum.icir.org> Message-ID: <470BEE32.20904@ubs.com> > The auto-RP mechanism for dynamic distribution of the group-to-RP > mapping is a legacy protocol that was developed for PIM-SMv1. > ... > Well, I understand that this switch might not be possible for > various reasons (e.g., out of your control, etc). > I understand the history, and I understand that I shouldn't be using it. But it is out of my control ;-). I had noted that I couldn't seem to find any documentation on the protocol which would mean some reverse engineering was in order. > In that case, a possible work-around would be to use Static RP > configuration with XORP. I was contemplating this very thing... > I would be very much interested to know the solution you choose > (incl. the reasons for the particular choice), and how well it > worked (or didn't work). Your experience will be very valuable for other folks that might be > in similar situation. > Will do. It may be: use static joins on the other end for now, and buy a new router for the future :-(. stephen. Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mails are not encrypted and cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From pavlin at icir.org Tue Oct 9 15:17:20 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 09 Oct 2007 15:17:20 -0700 Subject: [Xorp-hackers] PIM auto-RP sparse-dense-mode? In-Reply-To: Message from "Stephen C. Pope" of "Tue, 09 Oct 2007 15:10:10 MDT." <470BEE32.20904@ubs.com> Message-ID: <200710092217.l99MHKPi047183@possum.icir.org> > > In that case, a possible work-around would be to use Static RP > > configuration with XORP. > > I was contemplating this very thing... > > > I would be very much interested to know the solution you choose > > (incl. the reasons for the particular choice), and how well it > > worked (or didn't work). Your experience will be very valuable for other folks that might be > > in similar situation. > > > > Will do. It may be: use static joins on the other end for now, and buy a > new router for the future :-(. Static joins are probably the simplest short-term solution, but the downside is traffic overhead if there are no downstream receivers. XORP with static RPs will get you around that, assuming the Cand-RP set doesn't change over time. And it will also save you the $$$$ for the new router :) Re. updating the static RPs information by snooping and decoding the auto-RP messages, I think this can be a very interesting mini-project for someone who likes to play with this kind of stuff. The only tricky part will be the decoding of the auto-RP messages. Strictly speaking it should be possible to do it with a script program (in any language you might like). Though, a tool like Scapy will greatly simplify the solution: http://www.secdev.org/projects/scapy/ Regards, Pavlin From arjun at ceeyes.com Wed Oct 10 01:38:05 2007 From: arjun at ceeyes.com (arjun at ceeyes.com) Date: Wed, 10 Oct 2007 04:38:05 -0400 Subject: [Xorp-hackers] How to Configure the LIVE CD Message-ID: <380-22007103108385833@M2W027.mail2web.com> Hi All! I have downloaded and made a live CD of XORP. Now i wanted to configure it to make it act as RIP router. So plz tell me how can i configure it (with some examples). Also i want to test it on my pc running linux. Also i want to test it on a network consists of two computers. how can i test its working plz write in details. Regards, Arjun -------------------------------------------------------------------- mail2web.com - Microsoft? Exchange solutions from a leading provider - http://link.mail2web.com/Business/Exchange From a.greenhalgh at cs.ucl.ac.uk Wed Oct 10 02:08:58 2007 From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh) Date: Wed, 10 Oct 2007 10:08:58 +0100 Subject: [Xorp-hackers] How to Configure the LIVE CD In-Reply-To: <380-22007103108385833@M2W027.mail2web.com> References: <380-22007103108385833@M2W027.mail2web.com> Message-ID: <4769af410710100208p35addd07jdb52e3ca9109d85c@mail.gmail.com> What you want is http://www.xorp.org/getting_started.html and http://www.xorp.org/releases/current/docs/user_manual/user_manual.pdf adam On 10/10/2007, arjun at ceeyes.com wrote: > Hi All! > > I have downloaded and made a live CD of XORP. > Now i wanted to configure it to make it act as RIP router. > So plz tell me how can i configure it (with some examples). > > Also i want to test it on my pc running linux. > > Also i want to test it on a network consists of two computers. > > how can i test its working plz write in details. > > Regards, > Arjun > > -------------------------------------------------------------------- > mail2web.com - Microsoft(r) Exchange solutions from a leading provider - > http://link.mail2web.com/Business/Exchange > > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > From greearb at candelatech.com Wed Oct 10 17:24:55 2007 From: greearb at candelatech.com (Ben Greear) Date: Wed, 10 Oct 2007 17:24:55 -0700 Subject: [Xorp-hackers] Feature request for xorpsh Message-ID: <470D6D57.6080407@candelatech.com> First, I never posted back to this list, but I was able to get XORP + OSPF to function as I was trying to do. Big thanks to Atanu for that last set of fixes to OSPF to make it handle peers correctly in my scenario. Now, a small feature quest: I would like a flag to xorpsh to make it die immediately if it cannot connect to the specified router-mgr (based on the port specified in the environment variable). This will make it a lot easier to script. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Wed Oct 10 18:14:34 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 10 Oct 2007 18:14:34 -0700 Subject: [Xorp-hackers] Feature request for xorpsh In-Reply-To: Message from Ben Greear of "Wed, 10 Oct 2007 17:24:55 PDT." <470D6D57.6080407@candelatech.com> Message-ID: <200710110114.l9B1EYO4084162@possum.icir.org> A non-text attachment was scrubbed... Name: xorpsh.patch Type: text/x-c++ Size: 7194 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20071010/d4054916/attachment.bin From zhj.zhao at gmail.com Thu Oct 11 08:07:30 2007 From: zhj.zhao at gmail.com (jerry zhao) Date: Thu, 11 Oct 2007 17:07:30 +0200 Subject: [Xorp-hackers] source code of router software Message-ID: Hello, Eine einfache Rechnung zeigt, da? die Wiedergabe unkomprimierte Does anyone know if there is any source code of router software except Xorp that we can download and use? Any advice is appreciated. Thanks. Best regards. Jerry -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20071011/292c3d26/attachment.html From zhj.zhao at gmail.com Thu Oct 11 08:29:07 2007 From: zhj.zhao at gmail.com (jerry zhao) Date: Thu, 11 Oct 2007 17:29:07 +0200 Subject: [Xorp-hackers] source code of router software Message-ID: Hello, Does anyone know if there is any source code of router software except Xorp that we can download and use? Any advice is appreciated. Thanks. Best regards. Jerry -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20071011/57f6e6af/attachment.html From greearb at candelatech.com Thu Oct 11 09:10:40 2007 From: greearb at candelatech.com (Ben Greear) Date: Thu, 11 Oct 2007 09:10:40 -0700 Subject: [Xorp-hackers] xorpsh crash Message-ID: <470E4B00.5000700@candelatech.com> I'm getting a repeatable crash in xorpsh (I have not yet added that patch that Pavlin sent yesterday...this is just the latest cvs). I think it may be related to the fix for the cli busy-spin when scripting, probably the _clock member has been deleted or otherwise corrupted: (gdb) bt #0 0x470c91a8 in main_arena () from /lib/libc.so.6 #1 0x08189375 in TimerList::current_time (this=0x470c9194, now=@0xbfa7a828) at timer.cc:246 #2 0x0818a7f1 in TimerNode::schedule_after (this=0x832fe60, wait=@0xbfa7a8e4, priority=9) at timer.cc:140 #3 0x0818aa26 in TimerList::new_oneoff_after (this=0x470c9194, wait=@0xbfa7a8e4, cb=@0xbfa7a8d8, priority=9) at timer.cc:328 #4 0x080eddc3 in EventLoop::new_oneoff_after (this=0x470c9190, wait=@0xbfa7a8e4, ocb=@0xbfa7a8d8, priority=9) at ../libxorp/eventloop.hh:369 #5 0x080e9855 in CliClient::schedule_process_input_data (this=0x8307660) at cli_node_net.cc:901 #6 0x080eb85f in CliClient::process_input_data (this=0x8307660) at cli_node_net.cc:880 #7 0x080ed6a9 in XorpMemberCallback0B0::dispatch (this=0x82ff958) at ../libxorp/callback_nodebug.hh:305 #8 0x0818afa2 in OneoffTimerNode2::expire (this=0x831b8d8) at timer.cc:184 #9 0x08189e4a in TimerList::expire_one (this=0xbfa849cc, worst_priority=9) at timer.cc:481 #10 0x08189fae in TimerList::run (this=0xbfa849cc) at timer.cc:428 #11 0x0817045c in EventLoop::run (this=0xbfa849c8) at eventloop.cc:114 #12 0x080c1cdf in XorpShell::run (this=0xbfa82a88, commands=@0xbfa84bf4) at xorpsh_main.cc:388 #13 0x080c3b69 in main (argc=1, argv=0xbfa84cb4) at xorpsh_main.cc:897 (gdb) frame 1 #1 0x08189375 in TimerList::current_time (this=0x470c9194, now=@0xbfa7a828) at timer.cc:246 (gdb) print _clock $1 = (class ClockBase *) 0x470c91a0 (gdb) print *_clock warning: can't find linker symbol for virtual table for `ClockBase' value $2 = {_vptr.ClockBase = 0x470c9198} If no one beats me to it, I'll try to figure this one out later today. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Thu Oct 11 14:03:49 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 11 Oct 2007 14:03:49 -0700 Subject: [Xorp-hackers] xorpsh crash In-Reply-To: Message from Ben Greear of "Thu, 11 Oct 2007 09:10:40 PDT." <470E4B00.5000700@candelatech.com> Message-ID: <200710112103.l9BL3nvw097502@possum.icir.org> Ben Greear wrote: > I'm getting a repeatable crash in xorpsh (I have not yet added that patch > that Pavlin sent yesterday...this is just the latest cvs). Is there a simple procedure how to repeat the crash? > I think it may be related to the fix for the cli busy-spin when > scripting, probably the _clock member has been deleted or > otherwise corrupted: The particular warning you are seeing below is probably an artifact of the C++ inheritance for the SystemClock class implementation, so this might not be the real issue. Unfortunately, your backtrace doesn't provide much information about the crash itself. The only issue that comes to mind is that the CliClient might have been deleted somehow before the timer that called CliClient::process_input_data(). This is very unlike, because the timer deletion should have canceled the callback, but is something you could investigate by adding XLOG message in the CliClient destructor. Thanks, Pavlin > > (gdb) bt > #0 0x470c91a8 in main_arena () from /lib/libc.so.6 > #1 0x08189375 in TimerList::current_time (this=0x470c9194, now=@0xbfa7a828) at timer.cc:246 > #2 0x0818a7f1 in TimerNode::schedule_after (this=0x832fe60, wait=@0xbfa7a8e4, priority=9) > at timer.cc:140 > #3 0x0818aa26 in TimerList::new_oneoff_after (this=0x470c9194, wait=@0xbfa7a8e4, cb=@0xbfa7a8d8, > priority=9) at timer.cc:328 > #4 0x080eddc3 in EventLoop::new_oneoff_after (this=0x470c9190, wait=@0xbfa7a8e4, ocb=@0xbfa7a8d8, > priority=9) at ../libxorp/eventloop.hh:369 > #5 0x080e9855 in CliClient::schedule_process_input_data (this=0x8307660) at cli_node_net.cc:901 > #6 0x080eb85f in CliClient::process_input_data (this=0x8307660) at cli_node_net.cc:880 > #7 0x080ed6a9 in XorpMemberCallback0B0::dispatch (this=0x82ff958) > at ../libxorp/callback_nodebug.hh:305 > #8 0x0818afa2 in OneoffTimerNode2::expire (this=0x831b8d8) at timer.cc:184 > #9 0x08189e4a in TimerList::expire_one (this=0xbfa849cc, worst_priority=9) at timer.cc:481 > #10 0x08189fae in TimerList::run (this=0xbfa849cc) at timer.cc:428 > #11 0x0817045c in EventLoop::run (this=0xbfa849c8) at eventloop.cc:114 > #12 0x080c1cdf in XorpShell::run (this=0xbfa82a88, commands=@0xbfa84bf4) at xorpsh_main.cc:388 > #13 0x080c3b69 in main (argc=1, argv=0xbfa84cb4) at xorpsh_main.cc:897 > > (gdb) frame 1 > #1 0x08189375 in TimerList::current_time (this=0x470c9194, now=@0xbfa7a828) at timer.cc:246 > > (gdb) print _clock > $1 = (class ClockBase *) 0x470c91a0 > (gdb) print *_clock > warning: can't find linker symbol for virtual table for `ClockBase' value > $2 = {_vptr.ClockBase = 0x470c9198} > > > If no one beats me to it, I'll try to figure this one out later today. > > Thanks, > Ben > > > -- > 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 greearb at candelatech.com Thu Oct 11 17:39:03 2007 From: greearb at candelatech.com (Ben Greear) Date: Thu, 11 Oct 2007 17:39:03 -0700 Subject: [Xorp-hackers] xorpsh crash In-Reply-To: <200710112103.l9BL3nvw097502@possum.icir.org> References: <200710112103.l9BL3nvw097502@possum.icir.org> Message-ID: <470EC227.5000504@candelatech.com> Pavlin Radoslavov wrote: > Ben Greear wrote: > >> I'm getting a repeatable crash in xorpsh (I have not yet added that patch >> that Pavlin sent yesterday...this is just the latest cvs). > > Is there a simple procedure how to repeat the crash? I don't think so...seems it might be a race of some kind... I'm trying to add a new file to libxorp/ dir to help debug this. I tried editing the Makefile.am and reran ./configure in the base dir, but the .cc file is still not being compiled. What do I need to do to make it compile my file? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Thu Oct 11 17:57:28 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 11 Oct 2007 17:57:28 -0700 Subject: [Xorp-hackers] xorpsh crash In-Reply-To: Message from Ben Greear of "Thu, 11 Oct 2007 17:39:03 PDT." <470EC227.5000504@candelatech.com> Message-ID: <200710120057.l9C0vSvi099560@possum.icir.org> Ben Greear wrote: > Pavlin Radoslavov wrote: > > Ben Greear wrote: > > > >> I'm getting a repeatable crash in xorpsh (I have not yet added that patch > >> that Pavlin sent yesterday...this is just the latest cvs). > > > > Is there a simple procedure how to repeat the crash? > > I don't think so...seems it might be a race of some kind... > > I'm trying to add a new file to libxorp/ dir to help debug > this. I tried editing the Makefile.am and reran ./configure in the > base dir, but the .cc file is still not being compiled. What do I > need to do to make it compile my file? If you modify any Makefile.am or configure.in file, you must run ./bootstrap in the XORP top-level directory. After that you need to run ./configure Note however that you should have installed the same versions of the autotools we are using, otherwise the result is unpredictable: autoconf: 2.61 automake: 1.10 libtool: 1.5.22 Also, see the beginning of the "bootstrap" script for the list of environmental variables you might need to set if the installed executables on your machine doesn't match those names: ACLOCAL=${ACLOCAL:-"aclocal-1.10"} AUTOCONF=${AUTOCONF:-"autoconf-2.61"} AUTOHEADER=${AUTOHEADER:-"autoheader-2.61"} AUTOM4TE=${AUTOM4TE:-"autom4te-2.61"} AUTOMAKE=${AUTOMAKE:-"automake-1.10"} LIBTOOLIZE=${LIBTOOLIZE:-"libtoolize"} Regards, Pavlin From greearb at candelatech.com Thu Oct 11 18:55:45 2007 From: greearb at candelatech.com (Ben Greear) Date: Thu, 11 Oct 2007 18:55:45 -0700 Subject: [Xorp-hackers] xorpsh crash In-Reply-To: <200710120057.l9C0vSvi099560@possum.icir.org> References: <200710120057.l9C0vSvi099560@possum.icir.org> Message-ID: <470ED421.8030603@candelatech.com> Pavlin Radoslavov wrote: > Ben Greear wrote: > >> Pavlin Radoslavov wrote: >>> Ben Greear wrote: >>> >>>> I'm getting a repeatable crash in xorpsh (I have not yet added that patch >>>> that Pavlin sent yesterday...this is just the latest cvs). >>> Is there a simple procedure how to repeat the crash? >> I don't think so...seems it might be a race of some kind... >> >> I'm trying to add a new file to libxorp/ dir to help debug >> this. I tried editing the Makefile.am and reran ./configure in the >> base dir, but the .cc file is still not being compiled. What do I >> need to do to make it compile my file? > > If you modify any Makefile.am or configure.in file, you must run > ./bootstrap > in the XORP top-level directory. > After that you need to run ./configure > > Note however that you should have installed the same versions of the > autotools we are using, otherwise the result is unpredictable: > > autoconf: 2.61 > automake: 1.10 > libtool: 1.5.22 > > Also, see the beginning of the "bootstrap" script for the list of > environmental variables you might need to set if the installed > executables on your machine doesn't match those names: > > ACLOCAL=${ACLOCAL:-"aclocal-1.10"} > AUTOCONF=${AUTOCONF:-"autoconf-2.61"} > AUTOHEADER=${AUTOHEADER:-"autoheader-2.61"} > AUTOM4TE=${AUTOM4TE:-"autom4te-2.61"} > AUTOMAKE=${AUTOMAKE:-"automake-1.10"} > LIBTOOLIZE=${LIBTOOLIZE:-"libtoolize"} That sounds a bit scary...it won't be easy to fix this if my versions are off. I managed to manually tweak the Makefile for now... Anyway, I added my 'bug-cather' files and sure enough, we are deleting already-freed memory: (gdb) bt #0 0x08189566 in TimerNode::release_ref (this=0x83016d0) at timer.cc:87 #1 0x080bea0e in ~XorpTimer (this=0xbf8cdf04) at timer.hh:537 #2 0x0818a24c in TimerList::expire_one (this=0xbf8d4014, worst_priority=9) at timer.cc:458 #3 0x0818a395 in TimerList::run (this=0xbf8d4014) at timer.cc:428 #4 0x08170688 in EventLoop::run (this=0xbf8d4010) at eventloop.cc:114 #5 0x080c1cdf in XorpShell::run (this=0xbf8d20d0, commands=@0xbf8d4244) at xorpsh_main.cc:388 #6 0x080c3b69 in main (argc=1, argv=0xbf8d4304) at xorpsh_main.cc:897 (gdb) frame 0 #0 0x08189566 in TimerNode::release_ref (this=0x83016d0) at timer.cc:87 87 in timer.cc (gdb) print *this $1 = { = { = {_vptr.BugCatcher = 0x0, magic = 3735928559, static _cnt = 8}, _pos_in_heap = -1}, _ref_cnt = -1, _expires = {static ONE_MILLION = 1000000, _sec = 179108, _usec = 477834}, _cb = {_M_ptr = 0x0, _M_index = 71}, _priority = 9, _list = 0xbf8d4014} (gdb) print /x this->magic $2 = 0xdeadbeef (gdb) No fix yet, but please consider the attached patch and new files..this has saved me many hours debugging complex applications & core files... Thanks, Ben > > Regards, > Pavlin -- Ben Greear Candela Technologies Inc http://www.candelatech.com -------------- next part -------------- A non-text attachment was scrubbed... Name: xorp.patch Type: text/x-patch Size: 3892 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20071011/9b059ab2/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: bug_catcher.cc Type: text/x-c++src Size: 66 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20071011/9b059ab2/attachment-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: bug_catcher.hh Type: text/x-c++hdr Size: 511 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20071011/9b059ab2/attachment-0002.bin From greearb at candelatech.com Thu Oct 11 19:28:15 2007 From: greearb at candelatech.com (Ben Greear) Date: Thu, 11 Oct 2007 19:28:15 -0700 Subject: [Xorp-hackers] OSPF doesn't deal well with changing interfaces/neighbors if not currently in state FULL. Message-ID: <470EDBBF.3010801@candelatech.com> I notice that if I run xorpsh commands too soon after starting xorp, the OSPF routers get stuck in ExStart state. However, if I wait till they go to Full state, then it seems to work properly when interfaces & neighbours are changed. Here is output of two stuck routers: [root at lanforge-33-46 lanforge]# export XORP_FINDER_SERVER_PORT=20008; xorpsh Welcome to XORP on lanforge-33-46 root at lanforge-33-46> show ospf4 neighbor Address Interface State ID Pri Dead 10.4.0.7 rddVR45/rddVR45 ExStart 127.1.0.2 128 31 root at lanforge-33-46> show ospf4 `ospf4' is ambiguous. Possible completions: database Show LSA database neighbor Show Neighbors root at lanforge-33-46> show ospf4 `ospf4' is ambiguous. Possible completions: database Show LSA database neighbor Show Neighbors root at lanforge-33-46> show ospf4 database OSPF link state database, Area 0.0.0.0 Type ID Adv Rtr Seq Age Opt Cksum Len Router *127.1.0.8 127.1.0.8 0x80000001 252 0x2 0x1afc 48 root at lanforge-33-46> quit [root at lanforge-33-46 lanforge]# export XORP_FINDER_SERVER_PORT=20002; xorpsh Welcome to XORP on lanforge-33-46 root at lanforge-33-46> show ospf4 neighbor Address Interface State ID Pri Dead 10.0.0.2 rddVR0/rddVR0 Full 127.1.0.1 128 38 10.4.0.2 rddVR44/rddVR44 ExStart 127.1.0.8 128 38 root at lanforge-33-46> quit Here's one of the log files: [root at lanforge-33-46 local]# cat /tmp/lanforge/xorp-log-vr10008.txt 2007-10-11 18:43:38 lf_stop_xorp: Tried to kill non-existent PPID: 20008 [ 2007/10/11 18:43:47 INFO xorp_rtrmgr:18689 RTRMGR master_conf_tree.cc:239 execute ] Changed modules: interfaces, fea, rib, policy, static_routes, ospf4 [ 2007/10/11 18:43:47 INFO xorp_rtrmgr:18689 RTRMGR module_manager.cc:96 execute ] Executing module: interfaces (fea/xorp_fea)ere is no member or method named magic. [ 2007/10/11 18:43:49 WARNING xorp_rtrmgr:18689 XrlFinderTarget ../xrl/targets/finder_base.cc:406 handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Xrl target is not enabled. [ 2007/10/11 18:43:50 ERROR xorp_fea:18841 LIBCOMM comm_sock.c:115 comm_sock_open ] Error opening socket (domain = 10, type = 2, protocol = 0): Address family not supported by protocol [ 2007/10/11 18:43:50 ERROR xorp_fea:18841 LIBCOMM comm_sock.c:115 comm_sock_open ] Error opening socket (domain = 10, type = 2, protocol = 0): Address family not supported by protocol [ 2007/10/11 18:43:51 INFO xorp_fea MFEA ] MFEA enabledt_1.out [ 2007/10/11 18:43:51 INFO xorp_fea MFEA ] CLI enabled-vr10008.txt [ 2007/10/11 18:43:51 INFO xorp_fea MFEA ] CLI started [ 2007/10/11 18:43:51 INFO xorp_fea MFEA ] MFEA enabled [ 2007/10/11 18:43:51 INFO xorp_fea MFEA ] CLI enabled [ 2007/10/11 18:43:51 INFO xorp_fea MFEA ] CLI started [ 2007/10/11 18:43:51 INFO xorp_rtrmgr:18689 RTRMGR module_manager.cc:96 execute ] Executing module: fea (fea/xorp_fea) [ 2007/10/11 18:43:57 INFO xorp_rtrmgr:18689 RTRMGR module_manager.cc:96 execute ] Executing module: rib (rib/xorp_rib) [ 2007/10/11 18:43:57 INFO xorp_rib RIB ] Setting 'static' distance to: 220 based on XORP_RIB_STATIC_DISTANCE environment variable. [ 2007/10/11 18:43:57 INFO xorp_rib RIB ] Setting 'static' distance to: 220 based on XORP_RIB_STATIC_DISTANCE environment variable. [ 2007/10/11 18:43:57 INFO xorp_rib RIB ] Setting 'static' distance to: 220 based on XORP_RIB_STATIC_DISTANCE environment variable. [ 2007/10/11 18:43:57 INFO xorp_rib RIB ] Setting 'static' distance to: 220 based on XORP_RIB_STATIC_DISTANCE environment variable. [ 2007/10/11 18:43:59 INFO xorp_rtrmgr:18689 RTRMGR module_manager.cc:96 execute ] Executing module: policy (policy/xorp_policy) [ 2007/10/11 18:44:01 INFO xorp_rtrmgr:18689 RTRMGR module_manager.cc:96 execute ] Executing module: static_routes (static_routes/xorp_static_routes) [ 2007/10/11 18:44:03 INFO xorp_rtrmgr:18689 RTRMGR module_manager.cc:96 execute ] Executing module: ospf4 (ospf/xorp_ospfv2) [ 2007/10/11 18:44:06 TRACE xorp_ospfv2 OSPF ] Event(InterfaceUp) Interface(rddVR45/rddVR45) State(Down) [ 2007/10/11 18:44:06 TRACE xorp_ospfv2 OSPF ] Event(InterfaceUp) Interface(rddVR5/rddVR5) State(Down) [ 2007/10/11 18:44:06 INFO xorp_rtrmgr:18689 RTRMGR task.cc:2228 run_task ] No more tasks to run [ 2007/10/11 18:44:06 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(Init) [ 2007/10/11 18:44:06 TRACE xorp_ospfv2 OSPF ] Event(1-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(Init) [ 2007/10/11 18:44:16 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(Init) [ 2007/10/11 18:44:16 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(Init) [ 2007/10/11 18:44:35 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(TwoWay) [ 2007/10/11 18:44:35 TRACE xorp_ospfv2 OSPF ] Event(1-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(TwoWay) [ 2007/10/11 18:44:35 TRACE xorp_ospfv2 OSPF ] Event(NeighborChange) Interface(rddVR45/rddVR45) State(Waiting) [ 2007/10/11 18:44:35 WARNING xorp_ospfv2:19127 OSPF peer.cc:1891 event_neighbour_change ] Unexpected state Waiting [ 2007/10/11 18:44:45 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(Init) [ 2007/10/11 18:44:45 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(Init) [ 2007/10/11 18:44:46 TRACE xorp_ospfv2 OSPF ] Event(WaitTimer) Interface(rddVR45/rddVR45) State(Waiting) [ 2007/10/11 18:44:46 TRACE xorp_ospfv2 OSPF ] Start election: DR 0.0.0.0 BDR 0.0.0.0 [ 2007/10/11 18:44:46 TRACE xorp_ospfv2 OSPF ] Current BDR 0.0.0.0 [ 2007/10/11 18:44:46 TRACE xorp_ospfv2 OSPF ] Candidate: CID 10.4.0.2 RID 127.1.0.8 DR 0.0.0.0 BDR 0.0.0.0 PRI 0.0.0.128 [ 2007/10/11 18:44:46 TRACE xorp_ospfv2 OSPF ] Candidate: CID 10.4.0.7 RID 127.1.0.2 DR 0.0.0.0 BDR 0.0.0.0 PRI 0.0.0.128 [ 2007/10/11 18:44:46 TRACE xorp_ospfv2 OSPF ] New BDR 10.4.0.2 [ 2007/10/11 18:44:46 TRACE xorp_ospfv2 OSPF ] Current DR 0.0.0.0 [ 2007/10/11 18:44:46 TRACE xorp_ospfv2 OSPF ] Candidate: CID 10.4.0.2 RID 127.1.0.8 DR 0.0.0.0 BDR 0.0.0.0 PRI 0.0.0.128 [ 2007/10/11 18:44:46 TRACE xorp_ospfv2 OSPF ] Candidate: CID 10.4.0.7 RID 127.1.0.2 DR 0.0.0.0 BDR 0.0.0.0 PRI 0.0.0.128 [ 2007/10/11 18:44:46 TRACE xorp_ospfv2 OSPF ] New DR chose BDR 10.4.0.2 [ 2007/10/11 18:44:46 TRACE xorp_ospfv2 OSPF ] Current BDR 0.0.0.0 [ 2007/10/11 18:44:46 TRACE xorp_ospfv2 OSPF ] Candidate: CID 10.4.0.2 RID 127.1.0.8 DR 10.4.0.2 BDR 10.4.0.2 PRI 0.0.0.128 [ 2007/10/11 18:44:46 TRACE xorp_ospfv2 OSPF ] Candidate: CID 10.4.0.7 RID 127.1.0.2 DR 0.0.0.0 BDR 0.0.0.0 PRI 0.0.0.128 [ 2007/10/11 18:44:46 TRACE xorp_ospfv2 OSPF ] New BDR 10.4.0.7 [ 2007/10/11 18:44:46 TRACE xorp_ospfv2 OSPF ] Current DR 0.0.0.0 [ 2007/10/11 18:44:46 TRACE xorp_ospfv2 OSPF ] Candidate: CID 10.4.0.2 RID 127.1.0.8 DR 10.4.0.2 BDR 10.4.0.2 PRI 0.0.0.128 [ 2007/10/11 18:44:46 TRACE xorp_ospfv2 OSPF ] Candidate: CID 10.4.0.7 RID 127.1.0.2 DR 0.0.0.0 BDR 0.0.0.0 PRI 0.0.0.128 [ 2007/10/11 18:44:46 TRACE xorp_ospfv2 OSPF ] New DR 10.4.0.2 [ 2007/10/11 18:44:46 TRACE xorp_ospfv2 OSPF ] End election: DR 10.4.0.2 BDR 10.4.0.7 [ 2007/10/11 18:44:46 TRACE xorp_ospfv2 OSPF ] Event(AdjOK?) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(TwoWay) [ 2007/10/11 18:44:46 TRACE xorp_ospfv2 OSPF ] Event(WaitTimer) Interface(rddVR5/rddVR5) State(Waiting) [ 2007/10/11 18:44:46 TRACE xorp_ospfv2 OSPF ] Start election: DR 0.0.0.0 BDR 0.0.0.0 [ 2007/10/11 18:44:46 TRACE xorp_ospfv2 OSPF ] Current BDR 0.0.0.0 [ 2007/10/11 18:44:46 TRACE xorp_ospfv2 OSPF ] Candidate: CID 10.1.0.1 RID 127.1.0.8 DR 0.0.0.0 BDR 0.0.0.0 PRI 0.0.0.128 [ 2007/10/11 18:44:46 TRACE xorp_ospfv2 OSPF ] New BDR 10.1.0.1 [ 2007/10/11 18:44:46 TRACE xorp_ospfv2 OSPF ] Current DR 0.0.0.0 [ 2007/10/11 18:44:46 TRACE xorp_ospfv2 OSPF ] Candidate: CID 10.1.0.1 RID 127.1.0.8 DR 0.0.0.0 BDR 0.0.0.0 PRI 0.0.0.128 [ 2007/10/11 18:44:46 TRACE xorp_ospfv2 OSPF ] New DR chose BDR 10.1.0.1 [ 2007/10/11 18:44:46 TRACE xorp_ospfv2 OSPF ] Current BDR 0.0.0.0 [ 2007/10/11 18:44:46 TRACE xorp_ospfv2 OSPF ] Candidate: CID 10.1.0.1 RID 127.1.0.8 DR 10.1.0.1 BDR 10.1.0.1 PRI 0.0.0.128 [ 2007/10/11 18:44:46 TRACE xorp_ospfv2 OSPF ] New BDR 0.0.0.0 [ 2007/10/11 18:44:46 TRACE xorp_ospfv2 OSPF ] Current DR 0.0.0.0 [ 2007/10/11 18:44:46 TRACE xorp_ospfv2 OSPF ] Candidate: CID 10.1.0.1 RID 127.1.0.8 DR 10.1.0.1 BDR 10.1.0.1 PRI 0.0.0.128 [ 2007/10/11 18:44:46 TRACE xorp_ospfv2 OSPF ] New DR 10.1.0.1 [ 2007/10/11 18:44:46 TRACE xorp_ospfv2 OSPF ] End election: DR 10.1.0.1 BDR 0.0.0.0 [ 2007/10/11 18:44:55 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:44:55 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:45:05 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:45:05 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:45:15 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:45:15 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:45:15 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:45:15 TRACE xorp_ospfv2 OSPF ] Event(NeighborChange) Interface(rddVR45/rddVR45) State(DR) [ 2007/10/11 18:45:15 TRACE xorp_ospfv2 OSPF ] Start election: DR 10.4.0.2 BDR 10.4.0.7 [ 2007/10/11 18:45:15 TRACE xorp_ospfv2 OSPF ] Current BDR 10.4.0.7 [ 2007/10/11 18:45:15 TRACE xorp_ospfv2 OSPF ] Candidate: CID 10.4.0.2 RID 127.1.0.8 DR 10.4.0.2 BDR 10.4.0.7 PRI 0.0.0.128 [ 2007/10/11 18:45:15 TRACE xorp_ospfv2 OSPF ] Candidate: CID 10.4.0.7 RID 127.1.0.2 DR 10.4.0.2 BDR 10.4.0.7 PRI 0.0.0.128 [ 2007/10/11 18:45:15 TRACE xorp_ospfv2 OSPF ] New BDR 10.4.0.7 [ 2007/10/11 18:45:15 TRACE xorp_ospfv2 OSPF ] Current DR 10.4.0.2 [ 2007/10/11 18:45:15 TRACE xorp_ospfv2 OSPF ] Candidate: CID 10.4.0.2 RID 127.1.0.8 DR 10.4.0.2 BDR 10.4.0.7 PRI 0.0.0.128 [ 2007/10/11 18:45:15 TRACE xorp_ospfv2 OSPF ] Candidate: CID 10.4.0.7 RID 127.1.0.2 DR 10.4.0.2 BDR 10.4.0.7 PRI 0.0.0.128 [ 2007/10/11 18:45:15 TRACE xorp_ospfv2 OSPF ] New DR 10.4.0.2 [ 2007/10/11 18:45:15 TRACE xorp_ospfv2 OSPF ] End election: No change [ 2007/10/11 18:45:20 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:45:25 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:45:25 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:45:25 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:45:30 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:45:35 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:45:35 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:45:35 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:45:40 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:45:45 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:45:45 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:45:45 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:45:50 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:45:55 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:45:55 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:45:55 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:46:00 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:46:05 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:46:05 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:46:05 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:46:10 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:46:15 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:46:15 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:46:15 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:46:20 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:46:25 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:46:25 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:46:25 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:46:30 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:46:35 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:46:35 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:46:35 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:46:40 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:46:45 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:46:45 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:46:45 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:46:50 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:46:55 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:46:55 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:46:55 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:47:00 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:47:05 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:47:05 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:47:05 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:47:10 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:47:15 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:47:15 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:47:15 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:47:20 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:47:25 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:47:25 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:47:25 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:47:30 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:47:35 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:47:35 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:47:35 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:47:40 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:47:45 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:47:45 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:47:45 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:47:50 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:47:55 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:47:55 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:47:55 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:48:00 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:48:05 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:48:05 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:48:05 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:48:10 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:48:15 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:48:15 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:48:15 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:48:20 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:48:25 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:48:25 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:48:25 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:48:30 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:48:35 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:48:35 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:48:35 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:48:40 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:48:50 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:48:50 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:48:50 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:48:51 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:48:55 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:48:55 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:48:55 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:49:04 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:49:05 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:49:05 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:49:05 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:49:12 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:49:20 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:49:20 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:49:20 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:49:20 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:49:28 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:49:28 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:49:28 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:49:36 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:49:36 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:49:36 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:49:36 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:49:40 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:49:46 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:49:46 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:49:46 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:49:55 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:49:55 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:49:55 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:49:55 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:50:00 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:50:09 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:50:09 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:50:09 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:50:10 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:50:17 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:50:17 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:50:17 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:50:26 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:50:26 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:50:26 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:50:26 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:50:31 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:50:40 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:50:40 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:50:40 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:50:40 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:50:45 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:50:45 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:50:45 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:50:54 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:50:55 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:50:55 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:50:55 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:51:01 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:51:06 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:51:06 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:51:06 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:51:14 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:51:15 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:51:15 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:51:15 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:51:22 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:51:30 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:51:30 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:51:30 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:51:30 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:51:35 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:51:35 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:51:35 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:51:45 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:51:45 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:51:45 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:51:45 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:51:55 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:51:55 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:51:55 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:51:55 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:52:03 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:52:05 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:52:05 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:52:05 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:52:11 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:52:20 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:52:20 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:52:20 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:52:20 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:52:26 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:52:26 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:52:26 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:52:35 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:52:35 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:52:35 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:52:35 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:52:40 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:52:45 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:52:45 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:52:45 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:52:50 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:52:55 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:52:55 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:52:55 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:53:00 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:53:05 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:53:05 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:53:05 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:53:10 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:53:15 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) [ 2007/10/11 18:53:15 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR45/rddVR45) Neighbour(10.4.0.7) State(ExStart) -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Thu Oct 11 19:44:34 2007 From: greearb at candelatech.com (Ben Greear) Date: Thu, 11 Oct 2007 19:44:34 -0700 Subject: [Xorp-hackers] OSPF assert because multicast interface not properly removed from interface on interface delete. Message-ID: <470EDF92.5020502@candelatech.com> Continuing on with my testing: After waiting proper amount of time for OSPF instances to go to state Full, I changed interfaces & neighbours. This worked fine. I then waited for the state to go back to Full and changed interfaces again. This time, I get an ospfv2 core file due to an assert. It looks like the root cause might be that the previous owner didn't remove the multicast address properly because it couldn't find the interface. Maybe this is another race with deleted interfaces? As a potential work-around, is there any way to get rtrmgr to restart the xorp process, or exit cleanly so that the entire rtrmgr can be restarted? Here is the previous owner's log: [ 2007/10/11 19:30:27 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR1/rddVR1) Neighbour(10.0.0.1) State(Full) [ 2007/10/11 19:30:27 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR1/rddVR1) Neighbour(10.0.0.1) State(Full) [ 2007/10/11 19:30:33 TRACE xorp_ospfv2 OSPF ] Event(InterfaceDown) Interface(rddVR44/rddVR44) State(Backup) [ 2007/10/11 19:30:33 TRACE xorp_ospfv2 OSPF ] Event(KillNbr) Interface(rddVR44/rddVR44) Neighbour(10.4.0.2) State(Full) [ 2007/10/11 19:30:33 INFO xorp_rtrmgr:22031 RTRMGR task.cc:2228 run_task ] No more tasks to run [ 2007/10/11 19:30:33 WARNING xorp_fea XrlFeaTarget ] Handling method for raw_packet4/0.1/leave_multicast_group failed: XrlCmdError 102 Command failed Leaving multicast group 224.0.0.6 failed: interface rddVR44 vif rddVR44 not found [ 2007/10/11 19:30:33 WARNING xorp_fea XrlFeaTarget ] Handling method for raw_packet4/0.1/send failed: XrlCmdError 102 Command failed No interface rddVR44 [ 2007/10/11 19:30:33 WARNING xorp_fea XrlFeaTarget ] Handling method for raw_packet4/0.1/leave_multicast_group failed: XrlCmdError 102 Command failed Leaving multicast group 224.0.0.5 failed: interface rddVR44 vif rddVR44 not found [ 2007/10/11 19:30:33 ERROR xorp_ospfv2:22481 OSPF xrl_io.cc:721 leave_multicast_group_cb ] Cannot leave a multicast group on interface rddVR44 vif rddVR44: 102 Command failed Leaving multicast group 224.0.0.6 failed: interface rddVR44 vif rddVR44 not found [ 2007/10/11 19:30:33 ERROR xorp_ospfv2:22481 OSPF xrl_io.cc:188 send_cb ] Cannot send a packet on interface rddVR44 vif rddVR44: 102 Command failed No interface rddVR44 [ 2007/10/11 19:30:33 ERROR xorp_ospfv2:22481 OSPF xrl_io.cc:721 leave_multicast_group_cb ] Cannot leave a multicast group on interface rddVR44 vif rddVR44: 102 Command failed Leaving multicast group 224.0.0.5 failed: interface rddVR44 vif rddVR44 not found [ 2007/10/11 19:30:33 TRACE xorp_ospfv2 OSPF ] Event(LinkStateAcknowledgementReceived-pseudo-event) Interface(rddVR1/rddVR1) Neighbour(10.0.0.1) State(Full) [ 2007/10/11 19:30:34 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.1.0.255(0xa0100ff) 0.0.0.0(0) not reachable [ 2007/10/11 19:30:34 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.4.0.2(0xa040002) 0.0.0.0(0) not reachable [ 2007/10/11 19:30:34 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router 127.1.0.8(0x7f010008) 0.0.0.0(0) not reachable [ 2007/10/11 19:30:34 TRACE xorp_ospfv2 OSPF ] Checking for virtual links Router-LSA: LS age 19 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link State ID 127.1.0.2 Advertising Router 127.1.0.2 LS sequence number 0x80000005 LS checksum 0x33c5 length 60 bit Nt false bit V false bit E false bit B false Type 2 Transit network IP address of Designated router 10.0.0.1 Routers interface address 10.0.0.1 Metric 1 Type 3 Stub network Subnet number 10.2.0.0 Mask 255.255.255.0 Metric 1 Type 3 Stub network Subnet number 10.3.0.0 Mask 255.255.255.0 Metric 1 [ 2007/10/11 19:30:34 TRACE xorp_ospfv2 OSPF ] Delete route Net 10.1.0.0/24 Here is the log for the router that gained the interface and then asserted. .... [ 2007/10/11 19:30:27 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR0/rddVR0) Neighbour(10.0.0.2) State(Full) [ 2007/10/11 19:30:27 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR0/rddVR0) Neighbour(10.0.0.2) State(Full) [ 2007/10/11 19:30:33 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(rddVR0/rddVR0) Neighbour(10.0.0.2) State(Full) [ 2007/10/11 19:30:34 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.1.0.255(0xa0100ff) 0.0.0.0(0) not reachable [ 2007/10/11 19:30:34 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.4.0.2(0xa040002) 0.0.0.0(0) not reachable [ 2007/10/11 19:30:34 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router 127.1.0.8(0x7f010008) 0.0.0.0(0) not reachable [ 2007/10/11 19:30:34 TRACE xorp_ospfv2 OSPF ] Checking for virtual links Router-LSA: LS age 1 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link State ID 127.1.0.1 Advertising Router 127.1.0.1 LS sequence number 0x80000005 LS checksum 0x87ad length 36 bit Nt false bit V false bit E false bit B false Type 2 Transit network IP address of Designated router 10.0.0.1 Routers interface address 10.0.0.2 Metric 1 [ 2007/10/11 19:30:34 TRACE xorp_ospfv2 OSPF ] Delete route Net 10.1.0.0/24 [ 2007/10/11 19:30:34 TRACE xorp_ospfv2 OSPF ] Delete route Net 10.4.0.0/24 [ 2007/10/11 19:30:37 INFO xorp_rtrmgr:22040 RTRMGR task.cc:2228 run_task ] No more tasks to run [ 2007/10/11 19:30:37 TRACE xorp_ospfv2 OSPF ] Event(LinkStateAcknowledgementReceived-pseudo-event) Interface(rddVR0/rddVR0) Neighbour(10.0.0.2) State(Full) [ 2007/10/11 19:30:37 ERROR xorp_rib:22367 RIB rib.cc:695 add_vif_address ] Attempting to add address to non-existant Vif "rddVR44" [ 2007/10/11 19:30:37 ERROR xorp_rib:22367 RIB vifmanager.cc:520 updates_made ] Cannot add address 10.4.0.7 to vif rddVR44 from the set of configured vifs: Failed to add VIF address 10.4.0.7 to Unicast IPv4 RIB [ 2007/10/11 19:30:37 TRACE xorp_ospfv2 OSPF ] Event(InterfaceUp) Interface(rddVR44/rddVR44) State(Down) [ 2007/10/11 19:30:37 WARNING xorp_fea XrlFeaTarget ] Handling method for raw_packet4/0.1/join_multicast_group failed: XrlCmdError 102 Command failed Cannot join group 224.0.0.5 on interface rddVR44 vif rddVR44: Address already in use [ 2007/10/11 19:30:37 FATAL xorp_ospfv2:22478 OSPF xrl_io.cc:638 join_multicast_group_cb ] Cannot join a multicast group on interface rddVR44 vif rddVR44: 102 Command failed Cannot join group 224.0.0.5 on interface rddVR44 vif rddVR44: Address already in use [ 2007/10/11 19:30:37 ERROR xorp_rtrmgr:22040 RTRMGR module_manager.cc:747 done_cb ] Command "/usr/local/xorp/ospf/xorp_ospfv2": terminated with signal 6; aborted with a core dump. [ 2007/10/11 19:30:37 INFO xorp_rtrmgr:22040 RTRMGR module_manager.cc:291 module_exited ] Module coredumped: ospf4 [ 2007/10/11 19:30:37 INFO xorp_rib RIB ] Received death event for protocol ospfv2 shutting down ------- OriginTable: ospf IGP next table = Redist:ospf [ 2007/10/11 19:30:37 INFO xorp_rib RIB ] Received death event for protocol ospfv2 shutting down ------- OriginTable: ospf IGP next table = Redist:ospf [ 2007/10/11 19:30:37 INFO xorp_rib RIB ] Received death event for protocol ospfv2 shutting down ------- OriginTable: ospf IGP next table = Redist:ospf [ 2007/10/11 19:30:37 INFO xorp_rib RIB ] Received death event for protocol ospfv2 shutting down ------- OriginTable: ospf IGP next table = Redist:ospf [ 2007/10/11 19:30:39 INFO xorp_rtrmgr:22040 RTRMGR task.cc:2228 run_task ] No more tasks to run Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From arjun at ceeyes.com Thu Oct 11 22:07:55 2007 From: arjun at ceeyes.com (arjun at ceeyes.com) Date: Fri, 12 Oct 2007 01:07:55 -0400 Subject: [Xorp-hackers] WANTS TO TEST THE RIP Message-ID: <380-22007105125755848@M2W004.mail2web.com> Hi all! I have downloaded the live CD. Now i want to configure it for RIP only. What are the diffrent other things i need to configure in order to run this CD as router. Also tell me the minimum physical environmrnt(network) i need to test this router(CD with configured RIP only). Regards, Arjun -------------------------------------------------------------------- mail2web.com ? What can On Demand Business Solutions do for you? http://link.mail2web.com/Business/SharePoint From pavlin at icir.org Thu Oct 11 22:48:27 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 11 Oct 2007 22:48:27 -0700 Subject: [Xorp-hackers] WANTS TO TEST THE RIP In-Reply-To: Message from "arjun@ceeyes.com" of "Fri, 12 Oct 2007 01:07:55 EDT." <380-22007105125755848@M2W004.mail2web.com> Message-ID: <200710120548.l9C5mRk7001876@possum.icir.org> > I have downloaded the live CD. > Now i want to configure it for RIP only. > > What are the diffrent other things i need to configure in order to run this > CD as router. You need to configure the network interfaces (the "interfaces" configuration section), and you need to enable unicast forwarding (inside the "fea" section). If you need to use routing policy or to advertise, say static or connected routes, then you need to configure the policy as well. > Also tell me the minimum physical environmrnt(network) i need to test this > router(CD with configured RIP only). It depends what you need to test. The simplest topology would be two PCs connected with a single subnet between them. Hope that helps, Pavlin From atanu at ICSI.Berkeley.EDU Fri Oct 12 00:51:02 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Fri, 12 Oct 2007 00:51:02 -0700 Subject: [Xorp-hackers] OSPF doesn't deal well with changing interfaces/neighbors if not currently in state FULL. In-Reply-To: Message from Ben Greear of "Thu, 11 Oct 2007 19:28:15 PDT." <470EDBBF.3010801@candelatech.com> Message-ID: <48152.1192175462@tigger.icir.org> >>>>> "Ben" == Ben Greear writes: Ben> I notice that if I run xorpsh commands too soon after starting Ben> xorp, the OSPF routers get stuck in ExStart state. However, Ben> if I wait till they go to Full state, then it seems to work properly Ben> when interfaces & neighbours are changed. Ben> Here is output of two stuck routers: Hi, This is how OSPF works, when OSPF is first enabled on an interface the interface goes into state Waiting for time RouterDeadInterval (default 40 seconds). No DR election or attempt to form adjancies will occur until this time has expired. The only shortcut is if one of the neigbhours has choosen itself as the DR and the BDR is zero, or if a neighbour selects this router as the DR. This delay is to stop any unnecessary changes of the DR or BDR. Once this initial Waiting state has passed OSPF will become much more reactive. I noticed from your trace that there is a hello packet missing at time [ 2007/10/11 18:44:26 ], so you seem to have some other problems. Plus I suspect the other router has lost a number of hello messages. On the bright side from looking at your trace I now understand what is causing this warning: [ 2007/10/11 18:44:35 WARNING xorp_ospfv2:19127 OSPF peer.cc:1891 event_neighbour_change ] Unexpected state Waiting Atanu. From atanu at ICSI.Berkeley.EDU Fri Oct 12 01:07:52 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Fri, 12 Oct 2007 01:07:52 -0700 Subject: [Xorp-hackers] OSPF assert because multicast interface not properly removed from interface on interface delete. In-Reply-To: Message from Ben Greear of "Thu, 11 Oct 2007 19:44:34 PDT." <470EDF92.5020502@candelatech.com> Message-ID: <52295.1192176472@tigger.icir.org> Hi, You can delete the whole configuration and put it back this will stop and restart all the processes. What you need is a restart command that can be given a part of the configuration tree that can delete and then put back the configuration. You can emulate this behaviour by using the save command to save the config, then delete the config, followed by loading the saved config. Atanu. >>>>> "Ben" == Ben Greear writes: Ben> Continuing on with my testing: After waiting proper amount of time Ben> for OSPF instances to go to state Full, I changed interfaces & neighbours. Ben> This worked fine. Ben> I then waited for the state to go back to Full and changed interfaces again. Ben> This time, I get an ospfv2 core file due to an assert. Ben> It looks like the root cause might be that the previous owner didn't remove Ben> the multicast address properly because it couldn't find the interface. Maybe Ben> this is another race with deleted interfaces? Ben> As a potential work-around, is there any way to get rtrmgr to restart Ben> the xorp process, or exit cleanly so that the entire rtrmgr can be restarted? Ben> Here is the previous owner's log: Ben> [ 2007/10/11 19:30:27 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR1/rddVR1) Neighbour(10.0.0.1) State(Full) Ben> [ 2007/10/11 19:30:27 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR1/rddVR1) Neighbour(10.0.0.1) State(Full) Ben> [ 2007/10/11 19:30:33 TRACE xorp_ospfv2 OSPF ] Event(InterfaceDown) Interface(rddVR44/rddVR44) State(Backup) Ben> [ 2007/10/11 19:30:33 TRACE xorp_ospfv2 OSPF ] Event(KillNbr) Interface(rddVR44/rddVR44) Neighbour(10.4.0.2) State(Full) Ben> [ 2007/10/11 19:30:33 INFO xorp_rtrmgr:22031 RTRMGR task.cc:2228 run_task ] No more tasks to run Ben> [ 2007/10/11 19:30:33 WARNING xorp_fea XrlFeaTarget ] Handling method for raw_packet4/0.1/leave_multicast_group failed: XrlCmdError 102 Command failed Leaving multicast group 224.0.0.6 failed: interface rddVR44 vif rddVR44 not found Ben> [ 2007/10/11 19:30:33 WARNING xorp_fea XrlFeaTarget ] Handling method for raw_packet4/0.1/send failed: XrlCmdError 102 Command failed No interface rddVR44 Ben> [ 2007/10/11 19:30:33 WARNING xorp_fea XrlFeaTarget ] Handling method for raw_packet4/0.1/leave_multicast_group failed: XrlCmdError 102 Command failed Leaving multicast group 224.0.0.5 failed: interface rddVR44 vif rddVR44 not found Ben> [ 2007/10/11 19:30:33 ERROR xorp_ospfv2:22481 OSPF xrl_io.cc:721 leave_multicast_group_cb ] Cannot leave a multicast group on interface rddVR44 vif rddVR44: 102 Command failed Leaving multicast group 224.0.0.6 failed: interface rddVR44 vif rddVR44 not found Ben> [ 2007/10/11 19:30:33 ERROR xorp_ospfv2:22481 OSPF xrl_io.cc:188 send_cb ] Cannot send a packet on interface rddVR44 vif rddVR44: 102 Command failed No interface rddVR44 Ben> [ 2007/10/11 19:30:33 ERROR xorp_ospfv2:22481 OSPF xrl_io.cc:721 leave_multicast_group_cb ] Cannot leave a multicast group on interface rddVR44 vif rddVR44: 102 Command failed Leaving multicast group 224.0.0.5 failed: interface rddVR44 vif rddVR44 not found Ben> [ 2007/10/11 19:30:33 TRACE xorp_ospfv2 OSPF ] Event(LinkStateAcknowledgementReceived-pseudo-event) Interface(rddVR1/rddVR1) Neighbour(10.0.0.1) State(Full) Ben> [ 2007/10/11 19:30:34 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.1.0.255(0xa0100ff) 0.0.0.0(0) not reachable Ben> [ 2007/10/11 19:30:34 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.4.0.2(0xa040002) 0.0.0.0(0) not reachable Ben> [ 2007/10/11 19:30:34 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router 127.1.0.8(0x7f010008) 0.0.0.0(0) not reachable Ben> [ 2007/10/11 19:30:34 TRACE xorp_ospfv2 OSPF ] Checking for virtual links Router-LSA: Ben> LS age 19 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link State ID 127.1.0.2 Advertising Router 127.1.0.2 LS sequence number 0x80000005 LS checksum 0x33c5 length 60 Ben> bit Nt false Ben> bit V false Ben> bit E false Ben> bit B false Ben> Type 2 Transit network IP address of Designated router 10.0.0.1 Routers interface address 10.0.0.1 Metric 1 Ben> Type 3 Stub network Subnet number 10.2.0.0 Mask 255.255.255.0 Metric 1 Ben> Type 3 Stub network Subnet number 10.3.0.0 Mask 255.255.255.0 Metric 1 Ben> [ 2007/10/11 19:30:34 TRACE xorp_ospfv2 OSPF ] Delete route Net 10.1.0.0/24 Ben> Here is the log for the router that gained the interface and then asserted. Ben> .... Ben> [ 2007/10/11 19:30:27 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(rddVR0/rddVR0) Neighbour(10.0.0.2) State(Full) Ben> [ 2007/10/11 19:30:27 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(rddVR0/rddVR0) Neighbour(10.0.0.2) State(Full) Ben> [ 2007/10/11 19:30:33 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(rddVR0/rddVR0) Neighbour(10.0.0.2) State(Full) Ben> [ 2007/10/11 19:30:34 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.1.0.255(0xa0100ff) 0.0.0.0(0) not reachable Ben> [ 2007/10/11 19:30:34 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.4.0.2(0xa040002) 0.0.0.0(0) not reachable Ben> [ 2007/10/11 19:30:34 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router 127.1.0.8(0x7f010008) 0.0.0.0(0) not reachable Ben> [ 2007/10/11 19:30:34 TRACE xorp_ospfv2 OSPF ] Checking for virtual links Router-LSA: Ben> LS age 1 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link State ID 127.1.0.1 Advertising Router 127.1.0.1 LS sequence number 0x80000005 LS checksum 0x87ad length 36 Ben> bit Nt false Ben> bit V false Ben> bit E false Ben> bit B false Ben> Type 2 Transit network IP address of Designated router 10.0.0.1 Routers interface address 10.0.0.2 Metric 1 Ben> [ 2007/10/11 19:30:34 TRACE xorp_ospfv2 OSPF ] Delete route Net 10.1.0.0/24 Ben> [ 2007/10/11 19:30:34 TRACE xorp_ospfv2 OSPF ] Delete route Net 10.4.0.0/24 Ben> [ 2007/10/11 19:30:37 INFO xorp_rtrmgr:22040 RTRMGR task.cc:2228 run_task ] No more tasks to run Ben> [ 2007/10/11 19:30:37 TRACE xorp_ospfv2 OSPF ] Event(LinkStateAcknowledgementReceived-pseudo-event) Interface(rddVR0/rddVR0) Neighbour(10.0.0.2) State(Full) Ben> [ 2007/10/11 19:30:37 ERROR xorp_rib:22367 RIB rib.cc:695 add_vif_address ] Attempting to add address to non-existant Vif "rddVR44" Ben> [ 2007/10/11 19:30:37 ERROR xorp_rib:22367 RIB vifmanager.cc:520 updates_made ] Cannot add address 10.4.0.7 to vif rddVR44 from the set of configured vifs: Failed to add VIF address 10.4.0.7 to Unicast IPv4 RIB Ben> [ 2007/10/11 19:30:37 TRACE xorp_ospfv2 OSPF ] Event(InterfaceUp) Interface(rddVR44/rddVR44) State(Down) Ben> [ 2007/10/11 19:30:37 WARNING xorp_fea XrlFeaTarget ] Handling method for raw_packet4/0.1/join_multicast_group failed: XrlCmdError 102 Command failed Cannot join group 224.0.0.5 on interface rddVR44 vif rddVR44: Address already in use Ben> [ 2007/10/11 19:30:37 FATAL xorp_ospfv2:22478 OSPF xrl_io.cc:638 join_multicast_group_cb ] Cannot join a multicast group on interface rddVR44 vif rddVR44: 102 Command failed Cannot join group 224.0.0.5 on interface rddVR44 vif rddVR44: Address already in use Ben> [ 2007/10/11 19:30:37 ERROR xorp_rtrmgr:22040 RTRMGR module_manager.cc:747 done_cb ] Command "/usr/local/xorp/ospf/xorp_ospfv2": terminated with signal 6; aborted with a core dump. Ben> [ 2007/10/11 19:30:37 INFO xorp_rtrmgr:22040 RTRMGR module_manager.cc:291 module_exited ] Module coredumped: ospf4 Ben> [ 2007/10/11 19:30:37 INFO xorp_rib RIB ] Received death event for protocol ospfv2 shutting down ------- Ben> OriginTable: ospf Ben> IGP Ben> next table = Redist:ospf Ben> [ 2007/10/11 19:30:37 INFO xorp_rib RIB ] Received death event for protocol ospfv2 shutting down ------- Ben> OriginTable: ospf Ben> IGP Ben> next table = Redist:ospf Ben> [ 2007/10/11 19:30:37 INFO xorp_rib RIB ] Received death event for protocol ospfv2 shutting down ------- Ben> OriginTable: ospf Ben> IGP Ben> next table = Redist:ospf Ben> [ 2007/10/11 19:30:37 INFO xorp_rib RIB ] Received death event for protocol ospfv2 shutting down ------- Ben> OriginTable: ospf Ben> IGP Ben> next table = Redist:ospf Ben> [ 2007/10/11 19:30:39 INFO xorp_rtrmgr:22040 RTRMGR task.cc:2228 run_task ] No more tasks to run Ben> Thanks, Ben> Ben Ben> -- Ben> Ben Greear Ben> Candela Technologies Inc http://www.candelatech.com Ben> _______________________________________________ Ben> Xorp-hackers mailing list Ben> Xorp-hackers at icir.org Ben> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From zhj.zhao at gmail.com Fri Oct 12 05:30:25 2007 From: zhj.zhao at gmail.com (jerry zhao) Date: Fri, 12 Oct 2007 14:30:25 +0200 Subject: [Xorp-hackers] Does any router vendor provide source code of their router software? Message-ID: Hello, first I am sorry for this unprofessional question. But I realy want to get some information about it. If anyone knows that any vendor provides source code of router software, please tell me. Thanks. Best regards. Jerry -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20071012/e01728b5/attachment-0001.html From zhj.zhao at gmail.com Fri Oct 12 08:22:14 2007 From: zhj.zhao at gmail.com (jerry zhao) Date: Fri, 12 Oct 2007 17:22:14 +0200 Subject: [Xorp-hackers] Can the router send some information to end system? Message-ID: Hello, all I am a newie with router software. I hope that someone could help me. It is supposed that there exists the following scenario: server<- - - ->router<- - - - ->client Can the router send some information ( e.g. its buffer state) to the server? Any advice is appreciated. Thanks. Best regards Jerry -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20071012/2d4cda16/attachment.html From greearb at candelatech.com Fri Oct 12 10:39:45 2007 From: greearb at candelatech.com (Ben Greear) Date: Fri, 12 Oct 2007 10:39:45 -0700 Subject: [Xorp-hackers] Patch to fix compile breakage. Message-ID: <470FB161.8030204@candelatech.com> Index: data_plane/ifconfig/ifconfig_set_netlink_socket.cc =================================================================== RCS file: /cvs/xorp/fea/data_plane/ifconfig/ifconfig_set_netlink_socket.cc,v retrieving revision 1.15 diff -r1.15 ifconfig_set_netlink_socket.cc 96c96 < if (NetlinkSocket::stop(error_msg) !+ XORP_OK) --- > if (NetlinkSocket::stop(error_msg) != XORP_OK) cvs diff: Diffing data_plane/io Index: data_plane/io/io_ip_socket.cc -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Fri Oct 12 10:55:38 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 12 Oct 2007 10:55:38 -0700 Subject: [Xorp-hackers] Patch to fix compile breakage. In-Reply-To: Message from Ben Greear of "Fri, 12 Oct 2007 10:39:45 PDT." <470FB161.8030204@candelatech.com> Message-ID: <200710121755.l9CHtcmH007999@possum.icir.org> Ben Greear wrote: > Index: data_plane/ifconfig/ifconfig_set_netlink_socket.cc > =================================================================== > RCS file: /cvs/xorp/fea/data_plane/ifconfig/ifconfig_set_netlink_socket.cc,v > retrieving revision 1.15 > diff -r1.15 ifconfig_set_netlink_socket.cc > 96c96 > < if (NetlinkSocket::stop(error_msg) !+ XORP_OK) > --- > > if (NetlinkSocket::stop(error_msg) != XORP_OK) > cvs diff: Diffing data_plane/io > Index: data_plane/io/io_ip_socket.cc Fixed in CVS. Thanks, Pavlin From greearb at candelatech.com Fri Oct 12 13:52:17 2007 From: greearb at candelatech.com (Ben Greear) Date: Fri, 12 Oct 2007 13:52:17 -0700 Subject: [Xorp-hackers] xorpsh crash In-Reply-To: <200710121857.l9CIvI8d008443@possum.icir.org> References: <200710121857.l9CIvI8d008443@possum.icir.org> Message-ID: <470FDE81.4060905@candelatech.com> The _node copy constructor does not seem to be implemented, so it's just doing a blind copy of members, including the _list. Maybe this is keeping us from unregistering properly. The patch below makes it crash somewhere else, at least. I'm not sure if the new crash is because of the fix below or if the bug was always there. I'm going to try to use the 'valgrind' tool to figure out where the memory corruption is occuring... RCS file: /cvs/xorp/cli/cli_node_net.cc,v retrieving revision 1.65 diff -u -r1.65 cli_node_net.cc --- cli_node_net.cc 12 Oct 2007 07:53:45 -0000 1.65 +++ cli_node_net.cc 12 Oct 2007 20:48:54 -0000 @@ -896,6 +896,9 @@ // XXX: Schedule the processing after 10ms to avoid increasing // the CPU usage. // + // Unschedule before we copy over the list pointer, etc. + _process_pending_input_data_timer.unschedule(); + _process_pending_input_data_timer = eventloop.new_oneoff_after( TimeVal(0, 10), cb, -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Fri Oct 12 15:18:19 2007 From: greearb at candelatech.com (Ben Greear) Date: Fri, 12 Oct 2007 15:18:19 -0700 Subject: [Xorp-hackers] xorpsh crash In-Reply-To: <470FDE81.4060905@candelatech.com> References: <200710121857.l9CIvI8d008443@possum.icir.org> <470FDE81.4060905@candelatech.com> Message-ID: <470FF2AB.1010008@candelatech.com> Ok, the CLI code is harder to fix that I thought it would be! It seems that when you type 'exit', the RouterCLI::logout_func() is called, which then calls _cli_node.delete_client But, that client that it's deleting originally called the method, so we end up referencing stale memory when we return back up the call-stack. Here's the stack reported by valgrind. The line numbers might be slightly off due to debugging code I added. ==29005== Address 0x48932D2 is 330 bytes inside a block of size 356 free'd ==29005== at 0x4004E26: operator delete(void*) (vg_replace_malloc.c:244) ==29005== by 0x80D4D43: CliClient::~CliClient() (cli_client.cc:193) ==29005== by 0x80E225B: CliNode::delete_client(CliClient*, std::string&) (cli_node.cc:635) ==29005== by 0x80548ED: RouterCLI::logout_func(std::string const&, std::string const&, unsigned, std::vector > const&, std::vector > const&) (cli.cc:1878) ==29005== by 0x806D332: XorpMemberCallback5B0 > const&, std::vector > const&>::dispatch(std::string const&, std::string const&, unsigned, std::vector > const&, std::vector > const&) (callback_nodebug.hh:11110) ==29005== by 0x80D224E: CliClient::process_command(std::string const&) (cli_client.cc:1520) ==29005== by 0x80D3375: CliClient::process_char(std::string const&, unsigned char, bool&) (cli_client.cc:1234) ==29005== by 0x80EBA3D: CliClient::process_input_data() (cli_node_net.cc:849) ==29005== by 0x80EBE4F: CliClient::client_read(XorpFd, IoEventType) (cli_node_net.cc:764) ==29005== by 0x80EDB31: XorpMemberCallback2B0::dispatch(XorpFd, IoEventType) (callback_nodebug.hh:4635) ==29005== by 0x8185551: SelectorList::Node::run_hooks(SelectorMask, XorpFd) (selector.cc:149) ==29005== by 0x8184298: SelectorList::wait_and_dispatch(TimeVal&) (selector.cc:435) -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Fri Oct 12 15:57:38 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 12 Oct 2007 15:57:38 -0700 Subject: [Xorp-hackers] xorpsh crash In-Reply-To: Message from Ben Greear of "Fri, 12 Oct 2007 13:52:17 PDT." <470FDE81.4060905@candelatech.com> Message-ID: <200710122257.l9CMvcH4010283@possum.icir.org> Ben Greear wrote: > The _node copy constructor does not seem to be implemented, > so it's just doing a blind copy of members, including the _list. > Maybe this is keeping us from unregistering properly. > > The patch below makes it crash somewhere else, at least. > I'm not sure if the new crash is because of the fix below > or if the bug was always there. This explicit unschedule() shouldn't be necessary, because the XorpTimer assignment should automatically unschedule the previous timer (if it is still running). Pavlin > I'm going to try to use the 'valgrind' tool to figure out > where the memory corruption is occuring... > > > RCS file: /cvs/xorp/cli/cli_node_net.cc,v > retrieving revision 1.65 > diff -u -r1.65 cli_node_net.cc > --- cli_node_net.cc 12 Oct 2007 07:53:45 -0000 1.65 > +++ cli_node_net.cc 12 Oct 2007 20:48:54 -0000 > @@ -896,6 +896,9 @@ > // XXX: Schedule the processing after 10ms to avoid increasing > // the CPU usage. > // > + // Unschedule before we copy over the list pointer, etc. > + _process_pending_input_data_timer.unschedule(); > + > _process_pending_input_data_timer = eventloop.new_oneoff_after( > TimeVal(0, 10), > cb, > > > -- > 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 pavlin at icir.org Fri Oct 12 16:13:36 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 12 Oct 2007 16:13:36 -0700 Subject: [Xorp-hackers] xorpsh crash In-Reply-To: Message from Ben Greear of "Fri, 12 Oct 2007 15:18:19 PDT." <470FF2AB.1010008@candelatech.com> Message-ID: <200710122313.l9CNDabI010512@possum.icir.org> A non-text attachment was scrubbed... Name: xorpsh_cli.patch Type: text/x-c++ Size: 4053 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20071012/7e431129/attachment.bin From greearb at candelatech.com Fri Oct 12 16:17:57 2007 From: greearb at candelatech.com (Ben Greear) Date: Fri, 12 Oct 2007 16:17:57 -0700 Subject: [Xorp-hackers] xorpsh crash In-Reply-To: <200710122313.l9CNDabI010512@possum.icir.org> References: <200710122313.l9CNDabI010512@possum.icir.org> Message-ID: <471000A5.4050902@candelatech.com> Pavlin Radoslavov wrote: > Please apply the patch below and see whether it solves the stale > memory problem and/or some of the earlier problems. I took a different path but my fix is somewhat similar. I'm tracking down some more memory leaks found by valgrind and hope to have a patch for review within the hour. I'll post my patch, but if you prefer your method (and it works), then that is fine too. Did you get a chance to look at the bug_catcher logic? Any interest in adding that? I think it will be useful for catching future bugs & debugging core files. It's especially nice for core files because you can print out the 'magic' member and see if an item has been deleted or not.... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Fri Oct 12 16:20:26 2007 From: greearb at candelatech.com (Ben Greear) Date: Fri, 12 Oct 2007 16:20:26 -0700 Subject: [Xorp-hackers] TimerList destructor leaking memory? Message-ID: <4710013A.5050600@candelatech.com> It seems that the TimerList object (timer.cc) doesn't delete the members in it's _heaplist in the destructor. Are these supposed to be cleaned up somewhere else? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Fri Oct 12 17:08:18 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 12 Oct 2007 17:08:18 -0700 Subject: [Xorp-hackers] xorpsh crash In-Reply-To: Message from Ben Greear of "Fri, 12 Oct 2007 16:17:57 PDT." <471000A5.4050902@candelatech.com> Message-ID: <200710130008.l9D08I3D051845@possum.icir.org> Ben Greear wrote: > Pavlin Radoslavov wrote: > > > Please apply the patch below and see whether it solves the stale > > memory problem and/or some of the earlier problems. > > I took a different path but my fix is somewhat similar. > > I'm tracking down some more memory leaks found by valgrind > and hope to have a patch for review within the hour. I'll > post my patch, but if you prefer your method (and it works), > then that is fine too. OK, I will wait for your patch and compare it with what I have before committing anything. > Did you get a chance to look at the bug_catcher logic? Any > interest in adding that? I think it will be useful for > catching future bugs & debugging core files. It's especially > nice for core files because you can print out the 'magic' member > and see if an item has been deleted or not.... I looked into it, but the downside of a solution like this is you have to modify the source code in the exact location you think there is a problem. Also, the only problem it seems to solve is deleting an object that has been deleted previously. This obviously makes its applicability very limited and I am not sure how much effort will be saved by using it. In fact, given that it typically requires modification of the *.hh header file with the class declaration, it might actually slow you down waiting for everything that depends on that header file to compile. Myself I am using similar hacks from time to time, but typically few simple "XLOG_INFO()" print messages are sufficient to tell me whether I am looking into the right direction. If it seems the problem is memory-related, then tools like valgrind should be used instead. Said that, I don't think we should push it into XORP because it might be of little value to other developers. Thanks, Pavlin From pavlin at icir.org Fri Oct 12 17:34:31 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 12 Oct 2007 17:34:31 -0700 Subject: [Xorp-hackers] TimerList destructor leaking memory? In-Reply-To: Message from Ben Greear of "Fri, 12 Oct 2007 16:20:26 PDT." <4710013A.5050600@candelatech.com> Message-ID: <200710130034.l9D0YVlp052065@possum.icir.org> Ben Greear wrote: > It seems that the TimerList object (timer.cc) > doesn't delete the members in it's _heaplist > in the destructor. > > Are these supposed to be cleaned up somewhere else? I think you are right, it seems the Heap objects on the _heaplist are not deleted when TimerList destructor is invoked. The Heap objects are alocated only inside TimerList::find_heap() and the _heaplist management/access is internal to TimerList only, so the TimerList destructor should delete the leftover. The fix for that will be trivial, but lets address it after the pending two xorpsh related patches are out of the way. Thanks, Pavlin From greearb at candelatech.com Fri Oct 12 17:45:22 2007 From: greearb at candelatech.com (Ben Greear) Date: Fri, 12 Oct 2007 17:45:22 -0700 Subject: [Xorp-hackers] TimerList destructor leaking memory? In-Reply-To: <200710130034.l9D0YVlp052065@possum.icir.org> References: <200710130034.l9D0YVlp052065@possum.icir.org> Message-ID: <47101522.1050907@candelatech.com> Pavlin Radoslavov wrote: > Ben Greear wrote: > >> It seems that the TimerList object (timer.cc) >> doesn't delete the members in it's _heaplist >> in the destructor. >> >> Are these supposed to be cleaned up somewhere else? > > I think you are right, it seems the Heap objects on the _heaplist > are not deleted when TimerList destructor is invoked. > The Heap objects are alocated only inside TimerList::find_heap() and > the _heaplist management/access is internal to TimerList only, so > the TimerList destructor should delete the leftover. > > The fix for that will be trivial, but lets address it after the > pending two xorpsh related patches are out of the way. I thought it would be trivial too, but ran into wierd problems. Hopefully it's some other mistake I added in my code...will re-sync with your tree when you commit the changes. Thanks, Ben > > Thanks, > Pavlin -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Fri Oct 12 19:00:22 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 12 Oct 2007 19:00:22 -0700 Subject: [Xorp-hackers] TimerList destructor leaking memory? In-Reply-To: Message from Ben Greear of "Fri, 12 Oct 2007 17:45:22 PDT." <47101522.1050907@candelatech.com> Message-ID: <200710130200.l9D20MZD085650@possum.icir.org> Ben Greear wrote: > Pavlin Radoslavov wrote: > > Ben Greear wrote: > > > >> It seems that the TimerList object (timer.cc) > >> doesn't delete the members in it's _heaplist > >> in the destructor. > >> > >> Are these supposed to be cleaned up somewhere else? > > > > I think you are right, it seems the Heap objects on the _heaplist > > are not deleted when TimerList destructor is invoked. > > The Heap objects are alocated only inside TimerList::find_heap() and > > the _heaplist management/access is internal to TimerList only, so > > the TimerList destructor should delete the leftover. > > > > The fix for that will be trivial, but lets address it after the > > pending two xorpsh related patches are out of the way. > > I thought it would be trivial too, but ran into wierd problems. Hopefully > it's some other mistake I added in my code...will re-sync with your tree > when you commit the changes. Interesting. Anyway, I committed all outstanding changes + the extra patch from you (received off-list), so lets sync with HEAD before investigating the _heaplist issue. Thanks, Pavlin From greearb at candelatech.com Fri Oct 12 20:34:49 2007 From: greearb at candelatech.com (Ben Greear) Date: Fri, 12 Oct 2007 20:34:49 -0700 Subject: [Xorp-hackers] Interface deletion races. Message-ID: <47103CD9.2060307@candelatech.com> I am wondering about the right way to go about fixing the problem with removing interfaces & deleting multicast routes. There seems to be a race, and when the problem hits, it leads to an assert in ospf. A quick hack, and probably something that I will try soon just to work around this bug would be to probe for the requested interface and if found in the OS, do the route deletion anyway. A better fix would probably keep the interface around in the deleted state until we were somehow sure that all of the modules are done with it. We should probably also block the xorpsh commit completion until the routes & multicast bindings have been properly deleted. Otherwise, it will not be possible to safely know when we can add this interface to a different virtual router. I'm hoping one of the folks more familiar with the architecture can suggest a way to do this properly. Here's a snippet of logs... [ 2007/10/12 20:18:22 TRACE xorp_ospfv2 OSPF ] Event(InterfaceDown) Interface(rddVR44/rddVR44) State(Backup) [ 2007/10/12 20:18:22 TRACE xorp_ospfv2 OSPF ] Event(KillNbr) Interface(rddVR44/rddVR44) Neighbour(10.4.0.2) State(Full) [ 2007/10/12 20:18:22 INFO xorp_rtrmgr:28667 RTRMGR task.cc:2228 run_task ] No more tasks to run [ 2007/10/12 20:18:22 WARNING xorp_fea XrlFeaTarget ] Handling method for raw_packet4/0.1/leave_multicast_group failed: XrlCmdError 102 Command failed Leaving multicast group 224.0.0.6 failed: interface rddVR44 vif rddVR44 not found [ 2007/10/12 20:18:22 WARNING xorp_fea XrlFeaTarget ] Handling method for raw_packet4/0.1/send failed: XrlCmdError 102 Command failed No interface rddVR44 [ 2007/10/12 20:18:22 WARNING xorp_fea XrlFeaTarget ] Handling method for raw_packet4/0.1/leave_multicast_group failed: XrlCmdError 102 Command failed Leaving multicast group 224.0.0.5 failed: interface rddVR44 vif rddVR44 not found [ 2007/10/12 20:18:22 ERROR xorp_ospfv2:28891 OSPF xrl_io.cc:721 leave_multicast_group_cb ] Cannot leave a multicast group on interface rddVR44 vif rddVR44: 102 Command failed Leaving multicast group 224.0.0.6 failed: interface rddVR44 vif rddVR44 not found [ 2007/10/12 20:18:22 ERROR xorp_ospfv2:28891 OSPF xrl_io.cc:188 send_cb ] Cannot send a packet on interface rddVR44 vif rddVR44: 102 Command failed No interface rddVR44 [ 2007/10/12 20:18:22 ERROR xorp_ospfv2:28891 OSPF xrl_io.cc:721 leave_multicast_group_cb ] Cannot leave a multicast group on interface rddVR44 vif rddVR44: 102 Command failed Leaving multicast group 224.0.0.5 failed: interface rddVR44 vif rddVR44 not found [ 2007/10/12 20:18:22 TRACE xorp_ospfv2 OSPF ] Event(LinkStateAcknowledgementReceived-pseudo-event) Interface(rddVR1/rddVR1) Neighbour(10.0.0.1) State(Full) -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Fri Oct 19 18:00:50 2007 From: greearb at candelatech.com (Ben Greear) Date: Fri, 19 Oct 2007 18:00:50 -0700 Subject: [Xorp-hackers] OSPF stuck in TwoWay state. Message-ID: <47195342.90107@candelatech.com> Is it ever valid for neighbors to be stuck in TwoWay state? I configured a set of 15 virtual routers w/OSPF connected in interesting ways. Most of the nodes are connected to a bridge object (roughly directly connected), and other connections form a mesh. Most routers have several redundant paths through the network between any two nodes. Several of the instances connected across the bridge stay in TwoWay state, but some of them work. As far as I can tell, the hello messages are being send properly even from the guys in TwoWay state. I checked IP connectivity with traceroute, and it all seems to be right (ie, node 99.1.1.6 should be able to talk to 99.1.1.3). [root at lf1016-55 ~]# traceroute -n -i 3.16.3 99.1.1.6 traceroute to 99.1.1.6 (99.1.1.6), 30 hops max, 40 byte packets 1 99.1.1.6 2.785 ms 2.768 ms 2.756 ms Assuming its not normal for them to be in this state, can you give me an idea of where to look to start debugging this? root at lf1016-55> show ospf4 neighbor Address Interface State ID Pri Dead 99.1.1.9 3.16.3/3.16.3 TwoWay 127.1.0.9 128 33 99.1.1.10 3.16.3/3.16.3 TwoWay 127.1.0.10 128 34 99.1.1.6 3.16.3/3.16.3 TwoWay 127.1.0.6 128 35 99.1.1.2 3.16.3/3.16.3 TwoWay 127.1.0.2 128 35 99.1.1.12 3.16.3/3.16.3 Full 127.1.0.12 128 36 99.1.1.11 3.16.3/3.16.3 Full 127.1.0.11 128 36 10.1.3.1 1.3.3/1.3.3 Full 127.1.0.1 128 30 10.2.3.2 2.3.3/2.3.3 Full 127.1.0.2 128 35 10.3.4.4 3.4.3/3.4.3 Full 127.1.0.4 128 31 10.3.5.5 3.5.3/3.5.3 Full 127.1.0.5 128 33 10.3.9.9 3.9.3/3.9.3 Full 127.1.0.9 128 34 root at lf1016-55> Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Fri Oct 19 19:53:17 2007 From: greearb at candelatech.com (Ben Greear) Date: Fri, 19 Oct 2007 19:53:17 -0700 Subject: [Xorp-hackers] xorp_fea crashes when interface is removed from OS at in-opportune time. Message-ID: <47196D9D.5010207@candelatech.com> Seems xorp is very fragile when it comes to adding/deleting interfaces. I think a lot of these errors should just be warnings, not asserts. =================================================================== RCS file: /cvs/xorp/fea/data_plane/fibconfig/fibconfig_entry_set_netlink_socket.cc,v retrieving revision 1.15 diff -u -r1.15 fibconfig_entry_set_netlink_socket.cc --- fibconfig_entry_set_netlink_socket.cc 12 Oct 2007 07:53:47 -0000 1.15 +++ fibconfig_entry_set_netlink_socket.cc 20 Oct 2007 02:50:35 -0000 @@ -268,9 +268,9 @@ } // Catchall. - XLOG_FATAL("Could not find interface index for name %s", + XLOG_ERROR("Could not find interface index for name %s, maybe it was just deleted?", fte.vifname().c_str()); - break; + return XORP_ERROR; } while (false); } #0 0xffffe410 in __kernel_vsyscall () #1 0x49d42ee9 in raise () from /lib/libc.so.6 #2 0x49d444f1 in abort () from /lib/libc.so.6 #3 0x08287659 in xlog_fatal (module_name=Could not find the frame base for "xlog_fatal". ) at xlog.c:435 #4 0x08106a46 in FibConfigEntrySetNetlinkSocket::add_entry (this=0x842e9f8, fte=@0x778f1e24) at fibconfig_entry_set_netlink_socket.cc:271 #5 0x0810706d in FibConfigEntrySetNetlinkSocket::add_entry4 (this=0x842e9f8, fte=@0x8472e40) at fibconfig_entry_set_netlink_socket.cc:100 #6 0x0807eee4 in FibConfig::add_entry4 (this=0x778fe48c, fte=@0x8472e40) at fibconfig.cc:1077 #7 0x0805e025 in FibAddEntry4::dispatch (this=0x8472e38) at fibconfig_transaction.hh:112 #8 0x082b2377 in TransactionManager::Transaction::commit (this=0x84733a4) at transaction.cc:59 #9 0x082b0e66 in TransactionManager::commit (this=0x837e910, tid=8531650) at transaction.cc:201 #10 0x08080684 in FibConfig::commit_transaction (this=0x778fe48c, tid=8531650, error_msg=@0x778f1fd0) at fibconfig.cc:135 #11 0x080553ad in XrlFeaTarget::redist_transaction4_0_1_commit_transaction (this=0x778fefc0, tid=@0x84539d4) at xrl_fea_target.cc:2351 #12 0x0817daf0 in XrlFeaTargetBase::handle_redist_transaction4_0_1_commit_transaction (this=0x778fefc0, xa_inputs=@0x778f604c) at fea_base.cc:3230 #13 0x081a893f in XorpMemberCallback2B0::dispatch ( this=0x8418148, a1=@0x778f604c, a2=0x778f6030) at ../../libxorp/callback_nodebug.hh:4615 #14 0x08256f15 in XrlCmdEntry::dispatch (this=0x84181b4, inputs=@0x778f604c, outputs=0x778f6030) at xrl_cmd_map.hh:37 #15 0x0825da0a in XrlDispatcher::dispatch_xrl (this=0x778fe198, method_name=@0x778f5fc0, inputs=@0x778f604c, outputs=@0x778f6030) at xrl_dispatcher.cc:60 #16 0x08240d09 in XrlRouter::dispatch_xrl (this=0x778fe198, method_name=@0x778f6048, inputs=@0x778f604c, ---Type to continue, or q to quit--- outputs=@0x778f6030) at xrl_router.cc:587 #17 0x08265eed in STCPRequestHandler::dispatch_request (this=0x84794b0, seqno=428, packed_xrl=0x6fd30323 "?", packed_xrl_bytes=101) at xrl_pf_stcp.cc:235 #18 0x082665c3 in STCPRequestHandler::read_event (this=0x84794b0, ev=BufferedAsyncReader::DATA, buffer=0x6fd3030b "STCP\001\001", buffer_bytes=125) at xrl_pf_stcp.cc:199 #19 0x08267bbc in XorpMemberCallback4B0::dispatch (this=0x846f080, a1=0x84794b8, a2=BufferedAsyncReader::DATA, a3=0x6fd3030b "STCP\001\001", a4=125) at ../libxorp/callback_nodebug.hh:8965 #20 0x0828c0a3 in BufferedAsyncReader::announce_event (this=0x84794b8, ev=BufferedAsyncReader::DATA) at buffered_asyncio.cc:248 #21 0x0828c3e2 in BufferedAsyncReader::io_event (this=0x84794b8, fd={_filedesc = 51}, type=IOT_READ) at buffered_asyncio.cc:201 #22 0x0828cc24 in XorpMemberCallback2B0::dispatch (this=0x8440c48, a1= {_filedesc = 51}, a2=IOT_READ) at ../libxorp/callback_nodebug.hh:4635 #23 0x082a8756 in SelectorList::Node::run_hooks (this=0x8475a1c, m=SEL_RD, fd={_filedesc = 51}) at selector.cc:149 #24 0x082a73c1 in SelectorList::wait_and_dispatch (this=0x778ff034, timeout=@0x778fe120) at selector.cc:435 #25 0x0828e590 in EventLoop::run (this=0x778feff8) at eventloop.cc:137 #26 0x0804d192 in fea_main (finder_hostname=@0x778ff210, finder_port=19999) at xorp_fea.cc:101 #27 0x0804d478 in main (argc=0, argv=0x778ff2d8) at xorp_fea.cc:175 -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Fri Oct 19 20:06:51 2007 From: greearb at candelatech.com (Ben Greear) Date: Fri, 19 Oct 2007 20:06:51 -0700 Subject: [Xorp-hackers] xorp_fea crashes when interface is removed from OS at in-opportune time. In-Reply-To: <47196D9D.5010207@candelatech.com> References: <47196D9D.5010207@candelatech.com> Message-ID: <471970CB.1020401@candelatech.com> Ben Greear wrote: > Seems xorp is very fragile when it comes to adding/deleting > interfaces. I think a lot of these errors should just be warnings, > not asserts. Here's another one: =================================================================== RCS file: /cvs/xorp/fea/data_plane/control_socket/netlink_socket_utilities.cc,v retrieving revision 1.7 diff -u -r1.7 netlink_socket_utilities.cc --- netlink_socket_utilities.cc 27 Sep 2007 00:33:35 -0000 1.7 +++ netlink_socket_utilities.cc 20 Oct 2007 03:05:31 -0000 @@ -333,8 +333,9 @@ name = if_indextoname(if_index, name_buf); #endif if (name == NULL) { - XLOG_FATAL("Could not find interface corresponding to index %d", + XLOG_ERROR("Could not find interface corresponding to index %d, maybe it was just deleted?", if_index); + return XORP_ERROR; } if_name = string(name); } (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0x49d42ee9 in raise () from /lib/libc.so.6 #2 0x49d444f1 in abort () from /lib/libc.so.6 #3 0x08287669 in xlog_fatal (module_name=Could not find the frame base for "xlog_fatal". ) at xlog.c:435 #4 0x08148863 in NlmUtils::nlm_get_to_fte_cfg (iftree=@0x77c06ef4, fte=@0x77bfcba8, nlh=0x8472500, rtmsg=0x8472510, rta_len=40) at netlink_socket_utilities.cc:336 #5 0x0810d421 in FibConfigTableGetNetlinkSocket::parse_buffer_netlink_socket (family=2, iftree=@0x77c06ef4, fte_list=@0x77bfeb48, buffer=@0x77c00b64, is_nlm_get_only=false) at fibconfig_table_parse_netlink_socket.cc:122 #6 0x0810c6cb in FibConfigTableObserverNetlinkSocket::receive_data (this=0x842eab8, buffer=@0x77c00b64) at fibconfig_table_observer_netlink_socket.cc:131 #7 0x0810c5a7 in FibConfigTableObserverNetlinkSocket::netlink_socket_data (this=0x842eab8, buffer=@0x77c00b64) at fibconfig_table_observer_netlink_socket.cc:160 #8 0x08145926 in NetlinkSocket::force_recvmsg (this=0x842eac8, flags=0, only_kernel_messages=true, error_msg=@0x77c02b20) at netlink_socket.cc:534 #9 0x08145b87 in NetlinkSocket::io_event (this=0x842eac8, fd={_filedesc = 43}, type=IOT_READ) at netlink_socket.cc:547 #10 0x08147808 in XorpMemberCallback2B0::dispatch (this=0x843b8a8, a1= {_filedesc = 43}, a2=IOT_READ) at ../../../libxorp/callback_nodebug.hh:4635 #11 0x082a8766 in SelectorList::Node::run_hooks (this=0x8474dac, m=SEL_RD, fd={_filedesc = 43}) at selector.cc:149 #12 0x082a73d1 in SelectorList::wait_and_dispatch (this=0x77c07b34, timeout=@0x77c06c20) at selector.cc:435 #13 0x0828e570 in EventLoop::run (this=0x77c07af8) at eventloop.cc:123 #14 0x0804d192 in fea_main (finder_hostname=@0x77c07d10, finder_port=19999) at xorp_fea.cc:101 #15 0x0804d478 in main (argc=0, argv=0x77c07dd8) at xorp_fea.cc:175 (gdb) frame 4 #4 0x08148863 in NlmUtils::nlm_get_to_fte_cfg (iftree=@0x77c06ef4, fte=@0x77bfcba8, nlh=0x8472500, rtmsg=0x8472510, rta_len=40) at netlink_socket_utilities.cc:336 336 netlink_socket_utilities.cc: No such file or directory. in netlink_socket_utilities.cc (gdb) print if_index $1 = 955 (gdb) -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Fri Oct 19 20:32:59 2007 From: greearb at candelatech.com (Ben Greear) Date: Fri, 19 Oct 2007 20:32:59 -0700 Subject: [Xorp-hackers] xorp_fea crashes when interface is removed from OS at in-opportune time. In-Reply-To: <47196D9D.5010207@candelatech.com> References: <47196D9D.5010207@candelatech.com> Message-ID: <471976EB.5030907@candelatech.com> Ben Greear wrote: > Seems xorp is very fragile when it comes to adding/deleting > interfaces. I think a lot of these errors should just be warnings, > not asserts. And another related to the first: diff -u -r1.15 fibconfig_entry_set_netlink_socket.cc --- fibconfig_entry_set_netlink_socket.cc 12 Oct 2007 07:53:47 -0000 1.15 +++ fibconfig_entry_set_netlink_socket.cc 20 Oct 2007 03:10:55 -0000 @@ -256,7 +256,11 @@ break; const IfTree& iftree = fibconfig().iftree(); const IfTreeInterface* ifp = iftree.find_interface(fte.ifname()); - XLOG_ASSERT(ifp != NULL); + if (!ifp) { + XLOG_ERROR("Could not find interface: %s, maybe it was just deleted?\n", + fte.ifname().c_str()); + return XORP_ERROR; + } if (ifp->discard()) { rtmsg->rtm_type = RTN_BLACKHOLE; (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0x49d42ee9 in raise () from /lib/libc.so.6 #2 0x49d444f1 in abort () from /lib/libc.so.6 #3 0x08287669 in xlog_fatal (module_name=Could not find the frame base for "xlog_fatal". ) at xlog.c:435 #4 0x081069a8 in FibConfigEntrySetNetlinkSocket::add_entry (this=0x842ee50, fte=@0x77d9d2d4) at fibconfig_entry_set_netlink_socket.cc:259 #5 0x0810707d in FibConfigEntrySetNetlinkSocket::add_entry4 (this=0x842ee50, fte=@0x8473ee0) at fibconfig_entry_set_netlink_socket.cc:100 #6 0x0807eee4 in FibConfig::add_entry4 (this=0x77da993c, fte=@0x8473ee0) at fibconfig.cc:1077 #7 0x0805e025 in FibAddEntry4::dispatch (this=0x8473ed8) at fibconfig_transaction.hh:112 #8 0x082b2387 in TransactionManager::Transaction::commit (this=0x8442eec) at transaction.cc:59 #9 0x082b0e76 in TransactionManager::commit (this=0x837e910, tid=24373279) at transaction.cc:201 #10 0x08080684 in FibConfig::commit_transaction (this=0x77da993c, tid=24373279, error_msg=@0x77d9d480) at fibconfig.cc:135 #11 0x080553ad in XrlFeaTarget::redist_transaction4_0_1_commit_transaction (this=0x77daa470, tid=@0x84701bc) at xrl_fea_target.cc:2351 #12 0x0817db00 in XrlFeaTargetBase::handle_redist_transaction4_0_1_commit_transaction (this=0x77daa470, xa_inputs=@0x77da14fc) at fea_base.cc:3230 #13 0x081a894f in XorpMemberCallback2B0::dispatch ( this=0x8418148, a1=@0x77da14fc, a2=0x77da14e0) at ../../libxorp/callback_nodebug.hh:4615 #14 0x08256f25 in XrlCmdEntry::dispatch (this=0x84181b4, inputs=@0x77da14fc, outputs=0x77da14e0) at xrl_cmd_map.hh:37 #15 0x0825da1a in XrlDispatcher::dispatch_xrl (this=0x77da9648, method_name=@0x77da1470, inputs=@0x77da14fc, outputs=@0x77da14e0) at xrl_dispatcher.cc:60 #16 0x08240d19 in XrlRouter::dispatch_xrl (this=0x77da9648, method_name=@0x77da14f8, inputs=@0x77da14fc, outputs=@0x77da14e0) at xrl_router.cc:587 #17 0x08265efd in STCPRequestHandler::dispatch_request (this=0x847dc20, seqno=1249, packed_xrl=0x6fd0987c "?", packed_xrl_bytes=101) at xrl_pf_stcp.cc:235 #18 0x082665d3 in STCPRequestHandler::read_event (this=0x847dc20, ev=BufferedAsyncReader::DATA, buffer=0x6fd09864 "STCP\001\001", buffer_bytes=125) at xrl_pf_stcp.cc:199 #19 0x08267bcc in XorpMemberCallback4B0::dispatch (this=0x8446dc0, a1=0x847dc28, a2=BufferedAsyncReader::DATA, a3=0x6fd09864 "STCP\001\001", a4=125) at ../libxorp/callback_nodebug.hh:8965 #20 0x0828c0b3 in BufferedAsyncReader::announce_event (this=0x847dc28, ev=BufferedAsyncReader::DATA) at buffered_asyncio.cc:248 #21 0x0828c3f2 in BufferedAsyncReader::io_event (this=0x847dc28, fd={_filedesc = 51}, type=IOT_READ) at buffered_asyncio.cc:201 #22 0x0828cc34 in XorpMemberCallback2B0::dispatch (this=0x847ab18, a1= {_filedesc = 51}, a2=IOT_READ) at ../libxorp/callback_nodebug.hh:4635 #23 0x082a8766 in SelectorList::Node::run_hooks (this=0x84750dc, m=SEL_RD, fd={_filedesc = 51}) at selector.cc:149 #24 0x082a73d1 in SelectorList::wait_and_dispatch (this=0x77daa4e4, timeout=@0x77da95d0) at selector.cc:435 ---Type to continue, or q to quit--- #25 0x0828e5a0 in EventLoop::run (this=0x77daa4a8) at eventloop.cc:137 #26 0x0804d192 in fea_main (finder_hostname=@0x77daa6c0, finder_port=19999) at xorp_fea.cc:101 #27 0x0804d478 in main (argc=0, argv=0x77daa788) at xorp_fea.cc:175 (gdb) frame 4 #4 0x081069a8 in FibConfigEntrySetNetlinkSocket::add_entry (this=0x842ee50, fte=@0x77d9d2d4) at fibconfig_entry_set_netlink_socket.cc:259 259 fibconfig_entry_set_netlink_socket.cc: No such file or directory. in fibconfig_entry_set_netlink_socket.cc (gdb) print fte $1 = (const FteX &) @0x77d9d2d4: {> = {_net = {> = {_masked_addr = {_addr = {196874, 0, 0, 0}, _af = 2}, _prefix_len = 24}, }, _nexthop = {_addr = {67503114, 0, 0, 0}, _af = 2}, _ifname = {static npos = 4294967295, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x847c4fc "4.6.6"}}, _vifname = {static npos = 4294967295, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x8444bf4 "4.6.6"}}, _metric = 3, _admin_distance = 110, _xorp_route = true, _is_deleted = false, _is_unresolved = false, _is_connected_route = false}, } (gdb) -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Fri Oct 19 20:58:46 2007 From: greearb at candelatech.com (Ben Greear) Date: Fri, 19 Oct 2007 20:58:46 -0700 Subject: [Xorp-hackers] xorp-ospf performance issues: busy-spins & packet floods. Message-ID: <47197CF6.40502@candelatech.com> So, after I got fea to quit crashing, I was able to do some tests with dynamic interfaces & OSPF. With 15 routers, the system load goes to ~20 and ospf cannot seem to get out of init. I notice that ospf and fea are taking large amounts of CPU during and after xorpsh activity. I did an strace on xorp_ospf2 and it looks like it is sitting in a loop doing selects but not actually reading/writing the descriptors for much of the time. If I remember correctly, this was the same problem that xorpsh showed before Pavlin put the fix in to sleep for 10ms. Maybe a similar fix is needed for ospf2? Even then, it seems that we should not need to busy-spin even at 10ms. We should be able to set a longer timeout and wait on select to tell us when we have messages and/or can send data. Here' strace from xorp_ospfv2: clock_gettime(CLOCK_MONOTONIC, {19988, 604437813}) = 0 clock_gettime(CLOCK_MONOTONIC, {19988, 604521828}) = 0 select(48, [25 31 33 36 38 40 42 45 46 47], [46 47], [], {0, 0}) = 3 (in [46], out [46 47], left {0, 0}) select(48, [25 31 33 36 38 40 42 45 46 47], [46 47], [], {0, 0}) = 3 (in [46], out [46 47], left {0, 0}) clock_gettime(CLOCK_MONOTONIC, {19988, 604834293}) = 0 clock_gettime(CLOCK_MONOTONIC, {19988, 604918543}) = 0 clock_gettime(CLOCK_MONOTONIC, {19988, 605048836}) = 0 time(NULL) = 1192851387 time(NULL) = 1192851387 clock_gettime(CLOCK_MONOTONIC, {19988, 605290834}) = 0 clock_gettime(CLOCK_MONOTONIC, {19988, 605397338}) = 0 select(48, [25 31 33 36 38 40 42 45 46 47], [46 47], [], {0, 0}) = 3 (in [46], out [46 47], left {0, 0}) select(48, [25 31 33 36 38 40 42 45 46 47], [46 47], [], {0, 0}) = 3 (in [46], out [46 47], left {0, 0}) clock_gettime(CLOCK_MONOTONIC, {19988, 605731294}) = 0 clock_gettime(CLOCK_MONOTONIC, {19988, 605842029}) = 0 clock_gettime(CLOCK_MONOTONIC, {19988, 606542801}) = 0 time(NULL) = 1192851387 time(NULL) = 1192851387 clock_gettime(CLOCK_MONOTONIC, {19988, 606813953}) = 0 clock_gettime(CLOCK_MONOTONIC, {19988, 606927272}) = 0 select(48, [25 31 33 36 38 40 42 45 46 47], [46 47], [], {0, 0}) = 3 (in [46], out [46 47], left {0, 0}) select(48, [25 31 33 36 38 40 42 45 46 47], [46 47], [], {0, 0}) = 3 (in [46], out [46 47], left {0, 0}) clock_gettime(CLOCK_MONOTONIC, {19988, 607256007}) = 0 clock_gettime(CLOCK_MONOTONIC, {19988, 607339372}) = 0 clock_gettime(CLOCK_MONOTONIC, {19988, 608347317}) = 0 time(NULL) = 1192851387 time(NULL) = 1192851387 clock_gettime(CLOCK_MONOTONIC, {19988, 608595070}) = 0 clock_gettime(CLOCK_MONOTONIC, {19988, 608678070}) = 0 select(48, [25 31 33 36 38 40 42 45 46 47], [46 47], [], {0, 0}) = 3 (in [46], out [46 47], left {0, 0}) select(48, [25 31 33 36 38 40 42 45 46 47], [46 47], [], {0, 0}) = 3 (in [46], out [46 47], left {0, 0}) clock_gettime(CLOCK_MONOTONIC, {19988, 608989096}) = 0 clock_gettime(CLOCK_MONOTONIC, {19988, 609073655}) = 0 clock_gettime(CLOCK_MONOTONIC, {19988, 609176878}) = 0 time(NULL) = 1192851387 time(NULL) = 1192851387 clock_gettime(CLOCK_MONOTONIC, {19988, 609418106}) = 0 clock_gettime(CLOCK_MONOTONIC, {19988, 609500577}) = 0 select(48, [25 31 33 36 38 40 42 45 46 47], [46 47], [], {0, 0}) = 3 (in [46], out [46 47], left {0, 0}) select(48, [25 31 33 36 38 40 42 45 46 47], [46 47], [], {0, 0}) = 3 (in [46], out [46 47], left {0, 0}) clock_gettime(CLOCK_MONOTONIC, {19988, 609814101}) = 0 clock_gettime(CLOCK_MONOTONIC, {19988, 609934343}) = 0 clock_gettime(CLOCK_MONOTONIC, {19988, 610732073}) = 0 time(NULL) = 1192851387 time(NULL) = 1192851387 clock_gettime(CLOCK_MONOTONIC, {19988, 610919469}) = 0 clock_gettime(CLOCK_MONOTONIC, {19988, 610982308}) = 0 select(48, [25 31 33 36 38 40 42 45 46 47], [46 47], [], {0, 0}) = 3 (in [46], out [46 47], left {0, 0}) select(48, [25 31 33 36 38 40 42 45 46 47], [46 47], [], {0, 0}) = 3 (in [46], out [46 47], left {0, 0}) clock_gettime(CLOCK_MONOTONIC, {19988, 611307881}) = 0 clock_gettime(CLOCK_MONOTONIC, {19988, 611391965}) = 0 clock_gettime(CLOCK_MONOTONIC, {19988, 612422222}) = 0 fea is also taking up lots of CPU, but it seems like it might be doing at least some real work. It is running multiple selects before it actually reads from the FD, so it still seems like it could be optimized. clock_gettime(CLOCK_MONOTONIC, {20125, 745575383}) = 0 clock_gettime(CLOCK_MONOTONIC, {20125, 745683166}) = 0 select(60, [24 25 26 27 28 29 30 31 32 33 34 35 36 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 59], [], [], {0, 0}) = 1 (in [57], left {0, 0}) select(60, [24 25 26 27 28 29 30 31 32 33 34 35 36 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 59], [], [], {0, 0}) = 1 (in [57], left {0, 0}) select(60, [24 25 26 27 28 29 30 31 32 33 34 35 36 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 59], [], [], {3, 441222}) = 1 (in [57], left {3, 441222}) clock_gettime(CLOCK_MONOTONIC, {20125, 746149812}) = 0 recvmsg(57, {msg_name(16)={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("10.13.14.13")}, msg_iov(1)=[{"E\300\0P\253\314\0\0\1Y\24\252\n\r\16\r\340\0\0\5\2\4\0"..., 65536}], msg_controllen=24, {cmsg_len=24, cmsg_level=SOL_IP, cmsg_type=, ...}, msg_flags=0}, 0) = 80 time(NULL) = 1192851524 time(NULL) = 1192851524 clock_gettime(CLOCK_MONOTONIC, {20125, 746558226}) = 0 clock_gettime(CLOCK_MONOTONIC, {20125, 746641971}) = 0 At least part of fea's problem is that it is getting ~2000 packets per second for interfaces not it's own. I'm not sure at all why all the traffic...as under 'normal' load it was only getting about 100 per second. Here's a snippet of a packet capture. Looks like two routers have gone insane and are flooding each other with LS Updates. [root at lf1016-55 local]# tshark -n -i 11.16.11 Capturing on 11.16.11 0.000000 99.1.1.10 -> 224.0.0.5 OSPF LS Update 0.000111 99.1.1.10 -> 224.0.0.5 OSPF LS Update 0.000135 99.1.1.11 -> 224.0.0.5 OSPF LS Acknowledge 0.000157 99.1.1.11 -> 224.0.0.5 OSPF LS Update 0.000178 99.1.1.11 -> 224.0.0.5 OSPF LS Update 0.000198 99.1.1.11 -> 224.0.0.5 OSPF LS Acknowledge 0.000219 99.1.1.11 -> 224.0.0.5 OSPF LS Update 0.000239 99.1.1.10 -> 224.0.0.5 OSPF LS Update 0.000260 99.1.1.10 -> 224.0.0.5 OSPF LS Update 0.000285 99.1.1.11 -> 224.0.0.5 OSPF LS Update 0.000306 99.1.1.11 -> 224.0.0.5 OSPF LS Acknowledge 0.000326 99.1.1.11 -> 224.0.0.5 OSPF LS Update 0.000346 99.1.1.11 -> 224.0.0.5 OSPF LS Update Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Fri Oct 19 21:35:01 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 19 Oct 2007 21:35:01 -0700 Subject: [Xorp-hackers] xorp_fea crashes when interface is removed from OS at in-opportune time. In-Reply-To: Message from Ben Greear of "Fri, 19 Oct 2007 20:32:59 PDT." <471976EB.5030907@candelatech.com> Message-ID: <200710200435.l9K4Z1b0030897@possum.icir.org> Ben Greear wrote: > Ben Greear wrote: > > Seems xorp is very fragile when it comes to adding/deleting > > interfaces. I think a lot of these errors should just be warnings, > > not asserts. > > And another related to the first: Please provide instructions how to replicate the asserts triggering. Those asserts are intentionally there to catch problems that might be somewhere else. Thanks, Pavlin From greearb at candelatech.com Fri Oct 19 21:48:55 2007 From: greearb at candelatech.com (Ben Greear) Date: Fri, 19 Oct 2007 21:48:55 -0700 Subject: [Xorp-hackers] xorp_fea crashes when interface is removed from OS at in-opportune time. In-Reply-To: <200710200435.l9K4Z1b0030897@possum.icir.org> References: <200710200435.l9K4Z1b0030897@possum.icir.org> Message-ID: <471988B7.4090803@candelatech.com> Pavlin Radoslavov wrote: > Ben Greear wrote: > > >> Ben Greear wrote: >> >>> Seems xorp is very fragile when it comes to adding/deleting >>> interfaces. I think a lot of these errors should just be warnings, >>> not asserts. >>> >> And another related to the first: >> > > Please provide instructions how to replicate the asserts > triggering. > Those asserts are intentionally there to catch problems that might > be somewhere else. > I have a very complex set of apps driving xorp through xorpsh in an automated fashion, while creating/deleting network interfaces. I don't think I can give you an easy way to reproduce it. You *might* be able to cause it by unloading an ethernet driver out from under xorp, but it could take more luck than that to hit the race. However, you can imagine that at any time an interface may leave, and if it leaves before Xorp notices, then you can get those crashes. I'm all for having errors in the logs, but allowing an external event to crash the router seems like a bad idea. Part of the automation in my test case is done by a third party, so I can't offer you that code, but I *can* offer you a beta build of our tool which can at least create large virtual networks of Xorp routers on a single machine. Our tool can be scripted to create dynamic changes, but it would not be easy to exactly duplicate the kinds of changes that were causing this crash. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Fri Oct 19 22:03:58 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 19 Oct 2007 22:03:58 -0700 Subject: [Xorp-hackers] xorp-ospf performance issues: busy-spins & packet floods. In-Reply-To: Message from Ben Greear of "Fri, 19 Oct 2007 20:58:46 PDT." <47197CF6.40502@candelatech.com> Message-ID: <200710200503.l9K53wh8031161@possum.icir.org> Ben Greear wrote: > So, after I got fea to quit crashing, I was able to do some tests with > dynamic interfaces & OSPF. > > With 15 routers, the system load goes to ~20 and ospf cannot seem to > get out of init. > > I notice that ospf and fea are taking large amounts of CPU during > and after xorpsh activity. > > I did an strace on xorp_ospf2 and it looks like it is sitting in > a loop doing selects but not actually reading/writing the descriptors > for much of the time. > > If I remember correctly, this was the same problem that xorpsh showed > before Pavlin put the fix in to sleep for 10ms. Maybe a similar > fix is needed for ospf2? The xorpsh fix is semi-hackish and xorpsh-specific so it shouldn't be applied to OSPF or FEA. > Even then, it seems that we should not need to busy-spin even at 10ms. > We should be able to set a longer timeout and wait on select to tell > us when we have messages and/or can send data. The eventloop is used to handle different events (I/O, timers, tasks) and in the process it is calling select(2) probably more than necessary. E.g., it needs to find the event with the highest priority and the login for doing that probably could be optimized to reduce some of the system calls. This is probably the reason why you see the FEA calling select(2) several times, but this is just a speculation. Thanks, Pavlin > Here' strace from xorp_ospfv2: > > clock_gettime(CLOCK_MONOTONIC, {19988, 604437813}) = 0 > clock_gettime(CLOCK_MONOTONIC, {19988, 604521828}) = 0 > select(48, [25 31 33 36 38 40 42 45 46 47], [46 47], [], {0, 0}) = 3 (in [46], out [46 47], left {0, 0}) > select(48, [25 31 33 36 38 40 42 45 46 47], [46 47], [], {0, 0}) = 3 (in [46], out [46 47], left {0, 0}) > clock_gettime(CLOCK_MONOTONIC, {19988, 604834293}) = 0 > clock_gettime(CLOCK_MONOTONIC, {19988, 604918543}) = 0 > clock_gettime(CLOCK_MONOTONIC, {19988, 605048836}) = 0 > time(NULL) = 1192851387 > time(NULL) = 1192851387 > clock_gettime(CLOCK_MONOTONIC, {19988, 605290834}) = 0 > clock_gettime(CLOCK_MONOTONIC, {19988, 605397338}) = 0 > select(48, [25 31 33 36 38 40 42 45 46 47], [46 47], [], {0, 0}) = 3 (in [46], out [46 47], left {0, 0}) > select(48, [25 31 33 36 38 40 42 45 46 47], [46 47], [], {0, 0}) = 3 (in [46], out [46 47], left {0, 0}) > clock_gettime(CLOCK_MONOTONIC, {19988, 605731294}) = 0 > clock_gettime(CLOCK_MONOTONIC, {19988, 605842029}) = 0 > clock_gettime(CLOCK_MONOTONIC, {19988, 606542801}) = 0 > time(NULL) = 1192851387 > time(NULL) = 1192851387 > clock_gettime(CLOCK_MONOTONIC, {19988, 606813953}) = 0 > clock_gettime(CLOCK_MONOTONIC, {19988, 606927272}) = 0 > select(48, [25 31 33 36 38 40 42 45 46 47], [46 47], [], {0, 0}) = 3 (in [46], out [46 47], left {0, 0}) > select(48, [25 31 33 36 38 40 42 45 46 47], [46 47], [], {0, 0}) = 3 (in [46], out [46 47], left {0, 0}) > clock_gettime(CLOCK_MONOTONIC, {19988, 607256007}) = 0 > clock_gettime(CLOCK_MONOTONIC, {19988, 607339372}) = 0 > clock_gettime(CLOCK_MONOTONIC, {19988, 608347317}) = 0 > time(NULL) = 1192851387 > time(NULL) = 1192851387 > clock_gettime(CLOCK_MONOTONIC, {19988, 608595070}) = 0 > clock_gettime(CLOCK_MONOTONIC, {19988, 608678070}) = 0 > select(48, [25 31 33 36 38 40 42 45 46 47], [46 47], [], {0, 0}) = 3 (in [46], out [46 47], left {0, 0}) > select(48, [25 31 33 36 38 40 42 45 46 47], [46 47], [], {0, 0}) = 3 (in [46], out [46 47], left {0, 0}) > clock_gettime(CLOCK_MONOTONIC, {19988, 608989096}) = 0 > clock_gettime(CLOCK_MONOTONIC, {19988, 609073655}) = 0 > clock_gettime(CLOCK_MONOTONIC, {19988, 609176878}) = 0 > time(NULL) = 1192851387 > time(NULL) = 1192851387 > clock_gettime(CLOCK_MONOTONIC, {19988, 609418106}) = 0 > clock_gettime(CLOCK_MONOTONIC, {19988, 609500577}) = 0 > select(48, [25 31 33 36 38 40 42 45 46 47], [46 47], [], {0, 0}) = 3 (in [46], out [46 47], left {0, 0}) > select(48, [25 31 33 36 38 40 42 45 46 47], [46 47], [], {0, 0}) = 3 (in [46], out [46 47], left {0, 0}) > clock_gettime(CLOCK_MONOTONIC, {19988, 609814101}) = 0 > clock_gettime(CLOCK_MONOTONIC, {19988, 609934343}) = 0 > clock_gettime(CLOCK_MONOTONIC, {19988, 610732073}) = 0 > time(NULL) = 1192851387 > time(NULL) = 1192851387 > clock_gettime(CLOCK_MONOTONIC, {19988, 610919469}) = 0 > clock_gettime(CLOCK_MONOTONIC, {19988, 610982308}) = 0 > select(48, [25 31 33 36 38 40 42 45 46 47], [46 47], [], {0, 0}) = 3 (in [46], out [46 47], left {0, 0}) > select(48, [25 31 33 36 38 40 42 45 46 47], [46 47], [], {0, 0}) = 3 (in [46], out [46 47], left {0, 0}) > clock_gettime(CLOCK_MONOTONIC, {19988, 611307881}) = 0 > clock_gettime(CLOCK_MONOTONIC, {19988, 611391965}) = 0 > clock_gettime(CLOCK_MONOTONIC, {19988, 612422222}) = 0 > > > fea is also taking up lots of CPU, but it seems like it might be doing > at least some real work. It is running multiple selects before it actually > reads from the FD, so it still seems like it could be optimized. > > clock_gettime(CLOCK_MONOTONIC, {20125, 745575383}) = 0 > clock_gettime(CLOCK_MONOTONIC, {20125, 745683166}) = 0 > select(60, [24 25 26 27 28 29 30 31 32 33 34 35 36 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 59], [], [], {0, 0}) = 1 (in [57], left {0, 0}) > select(60, [24 25 26 27 28 29 30 31 32 33 34 35 36 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 59], [], [], {0, 0}) = 1 (in [57], left {0, 0}) > select(60, [24 25 26 27 28 29 30 31 32 33 34 35 36 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 59], [], [], {3, 441222}) = 1 (in [57], left {3, 441222}) > clock_gettime(CLOCK_MONOTONIC, {20125, 746149812}) = 0 > recvmsg(57, {msg_name(16)={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("10.13.14.13")}, msg_iov(1)=[{"E\300\0P\253\314\0\0\1Y\24\252\n\r\16\r\340\0\0\5\2\4\0"..., 65536}], msg_controllen=24, {cmsg_len=24, cmsg_level=SOL_IP, cmsg_type=, ...}, msg_flags=0}, 0) = 80 > time(NULL) = 1192851524 > time(NULL) = 1192851524 > clock_gettime(CLOCK_MONOTONIC, {20125, 746558226}) = 0 > clock_gettime(CLOCK_MONOTONIC, {20125, 746641971}) = 0 > > At least part of fea's problem is that it is getting ~2000 packets per second for > interfaces not it's own. I'm not sure at all why all the traffic...as under 'normal' > load it was only getting about 100 per second. > > Here's a snippet of a packet capture. Looks like two routers have > gone insane and are flooding each other with LS Updates. > > > [root at lf1016-55 local]# tshark -n -i 11.16.11 > Capturing on 11.16.11 > 0.000000 99.1.1.10 -> 224.0.0.5 OSPF LS Update > 0.000111 99.1.1.10 -> 224.0.0.5 OSPF LS Update > 0.000135 99.1.1.11 -> 224.0.0.5 OSPF LS Acknowledge > 0.000157 99.1.1.11 -> 224.0.0.5 OSPF LS Update > 0.000178 99.1.1.11 -> 224.0.0.5 OSPF LS Update > 0.000198 99.1.1.11 -> 224.0.0.5 OSPF LS Acknowledge > 0.000219 99.1.1.11 -> 224.0.0.5 OSPF LS Update > 0.000239 99.1.1.10 -> 224.0.0.5 OSPF LS Update > 0.000260 99.1.1.10 -> 224.0.0.5 OSPF LS Update > 0.000285 99.1.1.11 -> 224.0.0.5 OSPF LS Update > 0.000306 99.1.1.11 -> 224.0.0.5 OSPF LS Acknowledge > 0.000326 99.1.1.11 -> 224.0.0.5 OSPF LS Update > 0.000346 99.1.1.11 -> 224.0.0.5 OSPF LS Update > > Thanks, > Ben > > > -- > 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 pavlin at icir.org Fri Oct 19 22:11:15 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 19 Oct 2007 22:11:15 -0700 Subject: [Xorp-hackers] xorp_fea crashes when interface is removed from OS at in-opportune time. In-Reply-To: Message from Ben Greear of "Fri, 19 Oct 2007 21:48:55 PDT." <471988B7.4090803@candelatech.com> Message-ID: <200710200511.l9K5BFD2031271@possum.icir.org> > >>> Seems xorp is very fragile when it comes to adding/deleting > >>> interfaces. I think a lot of these errors should just be warnings, > >>> not asserts. > >>> > >> And another related to the first: > >> > > > > Please provide instructions how to replicate the asserts > > triggering. > > Those asserts are intentionally there to catch problems that might > > be somewhere else. > > > I have a very complex set of apps driving xorp through xorpsh in an > automated fashion, > while creating/deleting network interfaces. I don't think I can give > you an easy > way to reproduce it. You *might* be able to cause it by unloading an > ethernet driver > out from under xorp, but it could take more luck than that to hit the race. > > However, you can imagine that at any time an interface may leave, and if it > leaves before Xorp notices, then you can get those crashes. I'm all for > having > errors in the logs, but allowing an external event to crash the router seems > like a bad idea. Absolutely agree, an external event should not crash the router. Again, the assert is there to tell the developer there is an unusual problem that needs to be investigated. > Part of the automation in my test case is done by a third party, so I > can't offer you that code, > but I *can* offer you a beta build of our tool which can at least create > large virtual networks > of Xorp routers on a single machine. Our tool can be scripted to create > dynamic > changes, but it would not be easy to exactly duplicate the kinds of > changes that were causing > this crash. If the tool can be used to easily reproduce the problem, then yes please send me a copy of it with simple instructions how to use it to trigger the problem. Thanks, Pavlin From greearb at candelatech.com Fri Oct 19 22:19:37 2007 From: greearb at candelatech.com (Ben Greear) Date: Fri, 19 Oct 2007 22:19:37 -0700 Subject: [Xorp-hackers] xorp-ospf performance issues: busy-spins & packet floods. In-Reply-To: <200710200503.l9K53wh8031161@possum.icir.org> References: <200710200503.l9K53wh8031161@possum.icir.org> Message-ID: <47198FE9.108@candelatech.com> Pavlin Radoslavov wrote: > Ben Greear wrote: > > >> So, after I got fea to quit crashing, I was able to do some tests with >> dynamic interfaces & OSPF. >> >> With 15 routers, the system load goes to ~20 and ospf cannot seem to >> get out of init. >> >> I notice that ospf and fea are taking large amounts of CPU during >> and after xorpsh activity. >> >> I did an strace on xorp_ospf2 and it looks like it is sitting in >> a loop doing selects but not actually reading/writing the descriptors >> for much of the time. >> >> If I remember correctly, this was the same problem that xorpsh showed >> before Pavlin put the fix in to sleep for 10ms. Maybe a similar >> fix is needed for ospf2? >> > > The xorpsh fix is semi-hackish and xorpsh-specific so it shouldn't > be applied to OSPF or FEA. > It seems the current eventloop logic is too easy to use incorrectly and generate busy spins. >> Even then, it seems that we should not need to busy-spin even at 10ms. >> We should be able to set a longer timeout and wait on select to tell >> us when we have messages and/or can send data. >> > > The eventloop is used to handle different events (I/O, timers, > tasks) and in the process it is calling select(2) probably more than > necessary. E.g., it needs to find the event with the highest > priority and the login for doing that probably could be optimized to > reduce some of the system calls. > This is probably the reason why you see the FEA calling select(2) > several times, but this is just a speculation. > I've had good luck in other applications doing something like: while (1) { clear_fds, set timeout large, maxdesc to 0 //let each module recursively set fds it's interested in MainObjectCollection::instance().setFds(&input_set, &output_set, &exc_set, maxdesc, sleep_for, now); call select() on the fds with appropriate 'sleep_for' timeout // when done, we have either hit a timeout (ie, timer fired) // or we have IO ready. Pass in 'now' so that objects don't have to be doing system calls to get the time so often. now = getCurTime(); MainObjectCollection::instance().tick(&input_set, &output_set, &exc_set, now); } Even if you keep to your current architecture, I can't see any reason to call select if you are not going to read the descriptors immediately after the select. If you just want to sleep and not read fds, just send in null pointers to select() and it will sleep appropriately (within ~10ms accuracy or so). Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Fri Oct 19 22:29:36 2007 From: greearb at candelatech.com (Ben Greear) Date: Fri, 19 Oct 2007 22:29:36 -0700 Subject: [Xorp-hackers] xorp_fea crashes when interface is removed from OS at in-opportune time. In-Reply-To: <200710200511.l9K5BFD2031271@possum.icir.org> References: <200710200511.l9K5BFD2031271@possum.icir.org> Message-ID: <47199240.5020008@candelatech.com> Pavlin Radoslavov wrote: >> However, you can imagine that at any time an interface may leave, and if it >> leaves before Xorp notices, then you can get those crashes. I'm all for >> having >> errors in the logs, but allowing an external event to crash the router seems >> like a bad idea. >> > > Absolutely agree, an external event should not crash the router. > Again, the assert is there to tell the developer there is an unusual > problem that needs to be investigated. > It seems to take a while to propagate information through xorp, so it is possible for the code to not yet have discovered the interface is gone, and yet try the system call to get the interface name/index. There is absolutely no way you can be *certain* an interface is in the linux kernel when you make that call, so you *have* to be able to handle failure cases if you want your app to be robust. > If the tool can be used to easily reproduce the problem, then yes > please send me a copy of it with simple instructions how to use it > to trigger the problem. > I'm not sure it will reproduce this particular issue, but it should help you with other testing, especially with virtual routers and such. I'll send you information off-list on how to get it set up. Thanks, Ben > Thanks, > Pavlin > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Fri Oct 19 22:49:16 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 19 Oct 2007 22:49:16 -0700 Subject: [Xorp-hackers] xorp-ospf performance issues: busy-spins & packet floods. In-Reply-To: Message from Ben Greear of "Fri, 19 Oct 2007 22:19:37 PDT." <47198FE9.108@candelatech.com> Message-ID: <200710200549.l9K5nGdx031595@possum.icir.org> > > The eventloop is used to handle different events (I/O, timers, > > tasks) and in the process it is calling select(2) probably more than > > necessary. E.g., it needs to find the event with the highest > > priority and the login for doing that probably could be optimized to > > reduce some of the system calls. > > This is probably the reason why you see the FEA calling select(2) > > several times, but this is just a speculation. > > > I've had good luck in other applications doing something like: > > while (1) { > clear_fds, set timeout large, maxdesc to 0 > //let each module recursively set fds it's interested in > MainObjectCollection::instance().setFds(&input_set, &output_set, > &exc_set, > maxdesc, sleep_for, now); > call select() on the fds with appropriate 'sleep_for' timeout > // when done, we have either hit a timeout (ie, timer fired) > // or we have IO ready. Pass in 'now' so that objects don't have to > be doing system calls to get the time so often. > now = getCurTime(); > MainObjectCollection::instance().tick(&input_set, &output_set, > &exc_set, now); > } Earlier versions of the eventloop were using similar logic. Since then the eventloop has been extended to support priority and tasks and this makes things more complicated. > Even if you keep to your current architecture, I can't see any reason to > call select if you > are not going to read the descriptors immediately after the select. If > you just want to sleep > and not read fds, just send in null pointers to select() and it will > sleep appropriately (within ~10ms accuracy or so). See SelectorList::get_ready_priority() inside libxorp/selector.cc for example. It is used to find the best priority of a file descriptor that is ready. I should make it clear that I understand there is a performance problem that needs to be addressed, so I am not defending the current implementation. Please submit a bugzilla entry about the issue so later we can look at it more carefully. Thanks, Pavlin From atanu at ICSI.Berkeley.EDU Sat Oct 20 10:55:55 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Sat, 20 Oct 2007 10:55:55 -0700 Subject: [Xorp-hackers] OSPF stuck in TwoWay state. In-Reply-To: Message from Ben Greear of "Fri, 19 Oct 2007 18:00:50 PDT." <47195342.90107@candelatech.com> Message-ID: <84881.1192902955@tigger.icir.org> Hi, This behaviour is correct. Interfaces of type broadcast and NBMA will elect a DR and BDR if there are enough neighbours. In this case only the DR and BDR need to form full adjacencies with all neighbours, the other neighbours will stay in the 2-Way (TwoWay) state. ---------------------------------------- RFC 2328 Section 10.4 10.4. Whether to become adjacent Adjacencies are established with some subset of the router's neighbors. Routers connected by point-to-point networks, Point-to-MultiPoint networks and virtual links always become adjacent. On broadcast and NBMA networks, all routers become adjacent to both the Designated Router and the Backup Designated Router. The adjacency-forming decision occurs in two places in the neighbor state machine. First, when bidirectional communication is initially established with the neighbor, and secondly, when the identity of the attached network's (Backup) Designated Router changes. If the decision is made to not attempt an adjacency, the state of the neighbor communication stops at 2- Way. ... ---------------------------------------- Atanu. >>>>> "Ben" == Ben Greear writes: Ben> Is it ever valid for neighbors to be stuck in TwoWay Ben> state? Ben> I configured a set of 15 virtual routers w/OSPF connected in Ben> interesting ways. Most of the nodes are connected to a bridge Ben> object (roughly directly connected), and other connections form Ben> a mesh. Most routers have several redundant paths through the network Ben> between any two nodes. Ben> Several of the instances connected across the bridge stay in TwoWay Ben> state, but some of them work. As far as I can tell, the hello messages Ben> are being send properly even from the guys in TwoWay state. Ben> I checked IP connectivity with traceroute, and it all seems to be right Ben> (ie, node 99.1.1.6 should be able to talk to 99.1.1.3). Ben> [root at lf1016-55 ~]# traceroute -n -i 3.16.3 99.1.1.6 Ben> traceroute to 99.1.1.6 (99.1.1.6), 30 hops max, 40 byte packets Ben> 1 99.1.1.6 2.785 ms 2.768 ms 2.756 ms Ben> Assuming its not normal for them to be in this state, can you Ben> give me an idea of where to look to start debugging this? Ben> root at lf1016-55> show ospf4 neighbor Ben> Address Interface State ID Pri Dead Ben> 99.1.1.9 3.16.3/3.16.3 TwoWay 127.1.0.9 128 33 Ben> 99.1.1.10 3.16.3/3.16.3 TwoWay 127.1.0.10 128 34 Ben> 99.1.1.6 3.16.3/3.16.3 TwoWay 127.1.0.6 128 35 Ben> 99.1.1.2 3.16.3/3.16.3 TwoWay 127.1.0.2 128 35 Ben> 99.1.1.12 3.16.3/3.16.3 Full 127.1.0.12 128 36 Ben> 99.1.1.11 3.16.3/3.16.3 Full 127.1.0.11 128 36 Ben> 10.1.3.1 1.3.3/1.3.3 Full 127.1.0.1 128 30 Ben> 10.2.3.2 2.3.3/2.3.3 Full 127.1.0.2 128 35 Ben> 10.3.4.4 3.4.3/3.4.3 Full 127.1.0.4 128 31 Ben> 10.3.5.5 3.5.3/3.5.3 Full 127.1.0.5 128 33 Ben> 10.3.9.9 3.9.3/3.9.3 Full 127.1.0.9 128 34 Ben> root at lf1016-55> Ben> Thanks, Ben> Ben Ben> -- Ben> Ben Greear Ben> Candela Technologies Inc http://www.candelatech.com Ben> _______________________________________________ Ben> Xorp-hackers mailing list Ben> Xorp-hackers at icir.org Ben> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From greearb at candelatech.com Sat Oct 20 16:55:17 2007 From: greearb at candelatech.com (Ben Greear) Date: Sat, 20 Oct 2007 16:55:17 -0700 Subject: [Xorp-hackers] xorp-ospf performance issues: busy-spins & packet floods. In-Reply-To: <200710200549.l9K5nGdx031595@possum.icir.org> References: <200710200549.l9K5nGdx031595@possum.icir.org> Message-ID: <471A9565.3050307@candelatech.com> Pavlin Radoslavov wrote: > See SelectorList::get_ready_priority() inside libxorp/selector.cc > for example. > It is used to find the best priority of a file descriptor that is > ready. > What do you think about having the run() method execute the timer(s), then tasks, then the selector. I'd run the selector last since it can sleep. We can get rid of the get_ready_priority() all together that way. If you really wanted to not handle all of the available fds at once (ie, allow low priorities to be skipped), then we could just not process all of them. I can't think of a good reason to do that, however. Then, we have only one call to select(), as well as making sure that each of the run-queues (timers, tasks, selectors) gets some time to run. I am suspicious that the loop I see in ospf has to do with an endless timer loop where the ospf code keeps trying to fire timers but never reads/writes the sockets. I also assume that if it could actually process the sockets, it's timers would be satisfied and quit re-arming themselves. This is idle conjecture at this time, but it would fit the strace log I saw... I think I can code this up and test it out if it's something you'd consider merging. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Sat Oct 20 17:02:08 2007 From: greearb at candelatech.com (Ben Greear) Date: Sat, 20 Oct 2007 17:02:08 -0700 Subject: [Xorp-hackers] xorp-ospf performance issues: busy-spins & packet floods. In-Reply-To: <200710200549.l9K5nGdx031595@possum.icir.org> References: <200710200549.l9K5nGdx031595@possum.icir.org> Message-ID: <471A9700.8040209@candelatech.com> Pavlin Radoslavov wrote: > See SelectorList::get_ready_priority() inside libxorp/selector.cc > for example. > It is used to find the best priority of a file descriptor that is > ready. > > Another thing: Is it always assumed that if there is something in the task list, it should be run as soon as possible? Or, should we have something like _task_list.get_next_delay(t) so that tasks can sleep on the select loop? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Sat Oct 20 17:57:51 2007 From: greearb at candelatech.com (Ben Greear) Date: Sat, 20 Oct 2007 17:57:51 -0700 Subject: [Xorp-hackers] Bug 234 (DelayValidation & slow xorpsh commands) Message-ID: <471AA40F.3070807@candelatech.com> This bug is quite old, but I still see the DelayValidation logic found in the module_command.cc Any clues on what sorts of things need to be changed to get rid of this and put in proper status_methods? I'm interested primarily in OSPF, static routes, and interface handling (if it's a per-module issue). Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From jonirucoeith at gmail.com Sat Oct 20 19:01:23 2007 From: jonirucoeith at gmail.com (Jon) Date: Sun, 21 Oct 2007 04:01:23 +0200 Subject: [Xorp-hackers] xorp_fea crashes when interface is removed from OS at in-opportune time. In-Reply-To: <47199240.5020008@candelatech.com> References: <200710200511.l9K5BFD2031271@possum.icir.org> <47199240.5020008@candelatech.com> Message-ID: <471f67780710201901i34d1febdqdb4c595af8c268aa@mail.gmail.com> If you need to be able to remove interfaces on the fly; consider adding gre tunnels and use them as regular ethernet interfaces by the protocols. The tunnels can easily be both added and deleted and should be much easier to handle than manipulating a physical interface. -- Jon On 10/20/07, Ben Greear wrote: > > Pavlin Radoslavov wrote: > >> However, you can imagine that at any time an interface may leave, and > if it > >> leaves before Xorp notices, then you can get those crashes. I'm all > for > >> having > >> errors in the logs, but allowing an external event to crash the router > seems > >> like a bad idea. > >> > > > > Absolutely agree, an external event should not crash the router. > > Again, the assert is there to tell the developer there is an unusual > > problem that needs to be investigated. > > > It seems to take a while to propagate information through xorp, so it is > possible > for the code to not yet have discovered the interface is gone, and yet > try the system > call to get the interface name/index. > > There is absolutely no way you can be *certain* an interface is in the > linux kernel when you > make that call, so you *have* to be able to handle failure cases if you > want your app to > be robust. > > > If the tool can be used to easily reproduce the problem, then yes > > please send me a copy of it with simple instructions how to use it > > to trigger the problem. > > > I'm not sure it will reproduce this particular issue, but it should help > you with other > testing, especially with virtual routers and such. I'll send you > information off-list > on how to get it set up. > > Thanks, > Ben > > > Thanks, > > Pavlin > > > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20071021/f44222a8/attachment.html From greearb at candelatech.com Sat Oct 20 19:53:52 2007 From: greearb at candelatech.com (Ben Greear) Date: Sat, 20 Oct 2007 19:53:52 -0700 Subject: [Xorp-hackers] xorp-ospf performance issues: busy-spins & packet floods. In-Reply-To: <471A9565.3050307@candelatech.com> References: <200710200549.l9K5nGdx031595@possum.icir.org> <471A9565.3050307@candelatech.com> Message-ID: <471ABF40.3010200@candelatech.com> Ben Greear wrote: > Pavlin Radoslavov wrote: > >> See SelectorList::get_ready_priority() inside libxorp/selector.cc >> for example. >> It is used to find the best priority of a file descriptor that is >> ready. >> The attached patch still lets ospf busy-spin, but at least now it's spinning doing reads and writes of some SCTP payload instead of just spinning w/out obviously doing anything... It should get rid of several time calls and some static global variables as well. Thanks, Ben >> >> > > What do you think about having the run() method execute the timer(s), > then tasks, then the selector. I'd run the selector last since it can > sleep. > We can get rid of the get_ready_priority() all together that way. If you > really wanted to not handle all of the available fds at once (ie, allow low > priorities to be skipped), then we could just not process all of them. > I can't > think of a good reason to do that, however. > > Then, we have only one call to select(), as well as making sure that each > of the run-queues (timers, tasks, selectors) gets some time to run. I > am suspicious > that the loop I see in ospf has to do with an endless timer loop where > the ospf > code keeps trying to fire timers but never reads/writes the sockets. I > also assume > that if it could actually process the sockets, it's timers would be > satisfied and quit > re-arming themselves. This is idle conjecture at this time, but it > would fit the > strace log I saw... > > I think I can code this up and test it out if it's something you'd > consider merging. > > Thanks, > Ben > > -- Ben Greear Candela Technologies Inc http://www.candelatech.com -------------- next part -------------- A non-text attachment was scrubbed... Name: xorp.patch Type: text/x-patch Size: 2759 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20071020/bac14d00/attachment.bin From pavlin at icir.org Sat Oct 20 20:02:07 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Sat, 20 Oct 2007 20:02:07 -0700 Subject: [Xorp-hackers] xorp-ospf performance issues: busy-spins & packet floods. In-Reply-To: Message from Ben Greear of "Sat, 20 Oct 2007 16:55:17 PDT." <471A9565.3050307@candelatech.com> Message-ID: <200710210302.l9L327dT043174@possum.icir.org> Ben Greear wrote: > Pavlin Radoslavov wrote: > > See SelectorList::get_ready_priority() inside libxorp/selector.cc > > for example. > > It is used to find the best priority of a file descriptor that is > > ready. > > > > What do you think about having the run() method execute the timer(s), > then tasks, then the selector. I'd run the selector last since it can > sleep. > We can get rid of the get_ready_priority() all together that way. If you > really wanted to not handle all of the available fds at once (ie, allow low > priorities to be skipped), then we could just not process all of them. > I can't > think of a good reason to do that, however. > > Then, we have only one call to select(), as well as making sure that each > of the run-queues (timers, tasks, selectors) gets some time to run. I > am suspicious > that the loop I see in ospf has to do with an endless timer loop where > the ospf > code keeps trying to fire timers but never reads/writes the sockets. I > also assume > that if it could actually process the sockets, it's timers would be > satisfied and quit > re-arming themselves. This is idle conjecture at this time, but it > would fit the > strace log I saw... The problem should be approached by deciding first what kind of semantics do we want from the eventloop. Mark Handley will be a better person to query about the current set of semantics (tasks, priority, etc), because he introduced and implemented them so he can provide the insights and reasonings behind various choices. Thanks, Pavlin > I think I can code this up and test it out if it's something you'd > consider merging. > > Thanks, > Ben > > -- > 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 pavlin at icir.org Sat Oct 20 20:06:15 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Sat, 20 Oct 2007 20:06:15 -0700 Subject: [Xorp-hackers] xorp-ospf performance issues: busy-spins & packet floods. In-Reply-To: Message from Ben Greear of "Sat, 20 Oct 2007 19:53:52 PDT." <471ABF40.3010200@candelatech.com> Message-ID: <200710210306.l9L36FTW043244@possum.icir.org> Ben Greear wrote: > Ben Greear wrote: > > Pavlin Radoslavov wrote: > > > >> See SelectorList::get_ready_priority() inside libxorp/selector.cc > >> for example. > >> It is used to find the best priority of a file descriptor that is > >> ready. > >> > The attached patch still lets ospf busy-spin, but at least now it's spinning > doing reads and > writes of some SCTP payload instead of just spinning w/out obviously doing > anything... > > It should get rid of several time calls and some static global variables as > well. Without investigating the patch into details, one of the things it does is commenting-out the priority-related mechanism. This completely changes the current semantics. As I mentioned in my previous email, it is better to talk first with Mark on the subject. Thanks, Pavlin > Thanks, > Ben > > >> > > > > What do you think about having the run() method execute the timer(s), > > then tasks, then the selector. I'd run the selector last since it can > > sleep. > > We can get rid of the get_ready_priority() all together that way. If you > > really wanted to not handle all of the available fds at once (ie, allow low > > priorities to be skipped), then we could just not process all of them. I > > can't > > think of a good reason to do that, however. > > > > Then, we have only one call to select(), as well as making sure that each > > of the run-queues (timers, tasks, selectors) gets some time to run. I am > > suspicious > > that the loop I see in ospf has to do with an endless timer loop where the > > ospf > > code keeps trying to fire timers but never reads/writes the sockets. I also > > assume > > that if it could actually process the sockets, it's timers would be > > satisfied and quit > > re-arming themselves. This is idle conjecture at this time, but it would > > fit the > > strace log I saw... > > > > I think I can code this up and test it out if it's something you'd > > consider merging. > > > > Thanks, > > Ben > > > > > > > -- > Ben Greear Candela Technologies Inc > http://www.candelatech.com > > > Index: eventloop.cc > =================================================================== > RCS file: /cvs/xorp/libxorp/eventloop.cc,v > retrieving revision 1.25 > diff -u -r1.25 eventloop.cc > --- eventloop.cc 28 Sep 2007 06:34:50 -0000 1.25 > +++ eventloop.cc 21 Oct 2007 01:04:37 -0000 > @@ -29,11 +29,6 @@ > // > int eventloop_instance_count; > > -// > -// Last call to EventLoop::run. 0 is a special value that indicates > -// EventLoop::run has not been called. > -// > -static time_t last_ev_run; > > EventLoop::EventLoop() > : _clock(new SystemClock), _timer_list(_clock), > @@ -45,7 +40,8 @@ > { > XLOG_ASSERT(eventloop_instance_count == 0); > eventloop_instance_count++; > - last_ev_run = 0; > + last_ev_run = TimeVal::ZERO(); > + last_warned = 0; > } > > EventLoop::~EventLoop() > @@ -63,25 +59,47 @@ > void > EventLoop::run() > { > - const time_t MAX_ALLOWED = 2; > - static time_t last_warned; > + static const time_t MAX_ALLOWED = 2; > > - if (last_ev_run == 0) > - last_ev_run = time(0); > + _timer_list.advance_time(); > + TimeVal now; > + _timer_list.current_time(now); > > - time_t now = time(0); > - time_t diff = now - last_ev_run; > + if (last_ev_run.secs() == 0) > + last_ev_run = now; > > - if (now - last_warned > 0 && (diff > MAX_ALLOWED)) { > + int32_t diff = now.secs() - last_ev_run.secs(); > + if (now.secs() - last_warned > 0 && (diff > MAX_ALLOWED)) { > XLOG_WARNING("%d seconds between calls to EventLoop::run", (int)diff); > - last_warned = now; > + last_warned = now.secs(); > } > > TimeVal t; > > - _timer_list.advance_time(); > _timer_list.get_next_delay(t); > > + // Run timers if they need it. > + if (t == TimeVal::ZERO()) { > + _timer_list.run(); > + } > + > + if (!_task_list.empty()) { > + _task_list.run(); > + if (!_task_list.empty()) { > + // Run task again as soon as possible. > + t = TimeVal::ZERO(); > + } > + } > + > +#ifdef HOST_OS_WINDOWS > + _win_dispatcher.wait_and_dispatch(t); > +#else > + _selector_list.wait_and_dispatch(t); > +#endif > + > + _timer_list.current_time(last_ev_run); > + > +#if 0 > int timer_priority = XorpTask::PRIORITY_INFINITY; > int selector_priority = XorpTask::PRIORITY_INFINITY; > int task_priority = XorpTask::PRIORITY_INFINITY; > @@ -139,6 +157,7 @@ > } > > last_ev_run = time(0); > +#endif > } > > bool > Index: eventloop.hh > =================================================================== > RCS file: /cvs/xorp/libxorp/eventloop.hh,v > retrieving revision 1.28 > diff -u -r1.28 eventloop.hh > --- eventloop.hh 23 May 2007 12:12:42 -0000 1.28 > +++ eventloop.hh 21 Oct 2007 01:04:37 -0000 > @@ -343,6 +343,8 @@ > #else > SelectorList _selector_list; > #endif > + TimeVal last_ev_run; > + time_t last_warned; > }; > > // ---------------------------------------------------------------------------- > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From pavlin at icir.org Sat Oct 20 20:11:27 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Sat, 20 Oct 2007 20:11:27 -0700 Subject: [Xorp-hackers] Bug 234 (DelayValidation & slow xorpsh commands) In-Reply-To: Message from Ben Greear of "Sat, 20 Oct 2007 17:57:51 PDT." <471AA40F.3070807@candelatech.com> Message-ID: <200710210311.l9L3BRm0043315@possum.icir.org> Ben Greear wrote: > This bug is quite old, but I still see the DelayValidation logic found > in the > module_command.cc > > Any clues on what sorts of things need to be changed to get rid of this > and put in proper status_methods? I'm interested primarily in OSPF, static > routes, and interface handling (if it's a per-module issue). http://www.xorp.org/bugzilla/show_bug.cgi?id=677 Any semi-hackish solutions are going to make things worse and even less maintainable. Pavlin From greearb at candelatech.com Sun Oct 21 00:38:07 2007 From: greearb at candelatech.com (Ben Greear) Date: Sun, 21 Oct 2007 00:38:07 -0700 Subject: [Xorp-hackers] Bug 234 (DelayValidation & slow xorpsh commands) In-Reply-To: <200710210311.l9L3BRm0043315@possum.icir.org> References: <200710210311.l9L3BRm0043315@possum.icir.org> Message-ID: <471B01DF.4030702@candelatech.com> Pavlin Radoslavov wrote: > Ben Greear wrote: > > >> This bug is quite old, but I still see the DelayValidation logic found >> in the >> module_command.cc >> >> Any clues on what sorts of things need to be changed to get rid of this >> and put in proper status_methods? I'm interested primarily in OSPF, static >> routes, and interface handling (if it's a per-module issue). >> > > http://www.xorp.org/bugzilla/show_bug.cgi?id=677 > > Any semi-hackish solutions are going to make things worse and even > less maintainable. > Is anyone working on that? Any time someone talks about re-writing something, seems it's more of a hope than a reality :) In that bug's comments, you mention that decreasing the 2-second delay might work. I'll give that a try after I get the ospf busy-spin issue resolved. Thanks, Ben > Pavlin > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From arjun at ceeyes.com Mon Oct 22 05:47:59 2007 From: arjun at ceeyes.com (Arjun Prasad) Date: Mon, 22 Oct 2007 18:17:59 +0530 Subject: [Xorp-hackers] configuration of static routes Message-ID: <000e01c814a9$c7c627e0$2283a8c0@ceeyes.com> Hi all! I tried to configure static routes through CLI but it failed at creating route on 3rd level i.e level 1 protocols { level 2 static { level 3 route 192.168.131.74/24 { it is asking for Or after route in level 3rd i gave even though it didnt work. plz help!!! Regards Arjun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20071022/2a5e34f1/attachment.html From greearb at candelatech.com Mon Oct 22 09:16:04 2007 From: greearb at candelatech.com (Ben Greear) Date: Mon, 22 Oct 2007 09:16:04 -0700 Subject: [Xorp-hackers] OSPF stuck in Exchange state. In-Reply-To: <84881.1192902955@tigger.icir.org> References: <84881.1192902955@tigger.icir.org> Message-ID: <471CCCC4.7010302@candelatech.com> Atanu Ghosh wrote: > Hi, > > This behaviour is correct. > > Interfaces of type broadcast and NBMA will elect a DR and BDR if there > are enough neighbours. In this case only the DR and BDR need to form > full adjacencies with all neighbours, the other neighbours will stay in > the 2-Way (TwoWay) state. > Thanks for that info, that makes sense. Before asking my next question: I did read through the rfc, but don't see any reason for links to be stuck in the Exchange state. However, after leaving it overnight, it's still like that. The connection between the routers is an emulated 128kbps sat link (1.5seconds round-trip), and it drops packets occassionally (or more often if sent pkts at rates above 128kbps). This sat acts like an ethernet bridge to other routers connected to it. Maybe there is some retransmit logic that isn't quite right? If I restart Xorp a few times, it will eventually come up with all in 'full' state (on router 12, which appears to be the master) . I see hellos from the nodes in Exchange state, so it seems they should be able to communicate. [root at lf1016-55 lanforge]# tcpdump -n -i 2.16.2 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on br0, link-type EN10MB (Ethernet), capture size 96 bytes 09:04:32.113138 IP 99.1.1.12 > 224.0.0.5: OSPFv2, Hello, length: 68 09:04:32.493651 IP 99.1.1.11 > 224.0.0.5: OSPFv2, Hello, length: 68 09:04:32.506866 IP 99.1.1.10 > 224.0.0.5: OSPFv2, Hello, length: 68 09:04:32.541082 IP 99.1.1.2 > 224.0.0.5: OSPFv2, Hello, length: 68 09:04:32.911437 IP 99.1.1.6 > 224.0.0.5: OSPFv2, Hello, length: 68 5 packets captured 10 packets received by filter 0 packets dropped by kernel This is for router '2'. [root at lf1016-55 lanforge]# xorpsh Welcome to XORP on lf1016-55 root at lf1016-55> show ospf4 neighbor Address Interface State ID Pri Dead 99.1.1.12 2.16.2/2.16.2 Exchange 127.1.0.12 128 38 99.1.1.10 2.16.2/2.16.2 TwoWay 127.1.0.10 128 39 99.1.1.11 2.16.2/2.16.2 Exchange 127.1.0.11 128 39 99.1.1.6 2.16.2/2.16.2 TwoWay 127.1.0.6 128 39 99.1.1.9 2.16.2/2.16.2 TwoWay 127.1.0.9 128 34 99.1.1.3 2.16.2/2.16.2 TwoWay 127.1.0.3 128 37 10.1.2.1 1.2.2/1.2.2 Full 127.1.0.1 128 34 10.2.3.3 2.3.2/2.3.2 Full 127.1.0.3 128 35 10.2.4.4 2.4.2/2.4.2 Full 127.1.0.4 128 32 10.2.5.5 2.5.2/2.5.2 Full 127.1.0.5 128 37 10.2.6.6 2.6.2/2.6.2 Full 127.1.0.6 128 38 10.2.9.9 2.9.2/2.9.2 Full 127.1.0.9 128 33 10.2.10.10 2.10.2/2.10.2 Full 127.1.0.10 128 38 root at lf1016-55> quit [root at lf1016-55 lanforge]# Here is the 'show ospf neighbor' for router '12': Welcome to XORP on lf1016-55 root at lf1016-55> show ospf4 neighbor Address Interface State ID Pri Dead 99.1.1.3 12.16.12/12.16.12 Full 127.1.0.3 128 34 99.1.1.10 12.16.12/12.16.12 Full 127.1.0.10 128 34 99.1.1.2 12.16.12/12.16.12 Exchange 127.1.0.2 128 34 99.1.1.11 12.16.12/12.16.12 Full 127.1.0.11 128 34 99.1.1.6 12.16.12/12.16.12 Full 127.1.0.6 128 34 99.1.1.9 12.16.12/12.16.12 Full 127.1.0.9 128 31 10.1.12.1 1.12.12/1.12.12 Full 127.1.0.1 128 30 10.9.12.9 9.12.12/9.12.12 Full 127.1.0.9 128 39 10.10.12.10 10.12.12/10.12.12 Full 127.1.0.10 128 33 10.11.12.11 11.12.12/11.12.12 Full 127.1.0.11 128 33 10.12.13.13 12.13.12/12.13.12 Full 127.1.0.13 128 34 10.12.14.14 12.14.12/12.14.12 Full 127.1.0.14 128 33 10.12.15.15 12.15.12/12.15.12 Full 127.1.0.15 128 34 root at lf1016-55> Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Mon Oct 22 16:00:22 2007 From: greearb at candelatech.com (Ben Greear) Date: Mon, 22 Oct 2007 16:00:22 -0700 Subject: [Xorp-hackers] OSPF stuck in Exchange state. In-Reply-To: <471CCCC4.7010302@candelatech.com> References: <84881.1192902955@tigger.icir.org> <471CCCC4.7010302@candelatech.com> Message-ID: <471D2B86.2050404@candelatech.com> Looks like the problem might be that we are dropping a packet, and the ospf code does not retransmit? I see this comment in peer.cc: /** * XXX * The outgoing packets should be queued on the transmit queue, for * the time being just send them straight out. */ template bool PeerOut::transmit(typename Transmit::TransmitRef tr) { In the logs, I never see DataDescriptionReceived in the Exchange State: [root at lf1016-55 lanforge]# grep DataDescription x12.txt|grep "99.1.1.2" [ 2007/10/22 14:30:47 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.2) State(ExStart) [ 2007/10/22 14:30:49 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.2) State(ExStart) But, I do see an LoadingDone message, though it will be ignored since we are in the wrong state: [ 2007/10/22 14:30:51 TRACE xorp_ospfv2 OSPF ] Event(LoadingDone) Interface(12.16.12/12.16.12) Neighbour(99.1.1.2) State(Exchange) Off to try to figure out how we're supposed to do retransmits. Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Sun Oct 21 16:17:24 2007 From: greearb at candelatech.com (Ben Greear) Date: Sun, 21 Oct 2007 16:17:24 -0700 Subject: [Xorp-hackers] xorp-ospf performance issues: busy-spins & packet floods. In-Reply-To: <471A9565.3050307@candelatech.com> References: <200710200549.l9K5nGdx031595@possum.icir.org> <471A9565.3050307@candelatech.com> Message-ID: <471BDE04.2020104@candelatech.com> I managed to reproduce this with logging enabled in ospf. Below is a snippet from the logs. At this point, the emulated networks are probably not working right (ie, passing few if any packets), but no reason to spin so madly! Thanks, Ben [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.2.6.255(0xa0206ff) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.2.9.9(0xa020909) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.3.4.4(0xa030404) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.3.5.255(0xa0305ff) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.4.5.255(0xa0405ff) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.4.6.255(0xa0406ff) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.6.7.7(0xa060707) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.6.7.255(0xa0607ff) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.6.8.8(0xa060808) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.7.8.255(0xa0708ff) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.9.10.255(0xa090aff) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.9.11.11(0xa090b0b) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.9.11.255(0xa090bff) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.9.13.255(0xa090dff) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.9.14.255(0xa090eff) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.9.15.15(0xa090f0f) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.9.15.255(0xa090fff) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.10.11.255(0xa0a0bff) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.10.13.255(0xa0a0dff) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.10.14.255(0xa0a0eff) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.10.15.255(0xa0a0fff) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.11.13.255(0xa0b0dff) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.11.14.255(0xa0b0eff) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.11.15.255(0xa0b0fff) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.13.14.255(0xa0d0eff) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.13.15.255(0xa0d0fff) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.14.15.255(0xa0e0fff) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router 127.1.0.1(0x7f010001) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router 127.1.0.2(0x7f010002) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router 127.1.0.3(0x7f010003) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router 127.1.0.4(0x7f010004) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router 127.1.0.5(0x7f010005) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router 127.1.0.6(0x7f010006) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router 127.1.0.7(0x7f010007) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router 127.1.0.8(0x7f010008) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router 127.1.0.9(0x7f010009) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router 127.1.0.10(0x7f01000a) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router 127.1.0.11(0x7f01000b) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router 127.1.0.13(0x7f01000d) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router 127.1.0.14(0x7f01000e) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router 127.1.0.15(0x7f01000f) 0.0.0.0(0) not reachable [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.11) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateAcknowledgementReceived-pseudo-event) Interface(10.12.12/10.12.12) Neighbour(10.10.12.10) State(Loading ) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.11) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.11) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.11) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.11) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.11) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(12.16.12/12.16.12) Neighbour(99.1.1.3) DR (99.1.1.3) BDR (0.0.0.0) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(1-WayReceived) Interface(12.16.12/12.16.12) Neighbour(99.1.1.3) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(12.16.12/12.16.12) Neighbour(99.1.1.2) DR (99.1.1.2) BDR (0.0.0.0) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(1-WayReceived) Interface(12.16.12/12.16.12) Neighbour(99.1.1.2) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(12.16.12/12.16.12) Neighbour(99.1.1.11) DR (99.1.1.11) BDR (0.0.0.0) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(1-WayReceived) Interface(12.16.12/12.16.12) Neighbour(99.1.1.11) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Neighbour(10.12.13.13) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Neighbour(10.12.13.13) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Neighbour(10.12.13.13) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Neighbour(10.12.13.13) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Neighbour(10.12.13.13) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateAcknowledgementReceived-pseudo-event) Interface(12.14.12/12.14.12) Neighbour(10.12.14.14) State(Loading ) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.14.12/12.14.12) Neighbour(10.12.14.14) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.14.12/12.14.12) Neighbour(10.12.14.14) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.14.12/12.14.12) Neighbour(10.12.14.14) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.14.12/12.14.12) Neighbour(10.12.14.14) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) DR (99.1.1.11) BDR (99.1.1.10) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(1-WayReceived) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateAcknowledgementReceived-pseudo-event) Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading ) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateAcknowledgementReceived-pseudo-event) Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading ) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Neighbour(10.10.12.10) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Neighbour(10.10.12.10) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Neighbour(10.10.12.10) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateAcknowledgementReceived-pseudo-event) Interface(12.13.12/12.13.12) Neighbour(10.12.13.13) State(Loading ) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateAcknowledgementReceived-pseudo-event) Interface(12.13.12/12.13.12) Neighbour(10.12.13.13) State(Loading ) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Neighbour(10.12.13.13) State(Loading) [ 2007/10/21 16:07:59 WARNING xorp_fea FEA ] proto_socket_read() warning: Received: 1138000 packets for vifs not in use by this instance [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Neighbour(10.12.13.13) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Neighbour(10.12.13.13) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateAcknowledgementReceived-pseudo-event) Interface(12.14.12/12.14.12) Neighbour(10.12.14.14) State(Loading ) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.14.12/12.14.12) Neighbour(10.12.14.14) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.14.12/12.14.12) Neighbour(10.12.14.14) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.14.12/12.14.12) Neighbour(10.12.14.14) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.14.12/12.14.12) Neighbour(10.12.14.14) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateAcknowledgementReceived-pseudo-event) Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading ) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateAcknowledgementReceived-pseudo-event) Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading ) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Neighbour(10.10.12.10) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Neighbour(10.10.12.10) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateAcknowledgementReceived-pseudo-event) Interface(12.13.12/12.13.12) Neighbour(10.12.13.13) State(Loading ) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateAcknowledgementReceived-pseudo-event) Interface(12.13.12/12.13.12) Neighbour(10.12.13.13) State(Loading ) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Neighbour(10.12.13.13) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateAcknowledgementReceived-pseudo-event) Interface(12.13.12/12.13.12) Neighbour(10.12.13.13) State(Loading ) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Neighbour(10.12.13.13) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.14.12/12.14.12) Neighbour(10.12.14.14) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.14.12/12.14.12) Neighbour(10.12.14.14) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateAcknowledgementReceived-pseudo-event) Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading ) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateAcknowledgementReceived-pseudo-event) Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading ) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateAcknowledgementReceived-pseudo-event) Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading ) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateAcknowledgementReceived-pseudo-event) Interface(10.12.12/10.12.12) Neighbour(10.10.12.10) State(Loading ) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Neighbour(10.10.12.10) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Neighbour(10.10.12.10) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Neighbour(10.10.12.10) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Neighbour(10.10.12.10) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Neighbour(10.12.13.13) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Neighbour(10.12.13.13) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Neighbour(10.12.13.13) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Neighbour(10.12.13.13) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Neighbour(10.12.13.13) State(Loading) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateAcknowledgementReceived-pseudo-event) Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading ) [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateAcknowledgementReceived-pseudo-event) Interface(10.12.12/10.12.12) Neighbour(10.10.12.10) State(Loading ) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Neighbour(10.10.12.10) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Neighbour(10.10.12.10) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Neighbour(10.10.12.10) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Neighbour(10.10.12.10) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Neighbour(10.10.12.10) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Neighbour(10.12.13.13) State(Loading) [ 2007/10/21 16:08:00 WARNING xorp_fea FEA ] proto_socket_read() warning: Received: 1139000 packets for vifs not in use by this instance [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Neighbour(10.12.13.13) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Neighbour(10.12.13.13) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.1.2.2(0xa010202) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.1.3.255(0xa0103ff) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.1.4.4(0xa010404) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.1.5.5(0xa010505) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.1.9.9(0xa010909) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.1.11.255(0xa010bff) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.1.15.255(0xa010fff) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.2.3.3(0xa020303) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.2.3.255(0xa0203ff) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.2.4.4(0xa020404) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.2.5.5(0xa020505) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.2.5.255(0xa0205ff) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.2.6.255(0xa0206ff) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.2.9.9(0xa020909) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.3.4.4(0xa030404) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.3.5.255(0xa0305ff) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.4.5.255(0xa0405ff) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.4.6.255(0xa0406ff) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.6.7.7(0xa060707) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.6.7.255(0xa0607ff) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.6.8.8(0xa060808) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.7.8.255(0xa0708ff) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.9.10.255(0xa090aff) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.9.11.11(0xa090b0b) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.9.11.255(0xa090bff) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.9.13.255(0xa090dff) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.9.14.255(0xa090eff) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.9.15.15(0xa090f0f) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.9.15.255(0xa090fff) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.10.11.255(0xa0a0bff) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.10.13.255(0xa0a0dff) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.10.14.255(0xa0a0eff) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.10.15.255(0xa0a0fff) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.11.13.255(0xa0b0dff) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.11.14.255(0xa0b0eff) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.11.15.255(0xa0b0fff) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.13.14.255(0xa0d0eff) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.13.15.255(0xa0d0fff) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 10.14.15.255(0xa0e0fff) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router 127.1.0.1(0x7f010001) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router 127.1.0.2(0x7f010002) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router 127.1.0.3(0x7f010003) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router 127.1.0.4(0x7f010004) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router 127.1.0.5(0x7f010005) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router 127.1.0.6(0x7f010006) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router 127.1.0.7(0x7f010007) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router 127.1.0.8(0x7f010008) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router 127.1.0.9(0x7f010009) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router 127.1.0.10(0x7f01000a) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router 127.1.0.11(0x7f01000b) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router 127.1.0.13(0x7f01000d) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router 127.1.0.14(0x7f01000e) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router 127.1.0.15(0x7f01000f) 0.0.0.0(0) not reachable [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Neighbour(10.12.13.13) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Neighbour(10.12.13.13) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.14.12/12.14.12) Neighbour(10.12.14.14) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.14.12/12.14.12) Neighbour(10.12.14.14) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.14.12/12.14.12) Neighbour(10.12.14.14) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateAcknowledgementReceived-pseudo-event) Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading ) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateAcknowledgementReceived-pseudo-event) Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading ) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateAcknowledgementReceived-pseudo-event) Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading ) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Neighbour(10.10.12.10) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Neighbour(10.10.12.10) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateAcknowledgementReceived-pseudo-event) Interface(12.13.12/12.13.12) Neighbour(10.12.13.13) State(Loading ) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Neighbour(10.12.13.13) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Neighbour(10.12.13.13) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Neighbour(10.12.13.13) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Neighbour(10.12.13.13) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateAcknowledgementReceived-pseudo-event) Interface(12.14.12/12.14.12) Neighbour(10.12.14.14) State(Loading ) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.14.12/12.14.12) Neighbour(10.12.14.14) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.14.12/12.14.12) Neighbour(10.12.14.14) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.14.12/12.14.12) Neighbour(10.12.14.14) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(12.14.12/12.14.12) Neighbour(10.12.14.14) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateAcknowledgementReceived-pseudo-event) Interface(10.12.12/10.12.12) Neighbour(10.10.12.10) State(Loading ) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Neighbour(10.10.12.10) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Neighbour(10.10.12.10) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Neighbour(10.10.12.10) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Neighbour(10.10.12.10) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Neighbour(10.10.12.10) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Neighbour(10.10.12.10) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Neighbour(10.10.12.10) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Neighbour(10.10.12.10) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Neighbour(10.10.12.10) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Neighbour(10.10.12.10) State(Loading) [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Neighbour(10.10.12.10) State(Loading) -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Mon Oct 22 16:38:15 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Mon, 22 Oct 2007 16:38:15 -0700 Subject: [Xorp-hackers] configuration of static routes In-Reply-To: Message from "Arjun Prasad" of "Mon, 22 Oct 2007 18:17:59 +0530." <000e01c814a9$c7c627e0$2283a8c0@ceeyes.com> Message-ID: <200710222338.l9MNcFUI078362@possum.icir.org> > I tried to configure static routes through CLI but it failed at > creating route on 3rd level > > i.e > level 1 protocols { > level 2 static { > level 3 route 192.168.131.74/24 { > > it is asking for Or after route in level 3rd i gave even though it didnt work. What is the exact error message you see? Pavlin From pavlin at icir.org Mon Oct 22 16:50:21 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Mon, 22 Oct 2007 16:50:21 -0700 Subject: [Xorp-hackers] Bug 234 (DelayValidation & slow xorpsh commands) In-Reply-To: Message from Ben Greear of "Sun, 21 Oct 2007 00:38:07 PDT." <471B01DF.4030702@candelatech.com> Message-ID: <200710222350.l9MNoLRA078499@possum.icir.org> > >> This bug is quite old, but I still see the DelayValidation logic found > >> in the > >> module_command.cc > >> > >> Any clues on what sorts of things need to be changed to get rid of this > >> and put in proper status_methods? I'm interested primarily in OSPF, static > >> routes, and interface handling (if it's a per-module issue). > >> > > > > http://www.xorp.org/bugzilla/show_bug.cgi?id=677 > > > > Any semi-hackish solutions are going to make things worse and even > > less maintainable. > > > Is anyone working on that? Any time someone talks about re-writing > something, seems > it's more of a hope than a reality :) We hope we will get the time to do it ourselves with all the ideas and experience we have accumulated so far :) > In that bug's comments, you mention that decreasing the 2-second delay > might work. Note the sentence right after the above suggestion. Decreasing the 2 second delay might break other things so we need to do lots of testings before we are confident this is not the case. Thanks, Pavlin > I'll give that a try after I get the ospf busy-spin issue resolved. > > Thanks, > Ben > > > Pavlin > > > > > -- > 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 atanu at ICSI.Berkeley.EDU Mon Oct 22 18:05:00 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Mon, 22 Oct 2007 18:05:00 -0700 Subject: [Xorp-hackers] OSPF stuck in Exchange state. In-Reply-To: Message from Ben Greear of "Mon, 22 Oct 2007 09:16:04 PDT." <471CCCC4.7010302@candelatech.com> Message-ID: <17704.1193101500@tigger.icir.org> Hi, If you think that the retransmission code has failed then in the method "doit()" bool doit() { debug_msg("retransmission: %s\n", str().c_str()); return _rcb->dispatch(); } Change the debug_msg to "fprintf(stderr," while an adjacency is in the state Exchange the master side should be retransmitting every second. Atanu. >>>>> "Ben" == Ben Greear writes: Ben> Atanu Ghosh wrote: >> Hi, >> >> This behaviour is correct. >> >> Interfaces of type broadcast and NBMA will elect a DR and BDR if >> there are enough neighbours. In this case only the DR and BDR >> need to form full adjacencies with all neighbours, the other >> neighbours will stay in the 2-Way (TwoWay) state. >> Ben> Thanks for that info, that makes sense. Before asking my next Ben> question: I did read through the rfc, but don't see any reason Ben> for links to be stuck in the Exchange state. However, after Ben> leaving it overnight, it's still like that. The connection Ben> between the routers is an emulated 128kbps sat link (1.5seconds Ben> round-trip), and it drops packets occassionally (or more often Ben> if sent pkts at rates above 128kbps). This sat acts like an Ben> ethernet bridge to other routers connected to it. Maybe there Ben> is some retransmit logic that isn't quite right? Ben> If I restart Xorp a few times, it will eventually come up with Ben> all in 'full' state (on router 12, which appears to be the Ben> master) . I see hellos from the nodes in Exchange state, so it Ben> seems they should be able to communicate. Ben> [root at lf1016-55 lanforge]# tcpdump -n -i 2.16.2 tcpdump: Ben> verbose output suppressed, use -v or -vv for full protocol Ben> decode listening on br0, link-type EN10MB (Ethernet), capture Ben> size 96 bytes 09:04:32.113138 IP 99.1.1.12 > 224.0.0.5: OSPFv2, Ben> Hello, length: 68 09:04:32.493651 IP 99.1.1.11 > 224.0.0.5: Ben> OSPFv2, Hello, length: 68 09:04:32.506866 IP 99.1.1.10 > Ben> 224.0.0.5: OSPFv2, Hello, length: 68 09:04:32.541082 IP Ben> 99.1.1.2 > 224.0.0.5: OSPFv2, Hello, length: 68 09:04:32.911437 Ben> IP 99.1.1.6 > 224.0.0.5: OSPFv2, Hello, length: 68 Ben> 5 packets captured 10 packets received by filter 0 packets Ben> dropped by kernel Ben> This is for router '2'. Ben> [root at lf1016-55 lanforge]# xorpsh Welcome to XORP on lf1016-55 Ben> root at lf1016-55> show ospf4 neighbor Address Interface State ID Ben> Pri Dead 99.1.1.12 2.16.2/2.16.2 Exchange 127.1.0.12 128 38 Ben> 99.1.1.10 2.16.2/2.16.2 TwoWay 127.1.0.10 128 39 99.1.1.11 Ben> 2.16.2/2.16.2 Exchange 127.1.0.11 128 39 99.1.1.6 2.16.2/2.16.2 Ben> TwoWay 127.1.0.6 128 39 99.1.1.9 2.16.2/2.16.2 TwoWay 127.1.0.9 Ben> 128 34 99.1.1.3 2.16.2/2.16.2 TwoWay 127.1.0.3 128 37 10.1.2.1 Ben> 1.2.2/1.2.2 Full 127.1.0.1 128 34 10.2.3.3 2.3.2/2.3.2 Full Ben> 127.1.0.3 128 35 10.2.4.4 2.4.2/2.4.2 Full 127.1.0.4 128 32 Ben> 10.2.5.5 2.5.2/2.5.2 Full 127.1.0.5 128 37 10.2.6.6 2.6.2/2.6.2 Ben> Full 127.1.0.6 128 38 10.2.9.9 2.9.2/2.9.2 Full 127.1.0.9 128 Ben> 33 10.2.10.10 2.10.2/2.10.2 Full 127.1.0.10 128 38 Ben> root at lf1016-55> quit [root at lf1016-55 lanforge]# Ben> Here is the 'show ospf neighbor' for router '12': Ben> Welcome to XORP on lf1016-55 root at lf1016-55> show ospf4 Ben> neighbor Address Interface State ID Pri Dead 99.1.1.3 Ben> 12.16.12/12.16.12 Full 127.1.0.3 128 34 99.1.1.10 Ben> 12.16.12/12.16.12 Full 127.1.0.10 128 34 99.1.1.2 Ben> 12.16.12/12.16.12 Exchange 127.1.0.2 128 34 99.1.1.11 Ben> 12.16.12/12.16.12 Full 127.1.0.11 128 34 99.1.1.6 Ben> 12.16.12/12.16.12 Full 127.1.0.6 128 34 99.1.1.9 Ben> 12.16.12/12.16.12 Full 127.1.0.9 128 31 10.1.12.1 Ben> 1.12.12/1.12.12 Full 127.1.0.1 128 30 10.9.12.9 9.12.12/9.12.12 Ben> Full 127.1.0.9 128 39 10.10.12.10 10.12.12/10.12.12 Full Ben> 127.1.0.10 128 33 10.11.12.11 11.12.12/11.12.12 Full 127.1.0.11 Ben> 128 33 10.12.13.13 12.13.12/12.13.12 Full 127.1.0.13 128 34 Ben> 10.12.14.14 12.14.12/12.14.12 Full 127.1.0.14 128 33 Ben> 10.12.15.15 12.15.12/12.15.12 Full 127.1.0.15 128 34 Ben> root at lf1016-55> Ben> Thanks, Ben Ben> -- Ben Greear Candela Technologies Ben> Inc http://www.candelatech.com From greearb at candelatech.com Mon Oct 22 18:15:00 2007 From: greearb at candelatech.com (Ben Greear) Date: Mon, 22 Oct 2007 18:15:00 -0700 Subject: [Xorp-hackers] OSPF stuck in Exchange state. In-Reply-To: <17704.1193101500@tigger.icir.org> References: <17704.1193101500@tigger.icir.org> Message-ID: <471D4B14.1090508@candelatech.com> Atanu Ghosh wrote: > Hi, > > If you think that the retransmission code has failed then in the method > "doit()" > > bool doit() { > debug_msg("retransmission: %s\n", str().c_str()); > return _rcb->dispatch(); > > } > > Change the debug_msg to "fprintf(stderr," while an adjacency is in the > state Exchange the master side should be retransmitting every second. I found the ::retransmitter() code in peer.cc, and am compiling logging into it now. Is this part of the code chain that should be resending the data-description packet? I'll look for the method you mention above as well. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From atanu at ICSI.Berkeley.EDU Mon Oct 22 18:35:23 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Mon, 22 Oct 2007 18:35:23 -0700 Subject: [Xorp-hackers] OSPF stuck in Exchange state. In-Reply-To: Message from Ben Greear of "Mon, 22 Oct 2007 18:15:00 PDT." <471D4B14.1090508@candelatech.com> Message-ID: <24657.1193103323@tigger.icir.org> >>>>> "Ben" == Ben Greear writes: Ben> Atanu Ghosh wrote: >> Hi, >> If you think that the retransmission code has failed then in the >> method >> "doit()" >> bool doit() { >> debug_msg("retransmission: %s\n", str().c_str()); >> return _rcb->dispatch(); >> } >> Change the debug_msg to "fprintf(stderr," while an adjacency is in >> the >> state Exchange the master side should be retransmitting every second. Ben> I found the ::retransmitter() code in peer.cc, and am compiling logging into Ben> it now. Is this part of the code chain that should be resending the data-description Ben> packet? No - I think this code path is used later after the database descriptions have been exchanged. Look at "start_sending_data_description_packets()" at the end you will see "start_rxmt_timer()". Please note that the slave side of the transaction does *not* retransmit. By the way the retransmission is not every second, it's every five seconds and is taken from the configuration variable "retransmit-interval". Atanu. From greearb at candelatech.com Mon Oct 22 19:44:16 2007 From: greearb at candelatech.com (Ben Greear) Date: Mon, 22 Oct 2007 19:44:16 -0700 Subject: [Xorp-hackers] OSPF stuck in Exchange state. In-Reply-To: <24657.1193103323@tigger.icir.org> References: <24657.1193103323@tigger.icir.org> Message-ID: <471D6000.7060702@candelatech.com> Atanu Ghosh wrote: >>>>>> "Ben" == Ben Greear writes: > > Ben> Atanu Ghosh wrote: > >> Hi, > >> If you think that the retransmission code has failed then in the > >> method > >> "doit()" > >> bool doit() { > >> debug_msg("retransmission: %s\n", str().c_str()); > >> return _rcb->dispatch(); > >> } > >> Change the debug_msg to "fprintf(stderr," while an adjacency is in > >> the > >> state Exchange the master side should be retransmitting every second. > > Ben> I found the ::retransmitter() code in peer.cc, and am compiling logging into > Ben> it now. Is this part of the code chain that should be resending the data-description > Ben> packet? > > No - I think this code path is used later after the database > descriptions have been exchanged. > > Look at "start_sending_data_description_packets()" at the end you will > see "start_rxmt_timer()". Please note that the slave side of the > transaction does *not* retransmit. > > By the way the retransmission is not every second, it's every five > seconds and is taken from the configuration variable > "retransmit-interval". I think this snippet shows the problem. We are disabling the old timer and starting a new timer. [ 2007/10/22 19:38:04 TRACE xorp_ospfv2 OSPF ] Event(NegotiationDone) Interface(12.16.12/12.16.12) Neighbour(99.1.1.9) State(ExStart) [ 2007/10/22 19:38:04 TRACE xorp_ospfv2 OSPF ] stop_rxmt_timer: 0x838ab08 12.16.12/12.16.12 Neighbour: 99.1.1.9 NegotiationDone (master) [ 2007/10/22 19:38:04 TRACE xorp_ospfv2 OSPF ] start_rxmt_timer: 0x838ab08 12.16.12/12.16.12 Neighbour: 99.1.1.9 send_data_description from NegotiationDone [ 2007/10/22 19:38:04 TRACE xorp_ospfv2 OSPF ] send_data_description_packet, Interface(12.16.12/12.16.12) Neighbour(99.1.1.9) State(Exchange) [ 2007/10/22 19:38:05 TRACE xorp_ospfv2 OSPF ] stop_rxmt_timer: 0x838ab08 12.16.12/12.16.12 Neighbour: 99.1.1.9 push_lsas [ 2007/10/22 19:38:05 TRACE xorp_ospfv2 OSPF ] start_rxmt_timer: 0x838ab08 12.16.12/12.16.12 Neighbour: 99.1.1.9 push_lsas [ 2007/10/22 19:38:05 TRACE xorp_ospfv2 OSPF ] stop_rxmt_timer: 0x838ab08 12.16.12/12.16.12 Neighbour: 99.1.1.9 push_lsas [ 2007/10/22 19:38:05 TRACE xorp_ospfv2 OSPF ] start_rxmt_timer: 0x838ab08 12.16.12/12.16.12 Neighbour: 99.1.1.9 push_lsas even though we are not out of the Exchange state ... [ 2007/10/22 19:38:06 TRACE xorp_ospfv2 OSPF ] start_rxmt_timer: 0x838ab08 12.16.12/12.16.12 Neighbour: 99.1.1.9 push_lsas [ 2007/10/22 19:38:06 TRACE xorp_ospfv2 OSPF ] Event(LoadingDone) Interface(12.16.12/12.16.12) Neighbour(99.1.1.9) State(Exchange) > > Atanu. -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Mon Oct 22 20:30:47 2007 From: greearb at candelatech.com (Ben Greear) Date: Mon, 22 Oct 2007 20:30:47 -0700 Subject: [Xorp-hackers] OSPF stuck in Exchange state. In-Reply-To: <471D6000.7060702@candelatech.com> References: <24657.1193103323@tigger.icir.org> <471D6000.7060702@candelatech.com> Message-ID: <471D6AE7.1040809@candelatech.com> Ben Greear wrote: > I think this snippet shows the problem. We are disabling the old timer and starting > a new timer. > > [ 2007/10/22 19:38:04 TRACE xorp_ospfv2 OSPF ] Event(NegotiationDone) Interface(12.16.12/12.16.12) Neighbour(99.1.1.9) State(ExStart) > [ 2007/10/22 19:38:04 TRACE xorp_ospfv2 OSPF ] stop_rxmt_timer: 0x838ab08 12.16.12/12.16.12 Neighbour: 99.1.1.9 NegotiationDone (master) > [ 2007/10/22 19:38:04 TRACE xorp_ospfv2 OSPF ] start_rxmt_timer: 0x838ab08 12.16.12/12.16.12 Neighbour: 99.1.1.9 send_data_description from NegotiationDone > [ 2007/10/22 19:38:04 TRACE xorp_ospfv2 OSPF ] send_data_description_packet, Interface(12.16.12/12.16.12) Neighbour(99.1.1.9) State(Exchange) > [ 2007/10/22 19:38:05 TRACE xorp_ospfv2 OSPF ] stop_rxmt_timer: 0x838ab08 12.16.12/12.16.12 Neighbour: 99.1.1.9 push_lsas > [ 2007/10/22 19:38:05 TRACE xorp_ospfv2 OSPF ] start_rxmt_timer: 0x838ab08 12.16.12/12.16.12 Neighbour: 99.1.1.9 push_lsas > [ 2007/10/22 19:38:05 TRACE xorp_ospfv2 OSPF ] stop_rxmt_timer: 0x838ab08 12.16.12/12.16.12 Neighbour: 99.1.1.9 push_lsas > [ 2007/10/22 19:38:05 TRACE xorp_ospfv2 OSPF ] start_rxmt_timer: 0x838ab08 12.16.12/12.16.12 Neighbour: 99.1.1.9 push_lsas > > even though we are not out of the Exchange state > ... > [ 2007/10/22 19:38:06 TRACE xorp_ospfv2 OSPF ] start_rxmt_timer: 0x838ab08 12.16.12/12.16.12 Neighbour: 99.1.1.9 push_lsas > [ 2007/10/22 19:38:06 TRACE xorp_ospfv2 OSPF ] Event(LoadingDone) Interface(12.16.12/12.16.12) Neighbour(99.1.1.9) State(Exchange) So, it seems push_lsas causes the send_data_description timer to be over-written. This code seems to do the trick (ignore all the extra debugging..I want to keep it in longer to help find other bugs more quickly.) Another fix might be to have multiple timers..as this problem could exist elsewhere. template bool Neighbour::push_lsas(const char* message) { if (get_state() == Exchange) { XLOG_TRACE(true, "WARNING: cannot do a push_lsas in Exchange state because that will" " over-write our one and only timer that needs to finish with send_data_description" " state first, neighbour: %p %s Neighbour: %s State: %s %s\n", this, _peer.get_if_name().c_str(), pr_id(get_candidate_id()).c_str(), pp_state(get_state()).c_str(), message); // Can't return false here...calling code will assert in area_router.cc --Ben return true; } > > > >> Atanu. > > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Mon Oct 22 21:10:30 2007 From: greearb at candelatech.com (Ben Greear) Date: Mon, 22 Oct 2007 21:10:30 -0700 Subject: [Xorp-hackers] xorp_fea crashes when interface is removed from OS at in-opportune time. In-Reply-To: <471976EB.5030907@candelatech.com> References: <47196D9D.5010207@candelatech.com> <471976EB.5030907@candelatech.com> Message-ID: <471D7436.5000707@candelatech.com> This fixes another potential crash due to interface removal races. Index: ifconfig_parse_netlink_socket.cc =================================================================== RCS file: /cvs/xorp/fea/data_plane/ifconfig/ifconfig_parse_netlink_socket.cc,v retrieving revision 1.11 diff -u -r1.11 ifconfig_parse_netlink_socket.cc --- ifconfig_parse_netlink_socket.cc 25 Sep 2007 23:00:29 -0000 1.11 +++ ifconfig_parse_netlink_socket.cc 23 Oct 2007 04:08:03 -0000 @@ -447,7 +449,9 @@ // XXX: vifname == ifname on this platform IfTreeVif* vifp = iftree.find_vif(if_name, if_name); if (vifp == NULL) { - XLOG_FATAL("Could not find vif named %s in IfTree", if_name.c_str()); + XLOG_ERROR("Could not find vif named %s in IfTree, dbg: %i if_index: %i, maybe it was just deleted?", + if_name.c_str(), dbg, if_index); + return; } // Ben Greear wrote: > Ben Greear wrote: >> Seems xorp is very fragile when it comes to adding/deleting >> interfaces. I think a lot of these errors should just be warnings, >> not asserts. > > And another related to the first: > > diff -u -r1.15 fibconfig_entry_set_netlink_socket.cc > --- fibconfig_entry_set_netlink_socket.cc 12 Oct 2007 07:53:47 -0000 1.15 > +++ fibconfig_entry_set_netlink_socket.cc 20 Oct 2007 03:10:55 -0000 > @@ -256,7 +256,11 @@ > break; > const IfTree& iftree = fibconfig().iftree(); > const IfTreeInterface* ifp = iftree.find_interface(fte.ifname()); > - XLOG_ASSERT(ifp != NULL); > + if (!ifp) { > + XLOG_ERROR("Could not find interface: %s, maybe it was just deleted?\n", > + fte.ifname().c_str()); > + return XORP_ERROR; > + } > > if (ifp->discard()) { > rtmsg->rtm_type = RTN_BLACKHOLE; > > > (gdb) bt > #0 0xffffe410 in __kernel_vsyscall () > #1 0x49d42ee9 in raise () from /lib/libc.so.6 > #2 0x49d444f1 in abort () from /lib/libc.so.6 > #3 0x08287669 in xlog_fatal (module_name=Could not find the frame base for "xlog_fatal". > ) at xlog.c:435 > #4 0x081069a8 in FibConfigEntrySetNetlinkSocket::add_entry (this=0x842ee50, fte=@0x77d9d2d4) > at fibconfig_entry_set_netlink_socket.cc:259 > #5 0x0810707d in FibConfigEntrySetNetlinkSocket::add_entry4 (this=0x842ee50, fte=@0x8473ee0) > at fibconfig_entry_set_netlink_socket.cc:100 > #6 0x0807eee4 in FibConfig::add_entry4 (this=0x77da993c, fte=@0x8473ee0) at fibconfig.cc:1077 > #7 0x0805e025 in FibAddEntry4::dispatch (this=0x8473ed8) at fibconfig_transaction.hh:112 > #8 0x082b2387 in TransactionManager::Transaction::commit (this=0x8442eec) at transaction.cc:59 > #9 0x082b0e76 in TransactionManager::commit (this=0x837e910, tid=24373279) at transaction.cc:201 > #10 0x08080684 in FibConfig::commit_transaction (this=0x77da993c, tid=24373279, error_msg=@0x77d9d480) > at fibconfig.cc:135 > #11 0x080553ad in XrlFeaTarget::redist_transaction4_0_1_commit_transaction (this=0x77daa470, tid=@0x84701bc) > at xrl_fea_target.cc:2351 > #12 0x0817db00 in XrlFeaTargetBase::handle_redist_transaction4_0_1_commit_transaction (this=0x77daa470, > xa_inputs=@0x77da14fc) at fea_base.cc:3230 > #13 0x081a894f in XorpMemberCallback2B0::dispatch ( > this=0x8418148, a1=@0x77da14fc, a2=0x77da14e0) at ../../libxorp/callback_nodebug.hh:4615 > #14 0x08256f25 in XrlCmdEntry::dispatch (this=0x84181b4, inputs=@0x77da14fc, outputs=0x77da14e0) at xrl_cmd_map.hh:37 > #15 0x0825da1a in XrlDispatcher::dispatch_xrl (this=0x77da9648, method_name=@0x77da1470, inputs=@0x77da14fc, > outputs=@0x77da14e0) at xrl_dispatcher.cc:60 > #16 0x08240d19 in XrlRouter::dispatch_xrl (this=0x77da9648, method_name=@0x77da14f8, inputs=@0x77da14fc, > outputs=@0x77da14e0) at xrl_router.cc:587 > #17 0x08265efd in STCPRequestHandler::dispatch_request (this=0x847dc20, seqno=1249, packed_xrl=0x6fd0987c "?", > packed_xrl_bytes=101) at xrl_pf_stcp.cc:235 > #18 0x082665d3 in STCPRequestHandler::read_event (this=0x847dc20, ev=BufferedAsyncReader::DATA, > buffer=0x6fd09864 "STCP\001\001", buffer_bytes=125) at xrl_pf_stcp.cc:199 > #19 0x08267bcc in XorpMemberCallback4B0::dispatch (this=0x8446dc0, a1=0x847dc28, a2=BufferedAsyncReader::DATA, > a3=0x6fd09864 "STCP\001\001", a4=125) at ../libxorp/callback_nodebug.hh:8965 > #20 0x0828c0b3 in BufferedAsyncReader::announce_event (this=0x847dc28, ev=BufferedAsyncReader::DATA) > at buffered_asyncio.cc:248 > #21 0x0828c3f2 in BufferedAsyncReader::io_event (this=0x847dc28, fd={_filedesc = 51}, type=IOT_READ) > at buffered_asyncio.cc:201 > #22 0x0828cc34 in XorpMemberCallback2B0::dispatch (this=0x847ab18, a1= > {_filedesc = 51}, a2=IOT_READ) at ../libxorp/callback_nodebug.hh:4635 > #23 0x082a8766 in SelectorList::Node::run_hooks (this=0x84750dc, m=SEL_RD, fd={_filedesc = 51}) at selector.cc:149 > #24 0x082a73d1 in SelectorList::wait_and_dispatch (this=0x77daa4e4, timeout=@0x77da95d0) at selector.cc:435 > ---Type to continue, or q to quit--- > #25 0x0828e5a0 in EventLoop::run (this=0x77daa4a8) at eventloop.cc:137 > #26 0x0804d192 in fea_main (finder_hostname=@0x77daa6c0, finder_port=19999) at xorp_fea.cc:101 > #27 0x0804d478 in main (argc=0, argv=0x77daa788) at xorp_fea.cc:175 > (gdb) frame 4 > #4 0x081069a8 in FibConfigEntrySetNetlinkSocket::add_entry (this=0x842ee50, fte=@0x77d9d2d4) > at fibconfig_entry_set_netlink_socket.cc:259 > 259 fibconfig_entry_set_netlink_socket.cc: No such file or directory. > in fibconfig_entry_set_netlink_socket.cc > (gdb) print fte > $1 = (const FteX &) @0x77d9d2d4: {> = {_net = {> = {_masked_addr = {_addr = {196874, 0, > 0, 0}, _af = 2}, _prefix_len = 24}, }, _nexthop = {_addr = {67503114, 0, 0, 0}, _af = 2}, > _ifname = {static npos = 4294967295, > _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x847c4fc "4.6.6"}}, _vifname = {static npos = 4294967295, > _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x8444bf4 "4.6.6"}}, _metric = 3, _admin_distance = 110, _xorp_route = true, _is_deleted = false, > _is_unresolved = false, _is_connected_route = false}, } > (gdb) > > > > > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From arjun at ceeyes.com Mon Oct 22 21:38:09 2007 From: arjun at ceeyes.com (arjun at ceeyes.com) Date: Tue, 23 Oct 2007 00:38:09 -0400 Subject: [Xorp-hackers] (no subject) Message-ID: <380-22007102234389714@M2W009.mail2web.com> Hi all! I tried to configure static routes through CLI but it failed at creating route on 3rd level i.e level 1 protocols { level 2 static { level 3 route 192.168.131.74/24 { following error i got at this level 3rd:- syntax error, expecting `',or `'. plz write what should be the in 3rd level and onwards Thanking u All in advance Arjun -------------------------------------------------------------------- mail2web - Check your email from the web at http://link.mail2web.com/mail2web From greearb at candelatech.com Mon Oct 22 21:52:48 2007 From: greearb at candelatech.com (Ben Greear) Date: Mon, 22 Oct 2007 21:52:48 -0700 Subject: [Xorp-hackers] (no subject) In-Reply-To: <380-22007102234389714@M2W009.mail2web.com> References: <380-22007102234389714@M2W009.mail2web.com> Message-ID: <471D7E20.5090409@candelatech.com> arjun at ceeyes.com wrote: > > Hi all! > > > I tried to configure static routes through CLI but it failed at > creating route on 3rd level > > i.e > level 1 protocols { > level 2 static { > level 3 route 192.168.131.74/24 { > > following error i got at this level 3rd:- > > syntax error, expecting `',or `'. > > plz write what should be the in 3rd level and onwards > > Thanking u All in advance > Arjun > Hit 'tab', it will list the alternatives for you at each level. The user-guide has good examples as well. Thanks, Ben > > > > -------------------------------------------------------------------- > mail2web - Check your email from the web at > http://link.mail2web.com/mail2web > > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Mon Oct 22 22:41:08 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Mon, 22 Oct 2007 22:41:08 -0700 Subject: [Xorp-hackers] (no subject) In-Reply-To: Message from "arjun@ceeyes.com" of "Tue, 23 Oct 2007 00:38:09 EDT." <380-22007102234389714@M2W009.mail2web.com> Message-ID: <200710230541.l9N5f8Yq086243@possum.icir.org> arjun at ceeyes.com wrote: > > Hi all! > > > I tried to configure static routes through CLI but it failed at > creating route on 3rd level > > i.e > level 1 protocols { > level 2 static { > level 3 route 192.168.131.74/24 { > > following error i got at this level 3rd:- > > syntax error, expecting `',or `'. Try to use 192.168.131.00/24 instead of 192.168.131.74/24. The subnet address should have the bits after the netmask set to zero. Hope that helps, Pavlin > plz write what should be the in 3rd level and onwards > > Thanking u All in advance > Arjun > > > > > -------------------------------------------------------------------- > mail2web - Check your email from the web at > http://link.mail2web.com/mail2web > > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From arjun at ceeyes.com Tue Oct 23 00:13:38 2007 From: arjun at ceeyes.com (arjun at ceeyes.com) Date: Tue, 23 Oct 2007 03:13:38 -0400 Subject: [Xorp-hackers] (no subject) Message-ID: <380-220071022371338424@M2W037.mail2web.com> Hi! It didn't work. same error is coming. plz write a sample static config. Regards, Arjun Original Message: ----------------- From: Pavlin Radoslavov pavlin at icir.org Date: Mon, 22 Oct 2007 22:41:08 -0700 To: arjun at ceeyes.com, xorp-hackers at icir.org Subject: Re: [Xorp-hackers] (no subject) arjun at ceeyes.com wrote: > > Hi all! > > > I tried to configure static routes through CLI but it failed at > creating route on 3rd level > > i.e > level 1 protocols { > level 2 static { > level 3 route 192.168.131.74/24 { > > following error i got at this level 3rd:- > > syntax error, expecting `',or `'. Try to use 192.168.131.00/24 instead of 192.168.131.74/24. The subnet address should have the bits after the netmask set to zero. Hope that helps, Pavlin > plz write what should be the in 3rd level and onwards > > Thanking u All in advance > Arjun > > > > > -------------------------------------------------------------------- > mail2web - Check your email from the web at > http://link.mail2web.com/mail2web > > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers -------------------------------------------------------------------- mail2web.com - Microsoft? Exchange solutions from a leading provider - http://link.mail2web.com/Business/Exchange From pavlin at icir.org Tue Oct 23 00:43:28 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 23 Oct 2007 00:43:28 -0700 Subject: [Xorp-hackers] (no subject) In-Reply-To: Message from "arjun@ceeyes.com" of "Tue, 23 Oct 2007 03:13:38 EDT." <380-220071022371338424@M2W037.mail2web.com> Message-ID: <200710230743.l9N7hSUP087619@possum.icir.org> arjun at ceeyes.com wrote: > > Hi! > > It didn't work. same error is coming. > plz write a sample static config. See the "Static Routes" subsection in the "Protocols" section: http://www.xorp.org/getting_started.html Of course you also need to configure the "interfaces" and the "fea". See the above URL for details and sample configurations. Pavlin > Regards, > Arjun > > Original Message: > ----------------- > From: Pavlin Radoslavov pavlin at icir.org > Date: Mon, 22 Oct 2007 22:41:08 -0700 > To: arjun at ceeyes.com, xorp-hackers at icir.org > Subject: Re: [Xorp-hackers] (no subject) > > > arjun at ceeyes.com wrote: > > > > > Hi all! > > > > > > I tried to configure static routes through CLI but it failed at > > creating route on 3rd level > > > > i.e > > level 1 protocols { > > level 2 static { > > level 3 route 192.168.131.74/24 { > > > > following error i got at this level 3rd:- > > > > syntax error, expecting `',or `'. > > Try to use 192.168.131.00/24 instead of 192.168.131.74/24. > The subnet address should have the bits after the netmask set to > zero. > > Hope that helps, > Pavlin > > > plz write what should be the in 3rd level and onwards > > > > Thanking u All in advance > > Arjun > > > > > > > > > > -------------------------------------------------------------------- > > mail2web - Check your email from the web at > > http://link.mail2web.com/mail2web > > > > > > > > _______________________________________________ > > Xorp-hackers mailing list > > Xorp-hackers at icir.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > > -------------------------------------------------------------------- > mail2web.com - Microsoft? Exchange solutions from a leading provider - > http://link.mail2web.com/Business/Exchange > > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From luca.giraudo at gmail.com Tue Oct 23 00:51:25 2007 From: luca.giraudo at gmail.com (Luca Giraudo) Date: Tue, 23 Oct 2007 09:51:25 +0200 Subject: [Xorp-hackers] (no subject) In-Reply-To: <380-220071022371338424@M2W037.mail2web.com> References: <380-220071022371338424@M2W037.mail2web.com> Message-ID: <33404c390710230051h6f17f8eah4e120ac8ff48ec81@mail.gmail.com> This is my configuration of static routes. If you want a preinstalled static route try this: ------------------------------- protocols { static { route 10.1.1.0/24 { next-hop: 10.1.0.4 metric: 10 } } } ------------------------------- else, if you want only to start the static routes process: ------------------------------- protocols { static { } } ------------------------------- Luca -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20071023/99516647/attachment.html From arjun at ceeyes.com Tue Oct 23 01:22:31 2007 From: arjun at ceeyes.com (arjun at ceeyes.com) Date: Tue, 23 Oct 2007 04:22:31 -0400 Subject: [Xorp-hackers] (no subject) Message-ID: <380-220071022382231538@M2W005.mail2web.com> Hi Sir! I have allready configured interface, RIP,FEA,OSPF. All are working(i.e i m able to execute commands corresponding to these protocols) After that i was tring to config. static routes but got that problem. Regards Arjun Original Message: ----------------- From: Pavlin Radoslavov pavlin at icir.org Date: Tue, 23 Oct 2007 00:43:28 -0700 To: arjun at ceeyes.com, pavlin at icir.org, xorp-hackers at icir.org Subject: Re: [Xorp-hackers] (no subject) arjun at ceeyes.com wrote: > > Hi! > > It didn't work. same error is coming. > plz write a sample static config. See the "Static Routes" subsection in the "Protocols" section: http://www.xorp.org/getting_started.html Of course you also need to configure the "interfaces" and the "fea". See the above URL for details and sample configurations. Pavlin > Regards, > Arjun > > Original Message: > ----------------- > From: Pavlin Radoslavov pavlin at icir.org > Date: Mon, 22 Oct 2007 22:41:08 -0700 > To: arjun at ceeyes.com, xorp-hackers at icir.org > Subject: Re: [Xorp-hackers] (no subject) > > > arjun at ceeyes.com wrote: > > > > > Hi all! > > > > > > I tried to configure static routes through CLI but it failed at > > creating route on 3rd level > > > > i.e > > level 1 protocols { > > level 2 static { > > level 3 route 192.168.131.74/24 { > > > > following error i got at this level 3rd:- > > > > syntax error, expecting `',or `'. > > Try to use 192.168.131.00/24 instead of 192.168.131.74/24. > The subnet address should have the bits after the netmask set to > zero. > > Hope that helps, > Pavlin > > > plz write what should be the in 3rd level and onwards > > > > Thanking u All in advance > > Arjun > > > > > > > > > > -------------------------------------------------------------------- > > mail2web - Check your email from the web at > > http://link.mail2web.com/mail2web > > > > > > > > _______________________________________________ > > Xorp-hackers mailing list > > Xorp-hackers at icir.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > > -------------------------------------------------------------------- > mail2web.com - Microsoft? Exchange solutions from a leading provider - > http://link.mail2web.com/Business/Exchange > > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers -------------------------------------------------------------------- mail2web LIVE ? Free email based on Microsoft? Exchange technology - http://link.mail2web.com/LIVE From atanu at ICSI.Berkeley.EDU Tue Oct 23 02:08:07 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Tue, 23 Oct 2007 02:08:07 -0700 Subject: [Xorp-hackers] OSPF stuck in Exchange state. In-Reply-To: Message from Ben Greear of "Mon, 22 Oct 2007 20:30:47 PDT." <471D6AE7.1040809@candelatech.com> Message-ID: <43351.1193130487@tigger.icir.org> An embedded message was scrubbed... From: Atanu Ghosh Subject: [Xorp-cvs] XORP cvs commit: xorp/ospf Date: Tue, 23 Oct 2007 08:59:55 GMT Size: 4123 Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20071023/5c112bea/attachment-0001.mht From pavlin at icir.org Tue Oct 23 02:08:09 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 23 Oct 2007 02:08:09 -0700 Subject: [Xorp-hackers] (no subject) In-Reply-To: Message from "arjun@ceeyes.com" of "Tue, 23 Oct 2007 04:22:31 EDT." <380-220071022382231538@M2W005.mail2web.com> Message-ID: <200710230908.l9N989rS088600@possum.icir.org> arjun at ceeyes.com wrote: > > Hi Sir! > > I have allready configured interface, RIP,FEA,OSPF. > All are working(i.e i m able to execute commands corresponding to these > protocols) > After that i was tring to config. static routes but got that problem. In that case please send a copy of your configuration (before you attempt to configure static routes), and a copy (copy-and-paste) of the xorpsh commands and error messages. Thanks, Pavlin > Regards > Arjun > Original Message: > ----------------- > From: Pavlin Radoslavov pavlin at icir.org > Date: Tue, 23 Oct 2007 00:43:28 -0700 > To: arjun at ceeyes.com, pavlin at icir.org, xorp-hackers at icir.org > Subject: Re: [Xorp-hackers] (no subject) > > > arjun at ceeyes.com wrote: > > > > > Hi! > > > > It didn't work. same error is coming. > > plz write a sample static config. > > See the "Static Routes" subsection in the "Protocols" section: > http://www.xorp.org/getting_started.html > > Of course you also need to configure the "interfaces" and the "fea". > See the above URL for details and sample configurations. > > Pavlin > > > Regards, > > Arjun > > > > Original Message: > > ----------------- > > From: Pavlin Radoslavov pavlin at icir.org > > Date: Mon, 22 Oct 2007 22:41:08 -0700 > > To: arjun at ceeyes.com, xorp-hackers at icir.org > > Subject: Re: [Xorp-hackers] (no subject) > > > > > > arjun at ceeyes.com wrote: > > > > > > > > Hi all! > > > > > > > > > I tried to configure static routes through CLI but it failed at > > > creating route on 3rd level > > > > > > i.e > > > level 1 protocols { > > > level 2 static { > > > level 3 route 192.168.131.74/24 { > > > > > > following error i got at this level 3rd:- > > > > > > syntax error, expecting `',or `'. > > > > Try to use 192.168.131.00/24 instead of 192.168.131.74/24. > > The subnet address should have the bits after the netmask set to > > zero. > > > > Hope that helps, > > Pavlin > > > > > plz write what should be the in 3rd level and onwards > > > > > > Thanking u All in advance > > > Arjun > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > mail2web - Check your email from the web at > > > http://link.mail2web.com/mail2web > > > > > > > > > > > > _______________________________________________ > > > Xorp-hackers mailing list > > > Xorp-hackers at icir.org > > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > > > > > -------------------------------------------------------------------- > > mail2web.com - Microsoft? Exchange solutions from a leading provider - > > http://link.mail2web.com/Business/Exchange > > > > > > > > _______________________________________________ > > Xorp-hackers mailing list > > Xorp-hackers at icir.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > > -------------------------------------------------------------------- > mail2web LIVE ? Free email based on Microsoft? Exchange technology - > http://link.mail2web.com/LIVE > > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From kristian at spritelink.net Tue Oct 23 02:10:31 2007 From: kristian at spritelink.net (Kristian Larsson) Date: Tue, 23 Oct 2007 11:10:31 +0200 Subject: [Xorp-hackers] configuration of static routes In-Reply-To: <000e01c814a9$c7c627e0$2283a8c0@ceeyes.com> References: <000e01c814a9$c7c627e0$2283a8c0@ceeyes.com> Message-ID: <20071023091031.GC11007@spritelink.se> On Mon, Oct 22, 2007 at 06:17:59PM +0530, Arjun Prasad wrote: > Hi all! > I tried to configure static routes through CLI but it failed at > creating route on 3rd level > > i.e > level 1 protocols { > level 2 static { > level 3 route 192.168.131.74/24 { Did you by any chance mean 192.168.131.0/24 ? -K -- Kristian Larsson KLL-RIPE Network Engineer & Peering Coordinator SpriteLink [AS39525] +46 704 910401 kll at spritelink.net From greearb at candelatech.com Tue Oct 23 08:57:01 2007 From: greearb at candelatech.com (Ben Greear) Date: Tue, 23 Oct 2007 08:57:01 -0700 Subject: [Xorp-hackers] OSPF stuck in Exchange state. In-Reply-To: <43351.1193130487@tigger.icir.org> References: <43351.1193130487@tigger.icir.org> Message-ID: <471E19CD.3000603@candelatech.com> Atanu Ghosh wrote: > Hi, > > Thanks for finding the problem. > > A fix is now in CVS using two timers. > > Thanks, this does seem to fix the problem. I'm also attaching a patch that adds more trace messages, which might be useful for future debugging, just in case you want to apply them. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -------------- next part -------------- A non-text attachment was scrubbed... Name: xorp_ospf.patch Type: text/x-patch Size: 8932 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20071023/8463e84b/attachment.bin From jonirucoeith at gmail.com Tue Oct 23 11:16:49 2007 From: jonirucoeith at gmail.com (Jon) Date: Tue, 23 Oct 2007 20:16:49 +0200 Subject: [Xorp-hackers] OSPF on high latency links Message-ID: <471f67780710231116x3995ea1iec35b0ca7add9039@mail.gmail.com> Hi all, I have a problem with ospf loosing connection over high latency links. The link in question will induce a delay from minimum 1 sec to a maximum of more than 20 sec. (Yes, such links do exist:-/ ) I have tried to set the hello and router-dead intervals to 60 and 240 respectivly, but I still loose the connection. I have also tried to manipulate transmit-delay and retransmit in order to handle the latency (20 and 90secs) but no luck so far. Can anybody tell me why this happens, or at least what I can do to make ospf a bit more forgiving about delayed packages (If that is the problem...)? Thanks in advance, Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20071023/3ff018ab/attachment.html From jonirucoeith at gmail.com Tue Oct 23 11:16:49 2007 From: jonirucoeith at gmail.com (Jon) Date: Tue, 23 Oct 2007 20:16:49 +0200 Subject: [Xorp-hackers] OSPF on high latency links Message-ID: <471f67780710231116x3995ea1iec35b0ca7add9039@mail.gmail.com> Hi all, I have a problem with ospf loosing connection over high latency links. The link in question will induce a delay from minimum 1 sec to a maximum of more than 20 sec. (Yes, such links do exist:-/ ) I have tried to set the hello and router-dead intervals to 60 and 240 respectivly, but I still loose the connection. I have also tried to manipulate transmit-delay and retransmit in order to handle the latency (20 and 90secs) but no luck so far. Can anybody tell me why this happens, or at least what I can do to make ospf a bit more forgiving about delayed packages (If that is the problem...)? Thanks in advance, Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20071023/3ff018ab/attachment-0001.html From greearb at candelatech.com Tue Oct 23 22:54:04 2007 From: greearb at candelatech.com (Ben Greear) Date: Tue, 23 Oct 2007 22:54:04 -0700 Subject: [Xorp-hackers] Route with bad next-hop added with OSPF with redundant-link configuration. Message-ID: <471EDDFC.7010901@candelatech.com> I think this problem may be triggered by the high latency, as another team tried to reproduce this on two separate machines configured similarly and connected with fast ethernet, but it worked for them. Full logs with lots of debug enabled are available if you want them. This problem is 100% reproducible on my system, so I can also enable more debugging and generate new logs if that helps. I have two (virtual) routers, each with 3 interfaces. Two pairs connect to each other, the other pair connects to an external network (not running OSPF). The interfaces are named as A.B.C Router 1 Router 2 1.3.1 IP: 99.1.1.1/24 { high latency (1.5s RTT) network } 2.3.2 IP: 99.1.1.2/24 1.2.1 IP: 10.1.2.1/24 { 15ms RTT } 1.2.2 IP: 10.1.2.2/24 eth1 IP: 10.1.1.1/24 -- not connected -- eth2 IP: 10.2.2.2/24 The routing tables for router 2 use the 1.2.2 interface's IP as next hop, instead of 1.2.1 on the peer: Router-1 table looks OK: [root at lf1016-55 lanforge]# ip route show table 10001 99.1.1.0/24 dev 1.3.1 scope link 10.2.2.0/24 via 10.1.2.2 dev 1.2.1 proto xorp metric 2 notify 10.1.1.0/24 dev eth1 scope link 10.1.2.0/24 dev 1.2.1 scope link unreachable default proto xorp metric 1 notify [root at lf1016-55 lanforge]# Router-2 uses wrong next-hop for the xorp route: [root at lf1016-55 lanforge]# ip route show table 10002 99.1.1.0/24 dev 2.3.2 scope link 10.2.2.0/24 dev eth2 scope link 10.1.1.0/24 via 10.1.2.2 dev 1.2.2 proto xorp metric 2 notify 10.1.2.0/24 dev 1.2.2 scope link unreachable default proto xorp metric 1 notify [root at lf1016-55 lanforge]# Config files at end of email. Logs leading up to where I think the problem lies: [ 6317 +5582 area_router.cc routing_router_lsaV2 ] Vertex OSPFv2 Router 127.1.0.1(0x7f010001) 0.0.0.0(0) Router-LSA: LS age 1 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link State ID 127.1.0.1 Advertising Router 127.1.0.1 LS sequence number 0x80000002 LS checksum 0x7cb1 length 60 bit Nt false bit V false bit E false bit B false Type 2 Transit network IP address of Designated router 99.1.1.2 Routers interface address 99.1.1.1 Metric 10 Type 3 Stub network Subnet number 10.1.1.0 Mask 255.255.255.0 Metric 1 Type 2 Transit network IP address of Designated router 10.1.2.2 Routers interface address 10.1.2.1 Metric 1 [ 6317 +5562 area_router.cc update_edge ] src OSPFv2 Router 127.1.0.1(0x7f010001) 0.0.0.0(0) metric 10 dst OSPFv2 Network 99.1.1.2(0x63010102) 0.0.0.0(0) [ 6317 +5562 area_router.cc update_edge ] src OSPFv2 Network 99.1.1.2(0x63010102) 0.0.0.0(0) metric 0 dst OSPFv2 Router 127.1.0.1(0x7f010001) 0.0.0.0(0) [ 6317 +5562 area_router.cc update_edge ] src OSPFv2 Router 127.1.0.1(0x7f010001) 0.0.0.0(0) metric 1 dst OSPFv2 Network 10.1.2.2(0xa010202) 0.0.0.0(0) [ 6317 +5562 area_router.cc update_edge ] src OSPFv2 Network 10.1.2.2(0xa010202) 0.0.0.0(0) metric 0 dst OSPFv2 Router 127.1.0.1(0x7f010001) 0.0.0.0(0) [ 6317 +51 routing_table.cc begin ] area 0.0.0.0 [ 6317 +675 routing_table.cc clear_area ] Clearing area 0.0.0.0 [ 6317 +72 routing_table.cc begin ] ire Area: 0.0.0.0 RouteEntry: Network Address 10.1.1.0 Area 0.0.0.0 intra area cost 11 nexthop 99.1.1.1 advertising router 127.1.0.1 Network-LSA: LS age 0 Options 0 DC: 0 EA: 0 N/P: 0 MC: 0 E: 0 LS type 0x2 Link State ID 10.1.1.0 Advertising Router 127.1.0.1 LS sequence number 0x80000001 LS checksum 0 length 0 Network Mask 0xffffff00 winner [ 6317 +81 routing_table.cc begin ] empty ire only this area was present [ 6317 +72 routing_table.cc begin ] ire Area: 0.0.0.0 RouteEntry: Network direct Address 10.1.2.2 Area 0.0.0.0 intra area cost 1 nexthop 10.1.2.2 advertising router 127.1.0.2 Network-LSA: LS age 1 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State ID 10.1.2.2 Advertising Router 127.1.0.2 LS sequence number 0x80000001 LS checksum 0x665e length 32 Network Mask 0xffffff00 Attached Router 127.1.0.2 Attached Router 127.1.0.1 winner [ 6317 +81 routing_table.cc begin ] empty ire only this area was present [ 6317 +72 routing_table.cc begin ] ire Area: 0.0.0.0 RouteEntry: Network direct Address 10.2.2.0 Area 0.0.0.0 intra area cost 1 nexthop 0.0.0.0 advertising router 127.1.0.2 Network-LSA: LS age 0 Options 0 DC: 0 EA: 0 N/P: 0 MC: 0 E: 0 LS type 0x2 Link State ID 10.2.2.0 Advertising Router 127.1.0.2 LS sequence number 0x80000001 LS checksum 0 length 0 Network Mask 0xffffff00 winner [ 6317 +81 routing_table.cc begin ] empty ire only this area was present [ 6317 +72 routing_table.cc begin ] ire Area: 0.0.0.0 RouteEntry: Network direct Address 99.1.1.2 Area 0.0.0.0 intra area cost 10 nexthop 99.1.1.2 advertising router 127.1.0.2 Network-LSA: LS age 0 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State ID 99.1.1.2 Advertising Router 127.1.0.2 LS sequence number 0x80000001 LS checksum 0xe784 length 32 Network Mask 0xffffff00 Attached Router 127.1.0.2 Attached Router 127.1.0.1 winner [ 6317 +81 routing_table.cc begin ] empty ire only this area was present [ 6317 +907 ../libproto/spt.hh set_adjacent_weights ] Node: OSPFv2 Network 10.1.2.2(0xa010202) 10.1.2.2(0x202010a) [ 6317 +907 ../libproto/spt.hh set_adjacent_weights ] Node: OSPFv2 Network 10.2.2.255(0xa0202ff) 0.0.0.0(0) [ 6317 +907 ../libproto/spt.hh set_adjacent_weights ] Node: OSPFv2 Network 99.1.1.2(0x63010102) 99.1.1.2(0x2010163) [ 6317 +907 ../libproto/spt.hh set_adjacent_weights ] Node: OSPFv2 Router 127.1.0.1(0x7f010001) 99.1.1.1(0x1010163) [ 6317 +751 ../libproto/spt.hh dijkstra ] Previous: OSPFv2(Origin) Router 127.1.0.2(0x7f010002) 0.0.0.0(0) [ 6317 +755 ../libproto/spt.hh dijkstra ] Permanent: OSPFv2 Network 10.2.2.255(0xa0202ff) 0.0.0.0(0) distance 1 next hop OSPFv2 Network 10.2.2.255(0xa0202ff) 0.0.0.0(0) [ 6317 +751 ../libproto/spt.hh dijkstra ] Previous: OSPFv2(Origin) Router 127.1.0.2(0x7f010002) 0.0.0.0(0) [ 6317 +755 ../libproto/spt.hh dijkstra ] Permanent: OSPFv2 Network 10.1.2.2(0xa010202) 10.1.2.2(0x202010a) distance 1 next hop OSPFv2 Network 10.1.2.2(0xa010202) 10.1.2.2(0x202010a) [ 6317 +907 ../libproto/spt.hh set_adjacent_weights ] Node: OSPFv2 Router 127.1.0.1(0x7f010001) 99.1.1.1(0x1010163) [ 6317 +907 ../libproto/spt.hh set_adjacent_weights ] Node: OSPFv2(Origin) Router 127.1.0.2(0x7f010002) 0.0.0.0(0) [ 6317 +751 ../libproto/spt.hh dijkstra ] Previous: OSPFv2 Network 10.1.2.2(0xa010202) 10.1.2.2(0x202010a) [ 6317 +755 ../libproto/spt.hh dijkstra ] Permanent: OSPFv2 Router 127.1.0.1(0x7f010001) 99.1.1.1(0x1010163) distance 1 next hop OSPFv2 Network 10.1.2.2(0xa010202) 10.1.2.2(0x202010a) [ 6317 +907 ../libproto/spt.hh set_adjacent_weights ] Node: OSPFv2 Network 10.1.1.255(0xa0101ff) 0.0.0.0(0) [ 6317 +907 ../libproto/spt.hh set_adjacent_weights ] Node: OSPFv2 Network 10.1.2.2(0xa010202) 10.1.2.2(0x202010a) [ 6317 +907 ../libproto/spt.hh set_adjacent_weights ] Node: OSPFv2 Network 99.1.1.2(0x63010102) 99.1.1.2(0x2010163) [ 6317 +751 ../libproto/spt.hh dijkstra ] Previous: OSPFv2 Router 127.1.0.1(0x7f010001) 99.1.1.1(0x1010163) [ 6317 +755 ../libproto/spt.hh dijkstra ] Permanent: OSPFv2 Network 10.1.1.255(0xa0101ff) 0.0.0.0(0) distance 2 next hop OSPFv2 Network 10.1.2.2(0xa010202) 10.1.2.2(0x202010a) [ 6317 +751 ../libproto/spt.hh dijkstra ] Previous: OSPFv2(Origin) Router 127.1.0.2(0x7f010002) 0.0.0.0(0) [ 6317 +755 ../libproto/spt.hh dijkstra ] Permanent: OSPFv2 Network 99.1.1.2(0x63010102) 99.1.1.2(0x2010163) distance 10 next hop OSPFv2 Network 99.1.1.2(0x63010102) 99.1.1.2(0x2010163) [ 6317 +907 ../libproto/spt.hh set_adjacent_weights ] Node: OSPFv2 Router 127.1.0.1(0x7f010001) 99.1.1.1(0x1010163) [ 6317 +907 ../libproto/spt.hh set_adjacent_weights ] Node: OSPFv2(Origin) Router 127.1.0.2(0x7f010002) 0.0.0.0(0) [ 6317 +3919 area_router.cc routing_total_recomputeV2 ] Add route: Node: OSPFv2 Network 10.1.1.255(0xa0101ff) 0.0.0.0(0) -> Nexthop OSPFv2 Network 10.1.2.2(0xa010202) 10.1.2.2(0x202010a) [ 6317 +231 routing_table.cc lookup_entry ] 10.1.1.0/24 [ 6317 +96 routing_table.cc add_entry ] area 0.0.0.0 10.1.1.0/24 RouteEntry: Network Address 10.1.1.0 Area 0.0.0.0 intra area cost 2 nexthop 10.1.2.2 advertising router 127.1.0.1 Network-LSA: LS age 0 Options 0 DC: 0 EA: 0 N/P: 0 MC: 0 E: 0 LS type 0x2 Link State ID 10.1.1.0 Advertising Router 127.1.0.1 LS sequence number 0x80000001 LS checksum 0 length 0 Network Mask 0xffffff00 msg: void AreaRouter::routing_total_recomputeV2() [with A = IPv4] [ 6317 +3919 area_router.cc routing_total_recomputeV2 ] Add route: Node: OSPFv2 Network 10.1.2.2(0xa010202) 10.1.2.2(0x202010a) -> Nexthop OSPFv2 Network 10.1.2.2(0xa010202) 10.1.2.2(0x202010a) [ 6317 +231 routing_table.cc lookup_entry ] 10.1.2.0/24 [ 6317 +96 routing_table.cc add_entry ] area 0.0.0.0 10.1.2.0/24 RouteEntry: Network direct Address 10.1.2.2 Area 0.0.0.0 intra area cost 1 nexthop 10.1.2.2 advertising router 127.1.0.2 Network-LSA: LS age 1 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State ID 10.1.2.2 Advertising Router 127.1.0.2 LS sequence number 0x80000001 LS checksum 0x665e length 32 Network Mask 0xffffff00 Attached Router 127.1.0.2 Attached Router 127.1.0.1 msg: void AreaRouter::routing_total_recomputeV2() [with A = IPv4] [ 6317 +3919 area_router.cc routing_total_recomputeV2 ] Add route: Node: OSPFv2 Network 10.2.2.255(0xa0202ff) 0.0.0.0(0) -> Nexthop OSPFv2 Network 10.2.2.255(0xa0202ff) 0.0.0.0(0) [ 6317 +231 routing_table.cc lookup_entry ] 10.2.2.0/24 [ 6317 +96 routing_table.cc add_entry ] area 0.0.0.0 10.2.2.0/24 RouteEntry: Network direct Address 10.2.2.0 Area 0.0.0.0 intra area cost 1 nexthop 0.0.0.0 advertising router 127.1.0.2 Network-LSA: LS age 0 Options 0 DC: 0 EA: 0 N/P: 0 MC: 0 E: 0 LS type 0x2 Link State ID 10.2.2.0 Advertising Router 127.1.0.2 LS sequence number 0x80000001 LS checksum 0 length 0 Network Mask 0xffffff00 msg: void AreaRouter::routing_total_recomputeV2() [with A = IPv4] [ 6317 +3919 area_router.cc routing_total_recomputeV2 ] Add route: Node: OSPFv2 Network 99.1.1.2(0x63010102) 99.1.1.2(0x2010163) -> Nexthop OSPFv2 Network 99.1.1.2(0x63010102) 99.1.1.2(0x2010163) [ 6317 +231 routing_table.cc lookup_entry ] 99.1.1.0/24 [ 6317 +96 routing_table.cc add_entry ] area 0.0.0.0 99.1.1.0/24 RouteEntry: Network direct Address 99.1.1.2 Area 0.0.0.0 intra area cost 10 nexthop 99.1.1.2 advertising router 127.1.0.2 Network-LSA: LS age 0 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State ID 99.1.1.2 Advertising Router 127.1.0.2 LS sequence number 0x80000001 LS checksum 0xe784 length 32 Network Mask 0xffffff00 Attached Router 127.1.0.2 Attached Router 127.1.0.1 msg: void AreaRouter::routing_total_recomputeV2() [with A = IPv4] [ 6317 +3919 area_router.cc routing_total_recomputeV2 ] Add route: Node: OSPFv2 Router 127.1.0.1(0x7f010001) 99.1.1.1(0x1010163) -> Nexthop OSPFv2 Network 10.1.2.2(0xa010202) 10.1.2.2(0x202010a) [ 2007/10/23 21:39:47 TRACE xorp_ospfv2 OSPF ] Checking for virtual links V2, count(rid): 0 Router-LSA: LS age 1 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link State ID 127.1.0.1 Advertising Router 127.1.0.1 LS sequence number 0x80000002 LS checksum 0x7cb1 length 60 bit Nt false bit V false bit E false bit B false Type 2 Transit network IP address of Designated router 99.1.1.2 Routers interface address 99.1.1.1 Metric 10 Type 3 Stub network Subnet number 10.1.1.0 Mask 255.255.255.0 Metric 1 Type 2 Transit network IP address of Designated router 10.1.2.2 Routers interface address 10.1.2.1 Metric 1 [ 6317 +276 routing_table.cc end ] [ 6317 +442 routing_table.cc replace_route ] REPLACE ROUTE area 0.0.0.0 10.1.1.0/24 [ 6317 +417 routing_table.cc delete_route ] DELETE ROUTE area 0.0.0.0 10.1.1.0/24 filtered false [ 2007/10/23 21:39:47 TRACE xorp_ospfv2 OSPF ] Delete route Net 10.1.1.0/24 [ 6317 +389 routing_table.cc add_route ] ADD ROUTE area 0.0.0.0 net 10.1.1.0/24 nexthop 10.1.2.2 metric 2 [ 6317 +522 routing_table.cc do_filtering ] [OSPF] Running filter: Import on route: 10.1.1.0/24 [ 2007/10/23 21:39:47 TRACE xorp_ospfv2 OSPF ] [OSPF] Running filter: Import on route: 10.1.1.0/24 [ 6317 +540 routing_table.cc do_filtering ] [OSPF] Running filter: Export-SourceMatch on route: 10.1.1.0/24 [ 2007/10/23 21:39:47 TRACE xorp_ospfv2 OSPF ] [OSPF] Running filter: Export-SourceMatch on route: 10.1.1.0/24 [ 2007/10/23 21:39:47 TRACE xorp_ospfv2 OSPF ] Add route Net 10.1.1.0/24 Nexthop 10.1.2.2 metric 2 equal false discard false policy [ 2007/10/23 21:39:47 TRACE xorp_ospfv2 OSPF ] Interface 2.3.2 Vif 2.3.2 dst 224.0.0.5 src 99.1.1.1 data 0x8394730 len 88 router-1 config: /* For Virtual-Router: Router-1 */ interfaces { interface my_discard { unreachable: true vif my_discard { } } interface 1.3.1 { vif 1.3.1 { address 99.1.1.1 { prefix-length: 24 } } } interface eth1 { vif eth1 { address 10.1.1.1 { prefix-length: 24 } } } interface 1.2.1 { vif 1.2.1 { address 10.1.2.1 { prefix-length: 24 } } } } fea { unicast-forwarding4 { disable: false table-id: 10001 } } protocols { static { interface-route 0.0.0.0/0 { next-hop-interface: "my_discard" next-hop-vif: "my_discard" } } ospf4 { router-id: 127.1.0.1 area 0.0.0.0 { interface 1.3.1 { vif 1.3.1 { address 99.1.1.1 { interface-cost: 10 } } } interface eth1 { vif eth1 { address 10.1.1.1 { interface-cost: 1 } } } interface 1.2.1 { vif 1.2.1 { address 10.1.2.1 { interface-cost: 1 } } } } traceoptions { flag all { disable: false } } } } /* End of Config File */ router-2 config: /* For Virtual-Router: Router-2 */ interfaces { interface my_discard { unreachable: true vif my_discard { } } interface 2.3.2 { vif 2.3.2 { address 99.1.1.2 { prefix-length: 24 } } } interface eth2 { vif eth2 { address 10.2.2.2 { prefix-length: 24 } } } interface 1.2.2 { vif 1.2.2 { address 10.1.2.2 { prefix-length: 24 } } } } fea { unicast-forwarding4 { disable: false table-id: 10002 } } protocols { static { interface-route 0.0.0.0/0 { next-hop-interface: "my_discard" next-hop-vif: "my_discard" } } ospf4 { router-id: 127.1.0.2 area 0.0.0.0 { interface 2.3.2 { vif 2.3.2 { address 99.1.1.2 { interface-cost: 10 } } } interface eth2 { vif eth2 { address 10.2.2.2 { interface-cost: 1 } } } interface 1.2.2 { vif 1.2.2 { address 10.1.2.2 { interface-cost: 1 } } } } traceoptions { flag all { disable: false } } } } /* End of Config File */ -- Ben Greear Candela Technologies Inc http://www.candelatech.com From atanu at ICSI.Berkeley.EDU Tue Oct 23 23:57:08 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Tue, 23 Oct 2007 23:57:08 -0700 Subject: [Xorp-hackers] OSPF stuck in Exchange state. In-Reply-To: Message from Ben Greear of "Mon, 22 Oct 2007 16:00:22 PDT." <471D2B86.2050404@candelatech.com> Message-ID: <91140.1193209028@tigger.icir.org> Hi, The comment is mis-leading and has been removed. Atanu. >>>>> "Ben" == Ben Greear writes: Ben> Looks like the problem might be that we are dropping a packet, Ben> and the ospf code does not retransmit? I see this comment in peer.cc: Ben> /** Ben> * XXX Ben> * The outgoing packets should be queued on the transmit queue, for Ben> * the time being just send them straight out. Ben> */ Ben> template Ben> bool Ben> PeerOut::transmit(typename Transmit::TransmitRef tr) Ben> { Ben> In the logs, I never see DataDescriptionReceived in the Exchange State: Ben> [root at lf1016-55 lanforge]# grep DataDescription x12.txt|grep "99.1.1.2" Ben> [ 2007/10/22 14:30:47 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.2) State(ExStart) Ben> [ 2007/10/22 14:30:49 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(12.16.12/12.16.12) Neighbour(99.1.1.2) State(ExStart) Ben> But, I do see an LoadingDone message, though it will be ignored since we are in the wrong state: Ben> [ 2007/10/22 14:30:51 TRACE xorp_ospfv2 OSPF ] Event(LoadingDone) Interface(12.16.12/12.16.12) Neighbour(99.1.1.2) State(Exchange) Ben> Off to try to figure out how we're supposed to do retransmits. Ben> Ben Ben> -- Ben> Ben Greear Ben> Candela Technologies Inc http://www.candelatech.com From atanu at ICSI.Berkeley.EDU Wed Oct 24 00:24:33 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Wed, 24 Oct 2007 00:24:33 -0700 Subject: [Xorp-hackers] OSPF on high latency links In-Reply-To: Message from Jon of "Tue, 23 Oct 2007 20:16:49 +0200." <471f67780710231116x3995ea1iec35b0ca7add9039@mail.gmail.com> Message-ID: <97910.1193210673@tigger.icir.org> Hi, Just out of curiosity what kind of links do you have that can have a latency of 20 seconds? For two OSPF routers to maintain bidirectional communications each must receive a hello packet from the other at least every router-dead-interval (default 40 seconds), a hello packet is sent every hello-interval (default 10 seconds). Are you experiencing packet loss as well as high latencies? If you are you could try increasing the frequency of the hello packets by decreasing the hello-interval value and also increasing the router-dead-interval. Atanu. >>>>> "Jon" == Jon writes: Jon> Hi all, Jon> I have a problem with ospf loosing connection over high latency links. Jon> The link in question will induce a delay from minimum 1 sec to a Jon> maximum of more than 20 sec. (Yes, such links do exist:-/ ) Jon> I have tried to set the hello and router-dead intervals to 60 and 240 Jon> respectivly, but I still loose the connection. Jon> I have also tried to manipulate transmit-delay and retransmit in order Jon> to handle the latency (20 and 90secs) but no luck so far. Jon> Can anybody tell me why this happens, or at least what I can do to Jon> make ospf a bit more forgiving about delayed packages (If that is the Jon> problem...)? Jon> Thanks in advance, Jon> Jon Jon> _______________________________________________ Jon> Xorp-hackers mailing list Jon> Xorp-hackers at icir.org Jon> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From atanu at ICSI.Berkeley.EDU Wed Oct 24 00:24:33 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Wed, 24 Oct 2007 00:24:33 -0700 Subject: [Xorp-hackers] OSPF on high latency links In-Reply-To: Message from Jon of "Tue, 23 Oct 2007 20:16:49 +0200." <471f67780710231116x3995ea1iec35b0ca7add9039@mail.gmail.com> Message-ID: <97910.1193210673@tigger.icir.org> Hi, Just out of curiosity what kind of links do you have that can have a latency of 20 seconds? For two OSPF routers to maintain bidirectional communications each must receive a hello packet from the other at least every router-dead-interval (default 40 seconds), a hello packet is sent every hello-interval (default 10 seconds). Are you experiencing packet loss as well as high latencies? If you are you could try increasing the frequency of the hello packets by decreasing the hello-interval value and also increasing the router-dead-interval. Atanu. >>>>> "Jon" == Jon writes: Jon> Hi all, Jon> I have a problem with ospf loosing connection over high latency links. Jon> The link in question will induce a delay from minimum 1 sec to a Jon> maximum of more than 20 sec. (Yes, such links do exist:-/ ) Jon> I have tried to set the hello and router-dead intervals to 60 and 240 Jon> respectivly, but I still loose the connection. Jon> I have also tried to manipulate transmit-delay and retransmit in order Jon> to handle the latency (20 and 90secs) but no luck so far. Jon> Can anybody tell me why this happens, or at least what I can do to Jon> make ospf a bit more forgiving about delayed packages (If that is the Jon> problem...)? Jon> Thanks in advance, Jon> Jon Jon> _______________________________________________ Jon> Xorp-hackers mailing list Jon> Xorp-hackers at icir.org Jon> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From atanu at ICSI.Berkeley.EDU Wed Oct 24 00:42:54 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Wed, 24 Oct 2007 00:42:54 -0700 Subject: [Xorp-hackers] Route with bad next-hop added with OSPF with redundant-link configuration. In-Reply-To: Message from Ben Greear of "Tue, 23 Oct 2007 22:54:04 PDT." <471EDDFC.7010901@candelatech.com> Message-ID: <2499.1193211774@tigger.icir.org> Hi, If you think that routes are being incorrectly computed could you send me the LSA database as well as the routes that you expect to see. The LSA database can be extracted with the print_lsas command. $ print_lsas -S saved.lsas Atanu. >>>>> "Ben" == Ben Greear writes: Ben> I think this problem may be triggered by the high latency, as another Ben> team tried to reproduce Ben> this on two separate machines configured similarly and connected with Ben> fast ethernet, but it Ben> worked for them. Full logs with lots of debug enabled are available if Ben> you want them. This Ben> problem is 100% reproducible on my system, so I can also enable more Ben> debugging and Ben> generate new logs if that helps. Ben> I have two (virtual) routers, each with 3 interfaces. Two pairs Ben> connect to each other, the other pair connects Ben> to an external network (not running OSPF). The interfaces are named as Ben> A.B.C Ben> Router 1 Ben> Router 2 Ben> 1.3.1 IP: 99.1.1.1/24 { high latency (1.5s RTT) network } 2.3.2 IP: Ben> 99.1.1.2/24 Ben> 1.2.1 IP: 10.1.2.1/24 { 15ms RTT } Ben> 1.2.2 IP: 10.1.2.2/24 Ben> eth1 IP: 10.1.1.1/24 -- not connected Ben> -- eth2 IP: 10.2.2.2/24 Ben> The routing tables for router 2 use the 1.2.2 interface's IP as next Ben> hop, instead of 1.2.1 on the peer: Ben> Router-1 table looks OK: Ben> [root at lf1016-55 lanforge]# ip route show table 10001 Ben> 99.1.1.0/24 dev 1.3.1 scope link Ben> 10.2.2.0/24 via 10.1.2.2 dev 1.2.1 proto xorp metric 2 notify Ben> 10.1.1.0/24 dev eth1 scope link Ben> 10.1.2.0/24 dev 1.2.1 scope link Ben> unreachable default proto xorp metric 1 notify Ben> [root at lf1016-55 lanforge]# Ben> Router-2 uses wrong next-hop for the xorp route: Ben> [root at lf1016-55 lanforge]# ip route show table 10002 Ben> 99.1.1.0/24 dev 2.3.2 scope link Ben> 10.2.2.0/24 dev eth2 scope link Ben> 10.1.1.0/24 via 10.1.2.2 dev 1.2.2 proto xorp metric 2 notify Ben> 10.1.2.0/24 dev 1.2.2 scope link Ben> unreachable default proto xorp metric 1 notify Ben> [root at lf1016-55 lanforge]# Ben> Config files at end of email. Ben> Logs leading up to where I think the problem lies: Ben> [ 6317 +5582 area_router.cc routing_router_lsaV2 ] Vertex OSPFv2 Router Ben> 127.1.0.1(0x7f010001) 0.0.0.0(0) Ben> Router-LSA: Ben> LS age 1 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link Ben> State ID 127.1.0.1 Advertising Router 127.1.0.1 LS sequence number Ben> 0x80000002 LS checksum 0x7cb1 length 60 Ben> bit Nt false Ben> bit V false Ben> bit E false Ben> bit B false Ben> Type 2 Transit network IP address of Designated router 99.1.1.2 Ben> Routers interface address 99.1.1.1 Metric 10 Ben> Type 3 Stub network Subnet number 10.1.1.0 Mask 255.255.255.0 Ben> Metric 1 Ben> Type 2 Transit network IP address of Designated router 10.1.2.2 Ben> Routers interface address 10.1.2.1 Metric 1 Ben> [ 6317 +5562 area_router.cc update_edge ] src OSPFv2 Router Ben> 127.1.0.1(0x7f010001) 0.0.0.0(0) metric 10 dst OSPFv2 Network Ben> 99.1.1.2(0x63010102) 0.0.0.0(0) Ben> [ 6317 +5562 area_router.cc update_edge ] src OSPFv2 Network Ben> 99.1.1.2(0x63010102) 0.0.0.0(0) metric 0 dst OSPFv2 Router Ben> 127.1.0.1(0x7f010001) 0.0.0.0(0) Ben> [ 6317 +5562 area_router.cc update_edge ] src OSPFv2 Router Ben> 127.1.0.1(0x7f010001) 0.0.0.0(0) metric 1 dst OSPFv2 Network Ben> 10.1.2.2(0xa010202) 0.0.0.0(0) Ben> [ 6317 +5562 area_router.cc update_edge ] src OSPFv2 Network Ben> 10.1.2.2(0xa010202) 0.0.0.0(0) metric 0 dst OSPFv2 Router Ben> 127.1.0.1(0x7f010001) 0.0.0.0(0) Ben> [ 6317 +51 routing_table.cc begin ] area 0.0.0.0 Ben> [ 6317 +675 routing_table.cc clear_area ] Clearing area 0.0.0.0 Ben> [ 6317 +72 routing_table.cc begin ] ire Area: 0.0.0.0 RouteEntry: Ben> Network Address 10.1.1.0 Area 0.0.0.0 intra area cost 11 nexthop Ben> 99.1.1.1 advertising router 127.1.0.1 Network-LSA: Ben> LS age 0 Options 0 DC: 0 EA: 0 N/P: 0 MC: 0 E: 0 LS type 0x2 Link Ben> State ID 10.1.1.0 Advertising Router 127.1.0.1 LS sequence number Ben> 0x80000001 LS checksum 0 length 0 Ben> Network Mask 0xffffff00 winner Ben> [ 6317 +81 routing_table.cc begin ] empty ire only this area was present Ben> [ 6317 +72 routing_table.cc begin ] ire Area: 0.0.0.0 RouteEntry: Ben> Network direct Address 10.1.2.2 Area 0.0.0.0 intra area cost 1 nexthop Ben> 10.1.2.2 advertising router 127.1.0.2 Network-LSA: Ben> LS age 1 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link Ben> State ID 10.1.2.2 Advertising Router 127.1.0.2 LS sequence number Ben> 0x80000001 LS checksum 0x665e length 32 Ben> Network Mask 0xffffff00 Ben> Attached Router 127.1.0.2 Ben> Attached Router 127.1.0.1 winner Ben> [ 6317 +81 routing_table.cc begin ] empty ire only this area was present Ben> [ 6317 +72 routing_table.cc begin ] ire Area: 0.0.0.0 RouteEntry: Ben> Network direct Address 10.2.2.0 Area 0.0.0.0 intra area cost 1 nexthop Ben> 0.0.0.0 advertising router 127.1.0.2 Network-LSA: Ben> LS age 0 Options 0 DC: 0 EA: 0 N/P: 0 MC: 0 E: 0 LS type 0x2 Link Ben> State ID 10.2.2.0 Advertising Router 127.1.0.2 LS sequence number Ben> 0x80000001 LS checksum 0 length 0 Ben> Network Mask 0xffffff00 winner Ben> [ 6317 +81 routing_table.cc begin ] empty ire only this area was present Ben> [ 6317 +72 routing_table.cc begin ] ire Area: 0.0.0.0 RouteEntry: Ben> Network direct Address 99.1.1.2 Area 0.0.0.0 intra area cost 10 nexthop Ben> 99.1.1.2 advertising router 127.1.0.2 Network-LSA: Ben> LS age 0 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link Ben> State ID 99.1.1.2 Advertising Router 127.1.0.2 LS sequence number Ben> 0x80000001 LS checksum 0xe784 length 32 Ben> Network Mask 0xffffff00 Ben> Attached Router 127.1.0.2 Ben> Attached Router 127.1.0.1 winner Ben> [ 6317 +81 routing_table.cc begin ] empty ire only this area was present Ben> [ 6317 +907 ../libproto/spt.hh set_adjacent_weights ] Node: OSPFv2 Ben> Network 10.1.2.2(0xa010202) 10.1.2.2(0x202010a) Ben> [ 6317 +907 ../libproto/spt.hh set_adjacent_weights ] Node: OSPFv2 Ben> Network 10.2.2.255(0xa0202ff) 0.0.0.0(0) Ben> [ 6317 +907 ../libproto/spt.hh set_adjacent_weights ] Node: OSPFv2 Ben> Network 99.1.1.2(0x63010102) 99.1.1.2(0x2010163) Ben> [ 6317 +907 ../libproto/spt.hh set_adjacent_weights ] Node: OSPFv2 Ben> Router 127.1.0.1(0x7f010001) 99.1.1.1(0x1010163) Ben> [ 6317 +751 ../libproto/spt.hh dijkstra ] Previous: OSPFv2(Origin) Ben> Router 127.1.0.2(0x7f010002) 0.0.0.0(0) Ben> [ 6317 +755 ../libproto/spt.hh dijkstra ] Permanent: OSPFv2 Network Ben> 10.2.2.255(0xa0202ff) 0.0.0.0(0) distance 1 next hop OSPFv2 Network Ben> 10.2.2.255(0xa0202ff) 0.0.0.0(0) Ben> [ 6317 +751 ../libproto/spt.hh dijkstra ] Previous: OSPFv2(Origin) Ben> Router 127.1.0.2(0x7f010002) 0.0.0.0(0) Ben> [ 6317 +755 ../libproto/spt.hh dijkstra ] Permanent: OSPFv2 Network Ben> 10.1.2.2(0xa010202) 10.1.2.2(0x202010a) distance 1 next hop OSPFv2 Ben> Network 10.1.2.2(0xa010202) 10.1.2.2(0x202010a) Ben> [ 6317 +907 ../libproto/spt.hh set_adjacent_weights ] Node: OSPFv2 Ben> Router 127.1.0.1(0x7f010001) 99.1.1.1(0x1010163) Ben> [ 6317 +907 ../libproto/spt.hh set_adjacent_weights ] Node: Ben> OSPFv2(Origin) Router 127.1.0.2(0x7f010002) 0.0.0.0(0) Ben> [ 6317 +751 ../libproto/spt.hh dijkstra ] Previous: OSPFv2 Network Ben> 10.1.2.2(0xa010202) 10.1.2.2(0x202010a) Ben> [ 6317 +755 ../libproto/spt.hh dijkstra ] Permanent: OSPFv2 Router Ben> 127.1.0.1(0x7f010001) 99.1.1.1(0x1010163) distance 1 next hop OSPFv2 Ben> Network 10.1.2.2(0xa010202) 10.1.2.2(0x202010a) Ben> [ 6317 +907 ../libproto/spt.hh set_adjacent_weights ] Node: OSPFv2 Ben> Network 10.1.1.255(0xa0101ff) 0.0.0.0(0) Ben> [ 6317 +907 ../libproto/spt.hh set_adjacent_weights ] Node: OSPFv2 Ben> Network 10.1.2.2(0xa010202) 10.1.2.2(0x202010a) Ben> [ 6317 +907 ../libproto/spt.hh set_adjacent_weights ] Node: OSPFv2 Ben> Network 99.1.1.2(0x63010102) 99.1.1.2(0x2010163) Ben> [ 6317 +751 ../libproto/spt.hh dijkstra ] Previous: OSPFv2 Router Ben> 127.1.0.1(0x7f010001) 99.1.1.1(0x1010163) Ben> [ 6317 +755 ../libproto/spt.hh dijkstra ] Permanent: OSPFv2 Network Ben> 10.1.1.255(0xa0101ff) 0.0.0.0(0) distance 2 next hop OSPFv2 Network Ben> 10.1.2.2(0xa010202) 10.1.2.2(0x202010a) Ben> [ 6317 +751 ../libproto/spt.hh dijkstra ] Previous: OSPFv2(Origin) Ben> Router 127.1.0.2(0x7f010002) 0.0.0.0(0) Ben> [ 6317 +755 ../libproto/spt.hh dijkstra ] Permanent: OSPFv2 Network Ben> 99.1.1.2(0x63010102) 99.1.1.2(0x2010163) distance 10 next hop OSPFv2 Ben> Network 99.1.1.2(0x63010102) 99.1.1.2(0x2010163) Ben> [ 6317 +907 ../libproto/spt.hh set_adjacent_weights ] Node: OSPFv2 Ben> Router 127.1.0.1(0x7f010001) 99.1.1.1(0x1010163) Ben> [ 6317 +907 ../libproto/spt.hh set_adjacent_weights ] Node: Ben> OSPFv2(Origin) Router 127.1.0.2(0x7f010002) 0.0.0.0(0) Ben> [ 6317 +3919 area_router.cc routing_total_recomputeV2 ] Add route: Node: Ben> OSPFv2 Network 10.1.1.255(0xa0101ff) 0.0.0.0(0) -> Nexthop OSPFv2 Ben> Network 10.1.2.2(0xa010202) 10.1.2.2(0x202010a) Ben> [ 6317 +231 routing_table.cc lookup_entry ] 10.1.1.0/24 Ben> [ 6317 +96 routing_table.cc add_entry ] area 0.0.0.0 10.1.1.0/24 Ben> RouteEntry: Network Address 10.1.1.0 Area 0.0.0.0 intra area cost 2 Ben> nexthop 10.1.2.2 advertising router 127.1.0.1 Network-LSA: Ben> LS age 0 Options 0 DC: 0 EA: 0 N/P: 0 MC: 0 E: 0 LS type 0x2 Link Ben> State ID 10.1.1.0 Advertising Router 127.1.0.1 LS sequence number Ben> 0x80000001 LS checksum 0 length 0 Ben> Network Mask 0xffffff00 msg: void Ben> AreaRouter::routing_total_recomputeV2() [with A = IPv4] Ben> [ 6317 +3919 area_router.cc routing_total_recomputeV2 ] Add route: Node: Ben> OSPFv2 Network 10.1.2.2(0xa010202) 10.1.2.2(0x202010a) -> Nexthop OSPFv2 Ben> Network 10.1.2.2(0xa010202) 10.1.2.2(0x202010a) Ben> [ 6317 +231 routing_table.cc lookup_entry ] 10.1.2.0/24 Ben> [ 6317 +96 routing_table.cc add_entry ] area 0.0.0.0 10.1.2.0/24 Ben> RouteEntry: Network direct Address 10.1.2.2 Area 0.0.0.0 intra area cost Ben> 1 nexthop 10.1.2.2 advertising router 127.1.0.2 Network-LSA: Ben> LS age 1 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link Ben> State ID 10.1.2.2 Advertising Router 127.1.0.2 LS sequence number Ben> 0x80000001 LS checksum 0x665e length 32 Ben> Network Mask 0xffffff00 Ben> Attached Router 127.1.0.2 Ben> Attached Router 127.1.0.1 msg: void Ben> AreaRouter::routing_total_recomputeV2() [with A = IPv4] Ben> [ 6317 +3919 area_router.cc routing_total_recomputeV2 ] Add route: Node: Ben> OSPFv2 Network 10.2.2.255(0xa0202ff) 0.0.0.0(0) -> Nexthop OSPFv2 Ben> Network 10.2.2.255(0xa0202ff) 0.0.0.0(0) Ben> [ 6317 +231 routing_table.cc lookup_entry ] 10.2.2.0/24 Ben> [ 6317 +96 routing_table.cc add_entry ] area 0.0.0.0 10.2.2.0/24 Ben> RouteEntry: Network direct Address 10.2.2.0 Area 0.0.0.0 intra area cost Ben> 1 nexthop 0.0.0.0 advertising router 127.1.0.2 Network-LSA: Ben> LS age 0 Options 0 DC: 0 EA: 0 N/P: 0 MC: 0 E: 0 LS type 0x2 Link Ben> State ID 10.2.2.0 Advertising Router 127.1.0.2 LS sequence number Ben> 0x80000001 LS checksum 0 length 0 Ben> Network Mask 0xffffff00 msg: void Ben> AreaRouter::routing_total_recomputeV2() [with A = IPv4] Ben> [ 6317 +3919 area_router.cc routing_total_recomputeV2 ] Add route: Node: Ben> OSPFv2 Network 99.1.1.2(0x63010102) 99.1.1.2(0x2010163) -> Nexthop Ben> OSPFv2 Network 99.1.1.2(0x63010102) 99.1.1.2(0x2010163) Ben> [ 6317 +231 routing_table.cc lookup_entry ] 99.1.1.0/24 Ben> [ 6317 +96 routing_table.cc add_entry ] area 0.0.0.0 99.1.1.0/24 Ben> RouteEntry: Network direct Address 99.1.1.2 Area 0.0.0.0 intra area cost Ben> 10 nexthop 99.1.1.2 advertising router 127.1.0.2 Network-LSA: Ben> LS age 0 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link Ben> State ID 99.1.1.2 Advertising Router 127.1.0.2 LS sequence number Ben> 0x80000001 LS checksum 0xe784 length 32 Ben> Network Mask 0xffffff00 Ben> Attached Router 127.1.0.2 Ben> Attached Router 127.1.0.1 msg: void Ben> AreaRouter::routing_total_recomputeV2() [with A = IPv4] Ben> [ 6317 +3919 area_router.cc routing_total_recomputeV2 ] Add route: Node: Ben> OSPFv2 Router 127.1.0.1(0x7f010001) 99.1.1.1(0x1010163) -> Nexthop Ben> OSPFv2 Network 10.1.2.2(0xa010202) 10.1.2.2(0x202010a) Ben> [ 2007/10/23 21:39:47 TRACE xorp_ospfv2 OSPF ] Checking for virtual Ben> links V2, count(rid): 0 Router-LSA: Ben> LS age 1 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link Ben> State ID 127.1.0.1 Advertising Router 127.1.0.1 LS sequence number Ben> 0x80000002 LS checksum 0x7cb1 length 60 Ben> bit Nt false Ben> bit V false Ben> bit E false Ben> bit B false Ben> Type 2 Transit network IP address of Designated router 99.1.1.2 Ben> Routers interface address 99.1.1.1 Metric 10 Ben> Type 3 Stub network Subnet number 10.1.1.0 Mask 255.255.255.0 Ben> Metric 1 Ben> Type 2 Transit network IP address of Designated router 10.1.2.2 Ben> Routers interface address 10.1.2.1 Metric 1 Ben> [ 6317 +276 routing_table.cc end ] Ben> [ 6317 +442 routing_table.cc replace_route ] REPLACE ROUTE area 0.0.0.0 Ben> 10.1.1.0/24 Ben> [ 6317 +417 routing_table.cc delete_route ] DELETE ROUTE area 0.0.0.0 Ben> 10.1.1.0/24 filtered false Ben> [ 2007/10/23 21:39:47 TRACE xorp_ospfv2 OSPF ] Delete route Net 10.1.1.0/24 Ben> [ 6317 +389 routing_table.cc add_route ] ADD ROUTE area 0.0.0.0 net Ben> 10.1.1.0/24 nexthop 10.1.2.2 metric 2 Ben> [ 6317 +522 routing_table.cc do_filtering ] [OSPF] Running filter: Ben> Import on route: 10.1.1.0/24 Ben> [ 2007/10/23 21:39:47 TRACE xorp_ospfv2 OSPF ] [OSPF] Running filter: Ben> Import on route: 10.1.1.0/24 Ben> [ 6317 +540 routing_table.cc do_filtering ] [OSPF] Running filter: Ben> Export-SourceMatch on route: 10.1.1.0/24 Ben> [ 2007/10/23 21:39:47 TRACE xorp_ospfv2 OSPF ] [OSPF] Running filter: Ben> Export-SourceMatch on route: 10.1.1.0/24 Ben> [ 2007/10/23 21:39:47 TRACE xorp_ospfv2 OSPF ] Add route Net 10.1.1.0/24 Ben> Nexthop 10.1.2.2 metric 2 equal false discard false policy Ben> [ 2007/10/23 21:39:47 TRACE xorp_ospfv2 OSPF ] Interface 2.3.2 Vif 2.3.2 Ben> dst 224.0.0.5 src 99.1.1.1 data 0x8394730 len 88 Ben> router-1 config: Ben> /* For Virtual-Router: Router-1 */ Ben> interfaces { Ben> interface my_discard { Ben> unreachable: true Ben> vif my_discard { Ben> } Ben> } Ben> interface 1.3.1 { Ben> vif 1.3.1 { Ben> address 99.1.1.1 { Ben> prefix-length: 24 Ben> } Ben> } Ben> } Ben> interface eth1 { Ben> vif eth1 { Ben> address 10.1.1.1 { Ben> prefix-length: 24 Ben> } Ben> } Ben> } Ben> interface 1.2.1 { Ben> vif 1.2.1 { Ben> address 10.1.2.1 { Ben> prefix-length: 24 Ben> } Ben> } Ben> } Ben> } Ben> fea { Ben> unicast-forwarding4 { Ben> disable: false Ben> table-id: 10001 Ben> } Ben> } Ben> protocols { Ben> static { Ben> interface-route 0.0.0.0/0 { Ben> next-hop-interface: "my_discard" Ben> next-hop-vif: "my_discard" Ben> } Ben> } Ben> ospf4 { Ben> router-id: 127.1.0.1 Ben> area 0.0.0.0 { Ben> interface 1.3.1 { Ben> vif 1.3.1 { Ben> address 99.1.1.1 { Ben> interface-cost: 10 Ben> } Ben> } Ben> } Ben> interface eth1 { Ben> vif eth1 { Ben> address 10.1.1.1 { Ben> interface-cost: 1 Ben> } Ben> } Ben> } Ben> interface 1.2.1 { Ben> vif 1.2.1 { Ben> address 10.1.2.1 { Ben> interface-cost: 1 Ben> } Ben> } Ben> } Ben> } Ben> traceoptions { Ben> flag all { Ben> disable: false Ben> } Ben> } Ben> } Ben> } Ben> /* End of Config File */ Ben> router-2 config: Ben> /* For Virtual-Router: Router-2 */ Ben> interfaces { Ben> interface my_discard { Ben> unreachable: true Ben> vif my_discard { Ben> } Ben> } Ben> interface 2.3.2 { Ben> vif 2.3.2 { Ben> address 99.1.1.2 { Ben> prefix-length: 24 Ben> } Ben> } Ben> } Ben> interface eth2 { Ben> vif eth2 { Ben> address 10.2.2.2 { Ben> prefix-length: 24 Ben> } Ben> } Ben> } Ben> interface 1.2.2 { Ben> vif 1.2.2 { Ben> address 10.1.2.2 { Ben> prefix-length: 24 Ben> } Ben> } Ben> } Ben> } Ben> fea { Ben> unicast-forwarding4 { Ben> disable: false Ben> table-id: 10002 Ben> } Ben> } Ben> protocols { Ben> static { Ben> interface-route 0.0.0.0/0 { Ben> next-hop-interface: "my_discard" Ben> next-hop-vif: "my_discard" Ben> } Ben> } Ben> ospf4 { Ben> router-id: 127.1.0.2 Ben> area 0.0.0.0 { Ben> interface 2.3.2 { Ben> vif 2.3.2 { Ben> address 99.1.1.2 { Ben> interface-cost: 10 Ben> } Ben> } Ben> } Ben> interface eth2 { Ben> vif eth2 { Ben> address 10.2.2.2 { Ben> interface-cost: 1 Ben> } Ben> } Ben> } Ben> interface 1.2.2 { Ben> vif 1.2.2 { Ben> address 10.1.2.2 { Ben> interface-cost: 1 Ben> } Ben> } Ben> } Ben> } Ben> traceoptions { Ben> flag all { Ben> disable: false Ben> } Ben> } Ben> } Ben> } Ben> /* End of Config File */ Ben> -- Ben> Ben Greear Ben> Candela Technologies Inc http://www.candelatech.com Ben> _______________________________________________ Ben> Xorp-hackers mailing list Ben> Xorp-hackers at icir.org Ben> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From greearb at candelatech.com Wed Oct 24 09:39:04 2007 From: greearb at candelatech.com (Ben Greear) Date: Wed, 24 Oct 2007 09:39:04 -0700 Subject: [Xorp-hackers] xorp-ospf performance issues: busy-spins & packet floods. In-Reply-To: <92402.1193209321@tigger.icir.org> References: <92402.1193209321@tigger.icir.org> Message-ID: <471F7528.6060807@candelatech.com> Atanu Ghosh wrote: > Hi, > > What exactly is the problem? > > Atanu. > Look back at the timestamps...it's sending hundreds or thousands of packets per second. But, as I mentioned in the bugzilla entry, after the 'Exchange' state hang fix and my hacks to the eventloop, I have not reproduced this problem again. If I do reproduce it again, I'll let you know..but for now I think it might be fixed. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From atanu at ICSI.Berkeley.EDU Wed Oct 24 00:02:01 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Wed, 24 Oct 2007 00:02:01 -0700 Subject: [Xorp-hackers] xorp-ospf performance issues: busy-spins & packet floods. In-Reply-To: Message from Ben Greear of "Sun, 21 Oct 2007 16:17:24 PDT." <471BDE04.2020104@candelatech.com> Message-ID: <92402.1193209321@tigger.icir.org> Hi, What exactly is the problem? Atanu. >>>>> "Ben" == Ben Greear writes: Ben> I managed to reproduce this with logging enabled in ospf. Below is a Ben> snippet from the logs. At this point, Ben> the emulated networks are probably not working right (ie, passing few if Ben> any packets), but no reason to Ben> spin so madly! Ben> Thanks, Ben> Ben Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.2.6.255(0xa0206ff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.2.9.9(0xa020909) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.3.4.4(0xa030404) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.3.5.255(0xa0305ff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.4.5.255(0xa0405ff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.4.6.255(0xa0406ff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.6.7.7(0xa060707) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.6.7.255(0xa0607ff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.6.8.8(0xa060808) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.7.8.255(0xa0708ff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.9.10.255(0xa090aff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.9.11.11(0xa090b0b) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.9.11.255(0xa090bff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.9.13.255(0xa090dff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.9.14.255(0xa090eff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.9.15.15(0xa090f0f) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.9.15.255(0xa090fff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.10.11.255(0xa0a0bff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.10.13.255(0xa0a0dff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.10.14.255(0xa0a0eff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.10.15.255(0xa0a0fff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.11.13.255(0xa0b0dff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.11.14.255(0xa0b0eff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.11.15.255(0xa0b0fff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.13.14.255(0xa0d0eff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.13.15.255(0xa0d0fff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.14.15.255(0xa0e0fff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router Ben> 127.1.0.1(0x7f010001) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router Ben> 127.1.0.2(0x7f010002) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router Ben> 127.1.0.3(0x7f010003) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router Ben> 127.1.0.4(0x7f010004) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router Ben> 127.1.0.5(0x7f010005) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router Ben> 127.1.0.6(0x7f010006) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router Ben> 127.1.0.7(0x7f010007) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router Ben> 127.1.0.8(0x7f010008) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router Ben> 127.1.0.9(0x7f010009) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router Ben> 127.1.0.10(0x7f01000a) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router Ben> 127.1.0.11(0x7f01000b) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router Ben> 127.1.0.13(0x7f01000d) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router Ben> 127.1.0.14(0x7f01000e) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router Ben> 127.1.0.15(0x7f01000f) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.11) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateAcknowledgementReceived-pseudo-event) Ben> Interface(10.12.12/10.12.12) Neighbour(10.10.12.10) State(Loading ) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.11) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.11) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.11) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.11) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.11) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Ben> Interface(12.16.12/12.16.12) Neighbour(99.1.1.3) DR (99.1.1.3) BDR Ben> (0.0.0.0) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(1-WayReceived) Ben> Interface(12.16.12/12.16.12) Neighbour(99.1.1.3) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Ben> Interface(12.16.12/12.16.12) Neighbour(99.1.1.2) DR (99.1.1.2) BDR Ben> (0.0.0.0) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(1-WayReceived) Ben> Interface(12.16.12/12.16.12) Neighbour(99.1.1.2) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Ben> Interface(12.16.12/12.16.12) Neighbour(99.1.1.11) DR (99.1.1.11) BDR Ben> (0.0.0.0) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(1-WayReceived) Ben> Interface(12.16.12/12.16.12) Neighbour(99.1.1.11) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Ben> Neighbour(10.12.13.13) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Ben> Neighbour(10.12.13.13) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Ben> Neighbour(10.12.13.13) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Ben> Neighbour(10.12.13.13) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Ben> Neighbour(10.12.13.13) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateAcknowledgementReceived-pseudo-event) Ben> Interface(12.14.12/12.14.12) Neighbour(10.12.14.14) State(Loading ) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.14.12/12.14.12) Ben> Neighbour(10.12.14.14) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.14.12/12.14.12) Ben> Neighbour(10.12.14.14) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.14.12/12.14.12) Ben> Neighbour(10.12.14.14) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.14.12/12.14.12) Ben> Neighbour(10.12.14.14) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Ben> Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) DR (99.1.1.11) BDR Ben> (99.1.1.10) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Event(1-WayReceived) Ben> Interface(12.16.12/12.16.12) Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Ben> Neighbour(10.11.12.11) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Ben> Neighbour(10.11.12.11) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Ben> Neighbour(10.11.12.11) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateAcknowledgementReceived-pseudo-event) Ben> Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading ) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateAcknowledgementReceived-pseudo-event) Ben> Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading ) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Ben> Neighbour(10.11.12.11) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Ben> Neighbour(10.10.12.10) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Ben> Neighbour(10.10.12.10) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Ben> Neighbour(10.10.12.10) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateAcknowledgementReceived-pseudo-event) Ben> Interface(12.13.12/12.13.12) Neighbour(10.12.13.13) State(Loading ) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateAcknowledgementReceived-pseudo-event) Ben> Interface(12.13.12/12.13.12) Neighbour(10.12.13.13) State(Loading ) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Ben> Neighbour(10.12.13.13) State(Loading) Ben> [ 2007/10/21 16:07:59 WARNING xorp_fea FEA ] proto_socket_read() Ben> warning: Received: 1138000 packets for vifs not in use by this instance Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Ben> Neighbour(10.12.13.13) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Ben> Neighbour(10.12.13.13) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateAcknowledgementReceived-pseudo-event) Ben> Interface(12.14.12/12.14.12) Neighbour(10.12.14.14) State(Loading ) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.14.12/12.14.12) Ben> Neighbour(10.12.14.14) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.14.12/12.14.12) Ben> Neighbour(10.12.14.14) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.14.12/12.14.12) Ben> Neighbour(10.12.14.14) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.14.12/12.14.12) Ben> Neighbour(10.12.14.14) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateAcknowledgementReceived-pseudo-event) Ben> Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading ) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateAcknowledgementReceived-pseudo-event) Ben> Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading ) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Ben> Neighbour(10.11.12.11) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Ben> Neighbour(10.11.12.11) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Ben> Neighbour(10.11.12.11) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Ben> Neighbour(10.11.12.11) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Ben> Neighbour(10.10.12.10) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Ben> Neighbour(10.10.12.10) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateAcknowledgementReceived-pseudo-event) Ben> Interface(12.13.12/12.13.12) Neighbour(10.12.13.13) State(Loading ) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateAcknowledgementReceived-pseudo-event) Ben> Interface(12.13.12/12.13.12) Neighbour(10.12.13.13) State(Loading ) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Ben> Neighbour(10.12.13.13) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateAcknowledgementReceived-pseudo-event) Ben> Interface(12.13.12/12.13.12) Neighbour(10.12.13.13) State(Loading ) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Ben> Neighbour(10.12.13.13) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.14.12/12.14.12) Ben> Neighbour(10.12.14.14) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.14.12/12.14.12) Ben> Neighbour(10.12.14.14) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateAcknowledgementReceived-pseudo-event) Ben> Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading ) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateAcknowledgementReceived-pseudo-event) Ben> Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading ) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Ben> Neighbour(10.11.12.11) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateAcknowledgementReceived-pseudo-event) Ben> Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading ) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Ben> Neighbour(10.11.12.11) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Ben> Neighbour(10.11.12.11) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateAcknowledgementReceived-pseudo-event) Ben> Interface(10.12.12/10.12.12) Neighbour(10.10.12.10) State(Loading ) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Ben> Neighbour(10.10.12.10) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Ben> Neighbour(10.10.12.10) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Ben> Neighbour(10.10.12.10) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Ben> Neighbour(10.10.12.10) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Ben> Neighbour(10.12.13.13) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Ben> Neighbour(10.12.13.13) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Ben> Neighbour(10.12.13.13) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Ben> Neighbour(10.12.13.13) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Ben> Neighbour(10.12.13.13) State(Loading) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateAcknowledgementReceived-pseudo-event) Ben> Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading ) Ben> [ 2007/10/21 16:07:59 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Ben> Neighbour(10.11.12.11) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Ben> Neighbour(10.11.12.11) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Ben> Neighbour(10.11.12.11) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Ben> Neighbour(10.11.12.11) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Ben> Neighbour(10.11.12.11) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateAcknowledgementReceived-pseudo-event) Ben> Interface(10.12.12/10.12.12) Neighbour(10.10.12.10) State(Loading ) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Ben> Neighbour(10.10.12.10) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Ben> Neighbour(10.10.12.10) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Ben> Neighbour(10.10.12.10) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Ben> Neighbour(10.10.12.10) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Ben> Neighbour(10.10.12.10) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Ben> Neighbour(10.12.13.13) State(Loading) Ben> [ 2007/10/21 16:08:00 WARNING xorp_fea FEA ] proto_socket_read() Ben> warning: Received: 1139000 packets for vifs not in use by this instance Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Ben> Neighbour(10.12.13.13) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Ben> Neighbour(10.12.13.13) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.1.2.2(0xa010202) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.1.3.255(0xa0103ff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.1.4.4(0xa010404) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.1.5.5(0xa010505) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.1.9.9(0xa010909) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.1.11.255(0xa010bff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.1.15.255(0xa010fff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.2.3.3(0xa020303) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.2.3.255(0xa0203ff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.2.4.4(0xa020404) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.2.5.5(0xa020505) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.2.5.255(0xa0205ff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.2.6.255(0xa0206ff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.2.9.9(0xa020909) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.3.4.4(0xa030404) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.3.5.255(0xa0305ff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.4.5.255(0xa0405ff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.4.6.255(0xa0406ff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.6.7.7(0xa060707) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.6.7.255(0xa0607ff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.6.8.8(0xa060808) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.7.8.255(0xa0708ff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.9.10.255(0xa090aff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.9.11.11(0xa090b0b) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.9.11.255(0xa090bff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.9.13.255(0xa090dff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.9.14.255(0xa090eff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.9.15.15(0xa090f0f) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.9.15.255(0xa090fff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.10.11.255(0xa0a0bff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.10.13.255(0xa0a0dff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.10.14.255(0xa0a0eff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.10.15.255(0xa0a0fff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.11.13.255(0xa0b0dff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.11.14.255(0xa0b0eff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.11.15.255(0xa0b0fff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.13.14.255(0xa0d0eff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.13.15.255(0xa0d0fff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network Ben> 10.14.15.255(0xa0e0fff) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router Ben> 127.1.0.1(0x7f010001) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router Ben> 127.1.0.2(0x7f010002) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router Ben> 127.1.0.3(0x7f010003) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router Ben> 127.1.0.4(0x7f010004) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router Ben> 127.1.0.5(0x7f010005) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router Ben> 127.1.0.6(0x7f010006) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router Ben> 127.1.0.7(0x7f010007) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router Ben> 127.1.0.8(0x7f010008) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router Ben> 127.1.0.9(0x7f010009) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router Ben> 127.1.0.10(0x7f01000a) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router Ben> 127.1.0.11(0x7f01000b) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router Ben> 127.1.0.13(0x7f01000d) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router Ben> 127.1.0.14(0x7f01000e) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router Ben> 127.1.0.15(0x7f01000f) 0.0.0.0(0) not reachable Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Ben> Neighbour(10.12.13.13) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Ben> Neighbour(10.12.13.13) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.14.12/12.14.12) Ben> Neighbour(10.12.14.14) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.14.12/12.14.12) Ben> Neighbour(10.12.14.14) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.14.12/12.14.12) Ben> Neighbour(10.12.14.14) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateAcknowledgementReceived-pseudo-event) Ben> Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading ) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateAcknowledgementReceived-pseudo-event) Ben> Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading ) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Ben> Neighbour(10.11.12.11) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateAcknowledgementReceived-pseudo-event) Ben> Interface(11.12.12/11.12.12) Neighbour(10.11.12.11) State(Loading ) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Ben> Neighbour(10.11.12.11) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Ben> Neighbour(10.11.12.11) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Ben> Neighbour(10.10.12.10) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Ben> Neighbour(10.10.12.10) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateAcknowledgementReceived-pseudo-event) Ben> Interface(12.13.12/12.13.12) Neighbour(10.12.13.13) State(Loading ) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Ben> Neighbour(10.12.13.13) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Ben> Neighbour(10.12.13.13) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Ben> Neighbour(10.12.13.13) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.13.12/12.13.12) Ben> Neighbour(10.12.13.13) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.16.12/12.16.12) Ben> Neighbour(99.1.1.10) State(Init) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateAcknowledgementReceived-pseudo-event) Ben> Interface(12.14.12/12.14.12) Neighbour(10.12.14.14) State(Loading ) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.14.12/12.14.12) Ben> Neighbour(10.12.14.14) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.14.12/12.14.12) Ben> Neighbour(10.12.14.14) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.14.12/12.14.12) Ben> Neighbour(10.12.14.14) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(12.14.12/12.14.12) Ben> Neighbour(10.12.14.14) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Ben> Neighbour(10.11.12.11) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Ben> Neighbour(10.11.12.11) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Ben> Neighbour(10.11.12.11) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Ben> Neighbour(10.11.12.11) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Ben> Neighbour(10.11.12.11) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(11.12.12/11.12.12) Ben> Neighbour(10.11.12.11) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateAcknowledgementReceived-pseudo-event) Ben> Interface(10.12.12/10.12.12) Neighbour(10.10.12.10) State(Loading ) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Ben> Neighbour(10.10.12.10) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Ben> Neighbour(10.10.12.10) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Ben> Neighbour(10.10.12.10) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Ben> Neighbour(10.10.12.10) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Ben> Neighbour(10.10.12.10) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Ben> Neighbour(10.10.12.10) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Ben> Neighbour(10.10.12.10) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Ben> Neighbour(10.10.12.10) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Ben> Neighbour(10.10.12.10) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Ben> Neighbour(10.10.12.10) State(Loading) Ben> [ 2007/10/21 16:08:00 TRACE xorp_ospfv2 OSPF ] Ben> Event(LinkStateUpdateReceived-pseudo-event) Interface(10.12.12/10.12.12) Ben> Neighbour(10.10.12.10) State(Loading) Ben> -- Ben> Ben Greear Ben> Candela Technologies Inc http://www.candelatech.com Ben> _______________________________________________ Ben> Xorp-hackers mailing list Ben> Xorp-hackers at icir.org Ben> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From greearb at candelatech.com Wed Oct 24 10:01:15 2007 From: greearb at candelatech.com (Ben Greear) Date: Wed, 24 Oct 2007 10:01:15 -0700 Subject: [Xorp-hackers] Route with bad next-hop added with OSPF with redundant-link configuration. In-Reply-To: <2499.1193211774@tigger.icir.org> References: <2499.1193211774@tigger.icir.org> Message-ID: <471F7A5B.90801@candelatech.com> Atanu Ghosh wrote: > Hi, > > If you think that routes are being incorrectly computed could you send > me the LSA database as well as the routes that you expect to see. > > The LSA database can be extracted with the print_lsas command. > $ print_lsas -S saved.lsas > > Atanu. > lsas are attached (for router 2). I see these routes: [root at lf1016-55 lanforge]# ip route show table 10002 99.1.1.0/24 dev 2.3.2 scope link 10.2.2.0/24 dev eth2 scope link 10.1.1.0/24 via 10.1.2.2 dev 1.2.2 proto xorp metric 2 notify 10.1.2.0/24 dev 1.2.2 scope link unreachable default proto xorp metric 1 notify I expect to see: [root at lf1016-55 lanforge]# ip route show table 10002 99.1.1.0/24 dev 2.3.2 scope link 10.2.2.0/24 dev eth2 scope link 10.1.1.0/24 via 10.1.2.1 dev 1.2.2 proto xorp metric 2 notify ^^^^ 10.1.2.0/24 dev 1.2.2 scope link unreachable default proto xorp metric 1 notify Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -------------- next part -------------- A non-text attachment was scrubbed... Name: saved.lsas Type: application/octet-stream Size: 265 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20071024/9febc1cc/attachment.obj From greearb at candelatech.com Wed Oct 24 10:50:08 2007 From: greearb at candelatech.com (Ben Greear) Date: Wed, 24 Oct 2007 10:50:08 -0700 Subject: [Xorp-hackers] Route with bad next-hop added with OSPF with redundant-link configuration. In-Reply-To: <471F7A5B.90801@candelatech.com> References: <2499.1193211774@tigger.icir.org> <471F7A5B.90801@candelatech.com> Message-ID: <471F85D0.6040707@candelatech.com> Ben Greear wrote: > Atanu Ghosh wrote: >> Hi, >> >> If you think that routes are being incorrectly computed could you send >> me the LSA database as well as the routes that you expect to see. >> >> The LSA database can be extracted with the print_lsas command. >> $ print_lsas -S saved.lsas >> >> Atanu. >> > lsas are attached (for router 2). I see these routes: > > [root at lf1016-55 lanforge]# ip route show table 10002 > 99.1.1.0/24 dev 2.3.2 scope link > 10.2.2.0/24 dev eth2 scope link > 10.1.1.0/24 via 10.1.2.2 dev 1.2.2 proto xorp metric 2 notify > 10.1.2.0/24 dev 1.2.2 scope link > unreachable default proto xorp metric 1 notify > > I expect to see: > [root at lf1016-55 lanforge]# ip route show table 10002 > 99.1.1.0/24 dev 2.3.2 scope link > 10.2.2.0/24 dev eth2 scope link > 10.1.1.0/24 via 10.1.2.1 dev 1.2.2 proto xorp metric 2 notify > ^^^^ Sorry, that ^^^ was supposed to be below the 10.1.2.1 Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Wed Oct 24 17:03:51 2007 From: greearb at candelatech.com (Ben Greear) Date: Wed, 24 Oct 2007 17:03:51 -0700 Subject: [Xorp-hackers] Question on RIB Message-ID: <471FDD67.8070809@candelatech.com> I have a scenario of 4 routers. Starting config is: A <-> B B <-> C C <-> D Also: B <-> D (high cost link) OSPF chooses the B-C link instead of the high cost link, and all is well. Then, I disconnect (remove the interfaces & OSPF config for those interfaces with xorpsh) B & C OSPF correctly starts using the high-cost link. Then, I reconnect B & C with the low cost link. It seems OSPF is trying to do the right thing. Routes are deleted from the high-cost link, but they do not appear on the low cost link. The reason appears to be this error in RIB. I tried doing a 'commit' after adding the interface and before adding the config to OSPF, but that did not help. Any idea how RIB learns about the directly connected interfaces? Looks like I need to somehow make it learn faster... [ 2007/10/24 16:40:25 TRACE xorp_ospfv2 OSPF ] Add route Net 10.2.2.0/24 Nexthop 10.2.3.3 metric 2 equal false discard false policy [ 2007/10/24 16:40:25 ERROR xorp_rib:17650 RIB rib.cc:856 add_route ] Attempting to add IGP route to table "ospf" (prefix 10.2.2.0/24 next-hop 10.2.3.3): no directly connected interface toward the next-hop router [ 2007/10/24 16:40:25 WARNING xorp_rib XrlRibTarget ] Handling method for rib/0.1/add_route4 failed: XrlCmdError 102 Command failed Could not add IPv4 route net 10.2.2.0/24, nexthop: 10.2.3.3 to unicast RIB [ 2007/10/24 16:40:25 ERROR xorp_ospfv2:17680 OSPF xrl_io.cc:1167 route_command_done ] callback: add_route: ribname rib net 10.2.2.0/24 nexthop 10.2.3.3 102 Command failed Could not add IPv4 route net 10.2.2.0/24, nexthop: 10.2.3.3 to unicast RIB Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From arjun at ceeyes.com Wed Oct 24 21:11:51 2007 From: arjun at ceeyes.com (Arjun Prasad) Date: Thu, 25 Oct 2007 09:41:51 +0530 Subject: [Xorp-hackers] class digram Message-ID: <000c01c816bd$2c7bccc0$2283a8c0@ceeyes.com> hi all! Is there any detailed class digram for xorp??? Any pictorial representation of xorp architecture regarding how classes r intractiong with each other etc. Regards, Arjun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20071025/09486bab/attachment.html From pavlin at icir.org Thu Oct 25 16:04:52 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 25 Oct 2007 16:04:52 -0700 Subject: [Xorp-hackers] Question on RIB In-Reply-To: Message from Ben Greear of "Wed, 24 Oct 2007 17:03:51 PDT." <471FDD67.8070809@candelatech.com> Message-ID: <200710252304.l9PN4qU2003079@possum.icir.org> Ben Greear wrote: > I have a scenario of 4 routers. Starting config is: > > A <-> B > B <-> C > C <-> D > > Also: > B <-> D (high cost link) > > OSPF chooses the B-C link instead of the high cost link, and all is well. > > Then, I disconnect (remove the interfaces & OSPF config for those interfaces > with xorpsh) > > B & C > > OSPF correctly starts using the high-cost link. > > > Then, I reconnect B & C with the low cost link. > > It seems OSPF is trying to do the right thing. Routes are deleted from > the high-cost link, but they do not appear on the low cost link. The > reason appears to be this error in RIB. I tried doing a 'commit' after > adding the interface and before adding the config to OSPF, but that did > not help. > > Any idea how RIB learns about the directly connected interfaces? Looks like > I need to somehow make it learn faster... I presume you already double-checked that that 10.2.3.3 indeed is a router directly connected to one of the new added interfaces. The RIB itself obtains the interface information from the FEA (like the routing protocols themselves), so it appears the reason for the error is a race condition. After the interface is added, the FEA notifies both OSPF and RIB about the change. However, by the time the information reaches OSPF and it sends add_route to the RIB, the RIB still hasn't received update. Off the top of my head, I see two possible solutions (at least): (a) Change the OSPF so it delays the add_route XRL to the RIB after a new interface has been added. This is a hackish solution that is probably not that difficult to implement, but strictly speaking it doesn't eliminate the race condition. E.g., even if you delay, for say, 5 seconds there is no guarantee the interface update from the FEA has reached the RIB within those 5 seconds. (b) Have the OSPF obtain the interface information via the RIB. I.e., have the RIB act as a proxy for passing the information from the FEA to OSPF. This will guarantee that the RIB will always see the update before the protocol (OSPF). FYI, we do something similar for multicast: the MFEA acts as a proxy for the interface information propagation from the FEA to IGMP/MLD and PIM-SM, but the original motivation for that was different (the MFEA was adding multicast-specific information to the iftree). Though, in case of MFEA the implementation takes a short-cut utilizing the fact that both the FEA and MFEA are within the same process. The RIB implementation needs to be a bit different in that aspect. Regards, Pavlin > [ 2007/10/24 16:40:25 TRACE xorp_ospfv2 OSPF ] Add route Net 10.2.2.0/24 Nexthop 10.2.3.3 metric 2 equal false discard false policy > [ 2007/10/24 16:40:25 ERROR xorp_rib:17650 RIB rib.cc:856 add_route ] Attempting to add IGP route to table "ospf" (prefix 10.2.2.0/24 next-hop 10.2.3.3): no directly connected interface toward the next-hop router > [ 2007/10/24 16:40:25 WARNING xorp_rib XrlRibTarget ] Handling method for rib/0.1/add_route4 failed: XrlCmdError 102 Command failed Could not add IPv4 route net 10.2.2.0/24, nexthop: 10.2.3.3 to unicast RIB > [ 2007/10/24 16:40:25 ERROR xorp_ospfv2:17680 OSPF xrl_io.cc:1167 route_command_done ] callback: add_route: ribname rib net 10.2.2.0/24 nexthop 10.2.3.3 102 Command failed Could not add IPv4 route net 10.2.2.0/24, nexthop: 10.2.3.3 to unicast RIB > > Thanks, > Ben > > -- > 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 pavlin at icir.org Thu Oct 25 16:21:06 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 25 Oct 2007 16:21:06 -0700 Subject: [Xorp-hackers] class digram In-Reply-To: Message from "Arjun Prasad" of "Thu, 25 Oct 2007 09:41:51 +0530." <000c01c816bd$2c7bccc0$2283a8c0@ceeyes.com> Message-ID: <200710252321.l9PNL6j1003226@possum.icir.org> Arjun Prasad wrote: > hi all! > > Is there any detailed class digram for xorp??? > Any pictorial representation of xorp architecture regarding how classes r intractiong with each other etc. The following URL contains a list of design documents: http://www.xorp.org/design_docs.html Some of documents there (e.g., the first one: "XORP Design Overview") provide high-level design overview of the XORP architecture. Other documents provide protocol-specific details. E.g., "XORP BGP Routing Daemon" describes the BGP implementation. Some of the above documents mention some of the important classes by name, but this is high-level description. There is also the "XORP Source Code Documentation" that is automatically generated from the source code itself: http://www.xorp.org/releases/current/docs/kdoc/html/index.html It is based on the Kdoc comments in the *.hh header files. There are no documents at the level of detailed class interaction. I guess there are generic C++ tools that will analyze the code and generate such pictures for you, but I haven't used such tools. Hopefully other folks on the list can give you some recommendations for such tools. Regards, Pavlin From greearb at candelatech.com Thu Oct 25 18:07:32 2007 From: greearb at candelatech.com (Ben Greear) Date: Thu, 25 Oct 2007 18:07:32 -0700 Subject: [Xorp-hackers] Question on RIB In-Reply-To: <200710252304.l9PN4qU2003079@possum.icir.org> References: <200710252304.l9PN4qU2003079@possum.icir.org> Message-ID: <47213DD4.5080705@candelatech.com> Pavlin Radoslavov wrote: > Ben Greear wrote: > >> I have a scenario of 4 routers. Starting config is: >> >> A <-> B >> B <-> C >> C <-> D >> >> Also: >> B <-> D (high cost link) >> >> OSPF chooses the B-C link instead of the high cost link, and all is well. >> >> Then, I disconnect (remove the interfaces & OSPF config for those interfaces >> with xorpsh) >> >> B & C >> >> OSPF correctly starts using the high-cost link. >> >> >> Then, I reconnect B & C with the low cost link. >> >> It seems OSPF is trying to do the right thing. Routes are deleted from >> the high-cost link, but they do not appear on the low cost link. The >> reason appears to be this error in RIB. I tried doing a 'commit' after >> adding the interface and before adding the config to OSPF, but that did >> not help. >> >> Any idea how RIB learns about the directly connected interfaces? Looks like >> I need to somehow make it learn faster... > > I presume you already double-checked that that 10.2.3.3 indeed is a > router directly connected to one of the new added interfaces. Yes, can ping between them and traceroute shows expected info. Also, if I restart XORP, it comes up with expected routes. > The RIB itself obtains the interface information from the FEA (like > the routing protocols themselves), so it appears the reason for the > error is a race condition. > After the interface is added, the FEA notifies both OSPF and RIB > about the change. However, by the time the information reaches OSPF > and it sends add_route to the RIB, the RIB still hasn't received > update. > > Off the top of my head, I see two possible solutions (at least): > > (a) Change the OSPF so it delays the add_route XRL to the RIB after > a new interface has been added. This is a hackish solution > that is probably not that difficult to implement, but strictly > speaking it doesn't eliminate the race condition. E.g., even if > you delay, for say, 5 seconds there is no guarantee the > interface update from the FEA has reached the RIB within those > 5 seconds. > > (b) Have the OSPF obtain the interface information via the > RIB. I.e., have the RIB act as a proxy for passing the > information from the FEA to OSPF. This will guarantee that the > RIB will always see the update before the protocol (OSPF). > FYI, we do something similar for multicast: the MFEA acts as a > proxy for the interface information propagation from the FEA to > IGMP/MLD and PIM-SM, but the original motivation for that was > different (the MFEA was adding multicast-specific information to > the iftree). > Though, in case of MFEA the implementation takes a short-cut > utilizing the fact that both the FEA and MFEA are within the > same process. The RIB implementation needs to be a bit different > in that aspect. Option B seems best to me. In general, it seems we should have exactly one 'real' interface tree, and let other modules query it and cache whatever local info they need from this tree. The modules should be aware that interfaces can change at any time, so they should handle errors (ie, I added a route to interface foo and foo doesn't exist now) gracefully. It seems OSPF basically does handle the errors...it just prints a message instead of asserting or crashing. That said, I'll see if I can figure out a way to do 'A' quickly. Trying really hard to get something working by Monday, even if it's a bit of a hack :) Thanks, Ben From greearb at candelatech.com Thu Oct 25 21:03:09 2007 From: greearb at candelatech.com (Ben Greear) Date: Thu, 25 Oct 2007 21:03:09 -0700 Subject: [Xorp-hackers] Question on RIB In-Reply-To: <200710252304.l9PN4qU2003079@possum.icir.org> References: <200710252304.l9PN4qU2003079@possum.icir.org> Message-ID: <472166FD.5060103@candelatech.com> Pavlin Radoslavov wrote: > Ben Greear wrote: > >> I have a scenario of 4 routers. Starting config is: >> >> A <-> B >> B <-> C >> C <-> D >> >> Also: >> B <-> D (high cost link) >> >> OSPF chooses the B-C link instead of the high cost link, and all is well. >> >> Then, I disconnect (remove the interfaces & OSPF config for those interfaces >> with xorpsh) >> >> B & C >> >> OSPF correctly starts using the high-cost link. >> >> >> Then, I reconnect B & C with the low cost link. >> >> It seems OSPF is trying to do the right thing. Routes are deleted from >> the high-cost link, but they do not appear on the low cost link. The >> reason appears to be this error in RIB. I tried doing a 'commit' after >> adding the interface and before adding the config to OSPF, but that did >> not help. >> >> Any idea how RIB learns about the directly connected interfaces? Looks like >> I need to somehow make it learn faster... > > I presume you already double-checked that that 10.2.3.3 indeed is a > router directly connected to one of the new added interfaces. After some more thinking...you may have a point here. There might be a race in my setup logic...ie the interface isn't fully configured (or perhaps the peer isn't fully configured) when I poke xorp. I'm going to add some more debugging logic near where RIB is searching for the Vif and see what I can see. Thanks, Ben From greearb at candelatech.com Fri Oct 26 15:37:27 2007 From: greearb at candelatech.com (Ben Greear) Date: Fri, 26 Oct 2007 15:37:27 -0700 Subject: [Xorp-hackers] Question on RIB In-Reply-To: <200710252304.l9PN4qU2003079@possum.icir.org> References: <200710252304.l9PN4qU2003079@possum.icir.org> Message-ID: <47226C27.2090400@candelatech.com> I found the problem: The Vif reuse logic wasn't quite right: (rib.cc) @@ -509,14 +524,18 @@ new_rib_vif->set_deleted(false); _deleted_vifs.erase(vi); new_rib_vif->copy_in(vif); + _vifs[vifname] = new_rib_vif; + debug_msg("Reused previously deleted vif\n"); } else { // Create a new vif I'm attaching a full patch with more debugging logic for rib in case you'd care to apply it. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -------------- next part -------------- A non-text attachment was scrubbed... Name: xorp.patch Type: text/x-patch Size: 2604 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20071026/723ba7d5/attachment.bin From pavlin at icir.org Fri Oct 26 15:58:20 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 26 Oct 2007 15:58:20 -0700 Subject: [Xorp-hackers] Question on RIB In-Reply-To: Message from Ben Greear of "Fri, 26 Oct 2007 15:37:27 PDT." <47226C27.2090400@candelatech.com> Message-ID: <200710262258.l9QMwKIJ013978@possum.icir.org> Ben Greear wrote: > I found the problem: The Vif reuse logic wasn't quite right: > (rib.cc) > > @@ -509,14 +524,18 @@ > new_rib_vif->set_deleted(false); > _deleted_vifs.erase(vi); > new_rib_vif->copy_in(vif); > + _vifs[vifname] = new_rib_vif; > + debug_msg("Reused previously deleted vif\n"); > } else { > // Create a new vif Nice catch! The fix (slightly modified) is applied to CVS. > I'm attaching a full patch with more debugging logic for rib > in case you'd care to apply it. Adding that amount of debug messages to CVS is probably an overkill and makes the current code more difficult to read. For the time being I'd rather leave it out. If we keep seeing more and more bugs in that part of the code then I might add it to facilitate the bug chasing. Thanks, Pavlin > Thanks, > Ben > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > Index: rib.cc > =================================================================== > RCS file: /cvs/xorp/rib/rib.cc,v > retrieving revision 1.68 > diff -u -r1.68 rib.cc > --- rib.cc 3 Oct 2007 00:05:48 -0000 1.68 > +++ rib.cc 26 Oct 2007 22:35:44 -0000 > @@ -495,9 +507,12 @@ > map::iterator vi; > RibVif* new_rib_vif = NULL; > > - debug_msg("RIB::new_vif: %s\n", vifname.c_str()); > - if (_vifs.find(vifname) != _vifs.end()) > + debug_msg("RIB::new_vif: this: %p name: %s %s\n", > + this, name().c_str(), vifname.c_str()); > + if (_vifs.find(vifname) != _vifs.end()) { > + debug_msg("RIB::new_vif, vif %s already exists.\n", vifname.c_str()); > return XORP_ERROR; > + } > > // > // If the vif is pending deletion, then reuse it instead > @@ -509,14 +524,18 @@ > new_rib_vif->set_deleted(false); > _deleted_vifs.erase(vi); > new_rib_vif->copy_in(vif); > + _vifs[vifname] = new_rib_vif; > + debug_msg("Reused previously deleted vif\n"); > } else { > // Create a new vif > new_rib_vif = new RibVif(this, vif); > _vifs[vifname] = new_rib_vif; > + debug_msg("Created new vif\n"); > } > XLOG_ASSERT(new_rib_vif != NULL); > > if (new_rib_vif->is_underlying_vif_up()) { > + debug_msg("Underlying VIF was up\n"); > // > // Add the directly connected routes associated with this vif > // > @@ -535,6 +554,9 @@ > add_connected_route(*new_rib_vif, subnet_addr, addr, peer_addr); > } > } > + else { > + debug_msg("Underlying vif was NOT up, not adding directly connected routes at this time.\n"); > + } > > return XORP_OK; > } > @@ -685,6 +707,8 @@ > if (vi == _vifs.end()) { > XLOG_ERROR("Attempting to add address to non-existant Vif \"%s\"", > vifname.c_str()); > + XLOG_ERROR("RIB: this: %p name: %s\n%s\n", > + this, name().c_str(), str().c_str()); > return XORP_ERROR; > } > RibVif* vif = vi->second; > @@ -1559,6 +1583,23 @@ > } > > template > +string > +RIB::str() > +{ > + string rv; > + map::iterator iter; > + > + for (iter = _vifs.begin(); iter != _vifs.end(); ++iter) { > + rv += iter->first; > + rv += ": "; > + rv += iter->second->str(); > + rv += "\n"; > + } > + return rv; > +} > + > + > +template > void > RIB::print_rib() const > { > Index: rib.hh > =================================================================== > RCS file: /cvs/xorp/rib/rib.hh,v > retrieving revision 1.41 > diff -u -r1.41 rib.hh > --- rib.hh 3 Oct 2007 00:05:48 -0000 1.41 > +++ rib.hh 26 Oct 2007 22:35:44 -0000 > @@ -486,6 +486,7 @@ > * Print the RIB structure for debugging > */ > void print_rib() const; > + string str(); > > /** > * Get RIB name. > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From arjun at ceeyes.com Wed Oct 31 20:34:02 2007 From: arjun at ceeyes.com (Arjun Prasad) Date: Thu, 1 Nov 2007 09:04:02 +0530 Subject: [Xorp-hackers] CLI Message-ID: <000c01c81c38$0d3591e0$2283a8c0@ceeyes.com> Hi all! plz any one can tell me where in the source code command line interface is asking for command(string). Regards, Arjun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20071101/5745b799/attachment.html From arjun at ceeyes.com Wed Oct 31 20:45:45 2007 From: arjun at ceeyes.com (Arjun Prasad) Date: Thu, 1 Nov 2007 09:15:45 +0530 Subject: [Xorp-hackers] periodic updation Message-ID: <001f01c81c39$b0595fe0$2283a8c0@ceeyes.com> Hi all! As we know that there is periodic as well as triggered updation is there in RIP and OSPF. My question is why we need periodic updation as triggered updation is sufficeint enough to update the table whenever there is any change in network.(also because of periodic updation we have unneccessry trafic in network). And why periodic updation time interval is so less in case of RIP table updation whereas comparatively high in OSPF table periodic updation. Regards, Arjun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20071101/889312c7/attachment.html From pavlin at icir.org Wed Oct 31 21:01:26 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 31 Oct 2007 21:01:26 -0700 Subject: [Xorp-hackers] CLI In-Reply-To: Message from "Arjun Prasad" of "Thu, 01 Nov 2007 09:04:02 +0530." <000c01c81c38$0d3591e0$2283a8c0@ceeyes.com> Message-ID: <200711010401.lA141QPV052595@possum.icir.org> > plz any one can tell me where in the source code command line > interface is asking for command(string). Please clarify your question and provide more details, because I don't understand it. Thanks, Pavlin