From dave.price@aber.ac.uk Thu Jul 8 15:45:04 2004 From: dave.price@aber.ac.uk (Dave Price) Date: Thu, 08 Jul 2004 15:45:04 +0100 Subject: [Xorp-users] Problems with "priviledged instruction fault" and 1.0RC Message-ID: <17557.1089297904@aber.ac.uk> Dear All, I've just made a 1.0 RC LiveCD and and attempted to boot it on a PII-MMX 350 with 3384K ram which I have managed to srounge and added 4 ethernet interfaces. During the process of booting, a message "Timecounter "i8254" frequency 1193182 Hz appears and then I get Fatal Trap 1: privileged instruction fault while in kernel mode and then lots of detailed contents of registers etc. Any suggestions anyone?? Dave Price --------------------------------------------------------- | David Price, Computer Science | | | | Computer Science, University of Wales, Aberystwyth, | | Penglais Campus, Aberystwyth, Ceredigion, SY23 3DB | | | | Email: dap@aber.ac.uk WWW: http://www.aber.ac.uk/~dap | | Phone: +44 1970 622428 FAX: +44 1970 622455 | --------------------------------------------------------- From adam@hiddennet.net Thu Jul 8 16:32:08 2004 From: adam@hiddennet.net (adam@hiddennet.net) Date: Thu, 8 Jul 2004 16:32:08 +0100 (BST) Subject: [Xorp-users] Problems with 'priviledged instruction fault' and 1.0RC In-Reply-To: <17557.1089297904@aber.ac.uk> References: <17557.1089297904@aber.ac.uk> Message-ID: <53566.213.121.161.106.1089300728.squirrel@213.121.161.106> A quick check to see where the problem might lie is to get hold of one of the recent FreeBSD 4.8/4.9/4.10 install CDs and check that this boots on the machine in question as the Xorp live cd is based on freebsd. I can't quite remember which version though, if you manage to see the version number whilst the Xorp LiveCD is booting pick that version and try that. Mark is the best person to answer this question, but he is at a conference today and tomorrow and so may not reply. Not sure this helps much, but at least it may start the debugging process. Adam > Dear All, > > I've just made a 1.0 RC LiveCD and and attempted to boot > it on a PII-MMX 350 with 3384K ram which I have managed to srounge and > added > 4 ethernet interfaces. > > During the process of booting, a message > "Timecounter "i8254" frequency 1193182 Hz > > appears and then I get > > Fatal Trap 1: privileged instruction fault while in kernel mode > > and then lots of detailed contents of registers etc. > > Any suggestions anyone?? > > Dave Price > --------------------------------------------------------- > | David Price, Computer Science | > | | > | Computer Science, University of Wales, Aberystwyth, | > | Penglais Campus, Aberystwyth, Ceredigion, SY23 3DB | > | | > | Email: dap@aber.ac.uk WWW: http://www.aber.ac.uk/~dap | > | Phone: +44 1970 622428 FAX: +44 1970 622455 | > --------------------------------------------------------- > > > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > From adam@hiddennet.net Thu Jul 8 18:21:39 2004 From: adam@hiddennet.net (Adam Greenhalgh) Date: Thu, 08 Jul 2004 18:21:39 +0100 Subject: [Xorp-users] Problems with 'priviledged instruction fault' and 1.0RC In-Reply-To: <17732.1089302084@aber.ac.uk> References: <17732.1089302084@aber.ac.uk> Message-ID: <1089305354.12064.2.camel@cellini.cs.ucl.ac.uk> No sorry, my FreeBSD knowledge isn't up to speed at the moment so I'm not sure what would cause it to only detect 3 out of the 4 cards. The other xorp guys might know. Perhaps one thing worth trying is to find out is, is the 4th card not being detected because it is broken or has an interupt clash etc or because there is a limit on the number of interfaces. I know the xorp test bed machines have 9 interfaces, but I can't remember if they did anything special with them (they are not rtl8139's ). sorry I can't be much more help. Adam On Thu, 2004-07-08 at 16:54, Dave Price wrote: > Dear Adam, > > > adam@hiddennet.net said: > > A quick check to see where the problem might lie is to get hold of one > > of the recent FreeBSD 4.8/4.9/4.10 install CDs and check that this > > boots on the machine in question as the Xorp live cd is based on > > freebsd. I can't quite remember which version though, if you manage to > > see the version number whilst the Xorp LiveCD is booting pick that > > version and try that. > > Thanks for reply. It looks like the machine did not really want to run > at 350 Mhz, its had soft CPU setting, the defaulty for which turned out > to be 233 so I set to that and faults went away. > > Now though, it only seems to want to spot three of my ethernet cards, > not all four. They have a rtl8139d chip on them. It spots rl0, rl1 and rl2 > but no more. Any ideas?? > > I'm also having trouble with floppy drive... but I expect that is hardware > related so I plan to swap that with another (I already tried two others > but they were completely dead....). > > Dave Price > > > From dave.price@aber.ac.uk Thu Jul 8 18:50:36 2004 From: dave.price@aber.ac.uk (Dave Price) Date: Thu, 08 Jul 2004 18:50:36 +0100 Subject: [Xorp-users] Problems with 'priviledged instruction fault' and 1.0RC In-Reply-To: Your message of Thu, 08 Jul 2004 18:21:39 +0100. <1089305354.12064.2.camel@cellini.cs.ucl.ac.uk> Message-ID: <17966.1089309036@aber.ac.uk> Dear Adam, adam@hiddennet.net said: > No sorry, my FreeBSD knowledge isn't up to speed at the moment so I'm > not sure what would cause it to only detect 3 out of the 4 cards. The > other xorp guys might know. Perhaps one thing worth trying is to find > out is, is the 4th card not being detected because it is broken or has > an interupt clash etc or because there is a limit on the number of > interfaces. I know the xorp test bed machines have 9 interfaces, but I > can't remember if they did anything special with them (they are not > rtl8139's ). Thanks for that. The "interrupts" issue is one I was thinking aboput myself. I notice that one of the cards had the same interrupt allocated as a "multimedia" card and a serial i/o card. I removed the multimedia card, but problem remained. I'll try to see if I can manually moved interrupts around in the bios or whatever. Dave From bms@spc.org Thu Jul 8 20:40:08 2004 From: bms@spc.org (Bruce M Simpson) Date: Thu, 8 Jul 2004 20:40:08 +0100 Subject: [Xorp-users] Problems with "priviledged instruction fault" and 1.0RC In-Reply-To: <17557.1089297904@aber.ac.uk> References: <17557.1089297904@aber.ac.uk> Message-ID: <20040708194008.GD15368@empiric.dek.spc.org> On Thu, Jul 08, 2004 at 03:45:04PM +0100, Dave Price wrote: > I've just made a 1.0 RC LiveCD and and attempted to boot > it on a PII-MMX 350 with 3384K ram which I have managed to srounge and added ^^^^^ 3.3MB? Can you re-check the amount of memory in the machine? Is the memory in this machine known good and working? 16MB is what I'd regard as a bare minimum for FreeBSD these days. > During the process of booting, a message > "Timecounter "i8254" frequency 1193182 Hz > appears and then I get > Fatal Trap 1: privileged instruction fault while in kernel mode There is a problem of some kind but not enough information to diagnose it. The suggestions by others on this list to try booting a regular FreeBSD 4.9 CD, or even FreeSBIE, are most helpful here. > and then lots of detailed contents of registers etc. Can you post the traceback in full to me off-list? You may need to use a serial console and null-modem cable to get this info, please see: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serialconsole-setup.html Regards, BMS From bms@spc.org Thu Jul 8 21:23:21 2004 From: bms@spc.org (Bruce M Simpson) Date: Thu, 8 Jul 2004 21:23:21 +0100 Subject: [Xorp-users] Problems with 'priviledged instruction fault' and 1.0RC In-Reply-To: <1089305354.12064.2.camel@cellini.cs.ucl.ac.uk> References: <17732.1089302084@aber.ac.uk> <1089305354.12064.2.camel@cellini.cs.ucl.ac.uk> Message-ID: <20040708202321.GJ15368@empiric.dek.spc.org> On Thu, Jul 08, 2004 at 06:21:39PM +0100, Adam Greenhalgh wrote: > > Thanks for reply. It looks like the machine did not really want to run > > at 350 Mhz, its had soft CPU setting, the defaulty for which turned out > > to be 233 so I set to that and faults went away. Overclocking and FreeBSD often don't mix. > > Now though, it only seems to want to spot three of my ethernet cards, > > not all four. They have a rtl8139d chip on them. It spots rl0, rl1 and rl2 > > but no more. Any ideas?? The most likely scenario I can think of here is that the fourth rl(4) card is not in a bus-master capable slot. Many motherboards have such a limitation in that only a finite number of slots are connected to the PCI bus arbiter with the necessary signalling in place for bus mastering. The rl(4) driver should share interrupts without problems, as it isn't marked as INTR_FAST, but it's entirely possible there is a PCI routing problem with your BIOS. I'd suggest using a tool such as pirtool to check what the PCI routing is (available from my website): http://www.incunabulum.com/code/projects/pci/freebsd/pirtool/ ..although much of this information should be printed if you boot FreeBSD in bootverbose mode (boot -v at the loader's 'ok' prompt). Regards, BMS From dap@aber.ac.uk Thu Jul 8 16:54:44 2004 From: dap@aber.ac.uk (Dave Price) Date: Thu, 08 Jul 2004 16:54:44 +0100 Subject: [Xorp-users] Problems with 'priviledged instruction fault' and 1.0RC In-Reply-To: Your message of Thu, 08 Jul 2004 16:32:08 +0100. <53566.213.121.161.106.1089300728.squirrel@213.121.161.106> Message-ID: <17732.1089302084@aber.ac.uk> Dear Adam, adam@hiddennet.net said: > A quick check to see where the problem might lie is to get hold of one > of the recent FreeBSD 4.8/4.9/4.10 install CDs and check that this > boots on the machine in question as the Xorp live cd is based on > freebsd. I can't quite remember which version though, if you manage to > see the version number whilst the Xorp LiveCD is booting pick that > version and try that. Thanks for reply. It looks like the machine did not really want to run at 350 Mhz, its had soft CPU setting, the defaulty for which turned out to be 233 so I set to that and faults went away. Now though, it only seems to want to spot three of my ethernet cards, not all four. They have a rtl8139d chip on them. It spots rl0, rl1 and rl2 but no more. Any ideas?? I'm also having trouble with floppy drive... but I expect that is hardware related so I plan to swap that with another (I already tried two others but they were completely dead....). Dave Price From jcmendes@int.gov.br Thu Jul 8 18:25:29 2004 From: jcmendes@int.gov.br (=?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?=) Date: Thu, 08 Jul 2004 14:25:29 -0300 Subject: [Xorp-users] Trouble compiling in FreeBSD 4.10-stable Message-ID: <40ED8389.4080806@int.gov.br> I have just updated xorp sources from CVS. The compile machine is a FreeBSD-4-stable, very up-to-date. ... g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -O2 -pipe -W -Wall -Wwrite-strings - Wcast-qual -Werror -Wpointer-arith -Wcast-align -Wstrict-prototypes -Woverloaded -virtual -Wnon-const-format -Wtraditional -ftemplate-depth-20 -c -o route_table_nhlookup.o `test -f route_table_nhlookup.cc || echo './'`route_table_nhlookup.cc cc1plus: warnings being treated as errors route_table_nhlookup.cc: In method `int NhLookupTable::delete_route(const InternalMessage &, BGPRouteTable *)': route_table_nhlookup.cc:396: instantiated from here route_table_nhlookup.cc:264: warning: `bool dont_send_delete' might be used uninitialized in this function route_table_nhlookup.cc: In method `int NhLookupTable::delete_route(const InternalMessage &, BGPRouteTable *)': route_table_nhlookup.cc:397: instantiated from here route_table_nhlookup.cc:264: warning: `bool dont_send_delete' might be used uninitialized in this function gmake[3]: *** [route_table_nhlookup.o] Error 1 gmake[3]: Leaving directory `/usr/home/users/jonny/tmp/xorp/cvs/xorp/bgp' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/usr/home/users/jonny/tmp/xorp/cvs/xorp/bgp' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/home/users/jonny/tmp/xorp/cvs/xorp' gmake: *** [all] Error 2 Now it is compiling without -Werror, but this takes looooooong... From atanu@ICSI.Berkeley.EDU Fri Jul 9 01:19:06 2004 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Thu, 08 Jul 2004 17:19:06 -0700 Subject: [Xorp-users] Trouble compiling in FreeBSD 4.10-stable In-Reply-To: Message from =?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?= of "Thu, 08 Jul 2004 14:25:29 -0300." <40ED8389.4080806@int.gov.br> Message-ID: <80798.1089332346@tigger.icir.org> Which g++ compiler are you using (g++ -v)? We normally build with: gcc version 2.95.4 20020320 [FreeBSD] gcc version 3.3.4 20040322 (prerelease) [FreeBSD] gcc version 3.4.0 20040310 (prerelease) [FreeBSD] Atanu. >>>>> "Joćo" == Joćo Carlos Mendes Luķs writes: Joćo> I have just updated xorp sources from CVS. The compile machine is a Joćo> FreeBSD-4-stable, very up-to-date. Joćo> ... Joćo> g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -O2 -pipe -W -Wall -Wwrite-strings - Joćo> Wcast-qual -Werror -Wpointer-arith -Wcast-align -Wstrict-prototypes -Woverloaded Joćo> -virtual -Wnon-const-format -Wtraditional -ftemplate-depth-20 -c -o Joćo> route_table_nhlookup.o `test -f route_table_nhlookup.cc || echo Joćo> './'`route_table_nhlookup.cc Joćo> cc1plus: warnings being treated as errors Joćo> route_table_nhlookup.cc: In method `int Joćo> NhLookupTable::delete_route(const InternalMessage &, Joćo> BGPRouteTable *)': Joćo> route_table_nhlookup.cc:396: instantiated from here Joćo> route_table_nhlookup.cc:264: warning: `bool dont_send_delete' might be Joćo> used uninitialized in this function Joćo> route_table_nhlookup.cc: In method `int Joćo> NhLookupTable::delete_route(const InternalMessage &, Joćo> BGPRouteTable *)': Joćo> route_table_nhlookup.cc:397: instantiated from here Joćo> route_table_nhlookup.cc:264: warning: `bool dont_send_delete' might be Joćo> used uninitialized in this function Joćo> gmake[3]: *** [route_table_nhlookup.o] Error 1 Joćo> gmake[3]: Leaving directory `/usr/home/users/jonny/tmp/xorp/cvs/xorp/bgp' Joćo> gmake[2]: *** [all-recursive] Error 1 Joćo> gmake[2]: Leaving directory `/usr/home/users/jonny/tmp/xorp/cvs/xorp/bgp' Joćo> gmake[1]: *** [all-recursive] Error 1 Joćo> gmake[1]: Leaving directory `/usr/home/users/jonny/tmp/xorp/cvs/xorp' Joćo> gmake: *** [all] Error 2 Joćo> Now it is compiling without -Werror, but this takes looooooong... Joćo> _______________________________________________ Joćo> Xorp-users mailing list Joćo> Xorp-users@xorp.org Joćo> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From atanu@ICSI.Berkeley.EDU Fri Jul 9 01:30:55 2004 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Thu, 08 Jul 2004 17:30:55 -0700 Subject: [Xorp-users] Problems with 'priviledged instruction fault' and 1.0RC In-Reply-To: Message from Dave Price of "Thu, 08 Jul 2004 16:54:44 BST." <17732.1089302084@aber.ac.uk> Message-ID: <83749.1089333055@tigger.icir.org> >>>>> "Dave" == Dave Price writes: Dave> Dear Adam, adam@hiddennet.net said: >> A quick check to see where the problem might lie is to get hold >> of one of the recent FreeBSD 4.8/4.9/4.10 install CDs and check >> that this boots on the machine in question as the Xorp live cd is >> based on freebsd. I can't quite remember which version though, if >> you manage to see the version number whilst the Xorp LiveCD is >> booting pick that version and try that. Dave> I'm also having trouble with floppy drive... but I expect that Dave> is hardware related so I plan to swap that with another (I Dave> already tried two others but they were completely dead....). The Live CD will work without a floppy drive. The floppy is only required for saving the configuration. Atanu. From jonny@jonny.eng.br Fri Jul 9 02:42:49 2004 From: jonny@jonny.eng.br (=?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?=) Date: Thu, 08 Jul 2004 22:42:49 -0300 Subject: [Xorp-users] Trouble compiling in FreeBSD 4.10-stable In-Reply-To: <80798.1089332346@tigger.icir.org> References: <80798.1089332346@tigger.icir.org> Message-ID: <40EDF819.4050105@jonny.eng.br> oma::jonny pim [557] gcc -v Using builtin specs. gcc version 2.95.4 20020320 [FreeBSD] roma::jonny pim [558] uname -a FreeBSD roma.coe.ufrj.br 4.10-BETA FreeBSD 4.10-BETA #4: Fri Apr 16 03:25:06 BRT 2004 jonny@roma.coe.ufrj.br:/usr/cvsup/RELENG_4/src/sys/compile/ROMA i386 roma::jonny pim [559] Atanu Ghosh wrote: > Which g++ compiler are you using (g++ -v)? > > We normally build with: > gcc version 2.95.4 20020320 [FreeBSD] > gcc version 3.3.4 20040322 (prerelease) [FreeBSD] > gcc version 3.4.0 20040310 (prerelease) [FreeBSD] > > Atanu. > > >>>>>>"Joćo" == Joćo Carlos Mendes Luķs writes: > > > Joćo> I have just updated xorp sources from CVS. The compile machine is a > Joćo> FreeBSD-4-stable, very up-to-date. > > Joćo> ... > Joćo> g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -O2 -pipe -W -Wall -Wwrite-strings - > Joćo> Wcast-qual -Werror -Wpointer-arith -Wcast-align -Wstrict-prototypes -Woverloaded > Joćo> -virtual -Wnon-const-format -Wtraditional -ftemplate-depth-20 -c -o > Joćo> route_table_nhlookup.o `test -f route_table_nhlookup.cc || echo > Joćo> './'`route_table_nhlookup.cc > Joćo> cc1plus: warnings being treated as errors > Joćo> route_table_nhlookup.cc: In method `int > Joćo> NhLookupTable::delete_route(const InternalMessage &, > Joćo> BGPRouteTable *)': > Joćo> route_table_nhlookup.cc:396: instantiated from here > Joćo> route_table_nhlookup.cc:264: warning: `bool dont_send_delete' might be > Joćo> used uninitialized in this function > Joćo> route_table_nhlookup.cc: In method `int > Joćo> NhLookupTable::delete_route(const InternalMessage &, > Joćo> BGPRouteTable *)': > Joćo> route_table_nhlookup.cc:397: instantiated from here > Joćo> route_table_nhlookup.cc:264: warning: `bool dont_send_delete' might be > Joćo> used uninitialized in this function > Joćo> gmake[3]: *** [route_table_nhlookup.o] Error 1 > Joćo> gmake[3]: Leaving directory `/usr/home/users/jonny/tmp/xorp/cvs/xorp/bgp' > Joćo> gmake[2]: *** [all-recursive] Error 1 > Joćo> gmake[2]: Leaving directory `/usr/home/users/jonny/tmp/xorp/cvs/xorp/bgp' > Joćo> gmake[1]: *** [all-recursive] Error 1 > Joćo> gmake[1]: Leaving directory `/usr/home/users/jonny/tmp/xorp/cvs/xorp' > Joćo> gmake: *** [all] Error 2 > > Joćo> Now it is compiling without -Werror, but this takes looooooong... > > Joćo> _______________________________________________ > Joćo> Xorp-users mailing list > Joćo> Xorp-users@xorp.org > Joćo> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users -- Jonny -- Joćo Carlos Mendes Luķs - Networking Engineer - jonny@jonny.eng.br From atanu@ICSI.Berkeley.EDU Fri Jul 9 04:36:31 2004 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Thu, 08 Jul 2004 20:36:31 -0700 Subject: [Xorp-users] Trouble compiling in FreeBSD 4.10-stable In-Reply-To: Message from =?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?= of "Thu, 08 Jul 2004 22:42:49 -0300." <40EDF819.4050105@jonny.eng.br> Message-ID: <35018.1089344191@tigger.icir.org> We have managed to reproduce the problem. It seems the compiler warning is generated when the optimizer is used. We haven't been testing with the '--enable-optimize' option to configure. We will be now:-(. Thanks for reporting this problem. Atanu. >>>>> "Joćo" == Joćo Carlos Mendes Luķs writes: Joćo> oma::jonny pim [557] gcc -v Joćo> Using builtin specs. Joćo> gcc version 2.95.4 20020320 [FreeBSD] Joćo> roma::jonny pim [558] uname -a Joćo> FreeBSD roma.coe.ufrj.br 4.10-BETA FreeBSD 4.10-BETA #4: Fri Apr 16 Joćo> 03:25:06 BRT 2004 Joćo> jonny@roma.coe.ufrj.br:/usr/cvsup/RELENG_4/src/sys/compile/ROMA i386 Joćo> roma::jonny pim [559] Joćo> Atanu Ghosh wrote: >> Which g++ compiler are you using (g++ -v)? >> We normally build with: >> gcc version 2.95.4 20020320 [FreeBSD] >> gcc version 3.3.4 20040322 (prerelease) [FreeBSD] >> gcc version 3.4.0 20040310 (prerelease) [FreeBSD] >> Atanu. >> >>>>>>> "Joćo" == Joćo Carlos Mendes Luķs writes: >> Joćo> I have just updated xorp sources from CVS. The compile >> machine is a >> Joćo> FreeBSD-4-stable, very up-to-date. >> Joćo> ... >> Joćo> g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -O2 -pipe -W -Wall -Wwrite-strings - >> Joćo> Wcast-qual -Werror -Wpointer-arith -Wcast-align -Wstrict-prototypes -Woverloaded >> Joćo> -virtual -Wnon-const-format -Wtraditional -ftemplate-depth-20 -c -o >> Joćo> route_table_nhlookup.o `test -f route_table_nhlookup.cc || echo >> Joćo> './'`route_table_nhlookup.cc >> Joćo> cc1plus: warnings being treated as errors >> Joćo> route_table_nhlookup.cc: In method `int >> Joćo> NhLookupTable::delete_route(const InternalMessage &, >> Joćo> BGPRouteTable *)': >> Joćo> route_table_nhlookup.cc:396: instantiated from here >> Joćo> route_table_nhlookup.cc:264: warning: `bool dont_send_delete' might be >> Joćo> used uninitialized in this function >> Joćo> route_table_nhlookup.cc: In method `int >> Joćo> NhLookupTable::delete_route(const InternalMessage &, >> Joćo> BGPRouteTable *)': >> Joćo> route_table_nhlookup.cc:397: instantiated from here >> Joćo> route_table_nhlookup.cc:264: warning: `bool dont_send_delete' might be >> Joćo> used uninitialized in this function >> Joćo> gmake[3]: *** [route_table_nhlookup.o] Error 1 >> Joćo> gmake[3]: Leaving directory `/usr/home/users/jonny/tmp/xorp/cvs/xorp/bgp' >> Joćo> gmake[2]: *** [all-recursive] Error 1 >> Joćo> gmake[2]: Leaving directory `/usr/home/users/jonny/tmp/xorp/cvs/xorp/bgp' >> Joćo> gmake[1]: *** [all-recursive] Error 1 >> Joćo> gmake[1]: Leaving directory `/usr/home/users/jonny/tmp/xorp/cvs/xorp' >> Joćo> gmake: *** [all] Error 2 >> Joćo> Now it is compiling without -Werror, but this takes >> looooooong... >> Joćo> _______________________________________________ >> Joćo> Xorp-users mailing list >> Joćo> Xorp-users@xorp.org >> Joćo> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users >> _______________________________________________ >> Xorp-users mailing list >> Xorp-users@xorp.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users Joćo> -- Joćo> Jonny Joćo> -- Joćo> Joćo Carlos Mendes Luķs - Networking Engineer - jonny@jonny.eng.br From atanu@ICSI.Berkeley.EDU Fri Jul 9 08:08:48 2004 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Fri, 09 Jul 2004 00:08:48 -0700 Subject: [Xorp-users] Announcing XORP Release 1.0 Message-ID: <98501.1089356928@tigger.icir.org> On behalf of the entire XORP team, I'm delighted to announce the XORP 1.0 Release, which is now available from . The XORP router is now totally configurable through the XORP shell (xorpsh). A quick start guide is available from . Please note that a XORP Live CD is also available. This is a bootable CD that allows you to experiment with XORP without having to build or install it. There are still a number of non-critical bugs that we know about which will not be addressed until the 1.1 release; these are documented in the errata section below. In general, to test XORP, we run automated regression tests on a daily basis with various operating systems and compilers. We also run a number of PCs as XORP routers. We have enabled as many protocols as feasible on those routers to test protocol interactions (for example a BGP IPv6 multicast feed being used by PIM-SM). In addition, automated scripts are run to externally toggle BGP peerings. Finally, we have automated scripts that interact directly with the xorpsh to change the configuration settings. We have put significant effort into testing but obviously we have not found all the problems. This is where you can help us to make XORP more stable, by downloading and using it! As always we'd welcome your comments - xorp-users@xorp.org is the right place for general discussion, and private feedback to the XORP core team can be sent to feedback@xorp.org. - The XORP Team P.S. Release notes and errata are included below. ------------------------------------------------------------------ XORP RELEASE NOTES Release 1.0 (2004/07/08) ========================= ALL: - All the routing processes can now be started and configured via the RTRMGR/XORPSH. LIBXORP: - Addition of support for safe callbacks (e.g., if an object is destroyed, all callbacks that refer to that object are invalidated). LIBXIPC: - Addition of support for event notification if the status of a target changes. LIBFEACLIENT: - Few bug fixes. XRL: - No significant changes. RTRMGR: - Addition of new command-line option "-v" to print verbose information. - Removal of command-line option "-d" that prints default information, because the same information is printed with the "-h" flag. - Addition of support for explicit configuration of the XRL target name of a module. - Addition of support for %help command in the rtrmgr template files. - Addition of support for new methods per module: "startup_method" and "shutdown_method". - Numerous other improvements and bug fixes. XORPSH: - Addition of new command-line option "-v" to print verbose information. - Removal of command-line option "-d" that prints default information, because the same information is printed with the "-h" flag. - Addition of support for help string in the xorpsh operational commands template files. - Addition of support for positional arguments in the xorpsh operational commands template files. - Addition of support to interrupt an operational command. Now if a command is interrupted from the command line by typing Ctrl-C, then the executed binary command itself (and its forked children, if any) is killed. - Numerous other improvements and bug fixes. FEA/MFEA: - Addition of support for propagating the Forwarding Information Base from the underlying system to clients interested in that information. - Addition of support for opening TCP or UDP sockets via the FEA. - Modification to the MFEA to use "libfeaclient" to obtain the interface information from the FEA. - Numerious bug fixes. RIB: - Addition of support for redistributing routes between two internal tables. - Addition of support for obtaining routes directly from some of the internal tables. - Modification to the RIB to use "libfeaclient" to obtain the interface information from the FEA. - Modification to the RIB to use the new RedistTable to propagate the final routes to the FEA and anyone else interested (e.g., PIM-SM). - Few bug fixes. RIP: - Packet forwarding and reception via FEA written for RIPv2 and RIPng. RIPv2 should be usable. BGP: - IPv6 has now been tested with peerings to the 6Bone; unicast and multicast SAFIs. - Route origination is now possible from BGP. - The memory leaks from the previous release have been found and fixed. STATIC_ROUTES: - This is a new module for configuring static routes to the unicast or multicast RIB. MLD/IGMP: - During startup, a primary address is selected per configured interface, and this primary address should be the link-local unicast address of that interface. - New CLI commands: "show igmp interface address" and "show mld interface address" - Resend some of the XRLs (e.g., those who do not carry soft-state such as protocol control messages) if there is an error. - Few bug fixes. PIM-SM: - Updated to support the lastest PIM-SM specification (draft-ietf-pim-sm-v2-new-09.{ps,txt}). - Addition of support for "alternative subnet" configuration such that non-local senders appear as senders connected to the same subnet. It is needed as a work-around solution when there are uni-directional interfaces for sending and receiving traffic (e.g., satellite links). - During startup, a primary address and a domain-wide address are selected per configured interface. The primary address should be the link-local unicast address of that interface, and the domain-wide address should be a domain-wide reachable unicast address. - Resend some of the XRLs (e.g., those who do not carry soft-state such as protocol control messages) if there is an error. - Several bug fixes. FIB2MRIB: - This is a new module for propagating the unicast forwarding information obtained from the underlying system via the FEA to the multicast RIB. CLI: - Addition of support to propagate command interruption (e.g., Ctrl-C) from the CLI to the object that handles the command processing by calling a pre-defined callback. - During startup, if the input is a terminal (e.g., xorpsh), then read the terminal size instead of using the default values. - A bug fix related to the CLI paging output: now it can handle properly lines that are longer than the width of the CLI output terminal. - Several other bug fixes. SNMP: - No significant changes. ------------------------------------------------------------------ XORP ERRATA ALL: - Parallel building (e.g., "gmake -j 4") may fail on multi-CPU machines. The simplest work-around is to rerun gmake or not to use the -j flag. - Building with the optimizer ("./configure --enable-optimize") will cause the build to fail. The build fails because some warnings are generated by the compiler and we treat warnings as fatal. This problem was discovered too late to be fixed for this release. LIBXORP: - No known issues. LIBXIPC: - No known issues. LIBFEACLIENT: - No known issues. XRL: - No known issues. RTRMGR: - There are several known issues, but none of them is considered critical. The list of known issues is available from http://www.xorp.org/bugzilla/query.cgi XORPSH: - A problem was noticed very late in the release process; rather than delay the release we have choosen to document the problem. The xorpsh provides the command line to the XORP router. The router configuration is structured as a tree, for instance configuring a new protocol essentially adds a new node to the tree. Removing a protocol involves deleting a node from the tree. In some cases deleting a node does not remove all the associated state; worse putting the same node back seems to fail in the majority of cases. FEA/MFEA: - On Linux, the following error message may appear during graceful shutdown (if PIM-SM is also running): [ 2004/06/09 14:50:40 ERROR xorp_fea:14359 MFEA +1676 mfea_mrouter.cc get_sg_count ] ioctl(SIOCGETSGCNT, (10.10.10.10 224.0.1.20)) failed: Bad file descriptor The error is harmless and can be ignored. - If a vif has been enabled with the startup configuration file, and then is disabled and enabled again via xorpsh, then the enabling will not start the operations on that vif. E.g., the "show mfea interface" xorpsh command will show the vif status as DOWN, and its status cannot be changed to UP. The problem is caused by a mismatch between how the enable/disable state is handled by the rtrmgr and by the MFEA module itself. This will be fixed for XORP Release-1.1. Currently, there is no work-around except that restarting the rtrmgr with all enabled interfaces again. - On Linux with kernel 2.6 (e.g., RedHat FC2 with kernel 2.6.5-1.358), some of the tests may fail (with or without an error message), but no coredump image. Some of those failures can be contributed to a kernel problem. E.g., running "dmesg can show kernel "Oops" messages like: Unable to handle kernel NULL pointer dereference at virtual address 00000000 printing eip: 02235532 *pde = 00000000 Oops: 0000 [#15] CPU: 0 EIP: 0060:[<02235532>] Not tainted EFLAGS: 00010202 (2.6.5-1.358) EIP is at __dev_get_by_index+0x14/0x2b eax: 022db854 ebx: 1ae7aef8 ecx: 00000001 edx: 00000000 esi: 00000000 edi: 00008910 ebp: fee43e9c esp: 1ae7aef0 ds: 007b es: 007b ss: 0068 Process test_finder_eve (pid: 2026, threadinfo=1ae7a000 task=1406d7b0) Stack: 022365c7 00000000 009caffc 009cc780 0969ef28 fee43edc 00000001 009cc780 0969ef28 fee43ed8 00008910 00000000 00008910 fee43e9c 02236e50 fee43e9c 07aa4e00 3530355b 5d303637 00000000 0227a55b 021536b6 022cfa00 00000001 Call Trace: [<022365c7>] dev_ifname+0x30/0x66 [<02236e50>] dev_ioctl+0x83/0x283 [<0227a55b>] unix_create1+0xef/0xf7 [<021536b6>] alloc_inode+0xf9/0x175 [<0227c090>] unix_ioctl+0x72/0x7b [<022301a5>] sock_ioctl+0x268/0x280 [<0223054f>] sys_socket+0x2a/0x3d [<0214ea0e>] sys_ioctl+0x1f2/0x224 Code: 0f 18 02 90 2d 34 01 00 00 39 48 34 74 08 85 d2 89 d0 75 ea This appears to be a kernel bug triggered by ioctl(SIOCGIFNAME) which itself is called by if_indextoname(3). Currently, there is no known solution of the problem except to use a kernel that does not have the problem (at this stage it is not known whether all 2.6 Linux kernels are affected or only specific versions). It seems that a very similar problem has been reported to the Linux kernel developers, but the problem is still unsolved: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121697 RIB: - If an interface address is deleted, the RIB may trigger the following error in the FEA: [ 2004/06/07 16:08:57 ERROR xorp_fea:1605 FEA +259 fticonfig_entry_set_rtsock.cc delete_entry ] error writing to routing socket: No such process [ 2004/06/07 16:08:57 ERROR xorp_fea:1605 FEA +61 fti_transaction.cc operation_result ] FTI transaction commit failed on DeleteEntry4: net = 172.16.124.0/24 gateway = 0.0.0.0 ifname = vifname = metric = 0 admin_distance = 0 xorp_route = false is_deleted = false [ 2004/06/07 16:08:57 ERROR xorp_fea:1605 FEA +259 This error has no side effects, and can be ignored. - In some rare cases, the RIB may fail to delete an existing route (See http://www.xorp.org/bugzilla/show_bug.cgi?id=62). We are aware of the issue and will attempt to fix it in the near future. RIP: - No known issues. BGP: - Once BGP selects a route it is taking too long to install it in the kernel. - If the RIB bug above (failure to delete an existing route) is triggered by BGP, then the deletion failure error received by BGP from the RIB is considered by BGP as a fatal error. This is not a BGP problem, but a RIB problem that will be fixed after the XORP Release-1.0. STATIC_ROUTES: - If the FEA or RIB exit unexpected, then STATIC_ROUTES may start printing lots of error messages. MLD/IGMP: - If MLD/IGMP is started with a relatively large number of interfaces (e.g., on the order of 20), then it may fail with the following error: [ 2004/06/14 12:58:56 ERROR test_pim:16548 MFEA +666 mfea_proto_comm.cc join_multicast_group ] Cannot join group 224.0.0.2 on vif eth8: No buffer space available The solution is to increase the multicast group membership limit. E.g., to increase the value from 20 (the default) to 200, run as a root: echo 200 > /proc/sys/net/ipv4/igmp_max_memberships - If a vif has been enabled with the startup configuration file, and then is disabled and enabled again via xorpsh, then the enabling will not start the operations on that vif. E.g., the "show igmp interface" xorpsh command will show the vif status as DOWN, and its status cannot be changed to UP. The problem is caused by a mismatch between how the enable/disable state is handled by the rtrmgr and by the MLD/IGMP module itself. This will be fixed for XORP Release-1.1. Currently, there is no work-around except that restarting the rtrmgr with all enabled interfaces again. PIM-SM: - If the kernel does not support PIM-SM, or if PIM-SM is not enabled in the kernel, then running PIM-SM will fail with the following error message: [ 2004/06/12 10:26:41 ERROR xorp_fea:444 MFEA +529 mfea_mrouter.cc start_mrt ] setsockopt(MRT_INIT, 1) failed: Operation not supported - On Linux, if the unicast Reverse Path Forwarding information is different from the multicast Reverse Path Forwarding information, the Reverse Path Filtering should be disabled. E.g., as root: echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter OR echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter ... Otherwise, the router will ignore packets if they don't arrive on the reverse-path interface. For more information about Reverse Path Filtering see http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.kernel.rpf.html - If a vif has been enabled with the startup configuration file, and then is disabled and enabled again via xorpsh, then the enabling will not start the operations on that vif. E.g., the "show pim interface" xorpsh command will show the vif status as DOWN, and its status cannot be changed to UP. The problem is caused by a mismatch between how the enable/disable state is handled by the rtrmgr and by the PIM-SM module itself. This will be fixed for XORP Release-1.1. Currently, there is no work-around except that restarting the rtrmgr with all enabled interfaces again. - Very late in the release process a problem was found with scheduling the internal PIM-SM tasks for state dependency tracking. The result of it is that if the router is heavy loaded and if it has lots of multicast routing state, then any change that affects many multicast routing entries (e.g., MRIB changes, etc) in some cases may result in incorrect recomputation of the result multicast routing state. This problem will be fixed in the CVS repository right after the XORP Release-1.0. FIB2MRIB: - If the FEA or RIB exit unexpected, then STATIC_ROUTES may start printing lots of error messages. CLI: - No known issues. SNMP: - On some versions of Linux, there are some bugs in net-snmp versions 5.0.8 and 5.0.9, which prevent dynamic loading from working. See http://www.xorp.org/snmp.html for links to the net-snmp patches that solve the problems. - Version 5.1 of net-snmp requires a simple modification, otherwise XORP will fail to compile. See http://www.xorp.org/snmp.html for a link to the net-snmp patch that solves the problems. ------------------------------------------------------------------ From dave.price@aber.ac.uk Fri Jul 9 09:12:58 2004 From: dave.price@aber.ac.uk (Dave Price) Date: Fri, 09 Jul 2004 09:12:58 +0100 Subject: [Xorp-users] Problems with "priviledged instruction fault" and 1.0RC In-Reply-To: Your message of Thu, 08 Jul 2004 20:40:08 +0100. <20040708194008.GD15368@empiric.dek.spc.org> Message-ID: <18821.1089360778@aber.ac.uk> Dear Bruce, bms@spc.org said: > 3384K ram which I have managed to srounge and added > ^^^^^ 3.3MB? Can you re-check the amount of > memory in the machine? Is the memory in this machine known good and > working? 16MB is what I'd regard as a bare minimum for FreeBSD these > days. typed before thinking on my part.... 384 Mbytes installed.... bms@spc.org said: > Can you post the traceback in full to me off-list? I've got past that now, I dropped CPU speed and all went away. I suspect some memory perhaps not as fast as other chips or some such. My current problems now... 1/. only spots 3 or 4 ethernet cards, I am going to chase use of interrrupts, i/o space etc and see what I can fix 2/. I'm being thick here..... Reading documentation, its not clear to me whether, using LiveCD, I have to set IP addresses of interfaces using ifconfig logged on as root, or whether I can do all of that via xorpsh etc, or am I better editing some config files or.... 3/. I want to be able to use this xorp box in two ways. Once as basically a multicast router, but also as a backup unicast router. We have for a long time (although not actually at the moment) often run two routers in parallel, one set to be our main unicast router and one set to do multicast routing (using mrouted which we of course we have now not used for ages). On the multicast router (which was a multiinterface sun workstation) we artifically increased the metric/cost associated with each interface so as the other router became "preferred" by other machines on our networks, but would get used automatically if the other one failed. Cutting a long tale short, is it fairly easy to set up Xorp to artifically high costs associated with interfaces? We would then run RIP for unicast and PIM-SM etc for multicast... 4/. I've read through the XORP command line interface guide and the Live CD web pages, but I still feel short of knowledge/understanding here. Any pointers to which other document I really should read as opposed to which is internals etc. Thanks, Dave Price From jonny@jonny.eng.br Fri Jul 9 14:52:30 2004 From: jonny@jonny.eng.br (=?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?=) Date: Fri, 09 Jul 2004 10:52:30 -0300 Subject: [Xorp-users] Trouble compiling in FreeBSD 4.10-stable In-Reply-To: <35018.1089344191@tigger.icir.org> References: <35018.1089344191@tigger.icir.org> Message-ID: <40EEA31E.5050200@jonny.eng.br> Atanu Ghosh wrote: > We have managed to reproduce the problem. > > It seems the compiler warning is generated when the optimizer is > used. We haven't been testing with the '--enable-optimize' option to > configure. We will be now:-(. FYI, i used this command line to configure: ./configure --enable-optimize --enable-advanced-mcast-api --without-snmp Do you think it's safe to use -march=i686 -mcpu=i686 in compiler flags? > > Thanks for reporting this problem. > > Atanu. > > >>>>>>"Joćo" == Joćo Carlos Mendes Luķs writes: > > > Joćo> oma::jonny pim [557] gcc -v > Joćo> Using builtin specs. > Joćo> gcc version 2.95.4 20020320 [FreeBSD] > Joćo> roma::jonny pim [558] uname -a > Joćo> FreeBSD roma.coe.ufrj.br 4.10-BETA FreeBSD 4.10-BETA #4: Fri Apr 16 > Joćo> 03:25:06 BRT 2004 > Joćo> jonny@roma.coe.ufrj.br:/usr/cvsup/RELENG_4/src/sys/compile/ROMA i386 > Joćo> roma::jonny pim [559] > > Joćo> Atanu Ghosh wrote: > > >> Which g++ compiler are you using (g++ -v)? > >> We normally build with: > >> gcc version 2.95.4 20020320 [FreeBSD] > >> gcc version 3.3.4 20040322 (prerelease) [FreeBSD] > >> gcc version 3.4.0 20040310 (prerelease) [FreeBSD] > >> Atanu. > >> > >>>>>>> "Joćo" == Joćo Carlos Mendes Luķs writes: > >> Joćo> I have just updated xorp sources from CVS. The compile > >> machine is a > >> Joćo> FreeBSD-4-stable, very up-to-date. > >> Joćo> ... > >> Joćo> g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -O2 -pipe -W -Wall -Wwrite-strings - > >> Joćo> Wcast-qual -Werror -Wpointer-arith -Wcast-align -Wstrict-prototypes -Woverloaded > >> Joćo> -virtual -Wnon-const-format -Wtraditional -ftemplate-depth-20 -c -o > >> Joćo> route_table_nhlookup.o `test -f route_table_nhlookup.cc || echo > >> Joćo> './'`route_table_nhlookup.cc > >> Joćo> cc1plus: warnings being treated as errors > >> Joćo> route_table_nhlookup.cc: In method `int > >> Joćo> NhLookupTable::delete_route(const InternalMessage &, > >> Joćo> BGPRouteTable *)': > >> Joćo> route_table_nhlookup.cc:396: instantiated from here > >> Joćo> route_table_nhlookup.cc:264: warning: `bool dont_send_delete' might be > >> Joćo> used uninitialized in this function > >> Joćo> route_table_nhlookup.cc: In method `int > >> Joćo> NhLookupTable::delete_route(const InternalMessage &, > >> Joćo> BGPRouteTable *)': > >> Joćo> route_table_nhlookup.cc:397: instantiated from here > >> Joćo> route_table_nhlookup.cc:264: warning: `bool dont_send_delete' might be > >> Joćo> used uninitialized in this function > >> Joćo> gmake[3]: *** [route_table_nhlookup.o] Error 1 > >> Joćo> gmake[3]: Leaving directory `/usr/home/users/jonny/tmp/xorp/cvs/xorp/bgp' > >> Joćo> gmake[2]: *** [all-recursive] Error 1 > >> Joćo> gmake[2]: Leaving directory `/usr/home/users/jonny/tmp/xorp/cvs/xorp/bgp' > >> Joćo> gmake[1]: *** [all-recursive] Error 1 > >> Joćo> gmake[1]: Leaving directory `/usr/home/users/jonny/tmp/xorp/cvs/xorp' > >> Joćo> gmake: *** [all] Error 2 > >> Joćo> Now it is compiling without -Werror, but this takes > >> looooooong... > >> Joćo> _______________________________________________ > >> Joćo> Xorp-users mailing list > >> Joćo> Xorp-users@xorp.org > >> Joćo> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > >> _______________________________________________ > >> Xorp-users mailing list > >> Xorp-users@xorp.org > >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > Joćo> -- > > Joćo> Jonny > > Joćo> -- > Joćo> Joćo Carlos Mendes Luķs - Networking Engineer - jonny@jonny.eng.br From atanu@ICSI.Berkeley.EDU Fri Jul 9 16:34:43 2004 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Fri, 09 Jul 2004 08:34:43 -0700 Subject: [Xorp-users] Trouble compiling in FreeBSD 4.10-stable In-Reply-To: Message from =?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?= of "Fri, 09 Jul 2004 10:52:30 -0300." <40EEA31E.5050200@jonny.eng.br> Message-ID: <2529.1089387283@tigger.icir.org> >>>>> "Joćo" == Joćo Carlos Mendes Luķs writes: Joćo> Atanu Ghosh wrote: >> We have managed to reproduce the problem. It seems the compiler >> warning is generated when the optimizer is used. We haven't been >> testing with the '--enable-optimize' option to configure. We will >> be now:-(. Joćo> FYI, i used this command line to configure: Joćo> ./configure --enable-optimize --enable-advanced-mcast-api Joćo> --without-snmp Joćo> Do you think it's safe to use -march=i686 -mcpu=i686 in Joćo> compiler flags? Its not something that we have tried, however I don't see why it wouldn't work. If you try it, I recommend running the regression tests to check for obvious problems. By the way, the error generated when compiling with the optimizer has now been fixed and is in the CVS repository. Unfortunately it didn't make it to the 1.0 Release. Atanu. From jonny@jonny.eng.br Fri Jul 9 16:46:48 2004 From: jonny@jonny.eng.br (=?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?=) Date: Fri, 09 Jul 2004 12:46:48 -0300 Subject: [Xorp-users] PIM support in XORP 1.0 In-Reply-To: <2529.1089387283@tigger.icir.org> References: <2529.1089387283@tigger.icir.org> Message-ID: <40EEBDE8.9030400@jonny.eng.br> Sorry, but I could not find this info anywhere. How good is PIM support in XORP 1.0? Has it already been fully integrated? From atanu@ICSI.Berkeley.EDU Fri Jul 9 17:54:00 2004 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Fri, 09 Jul 2004 09:54:00 -0700 Subject: [Xorp-users] PIM support in XORP 1.0 In-Reply-To: Message from =?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?= of "Fri, 09 Jul 2004 12:46:48 -0300." <40EEBDE8.9030400@jonny.eng.br> Message-ID: <18302.1089392040@tigger.icir.org> Joćo> Sorry, but I could not find this info anywhere. The status information link is hidden on the downloads page. The configuration guide should give you a good idea of what features are supported by PIM . Joćo> How good is PIM support in XORP 1.0? Its difficult for us to make this judgement. Check the PIM section in the ERRATA to see the problems that we are aware of. We have received very positive feedback from people that have tried PIM. Perhaps people on the list could share their experiences? Joćo> Has it already been fully integrated? We have tested feeding BGP multicast routes to PIM. Atanu. From pavlin@icir.org Fri Jul 9 18:31:18 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 09 Jul 2004 10:31:18 -0700 Subject: [Xorp-users] PIM support in XORP 1.0 In-Reply-To: Message from Atanu Ghosh of "Fri, 09 Jul 2004 09:54:00 PDT." <18302.1089392040@tigger.icir.org> Message-ID: <200407091731.i69HVI8U095990@possum.icir.org> > Joćo> Sorry, but I could not find this info anywhere. > > The status information link is hidden > on the downloads page. The > configuration guide should give you a good idea of what features are > supported by PIM > . > > Joćo> How good is PIM support in XORP 1.0? > > Its difficult for us to make this judgement. Check the PIM section in > the ERRATA to see the problems that we are aware of. We have received > very positive feedback from people that have tried PIM. > > Perhaps people on the list could share their experiences? > > Joćo> Has it already been fully integrated? > > We have tested feeding BGP multicast routes to PIM. In addition to Atanu's info I'd like to note that PIM-SM has been integrated with the RIB as well so now for example it can be configured with static multicast-only routes (a feature that many users asked for). However, the RIB integration is true only if you run PIM-SM from the rtrmgr. The pim/test_pim binary that can be used for testing purpose doesn't include yet the RIB. Soon it also will be integrated. Pavlin From pavlin@icir.org Fri Jul 9 19:03:49 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 09 Jul 2004 11:03:49 -0700 Subject: [Xorp-users] Problems with "priviledged instruction fault" and 1.0RC In-Reply-To: Message from Dave Price of "Fri, 09 Jul 2004 09:12:58 BST." <18821.1089360778@aber.ac.uk> Message-ID: <200407091803.i69I3n8U096230@possum.icir.org> > 2/. I'm being thick here..... Reading documentation, its not > clear to me whether, using LiveCD, I have to set IP addresses > of interfaces using ifconfig logged on as root, or whether I can do > all of that via xorpsh etc, or am I better editing some config files or.... You can do it all via xorpsh. Of course, if you want to keep the configuration you created via xorpsh you would have to save it to a file (on a floppy) so the next time when you reboot you don't have to recreate all the configuration again. > 3/. I want to be able to use this xorp box in two ways. Once as basically > a multicast router, but also as a backup unicast router. We have for > a long time (although not actually at the moment) often run two routers in parallel, > one set to be our main unicast router and > one set to do multicast routing (using mrouted which we of course we have now not used for ages). > On the multicast router (which was a multiinterface sun workstation) we artifically > increased the metric/cost associated with each interface so as > the other router became "preferred" by other machines on our networks, > but would get used automatically if the other one failed. Cutting a long tale short, > is it fairly easy to set up Xorp to artifically high costs associated with interfaces? I think the answer is "yes". In the RIP configuration, when you assign addresses per vif, there is a variable called "metric", which by default is "1". According to the xorpsh online help, that metric is used to: "Set the cost metric added to routes received on address." In addition, when you export, say, the connected or static routes in the "export connected" or "export static" RIP configuration section, there is another variable "metric" that can be used to assign the metric for those exported routes. > We would then run RIP for unicast and PIM-SM etc for multicast... > > 4/. I've read through the XORP command line interface guide and the > Live CD web pages, but I still feel short of knowledge/understanding here. > Any pointers to which other document I really should read as opposed > to which is internals etc. >From user's perspective, the "Getting Started" web page, the Live CD web page, the "CLI Manual (PDF)" and "Configuration Guide (PDF)" are the documents you need to read. The "XORP Design Overview" PDF/PS document from the "Design docs" list is useful for high-level overview of the XORP design. Those documents are probably a good starting point, but they are far from being completed. We are continuously trying to improve things so any input or help in improving the documentation is appreciated. Thanks, Pavlin From gernot.schmied@chello.at Sat Jul 10 20:05:20 2004 From: gernot.schmied@chello.at (Gernot W. Schmied) Date: Sat, 10 Jul 2004 21:05:20 +0200 Subject: [Xorp-users] XORP SNMP Support Message-ID: <40F03DF0.7010307@chello.at> Hi, So far I was unable to convince ./configure to work with net-snmp. checking for net-snmp-config... true checking if net-snmp version equal or newer than 5.0.6... yes checking if snmpd can be started... Warning: -l option is deprecated, use -Lf instead yes checking whether C compiler supports flag "-g -O2 -Dlinux -I. -I/usr/local/include"... yes checking for net-snmp/agent/net-snmp-agent-includes.h... no configure: WARNING: File does not appear usable configure: WARNING: XORP MIBs will not be built Any ideas? How relevant is the following statement for net-snmp 5.2 and XORP 1.0? Version 5.1 of net-snmp requires a simple modification, otherwise XORP will fail to compile. A patch that can be applied to a net-snmp-5.1 installation is available here. Regards, Gernot From atanu@ICSI.Berkeley.EDU Sat Jul 10 20:26:19 2004 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Sat, 10 Jul 2004 12:26:19 -0700 Subject: [Xorp-users] XORP SNMP Support In-Reply-To: Message from "Gernot W. Schmied" of "Sat, 10 Jul 2004 21:05:20 +0200." <40F03DF0.7010307@chello.at> Message-ID: <40517.1089487579@tigger.icir.org> As far as I am aware we haven't tried building with net-snmp 5.2. Configure is warning about a missing include file, the patch is not going to solve this problem. We will take a look next week. Atanu. >>>>> "Gernot" == Gernot W Schmied writes: Gernot> Hi, Gernot> So far I was unable to convince ./configure to work with net-snmp. Gernot> checking for net-snmp-config... true Gernot> checking if net-snmp version equal or newer than 5.0.6... yes Gernot> checking if snmpd can be started... Warning: -l option is deprecated, Gernot> use -Lf instead Gernot> yes Gernot> checking whether C compiler supports flag "-g -O2 -Dlinux -I. Gernot> -I/usr/local/include"... yes Gernot> checking for net-snmp/agent/net-snmp-agent-includes.h... no Gernot> configure: WARNING: File does Gernot> not appear usable Gernot> configure: WARNING: XORP MIBs will not be built Gernot> Any ideas? Gernot> How relevant is the following statement for net-snmp 5.2 and XORP 1.0? Gernot> Gernot> Version 5.1 of net-snmp requires a simple modification, otherwise XORP Gernot> will fail to compile. A patch that can be applied to a net-snmp-5.1 Gernot> installation is available here. Gernot> Gernot> Regards, Gernot> Gernot Gernot> _______________________________________________ Gernot> Xorp-users mailing list Gernot> Xorp-users@xorp.org Gernot> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From adam@hiddennet.net Sat Jul 10 20:30:14 2004 From: adam@hiddennet.net (Adam Greenhalgh) Date: Sat, 10 Jul 2004 20:30:14 +0100 Subject: [Xorp-users] XORP SNMP Support In-Reply-To: <40F03DF0.7010307@chello.at> References: <40F03DF0.7010307@chello.at> Message-ID: <1089487814.22654.10.camel@cellini.cs.ucl.ac.uk> to help atanu later, what does find / -name net-snmp-agent-includes.h -print give you , and what OS / version etc are you using ? Adam On Sat, 2004-07-10 at 21:05 +0200, Gernot W. Schmied wrote: > et-snmp-agent-includes.h From atanu@ICSI.Berkeley.EDU Sat Jul 10 20:31:39 2004 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Sat, 10 Jul 2004 12:31:39 -0700 Subject: [Xorp-users] XORP SNMP Support In-Reply-To: Message from Atanu Ghosh of "Sat, 10 Jul 2004 12:26:19 PDT." <40517.1089487579@tigger.icir.org> Message-ID: <41604.1089487899@tigger.icir.org> I just check the net-snmp web site there is no net-snmp 5.2? Atanu. >>>>> "Atanu" == Atanu Ghosh writes: Atanu> As far as I am aware we haven't tried building with net-snmp 5.2. Atanu> Configure is warning about a missing include file, the patch is not Atanu> going to solve this problem. Atanu> We will take a look next week. Atanu> Atanu. >>>>> "Gernot" == Gernot W Schmied writes: Gernot> Hi, Gernot> So far I was unable to convince ./configure to work with net-snmp. Gernot> checking for net-snmp-config... true Gernot> checking if net-snmp version equal or newer than 5.0.6... yes Gernot> checking if snmpd can be started... Warning: -l option is deprecated, Gernot> use -Lf instead Gernot> yes Gernot> checking whether C compiler supports flag "-g -O2 -Dlinux -I. Gernot> -I/usr/local/include"... yes Gernot> checking for net-snmp/agent/net-snmp-agent-includes.h... no Gernot> configure: WARNING: File does Gernot> not appear usable Gernot> configure: WARNING: XORP MIBs will not be built Gernot> Any ideas? Gernot> How relevant is the following statement for net-snmp 5.2 and XORP 1.0? Gernot> Gernot> Version 5.1 of net-snmp requires a simple modification, otherwise XORP Gernot> will fail to compile. A patch that can be applied to a net-snmp-5.1 Gernot> installation is available here. Gernot> Gernot> Regards, Gernot> Gernot Gernot> _______________________________________________ Gernot> Xorp-users mailing list Gernot> Xorp-users@xorp.org Gernot> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users Atanu> _______________________________________________ Atanu> Xorp-users mailing list Atanu> Xorp-users@xorp.org Atanu> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From gernot.schmied@chello.at Sat Jul 10 21:19:10 2004 From: gernot.schmied@chello.at (Gernot W. Schmied) Date: Sat, 10 Jul 2004 22:19:10 +0200 Subject: [Xorp-users] XORP SNMP Support In-Reply-To: <1089487814.22654.10.camel@cellini.cs.ucl.ac.uk> References: <40F03DF0.7010307@chello.at> <1089487814.22654.10.camel@cellini.cs.ucl.ac.uk> Message-ID: <40F04F3E.8000601@chello.at> Adam Greenhalgh wrote: > to help atanu later, what does > > find / -name net-snmp-agent-includes.h -print > > give you , and what OS / version etc are you using ? > > Adam > > On Sat, 2004-07-10 at 21:05 +0200, Gernot W. Schmied wrote: > >>et-snmp-agent-includes.h > > > Hi Adam/Atanu, Thanks for your quick response. I am actually using net-snmp 5.1.1 and testing 5.1.2pre (typo on my side). All the files are present and I pass the following to ./configure: ./configure --enable-advanced-mcast-api --with-path-to-snmpd=/usr/local/sbin/ --with-path-to-net-snmpd-src=/usr/local/src/SNMP/net-snmp/ /usr/local/src/SNMP/net-snmp/agent/net-snmp-agent-includes.h is present on the system. Regards, Gernot PS: I'll look into the configure setup tomorrow as well. From gernot.schmied@chello.at Sat Jul 10 21:25:09 2004 From: gernot.schmied@chello.at (Gernot W. Schmied) Date: Sat, 10 Jul 2004 22:25:09 +0200 Subject: [Xorp-users] XORP SNMP Support In-Reply-To: <1089487814.22654.10.camel@cellini.cs.ucl.ac.uk> References: <40F03DF0.7010307@chello.at> <1089487814.22654.10.camel@cellini.cs.ucl.ac.uk> Message-ID: <40F050A5.4010909@chello.at> Adam Greenhalgh wrote: > to help atanu later, what does > > find / -name net-snmp-agent-includes.h -print > > give you , and what OS / version etc are you using ? > > Adam > > On Sat, 2004-07-10 at 21:05 +0200, Gernot W. Schmied wrote: > >>et-snmp-agent-includes.h > > > I forgot, I am running XORP 1.0 on Linux 2.4.26 Mandrake 9.1. Regards, Gernot From sspies@sloc.de Sun Jul 11 21:39:47 2004 From: sspies@sloc.de (Sebastian Spies) Date: Sun, 11 Jul 2004 22:39:47 +0200 Subject: [Xorp-users] (no subject) Message-ID: <1089578387.3761.4.camel@setebos> From pavlin@icir.org Mon Jul 12 23:55:31 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Mon, 12 Jul 2004 15:55:31 -0700 Subject: [Xorp-users] XORP SNMP Support In-Reply-To: Message from "Gernot W. Schmied" of "Sat, 10 Jul 2004 22:19:10 +0200." <40F04F3E.8000601@chello.at> Message-ID: <200407122255.i6CMtV8U035559@possum.icir.org> > Adam Greenhalgh wrote: > > to help atanu later, what does > > > > find / -name net-snmp-agent-includes.h -print > > > > give you , and what OS / version etc are you using ? > > > > Adam > > > > On Sat, 2004-07-10 at 21:05 +0200, Gernot W. Schmied wrote: > > > >>et-snmp-agent-includes.h > > > > > > > > > Hi Adam/Atanu, > > Thanks for your quick response. I am actually using net-snmp 5.1.1 and > testing 5.1.2pre (typo on my side). All the files are present and I pass > the following to ./configure: > > ./configure > --enable-advanced-mcast-api --with-path-to-snmpd=/usr/local/sbin/ > --with-path-to-net-snmpd-src=/usr/local/src/SNMP/net-snmp/ > > /usr/local/src/SNMP/net-snmp/agent/net-snmp-agent-includes.h is present > on the system. On closer examination, the --with-path-to-net-snmpd-src is actually a no-op, so it cannot be used to specify the path to the net-snmp sources and the above include file. Hence, you would have to either (a) install the net-snmp version you are testing OR (b) wait until the above flag is fixed in the CVS repository so it does the right thing. Thanks, Pavlin From pavlin@icir.org Tue Jul 13 00:01:04 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Mon, 12 Jul 2004 16:01:04 -0700 Subject: [Xorp-users] XORP SNMP Support In-Reply-To: Message from "Gernot W. Schmied" of "Sat, 10 Jul 2004 22:19:10 +0200." <40F04F3E.8000601@chello.at> Message-ID: <200407122301.i6CN148U035596@possum.icir.org> > ./configure > --enable-advanced-mcast-api --with-path-to-snmpd=/usr/local/sbin/ > --with-path-to-net-snmpd-src=/usr/local/src/SNMP/net-snmp/ On slightly different subject. Currently, the --enable-advanced-mcast-api config flag makes difference only on FreeBSD, because Linux (the OS you are using) doesn't support (yet) this new API. In other words, using that flag won't make any difference for you, but it won't hurt either. Pavlin From gernot.schmied@chello.at Tue Jul 13 00:48:39 2004 From: gernot.schmied@chello.at (Gernot W. Schmied) Date: Tue, 13 Jul 2004 01:48:39 +0200 Subject: [Xorp-users] XORP SNMP Support In-Reply-To: <200407122301.i6CN148U035596@possum.icir.org> References: <200407122301.i6CN148U035596@possum.icir.org> Message-ID: <40F32357.4080102@chello.at> Pavlin Radoslavov wrote: >>./configure >>--enable-advanced-mcast-api --with-path-to-snmpd=/usr/local/sbin/ >>--with-path-to-net-snmpd-src=/usr/local/src/SNMP/net-snmp/ > > > On slightly different subject. > Currently, the --enable-advanced-mcast-api config flag makes > difference only on FreeBSD, because Linux (the OS you are using) > doesn't support (yet) this new API. In other words, using that flag > won't make any difference for you, but it won't hurt either. > > Pavlin > Hi Pavlin, Thanks for the reminder, we already discussed that when corresponding about XORP 0.5 multicasting a while ago. I will have a look at the API on my FreeBSD 4.9. Have there been changes from FreeBSD 4.9 to 4.10? Any good resources besides the man pages and the sources :-)? It looks like there was a lot of progress on the multicast side from 0.5 to 1.0 XORP, splendid. I'll play with it and report my testings in a Quagga/Cisco testing environment. Best Regards, Gernot From pavlin@icir.org Tue Jul 13 00:56:50 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Mon, 12 Jul 2004 16:56:50 -0700 Subject: [Xorp-users] XORP SNMP Support In-Reply-To: Message from "Gernot W. Schmied" of "Tue, 13 Jul 2004 01:48:39 +0200." <40F32357.4080102@chello.at> Message-ID: <200407122356.i6CNuo8U045163@possum.icir.org> > >>./configure > >>--enable-advanced-mcast-api --with-path-to-snmpd=/usr/local/sbin/ > >>--with-path-to-net-snmpd-src=/usr/local/src/SNMP/net-snmp/ > > > > > > On slightly different subject. > > Currently, the --enable-advanced-mcast-api config flag makes > > difference only on FreeBSD, because Linux (the OS you are using) > > doesn't support (yet) this new API. In other words, using that flag > > won't make any difference for you, but it won't hurt either. > > > > Pavlin > > > > Hi Pavlin, > > Thanks for the reminder, we already discussed that when corresponding > about XORP 0.5 multicasting a while ago. > I will have a look at the API on my FreeBSD 4.9. Have there been changes > from FreeBSD 4.9 to 4.10? Any good resources besides the man pages and > the sources :-)? No, there are no multicast routing related kernel changes between 4.9 and 4.10. The man pages and the source code are still the only written source of information :) > It looks like there was a lot of progress on the multicast side from 0.5 > to 1.0 XORP, splendid. I'll play with it and report my testings in a > Quagga/Cisco testing environment. Bug reports, feedbacks, etc are always welcome. Thanks, Pavlin From pavlin@icir.org Tue Jul 13 06:03:54 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Mon, 12 Jul 2004 22:03:54 -0700 Subject: [Xorp-users] Trouble compiling in FreeBSD 4.10-stable In-Reply-To: Message from =?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?= of "Fri, 09 Jul 2004 10:52:30 -0300." <40EEA31E.5050200@jonny.eng.br> Message-ID: <200407130504.i6D53s8U008159@possum.icir.org> > FYI, i used this command line to configure: > > ./configure --enable-optimize --enable-advanced-mcast-api --without-snmp > > Do you think it's safe to use -march=i686 -mcpu=i686 in compiler flags? Just for the kick of it, I tried it with the additional i686 flags, and it seems to work (at least, gmake check succeeds). I have tried it only with gcc34 on FreeBSD: pavlin@possum[1] gcc34 --version gcc34 (GCC) 3.4.0 20040310 (prerelease) [FreeBSD] FYI, if someone wants to add more compilation flags without modifying configure.in, the CFLAGS and CXXFLAGS environmental variables can be used for that: setenv CFLAGS "-march=i686 -mtune=i686" setenv CXXFLAGS "-march=i686 -mtune=i686" ./configure --enable-optimize --enable-advanced-mcast-api --without-snmp Pavlin From jgold@mazunetworks.com Tue Jul 13 19:40:38 2004 From: jgold@mazunetworks.com (Jeff Gold) Date: Tue, 13 Jul 2004 14:40:38 -0400 Subject: [Xorp-users] XORP OSPF on Linux: compile error and documentation request Message-ID: <40F42CA6.2090001@mazunetworks.com> I would like to experiment with XORP using OSPF on Linux. I understand that this is supported only through a contrib package that is thoroughly tested only on FreeBSD, but I would like to see how it holds up. Unfortunately for me it seems that OSPF won't even compile on Linux. I have managed to solve a few of the problems with the patch attached to this message, but I am stuck on the following problem: $ ./configure --prefix=/usr/local/routed/xorp --without-snmp && \ make clean && make [...] g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../.. -I../../.. -I./../src -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Wstrict-prototypes -Woverloaded-virtual -ftemplate-depth-20 -c -o ospfd_xorp.o `test -f ospfd_xorp.C || echo './'`ospfd_xorp.C In file included from ospfd_xorp.C:46: ospfd_xorp.h:101: error: field `rt_rtm' has incomplete type make[4]: *** [ospfd_xorp.o] Error 1 make[4]: Leaving directory `/root/xorp-1.0/contrib/ospfd/xorp' Apparently the xorp/ospfd_xorp.[hC] files are significantly changed versions of the freebsd/ospfd_freebsd.[hC] files. Can this be right? How is one supposed to build this on Linux, short of porting the XORP changes to the linux/ospfd_linux.[hC] files? Jeff diff -urN xorp-1.0/configure xorp-1.0-ospflinux/configure --- xorp-1.0/configure 2004-07-09 02:34:59.000000000 -0400 +++ xorp-1.0-ospflinux/configure 2004-07-13 10:30:03.000000000 -0400 @@ -9136,7 +9136,7 @@ xorp_cv_ospfd_os="freebsd" ;; linux* ) - xorp_cv_ospfd_os="unsupported" + xorp_cv_ospfd_os="linux" ;; * ) xorp_cv_ospfd_os="unsupported" diff -urN xorp-1.0/contrib/ospfd/xorp/ospfd_xorp.C xorp-1.0-ospflinux/contrib/ospfd/xorp/ospfd_xorp.C --- xorp-1.0/contrib/ospfd/xorp/ospfd_xorp.C 2003-09-27 18:32:45.000000000 -0400 +++ xorp-1.0-ospflinux/contrib/ospfd/xorp/ospfd_xorp.C 2004-07-13 10:30:34.000000000 -0400 @@ -46,6 +46,14 @@ #include "ospfd_xorp.h" #include "xrl_target.h" +/* apparently this is a BSD specific macro */ +#ifndef _SIZEOF_ADDR_IFREQ +# define _SIZEOF_ADDR_IFREQ(ifr) \ + ((ifr).ifr_addr.sa_len > sizeof(struct sockaddr) ? \ + (sizeof(struct ifreq) - sizeof(struct sockaddr) + \ + (ifr).ifr_addr.sa_len) : sizeof(struct ifreq)) +#endif /* _SIZEOF_ADDR_IFREQ */ + /* Initialize the FreeBSD interface. * Open the network interface. * Start the random number generator. From atanu@ICSI.Berkeley.EDU Wed Jul 14 04:52:09 2004 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Tue, 13 Jul 2004 20:52:09 -0700 Subject: [Xorp-users] XORP OSPF on Linux: compile error and documentation request In-Reply-To: Message from Jeff Gold of "Tue, 13 Jul 2004 14:40:38 EDT." <40F42CA6.2090001@mazunetworks.com> Message-ID: <70663.1089777129@tigger.icir.org> The OSPF code is not tested in any environment. At the time the code was ported we only supported FreeBSD. Thats why we don't try and build it for Linux. To get the code to compile/work on Linux is going to take some effort. We intend to produce our own OSPF implementation so we haven't been doing much with this code. Its still in the source tree because we put effort into porting it and it may be useful on FreeBSD. Atanu. >>>>> "Jeff" == Jeff Gold writes: Jeff> I would like to experiment with XORP using OSPF on Linux. I understand Jeff> that this is supported only through a contrib package that is thoroughly Jeff> tested only on FreeBSD, but I would like to see how it holds up. Jeff> Unfortunately for me it seems that OSPF won't even compile on Linux. I Jeff> have managed to solve a few of the problems with the patch attached to Jeff> this message, but I am stuck on the following problem: Jeff> $ ./configure --prefix=/usr/local/routed/xorp --without-snmp && \ Jeff> make clean && make Jeff> [...] Jeff> g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../.. -I../../.. -I./../src Jeff> -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith Jeff> -Wcast-align -Wstrict-prototypes -Woverloaded-virtual Jeff> -ftemplate-depth-20 -c -o ospfd_xorp.o `test -f ospfd_xorp.C || echo Jeff> './'`ospfd_xorp.C Jeff> In file included from ospfd_xorp.C:46: Jeff> ospfd_xorp.h:101: error: field `rt_rtm' has incomplete type Jeff> make[4]: *** [ospfd_xorp.o] Error 1 Jeff> make[4]: Leaving directory `/root/xorp-1.0/contrib/ospfd/xorp' Jeff> Apparently the xorp/ospfd_xorp.[hC] files are significantly changed Jeff> versions of the freebsd/ospfd_freebsd.[hC] files. Can this be right? Jeff> How is one supposed to build this on Linux, short of porting the XORP Jeff> changes to the linux/ospfd_linux.[hC] files? Jeff> Jeff Jeff> diff -urN xorp-1.0/configure xorp-1.0-ospflinux/configure Jeff> --- xorp-1.0/configure 2004-07-09 02:34:59.000000000 -0400 Jeff> +++ xorp-1.0-ospflinux/configure 2004-07-13 10:30:03.000000000 -0400 Jeff> @@ -9136,7 +9136,7 @@ Jeff> xorp_cv_ospfd_os="freebsd" Jeff> ;; Jeff> linux* ) Jeff> - xorp_cv_ospfd_os="unsupported" Jeff> + xorp_cv_ospfd_os="linux" Jeff> ;; Jeff> * ) Jeff> xorp_cv_ospfd_os="unsupported" Jeff> diff -urN xorp-1.0/contrib/ospfd/xorp/ospfd_xorp.C Jeff> xorp-1.0-ospflinux/contrib/ospfd/xorp/ospfd_xorp.C Jeff> --- xorp-1.0/contrib/ospfd/xorp/ospfd_xorp.C 2003-09-27 Jeff> 18:32:45.000000000 -0400 Jeff> +++ xorp-1.0-ospflinux/contrib/ospfd/xorp/ospfd_xorp.C 2004-07-13 Jeff> 10:30:34.000000000 -0400 Jeff> @@ -46,6 +46,14 @@ Jeff> #include "ospfd_xorp.h" Jeff> #include "xrl_target.h" Jeff> +/* apparently this is a BSD specific macro */ Jeff> +#ifndef _SIZEOF_ADDR_IFREQ Jeff> +# define _SIZEOF_ADDR_IFREQ(ifr) \ Jeff> + ((ifr).ifr_addr.sa_len > sizeof(struct sockaddr) ? \ Jeff> + (sizeof(struct ifreq) - sizeof(struct sockaddr) + \ Jeff> + (ifr).ifr_addr.sa_len) : sizeof(struct ifreq)) Jeff> +#endif /* _SIZEOF_ADDR_IFREQ */ Jeff> + Jeff> /* Initialize the FreeBSD interface. Jeff> * Open the network interface. Jeff> * Start the random number generator. Jeff> _______________________________________________ Jeff> Xorp-users mailing list Jeff> Xorp-users@xorp.org Jeff> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From jgold@mazunetworks.com Wed Jul 14 16:16:08 2004 From: jgold@mazunetworks.com (Jeff Gold) Date: Wed, 14 Jul 2004 11:16:08 -0400 Subject: [Xorp-users] XORP OSPF on Linux: compile error and documentation request In-Reply-To: <70663.1089777129@tigger.icir.org> References: <70663.1089777129@tigger.icir.org> Message-ID: <40F54E38.4060803@mazunetworks.com> Atanu Ghosh wrote: > We intend to produce our own OSPF implementation so we haven't been > doing much with this code. Its still in the source tree because we > put effort into porting it and it may be useful on FreeBSD. Ah, okay. Thanks for the clarification. Jeff From emmanuel.quemener@free.fr Wed Jul 14 19:52:07 2004 From: emmanuel.quemener@free.fr (Emmanuel QUEMENER) Date: Wed, 14 Jul 2004 20:52:07 +0200 Subject: [Xorp-users] Problem with ps figures when creating doc Message-ID: <40F580D7.5050004@free.fr> As I told Pavlin several weeks ago, I'm working on a Debian package since weeks. The first version for 1.0 release is created for Sarge distribution users. Also, I've got some problems when compiling documentation. When I investigate in error logs, I discover that the origin seems to be ghostscript interpretation of several postscript figures, like BGP ones : ps2pdf bgp.ps bgp.pdf Error: /rangecheck in --get-- Operand stack: --nostringval-- --nostringval-- --nostringval-- --nostringval-- descender 0 --nostringval-- 1 Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- --nostringval-- Dictionary stack: --dict:1055/1417(ro)(G)-- --dict:0/20(G)-- --dict:71/200(L)-- --dict:123/300(L)-- --dict:50/200(L)-- --dict:36/51(L)-- --dict:1/17(L)-- --dict:0/17(L)-- --dict:5/17(L)-- --dict:1/3(L)-- --dict:13/14(ro)(L)-- Current allocation mode is local Current file position is 32984 ESP Ghostscript 7.07.1: Unrecoverable error, exit code 1 make[1]: *** [bgp.pdf] Erreur 1 make[1]: quittant le répertoire « /usr/src/projects/xorp-1.0RC/docs/bgp » make: *** [all-recursive] Erreur 1 When I try to visualize the figures in bgp/figs, same problems... My gs version is 7.07.1 : is it enough ? Would you like me to purpose my package without compiled official documentation ? Best regards... Manu -- M. Emmanuel QUEMENER 1, rue du Poisson Bleu Tel.: 01 40 91 83 13 92290 CHATENAY-MALABRY Emmanuel.Quemener@free.fr From pavlin@icir.org Thu Jul 15 05:19:12 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 14 Jul 2004 21:19:12 -0700 Subject: [Xorp-users] Problem with ps figures when creating doc In-Reply-To: Message from Emmanuel QUEMENER of "Wed, 14 Jul 2004 20:52:07 +0200." <40F580D7.5050004@free.fr> Message-ID: <200407150419.i6F4JC8U048989@possum.icir.org> > As I told Pavlin several weeks ago, I'm working on a Debian package > since weeks. > > The first version for 1.0 release is created for Sarge distribution users. > > Also, I've got some problems when compiling documentation. When I > investigate in error logs, I discover that the origin seems to be > ghostscript interpretation of several postscript figures, like BGP ones : > > ps2pdf bgp.ps bgp.pdf > Error: /rangecheck in --get-- > Operand stack: > --nostringval-- --nostringval-- --nostringval-- > --nostringval-- descender 0 --nostringval-- 1 > Execution stack: > %interp_exit .runexec2 --nostringval-- --nostringval-- > --nostringval-- 2 %stopped_push --nostringval-- > --nostringval-- --nostringval-- false 1 %stopped_push 1 3 > %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop .runexec2 > --nostringval-- --nostringval-- --nostringval-- 2 > %stopped_push --nostringval-- --nostringval-- --nostringval-- > --nostringval-- > Dictionary stack: > --dict:1055/1417(ro)(G)-- --dict:0/20(G)-- --dict:71/200(L)-- > --dict:123/300(L)-- --dict:50/200(L)-- --dict:36/51(L)-- > --dict:1/17(L)-- --dict:0/17(L)-- --dict:5/17(L)-- > --dict:1/3(L)-- --dict:13/14(ro)(L)-- > Current allocation mode is local > Current file position is 32984 > ESP Ghostscript 7.07.1: Unrecoverable error, exit code 1 > make[1]: *** [bgp.pdf] Erreur 1 > make[1]: quittant le répertoire « /usr/src/projects/xorp-1.0RC/docs/bgp » > make: *** [all-recursive] Erreur 1 > > When I try to visualize the figures in bgp/figs, same problems... My gs > version is 7.07.1 : is it enough ? Manu, We are using gs-8.00, but I don't know whether the problem is that you use an older version or something else. Can you try to update your gs version and try again to generate the documentation? If it still doesn't work, would it help if we give you a tarball with all generated documentation? Actually, such tarball already exists from the following non-advertised URL: http://www.xorp.org/releases/1.0/docs-1.0.tar.gz BTW, when generating the Debian package, please make sure that you are using the 1.0 release, and not the 1.0RC :) Thanks, Pavlin From dave.price@aber.ac.uk Fri Jul 16 13:20:45 2004 From: dave.price@aber.ac.uk (Dave Price) Date: Fri, 16 Jul 2004 13:20:45 +0100 Subject: [Xorp-users] Adding a new user to a LiveCD boot of XORP Message-ID: <28981.1089980445@aber.ac.uk> Dear All, I need to be able to add another account to a LiveCD boot of xorp so as I can log in and then "su" to root to do some things. The standard ssh setup does not allow diredt logins as root it seems and if I log in as xorp, I can't su from the xorpsh shell. So, is there a recommended way to add a new account so as it will still be there after I reboot etc. I guess whatever changes I make need to get saved to the config CD etc. Thanks, Dave Price --------------------------------------------------------- | David Price, Computer Science | | | | Computer Science, University of Wales, Aberystwyth, | | Penglais Campus, Aberystwyth, Ceredigion, SY23 3DB | | | | Email: dap@aber.ac.uk WWW: http://www.aber.ac.uk/~dap | | Phone: +44 1970 622428 FAX: +44 1970 622455 | --------------------------------------------------------- From M.Handley@cs.ucl.ac.uk Fri Jul 16 13:38:05 2004 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Fri, 16 Jul 2004 13:38:05 +0100 Subject: [Xorp-users] Adding a new user to a LiveCD boot of XORP In-Reply-To: Your message of "Fri, 16 Jul 2004 13:20:45 BST." <28981.1089980445@aber.ac.uk> Message-ID: <29943.1089981485@aardvark.cs.ucl.ac.uk> > I need to be able to add another account to >a LiveCD boot of xorp so as I can log in and then "su" >to root to do some things. The standard ssh setup does not allow >diredt logins as root it seems and if I log >in as xorp, I can't su from the xorpsh shell. > > So, is there a recommended way to add a new account so >as it will still be there after I reboot etc. I guess whatever >changes I make need to get saved to the config CD etc. Ideally, you'd be able to add and delete users from the XORP CLI. But we haven't implemented this functionality yet. If you can login as root on the console, you can use the adduser command. Then you should reboot the machine, and this should force a write to the floppy of the password file. Otherwise could could copy /etc/passwd and /etc/master.password manually to the locations on the floppy indicated in the /mnt/floppy/manifest file. If you can't login as root because the machine is remote, then I don't really have a good suggestion. Sorry. If you can't login as root because the machine has no keyboard or monitor, then you could manually copy a modified sshd_config file (permitting root login) onto the floppy, and add a manifest entry to the manifest file on the floppy that will cause it to be copied into /etc/ssh/sshd_config after boot. Hope one of these works! - Mark From dave.price@aber.ac.uk Fri Jul 16 18:16:13 2004 From: dave.price@aber.ac.uk (Dave Price) Date: Fri, 16 Jul 2004 18:16:13 +0100 Subject: [Xorp-users] Adding a new user to a LiveCD boot of XORP In-Reply-To: Your message of Fri, 16 Jul 2004 13:38:05 +0100. <29943.1089981485@aardvark.cs.ucl.ac.uk> Message-ID: <29340.1089998173@aber.ac.uk> Dear Mark, M.Handley@cs.ucl.ac.uk said: > If you can login as root on the console, you can use the adduser > command. I've been trying that, but its fighting back.... Its complaining about a missing config file and that shells are not valid and ... I'll try again... The main reason I think I need to be "root" is that there is no ping or traceroute command available in xorpsh and so its a bit hard trying to see what works from that end.... Thanks, Dave Price From M.Handley@cs.ucl.ac.uk Fri Jul 16 21:02:33 2004 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Fri, 16 Jul 2004 21:02:33 +0100 Subject: [Xorp-users] Adding a new user to a LiveCD boot of XORP In-Reply-To: Your message of "Fri, 16 Jul 2004 18:16:13 BST." <29340.1089998173@aber.ac.uk> Message-ID: <50225.1090008153@vulture.xorp.org> >M.Handley@cs.ucl.ac.uk said: >> If you can login as root on the console, you can use the adduser >> command. > >I've been trying that, but its fighting back.... Its complaining >about a missing config file and that shells are not valid and ... > >I'll try again... Ooops - my bad. I should have added /usr/local/xorp/bin/xorpsh to /etc/shells. You could manually do this before using adduser. Let me know if you succeed. If not, let be know, and I'll generate you a new ISO that gives you the ability to login as root via ssh. >The main reason I think I need to be "root" is that >there is no ping or traceroute command available in xorpsh >and so its a bit hard trying to see what works from that end.... I'll submit a bugzilla report on this, just to make sure it gets on the wish list and doesn't get forgotten. We should have operational mode command support for traceroute and ping from xorpsh. Any other common commands people would like? Cheers, Mark From dave.price@aber.ac.uk Mon Jul 19 14:36:28 2004 From: dave.price@aber.ac.uk (Dave Price) Date: Mon, 19 Jul 2004 14:36:28 +0100 Subject: [Xorp-users] Adding a new user to a LiveCD boot of XORP In-Reply-To: Your message of Fri, 16 Jul 2004 21:02:33 +0100. <50225.1090008153@vulture.xorp.org> Message-ID: <2639.1090244188@aber.ac.uk> Dear Mark, M.Handley@cs.ucl.ac.uk said: > Ooops - my bad. I should have added /usr/local/xorp/bin/xorpsh to / > etc/shells. You could manually do this before using adduser. I did that, but it also complains about not having a /etc/adduser.conf file. This then mislead me, as adduser's prompts are then really asking you for info for that file rather than for the user you are trying to add.... Once I get my head around that, I entered info for it to put in that file and then the info for my new user. I then tried logging in as my new user and using "su" to change to root. That failed saying I was not in group "wheel". I then deleted my new user and then added it again this time saying I wanted to be in "wheel" at the appropriate place. However, when I now try to "su" to root it comes back and says "Sorry" even though I know I am getting password correct. Investigations led me to a file called /etc/login.auth [or some such, I'm in office and can't quite rememeber... and I can't remote log in to check :-( ] Do I need to edit that?? I'm also having problems that I can update the config from xorpsh and issue a "save" (to either of /etc/xorp.cfg or /etc/xorp.conf ) but when I reboot it seems to have lost my changes... I'll have a look again on that though in a few minutes time. I'm also getting a "watchdog timer" message associated with one of my four ethernet interfaces and I can't seem to manage to see traffic on it using tcpdump and I can't ping that interface from elsewhere. I'm about to change card yet again, but any other ideas?? Thanks Mark (& folks) Any ideas?? Dave Price From dave.price@aber.ac.uk Mon Jul 19 18:23:10 2004 From: dave.price@aber.ac.uk (Dave Price) Date: Mon, 19 Jul 2004 18:23:10 +0100 Subject: [Xorp-users] Setting default routes In-Reply-To: Your message of Mon, 19 Jul 2004 14:36:28 +0100. <2639.1090244188@aber.ac.uk> Message-ID: <3007.1090257790@aber.ac.uk> Dear All, I am attempting to work out the syntax and commands etc for setting a static default route on my Xorp box. I tried using 0.0.0.0/0, but no luck. I also tried enabling rip on the interface towards the default router, but that seemed not to recognise the RIPv1 packets from the next-hop router. Any ideas?? My current plan is to get the box doing multicast routing for four connected networks, but NOT to normally do unicast routing. It strikes me as "safer" if I don't have the box making RIP announcements as its wired in parallel with a unicast-only router that "really" services the unicast routing between the four networks. Thoughts/advice from anyone? Also, is there any detailed documentation on all the paremeters/settings etc for the various bits of Xorp, like for instance all the settings associated with rip?? Thanks, Dave Price From atanu@ICSI.Berkeley.EDU Mon Jul 19 20:32:00 2004 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Mon, 19 Jul 2004 12:32:00 -0700 Subject: [Xorp-users] Setting default routes In-Reply-To: Message from Dave Price of "Mon, 19 Jul 2004 18:23:10 BST." <3007.1090257790@aber.ac.uk> Message-ID: <52575.1090265520@tigger.icir.org> >>>>> "Dave" == Dave Price writes: Dave> Dear All, I am attempting to work out the syntax and commands Dave> etc for setting a static default route on my Xorp box. Dave> I tried using 0.0.0.0/0, but no luck. I tried the following in my config file, it worked for me. ---------------------------------------- protocols { static { route4 0.0.0.0/0 { nexthop: 144.124.0.2 metric: 1 } } } ---------------------------------------- Dave> I also tried enabling rip on the interface towards the Dave> default router, but that seemed not to recognise the RIPv1 Dave> packets from the next-hop router. I believe that we only speak RIPv2. Dave> Any ideas?? Dave> My current plan is to get the box doing multicast Dave> routing for four connected networks, but NOT to normally do Dave> unicast routing. It strikes me as "safer" if I don't have the Dave> box making RIP announcements as its wired in parallel with a Dave> unicast-only router that "really" services the unicast routing Dave> between the four networks. Dave> Thoughts/advice from anyone? You can configure the XORP RIP to be passive (i.e. receive only). Hence, no danger of it routing unicast packets. Dave> Also, is there any detailed documentation on all the Dave> paremeters/settings etc for the various bits of Xorp, like for Dave> instance all the settings associated with rip?? The simplest way of discovering all the settings for a protocol is to use the xorpsh. In configure mode it will show all the settings along with help text. For example: xorp$ xorpsh Welcome to XORP on xorp.icir.org Xorp> configure Entering configuration mode. User atanu is also in configuration mode. [edit] XORP> edit protocols rip interface dc0 vif dc0 address 172.16.0.1 Will list all the available settings for this address. There is also a sample configuration file in the router manager directory. As well as . This unfortunately only covers the simple cases. A lower level way of discovering what options are available is to look in the template file that is used by the router manager and the xorpsh. In the case of RIP etc/templates/rip.tp is the relevant file. We are intending to make some sample configuration files available. Your configuration file would be a great candidate. Atanu. From dave.price@aber.ac.uk Tue Jul 20 09:29:55 2004 From: dave.price@aber.ac.uk (Dave Price) Date: Tue, 20 Jul 2004 09:29:55 +0100 Subject: [Xorp-users] Setting default routes In-Reply-To: Your message of Mon, 19 Jul 2004 12:32:00 -0700. <52575.1090265520@tigger.icir.org> Message-ID: <3752.1090312195@aber.ac.uk> Dear Atanu, atanu@icsi.berkeley.edu said: > I tried the following in my config file, it worked for me. > ---------------------------------------- protocols { > static { > route4 0.0.0.0/0 { > nexthop: 144.124.0.2 > metric: 1 > } > } } ---------------------------------------- That lookss exactly the same as what I believe I had added yesterday when I could not seem to get it to work. I'll try again. Slight complication in so much as we subnet 144.124.x.x (at 22 bits) and so the interface to the default is on a subnet of this, but I can't see that should change things. I have NOT enabled the unicast FEA as I don't actually want this box to unicast forward between its ports, I plan to just get it to act as a multicast router. I wonder if that interacts. Anyway, I'll try to static default route again. atanu@icsi.berkeley.edu said: > I believe that we only speak RIPv2. I had come to that conclusion, the docs implied that and I could see multicast RIPv2 requests coming out of the xorp box when I did enable RIP. It was ignoring RIPv1 announcements that were arriving. atanu@icsi.berkeley.edu said: > The simplest way of discovering all the settings for a protocol is to > use the xorpsh. In configure mode it will show all the settings along > with help text. That lets you discover their existence, but it does not give precise descriptions of their role etc. Some have names which might be interpreted in more than one way I felt. atanu@icsi.berkeley.edu said: > We are intending to make some sample configuration files available. > Your configuration file would be a great candidate. assuming I can get it to work :-) I'll go and have another play.... Dave Price From M.Handley@cs.ucl.ac.uk Tue Jul 20 10:31:31 2004 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Tue, 20 Jul 2004 10:31:31 +0100 Subject: [Xorp-users] Setting default routes In-Reply-To: Your message of "Tue, 20 Jul 2004 09:29:55 BST." <3752.1090312195@aber.ac.uk> Message-ID: <91896.1090315891@aardvark.cs.ucl.ac.uk> >atanu@icsi.berkeley.edu said: >> I tried the following in my config file, it worked for me. >> ---------------------------------------- protocols { >> static { >> route4 0.0.0.0/0 { >> nexthop: 144.124.0.2 >> metric: 1 >> } >> } } ---------------------------------------- > >That lookss exactly the same as what I believe I had >added yesterday when I could not seem to get it to work. I'll >try again. Slight complication in so much as we subnet >144.124.x.x (at 22 bits) and so the interface to the default >is on a subnet of this, but I can't see that should change things. > >I have NOT enabled the unicast FEA as I don't actually want this box >to unicast forward between its ports, I plan to just get it >to act as a multicast router. I wonder if that interacts. >Anyway, I'll try to static default route again. I'm not completely clear what you're trying to do, but there's a fair chance that you're putting the static route only in the unicast RIB and PIM-SM is looking in the multicast rib. Can you try the mrib-route4 command instead of the route4 command? The route4 command only inserts the route into the unicast RIB. the mrib-route4 command has identical syntax, but puts the route in the multicast RIB. This sounds like what you want - ie the route to NOT be used for unicast forwarding, but to be used for topology discovery for forwarding multicast joins and prunes towards the RP (if this isn't the RP itself) and towards multicast sources. >That lets you discover their existence, but it does not give >precise descriptions of their role etc. Some have names >which might be interpreted in more than one way I felt. Agreed - an improved user manual is high on my priority list. - Mark From dave.price@aber.ac.uk Tue Jul 20 13:26:07 2004 From: dave.price@aber.ac.uk (Dave Price) Date: Tue, 20 Jul 2004 13:26:07 +0100 Subject: [Xorp-users] Was: Setting default routes Now: general config problem I think... In-Reply-To: Your message of Tue, 20 Jul 2004 10:31:31 +0100. <91896.1090315891@aardvark.cs.ucl.ac.uk> Message-ID: <4344.1090326367@aber.ac.uk> This is a multipart MIME message. --==_Exmh_-21163577130 Content-Type: text/plain; charset=us-ascii Dear Mark, Atanu and All, M.Handley@cs.ucl.ac.uk said: > I'm not completely clear what you're trying to do A more coherent description from me... I am attempting to set up an Xorp machine that will normally be used as a multicast router to feed three internal networks (possibly more later, but ignore that for now) fed from one other network that leads to our JANET connection and on to the Internet.... "Internal" networks carry the numbers 193.60.10.x/24, 193.60.11.x/24 and 193.60.15.x/24 The feed network is 144.124.32.0/22 (i.e. all of 32,33,34 and 35 for third place). The upstream PIM-SM neighbour is 144.124.35.254 and my machines interface to that network is 144.124.34.30 For complex reasons (read network with odd routers.....) I have to use a distant router as the RP (don't ask...) it has IP address 146.97.34.8 I needed to add a default static unicast route to the XORP config so I can get to and fro our other local machines on the other subnets to 144.124.0.0 but I don't want the XORP machine to actually unicast route between its interfaces. When I was emailing to/fro Atanu I was then just trying to establish initial unicast connectivity. I've got that all o.k. now. [Aside: except following my earlier track of emails I still cannot manage to allow my new "plain" use account "dap" to su to root etc from either a console login or from a remote ssh session]. I have (just before reading Mark's email) set up all the multicast related configurations. I have added a static default route in the mrib-route4 part pointing to the upstream router. I have enabled the MFEA and added all four of my network interfaces into that as I want it to multicast back and forth between each of these. I have created all the protocols-igmp stuff for all four interfaces and the register_vif (once I worked out it was an underscore and not a dot!) [Aside: when I did do it with a dot in name, it let me create it all but then gave a syntax error when I tried to commit the change. I guess that's correct, but it was sort of only by luck I spotted I had the dot and not an underscore] I have created the protocols-pimsm4 stuff for all four interfaces, the register_vif interface and set a static RP to point to the distant router. I set the switch-to... stuff to match the documents. [Aside: do I really need to add all four interfaces into the PIMSM setting as the only PIM neighbour is upstream and I guess only IGMP is used to signal on the other three networks that hosts are interested in multicast traffic etc. I only added the upstream one first but that seemd to not work so I added the other three, but I don't think its really working now anyway...] I have not enabled the fib2mrib stuff as I only have directly connected networks plus the default route which I have manually added as a static-mrib4 entry. I've just started a copy of "sdr" on my Sun workstation here having thrown away its cache from when it was last used back in 2002! However, my sdr display is not filling with anything..... I've attached a copy of /etc/xorp.cfg to this email, anyone someone can have a look for me and spot any obvious (or less obvious :-) ) problems.... Dave Price --==_Exmh_-21163577130 Content-Type: text/plain ; name="xorp.cfg"; charset=us-ascii Content-Description: xorp.cfg Content-Disposition: attachment; filename="xorp.cfg" /*XORP Configuration File, v1.0*/ interfaces { interface rl0 { description: "Ethernet" vif rl0 { enabled: true address 193.60.15.40 { enabled: true broadcast: 193.60.15.255 prefix-length: 24 } } enabled: true } interface rl1 { description: "Ethernet" vif rl1 { enabled: true address 193.60.10.90 { enabled: true broadcast: 193.60.10.255 prefix-length: 24 } } enabled: true } interface rl2 { description: "Ethernet" vif rl2 { enabled: true address 193.60.11.33 { enabled: true prefix-length: 24 broadcast: 193.60.11.255 } } enabled: true } interface rl3 { description: "Ethernet" vif rl3 { enabled: true address 144.124.34.30 { enabled: true broadcast: 144.124.35.255 prefix-length: 22 } } enabled: true } interface lo0 { description: "Loopback interface" vif lo0 { enabled: true } enabled: true } targetname: "fea" } protocols { static { route4 0.0.0.0/0 { metric: 1 nexthop: 144.124.35.254 } targetname: "static_routes" enabled: true mrib-route4 0.0.0.0/0 { metric: 1 nexthop: 144.124.35.254 } } igmp { interface rl3 { vif rl3 { enabled: true } } interface rl2 { vif rl2 { enabled: true } } interface rl1 { vif rl1 { enabled: true } } interface rl0 { vif rl0 { enabled: true } } targetname: "IGMP" enabled: true traceoptions { flag { all { enabled: false } } } } pimsm4 { interface rl3 { vif rl3 { enabled: true dr-priority: 1 } } interface register_vif { vif register_vif { enabled: true dr-priority: 1 } } interface rl0 { vif rl0 { enabled: true dr-priority: 1 } } interface rl1 { vif rl1 { enabled: true dr-priority: 1 } } interface rl2 { vif rl2 { enabled: true dr-priority: 1 } } targetname: "PIMSM_4" enabled: true static-rps { rp 146.97.34.8 { group-prefix 224.0.0.0/4 { rp-priority: 192 hash-mask-len: 30 } } } switch-to-spt-threshold { enabled: true interval-sec: 100 bytes: 102400 } traceoptions { flag { all { enabled: false } } } } } plumbing { mfea4 { interface rl3 { vif rl3 { enabled: true } } interface rl2 { vif rl2 { enabled: true } } interface rl1 { vif rl1 { enabled: true } } interface rl0 { vif rl0 { enabled: true } } interface register_vif { vif register_vif { enabled: true } } targetname: "MFEA_4" enabled: true traceoptions { flag { all { enabled: false } } } } } --==_Exmh_-21163577130-- From philippe.vanhecke@belnet.be Tue Jul 20 14:00:39 2004 From: philippe.vanhecke@belnet.be (Philippe Van Hecke) Date: Tue, 20 Jul 2004 15:00:39 +0200 Subject: [Xorp-users] Was: Setting default routes Now: general config problem I think... In-Reply-To: <4344.1090326367@aber.ac.uk> References: <4344.1090326367@aber.ac.uk> Message-ID: <200407201500.39320.philippe.vanhecke@belnet.be> Simple question what is the DR priroity of your upstream neighbour ? also to answer to your question about enable pim and all interfaces. If multicast traffic should travel these interface, yes you need to enable it on all interface. Philippe. > Dear Mark, Atanu and All, > > M.Handley@cs.ucl.ac.uk said: > > I'm not completely clear what you're trying to do > > A more coherent description from me... > > I am attempting to set up an Xorp > machine that will normally be used as > a multicast router to feed three internal networks > (possibly more later, but ignore that for now) > fed from one other network that leads > to our JANET connection and on to the Internet.... > > "Internal" networks carry the numbers 193.60.10.x/24, 193.60.11.x/24 and > 193.60.15.x/24 > > The feed network is 144.124.32.0/22 (i.e. all of 32,33,34 and 35 > for third place). > > The upstream PIM-SM neighbour is 144.124.35.254 and my machines > interface to that network is 144.124.34.30 > > For complex reasons (read network with odd routers.....) > I have to use a distant router as the RP (don't ask...) > it has IP address 146.97.34.8 > > I needed to add a default static unicast route > to the XORP config so I can get to and fro > our other local machines on the other subnets to 144.124.0.0 > but I don't want the XORP machine to actually unicast route > between its interfaces. When I was > emailing to/fro Atanu I was then just trying to establish > initial unicast connectivity. I've got that all o.k. > now. > > [Aside: except following my earlier track of emails > I still cannot manage to allow my new "plain" use > account "dap" to su to root etc from either a console > login or from a remote ssh session]. > > I have (just before reading Mark's email) set up > all the multicast related configurations. > > I have added a static default route in the mrib-route4 > part pointing to the upstream router. > > I have enabled the MFEA and added all four of my network > interfaces into that as I want it to multicast > back and forth between each of these. > > > I have created all the protocols-igmp stuff > for all four interfaces and the register_vif > (once I worked out it was an underscore and not a dot!) > > [Aside: when I did do it with a dot in name, it let > me create it all but then gave a syntax error when > I tried to commit the change. I guess that's correct, > but it was sort of only by luck I spotted I had the dot > and not an underscore] > > I have created the protocols-pimsm4 stuff for all four > interfaces, the register_vif interface and set a static RP > to point to the distant router. I set the switch-to... > stuff to match the documents. > > [Aside: do I really need to add all four interfaces > into the PIMSM setting as the only PIM neighbour > is upstream and I guess only IGMP is used to signal > on the other three networks that hosts are interested > in multicast traffic etc. I only added the upstream > one first but that seemd to not work so I added > the other three, but I don't think its really working now > anyway...] > > I have not enabled the fib2mrib stuff as I only have > directly connected networks plus the default route > which I have manually added as a static-mrib4 entry. > > I've just started a copy of "sdr" on my Sun workstation > here having thrown away its cache from when it was > last used back in 2002! However, my sdr display > is not filling with anything..... > > I've attached a copy of /etc/xorp.cfg to this email, anyone > someone can have a look for me and spot any obvious > (or less obvious :-) ) problems.... > > Dave Price -- ___________________________________________________________________ Philippe Van Hecke - BELNET, The Belgian Research Network "In a world without walls and fences, who needs windows and gates?" ___________________________________________________________________ From M.Handley@cs.ucl.ac.uk Tue Jul 20 15:31:38 2004 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Tue, 20 Jul 2004 15:31:38 +0100 Subject: [Xorp-users] Re: Was: Setting default routes Now: general config problem I think... In-Reply-To: Your message of "Tue, 20 Jul 2004 13:26:07 BST." <4344.1090326367@aber.ac.uk> Message-ID: <12757.1090333898@aardvark.cs.ucl.ac.uk> >[Aside: except following my earlier track of emails >I still cannot manage to allow my new "plain" use >account "dap" to su to root etc from either a console >login or from a remote ssh session]. There's now a new version of the LiveCD here: http://nrg.cs.ucl.ac.uk/mjh/tmp/LiveCD.iso.gz MD5 (LiveCD.iso.gz) = eb1df47971e02c625f05761d85da34a9 This is a fresh build of XORP from the current CVS tree, so it's not quite 1.0-RELEASE, but the differences should be minor. The main relevant change is that I've modified sshd_config to allow root logins. This isn't the "correct" solution to your problem, but it should at least be a viable work around while you're debugging. For everyone else: I'd prefer you to use the 1.0-RELEASE version unless you also have the same problem Dave has. Also the URL above isn't guaranteed to always contain this same version. Cheers, Mark From dave.price@aber.ac.uk Tue Jul 20 16:42:30 2004 From: dave.price@aber.ac.uk (Dave Price) Date: Tue, 20 Jul 2004 16:42:30 +0100 Subject: [Xorp-users] Re: Was: Setting default routes Now: general config problem I think... In-Reply-To: Your message of Tue, 20 Jul 2004 15:31:38 +0100. <12757.1090333898@aardvark.cs.ucl.ac.uk> Message-ID: <4669.1090338150@aber.ac.uk> Dear Mark, M.Handley@cs.ucl.ac.uk said: > This is a fresh build of XORP from the current CVS tree, so it's not > quite 1.0-RELEASE, but the differences should be minor. The main > relevant change is that I've modified sshd_config to allow root > logins. excellent. I'll now be able to debug from my office, rather than standing next to a machine perched on a filing cabinet with a monitor perched on top and a keyboard whose cable keeps getting stuck in the cabinet door..... My "safety officer" is eternally greatful :-) Dave Price From jonny@jonny.eng.br Tue Jul 20 16:53:46 2004 From: jonny@jonny.eng.br (=?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?=) Date: Tue, 20 Jul 2004 12:53:46 -0300 Subject: [Xorp-users] Re: Was: Setting default routes Now: general config problem I think... In-Reply-To: <12757.1090333898@aardvark.cs.ucl.ac.uk> References: <12757.1090333898@aardvark.cs.ucl.ac.uk> Message-ID: <40FD400A.1070603@jonny.eng.br> Mark Handley wrote: > There's now a new version of the LiveCD here: > http://nrg.cs.ucl.ac.uk/mjh/tmp/LiveCD.iso.gz > > MD5 (LiveCD.iso.gz) = eb1df47971e02c625f05761d85da34a9 > > This is a fresh build of XORP from the current CVS tree, so it's not > quite 1.0-RELEASE, but the differences should be minor. The main > relevant change is that I've modified sshd_config to allow root > logins. This isn't the "correct" solution to your problem, but it > should at least be a viable work around while you're debugging. May I suggest something? Use a better name description for the LiveCDs. For example, a name like XORP-1.0-RELEASE-LiveCD.iso.gz would avoid confusion, and allow easier sharing in ed2k: networks. This is not probably to be used with this CD, since it's not -RELEASE, but could be something like: XORP-2004072-LiveCD.iso.gz Just MHO, off course. From M.Handley@cs.ucl.ac.uk Tue Jul 20 16:56:59 2004 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Tue, 20 Jul 2004 16:56:59 +0100 Subject: [Xorp-users] Re: Was: Setting default routes Now: general config problem I think... In-Reply-To: Your message of "Tue, 20 Jul 2004 12:53:46 -0300." <40FD400A.1070603@jonny.eng.br> Message-ID: <29462.1090339019@aardvark.cs.ucl.ac.uk> > Use a better name description for the LiveCDs. For example, a name >like XORP-1.0-RELEASE-LiveCD.iso.gz would avoid confusion, and allow >easier sharing in ed2k: networks. > > This is not probably to be used with this CD, since it's not >-RELEASE, but could be something like: XORP-2004072-LiveCD.iso.gz Yes, good suggestion. - Mark From dave.price@aber.ac.uk Tue Jul 20 19:00:05 2004 From: dave.price@aber.ac.uk (Dave Price) Date: Tue, 20 Jul 2004 19:00:05 +0100 Subject: [Xorp-users] Well - I'm half working.... In-Reply-To: Your message of Tue, 20 Jul 2004 16:56:59 +0100. <29462.1090339019@aardvark.cs.ucl.ac.uk> Message-ID: <5047.1090346405@aber.ac.uk> Dear All, After help received so far (thanks Mark for new LiveCD), I'm now half working. Following a local suggestion (Thanks Hefin), I've set up a multicast beacon client reporting to the JANET beacon monitoring system from my Sun (193.60.11.36). As far as I can tell, the monitoring system, and other sites are reporting seeing my multicast beacon packets being sent to 233.3.18.1 However, my beacon sees no incoming multicasts from other beacons, seems to report no reception on the monitoring software and indeed, using tcpdump/snoop on various interfaces I can see my outgoing packets but none coming back. [Aside, why does the XORP machine ask www.icir.org to do pointer DNS lookups every now and then... That machine replies NX. The enquiries are for addresses that would exist in our number space but are unused. I suspect there is some low volume of port scanning goping on perhaps - but why does it ask www.icir.org to do DNS?] I'm not quite sure what to expect as the output of the various xorp "show" commands, but there are a view cases where it says "UNKNOWN" for values of things and I wondered what the significance of that was. For instance if I issue "show pim join all" then I get lots of output, selecting just a bit, the output sections for the group 233.3.18.1 being used by the beacon are ... ================================================= 233.3.18.1 0.0.0.0 146.97.34.8 WC Upstream interface (RP): rl3 Upstream MRIB next hop (RP): UNKNOWN Upstream RPF'(*,G): UNKNOWN Upstream state: Joined Join timer: 58 Local receiver include WC: ...O.. Joins RP: ...... Joins WC: ...... Join state: ...... 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. Could assert WC: ...O.. I am DR: .OOO.O Immediate olist RP: ...... Immediate olist WC: ...O.. Inherited olist SG: ...O.. Inherited olist SG_RPT: ...O.. PIM include WC: ...O.. =================================================== and also... ============================== 233.3.18.1 193.60.11.36 146.97.34.8 SG SPT DirectlyConnectedS Upstream interface (S): rl2 Upstream interface (RP): rl3 Upstream MRIB next hop (RP): UNKNOWN Upstream MRIB next hop (S): UNKNOWN Upstream RPF'(S,G): UNKNOWN Upstream state: Joined Register state: RegisterPrune RegisterCouldRegister Join timer: 57 Local receiver include WC: ...O.. 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: ...... Assert winner WC: ...... Assert winner SG: ...... Assert lost WC: ...... Assert lost SG: ...... Assert lost SG_RPT: ...... Assert tracking SG: ...OO. Could assert WC: ...O.. Could assert SG: ....O. I am DR: .OOO.O Immediate olist RP: ...... Immediate olist WC: ...O.. Immediate olist SG: ....O. Inherited olist SG: ...OO. Inherited olist SG_RPT: ...O.. PIM include WC: ...O.. PIM include SG: ...... PIM exclude SG: ...... ================================================== is this the correct sort of thing? Are those "UNKNOWN" entries anything to worry about?? What other output should I look at to try to debug this?? Any suggestions? Xorp> show pim mrib DestPrefix NextHopRouter VifName VifIndex MetricPref Metric 0.0.0.0/0 144.124.35.254 rl3 4 1 1 144.124.32.0/22 144.124.34.30 rl3 4 0 0 193.60.10.0/24 193.60.10.90 rl1 2 0 0 193.60.11.0/24 193.60.11.33 rl2 3 0 0 193.60.15.0/24 193.60.15.40 rl0 1 0 0 Xorp> Xorp> show pim neighbors Interface DRpriority NeighborAddr V Mode Holdtime Timeout rl3 none 144.124.35.252 2 Sparse 105 79 rl3 none 144.124.35.253 2 Sparse 105 79 Xorp> Note: there are actually two router engines in our upstream Cisco box. As I understand it, they watch each other and one adopts 144.124.35.254 but they both have there own IP addresses too, hence perhaps the oddities above. Live failover is the plan I understand. Xorp> show pim mfc Group Source RP 233.3.18.1 193.60.11.36 146.97.34.8 Incoming interface : rl2 Outgoing interfaces: ....O. Xorp> so that looks o.k. I guess? yes? I presume the dots match to interfaces in which case I reckon the O matches to rl3 which is my route upstream. Any bright ideas anyone?? Thanks, Dave Price From M.Handley@cs.ucl.ac.uk Tue Jul 20 19:50:38 2004 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Tue, 20 Jul 2004 19:50:38 +0100 Subject: [Xorp-users] Well - I'm half working.... In-Reply-To: Your message of "Tue, 20 Jul 2004 19:00:05 BST." <5047.1090346405@aber.ac.uk> Message-ID: <95650.1090349438@vulture.xorp.org> >[Aside, why does the XORP machine ask www.icir.org to do pointer >DNS lookups every now and then... That machine replies NX. >The enquiries are for addresses that would exist in our >number space but are unused. I suspect there is some low volume >of port scanning goping on perhaps - but why >does it ask www.icir.org to do DNS?] For this release of the LiveCD, I chose to wire in the nameservers. I needed to choose something because if you're running without a floppy (and so can't save configuration), you want to be forced to configure the minimum amount possible on each router boot. So basically I chose to force you to configure the passwords, and defaulted the rest to sensible defaults. The only other alternative seemed to be to run "named" on the router itself with only a built-in knowledge of the root nameservers, but running named seemed to be just one more potential source of problems. The /etc/resolv.conf on the LiveCD contains: search xorp.org nameserver 192.150.187.11 nameserver 128.16.6.8 The first of these is at ICSI, and the second is at UCL. Both will relay requests for you. Like many OS-related things (such as user admin), there ought to be a good way to configure this through the XORP CLI, but we don't yet have that functionality. In any event, you'd still need a sensible default for people that don't have a floppy drive. If you do have a floppy drive, you can override this by manually adding an entry to the manifest file on the floppy, and adding your own resolv.conf file to the floppy to be copied into the /etc MFS at boot time. Hope this explains what's going on! Cheers, Mark From philippe.vanhecke@belnet.be Tue Jul 20 20:37:15 2004 From: philippe.vanhecke@belnet.be (Philippe Van Hecke) Date: Tue, 20 Jul 2004 21:37:15 +0200 Subject: [Xorp-users] Well - I'm half working.... In-Reply-To: <5047.1090346405@aber.ac.uk> References: <5047.1090346405@aber.ac.uk> Message-ID: <200407202137.17402.philippe.vanhecke@belnet.be> Le Tuesday 20 July 2004 20:00, Dave Price a écrit : > What other output should I look at to try to debug this?? Any suggestions? > You can also try this to see who is the dr for each lan # show pim interface the output will be something like that Interface State Mode V PIMstate Priority DRaddr Neighbors eth2 UP Sparse 2 DR 1000 172.24.192.3 2 eth3 UP Sparse 2 NotDR 1 193.190.113.21 2 register_vif UP Sparse 2 DR 1 0.0.0.0 0 __________________________________________________________________ Philippe Van Hecke - BELNET, The Belgian Research Network "In a world without walls or fences, who needs Windows and Gates?" __________________________________________________________________ From Kevin.Smith@fujitsu-siemens.com Tue Jul 20 03:40:25 2004 From: Kevin.Smith@fujitsu-siemens.com (Smith, Kevin) Date: Mon, 19 Jul 2004 19:40:25 -0700 Subject: [Xorp-users] Problem configuring linux box to bridge multicast packets on two subnets Message-ID: <019ABC937D6E0142AECD8AA615730D38010BC041@mlpex04e.usa.fsc.net> This is a multi-part message in MIME format. ------_=_NextPart_001_01C46E02.E96F8F3B Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C46E02.E96F8F3B" ------_=_NextPart_002_01C46E02.E96F8F3B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I'm trying to configuring a Linux box(RH 2.4.20) as a multicast-bridge(hostname =3D "mb-host") to forward = multicast packets between two subnets. I would like the hosts on both subnets(foo and bar)=20 to be members of the same multicast group. On the mb-host machine eth1 is connected to the subnet that includes the host "foo" and eth2 is connected to the subnet containing "bar". When I am logged into bar and I execute "ping 224.225.0.1" I would like both foo and bar to respond and vis-versa (Assuming that multicast client programs on foo and bar are registered to 224.225.0.1). I have not been successfully in getting this to work with pimd, mroute or xorp. When I execute "ping 224.225.0.1" on either subnet only hosts on the same physical subnet respond to the ping. It is my understanding that what I'm trying to do is a legitimate and common thing to do with xorp or pimd. Using tcpdump I can see that the multicast ping packets reach the interface on mb-host but I see no evidence that the packets are forwarded for one interface to the other. Any advice you folks can pass along would be appreciated. Please let me know if I can provide additional information regarding this problem. My best guess is that I need to add some special routes on mb-host. Note that foo can ping bar's IP address and vis-versa through mb-host. The ascii-figure below shows the relevant network setup. Use a non-proportional font(e.g. courier) to see the figure clearly. +------+ +-------+ +------+ |eth1 |<-->|eth1 | | | |222.33| |222.5 | | | | | |eth2 |<-->|eth1 | | | |223.4 | |223.35| |foo | |mb-host| |bar | +------+ +-------+ +------+ Note mb-host is configured with version 1.0 of xorp. Attached is the xorp configuration file that I used(also included below). <>=20 Regards, kevin Kevin Smith PRIMECLUSTER Engineering Fujitsu Siemens Computers, Inc. USA 1250 E. Arques Ave. Sunnyvale, CA 94085 Email : Kevin.Smith@Fujitsu-Siemens.com Begin xorp config file: interfaces { interface eth1 { description: "data interface" enabled: true /* default-system-config */ vif eth1 { enabled: true address 192.168.222.5 { prefix-length: 24 broadcast: 192.168.222.255 enabled: true } } } interface eth2 { description: "data interface" enabled: true /* default-system-config */ vif eth2 { enabled: true address 192.168.223.4 { prefix-length: 24 broadcast: 192.168.223.255 enabled: true } } } } fea { enable-unicast-forwarding4: true /* enable-unicast-forwarding6: true */ } protocols { static { route4 10.20.0.0/16 { nexthop: 10.10.10.20 metric: 1 } mrib-route4 192.168.223.0/24 { nexthop: 192.168.222.5 metric: 1 } } } plumbing { mfea4 { enabled: true interface eth1 { vif eth1 { enabled: true } } interface eth2 { vif eth2 { enabled: true } } interface register_vif { vif register_vif { /* Note: this vif should be always enabled */ enabled: true } } traceoptions { flag all { enabled: true } } } } protocols { igmp { enabled: true interface eth1 { vif eth1 { enabled: true } } interface eth2 { vif eth2 { enabled: true } } traceoptions { flag all { enabled: true } } } } protocols { pimsm4 { interface eth1 { vif eth1 { enabled: true } } interface eth2 { vif eth2 { enabled: true } } interface register_vif { vif register_vif { /* Note: this vif should be always enabled */ enabled: true } } static-rps { rp 192.168.222.5 { group-prefix 224.0.0.0/4 { rp-priority: 192 hash-mask-len: 30 } } } /* bootstrap { cand-bsr { scope-zone 224.0.0.0/4 { cand-bsr-by-vif-name: "eth1" bsr-priority: 1 } } cand-rp { group-prefix 224.0.0.0/4 { cand-rp-by-vif-name: "eth1" rp-priority: 192 rp-holdtime: 150 } } } */ switch-to-spt-threshold { enabled: true interval-sec: 100 bytes: 102400 } traceoptions { flag all { enabled: true } } } } protocols { fib2mrib { enabled: true } } End of email message. ------_=_NextPart_002_01C46E02.E96F8F3B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Problem configuring linux box to bridge multicast packets on two = subnets

