From Ivan.Mellen at gdcanada.com Thu Jan 3 08:31:34 2013 From: Ivan.Mellen at gdcanada.com (Mellen, Ivan) Date: Thu, 3 Jan 2013 09:31:34 -0700 Subject: [Xorp-users] bug: OSPF designated router holds routes from disconnected router Message-ID: <0119B6D93B00714F84D6C33DBBA5E56F051E0042@CGYSVW100.gdcan.com> Hi, I'd like to report this XORP bug: OSPF designated router holds routes from disconnected router. Bug description: The OSPF router A holds routes from another OSPF router C long time after that router C has disconnected, even though A knows that OSPF neighbor C is down. This happens only if the OSPF router A is the Designated Router. If OSPF router A is alone (has no neighbors) after router C disconnects, this bug does not appear. This test used unmodified XORP v1.8.5 with CORE 4.3 (20120307) running on 32 bit UBUNTU 11.04 For the details, required configuration files and CORE scenario please see: http://www.xorp.org/bugzilla/show_bug.cgi?id=120 Timeline (min:sec): 0:00 CORE simulation started 0:56 Injected route 10.41.1.0 from router C node appears in router A and router B 2:00 router C node interface to LAN manually brought down (ifconfig eth0 down) 2:35 router B (non DR node) properly withdraws injected route 10.41.1.0/26 from its kernel table. router A (Designated router) detects that router C neighbor is down, but keeps the injected route for another hour (even though it knows that next hop 10.254.10.4 is down) The console log below shows router A incorrectly maintain a route to 10.41.1.0/26 via a Down neighbor (10.254.10.4). The state below can persist up to 1 hour (External Route ads expire after 3600 seconds). root at n1:/tmp/pycore.34570/n1.conf# /usr/local/xorp/sbin/xorpsh Welcome to XORP v1.8.5 on n1 Version tag: 00000000 Build Date: 2012-12-05 11:26 32-bit root at n1> show ospf4 neighbor detail Address Interface State ID Pri Dead 10.254.41.14 eth2/eth2 Full 10.254.41.14 0 31 Area 0.0.0.0, opt 0x2, DR 10.254.40.131, BDR 0.0.0.0 Up 00:05:38, adjacent 00:04:53 10.254.10.4 eth2/eth2 Down 10.254.10.4 0 0 Area 0.0.0.0, opt 0, DR 0.0.0.0, BDR 0.0.0.0 Up 00:05:37 root at n1> show route table ipv4 unicast ospf detail Network 10.11.67.128/26 Nexthop := 10.254.41.14 Interface := eth2 Vif := eth2 Metric := 1 Protocol := ospf Admin distance := 110 Network 10.41.1.0/26 Nexthop := 10.254.10.4 Interface := eth2 Vif := eth2 Metric := 3 Protocol := ospf Admin distance := 110 root at n1> 10:00 router B LAN interface manually brought down (ifconfig eth2 down), router A remains alone on VND network 10:35 router A properly removes injected route router A does not act as DR when alone ? after reconnecting router B back to LAN network, injected route 10.41.1.0/26 does not appear again To prove that Designated Router status is causing this bug, please comment line 56 in the xorp2.conf file and restart the simulation. This will allow router B to participate in the DR selection and to win it. Once the router B becomes the DR, it will incorrectly main a route to 10.41.1.0/26 via a down neighbor after the router C node has disconnected. On the other hand, the router A node will now properly remove this route. Has anybody experienced similar behavior of the OSFP router? Thanks, Ivan The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20130103/8d17b38c/attachment.html From ahmadyudo at yahoo.com Fri Jan 4 21:02:29 2013 From: ahmadyudo at yahoo.com (oduy ahmad) Date: Fri, 4 Jan 2013 21:02:29 -0800 (PST) Subject: [Xorp-users] (no subject) Message-ID: <1357362149.72600.YahooMailNeo@web163905.mail.gq1.yahoo.com> http://hauntedlive.com/wp-content/plugins/html-on-pages/mndhvf.php -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20130104/93abc319/attachment.html From wkevils at gmail.com Fri Jan 11 22:43:53 2013 From: wkevils at gmail.com (Kevin Wilson) Date: Sat, 12 Jan 2013 08:43:53 +0200 Subject: [Xorp-users] build error in xorp : invalid conversion from 'const nlmsghdr*' Message-ID: Hi, I am trying to build XORP on Fedora 17 x86_64 machine. I downloaded xorp-1.8.5-src.tar.bz2 from http://www.xorp.org/releases/current/ I untar it and ran : scons. I am getting this error: ... fea/data_plane/ifconfig/ifconfig_get_netlink_socket.cc:282:35: error: invalid conversion from 'const nlmsghdr*' to 'nlmsghdr*' [-fpermissive] scons: *** [obj/x86_64-unknown-linux-gnu/fea/data_plane/ifconfig/ifconfig_get_netlink_socket.os] Error 1 scons: building terminated because of errors. ... Any ideas ? Is there a way to build scons without fea? Or to build only pim? scons --help | g fea shows: enable_fea_dummy: Build fea-dummy target (yes|no) But: scons enable_fea_dummy=no gave me the same error above of "invalid conversion from 'const nlmsghdr*' to 'nlmsghdr*' [-" rgs, Kevin From greearb at candelatech.com Sat Jan 12 09:45:20 2013 From: greearb at candelatech.com (Ben Greear) Date: Sat, 12 Jan 2013 09:45:20 -0800 Subject: [Xorp-users] build error in xorp : invalid conversion from 'const nlmsghdr*' In-Reply-To: References: Message-ID: <50F1A130.2050303@candelatech.com> On 01/11/2013 10:43 PM, Kevin Wilson wrote: > Hi, > I am trying to build XORP on Fedora 17 x86_64 machine. > > I downloaded xorp-1.8.5-src.tar.bz2 from http://www.xorp.org/releases/current/ > > I untar it and ran : scons. > > I am getting this error: > ... > fea/data_plane/ifconfig/ifconfig_get_netlink_socket.cc:282:35: error: > invalid conversion from 'const nlmsghdr*' to 'nlmsghdr*' > [-fpermissive] > scons: *** [obj/x86_64-unknown-linux-gnu/fea/data_plane/ifconfig/ifconfig_get_netlink_socket.os] > Error 1 > scons: building terminated because of errors. > ... > > Any ideas ? > > Is there a way to build scons without fea? Or to build only pim? Try the git tree, it's currently building F-17 for me. Thanks, Ben > > scons --help | g fea > shows: > enable_fea_dummy: Build fea-dummy target (yes|no) > > But: > scons enable_fea_dummy=no > gave me the same error above of "invalid conversion from 'const > nlmsghdr*' to 'nlmsghdr*' [-" > > rgs, > Kevin > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From wkevils at gmail.com Sat Jan 12 11:53:50 2013 From: wkevils at gmail.com (Kevin Wilson) Date: Sat, 12 Jan 2013 21:53:50 +0200 Subject: [Xorp-users] build error in xorp : invalid conversion from 'const nlmsghdr*' In-Reply-To: <50F1A130.2050303@candelatech.com> References: <50F1A130.2050303@candelatech.com> Message-ID: Hi, Thanks! with git tree, scons and scons install worked. Rgs KW On Sat, Jan 12, 2013 at 7:45 PM, Ben Greear wrote: > On 01/11/2013 10:43 PM, Kevin Wilson wrote: >> >> Hi, >> I am trying to build XORP on Fedora 17 x86_64 machine. >> >> I downloaded xorp-1.8.5-src.tar.bz2 from >> http://www.xorp.org/releases/current/ >> >> I untar it and ran : scons. >> >> I am getting this error: >> ... >> fea/data_plane/ifconfig/ifconfig_get_netlink_socket.cc:282:35: error: >> invalid conversion from 'const nlmsghdr*' to 'nlmsghdr*' >> [-fpermissive] >> scons: *** >> [obj/x86_64-unknown-linux-gnu/fea/data_plane/ifconfig/ifconfig_get_netlink_socket.os] >> Error 1 >> scons: building terminated because of errors. >> ... >> >> Any ideas ? >> >> Is there a way to build scons without fea? Or to build only pim? > > > Try the git tree, it's currently building F-17 for me. > > Thanks, > Ben > >> >> scons --help | g fea >> shows: >> enable_fea_dummy: Build fea-dummy target (yes|no) >> >> But: >> scons enable_fea_dummy=no >> gave me the same error above of "invalid conversion from 'const >> nlmsghdr*' to 'nlmsghdr*' [-" >> >> rgs, >> Kevin >> >> _______________________________________________ >> Xorp-users mailing list >> Xorp-users at xorp.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users >> > > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > From dspisak at agiosat.net Tue Jan 15 17:45:06 2013 From: dspisak at agiosat.net (Daniel Spisak) Date: Tue, 15 Jan 2013 17:45:06 -0800 Subject: [Xorp-users] Xorp 1.8.6 causes kernel panic in FreeBSD 8.3 Message-ID: <50F60622.8060703@agiosat.net> Hi there, I'm new to the list! Myself and a colleague have been trying to use Xorp 1.8.6 (we pulled the source from the git repo about a two months ago) to handle multicast routing over GRE tunnels for a rather convoluted scenario. In the course of trying to get that setup working (which will be another separate email to the list) we seem to be running into behavior from Xorp that is causing kernel panics to happen on FreeBSD 8.3-RELEASE. Currently, we are able to startup Xorp normally with no apparent problems. However, as soon as we try to shutdown the Xorp service or initiate a system reboot the system will kernel panic. We are running Xorp on ALIX1.D single board computers. You can see more about the hardware specs here: http://pcengines.ch/alix1d.htm I have created a file dump of some of the kernel panics along with some kdbg backtraces for developers to take a look at (along with a kernel.debug for our kernel build). If I am reading the backtraces right, it looks like there might be an issue being caused by IGMP somehow. Perhaps a mismatch between v2 and v3? http://www.mediafire.com/?ojxdc172mp7q6 I'm pretty new to Xorp and multicast so its possible I've missed something here. Below is the xorp.config of the box in question that does the kernel panics: /* XORP configuration file * * Configuration format: 1.1 * XORP version: 1.8.6-WIP * Date: 2012/12/05 00:04:02.421583 * Host: dispatch-dev * User: root */ protocols { fib2mrib { disable: false } igmp { disable: false interface vr0 { vif vr0 { disable: false version: 2 enable-ip-router-alert-option-check: false query-interval: 125 query-last-member-interval: 1 query-response-interval: 10 robust-count: 2 } } traceoptions { flag { all { disable: false } } } } pimsm4 { disable: false interface vr0 { vif vr0 { disable: false dr-priority: 100 hello-period: 30 hello-triggered-delay: 5 } } interface "register_vif" { vif "register_vif" { disable: false dr-priority: 1 hello-period: 30 hello-triggered-delay: 5 } } static-rps { rp 10.255.254.254 { group-prefix 239.0.0.1/32 { rp-priority: 192 hash-mask-len: 30 } } } switch-to-spt-threshold { disable: false interval: 100 bytes: 102400 } traceoptions { flag { all { disable: false } } } } } interfaces { restore-original-config-on-shutdown: false interface vr0 { description: "Ethernet Iface" disable: false discard: false unreachable: false management: false parent-ifname: "" iface-type: "" vid: "" vif vr0 { disable: false } default-system-config } } plumbing { mfea4 { disable: false interface vr0 { vif vr0 { disable: false } } interface "register_vif" { vif "register_vif" { disable: false } } traceoptions { flag { all { disable: false } } } } } Output from fbsd for interfaces: dispatch-dev# ifconfig -a vr0: flags=8a43 metric 0 mtu 1500 options=8280b ether 00:0d:b9:0e:32:d4 inet XX.XX.XXX.XX netmask 0xfffffffc broadcast XX.XX.XXX.XX inet 192.168.10.2 netmask 0xffffff00 broadcast 192.168.10.255 inet 10.13.8.253 netmask 0xffffff80 broadcast 10.13.8.255 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 options=3 inet 127.0.0.1 netmask 0xff000000 enc0: flags=0<> metric 0 mtu 1536 pflog0: flags=0<> metric 0 mtu 33200 gre0: flags=9010 metric 0 mtu 1476 If anyone has any input/insight as to what is causing the kernel panics and how to fix it, that would be great. Thanks! -- Daniel Spisak Network Engineer Agiosat Government Services dspisak at agiosat.net From greearb at candelatech.com Tue Jan 15 18:03:01 2013 From: greearb at candelatech.com (Ben Greear) Date: Tue, 15 Jan 2013 18:03:01 -0800 Subject: [Xorp-users] Xorp 1.8.6 causes kernel panic in FreeBSD 8.3 In-Reply-To: <50F60622.8060703@agiosat.net> References: <50F60622.8060703@agiosat.net> Message-ID: <50F60A55.5010703@candelatech.com> On 01/15/2013 05:45 PM, Daniel Spisak wrote: > Hi there, I'm new to the list! > > Myself and a colleague have been trying to use Xorp 1.8.6 (we pulled the > source from the git repo about a two months ago) to handle multicast > routing over GRE tunnels for a rather convoluted scenario. In the course > of trying to get that setup working (which will be another separate > email to the list) we seem to be running into behavior from Xorp that is > causing kernel panics to happen on FreeBSD 8.3-RELEASE. > > Currently, we are able to startup Xorp normally with no apparent > problems. However, as soon as we try to shutdown the Xorp service or > initiate a system reboot the system will kernel panic. We are running > Xorp on ALIX1.D single board computers. You can see more about the > hardware specs here: Well, whatever the problem might be with Xorp, the kernel shouldn't crash, so it's a FreeBSD bug primarily. I mostly work with Linux, so hopefully someone else (probably on some BSD mailing list) can help with the BSD kernel issues... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From dspisak at agiosat.net Tue Jan 15 19:52:25 2013 From: dspisak at agiosat.net (Daniel Spisak) Date: Tue, 15 Jan 2013 19:52:25 -0800 Subject: [Xorp-users] Need help with a multicast GRE & Cisco setup Message-ID: <50F623F9.7070503@agiosat.net> So I've got a tricky multicast setup I've been trying to get working and I feel like I've gone as far as I can with my limited knowledge. What we have basically is a situation where we have a device that takes radio chatter and turns it into multicast IP packets. There are potentially multiple users that would be talking to a central dispatch user and that central dispatch user also talks back to all of the remote users. In the diagram below dispatch is ROIP #2 and a remote user is ROIP #1. http://i.minus.com/iNCKQpvwwAcCI.png Because of the nature of the network connections between both users, it is necessary to do GRE tunnels to a common midpoint router to get multicast traffic across. In our case we have the ability to use a Cisco router for both our midpoint router as well as the dispatch side router. However, we are doing jitter correction for inbound packets from the ROIP boxes, and this is being handled by our FreeBSD ALIX box at both ends. This causes some complications for how to handle the inbound traffic at the dispatch end unless we do something like make the dispatch side ROIP box hang off a 3rd stub VLAN and talk to the ALIX board as its next-hop gateway and ensure the FreeBSD box is setup to act as a router for unicast and multicast traffic. Below I've included pastebin links to the xorp configs and the cisco configs as well. I'm hoping someone can pipe up here with some suggestions as to what I'm doing wrong and how to correct it. Right now for example, if I try to send a single ICMP ping to the 239.0.0.1 multicast IP from the midpoint cisco I get two responses back from the 10.255.254.6 address. Midpoint Cisco config: http://pastebin.com/53bxF2xU Dispatch Cisco config: http://pastebin.com/tUYq4sbi ROIP #1 Xorp config: http://pastebin.com/uTpK7nvT ROIP #2 Xorp config: http://pastebin.com/iRYMLB1A I'm still pretty green on multicast so a lot of this has been done based on reading up as much as I can and then tweaking things a little at a time, but I'm at a point now where I feel like I've lost sight of the solution and was hoping someone on here might have some insight as to how we might make this scenario work, if possible. If there is additional diagnostic info needed here, let me know and I will be happy to provide it, thanks! -- Daniel Spisak Network Engineer dspisak at agiosat.net From dspisak at agiosat.net Thu Jan 17 15:25:07 2013 From: dspisak at agiosat.net (Daniel Spisak) Date: Thu, 17 Jan 2013 15:25:07 -0800 Subject: [Xorp-users] Xorp 1.8.6 causes kernel panic in FreeBSD 8.3 In-Reply-To: <50F60A55.5010703@candelatech.com> References: <50F60622.8060703@agiosat.net> <50F60A55.5010703@candelatech.com> Message-ID: <50F88853.1080504@agiosat.net> Ben, I've gone ahead and submitted a bug to FreeBSD regarding this behavior which can be seen here: http://www.freebsd.org/cgi/query-pr.cgi?pr=175365 However, you will notice that its listed as a low priority and "non-critical" which I find a bit annoying considering the fact that userland software can cause the kernel to panic. To that effect, is there something we could be doing differently on our Xorp config to perhaps mitigate the problem? I was hoping other users with GRE and multicast experience would be able to speak up about our configuration we are trying to make work, but the lack of replies to it has me feeling like we're not going to be getting a lot of help from the community and this combined with having to deal with the whole kernel panic issue as well has me wondering where to go for working multicast capabilities as most of the other software projects I could find were so old and/or not actively maintained that it seemed like a long shot anything would be possible. Xorp to me at least felt like our last best hope for getting working multicast on FreeBSD, but I don't pretend to know everything out there. Any help is appreciated, thanks! > Ben Greear > Tuesday, January 15, 2013 6:03 PM > > > Well, whatever the problem might be with Xorp, the kernel shouldn't > crash, so it's a FreeBSD bug primarily. > > I mostly work with Linux, so hopefully someone else (probably > on some BSD mailing list) can help with the BSD kernel issues... > > Thanks, > Ben > > Daniel Spisak > Tuesday, January 15, 2013 5:45 PM > Hi there, I'm new to the list! > > Myself and a colleague have been trying to use Xorp 1.8.6 (we pulled > the source from the git repo about a two months ago) to handle > multicast routing over GRE tunnels for a rather convoluted scenario. > In the course of trying to get that setup working (which will be > another separate email to the list) we seem to be running into > behavior from Xorp that is causing kernel panics to happen on FreeBSD > 8.3-RELEASE. > > Currently, we are able to startup Xorp normally with no apparent > problems. However, as soon as we try to shutdown the Xorp service or > initiate a system reboot the system will kernel panic. We are running > Xorp on ALIX1.D single board computers. You can see more about the > hardware specs here: > > http://pcengines.ch/alix1d.htm > > I have created a file dump of some of the kernel panics along with > some kdbg backtraces for developers to take a look at (along with a > kernel.debug for our kernel build). If I am reading the backtraces > right, it looks like there might be an issue being caused by IGMP > somehow. Perhaps a mismatch between v2 and v3? > > http://www.mediafire.com/?ojxdc172mp7q6 > > I'm pretty new to Xorp and multicast so its possible I've missed > something here. Below is the xorp.config of the box in question that > does the kernel panics: > > /* XORP configuration file > * > * Configuration format: 1.1 > * XORP version: 1.8.6-WIP > * Date: 2012/12/05 00:04:02.421583 > * Host: dispatch-dev > * User: root > */ > > protocols { > fib2mrib { > disable: false > } > igmp { > disable: false > interface vr0 { > vif vr0 { > disable: false > version: 2 > enable-ip-router-alert-option-check: false > query-interval: 125 > query-last-member-interval: 1 > query-response-interval: 10 > robust-count: 2 > } > } > traceoptions { > flag { > all { > disable: false > } > } > } > } > pimsm4 { > disable: false > interface vr0 { > vif vr0 { > disable: false > dr-priority: 100 > hello-period: 30 > hello-triggered-delay: 5 > } > } > interface "register_vif" { > vif "register_vif" { > disable: false > dr-priority: 1 > hello-period: 30 > hello-triggered-delay: 5 > } > } > static-rps { > rp 10.255.254.254 { > group-prefix 239.0.0.1/32 { > rp-priority: 192 > hash-mask-len: 30 > } > } > } > switch-to-spt-threshold { > disable: false > interval: 100 > bytes: 102400 > } > traceoptions { > flag { > all { > disable: false > } > } > } > } > } > interfaces { > restore-original-config-on-shutdown: false > interface vr0 { > description: "Ethernet Iface" > disable: false > discard: false > unreachable: false > management: false > parent-ifname: "" > iface-type: "" > vid: "" > vif vr0 { > disable: false > } > default-system-config > } > } > plumbing { > mfea4 { > disable: false > interface vr0 { > vif vr0 { > disable: false > } > } > interface "register_vif" { > vif "register_vif" { > disable: false > } > } > traceoptions { > flag { > all { > disable: false > } > } > } > } > } > > Output from fbsd for interfaces: > > dispatch-dev# ifconfig -a > vr0: flags=8a43 > metric 0 mtu 1500 > > options=8280b > ether 00:0d:b9:0e:32:d4 > inet XX.XX.XXX.XX netmask 0xfffffffc broadcast XX.XX.XXX.XX > inet 192.168.10.2 netmask 0xffffff00 broadcast 192.168.10.255 > inet 10.13.8.253 netmask 0xffffff80 broadcast 10.13.8.255 > media: Ethernet autoselect (100baseTX ) > status: active > lo0: flags=8049 metric 0 mtu 16384 > options=3 > inet 127.0.0.1 netmask 0xff000000 > enc0: flags=0<> metric 0 mtu 1536 > pflog0: flags=0<> metric 0 mtu 33200 > gre0: flags=9010 metric 0 mtu 1476 > > If anyone has any input/insight as to what is causing the kernel > panics and how to fix it, that would be great. Thanks! > -- Daniel Spisak Network Engineer dspisak at agiosat.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20130117/773f2177/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: compose-unknown-contact.jpg Type: image/jpeg Size: 770 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20130117/773f2177/attachment.jpg From Ivan.Mellen at gdcanada.com Fri Jan 18 09:25:55 2013 From: Ivan.Mellen at gdcanada.com (Mellen, Ivan) Date: Fri, 18 Jan 2013 10:25:55 -0700 Subject: [Xorp-users] Partial fix found for : OSPF routes are lost/missing after a few hours Message-ID: <0119B6D93B00714F84D6C33DBBA5E56F051E0070@CGYSVW100.gdcan.com> Hi, In XORP 1.8.5, OSPF routes are being dropped when there are more than 100 OSPF routes. Once dropped these routes do not recover. Depending on the processing power of the PC, this bug can be reproduced anywhere from 100 to 700 routes and the time when routes are lost can be as low as one hour to several days. After examining Wireshark logs and looking through the XORP code the problem seems to be the way XORP packages route updates. There is only one route per LSA and when an OSPF refresh starts(after one hour) OSPF receivers can be overloaded with packets. A simple fix is to apply the below patch which adds a small delay between transmitting LSA packets. Of course the proper fix is to put more than one route in an LSA packet but this is a lengthy change to OSPF. *** peer.cc 19 Jan 2012 20:28:20 -0000 1.1 --- peer.cc 11 Dec 2012 00:20:14 -0000 1.2 *************** *** 4112,4117 **** --- 4112,4119 ---- _peer.transmit(tr); + usleep(50000); return true; } Cheers, Ivan The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20130118/3493544b/attachment-0001.html From greearb at candelatech.com Fri Jan 18 09:41:06 2013 From: greearb at candelatech.com (Ben Greear) Date: Fri, 18 Jan 2013 09:41:06 -0800 Subject: [Xorp-users] Partial fix found for : OSPF routes are lost/missing after a few hours In-Reply-To: <0119B6D93B00714F84D6C33DBBA5E56F051E0070@CGYSVW100.gdcan.com> References: <0119B6D93B00714F84D6C33DBBA5E56F051E0070@CGYSVW100.gdcan.com> Message-ID: <50F98932.90302@candelatech.com> On 01/18/2013 09:25 AM, Mellen, Ivan wrote: > Hi, > > In XORP 1.8.5, OSPF routes are being dropped when there are more than 100 OSPF routes. Once dropped these routes do not recover. > > Depending on the processing power of the PC, this bug can be reproduced anywhere from 100 to 700 routes and the time when routes are lost can be as low as one > hour to several days. > > After examining Wireshark logs and looking through the XORP code the problem seems to be the way XORP packages route updates. There is only one > route per LSA and when an OSPF refresh starts(after one hour) OSPF receivers can be overloaded with packets. > > A simple fix is to apply the below patch which adds a small delay between transmitting LSA packets. Of course the proper fix is to put more > than one route in an LSA packet but this is a lengthy change to OSPF. > > *** peer.cc 19 Jan 2012 20:28:20 -0000 1.1 > --- peer.cc 11 Dec 2012 00:20:14 -0000 1.2 > *************** > *** 4112,4117 **** > --- 4112,4119 ---- > > _peer.transmit(tr); > > + usleep(50000); > return true; > } I fixed some OSPF convergence issues related to bad OSPF retry timers (or something like that) some time back...I wonder if that is what you are hitting. Can you try top-of-tree xorp (without the hack above) and see if that works better? Either way, I'm reluctant to apply this sort of patch upstream... Thanks, Ben > > Cheers, > > Ivan > > The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the > exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this > communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender > immediately by return e-mail and destroy all copies of this message. > Thank you. > > <#> > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From Ivan.Mellen at gdcanada.com Fri Jan 18 14:24:38 2013 From: Ivan.Mellen at gdcanada.com (Mellen, Ivan) Date: Fri, 18 Jan 2013 15:24:38 -0700 Subject: [Xorp-users] Partial fix found for : OSPF routes are lost/missing after a few hours In-Reply-To: <50F98932.90302@candelatech.com> References: <0119B6D93B00714F84D6C33DBBA5E56F051E0070@CGYSVW100.gdcan.com> <50F98932.90302@candelatech.com> Message-ID: <0119B6D93B00714F84D6C33DBBA5E56F051E0074@CGYSVW100.gdcan.com> Hi Ben, Thanks for your reply. I haven't got chance to check top-of-tree xorp version yet. Is there any fix (or is it planed) that enables more than one route in an LSA packet? Thanks, Ivan -----Original Message----- From: Ben Greear [mailto:greearb at candelatech.com] Sent: Friday, January 18, 2013 10:41 AM To: Mellen, Ivan Cc: xorp-users at xorp.org Subject: Re: [Xorp-users] Partial fix found for : OSPF routes are lost/missing after a few hours On 01/18/2013 09:25 AM, Mellen, Ivan wrote: > Hi, > > In XORP 1.8.5, OSPF routes are being dropped when there are more than 100 OSPF routes. Once dropped these routes do not recover. > > Depending on the processing power of the PC, this bug can be > reproduced anywhere from 100 to 700 routes and the time when routes are lost can be as low as one hour to several days. > > After examining Wireshark logs and looking through > the XORP code the problem seems to be the way XORP packages route updates. There is only one route per LSA and when an OSPF refresh starts(after one hour) OSPF receivers can be overloaded with packets. > > A simple fix is to apply the below patch which adds a > small delay between transmitting LSA packets. Of course the proper fix is to put more than one route in an LSA packet but this is a lengthy change to OSPF. > > *** peer.cc 19 Jan 2012 20:28:20 -0000 1.1 > --- peer.cc 11 Dec 2012 00:20:14 -0000 1.2 > *************** > *** 4112,4117 **** > --- 4112,4119 ---- > > _peer.transmit(tr); > > + usleep(50000); > return true; > } I fixed some OSPF convergence issues related to bad OSPF retry timers (or something like that) some time back...I wonder if that is what you are hitting. Can you try top-of-tree xorp (without the hack above) and see if that works better? Either way, I'm reluctant to apply this sort of patch upstream... Thanks, Ben > > Cheers, > > Ivan > > The information contained in this e-mail message is PRIVATE. It may > contain confidential information and may be legally privileged. It is > intended for the exclusive use of the addressee(s). If you are not the > intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message. > Thank you. > > <#> > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From Ivan.Mellen at gdcanada.com Fri Jan 18 14:29:03 2013 From: Ivan.Mellen at gdcanada.com (Mellen, Ivan) Date: Fri, 18 Jan 2013 15:29:03 -0700 Subject: [Xorp-users] bug: OSPF designated router holds routes from disconnected router In-Reply-To: <0119B6D93B00714F84D6C33DBBA5E56F051E0074@CGYSVW100.gdcan.com> References: <0119B6D93B00714F84D6C33DBBA5E56F051E0070@CGYSVW100.gdcan.com><50F98932.90302@candelatech.com> <0119B6D93B00714F84D6C33DBBA5E56F051E0074@CGYSVW100.gdcan.com> Message-ID: <0119B6D93B00714F84D6C33DBBA5E56F051E0075@CGYSVW100.gdcan.com> Hi, I've posted this bug few weeks ago and was curious if anyone had a chance to look at it? Basically in summary the bug is as follows: The OSPF router A holds routes from another OSPF router C long time after that router C has disconnected, even though A knows that OSPF neighbor C is down. This happens only if the OSPF router A is the Designated Router. Full description is at http://www.xorp.org/bugzilla/show_bug.cgi?id=120 Thanks, Ivan The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message. Thank you. From greearb at candelatech.com Fri Jan 18 14:29:04 2013 From: greearb at candelatech.com (Ben Greear) Date: Fri, 18 Jan 2013 14:29:04 -0800 Subject: [Xorp-users] Partial fix found for : OSPF routes are lost/missing after a few hours In-Reply-To: <0119B6D93B00714F84D6C33DBBA5E56F051E0074@CGYSVW100.gdcan.com> References: <0119B6D93B00714F84D6C33DBBA5E56F051E0070@CGYSVW100.gdcan.com> <50F98932.90302@candelatech.com> <0119B6D93B00714F84D6C33DBBA5E56F051E0074@CGYSVW100.gdcan.com> Message-ID: <50F9CCB0.4050607@candelatech.com> On 01/18/2013 02:24 PM, Mellen, Ivan wrote: > Hi Ben, > Thanks for your reply. > I haven't got chance to check top-of-tree xorp version yet. > Is there any fix (or is it planed) that enables more than one route in > an LSA packet? I don't have any plans to muck with it unless I hit errors in my own testing, or if someone wants to pay for the feature. I will be happy to try to test and merge someone else's fixes, however. I don't recall exactly what I fixed last time, and too busy to go dig through gitk at the moment. Thanks, Ben > > Thanks, > > Ivan > > -----Original Message----- > From: Ben Greear [mailto:greearb at candelatech.com] > Sent: Friday, January 18, 2013 10:41 AM > To: Mellen, Ivan > Cc: xorp-users at xorp.org > Subject: Re: [Xorp-users] Partial fix found for : OSPF routes are > lost/missing after a few hours > > On 01/18/2013 09:25 AM, Mellen, Ivan wrote: >> Hi, >> >> In XORP 1.8.5, OSPF routes are being dropped when there are more than > 100 OSPF routes. Once dropped these routes do not recover. >> >> Depending on the processing power of the PC, this bug can be >> reproduced anywhere from 100 to 700 routes and the time when routes > are lost can be as low as one hour to several days. >> >> After examining Wireshark logs and looking through >> the XORP code the problem seems to be the way XORP packages route > updates. There is only one route per LSA and when an OSPF refresh > starts(after one hour) OSPF receivers can be overloaded with packets. >> >> A simple fix is to apply the below patch which adds a > >> small delay between transmitting LSA packets. Of course the proper fix > is to put more than one route in an LSA packet but this is a lengthy > change to OSPF. >> >> *** peer.cc 19 Jan 2012 20:28:20 -0000 1.1 >> --- peer.cc 11 Dec 2012 00:20:14 -0000 1.2 >> *************** >> *** 4112,4117 **** >> --- 4112,4119 ---- >> >> _peer.transmit(tr); >> >> + usleep(50000); >> return true; >> } > > I fixed some OSPF convergence issues related to bad OSPF retry timers > (or something like that) some time back...I wonder if that is what you > are hitting. > > Can you try top-of-tree xorp (without the hack above) and see if that > works better? > > Either way, I'm reluctant to apply this sort of patch upstream... > > Thanks, > Ben > >> >> Cheers, >> >> Ivan >> >> The information contained in this e-mail message is PRIVATE. It may >> contain confidential information and may be legally privileged. It is >> intended for the exclusive use of the addressee(s). If you are not the > >> intended recipient, you are hereby notified that any dissemination, > distribution or reproduction of this communication is strictly > prohibited. If the intended recipient(s) cannot be reached or if a > transmission problem has occurred, please notify the sender immediately > by return e-mail and destroy all copies of this message. >> Thank you. >> >> <#> >> >> >> _______________________________________________ >> Xorp-users mailing list >> Xorp-users at xorp.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users >> > > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > -- Ben Greear Candela Technologies Inc http://www.candelatech.com