From lherve at interfaceconcept.com Wed Oct 1 02:08:08 2008 From: lherve at interfaceconcept.com (=?iso-8859-1?Q?Herv=E9_L=E9onard?=) Date: Wed, 1 Oct 2008 11:08:08 +0200 Subject: [Xorp-users] the static route doesn't appear at first 'xorp_rtrmgr' launch...? Message-ID: <63AA311738CA4567BA3FBC8E0717349A@lehe6600v> Hello, I try to configure 2 routers xorp with a config file at launch on a Linux 2.6 (Ubuntu 8.04 Hardy Heron) with this command: sudo /usr/sbin/xorp_rtrmgr -b /etc/xorp/config.boot Here is my testbed configuration: Station1 Router1 Router2 Station2 eth0 -----------eth0 eth1 -------------- eth1 eth0 ------------ eth0 192.168.2.2 ---- 192.168.2.1 100.0.0.1 ---- 100.0.0.2 192.168.3.1 ---- 192.168.3.2 On Router2, for example, I have put this in the config.boot (generated by save command): /*XORP Configuration File, v1.0*/ protocols { static { disable: false route 192.168.2.0/24 { next-hop: 100.0.0.1 metric: 1 } } } fea { unicast-forwarding4 { disable: false forwarding-entries { retain-on-startup: false retain-on-shutdown: false } } } interfaces { restore-original-config-on-shutdown: false interface eth0 { description: "Ethernet Interface #1" disable: false discard: false unreachable: false management: false vif eth0 { disable: false address 192.168.3.1 { prefix-length: 24 broadcast: 192.168.3.255 disable: false } } } interface eth1 { description: "Ethernet Interface #2" disable: false discard: false unreachable: false management: false vif eth1 { disable: false address 100.0.0.2 { prefix-length: 8 broadcast: 100.255.255.255 disable: false } } } } The first time, the 2 interfaces are configured but the static route doesn't appear. Then I shutdown xorp et restart xorp_rtrmgr. And after that, I can see the static route. Here my shell log: ## ## Start of xorp_rtrmgr the first time ## labo at labo3000:~$ ifconfig eth0 Link encap:Ethernet HWaddr 00:13:21:c9:9d:05 inet adr:192.168.3.1 Bcast:192.168.3.255 Masque:255.255.255.0 adr inet6: fe80::213:21ff:fec9:9d05/64 Scope:Lien UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Packets re?us:16 erreurs:0 :0 overruns:0 frame:0 TX packets:22 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:1000 Octets re?us:2725 (2.6 KB) Octets transmis:3811 (3.7 KB) Interruption:17 eth1 Link encap:Ethernet HWaddr 00:40:f4:cc:f4:c1 inet adr:100.0.0.2 Bcast:100.255.255.255 Masque:255.0.0.0 adr inet6: fe80::240:f4ff:fecc:f4c1/64 Scope:Lien UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Packets re?us:0 erreurs:0 :0 overruns:0 frame:0 TX packets:22 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:1000 Octets re?us:0 (0.0 B) Octets transmis:3711 (3.6 KB) Interruption:19 Adresse de base:0x4000 lo Link encap:Boucle locale inet adr:127.0.0.1 Masque:255.0.0.0 adr inet6: ::1/128 Scope:H?te UP LOOPBACK RUNNING MTU:16436 Metric:1 Packets re?us:8510 erreurs:0 :0 overruns:0 frame:0 TX packets:8510 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:0 Octets re?us:838919 (819.2 KB) Octets transmis:838919 (819.2 KB) labo at labo3000:~$ route -n Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 100.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth1 labo at labo3000:~$ # # There is no static route # # # Then, shutdown and restart of xorp_rtrmgr with same config file and here is the result: # labo at labo3000:~$ route -n Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.2.0 100.0.0.1 255.255.255.0 UG 1 0 0 eth1 100.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth1 labo at labo3000:~$ # # This time, the static route appears # I try with a different config.boot file, with the "interfaces" configuration node before the "protocols" configuration node, but the result is the same.... Do I use correctly the config.boot file? Or is there any solution to have a correct configuration in one shot? From pavlin at ICSI.Berkeley.EDU Wed Oct 1 12:49:49 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Wed, 01 Oct 2008 12:49:49 -0700 Subject: [Xorp-users] the static route doesn't appear at first 'xorp_rtrmgr' launch...? In-Reply-To: <63AA311738CA4567BA3FBC8E0717349A@lehe6600v> References: <63AA311738CA4567BA3FBC8E0717349A@lehe6600v> Message-ID: <200810011950.m91Jnnak003240@fruitcake.ICSI.Berkeley.EDU> I tried Ubuntu 8.04.1 with 2.6.24-19-server kernel (under VMware) and I was able to replicate the problem when I used the Ubuntu (Debian?) xorp package: apt-get install xorp Running "apt-cache show xorp" reveals the following: ... Version: 1.5~cvs.20080128-1 ... In other words, the xorp package in Ubuntu-8.04.1 seems quite old (it is based on CVS snapshot from January 2008 and that code contains various FEA-related bugs). However, when I downloaded the vanilla xorp-1.5.tar.gz source code and compiled it, I didn't have this problem. Hence, you should get the vanilla xorp-1.5 release code from xorp.org and compile+install it yourself. I believe the next release of Ubuntu will have the updated xorp package that is based on the xorp-1.5 release. Pavlin Herv? L?onard wrote: > Hello, > > I try to configure 2 routers xorp with a config file at launch on a Linux > 2.6 (Ubuntu 8.04 Hardy Heron) with this command: > sudo /usr/sbin/xorp_rtrmgr -b /etc/xorp/config.boot > > Here is my testbed configuration: > > Station1 Router1 Router2 > Station2 > eth0 -----------eth0 eth1 -------------- eth1 eth0 ------------ > eth0 > 192.168.2.2 ---- 192.168.2.1 100.0.0.1 ---- 100.0.0.2 192.168.3.1 ---- > 192.168.3.2 > > On Router2, for example, I have put this in the config.boot (generated by > save command): > > /*XORP Configuration File, v1.0*/ > protocols { > static { > disable: false > route 192.168.2.0/24 { > next-hop: 100.0.0.1 > metric: 1 > } > } > } > fea { > unicast-forwarding4 { > disable: false > forwarding-entries { > retain-on-startup: false > retain-on-shutdown: false > } > } > } > interfaces { > restore-original-config-on-shutdown: false > interface eth0 { > description: "Ethernet Interface #1" > disable: false > discard: false > unreachable: false > management: false > vif eth0 { > disable: false > address 192.168.3.1 { > prefix-length: 24 > broadcast: 192.168.3.255 > disable: false > } > } > } > interface eth1 { > description: "Ethernet Interface #2" > disable: false > discard: false > unreachable: false > management: false > vif eth1 { > disable: false > address 100.0.0.2 { > prefix-length: 8 > broadcast: 100.255.255.255 > disable: false > } > } > } > } > > The first time, the 2 interfaces are configured but the static route doesn't > appear. Then I shutdown xorp et restart xorp_rtrmgr. And after that, I can > see the static route. > > Here my shell log: > > ## > ## Start of xorp_rtrmgr the first time > ## > > labo at labo3000:~$ ifconfig > eth0 Link encap:Ethernet HWaddr 00:13:21:c9:9d:05 > inet adr:192.168.3.1 Bcast:192.168.3.255 Masque:255.255.255.0 > adr inet6: fe80::213:21ff:fec9:9d05/64 Scope:Lien > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > Packets re?us:16 erreurs:0 :0 overruns:0 frame:0 > TX packets:22 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 lg file transmission:1000 > Octets re?us:2725 (2.6 KB) Octets transmis:3811 (3.7 KB) > Interruption:17 > > eth1 Link encap:Ethernet HWaddr 00:40:f4:cc:f4:c1 > inet adr:100.0.0.2 Bcast:100.255.255.255 Masque:255.0.0.0 > adr inet6: fe80::240:f4ff:fecc:f4c1/64 Scope:Lien > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > Packets re?us:0 erreurs:0 :0 overruns:0 frame:0 > TX packets:22 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 lg file transmission:1000 > Octets re?us:0 (0.0 B) Octets transmis:3711 (3.6 KB) > Interruption:19 Adresse de base:0x4000 > > lo Link encap:Boucle locale > inet adr:127.0.0.1 Masque:255.0.0.0 > adr inet6: ::1/128 Scope:H?te > UP LOOPBACK RUNNING MTU:16436 Metric:1 > Packets re?us:8510 erreurs:0 :0 overruns:0 frame:0 > TX packets:8510 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 lg file transmission:0 > Octets re?us:838919 (819.2 KB) Octets transmis:838919 (819.2 KB) > > labo at labo3000:~$ route -n > Table de routage IP du noyau > Destination Passerelle Genmask Indic Metric Ref Use > Iface > 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 > 100.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth1 > labo at labo3000:~$ > > # > # There is no static route > # > > # > # Then, shutdown and restart of xorp_rtrmgr with same config file and here > is the result: > # > > labo at labo3000:~$ route -n > Table de routage IP du noyau > Destination Passerelle Genmask Indic Metric Ref Use > Iface > 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 > 192.168.2.0 100.0.0.1 255.255.255.0 UG 1 0 0 eth1 > 100.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth1 > labo at labo3000:~$ > > # > # This time, the static route appears > # > > > I try with a different config.boot file, with the "interfaces" configuration > node before the "protocols" configuration node, but the result is the > same.... > > Do I use correctly the config.boot file? > Or is there any solution to have a correct configuration in one shot? > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From lherve at interfaceconcept.com Thu Oct 2 10:42:19 2008 From: lherve at interfaceconcept.com (=?iso-8859-1?Q?Herv=E9_L=E9onard?=) Date: Thu, 2 Oct 2008 19:42:19 +0200 Subject: [Xorp-users] the static route doesn't appear at first 'xorp_rtrmgr' launch...? In-Reply-To: <200810011950.m91Jnnak003240@fruitcake.ICSI.Berkeley.EDU> Message-ID: <10202758529546BA9B4955A20956BE24@lehe6600v> Many thanks for your response. So I compiled the vanilla xorp-1.5 (xorp-1.5.tar.gz form date 2007-07-22) but I have another issue: when I check the compilation by #make check , I have theses 3 FAIL: FAIL: test_lemming FAIL: test_xrl_router FAIL: test_finder_tcp Then, when starting xorp-rtrmgr (with same config.boot file than in first mail below), I have theses 2 error lignes : [ 2008/10/02 18:01:39 ERROR xorp_rtrmgr:6975 LIBCOMM +312 comm_sock.c comm_sock_bind4 ] Error binding socket (family = 2, my_addr = 127.0.0.1, my_port = 19999): Address already in use [ 2008/10/02 18:01:39 ERROR xorp_rtrmgr:6975 RTRMGR +243 main_rtrmgr.cc run ] Address already in use: a finder may already be running. Thanks in advance for your help, Regards, Leonard -----Message d'origine----- I tried Ubuntu 8.04.1 with 2.6.24-19-server kernel (under VMware) and I was able to replicate the problem when I used the Ubuntu (Debian?) xorp package: apt-get install xorp Running "apt-cache show xorp" reveals the following: ... Version: 1.5~cvs.20080128-1 ... In other words, the xorp package in Ubuntu-8.04.1 seems quite old (it is based on CVS snapshot from January 2008 and that code contains various FEA-related bugs). However, when I downloaded the vanilla xorp-1.5.tar.gz source code and compiled it, I didn't have this problem. Hence, you should get the vanilla xorp-1.5 release code from xorp.org and compile+install it yourself. I believe the next release of Ubuntu will have the updated xorp package that is based on the xorp-1.5 release. Pavlin Herv? L?onard wrote: > Hello, > > I try to configure 2 routers xorp with a config file at launch on a Linux > 2.6 (Ubuntu 8.04 Hardy Heron) with this command: > sudo /usr/sbin/xorp_rtrmgr -b /etc/xorp/config.boot > > Here is my testbed configuration: > > Station1 Router1 Router2 > Station2 > eth0 -----------eth0 eth1 -------------- eth1 eth0 ------------ > eth0 > 192.168.2.2 ---- 192.168.2.1 100.0.0.1 ---- 100.0.0.2 192.168.3.1 ---- > 192.168.3.2 > > On Router2, for example, I have put this in the config.boot (generated by > save command): > > /*XORP Configuration File, v1.0*/ > protocols { > static { > disable: false > route 192.168.2.0/24 { > next-hop: 100.0.0.1 > metric: 1 > } > } > } > fea { > unicast-forwarding4 { > disable: false > forwarding-entries { > retain-on-startup: false > retain-on-shutdown: false > } > } > } > interfaces { > restore-original-config-on-shutdown: false > interface eth0 { > description: "Ethernet Interface #1" > disable: false > discard: false > unreachable: false > management: false > vif eth0 { > disable: false > address 192.168.3.1 { > prefix-length: 24 > broadcast: 192.168.3.255 > disable: false > } > } > } > interface eth1 { > description: "Ethernet Interface #2" > disable: false > discard: false > unreachable: false > management: false > vif eth1 { > disable: false > address 100.0.0.2 { > prefix-length: 8 > broadcast: 100.255.255.255 > disable: false > } > } > } > } > > The first time, the 2 interfaces are configured but the static route doesn't > appear. Then I shutdown xorp et restart xorp_rtrmgr. And after that, I can > see the static route. > > Here my shell log: > > ## > ## Start of xorp_rtrmgr the first time > ## > > labo at labo3000:~$ ifconfig > eth0 Link encap:Ethernet HWaddr 00:13:21:c9:9d:05 > inet adr:192.168.3.1 Bcast:192.168.3.255 Masque:255.255.255.0 > adr inet6: fe80::213:21ff:fec9:9d05/64 Scope:Lien > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > Packets re?us:16 erreurs:0 :0 overruns:0 frame:0 > TX packets:22 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 lg file transmission:1000 > Octets re?us:2725 (2.6 KB) Octets transmis:3811 (3.7 KB) > Interruption:17 > > eth1 Link encap:Ethernet HWaddr 00:40:f4:cc:f4:c1 > inet adr:100.0.0.2 Bcast:100.255.255.255 Masque:255.0.0.0 > adr inet6: fe80::240:f4ff:fecc:f4c1/64 Scope:Lien > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > Packets re?us:0 erreurs:0 :0 overruns:0 frame:0 > TX packets:22 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 lg file transmission:1000 > Octets re?us:0 (0.0 B) Octets transmis:3711 (3.6 KB) > Interruption:19 Adresse de base:0x4000 > > lo Link encap:Boucle locale > inet adr:127.0.0.1 Masque:255.0.0.0 > adr inet6: ::1/128 Scope:H?te > UP LOOPBACK RUNNING MTU:16436 Metric:1 > Packets re?us:8510 erreurs:0 :0 overruns:0 frame:0 > TX packets:8510 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 lg file transmission:0 > Octets re?us:838919 (819.2 KB) Octets transmis:838919 (819.2 KB) > > labo at labo3000:~$ route -n > Table de routage IP du noyau > Destination Passerelle Genmask Indic Metric Ref Use > Iface > 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 > 100.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth1 > labo at labo3000:~$ > > # > # There is no static route > # > > # > # Then, shutdown and restart of xorp_rtrmgr with same config file and here > is the result: > # > > labo at labo3000:~$ route -n > Table de routage IP du noyau > Destination Passerelle Genmask Indic Metric Ref Use > Iface > 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 > 192.168.2.0 100.0.0.1 255.255.255.0 UG 1 0 0 eth1 > 100.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth1 > labo at labo3000:~$ > > # > # This time, the static route appears > # > > > I try with a different config.boot file, with the "interfaces" configuration > node before the "protocols" configuration node, but the result is the > same.... > > Do I use correctly the config.boot file? > Or is there any solution to have a correct configuration in one shot? > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users __________ Information NOD32 3488 (20081002) __________ Ce message a ete verifie par NOD32 Antivirus System. http://www.nod32.com From pavlin at ICSI.Berkeley.EDU Thu Oct 2 11:00:36 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Thu, 02 Oct 2008 11:00:36 -0700 Subject: [Xorp-users] the static route doesn't appear at first 'xorp_rtrmgr' launch...? In-Reply-To: <10202758529546BA9B4955A20956BE24@lehe6600v> References: <10202758529546BA9B4955A20956BE24@lehe6600v> Message-ID: <200810021800.m92I0aI8019592@fruitcake.ICSI.Berkeley.EDU> Herv? L?onard wrote: > > Many thanks for your response. > > So I compiled the vanilla xorp-1.5 (xorp-1.5.tar.gz form date 2007-07-22) > but I have another issue: > > when I check the compilation by #make check , I have theses 3 FAIL: > FAIL: test_lemming > FAIL: test_xrl_router > FAIL: test_finder_tcp Do you have any running process (incl. leftover XORP process) that is using port 19999? This could explain the failure of the above test programs, and the failure to start the rtrmgr. FYI, you can change the default port from 19999 to some other value by setting the XORP_FINDER_SERVER_PORT environmental variable in your shell before starting any XORP processes. Pavlin > Then, when starting xorp-rtrmgr (with same config.boot file than in first > mail below), I have theses 2 error lignes : > > [ 2008/10/02 18:01:39 ERROR xorp_rtrmgr:6975 LIBCOMM +312 comm_sock.c > comm_sock_bind4 ] Error binding socket (family = 2, my_addr = 127.0.0.1, > my_port = 19999): Address already in use > [ 2008/10/02 18:01:39 ERROR xorp_rtrmgr:6975 RTRMGR +243 main_rtrmgr.cc > run ] Address already in use: a finder may already be running. > > Thanks in advance for your help, > Regards, > > Leonard > > > -----Message d'origine----- > > I tried Ubuntu 8.04.1 with 2.6.24-19-server kernel (under VMware) > and I was able to replicate the problem when I used the Ubuntu > (Debian?) xorp package: > > apt-get install xorp > > Running "apt-cache show xorp" reveals the following: > ... > Version: 1.5~cvs.20080128-1 > ... > > In other words, the xorp package in Ubuntu-8.04.1 seems quite old > (it is based on CVS snapshot from January 2008 and that code contains > various FEA-related bugs). > > However, when I downloaded the vanilla xorp-1.5.tar.gz source code > and compiled it, I didn't have this problem. > > Hence, you should get the vanilla xorp-1.5 release code from > xorp.org and compile+install it yourself. > I believe the next release of Ubuntu will have the updated xorp > package that is based on the xorp-1.5 release. > > Pavlin > > > Herv? L?onard wrote: > > > Hello, > > > > I try to configure 2 routers xorp with a config file at launch on a Linux > > 2.6 (Ubuntu 8.04 Hardy Heron) with this command: > > sudo /usr/sbin/xorp_rtrmgr -b /etc/xorp/config.boot > > > > Here is my testbed configuration: > > > > Station1 Router1 Router2 > > Station2 > > eth0 -----------eth0 eth1 -------------- eth1 > eth0 ------------ > > eth0 > > 192.168.2.2 ---- 192.168.2.1 100.0.0.1 ---- 100.0.0.2 192.168.3.1 ---- > > 192.168.3.2 > > > > On Router2, for example, I have put this in the config.boot (generated by > > save command): > > > > /*XORP Configuration File, v1.0*/ > > protocols { > > static { > > disable: false > > route 192.168.2.0/24 { > > next-hop: 100.0.0.1 > > metric: 1 > > } > > } > > } > > fea { > > unicast-forwarding4 { > > disable: false > > forwarding-entries { > > retain-on-startup: false > > retain-on-shutdown: false > > } > > } > > } > > interfaces { > > restore-original-config-on-shutdown: false > > interface eth0 { > > description: "Ethernet Interface #1" > > disable: false > > discard: false > > unreachable: false > > management: false > > vif eth0 { > > disable: false > > address 192.168.3.1 { > > prefix-length: 24 > > broadcast: 192.168.3.255 > > disable: false > > } > > } > > } > > interface eth1 { > > description: "Ethernet Interface #2" > > disable: false > > discard: false > > unreachable: false > > management: false > > vif eth1 { > > disable: false > > address 100.0.0.2 { > > prefix-length: 8 > > broadcast: 100.255.255.255 > > disable: false > > } > > } > > } > > } > > > > The first time, the 2 interfaces are configured but the static route > doesn't > > appear. Then I shutdown xorp et restart xorp_rtrmgr. And after that, I can > > see the static route. > > > > Here my shell log: > > > > ## > > ## Start of xorp_rtrmgr the first time > > ## > > > > labo at labo3000:~$ ifconfig > > eth0 Link encap:Ethernet HWaddr 00:13:21:c9:9d:05 > > inet adr:192.168.3.1 Bcast:192.168.3.255 Masque:255.255.255.0 > > adr inet6: fe80::213:21ff:fec9:9d05/64 Scope:Lien > > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > > Packets re?us:16 erreurs:0 :0 overruns:0 frame:0 > > TX packets:22 errors:0 dropped:0 overruns:0 carrier:0 > > collisions:0 lg file transmission:1000 > > Octets re?us:2725 (2.6 KB) Octets transmis:3811 (3.7 KB) > > Interruption:17 > > > > eth1 Link encap:Ethernet HWaddr 00:40:f4:cc:f4:c1 > > inet adr:100.0.0.2 Bcast:100.255.255.255 Masque:255.0.0.0 > > adr inet6: fe80::240:f4ff:fecc:f4c1/64 Scope:Lien > > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > > Packets re?us:0 erreurs:0 :0 overruns:0 frame:0 > > TX packets:22 errors:0 dropped:0 overruns:0 carrier:0 > > collisions:0 lg file transmission:1000 > > Octets re?us:0 (0.0 B) Octets transmis:3711 (3.6 KB) > > Interruption:19 Adresse de base:0x4000 > > > > lo Link encap:Boucle locale > > inet adr:127.0.0.1 Masque:255.0.0.0 > > adr inet6: ::1/128 Scope:H?te > > UP LOOPBACK RUNNING MTU:16436 Metric:1 > > Packets re?us:8510 erreurs:0 :0 overruns:0 frame:0 > > TX packets:8510 errors:0 dropped:0 overruns:0 carrier:0 > > collisions:0 lg file transmission:0 > > Octets re?us:838919 (819.2 KB) Octets transmis:838919 (819.2 KB) > > > > labo at labo3000:~$ route -n > > Table de routage IP du noyau > > Destination Passerelle Genmask Indic Metric Ref Use > > Iface > > 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 > eth0 > > 100.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 > eth1 > > labo at labo3000:~$ > > > > # > > # There is no static route > > # > > > > # > > # Then, shutdown and restart of xorp_rtrmgr with same config file and here > > is the result: > > # > > > > labo at labo3000:~$ route -n > > Table de routage IP du noyau > > Destination Passerelle Genmask Indic Metric Ref Use > > Iface > > 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 > eth0 > > 192.168.2.0 100.0.0.1 255.255.255.0 UG 1 0 0 > eth1 > > 100.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 > eth1 > > labo at labo3000:~$ > > > > # > > # This time, the static route appears > > # > > > > > > I try with a different config.boot file, with the "interfaces" > configuration > > node before the "protocols" configuration node, but the result is the > > same.... > > > > Do I use correctly the config.boot file? > > Or is there any solution to have a correct configuration in one shot? > > > > _______________________________________________ > > Xorp-users mailing list > > Xorp-users at xorp.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > __________ Information NOD32 3488 (20081002) __________ > > Ce message a ete verifie par NOD32 Antivirus System. > http://www.nod32.com > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From atanu at xorp.org Thu Oct 2 16:08:14 2008 From: atanu at xorp.org (Atanu Ghosh) Date: Thu, 02 Oct 2008 16:08:14 -0700 Subject: [Xorp-users] XORP License change Message-ID: <39939.1222988894@xorps.icir.org> As of Thursday, October 2, 2008, we will be licensing XORP.org code under the GNU General Public License, Version 2 (GPL v2), with selected libraries made available under the GNU Lesser General Public License, Version 2.1 (LGPL v2.1). The license changes will apply to all code currently in the XORP.org CVS tree and to all future XORP.org releases, with the exception of code derived from other sources. Our goals in moving to the GPLv2 and LGPLv2.1 licenses are threefold: - First, we want to ensure that improvements and extensions to the XORP.org code base are made freely available to the XORP.org community. The copyleft provision of the GPLv2 maximizes the likelihood that this will be the case. - At the same time, we believe that the best way to encourage innovation in the broader networking arena is to make it easy for network application developers to take advantage of XORP's open APIs and extensible architecture. We aim to build an ecosystem of developers who adopt XORP as their network operating system of choice, regardless of whether their own code is open or proprietary. The LGPLv2.1 provides a straightforward way for them to do so. - Finally, we don't want to proliferate open source licenses. Moving from the customized wording of our original XORP license to the broadly used OSI-approved GPLv2 and LGPLv2.1 licenses is a step toward that end. Commercial users of XORP who believe they may be impacted or limited by the XORP.org license changes are encouraged to contact us at info at xorp.net. --The XORP Team From jose.spam at netvisao.pt Sun Oct 5 16:14:05 2008 From: jose.spam at netvisao.pt (Jose Manuel dos Santos Calhariz) Date: Mon, 6 Oct 2008 00:14:05 +0100 Subject: [Xorp-users] Builing xorp with --enable-shared vs --with-pic Message-ID: <20081005231405.GA7108@calhariz.com> Hi As I don't understand well the compiling process of xorp 1.5 so I have a question. What is the diference of building xorp using switch --enable-shared vs --with-pic in a Linux system. If building xorp with snmp support it will generate shared libraries for mibs that are made with objects compiled without -fPIC. This is a problem in Linux and even breaks on x86_84 systems. What is best? --enable-shared or with-pic See bug report on Debian for more info http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500325 Jose Calhariz -- -- Aqueles que bebem pra esquecer favor pagar adiantado -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20081006/c061c6b8/attachment.bin From karnik.jain at einfochips.com Mon Oct 6 04:10:51 2008 From: karnik.jain at einfochips.com (karnik) Date: Mon, 06 Oct 2008 16:40:51 +0530 Subject: [Xorp-users] [OSPF] Message-ID: <48E9F23B.8050904@einfochips.com> How can i configure xorp as a Area Border Router ( *ABR* ) and Autonomous System border router ( *ASBR* )? How can i configure virtual link between to two ABRs ? Tell me configuration for doing above thing. -- _____________________________________________________________________ Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated.Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. __________________________________________________________________________ From lherve at interfaceconcept.com Mon Oct 6 07:28:47 2008 From: lherve at interfaceconcept.com (=?iso-8859-1?Q?Herv=E9_L=E9onard?=) Date: Mon, 6 Oct 2008 16:28:47 +0200 Subject: [Xorp-users] IGMP report group ...? Message-ID: <4FBE10CE37CA46E092BF0A36D9A1D201@lehe6600v> Hi, I try to join a group multicast by sending a IGMP report message from a Linux host to a Linux Xorp router (both on a Linux 2.6 - Ubuntu 8.04 Hardy Heron) Here is the configuration of my testbed: HostA Router B eth0 ---------- eth0 eth1 192.168.2.2 192.168.2.1 100.0.0.1 Host A tries to join the group 239.7.7.7 or 224.7.7.7 by sending IGMP report v2 on the LAN. Xorp Router B do nothing...? Here the Xorp configuration: labo at DOL2400# show protocols { igmp { interface eth0 { vif eth0 { } } traceoptions { flag { all { } } } } static { route 192.168.3.0/24 { next-hop: 100.0.0.2 } } } fea { unicast-forwarding4 { forwarding-entries { } } } interfaces { interface eth0 { description: "Ethernet Interface #1" vif eth0 { address 192.168.2.1 { prefix-length: 24 broadcast: 192.168.2.255 } } } interface eth1 { description: "Ethernet Interface #2" vif eth1 { address 100.0.0.1 { prefix-length: 8 broadcast: 100.255.255.255 } } } } [edit] labo at DOL2400# And when I start this configuration, here is the rtrmgr log: labo at DOL2400:~/src/xorp/xorp-1.5/rtrmgr$ sudo xorp_rtrmgr -b /etc/xorp/config-xorp.sav [sudo] password for labo: [ 2008/10/06 14:22:31 INFO xorp_rtrmgr:17929 RTRMGR +239 master_conf_tree.cc execute ] Changed modules: interfaces, fea, rib, policy, static_routes [ 2008/10/06 14:22:31 INFO xorp_rtrmgr:17929 RTRMGR +96 module_manager.cc execute ] Executing module: interfaces (fea/xorp_fea) [ 2008/10/06 14:22:32 INFO xorp_fea MFEA ] MFEA enabled [ 2008/10/06 14:22:32 INFO xorp_fea MFEA ] CLI enabled [ 2008/10/06 14:22:32 INFO xorp_fea MFEA ] CLI started [ 2008/10/06 14:22:32 INFO xorp_fea MFEA ] MFEA enabled [ 2008/10/06 14:22:32 INFO xorp_fea MFEA ] CLI enabled [ 2008/10/06 14:22:32 INFO xorp_fea MFEA ] CLI started [ 2008/10/06 14:22:33 INFO xorp_rtrmgr:17929 RTRMGR +96 module_manager.cc execute ] Executing module: fea (fea/xorp_fea) [ 2008/10/06 14:22:39 INFO xorp_rtrmgr:17929 RTRMGR +96 module_manager.cc execute ] Executing module: rib (rib/xorp_rib) [ 2008/10/06 14:22:41 INFO xorp_rtrmgr:17929 RTRMGR +96 module_manager.cc execute ] Executing module: policy (policy/xorp_policy) [ 2008/10/06 14:22:43 INFO xorp_rtrmgr:17929 RTRMGR +96 module_manager.cc execute ] Executing module: static_routes (static_routes/xorp_static_routes) [ 2008/10/06 14:22:45 INFO xorp_rtrmgr:17929 RTRMGR +2228 task.cc run_task ] No more tasks to run [ 2008/10/06 14:23:51 INFO xorp_rtrmgr:17929 RTRMGR +96 module_manager.cc execute ] Executing module: mfea4 (fea/xorp_fea) [ 2008/10/06 14:23:51 INFO xorp_fea MFEA ] Interface added: Vif[eth0] pif_index: 3 vif_index: 0 addr: 192.168.2.1 subnet: 192.168.2.0/24 broadcast: 192.168.2.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 [ 2008/10/06 14:23:51 INFO xorp_fea MFEA ] Interface added: Vif[eth1] pif_index: 2 vif_index: 1 addr: 100.0.0.1 subnet: 100.0.0.0/8 broadcast: 100.255.255.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 [ 2008/10/06 14:23:51 ERROR xorp_fea:17930 MFEA +765 mfea_mrouter.cc start_mrt ] setsockopt(MRT_INIT, 1) failed: Address already in use [ 2008/10/06 14:23:51 INFO xorp_fea MFEA ] MFEA started [ 2008/10/06 14:23:51 INFO xorp_rtrmgr:17929 RTRMGR +96 module_manager.cc execute ] Executing module: igmp (mld6igmp/xorp_igmp) [ 2008/10/06 14:23:51 WARNING xorp_rtrmgr:17929 XrlFinderTarget +406 ../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. [ 2008/10/06 14:23:51 INFO xorp_igmp MLD6IGMP ] Protocol enabled [ 2008/10/06 14:23:51 INFO xorp_igmp MLD6IGMP ] CLI enabled [ 2008/10/06 14:23:51 INFO xorp_igmp MLD6IGMP ] CLI started [ 2008/10/06 14:23:52 INFO xorp_igmp MLD6IGMP ] Protocol started [ 2008/10/06 14:23:52 INFO xorp_igmp MLD6IGMP ] Interface added: Vif[eth0] pif_index: 3 vif_index: 0 addr: 192.168.2.1 subnet: 192.168.2.0/24 broadcast: 192.168.2.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 [ 2008/10/06 14:23:52 INFO xorp_igmp MLD6IGMP ] Interface added: Vif[eth1] pif_index: 2 vif_index: 1 addr: 100.0.0.1 subnet: 100.0.0.0/8 broadcast: 100.255.255.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 [ 2008/10/06 14:23:53 INFO xorp_igmp MLD6IGMP ] Interface enabled: Vif[eth0] pif_index: 3 vif_index: 0 addr: 192.168.2.1 subnet: 192.168.2.0/24 broadcast: 192.168.2.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED [ 2008/10/06 14:23:53 INFO xorp_igmp MLD6IGMP ] Interface started: Vif[eth0] pif_index: 3 vif_index: 0 addr: 192.168.2.1 subnet: 192.168.2.0/24 broadcast: 192.168.2.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED [ 2008/10/06 14:23:53 INFO xorp_rtrmgr:17929 RTRMGR +2228 task.cc run_task ] No more tasks to run [ 2008/10/06 14:23:53 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 192.168.2.1 to 224.0.0.2 on vif eth0 [ 2008/10/06 14:23:53 TRACE xorp_igmp MLD6IGMP ] Notify routing add membership for (0.0.0.0, 224.0.0.2) on vif eth0 [ 2008/10/06 14:23:53 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 192.168.2.1 to 224.0.0.22 on vif eth0 [ 2008/10/06 14:23:53 TRACE xorp_igmp MLD6IGMP ] Notify routing add membership for (0.0.0.0, 224.0.0.22) on vif eth0 [ 2008/10/06 14:23:53 TRACE xorp_igmp MLD6IGMP ] RX IGMP_MEMBERSHIP_QUERY from 192.168.2.1 to 224.0.0.1 on vif eth0 [ 2008/10/06 14:23:54 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 192.168.2.2 to 224.0.0.251 on vif eth0 [ 2008/10/06 14:23:54 TRACE xorp_igmp MLD6IGMP ] Notify routing add membership for (0.0.0.0, 224.0.0.251) on vif eth0 [ 2008/10/06 14:23:58 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 192.168.2.1 to 224.0.0.2 on vif eth0 [ 2008/10/06 14:23:59 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 192.168.2.1 to 224.0.0.22 on vif eth0 [ 2008/10/06 14:24:24 TRACE xorp_igmp MLD6IGMP ] TX IGMP_MEMBERSHIP_QUERY from 192.168.2.1 to 224.0.0.1 [ 2008/10/06 14:24:24 TRACE xorp_igmp MLD6IGMP ] RX IGMP_MEMBERSHIP_QUERY from 192.168.2.1 to 224.0.0.1 on vif eth0 [ 2008/10/06 14:24:26 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 192.168.2.2 to 224.0.0.251 on vif eth0 [ 2008/10/06 14:24:30 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 192.168.2.1 to 224.0.0.2 on vif eth0 [ 2008/10/06 14:24:32 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 192.168.2.1 to 224.0.0.22 on vif eth0 Then I start sending IGMP Report message to group multicast address on the eth0: labo at DOL2400:~/etc/xorp$ sudo tcpdump -i eth0 -n -vvv [sudo] password for labo: tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 15:53:14.959119 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA)) 192.168.2.2 > 239.7.7.7: igmp v2 report 239.7.7.7 15:53:22.593183 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA)) 192.168.2.2 > 239.7.7.7: igmp v2 report 239.7.7.7 15:53:27.873692 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA)) 192.168.2.2 > 239.7.7.7: igmp v2 report 239.7.7.7 15:53:57.049679 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA)) 192.168.2.2 > 224.0.0.2: igmp leave 239.7.7.7 15:53:59.061554 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA)) 192.168.2.2 > 239.7.7.7: igmp v2 report 239.7.7.7 15:53:59.446758 IP (tos 0xc0, ttl 1, id 31304, offset 0, flags [none], proto IGMP (2), length 32, options (RA)) 192.168.2.1 > 224.0.0.1: igmp query v2 15:54:00.874230 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA)) 192.168.2.1 > 224.0.0.251: igmp v2 report 224.0.0.251 15:54:04.947704 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA)) 192.168.2.2 > 239.7.7.7: igmp v2 report 239.7.7.7 15:54:06.242220 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA)) 192.168.2.1 > 224.0.0.2: igmp v2 report 224.0.0.2 15:54:09.086227 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA)) 192.168.2.1 > 224.0.0.22: igmp v2 report 224.0.0.22 15:54:26.153357 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA)) 192.168.2.2 > 224.0.0.2: igmp leave 239.7.7.7 15:54:33.163695 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA)) 192.168.2.2 > 239.7.7.7: igmp v2 report 239.7.7.7 15:54:41.247102 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA)) 192.168.2.2 > 239.7.7.7: igmp v2 report 239.7.7.7 15:54:41.654394 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA)) 192.168.2.2 > 239.7.7.7: igmp v2 report 239.7.7.7 15:54:53.184916 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA)) 192.168.2.2 > 224.0.0.2: igmp leave 239.7.7.7 15:55:09.221425 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA)) 192.168.2.2 > 239.7.7.7: igmp v2 report 239.7.7.7 15:55:11.918001 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA)) 192.168.2.2 > 239.7.7.7: igmp v2 report 239.7.7.7 15:55:12.668454 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA)) 192.168.2.2 > 224.0.0.2: igmp leave 239.7.7.7 15:55:16.833821 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA)) 192.168.2.2 > 224.7.7.7: igmp v2 report 224.7.7.7 15:55:16.973124 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA)) 192.168.2.2 > 224.7.7.7: igmp v2 report 224.7.7.7 15:55:23.657583 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 32, options (RA)) 192.168.2.2 > 224.7.7.7: igmp v2 report 224.7.7.7 21 packets captured 21 packets received by filter 0 packets dropped by kernel But my Linux Xorp Router doesn't want to take my group add membership to 239.7.7.7 or 224.7.7.7 labo at DOL2400:~/etc/xorp$ netstat -gn IPv6/Adh?sions au groupe IPv4 Interface RefCnt Group --------------- ------ --------------------- lo 1 224.0.0.1 eth1 1 224.0.0.251 eth1 1 224.0.0.1 eth0 1 224.0.0.22 eth0 1 224.0.0.2 eth0 1 224.0.0.251 eth0 2 224.0.0.1 lo 1 ff02::1 eth1 1 ff02::1:ff58:c5f3 eth1 1 ff02::1 eth0 1 ff02::1:ff4b:2d00 eth0 1 ff02::1 labo at DOL2400> show igmp group Interface Group Source LastReported Timeout V State eth0 224.0.0.2 0.0.0.0 192.168.2.1 180 2 E eth0 224.0.0.22 0.0.0.0 192.168.2.1 183 2 E eth0 224.0.0.251 0.0.0.0 192.168.2.1 174 2 E labo at DOL2400> show igmp interface Interface State Querier Timeout Version Groups eth0 UP 192.168.2.1 None 2 3 eth1 DISABLED 100.0.0.1 None 2 0 labo at DOL2400> Is there any configuration to do on the Xorp Router or in Linux configuration? Many thanks for your advise. Regards, Leonard From bms at incunabulum.net Mon Oct 6 08:32:27 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Mon, 06 Oct 2008 16:32:27 +0100 Subject: [Xorp-users] Builing xorp with --enable-shared vs --with-pic In-Reply-To: <20081005231405.GA7108@calhariz.com> References: <20081005231405.GA7108@calhariz.com> Message-ID: <48EA2F8B.5090500@incunabulum.net> Jose Manuel dos Santos Calhariz wrote: > What is the diference of building xorp using switch --enable-shared vs > --with-pic in a Linux system. > Please don't pass these options to top-level configure as they are not supported, this is why configure.in contains AC_DISABLE_SHARED. [They MAY be supported in future, though I've had more success in this regard with non-GNU build systems i.e. Boost.BuildV2.] The mibs/ directory was broken out into a separate Autoconf package with libtoolization for this reason, it is the only part of XORP which should currently be building with shared library support, as the Net-SNMP extension modules specifically need to be ".so" files. > If building xorp with snmp support it will generate shared libraries > for mibs that are made with objects compiled without -fPIC. This is a > problem in Linux and even breaks on x86_84 systems. > We do use various static libraries to build XORP objects in the mibs directory. To date, I haven't been aware of any problems with this, as we don't try to expose symbols in those objects outside of the .so libraries we have built, and this has worked on the primary development platform, FreeBSD. If this is now causing problems with how amd64 platforms implement -fPIC relocations, then we probably need to revisit the shared library issue on a tree-wide basis. thanks BMS From bms at incunabulum.net Mon Oct 6 08:36:56 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Mon, 06 Oct 2008 16:36:56 +0100 Subject: [Xorp-users] [OSPF] In-Reply-To: <48E9F23B.8050904@einfochips.com> References: <48E9F23B.8050904@einfochips.com> Message-ID: <48EA3098.5050200@incunabulum.net> karnik wrote: > How can i configure xorp as a Area Border Router ( *ABR* ) and > Autonomous System border router ( *ASBR* )? > 1. Configure the router to be in at least two OSPF areas, where at least one of them isn't a stub area. See chapter 8 for examples. 2. Configure an external routing protocol, and redistribute routes into it using the "export:" directive. See Chapter 10 for examples. > How can i configure virtual link between to two ABRs ? > See section 8.3.1 of the user manual, which contains an example of the "virtual-link" directive. Hopefully if someone else has an example they can chime in on this thread. thanks BMS From bms at incunabulum.net Mon Oct 6 08:46:29 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Mon, 06 Oct 2008 16:46:29 +0100 Subject: [Xorp-users] IGMP report group ...? In-Reply-To: <4FBE10CE37CA46E092BF0A36D9A1D201@lehe6600v> References: <4FBE10CE37CA46E092BF0A36D9A1D201@lehe6600v> Message-ID: <48EA32D5.2090502@incunabulum.net> Herv? L?onard wrote: > Hi, > > I try to join a group multicast by sending a IGMP report message from a > Linux host to a Linux Xorp router (both on a Linux 2.6 - Ubuntu 8.04 Hardy > Heron) > ... > Host A tries to join the group 239.7.7.7 or 224.7.7.7 by sending IGMP report > v2 on the LAN. Xorp Router B do nothing...? > .. It looks like your XORP router has not received any IGMPv2 JOIN messages. Please do the following: 1. Check that your network card driver supports "multicast promiscuous" mode (aka ALLMULTI). ifconfig should tell you if this bit is set. 2. Check that your router is receiving the IGMPv2 JOIN messages on the correct MAC address, by passing the -e switch to tcpdump. For IGMPv2, this should be the same as the group's MAC address itself. We need to be sure that the IGMP messages are in fact being accepted by the socket layer, and going to the xorp_fea process. Most likely the problem is further down in the stack though, I've had problems with the FreeBSD fxp(4) driver recently. thanks BMS From pavlin at ICSI.Berkeley.EDU Mon Oct 6 13:44:15 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Mon, 06 Oct 2008 13:44:15 -0700 Subject: [Xorp-users] IGMP report group ...? In-Reply-To: <48EA32D5.2090502@incunabulum.net> References: <4FBE10CE37CA46E092BF0A36D9A1D201@lehe6600v> <48EA32D5.2090502@incunabulum.net> Message-ID: <200810062044.m96KiFW5027324@fruitcake.ICSI.Berkeley.EDU> Please check whether the system has any firewall entries which might drop the IGMP packets. You didn't specify which Linux distribution, but I think on some distributions there are default firewall rules which stop the IGMP packets. Pavlin Bruce M Simpson wrote: > Herv? L?onard wrote: > > Hi, > > > > I try to join a group multicast by sending a IGMP report message from a > > Linux host to a Linux Xorp router (both on a Linux 2.6 - Ubuntu 8.04 Hardy > > Heron) > > ... > > Host A tries to join the group 239.7.7.7 or 224.7.7.7 by sending IGMP report > > v2 on the LAN. Xorp Router B do nothing...? > > > .. > > It looks like your XORP router has not received any IGMPv2 JOIN messages. > > Please do the following: > > 1. Check that your network card driver supports "multicast promiscuous" > mode (aka ALLMULTI). > ifconfig should tell you if this bit is set. > > 2. Check that your router is receiving the IGMPv2 JOIN messages on the > correct MAC address, by passing the -e switch to tcpdump. For IGMPv2, > this should be the same as the group's MAC address itself. > > We need to be sure that the IGMP messages are in fact being accepted by > the socket layer, and going to the xorp_fea process. Most likely the > problem is further down in the stack though, I've had problems with the > FreeBSD fxp(4) driver recently. > > thanks > BMS > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at ICSI.Berkeley.EDU Mon Oct 6 17:33:08 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Mon, 06 Oct 2008 17:33:08 -0700 Subject: [Xorp-users] Builing xorp with --enable-shared vs --with-pic In-Reply-To: <20081005231405.GA7108@calhariz.com> References: <20081005231405.GA7108@calhariz.com> Message-ID: <200810070033.m970X8Vg020898@fruitcake.ICSI.Berkeley.EDU> Jose Manuel dos Santos Calhariz wrote: > Hi > > As I don't understand well the compiling process of xorp 1.5 so I have a > question. > > What is the diference of building xorp using switch --enable-shared vs > --with-pic in a Linux system. > > If building xorp with snmp support it will generate shared libraries > for mibs that are made with objects compiled without -fPIC. This is a > problem in Linux and even breaks on x86_84 systems. > > What is best? --enable-shared or with-pic > > See bug report on Debian for more info > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500325 > > Jose Calhariz What is the original issue you are trying to solve? According to the above Debian bug report, I am guessing XORP failed to compile on x86_64 machine with SNMP enabled. Did you try to use the following commands: ./configure --with-snmp --enable-shared gmake clean gmake The original text in xorp/ERRATA cited FreeBSD as one of the example OS-es that have that problem. I just tried Ubuntu-7.10 on amd64, and using --enable-shared fixed the problem for me. Note that I used latest vanilla XORP code from CVS, including the rev. 1.27 fix to the following file that I just applied: http://cvsweb.xorp.org/cgi-bin/cvsweb.cgi/xorp/mibs/bgp4_mib_1657_bgp4pathattrtable.cc Pavlin From karnik.jain at einfochips.com Mon Oct 6 22:19:26 2008 From: karnik.jain at einfochips.com (karnik) Date: Tue, 07 Oct 2008 10:49:26 +0530 Subject: [Xorp-users] [OSPF] Message-ID: <48EAF15E.6090006@einfochips.com> One more thing i have to ask regarding xorp : Can i do the following testing on xorp? *To verify that an ABR properly uses a configured address range, as per RFC 1583 or not.* -- _____________________________________________________________________ Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated.Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. __________________________________________________________________________ From karnik.jain at einfochips.com Mon Oct 6 23:30:40 2008 From: karnik.jain at einfochips.com (karnik) Date: Tue, 07 Oct 2008 12:00:40 +0530 Subject: [Xorp-users] [BGP] Configuration file Message-ID: <48EB0210.1080500@einfochips.com> Can anyone please send me the sample configuration file for BGP protocol ? -- _____________________________________________________________________ Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated.Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. __________________________________________________________________________ From lherve at interfaceconcept.com Tue Oct 7 02:25:06 2008 From: lherve at interfaceconcept.com (=?iso-8859-1?Q?Herv=E9_L=E9onard?=) Date: Tue, 7 Oct 2008 11:25:06 +0200 Subject: [Xorp-users] IGMP report group ...? In-Reply-To: <48EA32D5.2090502@incunabulum.net> Message-ID: <5FA669C68BA141F99850BD97BB5D3133@lehe6600v> You're right BMS: I did that command on xorp router: #ifconfig eth0 allmulti Then my group join IGMP report messages are dealed and IGMP query are send by xorp router. And I see the IGMP group membership on xorp router. Before that, it seems that the network card driver only forwards to kernel the 224.0.0.x addresses but not the other multicast addresses.... Thanks, L?o -----Message d'origine----- De : Bruce M Simpson Envoy? : lundi 6 octobre 2008 17:46 ? : Herv? L?onard Cc : xorp-users at xorp.org Objet : Re: [Xorp-users] IGMP report group ...? Herv? L?onard wrote: > Hi, > > I try to join a group multicast by sending a IGMP report message from a > Linux host to a Linux Xorp router (both on a Linux 2.6 - Ubuntu 8.04 Hardy > Heron) > ... > Host A tries to join the group 239.7.7.7 or 224.7.7.7 by sending IGMP report > v2 on the LAN. Xorp Router B do nothing...? > .. It looks like your XORP router has not received any IGMPv2 JOIN messages. Please do the following: 1. Check that your network card driver supports "multicast promiscuous" mode (aka ALLMULTI). ifconfig should tell you if this bit is set. 2. Check that your router is receiving the IGMPv2 JOIN messages on the correct MAC address, by passing the -e switch to tcpdump. For IGMPv2, this should be the same as the group's MAC address itself. We need to be sure that the IGMP messages are in fact being accepted by the socket layer, and going to the xorp_fea process. Most likely the problem is further down in the stack though, I've had problems with the FreeBSD fxp(4) driver recently. thanks BMS __________ Information NOD32 3499 (20081007) __________ Ce message a ete verifie par NOD32 Antivirus System. http://www.nod32.com From tushar.mehta at einfochips.com Tue Oct 7 05:08:37 2008 From: tushar.mehta at einfochips.com (Tushar Mehta) Date: Tue, 07 Oct 2008 17:38:37 +0530 Subject: [Xorp-users] Getting problem with MLD Message-ID: <48EB5145.7050302@einfochips.com> I am getting problem in XORP-1.4 with MLD protocol. I want to run XORP as a MLD router but it is crashed while booting!!! *It seems that my kernel is not supporting IPv6 multicasting!!!* what are the changes required in the XORP configuration file or in kernel? My OS specification: Fedora Core 5 kernel version: 2.6.15 XORP version: 1.4 Attachments: 1) Configuration file which is i am using in this case. 2) Snap shot of my desktop when XORP is crashed so you can see what kind of messages it is showing when i run it. 3) Ethereal Packets, which are captured when XORP booted up. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20081007/38b737c1/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot.png Type: image/png Size: 254514 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20081007/38b737c1/attachment-0001.bin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: multicast6.boot Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20081007/38b737c1/attachment-0001.ksh -------------- next part -------------- A non-text attachment was scrubbed... Name: ethereal_xorp_mld_bootup Type: application/octet-stream Size: 490 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20081007/38b737c1/attachment-0001.obj From lherve at interfaceconcept.com Tue Oct 7 09:26:29 2008 From: lherve at interfaceconcept.com (=?iso-8859-1?Q?Herv=E9_L=E9onard?=) Date: Tue, 7 Oct 2008 18:26:29 +0200 Subject: [Xorp-users] IGMP report group ...? In-Reply-To: <48EA32D5.2090502@incunabulum.net> Message-ID: <28619018EB54406EBFEF3581375A6826@lehe6600v> Hi, In fact, i do some other tests... The flag 'ALLMULTI' for the network card driver (in ifconfig) was not the root cause of the group membership in xorp router. It was in fact the IGMP version number for the interface in Xorp configuration. With the IGMP version 2 (by default) the IGMP membership doesn't work. But with version 3, it does. I thought that only one router on the LAN can send IGMP Query, it is the Querier IGMP. And this Querier IGMP should deal with 3 versions of IGMP for all different kinds of hosts on the LAN... Is that the case with Xorp? Thanks, Leonard -----Message d'origine----- De : Bruce M Simpson Envoy? : lundi 6 octobre 2008 17:46 ? : Herv? L?onard Cc : xorp-users at xorp.org Objet : Re: [Xorp-users] IGMP report group ...? Herv? L?onard wrote: > Hi, > > I try to join a group multicast by sending a IGMP report message from a > Linux host to a Linux Xorp router (both on a Linux 2.6 - Ubuntu 8.04 Hardy > Heron) > ... > Host A tries to join the group 239.7.7.7 or 224.7.7.7 by sending IGMP report > v2 on the LAN. Xorp Router B do nothing...? > .. It looks like your XORP router has not received any IGMPv2 JOIN messages. Please do the following: 1. Check that your network card driver supports "multicast promiscuous" mode (aka ALLMULTI). ifconfig should tell you if this bit is set. 2. Check that your router is receiving the IGMPv2 JOIN messages on the correct MAC address, by passing the -e switch to tcpdump. For IGMPv2, this should be the same as the group's MAC address itself. We need to be sure that the IGMP messages are in fact being accepted by the socket layer, and going to the xorp_fea process. Most likely the problem is further down in the stack though, I've had problems with the FreeBSD fxp(4) driver recently. thanks BMS __________ Information NOD32 3499 (20081007) __________ Ce message a ete verifie par NOD32 Antivirus System. http://www.nod32.com From pavlin at ICSI.Berkeley.EDU Tue Oct 7 09:36:29 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Tue, 07 Oct 2008 09:36:29 -0700 Subject: [Xorp-users] Getting problem with MLD In-Reply-To: <48EB5145.7050302@einfochips.com> References: <48EB5145.7050302@einfochips.com> Message-ID: <200810071636.m97GaUbD027443@fruitcake.ICSI.Berkeley.EDU> Tushar Mehta wrote: > I am getting problem in XORP-1.4 with MLD protocol. > I want to run XORP as a MLD router but it is crashed while booting!!! > > *It seems that my kernel is not supporting IPv6 multicasting!!!* IPv6 multicast routing support was added to Linux kernel 2.6.26, hence you need to use a recent OS distribution with that kernel. On XORP side you need to get the latest code from CVS, which fixes some compilation issues introduced by kernel 2.6.26: http://www.xorp.org/cvs.html Also, have a look at XORP Bugzilla entry 761 in case your Linux distribution's glibc has a buggy inet6_opt_init() implementation: http://bugzilla.xorp.org/bugzilla/show_bug.cgi?id=761 Pavlin > what are the changes required in the XORP configuration file or in kernel? > > My OS specification: > Fedora Core 5 > kernel version: 2.6.15 > XORP version: 1.4 > > Attachments: > 1) Configuration file which is i am using in this case. > 2) Snap shot of my desktop when XORP is crashed so you can see what kind of > messages it is showing when i run it. > 3) Ethereal Packets, which are captured when XORP booted up. > > /* $XORP: xorp/rtrmgr/config/multicast6.boot,v 1.1 2007/08/29 06:49:43 pavlin Exp $ */ > > interfaces { > interface eth0 { > vif eth0 { > address 2001:DB8:10:10:10:10:11:11 { > prefix-length: 64 > } > /* Note: The IPv6 link-local address must be configured */ > address fe80::1111:1111:1111:1111 { > prefix-length: 64 > } > } > } > } > > fea { > unicast-forwarding6 { > disable: false > } > } > > plumbing { > mfea6 { > disable: false > interface eth0 { > vif eth0 { > disable: false > } > } > interface register_vif { > vif register_vif { > /* Note: this vif should be always enabled */ > disable: false > } > } > } > } > > protocols { > mld { > interface eth0 { > vif eth0 { > disable: false > } > } > } > } > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at ICSI.Berkeley.EDU Tue Oct 7 10:01:05 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Tue, 07 Oct 2008 10:01:05 -0700 Subject: [Xorp-users] IGMP report group ...? In-Reply-To: <28619018EB54406EBFEF3581375A6826@lehe6600v> References: <28619018EB54406EBFEF3581375A6826@lehe6600v> Message-ID: <200810071701.m97H15Oe000397@fruitcake.ICSI.Berkeley.EDU> Herv? L?onard wrote: > > Hi, > > In fact, i do some other tests... > > The flag 'ALLMULTI' for the network card driver (in ifconfig) was not the > root cause of the group membership in xorp router. > > It was in fact the IGMP version number for the interface in Xorp > configuration. > > With the IGMP version 2 (by default) the IGMP membership doesn't work. But > with version 3, it does. > > I thought that only one router on the LAN can send IGMP Query, it is the > Querier IGMP. And this Querier IGMP should deal with 3 versions of IGMP for > all different kinds of hosts on the LAN... > > Is that the case with Xorp? Few things: * Yes, only the elected Querier should send IGMP Query messages. * If the Querier is configured for IGMPv3, it should deal with all IGMP control messages from other routers and hosts: IGMPv1, IGMPv2, IGMPv3. The XORP IGMPv3 router-side implementation supports that. * If the Querier is configured for IGMPv2, the IGMPv3 hosts MUST operate in IGMPv2 compatibility mode. If they don't, then you need to find the root cause for that: is it on the host side (e.g., the host IGMP implementation) or are there some other factors (e.g., firewall entries on either the host or the router side as I mentioned in my earlier email on the subject). * Setting the XORP IGMP version to 3 is a perfectly acceptable solution. In the future IGMPv3 and MLDv2 will become the default configuration for XORP. Pavlin From bms at incunabulum.net Tue Oct 7 10:32:33 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Tue, 07 Oct 2008 18:32:33 +0100 Subject: [Xorp-users] IGMP report group ...? In-Reply-To: <28619018EB54406EBFEF3581375A6826@lehe6600v> References: <28619018EB54406EBFEF3581375A6826@lehe6600v> Message-ID: <48EB9D31.8040604@incunabulum.net> Herv? L?onard wrote: > The flag 'ALLMULTI' for the network card driver (in ifconfig) was not the > root cause of the group membership in xorp router. > It was in fact the IGMP version number for the interface in Xorp > configuration. > With the IGMP version 2 (by default) the IGMP membership doesn't work. But > with version 3, it does. > Pavlin's already covered most of the technical points here, so I'll be brief: Those could in fact be overlapping issues, as IGMPv3 uses a single link-scope group address for its reports -- therefore a strictly IGMPv3 querier does not need to have the ALLMULTI mode set on the interface, although as it SHOULD listen for old version hosts, this still breaks the spec. A multicast router does of course need to be listening on all groups regardless of whether IGMP is running or not, otherwise it may not be able to forward multicast traffic. You haven't mentioned which network driver you're using in Linux, so broken ALLMULTI filtering still can't be ruled out as the root cause. thanks BMS From jose.spam at netvisao.pt Tue Oct 7 15:31:01 2008 From: jose.spam at netvisao.pt (Jose Manuel dos Santos Calhariz) Date: Tue, 7 Oct 2008 23:31:01 +0100 Subject: [Xorp-users] Builing xorp with --enable-shared vs --with-pic In-Reply-To: <20081005231405.GA7108@calhariz.com> References: <20081005231405.GA7108@calhariz.com> Message-ID: <20081007223101.GA15335@calhariz.com> I don't know why but I didn't receive the 2 replys to my question. Copying from the archives. Jose Manuel dos Santos Calhariz wrote: > > Hi > > > > As I don't understand well the compiling process of xorp 1.5 so I have a > > question. > > > > What is the diference of building xorp using switch --enable-shared vs > > --with-pic in a Linux system. > > > > If building xorp with snmp support it will generate shared libraries > > for mibs that are made with objects compiled without -fPIC. This is a > > problem in Linux and even breaks on x86_84 systems. > > > > What is best? --enable-shared or with-pic > > > > See bug report on Debian for more info > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500325 > > > > Jose Calhariz > What is the original issue you are trying to solve? > According to the above Debian bug report, I am guessing XORP failed > to compile on x86_64 machine with SNMP enabled. > Did you try to use the following commands: > ./configure --with-snmp --enable-shared > gmake clean > gmake > The original text in xorp/ERRATA cited FreeBSD as one of the example > OS-es that have that problem. I just tried Ubuntu-7.10 on amd64, and > using --enable-shared fixed the problem for me. The two options seams to work, --enable-shared and --with-pic. I am asking what is the best option in the opinion of Xorp developers, as I am one of the persons building xorp to be released in Debian. But this weekend I had to use a i386 machine for the tests. It don't break the compilation but complains about non -fPIC code inside a shared library. Now that my x86_64 machine is again working I can try it and be 100% certain that --enable-shared or --with-pic solve the problem. > Note that I used latest vanilla XORP code from CVS, including the > rev. 1.27 fix to the following file that I just applied: > http://cvsweb.xorp.org/cgi-bin/cvsweb.cgi/xorp/mibs/bgp4_mib_1657_bgp4pathattrtable.cc I am using release 1.5 with some updates from CVS. > Pavlin Jos? Calhariz -- -- E parte da cura o desejo de ser curado. -- Seneca, o jovem; filosofo romano4 a.C. ? 65 d.C.. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20081007/f6680bde/attachment.bin From pavlin at ICSI.Berkeley.EDU Tue Oct 7 16:33:46 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Tue, 07 Oct 2008 16:33:46 -0700 Subject: [Xorp-users] Builing xorp with --enable-shared vs --with-pic In-Reply-To: <20081007223101.GA15335@calhariz.com> References: <20081005231405.GA7108@calhariz.com> <20081007223101.GA15335@calhariz.com> Message-ID: <200810072334.m97NXl3K024168@fruitcake.ICSI.Berkeley.EDU> Jose Manuel dos Santos Calhariz wrote: > I don't know why but I didn't receive the 2 replys to my question. > Copying from the archives. Is your subscription email address valid? > Jose Manuel dos Santos Calhariz wrote: > > > > Hi > > > > > > As I don't understand well the compiling process of xorp 1.5 so I have a > > > question. > > > > > > What is the diference of building xorp using switch --enable-shared vs > > > --with-pic in a Linux system. > > > > > > If building xorp with snmp support it will generate shared libraries > > > for mibs that are made with objects compiled without -fPIC. This is a > > > problem in Linux and even breaks on x86_84 systems. > > > > > > What is best? --enable-shared or with-pic > > > > > > See bug report on Debian for more info > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500325 > > > > > > Jose Calhariz > > > What is the original issue you are trying to solve? > > According to the above Debian bug report, I am guessing XORP failed > > to compile on x86_64 machine with SNMP enabled. > > > Did you try to use the following commands: > > ./configure --with-snmp --enable-shared > > gmake clean > > gmake > > > The original text in xorp/ERRATA cited FreeBSD as one of the example > > OS-es that have that problem. I just tried Ubuntu-7.10 on amd64, and > > using --enable-shared fixed the problem for me. > > The two options seams to work, --enable-shared and --with-pic. I am > asking what is the best option in the opinion of Xorp developers, as I > am one of the persons building xorp to be released in Debian. But > this weekend I had to use a i386 machine for the tests. It don't > break the compilation but complains about non -fPIC code inside a > shared library. > > Now that my x86_64 machine is again working I can try it and be 100% > certain that --enable-shared or --with-pic solve the problem. The original advice in xorp/ERRATA was to use --enable-shared. However, if --with-pic solves the problem, I think --enable-shared is probably an overkill. Also, the --enable-shared solution hasn't been tested in details (e.g., whether the libraries are installed properly by "gmake install"), so it might be safer to go with the --with-pic solution. Pavlin > > > Note that I used latest vanilla XORP code from CVS, including the > > rev. 1.27 fix to the following file that I just applied: > > http://cvsweb.xorp.org/cgi-bin/cvsweb.cgi/xorp/mibs/bgp4_mib_1657_bgp4pathattrtable.cc > > I am using release 1.5 with some updates from CVS. > > > Pavlin > > Jos? Calhariz > > -- > -- > E parte da cura o desejo de ser curado. > -- Seneca, o jovem; filosofo romano4 a.C. ? 65 d.C.. > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From karnik.jain at einfochips.com Tue Oct 7 23:49:32 2008 From: karnik.jain at einfochips.com (karnik) Date: Wed, 08 Oct 2008 12:19:32 +0530 Subject: [Xorp-users] [GEN] query-> OSPF (waiting for your Answers) Message-ID: <48EC57FC.6040305@einfochips.com> Query : While Calculating cost only calculate cost For Router to Network not for Network to router why? *Example: *Consider the following *scenario and Figure A* For RTA router if it wants to send packet to RTB Cost = 10 why not , cost = 18 ? If u have answer please tell me............ Shortest Path Tree Assume we have the following network diagram with the indicated interface costs. In order to build the shortest path tree for RTA, we would have to make RTA the root of the tree and calculate the smallest cost for each destination. spf1.gif * figure A* The above is the view of the network as seen from RTA. Note the direction of the arrows in calculating the cost. For example, the cost of RTB's interface to network 128.213.0.0 is not relevant when calculating the cost to 192.213.11.0. RTA can reach 192.213.11.0 via RTB with a cost of 15 (10+5). RTA can also reach 222.211.10.0 via RTC with a cost of 20 (10+10) or via RTB with a cost of 20 (10+5+5). In case equal cost paths exist to the same destination, Cisco's implementation of OSPF will keep track of up to six next hops to the same destination. After the router builds the shortest path tree, it will start building the routing table accordingly. Directly connected networks will be reached via a metric (cost) of 0 and other networks will be reached according to the cost calculated in the tree. -- _____________________________________________________________________ Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated.Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. __________________________________________________________________________ From stegen at owns.com Wed Oct 8 08:20:43 2008 From: stegen at owns.com (Stegen Smith) Date: Wed, 8 Oct 2008 08:20:43 -0700 Subject: [Xorp-users] OpenBSD IGMP/PIM Issue Message-ID: <2C060594-1C67-4BC3-90F6-EC1215DA5296@owns.com> Hello All, I've got encountered an issue while trying to run xorp on an OpenBSD 4.3 i386 GENERIC system using IGMP and PIM. I've got net.inet.ip.forwarding and net.inet.ip.mforwarding enabled, and I'll paste my config below. interfaces { restore-original-config-on-shutdown: false interface vlan40 { description: "data interface" disable: false default-system-config } } fea { unicast-forwarding4 { disable: false } click { disable: true } } plumbing { mfea4 { disable: false interface vlan40 { vif vlan40 { disable: false } } interface register_vif { vif register_vif { disable: false } } traceoptions { flag all { disable: false } } } } protocols { igmp { disable: false interface vlan40 { vif vlan40 { disable: false version: 2 enable-ip-router-alert-option-check: false query-interval: 30 query-last-member-interval: 1 query-response-interval: 10 robust-count: 2 } } traceoptions { flag all { disable: false } } } pimsm4 { disable: false interface vlan40 { vif vlan40 { disable: false dr-priority: 1 hello-period: 30 hello-triggered-delay: 5 } } interface register_vif { vif register_vif { disable: false } } bootstrap { disable: false cand-bsr { scope-zone 224.0.0.0/4 { is-scope-zone: false cand-bsr-by-vif-name: "vlan40" cand-bsr-by-vif-addr: 10.3.48.2 bsr-priority: 1 hash-mask-len: 30 } } } switch-to-spt-threshold { /* approx. 1K bytes/s (10Kbps) threshold */ disable: false interval: 100 bytes: 102400 } traceoptions { flag all { disable: false } } } } Note that I've only got it enabled on vlan40 because I'm not seeing any igmp queries coming from the system at all, and I just wanted a trimmed down configuration until I can see the queries. Now here's an interesting log entry that I've seen. [ 2008/10/07 23:38:13 WARNING xorp_fea XrlFeaTarget ] Handling method for raw_packet4/0.1/send failed: XrlCmdError 102 Command failed sendmsg(proto 2 size 32 from 10.3.48.2 to 224.0.0.1 on interface vlan40 vif vlan40) failed: No route to host I saw something similar in an older post, but there wasn't any follow up to it: http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2004-December/000332.html I'm sure that other folks have gotten this to work on other openbsd systems, but I'm not sure what I'm missing. I'm using an intel em0 interface for vlan40, and MULTICAST is enabled on the interface. I must just be missing something silly! I'm also not sure if I should have fib2mrib enabled or not, but when I do enable it, the xorp_fib2mrib module dies. [ 2008/10/07 23:43:57 ERROR xorp_rtrmgr:14018 RTRMGR +747 module_manager.cc done_cb ] Command "/usr/local/xorp/fib2mrib/ xorp_fib2mrib": terminated with signal 6; aborted with a core dump. [ 2008/10/07 23:43:57 INFO xorp_rtrmgr:14018 RTRMGR +291 module_manager.cc module_exited ] Module coredumped: fib2mrib [ 2008/10/07 23:43:57 INFO xorp_rib RIB ] Received death event for protocol fib2mrib shutting down ------- OriginTable: fib2mrib IGP next table = Redist:fib2mrib ... xorp churns and churns and ultimately ends up here ... [ 2008/10/07 23:46:24 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 1 vif_index = 0 src = 10.3.49.57 dst = 239.1.1.1 [ 2008/10/07 23:46:24 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 1 vif_index = 0 src = 10.3.49.33 dst = 239.1.1.1 [ 2008/10/07 23:46:24 WARNING xorp_rtrmgr:14018 XrlFinderTarget +406 ../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 "fib2mrib" does not exist or is not enabled. [ 2008/10/07 23:46:24 ERROR xorp_rtrmgr:14018 RTRMGR +1998 task.cc task_fail ] Shutting down fatally wounded process (fib2mrib) [ 2008/10/07 23:46:24 ERROR xorp_rtrmgr:14018 RTRMGR +681 master_conf_tree.cc commit_pass2_done ] Commit failed: Can't validate config ready of process fib2mrib [ 2008/10/07 23:46:24 ERROR xorp_rtrmgr:14018 RTRMGR +251 master_conf_tree.cc config_done ] Configuration failed: Can't validate config ready of process fib2mrib xorp_rtrmgr in free(): error: chunk is already free [1] + 14018 abort (core dumped) ./bin/xorp_rtrmgr root134p0at-ig0.sv/usr/local/xorp So I've got it disabled for now, but I figured I'd let this issue be known too. If anyone could provide me with some insight as to what I'm missing I'd definitely be appreciative as I'd love to get this working. =) Also please let me know if I should provide any more information. thanks for the help stegen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20081008/8188cd80/attachment-0001.html From bms at incunabulum.net Wed Oct 8 08:53:59 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Wed, 08 Oct 2008 16:53:59 +0100 Subject: [Xorp-users] OpenBSD IGMP/PIM Issue In-Reply-To: <2C060594-1C67-4BC3-90F6-EC1215DA5296@owns.com> References: <2C060594-1C67-4BC3-90F6-EC1215DA5296@owns.com> Message-ID: <48ECD797.6080207@incunabulum.net> Hi, I'm not sure where the "No route to host" message is coming from, I don't normally use OpenBSD. Normally this suggests that it wasn't possible for a multicast datagram to be sent, for a variety of reasons -- this could be because the socket the process is trying to send on hasn't joined the group. AFAIK the BSDs don't implement strict checks like this. We really need to be sure that IGMP is working in host-mode on vlan40; multicast routers will send IGMP JOIN messages themselves for local-scope groups, whilpst IGMPv3 deprecates this, it's important to allow them to be sent in case layer 2 snooping switches are filtering multicast. It is entirely possible the VLANs you have configured outside of XORP are somehow not passing the ALLMULTI bit down to the lower layer em(4) instance. It looks like everything else is fine in your config. * Can you confirm that the PIM router is receiving IGMP JOIN messages with tcpdump? * And that the parent em(4) interface has ALLMULTI set with ifconfig? * Also, which version of IGMP is in use on the local LAN? (My guess is IGMPv2, as AFAIK, OpenBSD does not support IGMPv3). The fib2mrib crash seems like a red herring for now, we would need a backtrace from the coredump in order to know where to start looking anyway. You could try configuring XORP up on a non-em, non-vlan interface, in order to rule those out as the point of failure. thanks BMS From bms at incunabulum.net Wed Oct 8 09:02:52 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Wed, 08 Oct 2008 17:02:52 +0100 Subject: [Xorp-users] OpenBSD IGMP/PIM Issue In-Reply-To: <2C060594-1C67-4BC3-90F6-EC1215DA5296@owns.com> References: <2C060594-1C67-4BC3-90F6-EC1215DA5296@owns.com> Message-ID: <48ECD9AC.7030902@incunabulum.net> It would also be helpful if you could do the following: 1. Check vlan40 has a valid IPv4 address assigned with ifconfig. 2. Confirm that "normal" IGMP joins go out on vlan40 using mtest (which I believe is still in the OpenBSD tree) and tcpdump. thanks BMS From karnik.jain at einfochips.com Wed Oct 8 00:13:07 2008 From: karnik.jain at einfochips.com (karnik) Date: Wed, 08 Oct 2008 12:43:07 +0530 Subject: [Xorp-users] [OSPF] query Message-ID: <48EC5D83.3020004@einfochips.com> Query : While Calculating cost only calculate cost For Router to Network not for Network to router why? Example: Consider the attached scenario and Figure in attachment. For RTA router if it wants to send packet to RTB Cost = 10 why not , cost = 18 ? -- _____________________________________________________________________ Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated.Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. __________________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: spf.png Type: image/png Size: 51186 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20081008/e94ed1fb/attachment-0001.bin From pavlin at ICSI.Berkeley.EDU Wed Oct 8 09:48:42 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Wed, 08 Oct 2008 09:48:42 -0700 Subject: [Xorp-users] OpenBSD IGMP/PIM Issue In-Reply-To: <2C060594-1C67-4BC3-90F6-EC1215DA5296@owns.com> References: <2C060594-1C67-4BC3-90F6-EC1215DA5296@owns.com> Message-ID: <200810081648.m98Gmgo1028522@fruitcake.ICSI.Berkeley.EDU> Stegen Smith wrote: > Hello All, > > I've got encountered an issue while trying to run xorp on an OpenBSD 4.3 i386 > GENERIC system using IGMP and PIM. > I've got net.inet.ip.forwarding and net.inet.ip.mforwarding enabled, and I'll > paste my config below. Stegen, Do you have the following in your /etc/rc.conf.local file (mentioned in the XORP User Manual, the PIM-SM section): # Enable multicast routing (see netstart(8) for details). multicast_host=NO multicast_router=YES The sendmsg() "No route to host" error seems an indication that the outgoing multicast control packets are dropped by the IPv4 forwarding table check. Typically this happens if the forwarding table is missing a default route or a 224.0.0.0/4 route (you need either one). The above /etc/rc.conf.local configuration fixes that. The xorp_fib2mrib crash seems an orthogonal issue that must be investigated and fixed, hence please send us the coredump trace. Pavlin > interfaces { > restore-original-config-on-shutdown: false > interface vlan40 { > description: "data interface" > disable: false > default-system-config > } > } > > fea { > unicast-forwarding4 { > disable: false > } > click { > disable: true > } > } > > plumbing { > mfea4 { > disable: false > interface vlan40 { > vif vlan40 { > disable: false > } > } > interface register_vif { > vif register_vif { > disable: false > } > } > traceoptions { > flag all { > disable: false > } > } > } > } > > protocols { > igmp { > disable: false > interface vlan40 { > vif vlan40 { > disable: false > version: 2 > enable-ip-router-alert-option-check: false > query-interval: 30 > query-last-member-interval: 1 > query-response-interval: 10 > robust-count: 2 > } > } > traceoptions { > flag all { > disable: false > } > } > } > pimsm4 { > disable: false > interface vlan40 { > vif vlan40 { > disable: false > dr-priority: 1 > hello-period: 30 > hello-triggered-delay: 5 > } > } > interface register_vif { > vif register_vif { > disable: false > } > } > bootstrap { > disable: false > cand-bsr { > scope-zone 224.0.0.0/4 { > is-scope-zone: false > cand-bsr-by-vif-name: "vlan40" > cand-bsr-by-vif-addr: 10.3.48.2 > bsr-priority: 1 > hash-mask-len: 30 > } > } > } > switch-to-spt-threshold { > /* approx. 1K bytes/s (10Kbps) threshold */ > disable: false > interval: 100 > bytes: 102400 > } > > traceoptions { > flag all { > disable: false > } > } > > } > } > > Note that I've only got it enabled on vlan40 because I'm not seeing any igmp > queries coming from the system at all, and I just wanted a trimmed down > configuration until I can see the queries. Now here's an interesting log > entry that I've seen. > > [ 2008/10/07 23:38:13 WARNING xorp_fea XrlFeaTarget ] Handling method for > raw_packet4/0.1/send failed: XrlCmdError 102 Command failed sendmsg(proto 2 > size 32 from 10.3.48.2 to 224.0.0.1 on interface vlan40 vif vlan40) failed: > No route to host > > I saw something similar in an older post, but there wasn't any follow up to > it: > http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2004-December/000332.html > > I'm sure that other folks have gotten this to work on other openbsd systems, > but I'm not sure what I'm missing. I'm using an intel em0 interface for > vlan40, and MULTICAST is enabled on the interface. I must just be missing > something silly! > > I'm also not sure if I should have fib2mrib enabled or not, but when I do > enable it, the xorp_fib2mrib module dies. > [ 2008/10/07 23:43:57 ERROR xorp_rtrmgr:14018 RTRMGR +747 module_manager.cc > done_cb ] Command "/usr/local/xorp/fib2mrib/ xorp_fib2mrib": terminated with > signal 6; aborted with a core dump. > [ 2008/10/07 23:43:57 INFO xorp_rtrmgr:14018 RTRMGR +291 module_manager.cc > module_exited ] Module coredumped: fib2mrib > [ 2008/10/07 23:43:57 INFO xorp_rib RIB ] Received death event for protocol > fib2mrib shutting down ------- > OriginTable: fib2mrib > IGP > next table = Redist:fib2mrib > > ... xorp churns and churns and ultimately ends up here ... > > [ 2008/10/07 23:46:24 TRACE xorp_fea MFEA ] RX kernel signal: message_type = > 1 vif_index = 0 src = 10.3.49.57 dst = 239.1.1.1 > [ 2008/10/07 23:46:24 TRACE xorp_fea MFEA ] RX kernel signal: message_type = > 1 vif_index = 0 src = 10.3.49.33 dst = 239.1.1.1 > [ 2008/10/07 23:46:24 WARNING xorp_rtrmgr:14018 XrlFinderTarget +406 > ../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 > "fib2mrib" does not exist or is not enabled. > [ 2008/10/07 23:46:24 ERROR xorp_rtrmgr:14018 RTRMGR +1998 task.cc task_fail > ] Shutting down fatally wounded process (fib2mrib) > [ 2008/10/07 23:46:24 ERROR xorp_rtrmgr:14018 RTRMGR +681 > master_conf_tree.cc commit_pass2_done ] Commit failed: Can't validate config > ready of process fib2mrib > [ 2008/10/07 23:46:24 ERROR xorp_rtrmgr:14018 RTRMGR +251 > master_conf_tree.cc config_done ] Configuration failed: Can't validate config > ready of process fib2mrib > xorp_rtrmgr in free(): error: chunk is already free > [1] + 14018 abort (core dumped) ./bin/xorp_rtrmgr > root134p0at-ig0.sv/usr/local/xorp > > So I've got it disabled for now, but I figured I'd let this issue be known > too. > > If anyone could provide me with some insight as to what I'm missing I'd > definitely be appreciative as I'd love to get this working. =) Also please > let me know if I should provide any more information. > > thanks for the help > stegen_______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From stegen at owns.com Wed Oct 8 11:46:53 2008 From: stegen at owns.com (Stegen Smith) Date: Wed, 8 Oct 2008 11:46:53 -0700 Subject: [Xorp-users] OpenBSD IGMP/PIM Issue In-Reply-To: <48ECD797.6080207@incunabulum.net> References: <2C060594-1C67-4BC3-90F6-EC1215DA5296@owns.com> <48ECD797.6080207@incunabulum.net> Message-ID: <12129997-E09B-4337-A884-F24A413CB767@owns.com> Hi Bruce, Thank you very much for your reply. Here's some additional information on my setup, which I didn't include earlier, but probably should have. I'm using a source build of xorp 1.5 root0p2at-ig0.sv~ uname -a OpenBSD at-ig0.sv.atomz.com 4.3 ATOMZ_ROUTER#0 i386 root0p2at-ig0.sv~ gcc -v Reading specs from /usr/lib/gcc-lib/i386-unknown-openbsd4.3/3.3.5/specs Configured with: Thread model: single gcc version 3.3.5 (propolice) Also note that I found some other posts regarding bugs with xorp and gcc with propolice, so I've built it with -fno-stack-protector. I also neglected to mention that when I start the software, I see the following error: [ 2008/10/08 11:17:46 ERROR xorp_fea:29494 FEA +74 fibconfig_table_parse_routing_socket.cc parse_buffer_routing_socket ] RTM version mismatch: expected 4 got 3 Perhaps that may also be an issue. (Will touch base with Pavlin on where to send cores ;) ) So here's some more information (I'll also cover Pavlin's reply here as well) I've brought up another em interface, without a vlan (i'll try fxp next, as that's the only other type of nic i've got lying around), and the interface does have ALLMULTI set: root0p2at-ig0.sv~ ifconfig em2 em2: flags=8a43 mtu 1500 lladdr 00:1b:21:26:c2:db groups: egress media: Ethernet autoselect (1000baseT full-duplex,rxpause) status: active inet 10.3.48.1 netmask 0xfffff000 broadcast 10.3.63.255 inet6 fe80::21b:21ff:fe26:c2db%em2 prefixlen 64 scopeid 0x3 I also have mutlicast enabled as per the user manual: root0p2at-ig0.sv~ grep multicast /etc/rc.conf* /etc/rc.conf: # be sure to enable multicast_router below. /etc/rc.conf:multicast_host=YES # Route all multicast packets to a single interface /etc/rc.conf:multicast_router=NO # A multicast routing daemon will be run, e.g. mrouted /etc/rc.conf.local:multicast_host=YES /etc/rc.conf.local:multicast_router=NO there also exists both a default route and a 224/4 route: root0p2at-ig0.sv~ netstat -nr | egrep "(def|^224)" default 10.3.48.3 UGS 0 453 - em2 224/4 link#3 UCS 0 0 - em2 root0p2at-ig0.sv~ The switches that I'm using are cisco catalyst 6509 with the following software: Cisco IOS Software, s72033_rp Software (s72033_rp-ADVIPSERVICESK9_WAN- M), Version 12.2(33)SXH2a, RELEASE SOFTWARE (fc2) I've got igmp snooping enabled and the switch sees the groups: at-is0.sv#show ip igmp groups IGMP Connected Group Membership Group Address Interface Uptime Expires Last Reporter Group Accounted 239.1.1.1 Vlan40 00:17:10 00:02:18 10.3.49.49 224.0.1.40 Vlan40 00:17:10 00:02:28 10.3.48.4 at-is0.sv whereas the other system I've got shows: xorp at at-ig0.sv> show igmp group Interface Group Source LastReported Timeout V State xorp at at-ig0.sv> And I should have checked that before, but no I don't see any igmp report/leaves on a tcpdump. I wasn't paying attention to that, only if I could see query's coming from the system. I'm seeing none of the three, however here's some tcpdump output from a server running some multicast software which is doing some reports/leaves 11:22:25.124631 00:30:48:d1:9d:b2 > 01:00:5e:00:00:02, ethertype IPv4 (0x0800), length 46: 10.3.49.142 > 224.0.0.2: igmp leave 239.1.1.1 11:23:21.496777 00:30:48:d1:9d:b2 > 01:00:5e:01:01:01, ethertype IPv4 (0x0800), length 46: 10.3.49.142 > 239.1.1.1: igmp v2 report 239.1.1.1 11:24:16.540047 00:d0:00:a1:0c:00 > 01:00:5e:00:00:01, ethertype IPv4 (0x0800), length 60: 10.3.48.4 > 224.0.0.1: igmp query v2 11:24:18.513454 00:30:48:d1:9d:b2 > 01:00:5e:01:01:01, ethertype IPv4 (0x0800), length 46: 10.3.49.142 > 239.1.1.1: igmp v2 report 239.1.1.1 10.3.48.4 is the catalyst switch which I enabled pim on as well just so I could see some traffic that I would expect. it doesn't appear that mtest is in openbsd anymore... curtains. I'll dig around and see if I can find something. Thanks again for the help! stegen On Oct 8, 2008, at 8:53 AM, Bruce M Simpson wrote: > Hi, > > I'm not sure where the "No route to host" message is coming from, I > don't normally use OpenBSD. > > Normally this suggests that it wasn't possible for a multicast > datagram to be sent, for a variety of reasons -- this could be > because the socket the process is trying to send on hasn't joined > the group. AFAIK the BSDs don't implement strict checks like this. > > We really need to be sure that IGMP is working in host-mode on > vlan40; multicast routers will send IGMP JOIN messages themselves > for local-scope groups, whilpst IGMPv3 deprecates this, it's > important to allow them to be sent in case layer 2 snooping switches > are filtering multicast. > > It is entirely possible the VLANs you have configured outside of > XORP are somehow not passing the ALLMULTI bit down to the lower > layer em(4) instance. > > It looks like everything else is fine in your config. > > * Can you confirm that the PIM router is receiving IGMP JOIN > messages with tcpdump? > * And that the parent em(4) interface has ALLMULTI set with ifconfig? > * Also, which version of IGMP is in use on the local LAN? > (My guess is IGMPv2, as AFAIK, OpenBSD does not support IGMPv3). > > The fib2mrib crash seems like a red herring for now, we would need a > backtrace from the coredump in order to know where to start looking > anyway. > > You could try configuring XORP up on a non-em, non-vlan interface, > in order to rule those out as the point of failure. > > thanks > BMS > From stegen at owns.com Wed Oct 8 11:54:16 2008 From: stegen at owns.com (Stegen Smith) Date: Wed, 8 Oct 2008 11:54:16 -0700 Subject: [Xorp-users] OpenBSD IGMP/PIM Issue In-Reply-To: <200810081648.m98Gmgo1028522@fruitcake.ICSI.Berkeley.EDU> References: <2C060594-1C67-4BC3-90F6-EC1215DA5296@owns.com> <200810081648.m98Gmgo1028522@fruitcake.ICSI.Berkeley.EDU> Message-ID: Hi Pavlin, On Oct 8, 2008, at 9:48 AM, Pavlin Radoslavov wrote: > > Stegen, > > Do you have the following in your /etc/rc.conf.local file (mentioned > in the XORP User Manual, the PIM-SM section): > > # Enable multicast routing (see netstart(8) for details). > multicast_host=NO > multicast_router=YES > > The sendmsg() "No route to host" error seems an indication that the > outgoing multicast control packets are dropped by the IPv4 > forwarding table check. Typically this happens if the forwarding > table is missing a default route or a 224.0.0.0/4 route (you need > either one). > The above /etc/rc.conf.local configuration fixes that. I touched on the above in my previous reply to Bruce, but I'll just reiterate that yes, I've got the above set on my system to no avail. > The xorp_fib2mrib crash seems an orthogonal issue that must be > investigated and fixed, hence please send us the coredump trace. Where's the best address to send the coredump to? If you need an openbsd test bed, I can get another system online for you... ;) thanks for the help! stegen > > > Pavlin > >> interfaces { >> restore-original-config-on-shutdown: false >> interface vlan40 { >> description: "data interface" >> disable: false >> default-system-config >> } >> } >> >> fea { >> unicast-forwarding4 { >> disable: false >> } >> click { >> disable: true >> } >> } >> >> plumbing { >> mfea4 { >> disable: false >> interface vlan40 { >> vif vlan40 { >> disable: false >> } >> } >> interface register_vif { >> vif register_vif { >> disable: false >> } >> } >> traceoptions { >> flag all { >> disable: false >> } >> } >> } >> } >> >> protocols { >> igmp { >> disable: false >> interface vlan40 { >> vif vlan40 { >> disable: false >> version: 2 >> enable-ip-router-alert-option-check: false >> query-interval: 30 >> query-last-member-interval: 1 >> query-response-interval: 10 >> robust-count: 2 >> } >> } >> traceoptions { >> flag all { >> disable: false >> } >> } >> } >> pimsm4 { >> disable: false >> interface vlan40 { >> vif vlan40 { >> disable: false >> dr-priority: 1 >> hello-period: 30 >> hello-triggered-delay: 5 >> } >> } >> interface register_vif { >> vif register_vif { >> disable: false >> } >> } >> bootstrap { >> disable: false >> cand-bsr { >> scope-zone 224.0.0.0/4 { >> is-scope-zone: false >> cand-bsr-by-vif-name: "vlan40" >> cand-bsr-by-vif-addr: 10.3.48.2 >> bsr-priority: 1 >> hash-mask-len: 30 >> } >> } >> } >> switch-to-spt-threshold { >> /* approx. 1K bytes/s (10Kbps) threshold */ >> disable: false >> interval: 100 >> bytes: 102400 >> } >> >> traceoptions { >> flag all { >> disable: false >> } >> } >> >> } >> } >> >> Note that I've only got it enabled on vlan40 because I'm not >> seeing any igmp >> queries coming from the system at all, and I just wanted a trimmed >> down >> configuration until I can see the queries. Now here's an >> interesting log >> entry that I've seen. >> >> [ 2008/10/07 23:38:13 WARNING xorp_fea XrlFeaTarget ] Handling >> method for >> raw_packet4/0.1/send failed: XrlCmdError 102 Command failed >> sendmsg(proto 2 >> size 32 from 10.3.48.2 to 224.0.0.1 on interface vlan40 vif >> vlan40) failed: >> No route to host >> >> I saw something similar in an older post, but there wasn't any >> follow up to >> it: >> http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2004-December/000332.html >> >> I'm sure that other folks have gotten this to work on other >> openbsd systems, >> but I'm not sure what I'm missing. I'm using an intel em0 >> interface for >> vlan40, and MULTICAST is enabled on the interface. I must just be >> missing >> something silly! >> >> I'm also not sure if I should have fib2mrib enabled or not, but >> when I do >> enable it, the xorp_fib2mrib module dies. >> [ 2008/10/07 23:43:57 ERROR xorp_rtrmgr:14018 RTRMGR +747 >> module_manager.cc >> done_cb ] Command "/usr/local/xorp/fib2mrib/ xorp_fib2mrib": >> terminated with >> signal 6; aborted with a core dump. >> [ 2008/10/07 23:43:57 INFO xorp_rtrmgr:14018 RTRMGR +291 >> module_manager.cc >> module_exited ] Module coredumped: fib2mrib >> [ 2008/10/07 23:43:57 INFO xorp_rib RIB ] Received death event for >> protocol >> fib2mrib shutting down ------- >> OriginTable: fib2mrib >> IGP >> next table = Redist:fib2mrib >> >> ... xorp churns and churns and ultimately ends up here ... >> >> [ 2008/10/07 23:46:24 TRACE xorp_fea MFEA ] RX kernel signal: >> message_type = >> 1 vif_index = 0 src = 10.3.49.57 dst = 239.1.1.1 >> [ 2008/10/07 23:46:24 TRACE xorp_fea MFEA ] RX kernel signal: >> message_type = >> 1 vif_index = 0 src = 10.3.49.33 dst = 239.1.1.1 >> [ 2008/10/07 23:46:24 WARNING xorp_rtrmgr:14018 XrlFinderTarget >> +406 >> ../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 >> "fib2mrib" does not exist or is not enabled. >> [ 2008/10/07 23:46:24 ERROR xorp_rtrmgr:14018 RTRMGR +1998 >> task.cc task_fail >> ] Shutting down fatally wounded process (fib2mrib) >> [ 2008/10/07 23:46:24 ERROR xorp_rtrmgr:14018 RTRMGR +681 >> master_conf_tree.cc commit_pass2_done ] Commit failed: Can't >> validate config >> ready of process fib2mrib >> [ 2008/10/07 23:46:24 ERROR xorp_rtrmgr:14018 RTRMGR +251 >> master_conf_tree.cc config_done ] Configuration failed: Can't >> validate config >> ready of process fib2mrib >> xorp_rtrmgr in free(): error: chunk is already free >> [1] + 14018 abort (core dumped) ./bin/xorp_rtrmgr >> root134p0at-ig0.sv/usr/local/xorp >> >> So I've got it disabled for now, but I figured I'd let this issue >> be known >> too. >> >> If anyone could provide me with some insight as to what I'm >> missing I'd >> definitely be appreciative as I'd love to get this working. =) >> Also please >> let me know if I should provide any more information. >> >> thanks for the help >> stegen_______________________________________________ >> Xorp-users mailing list >> Xorp-users at xorp.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20081008/85d6aae1/attachment-0001.html From pavlin at ICSI.Berkeley.EDU Wed Oct 8 13:42:23 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Wed, 08 Oct 2008 13:42:23 -0700 Subject: [Xorp-users] OpenBSD IGMP/PIM Issue In-Reply-To: References: <2C060594-1C67-4BC3-90F6-EC1215DA5296@owns.com> <200810081648.m98Gmgo1028522@fruitcake.ICSI.Berkeley.EDU> Message-ID: <200810082042.m98KgOZa028662@fruitcake.ICSI.Berkeley.EDU> Stegen, I was able to replicate all of the issues so here is a quick update: * The "RTM version mismatch: expected 4 got 3" error. I will look into that and submit a fix to CVS. Right now I doubt this is related to the rest of the problems. * The fib2mrib coredump seems to be triggered by the FEA failing to read the forwarding table. If you remove the click block in the fea configuration this problem should go away. In any case, this seems a bug in the FEA, because disabled click statement shouldn't trigger that. Hence please submit a Bugzilla entry with your original configuration (fib2mrib and click included), and a copy of the output log messages. * The "No route to host" error message seems to be triggered only for IGMP messages (PIM messages seem to be fine). I will try to investigate the issue, unless Bruce beats me to that if you give him a temp. OpenBSD account :) Pavlin From pavlin at ICSI.Berkeley.EDU Thu Oct 9 00:49:09 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Thu, 09 Oct 2008 00:49:09 -0700 Subject: [Xorp-users] OpenBSD IGMP/PIM Issue In-Reply-To: <200810082042.m98KgOZa028662@fruitcake.ICSI.Berkeley.EDU> References: <2C060594-1C67-4BC3-90F6-EC1215DA5296@owns.com> <200810081648.m98Gmgo1028522@fruitcake.ICSI.Berkeley.EDU> <200810082042.m98KgOZa028662@fruitcake.ICSI.Berkeley.EDU> Message-ID: <200810090749.m997nAkJ010500@fruitcake.ICSI.Berkeley.EDU> Further update on the subject. Pavlin Radoslavov wrote: > Stegen, > > I was able to replicate all of the issues so here is a quick update: > > * The "RTM version mismatch: expected 4 got 3" error. > I will look into that and submit a fix to CVS. > Right now I doubt this is related to the rest of the problems. Those error messages can be ignored. Apparently, OpenBSD sends each routing message twice, once as RTM_VERSION and once as RTM_OVERSION. Anyway, the problem is fixed in CVS: Revision Changes Path 1.17 +12 -2; commitid: 12b3148ed5b5541a7; xorp/fea/data_plane/fibconfig/fibconfig_entry_parse_routing_socket.cc 1.17 +12 -2; commitid: 12b3148ed5b5541a7; xorp/fea/data_plane/fibconfig/fibconfig_table_parse_routing_socket.cc 1.27 +11 -1; commitid: 12b3148ed5b5541a7; xorp/fea/data_plane/ifconfig/ifconfig_parse_routing_socket.cc > * The fib2mrib coredump seems to be triggered by the FEA failing to > read the forwarding table. > If you remove the click block in the fea configuration this > problem should go away. > In any case, this seems a bug in the FEA, because disabled click > statement shouldn't trigger that. Hence please submit a Bugzilla > entry with your original configuration (fib2mrib and click > included), and a copy of the output log messages. > > * The "No route to host" error message seems to be triggered only > for IGMP messages (PIM messages seem to be fine). > I will try to investigate the issue, unless Bruce beats me to that > if you give him a temp. OpenBSD account :) The problem was that the FEA unconditionally enabled the OpenBSD pf(4) firewall on startup, and by default the pf(4) drops IP packets with the Router Alert IP option (included in the IGMP packets). The problem is now fixed in CVS: Revision Changes Path 1.21 +7 -1; commitid: 1346248edb08f41a7; xorp/fea/fea_node.cc 1.8 +7 -1; commitid: 1346248edb08f41a7; xorp/fea/firewall_manager.cc Please get the latest code from CVS and see whether it works for you. If using the CVS code is not an option, a possible hackish work-around is to disable the firewall AFTER XORP is started by using the following UNIX command: pfctl -d Pavlin From stegen at owns.com Thu Oct 9 01:15:28 2008 From: stegen at owns.com (Stegen Smith) Date: Thu, 09 Oct 2008 01:15:28 -0700 Subject: [Xorp-users] OpenBSD IGMP/PIM Issue In-Reply-To: <200810090749.m997nAkJ010500@fruitcake.ICSI.Berkeley.EDU> References: <2C060594-1C67-4BC3-90F6-EC1215DA5296@owns.com> <200810081648.m98Gmgo1028522@fruitcake.ICSI.Berkeley.EDU> <200810082042.m98KgOZa028662@fruitcake.ICSI.Berkeley.EDU> <200810090749.m997nAkJ010500@fruitcake.ICSI.Berkeley.EDU> Message-ID: <48EDBDA0.9050904@owns.com> Sweet! I didn't even think of checking pf. That was the trick! I'll update CVS in the morning and use it with the new fixes. For now, though, disabling pf worked. I'm now seeing the igmp packets coming and going. This is excellent news... thank you very much for the help and I'll let you know how the update works in the morning (which I'm sure it'll work gloriously. ;) ) stegen Pavlin Radoslavov wrote: > Further update on the subject. > > Pavlin Radoslavov wrote: > >> Stegen, >> >> I was able to replicate all of the issues so here is a quick update: >> >> * The "RTM version mismatch: expected 4 got 3" error. >> I will look into that and submit a fix to CVS. >> Right now I doubt this is related to the rest of the problems. > > Those error messages can be ignored. Apparently, OpenBSD sends each > routing message twice, once as RTM_VERSION and once as RTM_OVERSION. > Anyway, the problem is fixed in CVS: > > Revision Changes Path > 1.17 +12 -2; commitid: 12b3148ed5b5541a7; > xorp/fea/data_plane/fibconfig/fibconfig_entry_parse_routing_socket.cc > 1.17 +12 -2; commitid: 12b3148ed5b5541a7; > xorp/fea/data_plane/fibconfig/fibconfig_table_parse_routing_socket.cc > 1.27 +11 -1; commitid: 12b3148ed5b5541a7; > xorp/fea/data_plane/ifconfig/ifconfig_parse_routing_socket.cc > >> * The fib2mrib coredump seems to be triggered by the FEA failing to >> read the forwarding table. >> If you remove the click block in the fea configuration this >> problem should go away. >> In any case, this seems a bug in the FEA, because disabled click >> statement shouldn't trigger that. Hence please submit a Bugzilla >> entry with your original configuration (fib2mrib and click >> included), and a copy of the output log messages. >> >> * The "No route to host" error message seems to be triggered only >> for IGMP messages (PIM messages seem to be fine). >> I will try to investigate the issue, unless Bruce beats me to that >> if you give him a temp. OpenBSD account :) > > The problem was that the FEA unconditionally enabled the OpenBSD > pf(4) firewall on startup, and by default the pf(4) drops IP packets > with the Router Alert IP option (included in the IGMP packets). > > The problem is now fixed in CVS: > > Revision Changes Path > 1.21 +7 -1; commitid: 1346248edb08f41a7; xorp/fea/fea_node.cc > 1.8 +7 -1; commitid: 1346248edb08f41a7; xorp/fea/firewall_manager.cc > > Please get the latest code from CVS and see whether it works for > you. If using the CVS code is not an option, a possible hackish > work-around is to disable the firewall AFTER XORP is started by > using the following UNIX command: > > pfctl -d > > Pavlin > From jose.spam at netvisao.pt Thu Oct 9 02:16:22 2008 From: jose.spam at netvisao.pt (Jose Manuel dos Santos Calhariz) Date: Thu, 9 Oct 2008 10:16:22 +0100 Subject: [Xorp-users] Builing xorp with --enable-shared vs --with-pic In-Reply-To: <200810072334.m97NXl3K024168@fruitcake.ICSI.Berkeley.EDU> References: <20081005231405.GA7108@calhariz.com> <20081007223101.GA15335@calhariz.com> <200810072334.m97NXl3K024168@fruitcake.ICSI.Berkeley.EDU> Message-ID: <20081009091621.GA5379@calhariz.com> On Tue, Oct 07, 2008 at 04:33:46PM -0700, Pavlin Radoslavov wrote: > Jose Manuel dos Santos Calhariz wrote: > > > I don't know why but I didn't receive the 2 replys to my question. > > Copying from the archives. > > Is your subscription email address valid? Yes it is, thank you. I have found and corrected the problem. > > > Jose Manuel dos Santos Calhariz wrote: > > > > > > Hi > > > > > > > > As I don't understand well the compiling process of xorp 1.5 so I have a > > > > question. > > > > > > > > What is the diference of building xorp using switch --enable-shared vs > > > > --with-pic in a Linux system. > > > > > > > > If building xorp with snmp support it will generate shared libraries > > > > for mibs that are made with objects compiled without -fPIC. This is a > > > > problem in Linux and even breaks on x86_84 systems. > > > > > > > > What is best? --enable-shared or with-pic > > > > > > > > See bug report on Debian for more info > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500325 > > > > > > > > Jose Calhariz > > > > > What is the original issue you are trying to solve? > > > According to the above Debian bug report, I am guessing XORP failed > > > to compile on x86_64 machine with SNMP enabled. > > > > > Did you try to use the following commands: > > > ./configure --with-snmp --enable-shared > > > gmake clean > > > gmake > > > > > The original text in xorp/ERRATA cited FreeBSD as one of the example > > > OS-es that have that problem. I just tried Ubuntu-7.10 on amd64, and > > > using --enable-shared fixed the problem for me. > > > > The two options seams to work, --enable-shared and --with-pic. I am > > asking what is the best option in the opinion of Xorp developers, as I > > am one of the persons building xorp to be released in Debian. But > > this weekend I had to use a i386 machine for the tests. It don't > > break the compilation but complains about non -fPIC code inside a > > shared library. > > > > Now that my x86_64 machine is again working I can try it and be 100% > > certain that --enable-shared or --with-pic solve the problem. > > The original advice in xorp/ERRATA was to use --enable-shared. > However, if --with-pic solves the problem, I think --enable-shared > is probably an overkill. Also, the --enable-shared solution hasn't > been tested in details (e.g., whether the libraries are installed > properly by "gmake install"), so it might be safer to go with the > --with-pic solution. I will use the "--with-pic" option, it worked with my test setup for next release of Debian in x86_64. Thank you for your help. If there is peopled interested in this mailing list I may put in a public access repository, non-oficial packages of xorp release 1.5 for Debian 4.0, aka, stable, for i386, amd64, powerpc and sparc archs. > > Pavlin > Jos? Calhariz -- -- E parte da cura o desejo de ser curado. -- Seneca, o jovem; filosofo romano4 a.C. ? 65 d.C.. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20081009/df6091b3/attachment.bin From lherve at interfaceconcept.com Thu Oct 9 09:15:26 2008 From: lherve at interfaceconcept.com (=?iso-8859-1?Q?Herv=E9_L=E9onard?=) Date: Thu, 9 Oct 2008 18:15:26 +0200 Subject: [Xorp-users] IGMP report group ...? In-Reply-To: <200810071701.m97H15Oe000397@fruitcake.ICSI.Berkeley.EDU> Message-ID: <33B56DD6AA684C9DA99F277933E6004F@lehe6600v> Thank you very much Pavlin and Bruce for your answers. I took your advices and tried to go further... In fact, in my first configuration, i did not have the mfea statement (see my first mail): plumbing mfea4 interface eth0 vif eth0... but only the IGMP configuration statement: protocols igmp interface eth0 vif eth0 But the flag ALLMULTI is set on the interface by the option MRT_ADD_VIF using setsockopt() passed to the kernel. And setsockopt(MRT_ADD_VIF) is done in mfea_mrouter.cc is that correct? Anyway, IGMP version 2 WITHOUT the mfea configuration statement for eth0 it doesn't work but WITH the mfea configuration, it does: the IGMP group appears in xorp. Thanks, Leonard -----Message d'origine----- De : Pavlin Radoslavov Envoy? : mardi 7 octobre 2008 19:01 ? : Herv? L?onard Cc : xorp-users at xorp.org Objet : Re: [Xorp-users] IGMP report group ...? Herv? L?onard wrote: > > Hi, > > In fact, i do some other tests... > > The flag 'ALLMULTI' for the network card driver (in ifconfig) was not the > root cause of the group membership in xorp router. > > It was in fact the IGMP version number for the interface in Xorp > configuration. > > With the IGMP version 2 (by default) the IGMP membership doesn't work. But > with version 3, it does. > > I thought that only one router on the LAN can send IGMP Query, it is the > Querier IGMP. And this Querier IGMP should deal with 3 versions of IGMP for > all different kinds of hosts on the LAN... > > Is that the case with Xorp? Few things: * Yes, only the elected Querier should send IGMP Query messages. * If the Querier is configured for IGMPv3, it should deal with all IGMP control messages from other routers and hosts: IGMPv1, IGMPv2, IGMPv3. The XORP IGMPv3 router-side implementation supports that. * If the Querier is configured for IGMPv2, the IGMPv3 hosts MUST operate in IGMPv2 compatibility mode. If they don't, then you need to find the root cause for that: is it on the host side (e.g., the host IGMP implementation) or are there some other factors (e.g., firewall entries on either the host or the router side as I mentioned in my earlier email on the subject). * Setting the XORP IGMP version to 3 is a perfectly acceptable solution. In the future IGMPv3 and MLDv2 will become the default configuration for XORP. Pavlin __________ Information NOD32 3502 (20081007) __________ Ce message a ete verifie par NOD32 Antivirus System. http://www.nod32.com From stegen at owns.com Thu Oct 9 10:02:59 2008 From: stegen at owns.com (Stegen Smith) Date: Thu, 9 Oct 2008 10:02:59 -0700 Subject: [Xorp-users] [Fwd: [PATCH] PF: Allow IP Router Alert option by default] In-Reply-To: <48EDFE40.4010405@icir.org> References: <48EDFE40.4010405@icir.org> Message-ID: <5CE48040-8022-40E0-A006-DDCE7E87DFED@owns.com> Hi Pavlin and Bruce, I just wanted to let the list know that I updated xorp from cvs and all is working out great. Thanks again for all the help and quick turnaroun. Great stuff! stegen On Oct 9, 2008, at 5:51 AM, Bruce M. Simpson wrote: > I actually submitted a patch to dhartmei@ to allow the RA option > filter to be disabled by default, as this is almost always what > bites us with PF on BSD systems. > > Forwarding here to pick up in archives. > > thanks > BMS > > From: Bruce M Simpson > Date: May 4, 2008 8:38:14 PM PDT > To: dhartmei at freebsd.org, Max Laier , Pavlin > Radoslavov > Subject: [PATCH] PF: Allow IP Router Alert option by default > > > I've tested this in a virtual machine, against FreeBSD 6.3-RELEASE, > and it looks fine. > > I'd like to commit it as soon as possible if there are no objections. > > Performance impact should be negligible, though I haven't > measured. The pf_pull_hdr() call is however required as you know, > the mbuf chain might not be pulled up. > > The match is a loose match, although the RA option must come right > after the header. This is the norm for the implementations I've > seen. The value of the option isn't checked, I believe hardware > router boxes don't either. > > I deliberately rolled this to respect the existing values of > "allow_opts", so that existing pfsync installations will continue to > work; nodes which don't understand the PF_ALLOWOPTS_RA flag will > treat it as "allow all options" however. Caveat user: should really > upgrade redundant firewalls in tandem. > > The syntax originally suggested ("allow-opts(RA)") doesn't work, > because the parser treats '(' and ')' as special tokens which can't > be part of other tokens, so I added a keyword "allow-ra-opt". > > cheers > BMS > --- contrib/pf/pfctl/parse.y.orig 2005-05-03 17:55:20.000000000 +0100 > +++ contrib/pf/pfctl/parse.y 2008-05-05 03:15:05.000000000 +0100 > @@ -405,7 +405,8 @@ > %token PASS BLOCK SCRUB RETURN IN OS OUT LOG LOGALL QUICK ON FROM TO > FLAGS > %token RETURNRST RETURNICMP RETURNICMP6 PROTO INET INET6 ALL ANY > ICMPTYPE > %token ICMP6TYPE CODE KEEP MODULATE STATE PORT RDR NAT BINAT ARROW > NODF > -%token MINTTL ERROR ALLOWOPTS FASTROUTE FILENAME ROUTETO DUPTO > REPLYTO NO LABEL > +%token MINTTL ERROR ALLOWOPTS ALLOWOPTSRA > +%token FASTROUTE FILENAME ROUTETO DUPTO REPLYTO NO LABEL > %token NOROUTE FRAGMENT USER GROUP MAXMSS MAXIMUM TTL TOS DROP TABLE > %token REASSEMBLE FRAGDROP FRAGCROP ANCHOR NATANCHOR RDRANCHOR > BINATANCHOR > %token SET OPTIMIZATION TIMEOUT LIMIT LOGINTERFACE BLOCKPOLICY > RANDOMID > @@ -1902,7 +1903,10 @@ > filter_opts.fragment = 1; > } > | ALLOWOPTS { > - filter_opts.allowopts = 1; > + filter_opts.allowopts = PF_ALLOWOPTS_ALL; > + } > + | ALLOWOPTSRA { > + filter_opts.allowopts |= PF_ALLOWOPTS_RA; > } > | label { > if (filter_opts.label) { > @@ -4577,6 +4581,7 @@ > static const struct keywords keywords[] = { > { "all", ALL}, > { "allow-opts", ALLOWOPTS}, > + { "allow-ra-opt", ALLOWOPTSRA}, > { "altq", ALTQ}, > { "anchor", ANCHOR}, > { "antispoof", ANTISPOOF}, > --- contrib/pf/pfctl/pfctl_parser.c.orig 2005-05-03 > 17:55:20.000000000 +0100 > +++ contrib/pf/pfctl/pfctl_parser.c 2008-05-05 03:16:29.000000000 > +0100 > @@ -928,8 +928,10 @@ > printf(" min-ttl %d", r->min_ttl); > if (r->max_mss) > printf(" max-mss %d", r->max_mss); > - if (r->allow_opts) > + if (r->allow_opts & PF_ALLOWOPTS_ALL) > printf(" allow-opts"); > + else if (r->allow_opts & PF_ALLOWOPTS_RA) > + printf(" allow-ra-opt"); > if (r->action == PF_SCRUB) { > if (r->rule_flag & PFRULE_REASSEMBLE_TCP) > printf(" reassemble tcp"); > --- sys/contrib/pf/net/pf.c.orig 2008-05-05 04:12:00.000000000 +0100 > +++ sys/contrib/pf/net/pf.c 2008-05-05 04:24:48.000000000 +0100 > @@ -6681,13 +6681,35 @@ > } > > done: > - if (action == PF_PASS && h->ip_hl > 5 && > - !((s && s->allow_opts) || r->allow_opts)) { > - action = PF_DROP; > - REASON_SET(&reason, PFRES_IPOPTIONS); > - log = 1; > - DPFPRINTF(PF_DEBUG_MISC, > - ("pf: dropping packet with ip options\n")); > + if (action == PF_PASS && h->ip_hl > 5) { > + do { > + /* If allow-opts is set, allow any IP option. */ > + if ((s && (s->allow_opts & PF_ALLOWOPTS_ALL)) || > + (r->allow_opts & PF_ALLOWOPTS_ALL)) > + break; > + /* > + * If allow-ra-opt is set, allow only the > + * IP Router Alert option; it must be the first > + * IP option, and its value is ignored. > + */ > + if ((s && (s->allow_opts & PF_ALLOWOPTS_RA)) || > + (r->allow_opts & PF_ALLOWOPTS_RA)) { > + uint8_t opt[4]; > + if (pf_pull_hdr(m, sizeof(struct ip), > + &opt[0], sizeof(opt), > + &action, &reason, > + AF_INET) != NULL) { > + if (opt[0] == IPOPT_RA && > + opt[1] == 4) > + break; > + } > + } > + action = PF_DROP; > + REASON_SET(&reason, PFRES_IPOPTIONS); > + log = 1; > + DPFPRINTF(PF_DEBUG_MISC, > + ("pf: dropping packet with ip options\n")); > + } while (0); > } > > if (s && s->tag) > --- sys/contrib/pf/net/pf_ioctl.c.orig 2007-01-04 18:31:43.000000000 > +0000 > +++ sys/contrib/pf/net/pf_ioctl.c 2008-05-05 04:23:02.000000000 +0100 > @@ -320,6 +320,7 @@ > /* default rule should never be garbage collected */ > pf_default_rule.entries.tqe_prev = &pf_default_rule.entries.tqe_next; > pf_default_rule.action = PF_PASS; > + pf_default_rule.allow_opts = PF_ALLOWOPTS_RA; > pf_default_rule.nr = -1; > > /* initialize default timeouts */ > @@ -391,6 +392,7 @@ > /* default rule should never be garbage collected */ > pf_default_rule.entries.tqe_prev = &pf_default_rule.entries.tqe_next; > pf_default_rule.action = PF_PASS; > + pf_default_rule.allow_opts = PF_ALLOWOPTS_RA; > pf_default_rule.nr = -1; > > /* initialize default timeouts */ > --- sys/contrib/pf/net/pfvar.h.orig 2005-12-30 00:50:18.000000000 > +0000 > +++ sys/contrib/pf/net/pfvar.h 2008-05-05 03:05:42.000000000 +0100 > @@ -651,6 +651,9 @@ > u_int8_t flagset; > u_int8_t min_ttl; > u_int8_t allow_opts; > +#define PF_ALLOWOPTS_ALL 0x1 > +#define PF_ALLOWOPTS_RA 0x2 /* IP Router Alert */ > +#define PF_ALLOWOPTS_MASK 0x3 > u_int8_t rt; > u_int8_t return_ttl; > u_int8_t tos; > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20081009/4dc97231/attachment-0001.html From pavlin at ICSI.Berkeley.EDU Thu Oct 9 12:27:55 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Thu, 09 Oct 2008 12:27:55 -0700 Subject: [Xorp-users] IGMP report group ...? In-Reply-To: <33B56DD6AA684C9DA99F277933E6004F@lehe6600v> References: <33B56DD6AA684C9DA99F277933E6004F@lehe6600v> Message-ID: <200810091927.m99JRtDQ010589@fruitcake.ICSI.Berkeley.EDU> Herv? L?onard wrote: > > Thank you very much Pavlin and Bruce for your answers. I took your advices > and tried to go further... > > In fact, in my first configuration, i did not have the mfea statement (see > my first mail): > > plumbing mfea4 interface eth0 vif eth0... You must have the mfea statement in your config for all the IGMP and PIM-SM enabled interfaces (incl. "interface register_vif"); it was an oversight on my side that I didn't notice that in your original email. > but only the IGMP configuration statement: > > protocols igmp interface eth0 vif eth0 > > > But the flag ALLMULTI is set on the interface by the option MRT_ADD_VIF > using setsockopt() passed to the kernel. > And setsockopt(MRT_ADD_VIF) is done in mfea_mrouter.cc > > is that correct? Yes. Pavlin > Anyway, IGMP version 2 WITHOUT the mfea configuration statement for eth0 it > doesn't work but WITH the mfea configuration, it does: the IGMP group > appears in xorp. > > > Thanks, > Leonard > > > -----Message d'origine----- > De : Pavlin Radoslavov > Envoy? : mardi 7 octobre 2008 19:01 > ? : Herv? L?onard > Cc : xorp-users at xorp.org > Objet : Re: [Xorp-users] IGMP report group ...? > > > Herv? L?onard wrote: > > > > > Hi, > > > > In fact, i do some other tests... > > > > The flag 'ALLMULTI' for the network card driver (in ifconfig) was not the > > root cause of the group membership in xorp router. > > > > It was in fact the IGMP version number for the interface in Xorp > > configuration. > > > > With the IGMP version 2 (by default) the IGMP membership doesn't work. But > > with version 3, it does. > > > > I thought that only one router on the LAN can send IGMP Query, it is the > > Querier IGMP. And this Querier IGMP should deal with 3 versions of IGMP > for > > all different kinds of hosts on the LAN... > > > > Is that the case with Xorp? > > Few things: > > * Yes, only the elected Querier should send IGMP Query messages. > * If the Querier is configured for IGMPv3, it should deal with all > IGMP control messages from other routers and hosts: IGMPv1, > IGMPv2, IGMPv3. > The XORP IGMPv3 router-side implementation supports that. > * If the Querier is configured for IGMPv2, the IGMPv3 hosts MUST > operate in IGMPv2 compatibility mode. If they don't, then you need > to find the root cause for that: is it on the host side (e.g., the > host IGMP implementation) or are there some other factors (e.g., > firewall entries on either the host or the router side as I > mentioned in my earlier email on the subject). > * Setting the XORP IGMP version to 3 is a perfectly acceptable > solution. In the future IGMPv3 and MLDv2 will become the default > configuration for XORP. > > Pavlin > > __________ Information NOD32 3502 (20081007) __________ > > Ce message a ete verifie par NOD32 Antivirus System. > http://www.nod32.com > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at ICSI.Berkeley.EDU Thu Oct 9 12:39:55 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Thu, 09 Oct 2008 12:39:55 -0700 Subject: [Xorp-users] [Fwd: [PATCH] PF: Allow IP Router Alert option by default] In-Reply-To: <5CE48040-8022-40E0-A006-DDCE7E87DFED@owns.com> References: <48EDFE40.4010405@icir.org> <5CE48040-8022-40E0-A006-DDCE7E87DFED@owns.com> Message-ID: <200810091939.m99JdtMQ012020@fruitcake.ICSI.Berkeley.EDU> Stegen Smith wrote: > Hi Pavlin and Bruce, > > I just wanted to let the list know that I updated xorp from cvs and all is > working out great. Thanks again for all the help and quick turnaroun. Great > stuff! Stegen, thanks for the update on the subject. Bruce, it was a good call on your side when you pushed that change to FreeBSD. However, it appears that in OpenBSD the IP Router Alert options are explicitly disabled by default. Given that you have done the FreeBSD implementation nits and details, can you raise the issue with the OpenBSD folks so they also don't disable the RAs in their stack. You have my full support on that. Disabled RAs breaks IGMP on both sides (router and host), and debugging multicast-related issues is hard enough even without this obstacle. Pavlin > stegen > On Oct 9, 2008, at 5:51 AM, Bruce M. Simpson wrote: > > > I actually submitted a patch to dhartmei@ to allow the RA option filter to > > be disabled by default, as this is almost always what bites us with PF on > > BSD systems. > > > > Forwarding here to pick up in archives. > > > > thanks > > BMS > > > > From: Bruce M Simpson > > Date: May 4, 2008 8:38:14 PM PDT > > To: dhartmei at freebsd.org, Max Laier , Pavlin Radoslavov > > > > Subject: [PATCH] PF: Allow IP Router Alert option by default > > > > > > I've tested this in a virtual machine, against FreeBSD 6.3-RELEASE, and it > > looks fine. > > > > I'd like to commit it as soon as possible if there are no objections. > > > > Performance impact should be negligible, though I haven't measured. The > > pf_pull_hdr() call is however required as you know, the mbuf chain might > > not be pulled up. > > > > The match is a loose match, although the RA option must come right after > > the header. This is the norm for the implementations I've seen. The value > > of the option isn't checked, I believe hardware router boxes don't either. > > > > I deliberately rolled this to respect the existing values of > > "allow_opts", so that existing pfsync installations will continue to work; > > nodes which don't understand the PF_ALLOWOPTS_RA flag will treat it as > > "allow all options" however. Caveat user: should really upgrade redundant > > firewalls in tandem. > > > > The syntax originally suggested ("allow-opts(RA)") doesn't work, because > > the parser treats '(' and ')' as special tokens which can't be part of > > other tokens, so I added a keyword "allow-ra-opt". > > > > cheers > > BMS > > --- contrib/pf/pfctl/parse.y.orig 2005-05-03 17:55:20.000000000 +0100 > > +++ contrib/pf/pfctl/parse.y 2008-05-05 03:15:05.000000000 +0100 > > @@ -405,7 +405,8 @@ > > %token PASS BLOCK SCRUB RETURN IN OS OUT LOG LOGALL QUICK ON FROM TO > > FLAGS > > %token RETURNRST RETURNICMP RETURNICMP6 PROTO INET INET6 ALL ANY > > ICMPTYPE > > %token ICMP6TYPE CODE KEEP MODULATE STATE PORT RDR NAT BINAT ARROW > > NODF > > -%token MINTTL ERROR ALLOWOPTS FASTROUTE FILENAME ROUTETO DUPTO > > REPLYTO NO LABEL > > +%token MINTTL ERROR ALLOWOPTS ALLOWOPTSRA > > +%token FASTROUTE FILENAME ROUTETO DUPTO REPLYTO NO LABEL > > %token NOROUTE FRAGMENT USER GROUP MAXMSS MAXIMUM TTL TOS DROP TABLE > > %token REASSEMBLE FRAGDROP FRAGCROP ANCHOR NATANCHOR RDRANCHOR > > BINATANCHOR > > %token SET OPTIMIZATION TIMEOUT LIMIT LOGINTERFACE BLOCKPOLICY > > RANDOMID > > @@ -1902,7 +1903,10 @@ > > filter_opts.fragment = 1; > > } > > | ALLOWOPTS { > > - filter_opts.allowopts = 1; > > + filter_opts.allowopts = PF_ALLOWOPTS_ALL; > > + } > > + | ALLOWOPTSRA { > > + filter_opts.allowopts |= PF_ALLOWOPTS_RA; > > } > > | label { > > if (filter_opts.label) { > > @@ -4577,6 +4581,7 @@ > > static const struct keywords keywords[] = { > > { "all", ALL}, > > { "allow-opts", ALLOWOPTS}, > > + { "allow-ra-opt", ALLOWOPTSRA}, > > { "altq", ALTQ}, > > { "anchor", ANCHOR}, > > { "antispoof", ANTISPOOF}, > > --- contrib/pf/pfctl/pfctl_parser.c.orig 2005-05-03 17:55:20.000000000 > > +0100 > > +++ contrib/pf/pfctl/pfctl_parser.c 2008-05-05 03:16:29.000000000 +0100 > > @@ -928,8 +928,10 @@ > > printf(" min-ttl %d", r->min_ttl); > > if (r->max_mss) > > printf(" max-mss %d", r->max_mss); > > - if (r->allow_opts) > > + if (r->allow_opts & PF_ALLOWOPTS_ALL) > > printf(" allow-opts"); > > + else if (r->allow_opts & PF_ALLOWOPTS_RA) > > + printf(" allow-ra-opt"); > > if (r->action == PF_SCRUB) { > > if (r->rule_flag & PFRULE_REASSEMBLE_TCP) > > printf(" reassemble tcp"); > > --- sys/contrib/pf/net/pf.c.orig 2008-05-05 04:12:00.000000000 +0100 > > +++ sys/contrib/pf/net/pf.c 2008-05-05 04:24:48.000000000 +0100 > > @@ -6681,13 +6681,35 @@ > > } > > > > done: > > - if (action == PF_PASS && h->ip_hl > 5 && > > - !((s && s->allow_opts) || r->allow_opts)) { > > - action = PF_DROP; > > - REASON_SET(&reason, PFRES_IPOPTIONS); > > - log = 1; > > - DPFPRINTF(PF_DEBUG_MISC, > > - ("pf: dropping packet with ip options\n")); > > + if (action == PF_PASS && h->ip_hl > 5) { > > + do { > > + /* If allow-opts is set, allow any IP option. */ > > + if ((s && (s->allow_opts & PF_ALLOWOPTS_ALL)) || > > + (r->allow_opts & PF_ALLOWOPTS_ALL)) > > + break; > > + /* > > + * If allow-ra-opt is set, allow only the > > + * IP Router Alert option; it must be the first > > + * IP option, and its value is ignored. > > + */ > > + if ((s && (s->allow_opts & PF_ALLOWOPTS_RA)) || > > + (r->allow_opts & PF_ALLOWOPTS_RA)) { > > + uint8_t opt[4]; > > + if (pf_pull_hdr(m, sizeof(struct ip), > > + &opt[0], sizeof(opt), > > + &action, &reason, > > + AF_INET) != NULL) { > > + if (opt[0] == IPOPT_RA && > > + opt[1] == 4) > > + break; > > + } > > + } > > + action = PF_DROP; > > + REASON_SET(&reason, PFRES_IPOPTIONS); > > + log = 1; > > + DPFPRINTF(PF_DEBUG_MISC, > > + ("pf: dropping packet with ip options\n")); > > + } while (0); > > } > > > > if (s && s->tag) > > --- sys/contrib/pf/net/pf_ioctl.c.orig 2007-01-04 18:31:43.000000000 > > +0000 > > +++ sys/contrib/pf/net/pf_ioctl.c 2008-05-05 04:23:02.000000000 +0100 > > @@ -320,6 +320,7 @@ > > /* default rule should never be garbage collected */ > > pf_default_rule.entries.tqe_prev = &pf_default_rule.entries.tqe_next; > > pf_default_rule.action = PF_PASS; > > + pf_default_rule.allow_opts = PF_ALLOWOPTS_RA; > > pf_default_rule.nr = -1; > > > > /* initialize default timeouts */ > > @@ -391,6 +392,7 @@ > > /* default rule should never be garbage collected */ > > pf_default_rule.entries.tqe_prev = &pf_default_rule.entries.tqe_next; > > pf_default_rule.action = PF_PASS; > > + pf_default_rule.allow_opts = PF_ALLOWOPTS_RA; > > pf_default_rule.nr = -1; > > > > /* initialize default timeouts */ > > --- sys/contrib/pf/net/pfvar.h.orig 2005-12-30 00:50:18.000000000 +0000 > > +++ sys/contrib/pf/net/pfvar.h 2008-05-05 03:05:42.000000000 +0100 > > @@ -651,6 +651,9 @@ > > u_int8_t flagset; > > u_int8_t min_ttl; > > u_int8_t allow_opts; > > +#define PF_ALLOWOPTS_ALL 0x1 > > +#define PF_ALLOWOPTS_RA 0x2 /* IP Router Alert */ > > +#define PF_ALLOWOPTS_MASK 0x3 > > u_int8_t rt; > > u_int8_t return_ttl; > > u_int8_t tos; > > > > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From greearb at candelatech.com Thu Oct 9 15:21:21 2008 From: greearb at candelatech.com (Ben Greear) Date: Thu, 09 Oct 2008 15:21:21 -0700 Subject: [Xorp-users] BGP route-reflector question. Message-ID: <48EE83E1.1080503@candelatech.com> I'm trying to add BGP support to or xorp configurator. In the manual, section 10.3.1, the syntax is shown as: route-reflector text { ... } However, when I use this config, it will not parse. I think it doesn't like the '1' for the 'text' portion: route-reflector 1 { identifier: 4.4.4.4 disable: false } What is 'text' supposed to be? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Thu Oct 9 15:49:26 2008 From: greearb at candelatech.com (Ben Greear) Date: Thu, 09 Oct 2008 15:49:26 -0700 Subject: [Xorp-users] BGP route-reflector question. In-Reply-To: <48EE83E1.1080503@candelatech.com> References: <48EE83E1.1080503@candelatech.com> Message-ID: <48EE8A76.80005@candelatech.com> Ben Greear wrote: > I'm trying to add BGP support to or xorp configurator. > > In the manual, section 10.3.1, the syntax is shown as: > > route-reflector text { > ... > } > > However, when I use this config, it will not parse. I think > it doesn't like the '1' for the 'text' portion: > > route-reflector 1 { > identifier: 4.4.4.4 > disable: false > } Seems it works fine if you just leave out the 'text' portion (and fix the 'identifier' which should be 'cluster-id'). Now, it seems that bgp might not be using fea, and if so, then I'm going to need to hack on it's socket code to bind to a specific device (SO_BINDTODEVICE) for my application. To do this right, I guess I'd need to change the config to have a local port-name instead of local-ip for peers, and a local port-name argument to the main bgp block for binding the bgp-id address? Anyone have any suggestions on better ways to do this? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From bms at incunabulum.net Thu Oct 9 16:14:39 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Fri, 10 Oct 2008 00:14:39 +0100 Subject: [Xorp-users] BGP route-reflector question. In-Reply-To: <48EE8A76.80005@candelatech.com> References: <48EE83E1.1080503@candelatech.com> <48EE8A76.80005@candelatech.com> Message-ID: <48EE905F.3010809@incunabulum.net> Ben Greear wrote: > ... > Now, it seems that bgp might not be using fea, and if so, then I'm > going to need to hack on it's socket code to bind to a specific > device (SO_BINDTODEVICE) for my application. > I believe Atanu's been working on the rewrite of BGP to use the FEA for sockets but I could be wrong. There are XRLs which wrap the wholly Linux specific SO_BINDTODEVICE option in the FEA. They are used by OLSR. There are also low-level libcomm functions which wrap it. cheers BMS From stegen at owns.com Thu Oct 9 16:28:55 2008 From: stegen at owns.com (Stegen Smith) Date: Thu, 09 Oct 2008 16:28:55 -0700 Subject: [Xorp-users] xorp clearing routing table upon startup Message-ID: <48EE93B7.8020607@owns.com> Hello again group! So I've got another question regarding xorp clearing the routing table on the system while starting up. I'm guessing that is the default behavior, but I was wondering if it could be disabled/modified. Here's the situation that I'm seeing. I've got openbgpd setup on my router, and have yet to configure bgp in xorp (unsure if I want to stick with openbgp or use xorp... I'm vacillating... but maybe this will force my hand!). So, openbgpd obviously inserts its routes into the routing table: root1p2at-ig1.sv~ netstat -nr|grep 10.3.48 10.3.48/20 10.3.14.39 UG1 0 0 - vlan290 I then startup xorp and: root1p2at-ig1.sv~ netstat -nr|grep 10.3.48 root1p2at-ig1.sv~ So is there any chance that I would be able to get them to play nicely, or is it a pipe dream? I guess that'd be a push to get everything into xorp ;) Here's my configuration if that helps: interfaces { restore-original-config-on-shutdown: false interface vlan41 { description: "data interface" disable: false default-system-config } } fea { unicast-forwarding4 { disable: false } } plumbing { mfea4 { disable: false interface vlan41 { vif vlan41 { disable: false } } interface register_vif { vif register_vif { disable: false } } } } protocols { igmp { disable: false interface vlan41 { vif vlan41 { disable: false version: 2 enable-ip-router-alert-option-check: false query-interval: 60 query-last-member-interval: 1 query-response-interval: 10 robust-count: 2 } } } pimsm4 { disable: false interface vlan41 { vif vlan41 { disable: false dr-priority: 1 hello-period: 30 hello-triggered-delay: 5 } } interface register_vif { vif register_vif { disable: false } } /* bootstrap { disable: false cand-bsr { scope-zone 224.0.0.0/4 { is-scope-zone: false cand-bsr-by-vif-name: "vlan41" cand-bsr-by-vif-addr: 10.3.96.2 bsr-priority: 1 hash-mask-len: 30 } } } */ /* Note: static-rps and bootstrap should not be mixed */ static-rps { rp 10.3.96.2 { group-prefix 224.0.0.0/4 { } } } switch-to-spt-threshold { /* approx. 1K bytes/s (10Kbps) threshold */ disable: false interval: 100 bytes: 102400 } } fib2mrib { disable: false } } Thanks for the help, and I apologize in advance if this is too much =) stegen From greearb at candelatech.com Thu Oct 9 16:33:34 2008 From: greearb at candelatech.com (Ben Greear) Date: Thu, 09 Oct 2008 16:33:34 -0700 Subject: [Xorp-users] BGP route-reflector question. In-Reply-To: <48EE905F.3010809@incunabulum.net> References: <48EE83E1.1080503@candelatech.com> <48EE8A76.80005@candelatech.com> <48EE905F.3010809@incunabulum.net> Message-ID: <48EE94CE.5010905@candelatech.com> Bruce M Simpson wrote: > Ben Greear wrote: >> ... >> Now, it seems that bgp might not be using fea, and if so, then I'm >> going to need to hack on it's socket code to bind to a specific >> device (SO_BINDTODEVICE) for my application. >> > > I believe Atanu's been working on the rewrite of BGP to use the FEA for > sockets but I could be wrong. > > There are XRLs which wrap the wholly Linux specific SO_BINDTODEVICE > option in the FEA. They are used by OLSR. There are also low-level > libcomm functions which wrap it. Yeah, it's not difficult to make the system calls..the rough part for me is dealing with configuration since I don't know that code well. Atanu: If you're working on moving it to Fea, please let me know..perhaps I can help. Thanks, Ben > > cheers > BMS -- Ben Greear Candela Technologies Inc http://www.candelatech.com From stegen at owns.com Thu Oct 9 16:40:49 2008 From: stegen at owns.com (Stegen Smith) Date: Thu, 09 Oct 2008 16:40:49 -0700 Subject: [Xorp-users] xorp clearing routing table upon startup In-Reply-To: <48EE93B7.8020607@owns.com> References: <48EE93B7.8020607@owns.com> Message-ID: <48EE9681.1060001@owns.com> Also an interesting thing to note is that if a routing entry is added manually, I see the following happening: [ 2008/10/09 16:31:35 ERROR xorp_fea:15980 XRL +379 xrl_pf_stcp.cc die ] STCPRequestHandler died: life timer expired [ 2008/10/09 16:31:35 ERROR xorp_fea:15980 XRL +379 xrl_pf_stcp.cc die ] STCPRequestHandler died: life timer expired And also, I forgot to give the following information... I'm using the latest xorp build from cvs, and this is openbsd 4.3. thanks! stegen Stegen Smith wrote: > Hello again group! > > So I've got another question regarding xorp clearing the routing table on the system while starting up. > I'm guessing that is the default behavior, but I was wondering if it could be disabled/modified. Here's the situation > that I'm seeing. I've got openbgpd setup on my router, and have yet to configure bgp in xorp (unsure if I want to > stick with openbgp or use xorp... I'm vacillating... but maybe this will force my hand!). > > So, openbgpd obviously inserts its routes into the routing table: > root1p2at-ig1.sv~ netstat -nr|grep 10.3.48 > 10.3.48/20 10.3.14.39 UG1 0 0 - vlan290 > > I then startup xorp and: > root1p2at-ig1.sv~ netstat -nr|grep 10.3.48 > root1p2at-ig1.sv~ > > So is there any chance that I would be able to get them to play nicely, or is it a pipe dream? I guess that'd be a push to get everything into xorp ;) > > Here's my configuration if that helps: > > interfaces { > restore-original-config-on-shutdown: false > interface vlan41 { > description: "data interface" > disable: false > default-system-config > } > } > > fea { > unicast-forwarding4 { > disable: false > } > } > > plumbing { > mfea4 { > disable: false > interface vlan41 { > vif vlan41 { > disable: false > } > } > interface register_vif { > vif register_vif { > disable: false > } > } > } > } > > protocols { > igmp { > disable: false > interface vlan41 { > vif vlan41 { > disable: false > version: 2 > enable-ip-router-alert-option-check: false > query-interval: 60 > query-last-member-interval: 1 > query-response-interval: 10 > robust-count: 2 > } > } > } > > pimsm4 { > disable: false > interface vlan41 { > vif vlan41 { > disable: false > dr-priority: 1 > hello-period: 30 > hello-triggered-delay: 5 > } > } > interface register_vif { > vif register_vif { > disable: false > } > } > /* > bootstrap { > disable: false > cand-bsr { > scope-zone 224.0.0.0/4 { > is-scope-zone: false > cand-bsr-by-vif-name: "vlan41" > cand-bsr-by-vif-addr: 10.3.96.2 > bsr-priority: 1 > hash-mask-len: 30 > } > } > } > */ > /* Note: static-rps and bootstrap should not be mixed */ > static-rps { > rp 10.3.96.2 { > group-prefix 224.0.0.0/4 { > } > } > } > > switch-to-spt-threshold { > /* approx. 1K bytes/s (10Kbps) threshold */ > disable: false > interval: 100 > bytes: 102400 > } > > } > > fib2mrib { > disable: false > } > } > > Thanks for the help, and I apologize in advance if this is too much =) > > stegen > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > From bms at incunabulum.net Thu Oct 9 16:43:34 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Fri, 10 Oct 2008 00:43:34 +0100 Subject: [Xorp-users] xorp clearing routing table upon startup In-Reply-To: <48EE93B7.8020607@owns.com> References: <48EE93B7.8020607@owns.com> Message-ID: <48EE9726.7000105@incunabulum.net> Stegen Smith wrote: > ... > So is there any chance that I would be able to get them to play nicely, or is it a pipe dream? I guess that'd be a push to get everything into xorp ;) > Folk have asked for this kind of interworking before, but without the necessary support in the underlying OS, it's not possible. There is no way to tell the origins of the routes apart in the BSDs, the "1" flag can't be shared as such. So you will have to move to XORP on the same box. thanks BMS From stegen at owns.com Thu Oct 9 16:45:37 2008 From: stegen at owns.com (Stegen Smith) Date: Thu, 09 Oct 2008 16:45:37 -0700 Subject: [Xorp-users] xorp clearing routing table upon startup In-Reply-To: <48EE9726.7000105@incunabulum.net> References: <48EE93B7.8020607@owns.com> <48EE9726.7000105@incunabulum.net> Message-ID: <48EE97A1.9080005@owns.com> Hi Bruce, Well there we go, then. Thank you for letting me know. I'll start my migrations now. =) thanks! stegen Bruce M Simpson wrote: > Stegen Smith wrote: >> ... >> So is there any chance that I would be able to get them to play >> nicely, or is it a pipe dream? I guess that'd be a push to get >> everything into xorp ;) >> > > Folk have asked for this kind of interworking before, but without the > necessary support in the underlying OS, it's not possible. > > There is no way to tell the origins of the routes apart in the BSDs, the > "1" flag can't be shared as such. > > So you will have to move to XORP on the same box. > > thanks > BMS > From pavlin at ICSI.Berkeley.EDU Thu Oct 9 20:19:34 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Thu, 09 Oct 2008 20:19:34 -0700 Subject: [Xorp-users] xorp clearing routing table upon startup In-Reply-To: <48EE9681.1060001@owns.com> References: <48EE93B7.8020607@owns.com> <48EE9681.1060001@owns.com> Message-ID: <200810100319.m9A3JYgc029228@fruitcake.ICSI.Berkeley.EDU> Stegen Smith wrote: > Also an interesting thing to note is that if a routing entry is added manually, I see the following happening: > > [ 2008/10/09 16:31:35 ERROR xorp_fea:15980 XRL +379 xrl_pf_stcp.cc die ] STCPRequestHandler died: life timer expired > [ 2008/10/09 16:31:35 ERROR xorp_fea:15980 XRL +379 xrl_pf_stcp.cc die ] STCPRequestHandler died: life timer expired This issue is probably independent from the routing table cleanup, hence please submit a Bugzilla entry. Thanks, Pavlin > And also, I forgot to give the following information... I'm using the latest xorp build from cvs, and this is openbsd 4.3. From stegen at owns.com Fri Oct 10 11:38:05 2008 From: stegen at owns.com (Stegen Smith) Date: Fri, 10 Oct 2008 11:38:05 -0700 Subject: [Xorp-users] xorp clearing routing table upon startup In-Reply-To: <200810100319.m9A3JYgc029228@fruitcake.ICSI.Berkeley.EDU> References: <48EE93B7.8020607@owns.com> <48EE9681.1060001@owns.com> <200810100319.m9A3JYgc029228@fruitcake.ICSI.Berkeley.EDU> Message-ID: <48EFA10D.6070502@owns.com> Hi Pavlin, Yeah, it seems to occur when things sit idly. Ultimately something gums up the works and I get those error messages, so it's not only when I modified the routing table myself. It should be easily recreated. Odd... So with that, I'll get one submitted right away with more detailed information. Another note... I've got bgp peering setup and I see the following: xorp at at-ig1.sv.atomz.com> show bgp routes Status Codes: * valid route, > best route Origin Codes: i IGP, e EGP, ? incomplete Prefix Nexthop Peer AS Path ------ ------- ---- ------- * 10.3.48.0/20 10.3.14.39 10.3.14.99 65000 i * 10.5.49.0/24 10.3.14.39 10.3.14.99 65000 i * 10.3.48.0/20 10.3.14.7 10.3.14.99 65000 i * 10.5.49.0/24 10.3.14.7 10.3.14.99 65000 i yet no routes are inserted on the system: root1paat-ig1.sv~ netstat -nr|grep 10.3.48 root1paat-ig1.sv~ I'm guessing that this is another bug, or perhaps related to the first issue I've noticed. I'll submit a bug for the first one, and if you would like me to do the same for this issue I'm seeing, let me know. =) And one more side note... what's the cleanest way to shutdown the routing software? I've been letting xorp_rtrmgr run in the foreground while I do testing, and ^C when I want to quit out. Probably not the best way to do it, as it ends up crashing (cores) and leaving other xorp processes up and running: ^C[ 2008/10/10 11:13:26 INFO xorp_rtrmgr:8398 RTRMGR +1024 task.cc shutdown ] Shutting down module: bgp [ 2008/10/10 11:13:26 INFO xorp_bgp:18890 BGP +451 peer.cc send_notification ] Sending: Notification Packet: Cease(6) [ 2008/10/10 11:13:26 TRACE xorp_bgp:18890 BGP +456 peer.cc send_notification ] Peer {10.3.14.40(179) 10.3.14.39(179)}: Send: Notification Packet: Cease(6) [ 2008/10/10 11:13:28 INFO xorp_rtrmgr:8398 XRL +432 xrl_router.cc get_sender ] Sender died (protocol = "stcp", address = "127.0.0.1:11810") [ 2008/10/10 11:13:28 ERROR xorp_rtrmgr:8398 LIBCOMM +610 comm_sock.c comm_sock_connect4 ] Error connecting socket (family = 2, remote_addr = 127.0.0.1, remote_port = 11810): Connection refused [ 2008/10/10 11:13:28 ERROR xorp_rtrmgr:8398 XRL +63 xrl_pf_factory.cc create_sender ] XrlPFSenderFactory::create failed: XrlPFConstructorError from line 668 of xrl_pf_stcp.cc: Could not connect to 127.0.0.1:11810 [ 2008/10/10 11:13:28 ERROR xorp_rtrmgr:8398 XRL +451 xrl_router.cc get_sender ] Could not create XrlPFSender for protocol = "stcp" address = "127.0.0.1:11810" [1] 8398 segmentation fault (core dumped) ./bin/xorp_rtrmgr root139p9at-ig1.sv/usr/local/xorp root139p9at-ig1.sv/usr/local/xorp ps auxww|grep xorp xorp 20544 0.0 0.1 3516 5484 p1 I+ 5:21PM 0:00.35 /usr/local/xorp/bin/xorpsh root 2811 0.0 0.2 5076 6476 p9 S 11:09AM 0:00.75 xorp_fea root 17533 0.0 0.1 2812 4452 p9 S 11:10AM 0:00.22 xorp_rib root 16731 0.0 0.1 2188 3872 p9 I 11:10AM 0:00.18 xorp_fib2mrib root 9111 0.0 0.1 2728 4268 p9 S 11:10AM 0:00.20 xorp_igmp root 32406 0.0 0.1 4752 6028 p9 S 11:10AM 0:00.50 xorp_pimsm4 root 4331 0.0 0.0 848 692 p9 R+/1 11:16AM 0:00.00 grep xorp (zsh) root0p9at-ig1.sv/usr/local/xorp I'm just working hard at keeping you guys busy ;) thanks, stegen Pavlin Radoslavov wrote: > Stegen Smith wrote: > >> Also an interesting thing to note is that if a routing entry is added manually, I see the following happening: >> >> [ 2008/10/09 16:31:35 ERROR xorp_fea:15980 XRL +379 xrl_pf_stcp.cc die ] STCPRequestHandler died: life timer expired >> [ 2008/10/09 16:31:35 ERROR xorp_fea:15980 XRL +379 xrl_pf_stcp.cc die ] STCPRequestHandler died: life timer expired > > This issue is probably independent from the routing table cleanup, > hence please submit a Bugzilla entry. > > Thanks, > Pavlin > >> And also, I forgot to give the following information... I'm using the latest xorp build from cvs, and this is openbsd 4.3. > From pavlin at ICSI.Berkeley.EDU Fri Oct 10 14:20:52 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Fri, 10 Oct 2008 14:20:52 -0700 Subject: [Xorp-users] xorp clearing routing table upon startup In-Reply-To: <48EFA10D.6070502@owns.com> References: <48EE93B7.8020607@owns.com> <48EE9681.1060001@owns.com> <200810100319.m9A3JYgc029228@fruitcake.ICSI.Berkeley.EDU> <48EFA10D.6070502@owns.com> Message-ID: <200810102121.m9ALKq9F006307@fruitcake.ICSI.Berkeley.EDU> Stegen Smith wrote: > Hi Pavlin, > > Yeah, it seems to occur when things sit idly. Ultimately something gums up the works and I get > those error messages, so it's not only when I modified the routing table myself. It should be > easily recreated. Odd... So with that, I'll get one submitted right away with more detailed > information. I just saw the entry in Bugzilla. Thanks! The missing routes might be related to the XRL errors. The "life timer expired" indicates that the XRL communication has timed-out, and after that all bets are off. BTW, this particular timeout shouldn't happen under (very relaxed) normal circumstances, so there is something else happening. This probably also explains the shutdown problem with the leftover XORP processes. Re. the shutdown question: yes, if you are running XORP in foreground, Ctrl-C should be the way to stop it. I (or somebody else) should look at this problem very soon, because it looks critical. Pavlin > Another note... I've got bgp peering setup and I see the following: > xorp at at-ig1.sv.atomz.com> show bgp routes > Status Codes: * valid route, > best route > Origin Codes: i IGP, e EGP, ? incomplete > > Prefix Nexthop Peer AS Path > ------ ------- ---- ------- > * 10.3.48.0/20 10.3.14.39 10.3.14.99 65000 i > * 10.5.49.0/24 10.3.14.39 10.3.14.99 65000 i > * 10.3.48.0/20 10.3.14.7 10.3.14.99 65000 i > * 10.5.49.0/24 10.3.14.7 10.3.14.99 65000 i > > yet no routes are inserted on the system: > root1paat-ig1.sv~ netstat -nr|grep 10.3.48 > root1paat-ig1.sv~ > > I'm guessing that this is another bug, or perhaps related to the first issue I've noticed. I'll > submit a bug for the first one, and if you would like me to do the same for this issue I'm seeing, > let me know. =) > > And one more side note... what's the cleanest way to shutdown the routing software? I've been > letting xorp_rtrmgr run in the foreground while I do testing, and ^C when I want to quit out. > Probably not the best way to do it, as it ends up crashing (cores) and leaving other xorp processes > up and running: > > ^C[ 2008/10/10 11:13:26 INFO xorp_rtrmgr:8398 RTRMGR +1024 task.cc shutdown ] Shutting down module: bgp > [ 2008/10/10 11:13:26 INFO xorp_bgp:18890 BGP +451 peer.cc send_notification ] Sending: > Notification Packet: Cease(6) > [ 2008/10/10 11:13:26 TRACE xorp_bgp:18890 BGP +456 peer.cc send_notification ] Peer > {10.3.14.40(179) 10.3.14.39(179)}: Send: Notification Packet: Cease(6) > > > > [ 2008/10/10 11:13:28 INFO xorp_rtrmgr:8398 XRL +432 xrl_router.cc get_sender ] Sender died > (protocol = "stcp", address = "127.0.0.1:11810") > [ 2008/10/10 11:13:28 ERROR xorp_rtrmgr:8398 LIBCOMM +610 comm_sock.c comm_sock_connect4 ] Error > connecting socket (family = 2, remote_addr = 127.0.0.1, remote_port = 11810): Connection refused > [ 2008/10/10 11:13:28 ERROR xorp_rtrmgr:8398 XRL +63 xrl_pf_factory.cc create_sender ] > XrlPFSenderFactory::create failed: XrlPFConstructorError from line 668 of xrl_pf_stcp.cc: Could not > connect to 127.0.0.1:11810 > > [ 2008/10/10 11:13:28 ERROR xorp_rtrmgr:8398 XRL +451 xrl_router.cc get_sender ] Could not create > XrlPFSender for protocol = "stcp" address = "127.0.0.1:11810" > [1] 8398 segmentation fault (core dumped) ./bin/xorp_rtrmgr > root139p9at-ig1.sv/usr/local/xorp > root139p9at-ig1.sv/usr/local/xorp ps auxww|grep xorp > xorp 20544 0.0 0.1 3516 5484 p1 I+ 5:21PM 0:00.35 /usr/local/xorp/bin/xorpsh > root 2811 0.0 0.2 5076 6476 p9 S 11:09AM 0:00.75 xorp_fea > root 17533 0.0 0.1 2812 4452 p9 S 11:10AM 0:00.22 xorp_rib > root 16731 0.0 0.1 2188 3872 p9 I 11:10AM 0:00.18 xorp_fib2mrib > root 9111 0.0 0.1 2728 4268 p9 S 11:10AM 0:00.20 xorp_igmp > root 32406 0.0 0.1 4752 6028 p9 S 11:10AM 0:00.50 xorp_pimsm4 > root 4331 0.0 0.0 848 692 p9 R+/1 11:16AM 0:00.00 grep xorp (zsh) > root0p9at-ig1.sv/usr/local/xorp > > I'm just working hard at keeping you guys busy ;) > > thanks, > stegen > > Pavlin Radoslavov wrote: > > Stegen Smith wrote: > > > >> Also an interesting thing to note is that if a routing entry is added manually, I see the following happening: > >> > >> [ 2008/10/09 16:31:35 ERROR xorp_fea:15980 XRL +379 xrl_pf_stcp.cc die ] STCPRequestHandler died: life timer expired > >> [ 2008/10/09 16:31:35 ERROR xorp_fea:15980 XRL +379 xrl_pf_stcp.cc die ] STCPRequestHandler died: life timer expired > > > > This issue is probably independent from the routing table cleanup, > > hence please submit a Bugzilla entry. > > > > Thanks, > > Pavlin > > > >> And also, I forgot to give the following information... I'm using the latest xorp build from cvs, and this is openbsd 4.3. > > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From z_campt001 at yahoo.com Sat Oct 11 04:16:12 2008 From: z_campt001 at yahoo.com (zeinab farhoudi) Date: Sat, 11 Oct 2008 04:16:12 -0700 (PDT) Subject: [Xorp-users] xorp installation Message-ID: <868508.51546.qm@web50111.mail.re2.yahoo.com> hello I have installed xorp-1.5.tar.gz from www.xorp.org and i compiled it in fedora core 8. but when i run "gmake check" i receive this error: ./test_fea_rawlink.sh: Tests Failed SIGTERM received. Exiting. ./test_fea_rawlink.sh: Tests Failed ./test_fea_rawlink.sh: Tests Failed FAIL: test_fea_rawlink.sh Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20081011/f81278f8/attachment.html From bms at incunabulum.net Sat Oct 11 04:27:31 2008 From: bms at incunabulum.net (Bruce M. Simpson) Date: Sat, 11 Oct 2008 12:27:31 +0100 Subject: [Xorp-users] xorp installation In-Reply-To: <868508.51546.qm@web50111.mail.re2.yahoo.com> References: <868508.51546.qm@web50111.mail.re2.yahoo.com> Message-ID: <48F08DA3.2020409@incunabulum.net> Generally it's OK to ignore this regression test error if you are not running tests as the root user, as super-user privileges are usually required to use the pcap library, which raw link access depends on. thanks BMS zeinab farhoudi wrote: > hello > I have installed xorp-1.5.tar.gz from www.xorp.org and i compiled it > in fedora core 8. but when i run "gmake check" i receive this error: > > ./test_fea_rawlink.sh: Tests Failed > SIGTERM received. Exiting. > ./test_fea_rawlink.sh: Tests Failed > ./test_fea_rawlink.sh: Tests Failed > FAIL: test_fea_rawlink.sh > > Thanks in advance > > > ------------------------------------------------------------------------ > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > From pavlin at ICSI.Berkeley.EDU Sun Oct 12 20:05:11 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Sun, 12 Oct 2008 20:05:11 -0700 Subject: [Xorp-users] xorp clearing routing table upon startup In-Reply-To: <200810102121.m9ALKq9F006307@fruitcake.ICSI.Berkeley.EDU> References: <48EE93B7.8020607@owns.com> <48EE9681.1060001@owns.com> <200810100319.m9A3JYgc029228@fruitcake.ICSI.Berkeley.EDU> <48EFA10D.6070502@owns.com> <200810102121.m9ALKq9F006307@fruitcake.ICSI.Berkeley.EDU> Message-ID: <200810130305.m9D35B2f017031@fruitcake.ICSI.Berkeley.EDU> Pavlin Radoslavov wrote: > Stegen Smith wrote: > > > Hi Pavlin, > > > > Yeah, it seems to occur when things sit idly. Ultimately something gums up the works and I get > > those error messages, so it's not only when I modified the routing table myself. It should be > > easily recreated. Odd... So with that, I'll get one submitted right away with more detailed > > information. > > I just saw the entry in Bugzilla. Thanks! > > The missing routes might be related to the XRL errors. > The "life timer expired" indicates that the XRL communication has > timed-out, and after that all bets are off. > BTW, this particular timeout shouldn't happen under (very relaxed) > normal circumstances, so there is something else happening. > This probably also explains the shutdown problem with the leftover > XORP processes. > > Re. the shutdown question: yes, if you are running XORP in > foreground, Ctrl-C should be the way to stop it. > > I (or somebody else) should look at this problem very soon, because > it looks critical. The problem is fixed in CVS: Revision Changes Path 1.25 +9 -8; commitid: 7b5a48f2abbc41a7; xorp/libxipc/test_stcp.cc 1.72 +18 -20; commitid: 7b5a48f2abbc41a7; xorp/libxipc/xrl_pf_stcp.cc 1.36 +4 -4; commitid: 7b5a48f2abbc41a7; xorp/libxipc/xrl_pf_stcp.hh Please checkout the latest code from CVS and verify whether it fixes the problems on your side. Pavlin > Pavlin > > > Another note... I've got bgp peering setup and I see the following: > > xorp at at-ig1.sv.atomz.com> show bgp routes > > Status Codes: * valid route, > best route > > Origin Codes: i IGP, e EGP, ? incomplete > > > > Prefix Nexthop Peer AS Path > > ------ ------- ---- ------- > > * 10.3.48.0/20 10.3.14.39 10.3.14.99 65000 i > > * 10.5.49.0/24 10.3.14.39 10.3.14.99 65000 i > > * 10.3.48.0/20 10.3.14.7 10.3.14.99 65000 i > > * 10.5.49.0/24 10.3.14.7 10.3.14.99 65000 i > > > > yet no routes are inserted on the system: > > root1paat-ig1.sv~ netstat -nr|grep 10.3.48 > > root1paat-ig1.sv~ > > > > I'm guessing that this is another bug, or perhaps related to the first issue I've noticed. I'll > > submit a bug for the first one, and if you would like me to do the same for this issue I'm seeing, > > let me know. =) > > > > And one more side note... what's the cleanest way to shutdown the routing software? I've been > > letting xorp_rtrmgr run in the foreground while I do testing, and ^C when I want to quit out. > > Probably not the best way to do it, as it ends up crashing (cores) and leaving other xorp processes > > up and running: > > > > ^C[ 2008/10/10 11:13:26 INFO xorp_rtrmgr:8398 RTRMGR +1024 task.cc shutdown ] Shutting down module: bgp > > [ 2008/10/10 11:13:26 INFO xorp_bgp:18890 BGP +451 peer.cc send_notification ] Sending: > > Notification Packet: Cease(6) > > [ 2008/10/10 11:13:26 TRACE xorp_bgp:18890 BGP +456 peer.cc send_notification ] Peer > > {10.3.14.40(179) 10.3.14.39(179)}: Send: Notification Packet: Cease(6) > > > > > > > > [ 2008/10/10 11:13:28 INFO xorp_rtrmgr:8398 XRL +432 xrl_router.cc get_sender ] Sender died > > (protocol = "stcp", address = "127.0.0.1:11810") > > [ 2008/10/10 11:13:28 ERROR xorp_rtrmgr:8398 LIBCOMM +610 comm_sock.c comm_sock_connect4 ] Error > > connecting socket (family = 2, remote_addr = 127.0.0.1, remote_port = 11810): Connection refused > > [ 2008/10/10 11:13:28 ERROR xorp_rtrmgr:8398 XRL +63 xrl_pf_factory.cc create_sender ] > > XrlPFSenderFactory::create failed: XrlPFConstructorError from line 668 of xrl_pf_stcp.cc: Could not > > connect to 127.0.0.1:11810 > > > > [ 2008/10/10 11:13:28 ERROR xorp_rtrmgr:8398 XRL +451 xrl_router.cc get_sender ] Could not create > > XrlPFSender for protocol = "stcp" address = "127.0.0.1:11810" > > [1] 8398 segmentation fault (core dumped) ./bin/xorp_rtrmgr > > root139p9at-ig1.sv/usr/local/xorp > > root139p9at-ig1.sv/usr/local/xorp ps auxww|grep xorp > > xorp 20544 0.0 0.1 3516 5484 p1 I+ 5:21PM 0:00.35 /usr/local/xorp/bin/xorpsh > > root 2811 0.0 0.2 5076 6476 p9 S 11:09AM 0:00.75 xorp_fea > > root 17533 0.0 0.1 2812 4452 p9 S 11:10AM 0:00.22 xorp_rib > > root 16731 0.0 0.1 2188 3872 p9 I 11:10AM 0:00.18 xorp_fib2mrib > > root 9111 0.0 0.1 2728 4268 p9 S 11:10AM 0:00.20 xorp_igmp > > root 32406 0.0 0.1 4752 6028 p9 S 11:10AM 0:00.50 xorp_pimsm4 > > root 4331 0.0 0.0 848 692 p9 R+/1 11:16AM 0:00.00 grep xorp (zsh) > > root0p9at-ig1.sv/usr/local/xorp > > > > I'm just working hard at keeping you guys busy ;) > > > > thanks, > > stegen > > > > Pavlin Radoslavov wrote: > > > Stegen Smith wrote: > > > > > >> Also an interesting thing to note is that if a routing entry is added manually, I see the following happening: > > >> > > >> [ 2008/10/09 16:31:35 ERROR xorp_fea:15980 XRL +379 xrl_pf_stcp.cc die ] STCPRequestHandler died: life timer expired > > >> [ 2008/10/09 16:31:35 ERROR xorp_fea:15980 XRL +379 xrl_pf_stcp.cc die ] STCPRequestHandler died: life timer expired > > > > > > This issue is probably independent from the routing table cleanup, > > > hence please submit a Bugzilla entry. > > > > > > Thanks, > > > Pavlin > > > > > >> And also, I forgot to give the following information... I'm using the latest xorp build from cvs, and this is openbsd 4.3. > > > > > > > _______________________________________________ > > Xorp-users mailing list > > Xorp-users at xorp.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From jjajal at gmail.com Mon Oct 13 06:31:00 2008 From: jjajal at gmail.com (Jigar) Date: Mon, 13 Oct 2008 19:01:00 +0530 Subject: [Xorp-users] IGMP and PIM-SSM problem Message-ID: <48F34D94.2070201@gmail.com> Hi All, I have two PCs with Red Hat Linux installed in them. Both have two NICs. XORP-1.4 is running in PC-A with IGMPv3 and PIM-SM enabled. PC-A and PC-B are connected to each other through both interfaces. PC-A eth0: 10.100.3.107/24 PC-A eth1: 192.168.14.212/24 PC-B eth1: 10.100.3.220/24 PC-B eth0: 192.168.14.211/24 PC-A eth0 and PC-B eth1 are directly connected to each other. Similarly, PC-A eth1 and PC-B eth0 are directly connected to each other. Here, 192.168.14.211 is configured as static RP in PC-A. I am sending IGMP join report for 232.11.22.33 group and 192.168.14.14 source with INCLUDE mode from 10.100.3.220. I have sent PIM hello message from 192.168.14.211. As IGMPv3 and PIM-SM are runing on PC-A, it should convert that report into PIM JOIN(S,G) message and send it towards RP(192.168.14.211). But no message was sent by PC-A on its eth1. Tell me where I went wrong? I have copied my configuration file and condition of PC-A when I sent the IGMP report. * XORP Configuration file (On PC-A):* interfaces { restore-original-config-on-shutdown: false interface eth0 { description: "data interface" disable: false default-system-config } interface eth1 { description: "data interface" disable: false default-system-config } } fea { unicast-forwarding4 { disable: false forwarding-entries { retain-on-startup: false retain-on-shutdown: false } } } policy { /* Describe connected routes for redistribution */ policy-statement connected { term export { from { protocol: "connected" } } } } policy { /* Describe static routes for redistribution */ policy-statement static { term export { from { protocol: "static" } } } } plumbing { mfea4 { disable: false interface eth0 { vif eth0 { disable: false } } interface eth1 { vif eth1 { 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 eth0 { vif eth0 { disable: false version: 3 } } interface eth1 { vif eth1 { disable: false version: 3 } } traceoptions { flag all { disable: false } } } } protocols { pimsm4 { disable: false interface eth0 { vif eth0 { disable: false } } interface eth1 { vif eth1 { disable: false } } interface register_vif { vif register_vif { /* Note: this vif should be always enabled */ disable: false } } traceoptions { flag all { disable: false } } } } /* * Note: fib2mrib is needed for multicast only if the unicast protocols * don't populate the MRIB with multicast-specific routes. */ protocols { fib2mrib { disable: false } } *I have made 192.168.14.211 as static RP from configuration mode of xorpsh. Here is the command: set protocols pimsm4 static-rps rp 192.168.14.211 group-prefix 224.0.0.0/4* *then commit.* *XORPSH Console when I sent IGMP report:* root at localhost.localdomain> show pim join all Group Source RP Flags 224.0.0.0 192.168.14.211 192.168.14.211 RP Upstream interface (RP): eth1 Upstream MRIB next hop (RP): 192.168.14.211 Upstream state: NotJoined Join timer: -1 Joins RP: ... Join state: ... Prune state: ... Prune pending state: ... Could assert WC: ... I am DR: OOO Immediate olist RP: ... Inherited olist SG: ... Inherited olist SG_RPT: ... 232.11.22.33 192.168.14.14 192.168.14.211 SG DirectlyConnectedS Upstream interface (S): eth1 Upstream interface (RP): eth1 Upstream MRIB next hop (RP): 192.168.14.211 Upstream MRIB next hop (S): UNKNOWN *Upstream RPF'(S,G): UNKNOWN (I have doubt in this. How can I configure RPF'(S,G)?)* Upstream state: Joined Register state: RegisterNoinfo RegisterNotCouldRegister Join timer: 1 KAT(S,G) running: false Local receiver include WC: ... Local receiver include SG: O.. Local receiver exclude SG: ... Joins RP: ... Joins WC: ... Joins SG: ... Join state: ... 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: OO. Could assert WC: ... Could assert SG: ... I am DR: OOO Immediate olist RP: ... Immediate olist WC: ... Immediate olist SG: O.. Inherited olist SG: O.. Inherited olist SG_RPT: ... PIM include WC: ... PIM include SG: O.. PIM exclude SG: ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20081013/e91bb9c7/attachment-0001.html From pavlin at ICSI.Berkeley.EDU Mon Oct 13 10:53:51 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Mon, 13 Oct 2008 10:53:51 -0700 Subject: [Xorp-users] IGMP and PIM-SSM problem In-Reply-To: <48F34D94.2070201@gmail.com> References: <48F34D94.2070201@gmail.com> Message-ID: <200810131753.m9DHrppg004342@fruitcake.ICSI.Berkeley.EDU> Jigar wrote: > Hi All, > I have two PCs with Red Hat Linux installed in them. Both have two > NICs. XORP-1.4 is running in PC-A with IGMPv3 and PIM-SM enabled. PC-A and > PC-B are connected to each other through both interfaces. > > PC-A eth0: 10.100.3.107/24 > PC-A eth1: 192.168.14.212/24 > PC-B eth1: 10.100.3.220/24 > PC-B eth0: 192.168.14.211/24 > > PC-A eth0 and PC-B eth1 are directly connected to each other. Similarly, PC-A > eth1 and PC-B eth0 are directly connected to each other. > > Here, 192.168.14.211 is configured as static RP in PC-A. I am sending IGMP > join report for 232.11.22.33 group and 192.168.14.14 source with INCLUDE mode > from 10.100.3.220. I have sent PIM hello message from 192.168.14.211. As > IGMPv3 and PIM-SM are runing on PC-A, it should convert that report into PIM > JOIN(S,G) message and send it towards RP(192.168.14.211). But no message was > sent by PC-A on its eth1. Tell me where I went wrong? The sender 192.168.14.14 is directly connected to both PC-A and PC-B. Hence, the PIM-SM router connected to it will NOT send PIM-SM Join message toward it. PIM-SM Join messages are only sent to PIM-SM routers toward the sender (or the RP), and only if the sender (or the RP) is not directly connected. Pavlin 232.11.22.33 192.168.14.14 192.168.14.211 SG DirectlyConnectedS Upstream interface (S): eth1 Upstream interface (RP): eth1 Upstream MRIB next hop (RP): 192.168.14.211 Upstream MRIB next hop (S): UNKNOWN *Upstream RPF'(S,G): UNKNOWN (I have doubt in this. How can I configure RPF'(S,G)?)* Upstream state: Joined > > I have copied my configuration file and condition of PC-A when I sent the > IGMP report. > * > XORP Configuration file (On PC-A):* > > interfaces { > restore-original-config-on-shutdown: false > interface eth0 { > description: "data interface" > disable: false > default-system-config > } > interface eth1 { > description: "data interface" > disable: false > default-system-config > } > } > > fea { > unicast-forwarding4 { > disable: false > forwarding-entries { > retain-on-startup: false > retain-on-shutdown: false > } > } > } > > policy { > /* Describe connected routes for redistribution */ > policy-statement connected { > term export { > from { > protocol: "connected" > } > } > } > } > > policy { > /* Describe static routes for redistribution */ > policy-statement static { > term export { > from { > protocol: "static" > } > } > } > } > > plumbing { > mfea4 { > disable: false > interface eth0 { > vif eth0 { > disable: false > } > } > interface eth1 { > vif eth1 { > 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 eth0 { > vif eth0 { > disable: false > version: 3 > } > } > interface eth1 { > vif eth1 { > disable: false > version: 3 > } > } > traceoptions { > flag all { > disable: false > } > } > } > } > > protocols { > pimsm4 { > disable: false > interface eth0 { > vif eth0 { > disable: false > } > } > interface eth1 { > vif eth1 { > disable: false > } > } > interface register_vif { > vif register_vif { > /* Note: this vif should be always enabled */ > disable: false > } > } > > traceoptions { > flag all { > disable: false > } > } > > } > } > > /* > * Note: fib2mrib is needed for multicast only if the unicast protocols > * don't populate the MRIB with multicast-specific routes. > */ > protocols { > fib2mrib { > disable: false > } > } > > *I have made 192.168.14.211 as static RP from configuration mode of xorpsh. > Here is the command: set protocols pimsm4 static-rps rp 192.168.14.211 > group-prefix 224.0.0.0/4* > *then commit.* > > *XORPSH Console when I sent IGMP report:* > root at localhost.localdomain> show pim join all > Group Source RP Flags > 224.0.0.0 192.168.14.211 192.168.14.211 RP > Upstream interface (RP): eth1 > Upstream MRIB next hop (RP): 192.168.14.211 > Upstream state: NotJoined > Join timer: -1 > Joins RP: ... > Join state: ... > Prune state: ... > Prune pending state: ... > Could assert WC: ... > I am DR: OOO > Immediate olist RP: ... > Inherited olist SG: ... > Inherited olist SG_RPT: ... > 232.11.22.33 192.168.14.14 192.168.14.211 SG DirectlyConnectedS > Upstream interface (S): eth1 > Upstream interface (RP): eth1 > Upstream MRIB next hop (RP): 192.168.14.211 > Upstream MRIB next hop (S): UNKNOWN > *Upstream RPF'(S,G): UNKNOWN (I have doubt in > this. How can I configure RPF'(S,G)?)* > Upstream state: Joined > Register state: RegisterNoinfo RegisterNotCouldRegister > Join timer: 1 > KAT(S,G) running: false > Local receiver include WC: ... > Local receiver include SG: O.. > Local receiver exclude SG: ... > Joins RP: ... > Joins WC: ... > Joins SG: ... > Join state: ... > 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: OO. > Could assert WC: ... > Could assert SG: ... > I am DR: OOO > Immediate olist RP: ... > Immediate olist WC: ... > Immediate olist SG: O.. > Inherited olist SG: O.. > Inherited olist SG_RPT: ... > PIM include WC: ... > PIM include SG: O.. > PIM exclude SG: ... > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From stegen at owns.com Mon Oct 13 12:12:34 2008 From: stegen at owns.com (Stegen Smith) Date: Mon, 13 Oct 2008 12:12:34 -0700 Subject: [Xorp-users] xorp clearing routing table upon startup In-Reply-To: <200810130305.m9D35B2f017031@fruitcake.ICSI.Berkeley.EDU> References: <48EE93B7.8020607@owns.com> <48EE9681.1060001@owns.com> <200810100319.m9A3JYgc029228@fruitcake.ICSI.Berkeley.EDU> <48EFA10D.6070502@owns.com> <200810102121.m9ALKq9F006307@fruitcake.ICSI.Berkeley.EDU> <200810130305.m9D35B2f017031@fruitcake.ICSI.Berkeley.EDU> Message-ID: <48F39DA2.6080109@owns.com> Hi Pavlin, Thanks for the update! I've grabbed the latest source from CVS and got it up. I'm no longer seeing those errors that I submitted the bug for; however, it does not seem that the latter issue of the routing table not being updated from bgp is resolved. I can do the following: xorp at at-ig1.sv> show bgp routes Status Codes: * valid route, > best route Origin Codes: i IGP, e EGP, ? incomplete Prefix Nexthop Peer AS Path ------ ------- ---- ------- * 10.3.48.0/20 10.3.14.7 10.3.14.99 65000 i * 10.3.48.0/20 10.3.14.39 10.3.14.99 65000 i * 10.5.49.0/24 10.3.14.39 10.3.14.99 65000 i * 10.5.49.0/24 10.3.14.7 10.3.14.99 65000 i xorp at at-ig1.sv> root0p7at-ig1.sv/usr/local/xorp netstat -nr|egrep "^10.[3,5].48" root1p7at-ig1.sv/usr/local/xorp Also, when I ^C out of xorp_rtrmgr, it still does not shut down so cleanly: ^C[ 2008/10/13 12:22:31 INFO xorp_rtrmgr:351 RTRMGR +1024 task.cc shutdown ] Shutting down module: bgp [ 2008/10/13 12:22:31 INFO xorp_bgp:15136 BGP +451 peer.cc send_notification ] Sending: Notification Packet: Cease(6) [ 2008/10/13 12:22:31 TRACE xorp_bgp:15136 BGP +456 peer.cc send_notification ] Peer {10.3.14.40(179) 10.3.14.39(179)}: Send: Notification Packet: Cease(6) [ 2008/10/13 12:22:31 TRACE xorp_bgp:15136 BGP +2062 peer.cc set_state ] Peer {10.3.14.40(179) 10.3.14.39(179)}: Previous state: ESTABLISHED(6) Current state: STOPPED(7) [ 2008/10/13 12:22:31 INFO xorp_bgp:15136 BGP +451 peer.cc send_notification ] Sending: Notification Packet: Cease(6) [ 2008/10/13 12:22:31 TRACE xorp_bgp:15136 BGP +456 peer.cc send_notification ] Peer {10.3.14.8(179) 10.3.14.7(179)}: Send: Notification Packet: Cease(6) [ 2008/10/13 12:22:31 TRACE xorp_bgp:15136 BGP +2062 peer.cc set_state ] Peer {10.3.14.8(179) 10.3.14.7(179)}: Previous state: ESTABLISHED(6) Current state: STOPPED(7) [ 2008/10/13 12:22:31 TRACE xorp_bgp:15136 BGP +2062 peer.cc set_state ] Peer {10.3.14.8(179) 10.3.14.7(179)}: Previous state: STOPPED(7) Current state: IDLE(1) [ 2008/10/13 12:22:31 TRACE xorp_bgp:15136 BGP +2062 peer.cc set_state ] Peer {10.3.14.40(179) 10.3.14.39(179)}: Previous state: STOPPED(7) Current state: IDLE(1) [ 2008/10/13 12:22:31 INFO xorp_bgp:15136 BGP +149 bgp.cc BGPMain ] EVENT: timers 4 [ 2008/10/13 12:22:31 INFO xorp_bgp:15136 BGP +161 bgp.cc BGPMain ] xrl router still has pending operations [ 2008/10/13 12:22:31 INFO xorp_bgp:15136 BGP +167 bgp.cc BGPMain ] xrl router no more pending operations [ 2008/10/13 12:22:31 ERROR xorp_rib:30518 LIBXORP +222 buffered_asyncio.cc io_event ] read error 54 [ 2008/10/13 12:22:31 ERROR xorp_rib:30518 XRL +169 xrl_pf_stcp.cc read_event ] Read failed (error = 54) [ 2008/10/13 12:22:31 ERROR xorp_rib:30518 XRL +378 xrl_pf_stcp.cc die ] STCPRequestHandler died: read error [ 2008/10/13 12:22:31 INFO xorp_rtrmgr:351 RTRMGR +280 module_manager.cc module_exited ] Module normal exit: bgp [ 2008/10/13 12:22:31 INFO xorp_rib RIB ] Received death event for protocol bgp shutting down ------- OriginTable: ebgp EGP next table = Merged:(ebgp)+(ibgp) [ 2008/10/13 12:22:31 INFO xorp_rib RIB ] Received death event for protocol bgp shutting down ------- OriginTable: ebgp EGP next table = Merged:(ebgp)+(ibgp) [ 2008/10/13 12:22:32 WARNING xorp_rtrmgr:351 XrlFinderTarget +407 ../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 "bgp" does not exist or is not enabled. [ 2008/10/13 12:22:33 INFO xorp_rtrmgr:351 RTRMGR +1024 task.cc shutdown ] Shutting down module: policy [ 2008/10/13 12:22:33 INFO xorp_rtrmgr:351 XRL +432 xrl_router.cc get_sender ] Sender died (protocol = "stcp", address = "127.0.0.1:11045") [ 2008/10/13 12:22:33 ERROR xorp_rtrmgr:351 LIBCOMM +610 comm_sock.c comm_sock_connect4 ] Error connecting socket (family = 2, remote_addr = 127.0.0.1, remote_port = 11045): Connection refused [ 2008/10/13 12:22:33 ERROR xorp_rtrmgr:351 XRL +63 xrl_pf_factory.cc create_sender ] XrlPFSenderFactory::create failed: XrlPFConstructorError from line 667 of xrl_pf_stcp.cc: Could not connect to 127.0.0.1:11045 [ 2008/10/13 12:22:33 ERROR xorp_rtrmgr:351 XRL +451 xrl_router.cc get_sender ] Could not create XrlPFSender for protocol = "stcp" address = "127.0.0.1:11045" [1] 351 segmentation fault (core dumped) ./bin/xorp_rtrmgr Let me know what you would like me to do next =) thanks! stegen Pavlin Radoslavov wrote: > Pavlin Radoslavov wrote: > >> Stegen Smith wrote: >> >>> Hi Pavlin, >>> >>> Yeah, it seems to occur when things sit idly. Ultimately something gums up the works and I get >>> those error messages, so it's not only when I modified the routing table myself. It should be >>> easily recreated. Odd... So with that, I'll get one submitted right away with more detailed >>> information. >> I just saw the entry in Bugzilla. Thanks! >> >> The missing routes might be related to the XRL errors. >> The "life timer expired" indicates that the XRL communication has >> timed-out, and after that all bets are off. >> BTW, this particular timeout shouldn't happen under (very relaxed) >> normal circumstances, so there is something else happening. >> This probably also explains the shutdown problem with the leftover >> XORP processes. >> >> Re. the shutdown question: yes, if you are running XORP in >> foreground, Ctrl-C should be the way to stop it. >> >> I (or somebody else) should look at this problem very soon, because >> it looks critical. > > The problem is fixed in CVS: > > Revision Changes Path > 1.25 +9 -8; commitid: 7b5a48f2abbc41a7; xorp/libxipc/test_stcp.cc > 1.72 +18 -20; commitid: 7b5a48f2abbc41a7; xorp/libxipc/xrl_pf_stcp.cc > 1.36 +4 -4; commitid: 7b5a48f2abbc41a7; xorp/libxipc/xrl_pf_stcp.hh > > Please checkout the latest code from CVS and verify whether it fixes > the problems on your side. > > Pavlin > >> Pavlin >> >>> Another note... I've got bgp peering setup and I see the following: >>> xorp at at-ig1.sv.atomz.com> show bgp routes >>> Status Codes: * valid route, > best route >>> Origin Codes: i IGP, e EGP, ? incomplete >>> >>> Prefix Nexthop Peer AS Path >>> ------ ------- ---- ------- >>> * 10.3.48.0/20 10.3.14.39 10.3.14.99 65000 i >>> * 10.5.49.0/24 10.3.14.39 10.3.14.99 65000 i >>> * 10.3.48.0/20 10.3.14.7 10.3.14.99 65000 i >>> * 10.5.49.0/24 10.3.14.7 10.3.14.99 65000 i >>> >>> yet no routes are inserted on the system: >>> root1paat-ig1.sv~ netstat -nr|grep 10.3.48 >>> root1paat-ig1.sv~ >>> >>> I'm guessing that this is another bug, or perhaps related to the first issue I've noticed. I'll >>> submit a bug for the first one, and if you would like me to do the same for this issue I'm seeing, >>> let me know. =) >>> >>> And one more side note... what's the cleanest way to shutdown the routing software? I've been >>> letting xorp_rtrmgr run in the foreground while I do testing, and ^C when I want to quit out. >>> Probably not the best way to do it, as it ends up crashing (cores) and leaving other xorp processes >>> up and running: >>> >>> ^C[ 2008/10/10 11:13:26 INFO xorp_rtrmgr:8398 RTRMGR +1024 task.cc shutdown ] Shutting down module: bgp >>> [ 2008/10/10 11:13:26 INFO xorp_bgp:18890 BGP +451 peer.cc send_notification ] Sending: >>> Notification Packet: Cease(6) >>> [ 2008/10/10 11:13:26 TRACE xorp_bgp:18890 BGP +456 peer.cc send_notification ] Peer >>> {10.3.14.40(179) 10.3.14.39(179)}: Send: Notification Packet: Cease(6) >>> >>> >>> >>> [ 2008/10/10 11:13:28 INFO xorp_rtrmgr:8398 XRL +432 xrl_router.cc get_sender ] Sender died >>> (protocol = "stcp", address = "127.0.0.1:11810") >>> [ 2008/10/10 11:13:28 ERROR xorp_rtrmgr:8398 LIBCOMM +610 comm_sock.c comm_sock_connect4 ] Error >>> connecting socket (family = 2, remote_addr = 127.0.0.1, remote_port = 11810): Connection refused >>> [ 2008/10/10 11:13:28 ERROR xorp_rtrmgr:8398 XRL +63 xrl_pf_factory.cc create_sender ] >>> XrlPFSenderFactory::create failed: XrlPFConstructorError from line 668 of xrl_pf_stcp.cc: Could not >>> connect to 127.0.0.1:11810 >>> >>> [ 2008/10/10 11:13:28 ERROR xorp_rtrmgr:8398 XRL +451 xrl_router.cc get_sender ] Could not create >>> XrlPFSender for protocol = "stcp" address = "127.0.0.1:11810" >>> [1] 8398 segmentation fault (core dumped) ./bin/xorp_rtrmgr >>> root139p9at-ig1.sv/usr/local/xorp >>> root139p9at-ig1.sv/usr/local/xorp ps auxww|grep xorp >>> xorp 20544 0.0 0.1 3516 5484 p1 I+ 5:21PM 0:00.35 /usr/local/xorp/bin/xorpsh >>> root 2811 0.0 0.2 5076 6476 p9 S 11:09AM 0:00.75 xorp_fea >>> root 17533 0.0 0.1 2812 4452 p9 S 11:10AM 0:00.22 xorp_rib >>> root 16731 0.0 0.1 2188 3872 p9 I 11:10AM 0:00.18 xorp_fib2mrib >>> root 9111 0.0 0.1 2728 4268 p9 S 11:10AM 0:00.20 xorp_igmp >>> root 32406 0.0 0.1 4752 6028 p9 S 11:10AM 0:00.50 xorp_pimsm4 >>> root 4331 0.0 0.0 848 692 p9 R+/1 11:16AM 0:00.00 grep xorp (zsh) >>> root0p9at-ig1.sv/usr/local/xorp >>> >>> I'm just working hard at keeping you guys busy ;) >>> >>> thanks, >>> stegen >>> >>> Pavlin Radoslavov wrote: >>>> Stegen Smith wrote: >>>> >>>>> Also an interesting thing to note is that if a routing entry is added manually, I see the following happening: >>>>> >>>>> [ 2008/10/09 16:31:35 ERROR xorp_fea:15980 XRL +379 xrl_pf_stcp.cc die ] STCPRequestHandler died: life timer expired >>>>> [ 2008/10/09 16:31:35 ERROR xorp_fea:15980 XRL +379 xrl_pf_stcp.cc die ] STCPRequestHandler died: life timer expired >>>> This issue is probably independent from the routing table cleanup, >>>> hence please submit a Bugzilla entry. >>>> >>>> Thanks, >>>> Pavlin >>>> >>>>> And also, I forgot to give the following information... I'm using the latest xorp build from cvs, and this is openbsd 4.3. >>> _______________________________________________ >>> Xorp-users mailing list >>> Xorp-users at xorp.org >>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users >> _______________________________________________ >> Xorp-users mailing list >> Xorp-users at xorp.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > From stegen at owns.com Mon Oct 13 12:26:24 2008 From: stegen at owns.com (Stegen Smith) Date: Mon, 13 Oct 2008 12:26:24 -0700 Subject: [Xorp-users] xorp clearing routing table upon startup In-Reply-To: <48F39DA2.6080109@owns.com> References: <48EE93B7.8020607@owns.com> <48EE9681.1060001@owns.com> <200810100319.m9A3JYgc029228@fruitcake.ICSI.Berkeley.EDU> <48EFA10D.6070502@owns.com> <200810102121.m9ALKq9F006307@fruitcake.ICSI.Berkeley.EDU> <200810130305.m9D35B2f017031@fruitcake.ICSI.Berkeley.EDU> <48F39DA2.6080109@owns.com> Message-ID: <48F3A0E0.4030500@owns.com> Hmm... my bad. I should also state that the 10.5.49/24 network doesn't appear either... my egrep was fouled below so obviously it wouldn't have shown anything for that, but regardless it doesn't exist. just fyi for those who noticed my inability to type and would have felt inclined to reply about that... thanks! stegen Stegen Smith wrote: > Hi Pavlin, > > Thanks for the update! I've grabbed the latest source from CVS and got it up. I'm no longer seeing > those errors that I submitted the bug for; however, it does not seem that the latter issue of the > routing table not being updated from bgp is resolved. > > I can do the following: > xorp at at-ig1.sv> show bgp routes > Status Codes: * valid route, > best route > Origin Codes: i IGP, e EGP, ? incomplete > > Prefix Nexthop Peer AS Path > ------ ------- ---- ------- > * 10.3.48.0/20 10.3.14.7 10.3.14.99 65000 i > * 10.3.48.0/20 10.3.14.39 10.3.14.99 65000 i > * 10.5.49.0/24 10.3.14.39 10.3.14.99 65000 i > * 10.5.49.0/24 10.3.14.7 10.3.14.99 65000 i > xorp at at-ig1.sv> > > root0p7at-ig1.sv/usr/local/xorp netstat -nr|egrep "^10.[3,5].48" > root1p7at-ig1.sv/usr/local/xorp > > Also, when I ^C out of xorp_rtrmgr, it still does not shut down so cleanly: > ^C[ 2008/10/13 12:22:31 INFO xorp_rtrmgr:351 RTRMGR +1024 task.cc shutdown ] Shutting down module: bgp > [ 2008/10/13 12:22:31 INFO xorp_bgp:15136 BGP +451 peer.cc send_notification ] Sending: > Notification Packet: Cease(6) > [ 2008/10/13 12:22:31 TRACE xorp_bgp:15136 BGP +456 peer.cc send_notification ] Peer > {10.3.14.40(179) 10.3.14.39(179)}: Send: Notification Packet: Cease(6) > [ 2008/10/13 12:22:31 TRACE xorp_bgp:15136 BGP +2062 peer.cc set_state ] Peer {10.3.14.40(179) > 10.3.14.39(179)}: Previous state: ESTABLISHED(6) Current state: STOPPED(7) > [ 2008/10/13 12:22:31 INFO xorp_bgp:15136 BGP +451 peer.cc send_notification ] Sending: > Notification Packet: Cease(6) > [ 2008/10/13 12:22:31 TRACE xorp_bgp:15136 BGP +456 peer.cc send_notification ] Peer > {10.3.14.8(179) 10.3.14.7(179)}: Send: Notification Packet: Cease(6) > [ 2008/10/13 12:22:31 TRACE xorp_bgp:15136 BGP +2062 peer.cc set_state ] Peer {10.3.14.8(179) > 10.3.14.7(179)}: Previous state: ESTABLISHED(6) Current state: STOPPED(7) > [ 2008/10/13 12:22:31 TRACE xorp_bgp:15136 BGP +2062 peer.cc set_state ] Peer {10.3.14.8(179) > 10.3.14.7(179)}: Previous state: STOPPED(7) Current state: IDLE(1) > [ 2008/10/13 12:22:31 TRACE xorp_bgp:15136 BGP +2062 peer.cc set_state ] Peer {10.3.14.40(179) > 10.3.14.39(179)}: Previous state: STOPPED(7) Current state: IDLE(1) > [ 2008/10/13 12:22:31 INFO xorp_bgp:15136 BGP +149 bgp.cc BGPMain ] EVENT: timers 4 > [ 2008/10/13 12:22:31 INFO xorp_bgp:15136 BGP +161 bgp.cc BGPMain ] xrl router still has pending > operations > [ 2008/10/13 12:22:31 INFO xorp_bgp:15136 BGP +167 bgp.cc BGPMain ] xrl router no more pending > operations > [ 2008/10/13 12:22:31 ERROR xorp_rib:30518 LIBXORP +222 buffered_asyncio.cc io_event ] read error 54 > [ 2008/10/13 12:22:31 ERROR xorp_rib:30518 XRL +169 xrl_pf_stcp.cc read_event ] Read failed (error > = 54) > [ 2008/10/13 12:22:31 ERROR xorp_rib:30518 XRL +378 xrl_pf_stcp.cc die ] STCPRequestHandler died: > read error > [ 2008/10/13 12:22:31 INFO xorp_rtrmgr:351 RTRMGR +280 module_manager.cc module_exited ] Module > normal exit: bgp > [ 2008/10/13 12:22:31 INFO xorp_rib RIB ] Received death event for protocol bgp shutting down ------- > OriginTable: ebgp > EGP > next table = Merged:(ebgp)+(ibgp) > [ 2008/10/13 12:22:31 INFO xorp_rib RIB ] Received death event for protocol bgp shutting down ------- > OriginTable: ebgp > EGP > next table = Merged:(ebgp)+(ibgp) > [ 2008/10/13 12:22:32 WARNING xorp_rtrmgr:351 XrlFinderTarget +407 ../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 "bgp" does not exist or is not enabled. > [ 2008/10/13 12:22:33 INFO xorp_rtrmgr:351 RTRMGR +1024 task.cc shutdown ] Shutting down module: policy > [ 2008/10/13 12:22:33 INFO xorp_rtrmgr:351 XRL +432 xrl_router.cc get_sender ] Sender died > (protocol = "stcp", address = "127.0.0.1:11045") > [ 2008/10/13 12:22:33 ERROR xorp_rtrmgr:351 LIBCOMM +610 comm_sock.c comm_sock_connect4 ] Error > connecting socket (family = 2, remote_addr = 127.0.0.1, remote_port = 11045): Connection refused > [ 2008/10/13 12:22:33 ERROR xorp_rtrmgr:351 XRL +63 xrl_pf_factory.cc create_sender ] > XrlPFSenderFactory::create failed: XrlPFConstructorError from line 667 of xrl_pf_stcp.cc: Could not > connect to 127.0.0.1:11045 > > [ 2008/10/13 12:22:33 ERROR xorp_rtrmgr:351 XRL +451 xrl_router.cc get_sender ] Could not create > XrlPFSender for protocol = "stcp" address = "127.0.0.1:11045" > [1] 351 segmentation fault (core dumped) ./bin/xorp_rtrmgr > > Let me know what you would like me to do next =) > > thanks! > stegen > > Pavlin Radoslavov wrote: >> Pavlin Radoslavov wrote: >> >>> Stegen Smith wrote: >>> >>>> Hi Pavlin, >>>> >>>> Yeah, it seems to occur when things sit idly. Ultimately something gums up the works and I get >>>> those error messages, so it's not only when I modified the routing table myself. It should be >>>> easily recreated. Odd... So with that, I'll get one submitted right away with more detailed >>>> information. >>> I just saw the entry in Bugzilla. Thanks! >>> >>> The missing routes might be related to the XRL errors. >>> The "life timer expired" indicates that the XRL communication has >>> timed-out, and after that all bets are off. >>> BTW, this particular timeout shouldn't happen under (very relaxed) >>> normal circumstances, so there is something else happening. >>> This probably also explains the shutdown problem with the leftover >>> XORP processes. >>> >>> Re. the shutdown question: yes, if you are running XORP in >>> foreground, Ctrl-C should be the way to stop it. >>> >>> I (or somebody else) should look at this problem very soon, because >>> it looks critical. >> The problem is fixed in CVS: >> >> Revision Changes Path >> 1.25 +9 -8; commitid: 7b5a48f2abbc41a7; xorp/libxipc/test_stcp.cc >> 1.72 +18 -20; commitid: 7b5a48f2abbc41a7; xorp/libxipc/xrl_pf_stcp.cc >> 1.36 +4 -4; commitid: 7b5a48f2abbc41a7; xorp/libxipc/xrl_pf_stcp.hh >> >> Please checkout the latest code from CVS and verify whether it fixes >> the problems on your side. >> >> Pavlin >> >>> Pavlin >>> >>>> Another note... I've got bgp peering setup and I see the following: >>>> xorp at at-ig1.sv.atomz.com> show bgp routes >>>> Status Codes: * valid route, > best route >>>> Origin Codes: i IGP, e EGP, ? incomplete >>>> >>>> Prefix Nexthop Peer AS Path >>>> ------ ------- ---- ------- >>>> * 10.3.48.0/20 10.3.14.39 10.3.14.99 65000 i >>>> * 10.5.49.0/24 10.3.14.39 10.3.14.99 65000 i >>>> * 10.3.48.0/20 10.3.14.7 10.3.14.99 65000 i >>>> * 10.5.49.0/24 10.3.14.7 10.3.14.99 65000 i >>>> >>>> yet no routes are inserted on the system: >>>> root1paat-ig1.sv~ netstat -nr|grep 10.3.48 >>>> root1paat-ig1.sv~ >>>> >>>> I'm guessing that this is another bug, or perhaps related to the first issue I've noticed. I'll >>>> submit a bug for the first one, and if you would like me to do the same for this issue I'm seeing, >>>> let me know. =) >>>> >>>> And one more side note... what's the cleanest way to shutdown the routing software? I've been >>>> letting xorp_rtrmgr run in the foreground while I do testing, and ^C when I want to quit out. >>>> Probably not the best way to do it, as it ends up crashing (cores) and leaving other xorp processes >>>> up and running: >>>> >>>> ^C[ 2008/10/10 11:13:26 INFO xorp_rtrmgr:8398 RTRMGR +1024 task.cc shutdown ] Shutting down module: bgp >>>> [ 2008/10/10 11:13:26 INFO xorp_bgp:18890 BGP +451 peer.cc send_notification ] Sending: >>>> Notification Packet: Cease(6) >>>> [ 2008/10/10 11:13:26 TRACE xorp_bgp:18890 BGP +456 peer.cc send_notification ] Peer >>>> {10.3.14.40(179) 10.3.14.39(179)}: Send: Notification Packet: Cease(6) >>>> >>>> >>>> >>>> [ 2008/10/10 11:13:28 INFO xorp_rtrmgr:8398 XRL +432 xrl_router.cc get_sender ] Sender died >>>> (protocol = "stcp", address = "127.0.0.1:11810") >>>> [ 2008/10/10 11:13:28 ERROR xorp_rtrmgr:8398 LIBCOMM +610 comm_sock.c comm_sock_connect4 ] Error >>>> connecting socket (family = 2, remote_addr = 127.0.0.1, remote_port = 11810): Connection refused >>>> [ 2008/10/10 11:13:28 ERROR xorp_rtrmgr:8398 XRL +63 xrl_pf_factory.cc create_sender ] >>>> XrlPFSenderFactory::create failed: XrlPFConstructorError from line 668 of xrl_pf_stcp.cc: Could not >>>> connect to 127.0.0.1:11810 >>>> >>>> [ 2008/10/10 11:13:28 ERROR xorp_rtrmgr:8398 XRL +451 xrl_router.cc get_sender ] Could not create >>>> XrlPFSender for protocol = "stcp" address = "127.0.0.1:11810" >>>> [1] 8398 segmentation fault (core dumped) ./bin/xorp_rtrmgr >>>> root139p9at-ig1.sv/usr/local/xorp >>>> root139p9at-ig1.sv/usr/local/xorp ps auxww|grep xorp >>>> xorp 20544 0.0 0.1 3516 5484 p1 I+ 5:21PM 0:00.35 /usr/local/xorp/bin/xorpsh >>>> root 2811 0.0 0.2 5076 6476 p9 S 11:09AM 0:00.75 xorp_fea >>>> root 17533 0.0 0.1 2812 4452 p9 S 11:10AM 0:00.22 xorp_rib >>>> root 16731 0.0 0.1 2188 3872 p9 I 11:10AM 0:00.18 xorp_fib2mrib >>>> root 9111 0.0 0.1 2728 4268 p9 S 11:10AM 0:00.20 xorp_igmp >>>> root 32406 0.0 0.1 4752 6028 p9 S 11:10AM 0:00.50 xorp_pimsm4 >>>> root 4331 0.0 0.0 848 692 p9 R+/1 11:16AM 0:00.00 grep xorp (zsh) >>>> root0p9at-ig1.sv/usr/local/xorp >>>> >>>> I'm just working hard at keeping you guys busy ;) >>>> >>>> thanks, >>>> stegen >>>> >>>> Pavlin Radoslavov wrote: >>>>> Stegen Smith wrote: >>>>> >>>>>> Also an interesting thing to note is that if a routing entry is added manually, I see the following happening: >>>>>> >>>>>> [ 2008/10/09 16:31:35 ERROR xorp_fea:15980 XRL +379 xrl_pf_stcp.cc die ] STCPRequestHandler died: life timer expired >>>>>> [ 2008/10/09 16:31:35 ERROR xorp_fea:15980 XRL +379 xrl_pf_stcp.cc die ] STCPRequestHandler died: life timer expired >>>>> This issue is probably independent from the routing table cleanup, >>>>> hence please submit a Bugzilla entry. >>>>> >>>>> Thanks, >>>>> Pavlin >>>>> >>>>>> And also, I forgot to give the following information... I'm using the latest xorp build from cvs, and this is openbsd 4.3. >>>> _______________________________________________ >>>> Xorp-users mailing list >>>> Xorp-users at xorp.org >>>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users >>> _______________________________________________ >>> Xorp-users mailing list >>> Xorp-users at xorp.org >>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > From pavlin at ICSI.Berkeley.EDU Mon Oct 13 14:24:26 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Mon, 13 Oct 2008 14:24:26 -0700 Subject: [Xorp-users] xorp clearing routing table upon startup In-Reply-To: <48F39DA2.6080109@owns.com> References: <48EE93B7.8020607@owns.com> <48EE9681.1060001@owns.com> <200810100319.m9A3JYgc029228@fruitcake.ICSI.Berkeley.EDU> <48EFA10D.6070502@owns.com> <200810102121.m9ALKq9F006307@fruitcake.ICSI.Berkeley.EDU> <200810130305.m9D35B2f017031@fruitcake.ICSI.Berkeley.EDU> <48F39DA2.6080109@owns.com> Message-ID: <200810132124.m9DLOQqW027375@fruitcake.ICSI.Berkeley.EDU> Stegen Smith wrote: > Hi Pavlin, > > Thanks for the update! I've grabbed the latest source from CVS and got it up. I'm no longer seeing > those errors that I submitted the bug for; however, it does not seem that the latter issue of the > routing table not being updated from bgp is resolved. OK, according to a later email on the subject this issue has been resolved. However, the segmentation fault you get during a shutdown seems like a real issue. Please submit another Bugzilla entry about it. Thanks, Pavlin > I can do the following: > xorp at at-ig1.sv> show bgp routes > Status Codes: * valid route, > best route > Origin Codes: i IGP, e EGP, ? incomplete > > Prefix Nexthop Peer AS Path > ------ ------- ---- ------- > * 10.3.48.0/20 10.3.14.7 10.3.14.99 65000 i > * 10.3.48.0/20 10.3.14.39 10.3.14.99 65000 i > * 10.5.49.0/24 10.3.14.39 10.3.14.99 65000 i > * 10.5.49.0/24 10.3.14.7 10.3.14.99 65000 i > xorp at at-ig1.sv> > > root0p7at-ig1.sv/usr/local/xorp netstat -nr|egrep "^10.[3,5].48" > root1p7at-ig1.sv/usr/local/xorp > > Also, when I ^C out of xorp_rtrmgr, it still does not shut down so cleanly: > ^C[ 2008/10/13 12:22:31 INFO xorp_rtrmgr:351 RTRMGR +1024 task.cc shutdown ] Shutting down module: bgp > [ 2008/10/13 12:22:31 INFO xorp_bgp:15136 BGP +451 peer.cc send_notification ] Sending: > Notification Packet: Cease(6) > [ 2008/10/13 12:22:31 TRACE xorp_bgp:15136 BGP +456 peer.cc send_notification ] Peer > {10.3.14.40(179) 10.3.14.39(179)}: Send: Notification Packet: Cease(6) > [ 2008/10/13 12:22:31 TRACE xorp_bgp:15136 BGP +2062 peer.cc set_state ] Peer {10.3.14.40(179) > 10.3.14.39(179)}: Previous state: ESTABLISHED(6) Current state: STOPPED(7) > [ 2008/10/13 12:22:31 INFO xorp_bgp:15136 BGP +451 peer.cc send_notification ] Sending: > Notification Packet: Cease(6) > [ 2008/10/13 12:22:31 TRACE xorp_bgp:15136 BGP +456 peer.cc send_notification ] Peer > {10.3.14.8(179) 10.3.14.7(179)}: Send: Notification Packet: Cease(6) > [ 2008/10/13 12:22:31 TRACE xorp_bgp:15136 BGP +2062 peer.cc set_state ] Peer {10.3.14.8(179) > 10.3.14.7(179)}: Previous state: ESTABLISHED(6) Current state: STOPPED(7) > [ 2008/10/13 12:22:31 TRACE xorp_bgp:15136 BGP +2062 peer.cc set_state ] Peer {10.3.14.8(179) > 10.3.14.7(179)}: Previous state: STOPPED(7) Current state: IDLE(1) > [ 2008/10/13 12:22:31 TRACE xorp_bgp:15136 BGP +2062 peer.cc set_state ] Peer {10.3.14.40(179) > 10.3.14.39(179)}: Previous state: STOPPED(7) Current state: IDLE(1) > [ 2008/10/13 12:22:31 INFO xorp_bgp:15136 BGP +149 bgp.cc BGPMain ] EVENT: timers 4 > [ 2008/10/13 12:22:31 INFO xorp_bgp:15136 BGP +161 bgp.cc BGPMain ] xrl router still has pending > operations > [ 2008/10/13 12:22:31 INFO xorp_bgp:15136 BGP +167 bgp.cc BGPMain ] xrl router no more pending > operations > [ 2008/10/13 12:22:31 ERROR xorp_rib:30518 LIBXORP +222 buffered_asyncio.cc io_event ] read error 54 > [ 2008/10/13 12:22:31 ERROR xorp_rib:30518 XRL +169 xrl_pf_stcp.cc read_event ] Read failed (error > = 54) > [ 2008/10/13 12:22:31 ERROR xorp_rib:30518 XRL +378 xrl_pf_stcp.cc die ] STCPRequestHandler died: > read error > [ 2008/10/13 12:22:31 INFO xorp_rtrmgr:351 RTRMGR +280 module_manager.cc module_exited ] Module > normal exit: bgp > [ 2008/10/13 12:22:31 INFO xorp_rib RIB ] Received death event for protocol bgp shutting down ------- > OriginTable: ebgp > EGP > next table = Merged:(ebgp)+(ibgp) > [ 2008/10/13 12:22:31 INFO xorp_rib RIB ] Received death event for protocol bgp shutting down ------- > OriginTable: ebgp > EGP > next table = Merged:(ebgp)+(ibgp) > [ 2008/10/13 12:22:32 WARNING xorp_rtrmgr:351 XrlFinderTarget +407 ../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 "bgp" does not exist or is not enabled. > [ 2008/10/13 12:22:33 INFO xorp_rtrmgr:351 RTRMGR +1024 task.cc shutdown ] Shutting down module: policy > [ 2008/10/13 12:22:33 INFO xorp_rtrmgr:351 XRL +432 xrl_router.cc get_sender ] Sender died > (protocol = "stcp", address = "127.0.0.1:11045") > [ 2008/10/13 12:22:33 ERROR xorp_rtrmgr:351 LIBCOMM +610 comm_sock.c comm_sock_connect4 ] Error > connecting socket (family = 2, remote_addr = 127.0.0.1, remote_port = 11045): Connection refused > [ 2008/10/13 12:22:33 ERROR xorp_rtrmgr:351 XRL +63 xrl_pf_factory.cc create_sender ] > XrlPFSenderFactory::create failed: XrlPFConstructorError from line 667 of xrl_pf_stcp.cc: Could not > connect to 127.0.0.1:11045 > > [ 2008/10/13 12:22:33 ERROR xorp_rtrmgr:351 XRL +451 xrl_router.cc get_sender ] Could not create > XrlPFSender for protocol = "stcp" address = "127.0.0.1:11045" > [1] 351 segmentation fault (core dumped) ./bin/xorp_rtrmgr > > Let me know what you would like me to do next =) > > thanks! > stegen > > Pavlin Radoslavov wrote: > > Pavlin Radoslavov wrote: > > > >> Stegen Smith wrote: > >> > >>> Hi Pavlin, > >>> > >>> Yeah, it seems to occur when things sit idly. Ultimately something gums up the works and I get > >>> those error messages, so it's not only when I modified the routing table myself. It should be > >>> easily recreated. Odd... So with that, I'll get one submitted right away with more detailed > >>> information. > >> I just saw the entry in Bugzilla. Thanks! > >> > >> The missing routes might be related to the XRL errors. > >> The "life timer expired" indicates that the XRL communication has > >> timed-out, and after that all bets are off. > >> BTW, this particular timeout shouldn't happen under (very relaxed) > >> normal circumstances, so there is something else happening. > >> This probably also explains the shutdown problem with the leftover > >> XORP processes. > >> > >> Re. the shutdown question: yes, if you are running XORP in > >> foreground, Ctrl-C should be the way to stop it. > >> > >> I (or somebody else) should look at this problem very soon, because > >> it looks critical. > > > > The problem is fixed in CVS: > > > > Revision Changes Path > > 1.25 +9 -8; commitid: 7b5a48f2abbc41a7; xorp/libxipc/test_stcp.cc > > 1.72 +18 -20; commitid: 7b5a48f2abbc41a7; xorp/libxipc/xrl_pf_stcp.cc > > 1.36 +4 -4; commitid: 7b5a48f2abbc41a7; xorp/libxipc/xrl_pf_stcp.hh > > > > Please checkout the latest code from CVS and verify whether it fixes > > the problems on your side. > > > > Pavlin > > > >> Pavlin > >> > >>> Another note... I've got bgp peering setup and I see the following: > >>> xorp at at-ig1.sv.atomz.com> show bgp routes > >>> Status Codes: * valid route, > best route > >>> Origin Codes: i IGP, e EGP, ? incomplete > >>> > >>> Prefix Nexthop Peer AS Path > >>> ------ ------- ---- ------- > >>> * 10.3.48.0/20 10.3.14.39 10.3.14.99 65000 i > >>> * 10.5.49.0/24 10.3.14.39 10.3.14.99 65000 i > >>> * 10.3.48.0/20 10.3.14.7 10.3.14.99 65000 i > >>> * 10.5.49.0/24 10.3.14.7 10.3.14.99 65000 i > >>> > >>> yet no routes are inserted on the system: > >>> root1paat-ig1.sv~ netstat -nr|grep 10.3.48 > >>> root1paat-ig1.sv~ > >>> > >>> I'm guessing that this is another bug, or perhaps related to the first issue I've noticed. I'll > >>> submit a bug for the first one, and if you would like me to do the same for this issue I'm seeing, > >>> let me know. =) > >>> > >>> And one more side note... what's the cleanest way to shutdown the routing software? I've been > >>> letting xorp_rtrmgr run in the foreground while I do testing, and ^C when I want to quit out. > >>> Probably not the best way to do it, as it ends up crashing (cores) and leaving other xorp processes > >>> up and running: > >>> > >>> ^C[ 2008/10/10 11:13:26 INFO xorp_rtrmgr:8398 RTRMGR +1024 task.cc shutdown ] Shutting down module: bgp > >>> [ 2008/10/10 11:13:26 INFO xorp_bgp:18890 BGP +451 peer.cc send_notification ] Sending: > >>> Notification Packet: Cease(6) > >>> [ 2008/10/10 11:13:26 TRACE xorp_bgp:18890 BGP +456 peer.cc send_notification ] Peer > >>> {10.3.14.40(179) 10.3.14.39(179)}: Send: Notification Packet: Cease(6) > >>> > >>> > >>> > >>> [ 2008/10/10 11:13:28 INFO xorp_rtrmgr:8398 XRL +432 xrl_router.cc get_sender ] Sender died > >>> (protocol = "stcp", address = "127.0.0.1:11810") > >>> [ 2008/10/10 11:13:28 ERROR xorp_rtrmgr:8398 LIBCOMM +610 comm_sock.c comm_sock_connect4 ] Error > >>> connecting socket (family = 2, remote_addr = 127.0.0.1, remote_port = 11810): Connection refused > >>> [ 2008/10/10 11:13:28 ERROR xorp_rtrmgr:8398 XRL +63 xrl_pf_factory.cc create_sender ] > >>> XrlPFSenderFactory::create failed: XrlPFConstructorError from line 668 of xrl_pf_stcp.cc: Could not > >>> connect to 127.0.0.1:11810 > >>> > >>> [ 2008/10/10 11:13:28 ERROR xorp_rtrmgr:8398 XRL +451 xrl_router.cc get_sender ] Could not create > >>> XrlPFSender for protocol = "stcp" address = "127.0.0.1:11810" > >>> [1] 8398 segmentation fault (core dumped) ./bin/xorp_rtrmgr > >>> root139p9at-ig1.sv/usr/local/xorp > >>> root139p9at-ig1.sv/usr/local/xorp ps auxww|grep xorp > >>> xorp 20544 0.0 0.1 3516 5484 p1 I+ 5:21PM 0:00.35 /usr/local/xorp/bin/xorpsh > >>> root 2811 0.0 0.2 5076 6476 p9 S 11:09AM 0:00.75 xorp_fea > >>> root 17533 0.0 0.1 2812 4452 p9 S 11:10AM 0:00.22 xorp_rib > >>> root 16731 0.0 0.1 2188 3872 p9 I 11:10AM 0:00.18 xorp_fib2mrib > >>> root 9111 0.0 0.1 2728 4268 p9 S 11:10AM 0:00.20 xorp_igmp > >>> root 32406 0.0 0.1 4752 6028 p9 S 11:10AM 0:00.50 xorp_pimsm4 > >>> root 4331 0.0 0.0 848 692 p9 R+/1 11:16AM 0:00.00 grep xorp (zsh) > >>> root0p9at-ig1.sv/usr/local/xorp > >>> > >>> I'm just working hard at keeping you guys busy ;) > >>> > >>> thanks, > >>> stegen > >>> > >>> Pavlin Radoslavov wrote: > >>>> Stegen Smith wrote: > >>>> > >>>>> Also an interesting thing to note is that if a routing entry is added manually, I see the following happening: > >>>>> > >>>>> [ 2008/10/09 16:31:35 ERROR xorp_fea:15980 XRL +379 xrl_pf_stcp.cc die ] STCPRequestHandler died: life timer expired > >>>>> [ 2008/10/09 16:31:35 ERROR xorp_fea:15980 XRL +379 xrl_pf_stcp.cc die ] STCPRequestHandler died: life timer expired > >>>> This issue is probably independent from the routing table cleanup, > >>>> hence please submit a Bugzilla entry. > >>>> > >>>> Thanks, > >>>> Pavlin > >>>> > >>>>> And also, I forgot to give the following information... I'm using the latest xorp build from cvs, and this is openbsd 4.3. > >>> _______________________________________________ > >>> Xorp-users mailing list > >>> Xorp-users at xorp.org > >>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > >> _______________________________________________ > >> Xorp-users mailing list > >> Xorp-users at xorp.org > >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From jjajal at gmail.com Mon Oct 13 23:21:55 2008 From: jjajal at gmail.com (Jigar) Date: Tue, 14 Oct 2008 11:51:55 +0530 Subject: [Xorp-users] IGMP and PIM-SSM problem In-Reply-To: <200810131753.m9DHrppg004342@fruitcake.ICSI.Berkeley.EDU> References: <48F34D94.2070201@gmail.com> <200810131753.m9DHrppg004342@fruitcake.ICSI.Berkeley.EDU> Message-ID: <48F43A83.7000302@gmail.com> Pavlin Radoslavov wrote: > Jigar wrote: > > >> Hi All, >> I have two PCs with Red Hat Linux installed in them. Both have two >> NICs. XORP-1.4 is running in PC-A with IGMPv3 and PIM-SM enabled. PC-A and >> PC-B are connected to each other through both interfaces. >> >> PC-A eth0: 10.100.3.107/24 >> PC-A eth1: 192.168.14.212/24 >> PC-B eth1: 10.100.3.220/24 >> PC-B eth0: 192.168.14.211/24 >> >> PC-A eth0 and PC-B eth1 are directly connected to each other. Similarly, PC-A >> eth1 and PC-B eth0 are directly connected to each other. >> >> Here, 192.168.14.211 is configured as static RP in PC-A. I am sending IGMP >> join report for 232.11.22.33 group and 192.168.14.14 source with INCLUDE mode >> from 10.100.3.220. I have sent PIM hello message from 192.168.14.211. As >> IGMPv3 and PIM-SM are runing on PC-A, it should convert that report into PIM >> JOIN(S,G) message and send it towards RP(192.168.14.211). But no message was >> sent by PC-A on its eth1. Tell me where I went wrong? >> > > The sender 192.168.14.14 is directly connected to both PC-A and > PC-B. If I change the IP address of source in IGMP report i.e. if 192.168.14.14 is changed to 11.22.33.44 then it is not directly connected to both PCs. Is there any other modifications required to prove that source is not directly connected? > Hence, the PIM-SM router connected to it will NOT > send PIM-SM Join message toward it. PIM-SM Join messages are only > sent to PIM-SM routers toward the sender (or the RP), and only if > the sender (or the RP) is not directly connected. > > Pavlin > Can you provide me the reference in RFC for this particular statement because I am not aware of this rule. Thanking you, - Jigar > 232.11.22.33 192.168.14.14 192.168.14.211 SG DirectlyConnectedS > Upstream interface (S): eth1 > Upstream interface (RP): eth1 > Upstream MRIB next hop (RP): 192.168.14.211 > Upstream MRIB next hop (S): UNKNOWN > *Upstream RPF'(S,G): UNKNOWN (I have doubt in > this. How can I configure RPF'(S,G)?)* > Upstream state: Joined > > >> I have copied my configuration file and condition of PC-A when I sent the >> IGMP report. >> * >> XORP Configuration file (On PC-A):* >> >> interfaces { >> restore-original-config-on-shutdown: false >> interface eth0 { >> description: "data interface" >> disable: false >> default-system-config >> } >> interface eth1 { >> description: "data interface" >> disable: false >> default-system-config >> } >> } >> >> fea { >> unicast-forwarding4 { >> disable: false >> forwarding-entries { >> retain-on-startup: false >> retain-on-shutdown: false >> } >> } >> } >> >> policy { >> /* Describe connected routes for redistribution */ >> policy-statement connected { >> term export { >> from { >> protocol: "connected" >> } >> } >> } >> } >> >> policy { >> /* Describe static routes for redistribution */ >> policy-statement static { >> term export { >> from { >> protocol: "static" >> } >> } >> } >> } >> >> plumbing { >> mfea4 { >> disable: false >> interface eth0 { >> vif eth0 { >> disable: false >> } >> } >> interface eth1 { >> vif eth1 { >> 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 eth0 { >> vif eth0 { >> disable: false >> version: 3 >> } >> } >> interface eth1 { >> vif eth1 { >> disable: false >> version: 3 >> } >> } >> traceoptions { >> flag all { >> disable: false >> } >> } >> } >> } >> >> protocols { >> pimsm4 { >> disable: false >> interface eth0 { >> vif eth0 { >> disable: false >> } >> } >> interface eth1 { >> vif eth1 { >> disable: false >> } >> } >> interface register_vif { >> vif register_vif { >> /* Note: this vif should be always enabled */ >> disable: false >> } >> } >> >> traceoptions { >> flag all { >> disable: false >> } >> } >> >> } >> } >> >> /* >> * Note: fib2mrib is needed for multicast only if the unicast protocols >> * don't populate the MRIB with multicast-specific routes. >> */ >> protocols { >> fib2mrib { >> disable: false >> } >> } >> >> *I have made 192.168.14.211 as static RP from configuration mode of xorpsh. >> Here is the command: set protocols pimsm4 static-rps rp 192.168.14.211 >> group-prefix 224.0.0.0/4* >> *then commit.* >> >> *XORPSH Console when I sent IGMP report:* >> root at localhost.localdomain> show pim join all >> Group Source RP Flags >> 224.0.0.0 192.168.14.211 192.168.14.211 RP >> Upstream interface (RP): eth1 >> Upstream MRIB next hop (RP): 192.168.14.211 >> Upstream state: NotJoined >> Join timer: -1 >> Joins RP: ... >> Join state: ... >> Prune state: ... >> Prune pending state: ... >> Could assert WC: ... >> I am DR: OOO >> Immediate olist RP: ... >> Inherited olist SG: ... >> Inherited olist SG_RPT: ... >> 232.11.22.33 192.168.14.14 192.168.14.211 SG DirectlyConnectedS >> Upstream interface (S): eth1 >> Upstream interface (RP): eth1 >> Upstream MRIB next hop (RP): 192.168.14.211 >> Upstream MRIB next hop (S): UNKNOWN >> *Upstream RPF'(S,G): UNKNOWN (I have doubt in >> this. How can I configure RPF'(S,G)?)* >> Upstream state: Joined >> Register state: RegisterNoinfo RegisterNotCouldRegister >> Join timer: 1 >> KAT(S,G) running: false >> Local receiver include WC: ... >> Local receiver include SG: O.. >> Local receiver exclude SG: ... >> Joins RP: ... >> Joins WC: ... >> Joins SG: ... >> Join state: ... >> 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: OO. >> Could assert WC: ... >> Could assert SG: ... >> I am DR: OOO >> Immediate olist RP: ... >> Immediate olist WC: ... >> Immediate olist SG: O.. >> Inherited olist SG: O.. >> Inherited olist SG_RPT: ... >> PIM include WC: ... >> PIM include SG: O.. >> PIM exclude SG: ... >> >> _______________________________________________ >> Xorp-users mailing list >> Xorp-users at xorp.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20081014/1f1da10e/attachment.html From stegen at owns.com Mon Oct 13 21:43:48 2008 From: stegen at owns.com (Stegen Smith) Date: Mon, 13 Oct 2008 21:43:48 -0700 Subject: [Xorp-users] xorp clearing routing table upon startup In-Reply-To: <200810132124.m9DLOQqW027375@fruitcake.ICSI.Berkeley.EDU> References: <48EE93B7.8020607@owns.com> <48EE9681.1060001@owns.com> <200810100319.m9A3JYgc029228@fruitcake.ICSI.Berkeley.EDU> <48EFA10D.6070502@owns.com> <200810102121.m9ALKq9F006307@fruitcake.ICSI.Berkeley.EDU> <200810130305.m9D35B2f017031@fruitcake.ICSI.Berkeley.EDU> <48F39DA2.6080109@owns.com> <200810132124.m9DLOQqW027375@fruitcake.ICSI.Berkeley.EDU> Message-ID: <3A63B5A6-515E-486C-84BA-09CE5993787A@owns.com> Hi Pavlin, Ooops... my head must have been in the wrong place in the previous email, then. I should have said, even though my grep was wrong (the grep would not have caught an entry for the 10.5.49 network), the routes are still NOT showing up in the routing table. I see the 10.3.48.0/20 and 10.5.49.0/24 networks in bgp, but not in the systems routing table. I'll submit another bug entry about the segfaults and we can figure out where to go after the other issue. thanks and sorry for the lack of clarity there stegen On Oct 13, 2008, at 2:24 PM, Pavlin Radoslavov wrote: > Stegen Smith wrote: > >> Hi Pavlin, >> >> Thanks for the update! I've grabbed the latest source from CVS and >> got it up. I'm no longer seeing >> those errors that I submitted the bug for; however, it does not >> seem that the latter issue of the >> routing table not being updated from bgp is resolved. > > OK, according to a later email on the subject this issue has been > resolved. However, the segmentation fault you get during a shutdown > seems like a real issue. Please submit another Bugzilla entry about > it. > > Thanks, > Pavlin > >> I can do the following: >> xorp at at-ig1.sv> show bgp routes >> Status Codes: * valid route, > best route >> Origin Codes: i IGP, e EGP, ? incomplete >> >> Prefix Nexthop Peer >> AS Path >> ------ ------- ---- >> ------- >> * 10.3.48.0/20 10.3.14.7 10.3.14.99 >> 65000 i >> * 10.3.48.0/20 10.3.14.39 10.3.14.99 >> 65000 i >> * 10.5.49.0/24 10.3.14.39 10.3.14.99 >> 65000 i >> * 10.5.49.0/24 10.3.14.7 10.3.14.99 >> 65000 i >> xorp at at-ig1.sv> >> >> root0p7at-ig1.sv/usr/local/xorp netstat -nr|egrep "^10.[3,5].48" >> root1p7at-ig1.sv/usr/local/xorp >> >> Also, when I ^C out of xorp_rtrmgr, it still does not shut down so >> cleanly: >> ^C[ 2008/10/13 12:22:31 INFO xorp_rtrmgr:351 RTRMGR +1024 task.cc >> shutdown ] Shutting down module: bgp >> [ 2008/10/13 12:22:31 INFO xorp_bgp:15136 BGP +451 peer.cc >> send_notification ] Sending: >> Notification Packet: Cease(6) >> [ 2008/10/13 12:22:31 TRACE xorp_bgp:15136 BGP +456 peer.cc >> send_notification ] Peer >> {10.3.14.40(179) 10.3.14.39(179)}: Send: Notification Packet: >> Cease(6) >> [ 2008/10/13 12:22:31 TRACE xorp_bgp:15136 BGP +2062 peer.cc >> set_state ] Peer {10.3.14.40(179) >> 10.3.14.39(179)}: Previous state: ESTABLISHED(6) Current state: >> STOPPED(7) >> [ 2008/10/13 12:22:31 INFO xorp_bgp:15136 BGP +451 peer.cc >> send_notification ] Sending: >> Notification Packet: Cease(6) >> [ 2008/10/13 12:22:31 TRACE xorp_bgp:15136 BGP +456 peer.cc >> send_notification ] Peer >> {10.3.14.8(179) 10.3.14.7(179)}: Send: Notification Packet: Cease(6) >> [ 2008/10/13 12:22:31 TRACE xorp_bgp:15136 BGP +2062 peer.cc >> set_state ] Peer {10.3.14.8(179) >> 10.3.14.7(179)}: Previous state: ESTABLISHED(6) Current state: >> STOPPED(7) >> [ 2008/10/13 12:22:31 TRACE xorp_bgp:15136 BGP +2062 peer.cc >> set_state ] Peer {10.3.14.8(179) >> 10.3.14.7(179)}: Previous state: STOPPED(7) Current state: IDLE(1) >> [ 2008/10/13 12:22:31 TRACE xorp_bgp:15136 BGP +2062 peer.cc >> set_state ] Peer {10.3.14.40(179) >> 10.3.14.39(179)}: Previous state: STOPPED(7) Current state: IDLE(1) >> [ 2008/10/13 12:22:31 INFO xorp_bgp:15136 BGP +149 bgp.cc >> BGPMain ] EVENT: timers 4 >> [ 2008/10/13 12:22:31 INFO xorp_bgp:15136 BGP +161 bgp.cc >> BGPMain ] xrl router still has pending >> operations >> [ 2008/10/13 12:22:31 INFO xorp_bgp:15136 BGP +167 bgp.cc >> BGPMain ] xrl router no more pending >> operations >> [ 2008/10/13 12:22:31 ERROR xorp_rib:30518 LIBXORP +222 >> buffered_asyncio.cc io_event ] read error 54 >> [ 2008/10/13 12:22:31 ERROR xorp_rib:30518 XRL +169 xrl_pf_stcp.cc >> read_event ] Read failed (error >> = 54) >> [ 2008/10/13 12:22:31 ERROR xorp_rib:30518 XRL +378 xrl_pf_stcp.cc >> die ] STCPRequestHandler died: >> read error >> [ 2008/10/13 12:22:31 INFO xorp_rtrmgr:351 RTRMGR +280 >> module_manager.cc module_exited ] Module >> normal exit: bgp >> [ 2008/10/13 12:22:31 INFO xorp_rib RIB ] Received death event for >> protocol bgp shutting down ------- >> OriginTable: ebgp >> EGP >> next table = Merged:(ebgp)+(ibgp) >> [ 2008/10/13 12:22:31 INFO xorp_rib RIB ] Received death event for >> protocol bgp shutting down ------- >> OriginTable: ebgp >> EGP >> next table = Merged:(ebgp)+(ibgp) >> [ 2008/10/13 12:22:32 WARNING xorp_rtrmgr:351 XrlFinderTarget >> +407 ../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 "bgp" does not exist or is not enabled. >> [ 2008/10/13 12:22:33 INFO xorp_rtrmgr:351 RTRMGR +1024 task.cc >> shutdown ] Shutting down module: policy >> [ 2008/10/13 12:22:33 INFO xorp_rtrmgr:351 XRL +432 xrl_router.cc >> get_sender ] Sender died >> (protocol = "stcp", address = "127.0.0.1:11045") >> [ 2008/10/13 12:22:33 ERROR xorp_rtrmgr:351 LIBCOMM +610 >> comm_sock.c comm_sock_connect4 ] Error >> connecting socket (family = 2, remote_addr = 127.0.0.1, remote_port >> = 11045): Connection refused >> [ 2008/10/13 12:22:33 ERROR xorp_rtrmgr:351 XRL +63 >> xrl_pf_factory.cc create_sender ] >> XrlPFSenderFactory::create failed: XrlPFConstructorError from line >> 667 of xrl_pf_stcp.cc: Could not >> connect to 127.0.0.1:11045 >> >> [ 2008/10/13 12:22:33 ERROR xorp_rtrmgr:351 XRL +451 xrl_router.cc >> get_sender ] Could not create >> XrlPFSender for protocol = "stcp" address = "127.0.0.1:11045" >> [1] 351 segmentation fault (core dumped) ./bin/xorp_rtrmgr >> >> Let me know what you would like me to do next =) >> >> thanks! >> stegen >> >> Pavlin Radoslavov wrote: >>> Pavlin Radoslavov wrote: >>> >>>> Stegen Smith wrote: >>>> >>>>> Hi Pavlin, >>>>> >>>>> Yeah, it seems to occur when things sit idly. Ultimately >>>>> something gums up the works and I get >>>>> those error messages, so it's not only when I modified the >>>>> routing table myself. It should be >>>>> easily recreated. Odd... So with that, I'll get one submitted >>>>> right away with more detailed >>>>> information. >>>> I just saw the entry in Bugzilla. Thanks! >>>> >>>> The missing routes might be related to the XRL errors. >>>> The "life timer expired" indicates that the XRL communication has >>>> timed-out, and after that all bets are off. >>>> BTW, this particular timeout shouldn't happen under (very relaxed) >>>> normal circumstances, so there is something else happening. >>>> This probably also explains the shutdown problem with the leftover >>>> XORP processes. >>>> >>>> Re. the shutdown question: yes, if you are running XORP in >>>> foreground, Ctrl-C should be the way to stop it. >>>> >>>> I (or somebody else) should look at this problem very soon, because >>>> it looks critical. >>> >>> The problem is fixed in CVS: >>> >>> Revision Changes Path >>> 1.25 +9 -8; commitid: 7b5a48f2abbc41a7; xorp/libxipc/ >>> test_stcp.cc >>> 1.72 +18 -20; commitid: 7b5a48f2abbc41a7; xorp/libxipc/ >>> xrl_pf_stcp.cc >>> 1.36 +4 -4; commitid: 7b5a48f2abbc41a7; xorp/libxipc/ >>> xrl_pf_stcp.hh >>> >>> Please checkout the latest code from CVS and verify whether it fixes >>> the problems on your side. >>> >>> Pavlin >>> >>>> Pavlin >>>> >>>>> Another note... I've got bgp peering setup and I see the >>>>> following: >>>>> xorp at at-ig1.sv.atomz.com> show bgp routes >>>>> Status Codes: * valid route, > best route >>>>> Origin Codes: i IGP, e EGP, ? incomplete >>>>> >>>>> Prefix Nexthop >>>>> Peer AS Path >>>>> ------ ------- >>>>> ---- ------- >>>>> * 10.3.48.0/20 10.3.14.39 >>>>> 10.3.14.99 65000 i >>>>> * 10.5.49.0/24 10.3.14.39 >>>>> 10.3.14.99 65000 i >>>>> * 10.3.48.0/20 10.3.14.7 >>>>> 10.3.14.99 65000 i >>>>> * 10.5.49.0/24 10.3.14.7 >>>>> 10.3.14.99 65000 i >>>>> >>>>> yet no routes are inserted on the system: >>>>> root1paat-ig1.sv~ netstat -nr|grep 10.3.48 >>>>> root1paat-ig1.sv~ >>>>> >>>>> I'm guessing that this is another bug, or perhaps related to the >>>>> first issue I've noticed. I'll >>>>> submit a bug for the first one, and if you would like me to do >>>>> the same for this issue I'm seeing, >>>>> let me know. =) >>>>> >>>>> And one more side note... what's the cleanest way to shutdown >>>>> the routing software? I've been >>>>> letting xorp_rtrmgr run in the foreground while I do testing, >>>>> and ^C when I want to quit out. >>>>> Probably not the best way to do it, as it ends up crashing >>>>> (cores) and leaving other xorp processes >>>>> up and running: >>>>> >>>>> ^C[ 2008/10/10 11:13:26 INFO xorp_rtrmgr:8398 RTRMGR +1024 >>>>> task.cc shutdown ] Shutting down module: bgp >>>>> [ 2008/10/10 11:13:26 INFO xorp_bgp:18890 BGP +451 peer.cc >>>>> send_notification ] Sending: >>>>> Notification Packet: Cease(6) >>>>> [ 2008/10/10 11:13:26 TRACE xorp_bgp:18890 BGP +456 peer.cc >>>>> send_notification ] Peer >>>>> {10.3.14.40(179) 10.3.14.39(179)}: Send: Notification Packet: >>>>> Cease(6) >>>>> >>>>> >>>>> >>>>> [ 2008/10/10 11:13:28 INFO xorp_rtrmgr:8398 XRL +432 >>>>> xrl_router.cc get_sender ] Sender died >>>>> (protocol = "stcp", address = "127.0.0.1:11810") >>>>> [ 2008/10/10 11:13:28 ERROR xorp_rtrmgr:8398 LIBCOMM +610 >>>>> comm_sock.c comm_sock_connect4 ] Error >>>>> connecting socket (family = 2, remote_addr = 127.0.0.1, >>>>> remote_port = 11810): Connection refused >>>>> [ 2008/10/10 11:13:28 ERROR xorp_rtrmgr:8398 XRL +63 >>>>> xrl_pf_factory.cc create_sender ] >>>>> XrlPFSenderFactory::create failed: XrlPFConstructorError from >>>>> line 668 of xrl_pf_stcp.cc: Could not >>>>> connect to 127.0.0.1:11810 >>>>> >>>>> [ 2008/10/10 11:13:28 ERROR xorp_rtrmgr:8398 XRL +451 >>>>> xrl_router.cc get_sender ] Could not create >>>>> XrlPFSender for protocol = "stcp" address = "127.0.0.1:11810" >>>>> [1] 8398 segmentation fault (core dumped) ./bin/xorp_rtrmgr >>>>> root139p9at-ig1.sv/usr/local/xorp >>>>> root139p9at-ig1.sv/usr/local/xorp ps auxww|grep xorp >>>>> xorp 20544 0.0 0.1 3516 5484 p1 I+ 5:21PM >>>>> 0:00.35 /usr/local/xorp/bin/xorpsh >>>>> root 2811 0.0 0.2 5076 6476 p9 S 11:09AM >>>>> 0:00.75 xorp_fea >>>>> root 17533 0.0 0.1 2812 4452 p9 S 11:10AM >>>>> 0:00.22 xorp_rib >>>>> root 16731 0.0 0.1 2188 3872 p9 I 11:10AM >>>>> 0:00.18 xorp_fib2mrib >>>>> root 9111 0.0 0.1 2728 4268 p9 S 11:10AM >>>>> 0:00.20 xorp_igmp >>>>> root 32406 0.0 0.1 4752 6028 p9 S 11:10AM >>>>> 0:00.50 xorp_pimsm4 >>>>> root 4331 0.0 0.0 848 692 p9 R+/1 11:16AM >>>>> 0:00.00 grep xorp (zsh) >>>>> root0p9at-ig1.sv/usr/local/xorp >>>>> >>>>> I'm just working hard at keeping you guys busy ;) >>>>> >>>>> thanks, >>>>> stegen >>>>> >>>>> Pavlin Radoslavov wrote: >>>>>> Stegen Smith wrote: >>>>>> >>>>>>> Also an interesting thing to note is that if a routing entry >>>>>>> is added manually, I see the following happening: >>>>>>> >>>>>>> [ 2008/10/09 16:31:35 ERROR xorp_fea:15980 XRL +379 >>>>>>> xrl_pf_stcp.cc die ] STCPRequestHandler died: life timer expired >>>>>>> [ 2008/10/09 16:31:35 ERROR xorp_fea:15980 XRL +379 >>>>>>> xrl_pf_stcp.cc die ] STCPRequestHandler died: life timer expired >>>>>> This issue is probably independent from the routing table >>>>>> cleanup, >>>>>> hence please submit a Bugzilla entry. >>>>>> >>>>>> Thanks, >>>>>> Pavlin >>>>>> >>>>>>> And also, I forgot to give the following information... I'm >>>>>>> using the latest xorp build from cvs, and this is openbsd 4.3. >>>>> _______________________________________________ >>>>> Xorp-users mailing list >>>>> Xorp-users at xorp.org >>>>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users >>>> _______________________________________________ >>>> Xorp-users mailing list >>>> Xorp-users at xorp.org >>>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users >>> >> >> _______________________________________________ >> Xorp-users mailing list >> Xorp-users at xorp.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20081013/81a32740/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20081013/81a32740/attachment-0001.bin From pavlin at ICSI.Berkeley.EDU Tue Oct 14 10:23:44 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Tue, 14 Oct 2008 10:23:44 -0700 Subject: [Xorp-users] xorp clearing routing table upon startup In-Reply-To: <3A63B5A6-515E-486C-84BA-09CE5993787A@owns.com> References: <48EE93B7.8020607@owns.com> <48EE9681.1060001@owns.com> <200810100319.m9A3JYgc029228@fruitcake.ICSI.Berkeley.EDU> <48EFA10D.6070502@owns.com> <200810102121.m9ALKq9F006307@fruitcake.ICSI.Berkeley.EDU> <200810130305.m9D35B2f017031@fruitcake.ICSI.Berkeley.EDU> <48F39DA2.6080109@owns.com> <200810132124.m9DLOQqW027375@fruitcake.ICSI.Berkeley.EDU> <3A63B5A6-515E-486C-84BA-09CE5993787A@owns.com> Message-ID: <200810141723.m9EHNipB000887@fruitcake.ICSI.Berkeley.EDU> Stegen Smith wrote: > Hi Pavlin, > > Ooops... my head must have been in the wrong place in the previous email, > then. I should have said, even though my grep was wrong (the grep would not > have caught an entry for the 10.5.49 network), the routes are still NOT > showing up in the routing table. I see the 10.3.48.0/20 and 10.5.49.0/24 > networks in bgp, but not in the systems routing table. Could you clarify whether you see the BGP routes in the RIB table. Also, could you double-check that the next-hop routers 10.3.14.39 and 10.3.14.7 are resolved (e.g., they are directly connected or there is a static route or OSPR/RIP router to them). If the answer of the second question is yes, then you need to interact with the BGP folks to solve the issue. Pavlin > I'll submit another bug entry about the segfaults and we can figure out where > to go after the other issue. > > thanks and sorry for the lack of clarity there > > stegen > On Oct 13, 2008, at 2:24 PM, Pavlin Radoslavov wrote: > > > Stegen Smith wrote: > > > >> Hi Pavlin, > >> > >> Thanks for the update! I've grabbed the latest source from CVS and got it > >> up. I'm no longer seeing > >> those errors that I submitted the bug for; however, it does not seem that > >> the latter issue of the > >> routing table not being updated from bgp is resolved. > > > > OK, according to a later email on the subject this issue has been > > resolved. However, the segmentation fault you get during a shutdown > > seems like a real issue. Please submit another Bugzilla entry about > > it. > > > > Thanks, > > Pavlin > > > >> I can do the following: > >> xorp at at-ig1.sv> show bgp routes > >> Status Codes: * valid route, > best route > >> Origin Codes: i IGP, e EGP, ? incomplete > >> > >> Prefix Nexthop Peer AS Path > >> ------ ------- ---- ------- > >> * 10.3.48.0/20 10.3.14.7 10.3.14.99 65000 i > >> * 10.3.48.0/20 10.3.14.39 10.3.14.99 65000 i > >> * 10.5.49.0/24 10.3.14.39 10.3.14.99 65000 i > >> * 10.5.49.0/24 10.3.14.7 10.3.14.99 65000 i > >> xorp at at-ig1.sv> > >> > >> root0p7at-ig1.sv/usr/local/xorp netstat -nr|egrep "^10.[3,5].48" > >> root1p7at-ig1.sv/usr/local/xorp > >> > >> Also, when I ^C out of xorp_rtrmgr, it still does not shut down so cleanly: > >> ^C[ 2008/10/13 12:22:31 INFO xorp_rtrmgr:351 RTRMGR +1024 task.cc > >> shutdown ] Shutting down module: bgp > >> [ 2008/10/13 12:22:31 INFO xorp_bgp:15136 BGP +451 peer.cc > >> send_notification ] Sending: > >> Notification Packet: Cease(6) > >> [ 2008/10/13 12:22:31 TRACE xorp_bgp:15136 BGP +456 peer.cc > >> send_notification ] Peer > >> {10.3.14.40(179) 10.3.14.39(179)}: Send: Notification Packet: Cease(6) > >> [ 2008/10/13 12:22:31 TRACE xorp_bgp:15136 BGP +2062 peer.cc set_state ] > >> Peer {10.3.14.40(179) > >> 10.3.14.39(179)}: Previous state: ESTABLISHED(6) Current state: STOPPED(7) > >> [ 2008/10/13 12:22:31 INFO xorp_bgp:15136 BGP +451 peer.cc > >> send_notification ] Sending: > >> Notification Packet: Cease(6) > >> [ 2008/10/13 12:22:31 TRACE xorp_bgp:15136 BGP +456 peer.cc > >> send_notification ] Peer > >> {10.3.14.8(179) 10.3.14.7(179)}: Send: Notification Packet: Cease(6) > >> [ 2008/10/13 12:22:31 TRACE xorp_bgp:15136 BGP +2062 peer.cc set_state ] > >> Peer {10.3.14.8(179) > >> 10.3.14.7(179)}: Previous state: ESTABLISHED(6) Current state: STOPPED(7) > >> [ 2008/10/13 12:22:31 TRACE xorp_bgp:15136 BGP +2062 peer.cc set_state ] > >> Peer {10.3.14.8(179) > >> 10.3.14.7(179)}: Previous state: STOPPED(7) Current state: IDLE(1) > >> [ 2008/10/13 12:22:31 TRACE xorp_bgp:15136 BGP +2062 peer.cc set_state ] > >> Peer {10.3.14.40(179) > >> 10.3.14.39(179)}: Previous state: STOPPED(7) Current state: IDLE(1) > >> [ 2008/10/13 12:22:31 INFO xorp_bgp:15136 BGP +149 bgp.cc BGPMain ] > >> EVENT: timers 4 > >> [ 2008/10/13 12:22:31 INFO xorp_bgp:15136 BGP +161 bgp.cc BGPMain ] xrl > >> router still has pending > >> operations > >> [ 2008/10/13 12:22:31 INFO xorp_bgp:15136 BGP +167 bgp.cc BGPMain ] xrl > >> router no more pending > >> operations > >> [ 2008/10/13 12:22:31 ERROR xorp_rib:30518 LIBXORP +222 > >> buffered_asyncio.cc io_event ] read error 54 > >> [ 2008/10/13 12:22:31 ERROR xorp_rib:30518 XRL +169 xrl_pf_stcp.cc > >> read_event ] Read failed (error > >> = 54) > >> [ 2008/10/13 12:22:31 ERROR xorp_rib:30518 XRL +378 xrl_pf_stcp.cc die ] > >> STCPRequestHandler died: > >> read error > >> [ 2008/10/13 12:22:31 INFO xorp_rtrmgr:351 RTRMGR +280 module_manager.cc > >> module_exited ] Module > >> normal exit: bgp > >> [ 2008/10/13 12:22:31 INFO xorp_rib RIB ] Received death event for > >> protocol bgp shutting down ------- > >> OriginTable: ebgp > >> EGP > >> next table = Merged:(ebgp)+(ibgp) > >> [ 2008/10/13 12:22:31 INFO xorp_rib RIB ] Received death event for > >> protocol bgp shutting down ------- > >> OriginTable: ebgp > >> EGP > >> next table = Merged:(ebgp)+(ibgp) > >> [ 2008/10/13 12:22:32 WARNING xorp_rtrmgr:351 XrlFinderTarget +407 > >> ../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 "bgp" does not exist or is not enabled. > >> [ 2008/10/13 12:22:33 INFO xorp_rtrmgr:351 RTRMGR +1024 task.cc shutdown > >> ] Shutting down module: policy > >> [ 2008/10/13 12:22:33 INFO xorp_rtrmgr:351 XRL +432 xrl_router.cc > >> get_sender ] Sender died > >> (protocol = "stcp", address = "127.0.0.1:11045") > >> [ 2008/10/13 12:22:33 ERROR xorp_rtrmgr:351 LIBCOMM +610 comm_sock.c > >> comm_sock_connect4 ] Error > >> connecting socket (family = 2, remote_addr = 127.0.0.1, remote_port = > >> 11045): Connection refused > >> [ 2008/10/13 12:22:33 ERROR xorp_rtrmgr:351 XRL +63 xrl_pf_factory.cc > >> create_sender ] > >> XrlPFSenderFactory::create failed: XrlPFConstructorError from line 667 of > >> xrl_pf_stcp.cc: Could not > >> connect to 127.0.0.1:11045 > >> > >> [ 2008/10/13 12:22:33 ERROR xorp_rtrmgr:351 XRL +451 xrl_router.cc > >> get_sender ] Could not create > >> XrlPFSender for protocol = "stcp" address = "127.0.0.1:11045" > >> [1] 351 segmentation fault (core dumped) ./bin/xorp_rtrmgr > >> > >> Let me know what you would like me to do next =) > >> > >> thanks! > >> stegen > >> > >> Pavlin Radoslavov wrote: > >>> Pavlin Radoslavov wrote: > >>> > >>>> Stegen Smith wrote: > >>>> > >>>>> Hi Pavlin, > >>>>> > >>>>> Yeah, it seems to occur when things sit idly. Ultimately something > >>>>> gums up the works and I get > >>>>> those error messages, so it's not only when I modified the routing > >>>>> table myself. It should be > >>>>> easily recreated. Odd... So with that, I'll get one submitted right > >>>>> away with more detailed > >>>>> information. > >>>> I just saw the entry in Bugzilla. Thanks! > >>>> > >>>> The missing routes might be related to the XRL errors. > >>>> The "life timer expired" indicates that the XRL communication has > >>>> timed-out, and after that all bets are off. > >>>> BTW, this particular timeout shouldn't happen under (very relaxed) > >>>> normal circumstances, so there is something else happening. > >>>> This probably also explains the shutdown problem with the leftover > >>>> XORP processes. > >>>> > >>>> Re. the shutdown question: yes, if you are running XORP in > >>>> foreground, Ctrl-C should be the way to stop it. > >>>> > >>>> I (or somebody else) should look at this problem very soon, because > >>>> it looks critical. > >>> > >>> The problem is fixed in CVS: > >>> > >>> Revision Changes Path > >>> 1.25 +9 -8; commitid: 7b5a48f2abbc41a7; xorp/libxipc/ test_stcp.cc > >>> 1.72 +18 -20; commitid: 7b5a48f2abbc41a7; xorp/libxipc/ > >>> xrl_pf_stcp.cc > >>> 1.36 +4 -4; commitid: 7b5a48f2abbc41a7; xorp/libxipc/ > >>> xrl_pf_stcp.hh > >>> > >>> Please checkout the latest code from CVS and verify whether it fixes > >>> the problems on your side. > >>> > >>> Pavlin > >>> > >>>> Pavlin > >>>> > >>>>> Another note... I've got bgp peering setup and I see the following: > >>>>> xorp at at-ig1.sv.atomz.com> show bgp routes > >>>>> Status Codes: * valid route, > best route > >>>>> Origin Codes: i IGP, e EGP, ? incomplete > >>>>> > >>>>> Prefix Nexthop Peer AS > >>>>> Path > >>>>> ------ ------- ---- > >>>>> ------- > >>>>> * 10.3.48.0/20 10.3.14.39 10.3.14.99 65000 > >>>>> i > >>>>> * 10.5.49.0/24 10.3.14.39 10.3.14.99 65000 > >>>>> i > >>>>> * 10.3.48.0/20 10.3.14.7 10.3.14.99 65000 > >>>>> i > >>>>> * 10.5.49.0/24 10.3.14.7 10.3.14.99 65000 > >>>>> i > >>>>> > >>>>> yet no routes are inserted on the system: > >>>>> root1paat-ig1.sv~ netstat -nr|grep 10.3.48 > >>>>> root1paat-ig1.sv~ > >>>>> > >>>>> I'm guessing that this is another bug, or perhaps related to the first > >>>>> issue I've noticed. I'll > >>>>> submit a bug for the first one, and if you would like me to do the same > >>>>> for this issue I'm seeing, > >>>>> let me know. =) > >>>>> > >>>>> And one more side note... what's the cleanest way to shutdown the > >>>>> routing software? I've been > >>>>> letting xorp_rtrmgr run in the foreground while I do testing, and ^C > >>>>> when I want to quit out. > >>>>> Probably not the best way to do it, as it ends up crashing (cores) and > >>>>> leaving other xorp processes > >>>>> up and running: > >>>>> > >>>>> ^C[ 2008/10/10 11:13:26 INFO xorp_rtrmgr:8398 RTRMGR +1024 task.cc > >>>>> shutdown ] Shutting down module: bgp > >>>>> [ 2008/10/10 11:13:26 INFO xorp_bgp:18890 BGP +451 peer.cc > >>>>> send_notification ] Sending: > >>>>> Notification Packet: Cease(6) > >>>>> [ 2008/10/10 11:13:26 TRACE xorp_bgp:18890 BGP +456 peer.cc > >>>>> send_notification ] Peer > >>>>> {10.3.14.40(179) 10.3.14.39(179)}: Send: Notification Packet: Cease(6) > >>>>> > >>>>> > >>>>> > >>>>> [ 2008/10/10 11:13:28 INFO xorp_rtrmgr:8398 XRL +432 xrl_router.cc > >>>>> get_sender ] Sender died > >>>>> (protocol = "stcp", address = "127.0.0.1:11810") > >>>>> [ 2008/10/10 11:13:28 ERROR xorp_rtrmgr:8398 LIBCOMM +610 comm_sock.c > >>>>> comm_sock_connect4 ] Error > >>>>> connecting socket (family = 2, remote_addr = 127.0.0.1, remote_port = > >>>>> 11810): Connection refused > >>>>> [ 2008/10/10 11:13:28 ERROR xorp_rtrmgr:8398 XRL +63 xrl_pf_factory.cc > >>>>> create_sender ] > >>>>> XrlPFSenderFactory::create failed: XrlPFConstructorError from line 668 > >>>>> of xrl_pf_stcp.cc: Could not > >>>>> connect to 127.0.0.1:11810 > >>>>> > >>>>> [ 2008/10/10 11:13:28 ERROR xorp_rtrmgr:8398 XRL +451 xrl_router.cc > >>>>> get_sender ] Could not create > >>>>> XrlPFSender for protocol = "stcp" address = "127.0.0.1:11810" > >>>>> [1] 8398 segmentation fault (core dumped) ./bin/xorp_rtrmgr > >>>>> root139p9at-ig1.sv/usr/local/xorp > >>>>> root139p9at-ig1.sv/usr/local/xorp ps auxww|grep xorp > >>>>> xorp 20544 0.0 0.1 3516 5484 p1 I+ 5:21PM 0:00.35 > >>>>> /usr/local/xorp/bin/xorpsh > >>>>> root 2811 0.0 0.2 5076 6476 p9 S 11:09AM 0:00.75 > >>>>> xorp_fea > >>>>> root 17533 0.0 0.1 2812 4452 p9 S 11:10AM 0:00.22 > >>>>> xorp_rib > >>>>> root 16731 0.0 0.1 2188 3872 p9 I 11:10AM 0:00.18 > >>>>> xorp_fib2mrib > >>>>> root 9111 0.0 0.1 2728 4268 p9 S 11:10AM 0:00.20 > >>>>> xorp_igmp > >>>>> root 32406 0.0 0.1 4752 6028 p9 S 11:10AM 0:00.50 > >>>>> xorp_pimsm4 > >>>>> root 4331 0.0 0.0 848 692 p9 R+/1 11:16AM 0:00.00 grep > >>>>> xorp (zsh) > >>>>> root0p9at-ig1.sv/usr/local/xorp > >>>>> > >>>>> I'm just working hard at keeping you guys busy ;) > >>>>> > >>>>> thanks, > >>>>> stegen > >>>>> > >>>>> Pavlin Radoslavov wrote: > >>>>>> Stegen Smith wrote: > >>>>>> > >>>>>>> Also an interesting thing to note is that if a routing entry is added > >>>>>>> manually, I see the following happening: > >>>>>>> > >>>>>>> [ 2008/10/09 16:31:35 ERROR xorp_fea:15980 XRL +379 xrl_pf_stcp.cc > >>>>>>> die ] STCPRequestHandler died: life timer expired > >>>>>>> [ 2008/10/09 16:31:35 ERROR xorp_fea:15980 XRL +379 xrl_pf_stcp.cc > >>>>>>> die ] STCPRequestHandler died: life timer expired > >>>>>> This issue is probably independent from the routing table cleanup, > >>>>>> hence please submit a Bugzilla entry. > >>>>>> > >>>>>> Thanks, > >>>>>> Pavlin > >>>>>> > >>>>>>> And also, I forgot to give the following information... I'm using the > >>>>>>> latest xorp build from cvs, and this is openbsd 4.3. > >>>>> _______________________________________________ > >>>>> Xorp-users mailing list > >>>>> Xorp-users at xorp.org > >>>>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > >>>> _______________________________________________ > >>>> Xorp-users mailing list > >>>> Xorp-users at xorp.org > >>>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > >>> > >> > >> _______________________________________________ > >> Xorp-users mailing list > >> Xorp-users at xorp.org > >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at ICSI.Berkeley.EDU Tue Oct 14 10:53:52 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Tue, 14 Oct 2008 10:53:52 -0700 Subject: [Xorp-users] IGMP and PIM-SSM problem In-Reply-To: <48F43A83.7000302@gmail.com> References: <48F34D94.2070201@gmail.com> <200810131753.m9DHrppg004342@fruitcake.ICSI.Berkeley.EDU> <48F43A83.7000302@gmail.com> Message-ID: <200810141753.m9EHrqP0005353@fruitcake.ICSI.Berkeley.EDU> > > The sender 192.168.14.14 is directly connected to both PC-A and > > PC-B. > If I change the IP address of source in IGMP report i.e. if 192.168.14.14 is > changed to 11.22.33.44 then it is not directly connected to both PCs. Is there > any other modifications required to prove that source is not directly > connected? The IGMP reports are used by the receivers to indicate they want to join a multicast group (or source-group in case of SSM) so they won't affect the senders. If you change the IP address of the sender so it doesn't belong to the XORP subnets, and the sender is still connected to the same LAN, then yes, from XORP perspective it won't be considered directly connected. However, XORP still won't send PIM-SM Join message toward the sender, because the Join message will be sent to a directly connected PIM-SM router that is the next-hop (from MRIB perspective) toward the sender. Just curious, why do you want to force XORP to send PIM-SM Join message toward the directly connected sender, when from protocol perspective it is not necessary? Typically, the multicast sender starts transmitting even if there are no receivers, and the directly connected PIM-SM routers will forward the traffic only if there are downstream receivers. > > Hence, the PIM-SM router connected to it will NOT > > send PIM-SM Join message toward it. PIM-SM Join messages are only > > sent to PIM-SM routers toward the sender (or the RP), and only if > > the sender (or the RP) is not directly connected. > > > > Pavlin > > > Can you provide me the reference in RFC for this particular statement because > I am not aware of this rule. The above statement is a summary of the following PIM-SM rules: * PIM-SM Join messages are sent only to PIM-SM neighbors, which by definition are directly connected. * PIM-SM Join messages are sent on the RPF (Reverse Path Forwarding) toward the RP or the sender (depends on the type of the Join). * The PIM-SM (S,G) Join message is not propagated further once it reaches a PIM-SM router that already has (S,G) Join state or the PIM-SM router that is directly connected to the sender. All that information is in RFC 4601 (the PIM-SM spec). Within the context of directly-connected sources, the following statement from the spec is important: The function MRIB.next_hop( S ) returns an address of the next-hop PIM neighbor toward the host S, as indicated by the current MRIB. If S is directly adjacent, then MRIB.next_hop( S ) returns NULL. Hope that helps, Pavlin From jjajal at gmail.com Wed Oct 15 07:14:27 2008 From: jjajal at gmail.com (Jigar) Date: Wed, 15 Oct 2008 19:44:27 +0530 Subject: [Xorp-users] IGMP and PIM-SSM problem Message-ID: <48F5FAC3.2060302@gmail.com> Pavlin, Thanks for your kind reply. I think, I blundered in explaining the setup and the scenario which I want to create. Just scrap the previous one and start with the scratch. Actually, I want to test the following scenario given in RFC-4601 (PIM-SM) in section 4.5.7 (Sending (S,G) Join/Prune Messages) ######################################################### Transitions from NotJoined State When the upstream (S,G) state machine is in NotJoined state, the following event may trigger a state transition: JoinDesired(S,G) becomes True The macro JoinDesired(S,G) becomes True, e.g., because the downstream state for (S,G) has changed so that at least one interface is in inherited_olist(S,G). The upstream (S,G) state machine transitions to Joined state. Send Join(S,G) to the appropriate upstream neighbor, which is RPF'(S,G). Set the Join Timer (JT) to expire after t_periodic seconds. ########################################################## To generate above scenario, I have used setup as mentioned below. IP address: host A (eth0): 10.100.3.220/24 (IGMPv3 source specific join report sender) host B (eth1): 10.100.3.107/24 (PIM-SM downstream interface) host B (eth0): 192.168.14.212/24 (PIM-SM uptream interface) host C (eth0): 192.168.14.211/24 (configured as static RP on host B) Brief Information about setup: - All machines (host A, host B, and host C) are running RHEL4 (kernel-2.6.9). - host A and host C can be treated as packet generator. - host B is running xorp (1.4) with attached configuration (config.boot.pim-sm.cfg) - On host B, i configured host C as static RP for all group (pls see attached config file). - Test generates scenario such that host A becomes IGMP host (as receiver), host B becomes DR (of PIM-SM RPT), and host C becomes RP (of PIM-SM RPT). Steps followed in test: - host C sends PIM-SM hello packet with hold time as 0xffff (infinity) using packet generator utility. So host B assumes that RP is directly connect on its interface eth0. Also it ensures that RP remains always alive. - host A sends IGMPv3 source specific join report using attached application (igmpv3-join-generator.c). IGMP Join report is as following: Multicast Group address: 232.11.22.33 Mode: MCAST_INCLUDE No of sources in group: 1 Source address: 192.168.18.154 Expectation: - As per RFC, host B should generate PIM-SM join(S,G) (here S-192.168.18.154 G-232.11.22.33) message on eth0 (upstream interface) after receiving IGMPv3 source specific Join message on eth1 (downstream interface). But, I am not getting any PIM-SM join message on eth0 (upstream interface). Also, I have attached status of PIM-SM database on XORP. Can you pls guide me what is going wrong in this test scenario? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20081015/2b862fae/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 6218 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20081015/2b862fae/attachment.jpe -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: config.boot.pim-sm.cfg Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20081015/2b862fae/attachment.ksh -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: xorp-status.txt Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20081015/2b862fae/attachment.txt From pavlin at ICSI.Berkeley.EDU Wed Oct 15 10:22:12 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Wed, 15 Oct 2008 10:22:12 -0700 Subject: [Xorp-users] IGMP and PIM-SSM problem In-Reply-To: <48F5FAC3.2060302@gmail.com> References: <48F5FAC3.2060302@gmail.com> Message-ID: <200810151722.m9FHMCsG011144@fruitcake.ICSI.Berkeley.EDU> Jigar wrote: > I think, I blundered in explaining the setup and the scenario which I > want to > create. > Just scrap the previous one and start with the scratch. > > Actually, I want to test the following scenario given in RFC-4601 > (PIM-SM) in > section 4.5.7 (Sending (S,G) Join/Prune Messages) > > ######################################################### > Transitions from NotJoined State > When the upstream (S,G) state machine is in NotJoined state, the > following event may trigger a state transition: > JoinDesired(S,G) becomes True > The macro JoinDesired(S,G) becomes True, e.g., because the > downstream state for (S,G) has changed so that at least one > interface is in inherited_olist(S,G). > The upstream (S,G) state machine transitions to Joined state. > Send Join(S,G) to the appropriate upstream neighbor, which is > RPF'(S,G). Set the Join Timer (JT) to expire after t_periodic > seconds. > ########################################################## > > To generate above scenario, I have used setup as mentioned below. > > > > IP address: > host A (eth0): 10.100.3.220/24 (IGMPv3 source specific join report > sender) > host B (eth1): 10.100.3.107/24 (PIM-SM downstream interface) > host B (eth0): 192.168.14.212/24 (PIM-SM uptream interface) > host C (eth0): 192.168.14.211/24 (configured as static RP on host B) > > Brief Information about setup: > - All machines (host A, host B, and host C) are running RHEL4 > (kernel-2.6.9). > - host A and host C can be treated as packet generator. > - host B is running xorp (1.4) with attached configuration > (config.boot.pim-sm.cfg) > - On host B, i configured host C as static RP for all group (pls see > attached > config file). > - Test generates scenario such that > host A becomes IGMP host (as receiver), > host B becomes DR (of PIM-SM RPT), > and host C becomes RP (of PIM-SM RPT). > > Steps followed in test: > - host C sends PIM-SM hello packet with hold time as 0xffff (infinity) > using > packet generator utility. So host B assumes that RP is directly > connect on its > interface eth0. Also it ensures that RP remains always alive. > - host A sends IGMPv3 source specific join report using attached > application > (igmpv3-join-generator.c). > IGMP Join report is as following: > Multicast Group address: 232.11.22.33 > Mode: MCAST_INCLUDE > No of sources in group: 1 > Source address: 192.168.18.154 > > Expectation: > - As per RFC, host B should generate PIM-SM join(S,G) (here S-192.168.18.154 > G-232.11.22.33) message on eth0 (upstream interface) after receiving > IGMPv3 > source specific Join message on eth1 (downstream interface). > > But, I am not getting any PIM-SM join message on eth0 (upstream interface). > > Also, I have attached status of PIM-SM database on XORP. > > Can you pls guide me what is going wrong in this test scenario? Is the source address 192.168.18.158 or 192.168.18.154? In the above IGMP Join report it is 192.168.18.154, but in the "show pim join" output it is 192.168.18.158. In any case, the issue seems to be that the RPF'(S,G) toward the source is UNKNOWN: Upstream RPF'(S,G): UNKNOWN The reason it is UNKNOWN is because the MRIB (as seen by PIM-SM) doesn't seem to contain an entry that points toward the source: Upstream MRIB next hop (S): UNKNOWN The simplest thing to do is to install a static route for the source's subnet, say 192.168.18.0/24, and set host C (192.168.14.211) as the next-hop router toward that subnet. Pavlin P.S. In your particular setup you don't need the policy block. > > > --------------090900090503060700030800 > Content-Type: multipart/related; > boundary="------------050004070302010302040400" > > > --------------050004070302010302040400 > Content-Type: text/html; charset=ISO-8859-1 > Content-Transfer-Encoding: 7bit > > > > > > > Pavlin,
>
> Thanks for your kind reply.
>
> I think, I blundered in explaining the setup and the scenario which I > want to
> create.
> Just scrap the previous one and start with the scratch.
>
> Actually, I want to test the following scenario given in RFC-4601 > (PIM-SM) in
> section 4.5.7 (Sending (S,G) Join/Prune Messages)
>
> #########################################################
> Transitions from NotJoined State
>    When the upstream (S,G) state machine is in NotJoined state, the
>    following event may trigger a state transition:
>      JoinDesired(S,G) becomes True
>           The macro JoinDesired(S,G) becomes True, e.g., because the
>           downstream state for (S,G) has changed so that at least one
>           interface is in inherited_olist(S,G).
>           The upstream (S,G) state machine transitions to Joined state.
>           Send Join(S,G) to the appropriate upstream neighbor, which is
>           RPF'(S,G).  Set the Join Timer (JT) to expire after t_periodic
>           seconds.
> ##########################################################
>
> To generate above scenario, I have used setup as mentioned below.
>     
>   width="483">
>  
> IP address:
> host A (eth0): 10.100.3.220/24    (IGMPv3 source specific join report > sender)
> host B (eth1): 10.100.3.107/24    (PIM-SM downstream interface)
> host B (eth0): 192.168.14.212/24  (PIM-SM uptream interface)
> host C (eth0): 192.168.14.211/24  (configured as static RP on host B)
>
> Brief Information about setup:
> - All machines (host A, host B, and host C) are running RHEL4 > (kernel-2.6.9).
> - host A and host C can be treated as packet generator.
> - host B is running xorp (1.4) with attached configuration
>   (config.boot.pim-sm.cfg)
> - On host B, i configured host C as static RP for all group (pls see > attached
>   config file).
> - Test generates scenario such that
>   host A becomes IGMP host (as receiver),
>   host B becomes DR (of PIM-SM RPT),
>   and host C becomes RP (of PIM-SM RPT).
>  
> Steps followed in test:
> - host C sends PIM-SM hello packet with hold time as 0xffff (infinity) > using
>   packet generator utility. So host B assumes that RP is directly > connect on its
>   interface eth0. Also it ensures that RP remains always alive.
> - host A sends IGMPv3 source specific join report using attached > application
>   (igmpv3-join-generator.c).
>   IGMP Join report is as following:
>    Multicast Group address: 232.11.22.33
>    Mode: MCAST_INCLUDE
>    No of sources in group: 1
>    Source address: 192.168.18.154
>
> Expectation:
> - As per RFC, host B should generate PIM-SM join(S,G) (here > S-192.168.18.154
>    G-232.11.22.33) message on eth0 (upstream interface) after receiving > IGMPv3
>    source specific Join message on eth1 (downstream interface).
>  
> But, I am not getting any PIM-SM join message on eth0 (upstream > interface).
>
> Also, I have attached status of PIM-SM database on XORP.
>
> Can you pls guide me what is going wrong in this test scenario?
>
>
> > > > > --------------050004070302010302040400 > Content-Type: image/jpeg > Content-Transfer-Encoding: base64 > Content-ID: > > /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof > Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwh > MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAAR > CABxAeMDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA > AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK > FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG > h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl > 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA > AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk > NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE > hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk > 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iis/U4dYl8r+yb6xtcZ8z7XZvcbumMb > ZUx365zkdMcgGhRXP/Y/GH/Qd0P/AME03/yVR9j8Yf8AQd0P/wAE03/yVQB0FFc/9j8Yf9B3 > Q/8AwTTf/JVH2Pxh/wBB3Q//AATTf/JVAHQUVz/2Pxh/0HdD/wDBNN/8lUfY/GH/AEHdD/8A > BNN/8lUAdBRXP/Y/GH/Qd0P/AME03/yVWhpkOsReb/a19Y3WceX9ks3t9vXOd0r57dMYweue > ADQooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACis/U4dYl8r+yb6xtcZ8z7XZvcb > umMbZUx365zkdMc5/wBj8Yf9B3Q//BNN/wDJVAHQUVz/ANj8Yf8AQd0P/wAE03/yVR9j8Yf9 > B3Q//BNN/wDJVAHQUVz/ANj8Yf8AQd0P/wAE03/yVR9j8Yf9B3Q//BNN/wDJVAHQUVz/ANj8 > Yf8AQd0P/wAE03/yVR9j8Yf9B3Q//BNN/wDJVAHQUVn6ZDrEXm/2tfWN1nHl/ZLN7fb1zndK > +e3TGMHrnjQoAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACis/U4dYl8r+yb6xtcZ8z7 > XZvcbumMbZUx365zkdMc5/2Pxh/0HdD/APBNN/8AJVAHQUVz/wBj8Yf9B3Q//BNN/wDJVH2P > xh/0HdD/APBNN/8AJVAHQUVz/wBj8Yf9B3Q//BNN/wDJVH2Pxh/0HdD/APBNN/8AJVAHQUVz > /wBj8Yf9B3Q//BNN/wDJVH2Pxh/0HdD/APBNN/8AJVAHQUVn6ZDrEXm/2tfWN1nHl/ZLN7fb > 1zndK+e3TGMHrnjQoAKKKKAOf8d/8k88S/8AYKuv/RTV0FV7+xt9T065sLyPzLW6ieGZNxG5 > GBDDI5GQT0qxQAUUUUAFFFFABRRRQAVz/jv/AJJ54l/7BV1/6Kaugqvf2NvqenXNheR+Za3U > TwzJuI3IwIYZHIyCelAHP+OtU1HS9JtH0+5gs1muxFcXk8ywpbx+W7bjI0cipl1RMsjA79ow > WBHPvqGraj4Ee5/4SiB2ttVtt9/pF5FcFbfzYvN86QQqg2qzucIoCKu7cN+70iigDzvxVqel > S+BrO5XX7S9NvrFl9m1a/WMoZRcxsXUoI0cKhcExkcK4JBDYr3WsWV9cNpesaraajpek679n > 1Ca7aLYYTZO6m5CgRgC4bYMqBujUcuMn0yigDl/Bf2PZrX9leR/Y39oD+z/suPs/l/Z4d/lb > fl2+b5udvG/f3zXUUUUAFFFFABRRRQAVy/jrVNR0vSbR9PuYLNZrsRXF5PMsKW8flu24yNHI > qZdUTLIwO/aMFgR1FFAHm76hq2o+BHuf+EogdrbVbbff6ReRXBW382LzfOkEKoNqs7nCKAir > u3Dfuk8VanpUvgazuV1+0vTb6xZfZtWv1jKGUXMbF1KCNHCoXBMZHCuCQQ2PRKKAOLsNa027 > svEem6x4ijkt9JvUt5b03q2soUpGwMkkJQIfNaSPgLnZtOSGzl2t/Z337PU/2O7guPI8NNBN > 5Mgfy5FtPmRsdGGRkHkV6RVe/sbfU9OubC8j8y1uonhmTcRuRgQwyORkE9KALFFFFABRRRQA > UUUUAFFFFAHP+O/+SeeJf+wVdf8Aopqr+OtU1HS9JtH0+5gs1muxFcXk8ywpbx+W7bjI0cip > l1RMsjA79owWBHQX9jb6np1zYXkfmWt1E8MybiNyMCGGRyMgnpVigDzd9Q1bUfAj3P8AwlED > tbarbb7/AEi8iuCtv5sXm+dIIVQbVZ3OEUBFXduG/dJ4q1PSpfA1ncrr9pem31iy+zatfrGU > MouY2LqUEaOFQuCYyOFcEghseiUUAeZ3WsWV9cNpesaraajpek679n1Ca7aLYYTZO6m5CgRg > C4bYMqBujUcuMnpPBf2PZrX9leR/Y39oD+z/ALLj7P5f2eHf5W35dvm+bnbxv39811FFABRR > RQAUUUUAFcv461TUdL0m0fT7mCzWa7EVxeTzLClvH5btuMjRyKmXVEyyMDv2jBYEdRRQB5u+ > oatqPgR7n/hKIHa21W233+kXkVwVt/Ni83zpBCqDarO5wigIq7tw37pPFWp6VL4Gs7ldftL0 > 2+sWX2bVr9YyhlFzGxdSgjRwqFwTGRwrgkENj0SigDzO61iyvrhtL1jVbTUdL0nXfs+oTXbR > bDCbJ3U3IUCMAXDbBlQN0ajlxkyT/Y/+Fc+P/wCyvI/sbyrn+z/suPs/l/Yo9/lbfl2+b5ud > vG/f3zXpFV7+xt9T065sLyPzLW6ieGZNxG5GBDDI5GQT0oAsUUUUAFFFFABRRRQAUUUUAc/4 > 7/5J54l/7BV1/wCimroKr39jb6np1zYXkfmWt1E8MybiNyMCGGRyMgnpVigAooooA5/x3/yT > zxL/ANgq6/8ARTV0FV7+xt9T065sLyPzLW6ieGZNxG5GBDDI5GQT0qxQAUUUUAFFFFABRRRQ > AVz/AI7/AOSeeJf+wVdf+imroKr39jb6np1zYXkfmWt1E8MybiNyMCGGRyMgnpQBYorP1OHW > JfK/sm+sbXGfM+12b3G7pjG2VMd+uc5HTHOf9j8Yf9B3Q/8AwTTf/JVAHQUVz/2Pxh/0HdD/ > APBNN/8AJVH2Pxh/0HdD/wDBNN/8lUAdBRXP/Y/GH/Qd0P8A8E03/wAlUfY/GH/Qd0P/AME0 > 3/yVQB0FFc/9j8Yf9B3Q/wDwTTf/ACVR9j8Yf9B3Q/8AwTTf/JVAHQUVz/2Pxh/0HdD/APBN > N/8AJVH2Pxh/0HdD/wDBNN/8lUAdBRXP/Y/GH/Qd0P8A8E03/wAlUfY/GH/Qd0P/AME03/yV > QB0FFc/9j8Yf9B3Q/wDwTTf/ACVR9j8Yf9B3Q/8AwTTf/JVAHQVz/jv/AJJ54l/7BV1/6Kaj > 7H4w/wCg7of/AIJpv/kqrEWmX99p19YeIbqxv7W7iMJS0tJLb5GBDgkyuTkHttxz+ABsUUUU > Acv4/wD+Eb/4Rd/+En8j7L5qfZ/N8vd9oz+72eZ8m7OfvfJt3b/k3Vy9h/Y/2W4z9h+0f2qf > +Ex+z7Nn+qk+9t5+z+Z5fX+HzPN58+vUKKAPI/E50FdCu2s49Gk8NC90s6ekzolk119pP2gR > tggJ5W3eUBUfveC3mUa7Hpth4MvbTVrLRrKWPXbKWHR7mRVtbZTLEv7timPKkSOeQsqcB5gQ > SrivXKKAMPwvo82j2VzHLBaWiT3BlisbJi0FouxF2RnavBZWkOFX5pG4P3juUUUAc/47/wCS > eeJf+wVdf+imroKr39jb6np1zYXkfmWt1E8MybiNyMCGGRyMgnpVfU4dYl8r+yb6xtcZ8z7X > ZvcbumMbZUx365zkdMcgGhRXP/Y/GH/Qd0P/AME03/yVR9j8Yf8AQd0P/wAE03/yVQB0FFc/ > 9j8Yf9B3Q/8AwTTf/JVH2Pxh/wBB3Q//AATTf/JVAHQUVz/2Pxh/0HdD/wDBNN/8lUfY/GH/ > AEHdD/8ABNN/8lUAdBRXP/Y/GH/Qd0P/AME03/yVR9j8Yf8AQd0P/wAE03/yVQB0FFc/9j8Y > f9B3Q/8AwTTf/JVH2Pxh/wBB3Q//AATTf/JVAHQUVz/2Pxh/0HdD/wDBNN/8lUfY/GH/AEHd > D/8ABNN/8lUAdBXP+O/+SeeJf+wVdf8AopqPsfjD/oO6H/4Jpv8A5KqxFpl/fadfWHiG6sb+ > 1u4jCUtLSS2+RgQ4JMrk5B7bcc/gAbFFFFABRRRQAUUUUAFFFFAHP+O/+SeeJf8AsFXX/opq > 6Cq9/Y2+p6dc2F5H5lrdRPDMm4jcjAhhkcjIJ6VYoAKKKKAOf8d/8k88S/8AYKuv/RTV0FV7 > +xt9T065sLyPzLW6ieGZNxG5GBDDI5GQT0qxQAUUUUAFFFFABRRRQAVz/jv/AJJ54l/7BV1/ > 6Kaugqvf2NvqenXNheR+Za3UTwzJuI3IwIYZHIyCelAFiiiigAooooAKKKKACiiigAooooAK > KKKACiiigArn/Hf/ACTzxL/2Crr/ANFNXQVXv7G31PTrmwvI/MtbqJ4Zk3EbkYEMMjkZBPSg > CxXL+PdXl0TQbe7g1mDSpjqFrEJbgI0bq8qq6uGxlQhdztZWwmdwANdRRQBx93eTW3hW31TT > fFE+p266hbyS3p+zOjW3nJHMrNHGFEap5jFhgrtJLYBFc/feNSNO1qa18WwQtbeILSK1lukh > 2G2mEJIZSFLw4adlcEFljyHIBJ9QooA8z1LxfJZaXqlvF4utEu9K120shdXJgYyxyeVvEygK > MLvnB2eWcQHkFXJ2LDX7eay8R2F34sjh/si9S3bUzLbLKiskbZkynlA+Y0kX3B9zH3gTXaUU > AeZjxZFH8JvDupWHiLTbG4V9OtppFEJgV28sSxOgwFCozMUUoVCcFQDVhvFMim90xvEsYhsN > YFleasWg823hNsZQ8h2+UhM4MOSgHG3G/wCavRKr31lFqFnJazPOkb4yYJ3hcYIPDoQw6djz > 06UAedy6jd6p4C+Ick+sSanbW9vPbWkht0iUxCzRw4woLFjISXzsbAZAqkCvTKy08PaYmjXe > kmCSS0vEdLnzZ5JJJg67W3yMxdjtwoJbIAAGABjUoAKKKKACiiigAooooAKKKKACiiigAooo > oAK5/wAd/wDJPPEv/YKuv/RTV0FV7+xt9T065sLyPzLW6ieGZNxG5GBDDI5GQT0oAsUUUUAF > FFFABRRRQAUUUUAc/wCO/wDknniX/sFXX/opq6Cq9/Y2+p6dc2F5H5lrdRPDMm4jcjAhhkcj > IJ6VYoAKKKKAOf8AHf8AyTzxL/2Crr/0U1dBVe/sbfU9OubC8j8y1uonhmTcRuRgQwyORkE9 > Kr6nDrEvlf2TfWNrjPmfa7N7jd0xjbKmO/XOcjpjkA0KK5/7H4w/6Duh/wDgmm/+SqPsfjD/ > AKDuh/8Agmm/+SqAOgorn/sfjD/oO6H/AOCab/5Ko+x+MP8AoO6H/wCCab/5KoA6Ciuf+x+M > P+g7of8A4Jpv/kqj7H4w/wCg7of/AIJpv/kqgDoK5/x3/wAk88S/9gq6/wDRTUfY/GH/AEHd > D/8ABNN/8lVYi0y/vtOvrDxDdWN/a3cRhKWlpJbfIwIcEmVycg9tuOfwANiiiigAooooAKKK > KACiiigAooooAKKKKACiiigArn/Hf/JPPEv/AGCrr/0U1dBVe/sbfU9OubC8j8y1uonhmTcR > uRgQwyORkE9KALFFZ+pw6xL5X9k31ja4z5n2uze43dMY2ypjv1znI6Y5z/sfjD/oO6H/AOCa > b/5KoA6Ciuf+x+MP+g7of/gmm/8Akqj7H4w/6Duh/wDgmm/+SqAOgorn/sfjD/oO6H/4Jpv/ > AJKo+x+MP+g7of8A4Jpv/kqgDoKK5/7H4w/6Duh/+Cab/wCSqPsfjD/oO6H/AOCab/5KoAPH > f/JPPEv/AGCrr/0U1dBWPFpl/fadfWHiG6sb+1u4jCUtLSS2+RgQ4JMrk5B7bcc/hsUAFFFF > ABRRRQAUUUUAFFFFABRRRQAUUUUAFc/47/5J54l/7BV1/wCimroKr39jb6np1zYXkfmWt1E8 > MybiNyMCGGRyMgnpQBYorP1OHWJfK/sm+sbXGfM+12b3G7pjG2VMd+uc5HTHOf8AY/GH/Qd0 > P/wTTf8AyVQB0FFc/wDY/GH/AEHdD/8ABNN/8lUfY/GH/Qd0P/wTTf8AyVQB0FFc/wDY/GH/ > AEHdD/8ABNN/8lUfY/GH/Qd0P/wTTf8AyVQB0FFc/wDY/GH/AEHdD/8ABNN/8lUfY/GH/Qd0 > P/wTTf8AyVQAeO/+SeeJf+wVdf8Aopq6CseLTL++06+sPEN1Y39rdxGEpaWklt8jAhwSZXJy > D2245/DYoAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo > oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC > iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA4/4kzWdv4atZ7m5sbWaPVbF7We9AKR > SC4QlsEr0TeTgg7Q3IGTWW3imRTe6Y3iWMQ2GsCyvNWLQebbwm2MoeQ7fKQmcGHJQDjbjf8A > NXolFAHndz4mni8OXLR+KLRYTqYtbDV7qSKNbtPIWVsTLE0KkP5qbvLIPllMBzvFcXusX/gi > 5u28S3Z8jWLYnULN4Hj+zB4fNKzLEqSRKGkZn2KAUdG3KjbvTKKAMvQL22vdLVrTVpNXjRyn > 25gmJj1+Vo1VGAztygxlSD8was/x7qttpPgrVHuLm0gkuLeS1tftWzZJO6lUQh/lIJ67vlAB > LYUE10lFAHJ+ANTtrjRJtJjkjS50i4ltJLLzUd7SIO3kRuUZgSIgikhm5VgSWVq6yiigAooo > oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACuP8AiTNZ2/hq1nubmxtZo9VsXtZ70ApF > ILhCWwSvRN5OCDtDcgZNdhRQB523imRTe6Y3iWMQ2GsCyvNWLQebbwm2MoeQ7fKQmcGHJQDj > bjf81Fz4mni8OXLR+KLRYTqYtbDV7qSKNbtPIWVsTLE0KkP5qbvLIPllMBzvHolFAHmYvdYv > /BFzdt4luz5GsWxOoWbwPH9mDw+aVmWJUkiUNIzPsUAo6NuVG3dxoF7bXulq1pq0mrxo5T7c > wTEx6/K0aqjAZ25QYypB+YNWpRQBxfxQGmt4RhXUpNNjB1OyEL6iivErfaE3EqxGR5fmbgCM > pv5AzVjwCIU03UUtJLSWzW9It5bBBHZyL5UZJt0BYIgYuGAZsyCQ5BJUdZRQAUUUUAFFFFAB > RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABXH/Emazt/DVrPc3NjazR6rYvaz3oBSKQXCEtglei > bycEHaG5Aya7CigDztvFMim90xvEsYhsNYFleasWg823hNsZQ8h2+UhM4MOSgHG3G/5qLnxN > PF4cuWj8UWiwnUxa2Gr3UkUa3aeQsrYmWJoVIfzU3eWQfLKYDnePRKKAPMxe6xf+CLm7bxLd > nyNYtidQs3geP7MHh80rMsSpJEoaRmfYoBR0bcqNu7jQL22vdLVrTVpNXjRyn25gmJj1+Vo1 > VGAztygxlSD8watSigDn/Fn/AB62H2n/AJA/2v8A4mufufZ/Kkxv7+X5nlb+23dv+TfUnheD > w5DZXL+GIrRLGa4Lu1kuIHk2IpMePkIwqglONwYH5g1blFABRRRQAUUUUAFFFFABRRRQAUUU > UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB > RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU > UAFFFFAH/9k= > --------------050004070302010302040400-- > > --------------090900090503060700030800-- > > --------------070003010705090101090701 > Content-Type: text/plain; > name="config.boot.pim-sm.cfg" > Content-Transfer-Encoding: 7bit > Content-Disposition: inline; > filename="config.boot.pim-sm.cfg" > > /* $XORP: xorp/rtrmgr/config.boot.sample,v 1.46 2007/03/12 10:16:05 atanu Exp $ */ > > > interfaces { > restore-original-config-on-shutdown: false > interface eth0 { > description: "data interface" > disable: false > default-system-config > } > interface eth1 { > description: "data interface" > disable: false > default-system-config > } > } > > fea { > unicast-forwarding4 { > disable: false > forwarding-entries { > retain-on-startup: false > retain-on-shutdown: false > } > } > } > > policy { > /* Describe connected routes for redistribution */ > policy-statement connected { > term export { > from { > protocol: "connected" > } > } > } > } > > policy { > /* Describe static routes for redistribution */ > policy-statement static { > term export { > from { > protocol: "static" > } > } > } > } > > > plumbing { > mfea4 { > disable: false > interface eth0 { > vif eth0 { > disable: false > } > } > interface eth1 { > vif eth1 { > 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 eth0 { > vif eth0 { > disable: false > version: 3 > } > } > interface eth1 { > vif eth1 { > disable: false > version: 3 > } > } > traceoptions { > flag all { > disable: false > } > } > } > } > > protocols { > pimsm4 { > disable: false > interface eth0 { > vif eth0 { > 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 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 register_vif { > vif register_vif { > /* Note: this vif should be always enabled */ > disable: false > } > } > traceoptions { > flag all { > disable: false > } > } > static-rps { > rp 192.168.14.211 { > group-prefix 224.0.0.0/4 { > } > } > } > } > } > > /* > * Note: fib2mrib is needed for multicast only if the unicast protocols > * don't populate the MRIB with multicast-specific routes. > */ > protocols { > fib2mrib { > disable: false > } > } > > > --------------070003010705090101090701 > Content-Type: text/plain; > name="xorp-status.txt" > Content-Transfer-Encoding: 7bit > Content-Disposition: inline; > filename="xorp-status.txt" > > root at localhost.localdomain> show pim join all > Group Source RP Flags > 224.0.0.0 192.168.14.211 192.168.14.211 RP > Upstream interface (RP): eth1 > Upstream MRIB next hop (RP): 192.168.14.211 > Upstream state: NotJoined > Join timer: -1 > Joins RP: ... > Join state: ... > Prune state: ... > Prune pending state: ... > Could assert WC: ... > I am DR: OOO > Immediate olist RP: ... > Inherited olist SG: ... > Inherited olist SG_RPT: ... > 232.11.22.33 192.168.18.158 192.168.14.211 SG DirectlyConnectedS > Upstream interface (S): eth1 > Upstream interface (RP): eth1 > Upstream MRIB next hop (RP): 192.168.14.211 > Upstream MRIB next hop (S): UNKNOWN > Upstream RPF'(S,G): UNKNOWN > Upstream state: Joined > Register state: RegisterNoinfo RegisterNotCouldRegister > Join timer: 1 > KAT(S,G) running: false > Local receiver include WC: ... > Local receiver include SG: O.. > Local receiver exclude SG: ... > Joins RP: ... > Joins WC: ... > Joins SG: ... > Join state: ... > 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: OO. > Could assert WC: ... > Could assert SG: ... > I am DR: OOO > Immediate olist RP: ... > Immediate olist WC: ... > Immediate olist SG: O.. > Inherited olist SG: O.. > Inherited olist SG_RPT: ... > PIM include WC: ... > PIM include SG: O.. > PIM exclude SG: ... > > --------------070003010705090101090701 > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > --------------070003010705090101090701-- From jjajal at gmail.com Thu Oct 16 23:32:41 2008 From: jjajal at gmail.com (Jigar) Date: Fri, 17 Oct 2008 12:02:41 +0530 Subject: [Xorp-users] IGMP and PIM-SSM problem In-Reply-To: <200810151722.m9FHMCsG011144@fruitcake.ICSI.Berkeley.EDU> References: <48F5FAC3.2060302@gmail.com> <200810151722.m9FHMCsG011144@fruitcake.ICSI.Berkeley.EDU> Message-ID: <48F83189.3050406@gmail.com> Pavlin Radoslavov wrote: > Jigar wrote: > > >> I think, I blundered in explaining the setup and the scenario which I >> want to >> create. >> Just scrap the previous one and start with the scratch. >> >> Actually, I want to test the following scenario given in RFC-4601 >> (PIM-SM) in >> section 4.5.7 (Sending (S,G) Join/Prune Messages) >> >> ######################################################### >> Transitions from NotJoined State >> When the upstream (S,G) state machine is in NotJoined state, the >> following event may trigger a state transition: >> JoinDesired(S,G) becomes True >> The macro JoinDesired(S,G) becomes True, e.g., because the >> downstream state for (S,G) has changed so that at least one >> interface is in inherited_olist(S,G). >> The upstream (S,G) state machine transitions to Joined state. >> Send Join(S,G) to the appropriate upstream neighbor, which is >> RPF'(S,G). Set the Join Timer (JT) to expire after t_periodic >> seconds. >> ########################################################## >> >> To generate above scenario, I have used setup as mentioned below. >> >> >> >> IP address: >> host A (eth0): 10.100.3.220/24 (IGMPv3 source specific join report >> sender) >> host B (eth1): 10.100.3.107/24 (PIM-SM downstream interface) >> host B (eth0): 192.168.14.212/24 (PIM-SM uptream interface) >> host C (eth0): 192.168.14.211/24 (configured as static RP on host B) >> >> Brief Information about setup: >> - All machines (host A, host B, and host C) are running RHEL4 >> (kernel-2.6.9). >> - host A and host C can be treated as packet generator. >> - host B is running xorp (1.4) with attached configuration >> (config.boot.pim-sm.cfg) >> - On host B, i configured host C as static RP for all group (pls see >> attached >> config file). >> - Test generates scenario such that >> host A becomes IGMP host (as receiver), >> host B becomes DR (of PIM-SM RPT), >> and host C becomes RP (of PIM-SM RPT). >> >> Steps followed in test: >> - host C sends PIM-SM hello packet with hold time as 0xffff (infinity) >> using >> packet generator utility. So host B assumes that RP is directly >> connect on its >> interface eth0. Also it ensures that RP remains always alive. >> - host A sends IGMPv3 source specific join report using attached >> application >> (igmpv3-join-generator.c). >> IGMP Join report is as following: >> Multicast Group address: 232.11.22.33 >> Mode: MCAST_INCLUDE >> No of sources in group: 1 >> Source address: 192.168.18.154 >> >> Expectation: >> - As per RFC, host B should generate PIM-SM join(S,G) (here S-192.168.18.154 >> G-232.11.22.33) message on eth0 (upstream interface) after receiving >> IGMPv3 >> source specific Join message on eth1 (downstream interface). >> >> But, I am not getting any PIM-SM join message on eth0 (upstream interface). >> >> Also, I have attached status of PIM-SM database on XORP. >> >> Can you pls guide me what is going wrong in this test scenario? >> > > Is the source address 192.168.18.158 or 192.168.18.154? > In the above IGMP Join report it is 192.168.18.154, but in the > "show pim join" output it is 192.168.18.158. > I had a mistake writing down the source address in explanation. Source address is 192.168.18.158 in IGMP also. > In any case, the issue seems to be that the RPF'(S,G) toward the > source is UNKNOWN: > > Upstream RPF'(S,G): UNKNOWN > > The reason it is UNKNOWN is because the MRIB (as seen by PIM-SM) > doesn't seem to contain an entry that points toward the source: > > Upstream MRIB next hop (S): UNKNOWN > > The simplest thing to do is to install a static route for the > source's subnet, say 192.168.18.0/24, and set host C > (192.168.14.211) as the next-hop router toward that subnet. > > Pavlin > Thanks a lot, Pavlin. I got your point and install static route for the source subnet and it works. One main thing I was missing was: *PIM JOIN(S,G) is always forwarded or sent towards the source S.* Thanks again for your great help, I am sorry for taking your so much of time. Jigar Jajal > P.S. In your particular setup you don't need the policy block. > > >> --------------090900090503060700030800 >> Content-Type: multipart/related; >> boundary="------------050004070302010302040400" >> >> >> --------------050004070302010302040400 >> Content-Type: text/html; charset=ISO-8859-1 >> Content-Transfer-Encoding: 7bit >> >> >> >> >> >> >> Pavlin,
>>
>> Thanks for your kind reply.
>>
>> I think, I blundered in explaining the setup and the scenario which I >> want to
>> create.
>> Just scrap the previous one and start with the scratch.
>>
>> Actually, I want to test the following scenario given in RFC-4601 >> (PIM-SM) in
>> section 4.5.7 (Sending (S,G) Join/Prune Messages)
>>
>> #########################################################
>> Transitions from NotJoined State
>>    When the upstream (S,G) state machine is in NotJoined state, the
>>    following event may trigger a state transition:
>>      JoinDesired(S,G) becomes True
>>           The macro JoinDesired(S,G) becomes True, e.g., because the
>>           downstream state for (S,G) has changed so that at least one
>>           interface is in inherited_olist(S,G).
>>           The upstream (S,G) state machine transitions to Joined state.
>>           Send Join(S,G) to the appropriate upstream neighbor, which is
>>           RPF'(S,G).  Set the Join Timer (JT) to expire after t_periodic
>>           seconds.
>> ##########################################################
>>
>> To generate above scenario, I have used setup as mentioned below.
>>     
>>   > width="483">
>>  
>> IP address:
>> host A (eth0): 10.100.3.220/24    (IGMPv3 source specific join report >> sender)
>> host B (eth1): 10.100.3.107/24    (PIM-SM downstream interface)
>> host B (eth0): 192.168.14.212/24  (PIM-SM uptream interface)
>> host C (eth0): 192.168.14.211/24  (configured as static RP on host B)
>>
>> Brief Information about setup:
>> - All machines (host A, host B, and host C) are running RHEL4 >> (kernel-2.6.9).
>> - host A and host C can be treated as packet generator.
>> - host B is running xorp (1.4) with attached configuration
>>   (config.boot.pim-sm.cfg)
>> - On host B, i configured host C as static RP for all group (pls see >> attached
>>   config file).
>> - Test generates scenario such that
>>   host A becomes IGMP host (as receiver),
>>   host B becomes DR (of PIM-SM RPT),
>>   and host C becomes RP (of PIM-SM RPT).
>>  
>> Steps followed in test:
>> - host C sends PIM-SM hello packet with hold time as 0xffff (infinity) >> using
>>   packet generator utility. So host B assumes that RP is directly >> connect on its
>>   interface eth0. Also it ensures that RP remains always alive.
>> - host A sends IGMPv3 source specific join report using attached >> application
>>   (igmpv3-join-generator.c).
>>   IGMP Join report is as following:
>>    Multicast Group address: 232.11.22.33
>>    Mode: MCAST_INCLUDE
>>    No of sources in group: 1
>>    Source address: 192.168.18.154
>>
>> Expectation:
>> - As per RFC, host B should generate PIM-SM join(S,G) (here >> S-192.168.18.154
>>    G-232.11.22.33) message on eth0 (upstream interface) after receiving >> IGMPv3
>>    source specific Join message on eth1 (downstream interface).
>>  
>> But, I am not getting any PIM-SM join message on eth0 (upstream >> interface).
>>
>> Also, I have attached status of PIM-SM database on XORP.
>>
>> Can you pls guide me what is going wrong in this test scenario?
>>
>>
>> >> >> >> >> --------------050004070302010302040400 >> Content-Type: image/jpeg >> Content-Transfer-Encoding: base64 >> Content-ID: >> >> /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof >> Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwh >> MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAAR >> CABxAeMDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA >> AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK >> FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG >> h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl >> 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA >> AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk >> NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE >> hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk >> 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iis/U4dYl8r+yb6xtcZ8z7XZvcbumMb >> ZUx365zkdMcgGhRXP/Y/GH/Qd0P/AME03/yVR9j8Yf8AQd0P/wAE03/yVQB0FFc/9j8Yf9B3 >> Q/8AwTTf/JVH2Pxh/wBB3Q//AATTf/JVAHQUVz/2Pxh/0HdD/wDBNN/8lUfY/GH/AEHdD/8A >> BNN/8lUAdBRXP/Y/GH/Qd0P/AME03/yVWhpkOsReb/a19Y3WceX9ks3t9vXOd0r57dMYweue >> ADQooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACis/U4dYl8r+yb6xtcZ8z7XZvcb >> umMbZUx365zkdMc5/wBj8Yf9B3Q//BNN/wDJVAHQUVz/ANj8Yf8AQd0P/wAE03/yVR9j8Yf9 >> B3Q//BNN/wDJVAHQUVz/ANj8Yf8AQd0P/wAE03/yVR9j8Yf9B3Q//BNN/wDJVAHQUVz/ANj8 >> Yf8AQd0P/wAE03/yVR9j8Yf9B3Q//BNN/wDJVAHQUVn6ZDrEXm/2tfWN1nHl/ZLN7fb1zndK >> +e3TGMHrnjQoAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACis/U4dYl8r+yb6xtcZ8z7 >> XZvcbumMbZUx365zkdMc5/2Pxh/0HdD/APBNN/8AJVAHQUVz/wBj8Yf9B3Q//BNN/wDJVH2P >> xh/0HdD/APBNN/8AJVAHQUVz/wBj8Yf9B3Q//BNN/wDJVH2Pxh/0HdD/APBNN/8AJVAHQUVz >> /wBj8Yf9B3Q//BNN/wDJVH2Pxh/0HdD/APBNN/8AJVAHQUVn6ZDrEXm/2tfWN1nHl/ZLN7fb >> 1zndK+e3TGMHrnjQoAKKKKAOf8d/8k88S/8AYKuv/RTV0FV7+xt9T065sLyPzLW6ieGZNxG5 >> GBDDI5GQT0qxQAUUUUAFFFFABRRRQAVz/jv/AJJ54l/7BV1/6Kaugqvf2NvqenXNheR+Za3U >> TwzJuI3IwIYZHIyCelAHP+OtU1HS9JtH0+5gs1muxFcXk8ywpbx+W7bjI0cipl1RMsjA79ow >> WBHPvqGraj4Ee5/4SiB2ttVtt9/pF5FcFbfzYvN86QQqg2qzucIoCKu7cN+70iigDzvxVqel >> S+BrO5XX7S9NvrFl9m1a/WMoZRcxsXUoI0cKhcExkcK4JBDYr3WsWV9cNpesaraajpek679n >> 1Ca7aLYYTZO6m5CgRgC4bYMqBujUcuMn0yigDl/Bf2PZrX9leR/Y39oD+z/suPs/l/Z4d/lb >> fl2+b5udvG/f3zXUUUUAFFFFABRRRQAVy/jrVNR0vSbR9PuYLNZrsRXF5PMsKW8flu24yNHI >> qZdUTLIwO/aMFgR1FFAHm76hq2o+BHuf+EogdrbVbbff6ReRXBW382LzfOkEKoNqs7nCKAir >> u3Dfuk8VanpUvgazuV1+0vTb6xZfZtWv1jKGUXMbF1KCNHCoXBMZHCuCQQ2PRKKAOLsNa027 >> svEem6x4ijkt9JvUt5b03q2soUpGwMkkJQIfNaSPgLnZtOSGzl2t/Z337PU/2O7guPI8NNBN >> 5Mgfy5FtPmRsdGGRkHkV6RVe/sbfU9OubC8j8y1uonhmTcRuRgQwyORkE9KALFFFFABRRRQA >> UUUUAFFFFAHP+O/+SeeJf+wVdf8Aopqr+OtU1HS9JtH0+5gs1muxFcXk8ywpbx+W7bjI0cip >> l1RMsjA79owWBHQX9jb6np1zYXkfmWt1E8MybiNyMCGGRyMgnpVigDzd9Q1bUfAj3P8AwlED >> tbarbb7/AEi8iuCtv5sXm+dIIVQbVZ3OEUBFXduG/dJ4q1PSpfA1ncrr9pem31iy+zatfrGU >> MouY2LqUEaOFQuCYyOFcEghseiUUAeZ3WsWV9cNpesaraajpek679n1Ca7aLYYTZO6m5CgRg >> C4bYMqBujUcuMnpPBf2PZrX9leR/Y39oD+z/ALLj7P5f2eHf5W35dvm+bnbxv39811FFABRR >> RQAUUUUAFcv461TUdL0m0fT7mCzWa7EVxeTzLClvH5btuMjRyKmXVEyyMDv2jBYEdRRQB5u+ >> oatqPgR7n/hKIHa21W233+kXkVwVt/Ni83zpBCqDarO5wigIq7tw37pPFWp6VL4Gs7ldftL0 >> 2+sWX2bVr9YyhlFzGxdSgjRwqFwTGRwrgkENj0SigDzO61iyvrhtL1jVbTUdL0nXfs+oTXbR >> bDCbJ3U3IUCMAXDbBlQN0ajlxkyT/Y/+Fc+P/wCyvI/sbyrn+z/suPs/l/Yo9/lbfl2+b5ud >> vG/f3zXpFV7+xt9T065sLyPzLW6ieGZNxG5GBDDI5GQT0oAsUUUUAFFFFABRRRQAUUUUAc/4 >> 7/5J54l/7BV1/wCimroKr39jb6np1zYXkfmWt1E8MybiNyMCGGRyMgnpVigAooooA5/x3/yT >> zxL/ANgq6/8ARTV0FV7+xt9T065sLyPzLW6ieGZNxG5GBDDI5GQT0qxQAUUUUAFFFFABRRRQ >> AVz/AI7/AOSeeJf+wVdf+imroKr39jb6np1zYXkfmWt1E8MybiNyMCGGRyMgnpQBYorP1OHW >> JfK/sm+sbXGfM+12b3G7pjG2VMd+uc5HTHOf9j8Yf9B3Q/8AwTTf/JVAHQUVz/2Pxh/0HdD/ >> APBNN/8AJVH2Pxh/0HdD/wDBNN/8lUAdBRXP/Y/GH/Qd0P8A8E03/wAlUfY/GH/Qd0P/AME0 >> 3/yVQB0FFc/9j8Yf9B3Q/wDwTTf/ACVR9j8Yf9B3Q/8AwTTf/JVAHQUVz/2Pxh/0HdD/APBN >> N/8AJVH2Pxh/0HdD/wDBNN/8lUAdBRXP/Y/GH/Qd0P8A8E03/wAlUfY/GH/Qd0P/AME03/yV >> QB0FFc/9j8Yf9B3Q/wDwTTf/ACVR9j8Yf9B3Q/8AwTTf/JVAHQVz/jv/AJJ54l/7BV1/6Kaj >> 7H4w/wCg7of/AIJpv/kqrEWmX99p19YeIbqxv7W7iMJS0tJLb5GBDgkyuTkHttxz+ABsUUUU >> Acv4/wD+Eb/4Rd/+En8j7L5qfZ/N8vd9oz+72eZ8m7OfvfJt3b/k3Vy9h/Y/2W4z9h+0f2qf >> +Ex+z7Nn+qk+9t5+z+Z5fX+HzPN58+vUKKAPI/E50FdCu2s49Gk8NC90s6ekzolk119pP2gR >> tggJ5W3eUBUfveC3mUa7Hpth4MvbTVrLRrKWPXbKWHR7mRVtbZTLEv7timPKkSOeQsqcB5gQ >> SrivXKKAMPwvo82j2VzHLBaWiT3BlisbJi0FouxF2RnavBZWkOFX5pG4P3juUUUAc/47/wCS >> eeJf+wVdf+imroKr39jb6np1zYXkfmWt1E8MybiNyMCGGRyMgnpVfU4dYl8r+yb6xtcZ8z7X >> ZvcbumMbZUx365zkdMcgGhRXP/Y/GH/Qd0P/AME03/yVR9j8Yf8AQd0P/wAE03/yVQB0FFc/ >> 9j8Yf9B3Q/8AwTTf/JVH2Pxh/wBB3Q//AATTf/JVAHQUVz/2Pxh/0HdD/wDBNN/8lUfY/GH/ >> AEHdD/8ABNN/8lUAdBRXP/Y/GH/Qd0P/AME03/yVR9j8Yf8AQd0P/wAE03/yVQB0FFc/9j8Y >> f9B3Q/8AwTTf/JVH2Pxh/wBB3Q//AATTf/JVAHQUVz/2Pxh/0HdD/wDBNN/8lUfY/GH/AEHd >> D/8ABNN/8lUAdBXP+O/+SeeJf+wVdf8AopqPsfjD/oO6H/4Jpv8A5KqxFpl/fadfWHiG6sb+ >> 1u4jCUtLSS2+RgQ4JMrk5B7bcc/gAbFFFFABRRRQAUUUUAFFFFAHP+O/+SeeJf8AsFXX/opq >> 6Cq9/Y2+p6dc2F5H5lrdRPDMm4jcjAhhkcjIJ6VYoAKKKKAOf8d/8k88S/8AYKuv/RTV0FV7 >> +xt9T065sLyPzLW6ieGZNxG5GBDDI5GQT0qxQAUUUUAFFFFABRRRQAVz/jv/AJJ54l/7BV1/ >> 6Kaugqvf2NvqenXNheR+Za3UTwzJuI3IwIYZHIyCelAFiiiigAooooAKKKKACiiigAooooAK >> KKKACiiigArn/Hf/ACTzxL/2Crr/ANFNXQVXv7G31PTrmwvI/MtbqJ4Zk3EbkYEMMjkZBPSg >> CxXL+PdXl0TQbe7g1mDSpjqFrEJbgI0bq8qq6uGxlQhdztZWwmdwANdRRQBx93eTW3hW31TT >> fFE+p266hbyS3p+zOjW3nJHMrNHGFEap5jFhgrtJLYBFc/feNSNO1qa18WwQtbeILSK1lukh >> 2G2mEJIZSFLw4adlcEFljyHIBJ9QooA8z1LxfJZaXqlvF4utEu9K120shdXJgYyxyeVvEygK >> MLvnB2eWcQHkFXJ2LDX7eay8R2F34sjh/si9S3bUzLbLKiskbZkynlA+Y0kX3B9zH3gTXaUU >> AeZjxZFH8JvDupWHiLTbG4V9OtppFEJgV28sSxOgwFCozMUUoVCcFQDVhvFMim90xvEsYhsN >> YFleasWg823hNsZQ8h2+UhM4MOSgHG3G/wCavRKr31lFqFnJazPOkb4yYJ3hcYIPDoQw6djz >> 06UAedy6jd6p4C+Ick+sSanbW9vPbWkht0iUxCzRw4woLFjISXzsbAZAqkCvTKy08PaYmjXe >> kmCSS0vEdLnzZ5JJJg67W3yMxdjtwoJbIAAGABjUoAKKKKACiiigAooooAKKKKACiiigAooo >> oAK5/wAd/wDJPPEv/YKuv/RTV0FV7+xt9T065sLyPzLW6ieGZNxG5GBDDI5GQT0oAsUUUUAF >> FFFABRRRQAUUUUAc/wCO/wDknniX/sFXX/opq6Cq9/Y2+p6dc2F5H5lrdRPDMm4jcjAhhkcj >> IJ6VYoAKKKKAOf8AHf8AyTzxL/2Crr/0U1dBVe/sbfU9OubC8j8y1uonhmTcRuRgQwyORkE9 >> Kr6nDrEvlf2TfWNrjPmfa7N7jd0xjbKmO/XOcjpjkA0KK5/7H4w/6Duh/wDgmm/+SqPsfjD/ >> AKDuh/8Agmm/+SqAOgorn/sfjD/oO6H/AOCab/5Ko+x+MP8AoO6H/wCCab/5KoA6Ciuf+x+M >> P+g7of8A4Jpv/kqj7H4w/wCg7of/AIJpv/kqgDoK5/x3/wAk88S/9gq6/wDRTUfY/GH/AEHd >> D/8ABNN/8lVYi0y/vtOvrDxDdWN/a3cRhKWlpJbfIwIcEmVycg9tuOfwANiiiigAooooAKKK >> KACiiigAooooAKKKKACiiigArn/Hf/JPPEv/AGCrr/0U1dBVe/sbfU9OubC8j8y1uonhmTcR >> uRgQwyORkE9KALFFZ+pw6xL5X9k31ja4z5n2uze43dMY2ypjv1znI6Y5z/sfjD/oO6H/AOCa >> b/5KoA6Ciuf+x+MP+g7of/gmm/8Akqj7H4w/6Duh/wDgmm/+SqAOgorn/sfjD/oO6H/4Jpv/ >> AJKo+x+MP+g7of8A4Jpv/kqgDoKK5/7H4w/6Duh/+Cab/wCSqPsfjD/oO6H/AOCab/5KoAPH >> f/JPPEv/AGCrr/0U1dBWPFpl/fadfWHiG6sb+1u4jCUtLSS2+RgQ4JMrk5B7bcc/hsUAFFFF >> ABRRRQAUUUUAFFFFABRRRQAUUUUAFc/47/5J54l/7BV1/wCimroKr39jb6np1zYXkfmWt1E8 >> MybiNyMCGGRyMgnpQBYorP1OHWJfK/sm+sbXGfM+12b3G7pjG2VMd+uc5HTHOf8AY/GH/Qd0 >> P/wTTf8AyVQB0FFc/wDY/GH/AEHdD/8ABNN/8lUfY/GH/Qd0P/wTTf8AyVQB0FFc/wDY/GH/ >> AEHdD/8ABNN/8lUfY/GH/Qd0P/wTTf8AyVQB0FFc/wDY/GH/AEHdD/8ABNN/8lUfY/GH/Qd0 >> P/wTTf8AyVQAeO/+SeeJf+wVdf8Aopq6CseLTL++06+sPEN1Y39rdxGEpaWklt8jAhwSZXJy >> D2245/DYoAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo >> oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC >> iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA4/4kzWdv4atZ7m5sbWaPVbF7We9AKR >> SC4QlsEr0TeTgg7Q3IGTWW3imRTe6Y3iWMQ2GsCyvNWLQebbwm2MoeQ7fKQmcGHJQDjbjf8A >> NXolFAHndz4mni8OXLR+KLRYTqYtbDV7qSKNbtPIWVsTLE0KkP5qbvLIPllMBzvFcXusX/gi >> 5u28S3Z8jWLYnULN4Hj+zB4fNKzLEqSRKGkZn2KAUdG3KjbvTKKAMvQL22vdLVrTVpNXjRyn >> 25gmJj1+Vo1VGAztygxlSD8was/x7qttpPgrVHuLm0gkuLeS1tftWzZJO6lUQh/lIJ67vlAB >> LYUE10lFAHJ+ANTtrjRJtJjkjS50i4ltJLLzUd7SIO3kRuUZgSIgikhm5VgSWVq6yiigAooo >> oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACuP8AiTNZ2/hq1nubmxtZo9VsXtZ70ApF >> ILhCWwSvRN5OCDtDcgZNdhRQB523imRTe6Y3iWMQ2GsCyvNWLQebbwm2MoeQ7fKQmcGHJQDj >> bjf81Fz4mni8OXLR+KLRYTqYtbDV7qSKNbtPIWVsTLE0KkP5qbvLIPllMBzvHolFAHmYvdYv >> /BFzdt4luz5GsWxOoWbwPH9mDw+aVmWJUkiUNIzPsUAo6NuVG3dxoF7bXulq1pq0mrxo5T7c >> wTEx6/K0aqjAZ25QYypB+YNWpRQBxfxQGmt4RhXUpNNjB1OyEL6iivErfaE3EqxGR5fmbgCM >> pv5AzVjwCIU03UUtJLSWzW9It5bBBHZyL5UZJt0BYIgYuGAZsyCQ5BJUdZRQAUUUUAFFFFAB >> RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABXH/Emazt/DVrPc3NjazR6rYvaz3oBSKQXCEtglei >> bycEHaG5Aya7CigDztvFMim90xvEsYhsNYFleasWg823hNsZQ8h2+UhM4MOSgHG3G/5qLnxN >> PF4cuWj8UWiwnUxa2Gr3UkUa3aeQsrYmWJoVIfzU3eWQfLKYDnePRKKAPMxe6xf+CLm7bxLd >> nyNYtidQs3geP7MHh80rMsSpJEoaRmfYoBR0bcqNu7jQL22vdLVrTVpNXjRyn25gmJj1+Vo1 >> VGAztygxlSD8watSigDn/Fn/AB62H2n/AJA/2v8A4mufufZ/Kkxv7+X5nlb+23dv+TfUnheD >> w5DZXL+GIrRLGa4Lu1kuIHk2IpMePkIwqglONwYH5g1blFABRRRQAUUUUAFFFFABRRRQAUUU >> UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB >> RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU >> UAFFFFAH/9k= >> --------------050004070302010302040400-- >> >> --------------090900090503060700030800-- >> >> --------------070003010705090101090701 >> Content-Type: text/plain; >> name="config.boot.pim-sm.cfg" >> Content-Transfer-Encoding: 7bit >> Content-Disposition: inline; >> filename="config.boot.pim-sm.cfg" >> >> /* $XORP: xorp/rtrmgr/config.boot.sample,v 1.46 2007/03/12 10:16:05 atanu Exp $ */ >> >> >> interfaces { >> restore-original-config-on-shutdown: false >> interface eth0 { >> description: "data interface" >> disable: false >> default-system-config >> } >> interface eth1 { >> description: "data interface" >> disable: false >> default-system-config >> } >> } >> >> fea { >> unicast-forwarding4 { >> disable: false >> forwarding-entries { >> retain-on-startup: false >> retain-on-shutdown: false >> } >> } >> } >> >> policy { >> /* Describe connected routes for redistribution */ >> policy-statement connected { >> term export { >> from { >> protocol: "connected" >> } >> } >> } >> } >> >> policy { >> /* Describe static routes for redistribution */ >> policy-statement static { >> term export { >> from { >> protocol: "static" >> } >> } >> } >> } >> >> >> plumbing { >> mfea4 { >> disable: false >> interface eth0 { >> vif eth0 { >> disable: false >> } >> } >> interface eth1 { >> vif eth1 { >> 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 eth0 { >> vif eth0 { >> disable: false >> version: 3 >> } >> } >> interface eth1 { >> vif eth1 { >> disable: false >> version: 3 >> } >> } >> traceoptions { >> flag all { >> disable: false >> } >> } >> } >> } >> >> protocols { >> pimsm4 { >> disable: false >> interface eth0 { >> vif eth0 { >> 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 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 register_vif { >> vif register_vif { >> /* Note: this vif should be always enabled */ >> disable: false >> } >> } >> traceoptions { >> flag all { >> disable: false >> } >> } >> static-rps { >> rp 192.168.14.211 { >> group-prefix 224.0.0.0/4 { >> } >> } >> } >> } >> } >> >> /* >> * Note: fib2mrib is needed for multicast only if the unicast protocols >> * don't populate the MRIB with multicast-specific routes. >> */ >> protocols { >> fib2mrib { >> disable: false >> } >> } >> >> >> --------------070003010705090101090701 >> Content-Type: text/plain; >> name="xorp-status.txt" >> Content-Transfer-Encoding: 7bit >> Content-Disposition: inline; >> filename="xorp-status.txt" >> >> root at localhost.localdomain> show pim join all >> Group Source RP Flags >> 224.0.0.0 192.168.14.211 192.168.14.211 RP >> Upstream interface (RP): eth1 >> Upstream MRIB next hop (RP): 192.168.14.211 >> Upstream state: NotJoined >> Join timer: -1 >> Joins RP: ... >> Join state: ... >> Prune state: ... >> Prune pending state: ... >> Could assert WC: ... >> I am DR: OOO >> Immediate olist RP: ... >> Inherited olist SG: ... >> Inherited olist SG_RPT: ... >> 232.11.22.33 192.168.18.158 192.168.14.211 SG DirectlyConnectedS >> Upstream interface (S): eth1 >> Upstream interface (RP): eth1 >> Upstream MRIB next hop (RP): 192.168.14.211 >> Upstream MRIB next hop (S): UNKNOWN >> Upstream RPF'(S,G): UNKNOWN >> Upstream state: Joined >> Register state: RegisterNoinfo RegisterNotCouldRegister >> Join timer: 1 >> KAT(S,G) running: false >> Local receiver include WC: ... >> Local receiver include SG: O.. >> Local receiver exclude SG: ... >> Joins RP: ... >> Joins WC: ... >> Joins SG: ... >> Join state: ... >> 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: OO. >> Could assert WC: ... >> Could assert SG: ... >> I am DR: OOO >> Immediate olist RP: ... >> Immediate olist WC: ... >> Immediate olist SG: O.. >> Inherited olist SG: O.. >> Inherited olist SG_RPT: ... >> PIM include WC: ... >> PIM include SG: O.. >> PIM exclude SG: ... >> >> --------------070003010705090101090701 >> Content-Type: text/plain; charset="us-ascii" >> MIME-Version: 1.0 >> Content-Transfer-Encoding: 7bit >> Content-Disposition: inline >> >> _______________________________________________ >> Xorp-users mailing list >> Xorp-users at xorp.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users >> >> --------------070003010705090101090701-- >> > > From pavlin at ICSI.Berkeley.EDU Sun Oct 19 14:08:30 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Sun, 19 Oct 2008 14:08:30 -0700 Subject: [Xorp-users] XORP Web site search Message-ID: <200810192108.m9JL8UgG008416@fruitcake.ICSI.Berkeley.EDU> All, Now the http://www.xorp.org/ Web site has a search bar in the upper right corner. You would have to reload the front page if you don't see it. Please give it a try and send feedbacks to either xorp-users at xorp.org or feedback at xorp.org (the latter if you prefer to keep the feedbacks private). The XORP Team. From kees at pink-frog.com Tue Oct 21 14:09:39 2008 From: kees at pink-frog.com (Kees Jan Hermans) Date: Tue, 21 Oct 2008 23:09:39 +0200 Subject: [Xorp-users] Multicast in general, and perhaps xorp in particular Message-ID: <48FE4513.1000304@pink-frog.com> Dear reader, I'm a bit at my wits' end; I have until Friday to complete this demo, which is for a prototype of a networking device that must also do IP multicasting. I have the following network topology: host1----------device------------router-------------device------host2 192.168.2.20 anonymous 192.168.2.1 <-> 192.168.3.1 anonymous 192.168.3.20 The router is using xorp, which I think is a fantastic product, altough I'm not all that familiar with it, having discovered it only a few days ago. That being said, getting routing done was a piece of cake, so nothing but compliments there. I must add that I was a little bit surprised to discover that one had to make special arrangements for getting multicasting work out of the box; apparently it isn't in the design philosophy of xorp to have one segment subscribe to a multicast address, and route traffic to that segment's interface automatically when traffic to that multicast address is discovered on another interface. I wonder why that is, but not for too long, because I got it to work (through a 'rp'). That is to say, if you take out the two 'devices' in the diagram above, everything works flawlessly: host2 has VLC subscribe to a multicast address, and on host1 VLC sends packets to that address, which arrive and I can hear pretty music play on host2. So far, so good. The devices in question, amongst other tasks, proxy for the IGMP and multicast traffic; they act as bridges effectively, cleaning and monitoring the network packets. To do what they have to do, the devices cache the multicast subscriptions, and create IGMP packets themselves on a timely basis. And when I have those devices in the middle (as drawn in the diagram above), it doesn't work. By now I'm pretty sure that 'my' IGMP packets are good, and equal to the packets sent by 'host2', however, when I send them, the subscriptions won't show up in the 'show igmp groups' list (they do if you take my devices out). I've noticed a few things though, that I wonder could be related to this problem: namely that 'host2' sends IGMP subscriptions TWICE in quick succession (where I send them only once), and that there's some PIM traffic going on to address 224.0.0.13 (that I don't react to at all). My questions are: a) are my suspicions about the differences in behaviour any good ? b) do I have to react to PIM traffic, and in effect create a dialog before subscription to a multicast address becomes effective in the router ? c) is there a way to see in the xorp router what happens with a packet such as a IGMP report packet ? Thanks for your time, and only too willing to also post configurations and packet data in hexadecimal, Sincerely, KJ Hermans From pavlin at ICSI.Berkeley.EDU Tue Oct 21 14:43:40 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Tue, 21 Oct 2008 14:43:40 -0700 Subject: [Xorp-users] Multicast in general, and perhaps xorp in particular In-Reply-To: <48FE4513.1000304@pink-frog.com> References: <48FE4513.1000304@pink-frog.com> Message-ID: <200810212143.m9LLheWj004348@fruitcake.ICSI.Berkeley.EDU> Kees Jan Hermans wrote: > Dear reader, > > I'm a bit at my wits' end; I have until Friday to complete this demo, > which is for a prototype of a networking device that must also do IP > multicasting. I have the following network topology: > > host1----------device------------router-------------device------host2 > 192.168.2.20 anonymous 192.168.2.1 <-> 192.168.3.1 anonymous 192.168.3.20 > > The router is using xorp, which I think is a fantastic product, altough > I'm not all that familiar with it, having discovered it only a few days > ago. That being said, getting routing done was a piece of cake, so > nothing but compliments there. I must add that I was a little bit > surprised to discover that one had to make special arrangements for > getting multicasting work out of the box; apparently it isn't in the > design philosophy of xorp to have one segment subscribe to a multicast > address, and route traffic to that segment's interface automatically > when traffic to that multicast address is discovered on another > interface. I wonder why that is, but not for too long, because I got it > to work (through a 'rp'). That is to say, if you take out the two This is how multicast routing works: in general, you must have a multicast routing protocol (or equivalent like IGMP proxy) running on the routing devices in the middle. > 'devices' in the diagram above, everything works flawlessly: host2 has > VLC subscribe to a multicast address, and on host1 VLC sends packets to > that address, which arrive and I can hear pretty music play on host2. > So far, so good. > > The devices in question, amongst other tasks, proxy for the IGMP and > multicast traffic; they act as bridges effectively, cleaning and > monitoring the network packets. To do what they have to do, the devices > cache the multicast subscriptions, and create IGMP packets themselves on > a timely basis. And when I have those devices in the middle (as drawn > in the diagram above), it doesn't work. By now I'm pretty sure that > 'my' IGMP packets are good, and equal to the packets sent by 'host2', > however, when I send them, the subscriptions won't show up in the 'show > igmp groups' list (they do if you take my devices out). I've noticed a I presume you see the IGMP packets your device generates if you run tcpdump on the XORP router. If you enable all tracing options for the MFEA and IGMP do you see any log messages about the packets being received? Any warning or error messages that might be helpful? > few things though, that I wonder could be related to this problem: > namely that 'host2' sends IGMP subscriptions TWICE in quick succession > (where I send them only once), and that there's some PIM traffic going > on to address 224.0.0.13 (that I don't react to at all). My questions are: > > a) are my suspicions about the differences in behaviour any good ? The problem is the IGMP joins don't show in "show igmp groups". Even if you think your IGMP packets are exactly same, obviously there is something different which stops them from being received by XORP. > b) do I have to react to PIM traffic, and in effect create a dialog > before subscription to a multicast address becomes effective in the router ? In general you have to forward the PIM control messages so they can reach the PIM neighbor routers. For this particular experiment with a single PIM-SM router you can get away even without forwarding the PIM control messages, but you MUST do the right thing for the product itself :) > c) is there a way to see in the xorp router what happens with a packet > such as a IGMP report packet ? Try to enable the traceoptions in the XORP config (in both the mfea4 and igmp blocks: traceoptions { flag all { disable: false } } Also, enable the XRLTRACE environmental variable. E.g., in csh/tcsh: setenv XRLTRACE yes This will print all IPC interprocess exchange in XORP (the so called XRLs). Warning: it will be a lot, so save all the output to a file and then post-process it. My personal preference is to use script(1) and start XORP in foreground. Look for XRLs like raw_packet4_client/0.1/recv which will print the IGMP and PIM control messages beint sent from the FEA to the IGMP and PIM processes. Please let us know how it goes. Pavlin > Thanks for your time, and only too willing to also post configurations > and packet data in hexadecimal, > > Sincerely, > > KJ Hermans > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From kees at pink-frog.com Tue Oct 21 23:08:34 2008 From: kees at pink-frog.com (Kees Jan Hermans) Date: Wed, 22 Oct 2008 08:08:34 +0200 Subject: [Xorp-users] Multicast in general, and perhaps xorp in particular In-Reply-To: <200810212143.m9LLheWj004348@fruitcake.ICSI.Berkeley.EDU> References: <48FE4513.1000304@pink-frog.com> <200810212143.m9LLheWj004348@fruitcake.ICSI.Berkeley.EDU> Message-ID: <48FEC362.2070201@pink-frog.com> Yes, I did run tcpdump, but then on a host in between, like so: host2----hub----router | tcpdumper and: host2---device---hub---router | tcpdumper I'll see if I can post the traffic later. Gotta go to work now. Cheers, KJ Pavlin Radoslavov wrote: > Kees Jan Hermans wrote: > > >> Dear reader, >> >> I'm a bit at my wits' end; I have until Friday to complete this demo, >> which is for a prototype of a networking device that must also do IP >> multicasting. I have the following network topology: >> >> host1----------device------------router-------------device------host2 >> 192.168.2.20 anonymous 192.168.2.1 <-> 192.168.3.1 anonymous 192.168.3.20 >> >> The router is using xorp, which I think is a fantastic product, altough >> I'm not all that familiar with it, having discovered it only a few days >> ago. That being said, getting routing done was a piece of cake, so >> nothing but compliments there. I must add that I was a little bit >> surprised to discover that one had to make special arrangements for >> getting multicasting work out of the box; apparently it isn't in the >> design philosophy of xorp to have one segment subscribe to a multicast >> address, and route traffic to that segment's interface automatically >> when traffic to that multicast address is discovered on another >> interface. I wonder why that is, but not for too long, because I got it >> to work (through a 'rp'). That is to say, if you take out the two >> > > This is how multicast routing works: in general, you must have a > multicast routing protocol (or equivalent like IGMP proxy) running > on the routing devices in the middle. > > >> 'devices' in the diagram above, everything works flawlessly: host2 has >> VLC subscribe to a multicast address, and on host1 VLC sends packets to >> that address, which arrive and I can hear pretty music play on host2. >> So far, so good. >> >> The devices in question, amongst other tasks, proxy for the IGMP and >> multicast traffic; they act as bridges effectively, cleaning and >> monitoring the network packets. To do what they have to do, the devices >> cache the multicast subscriptions, and create IGMP packets themselves on >> a timely basis. And when I have those devices in the middle (as drawn >> in the diagram above), it doesn't work. By now I'm pretty sure that >> 'my' IGMP packets are good, and equal to the packets sent by 'host2', >> however, when I send them, the subscriptions won't show up in the 'show >> igmp groups' list (they do if you take my devices out). I've noticed a >> > > I presume you see the IGMP packets your device generates if you run > tcpdump on the XORP router. > If you enable all tracing options for the MFEA and IGMP do you see > any log messages about the packets being received? > Any warning or error messages that might be helpful? > > >> few things though, that I wonder could be related to this problem: >> namely that 'host2' sends IGMP subscriptions TWICE in quick succession >> (where I send them only once), and that there's some PIM traffic going >> on to address 224.0.0.13 (that I don't react to at all). My questions are: >> >> a) are my suspicions about the differences in behaviour any good ? >> > > The problem is the IGMP joins don't show in "show igmp groups". > Even if you think your IGMP packets are exactly same, obviously > there is something different which stops them from being received by > XORP. > > >> b) do I have to react to PIM traffic, and in effect create a dialog >> before subscription to a multicast address becomes effective in the router ? >> > > In general you have to forward the PIM control messages so they can > reach the PIM neighbor routers. > For this particular experiment with a single PIM-SM router you can > get away even without forwarding the PIM control messages, but you > MUST do the right thing for the product itself :) > > >> c) is there a way to see in the xorp router what happens with a packet >> such as a IGMP report packet ? >> > > Try to enable the traceoptions in the XORP config (in both the mfea4 > and igmp blocks: > > traceoptions { > flag all { > disable: false > } > } > > Also, enable the XRLTRACE environmental variable. E.g., in csh/tcsh: > > setenv XRLTRACE yes > > This will print all IPC interprocess exchange in XORP (the so called > XRLs). > Warning: it will be a lot, so save all the output to a file and then > post-process it. My personal preference is to use script(1) and > start XORP in foreground. > Look for XRLs like raw_packet4_client/0.1/recv which will print the > IGMP and PIM control messages beint sent from the FEA to the IGMP > and PIM processes. > > Please let us know how it goes. > Pavlin > > >> Thanks for your time, and only too willing to also post configurations >> and packet data in hexadecimal, >> >> Sincerely, >> >> KJ Hermans >> >> _______________________________________________ >> Xorp-users mailing list >> Xorp-users at xorp.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users >> > > > From kees at pink-frog.com Wed Oct 22 01:17:42 2008 From: kees at pink-frog.com (kees at pink-frog.com) Date: Wed, 22 Oct 2008 10:17:42 +0200 (CEST) Subject: [Xorp-users] Multicast in general, and perhaps xorp in particular In-Reply-To: <48FEC362.2070201@pink-frog.com> References: <48FE4513.1000304@pink-frog.com> <200810212143.m9LLheWj004348@fruitcake.ICSI.Berkeley.EDU> <48FEC362.2070201@pink-frog.com> Message-ID: <53606.83.160.27.115.1224663462.squirrel@webmail.trib-design.com> Ok. I got it. My program at one point made its IGMP packets exactly like the ones it received, and then the checksumming showed to be at fault; I had a struct ip4hdr* ip4hdr defined, and later on did the checksumming on sizeof(ip4hdr) instead of a sizeof(struct ip4hdr). It's not that I'm more of a C++ programmer really, but it was just a stupid mistake. Sorry to waste your time. It works now. I'll have a look later to see if the client also wants PIM, and if it's easy to implement. Sincerely, KJ > Yes, I did run tcpdump, but then on a host in between, like so: > > host2----hub----router > | > tcpdumper > > and: > > host2---device---hub---router > | > tcpdumper > > > I'll see if I can post the traffic later. Gotta go to work now. > > Cheers, > > KJ > > Pavlin Radoslavov wrote: >> Kees Jan Hermans wrote: >> >> >>> Dear reader, >>> >>> I'm a bit at my wits' end; I have until Friday to complete this demo, >>> which is for a prototype of a networking device that must also do IP >>> multicasting. I have the following network topology: >>> >>> host1----------device------------router-------------device------host2 >>> 192.168.2.20 anonymous 192.168.2.1 <-> 192.168.3.1 anonymous >>> 192.168.3.20 >>> >>> The router is using xorp, which I think is a fantastic product, altough >>> I'm not all that familiar with it, having discovered it only a few days >>> ago. That being said, getting routing done was a piece of cake, so >>> nothing but compliments there. I must add that I was a little bit >>> surprised to discover that one had to make special arrangements for >>> getting multicasting work out of the box; apparently it isn't in the >>> design philosophy of xorp to have one segment subscribe to a multicast >>> address, and route traffic to that segment's interface automatically >>> when traffic to that multicast address is discovered on another >>> interface. I wonder why that is, but not for too long, because I got >>> it >>> to work (through a 'rp'). That is to say, if you take out the two >>> >> >> This is how multicast routing works: in general, you must have a >> multicast routing protocol (or equivalent like IGMP proxy) running >> on the routing devices in the middle. >> >> >>> 'devices' in the diagram above, everything works flawlessly: host2 has >>> VLC subscribe to a multicast address, and on host1 VLC sends packets to >>> that address, which arrive and I can hear pretty music play on host2. >>> So far, so good. >>> >>> The devices in question, amongst other tasks, proxy for the IGMP and >>> multicast traffic; they act as bridges effectively, cleaning and >>> monitoring the network packets. To do what they have to do, the >>> devices >>> cache the multicast subscriptions, and create IGMP packets themselves >>> on >>> a timely basis. And when I have those devices in the middle (as drawn >>> in the diagram above), it doesn't work. By now I'm pretty sure that >>> 'my' IGMP packets are good, and equal to the packets sent by 'host2', >>> however, when I send them, the subscriptions won't show up in the 'show >>> igmp groups' list (they do if you take my devices out). I've noticed a >>> >> >> I presume you see the IGMP packets your device generates if you run >> tcpdump on the XORP router. >> If you enable all tracing options for the MFEA and IGMP do you see >> any log messages about the packets being received? >> Any warning or error messages that might be helpful? >> >> >>> few things though, that I wonder could be related to this problem: >>> namely that 'host2' sends IGMP subscriptions TWICE in quick succession >>> (where I send them only once), and that there's some PIM traffic going >>> on to address 224.0.0.13 (that I don't react to at all). My questions >>> are: >>> >>> a) are my suspicions about the differences in behaviour any good ? >>> >> >> The problem is the IGMP joins don't show in "show igmp groups". >> Even if you think your IGMP packets are exactly same, obviously >> there is something different which stops them from being received by >> XORP. >> >> >>> b) do I have to react to PIM traffic, and in effect create a dialog >>> before subscription to a multicast address becomes effective in the >>> router ? >>> >> >> In general you have to forward the PIM control messages so they can >> reach the PIM neighbor routers. >> For this particular experiment with a single PIM-SM router you can >> get away even without forwarding the PIM control messages, but you >> MUST do the right thing for the product itself :) >> >> >>> c) is there a way to see in the xorp router what happens with a packet >>> such as a IGMP report packet ? >>> >> >> Try to enable the traceoptions in the XORP config (in both the mfea4 >> and igmp blocks: >> >> traceoptions { >> flag all { >> disable: false >> } >> } >> >> Also, enable the XRLTRACE environmental variable. E.g., in csh/tcsh: >> >> setenv XRLTRACE yes >> >> This will print all IPC interprocess exchange in XORP (the so called >> XRLs). >> Warning: it will be a lot, so save all the output to a file and then >> post-process it. My personal preference is to use script(1) and >> start XORP in foreground. >> Look for XRLs like raw_packet4_client/0.1/recv which will print the >> IGMP and PIM control messages beint sent from the FEA to the IGMP >> and PIM processes. >> >> Please let us know how it goes. >> Pavlin >> >> >>> Thanks for your time, and only too willing to also post configurations >>> and packet data in hexadecimal, >>> >>> Sincerely, >>> >>> KJ Hermans >>> >>> _______________________________________________ >>> Xorp-users mailing list >>> Xorp-users at xorp.org >>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users >>> >> >> >> > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > From karnik.jain at einfochips.com Wed Oct 22 05:10:38 2008 From: karnik.jain at einfochips.com (karnik) Date: Wed, 22 Oct 2008 17:40:38 +0530 Subject: [Xorp-users] [OSPF] Virtual Link In-Reply-To: <200810190302.m9J32Tfd023102@fruitcake.ICSI.Berkeley.EDU> References: <48F8CB6B.5080307@candelatech.com> <200810172156.m9HLuLYB009081@fruitcake.ICSI.Berkeley.EDU> <48F91C8B.5070907@candelatech.com> <200810190302.m9J32Tfd023102@fruitcake.ICSI.Berkeley.EDU> Message-ID: <48FF183E.1040805@einfochips.com> How to configure /Virtul Link in OSPF./ Can you please send me the configuration file for OSPF to configure /Virtul Link ?/ -- _____________________________________________________________________ Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated.Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. __________________________________________________________________________ From pavlin at ICSI.Berkeley.EDU Wed Oct 22 08:05:44 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Wed, 22 Oct 2008 08:05:44 -0700 Subject: [Xorp-users] Multicast in general, and perhaps xorp in particular In-Reply-To: <53606.83.160.27.115.1224663462.squirrel@webmail.trib-design.com> References: <48FE4513.1000304@pink-frog.com> <200810212143.m9LLheWj004348@fruitcake.ICSI.Berkeley.EDU> <48FEC362.2070201@pink-frog.com> <53606.83.160.27.115.1224663462.squirrel@webmail.trib-design.com> Message-ID: <200810221506.m9MF5jGn008143@fruitcake.ICSI.Berkeley.EDU> kees at pink-frog.com wrote: > Ok. I got it. My program at one point made its IGMP packets exactly like > the ones it received, and then the checksumming showed to be at fault; I > had a struct ip4hdr* ip4hdr defined, and later on did the checksumming on > sizeof(ip4hdr) instead of a sizeof(struct ip4hdr). It's not that I'm more > of a C++ programmer really, but it was just a stupid mistake. Sorry to > waste your time. It works now. I'll have a look later to see if the > client also wants PIM, and if it's easy to implement. I am glad you got it working. Thanks for the update, Pavlin > Sincerely, > > KJ > > > Yes, I did run tcpdump, but then on a host in between, like so: > > > > host2----hub----router > > | > > tcpdumper > > > > and: > > > > host2---device---hub---router > > | > > tcpdumper > > > > > > I'll see if I can post the traffic later. Gotta go to work now. > > > > Cheers, > > > > KJ > > > > Pavlin Radoslavov wrote: > >> Kees Jan Hermans wrote: > >> > >> > >>> Dear reader, > >>> > >>> I'm a bit at my wits' end; I have until Friday to complete this demo, > >>> which is for a prototype of a networking device that must also do IP > >>> multicasting. I have the following network topology: > >>> > >>> host1----------device------------router-------------device------host2 > >>> 192.168.2.20 anonymous 192.168.2.1 <-> 192.168.3.1 anonymous > >>> 192.168.3.20 > >>> > >>> The router is using xorp, which I think is a fantastic product, altough > >>> I'm not all that familiar with it, having discovered it only a few days > >>> ago. That being said, getting routing done was a piece of cake, so > >>> nothing but compliments there. I must add that I was a little bit > >>> surprised to discover that one had to make special arrangements for > >>> getting multicasting work out of the box; apparently it isn't in the > >>> design philosophy of xorp to have one segment subscribe to a multicast > >>> address, and route traffic to that segment's interface automatically > >>> when traffic to that multicast address is discovered on another > >>> interface. I wonder why that is, but not for too long, because I got > >>> it > >>> to work (through a 'rp'). That is to say, if you take out the two > >>> > >> > >> This is how multicast routing works: in general, you must have a > >> multicast routing protocol (or equivalent like IGMP proxy) running > >> on the routing devices in the middle. > >> > >> > >>> 'devices' in the diagram above, everything works flawlessly: host2 has > >>> VLC subscribe to a multicast address, and on host1 VLC sends packets to > >>> that address, which arrive and I can hear pretty music play on host2. > >>> So far, so good. > >>> > >>> The devices in question, amongst other tasks, proxy for the IGMP and > >>> multicast traffic; they act as bridges effectively, cleaning and > >>> monitoring the network packets. To do what they have to do, the > >>> devices > >>> cache the multicast subscriptions, and create IGMP packets themselves > >>> on > >>> a timely basis. And when I have those devices in the middle (as drawn > >>> in the diagram above), it doesn't work. By now I'm pretty sure that > >>> 'my' IGMP packets are good, and equal to the packets sent by 'host2', > >>> however, when I send them, the subscriptions won't show up in the 'show > >>> igmp groups' list (they do if you take my devices out). I've noticed a > >>> > >> > >> I presume you see the IGMP packets your device generates if you run > >> tcpdump on the XORP router. > >> If you enable all tracing options for the MFEA and IGMP do you see > >> any log messages about the packets being received? > >> Any warning or error messages that might be helpful? > >> > >> > >>> few things though, that I wonder could be related to this problem: > >>> namely that 'host2' sends IGMP subscriptions TWICE in quick succession > >>> (where I send them only once), and that there's some PIM traffic going > >>> on to address 224.0.0.13 (that I don't react to at all). My questions > >>> are: > >>> > >>> a) are my suspicions about the differences in behaviour any good ? > >>> > >> > >> The problem is the IGMP joins don't show in "show igmp groups". > >> Even if you think your IGMP packets are exactly same, obviously > >> there is something different which stops them from being received by > >> XORP. > >> > >> > >>> b) do I have to react to PIM traffic, and in effect create a dialog > >>> before subscription to a multicast address becomes effective in the > >>> router ? > >>> > >> > >> In general you have to forward the PIM control messages so they can > >> reach the PIM neighbor routers. > >> For this particular experiment with a single PIM-SM router you can > >> get away even without forwarding the PIM control messages, but you > >> MUST do the right thing for the product itself :) > >> > >> > >>> c) is there a way to see in the xorp router what happens with a packet > >>> such as a IGMP report packet ? > >>> > >> > >> Try to enable the traceoptions in the XORP config (in both the mfea4 > >> and igmp blocks: > >> > >> traceoptions { > >> flag all { > >> disable: false > >> } > >> } > >> > >> Also, enable the XRLTRACE environmental variable. E.g., in csh/tcsh: > >> > >> setenv XRLTRACE yes > >> > >> This will print all IPC interprocess exchange in XORP (the so called > >> XRLs). > >> Warning: it will be a lot, so save all the output to a file and then > >> post-process it. My personal preference is to use script(1) and > >> start XORP in foreground. > >> Look for XRLs like raw_packet4_client/0.1/recv which will print the > >> IGMP and PIM control messages beint sent from the FEA to the IGMP > >> and PIM processes. > >> > >> Please let us know how it goes. > >> Pavlin > >> > >> > >>> Thanks for your time, and only too willing to also post configurations > >>> and packet data in hexadecimal, > >>> > >>> Sincerely, > >>> > >>> KJ Hermans > >>> > >>> _______________________________________________ > >>> Xorp-users mailing list > >>> Xorp-users at xorp.org > >>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > >>> > >> > >> > >> > > > > _______________________________________________ > > Xorp-users mailing list > > Xorp-users at xorp.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From lfross at ucdavis.edu Thu Oct 23 14:29:19 2008 From: lfross at ucdavis.edu (Larry Ross) Date: Thu, 23 Oct 2008 14:29:19 -0700 Subject: [Xorp-users] Guidance needed. Message-ID: <1FF77A6EABE79749A7D89BE018D5AF892FF6F74061@XEDAMAIL2.ex.ad3.ucdavis.edu> Rendezvous Point PIM-SM RP=192.168.0.103 ------------------------------------------------------XORP Router----------------------------------------Client Subnet Direct attached Workstations Campus Network XL0(w/pf firewall) dc0 192.168.1.158 10.10.0.94 10.10.251.80/28 Good Afternoon all; New to Xorp so pardon any obvious blunders. I am trying to configure a uni/multicast router/firewall for a small subnet. Campus uses PIM-SM for multicast transmission (see diagram above, IP's obfuscated). I have performed the majority of the cconfiguration from xorpsh to avoid syntax prblems however I am encountering a problem that is completely killing me... Whenever I try and activate mfea4 i receive errors that I believe are halting me from bringing up pimsm and IGMP. If you could please review my config and provide feedback I would greatly appreciate it. Also I am confused as to what (if any) kernel mods sysctl flags etc etc might be needed to get this puppy off the ground. Any assistance in this matter would be greatly appreciated. Thank you! root at WanliChangCheng.ucdavis.edu# set plumbing mfea4 interface xl0 vif xl0 [edit] root at WanliChangCheng.ucdavis.edu# set plumbing mfea4 interface register_vif vif register_vif [edit] root at WanliChangCheng.ucdavis.edu# set plumbing mfea4 traceoptions flag all [edit] root at WanliChangCheng.ucdavis.edu# commit Commit Failed 102 Command failed Cannot start vif xl0: cannot add the multicast vif to the kernel[edit] root at WanliChangCheng.ucdavis.edu# commit Commit Failed 102 Command failed Cannot start vif register_vif: cannot add the multicast vif to the kernel[edit] If I try a third time it appears to take however I believe this to be false as the vifs do not seem to be being entered into Kernel Multicast. root at WanliChangCheng.ucdavis.edu# commit OK [edit] root at WanliChangCheng.ucdavis.edu# root at WanliChangCheng.ucdavis.edu> show host os FreeBSD WanliChangCheng.ucdavis.edu 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008 root at logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 Running XORP 1.5 from FreeBSD ports collection. XORP.CONF protocols { fib2mrib { disable: false } static { disable: false route 0.0.0.0/0 { next-hop: 192.168.241.157 metric: 1 } } } fea { unicast-forwarding4 { disable: false } unicast-forwarding6 { disable: false } } interfaces { restore-original-config-on-shutdown: false interface dc0 { disable: false discard: false description: "Ethernet" vif dc0 { disable: false address 10.10.251.94 { prefix-length: 28 disable: false } } } interface xl0 { disable: false discard: false description: "Ethernet" vif xl0 { disable: false address 192.168.241.158 { prefix-length: 30 disable: false } } } interface lo0 { disable: false discard: false description: "Loopback interface" vif lo0 { disable: false } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20081023/76163329/attachment.html From pavlin at ICSI.Berkeley.EDU Thu Oct 23 15:04:59 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Thu, 23 Oct 2008 15:04:59 -0700 Subject: [Xorp-users] Guidance needed. In-Reply-To: <1FF77A6EABE79749A7D89BE018D5AF892FF6F74061@XEDAMAIL2.ex.ad3.ucdavis.edu> References: <1FF77A6EABE79749A7D89BE018D5AF892FF6F74061@XEDAMAIL2.ex.ad3.ucdavis.edu> Message-ID: <200810232205.m9NM50td023989@fruitcake.ICSI.Berkeley.EDU> For your OS (FreeBSD-7.0), you need to recompile your kernel with the following option added to your kernel config: options MROUTING # Multicast routing It is in the XORP User Manual in the PIM-SM chapter. Pavlin Larry Ross wrote: > Rendezvous Point PIM-SM > > RP=192.168.0.103 ------------------------------------------------------XORP Router----------------------------------------Client Subnet Direct attached Workstations > > Campus Network XL0(w/pf firewall) dc0 > > 192.168.1.158 10.10.0.94 10.10.251.80/28 > > > Good Afternoon all; > > New to Xorp so pardon any obvious blunders. I am trying to configure a uni/multicast router/firewall for a small subnet. Campus uses PIM-SM for multicast transmission (see diagram above, IP's obfuscated). I have performed the majority of the cconfiguration from xorpsh to avoid syntax prblems however I am encountering a problem that is completely killing me... Whenever I try and activate mfea4 i receive errors that I believe are halting me from bringing up pimsm and IGMP. If you could please review my config and provide feedback I would greatly appreciate it. Also I am confused as to what (if any) kernel mods sysctl flags etc etc might be needed to get this puppy off the ground. Any assistance in this matter would be greatly appreciated. > > Thank you! > > > > > > root at WanliChangCheng.ucdavis.edu# set plumbing mfea4 interface xl0 vif xl0 > [edit] > root at WanliChangCheng.ucdavis.edu# set plumbing mfea4 interface register_vif vif register_vif > [edit] > root at WanliChangCheng.ucdavis.edu# set plumbing mfea4 traceoptions flag all > [edit] > root at WanliChangCheng.ucdavis.edu# commit > Commit Failed > 102 Command failed Cannot start vif xl0: cannot add the multicast vif to the kernel[edit] > root at WanliChangCheng.ucdavis.edu# commit > Commit Failed > 102 Command failed Cannot start vif register_vif: cannot add the multicast vif to the kernel[edit] > > > If I try a third time it appears to take however I believe this to be false as the vifs do not seem to be being entered into Kernel Multicast. > > root at WanliChangCheng.ucdavis.edu# commit > OK > [edit] > root at WanliChangCheng.ucdavis.edu# > > > > root at WanliChangCheng.ucdavis.edu> show host os > FreeBSD WanliChangCheng.ucdavis.edu 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008 root at logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > > > Running XORP 1.5 from FreeBSD ports collection. > > > > > > XORP.CONF > > protocols { > fib2mrib { > disable: false > } > static { > disable: false > route 0.0.0.0/0 { > next-hop: 192.168.241.157 > metric: 1 > } > } > } > fea { > unicast-forwarding4 { > disable: false > } > unicast-forwarding6 { > disable: false > } > } > interfaces { > restore-original-config-on-shutdown: false > interface dc0 { > disable: false > discard: false > description: "Ethernet" > vif dc0 { > disable: false > address 10.10.251.94 { > prefix-length: 28 > disable: false > } > } > } > interface xl0 { > disable: false > discard: false > description: "Ethernet" > vif xl0 { > disable: false > address 192.168.241.158 { > prefix-length: 30 > disable: false > } > } > } > interface lo0 { > disable: false > discard: false > description: "Loopback interface" > vif lo0 { > disable: false > } > } > } > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From karnik.jain at einfochips.com Fri Oct 24 00:00:47 2008 From: karnik.jain at einfochips.com (karnik) Date: Fri, 24 Oct 2008 12:30:47 +0530 Subject: [Xorp-users] [OSPFv2] Router Crash] Message-ID: <4901729F.3080401@einfochips.com> I am doing some testing work of ospf with xorp for configuring virtual link between two ABRs. at that time i have noticed following errors in xorp. At that time xorp is giving following errors and crash : i don't understand what happens, tell me why this happen with xorp . /*/*I have attached the scenario and configuration file of both ABRs that i have created to configure the virtual link. */ */ /**/ON 1st ABR i have found following errors in xorp./* */ [ 2008/10/24 11:42:30 FATAL xorp_ospfv2:3594 OSPF +85 peer.hh get_interface_prefix_length ] Assertion (0 != _interface_prefix_length) failed [ 2008/10/24 11:42:30 ERROR xorp_rtrmgr:3567 RTRMGR +747 module_manager.cc done_cb ] Command "/usr/local/xorp/ospf/xorp_ospfv2": terminated with signal 6. [ 2008/10/24 11:42:30 INFO xorp_rtrmgr:3567 RTRMGR +294 module_manager.cc module_exited ] Module abnormally killed: ospf4 [ 2008/10/24 11:42:30 INFO xorp_rib RIB ] Received death event for protocol ospfv2 shutting down ------- OriginTable: ospf IGP next table = Redist:ospf [ 2008/10/24 11:42:30 INFO xorp_rib RIB ] Received death event for protocol ospfv2 shutting down ------- OriginTable: ospf IGP next table = Redist:ospf [ 2008/10/24 11:42:30 INFO xorp_rib RIB ] Received death event for protocol ospfv2 shutting down ------- OriginTable: ospf IGP next table = Redist:ospf /*/*ON 2nd ABR i have found following errors in xorp. */ */[2008/10/24 11:42:30 FATAL xorp_ospfv2:3594 OSPF +85 peer.hh get_interface_prefix_length ] Assertion (0 != _interface_prefix_length) failed [ 2008/10/24 11:42:30 ERROR xorp_rtrmgr:3567 RTRMGR +747 module_manager.cc done_cb ] Command "/usr/local/xorp/ospf/xorp_ospfv2": terminated with signal 6. [ 2008/10/24 11:42:30 INFO xorp_rtrmgr:3567 RTRMGR +294 module_manager.cc module_exited ] Module abnormally killed: ospf4 [ 2008/10/24 11:42:30 INFO xorp_rib RIB ] Received death event for protocol ospfv2 shutting down ------- OriginTable: ospf IGP next table = Redist:ospf [ 2008/10/24 11:42:30 INFO xorp_rib RIB ] Received death event for protocol ospfv2 shutting down ------- OriginTable: ospf IGP next table = Redist:ospf [ 2008/10/24 11:42:30 INFO xorp_rib RIB ] Received death event for protocol ospfv2 shutting down ------- OriginTable: ospf IGP next table = Redist:ospf [ 2008/10/24 11:42:30 INFO xorp_rib RIB ] Received death event for protocol ospfv2 shutting down ------- OriginTable: ospf IGP next table = Redist:ospf rib RIB ] Received death event for protocol ospfv2 shutting down ------- OriginTable: ospf IGP next table = Redist:ospf /*Test Setup: Test Setup */ */ON 1st ABR's configuration file./* ------------------------------------------------------------------------ /* $XORP: xorp/rtrmgr/config.boot.sample,v 1.46 2007/03/12 10:16:05 atanu Exp $ */ interfaces { restore-original-config-on-shutdown: false interface eth0 { description: "data interface" disable: false /*default-system-config*/ vif eth0 { disable: false address 192.168.14.1 { prefix-length: 24 broadcast: 192.168.14.255 disable: false } } } interface eth1 { description: "data interface" disable: false /*default-system-config*/ vif eth1 { disable: false address 192.168.16.20{ prefix-length: 24 broadcast: 192.168.16.255 disable: false } } } } fea { unicast-forwarding4 { disable: false forwarding-entries { retain-on-startup: false retain-on-shutdown: false } } } protocols { ospf4 { router-id: 10.10.10.10 /* export: "static" */ traceoptions { flag { all { disable: false } } } area 0.0.0.0{ virtual-link 10.10.10.11{ transit-area: 1.1.1.1 } interface eth0 { /* link-type: "broadcast" */ vif eth0 { address 192.168.14.1 { priority: 1 hello-interval: 10 router-dead-interval: 40 /*interface-cost: 1*/ /*retransmit-interval: 5*/ /*transit-delay: 1 */ /* authentication { simple-password: "password"; md5 @: u32 { password: "password"; start-time: "2006-01-01.12:00" end-time: "2007-01-01.12:00" max-time-drift: 3600 } } */ /* passive: false */ /* disable: false */ } } } } area 1.1.1.1{ interface eth1 { /* link-type: "broadcast" */ vif eth1 { address 192.168.16.20 { priority: 9 hello-interval: 10 router-dead-interval: 40 /*interface-cost: 1*/ /*retransmit-interval: 5*/ /*transit-delay: 1 */ /* authentication { simple-password: "password"; md5 @: u32 { password: "password"; start-time: "2006-01-01.12:00" end-time: "2007-01-01.12:00" max-time-drift: 3600 } } */ } } } } } } plumbing { mfea4 { disable: false interface eth0 { vif eth0 { disable: false } } interface eth1 { vif eth1 { disable: false } } interface register_vif { vif register_vif { /* Note: this vif should be always enabled */ disable: false } } traceoptions { flag all { disable: false } } } } /* * Note: fib2mrib is needed for multicast only if the unicast protocols * don't populate the MRIB with multicast-specific routes. */ protocols { fib2mrib { disable: false } } */ON 2nd ABR's configuration file./* ------------------------------------------------------------------------ /* $XORP: xorp/rtrmgr/config.boot.sample,v 1.46 2007/03/12 10:16:05 atanu Exp $ */ interfaces { restore-original-config-on-shutdown: false interface eth0 { description: "data interface" disable: false /*default-system-config*/ vif eth0 { disable: false address 192.168.14.2 { prefix-length: 24 broadcast: 192.168.14.255 disable: false } } } interface eth1 { description: "data interface" disable: false /*default-system-config*/ vif eth1 { disable: false address 192.168.16.201 { prefix-length: 24 broadcast: 192.168.16.255 disable: false } } } } fea { unicast-forwarding4 { disable: false forwarding-entries { retain-on-startup: false retain-on-shutdown: false } } } protocols { ospf4 { router-id: 10.10.10.11 /* export: "static" */ traceoptions { flag { all { disable: false } } } area 0.0.0.0{ virtual-link 10.10.10.10{ transit-area: 1.1.1.1 } interface eth0 { /* link-type: "broadcast" */ vif eth0 { address 192.168.14.2 { priority: 7 hello-interval: 10 router-dead-interval: 40 /*interface-cost: 1*/ /*retransmit-interval: 5*/ /*transit-delay: 1 */ /* authentication { simple-password: "password"; md5 @: u32 { password: "password"; start-time: "2006-01-01.12:00" end-time: "2007-01-01.12:00" max-time-drift: 3600 } } */ /* passive: false */ /* disable: false */ } } } } area 1.1.1.1{ interface eth1 { /* link-type: "broadcast" */ vif eth1 { address 192.168.16.201 { priority: 6 hello-interval: 10 router-dead-interval: 40 /*interface-cost: 1*/ /*retransmit-interval: 5*/ /*transit-delay: 1 */ /* authentication { simple-password: "password"; md5 @: u32 { password: "password"; start-time: "2006-01-01.12:00" end-time: "2007-01-01.12:00" max-time-drift: 3600 } } */ /* passive: false */ /* disable: false */ } } } } } } plumbing { mfea4 { disable: false interface eth0 { vif eth0 { disable: false } } interface eth1 { vif eth1 { disable: false } } interface register_vif { vif register_vif { /* Note: this vif should be always enabled */ disable: false } } traceoptions { flag all { disable: false } } } } /* * Note: fib2mrib is needed for multicast only if the unicast protocols * don't populate the MRIB with multicast-specific routes. */ protocols { fib2mrib { disable: false } } -- _____________________________________________________________________ Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated.Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. __________________________________________________________________________ From bms at incunabulum.net Fri Oct 24 06:31:14 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Fri, 24 Oct 2008 14:31:14 +0100 Subject: [Xorp-users] [OSPFv2] Router Crash] In-Reply-To: <4901729F.3080401@einfochips.com> References: <4901729F.3080401@einfochips.com> Message-ID: <4901CE22.1020609@incunabulum.net> karnik wrote: > I am doing some testing work of ospf with xorp for configuring virtual > link between two ABRs. at that time i have noticed following errors in > xorp. > At that time xorp is giving following errors and crash : > i don't understand what happens, tell me why this happen with xorp . > Can you tell us which version of XORP you are running? Problems like this involving virtual links should have been fixed since the last release, please see revision 1.152 of xorp/ospf/peer.hh. You may need to use CVS sources to get things running. thanks, BMS From atanu at xorp.org Fri Oct 24 08:17:59 2008 From: atanu at xorp.org (Atanu Ghosh) Date: Fri, 24 Oct 2008 08:17:59 -0700 Subject: [Xorp-users] [OSPFv2] Router Crash] In-Reply-To: Message from karnik of "Fri, 24 Oct 2008 12:30:47 +0530." <4901729F.3080401@einfochips.com> Message-ID: <65293.1224861479@xorps.icir.org> Hi, This problem was fixed after the latest release: http://bugzilla.xorp.org/bugzilla/show_bug.cgi?id=779 The patch included with the bug entry should solve your problem. Atanu. >>>>> "karnik" == karnik writes: karnik> I am doing some testing work of ospf with xorp for karnik> configuring virtual link between two ABRs. at that time i karnik> have noticed following errors in xorp. At that time xorp is karnik> giving following errors and crash : i don't understand what karnik> happens, tell me why this happen with xorp . karnik> /*/*I have attached the scenario and configuration file of karnik> both ABRs that i have created to configure the virtual karnik> link. */ */ karnik> /**/ON 1st ABR i have found following errors in xorp./* */ karnik> [ 2008/10/24 11:42:30 FATAL xorp_ospfv2:3594 OSPF +85 karnik> peer.hh karnik> get_interface_prefix_length ] Assertion (0 != karnik> _interface_prefix_length) failed [ 2008/10/24 11:42:30 ERROR karnik> xorp_rtrmgr:3567 RTRMGR +747 module_manager.cc done_cb ] karnik> Command "/usr/local/xorp/ospf/xorp_ospfv2": terminated with karnik> signal 6. [ 2008/10/24 11:42:30 INFO xorp_rtrmgr:3567 karnik> RTRMGR +294 module_manager.cc module_exited ] Module karnik> abnormally killed: ospf4 [ 2008/10/24 11:42:30 INFO xorp_rib karnik> RIB ] Received death event for protocol ospfv2 shutting down karnik> ------- OriginTable: ospf IGP next table = Redist:ospf [ karnik> 2008/10/24 11:42:30 INFO xorp_rib RIB ] Received death event karnik> for protocol ospfv2 shutting down ------- OriginTable: ospf karnik> IGP next table = Redist:ospf [ 2008/10/24 11:42:30 INFO karnik> xorp_rib RIB ] Received death event for protocol ospfv2 karnik> shutting down ------- OriginTable: ospf IGP next table = karnik> Redist:ospf karnik> /*/*ON 2nd ABR i have found following errors in xorp. */ karnik> */[2008/10/24 11:42:30 FATAL xorp_ospfv2:3594 OSPF +85 karnik> peer.hh get_interface_prefix_length ] Assertion (0 != karnik> _interface_prefix_length) failed [ 2008/10/24 11:42:30 ERROR karnik> xorp_rtrmgr:3567 RTRMGR +747 module_manager.cc done_cb ] karnik> Command "/usr/local/xorp/ospf/xorp_ospfv2": terminated with karnik> signal 6. [ 2008/10/24 11:42:30 INFO xorp_rtrmgr:3567 karnik> RTRMGR +294 module_manager.cc module_exited ] Module karnik> abnormally killed: ospf4 [ 2008/10/24 11:42:30 INFO xorp_rib karnik> RIB ] Received death event for protocol ospfv2 shutting down karnik> ------- OriginTable: ospf IGP next table = Redist:ospf [ karnik> 2008/10/24 11:42:30 INFO xorp_rib RIB ] Received death event karnik> for protocol ospfv2 shutting down ------- OriginTable: ospf karnik> IGP next table = Redist:ospf [ 2008/10/24 11:42:30 INFO karnik> xorp_rib RIB ] Received death event for protocol ospfv2 karnik> shutting down ------- OriginTable: ospf IGP next table = karnik> Redist:ospf [ 2008/10/24 11:42:30 INFO xorp_rib RIB ] karnik> Received death event for protocol ospfv2 shutting down karnik> ------- OriginTable: ospf IGP next table = Redist:ospf rib karnik> RIB ] Received death event for protocol ospfv2 shutting down karnik> ------- OriginTable: ospf IGP next table = Redist:ospf karnik> /*Test Setup: Test Setup karnik> */ karnik> */ON 1st ABR's configuration file./* karnik> ------------------------------------------------------------------------ karnik> /* $XORP: xorp/rtrmgr/config.boot.sample,v 1.46 2007/03/12 karnik> 10:16:05 atanu Exp $ */ karnik> interfaces { restore-original-config-on-shutdown: false karnik> interface eth0 { description: "data interface" disable: karnik> false /*default-system-config*/ vif eth0 { disable: false karnik> address 192.168.14.1 { prefix-length: 24 broadcast: karnik> 192.168.14.255 disable: false } } } karnik> interface eth1 { description: "data interface" disable: karnik> false /*default-system-config*/ vif eth1 { disable: false karnik> address 192.168.16.20{ prefix-length: 24 broadcast: karnik> 192.168.16.255 disable: false } } } karnik> } karnik> fea { unicast-forwarding4 { disable: false karnik> forwarding-entries { retain-on-startup: false karnik> retain-on-shutdown: false } } } karnik> protocols { ospf4 { router-id: 10.10.10.10 /* export: karnik> "static" */ karnik> traceoptions { flag { all { disable: false } } } karnik> area 0.0.0.0{ virtual-link 10.10.10.11{ transit-area: karnik> 1.1.1.1 } interface eth0 { /* link-type: "broadcast" */ vif karnik> eth0 { address 192.168.14.1 { priority: 1 hello-interval: 10 karnik> router-dead-interval: 40 /*interface-cost: 1*/ karnik> /*retransmit-interval: 5*/ /*transit-delay: 1 */ karnik> /* authentication { simple-password: "password"; karnik> md5 @: u32 { password: "password"; karnik> start-time: "2006-01-01.12:00" end-time: "2007-01-01.12:00" karnik> max-time-drift: 3600 } } */ karnik> /* passive: false */ karnik> /* disable: false */ karnik> } } } } area 1.1.1.1{ interface eth1 { /* karnik> link-type: "broadcast" */ vif eth1 { address 192.168.16.20 { karnik> priority: 9 hello-interval: 10 router-dead-interval: 40 karnik> /*interface-cost: 1*/ /*retransmit-interval: 5*/ karnik> /*transit-delay: 1 */ karnik> /* authentication { simple-password: "password"; karnik> md5 @: u32 { password: karnik> "password"; start-time: "2006-01-01.12:00" end-time: karnik> "2007-01-01.12:00" max-time-drift: 3600 } } */ karnik> } } } } karnik> } } karnik> plumbing { mfea4 { disable: false interface eth0 { vif eth0 karnik> { disable: false } } karnik> interface eth1 { vif eth1 { disable: false } } karnik> interface register_vif { vif register_vif { /* Note: karnik> this vif should be always enabled */ disable: false } } karnik> traceoptions { flag all { disable: false } } } } karnik> /* * Note: fib2mrib is needed for multicast only if the karnik> unicast protocols * don't populate the MRIB with karnik> multicast-specific routes. */ protocols { fib2mrib { karnik> disable: false } } karnik> */ON 2nd ABR's configuration file./* karnik> ------------------------------------------------------------------------ karnik> /* $XORP: xorp/rtrmgr/config.boot.sample,v 1.46 2007/03/12 karnik> 10:16:05 atanu Exp $ */ karnik> interfaces { restore-original-config-on-shutdown: false karnik> interface eth0 { description: "data interface" disable: karnik> false /*default-system-config*/ vif eth0 { disable: false karnik> address 192.168.14.2 { prefix-length: 24 broadcast: karnik> 192.168.14.255 disable: false } } } karnik> interface eth1 { description: "data interface" disable: karnik> false /*default-system-config*/ vif eth1 { disable: false karnik> address 192.168.16.201 { prefix-length: 24 broadcast: karnik> 192.168.16.255 disable: false } } } karnik> } karnik> fea { unicast-forwarding4 { disable: false karnik> forwarding-entries { retain-on-startup: false karnik> retain-on-shutdown: false } } } karnik> protocols { ospf4 { router-id: 10.10.10.11 /* export: karnik> "static" */ karnik> traceoptions { flag { all { disable: false } } } area karnik> 0.0.0.0{ virtual-link 10.10.10.10{ transit-area: 1.1.1.1 } karnik> interface eth0 { /* link-type: "broadcast" */ vif eth0 { karnik> address 192.168.14.2 { priority: 7 hello-interval: 10 karnik> router-dead-interval: 40 /*interface-cost: 1*/ karnik> /*retransmit-interval: 5*/ /*transit-delay: 1 */ karnik> /* authentication { simple-password: "password"; karnik> md5 @: u32 { password: "password"; karnik> start-time: "2006-01-01.12:00" end-time: "2007-01-01.12:00" karnik> max-time-drift: 3600 } } */ karnik> /* passive: false */ karnik> /* disable: false */ karnik> } } } } karnik> area 1.1.1.1{ interface eth1 { /* link-type: "broadcast" karnik> */ vif eth1 { address 192.168.16.201 { priority: 6 karnik> hello-interval: 10 router-dead-interval: 40 karnik> /*interface-cost: 1*/ /*retransmit-interval: 5*/ karnik> /*transit-delay: 1 */ karnik> /* authentication { simple-password: "password"; karnik> md5 @: u32 { password: karnik> "password"; start-time: "2006-01-01.12:00" end-time: karnik> "2007-01-01.12:00" max-time-drift: 3600 } } */ karnik> /* passive: false */ karnik> /* disable: false */ karnik> } } } } } } karnik> plumbing { mfea4 { disable: false interface eth0 { vif eth0 karnik> { disable: false } } karnik> interface eth1 { vif eth1 { disable: false } } karnik> interface register_vif { vif register_vif { /* Note: karnik> this vif should be always enabled */ disable: false } } karnik> traceoptions { flag all { disable: false } } } } karnik> /* * Note: fib2mrib is needed for multicast only if the karnik> unicast protocols * don't populate the MRIB with karnik> multicast-specific routes. */ protocols { fib2mrib { karnik> disable: false } } karnik> -- karnik> _____________________________________________________________________ karnik> Disclaimer: This e-mail message and all attachments karnik> transmitted with it are intended solely for the use of the karnik> addressee and may contain legally privileged and karnik> confidential information. If the reader of this message is karnik> not the intended recipient, or an employee or agent karnik> responsible for delivering this message to the intended karnik> recipient, you are hereby notified that any dissemination, karnik> distribution, copying, or other use of this message or its karnik> attachments is strictly prohibited. If you have received karnik> this message in error, please notify the sender immediately karnik> by replying to this message and please delete it from your karnik> computer. Any views expressed in this message are those of karnik> the individual sender unless otherwise stated.Company has karnik> taken enough precautions to prevent the spread of karnik> viruses. However the company accepts no liability for any karnik> damage caused by any virus transmitted by this email. karnik> __________________________________________________________________________ karnik> _______________________________________________ Xorp-users karnik> mailing list Xorp-users at xorp.org karnik> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From karnik.jain at einfochips.com Thu Oct 23 23:48:38 2008 From: karnik.jain at einfochips.com (karnik) Date: Fri, 24 Oct 2008 12:18:38 +0530 Subject: [Xorp-users] [OSPFv2] Router Crash Message-ID: <49016FC6.20208@einfochips.com> I am doing some testing work of ospf with xorp for configuring virtual link between two ABRs. at that time i have noticed following errors in xorp. At that time xorp is giving following errors and crash : i don't understand what happens, tell me why this happen with xorp . /*I have attached the scenario and configuration file of both ABRs that i have created to configure the virtual link. */ */ON 1st ABR i have found following errors in xorp./* [ 2008/10/24 11:42:30 FATAL xorp_ospfv2:3594 OSPF +85 peer.hh get_interface_prefix_length ] Assertion (0 != _interface_prefix_length) failed [ 2008/10/24 11:42:30 ERROR xorp_rtrmgr:3567 RTRMGR +747 module_manager.cc done_cb ] Command "/usr/local/xorp/ospf/xorp_ospfv2": terminated with signal 6. [ 2008/10/24 11:42:30 INFO xorp_rtrmgr:3567 RTRMGR +294 module_manager.cc module_exited ] Module abnormally killed: ospf4 [ 2008/10/24 11:42:30 INFO xorp_rib RIB ] Received death event for protocol ospfv2 shutting down ------- OriginTable: ospf IGP next table = Redist:ospf [ 2008/10/24 11:42:30 INFO xorp_rib RIB ] Received death event for protocol ospfv2 shutting down ------- OriginTable: ospf IGP next table = Redist:ospf [ 2008/10/24 11:42:30 INFO xorp_rib RIB ] Received death event for protocol ospfv2 shutting down ------- OriginTable: ospf IGP next table = Redist:ospf /*ON 2nd ABR i have found following errors in xorp. */[2008/10/24 11:42:30 FATAL xorp_ospfv2:3594 OSPF +85 peer.hh get_interface_prefix_length ] Assertion (0 != _interface_prefix_length) failed [ 2008/10/24 11:42:30 ERROR xorp_rtrmgr:3567 RTRMGR +747 module_manager.cc done_cb ] Command "/usr/local/xorp/ospf/xorp_ospfv2": terminated with signal 6. [ 2008/10/24 11:42:30 INFO xorp_rtrmgr:3567 RTRMGR +294 module_manager.cc module_exited ] Module abnormally killed: ospf4 [ 2008/10/24 11:42:30 INFO xorp_rib RIB ] Received death event for protocol ospfv2 shutting down ------- OriginTable: ospf IGP next table = Redist:ospf [ 2008/10/24 11:42:30 INFO xorp_rib RIB ] Received death event for protocol ospfv2 shutting down ------- OriginTable: ospf IGP next table = Redist:ospf [ 2008/10/24 11:42:30 INFO xorp_rib RIB ] Received death event for protocol ospfv2 shutting down ------- OriginTable: ospf IGP next table = Redist:ospf [ 2008/10/24 11:42:30 INFO xorp_rib RIB ] Received death event for protocol ospfv2 shutting down ------- OriginTable: ospf IGP next table = Redist:ospf rib RIB ] Received death event for protocol ospfv2 shutting down ------- OriginTable: ospf IGP next table = Redist:ospf -- _____________________________________________________________________ Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated.Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. __________________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: OSPF.doc Type: application/msword Size: 28672 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20081024/0f285b48/attachment-0001.doc -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: config.boot.sample_ABR1 Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20081024/0f285b48/attachment-0002.ksh -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: config.boot.sample_ABR2 Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20081024/0f285b48/attachment-0003.ksh From dikshie at gmail.com Mon Oct 27 06:30:40 2008 From: dikshie at gmail.com (dikshie) Date: Mon, 27 Oct 2008 22:30:40 +0900 Subject: [Xorp-users] zebra syntax to xorp syntax Message-ID: <910e60e80810270630x5192adc7o96699eac348ad309@mail.gmail.com> Hi, what's the equivalent syntax below in zebra to xorp? 1. multicast 2.no ipv6 nd suppress-ra 3.ipv6 nd prefix-advertisement 2001:xxx:yyy::/48 592000 604800 onlink autoconfig regards, -- -dikshie- From bms at incunabulum.net Fri Oct 31 03:18:18 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Fri, 31 Oct 2008 10:18:18 +0000 Subject: [Xorp-users] zebra syntax to xorp syntax In-Reply-To: <910e60e80810270630x5192adc7o96699eac348ad309@mail.gmail.com> References: <910e60e80810270630x5192adc7o96699eac348ad309@mail.gmail.com> Message-ID: <490ADB6A.8040604@incunabulum.net> Hello, Sorry for the delay in responding to your message. Most of the development team is currently tied up in preparing for the XORP 1.6 release. dikshie wrote: > Hi, > what's the equivalent syntax below in zebra to xorp? > 1. multicast > Please see chapters 11 and 12 of the User Manual for a basic overview of the syntax. For an example please refer to the files rtrmgr/config/multicast4.boot and rtrmgr/config/multicast6.boot. Multicast forwarding is not enabled using a single separate switch as such, however your attention is drawn to the "plumbing" configuration block in these examples. Please refer to User Manual section 2.4.5. > 2.no ipv6 nd suppress-ra > Actually, XORP doesn't support IPv6 Router Advertisement out-of-the-box. Generally this has to be configured using an OS-dependent mechanism, e.g. the rtadvd daemon, as found in KAME derived systems such as FreeBSD. We would very much welcome patches for adding the necessary ICMPv6 support, perhaps as a separate XORP process, or as a patch for the FEA. > 3.ipv6 nd prefix-advertisement 2001:xxx:yyy::/48 592000 604800 onlink autoconfig > Again, supporting this option would require a patch. thanks again BMS From karnik.jain at einfochips.com Fri Oct 31 03:55:49 2008 From: karnik.jain at einfochips.com (karnik) Date: Fri, 31 Oct 2008 16:25:49 +0530 Subject: [Xorp-users] [OSPFv2] Router Crash] In-Reply-To: <490AD70C.4030403@incunabulum.net> References: <4901729F.3080401@einfochips.com> <4901CE22.1020609@incunabulum.net> <490AAAC0.9000201@einfochips.com> <490AD70C.4030403@incunabulum.net> Message-ID: <490AE435.2090607@einfochips.com> Bruce M Simpson wrote: > karnik wrote: >> I am using xorp-1.5 >> system: RHEL4 >> kernal version: 2.6.9-42.ELsmp > > Thanks, can you Cc: this and my reply to the xorp-users@ list? > > XORP 1.5 lacks the patch Atanu pointed you at, which fixes the virtual > link problem you saw. > > thanks > BMS > >> >> Bruce M Simpson wrote: >>> karnik wrote: >>>> I am doing some testing work of ospf with xorp for configuring >>>> virtual link between two ABRs. at that time i have noticed >>>> following errors in xorp. >>>> At that time xorp is giving following errors and crash : >>>> i don't understand what happens, tell me why this happen with xorp . >>>> >>> >>> Can you tell us which version of XORP you are running? >>> >>> Problems like this involving virtual links should have been fixed >>> since the last release, please see revision 1.152 of >>> xorp/ospf/peer.hh. You may need to use CVS sources to get things >>> running. >>> >>> thanks, >>> BMS >>> >>> >>> Email Scanned for Virus & Dangerous Content by : >>> www.CleanMailGateway.com >>> >>> >> > > > > Email Scanned for Virus & Dangerous Content by : www.CleanMailGateway.com > > -- _____________________________________________________________________ Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated.Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. __________________________________________________________________________