From mh5942@bris.ac.uk Wed Mar 1 13:40:51 2006 From: mh5942@bris.ac.uk (Martin Hoffmann) Date: Wed, 01 Mar 2006 13:40:51 +0000 Subject: [Xorp-users] Xorp debug messages Message-ID: <4405A463.9020001@bris.ac.uk> Hi all, I'm currently testing my Click router multicast elements against Xorp. What is the easiest way to make Xorp print information about the PIM messages it received? Is there a way to enable Debug output for PIM only? My PIM Hello messages have the following format (captured with tethereal). I do not see the point why Xorp's PIM does not recognise them: ----------------- Capturing on eth3 Frame 1 (72 bytes on wire, 72 bytes captured) Arrival Time: Mar 1, 2006 13:05:56.263655000 Time delta from previous packet: 0.000000000 seconds Time since reference or first frame: 0.000000000 seconds Frame Number: 1 Packet Length: 72 bytes Capture Length: 72 bytes Protocols in frame: eth:ip:pim Ethernet II, Src: Intel_08:f0:a8 (00:04:23:08:f0:a8), Dst: 01:00:5e:00:00:0d (01:00:5e:00:00:0d) Destination: 01:00:5e:00:00:0d (01:00:5e:00:00:0d) Source: Intel_08:f0:a8 (00:04:23:08:f0:a8) Type: IP (0x0800) Internet Protocol, Src: 172.20.12.1 (172.20.12.1), Dst: 224.0.0.13 (224.0.0.13) Version: 4 Header length: 24 bytes Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00) 1100 00.. = Differentiated Services Codepoint: Class Selector 6 (0x30) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 58 Identification: 0xf45f (62559) Flags: 0x00 0... = Reserved bit: Not set .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 1 Protocol: PIM (0x67) Header checksum: 0x9716 [correct] Good: True Bad : False Source: 172.20.12.1 (172.20.12.1) Destination: 224.0.0.13 (224.0.0.13) Options: (4 bytes) Router Alert: Every router examines packet Protocol Independent Multicast Version: 2 Type: Hello (0) Checksum: 0x8447 [correct] PIM parameters Holdtime (1): 105s LAN Prune Delay (2) T bit is not set LAN Delay: 500ms Override Interval: 2500ms DR Priority (19): 2 Generation ID (20): 1331494912 ------------------ Any ideas are highly appreciated, Martin From dave.price@aber.ac.uk Wed Mar 1 17:36:12 2006 From: dave.price@aber.ac.uk (Dave Price) Date: Wed, 01 Mar 2006 17:36:12 +0000 Subject: [Xorp-users] Xorp - interface not plugged in problems... In-Reply-To: Your message of Mon, 27 Feb 2006 17:43:35 -0800. <200602280143.k1S1hZCN065090@possum.icir.org> Message-ID: <22197.1141234572@aber.ac.uk> Daer All, I've just built a new five interface Xorp box based on the CVS code I downloaded a few days ago. The OS is a new clean install of Fedora core 4, patched with yum to be up to date etc. I have configured five interfaces and I have configured the appropriate bits, IGMP, PIM-SM etc for it to act as a multicast router. When I tried to start rtrmgr, it refuses to finish to start and exits with messages if any one of the interfaces on the box is not plugged in to a live network port at the time I start it. Is this behaviour intended?? Surely one would want it to bring up the interfaces that were plugged in at the time and then bring up the extra interface later when it too got plugged in. Completely dying just because one interface is not plugged in seems a bit wrong. Have I missed some option to tell it to carry on regardless perhaps?? If I make sure that the config only mentions interfaces which are plugged in to live switch ports then all starts fine. Thanks Folks, Dave Price -- Dave Price, Email: dap@aber.ac.uk PHONE: +44 1970 622428 FAX: +44 1970 628536 Post: Computer Science, University of Wales, Penglais, Aberystwyth, WALES, UK, SY23 3DB. From pavlin@icir.org Wed Mar 1 19:46:09 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 01 Mar 2006 11:46:09 -0800 Subject: [Xorp-users] Xorp debug messages In-Reply-To: Message from Martin Hoffmann of "Wed, 01 Mar 2006 13:40:51 GMT." <4405A463.9020001@bris.ac.uk> Message-ID: <200603011946.k21Jk9A6019613@possum.icir.org> > I'm currently testing my Click router multicast elements against Xorp. > > What is the easiest way to make Xorp print information about the PIM > messages it received? Is there a way to enable Debug output for PIM only? Add the following to your XORP configuration: protocols { pimsm4 { ... traceoptions { flag all { disable: false } } } } In addition, you could add the following to the top of pim/pim_node.cc and recompile: #define DEBUG_LOGGING #define DEBUG_PRINT_FUNCTION_NAME With the latter solution PIM will print "Received message from ..." for any message received from the MFEA. > My PIM Hello messages have the following format (captured with > tethereal). I do not see the point why Xorp's PIM does not recognise them: > > ----------------- > Capturing on eth3 > Frame 1 (72 bytes on wire, 72 bytes captured) > Arrival Time: Mar 1, 2006 13:05:56.263655000 > Time delta from previous packet: 0.000000000 seconds > Time since reference or first frame: 0.000000000 seconds > Frame Number: 1 > Packet Length: 72 bytes > Capture Length: 72 bytes > Protocols in frame: eth:ip:pim > Ethernet II, Src: Intel_08:f0:a8 (00:04:23:08:f0:a8), Dst: > 01:00:5e:00:00:0d (01:00:5e:00:00:0d) > Destination: 01:00:5e:00:00:0d (01:00:5e:00:00:0d) > Source: Intel_08:f0:a8 (00:04:23:08:f0:a8) > Type: IP (0x0800) > Internet Protocol, Src: 172.20.12.1 (172.20.12.1), Dst: 224.0.0.13 > (224.0.0.13) > Version: 4 > Header length: 24 bytes > Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; > ECN: 0x00) > 1100 00.. = Differentiated Services Codepoint: Class Selector 6 > (0x30) > .... ..0. = ECN-Capable Transport (ECT): 0 > .... ...0 = ECN-CE: 0 > Total Length: 58 > Identification: 0xf45f (62559) > Flags: 0x00 > 0... = Reserved bit: Not set > .0.. = Don't fragment: Not set > ..0. = More fragments: Not set > Fragment offset: 0 > Time to live: 1 > Protocol: PIM (0x67) > Header checksum: 0x9716 [correct] > Good: True > Bad : False > Source: 172.20.12.1 (172.20.12.1) > Destination: 224.0.0.13 (224.0.0.13) > Options: (4 bytes) > Router Alert: Every router examines packet > Protocol Independent Multicast > Version: 2 > Type: Hello (0) > Checksum: 0x8447 [correct] > PIM parameters > Holdtime (1): 105s > LAN Prune Delay (2) > T bit is not set > LAN Delay: 500ms > Override Interval: 2500ms > DR Priority (19): 2 > Generation ID (20): 1331494912 > ------------------ There is nothing unusual I can see about the above message, so the starting point would be to see whether the PIM-SM module receives it at all. If not, then try to find whether the MFEA receives it. In general, if you want to print something for debug purpose inside the PIM-SM module or MFEA, use the XLOG_* facility (recommended) or fprintf(stderr), but don't use printf() or fprintf(stdout). Pavlin From pavlin@icir.org Thu Mar 2 02:01:49 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 01 Mar 2006 18:01:49 -0800 Subject: [Xorp-users] Xorp - interface not plugged in problems... In-Reply-To: Message from Dave Price of "Wed, 01 Mar 2006 17:36:12 GMT." <22197.1141234572@aber.ac.uk> Message-ID: <200603020201.k2221n3n077369@possum.icir.org> > I've just built a new five interface > Xorp box based on the CVS code I downloaded a few days ago. > > The OS is a new clean install of Fedora core 4, patched > with yum to be up to date etc. > > I have configured five interfaces and I have configured > the appropriate bits, IGMP, PIM-SM etc for it to act as a multicast router. > > When I tried to start rtrmgr, it refuses to finish > to start and exits with messages > if any one of the interfaces > on the box is not plugged in to a live network > port at the time I start it. > > Is this behaviour intended?? No, this is a bug. Unfortunately, fixing it properly is not going to be trivial, so the fix will be postponed until after the 1.2 release. I just created a bugzilla entry about it so you can add yourself to the CC list and track its status: http://www.xorp.org/bugzilla/show_bug.cgi?id=560 Pavlin > Surely one would want it to bring up the interfaces > that were plugged in at the time and then bring up the extra > interface later when it too got plugged in. Completely > dying just because one interface is not plugged in > seems a bit wrong. > > Have I missed some option to tell it to carry on regardless perhaps?? > > If I make sure that the config only mentions interfaces > which are plugged in to live switch ports then all starts fine. From mh5942@bris.ac.uk Thu Mar 2 16:24:32 2006 From: mh5942@bris.ac.uk (Martin Hoffmann) Date: Thu, 02 Mar 2006 16:24:32 +0000 Subject: [Xorp-users] Xorp debug messages In-Reply-To: <200603011946.k21Jk9A6019613@possum.icir.org> References: <200603011946.k21Jk9A6019613@possum.icir.org> Message-ID: <44071C40.2090105@bris.ac.uk> Hi Pavlin, Thanks for your ideas but I still couldn't figure out whats wrong. I added the debug output but it seems MFEA does not get the PIM messages - whyever. Can you have a quick glance at my .boot-file? Maybe I missed something there. --------- interfaces { interface eth3 { description: "een5047" disable: false vif eth3 { disable: false address 172.30.12.2 { prefix-length: 16 broadcast: 172.30.255.255 disable: false } } } interface eth5 { description: "een5212" disable: false vif eth5 { disable: false address 172.20.100.6 { prefix-length: 16 broadcast: 172.20.255.255 disable: false } } } } fea { unicast-forwarding4 { disable: false } } plumbing { mfea4 { disable: false interface eth3 { vif eth3 { disable: false } } interface eth5 { vif eth5 { disable: false } } interface register_vif { vif register_vif { /* Note: this vif should be always enabled */ disable: false } } traceoptions { flag all { disable: false } } } } protocols { igmp { disable: false interface eth3 { vif eth3 { disable: false } } interface eth5 { vif eth5 { disable: false } } traceoptions { flag all { disable: false } } } } protocols { pimsm4 { disable: false interface eth3 { vif eth3 { disable: false } } interface eth5 { vif eth5 { disable: false } } interface register_vif { vif register_vif { /* Note: this vif should be always enabled */ disable: false } } static-rps { rp 172.20.12.19 { group-prefix 224.0.0.0/4 { } } } switch-to-spt-threshold { disable: false interval-sec: 3 bytes: 1 } traceoptions { flag all { disable: false } } } } protocols { fib2mrib { disable: false } } ------------ Regards, Martin Pavlin Radoslavov wrote: >>I'm currently testing my Click router multicast elements against Xorp. >> >>What is the easiest way to make Xorp print information about the PIM >>messages it received? Is there a way to enable Debug output for PIM only? >> >> > >Add the following to your XORP configuration: > >protocols { > pimsm4 { > ... > traceoptions { > flag all { > disable: false > } > } > } >} > >In addition, you could add the following to the top of >pim/pim_node.cc and recompile: > >#define DEBUG_LOGGING >#define DEBUG_PRINT_FUNCTION_NAME > >With the latter solution PIM will print "Received message from ..." >for any message received from the MFEA. > > > >>My PIM Hello messages have the following format (captured with >>tethereal). I do not see the point why Xorp's PIM does not recognise them: >> >>----------------- >>Capturing on eth3 >>Frame 1 (72 bytes on wire, 72 bytes captured) >> Arrival Time: Mar 1, 2006 13:05:56.263655000 >> Time delta from previous packet: 0.000000000 seconds >> Time since reference or first frame: 0.000000000 seconds >> Frame Number: 1 >> Packet Length: 72 bytes >> Capture Length: 72 bytes >> Protocols in frame: eth:ip:pim >>Ethernet II, Src: Intel_08:f0:a8 (00:04:23:08:f0:a8), Dst: >>01:00:5e:00:00:0d (01:00:5e:00:00:0d) >> Destination: 01:00:5e:00:00:0d (01:00:5e:00:00:0d) >> Source: Intel_08:f0:a8 (00:04:23:08:f0:a8) >> Type: IP (0x0800) >>Internet Protocol, Src: 172.20.12.1 (172.20.12.1), Dst: 224.0.0.13 >>(224.0.0.13) >> Version: 4 >> Header length: 24 bytes >> Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; >>ECN: 0x00) >> 1100 00.. = Differentiated Services Codepoint: Class Selector 6 >>(0x30) >> .... ..0. = ECN-Capable Transport (ECT): 0 >> .... ...0 = ECN-CE: 0 >> Total Length: 58 >> Identification: 0xf45f (62559) >> Flags: 0x00 >> 0... = Reserved bit: Not set >> .0.. = Don't fragment: Not set >> ..0. = More fragments: Not set >> Fragment offset: 0 >> Time to live: 1 >> Protocol: PIM (0x67) >> Header checksum: 0x9716 [correct] >> Good: True >> Bad : False >> Source: 172.20.12.1 (172.20.12.1) >> Destination: 224.0.0.13 (224.0.0.13) >> Options: (4 bytes) >> Router Alert: Every router examines packet >>Protocol Independent Multicast >> Version: 2 >> Type: Hello (0) >> Checksum: 0x8447 [correct] >> PIM parameters >> Holdtime (1): 105s >> LAN Prune Delay (2) >> T bit is not set >> LAN Delay: 500ms >> Override Interval: 2500ms >> DR Priority (19): 2 >> Generation ID (20): 1331494912 >>------------------ >> >> > >There is nothing unusual I can see about the above message, so the >starting point would be to see whether the PIM-SM module receives it >at all. If not, then try to find whether the MFEA receives it. > >In general, if you want to print something for debug purpose inside >the PIM-SM module or MFEA, use the XLOG_* facility (recommended) or >fprintf(stderr), but don't use printf() or fprintf(stdout). > >Pavlin > > From dave.price@aber.ac.uk Thu Mar 2 18:28:32 2006 From: dave.price@aber.ac.uk (Dave Price) Date: Thu, 02 Mar 2006 18:28:32 +0000 Subject: [Xorp-users] suggested init.d scripts to start xorp anyone? Message-ID: <24499.1141324112@aber.ac.uk> Dear All, I am running xorp, for multicast routing only, on a fedora core 4 box that is doing nothing else. Does anyone have a suggested script to place in /etc/init.d to start it in an appropriate way? 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 pavlin@icir.org Thu Mar 2 20:30:48 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 02 Mar 2006 12:30:48 -0800 Subject: Linux IPv6 multicast routing (was Re: [Xorp-users] Xorp debug messages) In-Reply-To: Message from Chris Robson NRL of "Thu, 02 Mar 2006 05:30:42 EST." <6.2.1.2.2.20060302052913.02209640@ginger.cmf.nrl.navy.mil> Message-ID: <200603022030.k22KUm1k088053@possum.icir.org> > Anyone successfully built a Fedora Core 4 system with IPv6 multicast? I'm > using pim6sd which seems to have some issues with multicasting out several > interfaces. See the following email about some info on the subject: http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2005-November/000901.html Pavlin From pavlin@icir.org Thu Mar 2 22:31:09 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 02 Mar 2006 14:31:09 -0800 Subject: [Xorp-users] Xorp debug messages In-Reply-To: Message from Martin Hoffmann of "Thu, 02 Mar 2006 16:24:32 GMT." <44071C40.2090105@bris.ac.uk> Message-ID: <200603022231.k22MV95Y088960@possum.icir.org> > Thanks for your ideas but I still couldn't figure out whats wrong. I > added the debug output but it seems MFEA does not get the PIM messages - > whyever. > > Can you have a quick glance at my .boot-file? Maybe I missed something > there. Your XORP configuration seems fine. Can you confirm that it works for you without Click. Also, can you provide more details about how exactly you are using Click with XORP? E.g., are you using Click in kernel-mode or user-mode, are the Click elements in the middle of the processing path for PIM control messages and how the packets get from there to the MFEA in userland, etc. Pavlin > --------- > interfaces { > > interface eth3 { > description: "een5047" > disable: false > vif eth3 { > disable: false > address 172.30.12.2 { > prefix-length: 16 > broadcast: 172.30.255.255 > disable: false > } > } > } > interface eth5 { > description: "een5212" > disable: false > vif eth5 { > disable: false > address 172.20.100.6 { > prefix-length: 16 > broadcast: 172.20.255.255 > disable: false > } > } > } > } > > fea { > unicast-forwarding4 { > disable: false > } > } > plumbing { > mfea4 { > disable: false > interface eth3 { > vif eth3 { > disable: false > } > } > interface eth5 { > vif eth5 { > disable: false > } > } > interface register_vif { > vif register_vif { > /* Note: this vif should be always enabled */ > disable: false > } > } > traceoptions { > flag all { > disable: false > } > } > } > } > protocols { > igmp { > disable: false > interface eth3 { > vif eth3 { > disable: false > } > } > interface eth5 { > vif eth5 { > disable: false > } > } > traceoptions { > flag all { > disable: false > } > } > } > } > protocols { > pimsm4 { > disable: false > interface eth3 { > vif eth3 { > disable: false > } > } > interface eth5 { > vif eth5 { > disable: false > } > } > interface register_vif { > vif register_vif { > /* Note: this vif should be always enabled */ > disable: false > } > } > > static-rps { > rp 172.20.12.19 { > group-prefix 224.0.0.0/4 { > } > } > } > switch-to-spt-threshold { > disable: false > interval-sec: 3 > bytes: 1 > } > > traceoptions { > flag all { > disable: false > } > } > } > } > > protocols { > fib2mrib { > disable: false > } > } > ------------ From pavlin@icir.org Thu Mar 2 22:38:27 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 02 Mar 2006 14:38:27 -0800 Subject: [Xorp-users] suggested init.d scripts to start xorp anyone? In-Reply-To: Message from Dave Price of "Thu, 02 Mar 2006 18:28:32 GMT." <24499.1141324112@aber.ac.uk> Message-ID: <200603022238.k22McRNV089051@possum.icir.org> > I am running xorp, for multicast routing only, on a fedora core 4 box that > is doing nothing else. > > Does anyone have a suggested script to place in /etc/init.d to start it > in an appropriate way? Unfortunately, we (XORP) don't have such script, but we would like to have one in our tree. Ideally, we should have a solution for other OS-es as well. Contributions are welcome. Pavlin From batkinson@virtc.com Thu Mar 2 23:45:49 2006 From: batkinson@virtc.com (Brian Atkinson) Date: Thu, 2 Mar 2006 23:45:49 GMT Subject: [Xorp-users] suggested init.d scripts to start xorp anyone? Message-ID: <1141343149.98952@virtc.com> Dave, Below is the script that I use to start xorp at startup. I have installed it in /etc/init.d on Fedora Core 3, and then configured it as a service using the "services" gui provided by the OS. Hope this helps you out, or at least gives you a starting point for your particular applicaiton. Best regards, Brian Atkinson Orlando, Fl --------------------------------------- #!/bin/bash # start() { echo -n $"Starting xorp_rtrmgr... " /sbin/logsave -s /var/log/xorp_rtrmgr.log /usr/local/xorp/bin/xorp_rtrmgr &> /dev/null & RETVAL=$? echo return $RETVAL } stop() { echo -n $"Shutting down (stopping) xorp_rtrmgr: " /usr/bin/kill -2 `pgrep xorp_rtrmgr` RETVAL=$? echo return $RETVAL } kill() { echo -n $"Shutting down (killing) xorp_rtrmgr: " for i in `pgrep xorp`; do /usr/bin/kill -9 $i; done RETVAL=$? echo return $RETVAL } restart() { kill start RETVAL=$? echo return $RETVAL } RETVAL=0 # See how we were called. case "$1" in start) start ;; stop) stop ;; kill) kill ;; restart|reload) restart ;; *) echo $"Usage: $0 {start|stop|kill|restart}" exit 1 esac exit $? From Chris.Robson@nrl.navy.mil Thu Mar 2 10:30:42 2006 From: Chris.Robson@nrl.navy.mil (Chris Robson NRL) Date: Thu, 02 Mar 2006 05:30:42 -0500 Subject: [Xorp-users] Xorp debug messages In-Reply-To: <200603011946.k21Jk9A6019613@possum.icir.org> References: <200603011946.k21Jk9A6019613@possum.icir.org> Message-ID: <6.2.1.2.2.20060302052913.02209640@ginger.cmf.nrl.navy.mil> Anyone successfully built a Fedora Core 4 system with IPv6 multicast? I'm using pim6sd which seems to have some issues with multicasting out several interfaces. Thanks..... At 02:46 PM 3/1/2006, Pavlin Radoslavov wrote: > > I'm currently testing my Click router multicast elements against Xorp. > > > > What is the easiest way to make Xorp print information about the PIM > > messages it received? Is there a way to enable Debug output for PIM only? > >Add the following to your XORP configuration: > >protocols { > pimsm4 { > ... > traceoptions { > flag all { > disable: false > } > } > } >} > >In addition, you could add the following to the top of >pim/pim_node.cc and recompile: > >#define DEBUG_LOGGING >#define DEBUG_PRINT_FUNCTION_NAME > >With the latter solution PIM will print "Received message from ..." >for any message received from the MFEA. > > > My PIM Hello messages have the following format (captured with > > tethereal). I do not see the point why Xorp's PIM does not recognise them: > > > > ----------------- > > Capturing on eth3 > > Frame 1 (72 bytes on wire, 72 bytes captured) > > Arrival Time: Mar 1, 2006 13:05:56.263655000 > > Time delta from previous packet: 0.000000000 seconds > > Time since reference or first frame: 0.000000000 seconds > > Frame Number: 1 > > Packet Length: 72 bytes > > Capture Length: 72 bytes > > Protocols in frame: eth:ip:pim > > Ethernet II, Src: Intel_08:f0:a8 (00:04:23:08:f0:a8), Dst: > > 01:00:5e:00:00:0d (01:00:5e:00:00:0d) > > Destination: 01:00:5e:00:00:0d (01:00:5e:00:00:0d) > > Source: Intel_08:f0:a8 (00:04:23:08:f0:a8) > > Type: IP (0x0800) > > Internet Protocol, Src: 172.20.12.1 (172.20.12.1), Dst: 224.0.0.13 > > (224.0.0.13) > > Version: 4 > > Header length: 24 bytes > > Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; > > ECN: 0x00) > > 1100 00.. = Differentiated Services Codepoint: Class Selector 6 > > (0x30) > > .... ..0. = ECN-Capable Transport (ECT): 0 > > .... ...0 = ECN-CE: 0 > > Total Length: 58 > > Identification: 0xf45f (62559) > > Flags: 0x00 > > 0... = Reserved bit: Not set > > .0.. = Don't fragment: Not set > > ..0. = More fragments: Not set > > Fragment offset: 0 > > Time to live: 1 > > Protocol: PIM (0x67) > > Header checksum: 0x9716 [correct] > > Good: True > > Bad : False > > Source: 172.20.12.1 (172.20.12.1) > > Destination: 224.0.0.13 (224.0.0.13) > > Options: (4 bytes) > > Router Alert: Every router examines packet > > Protocol Independent Multicast > > Version: 2 > > Type: Hello (0) > > Checksum: 0x8447 [correct] > > PIM parameters > > Holdtime (1): 105s > > LAN Prune Delay (2) > > T bit is not set > > LAN Delay: 500ms > > Override Interval: 2500ms > > DR Priority (19): 2 > > Generation ID (20): 1331494912 > > ------------------ > >There is nothing unusual I can see about the above message, so the >starting point would be to see whether the PIM-SM module receives it >at all. If not, then try to find whether the MFEA receives it. > >In general, if you want to print something for debug purpose inside >the PIM-SM module or MFEA, use the XLOG_* facility (recommended) or >fprintf(stderr), but don't use printf() or fprintf(stdout). > >Pavlin >_______________________________________________ >Xorp-users mailing list >Xorp-users@xorp.org >http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users Christopher L. Robson GS-1550-NP-IV (V/C) 202-404-3138 EMAIL: Chris.Robson@nrl.navy.mil GIG-EF SIP: Chris.Robson@nrl.gigef.net DoN, NRL, Code 5590 4555 Overlook Ave Washington, D.C. 20375 From alain@ait.ac.th Fri Mar 3 02:33:27 2006 From: alain@ait.ac.th (Alain Fauconnet) Date: Fri, 3 Mar 2006 09:33:27 +0700 Subject: [Xorp-users] suggested init.d scripts to start xorp anyone? In-Reply-To: <200603022238.k22McRNV089051@possum.icir.org> References: <24499.1141324112@aber.ac.uk> <200603022238.k22McRNV089051@possum.icir.org> Message-ID: <20060303023327.GB8181@ait.ac.th> On Thu, Mar 02, 2006 at 02:38:27PM -0800, Pavlin Radoslavov wrote: > > I am running xorp, for multicast routing only, on a fedora core 4 box that > > is doing nothing else. > > > > Does anyone have a suggested script to place in /etc/init.d to start it > > in an appropriate way? > > Unfortunately, we (XORP) don't have such script, but we would like > to have one in our tree. Ideally, we should have a solution for > other OS-es as well. Contributions are welcome. Here's the one I use on a RH 7.3-based router box. (I know RH 7.3 is paleolitic, it's self-maintained from source now) Comments welcome. Greets, _Alain_ ---------------------------- cut here ------------------------------- #!/bin/bash # # xorp This shell script takes care of starting and stopping # the xorp service. # # chkconfig: 345 57 49 # description: xorp is a network routing daemon. # Change history: # ~~~~~~~~~~~~~~ # 22-Mar-2005 AlainF Rotate the log file, kill all remaining # processes at stop # 04-Apr-2005 AlainF Keep 3 rotated log files as .1, .2, .3 # Source function library. . /etc/rc.d/init.d/functions XORPDIR=/usr/local/xorp BINDIR=${XORPDIR}/bin LOGFILE=/var/log/xorp.log OPTIONS=-v [ -f $BINDIR/xorp_rtrmgr ] || exit 0 prog="xorp" start() { echo -n $"Starting $prog: " # Rotate log files if [ -f ${LOGFILE} ]; then [ -f ${LOGFILE}.2 ] && /bin/mv ${LOGFILE}.2 ${LOGFILE}.3 [ -f ${LOGFILE}.1 ] && /bin/mv ${LOGFILE}.1 ${LOGFILE}.2 /bin/mv ${LOGFILE} ${LOGFILE}.1 fi # Change current directory to Xorp's root if [ -d ${XORPDIR} ]; then cd ${XORPDIR} else exit 1 fi $BINDIR/xorp_rtrmgr $OPTIONS 2>&1 | /bin/cat >$LOGFILE & RETVAL=$? if [ $RETVAL = 0 ]; then success $"Starting $prog" else failure $"Starting $prog" fi echo return $RETVAL } stop() { echo -n $"Stopping $prog: " # Kill master process pid=`/bin/ps auxww | /bin/grep ${XORPDIR} | /bin/grep xorp_rtrmgr|\ /bin/grep -v grep | /usr/bin/awk '{print $2}'` if [ "$pid" != "" ]; then kill -15 ${pid} else # No master process?!? try proceeding anyway echo -n " (no master process found) " fi # Give it a while to signal other processes sleep 15 # Kill any remaining processes pids=`/bin/ps auxww | /bin/grep ${XORPDIR} | /bin/grep -v grep |\ /usr/bin/awk '{print $2}'` if [ "$pids" != "" ]; then kill -15 ${pids} fi success $"Stopping $prog" echo return 0 } case "$1" in start) start ;; stop) stop ;; status) status $prog ;; restart) stop start ;; *) echo "Usage: $prog {start|stop|restart|status}" exit 1 esac exit 0 ---------------------------- cut here ------------------------------- From I.FernandezDiaz@telecom.tno.nl Fri Mar 3 10:37:25 2006 From: I.FernandezDiaz@telecom.tno.nl (I.FernandezDiaz@telecom.tno.nl) Date: Fri, 3 Mar 2006 11:37:25 +0100 Subject: [Xorp-users] Problem starting xorp_rtrmgr in 1.2 RC Message-ID: <81FEC275650AE14EBD5245E624762B9701F4F303@ds07.tnoase.telecom.tno.nl> This is a multi-part message in MIME format. ------_=_NextPart_001_01C63EAE.764BC447 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, I installed 1.2 RC on FreeBSD 4.10 and compiled with the default compiler and gmake 3.79.1. When I try to start the xorp_rtrmgr as root, first a number of modules are started and then I get the following message: [ 2006/03/03 11:04:25 INFO xorp_fea MFEA ] CLI enabled [ 2006/03/03 11:04:26 INFO xorp_fea MFEA ] CLI started [ 2006/03/03 11:04:27 INFO xorp_rtrmgr:230 RTRMGR +99 module_manager.cc execute ] Executing module: fea (fea/xorp_fea) [ 2006/03/03 11:04:33 INFO xorp_rtrmgr:230 RTRMGR +2228 task.cc run_task ] No m ore tasks to run Afterwards nothing happens, no prompt, nothing. After CRTL C I get: ^C [ 2006/03/03 11:04:52 INFO xorp_rtrmgr:230 RTRMGR +174 module_manager.cc termin ate ] Terminating module: fea [ 2006/03/03 11:04:52 INFO xorp_rtrmgr:230 RTRMGR +1019 task.cc shutdown ] Shut ting down module: interfaces [ 2006/03/03 11:04:52 INFO xorp_fea MFEA ] CLI stopped [ 2006/03/03 11:04:52 INFO xorp_fea MFEA ] CLI stopped [ 2006/03/03 11:04:52 INFO xorp_rtrmgr:230 RTRMGR +278 module_manager.cc module _exited ] Module normal exit: interfaces [ 2006/03/03 11:04:53 INFO xorp_rtrmgr:230 RTRMGR +2228 task.cc run_task ] No m ore tasks to run I am using a very simple config file: /* $XORP: xorp/rtrmgr/config.boot.sample,v 1.33 2005/10/28 18:55:34 pavlin Exp $ */ interfaces { restore-original-config-on-shutdown: false interface em0 { description: "data interface" disable: false default-system-config=20 } =09 } fea { unicast-forwarding4 { disable: false } } Does anybody know how I can start the rtrmgr? What is the normal behaviour when I start it? Thank you. Regards, Irene Fernandez ------_=_NextPart_001_01C63EAE.764BC447 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Problem starting xorp_rtrmgr in 1.2 RC

Dear = All,

I installed 1.2 RC on = FreeBSD 4.10 and compiled with the default compiler and gmake = 3.79.1.
When I try to start = the xorp_rtrmgr as root, first a number of modules are started and then = I get the following message:

[ 2006/03/03 = 11:04:25 INFO xorp_fea MFEA ] CLI enabled
[ = 2006/03/03 11:04:26 INFO xorp_fea MFEA ] CLI started
[ = 2006/03/03 11:04:27  INFO xorp_rtrmgr:230 RTRMGR +99 = module_manager.cc execute
 ] = Executing module: fea (fea/xorp_fea)
[ = 2006/03/03 11:04:33  INFO xorp_rtrmgr:230 RTRMGR +2228 task.cc = run_task ] No m
ore tasks = to run

Afterwards = nothing happens, no prompt, nothing. After CRTL C I get:

^C
[ = 2006/03/03 11:04:52  INFO xorp_rtrmgr:230 RTRMGR +174 = module_manager.cc termin
ate ] = Terminating module: fea
[ = 2006/03/03 11:04:52  INFO xorp_rtrmgr:230 RTRMGR +1019 task.cc = shutdown ] Shut
ting down = module: interfaces
[ = 2006/03/03 11:04:52 INFO xorp_fea MFEA ] CLI stopped
[ = 2006/03/03 11:04:52 INFO xorp_fea MFEA ] CLI stopped
[ = 2006/03/03 11:04:52  INFO xorp_rtrmgr:230 RTRMGR +278 = module_manager.cc module
_exited ] = Module normal exit: interfaces
[ = 2006/03/03 11:04:53  INFO xorp_rtrmgr:230 RTRMGR +2228 task.cc = run_task ] No m
ore tasks to = run

I am using a very = simple config file:

/* $XORP: = xorp/rtrmgr/config.boot.sample,v 1.33 2005/10/28 18:55:34 pavlin Exp $ = */


interfaces = {
    restore-original-config-on-shutdown: = false
    interface em0 {
        = description: "data = interface"
        = disable: false
        = default-system-config
        =     }
        =
}

fea = {
    unicast-forwarding4 {
        = disable: false
    }
}

Does anybody know = how I can start the rtrmgr? What is the normal behaviour when I start = it?

Thank you. = Regards,

Irene = Fernandez

------_=_NextPart_001_01C63EAE.764BC447-- From kristian@juniks.net Fri Mar 3 13:48:31 2006 From: kristian@juniks.net (Kristian Larsson) Date: Fri, 3 Mar 2006 14:48:31 +0100 Subject: [Xorp-users] Problem starting xorp_rtrmgr in 1.2 RC In-Reply-To: <81FEC275650AE14EBD5245E624762B9701F4F303@ds07.tnoase.telecom.tno.nl> References: <81FEC275650AE14EBD5245E624762B9701F4F303@ds07.tnoase.telecom.tno.nl> Message-ID: <20060303134831.GA9781@juniks.net> On Fri, Mar 03, 2006 at 11:37:25AM +0100, I.FernandezDiaz@telecom.tno.nl wrote: > Dear All, > > I installed 1.2 RC on FreeBSD 4.10 and compiled with the default > compiler and gmake 3.79.1. > When I try to start the xorp_rtrmgr as root, first a number of modules > are started and then I get the following message: > > [ 2006/03/03 11:04:25 INFO xorp_fea MFEA ] CLI enabled > [ 2006/03/03 11:04:26 INFO xorp_fea MFEA ] CLI started > [ 2006/03/03 11:04:27 INFO xorp_rtrmgr:230 RTRMGR +99 module_manager.cc > execute > ] Executing module: fea (fea/xorp_fea) > [ 2006/03/03 11:04:33 INFO xorp_rtrmgr:230 RTRMGR +2228 task.cc > run_task ] No m > ore tasks to run > > Afterwards nothing happens, no prompt, nothing. After CRTL C I get: > > ^C > [ 2006/03/03 11:04:52 INFO xorp_rtrmgr:230 RTRMGR +174 > module_manager.cc termin > ate ] Terminating module: fea > [ 2006/03/03 11:04:52 INFO xorp_rtrmgr:230 RTRMGR +1019 task.cc > shutdown ] Shut > ting down module: interfaces > [ 2006/03/03 11:04:52 INFO xorp_fea MFEA ] CLI stopped > [ 2006/03/03 11:04:52 INFO xorp_fea MFEA ] CLI stopped > [ 2006/03/03 11:04:52 INFO xorp_rtrmgr:230 RTRMGR +278 > module_manager.cc module > _exited ] Module normal exit: interfaces > [ 2006/03/03 11:04:53 INFO xorp_rtrmgr:230 RTRMGR +2228 task.cc > run_task ] No m > ore tasks to run > > I am using a very simple config file: > > /* $XORP: xorp/rtrmgr/config.boot.sample,v 1.33 2005/10/28 18:55:34 > pavlin Exp $ */ > > > interfaces { > restore-original-config-on-shutdown: false > interface em0 { > description: "data interface" > disable: false > default-system-config > } > > } > > fea { > unicast-forwarding4 { > disable: false > } > } > > Does anybody know how I can start the rtrmgr? What is the normal > behaviour when I start it? You are seing the normal behaviour. Start another shell and exeute 'xorpsh' it will give you a nice prompt. The rtrmgr is just a background process that takes care of a lot of things for you. Kristian. From dave.price@aber.ac.uk Fri Mar 3 15:08:13 2006 From: dave.price@aber.ac.uk (Dave Price) Date: Fri, 03 Mar 2006 15:08:13 +0000 Subject: [Xorp-users] Problem starting xorp_rtrmgr in 1.2 RC In-Reply-To: Your message of Fri, 03 Mar 2006 14:48:31 +0100. <20060303134831.GA9781@juniks.net> Message-ID: <26959.1141398493@aber.ac.uk> Dear Kristian and All, kristian@juniks.net said: > You are seing the normal behaviour. Start another shell and exeute > 'xorpsh' it will give you a nice prompt. Actually, that a point in meant to query in my email yesterday. Is there any real reason why rtrmgr does not (have an option at least to) disconnect from open file descriptors and run as a background daemon as most programs of this nature would?? Dave Price -- Dave Price, Email: dap@aber.ac.uk PHONE: +44 1970 622428 FAX: +44 1970 628536 Post: Computer Science, University of Wales, Penglais, Aberystwyth, WALES, UK, SY23 3DB. From atanu@ICSI.Berkeley.EDU Fri Mar 3 16:39:58 2006 From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh) Date: Fri, 03 Mar 2006 08:39:58 -0800 Subject: [Xorp-users] Problem starting xorp_rtrmgr in 1.2 RC In-Reply-To: Message from Dave Price of "Fri, 03 Mar 2006 15:08:13 GMT." <26959.1141398493@aber.ac.uk> Message-ID: <1463.1141403998@tigger.icir.org> >>>>> "Dave" == Dave Price writes: Dave> Is there any real reason why rtrmgr does not (have an option Dave> at least to) disconnect from open file descriptors and run as Dave> a background daemon as most programs of this nature would?? I think that you are right the rtrmgr should have an option to run as a background daemon. Before we make such a change we would need to decide what to do with the output from the XORP processes, discard, send to syslog, put in a logfile in /var/log. In the code all output is generated with macros that would map directly to syslog priorities, we have just never tied XORP to syslog. Atanu. From mhorn@vyatta.com Fri Mar 3 18:15:15 2006 From: mhorn@vyatta.com (Mike Horn) Date: Fri, 3 Mar 2006 10:15:15 -0800 (PST) Subject: [Xorp-users] Problem starting xorp_rtrmgr in 1.2 RC Message-ID: <7394935.5371141409715703.JavaMail.root@mail.vyatta.com> You can use output redirection and & (background) to run rtrmgr in the background, here's an example: [root@fedora rtrmgr]# ./xorp_rtrmgr > /var/log/messages 2>&1 & [1] 6712 [root@fedora rtrmgr]# ./xorpsh Welcome to XORP on fedora root@fedora> This redirects all STDOUT and STDERR to /var/log/messages. I'm sure there are better ways to do this, but it gets the job done ;-) -mike ----- Original Message ----- From: Atanu Ghosh To: Dave Price Cc: Kristian Larsson , I FernandezDiaz , xorp-users@xorp.org, dap@aber.ac.uk Sent: Friday, March 3, 2006 9:39:58 AM GMT-0700 Subject: Re: [Xorp-users] Problem starting xorp_rtrmgr in 1.2 RC >>>>> "Dave" == Dave Price writes: Dave> Is there any real reason why rtrmgr does not (have an option Dave> at least to) disconnect from open file descriptors and run as Dave> a background daemon as most programs of this nature would?? I think that you are right the rtrmgr should have an option to run as a background daemon. Before we make such a change we would need to decide what to do with the output from the XORP processes, discard, send to syslog, put in a logfile in /var/log. In the code all output is generated with macros that would map directly to syslog priorities, we have just never tied XORP to syslog. Atanu. _______________________________________________ Xorp-users mailing list Xorp-users@xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin@icir.org Fri Mar 3 18:31:27 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 03 Mar 2006 10:31:27 -0800 Subject: [Xorp-users] Problem starting xorp_rtrmgr in 1.2 RC In-Reply-To: Message from Mike Horn of "Fri, 03 Mar 2006 10:15:15 PST." <7394935.5371141409715703.JavaMail.root@mail.vyatta.com> Message-ID: <200603031831.k23IVRNv007891@possum.icir.org> > You can use output redirection and & (background) to run rtrmgr in the background, here's an example: > > [root@fedora rtrmgr]# ./xorp_rtrmgr > /var/log/messages 2>&1 & I wouldn't recommend doing this :) First, it will truncate the existing /var/log/messages so at least you should use ">>" instead of ">" in the first redirection. Second, there could be some surprises if both the rtrmgr and syslogd are trying to write to the same file. Pavlin > [1] 6712 > [root@fedora rtrmgr]# ./xorpsh > Welcome to XORP on fedora > root@fedora> > > This redirects all STDOUT and STDERR to /var/log/messages. I'm sure there are better ways to do this, but it gets the job done ;-) > > -mike > > ----- Original Message ----- > From: Atanu Ghosh > To: Dave Price > Cc: Kristian Larsson , I FernandezDiaz , xorp-users@xorp.org, dap@aber.ac.uk > Sent: Friday, March 3, 2006 9:39:58 AM GMT-0700 > Subject: Re: [Xorp-users] Problem starting xorp_rtrmgr in 1.2 RC > > >>>>> "Dave" == Dave Price writes: > > Dave> Is there any real reason why rtrmgr does not (have an option > Dave> at least to) disconnect from open file descriptors and run as > Dave> a background daemon as most programs of this nature would?? > > I think that you are right the rtrmgr should have an option to run as a > background daemon. > > Before we make such a change we would need to decide what to do with the > output from the XORP processes, discard, send to syslog, put in a > logfile in /var/log. In the code all output is generated with macros > that would map directly to syslog priorities, we have just never tied > XORP to syslog. > > Atanu. > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > 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 From mhorn@vyatta.com Fri Mar 3 18:53:31 2006 From: mhorn@vyatta.com (Mike Horn) Date: Fri, 3 Mar 2006 10:53:31 -0800 (PST) Subject: [Xorp-users] Problem starting xorp_rtrmgr in 1.2 RC Message-ID: <4811897.5461141412011362.JavaMail.root@mail.vyatta.com> Thanks Pavlin! I have changed how I start rtrmgr to: ./xorp_rtrmgr >> /var/log/rtrmgr.log 2>&1 & This should avoid both problems for the time being until there is a better way. I have found it really helpful to have my log messages in a file. -mike ----- Original Message ----- From: Pavlin Radoslavov To: Mike Horn Cc: Atanu Ghosh , Kristian Larsson , I FernandezDiaz , xorp-users@xorp.org, dap@aber.ac.uk, Dave Price Sent: Friday, March 3, 2006 11:31:27 AM GMT-0700 Subject: Re: [Xorp-users] Problem starting xorp_rtrmgr in 1.2 RC > You can use output redirection and & (background) to run rtrmgr in the background, here's an example: > > [root@fedora rtrmgr]# ./xorp_rtrmgr > /var/log/messages 2>&1 & I wouldn't recommend doing this :) First, it will truncate the existing /var/log/messages so at least you should use ">>" instead of ">" in the first redirection. Second, there could be some surprises if both the rtrmgr and syslogd are trying to write to the same file. Pavlin > [1] 6712 > [root@fedora rtrmgr]# ./xorpsh > Welcome to XORP on fedora > root@fedora> > > This redirects all STDOUT and STDERR to /var/log/messages. I'm sure there are better ways to do this, but it gets the job done ;-) > > -mike > > ----- Original Message ----- > From: Atanu Ghosh > To: Dave Price > Cc: Kristian Larsson , I FernandezDiaz , xorp-users@xorp.org, dap@aber.ac.uk > Sent: Friday, March 3, 2006 9:39:58 AM GMT-0700 > Subject: Re: [Xorp-users] Problem starting xorp_rtrmgr in 1.2 RC > > >>>>> "Dave" == Dave Price writes: > > Dave> Is there any real reason why rtrmgr does not (have an option > Dave> at least to) disconnect from open file descriptors and run as > Dave> a background daemon as most programs of this nature would?? > > I think that you are right the rtrmgr should have an option to run as a > background daemon. > > Before we make such a change we would need to decide what to do with the > output from the XORP processes, discard, send to syslog, put in a > logfile in /var/log. In the code all output is generated with macros > that would map directly to syslog priorities, we have just never tied > XORP to syslog. > > Atanu. > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > 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 _______________________________________________ Xorp-users mailing list Xorp-users@xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From bms@spc.org Fri Mar 3 19:01:50 2006 From: bms@spc.org (Bruce M Simpson) Date: Fri, 3 Mar 2006 19:01:50 +0000 Subject: [Xorp-users] Problem starting xorp_rtrmgr in 1.2 RC In-Reply-To: <1463.1141403998@tigger.icir.org> References: <26959.1141398493@aber.ac.uk> <1463.1141403998@tigger.icir.org> Message-ID: <20060303190150.GL89218@spc.org> On Fri, Mar 03, 2006 at 08:39:58AM -0800, Atanu Ghosh wrote: > I think that you are right the rtrmgr should have an option to run as a > background daemon. I would try FreeBSD's daemon(8) command, too, the problem there is that the logs need to be told to go elsewhere. > Before we make such a change we would need to decide what to do with the > output from the XORP processes, discard, send to syslog, put in a > logfile in /var/log. In the code all output is generated with macros > that would map directly to syslog priorities, we have just never tied > XORP to syslog. There is a patch to make XORP's logging facility use the OutputDebugString API on Windows, the same could probably be done for the Event Logging API there too. BMS From mike@lrlart.com Fri Mar 3 19:43:01 2006 From: mike@lrlart.com (mike@lrlart.com) Date: Fri, 03 Mar 2006 12:43:01 -0700 Subject: [Xorp-users] Problem starting xorp_rtrmgr in 1.2 RC Message-ID: <20060303124301.8c0fa638fcef9dd13f5a2f992b1941af.6ec197f260.wbe@email.email.secureserver.net> ---901761091-437880765-1141414982=:24669 Content-Type: TEXT/plain; CHARSET=US-ASCII Hey all, Here's an smallish change to xorp that allows xorp to support syslogging. It requires a patch to the libxorp/xlog.c and the addition of the attached c and header file (which also belong in the libxorp directory). It doesn't support windows (sorry Bruce). Note that when adding a new .c and .h file the Makefile.am will need to be updated to include rl_syslog.c/.h Mike Larson --- xorp/libxorp/xlog.c 2006-03-02 21:48:11.000000000 +0000 +++ builddir/libxorp/xlog.c 2006-03-03 20:32:26.000000000 +0000 @@ -26,6 +26,8 @@ #include "xorp.h" #include "xlog.h" +#include "rl_syslog.h" + #include #ifdef HAVE_FCNTL_H #include @@ -1007,6 +1009,9 @@ size_t ndefaults = sizeof(defaults) / sizeof(defaults[0]); size_t i; + /* Add RouteLogics hook for syslog logging. */ + xlog_add_output_func(rl_syslog_callback, NULL); + /* * Attempt to open default output stream, console first in case * we are root, then stderr. > -------- Original Message -------- > Subject: Re: [Xorp-users] Problem starting xorp_rtrmgr in 1.2 RC > From: Bruce M Simpson > Date: Fri, March 03, 2006 12:01 pm > To: Atanu Ghosh > Cc: Dave Price , Kristian Larsson > , I.FernandezDiaz@telecom.tno.nl, > xorp-users@xorp.org, dap@aber.ac.uk > > On Fri, Mar 03, 2006 at 08:39:58AM -0800, Atanu Ghosh wrote: > > I think that you are right the rtrmgr should have an option to run as a > > background daemon. > > I would try FreeBSD's daemon(8) command, too, the problem there is that > the logs need to be told to go elsewhere. > > > Before we make such a change we would need to decide what to do with the > > output from the XORP processes, discard, send to syslog, put in a > > logfile in /var/log. In the code all output is generated with macros > > that would map directly to syslog priorities, we have just never tied > > XORP to syslog. > > There is a patch to make XORP's logging facility use the > OutputDebugString API on Windows, the same could probably be done for > the Event Logging API there too. > > BMS > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users ---901761091-437880765-1141414982=:24669 Content-Type: TEXT/x-c; name="rl_syslog.c"; CHARSET=US-ASCII Content-Transfer-Encoding: BASE64 Content-Disposition: attachment; filename="rl_syslog.c" LyoqCiAqCiAqCiAqLwojaW5jbHVkZSA8c3RkaW8uaD4KI2luY2x1ZGUgPHN0 cmluZy5oPgojaW5jbHVkZSA8c3lzL2tsb2cuaD4KI2luY2x1ZGUgPHVuaXN0 ZC5oPgojaW5jbHVkZSA8bGludXgvdW5pc3RkLmg+CiNpbmNsdWRlIDxzeXNs b2cuaD4KI2luY2x1ZGUgInhvcnAuaCIKI2luY2x1ZGUgInJsX3N5c2xvZy5o IgoKLy9UaGUgcHJlZml4IHRoYXQgaXMgdG8gYXBwZW5kIGFsbCBsb2cgbWVz c2FnZXMKLy9zdGF0aWMgY2hhciBybF9zeXNsb2dfbG9nX3ByZWZpeFsyNTVd OwoKaW50IApybF9zeXNsb2dfY2FsbGJhY2sodm9pZCAqZGF0YSwgY29uc3Qg Y2hhciAqYnVmZmVyKQp7CiAgICBybF9zeXNsb2dfbG9nKGJ1ZmZlcik7CiAg ICBVTlVTRUQoZGF0YSk7CiAgICByZXR1cm4gMDsKfQoKdm9pZApybF9zeXNs b2dfbG9nKGNvbnN0IGNoYXIgKmJ1ZmZlcikKewogIGludCBwcmlvcml0eSA9 IHJsX3N5c2xvZ19nZXRfcHJpb3JpdHkoYnVmZmVyKTsKCiAgLy90aGlzIGlz IHdoZXJlIHdlJ2xsIGRvIHRoZSBsb2dnaW5nIHRvIHN5c2xvZwogIHN5c2xv Zyhwcmlvcml0eSwgIiVzIiwgYnVmZmVyKTsKfQoKdm9pZApybF9zeXNsb2df bG9hZF9wcmVwZW5kKHZvaWQpCnsKICAvKgogIC8vdGhpcyBpcyB3aGVyZSB3 ZSByZWFkIGludG8gbWVtb3J5IHRoZSBwcmVwZW5kIHByZWZpeCBpZiB0aGUg ZmlsZSBoYXMgY2hhbmdlZAogIGludCBmZF9yZCwgcmRfd3I7CiAgRklMRSAq ZmRfd3JpdGVzdHJlYW0sICpmZF9yZWFkc3RyZWFtOwoKICBjaGFyIHJsX3N5 c2xvZ19maWxlbmFtZSgicmxfc3lzdGVtL3JsX3N5c2xvZy5jb25mIik7CiAg Y2hhciBybF9zeXNsb2dfZmlsZW5hbWVfbGNrKCJybF9zeXN0ZW0vcmxfc3lz bG9nLmNvbmYubGNrIik7CgogIC8vICBzdHJpbmcgZmlsZWxvY2sgPSBfZmls ZW5hbWUgKyAiLmxjayI7CiAgX2ZkX3dyaXRlID0gb3BlbihybF9zeXNsb2Nr X2ZpbGVfbGNrLCBPX1dST05MWSB8IE9fQ1JFQVQgfCBPX0VYQ0wsIDA2NDQp OwogIGlmIChmZF93ciA8IDAgJiYgZXJybm8gPT0gRUVYSVNUKSB7CiAgICBy ZXR1cm47CiAgfQogIGVsc2UgaWYgKGZkX3dyIDwgMCkgewogICAgcmV0dXJu OwogIH0KCiAgZmRfd3JpdGVzdHJlYW0gPSBmZG9wZW4oZmRfd3IsICJ3Iik7 CiAgaWYgKGZkX3dyaXRlc3RyZWFtID09IE5VTEwpIHsKICAgIGNsb3NlKGZk X3dyKTsKICAgIHVubGluayhybF9zeXNsb2dfZmlsZW5hbWVfbGNrKTsKICAg IHJldHVybjsKICB9CgogIC8vd2UgYXJlIGZyZWUgdG8gbG9jayB0aGlzIGZp bGUgbm93CiAgZmRfcmVhZHN0cmVhbSA9IGZvcGVuKHJsX3N5c2xvZ19maWxl bmFtZSwgInIiKTsgLy9sZXQncyBnZXQgYSBmaWxlIGRlc2NyaXB0b3IKICBp ZiAoZmRfcmQgPT0gTlVMTCkgewogICAgY2xvc2UoZmRfd3IpOwogICAgdW5s aW5rKHJsX3N5c2xvZ19maWxlbmFtZV9sY2spOwogICAgcmV0dXJuOwogIH0K CiAgLy9yZWFkIGluIHN5c2xvZyBwcmVwZW5kIGhlcmUhCiAgaW50IGN0ID0g MDsKICBjaGFyIGxpbmVbMjU2XTsKICBzdHJpbmcga2V5ID0gaG9zdCArICI6 IjsKICB3aGlsZSAoZmdldHMobGluZSwgMjU1LCBmZF9yZCkgIT0gTlVMTCkg ewogICAgaWYgKGtleS5maW5kKHN0cmluZyhsaW5lKSA9PSBzdHJpbmc6Om5w b3MpKSB7CgogICAgICAvL2hlcmUgaXMgd2hlcmUgd2UnbGwgbmVlZCB0byBz dG9yZSB0aGUgaG9zdC9wcmVwZW5kIGluIGEgaGFzaAoKICAgICAgLy9xdWVz dGlvbi0taG93IGFyZSB3ZSBnb2luZyB0byBrbm93IHdoYXQgdGhlIGhvc3Qg aXM/Pz8/PwoKICAgICAgY3QrKzsKICAgIH0KICB9CgoKCgogIGNsb3NlKGZk X3dyKTsKICBmY2xvc2UoZmRfcmVhZHN0cmVhbSk7CiAgZmNsb3NlKGZkX3dy aXRlc3RyZWFtKTsKCiAgcmVuYW1lKHJsX3N5c2xvY2tfZmlsZW5hbWVfbGNr LCBybF9zeXNsb2dfZmlsZW5hbWUpOwogICovCn0KCi8qKgogKiBXQVJOSU5H OiBUaGlzIGZpbGUgaXMgZGVwZW5kZW50IG9uIGNoYW5nZXMgdG8gdGhlIHhv cnAgbG9nZ2luZwogKiBsZXZlbHMuIEFueSBjaGFuZ2VzIG9uIHRoZSB4b3Jw IHNpZGUgbWF5IGJyZWFrIHRoZSBjb2RlIGJlbG93IQogKi8KaW50CnJsX3N5 c2xvZ19nZXRfcHJpb3JpdHkoY29uc3QgY2hhciogYnVmZmVyKQp7CiAgaW50 IGk7CiAgLyoKICAgKiBOT1RFOiBUaGlzIGlzIGR1cGxpY2F0ZWQgZnJvbSB0 aGUgZGF0YSBpbiB4bG9nLmMtLXRvIGF2b2lkCiAgICogYSBjaXJjdWxhciBk ZXBlbmRlbmN5LiAKICAgKi8KCiAgLy9UT0RPOiBQdXQgYSBsaW1pdCBvbiB0 aGUgc3RyY2hyIGNoZWNrLS13aGF0ZXZlciBhIHJlYXNvbmFibGUgCiAgLy9s ZW5ndGggbWF5IGJlLiBUaGlzIGlzIGF2b2lkIGEgbWVzc2FnZSB0aGF0IG1h eSBjb250YWluIGEga2V5d29yZC4KICBmb3IgKGkgPSAwOyBpIDwgNTsgKytp KSB7CiAgICBpZiAoc3Ryc3RyKGJ1ZmZlciwgIkZBVEFMIikgIT0gTlVMTCkg ewogICAgICByZXR1cm4gTE9HX0FMRVJUIHwgTE9HX0xPQ0FMNzsKICAgIH0K ICAgIGVsc2UgaWYgKHN0cnN0cihidWZmZXIsICJFUlJPUiIpICE9IE5VTEwp IHsKICAgICAgcmV0dXJuIExPR19FUlIgfCBMT0dfTE9DQUw3OwogICAgfQog ICAgZWxzZSBpZiAoc3Ryc3RyKGJ1ZmZlciwgIldBUk5JTkciKSAhPSBOVUxM KSB7CiAgICAgIHJldHVybiBMT0dfV0FSTklORyB8IExPR19MT0NBTDc7CiAg ICB9CiAgICBlbHNlIGlmIChzdHJzdHIoYnVmZmVyLCAiSU5GTyIpICE9IE5V TEwpIHsKICAgICAgcmV0dXJuIExPR19JTkZPIHwgTE9HX0xPQ0FMNzsKICAg IH0KICAgIGVsc2UgaWYgKHN0cnN0cihidWZmZXIsICJUUkFDRSIpICE9IE5V TEwpIHsKICAgICAgcmV0dXJuIExPR19ERUJVRyB8IExPR19MT0NBTDc7CiAg ICB9CiAgfQogIHJldHVybiBMT0dfSU5GTyB8IExPR19MT0NBTDc7Cn0K ---901761091-437880765-1141414982=:24669 Content-Type: TEXT/x-c; name="rl_syslog.h"; CHARSET=US-ASCII Content-Transfer-Encoding: BASE64 Content-Disposition: attachment; filename="rl_syslog.h" I2lmbmRlZiBfX0xJQlhPUlBfUkxfU1lTTE9HX0hfXwojZGVmaW5lIF9fTElC WE9SUF9STF9TWVNMT0dfSF9fCgovKioKICoKICoKICoKICovCnZvaWQKcmxf c3lzbG9nX2xvZyhjb25zdCBjaGFyKiBidWZmZXIpOwoKdm9pZApybF9zeXNs b2dfbG9hZF9wcmVwZW5kKHZvaWQpOwoKaW50IApybF9zeXNsb2dfY2FsbGJh Y2sodm9pZCAqZGF0YSwgY29uc3QgY2hhciAqYnVmZmVyKTsKCmludApybF9z eXNsb2dfZ2V0X3ByaW9yaXR5KGNvbnN0IGNoYXIqIGJ1ZmZlcik7CgojZW5k aWYgLy9fX0xJQlhPUlBfUkxfU1lTTE9HX0hfXwo= ---901761091-437880765-1141414982=:24669-- From pavlin@icir.org Fri Mar 3 20:13:04 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 03 Mar 2006 12:13:04 -0800 Subject: [Xorp-users] suggested init.d scripts to start xorp anyone? In-Reply-To: Message from Brian Atkinson of "Thu, 02 Mar 2006 23:45:49 GMT." <1141343149.98952@virtc.com> Message-ID: <200603032013.k23KD4ms008966@possum.icir.org> > Below is the script that I use to start xorp at startup. I have installed it in /etc/init.d on Fedora Core 3, and then configured it as a service using the "services" gui provided by the OS. > > Hope this helps you out, or at least gives you a starting point for your particular applicaiton. Thank you for the script. FYI, there is a bugzilla entry on the subject: http://www.xorp.org/bugzilla/show_bug.cgi?id=119 I added your script as an attachment to that entry so it won't be lost. Pavlin From pavlin@icir.org Fri Mar 3 20:15:18 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 03 Mar 2006 12:15:18 -0800 Subject: [Xorp-users] Problem starting xorp_rtrmgr in 1.2 RC In-Reply-To: Message from mike@lrlart.com of "Fri, 03 Mar 2006 12:43:01 MST." <20060303124301.8c0fa638fcef9dd13f5a2f992b1941af.6ec197f260.wbe@email.email.secureserver.net> Message-ID: <200603032015.k23KFIQj009012@possum.icir.org> > Here's an smallish change to xorp that allows xorp to support > syslogging. It requires a patch to the libxorp/xlog.c and the addition > of the attached c and header file (which also belong in the libxorp > directory). It doesn't support windows (sorry Bruce). > > Note that when adding a new .c and .h file the Makefile.am will need to > be updated to include rl_syslog.c/.h > > Mike Larson Code and instructions are added to the relevant bugzilla entry: http://www.xorp.org/bugzilla/show_bug.cgi?id=119 Thanks, Pavlin From pavlin@icir.org Fri Mar 3 20:14:19 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 03 Mar 2006 12:14:19 -0800 Subject: [Xorp-users] suggested init.d scripts to start xorp anyone? In-Reply-To: Message from Alain Fauconnet of "Fri, 03 Mar 2006 09:33:27 +0700." <20060303023327.GB8181@ait.ac.th> Message-ID: <200603032014.k23KEJd9008975@possum.icir.org> > On Thu, Mar 02, 2006 at 02:38:27PM -0800, Pavlin Radoslavov wrote: > > > I am running xorp, for multicast routing only, on a fedora core 4 box that > > > is doing nothing else. > > > > > > Does anyone have a suggested script to place in /etc/init.d to start it > > > in an appropriate way? > > > > Unfortunately, we (XORP) don't have such script, but we would like > > to have one in our tree. Ideally, we should have a solution for > > other OS-es as well. Contributions are welcome. > > Here's the one I use on a RH 7.3-based router box. Script attached to the relevant bugzilla entry: http://www.xorp.org/bugzilla/show_bug.cgi?id=119 Thanks, Pavlin From ahthamrin@gmail.com Wed Mar 8 12:32:13 2006 From: ahthamrin@gmail.com (Achmad Husni Thamrin) Date: Wed, 8 Mar 2006 21:32:13 +0900 Subject: [Xorp-users] IGMPv3/MLDv2 and Embedded-RP Message-ID: <4250f3610603080432v7efba865gcf5ee43f03ad9744@mail.gmail.com> ------=_Part_14164_900682.1141821133474 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, Looking at the Roadmap, XORP will support IGMPv3/MLDv2 by April. Is this going to be on schedule? Also, I'd like to know the plan to support Embedded-RP. I browsed the code and didn't find anything that indicates the support for Embedded-RP. Thank you. -- http://jaringan.info/ Just my two bits. ------=_Part_14164_900682.1141821133474 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi,

Looking at the Roadmap, XORP will support IGMPv3/MLDv2 by April.= Is this going to be on schedule?
Also, I'd like to know the plan to sup= port Embedded-RP. I browsed the code and didn't find anything that indicate= s the support for Embedded-RP.

Thank you.

--
<husni>
http://jaringan.info/
Just my two bits. ------=_Part_14164_900682.1141821133474-- From mh5942@bris.ac.uk Wed Mar 8 17:04:39 2006 From: mh5942@bris.ac.uk (Martin Hoffmann) Date: Wed, 08 Mar 2006 17:04:39 +0000 Subject: [Xorp-users] IPv4 PIM-SM and SSM (was Xorp debug messages) Message-ID: <440F0EA7.5080408@bris.ac.uk> Hi all, I solved my problem regarding the Hello messages. I set up a new machine, running Xorp-1.2-RC and a properly configured 2.6.10 kernel. Xorp and Click now successfully exchange PIM Hello messages. I'd like to built a Source Path Tree now. My testbed look like this: IGMPv3 Receiver <-> Click router <-> Xorp router <-> Sender 1. The sender sends a (S,G) stream to the Xorp router As a result, "show pim mfc" and "show pim join" return the following lines: martin@ubuntu> show pim mfc Group Source RP 232.2.2.2 192.168.40.1 0.0.0.0 Incoming interface : eth1 Outgoing interfaces: ..O martin@ubuntu> show pim join Group Source RP Flags 232.2.2.2 192.168.40.1 RP_ADDR_UNKNOWN SG SPT DirectlyConnectedS Upstream interface (S): eth1 Upstream interface (RP): UNKNOWN Upstream MRIB next hop (RP): UNKNOWN Upstream MRIB next hop (S): UNKNOWN Upstream RPF'(S,G): UNKNOWN Upstream state: Joined Register state: RegisterJoin RegisterCouldRegister Join timer: 4 KAT(S,G) running: true Local receiver include WC: ... Local receiver include SG: ... Local receiver exclude SG: ... Joins RP: ... Joins WC: ... Joins SG: ..O Join state: ..O Prune state: ... Prune pending state: ... I am assert winner state: ... I am assert loser state: ... Assert winner WC: ... Assert winner SG: ... Assert lost WC: ... Assert lost SG: ... Assert lost SG_RPT: ... Assert tracking SG: O.O Could assert WC: ... Could assert SG: ..O I am DR: O.O Immediate olist RP: ... Immediate olist WC: ... Immediate olist SG: ..O Inherited olist SG: ..O Inherited olist SG_RPT: ... PIM include WC: ... PIM include SG: ... PIM exclude SG: ... Is that ok so far? 2. The IGMPv3 receiver sends an "Include" report to the Click router and requests an (S,G) stream. The Click routers adds this information to its forwarding cache. A PIM join message is generated and sent to the Xorp router. 2.1 I used the PIM neighbors unicast address to sent the PIM join message to. This is mentioned in section 4.3.4 and 4.5.3 in draft-ietf-pim-sm-v2-new-11.txt. Xorp complains and asks for a multicast address. [ 2006/03/08 16:28:57 WARNING xorp_pimsm4 PIM ] RX PIM_JOIN_PRUNE from 192.168.30.6 to 192.168.30.2 on vif eth2: destination must be multicast 2.2 Sending the PIM join message to the group address (232.2.2.2 in this case) does not work either. Xorp adds an entry to its MFC, the Join/Prune message is not reckognised. martin@ubuntu> show pim mfc Group Source RP 232.2.2.2 192.168.30.6 0.0.0.0 Incoming interface : eth2 Outgoing interfaces: ... The PIM join message format is (tethereal output): ----- Frame 4 (72 bytes on wire, 72 bytes captured) Arrival Time: Mar 8, 2006 16:39:59.819030000 Time delta from previous packet: 0.009573000 seconds Time since reference or first frame: 0.121406000 seconds Frame Number: 4 Packet Length: 72 bytes Capture Length: 72 bytes Protocols in frame: eth:ip:pim Ethernet II, Src: 00:30:48:52:fe:b3, Dst: 00:09:5b:e4:23:7a Destination: 00:09:5b:e4:23:7a (192.168.30.2) Source: 00:30:48:52:fe:b3 (192.168.30.6) Type: IP (0x0800) Internet Protocol, Src Addr: 192.168.30.6 (192.168.30.6), Dst Addr: 232.2.2.2 (232.2.2.2) Version: 4 Header length: 24 bytes Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00) 1100 00.. = Differentiated Services Codepoint: Class Selector 6 (0x30) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 58 Identification: 0xf45f (62559) Flags: 0x00 0... = Reserved bit: Not set .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 1 Protocol: PIM (0x67) Header checksum: 0x6686 (correct) Source: 192.168.30.6 (192.168.30.6) Destination: 232.2.2.2 (232.2.2.2) Options: (4 bytes) Router Alert: Every router examines packet Protocol Independent Multicast Version: 2 Type: Join/Prune (3) Checksum: 0x1c60 (correct) PIM parameters Upstream-neighbor: 192.168.30.6 Groups: 1 Holdtime: 65535 (infty) Group 0: 232.2.2.2/32 Join: 1 IP address: 192.168.40.1/32 (SW) Prune: 0 ----- 2.3 draft-ietf-pim-sm-v2-new-11.txt mentions 0.0.0.0 as a valid destination address, see section 4.5.3. This did not work on Xorp. 2.4 My last try was to send the Join message to 224.0.0.13, the PIM routers' address. As a result I get the following line: [ 2006/03/08 16:55:17 WARNING xorp_pimsm4 PIM ] RX PIM_JOIN_PRUNE from 192.168.30.6 to 224.0.0.13: invalid source/RP flags for (192.168.40.1, 232.2.2.2): 0x6 I'm not sure where to continue now, any suggestions and explanation is highly appreciated. Thank you so far, Martin From tj_yang@hotmail.com Thu Mar 9 03:13:18 2006 From: tj_yang@hotmail.com (T.J. Yang) Date: Wed, 08 Mar 2006 21:13:18 -0600 Subject: [Xorp-users] Failed to configure on solaris 2.9 sparc Message-ID: I am able to build xorp on RH linux but not on Solaris. the configure script looks like work well if openssl is in /usr/lib, /lib. Looks like the configure.in has issue but I don't enough to fix it myself. Can others confirm the issue ? checking whether preprocessor supports GNU variadic macros... no checking whether preprocessor supports C99 variadic macros... yes checking if GNU make is installed... make checking for python2.2... no checking for python2... no checking for python... no checking OpenSSL installation prefix... /opt/bd/libopenssl097/ checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... no checking for unistd.h... yes checking openssl/md5.h usability... yes checking openssl/md5.h presence... yes checking for openssl/md5.h... yes checking for MD5_Init in -lcrypto... no Could not find part of OpenSSL or one it's components in /opt/bd/libopenssl097/ Use --with-openssl=DIR to specify OpenSSL installation root. error: error executing script bash-2.05# ls -l /opt/bd/libopenssl097/ total 30 drwxr-xr-x 2 root other 512 Mar 6 05:57 bin drwxr-xr-x 2 root root 1024 Mar 6 05:57 certs drwxr-xr-x 3 root other 512 Mar 6 05:57 include drwxr-xr-x 3 root other 512 Mar 6 05:57 lib drwxr-xr-x 6 root other 512 Mar 6 05:50 man drwxr-xr-x 2 root other 512 Mar 6 05:57 misc -rw-r--r-- 1 root other 7521 Mar 6 05:57 openssl.cnf drwxr-xr-x 2 root other 512 Mar 6 05:57 private bash-2.05# Thanks for your poiner T.J. Yang From Chris.Robson@nrl.navy.mil Thu Mar 9 10:33:41 2006 From: Chris.Robson@nrl.navy.mil (Chris Robson NRL) Date: Thu, 09 Mar 2006 05:33:41 -0500 Subject: [Xorp-users] MPLS & MPLS/BGP efforts Message-ID: <6.2.1.2.2.20060309053128.02220700@ginger.cmf.nrl.navy.mil> Hello Is anyone working L2VPNs and L3VPNs for xorp? Also, has anyone gotten MPLS-linux to work with xorp and/or work with FC4? Thanks.....Chris From jmartin@nextel.es Wed Mar 8 21:44:06 2006 From: jmartin@nextel.es (Chema Martin) Date: Wed, 08 Mar 2006 22:44:06 +0100 Subject: [Xorp-users] xorp and gated running together Message-ID: <440F5026.9090407@nextel.es> > Hi, > > I have a checkpoint cluster working OSPF with the avanced routing of > checkpoint (this is gated) > ang I have xorp running multicast PIM-SM in the same cluster. > It seems that the system works but the gated logs reports a lot of > error. If I stop xorp I do´nt see this errors messages. > > My question is: Do you know any problem with gated and xorp together? > What is this behavior in the log? Perhaps the unicast routes was lost > and xorp died? > > Thanks > Chema > > Mar 1 01:01:09 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:09 INFO > xorp_rtrmgr:20652 RTRMGR +1009 task.cc shutdown ] Shutting down > module: pimsm4 > Mar 1 01:01:10 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:10 INFO > xorp_pimsm4 PIM ] CLI stopped > Mar 1 01:01:10 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:10 INFO > xorp_pimsm4 PIM ] Bootstrap mechanism stopped > Mar 1 01:01:10 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:10 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > source 55.128.147.254 and group 224.128.147.254: not found > Mar 1 01:01:10 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:10 ERROR > xorp_fea:20664 MFEA +632 mfea_proto_comm.cc set_default_multicast_vif > ] setsockopt(IP_MULTICAST_IF, 55.128.95.254) failed: Cannot assign > requested address > Mar 1 01:01:10 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:10 WARNING > xorp_pimsm4 PIM ] JoinDesired(*,G) = false: RP for group > 224.128.147.254: not found > Mar 1 01:01:10 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:10 ERROR > xorp_fea:20664 MFEA +632 mfea_proto_comm.cc set_default_multicast_vif > ] setsockopt(IP_MULTICAST_IF, 55.128.95.254) failed: Cannot assign > requested address > Mar 1 01:01:10 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:10 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = true: upstream neighbor for > source 55.128.142.143 and group 230.230.5.20: not found > Mar 1 01:01:10 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:10 ERROR > xorp_fea:20664 MFEA +1865 mfea_proto_comm.cc proto_socket_write ] > sendmsg(proto 2 size 8 from 55.128.95.254 to 224.0.0.6 on vif vl_111) > failed: Invalid argument > Mar 1 01:01:10 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:10 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > source 55.128.191.254 and group 224.128.191.254: not found > Mar 1 01:01:10 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:10 WARNING > xorp_fea XrlMfeaTarget ] Handling method for > mfea/0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed > Cannot send IGMP protocol message from 55.128.95.254 to 224.0.0.6 on > vif vl_111 > Mar 1 01:01:10 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:10 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = true: upstream neighbor for > source 55.128.142.150 and group 230.230.5.1: not found > Mar 1 01:01:10 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:10 ERROR > xorp_igmp:20771 MLD6IGMP +1515 xrl_mld6igmp_node.cc > mfea_client_send_protocol_message_cb ] Cannot send a protocol message: > 102 Command failed Cannot send IGMP protocol message from > 55.128.95.254 to 224.0.0.6 on vif vl_111 > Mar 1 01:01:10 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:10 WARNING > xorp_pimsm4 PIM ] JoinDesired(*,G) = false: RP for group > 224.128.191.254: not found > Mar 1 01:01:11 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:11 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > source 55.128.79.254 and group 224.128.79.254: not found > Mar 1 01:01:11 FW1BJSCPD kernel: vl1_113: dev_set_allmulti(master, -1) > Mar 1 01:01:11 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:11 ERROR > xorp_igmp:20771 LIBXORP +161 buffered_asyncio.cc selector_event ] read > error 104 Connection reset by peer > Mar 1 01:01:11 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:11 ERROR > xorp_pimsm4:20806 PIM +240 xrl_pim_node.cc finder_disconnect_event ] > Finder disconnect event. Exiting immediately... > Mar 1 01:01:11 FW1BJSCPD kernel: vl1_2001: dev_set_allmulti(master, -1) > Mar 1 01:01:11 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:11 ERROR > xorp_igmp:20771 XRL +775 xrl_pf_stcp.cc read_event ] Read failed > (errno = 104): Connection reset by peer > Mar 1 01:01:11 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:11 ERROR > xorp_pimsm4:20806 PIM +2631 xrl_pim_node.cc > mfea_client_send_protocol_message_cb ] Cannot send a protocol message: > 210 Transport failed > Mar 1 01:01:11 FW1BJSCPD kernel: vl_110: dev_set_allmulti(master, -1) > Mar 1 01:01:11 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:11 ERROR > xorp_igmp:20771 XRL +629 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: > read error > Mar 1 01:01:11 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:11 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = true: upstream neighbor for > source 55.128.142.149 and group 230.230.5.1: not found > Mar 1 01:01:11 FW1BJSCPD kernel: vl_111: dev_set_allmulti(master, -1) > Mar 1 01:01:11 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:11 ERROR > xorp_igmp:20771 MLD6IGMP +1530 xrl_mld6igmp_node.cc > mfea_client_send_protocol_message_cb ] Cannot send a protocol message: > 210 Transport failed > Mar 1 01:01:11 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:11 WARNING > xorp_pimsm4 PIM ] JoinDesired(*,G) = false: RP for group > 224.128.79.254: not found > Mar 1 01:01:11 FW1BJSCPD kernel: vl_125: dev_set_allmulti(master, -1) > Mar 1 01:01:11 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:11 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = true: upstream neighbor for > source 55.128.142.170 and group 230.230.5.20: not found > Mar 1 01:01:11 FW1BJSCPD kernel: vl_126: dev_set_allmulti(master, -1) > Mar 1 01:01:11 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:11 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > source 55.128.95.254 and group 224.128.95.254: not found > Mar 1 01:01:11 FW1BJSCPD kernel: vl_141: dev_set_allmulti(master, -1) > Mar 1 01:01:11 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:11 WARNING > xorp_pimsm4 PIM ] JoinDesired(*,G) = false: upstream neighbor for RP > 55.63.50.8 for group 230.230.5.201: not found > Mar 1 01:01:12 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:12 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = true: upstream neighbor for > source 55.128.144.205 and group 230.230.5.1: not found > Mar 1 01:01:12 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:12 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = true: upstream neighbor for > source 55.128.142.31 and group 230.230.5.20: not found > Mar 1 01:01:12 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:12 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = true: upstream neighbor for > source 55.128.144.222 and group 230.230.5.1: not found > Mar 1 01:01:12 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:12 WARNING > xorp_pimsm4 PIM ] JoinDesired(*,G) = false: RP for group > 224.128.95.254: not found > Mar 1 01:01:12 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:12 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = true: upstream neighbor for > source 55.128.147.59 and group 230.230.5.1: not found > Mar 1 01:01:12 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:12 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > source 55.128.143.254 and group 224.128.143.254: not found > Mar 1 01:01:12 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:12 WARNING > xorp_pimsm4 PIM ] JoinDesired(*,G) = false: upstream neighbor for RP > 55.63.50.7 for group 230.230.5.40: not found > Mar 1 01:01:12 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:12 WARNING > xorp_pimsm4 PIM ] JoinDesired(*,G) = false: upstream neighbor for RP > 55.63.50.7 for group 230.230.5.20: not found > Mar 1 01:01:12 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:12 WARNING > xorp_pimsm4 PIM ] JoinDesired(*,G) = false: RP for group > 224.128.143.254: not found > Mar 1 01:01:12 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:12 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = true: upstream neighbor for > source 55.128.147.67 and group 230.230.5.20: not found > Mar 1 01:01:13 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:13 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > source 55.128.145.254 and group 224.128.145.254: not found > Mar 1 01:01:13 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:13 WARNING > xorp_pimsm4 PIM ] JoinDesired(*,G) = false: upstream neighbor for RP > 55.63.50.7 for group 230.230.5.1: not found > Mar 1 01:01:13 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:13 WARNING > xorp_pimsm4 PIM ] JoinDesired(*,G) = false: RP for group > 224.128.145.254: not found > Mar 1 01:01:13 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:13 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > source 55.128.142.2 and group 230.230.5.1: not found > Mar 1 01:01:13 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:13 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > source 55.128.142.24 and group 230.230.5.1: not found > Mar 1 01:01:13 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:13 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > source 55.128.142.25 and group 230.230.5.1: not found > Mar 1 01:01:13 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:13 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > source 55.128.142.27 and group 230.230.5.1: not found > Mar 1 01:01:13 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:13 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > source 55.128.142.28 and group 230.230.5.1: not found > Mar 1 01:01:13 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:13 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > source 55.128.142.30 and group 230.230.5.1: not found > Mar 1 01:01:13 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:13 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > source 55.128.142.32 and group 230.230.5.1: not found > Mar 1 01:01:13 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:13 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > source 55.128.142.33 and group 230.230.5.1: not found > Mar 1 01:01:13 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:13 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > source 55.128.142.34 and group 230.230.5.1: not found > Mar 1 01:01:13 FW1BJSCPD ntpdate[22026]: no server suitable for > synchronization found > Mar 1 01:01:13 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:13 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > source 55.128.142.38 and group 230.230.5.1: not found > Mar 1 01:01:13 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:13 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > source 55.128.142.54 and group 230.230.5.1: not found > Mar 1 01:01:13 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:13 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > source 55.128.142.56 and group 230.230.5.1: not found > Mar 1 01:01:13 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:13 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > source 55.128.142.58 and group 230.230.5.1: not found > Mar 1 01:01:13 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:13 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > source 55.128.142.60 and group 230.230.5.1: not found > Mar 1 01:01:14 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:14 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > source 55.128.142.61 and group 230.230.5.1: not found > Mar 1 01:01:14 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:14 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > source 55.128.142.62 and group 230.230.5.1: not found > Mar 1 01:01:14 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:14 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > source 55.128.142.63 and group 230.230.5.1: not found > Mar 1 01:01:14 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:14 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > source 55.128.142.64 and group 230.230.5.1: not found > Mar 1 01:01:14 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:14 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > source 55.128.142.66 and group 230.230.5.1: not found > Mar 1 01:01:14 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:14 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > source 55.128.142.80 and group 230.230.5.1: not found > Mar 1 01:01:14 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:14 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > source 55.128.142.81 and group 230.230.5.1: not found > Mar 1 01:01:14 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:14 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > source 55.128.142.82 and group 230.230.5.1: not found > Mar 1 01:01:14 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:14 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > source 55.128.142.83 and group 230.230.5.1: not found > Mar 1 01:01:14 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:14 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > source 55.128.142.84 and group 230.230.5.1: not found > Mar 1 01:01:14 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:14 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > source 55.128.142.85 and group 230.230.5.1: not found > Mar 1 01:01:14 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:14 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > source 55.128.142.86 and group 230.230.5.1: not found > Mar 1 01:01:14 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:14 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > source 55.128.142.88 and group 230.230.5.1: not found > Mar 1 01:01:14 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:14 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > source 55.128.142.89 and group 230.230.5.1: not found > Mar 1 01:01:14 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:14 WARNING > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > source 55.128.142.90 and group 230.230.5.1: not found > Mar 1 01:01:48 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:48 INFO > xorp_rtrmgr:22260 RTRMGR +170 master_conf_tree.cc execute ] Changed > modules: interfaces, fea, mfea4, rib, fib2mrib, igmp, pimsm4 > Mar 1 01:01:48 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:48 INFO > xorp_rtrmgr:22260 RTRMGR +426 module_manager.cc run ] Running module: > interfaces (/opt/bladefusion/xorp/fea/xorp_fea) > Mar 1 01:01:50 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:50 INFO xorp_fea > CLI ] CLI enabled > Mar 1 01:01:50 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:50 INFO xorp_fea > CLI ] CLI started > Mar 1 01:01:50 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:50 INFO xorp_fea > MFEA ] MFEA enabled > Mar 1 01:01:50 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:50 INFO xorp_fea > MFEA ] CLI enabled > Mar 1 01:01:50 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:50 INFO xorp_fea > MFEA ] CLI started > Mar 1 01:01:51 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:51 INFO > xorp_rtrmgr:22260 RTRMGR +426 module_manager.cc run ] Running module: > fea (/opt/bladefusion/xorp/fea/xorp_fea) > Mar 1 01:01:57 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:57 INFO > xorp_rtrmgr:22260 RTRMGR +426 module_manager.cc run ] Running module: > mfea4 (/opt/bladefusion/xorp/fea/xorp_fea) > Mar 1 01:01:57 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:57 INFO xorp_fea > MFEA ] Interface added: Vif[vl1_113] pif_index: 20 vif_index: 0 addr: > 55.128.147.254 subnet: 55.128.146.0/23 broadcast: 55.128.147.255 peer: > 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > Mar 1 01:01:57 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:57 INFO xorp_fea > MFEA ] Interface added: Vif[vl1_2001] pif_index: 21 vif_index: 1 addr: > 55.128.191.254 subnet: 55.128.176.0/20 broadcast: 55.128.191.255 peer: > 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > Mar 1 01:01:57 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:57 INFO xorp_fea > MFEA ] Interface added: Vif[vl_110] pif_index: 15 vif_index: 2 addr: > 55.128.79.254 subnet: 55.128.64.0/20 broadcast: 55.128.79.255 peer: > 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > Mar 1 01:01:57 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:57 INFO xorp_fea > MFEA ] Interface added: Vif[vl_111] pif_index: 14 vif_index: 3 addr: > 55.128.95.254 subnet: 55.128.80.0/20 broadcast: 55.128.95.255 peer: > 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > Mar 1 01:01:57 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:57 INFO xorp_fea > MFEA ] Interface added: Vif[vl_125] pif_index: 13 vif_index: 4 addr: > 55.128.143.254 subnet: 55.128.142.0/23 broadcast: 55.128.143.255 peer: > 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > Mar 1 01:01:57 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:57 INFO xorp_fea > MFEA ] Interface added: Vif[vl_126] pif_index: 12 vif_index: 5 addr: > 55.128.145.254 subnet: 55.128.144.0/23 broadcast: 55.128.145.255 peer: > 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > Mar 1 01:01:57 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:57 INFO xorp_fea > MFEA ] Interface added: Vif[vl_141] pif_index: 11 vif_index: 6 addr: > 55.128.16.3 subnet: 55.128.16.0/25 broadcast: 55.128.16.127 peer: > 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > Mar 1 01:01:57 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:57 INFO xorp_fea > MFEA ] MFEA started > Mar 1 01:01:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:58 INFO xorp_fea > MFEA ] Interface enabled Vif[vl_141] pif_index: 11 vif_index: 6 addr: > 55.128.16.3 subnet: 55.128.16.0/25 broadcast: 55.128.16.127 peer: > 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 ENABLED > Mar 1 01:01:58 FW1BJSCPD kernel: vl_141: dev_set_allmulti(master, 1) > Mar 1 01:01:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:58 INFO xorp_fea > MFEA ] Interface started: Vif[vl_141] pif_index: 11 vif_index: 6 addr: > 55.128.16.3 subnet: 55.128.16.0/25 broadcast: 55.128.16.127 peer: > 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 ENABLED > Mar 1 01:01:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:58 INFO xorp_fea > MFEA ] Interface added: Vif[register_vif] pif_index: 11 vif_index: 7 > addr: 55.128.16.3 subnet: 55.128.16.3/32 broadcast: 55.128.16.3 peer: > 0.0.0.0 Flags: PIM_REGISTER UNDERLYING_VIF_UP > Mar 1 01:01:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:58 INFO xorp_fea > MFEA ] Interface enabled Vif[vl1_2001] pif_index: 21 vif_index: 1 > addr: 55.128.191.254 subnet: 55.128.176.0/20 broadcast: 55.128.191.255 > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 > ENABLED > Mar 1 01:01:58 FW1BJSCPD kernel: vl1_2001: dev_set_allmulti(master, 1) > Mar 1 01:01:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:58 INFO xorp_fea > MFEA ] Interface started: Vif[vl1_2001] pif_index: 21 vif_index: 1 > addr: 55.128.191.254 subnet: 55.128.176.0/20 broadcast: 55.128.191.255 > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 > ENABLED > Mar 1 01:01:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:58 INFO xorp_fea > MFEA ] Interface enabled Vif[vl_110] pif_index: 15 vif_index: 2 addr: > 55.128.79.254 subnet: 55.128.64.0/20 broadcast: 55.128.79.255 peer: > 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 ENABLED > Mar 1 01:01:58 FW1BJSCPD kernel: vl_110: dev_set_allmulti(master, 1) > Mar 1 01:01:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:58 INFO xorp_fea > MFEA ] Interface started: Vif[vl_110] pif_index: 15 vif_index: 2 addr: > 55.128.79.254 subnet: 55.128.64.0/20 broadcast: 55.128.79.255 peer: > 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 ENABLED > Mar 1 01:01:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:58 INFO xorp_fea > MFEA ] Interface enabled Vif[vl_111] pif_index: 14 vif_index: 3 addr: > 55.128.95.254 subnet: 55.128.80.0/20 broadcast: 55.128.95.255 peer: > 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 ENABLED > Mar 1 01:01:58 FW1BJSCPD kernel: vl_111: dev_set_allmulti(master, 1) > Mar 1 01:01:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:58 INFO xorp_fea > MFEA ] Interface started: Vif[vl_111] pif_index: 14 vif_index: 3 addr: > 55.128.95.254 subnet: 55.128.80.0/20 broadcast: 55.128.95.255 peer: > 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 ENABLED > Mar 1 01:01:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:58 INFO xorp_fea > MFEA ] Interface enabled Vif[vl1_113] pif_index: 20 vif_index: 0 addr: > 55.128.147.254 subnet: 55.128.146.0/23 broadcast: 55.128.147.255 peer: > 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 ENABLED > Mar 1 01:01:58 FW1BJSCPD kernel: vl1_113: dev_set_allmulti(master, 1) > Mar 1 01:01:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:58 INFO xorp_fea > MFEA ] Interface started: Vif[vl1_113] pif_index: 20 vif_index: 0 > addr: 55.128.147.254 subnet: 55.128.146.0/23 broadcast: 55.128.147.255 > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 > ENABLED > Mar 1 01:01:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:58 INFO xorp_fea > MFEA ] Interface enabled Vif[vl_125] pif_index: 13 vif_index: 4 addr: > 55.128.143.254 subnet: 55.128.142.0/23 broadcast: 55.128.143.255 peer: > 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 ENABLED > Mar 1 01:01:58 FW1BJSCPD kernel: vl_125: dev_set_allmulti(master, 1) > Mar 1 01:01:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:58 INFO xorp_fea > MFEA ] Interface started: Vif[vl_125] pif_index: 13 vif_index: 4 addr: > 55.128.143.254 subnet: 55.128.142.0/23 broadcast: 55.128.143.255 peer: > 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 ENABLED > Mar 1 01:01:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:58 INFO xorp_fea > MFEA ] Interface enabled Vif[vl_126] pif_index: 12 vif_index: 5 addr: > 55.128.145.254 subnet: 55.128.144.0/23 broadcast: 55.128.145.255 peer: > 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 ENABLED > Mar 1 01:01:58 FW1BJSCPD kernel: vl_126: dev_set_allmulti(master, 1) > Mar 1 01:01:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:58 INFO xorp_fea > MFEA ] Interface started: Vif[vl_126] pif_index: 12 vif_index: 5 addr: > 55.128.145.254 subnet: 55.128.144.0/23 broadcast: 55.128.145.255 peer: > 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 ENABLED > Mar 1 01:01:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:58 INFO xorp_fea > MFEA ] Interface enabled Vif[register_vif] pif_index: 11 vif_index: 7 > addr: 55.128.16.3 subnet: 55.128.16.3/32 broadcast: 55.128.16.3 peer: > 0.0.0.0 Flags: PIM_REGISTER UNDERLYING_VIF_UP DOWN IPv4 ENABLED > Mar 1 01:01:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:58 INFO xorp_fea > MFEA ] Interface started: Vif[register_vif] pif_index: 11 vif_index: 7 > addr: 55.128.16.3 subnet: 55.128.16.3/32 broadcast: 55.128.16.3 peer: > 0.0.0.0 Flags: PIM_REGISTER UNDERLYING_VIF_UP UP IPv4 ENABLED > Mar 1 01:01:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:58 INFO > xorp_rtrmgr:22260 RTRMGR +426 module_manager.cc run ] Running module: > rib (/opt/bladefusion/xorp/rib/xorp_rib) > Mar 1 01:02:00 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:00 INFO > xorp_rtrmgr:22260 RTRMGR +426 module_manager.cc run ] Running module: > fib2mrib (/opt/bladefusion/xorp/fib2mrib/xorp_fib2mrib) > Mar 1 01:02:02 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:02 INFO > xorp_rtrmgr:22260 RTRMGR +426 module_manager.cc run ] Running module: > igmp (/opt/bladefusion/xorp/mld6igmp/xorp_igmp) > Mar 1 01:02:02 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:02 WARNING > xorp_rtrmgr:22260 XrlFinderTarget +405 ../xrl/targets/finder_base.cc > handle_finder_0_2_resolve_xrl ] Handling method for > finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target > "IGMP" does not exist or is not enabled. > Mar 1 01:02:03 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:03 INFO xorp_igmp > MLD6IGMP ] Protocol enabled > Mar 1 01:02:03 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:03 INFO xorp_igmp > MLD6IGMP ] CLI enabled > Mar 1 01:02:03 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:03 INFO xorp_igmp > MLD6IGMP ] CLI started > Mar 1 01:02:03 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:03 WARNING > xorp_fea MFEA ] Read 55.128.16.1 -> 55.128.16.3 Mar 1 01:02:03 > FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:03 WARNING xorp_fea MFEA ] Read > 55.128.16.2 -> 55.128.16.3 Mar 1 01:02:03 FW1BJSCPD BF-PIM: [ > 2006/03/01 01:02:03 WARNING xorp_fea MFEA ] Read 55.128.191.252 -> > 55.128.191.254 Mar 1 01:02:03 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:03 > WARNING xorp_fea MFEA ] Read 55.128.191.253 -> 55.128.191.254 Mar 1 > 01:02:03 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:03 WARNING xorp_fea MFEA > ] Read 55.128.79.252 -> 55.128.79.254 Mar 1 01:02:03 FW1BJSCPD > BF-PIM: [ 2006/03/01 01:02:03 WARNING xorp_fea MFEA ] Read > 55.128.79.253 -> 55.128.79.254 Mar 1 01:02:03 FW1BJSCPD BF-PIM: [ > 2006/03/01 01:02:03 WARNING xorp_fea MFEA ] Read 55.128.95.252 -> > 55.128.95.254 Mar 1 01:02:03 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:03 > WARNING xorp_fea MFEA ] Read 55.128.95.253 -> 55.128.95.254 Mar 1 > 01:02:03 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:03 WARNING xorp_fea MFEA > ] Read 55.128.147.252 -> 55.128.147.254 Mar 1 01:02:03 FW1BJSCPD > BF-PIM: [ 2006/03/01 01:02:03 WARNING xorp_fea MFEA ] Read > 55.128.147.253 -> 55.128.147.254 Mar 1 01:02:03 FW1BJSCPD BF-PIM: [ > 2006/03/01 01:02:03 WARNING xorp_fea MFEA ] Read 55.128.143.252 -> > 55.128.143.254 Mar 1 01:02:03 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:03 > WARNING xorp_fea MFEA ] Read 55.128.143.253 -> 55.128.143.254 Mar 1 > 01:02:03 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:03 WARNING xorp_fea MFEA > ] Read 55.128.145.252 -> 55.128.145.254 Mar 1 01:02:04 FW1BJSCPD > BF-PIM: [ 2006/03/01 01:02:04 WARNING xorp_fea MFEA ] Read > 55.128.145.253 -> 55.128.145.254 Mar 1 01:02:04 FW1BJSCPD BF-PIM: [ > 2006/03/01 01:02:04 ERROR xorp_fea:22293 MFEA +147 mfea_proto_comm.cc > BFReadConf ] bladefusion - wrong addr match > Mar 1 01:02:04 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:04 INFO xorp_igmp > MLD6IGMP ] Interface added: Vif[vl1_113] pif_index: 0 vif_index: 0 > addr: 55.128.147.254 subnet: 55.128.146.0/23 broadcast: 55.128.147.255 > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > Mar 1 01:02:04 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:04 INFO xorp_igmp > MLD6IGMP ] Interface added: Vif[vl1_2001] pif_index: 0 vif_index: 1 > addr: 55.128.191.254 subnet: 55.128.176.0/20 broadcast: 55.128.191.255 > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > Mar 1 01:02:04 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:04 INFO xorp_igmp > MLD6IGMP ] Interface added: Vif[vl_110] pif_index: 0 vif_index: 2 > addr: 55.128.79.254 subnet: 55.128.64.0/20 broadcast: 55.128.79.255 > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > Mar 1 01:02:04 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:04 INFO xorp_igmp > MLD6IGMP ] Interface added: Vif[vl_111] pif_index: 0 vif_index: 3 > addr: 55.128.95.254 subnet: 55.128.80.0/20 broadcast: 55.128.95.255 > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > Mar 1 01:02:04 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:04 INFO xorp_igmp > MLD6IGMP ] Interface added: Vif[vl_125] pif_index: 0 vif_index: 4 > addr: 55.128.143.254 subnet: 55.128.142.0/23 broadcast: 55.128.143.255 > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > Mar 1 01:02:04 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:04 INFO xorp_igmp > MLD6IGMP ] Interface added: Vif[vl_126] pif_index: 0 vif_index: 5 > addr: 55.128.145.254 subnet: 55.128.144.0/23 broadcast: 55.128.145.255 > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > Mar 1 01:02:04 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:04 INFO xorp_igmp > MLD6IGMP ] Interface added: Vif[vl_141] pif_index: 0 vif_index: 6 > addr: 55.128.16.3 subnet: 55.128.16.0/25 broadcast: 55.128.16.127 > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > Mar 1 01:02:04 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:04 INFO xorp_igmp > MLD6IGMP ] Protocol started > Mar 1 01:02:05 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:05 INFO xorp_igmp > MLD6IGMP ] Interface enabled: Vif[vl_141] pif_index: 0 vif_index: 6 > addr: 55.128.16.3 subnet: 55.128.16.0/25 broadcast: 55.128.16.127 > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 > ENABLED > Mar 1 01:02:05 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:05 INFO xorp_igmp > MLD6IGMP ] Interface started: Vif[vl_141] pif_index: 0 vif_index: 6 > addr: 55.128.16.3 subnet: 55.128.16.0/25 broadcast: 55.128.16.127 > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 > ENABLED > Mar 1 01:02:05 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:05 INFO xorp_igmp > MLD6IGMP ] Interface enabled: Vif[vl1_2001] pif_index: 0 vif_index: 1 > addr: 55.128.191.254 subnet: 55.128.176.0/20 broadcast: 55.128.191.255 > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 > ENABLED > Mar 1 01:02:05 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:05 INFO xorp_igmp > MLD6IGMP ] Interface started: Vif[vl1_2001] pif_index: 0 vif_index: 1 > addr: 55.128.191.254 subnet: 55.128.176.0/20 broadcast: 55.128.191.255 > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 > ENABLED > Mar 1 01:02:05 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:05 INFO xorp_igmp > MLD6IGMP ] Interface enabled: Vif[vl_110] pif_index: 0 vif_index: 2 > addr: 55.128.79.254 subnet: 55.128.64.0/20 broadcast: 55.128.79.255 > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 > ENABLED > Mar 1 01:02:05 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:05 INFO xorp_igmp > MLD6IGMP ] Interface started: Vif[vl_110] pif_index: 0 vif_index: 2 > addr: 55.128.79.254 subnet: 55.128.64.0/20 broadcast: 55.128.79.255 > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 > ENABLED > Mar 1 01:02:05 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:05 INFO xorp_igmp > MLD6IGMP ] Interface enabled: Vif[vl_111] pif_index: 0 vif_index: 3 > addr: 55.128.95.254 subnet: 55.128.80.0/20 broadcast: 55.128.95.255 > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 > ENABLED > Mar 1 01:02:05 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:05 INFO xorp_igmp > MLD6IGMP ] Interface started: Vif[vl_111] pif_index: 0 vif_index: 3 > addr: 55.128.95.254 subnet: 55.128.80.0/20 broadcast: 55.128.95.255 > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 > ENABLED > Mar 1 01:02:06 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:06 INFO xorp_igmp > MLD6IGMP ] Interface enabled: Vif[vl1_113] pif_index: 0 vif_index: 0 > addr: 55.128.147.254 subnet: 55.128.146.0/23 broadcast: 55.128.147.255 > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 > ENABLED > Mar 1 01:02:06 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:06 INFO xorp_igmp > MLD6IGMP ] Interface started: Vif[vl1_113] pif_index: 0 vif_index: 0 > addr: 55.128.147.254 subnet: 55.128.146.0/23 broadcast: 55.128.147.255 > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 > ENABLED > Mar 1 01:02:06 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:06 INFO xorp_igmp > MLD6IGMP ] Interface enabled: Vif[vl_125] pif_index: 0 vif_index: 4 > addr: 55.128.143.254 subnet: 55.128.142.0/23 broadcast: 55.128.143.255 > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 > ENABLED > Mar 1 01:02:06 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:06 INFO xorp_igmp > MLD6IGMP ] Interface started: Vif[vl_125] pif_index: 0 vif_index: 4 > addr: 55.128.143.254 subnet: 55.128.142.0/23 broadcast: 55.128.143.255 > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 > ENABLED > Mar 1 01:02:06 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:06 INFO xorp_igmp > MLD6IGMP ] Interface enabled: Vif[vl_126] pif_index: 0 vif_index: 5 > addr: 55.128.145.254 subnet: 55.128.144.0/23 broadcast: 55.128.145.255 > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 > ENABLED > Mar 1 01:02:06 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:06 INFO xorp_igmp > MLD6IGMP ] Interface started: Vif[vl_126] pif_index: 0 vif_index: 5 > addr: 55.128.145.254 subnet: 55.128.144.0/23 broadcast: 55.128.145.255 > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 > ENABLED > Mar 1 01:02:06 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:06 INFO > xorp_rtrmgr:22260 RTRMGR +426 module_manager.cc run ] Running module: > pimsm4 (/opt/bladefusion/xorp/pim/xorp_pimsm4) > Mar 1 01:02:06 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:06 WARNING > xorp_rtrmgr:22260 XrlFinderTarget +405 ../xrl/targets/finder_base.cc > handle_finder_0_2_resolve_xrl ] Handling method for > finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target > "PIMSM_4" does not exist or is not enabled. > Mar 1 01:02:07 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:07 WARNING > xorp_rtrmgr:22260 XrlFinderTarget +405 ../xrl/targets/finder_base.cc > handle_finder_0_2_resolve_xrl ] Handling method for > finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Xrl > target is not enabled. > Mar 1 01:02:08 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:08 INFO > xorp_pimsm4 PIM ] Protocol enabled > Mar 1 01:02:08 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:08 INFO > xorp_pimsm4 PIM ] CLI enabled > Mar 1 01:02:08 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:08 INFO > xorp_pimsm4 PIM ] CLI started > Mar 1 01:02:26 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:26 INFO > xorp_pimsm4 PIM ] Interface added: Vif[register_vif] pif_index: 0 > vif_index: 7 addr: 55.128.16.3 subnet: 55.128.16.3/32 broadcast: > 55.128.16.3 peer: 0.0.0.0 Flags: PIM_REGISTER UNDERLYING_VIF_UP > Mar 1 01:02:26 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:26 INFO > xorp_pimsm4 PIM ] Interface added: Vif[vl1_113] pif_index: 0 > vif_index: 0 addr: 55.128.147.254 subnet: 55.128.146.0/23 broadcast: > 55.128.147.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > Mar 1 01:02:26 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:26 INFO > xorp_pimsm4 PIM ] Interface added: Vif[vl1_2001] pif_index: 0 > vif_index: 1 addr: 55.128.191.254 subnet: 55.128.176.0/20 broadcast: > 55.128.191.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > Mar 1 01:02:26 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:26 INFO > xorp_pimsm4 PIM ] Interface added: Vif[vl_110] pif_index: 0 vif_index: > 2 addr: 55.128.79.254 subnet: 55.128.64.0/20 broadcast: 55.128.79.255 > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > Mar 1 01:02:26 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:26 INFO > xorp_pimsm4 PIM ] Interface added: Vif[vl_111] pif_index: 0 vif_index: > 3 addr: 55.128.95.254 subnet: 55.128.80.0/20 broadcast: 55.128.95.255 > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > Mar 1 01:02:26 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:26 INFO > xorp_pimsm4 PIM ] Interface added: Vif[vl_125] pif_index: 0 vif_index: > 4 addr: 55.128.143.254 subnet: 55.128.142.0/23 broadcast: > 55.128.143.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > Mar 1 01:02:26 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:26 INFO > xorp_pimsm4 PIM ] Interface added: Vif[vl_126] pif_index: 0 vif_index: > 5 addr: 55.128.145.254 subnet: 55.128.144.0/23 broadcast: > 55.128.145.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > Mar 1 01:02:26 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:26 INFO > xorp_pimsm4 PIM ] Interface added: Vif[vl_141] pif_index: 0 vif_index: > 6 addr: 55.128.16.3 subnet: 55.128.16.0/25 broadcast: 55.128.16.127 > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > Mar 1 01:02:26 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:26 INFO > xorp_pimsm4 PIM ] Protocol started > Mar 1 01:02:39 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:39 INFO > xorp_pimsm4 PIM ] Interface enabled: Vif[vl_141] pif_index: 0 > vif_index: 6 addr: 55.128.16.3 subnet: 55.128.16.0/25 broadcast: > 55.128.16.127 peer: 0.0.0.0 Flags: MULTICAST BROADCAST > UNDERLYING_VIF_UP DOWN IPv4 ENABLED > Mar 1 01:02:39 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:39 INFO > xorp_pimsm4 PIM ] Interface started: Vif[vl_141] pif_index: 0 > vif_index: 6 addr: 55.128.16.3 subnet: 55.128.16.0/25 broadcast: > 55.128.16.127 peer: 0.0.0.0 Flags: MULTICAST BROADCAST > UNDERLYING_VIF_UP UP IPv4 ENABLED > Mar 1 01:02:39 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:39 INFO > xorp_pimsm4 PIM ] Interface enabled: Vif[vl1_2001] pif_index: 0 > vif_index: 1 addr: 55.128.191.254 subnet: 55.128.176.0/20 broadcast: > 55.128.191.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST > UNDERLYING_VIF_UP DOWN IPv4 ENABLED > Mar 1 01:02:40 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:40 INFO > xorp_pimsm4 PIM ] Interface started: Vif[vl1_2001] pif_index: 0 > vif_index: 1 addr: 55.128.191.254 subnet: 55.128.176.0/20 broadcast: > 55.128.191.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST > UNDERLYING_VIF_UP UP IPv4 ENABLED > Mar 1 01:02:40 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:40 INFO > xorp_pimsm4 PIM ] Interface enabled: Vif[vl_110] pif_index: 0 > vif_index: 2 addr: 55.128.79.254 subnet: 55.128.64.0/20 broadcast: > 55.128.79.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST > UNDERLYING_VIF_UP DOWN IPv4 ENABLED > Mar 1 01:02:40 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:40 ERROR > xorp_fea:22293 MFEA +711 mfea_proto_comm.cc join_multicast_group ] > Cannot join group 224.0.0.13 on vif vl_141: No such device > Mar 1 01:02:40 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:40 INFO > xorp_pimsm4 PIM ] Interface started: Vif[vl_110] pif_index: 0 > vif_index: 2 addr: 55.128.79.254 subnet: 55.128.64.0/20 broadcast: > 55.128.79.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST > UNDERLYING_VIF_UP UP IPv4 ENABLED > Mar 1 01:02:40 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:40 INFO > xorp_rtrmgr:22260 RTRMGR +2182 task.cc run_task ] No more tasks to run > Mar 1 01:02:40 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:40 WARNING > xorp_fea XrlMfeaTarget ] Handling method for > mfea/0.1/join_multicast_group4 failed: XrlCmdError 102 Command failed > Cannot join group 224.0.0.13 on vif vl_141 > Mar 1 01:02:40 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:40 WARNING > xorp_pimsm4 PIM ] JoinDesired(*,G) = true: RP for group 224.128.16.3: > not found > Mar 1 01:02:40 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:40 FATAL > xorp_pimsm4:22431 PIM +1648 xrl_pim_node.cc > mfea_client_send_join_leave_multicast_group_cb ] Cannot join a > multicast group with the MFEA: 102 Command failed Cannot join group > 224.0.0.13 on vif vl_141 > Mar 1 01:02:40 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:40 ERROR > xorp_rib:22377 RIB +204 redist_xrl.cc dispatch_complete ] Fatal error > during route redistribution: 210 Transport failed > Mar 1 01:02:40 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:40 ERROR > xorp_igmp:22404 MLD6IGMP +1300 xrl_mld6igmp_node.cc > mld6igmp_client_send_add_delete_membership_cb ] XRL communication > error: 210 Transport failed > Mar 1 01:02:41 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:41 ERROR > xorp_fea:22293 MFEA +632 mfea_proto_comm.cc set_default_multicast_vif > ] setsockopt(IP_MULTICAST_IF, 55.128.95.254) failed: Cannot assign > requested address > Mar 1 01:02:41 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:41 ERROR > xorp_fea:22293 MFEA +632 mfea_proto_comm.cc set_default_multicast_vif > ] setsockopt(IP_MULTICAST_IF, 55.128.95.254) failed: Cannot assign > requested address > Mar 1 01:02:41 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:41 ERROR > xorp_fea:22293 MFEA +1865 mfea_proto_comm.cc proto_socket_write ] > sendmsg(proto 2 size 8 from 55.128.95.254 to 224.0.0.6 on vif vl_111) > failed: Invalid argument > Mar 1 01:02:41 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:41 ERROR > xorp_igmp:22404 MLD6IGMP +188 xrl_mld6igmp_node.cc > finder_disconnect_event ] Finder disconnect event. Exiting immediately... > Mar 1 01:02:41 FW1BJSCPD kernel: vl1_113: dev_set_allmulti(master, -1) > Mar 1 01:02:41 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:41 INFO xorp_igmp > MLD6IGMP ] Interface stopped: Vif[vl1_113] pif_index: 0 vif_index: 0 > addr: 55.128.147.254 subnet: 55.128.146.0/23 broadcast: 55.128.147.255 > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 > ENABLED > Mar 1 01:02:41 FW1BJSCPD kernel: vl1_2001: dev_set_allmulti(master, -1) > Mar 1 01:02:41 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:41 INFO xorp_igmp > MLD6IGMP ] Interface stopped: Vif[vl1_2001] pif_index: 0 vif_index: 1 > addr: 55.128.191.254 subnet: 55.128.176.0/20 broadcast: 55.128.191.255 > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 > ENABLED > Mar 1 01:02:41 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:41 INFO xorp_igmp > MLD6IGMP ] Interface stopped: Vif[vl_110] pif_index: 0 vif_index: 2 > addr: 55.128.79.254 subnet: 55.128.64.0/20 broadcast: 55.128.79.255 > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 > ENABLED > Mar 1 01:02:41 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:41 INFO xorp_igmp > MLD6IGMP ] Interface stopped: Vif[vl_111] pif_index: 0 vif_index: 3 > addr: 55.128.95.254 subnet: 55.128.80.0/20 broadcast: 55.128.95.255 > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 > ENABLED > Mar 1 01:02:41 FW1BJSCPD kernel: vl_110: dev_set_allmulti(master, -1) > Mar 1 01:02:41 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:41 INFO xorp_igmp > MLD6IGMP ] Interface stopped: Vif[vl_125] pif_index: 0 vif_index: 4 > addr: 55.128.143.254 subnet: 55.128.142.0/23 broadcast: 55.128.143.255 > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 > ENABLED > Mar 1 01:02:42 FW1BJSCPD kernel: vl_111: dev_set_allmulti(master, -1) > Mar 1 01:02:42 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:42 INFO xorp_igmp > MLD6IGMP ] Interface stopped: Vif[vl_126] pif_index: 0 vif_index: 5 > addr: 55.128.145.254 subnet: 55.128.144.0/23 broadcast: 55.128.145.255 > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 > ENABLED > Mar 1 01:02:42 FW1BJSCPD kernel: vl_125: dev_set_allmulti(master, -1) > Mar 1 01:02:42 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:42 INFO xorp_igmp > MLD6IGMP ] Interface stopped: Vif[vl_141] pif_index: 0 vif_index: 6 > addr: 55.128.16.3 subnet: 55.128.16.0/25 broadcast: 55.128.16.127 > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 > ENABLED > Mar 1 01:02:42 FW1BJSCPD kernel: vl_126: dev_set_allmulti(master, -1) > Mar 1 01:02:42 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:42 ERROR > xorp_igmp:22404 MLD6IGMP +1530 xrl_mld6igmp_node.cc > mfea_client_send_protocol_message_cb ] Cannot send a protocol message: > 210 Transport failed > Mar 1 01:02:42 FW1BJSCPD kernel: vl_141: dev_set_allmulti(master, -1) > Mar 1 01:02:44 FW1BJSCPD ntpdate[22455]: adjust time server 55.1.1.2 > offset 0.012073 sec > Mar 1 01:02:57 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:57 INFO > xorp_rtrmgr:22677 RTRMGR +170 master_conf_tree.cc execute ] Changed > modules: interfaces, fea, mfea4, rib, fib2mrib, igmp, pimsm4 > Mar 1 01:02:57 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:57 INFO > xorp_rtrmgr:22677 RTRMGR +426 module_manager.cc run ] Running module: > interfaces (/opt/bladefusion/xorp/fea/xorp_fea) > Mar 1 01:02:57 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:57 INFO xorp_fea > CLI ] CLI enabled > Mar 1 01:02:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:58 INFO xorp_fea > CLI ] CLI started > Mar 1 01:02:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:58 INFO xorp_fea > MFEA ] MFEA enabled > Mar 1 01:02:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:58 INFO xorp_fea > MFEA ] CLI enabled > Mar 1 01:02:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:58 INFO xorp_fea > MFEA ] CLI started > Mar 1 01:02:59 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:59 INFO > xorp_rtrmgr:22677 RTRMGR +2182 task.cc run_task ] No more tasks to run > Mar 1 01:02:59 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:59 INFO > xorp_rtrmgr:22677 RTRMGR +219 module_manager.cc terminate ] > Terminating module: interfaces > Mar 1 01:02:59 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:59 INFO > xorp_rtrmgr:22677 RTRMGR +272 module_manager.cc terminate ] Killing > module: interfaces (pid = 22689) > Mar 1 01:02:59 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:59 INFO > xorp_rtrmgr:22677 RTRMGR +576 module_manager.cc killed ] Module killed > during shutdown: interfaces > From mhorn@vyatta.com Thu Mar 9 15:45:52 2006 From: mhorn@vyatta.com (Mike Horn) Date: Thu, 9 Mar 2006 07:45:52 -0800 (PST) Subject: [Xorp-users] MPLS & MPLS/BGP efforts Message-ID: <10873589.2431141919152317.JavaMail.root@mail.vyatta.com> Hi Chris, Vyatta, which is based on the XORP routing platform, is working on adding L3VPN support and possibly L2VPN support depending community demand. Once we get it working we'll try to get it integrated with XORP provided it is something they want to add. For L2VPN are you looking for just 2547, or are you also interested in the PWE3 stuff as well? Here is a link to the Vyatta enhancement request page: http://www.vyatta.com/twiki/bin/view/Community/TopEnhancements -mike ----- Original Message ----- From: Chris Robson NRL To: Xorp-users@xorp.org Sent: Thursday, March 9, 2006 3:33:41 AM GMT-0700 Subject: [Xorp-users] MPLS & MPLS/BGP efforts Hello Is anyone working L2VPNs and L3VPNs for xorp? Also, has anyone gotten MPLS-linux to work with xorp and/or work with FC4? Thanks.....Chris _______________________________________________ Xorp-users mailing list Xorp-users@xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From hasso@linux.ee Thu Mar 9 16:11:59 2006 From: hasso@linux.ee (Hasso Tepper) Date: Thu, 9 Mar 2006 18:11:59 +0200 Subject: [Xorp-users] MPLS & MPLS/BGP efforts In-Reply-To: <10873589.2431141919152317.JavaMail.root@mail.vyatta.com> References: <10873589.2431141919152317.JavaMail.root@mail.vyatta.com> Message-ID: <200603091811.59739.hasso@linux.ee> Mike Horn wrote: > Vyatta, which is based on the XORP routing platform, is working on > adding L3VPN support and possibly L2VPN support depending community > demand. Once we get it working we'll try to get it integrated with > XORP provided it is something they want to add. Excellent. > For L2VPN are you looking for just 2547, or are you also interested in > the PWE3 stuff as well? RFC2547 isn't about L2VPN, but L3VPN and is obsoleted by RFC4364 already ;). -- Hasso Tepper From mhorn@vyatta.com Thu Mar 9 21:32:24 2006 From: mhorn@vyatta.com (Mike Horn) Date: Thu, 9 Mar 2006 13:32:24 -0800 (PST) Subject: [Xorp-users] MPLS & MPLS/BGP efforts Message-ID: <6075617.2951141939944298.JavaMail.root@mail.vyatta.com> Thanks Hasso. I read Chris's email too quickly. Let me clarify my comments: The Vyatta implementation will probably implement some type of site-to-site tunneled VPN solution first (IPsec, [GRE+IPsec], SSL), we are looking for ideas on which specific projects we should integrate. We are also looking at remote access VPN gateway solutions (IPsec and/or SSL) for mobile users. For true MPLS-based L3VPN we will need to gauge community interest in this. If you are looking for full PE functionality, my guess would be that there is limited demand for this, but we'll let the community tell us that. We can already act as a CE device, so no changes needed there. I would say the same thing about L2VPN, we would need to better understand community interest and desired capabilities. Sorry for any confusion, the caffeine was just starting to kick in :-) -mike ----- Original Message ----- From: Hasso Tepper To: xorp-users@xorp.org Cc: Mike Horn , Chris Robson NRL Sent: Thursday, March 9, 2006 9:11:59 AM GMT-0700 Subject: Re: [Xorp-users] MPLS & MPLS/BGP efforts Mike Horn wrote: > Vyatta, which is based on the XORP routing platform, is working on > adding L3VPN support and possibly L2VPN support depending community > demand. Once we get it working we'll try to get it integrated with > XORP provided it is something they want to add. Excellent. > For L2VPN are you looking for just 2547, or are you also interested in > the PWE3 stuff as well? RFC2547 isn't about L2VPN, but L3VPN and is obsoleted by RFC4364 already ;). -- Hasso Tepper _______________________________________________ Xorp-users mailing list Xorp-users@xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From Chris.Robson@nrl.navy.mil Thu Mar 9 22:01:38 2006 From: Chris.Robson@nrl.navy.mil (Chris Robson NRL) Date: Thu, 09 Mar 2006 17:01:38 -0500 Subject: [Xorp-users] MPLS & MPLS/BGP efforts In-Reply-To: <6075617.2951141939944298.JavaMail.root@mail.vyatta.com> References: <6075617.2951141939944298.JavaMail.root@mail.vyatta.com> Message-ID: <6.2.1.2.2.20060309165009.02265a40@ginger.cmf.nrl.navy.mil> No problem, you should see my gray matter when not sufficient tuned. Which, for me, is all day every day... :-) I do have a R&D effort revolving around MPLS and would be very interested in any work in these areas. What I hear from the commercial side is large support for L3VPNs. As for the open-community I am clueless to any need other than my own. In fact, the next step after solving the (please excuse the lack of a better name) OpenMPLS I plan to then run the LSPs over IPSec and GRE (or IP-In-IP). Anyway...thanks for the update, and good work...Chris At 04:32 PM 3/9/2006, Mike Horn wrote: >Thanks Hasso. I read Chris's email too quickly. Let me clarify my comments: > >The Vyatta implementation will probably implement some type of >site-to-site tunneled VPN solution first (IPsec, [GRE+IPsec], SSL), we are >looking for ideas on which specific projects we should integrate. We are >also looking at remote access VPN gateway solutions (IPsec and/or SSL) for >mobile users. > >For true MPLS-based L3VPN we will need to gauge community interest in >this. If you are looking for full PE functionality, my guess would be >that there is limited demand for this, but we'll let the community tell us >that. We can already act as a CE device, so no changes needed there. > >I would say the same thing about L2VPN, we would need to better understand >community interest and desired capabilities. > >Sorry for any confusion, the caffeine was just starting to kick in :-) > >-mike > >----- Original Message ----- >From: Hasso Tepper >To: xorp-users@xorp.org >Cc: Mike Horn , Chris Robson NRL >Sent: Thursday, March 9, 2006 9:11:59 AM GMT-0700 >Subject: Re: [Xorp-users] MPLS & MPLS/BGP efforts > >Mike Horn wrote: > > Vyatta, which is based on the XORP routing platform, is working on > > adding L3VPN support and possibly L2VPN support depending community > > demand. Once we get it working we'll try to get it integrated with > > XORP provided it is something they want to add. > >Excellent. > > > For L2VPN are you looking for just 2547, or are you also interested in > > the PWE3 stuff as well? > >RFC2547 isn't about L2VPN, but L3VPN and is obsoleted by RFC4364 >already ;). > > >-- >Hasso Tepper >_______________________________________________ >Xorp-users mailing list >Xorp-users@xorp.org >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 From pavlin@icir.org Thu Mar 9 22:18:08 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 09 Mar 2006 14:18:08 -0800 Subject: [Xorp-users] Announcing XORP Release 1.2 Message-ID: <200603092218.k29MI80i077022@possum.icir.org> On behalf of the entire XORP team, I'm delighted to announce the XORP 1.2 Release, which is now available from . The major new features with this release are: * OSPF implementation. * Complete integration of the routing policy mechanism. * Windows support. In addition, this release contains numerous bug fixes. There are still a number of non-critical bugs that we know about which will not be addressed until the 1.3 release; these are documented in the errata section below and in XORP Bugzilla database . 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.2 (2006/03/08) ========================= ALL: - Numerous improvements, bug fixes and cleanup. - The third-party ospfd implementation is replaced with a new OSPF implementation developed from scratch. - The integration of the routing policy mechanism with the rest of the system is completed. - XORP now builds on Windows Server 2003 (Service Pack 1), amd64+FreeBSD-6.0, FreeBSD-6.1 (BETA3), NetBSD-3.0, OpenBSD-2.8, MacOS X 10.4.5, Linux Fedora Core4 (among others). CONFIGURATION: - Addition of new interface related configuration statement: * restore-original-config-on-shutdown: This optional statement is used to enable the restoring of the original network interface information on shutdown. - Addition of new PIM-SM related configuration statements: * enable-ip-router-alert-option-check: This optional statement is used to enable the IP Router Alert option check per virtual interface. * cand-bsr-by-vif-addr: and * cand-rp-by-vif-addr: Those optional statements are used together with cand-bsr-by-vif-name and cand-rp-by-vif-name respectively to specify the particular IP address on the configured vif. If they are omitted, a domain-wide address (if exists) that belongs to that interface is chosen by the router itself. * hello-period: This optional statement is used to configure the PIM Hello messages period (in seconds). * hello-triggered-delay: This optional statement is used to configure the randomized triggered delay of the PIM Hello messages (in seconds). - Addition of new MLD/IGMP related configuration statements: * version: This optional statement is used to configure the MLD/IGMP protocol version per virtual interface. * enable-ip-router-alert-option-check: This optional statement is used to enable the IP Router Alert option check per virtual interface. * query-interval: This optional statement is used to specify (per virtual interface) the interval between general queries. * query-last-member-interval: This optional statement is used to specify (per virtual interface) the maximum response time inserted into group-specific queries sent in response to leave group messages. * query-response-interval: This optional statement is used to specify (per virtual interface) the maximum response time inserted into the periodic general queries. * robust-count: This optional statement is used to specify (per virtual interface) the robustness variable count that allows tuning for the expected packet loss on a subnet. - Addition of support for user environmental variables CFLAGS_END and CXXFLAGS_END. Those variables can be used to specify the compiler flags (for the C and C++ compiler respectively) that must be after all other flags. LIBXORP: - Various improvements in the RunCommand implementation. LIBXIPC: - No significant changes. LIBFEACLIENT: - No significant changes. XRL: - No significant changes. RTRMGR: - Generalization of the %mandatory keyword syntax so now it can be used to specify any node or variable (multi-value nodes excluded) in the configuration tree. Previously it could be used to specify only configuration child nodes or variables. - Addition of support for read-only, permanent and user-hidden nodes (specified respectively by the new %read-only, %permanent and %user-hidden template commands). - Modification of the %allow and %allow-range semantics so a help string can be supplied for each allowed value or range. - Removal of the mechanism for specifying the hook for saving a configuration file (the "-s " command-line argument). The mechanism is broken and is superseded by the rtrmgr template support for running external programs. - Various other improvements and bug fixes. XORPSH: - Addition of support to run xorpsh in non-interactive mode. - Modification of the configurational mode "show" command so now it displays parameters only if their value is not same as the default value. - Addition of command "show -all" that shows the complete configuration including the parameters with default values. - Modification to the "show" command output: in configuration mode all deleted (and uncommitted) entries are prefixed with "-". - Modification of the default operational and configuration mode prompts to "user@hostname> " and "user@hostname# " respectively. - Addition of support to modify the operational and configuration mode prompts by environmental variables XORP_PROMPT_OPERATIONAL and XORP_PROMPT_CONFIGURATION respectively. - Addition of support for command-line completion for allowed values. - Various other improvements and bug fixes. POLICY: - Several bug fixes. FEA/MFEA: - Addition of RawSocket{4,6} generic abstraction that is not multicast-specific. RIB: - Addition of support for displaying the routing tables in brief, detailed and terse format. The default format is "brief". - Few bug fixes. RIP: - The syntax for configuring the authentication mechanism has changed: OLD: authentication { type: "plaintext" password: "FOO" } OR authentication { type: "md5" password: "FOO" } NEW: authentication { simple-password: "FOO" } OR authentication { md5 1 { /* KeyID: [0, 255] */ password: "FOO" start-time: "YYYY-MM-DD.HH:MM" end-time: "YYYY-MM-DD.HH:MM" } } - Several bug fixes. OSPF: - Initial implementation of OSPF that replaces the third-party ospfd. BGP: - The network4/network6 directives have been deprecated. If you wish to inject static routes into BGP, you must now add these routes to the static_routes protocol block, and then configure the policy engine to redistribute them to BGP. - Proper support for policy filters. - Addition of support for route flap damping. - Addition of support for route aggregation. - Addition of support for route reflection. - Addition of support for confederations. - Bug fix to correctly handle connection collisions. - Addition of default support for NO_EXPORT, NO_ADVERTISE, and NO_EXPORT_SUBCONFED well-known communities. - Addition of the capability to reconfigure a peering (e.g., from IBGP to EBGP) which requires re-configuring the default filters. - Numerous bug fixes that should greatly improve stability. STATIC_ROUTES: - Several bug fixes. MLD/IGMP: - No significant changes. PIM-SM: - Updated to support the lastest PIM-SM specification (draft-ietf-pim-sm-v2-new-11.{ps,txt}). - Addition of support to disable the "wrong iif" kernel upcall on interfaces we don't need to monitor. - Bug fix related to the handling of the deleted MRIB entries. - Bug fix related to transmitting AssertCancel message when a PIM configured interface is gracefully shutdown. FIB2MRIB: - Several bug fixes. CLI: - Various improvements and 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. - The following compiler is known to be buggy, and should not be used to compile XORP: gcc34 (GCC) 3.4.0 20040310 (prerelease) [FreeBSD] A newer compiler such as the following should be used instead: gcc34 (GCC) 3.4.2 20040827 (prerelease) [FreeBSD] - If you run BGP, RIB, FIB2MRIB, and PIM-SM at the same time, the propagation latency for the BGP routes to reach the kernel is increased. We are investigating the problem. 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 - Using the rtrmgr "-r" command-line option to restart processes that have failed does not work if a process fails while being reconfigured via xorpsh. If that happens, the rtrmgr itself may coredump. Therefore, using the "-r" command-line option is not recommended! Also, note that a process that has been killed by SIGTERM or SIGKILL will not be restarted (this is a feature rather than a bug). Ideally, we want to monitor the processes status using the finder rather than the forked children process status, therefore in the future when we have a more robust implementation the "-r" switch will be removed and will be enabled by default. XORPSH: - 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 FEA/MFEA: - 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: ... 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, but it appears the problem may have been fixed for more recent Linux kernel versions: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121697 - The mechanism for tracking the network interface link status may not work for the following OS-es because the kernel for those systems does not provide a mechanism for asynchronous notification of userland programs when the link status changes: FreeBSD-5.2 and earlier and MacOS X (note: if the Windows kernel supports this feature, it is not used yet in XORP). Though, for those systems the link status should be read properly on startup. RIB: - In some rare cases, the RIB may fail to delete an existing route: http://www.xorp.org/bugzilla/show_bug.cgi?id=62 We are aware of the issue and will attempt to fix it in the future. RIP: - No known issues. OSPF: - 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 BGP: - 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 in the future. - The BGP configuration mandates that an IPv4 nexthop must be supplied. Unfortunately it is necessary to provide an IPv4 nexthop even for an IPv6 only peering. Even more unfortunately it is not possible to force the IPv6 nexthop. - It is *essential* for an IPv6 peering that an IPv6 nexthop is provided. Unfortunately the configuration does not enforce this requrement. This will be fixed in the future. - If a policy is configured for marking routes as candidates for aggregation, and an update for such a route arrives while a peering is being brought up (XORP is dumping routes to it), a race condition can occur which is considered by BGP as a fatal error. The problem was observed only on IPv6 peerings, and will be fixed in the future. STATIC_ROUTES: - No known issues. MLD/IGMP: - If MLD/IGMP is started on Linux 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 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 - Currently, the PIM-SM implementation does not support unnumbered point-to-point links. Furthermore, even on numbered point-to-point links the next-hop information in the routing entries should use an IP address instead of an interface name. For example, if there is a GRE tunnel on Linux and if we want to add a route that uses that tunnel, we should use a command like: route add -net gw instead of: route add -net FIB2MRIB: - No known issues. 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 the following URL for links to the net-snmp patches that solve the problems: http://www.xorp.org/snmp.html - Version 5.1 of net-snmp requires a simple modification, otherwise XORP will fail to compile. See the following URL for a link to the net-snmp patch that solves the problems: http://www.xorp.org/snmp.html From pavlin@icir.org Thu Mar 9 22:35:39 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 09 Mar 2006 14:35:39 -0800 Subject: [Xorp-users] IGMPv3/MLDv2 and Embedded-RP In-Reply-To: Message from "Achmad Husni Thamrin" of "Wed, 08 Mar 2006 21:32:13 +0900." <4250f3610603080432v7efba865gcf5ee43f03ad9744@mail.gmail.com> Message-ID: <200603092235.k29MZdpx085559@possum.icir.org> > Looking at the Roadmap, XORP will support IGMPv3/MLDv2 by April. Is this > going to be on schedule? Probably it won't happen by April. The roadmap was just updated, and we aim to support IGMPv3/MLDv2 for the next 1.3 release (June 2006). > Also, I'd like to know the plan to support Embedded-RP. I browsed the code > and didn't find anything that indicates the support for Embedded-RP. For the time being we are not looking to implement Embedded-RP, because we have other higher priority tasks. Pavlin From pavlin@icir.org Thu Mar 9 23:17:43 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 09 Mar 2006 15:17:43 -0800 Subject: [Xorp-users] IPv4 PIM-SM and SSM (was Xorp debug messages) In-Reply-To: Message from Martin Hoffmann of "Wed, 08 Mar 2006 17:04:39 GMT." <440F0EA7.5080408@bris.ac.uk> Message-ID: <200603092317.k29NHh44085913@possum.icir.org> > I solved my problem regarding the Hello messages. I set up a new > machine, running Xorp-1.2-RC and a properly configured 2.6.10 kernel. > Xorp and Click now successfully exchange PIM Hello messages. Can you elaborate a little bit more on the original problem and the solution. If I understand correctly, it was not possible to pass the PIM control messages from Click to XORP (if they were running on the same machine). However, if you run Click on a separate machine directly connected to XORP then XORP could receive the PIM control messages. Is this correct? > I'd like to built a Source Path Tree now. My testbed look like this: > > IGMPv3 Receiver <-> Click router <-> Xorp router <-> Sender > > 1. The sender sends a (S,G) stream to the Xorp router > As a result, "show pim mfc" and "show pim join" return the following lines: > > martin@ubuntu> show pim mfc > Group Source RP > 232.2.2.2 192.168.40.1 0.0.0.0 > Incoming interface : eth1 > Outgoing interfaces: ..O > martin@ubuntu> show pim join > Group Source RP Flags > 232.2.2.2 192.168.40.1 RP_ADDR_UNKNOWN SG SPT DirectlyConnectedS > Upstream interface (S): eth1 > Upstream interface (RP): UNKNOWN > Upstream MRIB next hop (RP): UNKNOWN > Upstream MRIB next hop (S): UNKNOWN > Upstream RPF'(S,G): UNKNOWN > Upstream state: Joined > Register state: RegisterJoin RegisterCouldRegister > Join timer: 4 > KAT(S,G) running: true > Local receiver include WC: ... > Local receiver include SG: ... > Local receiver exclude SG: ... > Joins RP: ... > Joins WC: ... > Joins SG: ..O > Join state: ..O > Prune state: ... > Prune pending state: ... > I am assert winner state: ... > I am assert loser state: ... > Assert winner WC: ... > Assert winner SG: ... > Assert lost WC: ... > Assert lost SG: ... > Assert lost SG_RPT: ... > Assert tracking SG: O.O > Could assert WC: ... > Could assert SG: ..O > I am DR: O.O > Immediate olist RP: ... > Immediate olist WC: ... > Immediate olist SG: ..O > Inherited olist SG: ..O > Inherited olist SG_RPT: ... > PIM include WC: ... > PIM include SG: ... > PIM exclude SG: ... > > Is that ok so far? I guess you have 2+1 PIM-SM related interfaces on your machine: eth0, eth1 and the special register_vif (generated internally by XORP). I presume that eth0 is the interface between the Click router and the XORP router and XORP should receive the PIM-SM (S,G) Join message on this interface. By looking into the "Joins SG" state above, the only Join state is for the third interface (which always is the register_vif), and that state is set internally without any PIM-SM (S,G) Join messages. In other words, it seems that the XORP router hasn't received the expected PIM-SM Join message from the Click router (or at least it didn't like it for some reason). > 2. The IGMPv3 receiver sends an "Include" report to the Click router and > requests an (S,G) stream. The Click routers adds this information to its > forwarding cache. A PIM join message is generated and sent to the Xorp > router. > > 2.1 I used the PIM neighbors unicast address to sent the PIM join > message to. This is mentioned in section 4.3.4 and 4.5.3 in > draft-ietf-pim-sm-v2-new-11.txt. The IP destination address of the PIM Join message must be 224.0.0.13. The "neighbor unicast adderss" mentioned in the above sections refer to the "Upstream Neighbor Address (Encoded-Unicast format)" _inside_ the PIM Join message. > Xorp complains and asks for a multicast address. > [ 2006/03/08 16:28:57 WARNING xorp_pimsm4 PIM ] RX PIM_JOIN_PRUNE from > 192.168.30.6 to 192.168.30.2 on vif eth2: destination must be multicast This complain is legitimate: the destination address must be 224.0.0.13 > 2.2 Sending the PIM join message to the group address (232.2.2.2 in this > case) does not work either. True, another multicast address won't work either. > Xorp adds an entry to its MFC, the Join/Prune message is not reckognised. > martin@ubuntu> show pim mfc > Group Source RP > 232.2.2.2 192.168.30.6 0.0.0.0 > Incoming interface : eth2 > Outgoing interfaces: ... This MFC entry won't forward anything because the outgoing interface set is empty. > The PIM join message format is (tethereal output): > ----- > Frame 4 (72 bytes on wire, 72 bytes captured) > Arrival Time: Mar 8, 2006 16:39:59.819030000 > Time delta from previous packet: 0.009573000 seconds > Time since reference or first frame: 0.121406000 seconds > Frame Number: 4 > Packet Length: 72 bytes > Capture Length: 72 bytes > Protocols in frame: eth:ip:pim > Ethernet II, Src: 00:30:48:52:fe:b3, Dst: 00:09:5b:e4:23:7a > Destination: 00:09:5b:e4:23:7a (192.168.30.2) > Source: 00:30:48:52:fe:b3 (192.168.30.6) > Type: IP (0x0800) > Internet Protocol, Src Addr: 192.168.30.6 (192.168.30.6), Dst Addr: > 232.2.2.2 (232.2.2.2) The IP destination address is wrong (see above). > Version: 4 > Header length: 24 bytes > Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; > ECN: 0x00) > 1100 00.. = Differentiated Services Codepoint: Class Selector 6 > (0x30) > .... ..0. = ECN-Capable Transport (ECT): 0 > .... ...0 = ECN-CE: 0 > Total Length: 58 > Identification: 0xf45f (62559) > Flags: 0x00 > 0... = Reserved bit: Not set > .0.. = Don't fragment: Not set > ..0. = More fragments: Not set > Fragment offset: 0 > Time to live: 1 > Protocol: PIM (0x67) > Header checksum: 0x6686 (correct) > Source: 192.168.30.6 (192.168.30.6) > Destination: 232.2.2.2 (232.2.2.2) > Options: (4 bytes) > Router Alert: Every router examines packet > Protocol Independent Multicast > Version: 2 > Type: Join/Prune (3) > Checksum: 0x1c60 (correct) > PIM parameters > Upstream-neighbor: 192.168.30.6 The "Upstream-neighbor" should not be the IP address of the originator of the PIM packet. Instead, it should be the address of the next-hop router toward the sender (maybe 192.168.30.2 in your setup?). > Groups: 1 > Holdtime: 65535 (infty) > Group 0: 232.2.2.2/32 > Join: 1 > IP address: 192.168.40.1/32 (SW) > Prune: 0 > ----- > > 2.3 draft-ietf-pim-sm-v2-new-11.txt mentions 0.0.0.0 as a valid > destination address, see section 4.5.3. This did not work on Xorp. Section 4.5.3 says th following: On unnumbered interfaces on point-to-point links, the router's address should be the same as the source address it chose for the Hello message it sent over that interface. However on point-to-point links we also recommend that for backwards compatibility PIM Join/Prune messages with a destination address of all zeros are also accepted. In other words, the acceptance of zero destination address is recommended (i.e., it is not mandatory) for backward compatibility purpose, and only on point-to-point links. Furthermore, the UNIX IP stack won't deliver to userland listeners IP packets with zero destination addresses, unless we bypass the IP stack and use bpf-like snooping to get the packets from the wire. This would require significant changes to the MFEA implementations, and such effort can be spent better on other more important tasks. > 2.4 My last try was to send the Join message to 224.0.0.13, the PIM > routers' address. > As a result I get the following line: > [ 2006/03/08 16:55:17 WARNING xorp_pimsm4 PIM ] RX PIM_JOIN_PRUNE from > 192.168.30.6 to 224.0.0.13: invalid source/RP flags for (192.168.40.1, > 232.2.2.2): 0x6 The IP destination address is correct, but some of the flags inside the packet are incorrect, so this is the real reason the XORP router doesn't mark an outgoing interface as joined. The problematic flags are the "|S|W|R|" flags in the Encoded-Source address format (see Section 4.9.1 in the spec). In your case "(S,G) Join" the flags should be "1|0|0" (i.e., 0x4). However, you have "1|1|0". I.e., you have set the S and the W flags, but this is not a valid combination because the spec says that: "If the WC bit is 1, the RPT bit MUST be 1". Keep only the "S" bit value set to 1 and try again. Pavlin From pavlin@icir.org Fri Mar 10 00:35:39 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 09 Mar 2006 16:35:39 -0800 Subject: [Xorp-users] Failed to configure on solaris 2.9 sparc In-Reply-To: Message from "T.J. Yang" of "Wed, 08 Mar 2006 21:13:18 CST." Message-ID: <200603100035.k2A0Zdm9086768@possum.icir.org> > I am able to build xorp on RH linux but not on Solaris. the configure script > looks like work well if openssl is in /usr/lib, /lib. Currently Solaris is not supported (see xorp/BUILD_NOTES for list of platforms that can be used to run XORP). > > Looks like the configure.in has issue but I don't enough to fix it myself. > Can others confirm the issue ? > > > > checking whether preprocessor supports GNU variadic macros... no > checking whether preprocessor supports C99 variadic macros... yes > checking if GNU make is installed... make > checking for python2.2... no > checking for python2... no > checking for python... no > checking OpenSSL installation prefix... /opt/bd/libopenssl097/ > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... no > checking for unistd.h... yes > checking openssl/md5.h usability... yes > checking openssl/md5.h presence... yes > checking for openssl/md5.h... yes > checking for MD5_Init in -lcrypto... no > Could not find part of OpenSSL or one it's components in > /opt/bd/libopenssl097/ > Use --with-openssl=DIR to specify OpenSSL installation root. > error: error executing script > bash-2.05# ls -l /opt/bd/libopenssl097/ > total 30 > drwxr-xr-x 2 root other 512 Mar 6 05:57 bin > drwxr-xr-x 2 root root 1024 Mar 6 05:57 certs > drwxr-xr-x 3 root other 512 Mar 6 05:57 include > drwxr-xr-x 3 root other 512 Mar 6 05:57 lib > drwxr-xr-x 6 root other 512 Mar 6 05:50 man > drwxr-xr-x 2 root other 512 Mar 6 05:57 misc > -rw-r--r-- 1 root other 7521 Mar 6 05:57 openssl.cnf > drwxr-xr-x 2 root other 512 Mar 6 05:57 private > bash-2.05# The particular test inside configure.in is whether it can find a directory like ${xr_cv_openssl_prefix}/include/openssl (e.g., /opt/bd/libopenssl097/include/openssl in your case), and whether that directory contains file md5.h. Furthermore, it checks whether there is a library ${xr_cv_openssl_prefix}/libcrypto* or ${xr_cv_openssl_prefix}/lib/libcrypto* and whether that library contains function MD5_Init(). This should give you some idea where to start looking for the problem. Pavlin From pavlin@icir.org Fri Mar 10 00:50:48 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 09 Mar 2006 16:50:48 -0800 Subject: [Xorp-users] xorp and gated running together In-Reply-To: Message from Chema Martin of "Wed, 08 Mar 2006 22:44:06 +0100." <440F5026.9090407@nextel.es> Message-ID: <200603100050.k2A0omwB086988@possum.icir.org> > > I have a checkpoint cluster working OSPF with the avanced routing of > > checkpoint (this is gated) > > ang I have xorp running multicast PIM-SM in the same cluster. > > It seems that the system works but the gated logs reports a lot of > > error. If I stop xorp I do´nt see this errors messages. > > > > My question is: Do you know any problem with gated and xorp together? In general there shouldn't be any problems if Gated is running only unicast and XORP is running only multicast. In such scenario don't forget the fib2mrib XORP module. > > What is this behavior in the log? Perhaps the unicast routes was lost > > and xorp died? >From the log below, the following error message is probably the real reason that XORP fails: > > Mar 1 01:02:40 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:40 ERROR > > xorp_fea:22293 MFEA +711 mfea_proto_comm.cc join_multicast_group ] > > Cannot join group 224.0.0.13 on vif vl_141: No such device Did you have interface vl_141 already installed in the kernel when XORP tried to use it (most likely on startup). In general, if you configure XORP to use a network interface, that interface must be in the kernel. If the interface is installed on the fly, then you have to configure XORP on the fly to include the new interface in the configuration. Running xorpsh in non-interactive mode can be useful for that purpose. See the user manual for details. Pavlin > > > > Thanks > > Chema > > > > Mar 1 01:01:09 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:09 INFO > > xorp_rtrmgr:20652 RTRMGR +1009 task.cc shutdown ] Shutting down > > module: pimsm4 > > Mar 1 01:01:10 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:10 INFO > > xorp_pimsm4 PIM ] CLI stopped > > Mar 1 01:01:10 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:10 INFO > > xorp_pimsm4 PIM ] Bootstrap mechanism stopped > > Mar 1 01:01:10 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:10 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > > source 55.128.147.254 and group 224.128.147.254: not found > > Mar 1 01:01:10 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:10 ERROR > > xorp_fea:20664 MFEA +632 mfea_proto_comm.cc set_default_multicast_vif > > ] setsockopt(IP_MULTICAST_IF, 55.128.95.254) failed: Cannot assign > > requested address > > Mar 1 01:01:10 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:10 WARNING > > xorp_pimsm4 PIM ] JoinDesired(*,G) = false: RP for group > > 224.128.147.254: not found > > Mar 1 01:01:10 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:10 ERROR > > xorp_fea:20664 MFEA +632 mfea_proto_comm.cc set_default_multicast_vif > > ] setsockopt(IP_MULTICAST_IF, 55.128.95.254) failed: Cannot assign > > requested address > > Mar 1 01:01:10 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:10 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = true: upstream neighbor for > > source 55.128.142.143 and group 230.230.5.20: not found > > Mar 1 01:01:10 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:10 ERROR > > xorp_fea:20664 MFEA +1865 mfea_proto_comm.cc proto_socket_write ] > > sendmsg(proto 2 size 8 from 55.128.95.254 to 224.0.0.6 on vif vl_111) > > failed: Invalid argument > > Mar 1 01:01:10 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:10 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > > source 55.128.191.254 and group 224.128.191.254: not found > > Mar 1 01:01:10 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:10 WARNING > > xorp_fea XrlMfeaTarget ] Handling method for > > mfea/0.1/send_protocol_message4 failed: XrlCmdError 102 Command failed > > Cannot send IGMP protocol message from 55.128.95.254 to 224.0.0.6 on > > vif vl_111 > > Mar 1 01:01:10 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:10 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = true: upstream neighbor for > > source 55.128.142.150 and group 230.230.5.1: not found > > Mar 1 01:01:10 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:10 ERROR > > xorp_igmp:20771 MLD6IGMP +1515 xrl_mld6igmp_node.cc > > mfea_client_send_protocol_message_cb ] Cannot send a protocol message: > > 102 Command failed Cannot send IGMP protocol message from > > 55.128.95.254 to 224.0.0.6 on vif vl_111 > > Mar 1 01:01:10 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:10 WARNING > > xorp_pimsm4 PIM ] JoinDesired(*,G) = false: RP for group > > 224.128.191.254: not found > > Mar 1 01:01:11 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:11 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > > source 55.128.79.254 and group 224.128.79.254: not found > > Mar 1 01:01:11 FW1BJSCPD kernel: vl1_113: dev_set_allmulti(master, -1) > > Mar 1 01:01:11 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:11 ERROR > > xorp_igmp:20771 LIBXORP +161 buffered_asyncio.cc selector_event ] read > > error 104 Connection reset by peer > > Mar 1 01:01:11 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:11 ERROR > > xorp_pimsm4:20806 PIM +240 xrl_pim_node.cc finder_disconnect_event ] > > Finder disconnect event. Exiting immediately... > > Mar 1 01:01:11 FW1BJSCPD kernel: vl1_2001: dev_set_allmulti(master, -1) > > Mar 1 01:01:11 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:11 ERROR > > xorp_igmp:20771 XRL +775 xrl_pf_stcp.cc read_event ] Read failed > > (errno = 104): Connection reset by peer > > Mar 1 01:01:11 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:11 ERROR > > xorp_pimsm4:20806 PIM +2631 xrl_pim_node.cc > > mfea_client_send_protocol_message_cb ] Cannot send a protocol message: > > 210 Transport failed > > Mar 1 01:01:11 FW1BJSCPD kernel: vl_110: dev_set_allmulti(master, -1) > > Mar 1 01:01:11 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:11 ERROR > > xorp_igmp:20771 XRL +629 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: > > read error > > Mar 1 01:01:11 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:11 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = true: upstream neighbor for > > source 55.128.142.149 and group 230.230.5.1: not found > > Mar 1 01:01:11 FW1BJSCPD kernel: vl_111: dev_set_allmulti(master, -1) > > Mar 1 01:01:11 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:11 ERROR > > xorp_igmp:20771 MLD6IGMP +1530 xrl_mld6igmp_node.cc > > mfea_client_send_protocol_message_cb ] Cannot send a protocol message: > > 210 Transport failed > > Mar 1 01:01:11 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:11 WARNING > > xorp_pimsm4 PIM ] JoinDesired(*,G) = false: RP for group > > 224.128.79.254: not found > > Mar 1 01:01:11 FW1BJSCPD kernel: vl_125: dev_set_allmulti(master, -1) > > Mar 1 01:01:11 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:11 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = true: upstream neighbor for > > source 55.128.142.170 and group 230.230.5.20: not found > > Mar 1 01:01:11 FW1BJSCPD kernel: vl_126: dev_set_allmulti(master, -1) > > Mar 1 01:01:11 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:11 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > > source 55.128.95.254 and group 224.128.95.254: not found > > Mar 1 01:01:11 FW1BJSCPD kernel: vl_141: dev_set_allmulti(master, -1) > > Mar 1 01:01:11 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:11 WARNING > > xorp_pimsm4 PIM ] JoinDesired(*,G) = false: upstream neighbor for RP > > 55.63.50.8 for group 230.230.5.201: not found > > Mar 1 01:01:12 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:12 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = true: upstream neighbor for > > source 55.128.144.205 and group 230.230.5.1: not found > > Mar 1 01:01:12 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:12 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = true: upstream neighbor for > > source 55.128.142.31 and group 230.230.5.20: not found > > Mar 1 01:01:12 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:12 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = true: upstream neighbor for > > source 55.128.144.222 and group 230.230.5.1: not found > > Mar 1 01:01:12 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:12 WARNING > > xorp_pimsm4 PIM ] JoinDesired(*,G) = false: RP for group > > 224.128.95.254: not found > > Mar 1 01:01:12 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:12 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = true: upstream neighbor for > > source 55.128.147.59 and group 230.230.5.1: not found > > Mar 1 01:01:12 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:12 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > > source 55.128.143.254 and group 224.128.143.254: not found > > Mar 1 01:01:12 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:12 WARNING > > xorp_pimsm4 PIM ] JoinDesired(*,G) = false: upstream neighbor for RP > > 55.63.50.7 for group 230.230.5.40: not found > > Mar 1 01:01:12 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:12 WARNING > > xorp_pimsm4 PIM ] JoinDesired(*,G) = false: upstream neighbor for RP > > 55.63.50.7 for group 230.230.5.20: not found > > Mar 1 01:01:12 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:12 WARNING > > xorp_pimsm4 PIM ] JoinDesired(*,G) = false: RP for group > > 224.128.143.254: not found > > Mar 1 01:01:12 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:12 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = true: upstream neighbor for > > source 55.128.147.67 and group 230.230.5.20: not found > > Mar 1 01:01:13 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:13 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > > source 55.128.145.254 and group 224.128.145.254: not found > > Mar 1 01:01:13 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:13 WARNING > > xorp_pimsm4 PIM ] JoinDesired(*,G) = false: upstream neighbor for RP > > 55.63.50.7 for group 230.230.5.1: not found > > Mar 1 01:01:13 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:13 WARNING > > xorp_pimsm4 PIM ] JoinDesired(*,G) = false: RP for group > > 224.128.145.254: not found > > Mar 1 01:01:13 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:13 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > > source 55.128.142.2 and group 230.230.5.1: not found > > Mar 1 01:01:13 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:13 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > > source 55.128.142.24 and group 230.230.5.1: not found > > Mar 1 01:01:13 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:13 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > > source 55.128.142.25 and group 230.230.5.1: not found > > Mar 1 01:01:13 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:13 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > > source 55.128.142.27 and group 230.230.5.1: not found > > Mar 1 01:01:13 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:13 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > > source 55.128.142.28 and group 230.230.5.1: not found > > Mar 1 01:01:13 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:13 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > > source 55.128.142.30 and group 230.230.5.1: not found > > Mar 1 01:01:13 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:13 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > > source 55.128.142.32 and group 230.230.5.1: not found > > Mar 1 01:01:13 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:13 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > > source 55.128.142.33 and group 230.230.5.1: not found > > Mar 1 01:01:13 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:13 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > > source 55.128.142.34 and group 230.230.5.1: not found > > Mar 1 01:01:13 FW1BJSCPD ntpdate[22026]: no server suitable for > > synchronization found > > Mar 1 01:01:13 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:13 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > > source 55.128.142.38 and group 230.230.5.1: not found > > Mar 1 01:01:13 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:13 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > > source 55.128.142.54 and group 230.230.5.1: not found > > Mar 1 01:01:13 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:13 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > > source 55.128.142.56 and group 230.230.5.1: not found > > Mar 1 01:01:13 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:13 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > > source 55.128.142.58 and group 230.230.5.1: not found > > Mar 1 01:01:13 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:13 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > > source 55.128.142.60 and group 230.230.5.1: not found > > Mar 1 01:01:14 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:14 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > > source 55.128.142.61 and group 230.230.5.1: not found > > Mar 1 01:01:14 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:14 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > > source 55.128.142.62 and group 230.230.5.1: not found > > Mar 1 01:01:14 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:14 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > > source 55.128.142.63 and group 230.230.5.1: not found > > Mar 1 01:01:14 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:14 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > > source 55.128.142.64 and group 230.230.5.1: not found > > Mar 1 01:01:14 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:14 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > > source 55.128.142.66 and group 230.230.5.1: not found > > Mar 1 01:01:14 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:14 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > > source 55.128.142.80 and group 230.230.5.1: not found > > Mar 1 01:01:14 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:14 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > > source 55.128.142.81 and group 230.230.5.1: not found > > Mar 1 01:01:14 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:14 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > > source 55.128.142.82 and group 230.230.5.1: not found > > Mar 1 01:01:14 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:14 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > > source 55.128.142.83 and group 230.230.5.1: not found > > Mar 1 01:01:14 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:14 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > > source 55.128.142.84 and group 230.230.5.1: not found > > Mar 1 01:01:14 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:14 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > > source 55.128.142.85 and group 230.230.5.1: not found > > Mar 1 01:01:14 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:14 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > > source 55.128.142.86 and group 230.230.5.1: not found > > Mar 1 01:01:14 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:14 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > > source 55.128.142.88 and group 230.230.5.1: not found > > Mar 1 01:01:14 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:14 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > > source 55.128.142.89 and group 230.230.5.1: not found > > Mar 1 01:01:14 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:14 WARNING > > xorp_pimsm4 PIM ] JoinDesired(S,G) = false: upstream neighbor for > > source 55.128.142.90 and group 230.230.5.1: not found > > Mar 1 01:01:48 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:48 INFO > > xorp_rtrmgr:22260 RTRMGR +170 master_conf_tree.cc execute ] Changed > > modules: interfaces, fea, mfea4, rib, fib2mrib, igmp, pimsm4 > > Mar 1 01:01:48 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:48 INFO > > xorp_rtrmgr:22260 RTRMGR +426 module_manager.cc run ] Running module: > > interfaces (/opt/bladefusion/xorp/fea/xorp_fea) > > Mar 1 01:01:50 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:50 INFO xorp_fea > > CLI ] CLI enabled > > Mar 1 01:01:50 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:50 INFO xorp_fea > > CLI ] CLI started > > Mar 1 01:01:50 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:50 INFO xorp_fea > > MFEA ] MFEA enabled > > Mar 1 01:01:50 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:50 INFO xorp_fea > > MFEA ] CLI enabled > > Mar 1 01:01:50 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:50 INFO xorp_fea > > MFEA ] CLI started > > Mar 1 01:01:51 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:51 INFO > > xorp_rtrmgr:22260 RTRMGR +426 module_manager.cc run ] Running module: > > fea (/opt/bladefusion/xorp/fea/xorp_fea) > > Mar 1 01:01:57 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:57 INFO > > xorp_rtrmgr:22260 RTRMGR +426 module_manager.cc run ] Running module: > > mfea4 (/opt/bladefusion/xorp/fea/xorp_fea) > > Mar 1 01:01:57 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:57 INFO xorp_fea > > MFEA ] Interface added: Vif[vl1_113] pif_index: 20 vif_index: 0 addr: > > 55.128.147.254 subnet: 55.128.146.0/23 broadcast: 55.128.147.255 peer: > > 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > > Mar 1 01:01:57 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:57 INFO xorp_fea > > MFEA ] Interface added: Vif[vl1_2001] pif_index: 21 vif_index: 1 addr: > > 55.128.191.254 subnet: 55.128.176.0/20 broadcast: 55.128.191.255 peer: > > 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > > Mar 1 01:01:57 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:57 INFO xorp_fea > > MFEA ] Interface added: Vif[vl_110] pif_index: 15 vif_index: 2 addr: > > 55.128.79.254 subnet: 55.128.64.0/20 broadcast: 55.128.79.255 peer: > > 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > > Mar 1 01:01:57 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:57 INFO xorp_fea > > MFEA ] Interface added: Vif[vl_111] pif_index: 14 vif_index: 3 addr: > > 55.128.95.254 subnet: 55.128.80.0/20 broadcast: 55.128.95.255 peer: > > 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > > Mar 1 01:01:57 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:57 INFO xorp_fea > > MFEA ] Interface added: Vif[vl_125] pif_index: 13 vif_index: 4 addr: > > 55.128.143.254 subnet: 55.128.142.0/23 broadcast: 55.128.143.255 peer: > > 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > > Mar 1 01:01:57 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:57 INFO xorp_fea > > MFEA ] Interface added: Vif[vl_126] pif_index: 12 vif_index: 5 addr: > > 55.128.145.254 subnet: 55.128.144.0/23 broadcast: 55.128.145.255 peer: > > 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > > Mar 1 01:01:57 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:57 INFO xorp_fea > > MFEA ] Interface added: Vif[vl_141] pif_index: 11 vif_index: 6 addr: > > 55.128.16.3 subnet: 55.128.16.0/25 broadcast: 55.128.16.127 peer: > > 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > > Mar 1 01:01:57 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:57 INFO xorp_fea > > MFEA ] MFEA started > > Mar 1 01:01:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:58 INFO xorp_fea > > MFEA ] Interface enabled Vif[vl_141] pif_index: 11 vif_index: 6 addr: > > 55.128.16.3 subnet: 55.128.16.0/25 broadcast: 55.128.16.127 peer: > > 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 ENABLED > > Mar 1 01:01:58 FW1BJSCPD kernel: vl_141: dev_set_allmulti(master, 1) > > Mar 1 01:01:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:58 INFO xorp_fea > > MFEA ] Interface started: Vif[vl_141] pif_index: 11 vif_index: 6 addr: > > 55.128.16.3 subnet: 55.128.16.0/25 broadcast: 55.128.16.127 peer: > > 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 ENABLED > > Mar 1 01:01:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:58 INFO xorp_fea > > MFEA ] Interface added: Vif[register_vif] pif_index: 11 vif_index: 7 > > addr: 55.128.16.3 subnet: 55.128.16.3/32 broadcast: 55.128.16.3 peer: > > 0.0.0.0 Flags: PIM_REGISTER UNDERLYING_VIF_UP > > Mar 1 01:01:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:58 INFO xorp_fea > > MFEA ] Interface enabled Vif[vl1_2001] pif_index: 21 vif_index: 1 > > addr: 55.128.191.254 subnet: 55.128.176.0/20 broadcast: 55.128.191.255 > > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 > > ENABLED > > Mar 1 01:01:58 FW1BJSCPD kernel: vl1_2001: dev_set_allmulti(master, 1) > > Mar 1 01:01:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:58 INFO xorp_fea > > MFEA ] Interface started: Vif[vl1_2001] pif_index: 21 vif_index: 1 > > addr: 55.128.191.254 subnet: 55.128.176.0/20 broadcast: 55.128.191.255 > > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 > > ENABLED > > Mar 1 01:01:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:58 INFO xorp_fea > > MFEA ] Interface enabled Vif[vl_110] pif_index: 15 vif_index: 2 addr: > > 55.128.79.254 subnet: 55.128.64.0/20 broadcast: 55.128.79.255 peer: > > 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 ENABLED > > Mar 1 01:01:58 FW1BJSCPD kernel: vl_110: dev_set_allmulti(master, 1) > > Mar 1 01:01:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:58 INFO xorp_fea > > MFEA ] Interface started: Vif[vl_110] pif_index: 15 vif_index: 2 addr: > > 55.128.79.254 subnet: 55.128.64.0/20 broadcast: 55.128.79.255 peer: > > 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 ENABLED > > Mar 1 01:01:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:58 INFO xorp_fea > > MFEA ] Interface enabled Vif[vl_111] pif_index: 14 vif_index: 3 addr: > > 55.128.95.254 subnet: 55.128.80.0/20 broadcast: 55.128.95.255 peer: > > 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 ENABLED > > Mar 1 01:01:58 FW1BJSCPD kernel: vl_111: dev_set_allmulti(master, 1) > > Mar 1 01:01:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:58 INFO xorp_fea > > MFEA ] Interface started: Vif[vl_111] pif_index: 14 vif_index: 3 addr: > > 55.128.95.254 subnet: 55.128.80.0/20 broadcast: 55.128.95.255 peer: > > 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 ENABLED > > Mar 1 01:01:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:58 INFO xorp_fea > > MFEA ] Interface enabled Vif[vl1_113] pif_index: 20 vif_index: 0 addr: > > 55.128.147.254 subnet: 55.128.146.0/23 broadcast: 55.128.147.255 peer: > > 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 ENABLED > > Mar 1 01:01:58 FW1BJSCPD kernel: vl1_113: dev_set_allmulti(master, 1) > > Mar 1 01:01:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:58 INFO xorp_fea > > MFEA ] Interface started: Vif[vl1_113] pif_index: 20 vif_index: 0 > > addr: 55.128.147.254 subnet: 55.128.146.0/23 broadcast: 55.128.147.255 > > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 > > ENABLED > > Mar 1 01:01:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:58 INFO xorp_fea > > MFEA ] Interface enabled Vif[vl_125] pif_index: 13 vif_index: 4 addr: > > 55.128.143.254 subnet: 55.128.142.0/23 broadcast: 55.128.143.255 peer: > > 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 ENABLED > > Mar 1 01:01:58 FW1BJSCPD kernel: vl_125: dev_set_allmulti(master, 1) > > Mar 1 01:01:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:58 INFO xorp_fea > > MFEA ] Interface started: Vif[vl_125] pif_index: 13 vif_index: 4 addr: > > 55.128.143.254 subnet: 55.128.142.0/23 broadcast: 55.128.143.255 peer: > > 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 ENABLED > > Mar 1 01:01:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:58 INFO xorp_fea > > MFEA ] Interface enabled Vif[vl_126] pif_index: 12 vif_index: 5 addr: > > 55.128.145.254 subnet: 55.128.144.0/23 broadcast: 55.128.145.255 peer: > > 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 ENABLED > > Mar 1 01:01:58 FW1BJSCPD kernel: vl_126: dev_set_allmulti(master, 1) > > Mar 1 01:01:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:58 INFO xorp_fea > > MFEA ] Interface started: Vif[vl_126] pif_index: 12 vif_index: 5 addr: > > 55.128.145.254 subnet: 55.128.144.0/23 broadcast: 55.128.145.255 peer: > > 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 ENABLED > > Mar 1 01:01:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:58 INFO xorp_fea > > MFEA ] Interface enabled Vif[register_vif] pif_index: 11 vif_index: 7 > > addr: 55.128.16.3 subnet: 55.128.16.3/32 broadcast: 55.128.16.3 peer: > > 0.0.0.0 Flags: PIM_REGISTER UNDERLYING_VIF_UP DOWN IPv4 ENABLED > > Mar 1 01:01:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:58 INFO xorp_fea > > MFEA ] Interface started: Vif[register_vif] pif_index: 11 vif_index: 7 > > addr: 55.128.16.3 subnet: 55.128.16.3/32 broadcast: 55.128.16.3 peer: > > 0.0.0.0 Flags: PIM_REGISTER UNDERLYING_VIF_UP UP IPv4 ENABLED > > Mar 1 01:01:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:01:58 INFO > > xorp_rtrmgr:22260 RTRMGR +426 module_manager.cc run ] Running module: > > rib (/opt/bladefusion/xorp/rib/xorp_rib) > > Mar 1 01:02:00 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:00 INFO > > xorp_rtrmgr:22260 RTRMGR +426 module_manager.cc run ] Running module: > > fib2mrib (/opt/bladefusion/xorp/fib2mrib/xorp_fib2mrib) > > Mar 1 01:02:02 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:02 INFO > > xorp_rtrmgr:22260 RTRMGR +426 module_manager.cc run ] Running module: > > igmp (/opt/bladefusion/xorp/mld6igmp/xorp_igmp) > > Mar 1 01:02:02 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:02 WARNING > > xorp_rtrmgr:22260 XrlFinderTarget +405 ../xrl/targets/finder_base.cc > > handle_finder_0_2_resolve_xrl ] Handling method for > > finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target > > "IGMP" does not exist or is not enabled. > > Mar 1 01:02:03 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:03 INFO xorp_igmp > > MLD6IGMP ] Protocol enabled > > Mar 1 01:02:03 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:03 INFO xorp_igmp > > MLD6IGMP ] CLI enabled > > Mar 1 01:02:03 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:03 INFO xorp_igmp > > MLD6IGMP ] CLI started > > Mar 1 01:02:03 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:03 WARNING > > xorp_fea MFEA ] Read 55.128.16.1 -> 55.128.16.3 Mar 1 01:02:03 > > FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:03 WARNING xorp_fea MFEA ] Read > > 55.128.16.2 -> 55.128.16.3 Mar 1 01:02:03 FW1BJSCPD BF-PIM: [ > > 2006/03/01 01:02:03 WARNING xorp_fea MFEA ] Read 55.128.191.252 -> > > 55.128.191.254 Mar 1 01:02:03 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:03 > > WARNING xorp_fea MFEA ] Read 55.128.191.253 -> 55.128.191.254 Mar 1 > > 01:02:03 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:03 WARNING xorp_fea MFEA > > ] Read 55.128.79.252 -> 55.128.79.254 Mar 1 01:02:03 FW1BJSCPD > > BF-PIM: [ 2006/03/01 01:02:03 WARNING xorp_fea MFEA ] Read > > 55.128.79.253 -> 55.128.79.254 Mar 1 01:02:03 FW1BJSCPD BF-PIM: [ > > 2006/03/01 01:02:03 WARNING xorp_fea MFEA ] Read 55.128.95.252 -> > > 55.128.95.254 Mar 1 01:02:03 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:03 > > WARNING xorp_fea MFEA ] Read 55.128.95.253 -> 55.128.95.254 Mar 1 > > 01:02:03 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:03 WARNING xorp_fea MFEA > > ] Read 55.128.147.252 -> 55.128.147.254 Mar 1 01:02:03 FW1BJSCPD > > BF-PIM: [ 2006/03/01 01:02:03 WARNING xorp_fea MFEA ] Read > > 55.128.147.253 -> 55.128.147.254 Mar 1 01:02:03 FW1BJSCPD BF-PIM: [ > > 2006/03/01 01:02:03 WARNING xorp_fea MFEA ] Read 55.128.143.252 -> > > 55.128.143.254 Mar 1 01:02:03 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:03 > > WARNING xorp_fea MFEA ] Read 55.128.143.253 -> 55.128.143.254 Mar 1 > > 01:02:03 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:03 WARNING xorp_fea MFEA > > ] Read 55.128.145.252 -> 55.128.145.254 Mar 1 01:02:04 FW1BJSCPD > > BF-PIM: [ 2006/03/01 01:02:04 WARNING xorp_fea MFEA ] Read > > 55.128.145.253 -> 55.128.145.254 Mar 1 01:02:04 FW1BJSCPD BF-PIM: [ > > 2006/03/01 01:02:04 ERROR xorp_fea:22293 MFEA +147 mfea_proto_comm.cc > > BFReadConf ] bladefusion - wrong addr match > > Mar 1 01:02:04 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:04 INFO xorp_igmp > > MLD6IGMP ] Interface added: Vif[vl1_113] pif_index: 0 vif_index: 0 > > addr: 55.128.147.254 subnet: 55.128.146.0/23 broadcast: 55.128.147.255 > > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > > Mar 1 01:02:04 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:04 INFO xorp_igmp > > MLD6IGMP ] Interface added: Vif[vl1_2001] pif_index: 0 vif_index: 1 > > addr: 55.128.191.254 subnet: 55.128.176.0/20 broadcast: 55.128.191.255 > > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > > Mar 1 01:02:04 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:04 INFO xorp_igmp > > MLD6IGMP ] Interface added: Vif[vl_110] pif_index: 0 vif_index: 2 > > addr: 55.128.79.254 subnet: 55.128.64.0/20 broadcast: 55.128.79.255 > > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > > Mar 1 01:02:04 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:04 INFO xorp_igmp > > MLD6IGMP ] Interface added: Vif[vl_111] pif_index: 0 vif_index: 3 > > addr: 55.128.95.254 subnet: 55.128.80.0/20 broadcast: 55.128.95.255 > > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > > Mar 1 01:02:04 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:04 INFO xorp_igmp > > MLD6IGMP ] Interface added: Vif[vl_125] pif_index: 0 vif_index: 4 > > addr: 55.128.143.254 subnet: 55.128.142.0/23 broadcast: 55.128.143.255 > > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > > Mar 1 01:02:04 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:04 INFO xorp_igmp > > MLD6IGMP ] Interface added: Vif[vl_126] pif_index: 0 vif_index: 5 > > addr: 55.128.145.254 subnet: 55.128.144.0/23 broadcast: 55.128.145.255 > > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > > Mar 1 01:02:04 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:04 INFO xorp_igmp > > MLD6IGMP ] Interface added: Vif[vl_141] pif_index: 0 vif_index: 6 > > addr: 55.128.16.3 subnet: 55.128.16.0/25 broadcast: 55.128.16.127 > > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > > Mar 1 01:02:04 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:04 INFO xorp_igmp > > MLD6IGMP ] Protocol started > > Mar 1 01:02:05 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:05 INFO xorp_igmp > > MLD6IGMP ] Interface enabled: Vif[vl_141] pif_index: 0 vif_index: 6 > > addr: 55.128.16.3 subnet: 55.128.16.0/25 broadcast: 55.128.16.127 > > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 > > ENABLED > > Mar 1 01:02:05 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:05 INFO xorp_igmp > > MLD6IGMP ] Interface started: Vif[vl_141] pif_index: 0 vif_index: 6 > > addr: 55.128.16.3 subnet: 55.128.16.0/25 broadcast: 55.128.16.127 > > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 > > ENABLED > > Mar 1 01:02:05 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:05 INFO xorp_igmp > > MLD6IGMP ] Interface enabled: Vif[vl1_2001] pif_index: 0 vif_index: 1 > > addr: 55.128.191.254 subnet: 55.128.176.0/20 broadcast: 55.128.191.255 > > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 > > ENABLED > > Mar 1 01:02:05 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:05 INFO xorp_igmp > > MLD6IGMP ] Interface started: Vif[vl1_2001] pif_index: 0 vif_index: 1 > > addr: 55.128.191.254 subnet: 55.128.176.0/20 broadcast: 55.128.191.255 > > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 > > ENABLED > > Mar 1 01:02:05 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:05 INFO xorp_igmp > > MLD6IGMP ] Interface enabled: Vif[vl_110] pif_index: 0 vif_index: 2 > > addr: 55.128.79.254 subnet: 55.128.64.0/20 broadcast: 55.128.79.255 > > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 > > ENABLED > > Mar 1 01:02:05 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:05 INFO xorp_igmp > > MLD6IGMP ] Interface started: Vif[vl_110] pif_index: 0 vif_index: 2 > > addr: 55.128.79.254 subnet: 55.128.64.0/20 broadcast: 55.128.79.255 > > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 > > ENABLED > > Mar 1 01:02:05 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:05 INFO xorp_igmp > > MLD6IGMP ] Interface enabled: Vif[vl_111] pif_index: 0 vif_index: 3 > > addr: 55.128.95.254 subnet: 55.128.80.0/20 broadcast: 55.128.95.255 > > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 > > ENABLED > > Mar 1 01:02:05 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:05 INFO xorp_igmp > > MLD6IGMP ] Interface started: Vif[vl_111] pif_index: 0 vif_index: 3 > > addr: 55.128.95.254 subnet: 55.128.80.0/20 broadcast: 55.128.95.255 > > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 > > ENABLED > > Mar 1 01:02:06 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:06 INFO xorp_igmp > > MLD6IGMP ] Interface enabled: Vif[vl1_113] pif_index: 0 vif_index: 0 > > addr: 55.128.147.254 subnet: 55.128.146.0/23 broadcast: 55.128.147.255 > > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 > > ENABLED > > Mar 1 01:02:06 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:06 INFO xorp_igmp > > MLD6IGMP ] Interface started: Vif[vl1_113] pif_index: 0 vif_index: 0 > > addr: 55.128.147.254 subnet: 55.128.146.0/23 broadcast: 55.128.147.255 > > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 > > ENABLED > > Mar 1 01:02:06 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:06 INFO xorp_igmp > > MLD6IGMP ] Interface enabled: Vif[vl_125] pif_index: 0 vif_index: 4 > > addr: 55.128.143.254 subnet: 55.128.142.0/23 broadcast: 55.128.143.255 > > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 > > ENABLED > > Mar 1 01:02:06 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:06 INFO xorp_igmp > > MLD6IGMP ] Interface started: Vif[vl_125] pif_index: 0 vif_index: 4 > > addr: 55.128.143.254 subnet: 55.128.142.0/23 broadcast: 55.128.143.255 > > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 > > ENABLED > > Mar 1 01:02:06 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:06 INFO xorp_igmp > > MLD6IGMP ] Interface enabled: Vif[vl_126] pif_index: 0 vif_index: 5 > > addr: 55.128.145.254 subnet: 55.128.144.0/23 broadcast: 55.128.145.255 > > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 > > ENABLED > > Mar 1 01:02:06 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:06 INFO xorp_igmp > > MLD6IGMP ] Interface started: Vif[vl_126] pif_index: 0 vif_index: 5 > > addr: 55.128.145.254 subnet: 55.128.144.0/23 broadcast: 55.128.145.255 > > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP UP IPv4 > > ENABLED > > Mar 1 01:02:06 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:06 INFO > > xorp_rtrmgr:22260 RTRMGR +426 module_manager.cc run ] Running module: > > pimsm4 (/opt/bladefusion/xorp/pim/xorp_pimsm4) > > Mar 1 01:02:06 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:06 WARNING > > xorp_rtrmgr:22260 XrlFinderTarget +405 ../xrl/targets/finder_base.cc > > handle_finder_0_2_resolve_xrl ] Handling method for > > finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target > > "PIMSM_4" does not exist or is not enabled. > > Mar 1 01:02:07 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:07 WARNING > > xorp_rtrmgr:22260 XrlFinderTarget +405 ../xrl/targets/finder_base.cc > > handle_finder_0_2_resolve_xrl ] Handling method for > > finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Xrl > > target is not enabled. > > Mar 1 01:02:08 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:08 INFO > > xorp_pimsm4 PIM ] Protocol enabled > > Mar 1 01:02:08 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:08 INFO > > xorp_pimsm4 PIM ] CLI enabled > > Mar 1 01:02:08 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:08 INFO > > xorp_pimsm4 PIM ] CLI started > > Mar 1 01:02:26 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:26 INFO > > xorp_pimsm4 PIM ] Interface added: Vif[register_vif] pif_index: 0 > > vif_index: 7 addr: 55.128.16.3 subnet: 55.128.16.3/32 broadcast: > > 55.128.16.3 peer: 0.0.0.0 Flags: PIM_REGISTER UNDERLYING_VIF_UP > > Mar 1 01:02:26 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:26 INFO > > xorp_pimsm4 PIM ] Interface added: Vif[vl1_113] pif_index: 0 > > vif_index: 0 addr: 55.128.147.254 subnet: 55.128.146.0/23 broadcast: > > 55.128.147.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > > Mar 1 01:02:26 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:26 INFO > > xorp_pimsm4 PIM ] Interface added: Vif[vl1_2001] pif_index: 0 > > vif_index: 1 addr: 55.128.191.254 subnet: 55.128.176.0/20 broadcast: > > 55.128.191.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > > Mar 1 01:02:26 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:26 INFO > > xorp_pimsm4 PIM ] Interface added: Vif[vl_110] pif_index: 0 vif_index: > > 2 addr: 55.128.79.254 subnet: 55.128.64.0/20 broadcast: 55.128.79.255 > > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > > Mar 1 01:02:26 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:26 INFO > > xorp_pimsm4 PIM ] Interface added: Vif[vl_111] pif_index: 0 vif_index: > > 3 addr: 55.128.95.254 subnet: 55.128.80.0/20 broadcast: 55.128.95.255 > > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > > Mar 1 01:02:26 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:26 INFO > > xorp_pimsm4 PIM ] Interface added: Vif[vl_125] pif_index: 0 vif_index: > > 4 addr: 55.128.143.254 subnet: 55.128.142.0/23 broadcast: > > 55.128.143.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > > Mar 1 01:02:26 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:26 INFO > > xorp_pimsm4 PIM ] Interface added: Vif[vl_126] pif_index: 0 vif_index: > > 5 addr: 55.128.145.254 subnet: 55.128.144.0/23 broadcast: > > 55.128.145.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > > Mar 1 01:02:26 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:26 INFO > > xorp_pimsm4 PIM ] Interface added: Vif[vl_141] pif_index: 0 vif_index: > > 6 addr: 55.128.16.3 subnet: 55.128.16.0/25 broadcast: 55.128.16.127 > > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP > > Mar 1 01:02:26 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:26 INFO > > xorp_pimsm4 PIM ] Protocol started > > Mar 1 01:02:39 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:39 INFO > > xorp_pimsm4 PIM ] Interface enabled: Vif[vl_141] pif_index: 0 > > vif_index: 6 addr: 55.128.16.3 subnet: 55.128.16.0/25 broadcast: > > 55.128.16.127 peer: 0.0.0.0 Flags: MULTICAST BROADCAST > > UNDERLYING_VIF_UP DOWN IPv4 ENABLED > > Mar 1 01:02:39 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:39 INFO > > xorp_pimsm4 PIM ] Interface started: Vif[vl_141] pif_index: 0 > > vif_index: 6 addr: 55.128.16.3 subnet: 55.128.16.0/25 broadcast: > > 55.128.16.127 peer: 0.0.0.0 Flags: MULTICAST BROADCAST > > UNDERLYING_VIF_UP UP IPv4 ENABLED > > Mar 1 01:02:39 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:39 INFO > > xorp_pimsm4 PIM ] Interface enabled: Vif[vl1_2001] pif_index: 0 > > vif_index: 1 addr: 55.128.191.254 subnet: 55.128.176.0/20 broadcast: > > 55.128.191.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST > > UNDERLYING_VIF_UP DOWN IPv4 ENABLED > > Mar 1 01:02:40 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:40 INFO > > xorp_pimsm4 PIM ] Interface started: Vif[vl1_2001] pif_index: 0 > > vif_index: 1 addr: 55.128.191.254 subnet: 55.128.176.0/20 broadcast: > > 55.128.191.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST > > UNDERLYING_VIF_UP UP IPv4 ENABLED > > Mar 1 01:02:40 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:40 INFO > > xorp_pimsm4 PIM ] Interface enabled: Vif[vl_110] pif_index: 0 > > vif_index: 2 addr: 55.128.79.254 subnet: 55.128.64.0/20 broadcast: > > 55.128.79.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST > > UNDERLYING_VIF_UP DOWN IPv4 ENABLED > > Mar 1 01:02:40 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:40 ERROR > > xorp_fea:22293 MFEA +711 mfea_proto_comm.cc join_multicast_group ] > > Cannot join group 224.0.0.13 on vif vl_141: No such device > > Mar 1 01:02:40 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:40 INFO > > xorp_pimsm4 PIM ] Interface started: Vif[vl_110] pif_index: 0 > > vif_index: 2 addr: 55.128.79.254 subnet: 55.128.64.0/20 broadcast: > > 55.128.79.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST > > UNDERLYING_VIF_UP UP IPv4 ENABLED > > Mar 1 01:02:40 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:40 INFO > > xorp_rtrmgr:22260 RTRMGR +2182 task.cc run_task ] No more tasks to run > > Mar 1 01:02:40 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:40 WARNING > > xorp_fea XrlMfeaTarget ] Handling method for > > mfea/0.1/join_multicast_group4 failed: XrlCmdError 102 Command failed > > Cannot join group 224.0.0.13 on vif vl_141 > > Mar 1 01:02:40 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:40 WARNING > > xorp_pimsm4 PIM ] JoinDesired(*,G) = true: RP for group 224.128.16.3: > > not found > > Mar 1 01:02:40 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:40 FATAL > > xorp_pimsm4:22431 PIM +1648 xrl_pim_node.cc > > mfea_client_send_join_leave_multicast_group_cb ] Cannot join a > > multicast group with the MFEA: 102 Command failed Cannot join group > > 224.0.0.13 on vif vl_141 > > Mar 1 01:02:40 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:40 ERROR > > xorp_rib:22377 RIB +204 redist_xrl.cc dispatch_complete ] Fatal error > > during route redistribution: 210 Transport failed > > Mar 1 01:02:40 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:40 ERROR > > xorp_igmp:22404 MLD6IGMP +1300 xrl_mld6igmp_node.cc > > mld6igmp_client_send_add_delete_membership_cb ] XRL communication > > error: 210 Transport failed > > Mar 1 01:02:41 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:41 ERROR > > xorp_fea:22293 MFEA +632 mfea_proto_comm.cc set_default_multicast_vif > > ] setsockopt(IP_MULTICAST_IF, 55.128.95.254) failed: Cannot assign > > requested address > > Mar 1 01:02:41 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:41 ERROR > > xorp_fea:22293 MFEA +632 mfea_proto_comm.cc set_default_multicast_vif > > ] setsockopt(IP_MULTICAST_IF, 55.128.95.254) failed: Cannot assign > > requested address > > Mar 1 01:02:41 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:41 ERROR > > xorp_fea:22293 MFEA +1865 mfea_proto_comm.cc proto_socket_write ] > > sendmsg(proto 2 size 8 from 55.128.95.254 to 224.0.0.6 on vif vl_111) > > failed: Invalid argument > > Mar 1 01:02:41 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:41 ERROR > > xorp_igmp:22404 MLD6IGMP +188 xrl_mld6igmp_node.cc > > finder_disconnect_event ] Finder disconnect event. Exiting immediately... > > Mar 1 01:02:41 FW1BJSCPD kernel: vl1_113: dev_set_allmulti(master, -1) > > Mar 1 01:02:41 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:41 INFO xorp_igmp > > MLD6IGMP ] Interface stopped: Vif[vl1_113] pif_index: 0 vif_index: 0 > > addr: 55.128.147.254 subnet: 55.128.146.0/23 broadcast: 55.128.147.255 > > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 > > ENABLED > > Mar 1 01:02:41 FW1BJSCPD kernel: vl1_2001: dev_set_allmulti(master, -1) > > Mar 1 01:02:41 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:41 INFO xorp_igmp > > MLD6IGMP ] Interface stopped: Vif[vl1_2001] pif_index: 0 vif_index: 1 > > addr: 55.128.191.254 subnet: 55.128.176.0/20 broadcast: 55.128.191.255 > > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 > > ENABLED > > Mar 1 01:02:41 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:41 INFO xorp_igmp > > MLD6IGMP ] Interface stopped: Vif[vl_110] pif_index: 0 vif_index: 2 > > addr: 55.128.79.254 subnet: 55.128.64.0/20 broadcast: 55.128.79.255 > > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 > > ENABLED > > Mar 1 01:02:41 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:41 INFO xorp_igmp > > MLD6IGMP ] Interface stopped: Vif[vl_111] pif_index: 0 vif_index: 3 > > addr: 55.128.95.254 subnet: 55.128.80.0/20 broadcast: 55.128.95.255 > > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 > > ENABLED > > Mar 1 01:02:41 FW1BJSCPD kernel: vl_110: dev_set_allmulti(master, -1) > > Mar 1 01:02:41 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:41 INFO xorp_igmp > > MLD6IGMP ] Interface stopped: Vif[vl_125] pif_index: 0 vif_index: 4 > > addr: 55.128.143.254 subnet: 55.128.142.0/23 broadcast: 55.128.143.255 > > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 > > ENABLED > > Mar 1 01:02:42 FW1BJSCPD kernel: vl_111: dev_set_allmulti(master, -1) > > Mar 1 01:02:42 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:42 INFO xorp_igmp > > MLD6IGMP ] Interface stopped: Vif[vl_126] pif_index: 0 vif_index: 5 > > addr: 55.128.145.254 subnet: 55.128.144.0/23 broadcast: 55.128.145.255 > > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 > > ENABLED > > Mar 1 01:02:42 FW1BJSCPD kernel: vl_125: dev_set_allmulti(master, -1) > > Mar 1 01:02:42 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:42 INFO xorp_igmp > > MLD6IGMP ] Interface stopped: Vif[vl_141] pif_index: 0 vif_index: 6 > > addr: 55.128.16.3 subnet: 55.128.16.0/25 broadcast: 55.128.16.127 > > peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP DOWN IPv4 > > ENABLED > > Mar 1 01:02:42 FW1BJSCPD kernel: vl_126: dev_set_allmulti(master, -1) > > Mar 1 01:02:42 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:42 ERROR > > xorp_igmp:22404 MLD6IGMP +1530 xrl_mld6igmp_node.cc > > mfea_client_send_protocol_message_cb ] Cannot send a protocol message: > > 210 Transport failed > > Mar 1 01:02:42 FW1BJSCPD kernel: vl_141: dev_set_allmulti(master, -1) > > Mar 1 01:02:44 FW1BJSCPD ntpdate[22455]: adjust time server 55.1.1.2 > > offset 0.012073 sec > > Mar 1 01:02:57 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:57 INFO > > xorp_rtrmgr:22677 RTRMGR +170 master_conf_tree.cc execute ] Changed > > modules: interfaces, fea, mfea4, rib, fib2mrib, igmp, pimsm4 > > Mar 1 01:02:57 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:57 INFO > > xorp_rtrmgr:22677 RTRMGR +426 module_manager.cc run ] Running module: > > interfaces (/opt/bladefusion/xorp/fea/xorp_fea) > > Mar 1 01:02:57 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:57 INFO xorp_fea > > CLI ] CLI enabled > > Mar 1 01:02:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:58 INFO xorp_fea > > CLI ] CLI started > > Mar 1 01:02:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:58 INFO xorp_fea > > MFEA ] MFEA enabled > > Mar 1 01:02:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:58 INFO xorp_fea > > MFEA ] CLI enabled > > Mar 1 01:02:58 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:58 INFO xorp_fea > > MFEA ] CLI started > > Mar 1 01:02:59 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:59 INFO > > xorp_rtrmgr:22677 RTRMGR +2182 task.cc run_task ] No more tasks to run > > Mar 1 01:02:59 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:59 INFO > > xorp_rtrmgr:22677 RTRMGR +219 module_manager.cc terminate ] > > Terminating module: interfaces > > Mar 1 01:02:59 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:59 INFO > > xorp_rtrmgr:22677 RTRMGR +272 module_manager.cc terminate ] Killing > > module: interfaces (pid = 22689) > > Mar 1 01:02:59 FW1BJSCPD BF-PIM: [ 2006/03/01 01:02:59 INFO > > xorp_rtrmgr:22677 RTRMGR +576 module_manager.cc killed ] Module killed > > during shutdown: interfaces > > > > > > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From mhorn@vyatta.com Fri Mar 10 02:17:13 2006 From: mhorn@vyatta.com (Mike Horn) Date: Thu, 9 Mar 2006 18:17:13 -0800 (PST) Subject: [Xorp-users] MPLS & MPLS/BGP efforts Message-ID: <9651699.3341141957033353.JavaMail.root@mail.vyatta.com> Hi Chris, Sounds like we have similar arguments with our gray matter. ;-) Out of curiosity, since you are planning to run the LSPs over tunnels, are you just using MPLS for traffic segregation? Or is there some other L3VPN capability that you are trying to leverage? I don't see anyone using Vyatta/XORP as a commercial PE router, at least not for quite some time, so our development in this area is probably a ways out. However, if you are able to contribute your work back to the Vyatta/XORP community I'm sure we would all like to be able to leverage what you guys get done. Looking to hearing about your progress! -mike ----- Original Message ----- From: Chris Robson NRL To: Mike Horn , Hasso Tepper Cc: xorp-users@xorp.org Sent: Thursday, March 9, 2006 3:01:38 PM GMT-0700 Subject: Re: [Xorp-users] MPLS & MPLS/BGP efforts No problem, you should see my gray matter when not sufficient tuned. Which, for me, is all day every day... :-) I do have a R&D effort revolving around MPLS and would be very interested in any work in these areas. What I hear from the commercial side is large support for L3VPNs. As for the open-community I am clueless to any need other than my own. In fact, the next step after solving the (please excuse the lack of a better name) OpenMPLS I plan to then run the LSPs over IPSec and GRE (or IP-In-IP). Anyway...thanks for the update, and good work...Chris At 04:32 PM 3/9/2006, Mike Horn wrote: >Thanks Hasso. I read Chris's email too quickly. Let me clarify my comments: > >The Vyatta implementation will probably implement some type of >site-to-site tunneled VPN solution first (IPsec, [GRE+IPsec], SSL), we are >looking for ideas on which specific projects we should integrate. We are >also looking at remote access VPN gateway solutions (IPsec and/or SSL) for >mobile users. > >For true MPLS-based L3VPN we will need to gauge community interest in >this. If you are looking for full PE functionality, my guess would be >that there is limited demand for this, but we'll let the community tell us >that. We can already act as a CE device, so no changes needed there. > >I would say the same thing about L2VPN, we would need to better understand >community interest and desired capabilities. > >Sorry for any confusion, the caffeine was just starting to kick in :-) > >-mike > >----- Original Message ----- >From: Hasso Tepper >To: xorp-users@xorp.org >Cc: Mike Horn , Chris Robson NRL >Sent: Thursday, March 9, 2006 9:11:59 AM GMT-0700 >Subject: Re: [Xorp-users] MPLS & MPLS/BGP efforts > >Mike Horn wrote: > > Vyatta, which is based on the XORP routing platform, is working on > > adding L3VPN support and possibly L2VPN support depending community > > demand. Once we get it working we'll try to get it integrated with > > XORP provided it is something they want to add. > >Excellent. > > > For L2VPN are you looking for just 2547, or are you also interested in > > the PWE3 stuff as well? > >RFC2547 isn't about L2VPN, but L3VPN and is obsoleted by RFC4364 >already ;). > > >-- >Hasso Tepper >_______________________________________________ >Xorp-users mailing list >Xorp-users@xorp.org >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 _______________________________________________ Xorp-users mailing list Xorp-users@xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From mhorn@vyatta.com Fri Mar 10 02:19:16 2006 From: mhorn@vyatta.com (Mike Horn) Date: Thu, 9 Mar 2006 18:19:16 -0800 (PST) Subject: [Xorp-users] Re: [Xorp-hackers] Announcing XORP Release 1.2 Message-ID: <29662751.3371141957156751.JavaMail.root@mail.vyatta.com> Hi Pavlin, Congratulations on getting 1.2 released! I know the XORP team has been working really hard and the number of bug fixes and enhancements in this release is truly impressive. Thanks to everyone that helped make this happen! -mike ----- Original Message ----- From: Pavlin Radoslavov To: xorp-announce@xorp.org Cc: xorp-users@xorp.org, xorp-hackers@xorp.org Sent: Thursday, March 9, 2006 3:18:08 PM GMT-0700 Subject: [Xorp-hackers] Announcing XORP Release 1.2 On behalf of the entire XORP team, I'm delighted to announce the XORP 1.2 Release, which is now available from . The major new features with this release are: * OSPF implementation. * Complete integration of the routing policy mechanism. * Windows support. In addition, this release contains numerous bug fixes. There are still a number of non-critical bugs that we know about which will not be addressed until the 1.3 release; these are documented in the errata section below and in XORP Bugzilla database . 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.2 (2006/03/08) ========================= ALL: - Numerous improvements, bug fixes and cleanup. - The third-party ospfd implementation is replaced with a new OSPF implementation developed from scratch. - The integration of the routing policy mechanism with the rest of the system is completed. - XORP now builds on Windows Server 2003 (Service Pack 1), amd64+FreeBSD-6.0, FreeBSD-6.1 (BETA3), NetBSD-3.0, OpenBSD-2.8, MacOS X 10.4.5, Linux Fedora Core4 (among others). CONFIGURATION: - Addition of new interface related configuration statement: * restore-original-config-on-shutdown: This optional statement is used to enable the restoring of the original network interface information on shutdown. - Addition of new PIM-SM related configuration statements: * enable-ip-router-alert-option-check: This optional statement is used to enable the IP Router Alert option check per virtual interface. * cand-bsr-by-vif-addr: and * cand-rp-by-vif-addr: Those optional statements are used together with cand-bsr-by-vif-name and cand-rp-by-vif-name respectively to specify the particular IP address on the configured vif. If they are omitted, a domain-wide address (if exists) that belongs to that interface is chosen by the router itself. * hello-period: This optional statement is used to configure the PIM Hello messages period (in seconds). * hello-triggered-delay: This optional statement is used to configure the randomized triggered delay of the PIM Hello messages (in seconds). - Addition of new MLD/IGMP related configuration statements: * version: This optional statement is used to configure the MLD/IGMP protocol version per virtual interface. * enable-ip-router-alert-option-check: This optional statement is used to enable the IP Router Alert option check per virtual interface. * query-interval: This optional statement is used to specify (per virtual interface) the interval between general queries. * query-last-member-interval: This optional statement is used to specify (per virtual interface) the maximum response time inserted into group-specific queries sent in response to leave group messages. * query-response-interval: This optional statement is used to specify (per virtual interface) the maximum response time inserted into the periodic general queries. * robust-count: This optional statement is used to specify (per virtual interface) the robustness variable count that allows tuning for the expected packet loss on a subnet. - Addition of support for user environmental variables CFLAGS_END and CXXFLAGS_END. Those variables can be used to specify the compiler flags (for the C and C++ compiler respectively) that must be after all other flags. LIBXORP: - Various improvements in the RunCommand implementation. LIBXIPC: - No significant changes. LIBFEACLIENT: - No significant changes. XRL: - No significant changes. RTRMGR: - Generalization of the %mandatory keyword syntax so now it can be used to specify any node or variable (multi-value nodes excluded) in the configuration tree. Previously it could be used to specify only configuration child nodes or variables. - Addition of support for read-only, permanent and user-hidden nodes (specified respectively by the new %read-only, %permanent and %user-hidden template commands). - Modification of the %allow and %allow-range semantics so a help string can be supplied for each allowed value or range. - Removal of the mechanism for specifying the hook for saving a configuration file (the "-s " command-line argument). The mechanism is broken and is superseded by the rtrmgr template support for running external programs. - Various other improvements and bug fixes. XORPSH: - Addition of support to run xorpsh in non-interactive mode. - Modification of the configurational mode "show" command so now it displays parameters only if their value is not same as the default value. - Addition of command "show -all" that shows the complete configuration including the parameters with default values. - Modification to the "show" command output: in configuration mode all deleted (and uncommitted) entries are prefixed with "-". - Modification of the default operational and configuration mode prompts to "user@hostname> " and "user@hostname# " respectively. - Addition of support to modify the operational and configuration mode prompts by environmental variables XORP_PROMPT_OPERATIONAL and XORP_PROMPT_CONFIGURATION respectively. - Addition of support for command-line completion for allowed values. - Various other improvements and bug fixes. POLICY: - Several bug fixes. FEA/MFEA: - Addition of RawSocket{4,6} generic abstraction that is not multicast-specific. RIB: - Addition of support for displaying the routing tables in brief, detailed and terse format. The default format is "brief". - Few bug fixes. RIP: - The syntax for configuring the authentication mechanism has changed: OLD: authentication { type: "plaintext" password: "FOO" } OR authentication { type: "md5" password: "FOO" } NEW: authentication { simple-password: "FOO" } OR authentication { md5 1 { /* KeyID: [0, 255] */ password: "FOO" start-time: "YYYY-MM-DD.HH:MM" end-time: "YYYY-MM-DD.HH:MM" } } - Several bug fixes. OSPF: - Initial implementation of OSPF that replaces the third-party ospfd. BGP: - The network4/network6 directives have been deprecated. If you wish to inject static routes into BGP, you must now add these routes to the static_routes protocol block, and then configure the policy engine to redistribute them to BGP. - Proper support for policy filters. - Addition of support for route flap damping. - Addition of support for route aggregation. - Addition of support for route reflection. - Addition of support for confederations. - Bug fix to correctly handle connection collisions. - Addition of default support for NO_EXPORT, NO_ADVERTISE, and NO_EXPORT_SUBCONFED well-known communities. - Addition of the capability to reconfigure a peering (e.g., from IBGP to EBGP) which requires re-configuring the default filters. - Numerous bug fixes that should greatly improve stability. STATIC_ROUTES: - Several bug fixes. MLD/IGMP: - No significant changes. PIM-SM: - Updated to support the lastest PIM-SM specification (draft-ietf-pim-sm-v2-new-11.{ps,txt}). - Addition of support to disable the "wrong iif" kernel upcall on interfaces we don't need to monitor. - Bug fix related to the handling of the deleted MRIB entries. - Bug fix related to transmitting AssertCancel message when a PIM configured interface is gracefully shutdown. FIB2MRIB: - Several bug fixes. CLI: - Various improvements and 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. - The following compiler is known to be buggy, and should not be used to compile XORP: gcc34 (GCC) 3.4.0 20040310 (prerelease) [FreeBSD] A newer compiler such as the following should be used instead: gcc34 (GCC) 3.4.2 20040827 (prerelease) [FreeBSD] - If you run BGP, RIB, FIB2MRIB, and PIM-SM at the same time, the propagation latency for the BGP routes to reach the kernel is increased. We are investigating the problem. 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 - Using the rtrmgr "-r" command-line option to restart processes that have failed does not work if a process fails while being reconfigured via xorpsh. If that happens, the rtrmgr itself may coredump. Therefore, using the "-r" command-line option is not recommended! Also, note that a process that has been killed by SIGTERM or SIGKILL will not be restarted (this is a feature rather than a bug). Ideally, we want to monitor the processes status using the finder rather than the forked children process status, therefore in the future when we have a more robust implementation the "-r" switch will be removed and will be enabled by default. XORPSH: - 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 FEA/MFEA: - 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: ... 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, but it appears the problem may have been fixed for more recent Linux kernel versions: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121697 - The mechanism for tracking the network interface link status may not work for the following OS-es because the kernel for those systems does not provide a mechanism for asynchronous notification of userland programs when the link status changes: FreeBSD-5.2 and earlier and MacOS X (note: if the Windows kernel supports this feature, it is not used yet in XORP). Though, for those systems the link status should be read properly on startup. RIB: - In some rare cases, the RIB may fail to delete an existing route: http://www.xorp.org/bugzilla/show_bug.cgi?id=62 We are aware of the issue and will attempt to fix it in the future. RIP: - No known issues. OSPF: - 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 BGP: - 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 in the future. - The BGP configuration mandates that an IPv4 nexthop must be supplied. Unfortunately it is necessary to provide an IPv4 nexthop even for an IPv6 only peering. Even more unfortunately it is not possible to force the IPv6 nexthop. - It is *essential* for an IPv6 peering that an IPv6 nexthop is provided. Unfortunately the configuration does not enforce this requrement. This will be fixed in the future. - If a policy is configured for marking routes as candidates for aggregation, and an update for such a route arrives while a peering is being brought up (XORP is dumping routes to it), a race condition can occur which is considered by BGP as a fatal error. The problem was observed only on IPv6 peerings, and will be fixed in the future. STATIC_ROUTES: - No known issues. MLD/IGMP: - If MLD/IGMP is started on Linux 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 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 - Currently, the PIM-SM implementation does not support unnumbered point-to-point links. Furthermore, even on numbered point-to-point links the next-hop information in the routing entries should use an IP address instead of an interface name. For example, if there is a GRE tunnel on Linux and if we want to add a route that uses that tunnel, we should use a command like: route add -net gw instead of: route add -net FIB2MRIB: - No known issues. 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 the following URL for links to the net-snmp patches that solve the problems: http://www.xorp.org/snmp.html - Version 5.1 of net-snmp requires a simple modification, otherwise XORP will fail to compile. See the following URL for a link to the net-snmp patch that solves the problems: http://www.xorp.org/snmp.html _______________________________________________ Xorp-hackers mailing list Xorp-hackers@icir.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From mh5942@bris.ac.uk Fri Mar 10 17:08:24 2006 From: mh5942@bris.ac.uk (Martin Hoffmann) Date: Fri, 10 Mar 2006 17:08:24 +0000 Subject: [Xorp-users] IPv4 PIM-SM and SSM (was Xorp debug messages) In-Reply-To: <200603092317.k29NHh44085913@possum.icir.org> References: <200603092317.k29NHh44085913@possum.icir.org> Message-ID: <4411B288.4050600@bris.ac.uk> > > >>I solved my problem regarding the Hello messages. I set up a new >>machine, running Xorp-1.2-RC and a properly configured 2.6.10 kernel. >>Xorp and Click now successfully exchange PIM Hello messages. >> >> > >Can you elaborate a little bit more on the original problem and the >solution. If I understand correctly, it was not possible to pass the >PIM control messages from Click to XORP (if they were running on the >same machine). However, if you run Click on a separate machine >directly connected to XORP then XORP could receive the PIM control >messages. Is this correct? > > I'm running Click and Xorp on separate machines. As you suggested before I set up a pure Xorp testbed (2 machines). Sending PIM control messages worked fine but neither of the Xorp routers received the messages. They physically passed the link (tethereal). The machines are servers in the machine room and half the department is working on them. Since I don't even have root access, I gave up searching for the problem and set up my laptop as a 2-port Xorp router. Maybe the problem was a messed up kernel configuration. I was confused because it was possible for the Xorp routers to receive IGMP messages from connected hosts. I couldn't figure out why they didn't get PIM control messages. Receiver <--IGMP works--> Xorp Router <--PIM control doesn't work-->Xorp Router <--.... Click is working fine on these machines so I did not investigate any further. Thank you for explaining all the rest, it made a lot of things clear! >The problematic flags are the "|S|W|R|" flags in the Encoded-Source >address format (see Section 4.9.1 in the spec). >In your case "(S,G) Join" the flags should be "1|0|0" (i.e., 0x4). >However, you have "1|1|0". I.e., you have set the S and the W flags, >but this is not a valid combination because the spec says that: >"If the WC bit is 1, the RPT bit MUST be 1". > >Keep only the "S" bit value set to 1 and try again. > > Yes, that solved the problem. Click and Xorp routers are now building a shortest path tree. Hello and Join/Prune messages work fine. Xorp throws the following warning for each multicast packet: [ ... WARNING xorp_pimsm4 PIM ] RX WHOLEPKT signal from MFEA_4: vif_index = 2 src = 192.168.40.1 dst = 232.2.2.2 len = 1344: no interface connected directly to source What's wrong here? Martin From dave.price@aber.ac.uk Fri Mar 10 18:39:08 2006 From: dave.price@aber.ac.uk (Dave Price) Date: Fri, 10 Mar 2006 18:39:08 +0000 Subject: [Xorp-users] XORP config with stupid broadcast address Message-ID: <15860.1142015948@aber.ac.uk> Dear All, While using my xorp config file as an example in a document, I just spotted I had a really silly broadcast address on one interface. I had... ============= interface eth4 { description: "Abernet Interface" disable: false /* default-system-config */ vif eth4 { disable: false address 144.124.34.30 { prefix-length: 22 broadcast: 133.124.35.255 disable: false } } } =========================== Shouldn't there be some "sanity checking" that would realise that 133.124.35.255 was rather silly for an interface with address 144.124.34.30 ?? As far as I can se, I had no complaints in logs etc. (Indeed, I seemed to have PIM-SM connectivity fine via that interface which is my route to the world...) Dave Price From mhorn@vyatta.com Fri Mar 10 18:53:01 2006 From: mhorn@vyatta.com (Mike Horn) Date: Fri, 10 Mar 2006 10:53:01 -0800 (PST) Subject: [Xorp-users] XORP config with stupid broadcast address Message-ID: <14899133.3521142016781446.JavaMail.root@mail.vyatta.com> Hi Dave, I would agree with you, in fact I opened a bug on this (bug 163) a while ago: http://www.xorp.org/bugzilla/show_bug.cgi?id=163 However, the applicable RFC allows for non-standard broadcast addresses. The system now automatically generates the standard broadcast address (the user no longer has to manually define it), so I think the behavior is ok. If someone really wants to modify the broadcast address they still have the ability to tweak the configuration. This is from a comment in the bug: For example, RFC 922, Section 7 "Broadcast IP Addressing - Conventions" says: Since the local network layer can always map an IP address into data link layer address, the choice of an IP "broadcast host number" is somewhat arbitrary. For simplicity, it should be one not likely to be assigned to a real host. The number whose bits are all ones has this property; this assignment was first proposed in [6]. In the few cases where a host has been assigned an address with a host-number part of all ones, it does not seem onerous to require renumbering. The sys ----- Original Message ----- From: Dave Price To: xorp-users@xorp.org Cc: dap@aber.ac.uk Sent: Friday, March 10, 2006 11:39:08 AM GMT-0700 Subject: [Xorp-users] XORP config with stupid broadcast address Dear All, While using my xorp config file as an example in a document, I just spotted I had a really silly broadcast address on one interface. I had... ============= interface eth4 { description: "Abernet Interface" disable: false /* default-system-config */ vif eth4 { disable: false address 144.124.34.30 { prefix-length: 22 broadcast: 133.124.35.255 disable: false } } } =========================== Shouldn't there be some "sanity checking" that would realise that 133.124.35.255 was rather silly for an interface with address 144.124.34.30 ?? As far as I can se, I had no complaints in logs etc. (Indeed, I seemed to have PIM-SM connectivity fine via that interface which is my route to the world...) Dave Price _______________________________________________ Xorp-users mailing list Xorp-users@xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From dave.price@aber.ac.uk Fri Mar 10 20:11:35 2006 From: dave.price@aber.ac.uk (Dave Price) Date: Fri, 10 Mar 2006 20:11:35 +0000 Subject: [Xorp-users] XORP config with stupid broadcast address In-Reply-To: Your message of Fri, 10 Mar 2006 10:53:01 -0800. <14899133.3521142016781446.JavaMail.root@mail.vyatta.com> Message-ID: <16080.1142021495@aber.ac.uk> Dear Mike, mhorn@vyatta.com said: > However, the applicable RFC allows for non-standard broadcast > addresses. The system now automatically generates the standard > broadcast address (the user no longer has to manually define it), so I > think the behavior is ok. Yes, I see what you say. I suppose I just felt embarrassed when I nearly copied my file, error and all, into a document I am writing that lots of other might just read.... I was also a bit surprised that it seemed to be working.... I guess I was simply not using any IP broadcasts in reality out of that interface. Dave Price From pavlin@icir.org Sat Mar 11 00:11:50 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 10 Mar 2006 16:11:50 -0800 Subject: [Xorp-users] IPv4 PIM-SM and SSM (was Xorp debug messages) In-Reply-To: Message from Martin Hoffmann of "Fri, 10 Mar 2006 17:08:24 GMT." <4411B288.4050600@bris.ac.uk> Message-ID: <200603110011.k2B0Bona063675@possum.icir.org> > >>I solved my problem regarding the Hello messages. I set up a new > >>machine, running Xorp-1.2-RC and a properly configured 2.6.10 kernel. > >>Xorp and Click now successfully exchange PIM Hello messages. > >> > >> > > > >Can you elaborate a little bit more on the original problem and the > >solution. If I understand correctly, it was not possible to pass the > >PIM control messages from Click to XORP (if they were running on the > >same machine). However, if you run Click on a separate machine > >directly connected to XORP then XORP could receive the PIM control > >messages. Is this correct? > > > > > I'm running Click and Xorp on separate machines. > As you suggested before I set up a pure Xorp testbed (2 machines). > Sending PIM control messages worked fine but neither of the Xorp routers > received the messages. They physically passed the link (tethereal). > The machines are servers in the machine room and half the department is > working on them. Since I don't even have root access, I gave up > searching for the problem and set up my laptop as a 2-port Xorp router. > Maybe the problem was a messed up kernel configuration. > I was confused because it was possible for the Xorp routers to receive > IGMP messages from connected hosts. I couldn't figure out why they > didn't get PIM control messages. > > Receiver <--IGMP works--> Xorp Router <--PIM control doesn't work-->Xorp > Router <--.... > > Click is working fine on these machines so I did not investigate any > further. A quick suggestion: could be a firewall rule that stops the messages? Otherwise, it is difficult to find the problem without further investigation. > Thank you for explaining all the rest, it made a lot of things clear! > > >The problematic flags are the "|S|W|R|" flags in the Encoded-Source > >address format (see Section 4.9.1 in the spec). > >In your case "(S,G) Join" the flags should be "1|0|0" (i.e., 0x4). > >However, you have "1|1|0". I.e., you have set the S and the W flags, > >but this is not a valid combination because the spec says that: > >"If the WC bit is 1, the RPT bit MUST be 1". > > > >Keep only the "S" bit value set to 1 and try again. > > > > > Yes, that solved the problem. Click and Xorp routers are now building a > shortest path tree. Hello and Join/Prune messages work fine. > > Xorp throws the following warning for each multicast packet: > [ ... WARNING xorp_pimsm4 PIM ] RX WHOLEPKT signal from MFEA_4: > vif_index = 2 src = 192.168.40.1 dst = 232.2.2.2 len = 1344: no > interface connected directly to source The data packet from source 192.168.40.1 was received on an interface (probably the third one in the order you can see them with the "show pim interface" command), but that interface either doesn't exist anymore (less likely), or is not UP. What is the output of "show pim interface"? If you want to debug the reason for the warning (e.g., to print the name of the interface with vif_index of 2 if it exists), add some XLOG_TRACE() right before the above XLOG_WARNING() around line 154 in pim/pim_mrt_mfc.cc. Pavlin From dave.price@aber.ac.uk Mon Mar 13 10:07:11 2006 From: dave.price@aber.ac.uk (Dave Price) Date: Mon, 13 Mar 2006 10:07:11 +0000 Subject: [Xorp-users] XORP config - why 127.127.0.1 In-Reply-To: Your message of Fri, 10 Mar 2006 20:11:35 +0000. <16080.1142021495@aber.ac.uk> Message-ID: <3443.1142244431@aber.ac.uk> Dear All, The sample config.boot given out with Xorp 1.2RC contains... interface discard0 { description: "discard interface" disable: false discard: true vif discard0 { disable: false address 127.127.0.1 { prefix-length: 32 disable: false } } } Can some explain the logic behind why this particular address is chosen. I'm quite used to the fact that 127.0.0.1 refers to localhost of course, but I'd not picked up on signficance of 127.127.0.1 Thanks, Dave Price From mhorn@vyatta.com Mon Mar 13 15:44:24 2006 From: mhorn@vyatta.com (Mike Horn) Date: Mon, 13 Mar 2006 07:44:24 -0800 (PST) Subject: [Xorp-users] XORP config - why 127.127.0.1 Message-ID: <4655492.4031142264664047.JavaMail.root@mail.vyatta.com> Hi Dave, On the XORP system, the traditional loopback 127.0.0.1 is used by the XRL IPC process, so you need to be very careful when configuring things like interface IP addresses, firewall rules, etc. that might affect this communications path. For instance, creating a discard interface with the 127.0.0.1 IP address could cause rtrmgr to stop communicating with the other processes, which would be fatal (hence the use of a different IP address in the example). In order to avoid confusion the sample configuration should probably be updated with a different IP address. -mike ----- Original Message ----- From: Dave Price To: xorp-users@xorp.org Cc: dap@aber.ac.uk Sent: Monday, March 13, 2006 3:07:11 AM GMT-0700 Subject: [Xorp-users] XORP config - why 127.127.0.1 Dear All, The sample config.boot given out with Xorp 1.2RC contains... interface discard0 { description: "discard interface" disable: false discard: true vif discard0 { disable: false address 127.127.0.1 { prefix-length: 32 disable: false } } } Can some explain the logic behind why this particular address is chosen. I'm quite used to the fact that 127.0.0.1 refers to localhost of course, but I'd not picked up on signficance of 127.127.0.1 Thanks, Dave Price _______________________________________________ Xorp-users mailing list Xorp-users@xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From bms@spc.org Mon Mar 13 21:52:07 2006 From: bms@spc.org (Bruce M Simpson) Date: Mon, 13 Mar 2006 21:52:07 +0000 Subject: [Xorp-users] XORP config - why 127.127.0.1 In-Reply-To: <3443.1142244431@aber.ac.uk> References: <16080.1142021495@aber.ac.uk> <3443.1142244431@aber.ac.uk> Message-ID: <20060313215207.GT81299@spc.org> On Mon, Mar 13, 2006 at 10:07:11AM +0000, Dave Price wrote: > Can some explain the logic behind why this particular address > is chosen. I'm quite used to the fact that 127.0.0.1 > refers to localhost of course, but I'd not picked > up on signficance of 127.127.0.1 I wrote this, so I'll own up. The discard interface, as implemented in most router operating systems, is a special case of the loopback interface (Cisco IOS, FreeBSD). Therefore I picked a specific address within 127.0.0.0/8 for those cases where all traffic for a given destination should be discarded, when working with next-hop resolution which doesn't treat discard next-hops as a special case, i.e. code which only understands routes to specific IPv4 destinations, such as the Windows FIB (which has no concept of a discard interface, or indeed unnumbered IP interfaces for that matter). The discard interface itself can be implemented in several ways at FIB level. Both Cisco IOS and FreeBSD have discard interfaces which are fully fledged IPv4 interfaces visible to the entire TCP/IP stack, and can broadly be treated as 'like loopback, but goes nowhere'. However, Linux (and older BSD derived implementations), rather than having a separate and distinct 'discard interface', instead have a special flag for a kernel FIB entry which says 'packets for this destination are to be discarded' (RTF_BLACKHOLE). The concept of the discard interface in XORP exists to deal with this implementation difference. At XORP RIB level, it acts as an interface to which packets may be forwarded much as any other directly connected interface route where Layer 2 next-hop resolution is dealt with by a lower layer (e.g. ARP, NDP, ATM-ARP) and the RIB/FIB need merely transmit the packet on the interface. The FEA takes care of mapping a XORP discard interface to a FIB flag or a platform's real discard interface, if that helps (on FreeBSD, using the fast-forwarding i.e. RTF_BLACKHOLE FIB path is actually faster, I committed a patch from an OCCAID member well over a year ago to blackhole more quickly). Because many FIBs deal purely in terms of IPv4 next-hops, sometimes it's necessary to just stuff something in there to keep it happy. You'll see this if you dip down deep into the murky depths of the rtsock code in the FEA. And 127.127.0.1 seemed less confusing (NTP is the only other application I know of which overloads the meaning of 127/8 address space in this way). This is probably more confusing than the original statement, but there you go! Regards, BMS From dave.price@aber.ac.uk Tue Mar 14 09:11:08 2006 From: dave.price@aber.ac.uk (Dave Price) Date: Tue, 14 Mar 2006 09:11:08 +0000 Subject: [Xorp-users] XORP config - why 127.127.0.1 In-Reply-To: Your message of Mon, 13 Mar 2006 21:52:07 +0000. <20060313215207.GT81299@spc.org> Message-ID: <5669.1142327468@aber.ac.uk> Dear Bruce, bms@spc.org said: > This is probably more confusing than the original statement, but there > you go! Thanks for your email. I found it detailed and clear. Great. Dave Price From kristian@juniks.net Tue Mar 14 19:59:34 2006 From: kristian@juniks.net (Kristian Larsson) Date: Tue, 14 Mar 2006 20:59:34 +0100 Subject: [Xorp-users] XORP config - why 127.127.0.1 In-Reply-To: <20060313215207.GT81299@spc.org> References: <16080.1142021495@aber.ac.uk> <3443.1142244431@aber.ac.uk> <20060313215207.GT81299@spc.org> Message-ID: <20060314195933.GC138@juniks.net> On Mon, Mar 13, 2006 at 09:52:07PM +0000, Bruce M Simpson wrote: > On Mon, Mar 13, 2006 at 10:07:11AM +0000, Dave Price wrote: > > Can some explain the logic behind why this particular address > > is chosen. I'm quite used to the fact that 127.0.0.1 > > refers to localhost of course, but I'd not picked > > up on signficance of 127.127.0.1 > > I wrote this, so I'll own up. > > The discard interface, as implemented in most router operating systems, > is a special case of the loopback interface (Cisco IOS, FreeBSD). > > Therefore I picked a specific address within 127.0.0.0/8 for those cases > where all traffic for a given destination should be discarded, when working > with next-hop resolution which doesn't treat discard next-hops as a special > case, i.e. code which only understands routes to specific IPv4 destinations, > such as the Windows FIB (which has no concept of a discard interface, or > indeed unnumbered IP interfaces for that matter). > > The discard interface itself can be implemented in several ways at FIB level. > Both Cisco IOS and FreeBSD have discard interfaces which are fully fledged > IPv4 interfaces visible to the entire TCP/IP stack, and can broadly be > treated as 'like loopback, but goes nowhere'. > > However, Linux (and older BSD derived implementations), rather than having > a separate and distinct 'discard interface', instead have a special flag > for a kernel FIB entry which says 'packets for this destination are to be > discarded' (RTF_BLACKHOLE). > > The concept of the discard interface in XORP exists to deal with this > implementation difference. At XORP RIB level, it acts as an > interface to which packets may be forwarded much as any other directly > connected interface route where Layer 2 next-hop resolution is dealt > with by a lower layer (e.g. ARP, NDP, ATM-ARP) and the RIB/FIB need > merely transmit the packet on the interface. > > The FEA takes care of mapping a XORP discard interface to a FIB flag or a > platform's real discard interface, if that helps (on FreeBSD, using the > fast-forwarding i.e. RTF_BLACKHOLE FIB path is actually faster, I > committed a patch from an OCCAID member well over a year ago to blackhole > more quickly). > > Because many FIBs deal purely in terms of IPv4 next-hops, sometimes it's > necessary to just stuff something in there to keep it happy. You'll see this > if you dip down deep into the murky depths of the rtsock code in the FEA. > > And 127.127.0.1 seemed less confusing (NTP is the only other application > I know of which overloads the meaning of 127/8 address space in this way). > > This is probably more confusing than the original statement, but there you go! Might one suggest using 192.0.2.1 in the examples as this is somewhat of an industry standard for blackhole destinations. Regards, Kristian From caluml@gmail.com Tue Mar 14 21:59:10 2006 From: caluml@gmail.com (Calum) Date: Tue, 14 Mar 2006 21:59:10 +0000 Subject: [Xorp-users] Stuff Message-ID: <635498b70603141359n51c217e5q103e3854c3feb414@mail.gmail.com> Hello all, Thanks for your help getting me up and running. I understand the way it's bolted together a lot more now, and so I'm happier. I have 3 points. 1. The fact that XORP falls over when an interface is actually removed (actually stopping a process that creates the tun/tap interface) is a biggie for me. Does this not affect anyone else? 2. Is it not possible that, if you try and add protocol pimsm4 int1 vif int1, and you haven't declared int1 in the interface section that it could automatically add that for you? Along with the mfea4, etc, etc? 3. I'm trying to set up a multicast network in order to learn more about PIM, but it's tricky. I can't seem to find anything about the Mbone these days - did that disappear? If it has, is there any sort of test network for joining up to? If not, would anyone on here like to create one? Grab a BGP AS each, a few openvpn/ipsec tunnels around the place, and an IRC channel, and we could get one working pretty well, methinks. If you would, please get in touch off-list. Thanks, Calum PS. Did Gmail die for anyone else about 10 mins ago? From pavlin@icir.org Tue Mar 14 23:26:07 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 14 Mar 2006 15:26:07 -0800 Subject: [Xorp-users] Stuff In-Reply-To: Message from Calum of "Tue, 14 Mar 2006 21:59:10 GMT." <635498b70603141359n51c217e5q103e3854c3feb414@mail.gmail.com> Message-ID: <200603142326.k2ENQ717081588@possum.icir.org> > I have 3 points. > > 1. The fact that XORP falls over when an interface is actually removed > (actually stopping a process that creates the tun/tap interface) is a > biggie for me. Does this not affect anyone else? Yes, this is not the desired behavior. Please submit a bugzilla entry about it. > 2. Is it not possible that, if you try and add protocol pimsm4 int1 > vif int1, and you haven't declared int1 in the interface section that > it could automatically add that for you? Along with the mfea4, etc, > etc? The current model is that (most) entities need to be explicitly configured, because this is the behavior with least surprises. Indeed, some leaf nodes have default values, but we want to be very careful if we want to automatically add more complex configuration statements. For example, if we automatically add the MFEA interface/vifs, then someone may ask why not adding the interface/vif inside the "interfaces {}" section as well. Once we start going this path, then it becomes more difficult to preserve the configuration consistency. E.g., if the user deletes the interface/vif inside the pimsm4 statement, do we automatically delete the interface/vif inside the mfea4 statement as well? I am not saying that such optimizations should be forbidden. Eventually, you should be able to write your own xorpsh/rtrmgr extentions that would automatically fill-in extra stuff for you, but we are not there yet, so for the time being we prefer to keep things simpler. > 3. I'm trying to set up a multicast network in order to learn more > about PIM, but it's tricky. I can't seem to find anything about the > Mbone these days - did that disappear? Originally, Mbone was about running DVMRP over tunnels. This has gradually dissolved into running PIM-SM within domains and MSDP between domains (within the IPv4 context only). There might be some remaining DVMRP tunnels, but this won't help you much. You may want to try M6bone, the IPv6 multicast backbone, though obviously you would have to run IPv6: http://www.m6bone.net/ If you are using Linux, then you would have to patch your kernel (or use Usagi's kernel) to add IPv6 multicast routing support. See the following URL for details: http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2005-November/000901.html Pavlin > If it has, is there any sort of test network for joining up to? > If not, would anyone on here like to create one? Grab a BGP AS each, a > few openvpn/ipsec tunnels around the place, and an IRC channel, and we > could get one working pretty well, methinks. If you would, please get > in touch off-list. From pavlin@icir.org Wed Mar 15 02:20:13 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 14 Mar 2006 18:20:13 -0800 Subject: [Xorp-users] XORP config - why 127.127.0.1 In-Reply-To: Message from Kristian Larsson of "Tue, 14 Mar 2006 20:59:34 +0100." <20060314195933.GC138@juniks.net> Message-ID: <200603150220.k2F2KDS5010518@possum.icir.org> > > Because many FIBs deal purely in terms of IPv4 next-hops, sometimes it's > > necessary to just stuff something in there to keep it happy. You'll see this > > if you dip down deep into the murky depths of the rtsock code in the FEA. > > > > And 127.127.0.1 seemed less confusing (NTP is the only other application > > I know of which overloads the meaning of 127/8 address space in this way). > > > > This is probably more confusing than the original statement, but there you go! > Might one suggest using 192.0.2.1 in the examples > as this is somewhat of an industry standard for > blackhole destinations. I believe that 192.0.2.1 is the one typically used in documentation. According to RFC 3330 it belongs to 192.0.2.0/24 which is assigned as: 192.0.2.0/24 - This block is assigned as "TEST-NET" for use in documentation and example code. It is often used in conjunction with domain names example.com or example.net in vendor and protocol documentation. Addresses within this block should not appear on the public Internet. In any case, the 127.127.0.1 address in our sample configuration is now changed to 192.0.2.1. Thanks, Pavlin From kristian@juniks.net Wed Mar 15 02:50:25 2006 From: kristian@juniks.net (Kristian Larsson) Date: Wed, 15 Mar 2006 03:50:25 +0100 Subject: [Xorp-users] XORP config - why 127.127.0.1 In-Reply-To: <200603150220.k2F2KDS5010518@possum.icir.org> References: <20060314195933.GC138@juniks.net> <200603150220.k2F2KDS5010518@possum.icir.org> Message-ID: <20060315025024.GE138@juniks.net> On Tue, Mar 14, 2006 at 06:20:13PM -0800, Pavlin Radoslavov wrote: > > > > > Because many FIBs deal purely in terms of IPv4 next-hops, sometimes it's > > > necessary to just stuff something in there to keep it happy. You'll see this > > > if you dip down deep into the murky depths of the rtsock code in the FEA. > > > > > > And 127.127.0.1 seemed less confusing (NTP is the only other application > > > I know of which overloads the meaning of 127/8 address space in this way). > > > > > > This is probably more confusing than the original statement, but there you go! > > Might one suggest using 192.0.2.1 in the examples > > as this is somewhat of an industry standard for > > blackhole destinations. > > I believe that 192.0.2.1 is the one typically used in documentation. > According to RFC 3330 it belongs to 192.0.2.0/24 which is assigned > as: > > 192.0.2.0/24 - This block is assigned as "TEST-NET" for use in > documentation and example code. It is often used in conjunction with > domain names example.com or example.net in vendor and protocol > documentation. Addresses within this block should not appear on the > public Internet. Yes and it is well known that it's often used for blackholing, just do a search on google, you'll get hits like: "Changed the next-hop from 192.168.1.1/32 to 192.0.2.1/32 in keeping with best practices of the day." -- Team Cymru page or the bgp blackhole "howto" from SUNET. > In any case, the 127.127.0.1 address in our sample configuration is > now changed to 192.0.2.1. Great :) Kristian. From dave@vyatta.com Wed Mar 15 23:19:35 2006 From: dave@vyatta.com (Dave Roberts) Date: Wed, 15 Mar 2006 15:19:35 -0800 Subject: [Xorp-users] UNH-IOL Test Results Message-ID: <4418A107.5050901@vyatta.com> I posted this to the Vyatta mailing lists a few minutes ago, but figured the XORP community would be interested as well. Note that this version of the OFR incorporated a relatively recent version of XORP, just prior to the recent XORP 1.2. We believe that some of the tests listed as failing in this report now pass with the most recent versions of XORP OSPF. Also note that officially, UNH-IOL did *not* test XORP, but rather a specific version of Vyatta's code and therefore no statements can or should be made about XORP's test results, since those don't officially exist. In spite of this, this is good news for the larger XORP community. ------------------ A couple of weeks ago, Vyatta took a version of the OFR code to the University of New Hampshire's InterOperability Lab (UNH-IOL). The lab does testing of various routing protocols for interoperability and conformance to the relevant protocol RFCs. Vyatta is a member of the UNH-IOL and will be sending future releases to the lab for additional testing. In this round, we had UNH-IOL focus on the OSPF code. The full test report can be found here: http://www.vyatta.com/twiki/bin/view/Community/UnhTestResults While the code did not pass 100% of all tests, this is a great result. In conjunction with our sponsorship of the XORP project, Vyatta will be working to increase that pass rate over time. If you have any questions, please discuss on vyatta-users. -- Dave From riteshkvm@yahoo.co.in Fri Mar 17 06:10:13 2006 From: riteshkvm@yahoo.co.in (Ritesh Vanmali) Date: Thu, 16 Mar 2006 22:10:13 -0800 (PST) Subject: [Xorp-users] Physical Connections. Message-ID: <20060317061013.93402.qmail@web8813.mail.in.yahoo.com> Hi, I am Ritesh working for MNC in India and am keen to know how can I connect my 2003 Server with Intel Platform to my lease line modems as I am planning to use the Xorp software as a Fallback device to my Cisco Router. Hoping for prompt response. Thanks and Best Regards Ritesh Vanmali __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From riteshkvm@yahoo.co.in Fri Mar 17 06:26:16 2006 From: riteshkvm@yahoo.co.in (Ritesh Vanmali) Date: Thu, 16 Mar 2006 22:26:16 -0800 (PST) Subject: [Xorp-users] Fwd: Physical Connections. Message-ID: <20060317062616.71184.qmail@web8807.mail.in.yahoo.com> Hi, Can I incorporate Xorp product on one end with Cisco Router on other end by using Static Routes through P2P Lease Line. Regards Ritesh Vanmali --- Ritesh Vanmali wrote: > Date: Thu, 16 Mar 2006 22:10:13 -0800 (PST) > From: Ritesh Vanmali > Subject: Physical Connections. > To: xorp-users@xorp.org > > Hi, > I am Ritesh working for MNC in India and am keen to > know how can I connect my 2003 Server with Intel > Platform to my lease line modems as I am planning to > use the Xorp software as a Fallback device to my > Cisco > Router. > > Hoping for prompt response. > > Thanks and Best Regards > > Ritesh Vanmali > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam > protection around > http://mail.yahoo.com > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From bms@spc.org Fri Mar 17 14:42:12 2006 From: bms@spc.org (Bruce M Simpson) Date: Fri, 17 Mar 2006 14:42:12 +0000 Subject: [Xorp-users] Physical Connections. In-Reply-To: <20060317061013.93402.qmail@web8813.mail.in.yahoo.com> References: <20060317061013.93402.qmail@web8813.mail.in.yahoo.com> Message-ID: <20060317144212.GD37590@spc.org> On Thu, Mar 16, 2006 at 10:10:13PM -0800, Ritesh Vanmali wrote: > I am Ritesh working for MNC in India and am keen to > know how can I connect my 2003 Server with Intel > Platform to my lease line modems as I am planning to > use the Xorp software as a Fallback device to my Cisco > Router. The XORP/Win32 port can be considered rough beta quality. It is not yet recommended for production use. It has never been tested with NDISWAN devices (I assume your leased line is using serial devices of this kind) and it is not a Windows 'service', that is, you will need to run it in an interactive Windows session, although the Windows XORP component binaries themselves are Win32 console subsystem applications. Configuration is more or less identical to the UNIX version with the difference that the network interface names are actually the 'Friendly names' seen in the Network Connections folder. If you wish to try it, and post your feedback here, you are very welcome to do so, but please pay attention to the BUILD_NOTES document in the source tree which contains important information about the port. Regards, BMS From kristian@juniks.net Tue Mar 21 10:44:14 2006 From: kristian@juniks.net (Kristian Larsson) Date: Tue, 21 Mar 2006 11:44:14 +0100 Subject: [Xorp-users] traceoptions. Message-ID: <20060321104414.GE15464@juniks.net> Hi! While looking at Hassos patches I enabled the traceoptions flag for ospf4... right now it seems there is only one option, I assume this will be expanded upon in the future and additional flags will be added, right? Is it possible to direct the output of a specific trace to a file? And would it be possible to add milliseconds to the log file? When debugging SPF calculations it's really nice to be able to the the exact time something was performed. Regards, Kristian From pavlin@icir.org Tue Mar 21 20:24:19 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 21 Mar 2006 12:24:19 -0800 Subject: [Xorp-users] traceoptions. In-Reply-To: Message from Kristian Larsson of "Tue, 21 Mar 2006 11:44:14 +0100." <20060321104414.GE15464@juniks.net> Message-ID: <200603212024.k2LKOJYo058316@possum.icir.org> > Hi! > > While looking at Hassos patches I enabled the > traceoptions flag for ospf4... > right now it seems there is only one option, I > assume this will be expanded upon in the future > and additional flags will be added, right? Yes. I believe the OSPF implementation supports internally a number of flags (see ospf/trace.hh), but currently only "all" is exported via the XRL/xorpsh interface. > Is it possible to direct the output of a specific > trace to a file? Not at this time, but eventually we should be able to do something like this in the future. For the time being you could redirect all output to a file and then use "grep" and friends to filter the output you want. > And would it be possible to add milliseconds to > the log file? When debugging SPF calculations it's > really nice to be able to the the exact time > something was performed. Currently the default behavior in the log output is not to print anything smaller than a second, because typically you don't need this information and it will unnecessary make the log output more difficult to read. As a quick solution, you could replace the xlog_localtime2string_short() calls inside libxorp/xlog.c (lines 603, 611, 621 for xlog.c rev. 1.18) with xlog_localtime2string() which should print the microseconds as well. Probably this replacement should be permanent for the XLOG_VERBOSE_HIGH case, but this should happen after XLOG_VERBOSE_LOW or XLOG_VERBOSE_MEDIUM replaces XLOG_VERBOSE_HIGH as the default verbosity level for all XORP processes. Pavlin From kristian@juniks.net Tue Mar 21 20:39:28 2006 From: kristian@juniks.net (Kristian Larsson) Date: Tue, 21 Mar 2006 21:39:28 +0100 Subject: [Xorp-users] traceoptions. In-Reply-To: <200603212024.k2LKOJYo058316@possum.icir.org> References: <20060321104414.GE15464@juniks.net> <200603212024.k2LKOJYo058316@possum.icir.org> Message-ID: <20060321203927.GA2000@juniks.net> On Tue, Mar 21, 2006 at 12:24:19PM -0800, Pavlin Radoslavov wrote: > > Hi! > > > > While looking at Hassos patches I enabled the > > traceoptions flag for ospf4... > > right now it seems there is only one option, I > > assume this will be expanded upon in the future > > and additional flags will be added, right? > > Yes. I believe the OSPF implementation supports internally a number > of flags (see ospf/trace.hh), but currently only "all" is exported > via the XRL/xorpsh interface. Ahh, should be quite an easy fix then. > > Is it possible to direct the output of a specific > > trace to a file? > > Not at this time, but eventually we should be able to do something > like this in the future. > For the time being you could redirect all output to a file and then > use "grep" and friends to filter the output you want. Yupp, already doing that :) > > And would it be possible to add milliseconds to > > the log file? When debugging SPF calculations it's > > really nice to be able to the the exact time > > something was performed. > > Currently the default behavior in the log output is not to print > anything smaller than a second, because typically you don't need > this information and it will unnecessary make the log output more > difficult to read. Perhaps an option similar to Ciscos service timestamp log for changing this, but I too realize this is not very high priority. > > As a quick solution, you could replace the > xlog_localtime2string_short() calls inside libxorp/xlog.c (lines > 603, 611, 621 for xlog.c rev. 1.18) with xlog_localtime2string() > which should print the microseconds as well. Thanks. > > Probably this replacement should be permanent for the > XLOG_VERBOSE_HIGH case, but this should happen after > XLOG_VERBOSE_LOW or XLOG_VERBOSE_MEDIUM replaces XLOG_VERBOSE_HIGH > as the default verbosity level for all XORP processes. Kristian. From Chris.Robson@nrl.navy.mil Thu Mar 23 17:25:57 2006 From: Chris.Robson@nrl.navy.mil (Chris Robson NRL) Date: Thu, 23 Mar 2006 12:25:57 -0500 Subject: [Xorp-users] click???? Message-ID: <6.2.1.2.2.20060323122423.02316ca8@ginger.cmf.nrl.navy.mil> What is click and how important is it? The config.boot.sample has it and causes the program to fail. Thanks...chris From mhorn@vyatta.com Thu Mar 23 17:37:27 2006 From: mhorn@vyatta.com (Mike Horn) Date: Thu, 23 Mar 2006 09:37:27 -0800 (PST) Subject: [Xorp-users] click???? Message-ID: <15597991.9691143135447169.JavaMail.root@mail.vyatta.com> Hi Chris, Click is routing/forwarding software that is a project at MIT: http://pdos.csail.mit.edu/click/ XORP can run on top of Click, or run on top of a standard kernel (using the FEA to interact with the kernel forwarding). This sounds like the configuration you are using, so you do not need Click and you can remove the references to it from your config.boot. -mike ----- Original Message ----- From: Chris Robson NRL To: xorp-users@xorp.org Sent: Thursday, March 23, 2006 10:25:57 AM GMT-0700 Subject: [Xorp-users] click???? What is click and how important is it? The config.boot.sample has it and causes the program to fail. Thanks...chris _______________________________________________ Xorp-users mailing list Xorp-users@xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From mark.winter@clearwire.com Fri Mar 24 18:13:46 2006 From: mark.winter@clearwire.com (Mark Winter) Date: Fri, 24 Mar 2006 10:13:46 -0800 Subject: [Xorp-users] bouncing interface kills OSPF - known behavior? Message-ID: <442436DA.90809@clearwire.com> Is there a way to HUP the OSPF process when an interface that is defined in OSPF toggles between up/down? Once this happens I have to restart the XORP process and then the neighbor will go back into the 'full' state. Currently running xorp 1.2. So with the config below tun5 goes down for about 30 seconds and then when it's brought back up is when I have the problem. root@marklaptop.localdomain> show ospf4 neighbor Address Interface State ID Pri Dead 172.25.3.1 tun5/tun5 Down 11.10.10.10 0 0 -------config file------------ interfaces { interface tun5 { default-system-config description: "Openvpn-test-interface" } interface "eth0.100" { default-system-config { } description: "Test interface" } } fea { unicast-forwarding4 { } } policy { policy-statement connected { term export { from { protocol: "connected" } } } policy-statement static { term export { from { protocol: "static" } } } } protocols { ospf4 { router-id: 10.10.10.10 area 0.0.0.0 { interface "eth0.100" { vif "eth0.100" { address 1.1.1.1 { passive: true } } } interface tun5 { vif tun5 { address 172.25.3.4 { authentication { md5 1 { password: "id10t" } } } } } } traceoptions { flag { all { } } } } } ---- LOG FILE------- [ 2006/03/24 10:00:27 INFO xorp_rtrmgr:28544 RTRMGR +240 master_conf_tree.cc execute ] Changed modules: interfaces, fea, rib, policy, ospf4 [ 2006/03/24 10:00:27 INFO xorp_rtrmgr:28544 RTRMGR +99 module_manager.cc execute ] Executing module: interfaces (fea/xorp_fea) [ 2006/03/24 10:00:28 INFO xorp_fea MFEA ] MFEA enabled [ 2006/03/24 10:00:28 INFO xorp_fea MFEA ] CLI enabled [ 2006/03/24 10:00:28 INFO xorp_fea MFEA ] CLI started [ 2006/03/24 10:00:28 INFO xorp_fea MFEA ] MFEA enabled [ 2006/03/24 10:00:28 INFO xorp_fea MFEA ] CLI enabled [ 2006/03/24 10:00:28 INFO xorp_fea MFEA ] CLI started [ 2006/03/24 10:00:29 INFO xorp_rtrmgr:28544 RTRMGR +99 module_manager.cc execute ] Executing module: fea (fea/xorp_fea) [ 2006/03/24 10:00:35 INFO xorp_rtrmgr:28544 RTRMGR +99 module_manager.cc execute ] Executing module: rib (rib/xorp_rib) [ 2006/03/24 10:00:37 INFO xorp_rtrmgr:28544 RTRMGR +99 module_manager.cc execute ] Executing module: policy (policy/xorp_policy) [ 2006/03/24 10:00:39 INFO xorp_rtrmgr:28544 RTRMGR +99 module_manager.cc execute ] Executing module: ospf4 (ospf/xorp_ospfv2) [ 2006/03/24 10:00:41 TRACE xorp_ospfv2 OSPF ] Event(LoopInd) Interface(eth0.100/eth0.100) State(Down) [ 2006/03/24 10:00:41 TRACE xorp_ospfv2 OSPF ] Event(InterfaceUp) Interface(tun5/tun5) State(Down) [ 2006/03/24 10:00:41 INFO xorp_rtrmgr:28544 RTRMGR +2228 task.cc run_task ] No more tasks to run [ 2006/03/24 10:00:42 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(tun5/tun5) Neighbour(172.25.3.1) State(Init) [ 2006/03/24 10:00:42 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(tun5/tun5) Neighbour(172.25.3.1) State(Init) [ 2006/03/24 10:00:42 TRACE xorp_ospfv2 OSPF ] Event(BackupSeen) Interface(tun5/tun5) State(Waiting) [ 2006/03/24 10:00:42 TRACE xorp_ospfv2 OSPF ] Event(AdjOK?) Interface(tun5/tun5) Neighbour(172.25.3.1) State(TwoWay) [ 2006/03/24 10:00:51 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(tun5/tun5) Neighbour(172.25.3.1) State(ExStart) [ 2006/03/24 10:00:51 TRACE xorp_ospfv2 OSPF ] Event(NegotiationDone) Interface(tun5/tun5) Neighbour(172.25.3.1) State(ExStart) [ 2006/03/24 10:00:51 TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pseudo-event) Interface(tun5/tun5) Neighbour(172.25.3.1) State(Exchange) [ 2006/03/24 10:00:51 TRACE xorp_ospfv2 OSPF ] Event(ExchangeDone) Interface(tun5/tun5) Neighbour(172.25.3.1) State(Exchange) [ 2006/03/24 10:00:52 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(tun5/tun5) Neighbour(172.25.3.1) State(Loading) [ 2006/03/24 10:00:52 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(tun5/tun5) Neighbour(172.25.3.1) State(Loading) [ 2006/03/24 10:00:52 TRACE xorp_ospfv2 OSPF ] Event(NeighborChange) Interface(tun5/tun5) State(Backup) [ 2006/03/24 10:00:56 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(tun5/tun5) Neighbour(172.25.3.1) State(Loading) [ 2006/03/24 10:00:56 TRACE xorp_ospfv2 OSPF ] Event(LoadingDone) Interface(tun5/tun5) Neighbour(172.25.3.1) State(Loading) [ 2006/03/24 10:00:56 TRACE xorp_ospfv2 OSPF ] Event(LinkStateRequestReceived-pseudo-event) Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) [ 2006/03/24 10:00:56 TRACE xorp_ospfv2 OSPF ] Event(LinkStateAcknowledgementReceived-pseudo-event) Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) [ 2006/03/24 10:00:56 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) [ 2006/03/24 10:00:56 TRACE xorp_ospfv2 OSPF ] Event(LinkStateAcknowledgementReceived-pseudo-event) Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) [ 2006/03/24 10:00:56 TRACE xorp_ospfv2 OSPF ] Ack for LSA not in retransmission list. LS age 1 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link State ID 10.10.10.10 Advertising Router 10.10.10.10 LS sequence number 0x80000001 LS checksum 0x1246 length 48 Link State Acknowledgement Packet: Version 2 Type 5 Router ID 11.10.10.10 Area ID 0.0.0.0 Auth Type 2 LS age 1 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link State ID 10.10.10.10 Advertising Router 10.10.10.10 LS sequence number 0x80000001 LS checksum 0x1246 length 48 [ 2006/03/24 10:00:57 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router 11.10.10.10(0xb0a0a0a) 0.0.0.0(0) not reachable [ 2006/03/24 10:00:57 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 172.25.3.255(0xac1903ff) 0.0.0.0(0) not reachable [ 2006/03/24 10:00:57 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 172.25.100.10(0xac19640a) 0.0.0.0(0) not reachable [ 2006/03/24 10:00:57 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router 255.255.255.255(0xffffffff) 0.0.0.0(0) not reachable [ 2006/03/24 10:01:01 TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pseudo-event) Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) [ 2006/03/24 10:01:02 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) [ 2006/03/24 10:01:02 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) [ 2006/03/24 10:01:02 TRACE xorp_ospfv2 OSPF ] Checking for virtual links Router-LSA: LS age 1 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link State ID 11.10.10.10 Advertising Router 11.10.10.10 LS sequence number 0x80000005 LS checksum 0xb346 length 48 Nt-bit false V-bit false E-bit false B-bit false Type 2 Transit network IP address of Designated router 172.25.100.10 Routers interface address 172.25.100.1 Metric 1 Type 2 Transit network IP address of Designated router 172.25.3.1 Routers interface address 172.25.3.1 Metric 1 [ 2006/03/24 10:01:02 TRACE xorp_ospfv2 OSPF ] Checking for virtual links Router-LSA: LS age 1505 Options 0x22 DC: 1 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link State ID 255.255.255.255 Advertising Router 255.255.255.255 LS sequence number 0x80000816 LS checksum 0x5558 length 36 Nt-bit false V-bit false E-bit false B-bit false Type 2 Transit network IP address of Designated router 172.25.100.10 Routers interface address 172.25.100.10 Metric 1 [ 2006/03/24 10:01:02 TRACE xorp_ospfv2 OSPF ] [OSPF] Running filter: Import on route: 172.25.100.0/24 [ 2006/03/24 10:01:02 TRACE xorp_ospfv2 OSPF ] [OSPF] Running filter: Export-SourceMatch on route: 172.25.100.0/24 [ 2006/03/24 10:01:02 TRACE xorp_ospfv2 OSPF ] Add route Net 172.25.100.0/24 Nexthop 172.25.3.1 metric 2 equal false discard false policy [ 2006/03/24 10:01:12 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) [ 2006/03/24 10:01:12 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) [ 2006/03/24 10:01:21 WARNING xorp_fea XrlFeaTarget ] Handling method for raw_packet4/0.1/send failed: XrlCmdError 102 Command failed setsockopt(IP_MULTICAST_IF, 172.25.3.4) failed: Cannot assign requested address [ 2006/03/24 10:01:21 ERROR xorp_ospfv2:28549 OSPF +181 xrl_io.cc send_cb ] Cannot send a packet on interface tun5 vif tun5: 102 Command failed setsockopt(IP_MULTICAST_IF, 172.25.3.4) failed: Cannot assign requested address [ 2006/03/24 10:01:52 TRACE xorp_ospfv2 OSPF ] Event(InactivityTimer) Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) [ 2006/03/24 10:01:52 TRACE xorp_ospfv2 OSPF ] Event(NeighborChange) Interface(tun5/tun5) State(Backup) [ 2006/03/24 10:01:53 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router 11.10.10.10(0xb0a0a0a) 0.0.0.0(0) not reachable [ 2006/03/24 10:01:53 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 172.25.3.1(0xac190301) 0.0.0.0(0) not reachable [ 2006/03/24 10:01:53 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network 172.25.100.10(0xac19640a) 0.0.0.0(0) not reachable [ 2006/03/24 10:01:53 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router 255.255.255.255(0xffffffff) 0.0.0.0(0) not reachable [ 2006/03/24 10:01:53 TRACE xorp_ospfv2 OSPF ] Delete route Net 172.25.100.0/24 [ 2006/03/24 10:01:53 ERROR xorp_fea:28545 FEA +503 fticonfig_entry_set_netlink.cc delete_entry ] Error checking netlink request: AF_NETLINK NLMSG_ERROR message: No such process [ 2006/03/24 10:01:53 ERROR xorp_fea:28545 FEA +71 fti_transaction.cc operation_result ] FTI transaction commit failed on DeleteEntry4: net = 172.25.100.0/24 nexthop = 0.0.0.0 ifname = vifname = metric = 0 admin_distance = 0 xorp_route = false is_deleted = false is_unresolved = false is_connected_route = false [ 2006/03/24 10:01:53 WARNING xorp_fea XrlFeaTarget ] Handling method for redist_transaction4/0.1/commit_transaction failed: XrlCmdError 102 Command failed DeleteEntry4: net = 172.25.100.0/24 nexthop = 0.0.0.0 ifname = vifname = metric = 0 admin_distance = 0 xorp_route = false is_deleted = false is_unresolved = false is_connected_route = false [ 2006/03/24 10:01:53 ERROR xorp_rib:28547 RIB +914 redist_xrl.cc dispatch_complete ] Failed to commit transaction: 102 Command failed DeleteEntry4: net = 172.25.100.0/24 nexthop = 0.0.0.0 ifname = vifname = metric = 0 admin_distance = 0 xorp_route = false is_deleted = false is_unresolved = false is_connected_route = false From pavlin@icir.org Fri Mar 24 23:28:59 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 24 Mar 2006 15:28:59 -0800 Subject: [Xorp-users] bouncing interface kills OSPF - known behavior? In-Reply-To: Message from Mark Winter of "Fri, 24 Mar 2006 10:13:46 PST." <442436DA.90809@clearwire.com> Message-ID: <200603242328.k2ONSxLb052330@possum.icir.org> > Is there a way to HUP the OSPF process when an interface that is defined > in OSPF toggles between up/down? Once this happens I have to restart > the XORP process and then the neighbor will go back into the 'full' > state. Currently running xorp 1.2. > > So with the config below tun5 goes down for about 30 seconds and then > when it's brought back up is when I have the problem. In general, have in mind that tunnels and VPNs are not supported (yet). It happens that tunnels are working (if configured before starting XORP), but so far we haven't got around to provide complete support for them. Hence, for the time being you may have to use some work-arounds if a tunnel is removed while XORP is running, etc. Could you provide the exact instuctions/commands about what you are doing. We tried to replicate the problem, but the messages we were seeing were different (e.g., we didn't see the "setsockopt(IP_MULTICAST_IF)" warnings). We saw some issues with bringing the tunnel down and up (by either using "ifconfig tun0 down/up" or just by killing and restarting the openvpn program), but we want to verify whether we are seeing same problem or something else before suggesting any possible work-around. Pavlin > root@marklaptop.localdomain> show ospf4 neighbor > Address Interface State ID Pri Dead > 172.25.3.1 tun5/tun5 Down 11.10.10.10 0 0 > > -------config file------------ > interfaces { > interface tun5 { > default-system-config > description: "Openvpn-test-interface" > } > interface "eth0.100" { > default-system-config { > } > description: "Test interface" > } > } > fea { > unicast-forwarding4 { > } > } > policy { > policy-statement connected { > term export { > from { > protocol: "connected" > } > } > } > policy-statement static { > term export { > from { > protocol: "static" > } > } > } > } > protocols { > ospf4 { > router-id: 10.10.10.10 > area 0.0.0.0 { > interface "eth0.100" { > vif "eth0.100" { > address 1.1.1.1 { > passive: true > } > } > } > interface tun5 { > vif tun5 { > address 172.25.3.4 { > authentication { > md5 1 { > password: "id10t" > } > } > } > } > } > } > traceoptions { > flag { > all { > } > } > } > } > } > > ---- LOG FILE------- > [ 2006/03/24 10:00:27 INFO xorp_rtrmgr:28544 RTRMGR +240 > master_conf_tree.cc execute ] Changed modules: interfaces, fea, rib, > policy, ospf4 > [ 2006/03/24 10:00:27 INFO xorp_rtrmgr:28544 RTRMGR +99 > module_manager.cc execute ] Executing module: interfaces (fea/xorp_fea) > [ 2006/03/24 10:00:28 INFO xorp_fea MFEA ] MFEA enabled > [ 2006/03/24 10:00:28 INFO xorp_fea MFEA ] CLI enabled > [ 2006/03/24 10:00:28 INFO xorp_fea MFEA ] CLI started > [ 2006/03/24 10:00:28 INFO xorp_fea MFEA ] MFEA enabled > [ 2006/03/24 10:00:28 INFO xorp_fea MFEA ] CLI enabled > [ 2006/03/24 10:00:28 INFO xorp_fea MFEA ] CLI started > [ 2006/03/24 10:00:29 INFO xorp_rtrmgr:28544 RTRMGR +99 > module_manager.cc execute ] Executing module: fea (fea/xorp_fea) > [ 2006/03/24 10:00:35 INFO xorp_rtrmgr:28544 RTRMGR +99 > module_manager.cc execute ] Executing module: rib (rib/xorp_rib) > [ 2006/03/24 10:00:37 INFO xorp_rtrmgr:28544 RTRMGR +99 > module_manager.cc execute ] Executing module: policy (policy/xorp_policy) > [ 2006/03/24 10:00:39 INFO xorp_rtrmgr:28544 RTRMGR +99 > module_manager.cc execute ] Executing module: ospf4 (ospf/xorp_ospfv2) > [ 2006/03/24 10:00:41 TRACE xorp_ospfv2 OSPF ] Event(LoopInd) > Interface(eth0.100/eth0.100) State(Down) > [ 2006/03/24 10:00:41 TRACE xorp_ospfv2 OSPF ] Event(InterfaceUp) > Interface(tun5/tun5) State(Down) > [ 2006/03/24 10:00:41 INFO xorp_rtrmgr:28544 RTRMGR +2228 task.cc > run_task ] No more tasks to run > [ 2006/03/24 10:00:42 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) > Interface(tun5/tun5) Neighbour(172.25.3.1) State(Init) > [ 2006/03/24 10:00:42 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) > Interface(tun5/tun5) Neighbour(172.25.3.1) State(Init) > [ 2006/03/24 10:00:42 TRACE xorp_ospfv2 OSPF ] Event(BackupSeen) > Interface(tun5/tun5) State(Waiting) > [ 2006/03/24 10:00:42 TRACE xorp_ospfv2 OSPF ] Event(AdjOK?) > Interface(tun5/tun5) Neighbour(172.25.3.1) State(TwoWay) > [ 2006/03/24 10:00:51 TRACE xorp_ospfv2 OSPF ] > Event(DataDescriptionReceived-pseudo-event) Interface(tun5/tun5) > Neighbour(172.25.3.1) State(ExStart) > [ 2006/03/24 10:00:51 TRACE xorp_ospfv2 OSPF ] Event(NegotiationDone) > Interface(tun5/tun5) Neighbour(172.25.3.1) State(ExStart) > [ 2006/03/24 10:00:51 TRACE xorp_ospfv2 OSPF ] > Event(DataDescriptionReceived-pseudo-event) Interface(tun5/tun5) > Neighbour(172.25.3.1) State(Exchange) > [ 2006/03/24 10:00:51 TRACE xorp_ospfv2 OSPF ] Event(ExchangeDone) > Interface(tun5/tun5) Neighbour(172.25.3.1) State(Exchange) > [ 2006/03/24 10:00:52 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) > Interface(tun5/tun5) Neighbour(172.25.3.1) State(Loading) > [ 2006/03/24 10:00:52 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) > Interface(tun5/tun5) Neighbour(172.25.3.1) State(Loading) > [ 2006/03/24 10:00:52 TRACE xorp_ospfv2 OSPF ] Event(NeighborChange) > Interface(tun5/tun5) State(Backup) > [ 2006/03/24 10:00:56 TRACE xorp_ospfv2 OSPF ] > Event(LinkStateUpdateReceived-pseudo-event) Interface(tun5/tun5) > Neighbour(172.25.3.1) State(Loading) > [ 2006/03/24 10:00:56 TRACE xorp_ospfv2 OSPF ] Event(LoadingDone) > Interface(tun5/tun5) Neighbour(172.25.3.1) State(Loading) > [ 2006/03/24 10:00:56 TRACE xorp_ospfv2 OSPF ] > Event(LinkStateRequestReceived-pseudo-event) Interface(tun5/tun5) > Neighbour(172.25.3.1) State(Full) > [ 2006/03/24 10:00:56 TRACE xorp_ospfv2 OSPF ] > Event(LinkStateAcknowledgementReceived-pseudo-event) > Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) > [ 2006/03/24 10:00:56 TRACE xorp_ospfv2 OSPF ] > Event(LinkStateUpdateReceived-pseudo-event) Interface(tun5/tun5) > Neighbour(172.25.3.1) State(Full) > [ 2006/03/24 10:00:56 TRACE xorp_ospfv2 OSPF ] > Event(LinkStateAcknowledgementReceived-pseudo-event) > Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) > [ 2006/03/24 10:00:56 TRACE xorp_ospfv2 OSPF ] Ack for LSA not in > retransmission list. > LS age 1 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link > State ID 10.10.10.10 Advertising Router 10.10.10.10 LS sequence number > 0x80000001 LS checksum 0x1246 length 48 > Link State Acknowledgement Packet: > Version 2 > Type 5 > Router ID 11.10.10.10 > Area ID 0.0.0.0 > Auth Type 2 > > LS age 1 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type > 0x1 Link State ID 10.10.10.10 Advertising Router 10.10.10.10 LS sequence > number 0x80000001 LS checksum 0x1246 length 48 > [ 2006/03/24 10:00:57 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router > 11.10.10.10(0xb0a0a0a) 0.0.0.0(0) not reachable > [ 2006/03/24 10:00:57 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network > 172.25.3.255(0xac1903ff) 0.0.0.0(0) not reachable > [ 2006/03/24 10:00:57 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network > 172.25.100.10(0xac19640a) 0.0.0.0(0) not reachable > [ 2006/03/24 10:00:57 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router > 255.255.255.255(0xffffffff) 0.0.0.0(0) not reachable > [ 2006/03/24 10:01:01 TRACE xorp_ospfv2 OSPF ] > Event(LinkStateUpdateReceived-pseudo-event) Interface(tun5/tun5) > Neighbour(172.25.3.1) State(Full) > [ 2006/03/24 10:01:02 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) > Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) > [ 2006/03/24 10:01:02 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) > Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) > [ 2006/03/24 10:01:02 TRACE xorp_ospfv2 OSPF ] Checking for virtual > links Router-LSA: > LS age 1 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link > State ID 11.10.10.10 Advertising Router 11.10.10.10 LS sequence number > 0x80000005 LS checksum 0xb346 length 48 > Nt-bit false > V-bit false > E-bit false > B-bit false > Type 2 Transit network IP address of Designated router > 172.25.100.10 Routers interface address 172.25.100.1 Metric 1 > Type 2 Transit network IP address of Designated router > 172.25.3.1 Routers interface address 172.25.3.1 Metric 1 > [ 2006/03/24 10:01:02 TRACE xorp_ospfv2 OSPF ] Checking for virtual > links Router-LSA: > LS age 1505 Options 0x22 DC: 1 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link > State ID 255.255.255.255 Advertising Router 255.255.255.255 LS sequence > number 0x80000816 LS checksum 0x5558 length 36 > Nt-bit false > V-bit false > E-bit false > B-bit false > Type 2 Transit network IP address of Designated router > 172.25.100.10 Routers interface address 172.25.100.10 Metric 1 > [ 2006/03/24 10:01:02 TRACE xorp_ospfv2 OSPF ] [OSPF] Running filter: > Import on route: 172.25.100.0/24 > [ 2006/03/24 10:01:02 TRACE xorp_ospfv2 OSPF ] [OSPF] Running filter: > Export-SourceMatch on route: 172.25.100.0/24 > [ 2006/03/24 10:01:02 TRACE xorp_ospfv2 OSPF ] Add route Net > 172.25.100.0/24 Nexthop 172.25.3.1 metric 2 equal false discard false policy > [ 2006/03/24 10:01:12 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) > Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) > [ 2006/03/24 10:01:12 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) > Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) > [ 2006/03/24 10:01:21 WARNING xorp_fea XrlFeaTarget ] Handling method > for raw_packet4/0.1/send failed: XrlCmdError 102 Command failed > setsockopt(IP_MULTICAST_IF, 172.25.3.4) failed: Cannot assign requested > address > [ 2006/03/24 10:01:21 ERROR xorp_ospfv2:28549 OSPF +181 xrl_io.cc > send_cb ] Cannot send a packet on interface tun5 vif tun5: 102 Command > failed setsockopt(IP_MULTICAST_IF, 172.25.3.4) failed: Cannot assign > requested address > [ 2006/03/24 10:01:52 TRACE xorp_ospfv2 OSPF ] Event(InactivityTimer) > Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) > [ 2006/03/24 10:01:52 TRACE xorp_ospfv2 OSPF ] Event(NeighborChange) > Interface(tun5/tun5) State(Backup) > [ 2006/03/24 10:01:53 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router > 11.10.10.10(0xb0a0a0a) 0.0.0.0(0) not reachable > [ 2006/03/24 10:01:53 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network > 172.25.3.1(0xac190301) 0.0.0.0(0) not reachable > [ 2006/03/24 10:01:53 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network > 172.25.100.10(0xac19640a) 0.0.0.0(0) not reachable > [ 2006/03/24 10:01:53 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router > 255.255.255.255(0xffffffff) 0.0.0.0(0) not reachable > [ 2006/03/24 10:01:53 TRACE xorp_ospfv2 OSPF ] Delete route Net > 172.25.100.0/24 > [ 2006/03/24 10:01:53 ERROR xorp_fea:28545 FEA +503 > fticonfig_entry_set_netlink.cc delete_entry ] Error checking netlink > request: AF_NETLINK NLMSG_ERROR message: No such process > [ 2006/03/24 10:01:53 ERROR xorp_fea:28545 FEA +71 fti_transaction.cc > operation_result ] FTI transaction commit failed on DeleteEntry4: net = > 172.25.100.0/24 nexthop = 0.0.0.0 ifname = vifname = metric = 0 > admin_distance = 0 xorp_route = false is_deleted = false is_unresolved = > false is_connected_route = false > [ 2006/03/24 10:01:53 WARNING xorp_fea XrlFeaTarget ] Handling method > for redist_transaction4/0.1/commit_transaction failed: XrlCmdError 102 > Command failed DeleteEntry4: net = 172.25.100.0/24 nexthop = 0.0.0.0 > ifname = vifname = metric = 0 admin_distance = 0 xorp_route = false > is_deleted = false is_unresolved = false is_connected_route = false > [ 2006/03/24 10:01:53 ERROR xorp_rib:28547 RIB +914 redist_xrl.cc > dispatch_complete ] Failed to commit transaction: 102 Command failed > DeleteEntry4: net = 172.25.100.0/24 nexthop = 0.0.0.0 ifname = vifname > = metric = 0 admin_distance = 0 xorp_route = false is_deleted = false > is_unresolved = false is_connected_route = false > > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From mark.winter@clearwire.com Sat Mar 25 00:56:33 2006 From: mark.winter@clearwire.com (Mark Winter) Date: Fri, 24 Mar 2006 16:56:33 -0800 Subject: [Xorp-users] bouncing interface kills OSPF - known behavior? In-Reply-To: <200603242328.k2ONSxLb052330@possum.icir.org> References: <200603242328.k2ONSxLb052330@possum.icir.org> Message-ID: <44249541.3060306@clearwire.com> Ok as a workaround what I've done is setup Openvpn to restart XORP when the tunnel is restarted. I am running openvpn 2.1 beta 11 which added the topology feature, that may be the difference in messages. The logs and config were from the client side, started with command: openvpn --config client.conf After it's connected and OSPF has established adjacency, I control C openvpn and then restart it again. --------- client.conf--------------- client up "/etc/init.d/xorp restart" dev tun5 proto udp remote xxx.xxx.xxx.xxx 3194 resolv-retry infinite nobind user nobody group nobody persist-key persist-tun mute-replay-warnings ca keys/ca.crt cert keys/client-new.crt key keys/client-new.key tls-auth keys/ta.key 1 cipher AES-256-CBC comp-lzo verb 3 ping 15 ping-restart 45 ping-timer-rem ------------------------------------- -----server.conf---------------- tls-server local xxx.xxx.xxx.xxx port 3194 proto udp dev tun5 client-config-dir /etc/openvpn-poptest/ccd ca keys/ca.crt cert keys/myserver.crt key keys/myserver.key dh keys/dh2048.pem crl-verify keys/crl.pem # Configure server mode and supply a VPN subnet topology subnet mode server server 172.25.3.0 255.255.255.0 ifconfig-pool-persist ipp.txt client-to-client ping 15 ping-restart 45 ping-timer-rem tls-auth keys/ta.key 0 cipher AES-256-CBC comp-lzo user nobody group nobody persist-key persist-tun status openvpn-status.log verb 3 mute 20 Thanks, Mark Pavlin Radoslavov wrote: >> Is there a way to HUP the OSPF process when an interface that is defined >> in OSPF toggles between up/down? Once this happens I have to restart >> the XORP process and then the neighbor will go back into the 'full' >> state. Currently running xorp 1.2. >> >> So with the config below tun5 goes down for about 30 seconds and then >> when it's brought back up is when I have the problem. >> > > In general, have in mind that tunnels and VPNs are not supported > (yet). It happens that tunnels are working (if configured before > starting XORP), but so far we haven't got around to provide complete > support for them. Hence, for the time being you may have to use some > work-arounds if a tunnel is removed while XORP is running, etc. > > Could you provide the exact instuctions/commands about what you are > doing. We tried to replicate the problem, but the messages we were > seeing were different (e.g., we didn't see the > "setsockopt(IP_MULTICAST_IF)" warnings). > > We saw some issues with bringing the tunnel down and up (by either > using "ifconfig tun0 down/up" or just by killing and restarting the > openvpn program), but we want to verify whether we are seeing same > problem or something else before suggesting any possible > work-around. > > Pavlin > > >> root@marklaptop.localdomain> show ospf4 neighbor >> Address Interface State ID Pri Dead >> 172.25.3.1 tun5/tun5 Down 11.10.10.10 0 0 >> >> -------config file------------ >> interfaces { >> interface tun5 { >> default-system-config >> description: "Openvpn-test-interface" >> } >> interface "eth0.100" { >> default-system-config { >> } >> description: "Test interface" >> } >> } >> fea { >> unicast-forwarding4 { >> } >> } >> policy { >> policy-statement connected { >> term export { >> from { >> protocol: "connected" >> } >> } >> } >> policy-statement static { >> term export { >> from { >> protocol: "static" >> } >> } >> } >> } >> protocols { >> ospf4 { >> router-id: 10.10.10.10 >> area 0.0.0.0 { >> interface "eth0.100" { >> vif "eth0.100" { >> address 1.1.1.1 { >> passive: true >> } >> } >> } >> interface tun5 { >> vif tun5 { >> address 172.25.3.4 { >> authentication { >> md5 1 { >> password: "id10t" >> } >> } >> } >> } >> } >> } >> traceoptions { >> flag { >> all { >> } >> } >> } >> } >> } >> >> ---- LOG FILE------- >> [ 2006/03/24 10:00:27 INFO xorp_rtrmgr:28544 RTRMGR +240 >> master_conf_tree.cc execute ] Changed modules: interfaces, fea, rib, >> policy, ospf4 >> [ 2006/03/24 10:00:27 INFO xorp_rtrmgr:28544 RTRMGR +99 >> module_manager.cc execute ] Executing module: interfaces (fea/xorp_fea) >> [ 2006/03/24 10:00:28 INFO xorp_fea MFEA ] MFEA enabled >> [ 2006/03/24 10:00:28 INFO xorp_fea MFEA ] CLI enabled >> [ 2006/03/24 10:00:28 INFO xorp_fea MFEA ] CLI started >> [ 2006/03/24 10:00:28 INFO xorp_fea MFEA ] MFEA enabled >> [ 2006/03/24 10:00:28 INFO xorp_fea MFEA ] CLI enabled >> [ 2006/03/24 10:00:28 INFO xorp_fea MFEA ] CLI started >> [ 2006/03/24 10:00:29 INFO xorp_rtrmgr:28544 RTRMGR +99 >> module_manager.cc execute ] Executing module: fea (fea/xorp_fea) >> [ 2006/03/24 10:00:35 INFO xorp_rtrmgr:28544 RTRMGR +99 >> module_manager.cc execute ] Executing module: rib (rib/xorp_rib) >> [ 2006/03/24 10:00:37 INFO xorp_rtrmgr:28544 RTRMGR +99 >> module_manager.cc execute ] Executing module: policy (policy/xorp_policy) >> [ 2006/03/24 10:00:39 INFO xorp_rtrmgr:28544 RTRMGR +99 >> module_manager.cc execute ] Executing module: ospf4 (ospf/xorp_ospfv2) >> [ 2006/03/24 10:00:41 TRACE xorp_ospfv2 OSPF ] Event(LoopInd) >> Interface(eth0.100/eth0.100) State(Down) >> [ 2006/03/24 10:00:41 TRACE xorp_ospfv2 OSPF ] Event(InterfaceUp) >> Interface(tun5/tun5) State(Down) >> [ 2006/03/24 10:00:41 INFO xorp_rtrmgr:28544 RTRMGR +2228 task.cc >> run_task ] No more tasks to run >> [ 2006/03/24 10:00:42 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) >> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Init) >> [ 2006/03/24 10:00:42 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) >> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Init) >> [ 2006/03/24 10:00:42 TRACE xorp_ospfv2 OSPF ] Event(BackupSeen) >> Interface(tun5/tun5) State(Waiting) >> [ 2006/03/24 10:00:42 TRACE xorp_ospfv2 OSPF ] Event(AdjOK?) >> Interface(tun5/tun5) Neighbour(172.25.3.1) State(TwoWay) >> [ 2006/03/24 10:00:51 TRACE xorp_ospfv2 OSPF ] >> Event(DataDescriptionReceived-pseudo-event) Interface(tun5/tun5) >> Neighbour(172.25.3.1) State(ExStart) >> [ 2006/03/24 10:00:51 TRACE xorp_ospfv2 OSPF ] Event(NegotiationDone) >> Interface(tun5/tun5) Neighbour(172.25.3.1) State(ExStart) >> [ 2006/03/24 10:00:51 TRACE xorp_ospfv2 OSPF ] >> Event(DataDescriptionReceived-pseudo-event) Interface(tun5/tun5) >> Neighbour(172.25.3.1) State(Exchange) >> [ 2006/03/24 10:00:51 TRACE xorp_ospfv2 OSPF ] Event(ExchangeDone) >> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Exchange) >> [ 2006/03/24 10:00:52 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) >> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Loading) >> [ 2006/03/24 10:00:52 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) >> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Loading) >> [ 2006/03/24 10:00:52 TRACE xorp_ospfv2 OSPF ] Event(NeighborChange) >> Interface(tun5/tun5) State(Backup) >> [ 2006/03/24 10:00:56 TRACE xorp_ospfv2 OSPF ] >> Event(LinkStateUpdateReceived-pseudo-event) Interface(tun5/tun5) >> Neighbour(172.25.3.1) State(Loading) >> [ 2006/03/24 10:00:56 TRACE xorp_ospfv2 OSPF ] Event(LoadingDone) >> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Loading) >> [ 2006/03/24 10:00:56 TRACE xorp_ospfv2 OSPF ] >> Event(LinkStateRequestReceived-pseudo-event) Interface(tun5/tun5) >> Neighbour(172.25.3.1) State(Full) >> [ 2006/03/24 10:00:56 TRACE xorp_ospfv2 OSPF ] >> Event(LinkStateAcknowledgementReceived-pseudo-event) >> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) >> [ 2006/03/24 10:00:56 TRACE xorp_ospfv2 OSPF ] >> Event(LinkStateUpdateReceived-pseudo-event) Interface(tun5/tun5) >> Neighbour(172.25.3.1) State(Full) >> [ 2006/03/24 10:00:56 TRACE xorp_ospfv2 OSPF ] >> Event(LinkStateAcknowledgementReceived-pseudo-event) >> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) >> [ 2006/03/24 10:00:56 TRACE xorp_ospfv2 OSPF ] Ack for LSA not in >> retransmission list. >> LS age 1 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link >> State ID 10.10.10.10 Advertising Router 10.10.10.10 LS sequence number >> 0x80000001 LS checksum 0x1246 length 48 >> Link State Acknowledgement Packet: >> Version 2 >> Type 5 >> Router ID 11.10.10.10 >> Area ID 0.0.0.0 >> Auth Type 2 >> >> LS age 1 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type >> 0x1 Link State ID 10.10.10.10 Advertising Router 10.10.10.10 LS sequence >> number 0x80000001 LS checksum 0x1246 length 48 >> [ 2006/03/24 10:00:57 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router >> 11.10.10.10(0xb0a0a0a) 0.0.0.0(0) not reachable >> [ 2006/03/24 10:00:57 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network >> 172.25.3.255(0xac1903ff) 0.0.0.0(0) not reachable >> [ 2006/03/24 10:00:57 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network >> 172.25.100.10(0xac19640a) 0.0.0.0(0) not reachable >> [ 2006/03/24 10:00:57 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router >> 255.255.255.255(0xffffffff) 0.0.0.0(0) not reachable >> [ 2006/03/24 10:01:01 TRACE xorp_ospfv2 OSPF ] >> Event(LinkStateUpdateReceived-pseudo-event) Interface(tun5/tun5) >> Neighbour(172.25.3.1) State(Full) >> [ 2006/03/24 10:01:02 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) >> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) >> [ 2006/03/24 10:01:02 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) >> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) >> [ 2006/03/24 10:01:02 TRACE xorp_ospfv2 OSPF ] Checking for virtual >> links Router-LSA: >> LS age 1 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link >> State ID 11.10.10.10 Advertising Router 11.10.10.10 LS sequence number >> 0x80000005 LS checksum 0xb346 length 48 >> Nt-bit false >> V-bit false >> E-bit false >> B-bit false >> Type 2 Transit network IP address of Designated router >> 172.25.100.10 Routers interface address 172.25.100.1 Metric 1 >> Type 2 Transit network IP address of Designated router >> 172.25.3.1 Routers interface address 172.25.3.1 Metric 1 >> [ 2006/03/24 10:01:02 TRACE xorp_ospfv2 OSPF ] Checking for virtual >> links Router-LSA: >> LS age 1505 Options 0x22 DC: 1 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link >> State ID 255.255.255.255 Advertising Router 255.255.255.255 LS sequence >> number 0x80000816 LS checksum 0x5558 length 36 >> Nt-bit false >> V-bit false >> E-bit false >> B-bit false >> Type 2 Transit network IP address of Designated router >> 172.25.100.10 Routers interface address 172.25.100.10 Metric 1 >> [ 2006/03/24 10:01:02 TRACE xorp_ospfv2 OSPF ] [OSPF] Running filter: >> Import on route: 172.25.100.0/24 >> [ 2006/03/24 10:01:02 TRACE xorp_ospfv2 OSPF ] [OSPF] Running filter: >> Export-SourceMatch on route: 172.25.100.0/24 >> [ 2006/03/24 10:01:02 TRACE xorp_ospfv2 OSPF ] Add route Net >> 172.25.100.0/24 Nexthop 172.25.3.1 metric 2 equal false discard false policy >> [ 2006/03/24 10:01:12 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) >> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) >> [ 2006/03/24 10:01:12 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) >> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) >> [ 2006/03/24 10:01:21 WARNING xorp_fea XrlFeaTarget ] Handling method >> for raw_packet4/0.1/send failed: XrlCmdError 102 Command failed >> setsockopt(IP_MULTICAST_IF, 172.25.3.4) failed: Cannot assign requested >> address >> [ 2006/03/24 10:01:21 ERROR xorp_ospfv2:28549 OSPF +181 xrl_io.cc >> send_cb ] Cannot send a packet on interface tun5 vif tun5: 102 Command >> failed setsockopt(IP_MULTICAST_IF, 172.25.3.4) failed: Cannot assign >> requested address >> [ 2006/03/24 10:01:52 TRACE xorp_ospfv2 OSPF ] Event(InactivityTimer) >> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) >> [ 2006/03/24 10:01:52 TRACE xorp_ospfv2 OSPF ] Event(NeighborChange) >> Interface(tun5/tun5) State(Backup) >> [ 2006/03/24 10:01:53 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router >> 11.10.10.10(0xb0a0a0a) 0.0.0.0(0) not reachable >> [ 2006/03/24 10:01:53 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network >> 172.25.3.1(0xac190301) 0.0.0.0(0) not reachable >> [ 2006/03/24 10:01:53 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network >> 172.25.100.10(0xac19640a) 0.0.0.0(0) not reachable >> [ 2006/03/24 10:01:53 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router >> 255.255.255.255(0xffffffff) 0.0.0.0(0) not reachable >> [ 2006/03/24 10:01:53 TRACE xorp_ospfv2 OSPF ] Delete route Net >> 172.25.100.0/24 >> [ 2006/03/24 10:01:53 ERROR xorp_fea:28545 FEA +503 >> fticonfig_entry_set_netlink.cc delete_entry ] Error checking netlink >> request: AF_NETLINK NLMSG_ERROR message: No such process >> [ 2006/03/24 10:01:53 ERROR xorp_fea:28545 FEA +71 fti_transaction.cc >> operation_result ] FTI transaction commit failed on DeleteEntry4: net = >> 172.25.100.0/24 nexthop = 0.0.0.0 ifname = vifname = metric = 0 >> admin_distance = 0 xorp_route = false is_deleted = false is_unresolved = >> false is_connected_route = false >> [ 2006/03/24 10:01:53 WARNING xorp_fea XrlFeaTarget ] Handling method >> for redist_transaction4/0.1/commit_transaction failed: XrlCmdError 102 >> Command failed DeleteEntry4: net = 172.25.100.0/24 nexthop = 0.0.0.0 >> ifname = vifname = metric = 0 admin_distance = 0 xorp_route = false >> is_deleted = false is_unresolved = false is_connected_route = false >> [ 2006/03/24 10:01:53 ERROR xorp_rib:28547 RIB +914 redist_xrl.cc >> dispatch_complete ] Failed to commit transaction: 102 Command failed >> DeleteEntry4: net = 172.25.100.0/24 nexthop = 0.0.0.0 ifname = vifname >> = metric = 0 admin_distance = 0 xorp_route = false is_deleted = false >> is_unresolved = false is_connected_route = false >> >> _______________________________________________ >> Xorp-users mailing list >> Xorp-users@xorp.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users >> > > From pavlin@icir.org Sat Mar 25 02:57:27 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Fri, 24 Mar 2006 18:57:27 -0800 Subject: [Xorp-users] bouncing interface kills OSPF - known behavior? In-Reply-To: Message from Mark Winter of "Fri, 24 Mar 2006 16:56:33 PST." <44249541.3060306@clearwire.com> Message-ID: <200603250257.k2P2vRCI054099@possum.icir.org> > Ok as a workaround what I've done is setup Openvpn to restart XORP when > the tunnel is restarted. I am running openvpn 2.1 beta 11 which added > the topology feature, that may be the difference in messages. > > The logs and config were from the client side, started with command: > openvpn --config client.conf > > After it's connected and OSPF has established adjacency, I control C > openvpn and then restart it again. In our testing we used OpenVPN 2.0.5 with just the minimum setup to have the tunnel created, and we also used Ctrl-C to restart it: openvpn --local xxx.xxx.xxx.xxx --remote yyy.yyy.yyy.yyy --ifconfig 10.10.10.1 10.10.10.2 --dev tun0 Though, I don't know whether the different openvpn version and the different setup accounts for the different error messages. If the tunnel is restarted, can you try to reconfigure the interface: set interfaces interface tun0 disable true commit set interfaces interface tun0 disable false commit It worked for us, but I don't know whether it will work for your setup. If it works, you could run the above commands as part of your script. See the XORP user manual for examples how to run xorpsh as part of a shell script and supply it with the commands. Pavlin > --------- client.conf--------------- > client > up "/etc/init.d/xorp restart" > dev tun5 > proto udp > remote xxx.xxx.xxx.xxx 3194 > resolv-retry infinite > nobind > user nobody > group nobody > persist-key > persist-tun > mute-replay-warnings > ca keys/ca.crt > cert keys/client-new.crt > key keys/client-new.key > tls-auth keys/ta.key 1 > cipher AES-256-CBC > comp-lzo > verb 3 > ping 15 > ping-restart 45 > ping-timer-rem > ------------------------------------- > -----server.conf---------------- > tls-server > local xxx.xxx.xxx.xxx > port 3194 > proto udp > dev tun5 > client-config-dir /etc/openvpn-poptest/ccd > ca keys/ca.crt > cert keys/myserver.crt > key keys/myserver.key > dh keys/dh2048.pem > crl-verify keys/crl.pem > # Configure server mode and supply a VPN subnet > topology subnet > mode server > server 172.25.3.0 255.255.255.0 > ifconfig-pool-persist ipp.txt > client-to-client > ping 15 > ping-restart 45 > ping-timer-rem > tls-auth keys/ta.key 0 > cipher AES-256-CBC > comp-lzo > user nobody > group nobody > persist-key > persist-tun > status openvpn-status.log > verb 3 > mute 20 > > Thanks, > Mark > Pavlin Radoslavov wrote: > >> Is there a way to HUP the OSPF process when an interface that is defined > >> in OSPF toggles between up/down? Once this happens I have to restart > >> the XORP process and then the neighbor will go back into the 'full' > >> state. Currently running xorp 1.2. > >> > >> So with the config below tun5 goes down for about 30 seconds and then > >> when it's brought back up is when I have the problem. > >> > > > > In general, have in mind that tunnels and VPNs are not supported > > (yet). It happens that tunnels are working (if configured before > > starting XORP), but so far we haven't got around to provide complete > > support for them. Hence, for the time being you may have to use some > > work-arounds if a tunnel is removed while XORP is running, etc. > > > > Could you provide the exact instuctions/commands about what you are > > doing. We tried to replicate the problem, but the messages we were > > seeing were different (e.g., we didn't see the > > "setsockopt(IP_MULTICAST_IF)" warnings). > > > > We saw some issues with bringing the tunnel down and up (by either > > using "ifconfig tun0 down/up" or just by killing and restarting the > > openvpn program), but we want to verify whether we are seeing same > > problem or something else before suggesting any possible > > work-around. > > > > Pavlin > > > > > >> root@marklaptop.localdomain> show ospf4 neighbor > >> Address Interface State ID Pri Dead > >> 172.25.3.1 tun5/tun5 Down 11.10.10.10 0 0 > >> > >> -------config file------------ > >> interfaces { > >> interface tun5 { > >> default-system-config > >> description: "Openvpn-test-interface" > >> } > >> interface "eth0.100" { > >> default-system-config { > >> } > >> description: "Test interface" > >> } > >> } > >> fea { > >> unicast-forwarding4 { > >> } > >> } > >> policy { > >> policy-statement connected { > >> term export { > >> from { > >> protocol: "connected" > >> } > >> } > >> } > >> policy-statement static { > >> term export { > >> from { > >> protocol: "static" > >> } > >> } > >> } > >> } > >> protocols { > >> ospf4 { > >> router-id: 10.10.10.10 > >> area 0.0.0.0 { > >> interface "eth0.100" { > >> vif "eth0.100" { > >> address 1.1.1.1 { > >> passive: true > >> } > >> } > >> } > >> interface tun5 { > >> vif tun5 { > >> address 172.25.3.4 { > >> authentication { > >> md5 1 { > >> password: "id10t" > >> } > >> } > >> } > >> } > >> } > >> } > >> traceoptions { > >> flag { > >> all { > >> } > >> } > >> } > >> } > >> } > >> > >> ---- LOG FILE------- > >> [ 2006/03/24 10:00:27 INFO xorp_rtrmgr:28544 RTRMGR +240 > >> master_conf_tree.cc execute ] Changed modules: interfaces, fea, rib, > >> policy, ospf4 > >> [ 2006/03/24 10:00:27 INFO xorp_rtrmgr:28544 RTRMGR +99 > >> module_manager.cc execute ] Executing module: interfaces (fea/xorp_fea) > >> [ 2006/03/24 10:00:28 INFO xorp_fea MFEA ] MFEA enabled > >> [ 2006/03/24 10:00:28 INFO xorp_fea MFEA ] CLI enabled > >> [ 2006/03/24 10:00:28 INFO xorp_fea MFEA ] CLI started > >> [ 2006/03/24 10:00:28 INFO xorp_fea MFEA ] MFEA enabled > >> [ 2006/03/24 10:00:28 INFO xorp_fea MFEA ] CLI enabled > >> [ 2006/03/24 10:00:28 INFO xorp_fea MFEA ] CLI started > >> [ 2006/03/24 10:00:29 INFO xorp_rtrmgr:28544 RTRMGR +99 > >> module_manager.cc execute ] Executing module: fea (fea/xorp_fea) > >> [ 2006/03/24 10:00:35 INFO xorp_rtrmgr:28544 RTRMGR +99 > >> module_manager.cc execute ] Executing module: rib (rib/xorp_rib) > >> [ 2006/03/24 10:00:37 INFO xorp_rtrmgr:28544 RTRMGR +99 > >> module_manager.cc execute ] Executing module: policy (policy/xorp_policy) > >> [ 2006/03/24 10:00:39 INFO xorp_rtrmgr:28544 RTRMGR +99 > >> module_manager.cc execute ] Executing module: ospf4 (ospf/xorp_ospfv2) > >> [ 2006/03/24 10:00:41 TRACE xorp_ospfv2 OSPF ] Event(LoopInd) > >> Interface(eth0.100/eth0.100) State(Down) > >> [ 2006/03/24 10:00:41 TRACE xorp_ospfv2 OSPF ] Event(InterfaceUp) > >> Interface(tun5/tun5) State(Down) > >> [ 2006/03/24 10:00:41 INFO xorp_rtrmgr:28544 RTRMGR +2228 task.cc > >> run_task ] No more tasks to run > >> [ 2006/03/24 10:00:42 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) > >> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Init) > >> [ 2006/03/24 10:00:42 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) > >> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Init) > >> [ 2006/03/24 10:00:42 TRACE xorp_ospfv2 OSPF ] Event(BackupSeen) > >> Interface(tun5/tun5) State(Waiting) > >> [ 2006/03/24 10:00:42 TRACE xorp_ospfv2 OSPF ] Event(AdjOK?) > >> Interface(tun5/tun5) Neighbour(172.25.3.1) State(TwoWay) > >> [ 2006/03/24 10:00:51 TRACE xorp_ospfv2 OSPF ] > >> Event(DataDescriptionReceived-pseudo-event) Interface(tun5/tun5) > >> Neighbour(172.25.3.1) State(ExStart) > >> [ 2006/03/24 10:00:51 TRACE xorp_ospfv2 OSPF ] Event(NegotiationDone) > >> Interface(tun5/tun5) Neighbour(172.25.3.1) State(ExStart) > >> [ 2006/03/24 10:00:51 TRACE xorp_ospfv2 OSPF ] > >> Event(DataDescriptionReceived-pseudo-event) Interface(tun5/tun5) > >> Neighbour(172.25.3.1) State(Exchange) > >> [ 2006/03/24 10:00:51 TRACE xorp_ospfv2 OSPF ] Event(ExchangeDone) > >> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Exchange) > >> [ 2006/03/24 10:00:52 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) > >> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Loading) > >> [ 2006/03/24 10:00:52 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) > >> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Loading) > >> [ 2006/03/24 10:00:52 TRACE xorp_ospfv2 OSPF ] Event(NeighborChange) > >> Interface(tun5/tun5) State(Backup) > >> [ 2006/03/24 10:00:56 TRACE xorp_ospfv2 OSPF ] > >> Event(LinkStateUpdateReceived-pseudo-event) Interface(tun5/tun5) > >> Neighbour(172.25.3.1) State(Loading) > >> [ 2006/03/24 10:00:56 TRACE xorp_ospfv2 OSPF ] Event(LoadingDone) > >> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Loading) > >> [ 2006/03/24 10:00:56 TRACE xorp_ospfv2 OSPF ] > >> Event(LinkStateRequestReceived-pseudo-event) Interface(tun5/tun5) > >> Neighbour(172.25.3.1) State(Full) > >> [ 2006/03/24 10:00:56 TRACE xorp_ospfv2 OSPF ] > >> Event(LinkStateAcknowledgementReceived-pseudo-event) > >> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) > >> [ 2006/03/24 10:00:56 TRACE xorp_ospfv2 OSPF ] > >> Event(LinkStateUpdateReceived-pseudo-event) Interface(tun5/tun5) > >> Neighbour(172.25.3.1) State(Full) > >> [ 2006/03/24 10:00:56 TRACE xorp_ospfv2 OSPF ] > >> Event(LinkStateAcknowledgementReceived-pseudo-event) > >> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) > >> [ 2006/03/24 10:00:56 TRACE xorp_ospfv2 OSPF ] Ack for LSA not in > >> retransmission list. > >> LS age 1 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link > >> State ID 10.10.10.10 Advertising Router 10.10.10.10 LS sequence number > >> 0x80000001 LS checksum 0x1246 length 48 > >> Link State Acknowledgement Packet: > >> Version 2 > >> Type 5 > >> Router ID 11.10.10.10 > >> Area ID 0.0.0.0 > >> Auth Type 2 > >> > >> LS age 1 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type > >> 0x1 Link State ID 10.10.10.10 Advertising Router 10.10.10.10 LS sequence > >> number 0x80000001 LS checksum 0x1246 length 48 > >> [ 2006/03/24 10:00:57 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router > >> 11.10.10.10(0xb0a0a0a) 0.0.0.0(0) not reachable > >> [ 2006/03/24 10:00:57 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network > >> 172.25.3.255(0xac1903ff) 0.0.0.0(0) not reachable > >> [ 2006/03/24 10:00:57 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network > >> 172.25.100.10(0xac19640a) 0.0.0.0(0) not reachable > >> [ 2006/03/24 10:00:57 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router > >> 255.255.255.255(0xffffffff) 0.0.0.0(0) not reachable > >> [ 2006/03/24 10:01:01 TRACE xorp_ospfv2 OSPF ] > >> Event(LinkStateUpdateReceived-pseudo-event) Interface(tun5/tun5) > >> Neighbour(172.25.3.1) State(Full) > >> [ 2006/03/24 10:01:02 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) > >> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) > >> [ 2006/03/24 10:01:02 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) > >> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) > >> [ 2006/03/24 10:01:02 TRACE xorp_ospfv2 OSPF ] Checking for virtual > >> links Router-LSA: > >> LS age 1 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link > >> State ID 11.10.10.10 Advertising Router 11.10.10.10 LS sequence number > >> 0x80000005 LS checksum 0xb346 length 48 > >> Nt-bit false > >> V-bit false > >> E-bit false > >> B-bit false > >> Type 2 Transit network IP address of Designated router > >> 172.25.100.10 Routers interface address 172.25.100.1 Metric 1 > >> Type 2 Transit network IP address of Designated router > >> 172.25.3.1 Routers interface address 172.25.3.1 Metric 1 > >> [ 2006/03/24 10:01:02 TRACE xorp_ospfv2 OSPF ] Checking for virtual > >> links Router-LSA: > >> LS age 1505 Options 0x22 DC: 1 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link > >> State ID 255.255.255.255 Advertising Router 255.255.255.255 LS sequence > >> number 0x80000816 LS checksum 0x5558 length 36 > >> Nt-bit false > >> V-bit false > >> E-bit false > >> B-bit false > >> Type 2 Transit network IP address of Designated router > >> 172.25.100.10 Routers interface address 172.25.100.10 Metric 1 > >> [ 2006/03/24 10:01:02 TRACE xorp_ospfv2 OSPF ] [OSPF] Running filter: > >> Import on route: 172.25.100.0/24 > >> [ 2006/03/24 10:01:02 TRACE xorp_ospfv2 OSPF ] [OSPF] Running filter: > >> Export-SourceMatch on route: 172.25.100.0/24 > >> [ 2006/03/24 10:01:02 TRACE xorp_ospfv2 OSPF ] Add route Net > >> 172.25.100.0/24 Nexthop 172.25.3.1 metric 2 equal false discard false policy > >> [ 2006/03/24 10:01:12 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) > >> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) > >> [ 2006/03/24 10:01:12 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) > >> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) > >> [ 2006/03/24 10:01:21 WARNING xorp_fea XrlFeaTarget ] Handling method > >> for raw_packet4/0.1/send failed: XrlCmdError 102 Command failed > >> setsockopt(IP_MULTICAST_IF, 172.25.3.4) failed: Cannot assign requested > >> address > >> [ 2006/03/24 10:01:21 ERROR xorp_ospfv2:28549 OSPF +181 xrl_io.cc > >> send_cb ] Cannot send a packet on interface tun5 vif tun5: 102 Command > >> failed setsockopt(IP_MULTICAST_IF, 172.25.3.4) failed: Cannot assign > >> requested address > >> [ 2006/03/24 10:01:52 TRACE xorp_ospfv2 OSPF ] Event(InactivityTimer) > >> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) > >> [ 2006/03/24 10:01:52 TRACE xorp_ospfv2 OSPF ] Event(NeighborChange) > >> Interface(tun5/tun5) State(Backup) > >> [ 2006/03/24 10:01:53 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router > >> 11.10.10.10(0xb0a0a0a) 0.0.0.0(0) not reachable > >> [ 2006/03/24 10:01:53 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network > >> 172.25.3.1(0xac190301) 0.0.0.0(0) not reachable > >> [ 2006/03/24 10:01:53 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network > >> 172.25.100.10(0xac19640a) 0.0.0.0(0) not reachable > >> [ 2006/03/24 10:01:53 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router > >> 255.255.255.255(0xffffffff) 0.0.0.0(0) not reachable > >> [ 2006/03/24 10:01:53 TRACE xorp_ospfv2 OSPF ] Delete route Net > >> 172.25.100.0/24 > >> [ 2006/03/24 10:01:53 ERROR xorp_fea:28545 FEA +503 > >> fticonfig_entry_set_netlink.cc delete_entry ] Error checking netlink > >> request: AF_NETLINK NLMSG_ERROR message: No such process > >> [ 2006/03/24 10:01:53 ERROR xorp_fea:28545 FEA +71 fti_transaction.cc > >> operation_result ] FTI transaction commit failed on DeleteEntry4: net = > >> 172.25.100.0/24 nexthop = 0.0.0.0 ifname = vifname = metric = 0 > >> admin_distance = 0 xorp_route = false is_deleted = false is_unresolved = > >> false is_connected_route = false > >> [ 2006/03/24 10:01:53 WARNING xorp_fea XrlFeaTarget ] Handling method > >> for redist_transaction4/0.1/commit_transaction failed: XrlCmdError 102 > >> Command failed DeleteEntry4: net = 172.25.100.0/24 nexthop = 0.0.0.0 > >> ifname = vifname = metric = 0 admin_distance = 0 xorp_route = false > >> is_deleted = false is_unresolved = false is_connected_route = false > >> [ 2006/03/24 10:01:53 ERROR xorp_rib:28547 RIB +914 redist_xrl.cc > >> dispatch_complete ] Failed to commit transaction: 102 Command failed > >> DeleteEntry4: net = 172.25.100.0/24 nexthop = 0.0.0.0 ifname = vifname > >> = metric = 0 admin_distance = 0 xorp_route = false is_deleted = false > >> is_unresolved = false is_connected_route = false > >> > >> _______________________________________________ > >> Xorp-users mailing list > >> Xorp-users@xorp.org > >> 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 From pavlin@icir.org Mon Mar 27 08:42:45 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Mon, 27 Mar 2006 00:42:45 -0800 Subject: [Xorp-users] HEADS UP: XORP configuration syntax changes Message-ID: <200603270842.k2R8gjr2036826@possum.icir.org> All, As of today, there are few changes in the XORP configuration syntax in XORP-current, and those changes will be in the next XORP-1.3 release as well. The changes are: * Deprecate the following statements for configuring static routes: route4 route6 interface-route4 interface-route6 mrib-route4 mrib-route6 mrib-interface-route4 mrib-interface-route6 The new replacement statements are: route interface-route mrib-route mrib-interface-route Each of the new statements can be used to configure either IPv4Net or IPv6Net route. Please let us know if you find any problems because of the above change. Thank you, The XORP Team From mark.winter@clearwire.com Mon Mar 27 16:06:07 2006 From: mark.winter@clearwire.com (Mark Winter) Date: Mon, 27 Mar 2006 08:06:07 -0800 Subject: [Xorp-users] bouncing interface kills OSPF - known behavior? In-Reply-To: <200603250257.k2P2vRCI054099@possum.icir.org> References: <200603250257.k2P2vRCI054099@possum.icir.org> Message-ID: <44280D6F.2050508@clearwire.com> Yes that works just fine for my setup. Appreciate the help. Thanks, Mark Pavlin Radoslavov wrote: >> Ok as a workaround what I've done is setup Openvpn to restart XORP when >> the tunnel is restarted. I am running openvpn 2.1 beta 11 which added >> the topology feature, that may be the difference in messages. >> >> The logs and config were from the client side, started with command: >> openvpn --config client.conf >> >> After it's connected and OSPF has established adjacency, I control C >> openvpn and then restart it again. >> > > In our testing we used OpenVPN 2.0.5 with just the minimum setup to > have the tunnel created, and we also used Ctrl-C to restart it: > > openvpn --local xxx.xxx.xxx.xxx --remote yyy.yyy.yyy.yyy --ifconfig > 10.10.10.1 10.10.10.2 --dev tun0 > > Though, I don't know whether the different openvpn version and the > different setup accounts for the different error messages. > > If the tunnel is restarted, can you try to reconfigure the > interface: > > set interfaces interface tun0 disable true > commit > set interfaces interface tun0 disable false > commit > > It worked for us, but I don't know whether it will work for your > setup. If it works, you could run the above commands as part of your > script. See the XORP user manual for examples how to run xorpsh as > part of a shell script and supply it with the commands. > > Pavlin > > > >> --------- client.conf--------------- >> client >> up "/etc/init.d/xorp restart" >> dev tun5 >> proto udp >> remote xxx.xxx.xxx.xxx 3194 >> resolv-retry infinite >> nobind >> user nobody >> group nobody >> persist-key >> persist-tun >> mute-replay-warnings >> ca keys/ca.crt >> cert keys/client-new.crt >> key keys/client-new.key >> tls-auth keys/ta.key 1 >> cipher AES-256-CBC >> comp-lzo >> verb 3 >> ping 15 >> ping-restart 45 >> ping-timer-rem >> ------------------------------------- >> -----server.conf---------------- >> tls-server >> local xxx.xxx.xxx.xxx >> port 3194 >> proto udp >> dev tun5 >> client-config-dir /etc/openvpn-poptest/ccd >> ca keys/ca.crt >> cert keys/myserver.crt >> key keys/myserver.key >> dh keys/dh2048.pem >> crl-verify keys/crl.pem >> # Configure server mode and supply a VPN subnet >> topology subnet >> mode server >> server 172.25.3.0 255.255.255.0 >> ifconfig-pool-persist ipp.txt >> client-to-client >> ping 15 >> ping-restart 45 >> ping-timer-rem >> tls-auth keys/ta.key 0 >> cipher AES-256-CBC >> comp-lzo >> user nobody >> group nobody >> persist-key >> persist-tun >> status openvpn-status.log >> verb 3 >> mute 20 >> >> Thanks, >> Mark >> Pavlin Radoslavov wrote: >> >>>> Is there a way to HUP the OSPF process when an interface that is defined >>>> in OSPF toggles between up/down? Once this happens I have to restart >>>> the XORP process and then the neighbor will go back into the 'full' >>>> state. Currently running xorp 1.2. >>>> >>>> So with the config below tun5 goes down for about 30 seconds and then >>>> when it's brought back up is when I have the problem. >>>> >>>> >>> In general, have in mind that tunnels and VPNs are not supported >>> (yet). It happens that tunnels are working (if configured before >>> starting XORP), but so far we haven't got around to provide complete >>> support for them. Hence, for the time being you may have to use some >>> work-arounds if a tunnel is removed while XORP is running, etc. >>> >>> Could you provide the exact instuctions/commands about what you are >>> doing. We tried to replicate the problem, but the messages we were >>> seeing were different (e.g., we didn't see the >>> "setsockopt(IP_MULTICAST_IF)" warnings). >>> >>> We saw some issues with bringing the tunnel down and up (by either >>> using "ifconfig tun0 down/up" or just by killing and restarting the >>> openvpn program), but we want to verify whether we are seeing same >>> problem or something else before suggesting any possible >>> work-around. >>> >>> Pavlin >>> >>> >>> >>>> root@marklaptop.localdomain> show ospf4 neighbor >>>> Address Interface State ID Pri Dead >>>> 172.25.3.1 tun5/tun5 Down 11.10.10.10 0 0 >>>> >>>> -------config file------------ >>>> interfaces { >>>> interface tun5 { >>>> default-system-config >>>> description: "Openvpn-test-interface" >>>> } >>>> interface "eth0.100" { >>>> default-system-config { >>>> } >>>> description: "Test interface" >>>> } >>>> } >>>> fea { >>>> unicast-forwarding4 { >>>> } >>>> } >>>> policy { >>>> policy-statement connected { >>>> term export { >>>> from { >>>> protocol: "connected" >>>> } >>>> } >>>> } >>>> policy-statement static { >>>> term export { >>>> from { >>>> protocol: "static" >>>> } >>>> } >>>> } >>>> } >>>> protocols { >>>> ospf4 { >>>> router-id: 10.10.10.10 >>>> area 0.0.0.0 { >>>> interface "eth0.100" { >>>> vif "eth0.100" { >>>> address 1.1.1.1 { >>>> passive: true >>>> } >>>> } >>>> } >>>> interface tun5 { >>>> vif tun5 { >>>> address 172.25.3.4 { >>>> authentication { >>>> md5 1 { >>>> password: "id10t" >>>> } >>>> } >>>> } >>>> } >>>> } >>>> } >>>> traceoptions { >>>> flag { >>>> all { >>>> } >>>> } >>>> } >>>> } >>>> } >>>> >>>> ---- LOG FILE------- >>>> [ 2006/03/24 10:00:27 INFO xorp_rtrmgr:28544 RTRMGR +240 >>>> master_conf_tree.cc execute ] Changed modules: interfaces, fea, rib, >>>> policy, ospf4 >>>> [ 2006/03/24 10:00:27 INFO xorp_rtrmgr:28544 RTRMGR +99 >>>> module_manager.cc execute ] Executing module: interfaces (fea/xorp_fea) >>>> [ 2006/03/24 10:00:28 INFO xorp_fea MFEA ] MFEA enabled >>>> [ 2006/03/24 10:00:28 INFO xorp_fea MFEA ] CLI enabled >>>> [ 2006/03/24 10:00:28 INFO xorp_fea MFEA ] CLI started >>>> [ 2006/03/24 10:00:28 INFO xorp_fea MFEA ] MFEA enabled >>>> [ 2006/03/24 10:00:28 INFO xorp_fea MFEA ] CLI enabled >>>> [ 2006/03/24 10:00:28 INFO xorp_fea MFEA ] CLI started >>>> [ 2006/03/24 10:00:29 INFO xorp_rtrmgr:28544 RTRMGR +99 >>>> module_manager.cc execute ] Executing module: fea (fea/xorp_fea) >>>> [ 2006/03/24 10:00:35 INFO xorp_rtrmgr:28544 RTRMGR +99 >>>> module_manager.cc execute ] Executing module: rib (rib/xorp_rib) >>>> [ 2006/03/24 10:00:37 INFO xorp_rtrmgr:28544 RTRMGR +99 >>>> module_manager.cc execute ] Executing module: policy (policy/xorp_policy) >>>> [ 2006/03/24 10:00:39 INFO xorp_rtrmgr:28544 RTRMGR +99 >>>> module_manager.cc execute ] Executing module: ospf4 (ospf/xorp_ospfv2) >>>> [ 2006/03/24 10:00:41 TRACE xorp_ospfv2 OSPF ] Event(LoopInd) >>>> Interface(eth0.100/eth0.100) State(Down) >>>> [ 2006/03/24 10:00:41 TRACE xorp_ospfv2 OSPF ] Event(InterfaceUp) >>>> Interface(tun5/tun5) State(Down) >>>> [ 2006/03/24 10:00:41 INFO xorp_rtrmgr:28544 RTRMGR +2228 task.cc >>>> run_task ] No more tasks to run >>>> [ 2006/03/24 10:00:42 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) >>>> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Init) >>>> [ 2006/03/24 10:00:42 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) >>>> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Init) >>>> [ 2006/03/24 10:00:42 TRACE xorp_ospfv2 OSPF ] Event(BackupSeen) >>>> Interface(tun5/tun5) State(Waiting) >>>> [ 2006/03/24 10:00:42 TRACE xorp_ospfv2 OSPF ] Event(AdjOK?) >>>> Interface(tun5/tun5) Neighbour(172.25.3.1) State(TwoWay) >>>> [ 2006/03/24 10:00:51 TRACE xorp_ospfv2 OSPF ] >>>> Event(DataDescriptionReceived-pseudo-event) Interface(tun5/tun5) >>>> Neighbour(172.25.3.1) State(ExStart) >>>> [ 2006/03/24 10:00:51 TRACE xorp_ospfv2 OSPF ] Event(NegotiationDone) >>>> Interface(tun5/tun5) Neighbour(172.25.3.1) State(ExStart) >>>> [ 2006/03/24 10:00:51 TRACE xorp_ospfv2 OSPF ] >>>> Event(DataDescriptionReceived-pseudo-event) Interface(tun5/tun5) >>>> Neighbour(172.25.3.1) State(Exchange) >>>> [ 2006/03/24 10:00:51 TRACE xorp_ospfv2 OSPF ] Event(ExchangeDone) >>>> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Exchange) >>>> [ 2006/03/24 10:00:52 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) >>>> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Loading) >>>> [ 2006/03/24 10:00:52 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) >>>> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Loading) >>>> [ 2006/03/24 10:00:52 TRACE xorp_ospfv2 OSPF ] Event(NeighborChange) >>>> Interface(tun5/tun5) State(Backup) >>>> [ 2006/03/24 10:00:56 TRACE xorp_ospfv2 OSPF ] >>>> Event(LinkStateUpdateReceived-pseudo-event) Interface(tun5/tun5) >>>> Neighbour(172.25.3.1) State(Loading) >>>> [ 2006/03/24 10:00:56 TRACE xorp_ospfv2 OSPF ] Event(LoadingDone) >>>> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Loading) >>>> [ 2006/03/24 10:00:56 TRACE xorp_ospfv2 OSPF ] >>>> Event(LinkStateRequestReceived-pseudo-event) Interface(tun5/tun5) >>>> Neighbour(172.25.3.1) State(Full) >>>> [ 2006/03/24 10:00:56 TRACE xorp_ospfv2 OSPF ] >>>> Event(LinkStateAcknowledgementReceived-pseudo-event) >>>> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) >>>> [ 2006/03/24 10:00:56 TRACE xorp_ospfv2 OSPF ] >>>> Event(LinkStateUpdateReceived-pseudo-event) Interface(tun5/tun5) >>>> Neighbour(172.25.3.1) State(Full) >>>> [ 2006/03/24 10:00:56 TRACE xorp_ospfv2 OSPF ] >>>> Event(LinkStateAcknowledgementReceived-pseudo-event) >>>> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) >>>> [ 2006/03/24 10:00:56 TRACE xorp_ospfv2 OSPF ] Ack for LSA not in >>>> retransmission list. >>>> LS age 1 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link >>>> State ID 10.10.10.10 Advertising Router 10.10.10.10 LS sequence number >>>> 0x80000001 LS checksum 0x1246 length 48 >>>> Link State Acknowledgement Packet: >>>> Version 2 >>>> Type 5 >>>> Router ID 11.10.10.10 >>>> Area ID 0.0.0.0 >>>> Auth Type 2 >>>> >>>> LS age 1 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type >>>> 0x1 Link State ID 10.10.10.10 Advertising Router 10.10.10.10 LS sequence >>>> number 0x80000001 LS checksum 0x1246 length 48 >>>> [ 2006/03/24 10:00:57 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router >>>> 11.10.10.10(0xb0a0a0a) 0.0.0.0(0) not reachable >>>> [ 2006/03/24 10:00:57 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network >>>> 172.25.3.255(0xac1903ff) 0.0.0.0(0) not reachable >>>> [ 2006/03/24 10:00:57 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network >>>> 172.25.100.10(0xac19640a) 0.0.0.0(0) not reachable >>>> [ 2006/03/24 10:00:57 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router >>>> 255.255.255.255(0xffffffff) 0.0.0.0(0) not reachable >>>> [ 2006/03/24 10:01:01 TRACE xorp_ospfv2 OSPF ] >>>> Event(LinkStateUpdateReceived-pseudo-event) Interface(tun5/tun5) >>>> Neighbour(172.25.3.1) State(Full) >>>> [ 2006/03/24 10:01:02 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) >>>> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) >>>> [ 2006/03/24 10:01:02 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) >>>> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) >>>> [ 2006/03/24 10:01:02 TRACE xorp_ospfv2 OSPF ] Checking for virtual >>>> links Router-LSA: >>>> LS age 1 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link >>>> State ID 11.10.10.10 Advertising Router 11.10.10.10 LS sequence number >>>> 0x80000005 LS checksum 0xb346 length 48 >>>> Nt-bit false >>>> V-bit false >>>> E-bit false >>>> B-bit false >>>> Type 2 Transit network IP address of Designated router >>>> 172.25.100.10 Routers interface address 172.25.100.1 Metric 1 >>>> Type 2 Transit network IP address of Designated router >>>> 172.25.3.1 Routers interface address 172.25.3.1 Metric 1 >>>> [ 2006/03/24 10:01:02 TRACE xorp_ospfv2 OSPF ] Checking for virtual >>>> links Router-LSA: >>>> LS age 1505 Options 0x22 DC: 1 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link >>>> State ID 255.255.255.255 Advertising Router 255.255.255.255 LS sequence >>>> number 0x80000816 LS checksum 0x5558 length 36 >>>> Nt-bit false >>>> V-bit false >>>> E-bit false >>>> B-bit false >>>> Type 2 Transit network IP address of Designated router >>>> 172.25.100.10 Routers interface address 172.25.100.10 Metric 1 >>>> [ 2006/03/24 10:01:02 TRACE xorp_ospfv2 OSPF ] [OSPF] Running filter: >>>> Import on route: 172.25.100.0/24 >>>> [ 2006/03/24 10:01:02 TRACE xorp_ospfv2 OSPF ] [OSPF] Running filter: >>>> Export-SourceMatch on route: 172.25.100.0/24 >>>> [ 2006/03/24 10:01:02 TRACE xorp_ospfv2 OSPF ] Add route Net >>>> 172.25.100.0/24 Nexthop 172.25.3.1 metric 2 equal false discard false policy >>>> [ 2006/03/24 10:01:12 TRACE xorp_ospfv2 OSPF ] Event(HelloReceived) >>>> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) >>>> [ 2006/03/24 10:01:12 TRACE xorp_ospfv2 OSPF ] Event(2-WayReceived) >>>> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) >>>> [ 2006/03/24 10:01:21 WARNING xorp_fea XrlFeaTarget ] Handling method >>>> for raw_packet4/0.1/send failed: XrlCmdError 102 Command failed >>>> setsockopt(IP_MULTICAST_IF, 172.25.3.4) failed: Cannot assign requested >>>> address >>>> [ 2006/03/24 10:01:21 ERROR xorp_ospfv2:28549 OSPF +181 xrl_io.cc >>>> send_cb ] Cannot send a packet on interface tun5 vif tun5: 102 Command >>>> failed setsockopt(IP_MULTICAST_IF, 172.25.3.4) failed: Cannot assign >>>> requested address >>>> [ 2006/03/24 10:01:52 TRACE xorp_ospfv2 OSPF ] Event(InactivityTimer) >>>> Interface(tun5/tun5) Neighbour(172.25.3.1) State(Full) >>>> [ 2006/03/24 10:01:52 TRACE xorp_ospfv2 OSPF ] Event(NeighborChange) >>>> Interface(tun5/tun5) State(Backup) >>>> [ 2006/03/24 10:01:53 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router >>>> 11.10.10.10(0xb0a0a0a) 0.0.0.0(0) not reachable >>>> [ 2006/03/24 10:01:53 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network >>>> 172.25.3.1(0xac190301) 0.0.0.0(0) not reachable >>>> [ 2006/03/24 10:01:53 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Network >>>> 172.25.100.10(0xac19640a) 0.0.0.0(0) not reachable >>>> [ 2006/03/24 10:01:53 TRACE xorp_ospfv2 OSPF ] Node: OSPFv2 Router >>>> 255.255.255.255(0xffffffff) 0.0.0.0(0) not reachable >>>> [ 2006/03/24 10:01:53 TRACE xorp_ospfv2 OSPF ] Delete route Net >>>> 172.25.100.0/24 >>>> [ 2006/03/24 10:01:53 ERROR xorp_fea:28545 FEA +503 >>>> fticonfig_entry_set_netlink.cc delete_entry ] Error checking netlink >>>> request: AF_NETLINK NLMSG_ERROR message: No such process >>>> [ 2006/03/24 10:01:53 ERROR xorp_fea:28545 FEA +71 fti_transaction.cc >>>> operation_result ] FTI transaction commit failed on DeleteEntry4: net = >>>> 172.25.100.0/24 nexthop = 0.0.0.0 ifname = vifname = metric = 0 >>>> admin_distance = 0 xorp_route = false is_deleted = false is_unresolved = >>>> false is_connected_route = false >>>> [ 2006/03/24 10:01:53 WARNING xorp_fea XrlFeaTarget ] Handling method >>>> for redist_transaction4/0.1/commit_transaction failed: XrlCmdError 102 >>>> Command failed DeleteEntry4: net = 172.25.100.0/24 nexthop = 0.0.0.0 >>>> ifname = vifname = metric = 0 admin_distance = 0 xorp_route = false >>>> is_deleted = false is_unresolved = false is_connected_route = false >>>> [ 2006/03/24 10:01:53 ERROR xorp_rib:28547 RIB +914 redist_xrl.cc >>>> dispatch_complete ] Failed to commit transaction: 102 Command failed >>>> DeleteEntry4: net = 172.25.100.0/24 nexthop = 0.0.0.0 ifname = vifname >>>> = metric = 0 admin_distance = 0 xorp_route = false is_deleted = false >>>> is_unresolved = false is_connected_route = false >>>> >>>> _______________________________________________ >>>> Xorp-users mailing list >>>> Xorp-users@xorp.org >>>> 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 >> > > From dave.price@aber.ac.uk Tue Mar 28 13:19:29 2006 From: dave.price@aber.ac.uk (Dave Price) Date: Tue, 28 Mar 2006 14:19:29 +0100 Subject: [Xorp-users] Interfaces all going "down" Message-ID: <8685.1143551969@aber.ac.uk> Dear All, I have recently deployed a multicast router using Xorp (release candidate for 1.2). This seems to run fine for a while, and then I noticed problems and when I then interrogate it I see... show pim interface Interface State Mode V PIMstate Priority DRaddr Neighbors discard0 DISABLED Sparse 2 DR 1 127.127.0.1 0 eth1 DOWN Sparse 2 NotDR 1 0.0.0.0 0 eth2 DOWN Sparse 2 NotDR 1 0.0.0.0 0 eth3 DOWN Sparse 2 NotDR 1 0.0.0.0 0 eth4 DOWN Sparse 2 NotDR 1 0.0.0.0 0 register_vif DOWN Sparse 2 DR 1 0.0.0.0 0 [The machine actually has five interfaces, but one, eth0 zero, is not connected to a switch at present and so I removed it from Xorp config. four interfaces 0-> 3 on one four port card and the fifth on a second card - Fedora Core 4 OS]. Any suggestions of a strategy I should adopt to try to track the fault that is leading to the interfaces going "down". Incidently, the interfaces are still shown as "up" with ifconfig at OS level and I can log in remotely using ssh just fine. 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 pavlin@icir.org Tue Mar 28 17:12:38 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Tue, 28 Mar 2006 09:12:38 -0800 Subject: [Xorp-users] Interfaces all going "down" In-Reply-To: Message from Dave Price of "Tue, 28 Mar 2006 14:19:29 +0100." <8685.1143551969@aber.ac.uk> Message-ID: <200603281712.k2SHCckV003429@possum.icir.org> > Dear All, > > I have recently deployed a multicast router > using Xorp (release candidate for 1.2). > This seems to run fine for a while, > and then I noticed problems and > when I then interrogate it I see... > > show pim interface > Interface State Mode V PIMstate Priority DRaddr Neighbors > discard0 DISABLED Sparse 2 DR 1 127.127.0.1 0 > eth1 DOWN Sparse 2 NotDR 1 0.0.0.0 0 > eth2 DOWN Sparse 2 NotDR 1 0.0.0.0 0 > eth3 DOWN Sparse 2 NotDR 1 0.0.0.0 0 > eth4 DOWN Sparse 2 NotDR 1 0.0.0.0 0 > register_vif DOWN Sparse 2 DR 1 0.0.0.0 0 > > [The machine actually has five interfaces, but one, eth0 zero, > is not connected to a switch at present and so I removed it from > Xorp config. four interfaces 0-> 3 on one four port card > and the fifth on a second card - Fedora Core 4 OS]. > > Any suggestions of a strategy I should adopt to > try to track the fault that is leading to the interfaces > going "down". Incidently, the interfaces are still > shown as "up" with ifconfig at OS level and I can > log in remotely using ssh just fine. If you haven't restarted XORP, what is the output of "show interfaces", "show mfea interface" and "show igmp interface" xorpsh commands? Also, did you notice how long time (hours, days?) it took to get into this state and do you have the xlog output when approximately this happened. Finally, do you remember whether the cables connecting the router have been disconnected and connected back in some stage? If you don't have the xlog output, then I'd recommend to enable the traceoptions inside mfea4, igmp and pimsm4 and save it to a file which can be reviewed later if/when this happens again. You can enable the traceoptions by adding the following to the mfea4, igmp, pimsm4 configuration blocks: traceoptions { flag all { disable: false } } Pavlin From dave.price@aber.ac.uk Wed Mar 29 13:13:27 2006 From: dave.price@aber.ac.uk (Dave Price) Date: Wed, 29 Mar 2006 14:13:27 +0100 Subject: [Xorp-users] Interfaces all going "down" In-Reply-To: Your message of Tue, 28 Mar 2006 09:12:38 -0800. <200603281712.k2SHCckV003429@possum.icir.org> Message-ID: <11114.1143638007@aber.ac.uk> Dear Pavlin, pavlin@icir.org said: > If you haven't restarted XORP, what is the output of "show > interfaces", "show mfea interface" and "show igmp interface" xorpsh > commands? I had already restarted it as I had announced to the department that a "multicast trial service" was now available and thus wanted to keep it going if I could... pavlin@icir.org said: > Also, did you notice how long time (hours, days?) it took to get into > this state I think it was probably about 24 -> 48 hours, no more. pavlin@icir.org said: > Finally, do you remember whether the cables connecting the router have > been disconnected and connected back in some stage? I am not aware of any disconnections during that period. There is a "fifth" interface, not plugged in and not mentioned at present in xorp config. You may recall I mentioned problems if that was mentioned while not plugged in a couple of weeks ago. I'll try to stop xorp tonight and swicth on logging etc. Although I have only announced an "experimental" service, I don't really want to disconnect/restart during times I think people might be doing things (like watching BBC TV transmissions!) Thanks, Dave Price From MANJON@terra.es Wed Mar 29 14:41:57 2006 From: MANJON@terra.es (MANJON@terra.es) Date: Wed, 29 Mar 2006 16:41:57 +0200 (MEST) Subject: [Xorp-users] questions about xorp Message-ID: <22130139.1143643317900.JavaMail.root@cps4> ------=_Part_4190_24549736.1143643317893 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Pavlin, I have some questions for you. I have a firewall cluster using xorp for multicast. I have an script that g= et up xorp processses in the active node. Really I have only run xorp in th= e active node. When there is a failover my script run the xorp in the new a= ctive node and kill xorp in the passive one. This is the xorp processes tha= t I start: 1308 ? S 0:01 /opt/bladefusion/xorp/bin/xorp_rtrmgr 1310 ? S 0:49 /opt/bladefusion/xorp/fea/xorp_fea 1381 ? S 0:00 /opt/bladefusion/xorp/rib/xorp_rib 1399 ? S 0:00 /opt/bladefusion/xorp/fib2mrib/xorp_fib2mrib 1417 ? S 0:28 /opt/bladefusion/xorp/mld6igmp/xorp_igmp 1435 ? S 0:05 /opt/bladefusion/xorp/pim/xorp_pimsm4 My question is: Is necessary use xorp_fib2mrib in my system? I haven=C2=B4t= to sync xorp states between nodes because I have only one node running xor= p . My other question is about an error in my /var/log/messages, when my xorp d= ied Mar 28 02:01:41 fw1bjscpd BF-PIM: [ 2006/03/28 02:01:41 ERROR xorp_rtrmgr:2= 2712 XRL +629 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: Keepalive timeout= =20 Mar 28 02:01:41 fw1bjscpd last message repeated 2 times Mar 28 02:01:43 fw1bjscpd BF-PIM: [ 2006/03/28 02:01:43 ERROR xorp_rtrmgr:2= 2712 XRL +629 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: Keepalive timeout= =20 Mar 28 02:01:43 fw1bjscpd BF-PIM: [ 2006/03/28 02:01:43 ERROR xorp_rtrmgr:2= 2712 XRL +629 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: Keepalive timeout= =20 Mar 28 02:01:51 fw1bjscpd BF-PIM: [ 2006/03/28 02:01:51 ERROR xorp_igmp:228= 31 XRL +629 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: Keepalive timeout=20 Mar 28 02:01:51 fw1bjscpd BF-PIM: [ 2006/03/28 02:01:51 ERROR xorp_rib:2279= 5 XRL +629 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: Keepalive timeout=20 Mar 28 02:02:13 fw1bjscpd ntpdate[24855]: adjust time server 55.1.1.8 offse= t -0.054280 sec Mar 28 02:02:21 fw1bjscpd BF-PIM: [ 2006/03/28 02:02:21 ERROR xorp_rtrmgr:2= 2712 XRL +629 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: Keepalive timeout= =20 Mar 28 02:02:24 fw1bjscpd BF-PIM: [ 2006/03/28 02:02:24 INFO xorp_igmp XRL = ] Sender died (protocol =3D "stcp", address =3D "127.0.0.1:63424")=20 Mar 28 02:02:30 fw1bjscpd BF-PIM: [ 2006/03/28 02:02:30 WARNING xorp_pimsm4= PIM ] JoinDesired(*,G) =3D true: RP for group 224.128.191.254: not found= =20 Mar 28 02:02:30 fw1bjscpd BF-PIM: [ 2006/03/28 02:02:30 WARNING xorp_pimsm4= PIM ] JoinDesired(*,G) =3D true: RP for group 224.128.147.254: not found= =20 Mar 28 02:02:30 fw1bjscpd BF-PIM: [ 2006/03/28 02:02:30 WARNING xorp_pimsm4= PIM ] JoinDesired(*,G) =3D true: RP for group 224.128.143.254: not found= =20 Mar 28 02:02:30 fw1bjscpd BF-PIM: [ 2006/03/28 02:02:30 WARNING xorp_pimsm4= PIM ] JoinDesired(*,G) =3D true: RP for group 224.128.79.254: not found=20 Mar 28 02:02:30 fw1bjscpd BF-PIM: [ 2006/03/28 02:02:30 WARNING xorp_pimsm4= PIM ] JoinDesired(*,G) =3D true: RP for group 224.128.145.254: not found= =20 Mar 28 02:02:39 fw1bjscpd BF-PIM: [ 2006/03/28 02:02:39 WARNING xorp_pimsm4= PIM ] JoinDesired(*,G) =3D true: RP for group 224.128.95.254: not found=20 Mar 28 02:03:01 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:01 ERROR xorp_igmp:228= 31 XRL +629 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: Keepalive timeout=20 Mar 28 02:03:00 fw1bjscpd ntpdate[24938]: adjust time server 55.1.1.2 offse= t 0.000875 sec Mar 28 02:03:03 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:03 ERROR xorp_fea:2272= 4 XRL +629 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: Keepalive timeout=20 Mar 28 02:03:03 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:03 ERROR xorp_fea:2272= 4 MFEA +545 xrl_mfea_node.cc mfea_client_client_send_recv_protocol_message_= cb ] XRL communication error: 210 Transport failed=20 Mar 28 02:03:03 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:03 ERROR xorp_fea:2272= 4 MFEA +701 xrl_mfea_node.cc mfea_client_client_send_recv_kernel_signal_mes= sage_cb ] XRL communication error: 210 Transport failed=20 Mar 28 02:03:03 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:03 ERROR xorp_fea:2272= 4 MFEA +701 xrl_mfea_node.cc mfea_client_client_send_recv_kernel_signal_mes= sage_cb ] XRL communication error: 210 Transport failed=20 Mar 28 02:03:03 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:03 ERROR xorp_fea:2272= 4 MFEA +1404 xrl_mfea_node.cc mfea_client_client_send_recv_dataflow_signal_= cb ] XRL communication error: 210 Transport failed=20 Mar 28 02:03:03 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:03 ERROR xorp_fea:2272= 4 MFEA +701 xrl_mfea_node.cc mfea_client_client_send_recv_kernel_signal_mes= sage_cb ] XRL communication error: 210 Transport failed=20 Mar 28 02:03:03 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:03 ERROR xorp_fea:2272= 4 MFEA +1404 xrl_mfea_node.cc mfea_client_client_send_recv_dataflow_signal_= cb ] XRL communication error: 210 Transport failed=20 Mar 28 02:03:03 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:03 ERROR xorp_fea:2272= 4 MFEA +701 xrl_mfea_node.cc mfea_client_client_send_recv_kernel_signal_mes= sage_cb ] XRL communication error: 210 Transport failed=20 Mar 28 02:03:03 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:03 ERROR xorp_fea:2272= 4 MFEA +545 xrl_mfea_node.cc mfea_client_client_send_recv_protocol_message_= cb ] XRL communication error: 210 Transport failed=20 Mar 28 02:03:03 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:03 ERROR xorp_fea:2272= 4 MFEA +701 xrl_mfea_node.cc mfea_client_client_send_recv_kernel_signal_mes= sage_cb ] XRL communication error: 210 Transport failed=20 Mar 28 02:03:03 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:03 ERROR xorp_fea:2272= 4 MFEA +701 xrl_mfea_node.cc mfea_client_client_send_recv_kernel_signal_mes= sage_cb ] XRL communication error: 210 Transport failed=20 Mar 28 02:03:03 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:03 ERROR xorp_fea:2272= 4 MFEA +545 xrl_mfea_node.cc mfea_client_client_send_recv_protocol_message_= cb ] XRL communication error: 210 Transport failed=20 Mar 28 02:03:03 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:03 ERROR xorp_fea:2272= 4 MFEA +701 xrl_mfea_node.cc mfea_client_client_send_recv_kernel_signal_mes= sage_cb ] XRL communication error: 210 Transport failed=20 Mar 28 02:03:03 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:03 ERROR xorp_fea:2272= 4 MFEA +545 xrl_mfea_node.cc mfea_client_client_send_recv_protocol_message_= cb ] XRL communication error: 210 Transport failed=20 Mar 28 02:03:03 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:03 ERROR xorp_fea:2272= 4 MFEA +545 xrl_mfea_node.cc mfea_client_client_send_recv_protocol_message_= cb ] XRL communication error: 210 Transport failed=20 Mar 28 02:03:04 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:04 INFO xorp_fea XRL ]= Sender died (protocol =3D "stcp", address =3D "127.0.0.1:63424")=20 Mar 28 02:03:06 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:06 INFO xorp_igmp XRL = ] Sender died (protocol =3D "stcp", address =3D "127.0.0.1:63424")=20 Mar 28 02:03:06 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:06 ERROR xorp_pimsm4:2= 2866 XRL +629 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: Keepalive timeout= =20 Mar 28 02:03:06 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:06 ERROR xorp_rib:2279= 5 LIBXORP +161 buffered_asyncio.cc selector_event ] read error 104 Connecti= on reset by peer=20 Mar 28 02:03:06 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:06 ERROR xorp_rib:2279= 5 XRL +149 xrl_pf_stcp.cc read_event ] Read failed (errno =3D 104): Connect= ion reset by peer=20 Mar 28 02:03:06 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:06 ERROR xorp_rib:2279= 5 XRL +329 xrl_pf_stcp.cc die ] STCPRequestHandler died: read error=20 Mar 28 02:03:06 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:06 ERROR xorp_pimsm4:2= 2866 XRL +629 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: Keepalive timeout= =20 Mar 28 02:03:06 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:06 ERROR xorp_igmp:228= 31 LIBXORP +161 buffered_asyncio.cc selector_event ] read error 104 Connect= ion reset by peer=20 Mar 28 02:03:06 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:06 ERROR xorp_igmp:228= 31 XRL +149 xrl_pf_stcp.cc read_event ] Read failed (errno =3D 104): Connec= tion reset by peer=20 Mar 28 02:03:06 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:06 ERROR xorp_igmp:228= 31 XRL +329 xrl_pf_stcp.cc die ] STCPRequestHandler died: read error=20 Mar 28 02:03:06 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:06 ERROR xorp_pimsm4:2= 2866 XRL +629 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: Keepalive timeout= =20 Mar 28 02:03:12 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:12 ERROR xorp_pimsm4:2= 2866 XRL +629 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: Keepalive timeout= =20 Mar 28 02:03:12 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:12 ERROR xorp_pimsm4:2= 2866 PIM +2631 xrl_pim_node.cc mfea_client_send_protocol_message_cb ] Canno= t send a protocol message: 210 Transport failed=20 Mar 28 02:03:12 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:12 ERROR xorp_fea:2272= 4 LIBXORP +161 buffered_asyncio.cc selector_event ] read error 104 Connecti= on reset by peer=20 Mar 28 02:03:14 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:14 INFO xorp_pimsm4 XR= L ] Sender died (protocol =3D "stcp", address =3D "127.0.0.1:63391")=20 Mar 28 02:03:14 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:14 ERROR xorp_fea:2272= 4 XRL +149 xrl_pf_stcp.cc read_event ] Read failed (errno =3D 104): Connect= ion reset by peer=20 Mar 28 02:03:17 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:17 ERROR xorp_fea:2272= 4 XRL +329 xrl_pf_stcp.cc die ] STCPRequestHandler died: read error=20 Mar 28 02:03:18 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:18 ERROR xorp_fea:2272= 4 LIBXORP +161 buffered_asyncio.cc selector_event ] read error 104 Connecti= on reset by peer=20 Mar 28 02:03:19 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:19 ERROR xorp_fea:2272= 4 XRL +149 xrl_pf_stcp.cc read_event ] Read failed (errno =3D 104): Connect= ion reset by peer=20 Mar 28 02:03:20 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:20 ERROR xorp_fea:2272= 4 XRL +329 xrl_pf_stcp.cc die ] STCPRequestHandler died: read error=20 Mar 28 02:03:30 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:30 WARNING xorp_pimsm4= PIM ] JoinDesired(*,G) =3D true: RP for group 224.128.191.254: not found= =20 Mar 28 02:03:30 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:30 WARNING xorp_pimsm4= PIM ] JoinDesired(*,G) =3D true: RP for group 224.128.147.254: not found= =20 Mar 28 02:03:30 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:30 WARNING xorp_pimsm4= PIM ] JoinDesired(*,G) =3D true: RP for group 224.128.143.254: not found= =20 Mar 28 02:03:30 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:30 WARNING xorp_pimsm4= PIM ] JoinDesired(*,G) =3D true: RP for group 224.128.79.254: not found=20 Mar 28 02:03:30 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:30 WARNING xorp_pimsm4= PIM ] JoinDesired(*,G) =3D true: RP for group 224.128.145.254: not found= =20 Mar 28 02:03:31 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:31 ERROR xorp_rtrmgr:2= 2712 FINDER +85 finder_xrl_queue.hh dispatch_cb ] Sent xrl got response 211= Reply timed out=20 Mar 28 02:03:31 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:31 ERROR xorp_pimsm4:2= 2866 PIM +240 xrl_pim_node.cc finder_disconnect_event ] Finder disconnect e= vent. Exiting immediately...=20 Mar 28 02:03:31 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:31 INFO xorp_pimsm4 PI= M ] Bootstrap mechanism stopped=20 Mar 28 02:03:31 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:31 WARNING xorp_pimsm4= PIM ] JoinDesired(S,G) =3D false: upstream neighbor for source 55.128.147.= 254 and group 224.128.147.254: not found=20 Mar 28 02:03:31 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:31 WARNING xorp_pimsm4= PIM ] JoinDesired(*,G) =3D false: RP for group 224.128.147.254: not found= =20 Mar 28 02:03:32 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:32 WARNING xorp_pimsm4= PIM ] JoinDesired(S,G) =3D false: upstream neighbor for source 55.128.191.= 254 and group 224.128.191.254: not found=20 Mar 28 02:03:32 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:32 WARNING xorp_pimsm4= PIM ] JoinDesired(*,G) =3D false: RP for group 224.128.191.254: not found= =20 Mar 28 02:03:32 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:32 WARNING xorp_pimsm4= PIM ] JoinDesired(S,G) =3D false: upstream neighbor for source 55.128.79.2= 54 and group 224.128.79.254: not found=20 Mar 28 02:03:32 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:32 WARNING xorp_pimsm4= PIM ] JoinDesired(*,G) =3D false: upstream neighbor for RP 55.63.50.8 for = group 230.230.5.210: not found=20 Mar 28 02:03:32 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:32 WARNING xorp_pimsm4= PIM ] JoinDesired(*,G) =3D false: RP for group 224.128.79.254: not found= =20 Mar 28 02:03:32 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:32 WARNING xorp_pimsm4= PIM ] JoinDesired(S,G) =3D false: upstream neighbor for source 55.128.95.2= 54 and group 224.128.95.254: not found=20 Mar 28 02:03:32 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:32 WARNING xorp_pimsm4= PIM ] JoinDesired(*,G) =3D false: RP for group 224.128.95.254: not found= =20 Mar 28 02:03:32 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:32 WARNING xorp_pimsm4= PIM ] JoinDesired(S,G) =3D false: upstream neighbor for source 55.128.143.= 254 and group 224.128.143.254: not found=20 Mar 28 02:03:33 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:33 WARNING xorp_pimsm4= PIM ] JoinDesired(*,G) =3D false: upstream neighbor for RP 55.63.50.7 for = group 230.230.5.20: not found=20 Mar 28 02:03:32 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:32 WARNING xorp_rtrmgr= :22712 XrlFinderTarget +405 ../xrl/targets/finder_base.cc handle_finder_0_2= _resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdErr= or 102 Command failed Target "PIMSM_4" does not exist or is not enabled.=20 Mar 28 02:03:33 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:33 WARNING xorp_pimsm4= PIM ] JoinDesired(*,G) =3D false: upstream neighbor for RP 55.63.50.7 for = group 230.230.5.40: not found=20 Mar 28 02:03:33 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:33 ERROR xorp_igmp:228= 31 MLD6IGMP +1300 xrl_mld6igmp_node.cc mld6igmp_client_send_add_delete_memb= ership_cb ] XRL communication error: 201 Resolve failed=20 Mar 28 02:03:33 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:33 WARNING xorp_pimsm4= PIM ] JoinDesired(*,G) =3D false: RP for group 224.128.143.254: not found= =20 Mar 28 02:03:33 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:33 WARNING xorp_pimsm4= PIM ] JoinDesired(S,G) =3D false: upstream neighbor for source 55.128.145.= 254 and group 224.128.145.254: not found=20 Mar 28 02:03:33 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:33 WARNING xorp_pimsm4= PIM ] JoinDesired(*,G) =3D false: upstream neighbor for RP 55.63.50.7 for = group 230.230.5.1: not found=20 Mar 28 02:03:33 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:33 WARNING xorp_pimsm4= PIM ] JoinDesired(*,G) =3D false: RP for group 224.128.145.254: not found= =20 Mar 28 02:03:33 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:33 WARNING xorp_pimsm4= PIM ] JoinDesired(S,G) =3D false: upstream neighbor for source 55.128.142.= 2 and group 230.230.5.1: not found=20 Mar 28 02:03:33 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:33 WARNING xorp_pimsm4= PIM ] JoinDesired(S,G) =3D false: upstream neighbor for source 55.128.142.= 3 and group 230.230.5.1: not found=20 Mar 28 02:03:33 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:33 WARNING xorp_pimsm4= PIM ] JoinDesired(S,G) =3D false: upstream neighbor for source 55.128.142.= 20 and group 230.230.5.1: not found=20 Mar 28 02:03:33 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:33 WARNING xorp_pimsm4= PIM ] JoinDesired(S,G) =3D false: upstream neighbor for source 55.128.142.= 21 and group 230.230.5.1: not found=20 Mar 28 02:03:34 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:34 WARNING xorp_pimsm4= PIM ] JoinDesired(S,G) =3D false: upstream neighbor for source 55.128.142.= 22 and group 230.230.5.1: not found=20 Mar 28 02:03:34 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:34 WARNING xorp_pimsm4= PIM ] JoinDesired(S,G) =3D false: upstream neighbor for source 55.128.142.= 23 and group 230.230.5.1: not found=20 Mar 28 02:03:34 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:34 WARNING xorp_rtrmgr= :22712 XrlFinderTarget +405 ../xrl/targets/finder_base.cc handle_finder_0_2= _resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdErr= or 102 Command failed Target "PIMSM_4" does not exist or is not enabled.=20 Mar 28 02:03:34 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:34 WARNING xorp_pimsm4= PIM ] JoinDesired(S,G) =3D false: upstream neighbor for source 55.128.142.= 24 and group 230.230.5.1: not found=20 Mar 28 02:03:34 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:34 ERROR xorp_rib:2279= 5 RIB +845 redist_xrl.cc dispatch_complete ] Fatal error during start trans= action: 201 Resolve failed=20 Mar 28 02:03:34 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:34 WARNING xorp_pimsm4= PIM ] JoinDesired(S,G) =3D false: upstream neighbor for source 55.128.142.= 25 and group 230.230.5.1: not found=20 Mar 28 02:03:34 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:34 WARNING xorp_pimsm4= PIM ] JoinDesired(S,G) =3D false: upstream neighbor for source 55.128.142.= 26 and group 230.230.5.1: not found=20 Mar 28 02:03:34 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:34 INFO xorp_rtrmgr:22= 712 RTRMGR +1009 task.cc shutdown ] Shutting down module: pimsm4=20 Mar 28 02:03:34 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:34 WARNING xorp_pimsm4= PIM ] JoinDesired(S,G) =3D false: upstream neighbor for source 55.128.142.= 27 and group 230.230.5.1: not found=20 Mar 28 02:03:34 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:34 WARNING xorp_rtrmgr= :22712 XrlFinderTarget +405 ../xrl/targets/finder_base.cc handle_finder_0_2= _resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdErr= or 102 Command failed Target "PIMSM_4" does not exist or is not enabled.=20 Mar 28 02:03:34 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:34 WARNING xorp_pimsm4= PIM ] JoinDesired(S,G) =3D false: upstream neighbor for source 55.128.142.= 28 and group 230.230.5.1: not found=20 Mar 28 02:03:34 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:34 WARNING xorp_rtrmgr= :22712 XrlFinderTarget +405 ../xrl/targets/finder_base.cc handle_finder_0_2= _resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdErr= or 102 Command failed Target "PIMSM_4" does not exist or is not enabled.=20 Thanks a lot Pavlin.=20 Jose Maria Martin=20 =09=09 TERRA=20 --> ------=_Part_4190_24549736.1143643317893 Content-Type: text/html;charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello Pavlin,

I have some questions for you.

I have a firewall cluster using xorp for multicast. I have an scrip= t that get up xorp processses in the active node. Really I have only r= un xorp in the active node. When there is a failover my script run the xorp= in the new active node and kill xorp in the passive one. This is the xorp = processes that I start:

 1308 ?        S  &nbs= p;   0:01 /opt/bladefusion/xorp/bin/xorp_rtrmgr
 1310 ?&n= bsp;       S      0:= 49 /opt/bladefusion/xorp/fea/xorp_fea
 1381 ?   &nbs= p;    S      0:00 /opt/bladefusion/= xorp/rib/xorp_rib
 1399 ?       = S      0:00 /opt/bladefusion/xorp/fib2mrib/xorp_f= ib2mrib
 1417 ?        S &n= bsp;    0:28 /opt/bladefusion/xorp/mld6igmp/xorp_igmp
&nb= sp;1435 ?        S   &nbs= p;  0:05 /opt/bladefusion/xorp/pim/xorp_pimsm4

My question is: Is necessary use xorp_fib2mrib in my system? I haven=C2= =B4t to sync xorp states between nodes because I have only one node running= xorp .

My other question is about an error in my /var/log/messages, when my xor= p died

Mar 28 02:01:41 fw1bjscpd BF-PIM: [ 2006/03/28 02:01:41 ERROR xorp_rtrmg= r:22712 XRL +629 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: Keepalive timeo= ut

Mar 28 02:01:41 fw1bjscpd last message repeated 2 times

Mar 28 02:01:43 fw1bjscpd BF-PIM: [ 2006/03/28 02:01:43 ERROR xorp_rtrmg= r:22712 XRL +629 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: Keepalive timeo= ut

Mar 28 02:01:43 fw1bjscpd BF-PIM: [ 2006/03/28 02:01:43 ERROR xorp_rtrmg= r:22712 XRL +629 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: Keepalive timeo= ut

Mar 28 02:01:51 fw1bjscpd BF-PIM: [ 2006/03/28 02:01:51 ERROR xorp_igmp:= 22831 XRL +629 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: Keepalive timeout=

Mar 28 02:01:51 fw1bjscpd BF-PIM: [ 2006/03/28 02:01:51 ERROR xorp_rib:2= 2795 XRL +629 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: Keepalive timeout =

Mar 28 02:02:13 fw1bjscpd ntpdate[24855]: adjust time server 55.1.1.8 of= fset -0.054280 sec

Mar 28 02:02:21 fw1bjscpd BF-PIM: [ 2006/03/28 02:02:21 ERROR xorp_rtrmg= r:22712 XRL +629 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: Keepalive timeo= ut

Mar 28 02:02:24 fw1bjscpd BF-PIM: [ 2006/03/28 02:02:24 INFO xorp_igmp X= RL ] Sender died (protocol =3D "stcp", address =3D "127.0.0.1:63424")

Mar 28 02:02:30 fw1bjscpd BF-PIM: [ 2006/03/28 02:02:30 WARNING xorp_pim= sm4 PIM ] JoinDesired(*,G) =3D true: RP for group 224.128.191.254: not foun= d

Mar 28 02:02:30 fw1bjscpd BF-PIM: [ 2006/03/28 02:02:30 WARNING xorp_pim= sm4 PIM ] JoinDesired(*,G) =3D true: RP for group 224.128.147.254: not foun= d

Mar 28 02:02:30 fw1bjscpd BF-PIM: [ 2006/03/28 02:02:30 WARNING xorp_pim= sm4 PIM ] JoinDesired(*,G) =3D true: RP for group 224.128.143.254: not foun= d

Mar 28 02:02:30 fw1bjscpd BF-PIM: [ 2006/03/28 02:02:30 WARNING xorp_pim= sm4 PIM ] JoinDesired(*,G) =3D true: RP for group 224.128.79.254: not found=

Mar 28 02:02:30 fw1bjscpd BF-PIM: [ 2006/03/28 02:02:30 WARNING xorp_pim= sm4 PIM ] JoinDesired(*,G) =3D true: RP for group 224.128.145.254: not foun= d

Mar 28 02:02:39 fw1bjscpd BF-PIM: [ 2006/03/28 02:02:39 WARNING xorp_pim= sm4 PIM ] JoinDesired(*,G) =3D true: RP for group 224.128.95.254: not found=

Mar 28 02:03:01 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:01 ERROR xorp_igmp:= 22831 XRL +629 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: Keepalive timeout=

Mar 28 02:03:00 fw1bjscpd ntpdate[24938]: adjust time server 55.1.1.2 of= fset 0.000875 sec

Mar 28 02:03:03 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:03 ERROR xorp_fea:2= 2724 XRL +629 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: Keepalive timeout =

Mar 28 02:03:03 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:03 ERROR xorp_fea:2= 2724 MFEA +545 xrl_mfea_node.cc mfea_client_client_send_recv_protocol_messa= ge_cb ] XRL communication error: 210 Transport failed

Mar 28 02:03:03 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:03 ERROR xorp_fea:2= 2724 MFEA +701 xrl_mfea_node.cc mfea_client_client_send_recv_kernel_signal_= message_cb ] XRL communication error: 210 Transport failed

Mar 28 02:03:03 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:03 ERROR xorp_fea:2= 2724 MFEA +701 xrl_mfea_node.cc mfea_client_client_send_recv_kernel_signal_= message_cb ] XRL communication error: 210 Transport failed

Mar 28 02:03:03 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:03 ERROR xorp_fea:2= 2724 MFEA +1404 xrl_mfea_node.cc mfea_client_client_send_recv_dataflow_sign= al_cb ] XRL communication error: 210 Transport failed

Mar 28 02:03:03 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:03 ERROR xorp_fea:2= 2724 MFEA +701 xrl_mfea_node.cc mfea_client_client_send_recv_kernel_signal_= message_cb ] XRL communication error: 210 Transport failed

Mar 28 02:03:03 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:03 ERROR xorp_fea:2= 2724 MFEA +1404 xrl_mfea_node.cc mfea_client_client_send_recv_dataflow_sign= al_cb ] XRL communication error: 210 Transport failed

Mar 28 02:03:03 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:03 ERROR xorp_fea:2= 2724 MFEA +701 xrl_mfea_node.cc mfea_client_client_send_recv_kernel_signal_= message_cb ] XRL communication error: 210 Transport failed

Mar 28 02:03:03 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:03 ERROR xorp_fea:2= 2724 MFEA +545 xrl_mfea_node.cc mfea_client_client_send_recv_protocol_messa= ge_cb ] XRL communication error: 210 Transport failed

Mar 28 02:03:03 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:03 ERROR xorp_fea:2= 2724 MFEA +701 xrl_mfea_node.cc mfea_client_client_send_recv_kernel_signal_= message_cb ] XRL communication error: 210 Transport failed

Mar 28 02:03:03 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:03 ERROR xorp_fea:2= 2724 MFEA +701 xrl_mfea_node.cc mfea_client_client_send_recv_kernel_signal_= message_cb ] XRL communication error: 210 Transport failed

Mar 28 02:03:03 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:03 ERROR xorp_fea:2= 2724 MFEA +545 xrl_mfea_node.cc mfea_client_client_send_recv_protocol_messa= ge_cb ] XRL communication error: 210 Transport failed

Mar 28 02:03:03 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:03 ERROR xorp_fea:2= 2724 MFEA +701 xrl_mfea_node.cc mfea_client_client_send_recv_kernel_signal_= message_cb ] XRL communication error: 210 Transport failed

Mar 28 02:03:03 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:03 ERROR xorp_fea:2= 2724 MFEA +545 xrl_mfea_node.cc mfea_client_client_send_recv_protocol_messa= ge_cb ] XRL communication error: 210 Transport failed

Mar 28 02:03:03 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:03 ERROR xorp_fea:2= 2724 MFEA +545 xrl_mfea_node.cc mfea_client_client_send_recv_protocol_messa= ge_cb ] XRL communication error: 210 Transport failed

Mar 28 02:03:04 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:04 INFO xorp_fea XR= L ] Sender died (protocol =3D "stcp", address =3D "127.0.0.1:63424")

Mar 28 02:03:06 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:06 INFO xorp_igmp X= RL ] Sender died (protocol =3D "stcp", address =3D "127.0.0.1:63424")

Mar 28 02:03:06 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:06 ERROR xorp_pimsm= 4:22866 XRL +629 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: Keepalive timeo= ut

Mar 28 02:03:06 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:06 ERROR xorp_rib:2= 2795 LIBXORP +161 buffered_asyncio.cc selector_event ] read error 104 Conne= ction reset by peer

Mar 28 02:03:06 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:06 ERROR xorp_rib:2= 2795 XRL +149 xrl_pf_stcp.cc read_event ] Read failed (errno =3D 104): Conn= ection reset by peer

Mar 28 02:03:06 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:06 ERROR xorp_rib:2= 2795 XRL +329 xrl_pf_stcp.cc die ] STCPRequestHandler died: read error

Mar 28 02:03:06 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:06 ERROR xorp_pimsm= 4:22866 XRL +629 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: Keepalive timeo= ut

Mar 28 02:03:06 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:06 ERROR xorp_igmp:= 22831 LIBXORP +161 buffered_asyncio.cc selector_event ] read error 104 Conn= ection reset by peer

Mar 28 02:03:06 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:06 ERROR xorp_igmp:= 22831 XRL +149 xrl_pf_stcp.cc read_event ] Read failed (errno =3D 104): Con= nection reset by peer

Mar 28 02:03:06 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:06 ERROR xorp_igmp:= 22831 XRL +329 xrl_pf_stcp.cc die ] STCPRequestHandler died: read error

Mar 28 02:03:06 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:06 ERROR xorp_pimsm= 4:22866 XRL +629 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: Keepalive timeo= ut

Mar 28 02:03:12 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:12 ERROR xorp_pimsm= 4:22866 XRL +629 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: Keepalive timeo= ut

Mar 28 02:03:12 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:12 ERROR xorp_pimsm= 4:22866 PIM +2631 xrl_pim_node.cc mfea_client_send_protocol_message_cb ] Ca= nnot send a protocol message: 210 Transport failed

Mar 28 02:03:12 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:12 ERROR xorp_fea:2= 2724 LIBXORP +161 buffered_asyncio.cc selector_event ] read error 104 Conne= ction reset by peer

Mar 28 02:03:14 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:14 INFO xorp_pimsm4= XRL ] Sender died (protocol =3D "stcp", address =3D "127.0.0.1:63391")

Mar 28 02:03:14 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:14 ERROR xorp_fea:2= 2724 XRL +149 xrl_pf_stcp.cc read_event ] Read failed (errno =3D 104): Conn= ection reset by peer

Mar 28 02:03:17 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:17 ERROR xorp_fea:2= 2724 XRL +329 xrl_pf_stcp.cc die ] STCPRequestHandler died: read error

Mar 28 02:03:18 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:18 ERROR xorp_fea:2= 2724 LIBXORP +161 buffered_asyncio.cc selector_event ] read error 104 Conne= ction reset by peer

Mar 28 02:03:19 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:19 ERROR xorp_fea:2= 2724 XRL +149 xrl_pf_stcp.cc read_event ] Read failed (errno =3D 104): Conn= ection reset by peer

Mar 28 02:03:20 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:20 ERROR xorp_fea:2= 2724 XRL +329 xrl_pf_stcp.cc die ] STCPRequestHandler died: read error

Mar 28 02:03:30 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:30 WARNING xorp_pim= sm4 PIM ] JoinDesired(*,G) =3D true: RP for group 224.128.191.254: not foun= d

Mar 28 02:03:30 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:30 WARNING xorp_pim= sm4 PIM ] JoinDesired(*,G) =3D true: RP for group 224.128.147.254: not foun= d

Mar 28 02:03:30 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:30 WARNING xorp_pim= sm4 PIM ] JoinDesired(*,G) =3D true: RP for group 224.128.143.254: not foun= d

Mar 28 02:03:30 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:30 WARNING xorp_pim= sm4 PIM ] JoinDesired(*,G) =3D true: RP for group 224.128.79.254: not found=

Mar 28 02:03:30 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:30 WARNING xorp_pim= sm4 PIM ] JoinDesired(*,G) =3D true: RP for group 224.128.145.254: not foun= d

Mar 28 02:03:31 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:31 ERROR xorp_rtrmg= r:22712 FINDER +85 finder_xrl_queue.hh dispatch_cb ] Sent xrl got response = 211 Reply timed out

Mar 28 02:03:31 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:31 ERROR xorp_pimsm= 4:22866 PIM +240 xrl_pim_node.cc finder_disconnect_event ] Finder disconnec= t event. Exiting immediately...

Mar 28 02:03:31 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:31 INFO xorp_pimsm4= PIM ] Bootstrap mechanism stopped

Mar 28 02:03:31 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:31 WARNING xorp_pim= sm4 PIM ] JoinDesired(S,G) =3D false: upstream neighbor for source 55.128.1= 47.254 and group 224.128.147.254: not found

Mar 28 02:03:31 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:31 WARNING xorp_pim= sm4 PIM ] JoinDesired(*,G) =3D false: RP for group 224.128.147.254: not fou= nd

Mar 28 02:03:32 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:32 WARNING xorp_pim= sm4 PIM ] JoinDesired(S,G) =3D false: upstream neighbor for source 55.128.1= 91.254 and group 224.128.191.254: not found

Mar 28 02:03:32 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:32 WARNING xorp_pim= sm4 PIM ] JoinDesired(*,G) =3D false: RP for group 224.128.191.254: not fou= nd

Mar 28 02:03:32 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:32 WARNING xorp_pim= sm4 PIM ] JoinDesired(S,G) =3D false: upstream neighbor for source 55.128.7= 9.254 and group 224.128.79.254: not found

Mar 28 02:03:32 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:32 WARNING xorp_pim= sm4 PIM ] JoinDesired(*,G) =3D false: upstream neighbor for RP 55.63.50.8 f= or group 230.230.5.210: not found

Mar 28 02:03:32 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:32 WARNING xorp_pim= sm4 PIM ] JoinDesired(*,G) =3D false: RP for group 224.128.79.254: not foun= d

Mar 28 02:03:32 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:32 WARNING xorp_pim= sm4 PIM ] JoinDesired(S,G) =3D false: upstream neighbor for source 55.128.9= 5.254 and group 224.128.95.254: not found

Mar 28 02:03:32 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:32 WARNING xorp_pim= sm4 PIM ] JoinDesired(*,G) =3D false: RP for group 224.128.95.254: not foun= d

Mar 28 02:03:32 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:32 WARNING xorp_pim= sm4 PIM ] JoinDesired(S,G) =3D false: upstream neighbor for source 55.128.1= 43.254 and group 224.128.143.254: not found

Mar 28 02:03:33 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:33 WARNING xorp_pim= sm4 PIM ] JoinDesired(*,G) =3D false: upstream neighbor for RP 55.63.50.7 f= or group 230.230.5.20: not found

Mar 28 02:03:32 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:32 WARNING xorp_rtr= mgr:22712 XrlFinderTarget +405 ../xrl/targets/finder_base.cc handle_finder_= 0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmd= Error 102 Command failed Target "PIMSM_4" does not exist or is not enabled.=

Mar 28 02:03:33 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:33 WARNING xorp_pim= sm4 PIM ] JoinDesired(*,G) =3D false: upstream neighbor for RP 55.63.50.7 f= or group 230.230.5.40: not found

Mar 28 02:03:33 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:33 ERROR xorp_igmp:= 22831 MLD6IGMP +1300 xrl_mld6igmp_node.cc mld6igmp_client_send_add_delete_m= embership_cb ] XRL communication error: 201 Resolve failed

Mar 28 02:03:33 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:33 WARNING xorp_pim= sm4 PIM ] JoinDesired(*,G) =3D false: RP for group 224.128.143.254: not fou= nd

Mar 28 02:03:33 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:33 WARNING xorp_pim= sm4 PIM ] JoinDesired(S,G) =3D false: upstream neighbor for source 55.128.1= 45.254 and group 224.128.145.254: not found

Mar 28 02:03:33 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:33 WARNING xorp_pim= sm4 PIM ] JoinDesired(*,G) =3D false: upstream neighbor for RP 55.63.50.7 f= or group 230.230.5.1: not found

Mar 28 02:03:33 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:33 WARNING xorp_pim= sm4 PIM ] JoinDesired(*,G) =3D false: RP for group 224.128.145.254: not fou= nd

Mar 28 02:03:33 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:33 WARNING xorp_pim= sm4 PIM ] JoinDesired(S,G) =3D false: upstream neighbor for source 55.128.1= 42.2 and group 230.230.5.1: not found

Mar 28 02:03:33 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:33 WARNING xorp_pim= sm4 PIM ] JoinDesired(S,G) =3D false: upstream neighbor for source 55.128.1= 42.3 and group 230.230.5.1: not found

Mar 28 02:03:33 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:33 WARNING xorp_pim= sm4 PIM ] JoinDesired(S,G) =3D false: upstream neighbor for source 55.128.1= 42.20 and group 230.230.5.1: not found

Mar 28 02:03:33 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:33 WARNING xorp_pim= sm4 PIM ] JoinDesired(S,G) =3D false: upstream neighbor for source 55.128.1= 42.21 and group 230.230.5.1: not found

Mar 28 02:03:34 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:34 WARNING xorp_pim= sm4 PIM ] JoinDesired(S,G) =3D false: upstream neighbor for source 55.128.1= 42.22 and group 230.230.5.1: not found

Mar 28 02:03:34 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:34 WARNING xorp_pim= sm4 PIM ] JoinDesired(S,G) =3D false: upstream neighbor for source 55.128.1= 42.23 and group 230.230.5.1: not found

Mar 28 02:03:34 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:34 WARNING xorp_rtr= mgr:22712 XrlFinderTarget +405 ../xrl/targets/finder_base.cc handle_finder_= 0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmd= Error 102 Command failed Target "PIMSM_4" does not exist or is not enabled.=

Mar 28 02:03:34 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:34 WARNING xorp_pim= sm4 PIM ] JoinDesired(S,G) =3D false: upstream neighbor for source 55.128.1= 42.24 and group 230.230.5.1: not found

Mar 28 02:03:34 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:34 ERROR xorp_rib:2= 2795 RIB +845 redist_xrl.cc dispatch_complete ] Fatal error during start tr= ansaction: 201 Resolve failed

Mar 28 02:03:34 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:34 WARNING xorp_pim= sm4 PIM ] JoinDesired(S,G) =3D false: upstream neighbor for source 55.128.1= 42.25 and group 230.230.5.1: not found

Mar 28 02:03:34 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:34 WARNING xorp_pim= sm4 PIM ] JoinDesired(S,G) =3D false: upstream neighbor for source 55.128.1= 42.26 and group 230.230.5.1: not found

Mar 28 02:03:34 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:34 INFO xorp_rtrmgr= :22712 RTRMGR +1009 task.cc shutdown ] Shutting down module: pimsm4

Mar 28 02:03:34 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:34 WARNING xorp_pim= sm4 PIM ] JoinDesired(S,G) =3D false: upstream neighbor for source 55.128.1= 42.27 and group 230.230.5.1: not found

Mar 28 02:03:34 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:34 WARNING xorp_rtr= mgr:22712 XrlFinderTarget +405 ../xrl/targets/finder_base.cc handle_finder_= 0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmd= Error 102 Command failed Target "PIMSM_4" does not exist or is not enabled.=

Mar 28 02:03:34 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:34 WARNING xorp_pim= sm4 PIM ] JoinDesired(S,G) =3D false: upstream neighbor for source 55.128.1= 42.28 and group 230.230.5.1: not found

Mar 28 02:03:34 fw1bjscpd BF-PIM: [ 2006/03/28 02:03:34 WARNING xorp_rtr= mgr:22712 XrlFinderTarget +405 ../xrl/targets/finder_base.cc handle_finder_= 0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmd= Error 102 Command failed Target "PIMSM_4" does not exist or is not enabled.=

Thanks a lot Pavlin. 

Jose Maria Martin 

------=_Part_4190_24549736.1143643317893-- From pavlin@icir.org Thu Mar 30 03:11:25 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Wed, 29 Mar 2006 19:11:25 -0800 Subject: [Xorp-users] questions about xorp In-Reply-To: Message from "MANJON@terra.es" of "Wed, 29 Mar 2006 16:41:57 +0200." <22130139.1143643317900.JavaMail.root@cps4> Message-ID: <200603300311.k2U3BPDF018293@possum.icir.org> > I have a firewall cluster using xorp for multicast. I have an script that g= > et up xorp processses in the active node. Really I have only run xorp in th= > e active node. When there is a failover my script run the xorp in the new a= > ctive node and kill xorp in the passive one. This is the xorp processes tha= > t I start: > > 1308 ? S 0:01 /opt/bladefusion/xorp/bin/xorp_rtrmgr > 1310 ? S 0:49 /opt/bladefusion/xorp/fea/xorp_fea > 1381 ? S 0:00 /opt/bladefusion/xorp/rib/xorp_rib > 1399 ? S 0:00 /opt/bladefusion/xorp/fib2mrib/xorp_fib2mrib > 1417 ? S 0:28 /opt/bladefusion/xorp/mld6igmp/xorp_igmp > 1435 ? S 0:05 /opt/bladefusion/xorp/pim/xorp_pimsm4 > > My question is: Is necessary use xorp_fib2mrib in my system? I haven=C2=B4t= > to sync xorp states between nodes because I have only one node running xor= > p . For all practical purpose, the answer is "yes". Process xorp_fib2mrib is used to obtain the unicast forwarding state from the kernel (via the FEA) and push it into the Multicast RIB (which is needed by PIM-SM for the reverse-path forwarding check). > My other question is about an error in my /var/log/messages, when my xorp d= > ied > > Mar 28 02:01:41 fw1bjscpd BF-PIM: [ 2006/03/28 02:01:41 ERROR xorp_rtrmgr:2= > 2712 XRL +629 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: Keepalive timeout= > =20 This error (and all other errors) is problematic. This message shows some XRL communication problems: the keepalive to some of the other XORP processes has timeout. All other errors are probably a direct or indirect result of those XRL timeouts. Do you see those errors during the switchover, or well after the switchover was completed? If they happen during the switchover then something has gone wrong. E.g., if you are starting a new instance of XORP, first you must make sure that all processes from the old instance have been killed. Otherwise, they may inflict on the new XORP instance. If you start seeing the errors well after the switchover has completed, then the following log message might be a suspect: > Mar 28 02:02:13 fw1bjscpd ntpdate[24855]: adjust time server 55.1.1.8 offse= > t -0.054280 sec In general, adjusting the time backwards doesn't play well with XORP, so the above adjustment _may_ have something to do with XRL keepalive timeout. The easiest way to test this is temporary to turn off NTP and see whether you still get keepalive timeouts. Pavlin From lists@yazzy.org Thu Mar 30 14:25:36 2006 From: lists@yazzy.org (Marcin Jessa) Date: Thu, 30 Mar 2006 14:25:36 +0000 Subject: [Xorp-users] Vyatta Message-ID: <20060330142536.8f4c9453.lists@yazzy.org> Hi guys. Is www.vyatta.com a fork of XORP or does it exchange sources with the XORP project ? I tested their LiveCD and it seemed to have many features I could not see it the src tree of the "vanilla" XORP. Features like web service runnking lighttpd with a web interface. I realize vyatta is Linux-centric and uses custom build with busybox etc but would it be difficult to incorporate the web interface into XORP ? And that leads to my second question. How modular is XORP, would it be possible to compile it with support for just a few features and/or add new features like e.g configuration of wireless devices? Cheers, Marcin. From kristian@juniks.net Thu Mar 30 14:43:54 2006 From: kristian@juniks.net (Kristian Larsson) Date: Thu, 30 Mar 2006 16:43:54 +0200 Subject: [Xorp-users] Vyatta In-Reply-To: <20060330142536.8f4c9453.lists@yazzy.org> References: <20060330142536.8f4c9453.lists@yazzy.org> Message-ID: <20060330144353.GD24663@juniks.net> On Thu, Mar 30, 2006 at 02:25:36PM +0000, Marcin Jessa wrote: > Hi guys. > > Is www.vyatta.com a fork of XORP or does it exchange sources > with the XORP project ? > I tested their LiveCD and it seemed to have many features I > could not see it the src tree of the "vanilla" XORP. > Features like web service runnking lighttpd with a web interface. > I realize vyatta is Linux-centric and uses custom build with busybox etc > but would it be difficult to incorporate the web interface into XORP ? > > And that leads to my second question. > How modular is XORP, would it be possible to compile it with support for > just a few features and/or add new features like e.g configuration of wireless devices? Vyatta is utilizing XORP as a foundation. XORP is the active routing component in Vyatta and the xorpsh is utilized as well. The Vyatta team has then added a lot of things, for example it is possible to configure users, a few services, firewalling rules and so on via the CLI. This is not possible in the standard XORP package. Although I've worked a bit with the Vyatta projects OFR I haven't come around to trying the web interface so can't answer that bit. XORP is rather modular. There is currently no support for configuration of wireless devices, but this could be added if someone just sat down and wrote some code :) Regards, Kristian. From dave.price@aber.ac.uk Thu Mar 30 15:06:33 2006 From: dave.price@aber.ac.uk (Dave Price) Date: Thu, 30 Mar 2006 16:06:33 +0100 Subject: [Xorp-users] Interfaces all going "down" In-Reply-To: Your message of Tue, 28 Mar 2006 09:12:38 -0800. <200603281712.k2SHCckV003429@possum.icir.org> Message-ID: <13890.1143731193@aber.ac.uk> This is a multipart MIME message. --==_Exmh_-9088102260 Content-Type: text/plain; charset=us-ascii Dear Pavlin and all, My XORP box has disabled all interfaces again at the XORP level although all fine at Linux/ifconfig level. pavlin@icir.org said: > If you haven't restarted XORP As I mentioned, I had restarted it when you last emailed. It has now gone into the same state again with all interfaces down. I have still not yet enabled logging, but I will do on the next restart. pavlin@icir.org said: > Also, did you notice how long time (hours, days?) it took to get into > this state I noticed it was definitly in this state a couple of hours ago, but from other problems I spotted elsewhere, I suspect it had gone into this state at about 08.50 this morning (30/3/2006). At that time multicast reception on other boxes stopped. The previous restart had been at about 14:20 on 28/3/2006. pavlin@icir.org said: > what is the output of "show interfaces", "show mfea interface" and > "show igmp interface" xorpsh commands? I ran those plus a few other things... Here's the output ===================================================== Welcome to XORP on trollope.dcs.aber.ac.uk xorp@trollope.dcs.aber.ac.uk> ? Possible completions: configure Switch to configuration mode help Provide help with commands ping Ping a hostname or IP address ping6 Ping an IPv6 hostname or IPv6 address quit Quit this command session show Display information about the system traceroute Trace the IP route to a hostname or IP address traceroute6 Trace the IPv6 route to a hostname or IPv6 address xorp@trollope.dcs.aber.ac.uk> show pim neighbors Interface DRpriority NeighborAddr V Mode Holdtime Timeout xorp@trollope.dcs.aber.ac.uk> show pim interface ? Possible completions: <[Enter]> Execute this command address Display information about addresses of PIM IPv4 interfaces | Pipe through a command xorp@trollope.dcs.aber.ac.uk> show pim interface Interface State Mode V PIMstate Priority DRaddr Neighbors discard0 DISABLED Sparse 2 DR 1 127.127.0.1 0 eth1 DOWN Sparse 2 NotDR 1 0.0.0.0 0 eth2 DOWN Sparse 2 NotDR 1 0.0.0.0 0 eth3 DOWN Sparse 2 NotDR 1 0.0.0.0 0 eth4 DOWN Sparse 2 NotDR 1 0.0.0.0 0 register_vif DOWN Sparse 2 DR 1 0.0.0.0 0 xorp@trollope.dcs.aber.ac.uk> show interfaces Command interrupted! xorp@trollope.dcs.aber.ac.uk> show mfea interface Error: 201 Resolve failed ERROR: Command "/usr/local/xorp/cli/tools/send_cli_processor_xrl": exited with exit status 1. xorp@trollope.dcs.aber.ac.uk> show igmp interface ^ syntax error, expecting . xorp@trollope.dcs.aber.ac.uk> show ? Possible completions: host Display information about the host interfaces Show network interface information mfea Display information about IPv4 MFEA pim Display information about IPv4 PIM route Show routes xorp@trollope.dcs.aber.ac.uk> ===================================================== The "show interfaces" hung for an hour with no output at all! As you can see, it claims "show igmp interface" is not a valid command! pavlin@icir.org said: > Finally, do you remember whether the cables connecting the router have > been disconnected and connected back in some stage As far as I am aware, no cables were disconnected. I don't know whether any upstream routers/switches got rebooted to be honest. I'll attach my config file and I have also pasted in the process listing below. Machine running Fedora Core 4 as of mid Jan. Any ideas? I'll now restart again, this time with logging enabled. Thanks, Dave Price [dap@trollope ~]$ ps -ef UID PID PPID C STIME TTY TIME CMD root 1 0 0 Mar28 ? 00:00:04 init [5] root 2 1 0 Mar28 ? 00:00:00 [ksoftirqd/0] root 3 1 0 Mar28 ? 00:00:00 [watchdog/0] root 4 1 0 Mar28 ? 00:00:00 [events/0] root 5 1 0 Mar28 ? 00:00:00 [khelper] root 6 1 0 Mar28 ? 00:00:00 [kthread] root 8 6 0 Mar28 ? 00:00:00 [kacpid] root 67 6 0 Mar28 ? 00:00:00 [kblockd/0] root 70 1 0 Mar28 ? 00:00:00 [khubd] root 116 6 0 Mar28 ? 00:00:00 [pdflush] root 117 6 0 Mar28 ? 00:00:00 [pdflush] root 119 6 0 Mar28 ? 00:00:00 [aio/0] root 118 1 0 Mar28 ? 00:00:00 [kswapd0] root 206 1 0 Mar28 ? 00:00:00 [kseriod] root 364 1 0 Mar28 ? 00:00:00 [kjournald] root 823 1 0 Mar28 ? 00:00:00 udevd root 908 1 0 Mar28 ? 00:00:00 [kgameportd] root 1330 1 0 Mar28 ? 00:00:00 [kjournald] root 1958 1 0 Mar28 ? 00:00:00 syslogd -m 0 root 1960 1 0 Mar28 ? 00:00:00 klogd -x rpc 1977 1 0 Mar28 ? 00:00:00 portmap rpcuser 1995 1 0 Mar28 ? 00:00:00 rpc.statd root 2009 1 0 Mar28 ? 00:00:00 auditd root 2013 6 0 Mar28 ? 00:00:00 [kauditd] root 2038 1 0 Mar28 ? 00:00:01 rpc.idmapd root 2051 1 0 Mar28 ? 00:00:00 hcid: processing events root 2055 1 0 Mar28 ? 00:00:00 sdpd root 2074 1 0 Mar28 ? 00:00:00 [krfcommd] root 2213 1 0 Mar28 ? 00:00:00 /usr/sbin/automount --timeout=60 /misc file /etc/auto.misc root 2245 1 0 Mar28 ? 00:00:00 /usr/sbin/automount --timeout=60 /net program /etc/auto.net root 2260 1 0 Mar28 ? 00:02:57 nifd -n nobody 2290 1 0 Mar28 ? 00:00:00 mDNSResponder root 2300 1 0 Mar28 ? 00:00:00 /usr/sbin/smartd root 2308 1 0 Mar28 ? 00:00:00 /usr/sbin/acpid root 2334 1 0 Mar28 ? 00:00:00 cupsd root 2370 1 0 Mar28 ? 00:00:00 /usr/sbin/sshd root 2379 1 0 Mar28 ? 00:00:00 xinetd -stayalive -pidfile /var/run/xinetd.pid root 2396 1 0 Mar28 ? 00:00:00 sendmail: accepting connections smmsp 2402 1 0 Mar28 ? 00:00:00 sendmail: Queue runner@01:00:00 for /var/spool/clientmqueue root 2411 1 0 Mar28 ? 00:00:00 gpm -m /dev/input/mice -t imps2 iiimd 2441 1 0 Mar28 ? 00:00:00 /usr/bin/iiimd canna 2451 1 0 Mar28 ? 00:00:01 /usr/sbin/cannaserver -syslog -u canna root 2460 1 0 Mar28 ? 00:00:00 crond xfs 2495 1 0 Mar28 ? 00:00:00 xfs -droppriv -daemon root 2502 1 1 Mar28 ? 00:34:51 /usr/local/xorp/bin/xorp_rtrmgr -b /usr/local/xorp/config.boot root 2516 1 0 Mar28 ? 00:00:00 /usr/sbin/atd dbus 2529 1 0 Mar28 ? 00:00:00 dbus-daemon --system root 2541 1 0 Mar28 ? 00:00:00 cups-config-daemon root 2551 1 0 Mar28 ? 00:00:01 hald --retain-privileges root 2556 2551 0 Mar28 ? 00:00:00 hald-addon-acpi root 2567 2551 0 Mar28 ? 00:00:21 hald-addon-storage root 2580 1 0 Mar28 tty1 00:00:00 /sbin/mingetty tty1 root 2581 1 0 Mar28 tty2 00:00:00 /sbin/mingetty tty2 root 2604 1 0 Mar28 tty3 00:00:00 /sbin/mingetty tty3 root 2607 1 0 Mar28 tty4 00:00:00 /sbin/mingetty tty4 root 2613 1 0 Mar28 tty5 00:00:00 /sbin/mingetty tty5 root 2619 1 0 Mar28 tty6 00:00:00 /sbin/mingetty tty6 root 2622 1 0 Mar28 ? 00:00:00 /bin/sh /etc/X11/prefdm -nodaemon root 2771 2622 0 Mar28 ? 00:00:00 /usr/bin/gdm-binary -nodaemon root 2798 2502 14 Mar28 ? 07:16:58 /usr/local/xorp/fea/xorp_fea root 2799 2771 0 Mar28 ? 00:00:00 /usr/bin/gdm-binary -nodaemon root 2807 2799 0 Mar28 ? 00:09:45 /usr/X11R6/bin/X :0 -audit 0 -auth /var/gdm/:0.Xauth -nolisten tcp vt7 gdm 2839 2799 0 Mar28 ? 00:00:19 /usr/bin/gdmgreeter root 2842 2502 0 Mar28 ? 00:04:16 /usr/local/xorp/rib/xorp_rib root 2857 2502 0 Mar28 ? 00:04:22 /usr/local/xorp/pim/xorp_pimsm4 root 2859 2502 0 Mar28 ? 00:02:17 /usr/local/xorp/policy/xorp_policy root 29316 2370 0 14:09 ? 00:00:00 sshd: dap [priv] dap 29323 29316 0 14:10 ? 00:00:00 sshd: dap@pts/2 dap 29324 29323 0 14:10 pts/2 00:00:00 -bash dap 30335 29324 0 16:00 pts/2 00:00:00 ps -ef --==_Exmh_-9088102260 Content-Type: text/plain ; name="config.boot"; charset=us-ascii Content-Description: config.boot Content-Disposition: attachment; filename="config.boot" /* $XORP: xorp/rtrmgr/config.boot.sample,v 1.33 2005/10/28 18:55:34 pavlin Exp $ */ interfaces { restore-original-config-on-shutdown: false interface eth1 { description: "AI Interface" disable: false /* default-system-config */ vif eth1 { disable: false address 193.60.10.90 { prefix-length: 24 broadcast: 193.60.10.255 disable: false } } } interface eth2 { description: "SEG Interface" disable: false /* default-system-config */ vif eth2 { disable: false address 193.60.11.33 { prefix-length: 24 broadcast: 193.60.11.255 disable: false } } } interface eth3 { description: "Teaching Interface" disable: false /* default-system-config */ vif eth3 { disable: false address 193.60.15.40 { prefix-length: 24 broadcast: 193.60.15.255 disable: false } } } interface eth4 { description: "Abernet Interface" disable: false /* default-system-config */ vif eth4 { disable: false address 144.124.34.30 { prefix-length: 22 broadcast: 144.124.35.255 disable: false } } } interface discard0 { description: "discard interface" disable: false discard: true vif discard0 { disable: false address 127.127.0.1 { prefix-length: 32 disable: false } } } } fea { unicast-forwarding4 { disable: true } } protocols { static { route4 0.0.0.0/0 { metric: 1 next-hop: 144.124.35.253 } mrib-route4 0.0.0.0/0 { metric: 1 next-hop: 144.124.35.253 } } } plumbing { mfea4 { disable: false interface eth1 { vif eth1 { disable: false } } interface eth2 { vif eth2 { disable: false } } interface eth3 { vif eth3 { disable: false } } interface eth4 { vif eth4 { disable: false } } interface register_vif { vif register_vif { /* Note: this vif should be always enabled */ disable: false } } traceoptions { flag all { disable: true } } } } protocols { igmp { disable: false interface eth1 { vif eth1 { disable: false /* version: 2 */ /* enable-ip-router-alert-option-check: false */ /* query-interval: 125 */ /* query-last-member-interval: 1 */ /* query-response-interval: 10 */ /* robust-count: 2 */ } } interface eth2 { vif eth2 { disable: false /* version: 2 */ /* enable-ip-router-alert-option-check: false */ /* query-interval: 125 */ /* query-last-member-interval: 1 */ /* query-response-interval: 10 */ /* robust-count: 2 */ } } interface eth3 { vif eth3 { disable: false /* version: 2 */ /* enable-ip-router-alert-option-check: false */ /* query-interval: 125 */ /* query-last-member-interval: 1 */ /* query-response-interval: 10 */ /* robust-count: 2 */ } } interface eth4 { vif eth4 { disable: false /* version: 2 */ /* enable-ip-router-alert-option-check: false */ /* query-interval: 125 */ /* query-last-member-interval: 1 */ /* query-response-interval: 10 */ /* robust-count: 2 */ } } traceoptions { flag all { disable: true } } } } protocols { pimsm4 { disable: false interface eth1 { vif eth1 { disable: false /* enable-ip-router-alert-option-check: false */ /* dr-priority: 1 */ /* hello-period: 30 */ /* hello-triggered-delay: 5 */ /* alternative-subnet 10.40.0.0/16 */ } } interface eth2 { vif eth2 { disable: false /* enable-ip-router-alert-option-check: false */ /* dr-priority: 1 */ /* hello-period: 30 */ /* hello-triggered-delay: 5 */ /* alternative-subnet 10.40.0.0/16 */ } } interface eth3 { vif eth3 { disable: false /* enable-ip-router-alert-option-check: false */ /* dr-priority: 1 */ /* hello-period: 30 */ /* hello-triggered-delay: 5 */ /* alternative-subnet 10.40.0.0/16 */ } } interface eth4 { vif eth4 { disable: false /* enable-ip-router-alert-option-check: false */ /* dr-priority: 1 */ /* hello-period: 30 */ /* hello-triggered-delay: 5 */ /* alternative-subnet 10.40.0.0/16 */ } } interface register_vif { vif register_vif { /* Note: this vif should be always enabled */ disable: false } } static-rps { rp 193.61.213.3 { group-prefix 224.0.0.0/4 { /* rp-priority: 192 */ /* hash-mask-len: 30 */ } } } switch-to-spt-threshold { /* approx. 1K bytes/s (10Kbps) threshold */ disable: false interval-sec: 100 bytes: 102400 } traceoptions { flag all { disable: true } } } } /* * Note: fib2mrib is needed for multicast only if the unicast protocols * don't populate the MRIB with multicast-specific routes. */ protocols { fib2mrib { disable: false } } /* * See xorp/mibs/snmpdscripts/README on how to configure Net-SNMP in your host * before uncommenting the snmp section below. * Also check that the "bgp4_mib_1657.so" exists in the correct location. */ /* protocols { snmp { mib-module bgp4_mib_1657 { abs-path: "/usr/local/xorp/mibs/bgp4_mib_1657.so" } } } */ --==_Exmh_-9088102260-- From Ambiga@amedia.com Thu Mar 30 15:17:28 2006 From: Ambiga@amedia.com (Ambiga Karthikeyan) Date: Thu, 30 Mar 2006 10:17:28 -0500 Subject: [Xorp-users] Triggered RIP support (RFC 2091) Message-ID: <9025E129D3FCD340A7BA67E342D10E7A12141E1E@ms06.mse1.mailstreet.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C6540C.612D5D21 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 Does XORP have support for triggered rip extension (rfc 2091). From the documents that I read, it doesn't look like XORP supports it but just wanted to confirm. =20 Thanks, Ambiga ------_=_NextPart_001_01C6540C.612D5D21 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

    Does XORP have support for = triggered rip extension (rfc 2091). From the documents that I read, it doesn’t look like XORP = supports it but just wanted to confirm.

 

Thanks,

Ambiga

------_=_NextPart_001_01C6540C.612D5D21-- From lists@yazzy.org Thu Mar 30 15:40:05 2006 From: lists@yazzy.org (Marcin Jessa) Date: Thu, 30 Mar 2006 15:40:05 +0000 Subject: [Xorp-users] Vyatta In-Reply-To: <704b63cf0603300701q75bdcefeica4036847e5168d5@mail.gmail.com> References: <20060330142536.8f4c9453.lists@yazzy.org> <20060330144353.GD24663@juniks.net> <704b63cf0603300701q75bdcefeica4036847e5168d5@mail.gmail.com> Message-ID: <20060330154005.c293e341.lists@yazzy.org> On Thu, 30 Mar 2006 07:01:52 -0800 "Allan Leinwand" wrote: > Hi folks, > > Thanks to Kristian for the correct answer on our product which is > available off our homepage. By "our product" you mean the one of vyatta.com ? > The web interface has been in our source tree > for sometime, although we have not officially announced that it is ready for > beta testing. We expect to be ready for folks to begin beta testing of the > web interface in the next few weeks. Great news :) > We're talked to XORP about taking our web interface and incorporating it > into their project and will work with them to do this work. We're also > preparing to submit the work that we've done on other features, such as > 802.1q VLAN support (which we announced last week). As I understand this is pretty much Linux-centric, right? I work with embedded Linux myself but I also work on a NetBSD and FreeBSD based project and wonder if the changes/patches you're talking about are O.S independant or just for Linux. Both the BSDs (along with the two other major BSDs - OpenBSD and DragonflyBSD) support VLAN. They also support bridging (sharing much of the same code) and since bridging is a part of the Vyatta fork it would be great to have it implemented as well. Not to mention all the other great features like user configuration, DHCP, NTP and DNS support. Cheers and thanks a lot for your answer. Marcin. > > On 3/30/06, Kristian Larsson wrote: > > > > On Thu, Mar 30, 2006 at 02:25:36PM +0000, Marcin Jessa wrote: > > > Hi guys. > > > > > > Is www.vyatta.com a fork of XORP or does it exchange sources > > > with the XORP project ? > > > I tested their LiveCD and it seemed to have many features I > > > could not see it the src tree of the "vanilla" XORP. > > > Features like web service runnking lighttpd with a web interface. > > > I realize vyatta is Linux-centric and uses custom build with busybox etc > > > but would it be difficult to incorporate the web interface into XORP ? > > > > > > And that leads to my second question. > > > How modular is XORP, would it be possible to compile it with support for > > > just a few features and/or add new features like e.g configuration of > > wireless devices? > > Vyatta is utilizing XORP as a foundation. XORP is > > the active routing component in Vyatta and the > > xorpsh is utilized as well. The Vyatta team has > > then added a lot of things, for example it is > > possible to configure users, a few services, > > firewalling rules and so on via the CLI. This is > > not possible in the standard XORP package. > > > > Although I've worked a bit with the Vyatta > > projects OFR I haven't come around to trying the > > web interface so can't answer that bit. > > > > XORP is rather modular. There is currently no > > support for configuration of wireless devices, but > > this could be added if someone just sat down and > > wrote some code :) > > > > Regards, > > Kristian. > > > > _______________________________________________ > > Xorp-users mailing list > > Xorp-users@xorp.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > > From lists@yazzy.org Thu Mar 30 15:44:19 2006 From: lists@yazzy.org (Marcin Jessa) Date: Thu, 30 Mar 2006 15:44:19 +0000 Subject: [Xorp-users] Vyatta In-Reply-To: <20060330144353.GD24663@juniks.net> References: <20060330142536.8f4c9453.lists@yazzy.org> <20060330144353.GD24663@juniks.net> Message-ID: <20060330154419.d00b5966.lists@yazzy.org> On Thu, 30 Mar 2006 16:43:54 +0200 Kristian Larsson wrote: > On Thu, Mar 30, 2006 at 02:25:36PM +0000, Marcin Jessa wrote: > > Hi guys. > > > > Is www.vyatta.com a fork of XORP or does it exchange sources > > with the XORP project ? > > I tested their LiveCD and it seemed to have many features I > > could not see it the src tree of the "vanilla" XORP. > > Features like web service runnking lighttpd with a web interface. > > I realize vyatta is Linux-centric and uses custom build with busybox etc > > but would it be difficult to incorporate the web interface into XORP ? > > > > And that leads to my second question. > > How modular is XORP, would it be possible to compile it with support for > > just a few features and/or add new features like e.g configuration of wireless devices? > Vyatta is utilizing XORP as a foundation. XORP is > the active routing component in Vyatta and the > xorpsh is utilized as well. The Vyatta team has > then added a lot of things, for example it is > possible to configure users, a few services, > firewalling rules and so on via the CLI. This is > not possible in the standard XORP package. > > Although I've worked a bit with the Vyatta > projects OFR I haven't come around to trying the > web interface so can't answer that bit. It looks very promicing. I had it crash on me when I tried to store config file not having floppy on my system but as I understand it is still in beta stage. > XORP is rather modular. Does it mean some of it's components can be taken away during compilation? Say I need only some basic features like configuration of interfaces, IP addresses, default routing and firewalling. Would I be able to compile just those parts and maybe add the missing, new modules ? >There is currently no > support for configuration of wireless devices, but > this could be added if someone just sat down and > wrote some code :) In that case I will try to give it a shot. Cheers, Marcin. From M.Handley@cs.ucl.ac.uk Thu Mar 30 15:47:39 2006 From: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Thu, 30 Mar 2006 15:47:39 +0000 Subject: [Xorp-users] Vyatta In-Reply-To: <20060330144353.GD24663@juniks.net> References: <20060330142536.8f4c9453.lists@yazzy.org> <20060330144353.GD24663@juniks.net> Message-ID: <84a612dd0603300747p5066481fq4caa4ca43626e84c@mail.gmail.com> On 3/30/06, Kristian Larsson wrote: > Vyatta is utilizing XORP as a foundation. XORP is > the active routing component in Vyatta and the > xorpsh is utilized as well. The Vyatta team has > then added a lot of things, for example it is > possible to configure users, a few services, > firewalling rules and so on via the CLI. This is > not possible in the standard XORP package. I should add that the Vyatta folks have contributed a lot of fixes (and bug reports!) back into the main tree, and they have provided funding for the core developers. So definitely not a fork. If you want, think of the Vyatta/XORP relationship as being similar to the {RedHat,Ubuntu,etc}/Linux relationship. - Mark From leinwand@gmail.com Thu Mar 30 16:05:59 2006 From: leinwand@gmail.com (Allan Leinwand) Date: Thu, 30 Mar 2006 08:05:59 -0800 Subject: [Xorp-users] Vyatta In-Reply-To: <20060330154005.c293e341.lists@yazzy.org> References: <20060330142536.8f4c9453.lists@yazzy.org> <20060330144353.GD24663@juniks.net> <704b63cf0603300701q75bdcefeica4036847e5168d5@mail.gmail.com> <20060330154005.c293e341.lists@yazzy.org> Message-ID: <704b63cf0603300805m57c7acf8x4b5028f6e9d90c1@mail.gmail.com> ------=_Part_5137_30786302.1143734759704 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Marcin, On 3/30/06, Marcin Jessa wrote: > > By "our product" you mean the one of vyatta.com ? Yep, my mistake for not using my vyatta account to reply to this. I was referring to the Vyatta OFR above. > We're talked to XORP about taking our web interface and incorporating > it > > into their project and will work with them to do this work. We're also > > preparing to submit the work that we've done on other features, such as > > 802.1q VLAN support (which we announced last week). > > As I understand this is pretty much Linux-centric, right? Yes, the OFR is Linux-centric. I work with embedded Linux myself but I also work on a NetBSD and FreeBSD > based project and wonder if the changes/patches you're talking about are > O.S independant or just for Linux. At the moment we have tested them only with Linux. Both the BSDs (along with the two other major BSDs - OpenBSD and > DragonflyBSD) > support VLAN. They also support bridging (sharing much of the same code) > and since > bridging is a part of the Vyatta fork it would be great to have it > implemented as well. > Not to mention all the other great features like user configuration, DHCP= , > NTP and DNS support. All of the above features are in the OFR image. Please alow me to be specific here for a second - when I say that we have these features we have not written our own implementations. We've incorporated kernel featuires or additional projects to round-out the feature set of the OFR and then extended this integration to our CLI and GUI. We clearly do not want to re-write NTP, DHCP, or VLAN tagging :) You can find the complete list of features and projects that we've incorporated on our wiki. Take care, allan ------=_Part_5137_30786302.1143734759704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Marcin,

On 3/30/06, Marcin Jessa <l= ists@yazzy.org> wrote:
By "our product" you mean the one of vyatta.com ?

Yep, my mistake for not using my vy= atta account to reply to this.  I was referring to the Vyatta OFR abov= e.=20

>= ;    We're talked to XORP about taking our web interfac= e and incorporating it
> into their project and will work with them to do this work. &= nbsp;We're also
> preparing to submit the work that we've done on oth= er features, such as
> 802.1q VLAN support (which we announced last w= eek).

As I understand this is pretty much Linux-centric, right?
<= div>
Yes, the OFR is Linux-centric.

I work with embedded Linux myself but I also work on a NetBSD and FreeBSDbased project and wonder if the changes/patches you're talking about are<= br>O.S independant or just for Linux.

At the moment we= have tested them only with Linux.=20

Bot= h the BSDs (along with the two other major BSDs - OpenBSD and DragonflyBSD)
support VLAN. They also support bridging (sharing much of the same code= ) and since
bridging is a part of the Vyatta fork it would be great to h= ave it implemented as well.
Not to mention all the other great features = like user configuration, DHCP, NTP and DNS support.

All of the above features are in the OFR image. = Please alow me to be specific here for a second - when I say that we have = these features we have not written our own implementations. We've incorpora= ted kernel featuires or additional projects to round-out the feature set of= the OFR and then extended this integration to our CLI and GUI.  We cl= early do not want to re-write NTP, DHCP, or VLAN tagging :)  You can f= ind the complete list of features and projects that we've incorporated on o= ur wiki.

Take care,

allan


------=_Part_5137_30786302.1143734759704-- From leinwand@gmail.com Thu Mar 30 15:01:52 2006 From: leinwand@gmail.com (Allan Leinwand) Date: Thu, 30 Mar 2006 07:01:52 -0800 Subject: [Xorp-users] Vyatta In-Reply-To: <20060330144353.GD24663@juniks.net> References: <20060330142536.8f4c9453.lists@yazzy.org> <20060330144353.GD24663@juniks.net> Message-ID: <704b63cf0603300701q75bdcefeica4036847e5168d5@mail.gmail.com> ------=_Part_4228_19756935.1143730912259 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi folks, Thanks to Kristian for the correct answer on our product which is available off our homepage. The web interface has been in our source tree for sometime, although we have not officially announced that it is ready fo= r beta testing. We expect to be ready for folks to begin beta testing of the web interface in the next few weeks. We're talked to XORP about taking our web interface and incorporating it into their project and will work with them to do this work. We're also preparing to submit the work that we've done on other features, such as 802.1q VLAN support (which we announced last week). Take care, allan On 3/30/06, Kristian Larsson wrote: > > On Thu, Mar 30, 2006 at 02:25:36PM +0000, Marcin Jessa wrote: > > Hi guys. > > > > Is www.vyatta.com a fork of XORP or does it exchange sources > > with the XORP project ? > > I tested their LiveCD and it seemed to have many features I > > could not see it the src tree of the "vanilla" XORP. > > Features like web service runnking lighttpd with a web interface. > > I realize vyatta is Linux-centric and uses custom build with busybox et= c > > but would it be difficult to incorporate the web interface into XORP ? > > > > And that leads to my second question. > > How modular is XORP, would it be possible to compile it with support fo= r > > just a few features and/or add new features like e.g configuration of > wireless devices? > Vyatta is utilizing XORP as a foundation. XORP is > the active routing component in Vyatta and the > xorpsh is utilized as well. The Vyatta team has > then added a lot of things, for example it is > possible to configure users, a few services, > firewalling rules and so on via the CLI. This is > not possible in the standard XORP package. > > Although I've worked a bit with the Vyatta > projects OFR I haven't come around to trying the > web interface so can't answer that bit. > > XORP is rather modular. There is currently no > support for configuration of wireless devices, but > this could be added if someone just sat down and > wrote some code :) > > Regards, > Kristian. > > _______________________________________________ > Xorp-users mailing list > Xorp-users@xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > ------=_Part_4228_19756935.1143730912259 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi folks,

   Thanks to Kristian for the correct answer on = our product which is available off our homepage.  The web interface ha= s been in our source tree for sometime, although we have not officially ann= ounced that it is ready for beta testing.  We expect to be ready for f= olks to begin beta testing of the web interface in the next few weeks.

   We're talked to XORP about taking our web interface an= d incorporating it into their project and will work with them to do this wo= rk.  We're also preparing to submit the work that we've done on other = features, such as=20 802.1q VLAN support (which we announced last week).

Take care,
allan

On 3/30/06, Kristian Larsson < kristian@juniks.net> wrote:
On Thu, Mar 30, 2006 at 02:25:36PM +0000, Marcin Je= ssa wrote:
> Hi guys.
>
> Is www.= vyatta.com a fork of XORP or does it exchange sources
> with the = XORP project ?
> I tested their LiveCD and it seemed to have many fea= tures I
> could not see it the src tree of the "vanilla" XORP.
= > Features like web service runnking lighttpd with a web interface.
&= gt; I realize vyatta is Linux-centric and uses custom build with busybox et= c
> but would it be difficult to incorporate the web interface into XO= RP ?
>
> And that leads to my second question.
> How modu= lar is XORP, would it be possible to compile it with support for
> ju= st a few features and/or add new features like=20 e.g configuration of wireless devices?
Vyatta is utilizing XORP as a fou= ndation. XORP is
the active routing component in Vyatta and the
xorps= h is utilized as well. The Vyatta team has
then added a lot of things, f= or example it is
possible to configure users, a few services,
firewalling rules and s= o on via the CLI. This is
not possible in the standard XORP package.
=
Although I've worked a bit with the Vyatta
projects OFR I haven't co= me around to trying the
web interface so can't answer that bit.

XORP is rather modular. = There is currently no
support for configuration of wireless devices, but=
this could be added if someone just sat down and
wrote some code :)

Regards,
  Kristian.

__________________________= _____________________
Xorp-users mailing list
Xorp-users@xorp.org
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users

------=_Part_4228_19756935.1143730912259-- From MANJON@terra.es Thu Mar 30 12:37:45 2006 From: MANJON@terra.es (MANJON@terra.es) Date: Thu, 30 Mar 2006 14:37:45 +0200 (MEST) Subject: [Xorp-users] questions about xorp Message-ID: <20460512.1143722265651.JavaMail.root@cps3> first at all, thanks for your help This messages appears when the processes of xorp have died. In my system the firewall and xorp switchover works fine: the firewall failover, the xorp is started in the active and stopped in the passive one. But each indefinite time one or two or all process of xorp are stopped or died. I don´t know why and I can´t understand the logs. At this moment I have the active node with 213 unicast routes and 785 multicast routes. What are the limits tested in xorp if they exist? I have two clusters with the same problem in different places. This is the exit of the "top" command in the active node right now. Now all is working but will fail sure. 14:32:56 up 29 days, 8:07, 1 user, load average: 1.06, 1.11, 1.09 47 processes: 45 sleeping, 2 running, 0 zombie, 0 stopped CPU states: cpu user nice system irq softirq iowait idle total 2.2% 0.0% 0.6% 0.0% 1.0% 0.0% 96.2% Mem: 899112k av, 389572k used, 509540k free, 0k shrd, 468k buff 233332k active, 57796k inactive Swap: 0k av, 0k used, 0k free 154628k cached PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND 32617 root 15 0 10384 10M 2932 S 0.4 1.1 7:34 0 xorp_pimsm4 32483 root 15 0 10332 10M 3664 S 0.2 1.1 3:33 0 xorp_fea I dont know what information you need to help me. thanks Pavlin Jose Maria Martin ----Mensaje original---- De: pavlin@icir.org Recibido: 30/03/2006 5:11 Para: CC: Asunto: Re: [Xorp-users] questions about xorp > I have a firewall cluster using xorp for multicast. I have an script that g= > et up xorp processses in the active node. Really I have only run xorp in th= > e active node. When there is a failover my script run the xorp in the new a= > ctive node and kill xorp in the passive one. This is the xorp processes tha= > t I start: > > 1308 ? S 0:01 /opt/bladefusion/xorp/bin/xorp_rtrmgr > 1310 ? S 0:49 /opt/bladefusion/xorp/fea/xorp_fea > 1381 ? S 0:00 /opt/bladefusion/xorp/rib/xorp_rib > 1399 ? S 0:00 /opt/bladefusion/xorp/fib2mrib/xorp_fib2mrib > 1417 ? S 0:28 /opt/bladefusion/xorp/mld6igmp/xorp_igmp > 1435 ? S 0:05 /opt/bladefusion/xorp/pim/xorp_pimsm4 > > My question is: Is necessary use xorp_fib2mrib in my system? I haven=C2=B4t= > to sync xorp states between nodes because I have only one node running xor= > p . For all practical purpose, the answer is "yes". Process xorp_fib2mrib is used to obtain the unicast forwarding state from the kernel (via the FEA) and push it into the Multicast RIB (which is needed by PIM-SM for the reverse-path forwarding check). > My other question is about an error in my /var/log/messages, when my xorp d= > ied > > Mar 28 02:01:41 fw1bjscpd BF-PIM: [ 2006/03/28 02:01:41 ERROR xorp_rtrmgr:2= > 2712 XRL +629 xrl_pf_stcp.cc die ] XrlPFSTCPSender died: Keepalive timeout= > =20 This error (and all other errors) is problematic. This message shows some XRL communication problems: the keepalive to some of the other XORP processes has timeout. All other errors are probably a direct or indirect result of those XRL timeouts. Do you see those errors during the switchover, or well after the switchover was completed? If they happen during the switchover then something has gone wrong. E.g., if you are starting a new instance of XORP, first you must make sure that all processes from the old instance have been killed. Otherwise, they may inflict on the new XORP instance. If you start seeing the errors well after the switchover has completed, then the following log message might be a suspect: > Mar 28 02:02:13 fw1bjscpd ntpdate[24855]: adjust time server 55.1.1.8 offse= > t -0.054280 sec In general, adjusting the time backwards doesn't play well with XORP, so the above adjustment _may_ have something to do with XRL keepalive timeout. The easiest way to test this is temporary to turn off NTP and see whether you still get keepalive timeouts. Pavlin _______________________________________________ Xorp-users mailing list Xorp-users@xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin@icir.org Thu Mar 30 23:11:19 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 30 Mar 2006 15:11:19 -0800 Subject: [Xorp-users] Interfaces all going "down" In-Reply-To: Message from Dave Price of "Thu, 30 Mar 2006 16:06:33 +0100." <13890.1143731193@aber.ac.uk> Message-ID: <200603302311.k2UNBJex044642@possum.icir.org> > My XORP box has disabled all interfaces again > at the XORP level although all fine at Linux/ifconfig level. > > what is the output of "show interfaces", "show mfea interface" and > > "show igmp interface" xorpsh commands? > > I ran those plus a few other things... > Here's the output > xorp@trollope.dcs.aber.ac.uk> show pim interface > Interface State Mode V PIMstate Priority DRaddr Neighbors > discard0 DISABLED Sparse 2 DR 1 127.127.0.1 0 > eth1 DOWN Sparse 2 NotDR 1 0.0.0.0 0 > eth2 DOWN Sparse 2 NotDR 1 0.0.0.0 0 > eth3 DOWN Sparse 2 NotDR 1 0.0.0.0 0 > eth4 DOWN Sparse 2 NotDR 1 0.0.0.0 0 > register_vif DOWN Sparse 2 DR 1 0.0.0.0 0 > xorp@trollope.dcs.aber.ac.uk> show interfaces > > Command interrupted! > > xorp@trollope.dcs.aber.ac.uk> show mfea interface > Error: 201 Resolve failed > ERROR: Command "/usr/local/xorp/cli/tools/send_cli_processor_xrl": exited with exit status 1. > xorp@trollope.dcs.aber.ac.uk> show igmp interface > ^ > syntax error, expecting . > xorp@trollope.dcs.aber.ac.uk> show ? > Possible completions: > host Display information about the host > interfaces Show network interface information > mfea Display information about IPv4 MFEA > pim Display information about IPv4 PIM > route Show routes > xorp@trollope.dcs.aber.ac.uk> > ===================================================== > > The "show interfaces" hung for an hour with no output > at all! It appears that the xorp_igmp process has died (confirmed by your "ps" output), and the xorp_fea process is in funny state if it doesn't respond to "show interfaces" and "show mfea interface". My best guess so far is that something went wrong with the xorp_fea process so it doesn't communicate properly with other processes. The disappearance of the xorp_igmp process may be related to this. The "show mfea interface" doesn't work, because the MFEA itself is part of the FEA process. I presume now you have enabled the log messages, so lets hope they will give us some useful info next time you have the same problem. Also, next time please include the output of "ps -auxww", because it includes more info like the particular state of each process. Pavlin P.S. Your configuration seems fine. From pavlin@icir.org Thu Mar 30 23:52:10 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 30 Mar 2006 15:52:10 -0800 Subject: [Xorp-users] Vyatta In-Reply-To: Message from Marcin Jessa of "Thu, 30 Mar 2006 15:44:19 GMT." <20060330154419.d00b5966.lists@yazzy.org> Message-ID: <200603302352.k2UNqAT0045015@possum.icir.org> > > XORP is rather modular. > Does it mean some of it's components can be taken away during compilation? > Say I need only some basic features like configuration of interfaces, IP addresses, > default routing and firewalling. Would I be able to compile just > those parts and maybe add the missing, new modules ? Yes (to some extend). For example, if you don't want a specific protocol, then don't compile it and it won't be used. Though, you may have to remove the corresponding configurational/operational template files under xorp/etc/templates to make sure the protocol is not configurable anymore. Note that by default "gmake" in the top-level directory will attempt to compile all components (except mibs). If you want to exclude some component, currently you would have to edit configure.in and the top-level Makefile.am and then regenerate the build infrastructure (by running ./bootstrap). Alternatively, you would have to "cd" to each particular directory and run "gmake" if you want to exclude some of the directories. You might have to compile the directories in some particular order, but the top-level Makefile.am can give you some rough idea what is mandatory and the compilation dependency order. Pavlin From pavlin@icir.org Fri Mar 31 00:24:12 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 30 Mar 2006 16:24:12 -0800 Subject: [Xorp-users] questions about xorp In-Reply-To: Message from "MANJON@terra.es" of "Thu, 30 Mar 2006 14:37:45 +0200." <20460512.1143722265651.JavaMail.root@cps3> Message-ID: <200603310025.k2V0OCjP045314@possum.icir.org> > This messages appears when the processes of xorp have died. > In my system the firewall and xorp switchover works fine: the firewall > failover, the xorp is started in the active and stopped in the passive > one. > But each indefinite time one or two or all process of xorp are stopped > or died. I don´t know why and I can´t understand the logs. > At this moment I have the active node with 213 unicast routes and 785 > multicast routes. What are the limits tested in xorp if they exist? > I have two clusters with the same problem in different places. > This is the exit of the "top" command in the active node right now. > Now all is working but will fail sure. Could you enable traceoptions for the following components: mfea4, igmp, pimsm4: traceoptions { flag all { disable: false } } Then, please save the XORP log to a file from the moment it is started and send me this log once you start experiencing the problem. Usually, now long time does it take to start seeing the timeout messages? Also, was there anything happening around that time (e.g., increase of the number of routes, etc). Finally, how/what do you count as multicast routes? The output of commands like "show route table ipv4 multicast final" or "show pim join" (or something else). Pavlin