Hello,
        I'm trying to = configuring a Linux box(RH 2.4.20)
        as a = multicast-bridge(hostname =3D "mb-host") to forward multicast = packets
        between two = subnets.
        I would like = the hosts on both subnets(foo and bar)
        to be members = of the same multicast group.
        On the mb-host = machine eth1 is connected to the subnet that includes
        the host = "foo" and eth2 is connected to the subnet containing = "bar".
        When I am = logged into bar and I execute "ping 224.225.0.1"
        I would like = both foo and bar to respond and vis-versa
        (Assuming that = multicast client programs on foo and bar are registered
         to = 224.225.0.1).
        I have not = been successfully in getting this to work
        with pimd, = mroute or xorp. When I execute "ping 224.225.0.1"
        on either = subnet only hosts on the same physical subnet respond
        to the ping. = It is my understanding that what I'm trying
        to do is a = legitimate and common thing to do with xorp or pimd.
        Using tcpdump = I can see that the multicast ping packets reach the
        interface on = mb-host but I see no evidence that the packets
        are forwarded = for one interface to the other.

        Any advice you = folks can pass along would be appreciated.
        Please let me = know if I can provide additional information
        regarding this = problem. My best guess is that
        I need to add = some special routes on mb-host.
        Note that foo = can ping bar's IP address and vis-versa through mb-host.

        The = ascii-figure below shows the relevant network setup.
        Use a = non-proportional font(e.g. courier) to see the figure clearly.

         &n= bsp;      +------+    = +-------+    +------+
         &n= bsp;      |eth1  = |<-->|eth1   |    = |      |
         &n= bsp;      |222.33|    = |222.5  |    |      = |
         &n= bsp;      |      = |    |eth2   |<-->|eth1  |
         &n= bsp;      |      = |    |223.4  |    |223.35|
         &n= bsp;      |foo   |    = |mb-host|    |bar   |
         &n= bsp;      +------+    = +-------+    +------+

        Note mb-host = is configured with version 1.0 of xorp.

        Attached is = the xorp configuration file that I used(also included below).
