From bms at incunabulum.net Sun Aug 3 15:07:56 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Sun, 03 Aug 2008 23:07:56 +0100 Subject: [Xorp-users] Compiling xorp with olsr In-Reply-To: <20080731101038.GA14676@calhariz.com> References: <20080730234327.GA28029@calhariz.com> <489173BB.70507@incunabulum.net> <20080731101038.GA14676@calhariz.com> Message-ID: <48962C3C.3000003@incunabulum.net> Jose Manuel dos Santos Calhariz wrote: >> OLSR is turned on by default at the moment and should build w/o any >> additional options, if adding --with-olsr it won't do anything due to >> how configure.in is currently set up. >> > > Thank you for the information, I will correct my ./configure command. > Thanks. You're quite right that there is a problem with how --with-olsr is implemented. Unfortunately we need to decide going forward whether or not to keep olsr turned on by default before making a change. This is not going to change for the 1.5 release, so please continue to workaround the behaviour of --with-olsr as discussed. Thanks BMS From karnik.jain at einfochips.com Fri Aug 8 02:57:26 2008 From: karnik.jain at einfochips.com (karnik) Date: Fri, 08 Aug 2008 15:27:26 +0530 Subject: [Xorp-users] [OSPF]: reagrding 1583 compatibility Message-ID: <489C1886.10700@einfochips.com> An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080808/8eb76532/attachment.html From atanu at icir.org Fri Aug 8 08:58:22 2008 From: atanu at icir.org (Atanu Ghosh) Date: Fri, 08 Aug 2008 08:58:22 -0700 Subject: [Xorp-users] [OSPF]: reagrding 1583 compatibility In-Reply-To: Message from karnik of "Fri, 08 Aug 2008 15:27:26 +0530." <489C1886.10700@einfochips.com> Message-ID: <55026.1218211102@xorps.icir.org> Hi, This bool changes the preference rules when choosing among multiple AS-external-LSAs advertising the same destination. It does not revert the behaviour of the whole OSPF to RFC1583. >From RFC2328: ---------------------------------------- RFC1583Compatibility Controls the preference rules used in Section 16.4 when choosing among multiple AS-external-LSAs advertising the same destination. When set to "enabled", the preference rules remain those specified by RFC 1583 ([Ref9]). When set to "disabled", the preference rules are those stated in Section 16.4.1, which prevent routing loops when AS- external-LSAs for the same destination have been originated from different areas. Set to "enabled" by default. In order to minimize the chance of routing loops, all OSPF routers in an OSPF routing domain should have RFC1583Compatibility set identically. When there are routers present that have not been updated with the functionality specified in Section 16.4.1 of this memo, all routers should have RFC1583Compatibility set to "enabled". Otherwise, all routers should have RFC1583Compatibility set to "disabled", preventing all routing loops. ---------------------------------------- The user manual now explains the behaviour of ths flag. Atanu. >>>>> "karnik" == karnik writes: karnik> hi I am using xorp as a ospf router i want to know karnik> following inforamtion: 1) if i enable 1583 compatibility in karnik> xorp then it totally behaves as a 1583 compatible router karnik> inplace of 2328 ospf . 2) I want to test following on ospf karnik> router: -> Senario i have to create on ospf router after enabling 1583 karnik> compatibility 1. OSPF is enabled on the routers. Wait for karnik> their databases to synchronize. 2. TR1 transmits a karnik> router-LSA for itself with sequence number 0x70000001. karnik> 3. TR1 transmits a router-LSA for itself with sequence karnik> number 0x8FFFFFFE after more than minLSInterval. 4. Observe karnik> the packets transmitted on network 0. then I have to check: karnik> if the RUT supports RFC 1583, it should drop the router-LSA karnik> with sequence number 0x8FFFFFFE. So my question is How can karnik> i test above thing using current your xorp karnik> ..................... Can u please guide me reagrding this karnik> problem.. -- karnik> _____________________________________________________________________ karnik> Disclaimer: This e-mail message and all attachments karnik> transmitted with it are intended solely for the use of the karnik> addressee and may contain legally privileged and karnik> confidential information. If the reader of this message is karnik> not the intended recipient, or an employee or agent karnik> responsible for delivering this message to the intended karnik> recipient, you are hereby notified that any dissemination, karnik> distribution, copying, or other use of this message or its karnik> attachments is strictly prohibited. If you have received karnik> this message in error, please notify the sender immediately karnik> by replying to this message and please delete it from your karnik> computer. Any views expressed in this message are those of karnik> the individual sender unless otherwise stated.Company has karnik> taken enough precautions to prevent the spread of karnik> viruses. However the company accepts no liability for any karnik> damage caused by any virus transmitted by this email. karnik> __________________________________________________________________________ karnik> _______________________________________________ Xorp-users karnik> mailing list Xorp-users at xorp.org karnik> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From karnik.jain at einfochips.com Sat Aug 9 02:49:21 2008 From: karnik.jain at einfochips.com (karnik.jain at einfochips.com) Date: Sat, 9 Aug 2008 15:19:21 +0530 (IST) Subject: [Xorp-users] Xorp-users Digest, Vol 29, Issue 2 In-Reply-To: References: Message-ID: <18283.210.211.253.125.1218275361.squirrel@india.einfochips.com> thank u........................................ > Send Xorp-users mailing list submissions to > xorp-users at xorp.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > or, via email, send a message with subject or body 'help' to > xorp-users-request at xorp.org > > You can reach the person managing the list at > xorp-users-owner at xorp.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Xorp-users digest..." > > > Today's Topics: > > 1. [OSPF]: reagrding 1583 compatibility (karnik) > 2. Re: [OSPF]: reagrding 1583 compatibility (Atanu Ghosh) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 08 Aug 2008 15:27:26 +0530 > From: karnik > Subject: [Xorp-users] [OSPF]: reagrding 1583 compatibility > To: xorp-users at xorp.org > Message-ID: <489C1886.10700 at einfochips.com> > Content-Type: text/plain; charset="us-ascii" > > An HTML attachment was scrubbed... > URL: > http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080808/8eb76532/attachment-0001.html > > ------------------------------ > > Message: 2 > Date: Fri, 08 Aug 2008 08:58:22 -0700 > From: Atanu Ghosh > Subject: Re: [Xorp-users] [OSPF]: reagrding 1583 compatibility > To: karnik > Cc: xorp-users at xorp.org > Message-ID: <55026.1218211102 at xorps.icir.org> > > Hi, > > This bool changes the preference rules when choosing among multiple > AS-external-LSAs advertising the same destination. It does not revert > the behaviour of the whole OSPF to RFC1583. > >>From RFC2328: > ---------------------------------------- > RFC1583Compatibility > Controls the preference rules used in Section 16.4 when > choosing among multiple AS-external-LSAs advertising the > same destination. When set to "enabled", the preference > rules remain those specified by RFC 1583 ([Ref9]). When set > to "disabled", the preference rules are those stated in > Section 16.4.1, which prevent routing loops when AS- > external-LSAs for the same destination have been originated > from different areas. Set to "enabled" by default. > > In order to minimize the chance of routing loops, all OSPF > routers in an OSPF routing domain should have > RFC1583Compatibility set identically. When there are routers > present that have not been updated with the functionality > specified in Section 16.4.1 of this memo, all routers should > have RFC1583Compatibility set to "enabled". Otherwise, all > routers should have RFC1583Compatibility set to "disabled", > preventing all routing loops. > ---------------------------------------- > > The user manual now explains the behaviour of ths flag. > > Atanu. > >>>>>> "karnik" == karnik writes: > > karnik> hi I am using xorp as a ospf router i want to know > karnik> following inforamtion: 1) if i enable 1583 compatibility in > karnik> xorp then it totally behaves as a 1583 compatible router > karnik> inplace of 2328 ospf . 2) I want to test following on ospf > karnik> router: > -> Senario i have to create on ospf router after enabling 1583 > karnik> compatibility 1. OSPF is enabled on the routers. Wait for > karnik> their databases to synchronize. 2. TR1 transmits a > karnik> router-LSA for itself with sequence number 0x70000001. > karnik> 3. TR1 transmits a router-LSA for itself with sequence > karnik> number 0x8FFFFFFE after more than minLSInterval. 4. Observe > karnik> the packets transmitted on network 0. then I have to check: > karnik> if the RUT supports RFC 1583, it should drop the router-LSA > karnik> with sequence number 0x8FFFFFFE. So my question is How can > karnik> i test above thing using current your xorp > karnik> ..................... Can u please guide me reagrding this > karnik> problem.. -- > karnik> > _____________________________________________________________________ > karnik> Disclaimer: This e-mail message and all attachments > karnik> transmitted with it are intended solely for the use of the > karnik> addressee and may contain legally privileged and > karnik> confidential information. If the reader of this message is > karnik> not the intended recipient, or an employee or agent > karnik> responsible for delivering this message to the intended > karnik> recipient, you are hereby notified that any dissemination, > karnik> distribution, copying, or other use of this message or its > karnik> attachments is strictly prohibited. If you have received > karnik> this message in error, please notify the sender immediately > karnik> by replying to this message and please delete it from your > karnik> computer. Any views expressed in this message are those of > karnik> the individual sender unless otherwise stated.Company has > karnik> taken enough precautions to prevent the spread of > karnik> viruses. However the company accepts no liability for any > karnik> damage caused by any virus transmitted by this email. > karnik> > __________________________________________________________________________ > karnik> _______________________________________________ Xorp-users > karnik> mailing list Xorp-users at xorp.org > karnik> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > > > ------------------------------ > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > > End of Xorp-users Digest, Vol 29, Issue 2 > ***************************************** > > > Email Scanned for Virus & Dangerous Content by : www.CleanMailGateway.com > > With regards, K at rN|K, Embedded Dept. -- _____________________________________________________________________ Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated.Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. __________________________________________________________________________ From dirk.schulz at kinzesberg.de Tue Aug 12 06:06:49 2008 From: dirk.schulz at kinzesberg.de (Dirk H. Schulz) Date: Tue, 12 Aug 2008 15:06:49 +0200 Subject: [Xorp-users] Avoiding asynchronous routing with OSPF Message-ID: Hi folks, I have the following setup: ------------- ------------- | | | | upstream routers | | | | ------------- ------------- | | | | | | ------------- ------------- | 1 |-----------------| 2 | my routers (connected via eth1) | | | | ------------- ------------- | | | | | | | | | | ----------- | | -----------| |-------- | switch A (subnet A) | | | | | ----------- | | | | ----------- | -----| |---------------| switch B (subnet B) | | ----------- The routers are using OSPFv2, the backbone area is the one behind my routers where subnet A and subnet B reside. Let's call the interfaces going to the switches ethA and ethB on each router. The servers are using virtual ips on ethA and ethB as gateways, so that servers in subnet A use router1 as gateway and servers in subnet B use router2 as gateway. The problem I have is that packets from servers in subnet B go out via router2 and answers partially come back via router1. I tried to avoid this by setting interface costs: 1. The hightest interface cost is on eth1 which connects my routers directly (so data traffic between MY routers should be avoided). 2. The interface ethA without virtual ip address A (that is ethA on router2) has a significantly higher cost than the other; with ethB it is similar. I had hoped that now OSPF would route the packets for subnet A always via router1 and for subnet B always via router2, but that does not work. There is still traffice destined for subnet B coming in on router1. Is there anything I overlook? Is routing priority based on other parameters than interface cost additionally? Any hint or help is appreciated. Dirk From pavlin at ICSI.Berkeley.EDU Tue Aug 12 21:08:02 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Tue, 12 Aug 2008 21:08:02 -0700 Subject: [Xorp-users] XORP IGMPv3 is not accepting the report with source IP 0.0.0.0 In-Reply-To: <200807241817.m6OIHTM7010761@fruitcake.ICSI.Berkeley.EDU> References: <48856F61.8070304@einfochips.com> <200807221938.m6MJbkbl022277@fruitcake.ICSI.Berkeley.EDU> <200807241817.m6OIHTM7010761@fruitcake.ICSI.Berkeley.EDU> Message-ID: <200808130408.m7D482qV022369@fruitcake.ICSI.Berkeley.EDU> For the record, the patch is committed to CVS: 1.90 +4 -3; commitid: 70d348a2093141a7; xorp/mld6igmp/mld6igmp_vif.cc Pavlin > Tushar, > > Were you able to verify whether the patch actually fixes the > problem. > > Thanks, > Pavlin > > Pavlin Radoslavov wrote: > > > Tushar Mehta wrote: > > > > > according to rfc-3376: > > > An IGMP report is sent with a valid IP source address for the > > > destination subnet. The 0.0.0.0 source address may be used by a > > > system that has not yet acquired an IP address. Note that the > > > 0.0.0.0 source address may simultaneously be used by multiple systems > > > on a LAN. Routers MUST accept a report with a source address of > > > 0.0.0.0. > > > > > > but in my case it is showing me this error message on the terminal "source > > > must be unicast".... > > > > > > XORP is accepting my IGMPv3 report with source IP address "0.0.0.0". > > ~~~~ > > I guess you meant to say that "XORP is NOT accepting..." > > > > Is the "source must be unicast" error message coming from the FEA or > > IGMP? The beginning of the error message should tell that. > > > > If it is coming from IGMP, please try the included patch (vs latest > > XORP code in CVS) and see whether it fixes the problem. > > > > Note that you must have enabled IGMPv3, because the acceptance of > > 0.0.0.0 is specified only in RFC 3376 (but not in earlier IGMP > > versions). Also, note that RFC 3810 doesn't say anything about IP > > source addresses that are zero, hence this won't apply for MLDv2 > > either. > > > > Pavlin > > > > Index: mld6igmp_vif.cc > > =================================================================== > > RCS file: /usr/local/www/data/cvs/xorp/mld6igmp/mld6igmp_vif.cc,v > > retrieving revision 1.88 > > diff -u -p -r1.88 mld6igmp_vif.cc > > --- mld6igmp_vif.cc 4 Jan 2008 03:16:52 -0000 1.88 > > +++ mld6igmp_vif.cc 22 Jul 2008 19:35:09 -0000 > > @@ -1192,7 +1192,7 @@ Mld6igmpVif::mld6igmp_process(const IPvX > > // > > // Source address check. > > // > > - if (! src.is_unicast()) { > > + if (! (src.is_unicast() || (allow_src_zero_address && src.is_zero()))) { > > // > > // Source address must always be unicast. > > // The kernel should have checked that, but just in case... > > @@ -1216,7 +1216,8 @@ Mld6igmpVif::mld6igmp_process(const IPvX > > src.af(), family()); > > } > > // Source address must be directly connected > > - if (! mld6igmp_node().is_directly_connected(*this, src)) { > > + if (! (mld6igmp_node().is_directly_connected(*this, src) > > + || (allow_src_zero_address && src.is_zero()))) { > > error_msg = c_format("RX %s from %s to %s on vif %s: " > > "source must be directly connected", > > proto_message_type2ascii(message_type), > > _______________________________________________ > > Xorp-users mailing list > > Xorp-users at xorp.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From daniel_ng11 at lycos.com Wed Aug 13 23:22:09 2008 From: daniel_ng11 at lycos.com (Daniel Ng) Date: Thu, 14 Aug 2008 02:22:09 -0400 (EDT) Subject: [Xorp-users] IPv4 Multicast Router on embedded Linux device? Message-ID: <20080814022209.HM.0000000000000E2@daniel_ng11.bos-mail-wwl24.lycos.com> An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080814/1a55c935/attachment.html From daniel.ngq at gmail.com Thu Aug 14 01:01:22 2008 From: daniel.ngq at gmail.com (Daniel ng) Date: Thu, 14 Aug 2008 18:01:22 +1000 Subject: [Xorp-users] Minimal XORP IPv4 Multicast for embedded Linux? Message-ID: <79097fba0808140101n6d83b1ebjc313e863a4409a38@mail.gmail.com> Hi, I'm looking for a reliable IPv4 Multicast Router implementation suitable for an embedded Linux device. Currently, my device runs Linux 2.6.14, with Quagga as its unicast routing engine. Would XORP run on this sort of system? To avoid using too much space, can I choose a minimal subset of the XORP modules to install? I only want IPv4 multicast routing and nothing else ie. no OSPF, no RIP. Would I have any interworking problems between XORP Multicast Routing and Quagga running OSPF/RIP? Currently, my Quagga implementation uses the uClibc mini C libraries. I believe XORP is in C++. Can XORP be compiled against a small version of the C++ libraries? Cheers, Daniel From bms at incunabulum.net Thu Aug 14 04:08:24 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Thu, 14 Aug 2008 12:08:24 +0100 Subject: [Xorp-users] Minimal XORP IPv4 Multicast for embedded Linux? In-Reply-To: <79097fba0808140101n6d83b1ebjc313e863a4409a38@mail.gmail.com> References: <79097fba0808140101n6d83b1ebjc313e863a4409a38@mail.gmail.com> Message-ID: <48A41228.5080506@incunabulum.net> Daniel ng wrote: > Hi, > > I'm looking for a reliable IPv4 Multicast Router implementation > suitable for an embedded Linux device. > > Currently, my device runs Linux 2.6.14, with Quagga as its unicast > routing engine. > > Would XORP run on this sort of system? > It's difficult to say without any details about memory, CPU, architecture etc. At a minimum, 256MB of memory is needed for the LiveCD on x86, although the binaries need to run out of RAM after being faulted-in from CD. It may be possible to squeeze some of XORP into a 64MB RAM footprint although this is dependent on changes to the build system, at the moment we do not support shared linking of XORP libraries for the router processes themselves -- other than system DLLs or 3rd party components. > To avoid using too much space, can I choose a minimal subset of the > XORP modules to install? > I only want IPv4 multicast routing and nothing else ie. no OSPF, no RIP. > What you install is up to you, I would suggest looking at the Windows .nsi installer file to see exactly which binary components are fundamental. > Would I have any interworking problems between XORP Multicast Routing > and Quagga running OSPF/RIP? > There shouldn't be, XORP has undergone some interop tests at UNH; please refer to the website for more details. > Currently, my Quagga implementation uses the uClibc mini C libraries. > I believe XORP is in C++. Can XORP be compiled against a small version > of the C++ libraries? > The only C++ runtime we regularly test against is the GNU libstdc++ runtime, feedback from folk about other libraries would be very welcome. thanks BMS From pavlin at ICSI.Berkeley.EDU Thu Aug 14 10:15:23 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Thu, 14 Aug 2008 10:15:23 -0700 Subject: [Xorp-users] Minimal XORP IPv4 Multicast for embedded Linux? In-Reply-To: <48A41228.5080506@incunabulum.net> References: <79097fba0808140101n6d83b1ebjc313e863a4409a38@mail.gmail.com> <48A41228.5080506@incunabulum.net> Message-ID: <200808141715.m7EHFNPL029675@fruitcake.ICSI.Berkeley.EDU> > > To avoid using too much space, can I choose a minimal subset of the > > XORP modules to install? > > I only want IPv4 multicast routing and nothing else ie. no OSPF, no RIP. > > > > What you install is up to you, I would suggest looking at the Windows > .nsi installer file to see exactly which binary components are fundamental. Off the top of my head, you need the following modules and associated binaries and template files: fea, rib, fib2mrib, rtrmgr, xorpsh, mld6igmp (xorp_igmp for IPv4 only), pim (xorp_pimsm4 for IPv4 only), cli/tools/send_cli_processor_xrl . The pragmatic approach that comes to mind how to select them would to be to compile vanilla XORP and install everything with "gmake install" under /usr/local/xorp . Then remove the directories you don't need (bgp, rip, etc), and the associated template files in etc/templates/ Hope that helps, Pavlin From daniel.ngq at gmail.com Thu Aug 14 17:22:00 2008 From: daniel.ngq at gmail.com (Daniel ng) Date: Fri, 15 Aug 2008 10:22:00 +1000 Subject: [Xorp-users] Minimal XORP IPv4 Multicast for embedded Linux? In-Reply-To: <48A411FD.9070505@icir.org> References: <79097fba0808140101n6d83b1ebjc313e863a4409a38@mail.gmail.com> <48A411FD.9070505@icir.org> Message-ID: <79097fba0808141722t2028f825i782a936c25469c5@mail.gmail.com> On Thu, Aug 14, 2008 at 9:07 PM, Bruce M. Simpson wrote: > It's difficult to say without any details about memory, CPU, architecture > etc. 32MB RAM, 32MB flash, PowerPC ie. not much! Quagga (with its OSPF module) complied against uClibc takes just 1MB of flash and about 2k of RAM. Can XORP with just IPv4 Multicast be shrunk to these sorts of sizes? From bms at incunabulum.net Fri Aug 15 04:26:39 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Fri, 15 Aug 2008 12:26:39 +0100 Subject: [Xorp-users] Minimal XORP IPv4 Multicast for embedded Linux? Message-ID: <48A567EF.7070205@incunabulum.net> Hi, I'm forwarding a message from last year when I did some profiling with Exmap: http://www.berthels.co.uk/exmap/ To clarify: I don't believe that the L2 cache artefacts would have a significant impact, except where the measurable use of C++ runtime symbol binding approaches that of say KDE. The latency you'd have to watch is slow flash read cycles (Nand vs Nor) but I don't think using NAND flash is going to make a big difference here. I only profiled the XORP libraries which are candidates for sharing. I don't think we can reach 1MB for all of XORP, although 4MB-8MB is a more realistic ballpark figure. One of the issues here is that the use of C++ language features such as exceptions and RTTI can increase the size of the binaries due to the code required for call stack trampolines and unwinding etc. We use RTTI in the OSPF and OLSR code, so we're tied to it, although our use of it is limited to dynamic_cast<>. cheers BMS -------------- next part -------------- An embedded message was scrubbed... From: Bruce M Simpson Subject: Shared libraries are a win Date: Sat, 02 Jun 2007 01:08:54 +0100 Size: 2987 Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080815/e1d447c1/attachment.eml From pavlin at ICSI.Berkeley.EDU Fri Aug 15 14:28:06 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Fri, 15 Aug 2008 14:28:06 -0700 Subject: [Xorp-users] Minimal XORP IPv4 Multicast for embedded Linux? In-Reply-To: <79097fba0808141722t2028f825i782a936c25469c5@mail.gmail.com> References: <79097fba0808140101n6d83b1ebjc313e863a4409a38@mail.gmail.com> <48A411FD.9070505@icir.org> <79097fba0808141722t2028f825i782a936c25469c5@mail.gmail.com> Message-ID: <200808152128.m7FLS6eZ028387@fruitcake.ICSI.Berkeley.EDU> Daniel ng wrote: > On Thu, Aug 14, 2008 at 9:07 PM, Bruce M. Simpson wrote: > > It's difficult to say without any details about memory, CPU, architecture > > etc. > > 32MB RAM, 32MB flash, PowerPC ie. not much! > > Quagga (with its OSPF module) complied against uClibc takes just 1MB > of flash and about 2k of RAM. > > Can XORP with just IPv4 Multicast be shrunk to these sorts of sizes? You would have to try and tell us :) By default XORP compiles with debug information enabled, which increases significantly the size. You might want to use: ./configure --enable-optimize --disable-debug --disable-ipv6 gmake clean && gmake After the compilation, you might be able to remove few extra KBs by using "strip" on each executable file you are going to use. Another thing to try is to set CFLAGS and CXXFLAGS environmental variables to, say, "-Os" which will optimize for size. E.g., use the following commands (in csh/tcsh) BEFORE running the above "./configure ..." command: setenv CFLAGS -Os setenv CXXFLAGS -Os Pavlin > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From todd.hayton at gmail.com Mon Aug 18 11:11:06 2008 From: todd.hayton at gmail.com (Todd Hayton) Date: Mon, 18 Aug 2008 14:11:06 -0400 Subject: [Xorp-users] IGMPv3 router implementations Message-ID: <50a66e370808181111l5348e314x5ce778b1e636ec26@mail.gmail.com> Hi there, I've been investigating what router implementations exist for IGMPv3 and came across XORP. I've browsed over the license terms for XORP but (since I'm not a lawyer) I just wanted some clarification - from my reading it sounds like XORP can be used in a commercial, closed source application - is this correct? Also, during my searching I was suprised not to find more existing open-source implementations of the router side of IGMPv3 given that it (IGMPv3) has been out for a number of years now. Other than XORP, the only other one I've come across is this one: http://www.loria.fr/~lahmadi/igmpv3-router.html. It seems like most of the work has gone into implementing only the host portion of IGMPv3 on both Linux and FreeBSD. Are there any other open-source implementations of the router portion IGMPv3 out there? Todd H -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080818/f32084e4/attachment.html From bms at incunabulum.net Mon Aug 18 15:03:07 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Mon, 18 Aug 2008 23:03:07 +0100 Subject: [Xorp-users] IGMPv3 router implementations In-Reply-To: <50a66e370808181111l5348e314x5ce778b1e636ec26@mail.gmail.com> References: <50a66e370808181111l5348e314x5ce778b1e636ec26@mail.gmail.com> Message-ID: <48A9F19B.2090900@incunabulum.net> Todd Hayton wrote: > Hi there, > > I've been investigating what router implementations exist for IGMPv3 > and came across XORP. I've browsed over the license terms for XORP but > (since I'm not a lawyer) I just wanted some clarification - from my > reading it sounds like XORP can be used in a commercial, closed source > application - is this correct? That is more or less correct, however you may wish to consult Atanu Ghosh if you have specific questions about the license. > > Also, during my searching I was suprised not to find more existing > open-source implementations of the router side of IGMPv3 given that it > (IGMPv3) has been out for a number of years now. Other than XORP, the > only other one I've come across is this one: > http://www.loria.fr/~lahmadi/igmpv3-router.html > . It seems like > most of the work has gone into implementing only the host portion of > IGMPv3 on both Linux and FreeBSD. Are there any other open-source > implementations of the router portion IGMPv3 out there? I'm not aware of other open source implementations of router-side IGMPv3, although I believe there was one old Linux snapshot of host-mode support which was bundled with router-mode; probably the one you found; I couldn't reach that URL. The most widely deployed implementation is probably Microsoft Windows, and that is not open-source to my knowledge. thanks BMS From matts at redcondor.com Tue Aug 19 12:37:58 2008 From: matts at redcondor.com (Matt Stevens) Date: Tue, 19 Aug 2008 12:37:58 -0700 Subject: [Xorp-users] 1.5 build problem Message-ID: <48AB2116.2090305@redcondor.com> Hi, I'm trying to build xorp 1.5 on OpenSuSe 10.2 x86-64 - but the build fails with the following: cc1plus: warnings being treated as errors fibconfig_entry_set_netlink_socket.cc: In member function 'int FibConfigEntrySetNetlinkSocket::add_entry(const FteX&)': fibconfig_entry_set_netlink_socket.cc:275: warning: NULL used in arithmetic make[4]: *** [fibconfig_entry_set_netlink_socket.lo] Error 1 make[4]: Leaving directory `/usr/local/src/xorp-1.5/fea/data_plane/fibconfig' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/usr/local/src/xorp-1.5/fea/data_plane' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/src/xorp-1.5/fea' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/xorp-1.5' make: *** [all] Error 2 I'm just doing a ./configure followed by a make - nothing fancy at this point. xorp 1.4 builds fine on the same machine. Has anyone else had issues building 1.5? If there's additional info that would help track down the issue, please let me know and I'll dig it up. Thanks! -- matt From pavlin at ICSI.Berkeley.EDU Tue Aug 19 15:01:03 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Tue, 19 Aug 2008 15:01:03 -0700 Subject: [Xorp-users] 1.5 build problem In-Reply-To: <48AB2116.2090305@redcondor.com> References: <48AB2116.2090305@redcondor.com> Message-ID: <200808192201.m7JM13Eb025378@fruitcake.ICSI.Berkeley.EDU> Matt Stevens wrote: > Hi, > > I'm trying to build xorp 1.5 on OpenSuSe 10.2 x86-64 - but the build > fails with the following: > > cc1plus: warnings being treated as errors > fibconfig_entry_set_netlink_socket.cc: In member function 'int > FibConfigEntrySetNetlinkSocket::add_entry(const FteX&)': > fibconfig_entry_set_netlink_socket.cc:275: warning: NULL used in arithmetic > make[4]: *** [fibconfig_entry_set_netlink_socket.lo] Error 1 > make[4]: Leaving directory > `/usr/local/src/xorp-1.5/fea/data_plane/fibconfig' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory `/usr/local/src/xorp-1.5/fea/data_plane' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/usr/local/src/xorp-1.5/fea' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/usr/local/src/xorp-1.5' > make: *** [all] Error 2 > > I'm just doing a ./configure followed by a make - nothing fancy at this > point. > > xorp 1.4 builds fine on the same machine. > > Has anyone else had issues building 1.5? XORP can build on a number of Linux distributions and other OSs (see BUILD_NOTES), but so far we hadn't tried it on OpenSUSE. Anyway, I just committed a fix to CVS: Revision Changes Path 1.20 +2 -2; commitid: e0648ab36f841a7; xorp/fea/data_plane/fibconfig/fibconfig_entry_set_netlink_socket.cc The fix itself is trivial so if you don't want to use the latest code from anon. CVS, you might want to apply that fix by hand: http://cvsweb.xorp.org/cgi-bin/cvsweb.cgi/xorp/fea/data_plane/fibconfig/fibconfig_entry_set_netlink_socket.cc.diff?r1=1.19;r2=1.20 We are using a variety of gcc compilers, so I am surprised that so far this particular compilation error hasn't been caught by some of them. What C/C++ compiler are you using? I am installing OpenSUSE-11.0-64x86 in background, so hopefully this will help us catch other similar compilation issues. In any case please let us know if you run across some other issues. Pavlin > If there's additional info that would help track down the issue, please > let me know and I'll dig it up. > > Thanks! > -- > matt > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From greearb at candelatech.com Tue Aug 19 15:45:51 2008 From: greearb at candelatech.com (Ben Greear) Date: Tue, 19 Aug 2008 15:45:51 -0700 Subject: [Xorp-users] Multicast problem Message-ID: <48AB4D1F.2090305@candelatech.com> First: This is with a patched xorp and a patched linux kernel to support multiple routing tables, so it could very well be my bug. I have a 3-router scenario, with each router running xorp OSPF and multicast routing. A screen-shot of our virtual-router config tool is attached. Router-1 ends up as the bootstrap, but I'm not sure if that is relevant. If I have a multicast transmitter connected to br1 (an interface in router-1), then mcast receivers on router 2 and 3 receive fine. However, if I put the transmitter on router 2, nothing else receives it. I'm not sure what other information to provide to make this easier to debug, so please ask if there is something that would help. I believe the problem has something to do with the receiver thinking it's upstream interface is register_vif (see router-1 output below the router-2 output). Any idea why it would think that? On router-2 (connected to mcast sender): root at lanforge-nec-demo> show pim join Group Source RP Flags 224.10.20.2 10.2.2.200 10.1.1.1 SG SPT DirectlyConnectedS Upstream interface (S): br2 Upstream interface (RP): 1.2.2 Upstream MRIB next hop (RP): 10.1.2.1 Upstream MRIB next hop (S): UNKNOWN Upstream RPF'(S,G): UNKNOWN Upstream state: Joined Register state: RegisterJoin RegisterCouldRegister Join timer: 33 KAT(S,G) running: true Local receiver include WC: ..... Local receiver include SG: ..... Local receiver exclude SG: ..... Joins RP: ..... Joins WC: ..... Joins SG: ....O Join state: ....O Prune state: ..... Prune pending state: ..... I am assert winner state: ..... I am assert loser state: ..... Assert winner WC: ..... Assert winner SG: ..... Assert lost WC: ..... Assert lost SG: ..... Assert lost SG_RPT: ..... Assert tracking SG: ..O.O Could assert WC: ..... Could assert SG: ....O I am DR: O.O.O Immediate olist RP: ..... Immediate olist WC: ..... Immediate olist SG: ....O Inherited olist SG: ....O Inherited olist SG_RPT: ..... PIM include WC: ..... PIM include SG: ..... PIM exclude SG: ..... root at lanforge-nec-demo> root at lanforge-nec-demo> show pim bootstrap Active zones: BSR Pri LocalAddress Pri State Timeout SZTimeout 10.1.1.1 199 10.2.2.2 198 Candidate 112 -1 Expiring zones: BSR Pri LocalAddress Pri State Timeout SZTimeout Configured zones: BSR Pri LocalAddress Pri State Timeout SZTimeout 10.2.2.2 198 10.2.2.2 198 Init -1 -1 root at lanforge-nec-demo> show pim interface Interface State Mode V PIMstate Priority DRaddr Neighbors 1.2.2 UP Sparse 2 DR 125 10.1.2.2 1 2.3.2 UP Sparse 2 NotDR 125 10.2.3.3 1 br2 UP Sparse 2 DR 125 10.2.2.2 0 my_discard DISABLED Sparse 2 NotDR 1 0.0.0.0 0 register_vif UP Sparse 2 DR 1 10.2.2.2 0 root at lanforge-nec-demo> show pim mfc Group Source RP 224.10.20.2 10.2.2.200 10.1.1.1 Incoming interface : br2 Outgoing interfaces: ....O root at lanforge-nec-demo> show pim mrib DestPrefix NextHopRouter VifName VifIndex MetricPref Metric 10.1.1.0/24 10.1.2.1 1.2.2 0 254 2 10.1.2.0/24 10.1.2.2 1.2.2 0 0 0 10.1.3.0/24 10.1.2.1 1.2.2 0 254 2 10.2.2.0/24 10.2.2.2 br2 2 0 0 10.2.3.0/24 10.2.3.2 2.3.2 1 0 0 10.3.3.0/24 10.2.3.3 2.3.2 1 254 2 root at lanforge-nec-demo> show pim neighbors Interface DRpriority NeighborAddr V Mode Holdtime Timeout 1.2.2 125 10.1.2.1 2 Sparse 105 88 2.3.2 125 10.2.3.3 2 Sparse 105 97 root at lanforge-nec-demo> show pim rps RP Type Pri Holdtime Timeout ActiveGroups GroupPrefix 10.1.1.1 bootstrap 101 150 105 0 224.0.0.0/4 On router 1 (receiver) root at lanforge-nec-demo> show pim join Group Source RP Flags 224.10.20.2 0.0.0.0 10.1.1.1 WC Upstream interface (RP): register_vif Upstream MRIB next hop (RP): UNKNOWN Upstream RPF'(*,G): UNKNOWN Upstream state: Joined Join timer: 57 Local receiver include WC: ..O.. Joins RP: ..... Joins WC: .O... Join state: .O... Prune state: ..... Prune pending state: ..... I am assert winner state: ..... I am assert loser state: ..... Assert winner WC: ..... Assert lost WC: ..... Assert tracking WC: .OO.O Could assert WC: .OO.. I am DR: ..O.O Immediate olist RP: ..... Immediate olist WC: .OO.. Inherited olist SG: .OO.. Inherited olist SG_RPT: .OO.. PIM include WC: ..O.. root at lanforge-nec-demo> show pim rps RP Type Pri Holdtime Timeout ActiveGroups GroupPrefix 10.1.1.1 bootstrap 101 150 -1 1 224.0.0.0/4 root at lanforge-nec-demo> show pim mfc Group Source RP root at lanforge-nec-demo> show pim mrib DestPrefix NextHopRouter VifName VifIndex MetricPref Metric 10.1.1.0/24 10.1.1.1 br1 2 0 0 10.1.2.0/24 10.1.2.1 1.2.1 0 0 0 10.1.3.0/24 10.1.3.1 1.3.1 1 0 0 10.2.2.0/24 10.1.2.2 1.2.1 0 254 2 10.2.3.0/24 10.1.3.3 1.3.1 1 254 2 10.3.3.0/24 10.1.3.3 1.3.1 1 254 2 root at lanforge-nec-demo> show pim neighbors Interface DRpriority NeighborAddr V Mode Holdtime Timeout 1.2.1 125 10.1.2.2 2 Sparse 105 87 1.3.1 125 10.1.3.3 2 Sparse 105 87 root at lanforge-nec-demo> -- Ben Greear Candela Technologies Inc http://www.candelatech.com -------------- next part -------------- A non-text attachment was scrubbed... Name: mcast_3node.png Type: image/png Size: 32982 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080819/cda671b7/attachment-0001.bin From bms at incunabulum.net Wed Aug 20 09:50:55 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Wed, 20 Aug 2008 17:50:55 +0100 Subject: [Xorp-users] Multicast problem In-Reply-To: <48AB4D1F.2090305@candelatech.com> References: <48AB4D1F.2090305@candelatech.com> Message-ID: <48AC4B6F.3090900@incunabulum.net> Are you running fib2mrib? The routers along the path may need to have a route back to the multicast source in order for the traffic to pass the RPF checks. From greearb at candelatech.com Wed Aug 20 10:22:20 2008 From: greearb at candelatech.com (Ben Greear) Date: Wed, 20 Aug 2008 10:22:20 -0700 Subject: [Xorp-users] Multicast problem In-Reply-To: <48AC4B6F.3090900@incunabulum.net> References: <48AB4D1F.2090305@candelatech.com> <48AC4B6F.3090900@incunabulum.net> Message-ID: <48AC52CC.3060703@candelatech.com> Bruce M Simpson wrote: > Are you running fib2mrib? > > The routers along the path may need to have a route back to the > multicast source in order for the traffic to pass the RPF checks. I have this in my config file: fib2mrib { disable: false } Is there a way to check to see if it's actually doing good things in xorpsh? On a more basic level, can you let me know if this is close to how this scenario *should* work: * kernel mcast sends the pkts to the pimreg device, which shows up on the mcast socket in mfea_mrouter. * Some piece of xorp (haven't found what yet) then makes a kernel call to set up the MFC for this particular route. I'm guessing fib2mrib or similar logic must query xorp's understanding of the routing tables to set up the MFC correctly? * After this, the kernel stops sending pkts to the pimreg device and instead sends them directly out the proper kernel interface. I'm going to stare at the code some more now... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From matts at redcondor.com Wed Aug 20 11:04:27 2008 From: matts at redcondor.com (Matt Stevens) Date: Wed, 20 Aug 2008 11:04:27 -0700 Subject: [Xorp-users] Xorp 1.5 can't add multicast vif Message-ID: <48AC5CAB.3070508@redcondor.com> I'm trying to migrate a working config from 1.4 to 1.5, but running into the following problem. 2008/08/20 13:50:11 INFO xorp_fea MFEA ] MFEA started [ 2008/08/20 13:50:11 INFO xorp_fea MFEA ] Interface enabled Vif[eth0] pif_index: 3 vif_index: 0 addr: 208.80.200.6 subnet: 208.80.200.0/24 broadcast: 208.80.200.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED [ 2008/08/20 13:50:11 ERROR xorp_fea:11223 MFEA +1081 mfea_mrouter.cc add_multicast_vif ] add_multicast_vif() failed: IPv4 multicast routing not supported [ 2008/08/20 13:50:11 ERROR xorp_fea:11223 MFEA +1186 mfea_node.cc start_vif ] Cannot start vif eth0: cannot add the multicast vif to the kernel [ 2008/08/20 13:50:11 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfea/0.1/start_vif failed: XrlCmdError 102 Command failed Cannot start vif eth0: cannot add the multicast vif to the kernel [ 2008/08/20 13:50:11 ERROR xorp_rtrmgr:10896 RTRMGR +681 master_conf_tree.cc commit_pass2_done ] Commit failed: 102 Command failed Cannot start vif eth0: cannot add the multicast vif to the kernel This same config works fine on 1.4 - and I've tried starting with a blank config and adding bits in. As soon as I configure my plumbing things go south... My running kernel is 2.6.18.8-0.10 -- matt From bms at incunabulum.net Wed Aug 20 11:32:39 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Wed, 20 Aug 2008 19:32:39 +0100 Subject: [Xorp-users] Multicast problem In-Reply-To: <48AC52CC.3060703@candelatech.com> References: <48AB4D1F.2090305@candelatech.com> <48AC4B6F.3090900@incunabulum.net> <48AC52CC.3060703@candelatech.com> Message-ID: <48AC6347.5020302@incunabulum.net> Ben Greear wrote: > ... > Is there a way to check to see if it's actually doing good things > in xorpsh? > show route table ipv4 multicast fib2mrib ...should tell you. > > On a more basic level, can you let me know if this is close to how > this scenario *should* work: > > * kernel mcast sends the pkts to the pimreg device, which shows up on > the mcast socket in mfea_mrouter. > > * Some piece of xorp (haven't found what yet) then makes a kernel > call to set up the MFC for this particular route. The interaction with the multicast FIB happens in the MFEA (which is now mostly merged with the FEA). libmrt might also be worth a look. > > > I'm guessing fib2mrib or similar logic must query xorp's understanding > of the routing tables to set up the MFC correctly? fib2mrib takes the unicast FIB contents and puts it into the multicast RIB, so that RPF checks can happen on each interface when a channel is brought up in PIM. Otherwise we'd have a situation where traffic could be forwarded back across the same interface twice, resulting in a packet explosion. Normally the RPF checks happen in kernel using interface indexes as the key. > > * After this, the kernel stops sending pkts to the pimreg device and > instead > sends them directly out the proper kernel interface. That's correct, once the REGISTER goes upstream to the RP, the MFC should be set up. From greearb at candelatech.com Wed Aug 20 12:20:41 2008 From: greearb at candelatech.com (Ben Greear) Date: Wed, 20 Aug 2008 12:20:41 -0700 Subject: [Xorp-users] Multicast problem In-Reply-To: <48AC6347.5020302@incunabulum.net> References: <48AB4D1F.2090305@candelatech.com> <48AC4B6F.3090900@incunabulum.net> <48AC52CC.3060703@candelatech.com> <48AC6347.5020302@incunabulum.net> Message-ID: <48AC6E89.8000403@candelatech.com> Bruce M Simpson wrote: > Ben Greear wrote: >> ... >> Is there a way to check to see if it's actually doing good things >> in xorpsh? > > > show route table ipv4 multicast fib2mrib > > ...should tell you. > >> >> On a more basic level, can you let me know if this is close to how >> this scenario *should* work: >> >> * kernel mcast sends the pkts to the pimreg device, which shows up on >> the mcast socket in mfea_mrouter. >> >> * Some piece of xorp (haven't found what yet) then makes a kernel >> call to set up the MFC for this particular route. > > The interaction with the multicast FIB happens in the MFEA (which is now > mostly merged with the FEA). libmrt might also be worth a look. > >> >> >> I'm guessing fib2mrib or similar logic must query xorp's understanding >> of the routing tables to set up the MFC correctly? > > fib2mrib takes the unicast FIB contents and puts it into the multicast > RIB, so that RPF checks can happen on each interface when a channel is > brought up in PIM. > > Otherwise we'd have a situation where traffic could be forwarded back > across the same interface twice, resulting in a packet explosion. > > Normally the RPF checks happen in kernel using interface indexes as the > key. I see the whole-pkt being sent to the PIMSM_4 module..do you happen to know the method that handles this message? I want to start tracing that code next... As far as I can tell, the fib2mrib routes look right, though I didn't verify every route... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at ICSI.Berkeley.EDU Wed Aug 20 13:53:53 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Wed, 20 Aug 2008 13:53:53 -0700 Subject: [Xorp-users] Xorp 1.5 can't add multicast vif In-Reply-To: <48AC5CAB.3070508@redcondor.com> References: <48AC5CAB.3070508@redcondor.com> Message-ID: <200808202053.m7KKrral022894@fruitcake.ICSI.Berkeley.EDU> Matt Stevens wrote: > I'm trying to migrate a working config from 1.4 to 1.5, but running into > the following problem. I guess you are running the latest code from anon. CVS. Accidentally this morning I found exactly same problem, so I am working on it right now. FYI, the problem is in the ./configure mechanism that discovers whether multicast routing is supported. Few days ago I probably broke it for older Linux kernels while trying to get it working for the latest 2.6.26 kernel. Pavlin > 2008/08/20 13:50:11 INFO xorp_fea MFEA ] MFEA started > [ 2008/08/20 13:50:11 INFO xorp_fea MFEA ] Interface enabled Vif[eth0] > pif_index: 3 vif_index: 0 addr: 208.80.200.6 subnet: 208.80.200.0/24 > broadcast: 208.80.200.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST > UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED > [ 2008/08/20 13:50:11 ERROR xorp_fea:11223 MFEA +1081 mfea_mrouter.cc > add_multicast_vif ] add_multicast_vif() failed: IPv4 multicast routing > not supported > [ 2008/08/20 13:50:11 ERROR xorp_fea:11223 MFEA +1186 mfea_node.cc > start_vif ] Cannot start vif eth0: cannot add the multicast vif to the > kernel > [ 2008/08/20 13:50:11 WARNING xorp_fea XrlMfeaTarget ] Handling method > for mfea/0.1/start_vif failed: XrlCmdError 102 Command failed Cannot > start vif eth0: cannot add the multicast vif to the kernel > [ 2008/08/20 13:50:11 ERROR xorp_rtrmgr:10896 RTRMGR +681 > master_conf_tree.cc commit_pass2_done ] Commit failed: 102 Command > failed Cannot start vif eth0: cannot add the multicast vif to the kernel > > This same config works fine on 1.4 - and I've tried starting with a > blank config and adding bits in. As soon as I configure my plumbing > things go south... > > My running kernel is 2.6.18.8-0.10 > -- > matt > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From matts at redcondor.com Wed Aug 20 13:57:25 2008 From: matts at redcondor.com (Matt Stevens) Date: Wed, 20 Aug 2008 13:57:25 -0700 Subject: [Xorp-users] Xorp 1.5 can't add multicast vif In-Reply-To: <200808202053.m7KKrral022894@fruitcake.ICSI.Berkeley.EDU> References: <48AC5CAB.3070508@redcondor.com> <200808202053.m7KKrral022894@fruitcake.ICSI.Berkeley.EDU> Message-ID: <48AC8535.8030008@redcondor.com> Pavlin Radoslavov wrote: > Matt Stevens wrote: > >> I'm trying to migrate a working config from 1.4 to 1.5, but running into >> the following problem. > > I guess you are running the latest code from anon. CVS. > Accidentally this morning I found exactly same problem, > so I am working on it right now. > FYI, the problem is in the ./configure mechanism that > discovers whether multicast routing is supported. > Few days ago I probably broke it for older Linux kernels while > trying to get it working for the latest 2.6.26 kernel. > > Pavlin > >> 2008/08/20 13:50:11 INFO xorp_fea MFEA ] MFEA started >> [ 2008/08/20 13:50:11 INFO xorp_fea MFEA ] Interface enabled Vif[eth0] >> pif_index: 3 vif_index: 0 addr: 208.80.200.6 subnet: 208.80.200.0/24 >> broadcast: 208.80.200.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST >> UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED >> [ 2008/08/20 13:50:11 ERROR xorp_fea:11223 MFEA +1081 mfea_mrouter.cc >> add_multicast_vif ] add_multicast_vif() failed: IPv4 multicast routing >> not supported >> [ 2008/08/20 13:50:11 ERROR xorp_fea:11223 MFEA +1186 mfea_node.cc >> start_vif ] Cannot start vif eth0: cannot add the multicast vif to the >> kernel >> [ 2008/08/20 13:50:11 WARNING xorp_fea XrlMfeaTarget ] Handling method >> for mfea/0.1/start_vif failed: XrlCmdError 102 Command failed Cannot >> start vif eth0: cannot add the multicast vif to the kernel >> [ 2008/08/20 13:50:11 ERROR xorp_rtrmgr:10896 RTRMGR +681 >> master_conf_tree.cc commit_pass2_done ] Commit failed: 102 Command >> failed Cannot start vif eth0: cannot add the multicast vif to the kernel >> >> This same config works fine on 1.4 - and I've tried starting with a >> blank config and adding bits in. As soon as I configure my plumbing >> things go south... >> >> My running kernel is 2.6.18.8-0.10 >> -- >> matt >> >> _______________________________________________ >> Xorp-users mailing list >> Xorp-users at xorp.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > Yeah. I picked up the cvs version for the build issue we talked about yesterday. Sounds like I need to apply the patch you sent to the 1.5 release instead of using cvs :-) Thanks for letting me know before I spent too long chasing things! -- matt From greearb at candelatech.com Wed Aug 20 14:33:52 2008 From: greearb at candelatech.com (Ben Greear) Date: Wed, 20 Aug 2008 14:33:52 -0700 Subject: [Xorp-users] Multicast problem In-Reply-To: <48AC6347.5020302@incunabulum.net> References: <48AB4D1F.2090305@candelatech.com> <48AC4B6F.3090900@incunabulum.net> <48AC52CC.3060703@candelatech.com> <48AC6347.5020302@incunabulum.net> Message-ID: <48AC8DC0.1090607@candelatech.com> After more digging, I think I *might* know the problem. While stracing the fea, I see this call: sendmsg(69, {msg_name(16)={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("10.1.1.1")}, msg_iov(1)=[{"E\0\0048\0\0\0\0 at g\0\0\n\1\2\2\n\1\1\1!\0\336\377\0\0\0\0E\0\4\34"..., 1080}], msg_controllen=0, msg_flags=MSG_OOB|MSG_DONTROUTE|MSG_PEEK|MSG_CTRUNC|MSG_PROXY|MSG_EOR|MSG_WAITALL|MSG_TRUNC|MSG_ERRQUEUE|MSG_DONTWAIT|MSG_CONFIRM|MSG_FIN|MSG_SYN|MSG_RST|MSG_NOSIGNAL|MSG_MORE|0xffff0000}, 0) = 1080 This appears to be the PIM register message. The interesting thing to me is that msg_flags has a huge number of flags set. I can't find anywhere that these flags are cleared in the io_ip_socket.cc, but it would seem to me that they should probably be cleared at the first part of the IoIpSocket::send_packet method. In particular, the MSG_DONTWAIT flag is probably causing my particular problem. I'm going to experiment with clearing msg_flags, but please let me know if that is being ignored for a reason. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Wed Aug 20 15:20:15 2008 From: greearb at candelatech.com (Ben Greear) Date: Wed, 20 Aug 2008 15:20:15 -0700 Subject: [Xorp-users] Multicast problem In-Reply-To: <48AC6347.5020302@incunabulum.net> References: <48AB4D1F.2090305@candelatech.com> <48AC4B6F.3090900@incunabulum.net> <48AC52CC.3060703@candelatech.com> <48AC6347.5020302@incunabulum.net> Message-ID: <48AC989F.6040606@candelatech.com> Bruce M Simpson wrote: >> * After this, the kernel stops sending pkts to the pimreg device and >> instead >> sends them directly out the proper kernel interface. > > That's correct, once the REGISTER goes upstream to the RP, the MFC > should be set up. I sort of have it working now. The final thing was to explicitly bind the fea's raw IP socket to a local IP so that the kernel would pay attention to my routing table logic. I wouldn't expect to have to do this, and will be poking at the kernel raw-ip routing logic. What I see now is each packet going through xorp and being sent upstream as a PIM Register packet. It seems the MFC is never updated and the latency is horrible. I'll see if I can figure out why MFC is not being setup next... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Wed Aug 20 16:38:40 2008 From: greearb at candelatech.com (Ben Greear) Date: Wed, 20 Aug 2008 16:38:40 -0700 Subject: [Xorp-users] Multicast problem In-Reply-To: <48AC989F.6040606@candelatech.com> References: <48AB4D1F.2090305@candelatech.com> <48AC4B6F.3090900@incunabulum.net> <48AC52CC.3060703@candelatech.com> <48AC6347.5020302@incunabulum.net> <48AC989F.6040606@candelatech.com> Message-ID: <48ACAB00.4040206@candelatech.com> Ok, the MFC was being set up, but it seems xorp continues to receive and transmit packets. I'm thinking I don't really know how multicast routing is supposed to work :) So, I think it's all working proper now. The only problem I found that might bother normal xorp users is the lack of resetting the msghdr flags. The socket binding problem probably only affects users like me who are using multiple routing tables, and it would *appear* that this might be a kernel bug anyway. Thanks for listening to me spew :) Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at ICSI.Berkeley.EDU Wed Aug 20 20:00:51 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Wed, 20 Aug 2008 20:00:51 -0700 Subject: [Xorp-users] Xorp 1.5 can't add multicast vif In-Reply-To: <48AC8535.8030008@redcondor.com> References: <48AC5CAB.3070508@redcondor.com> <200808202053.m7KKrral022894@fruitcake.ICSI.Berkeley.EDU> <48AC8535.8030008@redcondor.com> Message-ID: <200808210300.m7L30p9p023593@fruitcake.ICSI.Berkeley.EDU> For the record, I just committed the fix to CVS: Revision Changes Path 1.13 +16 -8; commitid: 619348acd86d41a7; xorp/config/acipmrt.m4 1.295 +13 -5; commitid: 619348acd86d41a7; xorp/configure Please let me know if it works for you (assuming you are still using the code from CVS ;) Pavlin Matt Stevens wrote: > Pavlin Radoslavov wrote: > > Matt Stevens wrote: > > > >> I'm trying to migrate a working config from 1.4 to 1.5, but running into > >> the following problem. > > > > I guess you are running the latest code from anon. CVS. > > Accidentally this morning I found exactly same problem, > > so I am working on it right now. > > FYI, the problem is in the ./configure mechanism that > > discovers whether multicast routing is supported. > > Few days ago I probably broke it for older Linux kernels while > > trying to get it working for the latest 2.6.26 kernel. > > > > Pavlin > > > >> 2008/08/20 13:50:11 INFO xorp_fea MFEA ] MFEA started > >> [ 2008/08/20 13:50:11 INFO xorp_fea MFEA ] Interface enabled Vif[eth0] > >> pif_index: 3 vif_index: 0 addr: 208.80.200.6 subnet: 208.80.200.0/24 > >> broadcast: 208.80.200.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST > >> UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED > >> [ 2008/08/20 13:50:11 ERROR xorp_fea:11223 MFEA +1081 mfea_mrouter.cc > >> add_multicast_vif ] add_multicast_vif() failed: IPv4 multicast routing > >> not supported > >> [ 2008/08/20 13:50:11 ERROR xorp_fea:11223 MFEA +1186 mfea_node.cc > >> start_vif ] Cannot start vif eth0: cannot add the multicast vif to the > >> kernel > >> [ 2008/08/20 13:50:11 WARNING xorp_fea XrlMfeaTarget ] Handling method > >> for mfea/0.1/start_vif failed: XrlCmdError 102 Command failed Cannot > >> start vif eth0: cannot add the multicast vif to the kernel > >> [ 2008/08/20 13:50:11 ERROR xorp_rtrmgr:10896 RTRMGR +681 > >> master_conf_tree.cc commit_pass2_done ] Commit failed: 102 Command > >> failed Cannot start vif eth0: cannot add the multicast vif to the kernel > >> > >> This same config works fine on 1.4 - and I've tried starting with a > >> blank config and adding bits in. As soon as I configure my plumbing > >> things go south... > >> > >> My running kernel is 2.6.18.8-0.10 > >> -- > >> matt > >> > >> _______________________________________________ > >> Xorp-users mailing list > >> Xorp-users at xorp.org > >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > > > Yeah. I picked up the cvs version for the build issue we talked about > yesterday. > > Sounds like I need to apply the patch you sent to the 1.5 release > instead of using cvs :-) > > Thanks for letting me know before I spent too long chasing things! > -- > matt > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at ICSI.Berkeley.EDU Wed Aug 20 20:48:58 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Wed, 20 Aug 2008 20:48:58 -0700 Subject: [Xorp-users] Multicast problem In-Reply-To: <48ACAB00.4040206@candelatech.com> References: <48AB4D1F.2090305@candelatech.com> <48AC4B6F.3090900@incunabulum.net> <48AC52CC.3060703@candelatech.com> <48AC6347.5020302@incunabulum.net> <48AC989F.6040606@candelatech.com> <48ACAB00.4040206@candelatech.com> Message-ID: <200808210348.m7L3mxY3027464@fruitcake.ICSI.Berkeley.EDU> Ben Greear wrote: > Ok, the MFC was being set up, but it seems xorp continues to > receive and transmit packets. I'm thinking I don't really know > how multicast routing is supposed to work :) Yes, this is how PIM-SM is suppose to work. The sender's multicast data packets are encapsulated in PIM Register messages by the DR (Designated Router) for the sender's subnet, and then are unicast to the RP. On Linux the encapsulation happens in user-space (in the XORP PIM-SM process); on BSD the IPv4 encapsulation can happen in kernel (IPv6 BSD doesn't have the kernel support to do that). The user-space data encapsulation is probably the reason for the long latency you were seeing. However, if the RP sends source-specific (S,G) toward the DR, then the multicast data packets will be forwarded natively (without the PIM Register encapsulation overhead). In XORP you can control when the RP sends the DR by using the following configuration inside the pimsm4 or pimsm6 block: switch-to-spt-threshold { /* approx. 1K bytes/s (10Kbps) threshold */ disable: false interval: 100 bytes: 102400 } If you set "bytes" to 0 for example, then the RP should send the (S,G) Join right after the first PIM Register for that socket is received by the RP. In your case where performance is critical you might want to set "bytes" to 0. > So, I think it's all working proper now. > > The only problem I found that might bother normal xorp users is the > lack of resetting the msghdr flags. I don't think this is necessary, because the msghdr.msg_flags are used only to return flags by recvmsg(2), and are not used by sendmsg(2). E.g., see: UNIX Network Programming W. R. Stevens et al, Volume 1, 3rd Edition, pp 390-391 Regards, Pavlin > The socket binding problem probably only affects users like me > who are using multiple routing tables, and it would *appear* that > this might be a kernel bug anyway. > > Thanks for listening to me spew :) > > Ben > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From greearb at candelatech.com Wed Aug 20 22:05:52 2008 From: greearb at candelatech.com (Ben Greear) Date: Wed, 20 Aug 2008 22:05:52 -0700 Subject: [Xorp-users] Multicast problem In-Reply-To: <200808210348.m7L3mxY3027464@fruitcake.ICSI.Berkeley.EDU> References: <48AB4D1F.2090305@candelatech.com> <48AC4B6F.3090900@incunabulum.net> <48AC52CC.3060703@candelatech.com> <48AC6347.5020302@incunabulum.net> <48AC989F.6040606@candelatech.com> <48ACAB00.4040206@candelatech.com> <200808210348.m7L3mxY3027464@fruitcake.ICSI.Berkeley.EDU> Message-ID: <48ACF7B0.6050703@candelatech.com> Pavlin Radoslavov wrote: > Ben Greear wrote: > > >> Ok, the MFC was being set up, but it seems xorp continues to >> receive and transmit packets. I'm thinking I don't really know >> how multicast routing is supposed to work :) >> > > Yes, this is how PIM-SM is suppose to work. > The sender's multicast data packets are encapsulated in PIM Register > messages by the DR (Designated Router) for the sender's subnet, > and then are unicast to the RP. On Linux the encapsulation happens > in user-space (in the XORP PIM-SM process); on BSD the IPv4 > encapsulation can happen in kernel (IPv6 BSD doesn't have the kernel > support to do that). > The user-space data encapsulation is probably the reason for the > long latency you were seeing. > > However, if the RP sends source-specific (S,G) toward the DR, then > the multicast data packets will be forwarded natively (without the > PIM Register encapsulation overhead). > In XORP you can control when the RP sends the DR by using the > following configuration inside the pimsm4 or pimsm6 block: > > switch-to-spt-threshold { > /* approx. 1K bytes/s (10Kbps) threshold */ > disable: false > interval: 100 > bytes: 102400 > } > > If you set "bytes" to 0 for example, then the RP should send the > (S,G) Join right after the first PIM Register for that socket is > received by the RP. In your case where performance is critical > you might want to set "bytes" to 0. > What is the benefit of setting it to something larger than 0 ? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at ICSI.Berkeley.EDU Thu Aug 21 00:26:56 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Thu, 21 Aug 2008 00:26:56 -0700 Subject: [Xorp-users] Multicast problem In-Reply-To: <48ACF7B0.6050703@candelatech.com> References: <48AB4D1F.2090305@candelatech.com> <48AC4B6F.3090900@incunabulum.net> <48AC52CC.3060703@candelatech.com> <48AC6347.5020302@incunabulum.net> <48AC989F.6040606@candelatech.com> <48ACAB00.4040206@candelatech.com> <200808210348.m7L3mxY3027464@fruitcake.ICSI.Berkeley.EDU> <48ACF7B0.6050703@candelatech.com> Message-ID: <200808210726.m7L7QuHN017513@fruitcake.ICSI.Berkeley.EDU> Ben Greear wrote: > > However, if the RP sends source-specific (S,G) toward the DR, then > > the multicast data packets will be forwarded natively (without the > > PIM Register encapsulation overhead). > > In XORP you can control when the RP sends the DR by using the > > following configuration inside the pimsm4 or pimsm6 block: > > > > switch-to-spt-threshold { > > /* approx. 1K bytes/s (10Kbps) threshold */ > > disable: false > > interval: 100 > > bytes: 102400 > > } > > > > If you set "bytes" to 0 for example, then the RP should send the > > (S,G) Join right after the first PIM Register for that socket is > > received by the RP. In your case where performance is critical > > you might want to set "bytes" to 0. > > > What is the benefit of setting it to something larger than 0 ? If the sender's data traffic is very low bandwidth for example. E.g., if the sender transmits a packet every few minutes, the (S,G) control overhead (the periodic Join messages, routing and forwarding entries) is too much. Pavlin From f.rodriguez at lancaster.ac.uk Thu Aug 21 02:41:49 2008 From: f.rodriguez at lancaster.ac.uk (Francisco Rodriguez) Date: Thu, 21 Aug 2008 10:41:49 +0100 Subject: [Xorp-users] Multiple XORP routers question Message-ID: <001b01c90372$226f89e0$c5e05894@lancs.local> Hi, Quick question, can XORP-1.5 be instatiated several times to create multiple routers in the same PC by just changing its enviroment variable "XORP_FINDER_SERVER_PORT="? Or do I need to use a different XORP version? Cheers, Francisco -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080821/dc45b2dd/attachment.html From greearb at candelatech.com Thu Aug 21 08:14:27 2008 From: greearb at candelatech.com (Ben Greear) Date: Thu, 21 Aug 2008 08:14:27 -0700 Subject: [Xorp-users] Multiple XORP routers question In-Reply-To: <001b01c90372$226f89e0$c5e05894@lancs.local> References: <001b01c90372$226f89e0$c5e05894@lancs.local> Message-ID: <48AD8653.3010902@candelatech.com> Francisco Rodriguez wrote: > > Hi, > > Quick question, can XORP-1.5 be instatiated several times to create > multiple routers in the same PC by just changing its enviroment > variable ?XORP_FINDER_SERVER_PORT=?? Or do I need to use a > different XORP version? > > Cheers, > > Francisco > It works, but if you want them to be independent, you have to use different routing table IDs and probably also do some clever policy-based routing rules so that pkts coming in interfaces associated with a particular router use that routing table. What I mention only works on Linux as far as I know. Thanks, Ben > ------------------------------------------------------------------------ > > _______________________________________________ > 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 f.rodriguez at lancaster.ac.uk Thu Aug 21 12:56:14 2008 From: f.rodriguez at lancaster.ac.uk (f.rodriguez at lancaster.ac.uk) Date: Thu, 21 Aug 2008 20:56:14 +0100 (BST) Subject: [Xorp-users] Multiple XORP routers question In-Reply-To: <48AD8653.3010902@candelatech.com> References: <001b01c90372$226f89e0$c5e05894@lancs.local> <48AD8653.3010902@candelatech.com> Message-ID: <52081.88.104.153.211.1219348574.squirrel@webmail01.lancs.ac.uk> Thanks for the answer Ben. If this is the case, then let me restate my question: Does XORP-1.5 comes with table id support in order to run multiple XORP instances in the same PC? I know, from previous e-mails in xorp's mail lists, that there was a CVS version of XORP-1.4. that do support routing table ID in order to run multiple XORP instances in the same PC. I'm looking to run multiple XORP instances in a Debian Linux box, not really looking forward for Windows support. Cheers, Francisco On Thu, 21 August, 2008 4:14 pm, Ben Greear wrote: > Francisco Rodriguez wrote: > >> >> Hi, >> >> >> Quick question, can XORP-1.5 be instatiated several times to create >> multiple routers in the same PC by just changing its enviroment variable >> �XORP_FINDER_SERVER_PORT=�? Or do I need to use a >> different XORP version? >> >> Cheers, >> >> >> Francisco >> >> > It works, but if you want them to be independent, you have to use > different routing table IDs and probably also do some clever policy-based > routing rules so that pkts coming in interfaces associated with a > particular router use that routing table. > > What I mention only works on Linux as far as I know. > > > Thanks, > Ben > > >> ----------------------------------------------------------------------- >> - >> >> >> _______________________________________________ >> 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 greearb at candelatech.com Thu Aug 21 13:51:08 2008 From: greearb at candelatech.com (Ben Greear) Date: Thu, 21 Aug 2008 13:51:08 -0700 Subject: [Xorp-users] Multiple XORP routers question In-Reply-To: <52081.88.104.153.211.1219348574.squirrel@webmail01.lancs.ac.uk> References: <001b01c90372$226f89e0$c5e05894@lancs.local> <48AD8653.3010902@candelatech.com> <52081.88.104.153.211.1219348574.squirrel@webmail01.lancs.ac.uk> Message-ID: <48ADD53C.9020406@candelatech.com> f.rodriguez at lancaster.ac.uk wrote: > Thanks for the answer Ben. If this is the case, then let me restate my > question: > Does XORP-1.5 comes with table id support in order to run multiple XORP > instances in the same PC? > > I know, from previous e-mails in xorp's mail lists, that there was a CVS > version of XORP-1.4. that do support routing table ID in order to run > multiple XORP instances in the same PC. I'm looking to run multiple XORP > instances in a Debian Linux box, not really looking forward for Windows > support. Yes, standard xorp should work. The user-guide has info on how to set the table ids. I have some optimizations for this type of thing in my own xorp repo if you want to try it. I mostly track cvs head, but currently this is based a few patches after the 1.5 Xorp release. git clone dmz1.candelatech.com:/pub/scm/xorp.git Take it easy, Ben > > Cheers, > Francisco > > On Thu, 21 August, 2008 4:14 pm, Ben Greear wrote: >> Francisco Rodriguez wrote: >> >>> Hi, >>> >>> >>> Quick question, can XORP-1.5 be instatiated several times to create >>> multiple routers in the same PC by just changing its enviroment variable >>> �XORP_FINDER_SERVER_PORT=�? Or do I need to use a >>> different XORP version? >>> >>> Cheers, >>> >>> >>> Francisco >>> >>> >> It works, but if you want them to be independent, you have to use >> different routing table IDs and probably also do some clever policy-based >> routing rules so that pkts coming in interfaces associated with a >> particular router use that routing table. >> >> What I mention only works on Linux as far as I know. >> >> >> Thanks, >> Ben >> >> >>> ----------------------------------------------------------------------- >>> - >>> >>> >>> _______________________________________________ >>> 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 From lcd15000 at gmail.com Wed Aug 27 21:21:35 2008 From: lcd15000 at gmail.com (Jay T) Date: Thu, 28 Aug 2008 00:21:35 -0400 Subject: [Xorp-users] xorp_rtrmgr start at boot? Message-ID: <196b100808272121q53ec5adbi44959cd7c52a4056@mail.gmail.com> how does xorp_rtrmgr start at boot on the live cd, i cant figure out how to do this from a freebsd install, my distro is freebsd 7.0, i installed xorp from "pkg_add -r xorp" from a minimal freebsd 7.0 install... everything works fine when in run the following command "/usr/local/bin/xorp_rtrmgr" but it will not start by default when the machine boots :( -- -Jay- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080828/8f8e653b/attachment.html From bms at incunabulum.net Thu Aug 28 03:36:56 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Thu, 28 Aug 2008 11:36:56 +0100 Subject: [Xorp-users] xorp_rtrmgr start at boot? In-Reply-To: <196b100808272121q53ec5adbi44959cd7c52a4056@mail.gmail.com> References: <196b100808272121q53ec5adbi44959cd7c52a4056@mail.gmail.com> Message-ID: <48B67FC8.9060009@incunabulum.net> Jay T wrote: > how does xorp_rtrmgr start at boot on the live cd, i cant figure out > how to do this from a freebsd install, my distro is freebsd 7.0, i > installed xorp from "pkg_add -r xorp" from a minimal freebsd 7.0 > install... everything works fine when in run the following command > "/usr/local/bin/xorp_rtrmgr" but it will not start by default when the > machine boots :( In the port's pkg-install script there are a bunch of messages printed which summarize what has to be done to bring up xorp_rtrmgr at boot. I'll repeat that again here: * You also have to add defaultrouter="NO" and xorp_enable="YES" to your /etc/rc.conf. * You must create a working configuration file in ${PREFIX}/etc/xorp.conf otherwise the router manager won't start. The LiveCD does some menu configuration to create this file by default. * PREFIX is almost always /usr/local, though it's only a symlink on the LiveCD. thanks BMS From dbellomo at cdc.unrc.edu.ar Thu Aug 28 06:43:11 2008 From: dbellomo at cdc.unrc.edu.ar (Daniel Bellomo) Date: Thu, 28 Aug 2008 10:43:11 -0300 Subject: [Xorp-users] xorp_rtrmgr start at boot? In-Reply-To: <48B67FC8.9060009@incunabulum.net> References: <196b100808272121q53ec5adbi44959cd7c52a4056@mail.gmail.com> <48B67FC8.9060009@incunabulum.net> Message-ID: <20080828134311.GB67383@quimey.lab.cdc.unrc.edu.ar> On Thu, Aug 28, 2008 at 11:36:56AM +0100, Bruce M Simpson wrote: > > * You also have to add defaultrouter="NO" and xorp_enable="YES" to your > /etc/rc.conf. > > * You must create a working configuration file in > ${PREFIX}/etc/xorp.conf otherwise the router manager won't start. The > LiveCD does some menu configuration to create this file by default. you can set other configuration file: from /etc/rc.conf: # XORP defaultrouter="NO" xorp_enable="YES" xorp_config_boot="/path/your-xorp.conf" Regards, Daniel. From lcd15000 at gmail.com Thu Aug 28 09:50:24 2008 From: lcd15000 at gmail.com (Jay T) Date: Thu, 28 Aug 2008 12:50:24 -0400 Subject: [Xorp-users] xorp_rtrmgr start at boot? In-Reply-To: <20080828134311.GB67383@quimey.lab.cdc.unrc.edu.ar> References: <196b100808272121q53ec5adbi44959cd7c52a4056@mail.gmail.com> <48B67FC8.9060009@incunabulum.net> <20080828134311.GB67383@quimey.lab.cdc.unrc.edu.ar> Message-ID: <196b100808280950p620b6333t1b2dce31ae55f4df@mail.gmail.com> thanks guys, i did add those entries to the rc.conf , but it was in /usr/local/etc/rc.conf but i made the proper changes and it works like a charm now, thanks for the help... On Thu, Aug 28, 2008 at 9:43 AM, Daniel Bellomo wrote: > On Thu, Aug 28, 2008 at 11:36:56AM +0100, Bruce M Simpson wrote: > > > > * You also have to add defaultrouter="NO" and xorp_enable="YES" to your > > /etc/rc.conf. > > > > * You must create a working configuration file in > > ${PREFIX}/etc/xorp.conf otherwise the router manager won't start. The > > LiveCD does some menu configuration to create this file by default. > > you can set other configuration file: > > from /etc/rc.conf: > > # XORP > defaultrouter="NO" > xorp_enable="YES" > xorp_config_boot="/path/your-xorp.conf" > > Regards, > Daniel. > -- -Jay- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080828/5a17c550/attachment.html