= <<xorp_config.txt>>
Regards, kevin
Kevin Smith
PRIMECLUSTER Engineering

Fujitsu Siemens Computers, Inc. = USA
1250 E. Arques Ave.
Sunnyvale, CA 94085

Email : = Kevin.Smith@Fujitsu-Siemens.com
Begin xorp config file:
interfaces {
    interface eth1 = {
         &nbs= p;      description: "data = interface"
         &nbs= p;      enabled: true
         &nbs= p;      /* default-system-config */
         &nbs= p;      vif eth1 {
         &nbs= p;            = ;  enabled: true
         &nbs= p;            = ;  address 192.168.222.5 {
         &nbs= p;            = ;          prefix-length: = 24
         &nbs= p;            = ;          broadcast: = 192.168.222.255
         &nbs= p;            = ;          enabled: = true
         &nbs= p;            = ;  }
         &nbs= p;      }
    }
    interface eth2 = {
         &nbs= p;      description: "data = interface"
         &nbs= p;      enabled: true
         &nbs= p;      /* default-system-config */
         &nbs= p;      vif eth2 {
         &nbs= p;            = ;  enabled: true
         &nbs= p;            = ;  address 192.168.223.4 {
         &nbs= p;            = ;          prefix-length: = 24
         &nbs= p;            = ;          broadcast: = 192.168.223.255
         &nbs= p;            = ;          enabled: = true
         &nbs= p;            = ;  }
         &nbs= p;      }
    }
}

fea {
        = enable-unicast-forwarding4: true
        /* = enable-unicast-forwarding6: true */
}

protocols {
        static = {
         &nbs= p;      route4 10.20.0.0/16 {
         &nbs= p;            = ;  nexthop: 10.10.10.20
         &nbs= p;            = ;  metric: 1
         &nbs= p;      }
         &nbs= p;      mrib-route4 192.168.223.0/24 {
         &nbs= p;            = ;  nexthop: 192.168.222.5
         &nbs= p;            = ;  metric: 1
         &nbs= p;      }
        }
}

plumbing {
        mfea4 {
         &nbs= p;      enabled: true
         &nbs= p;      interface eth1 {
         &nbs= p;            = ;  vif eth1 {
         &nbs= p;            = ;          enabled: = true
         &nbs= p;            = ;  }
         &nbs= p;      }
         &nbs= p;      interface eth2 {
         &nbs= p;            = ;  vif eth2 {
         &nbs= p;            = ;          enabled: = true
         &nbs= p;            = ;  }
         &nbs= p;      }
         &nbs= p;      interface register_vif {
         &nbs= p;            = ;  vif register_vif {
         &nbs= p;            = ;          /* Note: this = vif should be always enabled */
         &nbs= p;            = ;          enabled: = true
         &nbs= p;            = ;  }
         &nbs= p;      }
         &nbs= p;      traceoptions {
         &nbs= p;            = ;  flag all {
         &nbs= p;            = ;          enabled: = true
         &nbs= p;            = ;  }
         &nbs= p;      }
    }
}

protocols {
        igmp {
         &nbs= p;      enabled: true
         &nbs= p;      interface eth1 {
         &nbs= p;            = ;  vif eth1 {
         &nbs= p;            = ;          enabled: = true
         &nbs= p;            = ;  }
         &nbs= p;      }
         &nbs= p;      interface eth2 {
         &nbs= p;            = ;  vif eth2 {
         &nbs= p;            = ;          enabled: = true
         &nbs= p;            = ;  }
         &nbs= p;      }
         &nbs= p;      traceoptions {
         &nbs= p;            = ;  flag all {
         &nbs= p;            = ;          enabled: = true
         &nbs= p;            = ;  }
         &nbs= p;      }
        }
}

protocols {
        pimsm4 = {
         &nbs= p;      interface eth1 {
         &nbs= p;            = ;  vif eth1 {
         &nbs= p;            = ;          enabled: = true
         &nbs= p;            = ;  }
         &nbs= p;      }
         &nbs= p;      interface eth2 {
         &nbs= p;            = ;  vif eth2 {
         &nbs= p;            = ;          enabled: = true
         &nbs= p;            = ;  }
         &nbs= p;      }
         &nbs= p;      interface register_vif {
         &nbs= p;            = ;  vif register_vif {
         &nbs= p;            = ;          /* Note: this = vif should be always enabled */
         &nbs= p;            = ;          enabled: = true
         &nbs= p;            = ;  }
         &nbs= p;      }
        static-rps = {
         &nbs= p;  rp 192.168.222.5 {
         &nbs= p;      group-prefix 224.0.0.0/4 {
         &nbs= p;          rp-priority: = 192
         &nbs= p;          hash-mask-len: = 30
         &nbs= p;      }
         &nbs= p;  }
        }
/*
        bootstrap = {
         &nbs= p;  cand-bsr {
         &nbs= p;      scope-zone 224.0.0.0/4 {
         &nbs= p;          = cand-bsr-by-vif-name: "eth1"
         &nbs= p;          bsr-priority: = 1
         &nbs= p;      }
         &nbs= p;  }

         &nbs= p;  cand-rp {
         &nbs= p;      group-prefix 224.0.0.0/4 {
         &nbs= p;          = cand-rp-by-vif-name: "eth1"
         &nbs= p;          rp-priority: = 192
         &nbs= p;          rp-holdtime: = 150
         &nbs= p;      }
         &nbs= p;  }
        }
*/

         &nbs= p;      switch-to-spt-threshold {
         &nbs= p;            = ;  enabled: true
         &nbs= p;            = ;  interval-sec: 100
         &nbs= p;            = ;  bytes: 102400
         &nbs= p;      }
         &nbs= p;      traceoptions {
         &nbs= p;            = ;  flag all {
         &nbs= p;            = ;          enabled: = true
         &nbs= p;            = ;  }
         &nbs= p;      }
    }
}

protocols {
        fib2mrib = {
         &nbs= p;      enabled: true
        }
}
End of email message.

------_=_NextPart_002_01C46E02.E96F8F3B-- ------_=_NextPart_001_01C46E02.E96F8F3B Content-Type: text/plain; name="xorp_config.txt" Content-Transfer-Encoding: base64 Content-Description: xorp_config.txt Content-Disposition: attachment; filename="xorp_config.txt" aW50ZXJmYWNlcyB7DQogICAgaW50ZXJmYWNlIGV0aDEgew0KCQlkZXNjcmlwdGlvbjogImRhdGEg aW50ZXJmYWNlIg0KCQllbmFibGVkOiB0cnVlDQoJCS8qIGRlZmF1bHQtc3lzdGVtLWNvbmZpZyAq Lw0KCQl2aWYgZXRoMSB7DQoJCQllbmFibGVkOiB0cnVlDQoJCQlhZGRyZXNzIDE5Mi4xNjguMjIy LjUgew0KCQkJCXByZWZpeC1sZW5ndGg6IDI0DQoJCQkJYnJvYWRjYXN0OiAxOTIuMTY4LjIyMi4y NTUNCgkJCQllbmFibGVkOiB0cnVlDQoJCQl9DQoJCX0NCiAgICB9DQogICAgaW50ZXJmYWNlIGV0 aDIgew0KCQlkZXNjcmlwdGlvbjogImRhdGEgaW50ZXJmYWNlIg0KCQllbmFibGVkOiB0cnVlDQoJ CS8qIGRlZmF1bHQtc3lzdGVtLWNvbmZpZyAqLw0KCQl2aWYgZXRoMiB7DQoJCQllbmFibGVkOiB0 cnVlDQoJCQlhZGRyZXNzIDE5Mi4xNjguMjIzLjQgew0KCQkJCXByZWZpeC1sZW5ndGg6IDI0DQoJ CQkJYnJvYWRjYXN0OiAxOTIuMTY4LjIyMy4yNTUNCgkJCQllbmFibGVkOiB0cnVlDQoJCQl9DQoJ CX0NCiAgICB9DQp9DQoNCmZlYSB7DQoJZW5hYmxlLXVuaWNhc3QtZm9yd2FyZGluZzQ6IHRydWUN CgkvKiBlbmFibGUtdW5pY2FzdC1mb3J3YXJkaW5nNjogdHJ1ZSAqLw0KfQ0KDQpwcm90b2NvbHMg ew0KCXN0YXRpYyB7DQoJCXJvdXRlNCAxMC4yMC4wLjAvMTYgew0KCQkJbmV4dGhvcDogMTAuMTAu MTAuMjANCgkJCW1ldHJpYzogMQ0KCQl9DQoJCW1yaWItcm91dGU0IDE5Mi4xNjguMjIzLjAvMjQg ew0KCQkJbmV4dGhvcDogMTkyLjE2OC4yMjIuNQ0KCQkJbWV0cmljOiAxDQoJCX0NCgl9DQp9DQoN CnBsdW1iaW5nIHsNCgltZmVhNCB7DQoJCWVuYWJsZWQ6IHRydWUNCgkJaW50ZXJmYWNlIGV0aDEg ew0KCQkJdmlmIGV0aDEgew0KCQkJCWVuYWJsZWQ6IHRydWUNCgkJCX0NCgkJfQ0KCQlpbnRlcmZh Y2UgZXRoMiB7DQoJCQl2aWYgZXRoMiB7DQoJCQkJZW5hYmxlZDogdHJ1ZQ0KCQkJfQ0KCQl9DQoJ CWludGVyZmFjZSByZWdpc3Rlcl92aWYgew0KCQkJdmlmIHJlZ2lzdGVyX3ZpZiB7DQoJCQkJLyog Tm90ZTogdGhpcyB2aWYgc2hvdWxkIGJlIGFsd2F5cyBlbmFibGVkICovDQoJCQkJZW5hYmxlZDog dHJ1ZQ0KCQkJfQ0KCQl9DQoJCXRyYWNlb3B0aW9ucyB7DQoJCQlmbGFnIGFsbCB7DQoJCQkJZW5h YmxlZDogdHJ1ZQ0KCQkJfQ0KCQl9DQogICAgfQ0KfQ0KDQpwcm90b2NvbHMgew0KCWlnbXAgew0K CQllbmFibGVkOiB0cnVlDQoJCWludGVyZmFjZSBldGgxIHsNCgkJCXZpZiBldGgxIHsNCgkJCQll bmFibGVkOiB0cnVlDQoJCQl9DQoJCX0NCgkJaW50ZXJmYWNlIGV0aDIgew0KCQkJdmlmIGV0aDIg ew0KCQkJCWVuYWJsZWQ6IHRydWUNCgkJCX0NCgkJfQ0KCQl0cmFjZW9wdGlvbnMgew0KCQkJZmxh ZyBhbGwgew0KCQkJCWVuYWJsZWQ6IHRydWUNCgkJCX0NCgkJfQ0KCX0NCn0NCg0KcHJvdG9jb2xz IHsNCglwaW1zbTQgew0KCQlpbnRlcmZhY2UgZXRoMSB7DQoJCQl2aWYgZXRoMSB7DQoJCQkJZW5h YmxlZDogdHJ1ZQ0KCQkJfQ0KCQl9DQoJCWludGVyZmFjZSBldGgyIHsNCgkJCXZpZiBldGgyIHsN CgkJCQllbmFibGVkOiB0cnVlDQoJCQl9DQoJCX0NCgkJaW50ZXJmYWNlIHJlZ2lzdGVyX3ZpZiB7 DQoJCQl2aWYgcmVnaXN0ZXJfdmlmIHsNCgkJCQkvKiBOb3RlOiB0aGlzIHZpZiBzaG91bGQgYmUg YWx3YXlzIGVuYWJsZWQgKi8NCgkJCQllbmFibGVkOiB0cnVlDQoJCQl9DQoJCX0NCglzdGF0aWMt cnBzIHsNCgkgICAgcnAgMTkyLjE2OC4yMjIuNSB7DQoJCWdyb3VwLXByZWZpeCAyMjQuMC4wLjAv NCB7DQoJCSAgICBycC1wcmlvcml0eTogMTkyDQoJCSAgICBoYXNoLW1hc2stbGVuOiAzMA0KCQl9 DQoJICAgIH0NCgl9DQovKg0KCWJvb3RzdHJhcCB7DQoJICAgIGNhbmQtYnNyIHsNCgkJc2NvcGUt em9uZSAyMjQuMC4wLjAvNCB7DQoJCSAgICBjYW5kLWJzci1ieS12aWYtbmFtZTogImV0aDEiDQoJ CSAgICBic3ItcHJpb3JpdHk6IDENCgkJfQ0KCSAgICB9DQoNCgkgICAgY2FuZC1ycCB7DQoJCWdy b3VwLXByZWZpeCAyMjQuMC4wLjAvNCB7DQoJCSAgICBjYW5kLXJwLWJ5LXZpZi1uYW1lOiAiZXRo MSINCgkJICAgIHJwLXByaW9yaXR5OiAxOTINCgkJICAgIHJwLWhvbGR0aW1lOiAxNTANCgkJfQ0K CSAgICB9DQoJfQ0KKi8NCg0KCQlzd2l0Y2gtdG8tc3B0LXRocmVzaG9sZCB7DQoJCQllbmFibGVk OiB0cnVlDQoJCQlpbnRlcnZhbC1zZWM6IDEwMA0KCQkJYnl0ZXM6IDEwMjQwMA0KCQl9DQoJCXRy YWNlb3B0aW9ucyB7DQoJCQlmbGFnIGFsbCB7DQoJCQkJZW5hYmxlZDogdHJ1ZQ0KCQkJfQ0KCQl9 DQogICAgfQ0KfQ0KDQpwcm90b2NvbHMgew0KCWZpYjJtcmliIHsNCgkJZW5hYmxlZDogdHJ1ZQ0K CX0NCn0NCg== ------_=_NextPart_001_01C46E02.E96F8F3B-- From M.Handley@cs.ucl.ac.uk Wed Jul 21 00:19:52 2004 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Wed, 21 Jul 2004 00:19:52 +0100 Subject: [Xorp-users] Adding a new user to a LiveCD boot of XORP In-Reply-To: Your message of "Fri, 16 Jul 2004 18:16:13 BST." <29340.1089998173@aber.ac.uk> Message-ID: <97597.1090365592@vulture.xorp.org> >The main reason I think I need to be "root" is that >there is no ping or traceroute command available in xorpsh >and so its a bit hard trying to see what works from that end.... I just committed very simple ping and traceroute support for xorpsh into CVS. No support yet for command line flags, but at least the basic command is there. Welcome to XORP on vulture.xorp.org Xorp> ? Possible completions: configure Switch to configuration mode help Provide help with commands ping Ping a hostname or IP address quit Quit this command session show Display information about the system traceroute Trace the IP route to a hostname or IP address Xorp> ping ? Possible completions: <[Enter]> Execute this command Give a hostname or IP address to ping. Xorp> ping www.xorp.org PING www.xorp.org (192.150.187.19): 56 data bytes 64 bytes from 192.150.187.19: icmp_seq=0 ttl=46 time=156.402 ms 64 bytes from 192.150.187.19: icmp_seq=1 ttl=46 time=157.545 ms 64 bytes from 192.150.187.19: icmp_seq=2 ttl=46 time=157.366 ms 64 bytes from 192.150.187.19: icmp_seq=3 ttl=46 time=157.197 ms 64 bytes from 192.150.187.19: icmp_seq=4 ttl=46 time=157.069 ms Xorp> ping www.xorp.org Command interrupted! Xorp> - Mark From pavlin@icir.org Wed Jul 21 01:45:32 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 20 Jul 2004 17:45:32 -0700 Subject: [Xorp-users] Setting default routes In-Reply-To: Message from Dave Price of "Tue, 20 Jul 2004 09:29:55 BST." <3752.1090312195@aber.ac.uk> Message-ID: <200407210045.i6L0jW8U027024@possum.icir.org> > atanu@icsi.berkeley.edu said: > > I tried the following in my config file, it worked for me. > > ---------------------------------------- protocols { > > static { > > route4 0.0.0.0/0 { > > nexthop: 144.124.0.2 > > metric: 1 > > } > > } } ---------------------------------------- > > That lookss exactly the same as what I believe I had > added yesterday when I could not seem to get it to work. I'll > try again. Slight complication in so much as we subnet > 144.124.x.x (at 22 bits) and so the interface to the default > is on a subnet of this, but I can't see that should change things. > > I have NOT enabled the unicast FEA as I don't actually want this box > to unicast forward between its ports, I plan to just get it > to act as a multicast router. I wonder if that interacts. > Anyway, I'll try to static default route again. Dave, If you are going to use the router only for IPv4 multicast routing, then you don't have to enable the unicast forwarding. However, I should let you know that if you are going to use it for IPv6 multicast routing as well, and if you are using a KAME-based stack (e.g., *BSD), then the semantic is that you must have the following flag set: sysctl net.inet6.ip6.forwarding=1 The above flag enables both IPv6 unicast and multicast forwarding. You can set it from the command line (as a root) before starting XORP, or from the XORP configuration file: fea { /* enable-unicast-forwarding4: true */ enable-unicast-forwarding6: true } Hence, because of the difference in the semantics between IPv4 and IPv6, in general I recommend that both IPv4 (net.inet.ip.forwarding) and IPv6 (net.inet6.ip6.forwarding) forwarding flags are enabled. In your case, if none of your unicast routers have your multicast router as a next-hop router for a destination, then enabling the IPv4 unicast forwarding flag shoudn't make any difference. Pavlin > atanu@icsi.berkeley.edu said: > > I believe that we only speak RIPv2. > > I had come to that conclusion, the docs implied that and > I could see multicast RIPv2 requests coming out of the xorp > box when I did enable RIP. It was ignoring > RIPv1 announcements that were arriving. > > > atanu@icsi.berkeley.edu said: > > The simplest way of discovering all the settings for a protocol is to > > use the xorpsh. In configure mode it will show all the settings along > > with help text. > > That lets you discover their existence, but it does not give > precise descriptions of their role etc. Some have names > which might be interpreted in more than one way I felt. > > > atanu@icsi.berkeley.edu said: > > We are intending to make some sample configuration files available. > > Your configuration file would be a great candidate. > > assuming I can get it to work :-) > > I'll go and have another play.... > > Dave Price From pavlin@icir.org Wed Jul 21 02:07:12 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 20 Jul 2004 18:07:12 -0700 Subject: [Xorp-users] Was: Setting default routes Now: general config problem I think... In-Reply-To: Message from Dave Price of "Tue, 20 Jul 2004 13:26:07 BST." <4344.1090326367@aber.ac.uk> Message-ID: <200407210107.i6L17C8U027178@possum.icir.org> > I have created all the protocols-igmp stuff > for all four interfaces and the register_vif > (once I worked out it was an underscore and not a dot!) > > [Aside: when I did do it with a dot in name, it let > me create it all but then gave a syntax error when > I tried to commit the change. I guess that's correct, > but it was sort of only by luck I spotted I had the dot > and not an underscore] Interesting. The behavior is correct, but it needs to be improved to spot such errors when attempting to create the interface. I will add it to our TODO list, but in the mean time please be more careful with such typos :) > I have created the protocols-pimsm4 stuff for all four > interfaces, the register_vif interface and set a static RP > to point to the distant router. I set the switch-to... > stuff to match the documents. > > [Aside: do I really need to add all four interfaces > into the PIMSM setting as the only PIM neighbour > is upstream and I guess only IGMP is used to signal > on the other three networks that hosts are interested > in multicast traffic etc. I only added the upstream > one first but that seemd to not work so I added > the other three, but I don't think its really working now > anyway...] [Repeating Philippe's answer:] Yes, you have to enable PIMSM on all interfaces you are going to use for multicast forwarding. This includes the interfaces with only multicast senders or receivers. > I have not enabled the fib2mrib stuff as I only have > directly connected networks plus the default route > which I have manually added as a static-mrib4 entry. That's fine. If you are going to install a default route into the MRIB, then you don't need the fib2mrib stuff. > I've attached a copy of /etc/xorp.cfg to this email, anyone > someone can have a look for me and spot any obvious > (or less obvious :-) ) problems.... The configuration file looks fine. However, for debugging purpose I'd recommend that you set all "traceoptions" flags to "true", so you can see various debug messages that may be helpful spotting the problem. Pavlin > > Dave Price > > > --==_Exmh_-21163577130 > Content-Type: text/plain ; name="xorp.cfg"; charset=us-ascii > Content-Description: xorp.cfg > Content-Disposition: attachment; filename="xorp.cfg" > > /*XORP Configuration File, v1.0*/ > interfaces { > interface rl0 { > description: "Ethernet" > vif rl0 { > enabled: true > address 193.60.15.40 { > enabled: true > broadcast: 193.60.15.255 > prefix-length: 24 > } > } > enabled: true > } > interface rl1 { > description: "Ethernet" > vif rl1 { > enabled: true > address 193.60.10.90 { > enabled: true > broadcast: 193.60.10.255 > prefix-length: 24 > } > } > enabled: true > } > interface rl2 { > description: "Ethernet" > vif rl2 { > enabled: true > address 193.60.11.33 { > enabled: true > prefix-length: 24 > broadcast: 193.60.11.255 > } > } > enabled: true > } > interface rl3 { > description: "Ethernet" > vif rl3 { > enabled: true > address 144.124.34.30 { > enabled: true > broadcast: 144.124.35.255 > prefix-length: 22 > } > } > enabled: true > } > interface lo0 { > description: "Loopback interface" > vif lo0 { > enabled: true > } > enabled: true > } > targetname: "fea" > } > protocols { > static { > route4 0.0.0.0/0 { > metric: 1 > nexthop: 144.124.35.254 > } > targetname: "static_routes" > enabled: true > mrib-route4 0.0.0.0/0 { > metric: 1 > nexthop: 144.124.35.254 > } > } > igmp { > interface rl3 { > vif rl3 { > enabled: true > } > } > interface rl2 { > vif rl2 { > enabled: true > } > } > interface rl1 { > vif rl1 { > enabled: true > } > } > interface rl0 { > vif rl0 { > enabled: true > } > } > targetname: "IGMP" > enabled: true > traceoptions { > flag { > all { > enabled: false > } > } > } > } > pimsm4 { > interface rl3 { > vif rl3 { > enabled: true > dr-priority: 1 > } > } > interface register_vif { > vif register_vif { > enabled: true > dr-priority: 1 > } > } > interface rl0 { > vif rl0 { > enabled: true > dr-priority: 1 > } > } > interface rl1 { > vif rl1 { > enabled: true > dr-priority: 1 > } > } > interface rl2 { > vif rl2 { > enabled: true > dr-priority: 1 > } > } > targetname: "PIMSM_4" > enabled: true > static-rps { > rp 146.97.34.8 { > group-prefix 224.0.0.0/4 { > rp-priority: 192 > hash-mask-len: 30 > } > } > } > switch-to-spt-threshold { > enabled: true > interval-sec: 100 > bytes: 102400 > } > traceoptions { > flag { > all { > enabled: false > } > } > } > } > } > plumbing { > mfea4 { > interface rl3 { > vif rl3 { > enabled: true > } > } > interface rl2 { > vif rl2 { > enabled: true > } > } > interface rl1 { > vif rl1 { > enabled: true > } > } > interface rl0 { > vif rl0 { > enabled: true > } > } > interface register_vif { > vif register_vif { > enabled: true > } > } > targetname: "MFEA_4" > enabled: true > traceoptions { > flag { > all { > enabled: false > } > } > } > } > } > > --==_Exmh_-21163577130-- > > > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From edrt@citiz.net Wed Jul 21 02:17:45 2004 From: edrt@citiz.net (edrt) Date: Wed, 21 Jul 2004 9:17:45 +0800 Subject: [Xorp-users] Well - I'm half working.... Message-ID: <200407210119.AFH94895@mira1.citiz.net> Hi Dave : >From the (*, 233.3.18.1) TIB state, it seems that * rl3 of the Xorp router shares the address 146.97.34.8 * rl3 is the RP of group 233.3.18.1 * RP(233.3.18.1) only detect local multicast receiver, but not receiving any downstream Join(*,G) >From the neighbor info, it seems that * rl3 also shares address on subnet 144.124.32.0/22, and form adjacency with cisco router using this address, (not 146.97.34.8) Because you didn't show other (S,G) states, I can't deduce whether other multicast beacons are also directly connected with the Xorp router. So I made the assumption below * other multicast beacons (except 193.60.11.36) are _not_ directly connected with the Xorp router * all multicast beacons are using IGMPv2 (not IGMPv3) If the above deductions are right, could you also help to check things below : * check on cisco router to see whether it creates any (*,233.3.18.1) TIB state * check on cisco router to see whether it knows "RP(233.3.18.1) = 146.97.34.8" * check on cisco router to see whether it knows how to reach the 146.97.34.8 * sniff on Xorp/rl3 to see whether it receive any register packet or Join(*,G) from cisco router And could you also provide these info of the Xorp router to help debugging: * "show pim interface" * "show pim bootstrap" * "show pim rps" Thanks Eddy >Dear All, > > After help received so far (thanks Mark for new LiveCD), >I'm now half working. > > Following a local suggestion (Thanks Hefin), I've >set up a multicast beacon client reporting to the JANET >beacon monitoring system from my Sun (193.60.11.36). > > As far as I can tell, the monitoring >system, and other sites are reporting seeing my multicast >beacon packets being sent to 233.3.18.1 > > However, my beacon sees no incoming multicasts >from other beacons, seems to report no reception on the monitoring >software and indeed, using tcpdump/snoop on various interfaces >I can see my outgoing packets but none coming back. > >[Aside, why does the XORP machine ask www.icir.org to do pointer >DNS lookups every now and then... That machine replies NX. >The enquiries are for addresses that would exist in our >number space but are unused. I suspect there is some low volume >of port scanning goping on perhaps - but why >does it ask www.icir.org to do DNS?] > >I'm not quite sure what to expect as the output of the various >xorp "show" commands, but there are a view cases where it >says "UNKNOWN" for values of things and I wondered what the >significance of that was. For instance if I issue > >"show pim join all" > >then I get lots of output, selecting just a bit, the output >sections for the group 233.3.18.1 being used by the beacon >are ... > >================================================= >233.3.18.1 0.0.0.0 146.97.34.8 WC > Upstream interface (RP): rl3 > Upstream MRIB next hop (RP): UNKNOWN > Upstream RPF'(*,G): UNKNOWN > Upstream state: Joined > Join timer: 58 > Local receiver include WC: ...O.. > Joins RP: ...... > Joins WC: ...... > Join state: ...... > 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. > Could assert WC: ...O.. > I am DR: .OOO.O > Immediate olist RP: ...... > Immediate olist WC: ...O.. > Inherited olist SG: ...O.. > Inherited olist SG_RPT: ...O.. > PIM include WC: ...O.. >=================================================== > >and also... > >============================== >233.3.18.1 193.60.11.36 146.97.34.8 SG SPT DirectlyConnectedS > Upstream interface (S): rl2 > Upstream interface (RP): rl3 > Upstream MRIB next hop (RP): UNKNOWN > Upstream MRIB next hop (S): UNKNOWN > Upstream RPF'(S,G): UNKNOWN > Upstream state: Joined > Register state: RegisterPrune RegisterCouldRegister > Join timer: 57 > Local receiver include WC: ...O.. > 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: ...... > Assert winner WC: ...... > Assert winner SG: ...... > Assert lost WC: ...... > Assert lost SG: ...... > Assert lost SG_RPT: ...... > Assert tracking SG: ...OO. > Could assert WC: ...O.. > Could assert SG: ....O. > I am DR: .OOO.O > Immediate olist RP: ...... > Immediate olist WC: ...O.. > Immediate olist SG: ....O. > Inherited olist SG: ...OO. > Inherited olist SG_RPT: ...O.. > PIM include WC: ...O.. > PIM include SG: ...... > PIM exclude SG: ...... >================================================== > >is this the correct sort of thing? Are those "UNKNOWN" >entries anything to worry about?? > > >What other output should I look at to try to debug this?? Any suggestions? > >Xorp> show pim mrib >DestPrefix NextHopRouter VifName VifIndex MetricPref Metric >0.0.0.0/0 144.124.35.254 rl3 4 1 1 >144.124.32.0/22 144.124.34.30 rl3 4 0 0 >193.60.10.0/24 193.60.10.90 rl1 2 0 0 >193.60.11.0/24 193.60.11.33 rl2 3 0 0 >193.60.15.0/24 193.60.15.40 rl0 1 0 0 >Xorp> > >Xorp> show pim neighbors >Interface DRpriority NeighborAddr V Mode Holdtime Timeout >rl3 none 144.124.35.252 2 Sparse 105 79 >rl3 none 144.124.35.253 2 Sparse 105 79 >Xorp> > >Note: there are actually two router engines in our >upstream Cisco box. As I understand it, they watch each other and >one adopts 144.124.35.254 but they both have there own >IP addresses too, hence perhaps the oddities above. Live >failover is the plan I understand. > >Xorp> show pim mfc >Group Source RP >233.3.18.1 193.60.11.36 146.97.34.8 > Incoming interface : rl2 > Outgoing interfaces: ....O. >Xorp> > >so that looks o.k. I guess? yes? I presume the dots >match to interfaces in which case I reckon the O >matches to rl3 which is my route upstream. > >Any bright ideas anyone?? > >Thanks, > >Dave Price > >_______________________________________________ >Xorp-users mailing list >Xorp-users@xorp.org >http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From edrt@citiz.net Wed Jul 21 02:39:43 2004 From: edrt@citiz.net (edrt) Date: Wed, 21 Jul 2004 9:39:43 +0800 Subject: [Xorp-users] Well - I'm half working.... Message-ID: <200407210141.AGN92351@mira2.citiz.net> >Hi Dave : > >From the (*, 233.3.18.1) TIB state, it seems that > * rl3 of the Xorp router shares the address 146.97.34.8 > * rl3 is the RP of group 233.3.18.1 > * RP(233.3.18.1) only detect local multicast receiver, > but not receiving any downstream Join(*,G) > >From the neighbor info, it seems that > * rl3 also shares address on subnet 144.124.32.0/22, > and form adjacency with cisco router using this address, > (not 146.97.34.8) > >Because you didn't show other (S,G) states, I can't deduce whether other >multicast beacons are also directly connected with the Xorp router. >So I made the assumption below > * other multicast beacons (except 193.60.11.36) are _not_ directly > connected with the Xorp router > * all multicast beacons are using IGMPv2 (not IGMPv3) > >If the above deductions are right, >could you also help to check things below : > * check on cisco router to see whether it creates any (*,233.3.18.1) TIB state > * check on cisco router to see whether it knows "RP(233.3.18.1) = 146.97.34.8" > * check on cisco router to see whether it knows how to reach the 146.97.34.8 > * sniff on Xorp/rl3 to see whether it receive any register packet or Join(*,G) from cisco router > >And could you also provide these info of the Xorp router >to help debugging: > * "show pim interface" > * "show pim bootstrap" > * "show pim rps" > >Thanks >Eddy BTW, I'm just curious about the problem and help collecting information. Pavlin may help you solve the problem :) From pavlin@icir.org Wed Jul 21 05:07:30 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 20 Jul 2004 21:07:30 -0700 Subject: [Xorp-users] Well - I'm half working.... In-Reply-To: Message from Dave Price of "Tue, 20 Jul 2004 19:00:05 BST." <5047.1090346405@aber.ac.uk> Message-ID: <200407210407.i6L47U8U028255@possum.icir.org> > Following a local suggestion (Thanks Hefin), I've > set up a multicast beacon client reporting to the JANET > beacon monitoring system from my Sun (193.60.11.36). > > As far as I can tell, the monitoring > system, and other sites are reporting seeing my multicast > beacon packets being sent to 233.3.18.1 The reason that other sites are seeing your multicast beacon packets is because your XORP multicast router is unicasting them encapsulated within PIM Register packets. Those packets are sent directly to the RP, and don't depend on any other multicast routers [see below]. > I'm not quite sure what to expect as the output of the various > xorp "show" commands, but there are a view cases where it > says "UNKNOWN" for values of things and I wondered what the > significance of that was. For instance if I issue > > "show pim join all" Typically, you need only the "show pim join" command. The difference between the "show pim join" and "show pim join all" is that the latter shows the (*,*,RP) entries that were automatically created per RP (for implementation-specific reasons). > then I get lots of output, selecting just a bit, the output > sections for the group 233.3.18.1 being used by the beacon > are ... > > ================================================= > 233.3.18.1 0.0.0.0 146.97.34.8 WC > Upstream interface (RP): rl3 > Upstream MRIB next hop (RP): UNKNOWN > Upstream RPF'(*,G): UNKNOWN > Upstream state: Joined > Join timer: 58 > Local receiver include WC: ...O.. > Joins RP: ...... > Joins WC: ...... > Join state: ...... > 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. > Could assert WC: ...O.. > I am DR: .OOO.O > Immediate olist RP: ...... > Immediate olist WC: ...O.. > Inherited olist SG: ...O.. > Inherited olist SG_RPT: ...O.. > PIM include WC: ...O.. > =================================================== The problem is that the RPF'(*,G) entry is UNKNOWN, therefore the PIM Join messages aren't sent. This entry is suppose to point to the next-hop router toward the RP (146.97.34.8). >From your "show pim mrib" output it appears that the next-hop router toward the RP should be 144.124.35.254. However, the "show pim neighbors" output does not show a neighbor with such IP address. Therefore, it is question of finding why you don't have a PIM neighbor with IP address of 144.124.35.254. To debug the problem you can start with: * Run tcpdump on the rl3 interface and look for PIM Hello messages from 144.124.35.254 * Enable the traceoptions debug messages and look for PIM-SM debug messages like: [ 2004/07/20 20:54:24 TRACE test_pim PIM ] RX PIM_HELLO from 10.3.0.2 to 224.0.0.13 on vif dc1 BTW, does the upstream router 144.124.35.254 has more than one IP addresses assigned on that interface? Also, if tcpdump shows there are PIM Hello messages from 144.124.35.254, can you send the tcpdump of one of those messages. > and also... > > ============================== > 233.3.18.1 193.60.11.36 146.97.34.8 SG SPT DirectlyConnectedS > Upstream interface (S): rl2 > Upstream interface (RP): rl3 > Upstream MRIB next hop (RP): UNKNOWN > Upstream MRIB next hop (S): UNKNOWN > Upstream RPF'(S,G): UNKNOWN > Upstream state: Joined > Register state: RegisterPrune RegisterCouldRegister > Join timer: 57 > Local receiver include WC: ...O.. > 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: ...... > Assert winner WC: ...... > Assert winner SG: ...... > Assert lost WC: ...... > Assert lost SG: ...... > Assert lost SG_RPT: ...... > Assert tracking SG: ...OO. > Could assert WC: ...O.. > Could assert SG: ....O. > I am DR: .OOO.O > Immediate olist RP: ...... > Immediate olist WC: ...O.. > Immediate olist SG: ....O. > Inherited olist SG: ...OO. > Inherited olist SG_RPT: ...O.. > PIM include WC: ...O.. > PIM include SG: ...... > PIM exclude SG: ...... > ================================================== > > is this the correct sort of thing? Are those "UNKNOWN" > entries anything to worry about?? The UNKNOWN fields in the (*,G) entry are problematic, and the reason you are not receiving the multicast traffic from the RP. The UNKNOWN fields in the above (S,G) entry are OK, because this (S,G) entry is for a directly connected source (in that case there is no upstream PIM router toward the RP). > What other output should I look at to try to debug this?? Any suggestions? > > Xorp> show pim mrib > DestPrefix NextHopRouter VifName VifIndex MetricPref Metric > 0.0.0.0/0 144.124.35.254 rl3 4 1 1 > 144.124.32.0/22 144.124.34.30 rl3 4 0 0 > 193.60.10.0/24 193.60.10.90 rl1 2 0 0 > 193.60.11.0/24 193.60.11.33 rl2 3 0 0 > 193.60.15.0/24 193.60.15.40 rl0 1 0 0 > Xorp> > > Xorp> show pim neighbors > Interface DRpriority NeighborAddr V Mode Holdtime Timeout > rl3 none 144.124.35.252 2 Sparse 105 79 > rl3 none 144.124.35.253 2 Sparse 105 79 > Xorp> > > Note: there are actually two router engines in our > upstream Cisco box. As I understand it, they watch each other and > one adopts 144.124.35.254 but they both have there own > IP addresses too, hence perhaps the oddities above. Live > failover is the plan I understand. > > Xorp> show pim mfc > Group Source RP > 233.3.18.1 193.60.11.36 146.97.34.8 > Incoming interface : rl2 > Outgoing interfaces: ....O. > Xorp> > > so that looks o.k. I guess? yes? I presume the dots > match to interfaces in which case I reckon the O > matches to rl3 which is my route upstream. The above MFC entry is OK. It is for your directly connected source 193.60.11.36. And yes, the "O" is set for the outgoing interfaces. I guess in your case the only interface with "O" is the register_vif. To confirm that, can you send the output of "show pim interface" and "show mfea interface". Regards, Pavlin From edrt@citiz.net Wed Jul 21 05:37:57 2004 From: edrt@citiz.net (edrt) Date: Wed, 21 Jul 2004 12:37:57 +0800 Subject: [Xorp-users] Well - I'm half working.... Message-ID: <200407210439.AGO95067@mira2.citiz.net> >Hi Dave : > >From the (*, 233.3.18.1) TIB state, it seems that > * rl3 of the Xorp router shares the address 146.97.34.8 > * rl3 is the RP of group 233.3.18.1 Sorry, the above deduction seems broken :( Because the only situation I have seen that "Upstream state = Joined" while "RPF'(*,G) = UNKNOWN", is the router itself is the RP, but at that situation the Upstream interface (RP) should be register_vif. I didn't notice that at the first glance. The XORP router could register data to RP but could not draw data from RP. I doubt the problem may be related to the default MRIB route. So I suggest you make a static route to RP at the XORP router, and see if things works. Eddy From pavlin@icir.org Wed Jul 21 05:29:57 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 20 Jul 2004 21:29:57 -0700 Subject: [Xorp-users] Well - I'm half working.... In-Reply-To: Message from "edrt" of "Wed, 21 Jul 2004 09:17:45 +0800." <200407210119.AFH94895@mira1.citiz.net> Message-ID: <200407210429.i6L4Tv8U028441@possum.icir.org> > >From the (*, 233.3.18.1) TIB state, it seems that > * rl3 of the Xorp router shares the address 146.97.34.8 > * rl3 is the RP of group 233.3.18.1 > * RP(233.3.18.1) only detect local multicast receiver, > but not receiving any downstream Join(*,G) Actually, I think that 146.97.34.8 is not the address of rl3, hence the XORP router is not the RP. Dave, please send the output of the "show pim interface" and "show pim interface address" commands to confirm that. Thanks, Pavlin From edrt@citiz.net Wed Jul 21 06:03:01 2004 From: edrt@citiz.net (edrt) Date: Wed, 21 Jul 2004 13:3:1 +0800 Subject: [Xorp-users] Well - I'm half working.... Message-ID: <200407210505.i6L55dwY010647@wyvern.icir.org> >>Hi Dave : >> >>From the (*, 233.3.18.1) TIB state, it seems that >> * rl3 of the Xorp router shares the address 146.97.34.8 >> * rl3 is the RP of group 233.3.18.1 > >Sorry, the above deduction seems broken :( > >Because the only situation I have seen that "Upstream state = Joined" while "RPF'(*,G) = UNKNOWN", >is the router itself is the RP, but at that situation the Upstream interface (RP) should be register_vif. >I didn't notice that at the first glance. > >The XORP router could register data to RP but could not draw data from RP. >I doubt the problem may be related to the default MRIB route. >So I suggest you make a static route to RP at the XORP router, and see if things works. > > >Eddy > And according to the MRIB and neighbor information you provided, this may also be the root of the problem : The Xorp router failed to send Join(*,233.3.18.1) to 144.124.35.254, because Xorp router haven't learn hello from 144.124.35.254. But what puzzles me is that at this situation, how could the (*,233.3.18.1) TIB entry's Upstream state be in Joined state ? From pavlin@icir.org Wed Jul 21 06:09:12 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 20 Jul 2004 22:09:12 -0700 Subject: [Xorp-users] Problem configuring linux box to bridge multicast packets on two subnets In-Reply-To: Message from "Smith, Kevin" of "Mon, 19 Jul 2004 19:40:25 PDT." <019ABC937D6E0142AECD8AA615730D38010BC041@mlpex04e.usa.fsc.net> Message-ID: <200407210509.i6L59C8U028721@possum.icir.org> > I'm trying to configuring a Linux box(RH 2.4.20) > as a multicast-bridge(hostname =3D "mb-host") to forward = > multicast > packets > between two subnets. > I would like the hosts on both subnets(foo and bar)=20 > to be members of the same multicast group. > On the mb-host machine eth1 is connected to the subnet that > includes > the host "foo" and eth2 is connected to the subnet containing > "bar". > When I am logged into bar and I execute "ping 224.225.0.1" > I would like both foo and bar to respond and vis-versa > (Assuming that multicast client programs on foo and bar are > registered > to 224.225.0.1). > I have not been successfully in getting this to work > with pimd, mroute or xorp. When I execute "ping 224.225.0.1" > on either subnet only hosts on the same physical subnet respond > to the ping. It is my understanding that what I'm trying > to do is a legitimate and common thing to do with xorp or pimd. > Using tcpdump I can see that the multicast ping packets reach > the > interface on mb-host but I see no evidence that the packets > are forwarded for one interface to the other. I just tried it on my testbed with FreeBSD-4.9, and the multicast ping appears to work, but first I had to run "sysctl net.inet.icmp.bmcastecho=1" on each receiver. I also run ping from a Linux machine, and it also worked. A silly question, but I have to ask it :) Did you specify the TTL (-t ) for the outgoing multicast packets? By default it is set to 1, and multicast packets with TTL <= 1 are not forwarded. Regards, Pavlin > > Any advice you folks can pass along would be appreciated. > Please let me know if I can provide additional information > regarding this problem. My best guess is that > I need to add some special routes on mb-host. > Note that foo can ping bar's IP address and vis-versa through > mb-host. > > The ascii-figure below shows the relevant network setup. > Use a non-proportional font(e.g. courier) to see the figure > clearly. > > +------+ +-------+ +------+ > |eth1 |<-->|eth1 | | | > |222.33| |222.5 | | | > | | |eth2 |<-->|eth1 | > | | |223.4 | |223.35| > |foo | |mb-host| |bar | > +------+ +-------+ +------+ From pavlin@icir.org Wed Jul 21 06:13:01 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 20 Jul 2004 22:13:01 -0700 Subject: [Xorp-users] Well - I'm half working.... In-Reply-To: Message from "edrt" of "Wed, 21 Jul 2004 13:03:01 +0800." <200407210505.i6L55dwY010647@wyvern.icir.org> Message-ID: <200407210513.i6L5D18U028765@possum.icir.org> > >>Hi Dave : > >> > >>From the (*, 233.3.18.1) TIB state, it seems that > >> * rl3 of the Xorp router shares the address 146.97.34.8 > >> * rl3 is the RP of group 233.3.18.1 > > > >Sorry, the above deduction seems broken :( > > > >Because the only situation I have seen that "Upstream state = Joined" while "RPF'(*,G) = UNKNOWN", > >is the router itself is the RP, but at that situation the Upstream interface (RP) should be register_vif. > >I didn't notice that at the first glance. > > > >The XORP router could register data to RP but could not draw data from RP. > >I doubt the problem may be related to the default MRIB route. > >So I suggest you make a static route to RP at the XORP router, and see if things works. > > > > > >Eddy > > > > And according to the MRIB and neighbor information you provided, > this may also be the root of the problem : > > The Xorp router failed to send Join(*,233.3.18.1) to 144.124.35.254, > because Xorp router haven't learn hello from 144.124.35.254. Exactly, this was what I think the problem is. > But what puzzles me is that at this situation, how could the > (*,233.3.18.1) TIB entry's Upstream state be in Joined state ? This is legitimate. The Upstream state is Joined because there are directly-connected members. However, because the RPF'(*,G) upstream next-hop roter toward the RP is NULL, the Join messages are not sent. Regards, Pavlin From edrt@citiz.net Wed Jul 21 06:27:38 2004 From: edrt@citiz.net (edrt) Date: Wed, 21 Jul 2004 13:27:38 +0800 Subject: [Xorp-users] Well - I'm half working.... Message-ID: <200407210529.AGP40214@mira2.citiz.net> >>>Hi Dave : >>> >>>From the (*, 233.3.18.1) TIB state, it seems that >>> * rl3 of the Xorp router shares the address 146.97.34.8 >>> * rl3 is the RP of group 233.3.18.1 >> >>Sorry, the above deduction seems broken :( >> >>Because the only situation I have seen that "Upstream state = Joined" while "RPF'(*,G) = UNKNOWN", >>is the router itself is the RP, but at that situation the Upstream interface (RP) should be register_vif. >>I didn't notice that at the first glance. >> >>The XORP router could register data to RP but could not draw data from RP. >>I doubt the problem may be related to the default MRIB route. >>So I suggest you make a static route to RP at the XORP router, and see if things works. >> >> >>Eddy >> > >And according to the MRIB and neighbor information you provided, >this may also be the root of the problem : > >The Xorp router failed to send Join(*,233.3.18.1) to 144.124.35.254, >because Xorp router haven't learn hello from 144.124.35.254. > >But what puzzles me is that at this situation, how could the >(*,233.3.18.1) TIB entry's Upstream state be in Joined state ? > After checking the source code, I find Xorp-PIMSM will send Join even if it has not yet saw hello from the upstream neighbor. Could it because cisco router rejects the Join(*, 233.3.18.1) signal Xorp router sends to it, because the rpf neighbor indicated in the Join is 144.124.35.254? Eddy From edrt@citiz.net Wed Jul 21 07:04:01 2004 From: edrt@citiz.net (edrt) Date: Wed, 21 Jul 2004 14:4:1 +0800 Subject: [Xorp-users] Well - I'm half working.... Message-ID: <200407210606.AGP62291@mira2.citiz.net> >> And according to the MRIB and neighbor information you provided, >> this may also be the root of the problem : >> >> The Xorp router failed to send Join(*,233.3.18.1) to 144.124.35.254, >> because Xorp router haven't learn hello from 144.124.35.254. > >Exactly, this was what I think the problem is. > >> But what puzzles me is that at this situation, how could the >> (*,233.3.18.1) TIB entry's Upstream state be in Joined state ? > >This is legitimate. The Upstream state is Joined because there are >directly-connected members. Oh yes, the state only means JoinDesired(*,G) is true, not stands for JoinDesired(*,G) is true AND the router actually sends Join(*,G) to upstream neighbor. >However, because the RPF'(*,G) upstream >next-hop roter toward the RP is NULL, the Join messages are not >sent. Yes. I failed to notice that. This is one reason why the definition of RPF'(*,G) in the latest draft is changed to using "NBR( RPF_interface(RP(G)), MRIB.next_hop( RP(G) ) )" instead of "MRIB.next_hop( RP(G) )" Regards, Eddy From dave.price@aber.ac.uk Wed Jul 21 09:51:09 2004 From: dave.price@aber.ac.uk (Dave Price) Date: Wed, 21 Jul 2004 09:51:09 +0100 Subject: [Xorp-users] Well - I'm half working.... In-Reply-To: Your message of Tue, 20 Jul 2004 19:50:38 +0100. <95650.1090349438@vulture.xorp.org> Message-ID: <6025.1090399869@aber.ac.uk> Dear Mark, excellent explanation re DNS etc. I half quessed it was somewhat like that. Dave From dave.price@aber.ac.uk Wed Jul 21 10:56:20 2004 From: dave.price@aber.ac.uk (Dave Price) Date: Wed, 21 Jul 2004 10:56:20 +0100 Subject: [Xorp-users] Well - I'm half working.... In-Reply-To: Your message of Tue, 20 Jul 2004 21:29:57 -0700. <200407210429.i6L4Tv8U028441@possum.icir.org> Message-ID: <6172.1090403780@aber.ac.uk> Dear Pavli, edrt, Mark and All (and Hefin so you can check if my cisco remarks are indeed o.k.), I'm trying to plough my way through the list of replies from you all that have arrived here overnight. pavlin@icir.org said: > Actually, I think that 146.97.34.8 is not the address of rl3, hence > the XORP router is not the RP. The XORP router is not the RP, the RP is many router hops away from me, but the unicast route to it from the XORP box is via the same cisco box that acts as the PIM-SM router neighbour upstream too. The RP is 146.97.34.8 and this will be reached via rl3 which leads to the cisco box that is both the PIM-SM upstream neighbour and is also set as the unicast default route on the xorp box. Xorp> show pim rps RP Type Pri Holdtime Timeout ActiveGroups GroupPrefix 146.97.34.8 static 192 -1 -1 8 224.0.0.0/4 Xorp> pavlin@icir.org said: > Dave, please send the output of the "show pim interface" and "show pim > interface address" commands to confirm that. Xorp> show pim interface Interface State Mode V PIMstate Priority DRaddr Neighbors lo0 DISABLED Sparse 2 NotDR 1 0.0.0.0 0 rl0 UP Sparse 2 DR 1 193.60.15.40 0 rl1 UP Sparse 2 DR 1 193.60.10.90 0 rl2 UP Sparse 2 DR 1 193.60.11.33 0 rl3 UP Sparse 2 NotDR 1 144.124.35.253 2 register_vif UP Sparse 2 DR 1 0.0.0.0 0 Xorp> Xorp> show pim interface address Interface PrimaryAddr DomainWideAddr SecondaryAddr lo0 0.0.0.0 0.0.0.0 rl0 193.60.15.40 193.60.15.40 rl1 193.60.10.90 193.60.10.90 rl2 193.60.11.33 193.60.11.33 rl3 144.124.34.30 144.124.34.30 register_vif 144.124.34.30 144.124.34.30 Xorp> Now, as I commented earlier, this cisco box has two routing engines installed. The xorp's IP address to that connection to the cisco box is 144.124.34.30 as you can see from the above. The two routing engines have their own real IP addresses of 144.124.35.252 and 144.124.35.253. But the idea is that one or other of them is supposed to adopt the address 144.124.34.254 at any point in time. All other machines get told that the default unicast router address is actually 144.124.34.254 and one or other of the routing engines services that. I wonder if the trouble is that although I've set the default mrib-route4 0.0.0.0/0 { > metric: 1 > nexthop: 144.124.35.254 > } the PIM neighbours actually get shown as Xorp> show pim neighbors Interface DRpriority NeighborAddr V Mode Holdtime Timeout rl3 none 144.124.35.252 2 Sparse 105 94 rl3 none 144.124.35.253 2 Sparse 105 94 Xorp> i.e. the two underlying IP addresses of the routing engines rather tha the common 144.124.35.254 that are supposed to service in a hot-standby type manner. Eddy asked for output of show pim bootstrap Xorp> show pim bootstrap Active zones: BSR Pri LocalAddress Pri State Timeout SZTimeout Expiring zones: BSR Pri LocalAddress Pri State Timeout SZTimeout Configured zones: BSR Pri LocalAddress Pri State Timeout SZTimeout Xorp> pavlin@icir.org said: > The reason that other sites are seeing your multicast beacon packets > is because your XORP multicast router is unicasting them encapsulated > within PIM Register packets. Those packets are sent directly to the > RP, and don't depend on any other multicast routers [see below]. I'm not sure. If I run tcpdump on rl3 on the XORP box I see... LiveCD# tcpdump -n -v -i rl3 tcpdump: listening on rl3 10:53:47.884674 193.60.11.36.59810 > 233.3.18.1.56786: [udp sum ok] udp 51 (ttl 126, id 11069, len 79) 10:53:47.993499 193.60.11.36.59810 > 233.3.18.1.56786: [udp sum ok] udp 51 (ttl 126, id 11070, len 79) 10:53:48.103472 193.60.11.36.59810 > 233.3.18.1.56786: [udp sum ok] udp 51 (ttl 126, id 11071, len 79) Surely those packets really are being sent out by multicast at that stage are they not? Or am I misinterpreting the tcpdump output?? pavlin@icir.org said: > The problem is that the RPF'(*,G) entry is UNKNOWN, therefore the PIM > Join messages aren't sent. This entry is suppose to point to the > next-hop router toward the RP (146.97.34.8). >From your "show pim > mrib" output it appears that the next-hop router toward the RP should > be 144.124.35.254. However, the "show pim neighbors" output does not > show a neighbor with such IP address. Therefore, it is question of > finding why you don't have a PIM neighbor with IP address of > 144.124.35.254. I chatted about this above. Becuase of the two router engines in the cisco box, it appears they are using their "real" IP addresses of 144.124.35.252 and 253 when becoming neighbours whereas, in at leats the unicast world, one or the other routing engine at any one time is suppsoed to adopt 144.124.35.254 Do you think this is the real underlying cause of my problems?? pavlin@icir.org said: > * Run tcpdump on the rl3 interface and look for PIM Hello messages > from 144.124.35.254 LiveCD# tcpdump -n -v -i rl3 | grep -i PIM tcpdump: listening on rl3 10:58:49.216976 144.124.35.253 > 224.0.0.13: pim v2 Join/Prune upstream-neighbor=144.124.34.30 groups=1 holdtime=3m30s (group0: 233.3.18.1 join=1 193.60.11.36(S) prune=0) [tos 0xc0] [ttl 1] (id 10627, len 54) 10:58:50.220779 193.60.11.33 > 146.97.34.8: pim v2 Register N 193.60.11.36 > 233.3.18.1: [ttl 0] (id 0, len 20) (ttl 64, id 30487, len 48) 10:58:50.910874 144.124.34.30 > 224.0.0.13: pim v2 Hello (Hold-time 1m45s) [Hello option 2] (DR-Priority: 1) (Genid: 0x7fc06bf2) [tos 0xc0] [ttl 1] (id 30578, len 58, optlen=4 RA) 10:59:01.218104 144.124.35.253 > 224.0.0.13: pim v2 Hello (Hold-time 1m45s) [tos 0xc0] [ttl 1] (id 10831, len 30) 10:59:01.633067 144.124.35.252 > 224.0.0.13: pim v2 Hello (Hold-time 1m45s) [tos 0xc0] [ttl 1] (id 12107, len 30) 10:59:20.915313 144.124.34.30 > 224.0.0.13: pim v2 Hello (Hold-time 1m45s) [Hello option 2] (DR-Priority: 1) (Genid: 0x7fc06bf2) [tos 0xc0] [ttl 1] (id 33287, len 58, optlen=4 RA) 10:59:30.221702 144.124.35.253 > 224.0.0.13: pim v2 Join/Prune upstream-neighbor=144.124.34.30 groups=1 holdtime=3m30s (group0: 224.2.127.254 join=2 193.60.11.36(S) 193.60.11.49(S) prune=0) [tos 0xc0] [ttl 1] (id 11272, len 62) 10:59:31.221568 144.124.35.253 > 224.0.0.13: pim v2 Hello (Hold-time 1m45s) [tos 0xc0] [ttl 1] (id 11288, len 30) 10:59:31.636573 144.124.35.252 > 224.0.0.13: pim v2 Hello (Hold-time 1m45s) [tos 0xc0] [ttl 1] (id 12470, len 30) ^CLiveCD# as I have mentioned, there are the "real" IP addresses of the two router engines. pavlin@icir.org said: > * Enable the traceoptions debug messages and look for PIM-SM debug > messages like: > [ 2004/07/20 20:54:24 TRACE test_pim PIM ] RX PIM_HELLO from 10.3.0.2 > to 224.0.0.13 on vif dc1 exactly where do I lok to find them?? I've altered config to say "true" in the traceoptions for MFEA and for pimsm4 but where exactly do the debug messages go? pavlin@icir.org said: > BTW, does the upstream router 144.124.35.254 has more than one IP > addresses assigned on that interface? yes, as I explained above. Two "real" IP addresses one per routing engine and then another they are supposed to share, but as goes PIM, it seems they both kee going with their own IP addresses and do not seem to adopt the common one. pavlin@icir.org said: > Also, if tcpdump shows there are PIM Hello messages from > 144.124.35.254, can you send the tcpdump of one of those messages. As shown above, mesasages are from two separate routing engines. pavlin@icir.org said: > The above MFC entry is OK. It is for your directly connected source > 193.60.11.36. And yes, the "O" is set for the outgoing interfaces. I > guess in your case the only interface with "O" is the register_vif. To > confirm that, can you send the output of "show pim interface" and > "show mfea interface". Xorp> show pim interface Interface State Mode V PIMstate Priority DRaddr Neighbors lo0 DISABLED Sparse 2 NotDR 1 0.0.0.0 0 rl0 UP Sparse 2 DR 1 193.60.15.40 0 rl1 UP Sparse 2 DR 1 193.60.10.90 0 rl2 UP Sparse 2 DR 1 193.60.11.33 0 rl3 UP Sparse 2 NotDR 1 144.124.35.253 2 register_vif UP Sparse 2 DR 1 0.0.0.0 0 Xorp> Xorp> show mfea interface Interface State Vif/PifIndex Addr Flags lo0 DISABLED 0/9 LOOPBACK MULTICAST KERN_UP rl0 UP 1/1 193.60.15.40 MULTICAST BROADCAST KERN_UP rl1 UP 2/2 193.60.10.90 MULTICAST BROADCAST KERN_UP rl2 UP 3/3 193.60.11.33 MULTICAST BROADCAST KERN_UP rl3 UP 4/4 144.124.34.30 MULTICAST BROADCAST KERN_UP register_vif UP 5/4 144.124.34.30 PIM_REGISTER KERN_UP Xorp> wheras of course, Xorp> show pim mrib DestPrefix NextHopRouter VifName VifIndex MetricPref Metric 0.0.0.0/0 144.124.35.254 rl3 4 1 1 144.124.32.0/22 144.124.34.30 rl3 4 0 0 193.60.10.0/24 193.60.10.90 rl1 2 0 0 193.60.11.0/24 193.60.11.33 rl2 3 0 0 193.60.15.0/24 193.60.15.40 rl0 1 0 0 Xorp> Is the real underlying problem this confusion over 144.134.35.{252,253,254} ??? Thanks for help so far folks... Dave Price From edrt@citiz.net Wed Jul 21 13:17:54 2004 From: edrt@citiz.net (edrt) Date: Wed, 21 Jul 2004 20:17:54 +0800 Subject: [Xorp-users] Well - I'm half working.... Message-ID: <200407211208.AGU46042@mira2.citiz.net> >After checking the source code, I find Xorp-PIMSM will send Join even if >it has not yet saw hello from the upstream neighbor. > Ignore this, I miss the point. From pavlin@icir.org Wed Jul 21 21:03:52 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 21 Jul 2004 13:03:52 -0700 Subject: [Xorp-users] Well - I'm half working.... In-Reply-To: Message from Dave Price of "Wed, 21 Jul 2004 10:56:20 BST." <6172.1090403780@aber.ac.uk> Message-ID: <200407212003.i6LK3q8U035679@possum.icir.org> > Now, as I commented earlier, this cisco box has two routing > engines installed. The xorp's IP address to that connection to > the cisco box is 144.124.34.30 as you can see from the above. > The two routing engines have their own real IP addresses > of 144.124.35.252 and 144.124.35.253. But the idea is that one or > other of them is supposed to adopt the address 144.124.34.254 > at any point in time. All other machines get told that the > default unicast router address is actually 144.124.34.254 > and one or other of the routing engines services that. > > I wonder if the trouble is that although I've set the default > mrib-route4 0.0.0.0/0 { > > metric: 1 > > nexthop: 144.124.35.254 > > } > > the PIM neighbours actually get shown as > > Xorp> show pim neighbors > Interface DRpriority NeighborAddr V Mode Holdtime Timeout > rl3 none 144.124.35.252 2 Sparse 105 94 > rl3 none 144.124.35.253 2 Sparse 105 94 > Xorp> > > i.e. the two underlying IP addresses of the routing engines > rather tha the common 144.124.35.254 that are supposed > to service in a hot-standby type manner. Yes, I think this is the problem. When the two engines originate PIM Hello messages, they use source addresses 144.124.35.252 and 144.124.35.253 respectively. Hence, there is no PIM Hello message with source address of 144.124.35.254 which is your default next-hop router address. The easiest way to fix that is to modify your default mrib-route4 entry and set the nexthop field to either 144.124.35.252 or 144.124.35.253. > pavlin@icir.org said: > > The reason that other sites are seeing your multicast beacon packets > > is because your XORP multicast router is unicasting them encapsulated > > within PIM Register packets. Those packets are sent directly to the > > RP, and don't depend on any other multicast routers [see below]. > > I'm not sure. If I run tcpdump on rl3 on the XORP box > I see... > > LiveCD# tcpdump -n -v -i rl3 > tcpdump: listening on rl3 > 10:53:47.884674 193.60.11.36.59810 > 233.3.18.1.56786: [udp sum ok] udp 51 (ttl 126, id 11069, len 79) > 10:53:47.993499 193.60.11.36.59810 > 233.3.18.1.56786: [udp sum ok] udp 51 (ttl 126, id 11070, len 79) > 10:53:48.103472 193.60.11.36.59810 > 233.3.18.1.56786: [udp sum ok] udp 51 (ttl 126, id 11071, len 79) > > Surely those packets really are being sent out by multicast at that stage are > they not? Or am I misinterpreting the tcpdump output?? Your interpretation is correct. I didn't know that 144.124.35.252 and 144.124.35.253 belong to your upstream router, so now I have another explanation why you were able to originate multicast packets: * When the sender starts, the first few multicast data packets are encapsulated and unicast to the RP. By default, last-hop cisco routers will originate immediately (S,G) Joins toward the S once the first data packet is received. * Your XORP router will accept Join messages from your 144.124.35.252/144.124.35.253 cisco router, hence it will start to forward the data packets natively. Regards, Pavlin From pavlin@icir.org Wed Jul 21 23:34:33 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 21 Jul 2004 15:34:33 -0700 Subject: [Xorp-users] Well - I'm half working.... In-Reply-To: Message from Dave Price of "Wed, 21 Jul 2004 10:56:20 BST." <6172.1090403780@aber.ac.uk> Message-ID: <200407212234.i6LMYX8U036665@possum.icir.org> > Now, as I commented earlier, this cisco box has two routing > engines installed. The xorp's IP address to that connection to > the cisco box is 144.124.34.30 as you can see from the above. > The two routing engines have their own real IP addresses > of 144.124.35.252 and 144.124.35.253. But the idea is that one or > other of them is supposed to adopt the address 144.124.34.254 > at any point in time. All other machines get told that the > default unicast router address is actually 144.124.34.254 > and one or other of the routing engines services that. Just curious, what is the reason you are running two routing engines? Thanks, Pavlin From jgold@mazunetworks.com Thu Jul 22 00:15:21 2004 From: jgold@mazunetworks.com (Jeff Gold) Date: Wed, 21 Jul 2004 19:15:21 -0400 Subject: [Xorp-users] Routing Daemon Reliability Message-ID: <40FEF909.4010704@mazunetworks.com> What sort of tests are effective for estabilishing that a routing daemon is reliable without requiring an enormous test network? I am particularly interested in ensuring that the daemon will not crash under heavy load with routes representing complex topologies. Are there well established test suites that can determine this? What method does XORP use for testing release candidates? Jeff From atanu@ICSI.Berkeley.EDU Thu Jul 22 03:41:20 2004 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Wed, 21 Jul 2004 19:41:20 -0700 Subject: [Xorp-users] Routing Daemon Reliability In-Reply-To: Message from Jeff Gold of "Wed, 21 Jul 2004 19:15:21 EDT." <40FEF909.4010704@mazunetworks.com> Message-ID: <20401.1090464080@tigger.icir.org> We are aware of testing hardware such as SmartBits which is used for testing hardware. We unfortunately don't have access to one of these. The University of New Hampshire runs an interoperability Laboratory . We have not had XORP tested. We been been focusing on correctness not load. Having said that we have full IPv4 and IPv6 BGP feeds connected to XORP routers (RIP and PIM also enabled). We are currently seeing 140811 IPv4 routes and 73 IPv6 routes. For a few weeks before the release we were sending production traffic through a XORP router. We are not doing this at the moment because we periodically toggle the BGP peerings to try and trigger problems. We monitor process sizes, open files, swap usage etc... We have regression tests that that we run every few hours on a variety of platforms and compilers. For BGP we have built a test harness that is run as part of the regression test run, this tests the correctness of our BGP. For multicast we manually run a set of tests. We intend to automate the running of these tests. We have a small testbed that we can use to test simple topologies. We have also experimented with using multiple vmware instances to build simple networks in one host. We are intending to use IMUNES for testing complex topologies. Atanu. >>>>> "Jeff" == Jeff Gold writes: Jeff> What sort of tests are effective for estabilishing that a Jeff> routing daemon is reliable without requiring an enormous test Jeff> network? I am particularly interested in ensuring that the Jeff> daemon will not crash under heavy load with routes Jeff> representing complex topologies. Are there well established Jeff> test suites that can determine this? What method does XORP Jeff> use for testing release candidates? Jeff> Jeff Jeff> _______________________________________________ Xorp-users Jeff> mailing list Xorp-users@xorp.org Jeff> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From atanu@ICSI.Berkeley.EDU Fri Jul 23 00:50:48 2004 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Thu, 22 Jul 2004 16:50:48 -0700 Subject: [Xorp-users] San Diego IETF Message-ID: <83166.1090540248@tigger.icir.org> Hi, Some of the XORP developers will be at the San Diego IETF, is there any interest in meeting up with us? Atanu. From ahj@aber.ac.uk Thu Jul 22 08:55:37 2004 From: ahj@aber.ac.uk (Hefin James) Date: Thu, 22 Jul 2004 08:55:37 +0100 Subject: [Xorp-users] Well - I'm half working.... In-Reply-To: <200407212234.i6LMYX8U036665@possum.icir.org> Message-ID: Hi Pavlin, others, > > Just curious, what is the reason you are running two routing engines? > At the core of our network we've got a Cisco Catalyst 6513 chassis with dual supervisor engines which take care of L2, management, etc. One supervisor is active, while the other waits for a failure. Each supervisor engine has it's own router, and to enable automatic failover for our L3 networks, we've deployed HSRP (Hot Standby Router Protocol), which also allows us to run both routers in an active-active arrangement, with automatic failover if a fault occurs. Cheers, Hefin HSRP - http://www.cisco.com/en/US/tech/tk648/tk362/tk321/tech_protocol_home.html From ahthamrin@gmail.com Fri Jul 23 03:06:07 2004 From: ahthamrin@gmail.com (Achmad Husni Thamrin) Date: Fri, 23 Jul 2004 11:06:07 +0900 Subject: [Xorp-users] Upstream MRIB nexthop (RP) UNKNOWN Message-ID: <4250f36104072219067800304e@mail.gmail.com> Dear All, I use XORP for PIM-SM only. On my FreeBSD, the MRIB entries are coming from the kernel routing table as below. DestPrefix NextHopRouter VifName VifIndex MetricPref Metric 10.1.1.0/24 10.1.1.100 fxp1 1 0 0 10.10.1.0/24 10.1.1.1 fxp1 1 254 65535 10.20.1.0/24 10.20.1.1 fxp0 0 0 0 I am wondering why the Upstream MRIB next hop (RP) is always UNKNOWN? Below is the (truncated) results of show pim join. (I typed the line numbers) Thank you, -husni- Group Source RP Flags 1 239.18.100.100 0.0.0.0 10.10.1.1 WC 2 Upstream interface (RP): fxp1 3 Upstream MRIB next hop (RP): UNKNOWN 4 Upstream RPF'(*,G): 10.1.1.1 5 Upstream state: Joined 6 Join timer: 41 ... Group Source RP Flags 7 239.18.100.100 10.20.1.20 10.10.1.1 SG_RPT DirectlyConnectedS 8 Upstream interface (S): fxp0 9 Upstream interface (RP): fxp1 10 Upstream MRIB next hop (RP): UNKNOWN 11 Upstream RPF'(S,G,rpt): 10.1.1.1 12 Upstream state: Pruned ... Group Source RP Flags 13 239.18.100.100 10.10.1.10 10.10.1.1 SG SPT 14 Upstream interface (S): fxp1 15 Upstream interface (RP): fxp1 16 Upstream MRIB next hop (RP): UNKNOWN 17 Upstream MRIB next hop (S): 10.1.1.1 18 Upstream RPF'(S,G): 10.1.1.1 19 Upstream state: Joined 20 Join timer: 56 ... Group Source RP Flags 21 239.18.100.100 10.20.1.20 10.10.1.1 SG SPT DirectlyConnectedS 22 Upstream interface (S): fxp0 23 Upstream interface (RP): fxp1 24 Upstream MRIB next hop (RP): UNKNOWN 25 Upstream MRIB next hop (S): UNKNOWN 26 Upstream RPF'(S,G): UNKNOWN 27 Upstream state: Joined 28 Register state: RegisterPrune RegisterCouldRegister 29 Join timer: 38 From pavlin@icir.org Fri Jul 23 03:14:05 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 22 Jul 2004 19:14:05 -0700 Subject: [Xorp-users] Well - I'm half working.... In-Reply-To: Message from "Hefin James" of "Thu, 22 Jul 2004 08:55:37 BST." Message-ID: <200407230214.i6N2E58U078289@possum.icir.org> > > Hi Pavlin, others, > > > > > Just curious, what is the reason you are running two routing engines? > > > > At the core of our network we've got a Cisco Catalyst 6513 chassis with dual > supervisor engines which take care of L2, management, etc. One supervisor is > active, while the other waits for a failure. > > Each supervisor engine has it's own router, and to enable automatic failover > for our L3 networks, we've deployed HSRP (Hot Standby Router Protocol), > which also allows us to run both routers in an active-active arrangement, > with automatic failover if a fault occurs. > > Cheers, > Hefin > > HSRP - > http://www.cisco.com/en/US/tech/tk648/tk362/tk321/tech_protocol_home.html Interesting. I did some search and I found the following from the cisco's web site: "Why Doesn't PIM Sparse Mode Work with a Static Route to an HSRP Address?" http://www.cisco.com/warp/public/619/hsrpmcast.html The text there describes exactly the same problem you have: "In the example, the RPF neighbor is 10.1.3.3, which is the HSRP standby address used by the default static route. However, this address is not listed as a PIM neighbor. The reason the HSRP standby address is not listed as a PIM neighbor is because the two routers running HSRP (Routers 2 and 3) will not source the PIM neighbor messages from the HSRP standby address." The Web page suggests two solutions (and recommends the first one): 1. Run EIGRP on the downstream PIM router (i.e., the XORP router in your topology). Thus the downstream router will learn automatically the appropriate upstream RPF address. However, in your case you say that you don't want to run an unicast routing protocol (e.g., RIP) between the XORP router and the Cisco. 2. Add static multicast routes to the downstream router to make it RPF to the real routers' IP addresses. This was the solution I suggested, but of course it has the drawback that the RPF will stop working if the engine with the RPF address fails. However, at this moment this is the only solution you have, unless you decide to run RIP between the cisco router and XORP. While on the subject. Today (independently from the HSRP issue) we had a discussion about importing unicast RIP/BGP/OSPF routes into the MRIB at the protocol-level granularity if you are running one of those protocols (currently, the only solution is to use fib2mrib which imports all unicast forwarding entries). At the end of the discussion we concluded that we need a mechanism at each protocol's output. That mechanism can be configured such that the route add/delete commands that are typically sent only to the URIB can be sent to the MRIB as well. However, once we implement that mechanism, then it will be trivial to configure it such that the add/delete commands from, say, RIP are sent only to MRIB. In your case, this is exactly what you want: you can run RIP between the Cisco and XORP, but those routes won't affect the unicast routing in your XORP multicast router. Hopefully, we will have this functionality for the 1.1 release. In the mean time I'd recommend that you use the static mrib-route4 setup to one of the reals IP addresses. Regards, Pavlin From pavlin@icir.org Sat Jul 24 01:26:11 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 23 Jul 2004 17:26:11 -0700 Subject: [Xorp-users] Upstream MRIB nexthop (RP) UNKNOWN In-Reply-To: Message from Achmad Husni Thamrin of "Fri, 23 Jul 2004 11:06:07 +0900." <4250f36104072219067800304e@mail.gmail.com> Message-ID: <200407240026.i6O0QB8U011255@possum.icir.org> Husni, Yes, line 3 appears bogus, but accidentally that doesn't matter, because RPF'(*,G) is correct. All other UNKNOWN MRIB entries for the RP follow from that bogus entry. Note that lines 25 and 26 are OK, because they refer to a directly-connected source, and by definition there is no next-hop router toward such sources. Though, I wonder if "Upstream MRIB next hop (RP)" is UNKNOWN, how "Upstream RPF'(*,G)" was assigned value of 10.1.1.1. The only reason that comes to mind is if there was an exchange of Assert messages on interface fxp1. Could you verify that by checking the log messages and by checking the assert-related "show pim join" state (e.g., "Assert Lost WC" for the (*,G) entry should be set to "O" for fxp1). I have a suspicion about the source of the problem. To verify my suspicion, could you run the stand-alone pim/test_pim instead and check whether you still get that bogus UNKNOWN entry. If you are not familiar with how to configure and run it, please read pim/README. Thanks, Pavlin > Dear All, > > I use XORP for PIM-SM only. On my FreeBSD, the MRIB entries are coming > from the kernel routing table as below. > > DestPrefix NextHopRouter VifName VifIndex MetricPref Metric > 10.1.1.0/24 10.1.1.100 fxp1 1 0 0 > 10.10.1.0/24 10.1.1.1 fxp1 1 254 65535 > 10.20.1.0/24 10.20.1.1 fxp0 0 0 0 > > I am wondering why the Upstream MRIB next hop (RP) is always UNKNOWN? > > Below is the (truncated) results of show pim join. (I typed the line numbers) > > Thank you, > -husni- > > Group Source RP Flags > 1 239.18.100.100 0.0.0.0 10.10.1.1 WC > 2 Upstream interface (RP): fxp1 > 3 Upstream MRIB next hop (RP): UNKNOWN > 4 Upstream RPF'(*,G): 10.1.1.1 > 5 Upstream state: Joined > 6 Join timer: 41 > > ... > > Group Source RP Flags > 7 239.18.100.100 10.20.1.20 10.10.1.1 SG_RPT DirectlyConnectedS > 8 Upstream interface (S): fxp0 > 9 Upstream interface (RP): fxp1 > 10 Upstream MRIB next hop (RP): UNKNOWN > 11 Upstream RPF'(S,G,rpt): 10.1.1.1 > 12 Upstream state: Pruned > > ... > > Group Source RP Flags > 13 239.18.100.100 10.10.1.10 10.10.1.1 SG SPT > 14 Upstream interface (S): fxp1 > 15 Upstream interface (RP): fxp1 > 16 Upstream MRIB next hop (RP): UNKNOWN > 17 Upstream MRIB next hop (S): 10.1.1.1 > 18 Upstream RPF'(S,G): 10.1.1.1 > 19 Upstream state: Joined > 20 Join timer: 56 > > ... > > Group Source RP Flags > 21 239.18.100.100 10.20.1.20 10.10.1.1 SG SPT DirectlyConnectedS > 22 Upstream interface (S): fxp0 > 23 Upstream interface (RP): fxp1 > 24 Upstream MRIB next hop (RP): UNKNOWN > 25 Upstream MRIB next hop (S): UNKNOWN > 26 Upstream RPF'(S,G): UNKNOWN > 27 Upstream state: Joined > 28 Register state: RegisterPrune RegisterCouldRegister > 29 Join timer: 38 > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From ahthamrin@gmail.com Sat Jul 24 08:35:12 2004 From: ahthamrin@gmail.com (Achmad Husni Thamrin) Date: Sat, 24 Jul 2004 16:35:12 +0900 Subject: [Xorp-users] Upstream MRIB nexthop (RP) UNKNOWN In-Reply-To: <200407240026.i6O0QB8U011255@possum.icir.org> References: <200407240026.i6O0QB8U011255@possum.icir.org> Message-ID: <4250f36104072400357f2e76c0@mail.gmail.com> Pavlin, I did several tests and found out that the MIB nexthop UNKNOWN problem happens when a group already has a listener before XORP has the RP for the group. Before XORP has the RP, it complained that there is no RP for the group, and after XORP has the RP through the bootstrap, the MRIB nexthop (R) stays to UNKNOWN. In another test, I deleted the route toward the RP (10.10.1.0/24) and check the PIM Join state. An excerpt of the join state is as below. So I guess that the MRIB nexthop (R) is not recomputed after the MRIB changed. Another question: TCP connections between XORP processes on my router are mostly using the IP address of a physical interface, not the loopback address Is this correct? Is there any reason not to use loopback address for XORP IPC? I intentionally shut down the interface for XORP IPCs and XORP throwed many complaints. thanks, -husni- ---------- 239.18.100.100 0.0.0.0 RP_ADDR_UNKNOWN WC Upstream interface (RP): UNKNOWN Upstream MRIB next hop (RP): 10.1.1.1 Upstream RPF'(*,G): UNKNOWN Upstream state: Joined From atanu@ICSI.Berkeley.EDU Sat Jul 24 10:07:32 2004 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Sat, 24 Jul 2004 02:07:32 -0700 Subject: [Xorp-users] Upstream MRIB nexthop (RP) UNKNOWN In-Reply-To: Message from Achmad Husni Thamrin of "Sat, 24 Jul 2004 16:35:12 +0900." <4250f36104072400357f2e76c0@mail.gmail.com> Message-ID: <50590.1090660052@tigger.icir.org> Achmad> Another question: TCP connections between XORP processes on Achmad> my router are mostly using the IP address of a physical Achmad> interface, not the loopback address Is this correct? Is Achmad> there any reason not to use loopback address for XORP IPC? Achmad> I intentionally shut down the interface for XORP IPCs and Achmad> XORP throwed many complaints. The XORP IPC can be configured to be used between hosts, the default however is to use the loopback address. It does look like we are using the the first physical interface sometimes. This is a problem and a Bugzilla entry has been made. Atanu. From pavlin@icir.org Mon Jul 26 09:51:39 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Mon, 26 Jul 2004 01:51:39 -0700 Subject: [Xorp-users] Upstream MRIB nexthop (RP) UNKNOWN In-Reply-To: Message from Achmad Husni Thamrin of "Sat, 24 Jul 2004 16:35:12 +0900." <4250f36104072400357f2e76c0@mail.gmail.com> Message-ID: <200407260851.i6Q8pd8U096459@possum.icir.org> Husni, Yes, you are right. There were some problems in setting the info. I just commited few fixes that should take care of the problem. Please wait for up to an hour or so for the anon. CVS repository to be updated, and then get the lastest code. Those changes should fix the MRIB related problems you describe in this email and in your previous email, but let me know if something still doesn't work for you. Thanks, Pavlin > I did several tests and found out that the MIB nexthop UNKNOWN problem > happens when a group already has a listener before XORP has the RP for > the group. Before XORP has the RP, it complained that there is no RP > for the group, and after XORP has the RP through the bootstrap, the > MRIB nexthop (R) stays to UNKNOWN. > > In another test, I deleted the route toward the RP (10.10.1.0/24) and > check the PIM Join state. > An excerpt of the join state is as below. > So I guess that the MRIB nexthop (R) is not recomputed after the MRIB changed. > > Another question: > TCP connections between XORP processes on my router are mostly using > the IP address of a physical interface, not the loopback address > Is this correct? Is there any reason not to use loopback address for XORP IPC? > I intentionally shut down the interface for XORP IPCs and XORP throwed > many complaints. > > thanks, > -husni- > > ---------- > 239.18.100.100 0.0.0.0 RP_ADDR_UNKNOWN WC > Upstream interface (RP): UNKNOWN > Upstream MRIB next hop (RP): 10.1.1.1 > Upstream RPF'(*,G): UNKNOWN > Upstream state: Joined > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From dave.price@aber.ac.uk Mon Jul 26 10:31:55 2004 From: dave.price@aber.ac.uk (Dave Price) Date: Mon, 26 Jul 2004 10:31:55 +0100 Subject: [Xorp-users] Well - I'm half working.... In-Reply-To: Your message of Wed, 21 Jul 2004 15:34:33 -0700. <200407212234.i6LMYX8U036665@possum.icir.org> Message-ID: <5835.1090834315@aber.ac.uk> Dear Pavlin, pavlin@icir.org said: > Just curious, what is the reason you are running two routing engines? >From what I gather, this is standard and recommended practice on big boxes in many organisations so as to have hot live standby automatic fail over etc. The box in question is the core of our whole university network and if it died 7.5K students and several thousand staff would have no network access.... Dave Price From pavlin@icir.org Wed Jul 28 04:38:55 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 27 Jul 2004 20:38:55 -0700 Subject: [Xorp-users] HEADS UP: ./configure flag name change Message-ID: <200407280338.i6S3ctwK027765@possum.icir.org> By users' request (and because it is the right thing to do), I have replaced the ./configure flag --enable-advanced-mcast-api with --disable-advanced-multicast-api (note the change in the polarity of the flag AND in the name). Previously, the --enable-advanced-mcast-api flag attempted to enable the so-called advanced multicast API in the kernel (for multicast routing purpose), but only if the kernel really supports it. Now the default behavior is that the advanced multicast API will be used if the kernel supports it (auto-detected), but the new flag --disable-advanced-multicast-api can be used to explicitly disable the new API. Pavlin From dave.price@aber.ac.uk Wed Jul 28 14:58:07 2004 From: dave.price@aber.ac.uk (Dave Price) Date: Wed, 28 Jul 2004 14:58:07 +0100 Subject: [Xorp-users] (Most) Multicast packets arriving twice Message-ID: <4616.1091023087@aber.ac.uk> Dear All, While setting up my XORP router here, we have made progress, but we now have noticed that many multicast packets seem to arrive twice. A first we thought it was all packets, but my opinion is starting to change. If I start a beacon client (we are using the Java version chatting to the JANET beacon server at http://ulcc.beacon.ja.net/global/) then all beacon traffic appears to arrive twice to us from what we can see. I used tcpdump and snoop on various interfaces to spot the duplicates. [Aside: actually I think the Java Beacon client has bugs in some ways as it seems to count things in odd manners, especially with duplicates but thats another matter] However, if I stop the beacon client and allow traffic to die away and then use sdr to start vic/rat attached to "Places all round the world" that multicast traffic only appears to me to arrive once. Any thoughts?? Our one thought is that the main link feeding our site is actually a pair of load balancing links between riverstone routers. Could a copy of each packet be arriving one down each link we thought? But if that's the case, how come the "places around the world" traffic arrives once but the beacon traffic arrives twice? Another thought was shared trees v source trees. Could we be seeing the traffic arrive once down a RPT shared tree from the RP and then again on a SPT source tree directly from each source?? How would I tell from the arriving packets (I don't I can can I ??) which way they had arrived? Could I tell from the "show pim ..." commands whether or not XORP has tried to send prunes to the RP for the groups/sources arriving via SPT or ??? thoughts?? Thanks, Dave Price --------------------------------------------------------- | David Price, Computer Science | | | | Computer Science, University of Wales, Aberystwyth, | | Penglais Campus, Aberystwyth, Ceredigion, SY23 3DB | | | | Email: dap@aber.ac.uk WWW: http://www.aber.ac.uk/~dap | | Phone: +44 1970 622428 FAX: +44 1970 622455 | --------------------------------------------------------- From M.Handley@cs.ucl.ac.uk Wed Jul 28 15:17:23 2004 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Wed, 28 Jul 2004 15:17:23 +0100 Subject: [Xorp-users] (Most) Multicast packets arriving twice In-Reply-To: Your message of "Wed, 28 Jul 2004 14:58:07 BST." <4616.1091023087@aber.ac.uk> Message-ID: <64862.1091024243@aardvark.cs.ucl.ac.uk> > Any thoughts?? One useful piece of information you could gather is the TTL of the dups. Knowing what the TTL of a packet is and the TTL of its duplicate is will provide quite a bit of information about the possible causes because it will let you know what the difference is in the length of the paths the two packets took. A made up example: echidna.cs.ucl.ac.uk: tcpdump -n -v net 224 tcpdump: listening on vr0 15:12:06.376554 128.16.64.4.51166 > 224.2.0.251.4567: [udp sum ok] udp 41 [ttl 16] (id 36064, len 69) 15:12:06.376678 128.16.64.4.51166 > 224.2.0.251.4567: [udp sum ok] udp 41 [ttl 15] (id 36064, len 69) In this case you know that these are copies of the same packet because they have the same IP ID (36064) and you can see that one copy went one IP hop further than the other (TTL=16 vs TTL=15). Cheers, Mark From dave.price@aber.ac.uk Wed Jul 28 15:52:35 2004 From: dave.price@aber.ac.uk (Dave Price) Date: Wed, 28 Jul 2004 15:52:35 +0100 Subject: [Xorp-users] (Most) Multicast packets arriving twice In-Reply-To: Your message of Wed, 28 Jul 2004 15:17:23 +0100. <64862.1091024243@aardvark.cs.ucl.ac.uk> Message-ID: <4740.1091026355@aber.ac.uk> Dear Mark, Thanks for reply. M.Handley@cs.ucl.ac.uk said: > One useful piece of information you could gather is the TTL of the > dups. > Knowing what the TTL of a packet is and the TTL of its duplicate is > will provide quite a bit of information about the possible causes > because it will let you know what the difference is in the length of > the paths the two packets took. They both appear the same I think. LiveCD# tcpdump -vv -i rl3 tcpdump: listening on rl3 15:32:57.670046 cerb-ag2.bris.ac.uk.2767 > 233.3.18.1.56786: udp 79 (ttl 117, id 52287, len 107) 15:32:57.670083 cerb-ag2.bris.ac.uk.2767 > 233.3.18.1.56786: udp 79 (ttl 117, id 52287, len 107) 15:32:57.670115 river.oucs.ox.ac.uk.32884 > 233.3.18.1.56786: udp 82 (ttl 116, id 43885, len 110) 15:32:57.670132 river.oucs.ox.ac.uk.32884 > 233.3.18.1.56786: udp 82 (ttl 116, id 43885, len 110) 15:32:57.671589 osfgi.aber.ac.uk.32833 > 233.3.18.1.56786: udp 63 (DF) (ttl 126, id 0, len 91) 15:32:57.672336 194.83.100.74.1094 > 233.3.18.1.56786: udp 64 (ttl 116, id 56144, len 92) 15:32:57.672935 194.83.100.74.1094 > 233.3.18.1.56786: udp 64 (ttl 116, id 56144, len 92) The one shown only once, is another beacon client running on-site here. mynet <-> xorpbox <-> sitecisco <-> otherroutersonsite <-> localriverstone <==twinlinks==> distantriverstone and so on... The osfgi beacon hangs off another link on "sitecisco" above I guess this tells us that all pairs of packets are arriving by the same route as ttl for each pair matches. That I guess makes it unlikely ( I guess impossible) that one is on SPT and one on RPT. whereas, if I get tcpdump to not capture the beacon traffic on 233.3.18.1 then.. LiveCD# tcpdump -vv -i rl3 not host 233.3.18.1 tcpdump: listening on rl3 15:36:53.186014 noc6.koren21.net.50117 > 224.2.172.238.51482: udp 162 (ttl 112, id 18864, len 190) 15:36:53.209351 champion-station.cisco.com.1047 > 224.2.172.238.51482: udp 967 (ttl 96, id 2162, len 995) 15:36:53.221570 mission-peak.cisco.com.1035 > 224.2.172.238.51482: udp 109 (ttl 92, id 49343, len 137) 15:36:53.268883 noc6.koren21.net.50118 > 224.2.172.238.51483: udp 240 (ttl 112, id 18865, len 268) 15:36:53.295489 boboy.cisco.com.1024 > 224.2.172.238.51482: udp 239 (ttl 92, id 48976, len 267) 15:36:53.296774 noc6.koren21.net.50117 > 224.2.172.238.51482: udp 144 (ttl 112, id 18866, len 172) 15:36:53.297967 IPTVserver.ldc.lu.se.1107 > 224.2.172.238.51483: udp 280 (ttl 103, id 61628, len 308) which all seem to arrive just once. Any more thoughts?? We are running two beacon listeners within the site, 193.60.11.36 which is "mine", 144.124.19.40 which is osfgi.aber.ac.uk and then there is another attached to the local riverstone which is beacon.aber.swman.net.uk 194.83.179.254 I wonder if by some weird manner, each internal beacon is getting sent a copy of the multicast beacon traffic, but it gets delivered to both of them? No, surely not. To test this weird thought, I've just started another beacon client on 193.60.11.10, i'm still getting two of each packet though not more.... Mind you, both 193.60.11.36 and 193.60.11.10 have the ssame router acting as the DR whereas 144.124.19.40 has another. I also noticed something else odd. Some of the beacon clients send all their UDP packets showing an IP id field of zero in all packets. I guess that is o.k. or is it?? Any more thoughst folks?? Dave From pavlin@icir.org Thu Jul 29 02:06:11 2004 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 28 Jul 2004 18:06:11 -0700 Subject: [Xorp-users] (Most) Multicast packets arriving twice In-Reply-To: Message from Dave Price of "Wed, 28 Jul 2004 15:52:35 BST." <4740.1091026355@aber.ac.uk> Message-ID: <200407290106.i6T16BwK078725@possum.icir.org> > > Knowing what the TTL of a packet is and the TTL of its duplicate is > > will provide quite a bit of information about the possible causes > > because it will let you know what the difference is in the length of > > the paths the two packets took. > > They both appear the same I think. > > LiveCD# tcpdump -vv -i rl3 > tcpdump: listening on rl3 > 15:32:57.670046 cerb-ag2.bris.ac.uk.2767 > 233.3.18.1.56786: udp 79 (ttl 117, id 52287, len 107) > 15:32:57.670083 cerb-ag2.bris.ac.uk.2767 > 233.3.18.1.56786: udp 79 (ttl 117, id 52287, len 107) > 15:32:57.670115 river.oucs.ox.ac.uk.32884 > 233.3.18.1.56786: udp 82 (ttl 116, id 43885, len 110) > 15:32:57.670132 river.oucs.ox.ac.uk.32884 > 233.3.18.1.56786: udp 82 (ttl 116, id 43885, len 110) > 15:32:57.671589 osfgi.aber.ac.uk.32833 > 233.3.18.1.56786: udp 63 (DF) (ttl 126, id 0, len 91) > 15:32:57.672336 194.83.100.74.1094 > 233.3.18.1.56786: udp 64 (ttl 116, id 56144, len 92) > 15:32:57.672935 194.83.100.74.1094 > 233.3.18.1.56786: udp 64 (ttl 116, id 56144, len 92) > > The one shown only once, is another beacon client running on-site here. > > mynet <-> xorpbox <-> sitecisco <-> otherroutersonsite <-> localriverstone <==twinlinks==> distantriverstone and so on... > > The osfgi beacon hangs off another link on "sitecisco" above > > I guess this tells us that all pairs of packets are arriving by the same > route as ttl for each pair matches. That I guess makes it unlikely ( I guess impossible) > that one is on SPT and one on RPT. Dave, Given that you get duplicates for only the multicast beacon group, and given that you don't get duplicates for the beacon client that is within your domain, then if I have to guess I would say that the duplication problem is somewhere upstream. To verify that, the simplest thing to do (if you have access of course), is to run tcpdump for only the multicast beacon destination address on the link between your domain and your provider (i.e., between the localriverstone and distantriverstone). In your case, because you use twinkinks, you may want to run tcpdump on both links AND on the link between otherroutersonsite and localriverstone. In other words, try to run tcpdump as further upstream as possible. Other things you can try, though I doubt will make much difference is: (a) Stop all beacon clients in your site, and start only a single beacon client. (b) Instead of starting a beacon client, just use /usr/sbin/mtest to join the same multicast group and check whether you still get the duplicates (e.g., to rule-out that something funny is going on at the application level). > I also noticed something else odd. Some of the beacon clients > send all their UDP packets showing an IP id field of zero in all packets. > I guess that is o.k. or is it?? Is this consistent for some subset of the beacon clients? I guess that the multicast beacons are using the standart socket interface to send the UDP packets, so the IP id field should be set by the host OS. In other words, it looks like some host OSes are not behaving properly. Regards, Pavlin From dave.price@aber.ac.uk Thu Jul 29 14:47:03 2004 From: dave.price@aber.ac.uk (Dave Price) Date: Thu, 29 Jul 2004 14:47:03 +0100 Subject: [Xorp-users] (Most) Multicast packets arriving twice In-Reply-To: Your message of Wed, 28 Jul 2004 18:06:11 -0700. <200407290106.i6T16BwK078725@possum.icir.org> Message-ID: <6453.1091108823@aber.ac.uk> Dear Pavlin, Mark and All, Thanks for latest reply. My local colleague, Hefin, is out of the office for a couple of days so experiments/tests largely suspended. There is also a close limit on what we can monitor, as even the "local riverstone" mentioned in my earlier email is operated by the provider (an academic regional network). I also gather that our main contact at the regional provider is also off for a few days so there are things we can't easily get monitored. On the ID field in packets issue, pavlin@icir.org said: > Is this consistent for some subset of the beacon clients? It appears so to me. It would be interesting to try to work out what OSs are involved with the beacons that also set it to zero. Anyway, quiet from me for a while, no doubt I'll pester you all again early next week once Hefin and I can co-ordinate our testing and get the regional provider to check things too. Bye Dave Price From lqin@sce.carleton.ca Thu Jul 29 18:01:03 2004 From: lqin@sce.carleton.ca (Liang Qin) Date: Thu, 29 Jul 2004 13:01:03 -0400 Subject: [Xorp-users] Template file problem Message-ID: <41092D4F.30108@sce.carleton.ca> Hi XORP users, After I moved code from XORP 0.5 to XORP 1.0, and run with ./xorp_rtrmgr -b config.linux I got error message like: ERROR xorp_rtrmgr:4261 RTRMGR +212 main_rtrmgr.cc run ] Shutting down due to an init error: PARSE ERROR {Template File" ......../olp.tp line 3]: syntax error; last symbol parsed was "olp" but I have the same template file works well in XORP 0.5 my olp.tp: protocols { olp { interfaceName: text = "eth1"; ............ } } .............. I noticed some changes in main_rtrmgr.cc, is it the reason? Is there any syntax error in my olp.tp? Thanks! Liang From M.Handley@cs.ucl.ac.uk Thu Jul 29 18:48:14 2004 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Thu, 29 Jul 2004 18:48:14 +0100 Subject: [Xorp-users] Template file problem In-Reply-To: Your message of "Thu, 29 Jul 2004 13:01:03 EDT." <41092D4F.30108@sce.carleton.ca> Message-ID: <23690.1091123294@aardvark.cs.ucl.ac.uk> >I got error message like: >ERROR xorp_rtrmgr:4261 RTRMGR +212 main_rtrmgr.cc run ] Shutting down >due to an init error: PARSE ERROR {Template >File" ......../olp.tp line 3]: syntax error; last symbol parsed was "olp" > >but I have the same template file works well in XORP 0.5 > >my olp.tp: >protocols { > olp { > interfaceName: text = "eth1"; > ............ > } >} My apologies for the cryptic error message - rewriting this parser is on my to-do list. I believe the problem is probably the use of the type "text" when it should be "txt". Cheers, Mark From adam@hiddennet.net Thu Jul 29 21:20:47 2004 From: adam@hiddennet.net (Adam Greenhalgh) Date: Thu, 29 Jul 2004 21:20:47 +0100 Subject: [Xorp-hackers] Re: [Xorp-users] Template file problem In-Reply-To: <41094812.50403@sce.carleton.ca> References: <23690.1091123294@aardvark.cs.ucl.ac.uk> <41094812.50403@sce.carleton.ca> Message-ID: <1091132447.8059.7.camel@localhost> Group in this context is the unix group. If a normal user (non root) runs xorpsh and wants to change from the normal mode where you can only view the xorp configuration to the configuration mode where you can configure the router, that user needs to a member of the unix group called "xorp" . For example : bash-2.05b$ cat /etc/group | grep xorp xorp:*:244:adam,eve,snake The users adam, eve, snake and root would be able to configure xorp on the system above by running the xorp shell, xorpsh . Hope this helps Adam On Thu, 2004-07-29 at 14:55 -0400, Liang Qin wrote: > Thanks Mark! > > It seems that the template file's format changes a little bit, including > %modinfo, isn't it? :-) > > Another question, after launching XORP by xorp_rtrmgr, > I got lots of Error messages: > [ERROR xorp_rtrmgr: 4231 RTRMGR +116 userdb.cc add user ] Group "xorp" > does not exist on this system, > > What does it mean? > > > > Liang > > Mark Handley wrote: > > >>I got error message like: > >>ERROR xorp_rtrmgr:4261 RTRMGR +212 main_rtrmgr.cc run ] Shutting down > >>due to an init error: PARSE ERROR {Template > >>File" ......../olp.tp line 3]: syntax error; last symbol parsed was "olp" > >> > >>but I have the same template file works well in XORP 0.5 > >> > >>my olp.tp: > >>protocols { > >> olp { > >> interfaceName: text = "eth1"; > >> ............ > >> } > >>} > >> > >> > > > >My apologies for the cryptic error message - rewriting this parser is > >on my to-do list. > > > >I believe the problem is probably the use of the type "text" when it > >should be "txt". > > > >Cheers, > > Mark > > > >_______________________________________________ > >Xorp-hackers mailing list > >Xorp-hackers@icir.org > >http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > > > > > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers@icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers -- Adam Greenhalgh From adam@hiddennet.net Fri Jul 30 08:38:47 2004 From: adam@hiddennet.net (Adam Greenhalgh) Date: Fri, 30 Jul 2004 08:38:47 +0100 Subject: [Xorp-hackers] Re: [Xorp-users] Template file problem In-Reply-To: <32232.1091138310@vulture.xorp.org> References: <32232.1091138310@vulture.xorp.org> Message-ID: <1091173127.11870.7.camel@localhost> On Thu, 2004-07-29 at 22:58 +0100, Mark Handley wrote: > > Adam summarised this quite well. Basically xorpsh currently has a > crude form of user permissions: if you're in the Unix xorp group, you > can enter configuration mode. If not, then you can't. > > In the long run, this crude permissions scheme should be replaced by a > more fine-grain access control mechanism, configurable through the > CLI. But it's probably best to see how things are really used in > practice before we figure out what the real requirements are for > access control. > Thoughts, comments and ideas from users about what users would find useful are always welcome. So if you have an idea about how something should be say. Adam