From pavlin at icir.org Sat Sep 1 13:29:20 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Sat, 01 Sep 2007 13:29:20 -0700 Subject: [Xorp-users] Module not foudn problem In-Reply-To: Message from Chris Robson of "Fri, 31 Aug 2007 16:38:22 EDT." <46D87C3E.7000209@nrl.navy.mil> Message-ID: <200709012029.l81KTKjD023218@possum.icir.org> > Anyone now what is missing to cause this not found error? > /usr/local/sbin has the file xorp_mld. > > 2007/08/31 16:33:41 INFO xorp_rtrmgr:666 RTRMGR +96 module_manager.cc > execute ] Executing module: mld (mld6igmp/xorp_mld) > [ 2007/08/31 16:33:41 WARNING xorp_rtrmgr:666 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 "MLD" does not exist or is not enabled. Did the xorp_rtrmgr execution continue after that? Typically, this is a transient error during startup/shutdown, so if the xorp_rtrmgr execution continued then you can ignore it. Regards, Pavlin > -- > Chris > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at icir.org Sat Sep 1 22:35:04 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Sat, 01 Sep 2007 22:35:04 -0700 Subject: [Xorp-users] Module not foudn problem In-Reply-To: Message from Chris Robson of "Sat, 01 Sep 2007 18:00:36 EDT." <46D9E104.2070102@nrl.navy.mil> Message-ID: <200709020535.l825Z4XN026463@possum.icir.org> Chris Robson wrote: > > Pavlin > > Here is the complete dump, also is the "mld" section of the config file. > There is an error about invalid primary address which I assumed was being > caused because the module was being terminated. The "primary address" error is triggered because it appears eth0 doesn't have a configured IPv6 link-local address. The link-local address should be assigned by either explicitly configuring it in the "interfaces" section, or by using a configuration like: interfaces { interface eth0 { default-system-config } } The latter solution assumes that all relevant IPv4 and IPv6 addresses have been configured in advance. FYI, in the future this should be fixed in XORP such that the IPv6 link-local address will be automatically taken from the kernel even if "default-system-config" is not used. Regards, Pavlin > protocols { > mld { > disable: false > interface eth0 { > vif eth0 { > disable: false > version: 1 > enable-ip-router-alert-option-check: false > query-interval: 125 > query-last-member-interval: 1 > query-response-interval: 10 > robust-count: 2 > } > } > traceoptions { > flag all { > disable: false > } > } > } > } > > [ 2007/09/01 17:52:14 INFO xorp_rtrmgr:4757 RTRMGR +239 master_conf_tree.cc > execute ] Changed modules: interfaces, fea, mfea4, mfea6, mld, rib, fib2mrib, > igmp, pimsm4, policy, static_routes, ospf4 > [ 2007/09/01 17:52:14 INFO xorp_rtrmgr:4757 RTRMGR +96 module_manager.cc > execute ] Executing module: interfaces (fea/xorp_fea) > [ 2007/09/01 17:52:15 INFO xorp_fea MFEA ] MFEA enabled > [ 2007/09/01 17:52:15 INFO xorp_fea MFEA ] CLI enabled > [ 2007/09/01 17:52:15 INFO xorp_fea MFEA ] CLI started > [ 2007/09/01 17:52:15 INFO xorp_fea MFEA ] MFEA enabled > [ 2007/09/01 17:52:15 INFO xorp_fea MFEA ] CLI enabled > [ 2007/09/01 17:52:15 INFO xorp_fea MFEA ] CLI started > [ 2007/09/01 17:52:16 INFO xorp_rtrmgr:4757 RTRMGR +96 module_manager.cc > execute ] Executing module: fea (fea/xorp_fea) > [ 2007/09/01 17:52:22 INFO xorp_rtrmgr:4757 RTRMGR +96 module_manager.cc > execute ] Executing module: mfea4 (fea/xorp_fea) > [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] Interface added: Vif[eth0] > pif_index: 3 vif_index: 0 addr: 192.168.1.106 subnet: 192.168.1.0/24 > broadcast: 192.168.1.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST > UNDERLYING_VIF_UP MTU: 1500 > [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] MFEA started > [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] Interface enabled Vif[eth0] > pif_index: 3 vif_index: 0 addr: 192.168.1.106 subnet: 192.168.1.0/24 > broadcast: 192.168.1.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST > UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED > [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] Interface started: Vif[eth0] > pif_index: 3 vif_index: 0 addr: 192.168.1.106 subnet: 192.168.1.0/24 > broadcast: 192.168.1.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST > UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED > [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] Interface added: Vif[register_vif] > pif_index: 3 vif_index: 1 addr: 192.168.1.106 subnet: 192.168.1.106/32 > broadcast: 192.168.1.106 peer: 0.0.0.0 Flags: PIM_REGISTER UNDERLYING_VIF_UP > MTU: 1500 > [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] Interface enabled Vif[register_vif] > pif_index: 3 vif_index: 1 addr: 192.168.1.106 subnet: 192.168.1.106/32 > broadcast: 192.168.1.106 peer: 0.0.0.0 Flags: PIM_REGISTER UNDERLYING_VIF_UP > MTU: 1500 DOWN IPv4 ENABLED > [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] Interface started: > Vif[register_vif] pif_index: 3 vif_index: 1 addr: 192.168.1.106 subnet: > 192.168.1.106/32 broadcast: 192.168.1.106 peer: 0.0.0.0 Flags: PIM_REGISTER > UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED > [ 2007/09/01 17:52:22 INFO xorp_rtrmgr:4757 RTRMGR +96 module_manager.cc > execute ] Executing module: mfea6 (fea/xorp_fea) > [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] Interface added: Vif[eth0] > pif_index: 3 vif_index: 0 addr: 2001:480:f022:3:400:8000:0:196 subnet: > 2001:480:f022:3:400:8000::/84 broadcast: :: peer: :: Flags: MULTICAST > BROADCAST UNDERLYING_VIF_UP MTU: 1500 > [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] MFEA started > [ 2007/09/01 17:52:22 INFO xorp_rtrmgr:4757 RTRMGR +96 module_manager.cc > execute ] Executing module: mld (mld6igmp/xorp_mld) > [ 2007/09/01 17:52:22 WARNING xorp_rtrmgr:4757 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 "MLD" > does not exist or is not enabled. > [ 2007/09/01 17:52:22 INFO xorp_mld MLD6IGMP ] Protocol enabled > [ 2007/09/01 17:52:22 INFO xorp_mld MLD6IGMP ] CLI enabled > [ 2007/09/01 17:52:22 INFO xorp_mld MLD6IGMP ] CLI started > [ 2007/09/01 17:52:23 INFO xorp_mld MLD6IGMP ] Protocol started > [ 2007/09/01 17:52:23 ERROR xorp_mld:4763 MLD6IGMP +718 mld6igmp_node.cc > add_vif ] Error updating primary address for vif eth0: invalid primary address > [ 2007/09/01 17:52:24 INFO xorp_mld MLD6IGMP ] Interface enabled: Vif[eth0] > pif_index: 3 vif_index: 0 addr: 2001:480:f022:3:400:8000:0:196 subnet: > 2001:480:f022:3:400:8000::/84 broadcast: :: peer: :: Flags: MULTICAST > BROADCAST UNDERLYING_VIF_UP MTU: 1500 DOWN IPv6 ENABLED > [ 2007/09/01 17:52:24 ERROR xorp_mld:4763 MLD6IGMP +1083 mld6igmp_node.cc > start_vif ] Cannot start vif eth0: invalid primary address > [ 2007/09/01 17:52:24 WARNING xorp_mld XrlMld6igmpTarget ] Handling method for > mld6igmp/0.1/start_vif failed: XrlCmdError 102 Command failed Cannot start vif > eth0: invalid primary address > [ 2007/09/01 17:52:24 ERROR xorp_rtrmgr:4757 RTRMGR +675 master_conf_tree.cc > commit_pass2_done ] Commit failed: 102 Command failed Cannot start vif eth0: > invalid primary address > [ 2007/09/01 17:52:24 ERROR xorp_rtrmgr:4757 RTRMGR +251 master_conf_tree.cc > config_done ] Configuration failed: 102 Command failed Cannot start vif eth0: > invalid primary address > [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +2228 task.cc run_task ] > No more tasks to run > [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +171 module_manager.cc > terminate ] Terminating module: fea > [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +171 module_manager.cc > terminate ] Terminating module: interfaces > [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +171 module_manager.cc > terminate ] Terminating module: mfea4 > [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +171 module_manager.cc > terminate ] Terminating module: mfea6 > [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +194 module_manager.cc > terminate ] Killing module: mfea6 > [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +171 module_manager.cc > terminate ] Terminating module: mld > [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +194 module_manager.cc > terminate ] Killing module: mld > [ 2007/09/01 17:52:24 ERROR xorp_rtrmgr:4757 RTRMGR +747 module_manager.cc > done_cb ] Command "/usr/local/xorp/mld6igmp/xorp_mld": terminated with signal > 15. > [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +282 module_manager.cc > module_exited ] Module killed during shutdown: mld > [ 2007/09/01 17:52:24 ERROR xorp_rtrmgr:4757 RTRMGR +747 module_manager.cc > done_cb ] Command "/usr/local/xorp/fea/xorp_fea": terminated with signal 15. > [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +282 module_manager.cc > module_exited ] Module killed during shutdown: mfea6 > [root at FEON etc]# > > > > Pavlin Radoslavov wrote: > >> Anyone now what is missing to cause this not found error? /usr/local/sbin > >> has the file xorp_mld. > >> > >> 2007/08/31 16:33:41 INFO xorp_rtrmgr:666 RTRMGR +96 module_manager.cc > >> execute ] Executing module: mld (mld6igmp/xorp_mld) > >> [ 2007/08/31 16:33:41 WARNING xorp_rtrmgr:666 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 "MLD" does not exist or is not enabled. > >> > > > > Did the xorp_rtrmgr execution continue after that? > > Typically, this is a transient error during startup/shutdown, so if > > the xorp_rtrmgr execution continued then you can ignore it. > > > > Regards, > > Pavlin > > > > > >> -- > >> Chris > >> > >> _______________________________________________ > >> 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 > > > > > > > > -- > Christopher Robson > Senior Computer Scientist, GS-15 > Naval Research Laboratory > Center for Computational Science > Networking, Code 5591 > 4555 Overlook ave. > Washington, D.C. 20375-5320 > (COM) 202-404-3138 > (VoIP) 2024043138 at GIGEF > (CHAT) Chris.Robson at GIGEF From Chris.Robson at nrl.navy.mil Sat Sep 1 15:00:36 2007 From: Chris.Robson at nrl.navy.mil (Chris Robson) Date: Sat, 01 Sep 2007 18:00:36 -0400 Subject: [Xorp-users] Module not foudn problem In-Reply-To: <200709012029.l81KTKjD023218@possum.icir.org> References: <200709012029.l81KTKjD023218@possum.icir.org> Message-ID: <46D9E104.2070102@nrl.navy.mil> Pavlin Here is the complete dump, also is the "mld" section of the config file. There is an error about invalid primary address which I assumed was being caused because the module was being terminated. protocols { mld { disable: false interface eth0 { vif eth0 { disable: false version: 1 enable-ip-router-alert-option-check: false query-interval: 125 query-last-member-interval: 1 query-response-interval: 10 robust-count: 2 } } traceoptions { flag all { disable: false } } } } [ 2007/09/01 17:52:14 INFO xorp_rtrmgr:4757 RTRMGR +239 master_conf_tree.cc execute ] Changed modules: interfaces, fea, mfea4, mfea6, mld, rib, fib2mrib, igmp, pimsm4, policy, static_routes, ospf4 [ 2007/09/01 17:52:14 INFO xorp_rtrmgr:4757 RTRMGR +96 module_manager.cc execute ] Executing module: interfaces (fea/xorp_fea) [ 2007/09/01 17:52:15 INFO xorp_fea MFEA ] MFEA enabled [ 2007/09/01 17:52:15 INFO xorp_fea MFEA ] CLI enabled [ 2007/09/01 17:52:15 INFO xorp_fea MFEA ] CLI started [ 2007/09/01 17:52:15 INFO xorp_fea MFEA ] MFEA enabled [ 2007/09/01 17:52:15 INFO xorp_fea MFEA ] CLI enabled [ 2007/09/01 17:52:15 INFO xorp_fea MFEA ] CLI started [ 2007/09/01 17:52:16 INFO xorp_rtrmgr:4757 RTRMGR +96 module_manager.cc execute ] Executing module: fea (fea/xorp_fea) [ 2007/09/01 17:52:22 INFO xorp_rtrmgr:4757 RTRMGR +96 module_manager.cc execute ] Executing module: mfea4 (fea/xorp_fea) [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] Interface added: Vif[eth0] pif_index: 3 vif_index: 0 addr: 192.168.1.106 subnet: 192.168.1.0/24 broadcast: 192.168.1.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] MFEA started [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] Interface enabled Vif[eth0] pif_index: 3 vif_index: 0 addr: 192.168.1.106 subnet: 192.168.1.0/24 broadcast: 192.168.1.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] Interface started: Vif[eth0] pif_index: 3 vif_index: 0 addr: 192.168.1.106 subnet: 192.168.1.0/24 broadcast: 192.168.1.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] Interface added: Vif[register_vif] pif_index: 3 vif_index: 1 addr: 192.168.1.106 subnet: 192.168.1.106/32 broadcast: 192.168.1.106 peer: 0.0.0.0 Flags: PIM_REGISTER UNDERLYING_VIF_UP MTU: 1500 [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] Interface enabled Vif[register_vif] pif_index: 3 vif_index: 1 addr: 192.168.1.106 subnet: 192.168.1.106/32 broadcast: 192.168.1.106 peer: 0.0.0.0 Flags: PIM_REGISTER UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] Interface started: Vif[register_vif] pif_index: 3 vif_index: 1 addr: 192.168.1.106 subnet: 192.168.1.106/32 broadcast: 192.168.1.106 peer: 0.0.0.0 Flags: PIM_REGISTER UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED [ 2007/09/01 17:52:22 INFO xorp_rtrmgr:4757 RTRMGR +96 module_manager.cc execute ] Executing module: mfea6 (fea/xorp_fea) [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] Interface added: Vif[eth0] pif_index: 3 vif_index: 0 addr: 2001:480:f022:3:400:8000:0:196 subnet: 2001:480:f022:3:400:8000::/84 broadcast: :: peer: :: Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] MFEA started [ 2007/09/01 17:52:22 INFO xorp_rtrmgr:4757 RTRMGR +96 module_manager.cc execute ] Executing module: mld (mld6igmp/xorp_mld) [ 2007/09/01 17:52:22 WARNING xorp_rtrmgr:4757 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 "MLD" does not exist or is not enabled. [ 2007/09/01 17:52:22 INFO xorp_mld MLD6IGMP ] Protocol enabled [ 2007/09/01 17:52:22 INFO xorp_mld MLD6IGMP ] CLI enabled [ 2007/09/01 17:52:22 INFO xorp_mld MLD6IGMP ] CLI started [ 2007/09/01 17:52:23 INFO xorp_mld MLD6IGMP ] Protocol started [ 2007/09/01 17:52:23 ERROR xorp_mld:4763 MLD6IGMP +718 mld6igmp_node.cc add_vif ] Error updating primary address for vif eth0: invalid primary address [ 2007/09/01 17:52:24 INFO xorp_mld MLD6IGMP ] Interface enabled: Vif[eth0] pif_index: 3 vif_index: 0 addr: 2001:480:f022:3:400:8000:0:196 subnet: 2001:480:f022:3:400:8000::/84 broadcast: :: peer: :: Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 DOWN IPv6 ENABLED [ 2007/09/01 17:52:24 ERROR xorp_mld:4763 MLD6IGMP +1083 mld6igmp_node.cc start_vif ] Cannot start vif eth0: invalid primary address [ 2007/09/01 17:52:24 WARNING xorp_mld XrlMld6igmpTarget ] Handling method for mld6igmp/0.1/start_vif failed: XrlCmdError 102 Command failed Cannot start vif eth0: invalid primary address [ 2007/09/01 17:52:24 ERROR xorp_rtrmgr:4757 RTRMGR +675 master_conf_tree.cc commit_pass2_done ] Commit failed: 102 Command failed Cannot start vif eth0: invalid primary address [ 2007/09/01 17:52:24 ERROR xorp_rtrmgr:4757 RTRMGR +251 master_conf_tree.cc config_done ] Configuration failed: 102 Command failed Cannot start vif eth0: invalid primary address [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +2228 task.cc run_task ] No more tasks to run [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +171 module_manager.cc terminate ] Terminating module: fea [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +171 module_manager.cc terminate ] Terminating module: interfaces [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +171 module_manager.cc terminate ] Terminating module: mfea4 [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +171 module_manager.cc terminate ] Terminating module: mfea6 [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +194 module_manager.cc terminate ] Killing module: mfea6 [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +171 module_manager.cc terminate ] Terminating module: mld [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +194 module_manager.cc terminate ] Killing module: mld [ 2007/09/01 17:52:24 ERROR xorp_rtrmgr:4757 RTRMGR +747 module_manager.cc done_cb ] Command "/usr/local/xorp/mld6igmp/xorp_mld": terminated with signal 15. [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +282 module_manager.cc module_exited ] Module killed during shutdown: mld [ 2007/09/01 17:52:24 ERROR xorp_rtrmgr:4757 RTRMGR +747 module_manager.cc done_cb ] Command "/usr/local/xorp/fea/xorp_fea": terminated with signal 15. [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +282 module_manager.cc module_exited ] Module killed during shutdown: mfea6 [root at FEON etc]# Pavlin Radoslavov wrote: >> Anyone now what is missing to cause this not found error? >> /usr/local/sbin has the file xorp_mld. >> >> 2007/08/31 16:33:41 INFO xorp_rtrmgr:666 RTRMGR +96 module_manager.cc >> execute ] Executing module: mld (mld6igmp/xorp_mld) >> [ 2007/08/31 16:33:41 WARNING xorp_rtrmgr:666 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 "MLD" does not exist or is not enabled. >> > > Did the xorp_rtrmgr execution continue after that? > Typically, this is a transient error during startup/shutdown, so if > the xorp_rtrmgr execution continued then you can ignore it. > > Regards, > Pavlin > > >> -- >> Chris >> >> _______________________________________________ >> 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 > > > -- Christopher Robson Senior Computer Scientist, GS-15 Naval Research Laboratory Center for Computational Science Networking, Code 5591 4555 Overlook ave. Washington, D.C. 20375-5320 (COM) 202-404-3138 (VoIP) 2024043138 at GIGEF (CHAT) Chris.Robson at GIGEF From Chris.Robson at nrl.navy.mil Sun Sep 2 03:24:52 2007 From: Chris.Robson at nrl.navy.mil (Chris Robson) Date: Sun, 02 Sep 2007 06:24:52 -0400 Subject: [Xorp-users] Module not foudn problem In-Reply-To: <200709020535.l825Z4XN026463@possum.icir.org> References: <200709020535.l825Z4XN026463@possum.icir.org> Message-ID: <46DA8F74.3020008@nrl.navy.mil> Pavlin According to the "ip addr" command as shown below, there is a link local address. I wonder if there is an issue with xorp and linux kernel 2.6.22. Every since 2.6.18 a lot of IP stack things have broken. Could yo save me some time, where does xorp test for this? Then I can poke around and see what is happening. 3: eth0: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:1a:6b:69:a8:75 brd ff:ff:ff:ff:ff:ff inet 192.168.1.109/24 brd 192.168.1.255 scope global eth0 inet 192.168.1.106/24 brd 192.168.1.255 scope global secondary eth0 inet6 2001:480:f022:3:400:8000:0:196/84 scope global valid_lft forever preferred_lft forever inet6 fe80::21a:6bff:fe69:a875/64 scope link valid_lft forever preferred_lft forever .....chris Pavlin Radoslavov wrote: > Chris Robson wrote: > > >> Pavlin >> >> Here is the complete dump, also is the "mld" section of the config file. >> There is an error about invalid primary address which I assumed was being >> caused because the module was being terminated. >> > > The "primary address" error is triggered because it appears eth0 > doesn't have a configured IPv6 link-local address. The link-local > address should be assigned by either explicitly configuring it in > the "interfaces" section, or by using a configuration like: > > interfaces { > interface eth0 { > default-system-config > } > } > > The latter solution assumes that all relevant IPv4 and IPv6 > addresses have been configured in advance. > > FYI, in the future this should be fixed in XORP such that the IPv6 > link-local address will be automatically taken from the kernel even > if "default-system-config" is not used. > > Regards, > Pavlin > > >> protocols { >> mld { >> disable: false >> interface eth0 { >> vif eth0 { >> disable: false >> version: 1 >> enable-ip-router-alert-option-check: false >> query-interval: 125 >> query-last-member-interval: 1 >> query-response-interval: 10 >> robust-count: 2 >> } >> } >> traceoptions { >> flag all { >> disable: false >> } >> } >> } >> } >> >> [ 2007/09/01 17:52:14 INFO xorp_rtrmgr:4757 RTRMGR +239 master_conf_tree.cc >> execute ] Changed modules: interfaces, fea, mfea4, mfea6, mld, rib, fib2mrib, >> igmp, pimsm4, policy, static_routes, ospf4 >> [ 2007/09/01 17:52:14 INFO xorp_rtrmgr:4757 RTRMGR +96 module_manager.cc >> execute ] Executing module: interfaces (fea/xorp_fea) >> [ 2007/09/01 17:52:15 INFO xorp_fea MFEA ] MFEA enabled >> [ 2007/09/01 17:52:15 INFO xorp_fea MFEA ] CLI enabled >> [ 2007/09/01 17:52:15 INFO xorp_fea MFEA ] CLI started >> [ 2007/09/01 17:52:15 INFO xorp_fea MFEA ] MFEA enabled >> [ 2007/09/01 17:52:15 INFO xorp_fea MFEA ] CLI enabled >> [ 2007/09/01 17:52:15 INFO xorp_fea MFEA ] CLI started >> [ 2007/09/01 17:52:16 INFO xorp_rtrmgr:4757 RTRMGR +96 module_manager.cc >> execute ] Executing module: fea (fea/xorp_fea) >> [ 2007/09/01 17:52:22 INFO xorp_rtrmgr:4757 RTRMGR +96 module_manager.cc >> execute ] Executing module: mfea4 (fea/xorp_fea) >> [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] Interface added: Vif[eth0] >> pif_index: 3 vif_index: 0 addr: 192.168.1.106 subnet: 192.168.1.0/24 >> broadcast: 192.168.1.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST >> UNDERLYING_VIF_UP MTU: 1500 >> [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] MFEA started >> [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] Interface enabled Vif[eth0] >> pif_index: 3 vif_index: 0 addr: 192.168.1.106 subnet: 192.168.1.0/24 >> broadcast: 192.168.1.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST >> UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED >> [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] Interface started: Vif[eth0] >> pif_index: 3 vif_index: 0 addr: 192.168.1.106 subnet: 192.168.1.0/24 >> broadcast: 192.168.1.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST >> UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED >> [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] Interface added: Vif[register_vif] >> pif_index: 3 vif_index: 1 addr: 192.168.1.106 subnet: 192.168.1.106/32 >> broadcast: 192.168.1.106 peer: 0.0.0.0 Flags: PIM_REGISTER UNDERLYING_VIF_UP >> MTU: 1500 >> [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] Interface enabled Vif[register_vif] >> pif_index: 3 vif_index: 1 addr: 192.168.1.106 subnet: 192.168.1.106/32 >> broadcast: 192.168.1.106 peer: 0.0.0.0 Flags: PIM_REGISTER UNDERLYING_VIF_UP >> MTU: 1500 DOWN IPv4 ENABLED >> [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] Interface started: >> Vif[register_vif] pif_index: 3 vif_index: 1 addr: 192.168.1.106 subnet: >> 192.168.1.106/32 broadcast: 192.168.1.106 peer: 0.0.0.0 Flags: PIM_REGISTER >> UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED >> [ 2007/09/01 17:52:22 INFO xorp_rtrmgr:4757 RTRMGR +96 module_manager.cc >> execute ] Executing module: mfea6 (fea/xorp_fea) >> [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] Interface added: Vif[eth0] >> pif_index: 3 vif_index: 0 addr: 2001:480:f022:3:400:8000:0:196 subnet: >> 2001:480:f022:3:400:8000::/84 broadcast: :: peer: :: Flags: MULTICAST >> BROADCAST UNDERLYING_VIF_UP MTU: 1500 >> [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] MFEA started >> [ 2007/09/01 17:52:22 INFO xorp_rtrmgr:4757 RTRMGR +96 module_manager.cc >> execute ] Executing module: mld (mld6igmp/xorp_mld) >> [ 2007/09/01 17:52:22 WARNING xorp_rtrmgr:4757 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 "MLD" >> does not exist or is not enabled. >> [ 2007/09/01 17:52:22 INFO xorp_mld MLD6IGMP ] Protocol enabled >> [ 2007/09/01 17:52:22 INFO xorp_mld MLD6IGMP ] CLI enabled >> [ 2007/09/01 17:52:22 INFO xorp_mld MLD6IGMP ] CLI started >> [ 2007/09/01 17:52:23 INFO xorp_mld MLD6IGMP ] Protocol started >> [ 2007/09/01 17:52:23 ERROR xorp_mld:4763 MLD6IGMP +718 mld6igmp_node.cc >> add_vif ] Error updating primary address for vif eth0: invalid primary address >> [ 2007/09/01 17:52:24 INFO xorp_mld MLD6IGMP ] Interface enabled: Vif[eth0] >> pif_index: 3 vif_index: 0 addr: 2001:480:f022:3:400:8000:0:196 subnet: >> 2001:480:f022:3:400:8000::/84 broadcast: :: peer: :: Flags: MULTICAST >> BROADCAST UNDERLYING_VIF_UP MTU: 1500 DOWN IPv6 ENABLED >> [ 2007/09/01 17:52:24 ERROR xorp_mld:4763 MLD6IGMP +1083 mld6igmp_node.cc >> start_vif ] Cannot start vif eth0: invalid primary address >> [ 2007/09/01 17:52:24 WARNING xorp_mld XrlMld6igmpTarget ] Handling method for >> mld6igmp/0.1/start_vif failed: XrlCmdError 102 Command failed Cannot start vif >> eth0: invalid primary address >> [ 2007/09/01 17:52:24 ERROR xorp_rtrmgr:4757 RTRMGR +675 master_conf_tree.cc >> commit_pass2_done ] Commit failed: 102 Command failed Cannot start vif eth0: >> invalid primary address >> [ 2007/09/01 17:52:24 ERROR xorp_rtrmgr:4757 RTRMGR +251 master_conf_tree.cc >> config_done ] Configuration failed: 102 Command failed Cannot start vif eth0: >> invalid primary address >> [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +2228 task.cc run_task ] >> No more tasks to run >> [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +171 module_manager.cc >> terminate ] Terminating module: fea >> [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +171 module_manager.cc >> terminate ] Terminating module: interfaces >> [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +171 module_manager.cc >> terminate ] Terminating module: mfea4 >> [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +171 module_manager.cc >> terminate ] Terminating module: mfea6 >> [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +194 module_manager.cc >> terminate ] Killing module: mfea6 >> [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +171 module_manager.cc >> terminate ] Terminating module: mld >> [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +194 module_manager.cc >> terminate ] Killing module: mld >> [ 2007/09/01 17:52:24 ERROR xorp_rtrmgr:4757 RTRMGR +747 module_manager.cc >> done_cb ] Command "/usr/local/xorp/mld6igmp/xorp_mld": terminated with signal >> 15. >> [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +282 module_manager.cc >> module_exited ] Module killed during shutdown: mld >> [ 2007/09/01 17:52:24 ERROR xorp_rtrmgr:4757 RTRMGR +747 module_manager.cc >> done_cb ] Command "/usr/local/xorp/fea/xorp_fea": terminated with signal 15. >> [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +282 module_manager.cc >> module_exited ] Module killed during shutdown: mfea6 >> [root at FEON etc]# >> >> >> >> Pavlin Radoslavov wrote: >> >>>> Anyone now what is missing to cause this not found error? /usr/local/sbin >>>> has the file xorp_mld. >>>> >>>> 2007/08/31 16:33:41 INFO xorp_rtrmgr:666 RTRMGR +96 module_manager.cc >>>> execute ] Executing module: mld (mld6igmp/xorp_mld) >>>> [ 2007/08/31 16:33:41 WARNING xorp_rtrmgr:666 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 "MLD" does not exist or is not enabled. >>>> >>>> >>> Did the xorp_rtrmgr execution continue after that? >>> Typically, this is a transient error during startup/shutdown, so if >>> the xorp_rtrmgr execution continued then you can ignore it. >>> >>> Regards, >>> Pavlin >>> >>> >>> >>>> -- >>>> Chris >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >>> >>> >> -- >> Christopher Robson >> Senior Computer Scientist, GS-15 >> Naval Research Laboratory >> Center for Computational Science >> Networking, Code 5591 >> 4555 Overlook ave. >> Washington, D.C. 20375-5320 >> (COM) 202-404-3138 >> (VoIP) 2024043138 at GIGEF >> (CHAT) Chris.Robson at GIGEF >> > > > -- Christopher Robson Senior Computer Scientist, GS-15 Naval Research Laboratory Center for Computational Science Networking, Code 5591 4555 Overlook ave. Washington, D.C. 20375-5320 (COM) 202-404-3138 (VoIP) 2024043138 at GIGEF (CHAT) Chris.Robson at GIGEF From pavlin at icir.org Sun Sep 2 12:35:25 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Sun, 02 Sep 2007 12:35:25 -0700 Subject: [Xorp-users] Module not foudn problem In-Reply-To: Message from Chris Robson of "Sun, 02 Sep 2007 06:24:52 EDT." <46DA8F74.3020008@nrl.navy.mil> Message-ID: <200709021935.l82JZP97032441@possum.icir.org> > According to the "ip addr" command as shown below, there is a link local > address. > I wonder if there is an issue with xorp and linux kernel 2.6.22. Every > since 2.6.18 a lot of IP stack things have broken. Could yo save me > some time, where does xorp test for this? Then I can poke around and > see what is happening. > > > 3: eth0: mtu 1500 qdisc pfifo_fast > qlen 100 > link/ether 00:1a:6b:69:a8:75 brd ff:ff:ff:ff:ff:ff > inet 192.168.1.109/24 brd 192.168.1.255 scope global eth0 > inet 192.168.1.106/24 brd 192.168.1.255 scope global secondary eth0 > inet6 2001:480:f022:3:400:8000:0:196/84 scope global > valid_lft forever preferred_lft forever > inet6 fe80::21a:6bff:fe69:a875/64 scope link > valid_lft forever preferred_lft forever Yes, the IPv6 link-local address is configured in the kernel, but that configuration needs to be propagated to XORP as well. This can be done by either: a) Explicitly configure the IP addresses inside the XORP "interfaces" section, including the link-local address. b) Implicitly configure all IP addresses by using configuration like: interfaces { interface eth0 { default-system-config } } Option (b) is probably simpler in your case, so this is what I'd recommend you do for now. If you still get the same MLD error, then please configure only the "interfaces" and "mfea6" sections, and send the output of the following xorpsh commands: show interfaces show mfea6 interface Regards, Pavlin > .....chris > > Pavlin Radoslavov wrote: > > Chris Robson wrote: > > > > > >> Pavlin > >> > >> Here is the complete dump, also is the "mld" section of the config file. > >> There is an error about invalid primary address which I assumed was being > >> caused because the module was being terminated. > >> > > > > The "primary address" error is triggered because it appears eth0 > > doesn't have a configured IPv6 link-local address. The link-local > > address should be assigned by either explicitly configuring it in > > the "interfaces" section, or by using a configuration like: > > > > interfaces { > > interface eth0 { > > default-system-config > > } > > } > > > > The latter solution assumes that all relevant IPv4 and IPv6 > > addresses have been configured in advance. > > > > FYI, in the future this should be fixed in XORP such that the IPv6 > > link-local address will be automatically taken from the kernel even > > if "default-system-config" is not used. > > > > Regards, > > Pavlin > > > > > >> protocols { > >> mld { > >> disable: false > >> interface eth0 { > >> vif eth0 { > >> disable: false > >> version: 1 > >> enable-ip-router-alert-option-check: false > >> query-interval: 125 > >> query-last-member-interval: 1 > >> query-response-interval: 10 > >> robust-count: 2 > >> } > >> } > >> traceoptions { > >> flag all { > >> disable: false > >> } > >> } > >> } > >> } > >> > >> [ 2007/09/01 17:52:14 INFO xorp_rtrmgr:4757 RTRMGR +239 master_conf_tree.cc > >> execute ] Changed modules: interfaces, fea, mfea4, mfea6, mld, rib, fib2mrib, > >> igmp, pimsm4, policy, static_routes, ospf4 > >> [ 2007/09/01 17:52:14 INFO xorp_rtrmgr:4757 RTRMGR +96 module_manager.cc > >> execute ] Executing module: interfaces (fea/xorp_fea) > >> [ 2007/09/01 17:52:15 INFO xorp_fea MFEA ] MFEA enabled > >> [ 2007/09/01 17:52:15 INFO xorp_fea MFEA ] CLI enabled > >> [ 2007/09/01 17:52:15 INFO xorp_fea MFEA ] CLI started > >> [ 2007/09/01 17:52:15 INFO xorp_fea MFEA ] MFEA enabled > >> [ 2007/09/01 17:52:15 INFO xorp_fea MFEA ] CLI enabled > >> [ 2007/09/01 17:52:15 INFO xorp_fea MFEA ] CLI started > >> [ 2007/09/01 17:52:16 INFO xorp_rtrmgr:4757 RTRMGR +96 module_manager.cc > >> execute ] Executing module: fea (fea/xorp_fea) > >> [ 2007/09/01 17:52:22 INFO xorp_rtrmgr:4757 RTRMGR +96 module_manager.cc > >> execute ] Executing module: mfea4 (fea/xorp_fea) > >> [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] Interface added: Vif[eth0] > >> pif_index: 3 vif_index: 0 addr: 192.168.1.106 subnet: 192.168.1.0/24 > >> broadcast: 192.168.1.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST > >> UNDERLYING_VIF_UP MTU: 1500 > >> [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] MFEA started > >> [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] Interface enabled Vif[eth0] > >> pif_index: 3 vif_index: 0 addr: 192.168.1.106 subnet: 192.168.1.0/24 > >> broadcast: 192.168.1.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST > >> UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED > >> [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] Interface started: Vif[eth0] > >> pif_index: 3 vif_index: 0 addr: 192.168.1.106 subnet: 192.168.1.0/24 > >> broadcast: 192.168.1.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST > >> UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED > >> [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] Interface added: Vif[register_vif] > >> pif_index: 3 vif_index: 1 addr: 192.168.1.106 subnet: 192.168.1.106/32 > >> broadcast: 192.168.1.106 peer: 0.0.0.0 Flags: PIM_REGISTER UNDERLYING_VIF_UP > >> MTU: 1500 > >> [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] Interface enabled Vif[register_vif] > >> pif_index: 3 vif_index: 1 addr: 192.168.1.106 subnet: 192.168.1.106/32 > >> broadcast: 192.168.1.106 peer: 0.0.0.0 Flags: PIM_REGISTER UNDERLYING_VIF_UP > >> MTU: 1500 DOWN IPv4 ENABLED > >> [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] Interface started: > >> Vif[register_vif] pif_index: 3 vif_index: 1 addr: 192.168.1.106 subnet: > >> 192.168.1.106/32 broadcast: 192.168.1.106 peer: 0.0.0.0 Flags: PIM_REGISTER > >> UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED > >> [ 2007/09/01 17:52:22 INFO xorp_rtrmgr:4757 RTRMGR +96 module_manager.cc > >> execute ] Executing module: mfea6 (fea/xorp_fea) > >> [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] Interface added: Vif[eth0] > >> pif_index: 3 vif_index: 0 addr: 2001:480:f022:3:400:8000:0:196 subnet: > >> 2001:480:f022:3:400:8000::/84 broadcast: :: peer: :: Flags: MULTICAST > >> BROADCAST UNDERLYING_VIF_UP MTU: 1500 > >> [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] MFEA started > >> [ 2007/09/01 17:52:22 INFO xorp_rtrmgr:4757 RTRMGR +96 module_manager.cc > >> execute ] Executing module: mld (mld6igmp/xorp_mld) > >> [ 2007/09/01 17:52:22 WARNING xorp_rtrmgr:4757 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 "MLD" > >> does not exist or is not enabled. > >> [ 2007/09/01 17:52:22 INFO xorp_mld MLD6IGMP ] Protocol enabled > >> [ 2007/09/01 17:52:22 INFO xorp_mld MLD6IGMP ] CLI enabled > >> [ 2007/09/01 17:52:22 INFO xorp_mld MLD6IGMP ] CLI started > >> [ 2007/09/01 17:52:23 INFO xorp_mld MLD6IGMP ] Protocol started > >> [ 2007/09/01 17:52:23 ERROR xorp_mld:4763 MLD6IGMP +718 mld6igmp_node.cc > >> add_vif ] Error updating primary address for vif eth0: invalid primary address > >> [ 2007/09/01 17:52:24 INFO xorp_mld MLD6IGMP ] Interface enabled: Vif[eth0] > >> pif_index: 3 vif_index: 0 addr: 2001:480:f022:3:400:8000:0:196 subnet: > >> 2001:480:f022:3:400:8000::/84 broadcast: :: peer: :: Flags: MULTICAST > >> BROADCAST UNDERLYING_VIF_UP MTU: 1500 DOWN IPv6 ENABLED > >> [ 2007/09/01 17:52:24 ERROR xorp_mld:4763 MLD6IGMP +1083 mld6igmp_node.cc > >> start_vif ] Cannot start vif eth0: invalid primary address > >> [ 2007/09/01 17:52:24 WARNING xorp_mld XrlMld6igmpTarget ] Handling method for > >> mld6igmp/0.1/start_vif failed: XrlCmdError 102 Command failed Cannot start vif > >> eth0: invalid primary address > >> [ 2007/09/01 17:52:24 ERROR xorp_rtrmgr:4757 RTRMGR +675 master_conf_tree.cc > >> commit_pass2_done ] Commit failed: 102 Command failed Cannot start vif eth0: > >> invalid primary address > >> [ 2007/09/01 17:52:24 ERROR xorp_rtrmgr:4757 RTRMGR +251 master_conf_tree.cc > >> config_done ] Configuration failed: 102 Command failed Cannot start vif eth0: > >> invalid primary address > >> [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +2228 task.cc run_task ] > >> No more tasks to run > >> [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +171 module_manager.cc > >> terminate ] Terminating module: fea > >> [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +171 module_manager.cc > >> terminate ] Terminating module: interfaces > >> [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +171 module_manager.cc > >> terminate ] Terminating module: mfea4 > >> [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +171 module_manager.cc > >> terminate ] Terminating module: mfea6 > >> [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +194 module_manager.cc > >> terminate ] Killing module: mfea6 > >> [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +171 module_manager.cc > >> terminate ] Terminating module: mld > >> [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +194 module_manager.cc > >> terminate ] Killing module: mld > >> [ 2007/09/01 17:52:24 ERROR xorp_rtrmgr:4757 RTRMGR +747 module_manager.cc > >> done_cb ] Command "/usr/local/xorp/mld6igmp/xorp_mld": terminated with signal > >> 15. > >> [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +282 module_manager.cc > >> module_exited ] Module killed during shutdown: mld > >> [ 2007/09/01 17:52:24 ERROR xorp_rtrmgr:4757 RTRMGR +747 module_manager.cc > >> done_cb ] Command "/usr/local/xorp/fea/xorp_fea": terminated with signal 15. > >> [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +282 module_manager.cc > >> module_exited ] Module killed during shutdown: mfea6 > >> [root at FEON etc]# > >> > >> > >> > >> Pavlin Radoslavov wrote: > >> > >>>> Anyone now what is missing to cause this not found error? /usr/local/sbin > >>>> has the file xorp_mld. > >>>> > >>>> 2007/08/31 16:33:41 INFO xorp_rtrmgr:666 RTRMGR +96 module_manager.cc > >>>> execute ] Executing module: mld (mld6igmp/xorp_mld) > >>>> [ 2007/08/31 16:33:41 WARNING xorp_rtrmgr:666 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 "MLD" does not exist or is not enabled. > >>>> > >>>> > >>> Did the xorp_rtrmgr execution continue after that? > >>> Typically, this is a transient error during startup/shutdown, so if > >>> the xorp_rtrmgr execution continued then you can ignore it. > >>> > >>> Regards, > >>> Pavlin > >>> > >>> > >>> > >>>> -- > >>>> Chris > >>>> > >>>> _______________________________________________ > >>>> 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 > >>> > >>> > >>> > >>> > >> -- > >> Christopher Robson > >> Senior Computer Scientist, GS-15 > >> Naval Research Laboratory > >> Center for Computational Science > >> Networking, Code 5591 > >> 4555 Overlook ave. > >> Washington, D.C. 20375-5320 > >> (COM) 202-404-3138 > >> (VoIP) 2024043138 at GIGEF > >> (CHAT) Chris.Robson at GIGEF > >> > > > > > > > > -- > Christopher Robson > Senior Computer Scientist, GS-15 > Naval Research Laboratory > Center for Computational Science > Networking, Code 5591 > 4555 Overlook ave. > Washington, D.C. 20375-5320 > (COM) 202-404-3138 > (VoIP) 2024043138 at GIGEF > (CHAT) Chris.Robson at GIGEF > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From Chris.Robson at nrl.navy.mil Tue Sep 4 05:09:36 2007 From: Chris.Robson at nrl.navy.mil (Chris Robson) Date: Tue, 04 Sep 2007 08:09:36 -0400 Subject: [Xorp-users] Module not foudn problem In-Reply-To: <200709021935.l82JZP97032441@possum.icir.org> References: <200709021935.l82JZP97032441@possum.icir.org> Message-ID: <46DD4B00.7050007@nrl.navy.mil> Pavlin Well I thought I had tested the default-system-config configuration but it appears not. After deleting all the interface section and reprogramming as you suggested using only "default-system-config", its working now. However, I did try your second suggesting using both hard coded addresses and using the default-system-config and both worked and both show commands display the exact same information. So it seems when adding other configurations like "mld" have some issue with hard coding interface addresses. Besides the simple configuration you suggest of just configuring the default interface and mfea6, would you want something else tried but with the more complex configuration file that works when using just defaults in the interface section? Output from your second Option (b) suggestion: xorp at FEON.nrl.gigef.net> show interfaces eth0/eth0: Flags: mtu 1500 inet6 2001:480:f022:3:400:8000:0:196 prefixlen 84 inet6 fe80::21a:6bff:fe69:a875 prefixlen 64 inet 10.128.142.196 subnet 10.128.142.0/24 broadcast 10.128.142.255 physical index 4 ether 0:1a:6b:69:a8:75 xorp at FEON.nrl.gigef.net> show mfea6 interface Interface State Vif/PifIndex Addr Flags eth0 UP 0/4 2001:480:f022:3:400:8000:0:196 MULTICAST BROADCAST KERN_UP register_vif UP 1/4 2001:480:f022:3:400:8000:0:196 PIM_REGISTER KERN_UP ....Chris Pavlin Radoslavov wrote: >> According to the "ip addr" command as shown below, there is a link local >> address. >> I wonder if there is an issue with xorp and linux kernel 2.6.22. Every >> since 2.6.18 a lot of IP stack things have broken. Could yo save me >> some time, where does xorp test for this? Then I can poke around and >> see what is happening. >> >> >> 3: eth0: mtu 1500 qdisc pfifo_fast >> qlen 100 >> link/ether 00:1a:6b:69:a8:75 brd ff:ff:ff:ff:ff:ff >> inet 192.168.1.109/24 brd 192.168.1.255 scope global eth0 >> inet 192.168.1.106/24 brd 192.168.1.255 scope global secondary eth0 >> inet6 2001:480:f022:3:400:8000:0:196/84 scope global >> valid_lft forever preferred_lft forever >> inet6 fe80::21a:6bff:fe69:a875/64 scope link >> valid_lft forever preferred_lft forever >> > > Yes, the IPv6 link-local address is configured in the kernel, but > that configuration needs to be propagated to XORP as well. This can > be done by either: > > a) Explicitly configure the IP addresses inside the XORP > "interfaces" section, including the link-local address. > > b) Implicitly configure all IP addresses by using configuration > like: > > interfaces { > interface eth0 { > default-system-config > } > } > > Option (b) is probably simpler in your case, so this is what I'd > recommend you do for now. > If you still get the same MLD error, then please configure only the > "interfaces" and "mfea6" sections, and send the output of > the following xorpsh commands: > show interfaces > show mfea6 interface > > Regards, > Pavlin > > >> .....chris >> >> Pavlin Radoslavov wrote: >> >>> Chris Robson wrote: >>> >>> >>> >>>> Pavlin >>>> >>>> Here is the complete dump, also is the "mld" section of the config file. >>>> There is an error about invalid primary address which I assumed was being >>>> caused because the module was being terminated. >>>> >>>> >>> The "primary address" error is triggered because it appears eth0 >>> doesn't have a configured IPv6 link-local address. The link-local >>> address should be assigned by either explicitly configuring it in >>> the "interfaces" section, or by using a configuration like: >>> >>> interfaces { >>> interface eth0 { >>> default-system-config >>> } >>> } >>> >>> The latter solution assumes that all relevant IPv4 and IPv6 >>> addresses have been configured in advance. >>> >>> FYI, in the future this should be fixed in XORP such that the IPv6 >>> link-local address will be automatically taken from the kernel even >>> if "default-system-config" is not used. >>> >>> Regards, >>> Pavlin >>> >>> >>> >>>> protocols { >>>> mld { >>>> disable: false >>>> interface eth0 { >>>> vif eth0 { >>>> disable: false >>>> version: 1 >>>> enable-ip-router-alert-option-check: false >>>> query-interval: 125 >>>> query-last-member-interval: 1 >>>> query-response-interval: 10 >>>> robust-count: 2 >>>> } >>>> } >>>> traceoptions { >>>> flag all { >>>> disable: false >>>> } >>>> } >>>> } >>>> } >>>> >>>> [ 2007/09/01 17:52:14 INFO xorp_rtrmgr:4757 RTRMGR +239 master_conf_tree.cc >>>> execute ] Changed modules: interfaces, fea, mfea4, mfea6, mld, rib, fib2mrib, >>>> igmp, pimsm4, policy, static_routes, ospf4 >>>> [ 2007/09/01 17:52:14 INFO xorp_rtrmgr:4757 RTRMGR +96 module_manager.cc >>>> execute ] Executing module: interfaces (fea/xorp_fea) >>>> [ 2007/09/01 17:52:15 INFO xorp_fea MFEA ] MFEA enabled >>>> [ 2007/09/01 17:52:15 INFO xorp_fea MFEA ] CLI enabled >>>> [ 2007/09/01 17:52:15 INFO xorp_fea MFEA ] CLI started >>>> [ 2007/09/01 17:52:15 INFO xorp_fea MFEA ] MFEA enabled >>>> [ 2007/09/01 17:52:15 INFO xorp_fea MFEA ] CLI enabled >>>> [ 2007/09/01 17:52:15 INFO xorp_fea MFEA ] CLI started >>>> [ 2007/09/01 17:52:16 INFO xorp_rtrmgr:4757 RTRMGR +96 module_manager.cc >>>> execute ] Executing module: fea (fea/xorp_fea) >>>> [ 2007/09/01 17:52:22 INFO xorp_rtrmgr:4757 RTRMGR +96 module_manager.cc >>>> execute ] Executing module: mfea4 (fea/xorp_fea) >>>> [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] Interface added: Vif[eth0] >>>> pif_index: 3 vif_index: 0 addr: 192.168.1.106 subnet: 192.168.1.0/24 >>>> broadcast: 192.168.1.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST >>>> UNDERLYING_VIF_UP MTU: 1500 >>>> [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] MFEA started >>>> [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] Interface enabled Vif[eth0] >>>> pif_index: 3 vif_index: 0 addr: 192.168.1.106 subnet: 192.168.1.0/24 >>>> broadcast: 192.168.1.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST >>>> UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED >>>> [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] Interface started: Vif[eth0] >>>> pif_index: 3 vif_index: 0 addr: 192.168.1.106 subnet: 192.168.1.0/24 >>>> broadcast: 192.168.1.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST >>>> UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED >>>> [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] Interface added: Vif[register_vif] >>>> pif_index: 3 vif_index: 1 addr: 192.168.1.106 subnet: 192.168.1.106/32 >>>> broadcast: 192.168.1.106 peer: 0.0.0.0 Flags: PIM_REGISTER UNDERLYING_VIF_UP >>>> MTU: 1500 >>>> [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] Interface enabled Vif[register_vif] >>>> pif_index: 3 vif_index: 1 addr: 192.168.1.106 subnet: 192.168.1.106/32 >>>> broadcast: 192.168.1.106 peer: 0.0.0.0 Flags: PIM_REGISTER UNDERLYING_VIF_UP >>>> MTU: 1500 DOWN IPv4 ENABLED >>>> [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] Interface started: >>>> Vif[register_vif] pif_index: 3 vif_index: 1 addr: 192.168.1.106 subnet: >>>> 192.168.1.106/32 broadcast: 192.168.1.106 peer: 0.0.0.0 Flags: PIM_REGISTER >>>> UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED >>>> [ 2007/09/01 17:52:22 INFO xorp_rtrmgr:4757 RTRMGR +96 module_manager.cc >>>> execute ] Executing module: mfea6 (fea/xorp_fea) >>>> [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] Interface added: Vif[eth0] >>>> pif_index: 3 vif_index: 0 addr: 2001:480:f022:3:400:8000:0:196 subnet: >>>> 2001:480:f022:3:400:8000::/84 broadcast: :: peer: :: Flags: MULTICAST >>>> BROADCAST UNDERLYING_VIF_UP MTU: 1500 >>>> [ 2007/09/01 17:52:22 INFO xorp_fea MFEA ] MFEA started >>>> [ 2007/09/01 17:52:22 INFO xorp_rtrmgr:4757 RTRMGR +96 module_manager.cc >>>> execute ] Executing module: mld (mld6igmp/xorp_mld) >>>> [ 2007/09/01 17:52:22 WARNING xorp_rtrmgr:4757 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 "MLD" >>>> does not exist or is not enabled. >>>> [ 2007/09/01 17:52:22 INFO xorp_mld MLD6IGMP ] Protocol enabled >>>> [ 2007/09/01 17:52:22 INFO xorp_mld MLD6IGMP ] CLI enabled >>>> [ 2007/09/01 17:52:22 INFO xorp_mld MLD6IGMP ] CLI started >>>> [ 2007/09/01 17:52:23 INFO xorp_mld MLD6IGMP ] Protocol started >>>> [ 2007/09/01 17:52:23 ERROR xorp_mld:4763 MLD6IGMP +718 mld6igmp_node.cc >>>> add_vif ] Error updating primary address for vif eth0: invalid primary address >>>> [ 2007/09/01 17:52:24 INFO xorp_mld MLD6IGMP ] Interface enabled: Vif[eth0] >>>> pif_index: 3 vif_index: 0 addr: 2001:480:f022:3:400:8000:0:196 subnet: >>>> 2001:480:f022:3:400:8000::/84 broadcast: :: peer: :: Flags: MULTICAST >>>> BROADCAST UNDERLYING_VIF_UP MTU: 1500 DOWN IPv6 ENABLED >>>> [ 2007/09/01 17:52:24 ERROR xorp_mld:4763 MLD6IGMP +1083 mld6igmp_node.cc >>>> start_vif ] Cannot start vif eth0: invalid primary address >>>> [ 2007/09/01 17:52:24 WARNING xorp_mld XrlMld6igmpTarget ] Handling method for >>>> mld6igmp/0.1/start_vif failed: XrlCmdError 102 Command failed Cannot start vif >>>> eth0: invalid primary address >>>> [ 2007/09/01 17:52:24 ERROR xorp_rtrmgr:4757 RTRMGR +675 master_conf_tree.cc >>>> commit_pass2_done ] Commit failed: 102 Command failed Cannot start vif eth0: >>>> invalid primary address >>>> [ 2007/09/01 17:52:24 ERROR xorp_rtrmgr:4757 RTRMGR +251 master_conf_tree.cc >>>> config_done ] Configuration failed: 102 Command failed Cannot start vif eth0: >>>> invalid primary address >>>> [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +2228 task.cc run_task ] >>>> No more tasks to run >>>> [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +171 module_manager.cc >>>> terminate ] Terminating module: fea >>>> [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +171 module_manager.cc >>>> terminate ] Terminating module: interfaces >>>> [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +171 module_manager.cc >>>> terminate ] Terminating module: mfea4 >>>> [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +171 module_manager.cc >>>> terminate ] Terminating module: mfea6 >>>> [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +194 module_manager.cc >>>> terminate ] Killing module: mfea6 >>>> [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +171 module_manager.cc >>>> terminate ] Terminating module: mld >>>> [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +194 module_manager.cc >>>> terminate ] Killing module: mld >>>> [ 2007/09/01 17:52:24 ERROR xorp_rtrmgr:4757 RTRMGR +747 module_manager.cc >>>> done_cb ] Command "/usr/local/xorp/mld6igmp/xorp_mld": terminated with signal >>>> 15. >>>> [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +282 module_manager.cc >>>> module_exited ] Module killed during shutdown: mld >>>> [ 2007/09/01 17:52:24 ERROR xorp_rtrmgr:4757 RTRMGR +747 module_manager.cc >>>> done_cb ] Command "/usr/local/xorp/fea/xorp_fea": terminated with signal 15. >>>> [ 2007/09/01 17:52:24 INFO xorp_rtrmgr:4757 RTRMGR +282 module_manager.cc >>>> module_exited ] Module killed during shutdown: mfea6 >>>> [root at FEON etc]# >>>> >>>> >>>> >>>> Pavlin Radoslavov wrote: >>>> >>>> >>>>>> Anyone now what is missing to cause this not found error? /usr/local/sbin >>>>>> has the file xorp_mld. >>>>>> >>>>>> 2007/08/31 16:33:41 INFO xorp_rtrmgr:666 RTRMGR +96 module_manager.cc >>>>>> execute ] Executing module: mld (mld6igmp/xorp_mld) >>>>>> [ 2007/08/31 16:33:41 WARNING xorp_rtrmgr:666 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 "MLD" does not exist or is not enabled. >>>>>> >>>>>> >>>>>> >>>>> Did the xorp_rtrmgr execution continue after that? >>>>> Typically, this is a transient error during startup/shutdown, so if >>>>> the xorp_rtrmgr execution continued then you can ignore it. >>>>> >>>>> Regards, >>>>> Pavlin >>>>> >>>>> >>>>> >>>>> >>>>>> -- >>>>>> Chris >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>> -- >>>> Christopher Robson >>>> Senior Computer Scientist, GS-15 >>>> Naval Research Laboratory >>>> Center for Computational Science >>>> Networking, Code 5591 >>>> 4555 Overlook ave. >>>> Washington, D.C. 20375-5320 >>>> (COM) 202-404-3138 >>>> (VoIP) 2024043138 at GIGEF >>>> (CHAT) Chris.Robson at GIGEF >>>> >>>> >>> >>> >> -- >> Christopher Robson >> Senior Computer Scientist, GS-15 >> Naval Research Laboratory >> Center for Computational Science >> Networking, Code 5591 >> 4555 Overlook ave. >> Washington, D.C. 20375-5320 >> (COM) 202-404-3138 >> (VoIP) 2024043138 at GIGEF >> (CHAT) Chris.Robson at GIGEF >> >> _______________________________________________ >> 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 > > > -- Christopher Robson Senior Computer Scientist, GS-15 Naval Research Laboratory Center for Computational Science Networking, Code 5591 4555 Overlook ave. Washington, D.C. 20375-5320 (COM) 202-404-3138 (VoIP) 2024043138 at GIGEF (CHAT) Chris.Robson at GIGEF From flash at preferance.ru Tue Sep 4 09:06:51 2007 From: flash at preferance.ru (Yuri Kirsanov) Date: Tue, 4 Sep 2007 20:06:51 +0400 Subject: [Xorp-users] XORP IGMP Querier Message-ID: <200709042006.51319.flash@preferance.ru> Good day. I'm trying to use XORP as IGMP Querier to provide IpTV in our network. I use PIM-SM4 and IGMP, everything works just fine, but XORP doesn't act as an IGMP Querier. I mean it just doesn't send any group-specific IGMP queries periodically. It does send group-specifict IGMP message when user leaves a group to ensure there's nobody else left in group. Can anybody help me on this issue? I am sure that XORP is IGMP querier on that vif: root at video_gw> show igmp interface Interface ? ?State ? ?Querier ? ? ? ? Timeout Version Groups eth0 ? ? ? ? UP ? ? ? 172.17.17.8 ? ? ? ?None ? ? ? 2 ? ? 10 eth1.202 ? ? UP ? ? ? 192.168.202.1 ? ? ? 246 ? ? ? 2 ? ? ?3 By the way, what does "Timeout None" mean? Here's my IGMP groups: root at video_gw> show igmp group Interface Group Source LastReported Timeout V State eth0 224.0.0.2 0.0.0.0 172.17.200.47 80 2 E eth0 224.0.0.13 0.0.0.0 172.17.17.8 76 2 E eth0 224.0.0.22 0.0.0.0 172.17.17.8 77 2 E eth0 224.2.127.254 0.0.0.0 172.17.21.25 129 2 E eth0 225.3.3.1 0.0.0.0 172.17.8.184 83 2 E eth0 227.0.0.2 0.0.0.0 172.17.201.205 83 2 E eth0 233.163.114.173 0.0.0.0 172.17.197.100 126 2 E eth0 239.192.152.143 0.0.0.0 172.17.13.83 85 2 E eth0 239.195.255.255 0.0.0.0 172.17.21.25 129 2 E eth0 239.255.219.45 0.0.0.0 172.17.19.154 82 2 E eth0 239.255.255.255 0.0.0.0 172.17.21.25 129 2 E eth1.202 224.0.0.2 0.0.0.0 192.168.202.2 254 2 E eth1.202 224.0.0.13 0.0.0.0 192.168.202.2 250 2 E eth1.202 224.0.0.22 0.0.0.0 192.168.202.2 254 2 E Group 233.163.114.173 is my source of multicast traffic, TV channel actually. It's Timeout value goes to zero and then group disappears. From jfs at computer.org Tue Sep 4 09:34:17 2007 From: jfs at computer.org (Javier Fernandez-Sanguino) Date: Tue, 4 Sep 2007 18:34:17 +0200 Subject: [Xorp-users] XORP IGMP Querier In-Reply-To: <200709042006.51319.flash@preferance.ru> References: <200709042006.51319.flash@preferance.ru> Message-ID: 2007/9/4, Yuri Kirsanov : > Good day. Could you please send your xorp configuration file? It might be helpful to see if its properly defined. Regards Javier From flash at preferance.ru Tue Sep 4 09:55:23 2007 From: flash at preferance.ru (Yuri Kirsanov) Date: Tue, 4 Sep 2007 20:55:23 +0400 Subject: [Xorp-users] XORP IGMP Querier References: <200709042006.51319.flash@preferance.ru> Message-ID: <000901c7ef14$62c41330$3ac111ac@FLASH> Of course! Here it is: [root at video_gw ~]# cat /opt/xorp/config.boot /* $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: "Downstream interface" disable: false /* default-system-config */ vif eth0 { disable: false address 172.17.17.8 { prefix-length: 16 broadcast: 172.17.255.255 disable: false } } } interface eth1.202 { description: "Upstream interface" disable: false /* default-system-config */ vif eth1.202 { disable: false address 192.168.202.2 { prefix-length: 24 broadcast: 192.168.202.255 disable: false } } } } fea { unicast-forwarding4 { disable: false forwarding-entries { retain-on-startup: false retain-on-shutdown: false } } } plumbing { mfea4 { disable: false interface eth1.202 { vif eth1.202 { disable: false } } interface eth0 { vif eth0 { 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: 2 enable-ip-router-alert-option-check: true query-interval: 60 query-last-member-interval: 1 query-response-interval: 10 robust-count: 2 } } interface eth1.202 { vif eth1.202 { disable: false version: 2 } } traceoptions { flag all { disable: false } } } /* mld { disable: true } */ } protocols { pimsm4 { disable: false interface eth1.202 { vif eth1.202 { disable: false /* enable-ip-router-alert-option-check: false */ /* dr-priority: 1 */ /* hello-period: 30 */ /* hello-triggered-delay: 5 */ } } 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 register_vif { vif register_vif { /* Note: this vif should be always enabled */ disable: false } } static-rps { rp 85.112.112.2 { group-prefix 233.163.114.0/24 { /* rp-priority: 192 */ /* hash-mask-len: 30 */ } } } traceoptions { flag all { disable: true } } } } /* * Note: fib2mrib is needed for multicast only if the unicast protocols * don't populate the MRIB with multicast-specific routes. */ protocols { fib2mrib { disable: true } } ----- Original Message ----- From: "Javier Fernandez-Sanguino" To: "Yuri Kirsanov" Cc: Sent: Tuesday, September 04, 2007 8:34 PM Subject: Re: [Xorp-users] XORP IGMP Querier > 2007/9/4, Yuri Kirsanov : >> Good day. > > Could you please send your xorp configuration file? It might be > helpful to see if its properly defined. > > Regards > > Javier > From greearb at candelatech.com Tue Sep 4 15:55:09 2007 From: greearb at candelatech.com (Ben Greear) Date: Tue, 04 Sep 2007 15:55:09 -0700 Subject: [Xorp-users] Question on supporting multiple routing tables [PATCH] In-Reply-To: <200708311840.l7VIeqtB065546@possum.icir.org> References: <200708311840.l7VIeqtB065546@possum.icir.org> Message-ID: <46DDE24D.4070106@candelatech.com> I attempted to change my patch per your (off-list) comments, basically to only bind when non-multicast and then immediately un-bind. Unfortunately, it appears that the Linux kernel logic to un-bind does not work. I sent a mail to the kernel mailing list, so hopefully it can be fixed sometime soon (or I can be properly beat around the head if it's my mistake.) In the meantime, I think we will need to stick with something similar to my previous patch that always binds, even when sending multicast pkts. For posterity's sake, here is my patch with the attempted un-binding logic. Please note that the un-binding logic is NOT following what the 'man 7 socket' indicates is the proper method (zero-length optlen), but zero-length optlen is not supported in Linux in 2.6.22 at least. Do NOT apply this, as it doesn't work. I will follow up in a new email with a working patch based on the previous patch but w/out the commented out debugging code. [greearb at file-server io]$ cvs diff cvs diff: Diffing . Index: io_ip_socket.cc =================================================================== RCS file: /cvs/xorp/fea/data_plane/io/io_ip_socket.cc,v retrieving revision 1.11 diff -r1.11 io_ip_socket.cc 2349a2350,2355 > #ifdef SO_BINDTODEVICE > // NOTE: DO NOT RETURN from this method until the very end. Set return > // value properly and 'goto out' instead. This way we are certain to unbind > // the interface as needed. > bool unbind = false; > #endif 2369,2371c2375,2377 < if (set_default_multicast_interface(ifp->ifname(), < vifp->vifname(), < error_msg) --- > if ((ret_value = set_default_multicast_interface(ifp->ifname(), > vifp->vifname(), > error_msg)) 2373c2379 < return (XORP_ERROR); --- > goto out; 2379,2380c2385,2386 < if (enable_multicast_loopback(true, error_msg) != XORP_OK) { < return (XORP_ERROR); --- > if ((ret_value = enable_multicast_loopback(true, error_msg)) != XORP_OK) { > goto out; 2383a2390,2407 > #ifdef SO_BINDTODEVICE > else { > if (!vifp->ifname().empty()) { > unbind = true; > if (setsockopt(_proto_socket_out, SOL_SOCKET, SO_BINDTODEVICE, > vifp->ifname().c_str(), IFNAMSIZ)) { > error_msg += c_format("setsockopt(SO_BINDTODEVICE, %s) failed: %s", > vifp->ifname().c_str(), strerror(errno)); > } > else { > XLOG_ERROR("BINDTODEVICE, dev: %s, this: %p src-addr: %s", > vifp->ifname().c_str(), this, cstring(src_address)); > } > } > } > #endif > > 2409c2433,2434 < return (XORP_ERROR); --- > ret_value = XORP_ERROR; > goto out; 2456c2481,2482 < return (XORP_ERROR); --- > ret_value = XORP_ERROR; > goto out; 2478a2505,2526 > out: > #ifdef SO_BINDTODEVICE > XLOG_ERROR("out, unbind: %i vifp: %s mcast: %i", > (int)(unbind), vifp->ifname().c_str(), (int)(dst_address.is_multicast())); > if (unbind) { > // Un-bind the interface > int z = 0; > if (setsockopt(_proto_socket_out, SOL_SOCKET, SO_BINDTODEVICE, > &z, sizeof(z))) { > error_msg += c_format("setsockopt(SO_BINDTODEVICE, NULL) failed: %s", > strerror(errno)); > XLOG_ERROR("un-BINDTODEVICE, dev: %s, this: %p src-addr: %s failed: %s", > vifp->ifname().c_str(), this, cstring(src_address), > strerror(errno)); > } > else { > XLOG_ERROR("un-BINDTODEVICE, dev: %s, this: %p src-addr: %s", > vifp->ifname().c_str(), this, cstring(src_address)); > } > } > #endif > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Tue Sep 4 17:31:06 2007 From: greearb at candelatech.com (Ben Greear) Date: Tue, 04 Sep 2007 17:31:06 -0700 Subject: [Xorp-users] Question on supporting multiple routing tables [PATCH] In-Reply-To: <46DDE24D.4070106@candelatech.com> References: <200708311840.l7VIeqtB065546@possum.icir.org> <46DDE24D.4070106@candelatech.com> Message-ID: <46DDF8CA.8020507@candelatech.com> Ben Greear wrote: > I attempted to change my patch per your (off-list) comments, > basically to only bind when non-multicast and then immediately > un-bind. Unfortunately, it appears that the Linux kernel logic > to un-bind does not work. I sent a mail to the kernel mailing > list, so hopefully it can be fixed sometime soon (or I can be > properly beat around the head if it's my mistake.) Well, at least part of the problem was self inflicted, as usual. I'm still not certain the kernel handles un-binds correctly, but as far as I can tell, that doesn't matter for Xorp since we always bind on uni-cast, and multi-cast doesn't care. I have tested the attached patch, and it seems to work as planned. Please review and apply if it meets your specifications. There is a small change to the original logic: It used to return on some error cases and not run the loopback multicast setup at the bottom of the method. With the new patch, it will always run the loopback multicast test, as well as the un-bindtodevice logic. If you want changes to the patch, let me know. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -------------- next part -------------- A non-text attachment was scrubbed... Name: xorp.patch Type: text/x-patch Size: 3850 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070904/de0dd7b9/attachment.bin From pavlin at icir.org Tue Sep 4 22:41:20 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 04 Sep 2007 22:41:20 -0700 Subject: [Xorp-users] XORP IGMP Querier In-Reply-To: Message from Yuri Kirsanov of "Tue, 04 Sep 2007 20:06:51 +0400." <200709042006.51319.flash@preferance.ru> Message-ID: <200709050541.l855fKUH059209@possum.icir.org> > I'm trying to use XORP as IGMP Querier to provide IpTV in our network. I use > PIM-SM4 and IGMP, everything works just fine, but XORP doesn't act as an IGMP > Querier. I mean it just doesn't send any group-specific IGMP queries > periodically. It does send group-specifict IGMP message when user leaves a > group to ensure there's nobody else left in group. Can anybody help me on this > issue? I am sure that XORP is IGMP querier on that vif: This is how the IGMP protocol is suppose to work: the Querier sends periodic generic IGMP queries to 224.0.0.1, but sends a group-specific query only if a receiver leaves a group. > root at video_gw> show igmp interface > Interface ? ?State ? ?Querier ? ? ? ? Timeout Version Groups > eth0 ? ? ? ? UP ? ? ? 172.17.17.8 ? ? ? ?None ? ? ? 2 ? ? 10 > eth1.202 ? ? UP ? ? ? 192.168.202.1 ? ? ? 246 ? ? ? 2 ? ? ?3 > > By the way, what does "Timeout None" mean? If the Querier timer is not running (e.g., if I am the querier), then the Timeout is "None". > Here's my IGMP groups: > root at video_gw> show igmp group > Interface Group Source LastReported Timeout V State > eth0 224.0.0.2 0.0.0.0 172.17.200.47 80 2 E > eth0 224.0.0.13 0.0.0.0 172.17.17.8 76 2 E > eth0 224.0.0.22 0.0.0.0 172.17.17.8 77 2 E > eth0 224.2.127.254 0.0.0.0 172.17.21.25 129 2 E > eth0 225.3.3.1 0.0.0.0 172.17.8.184 83 2 E > eth0 227.0.0.2 0.0.0.0 172.17.201.205 83 2 E > eth0 233.163.114.173 0.0.0.0 172.17.197.100 126 2 E > eth0 239.192.152.143 0.0.0.0 172.17.13.83 85 2 E > eth0 239.195.255.255 0.0.0.0 172.17.21.25 129 2 E > eth0 239.255.219.45 0.0.0.0 172.17.19.154 82 2 E > eth0 239.255.255.255 0.0.0.0 172.17.21.25 129 2 E > eth1.202 224.0.0.2 0.0.0.0 192.168.202.2 254 2 E > eth1.202 224.0.0.13 0.0.0.0 192.168.202.2 250 2 E > eth1.202 224.0.0.22 0.0.0.0 192.168.202.2 254 2 E > > Group 233.163.114.173 is my source of multicast traffic, TV channel actually. > It's Timeout value goes to zero and then group disappears. When XORP sends generic query to 224.0.0.1 do you see Membership Reports about group 233.163.114.173? Running tcpdump like the following should show all IGMP traffic on interface eth0: tcpdump -i eth0 -n -vvv -s 0 -x proto \\igmp Also, what XORP version are you using. Regards, Pavlin > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at icir.org Tue Sep 4 23:58:12 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 04 Sep 2007 23:58:12 -0700 Subject: [Xorp-users] Module not foudn problem In-Reply-To: Message from Chris Robson of "Tue, 04 Sep 2007 08:09:36 EDT." <46DD4B00.7050007@nrl.navy.mil> Message-ID: <200709050658.l856wC8p059937@possum.icir.org> > Well I thought I had tested the default-system-config configuration but > it appears not. After deleting all the interface section and > reprogramming as you suggested using only "default-system-config", its > working now. However, I did try your second suggesting using both hard > coded addresses and using the default-system-config and both worked and > both show commands display the exact same information. So it seems when > adding other configurations like "mld" have some issue with hard coding > interface addresses. Besides the simple configuration you suggest of > just configuring the default interface and mfea6, would you want > something else tried but with the more complex configuration file that > works when using just defaults in the interface section? > > Output from your second Option (b) suggestion: > > xorp at FEON.nrl.gigef.net> show interfaces > eth0/eth0: Flags: mtu 1500 > inet6 2001:480:f022:3:400:8000:0:196 prefixlen 84 > inet6 fe80::21a:6bff:fe69:a875 prefixlen 64 > inet 10.128.142.196 subnet 10.128.142.0/24 broadcast 10.128.142.255 > physical index 4 > ether 0:1a:6b:69:a8:75 > xorp at FEON.nrl.gigef.net> show mfea6 interface > Interface State Vif/PifIndex Addr Flags > eth0 UP 0/4 2001:480:f022:3:400:8000:0:196 > MULTICAST BROADCAST KERN_UP > register_vif UP 1/4 2001:480:f022:3:400:8000:0:196 > PIM_REGISTER KERN_UP Sorry, the second command should have been "show mfea6 interface address" and shound print both IPv6 addresses: 2001:480:f022:3:400:8000:0:196 and fe80::21a:6bff:fe69:a875 . Could you send your "interfaces" config section when you explicitly configure the IP addresses instead of using "default-system-config". I just tried it, and appears to work, though I had to use FreeBSD instead of Linux, because the Linux version we have doesn't support IPv6 multicast routing. Regards, Pavlin From flash at preferance.ru Wed Sep 5 03:30:59 2007 From: flash at preferance.ru (Yuri Kirsanov) Date: Wed, 5 Sep 2007 14:30:59 +0400 Subject: [Xorp-users] XORP IGMP Querier In-Reply-To: <200709050541.l855fKUH059209@possum.icir.org> References: <200709050541.l855fKUH059209@possum.icir.org> Message-ID: <200709051430.59987.flash@preferance.ru> > This is how the IGMP protocol is suppose to work: the Querier sends > periodic generic IGMP queries to 224.0.0.1, but sends a > group-specific query only if a receiver leaves a group. > Thank you very much! The problem was not in XORP, somehow my swtiches didn't pass generic query to 224.0.0.1. Now problem is solved, everything works fine! Thanks again! From jfs at computer.org Thu Sep 6 14:44:14 2007 From: jfs at computer.org (Javier =?iso-8859-1?Q?Fern=E1ndez-Sanguino_Pe=F1a?=) Date: Thu, 6 Sep 2007 23:44:14 +0200 Subject: [Xorp-users] Xorp now available in Debian [installer@ftp-master.debian.org: xorp_1.5~cvs.20070824-1_i386.changes ACCEPTED] Message-ID: <20070906214414.GA13758@javifsp.no-ip.org> As you can see from the mail below, the Xorp packages have now been introduced into Debian. Soon http://packages.debian.org/xorp will present all the information about the package as well as access to the binaries built for all the different architectures supported by Debian (i386, sparc, arm, mips, ia64...). Supposing the binaries build fine in all other architectures that is. The version packed is the CVS copy of August 24th (future 1.5) with some patches some of which are Debian-specific (init.d file for example) some of which are not (manpages for the programs and simple configuration files, for example). All the patches have been sent to Xorp's bugzilla database and some are even fixed already in CVS. Enjoy! Javier ----- Forwarded message from Debian Installer ----- From: Debian Installer Date: Thu, 06 Sep 2007 18:51:13 +0000 To: Javier Fernandez-Sanguino Pen~a , Jose Calhariz Subject: xorp_1.5~cvs.20070824-1_i386.changes ACCEPTED Accepted: xorp-doc_1.5~cvs.20070824-1_all.deb to pool/main/x/xorp/xorp-doc_1.5~cvs.20070824-1_all.deb xorp_1.5~cvs.20070824-1.diff.gz to pool/main/x/xorp/xorp_1.5~cvs.20070824-1.diff.gz xorp_1.5~cvs.20070824-1.dsc to pool/main/x/xorp/xorp_1.5~cvs.20070824-1.dsc xorp_1.5~cvs.20070824-1_i386.deb to pool/main/x/xorp/xorp_1.5~cvs.20070824-1_i386.deb xorp_1.5~cvs.20070824.orig.tar.gz to pool/main/x/xorp/xorp_1.5~cvs.20070824.orig.tar.gz Override entries for your package: xorp-doc_1.5~cvs.20070824-1_all.deb - extra net xorp_1.5~cvs.20070824-1.dsc - extra net xorp_1.5~cvs.20070824-1_i386.deb - extra net Announcing to debian-devel-changes at lists.debian.org Closing bugs: 433467 Thank you for your contribution to Debian. ----- End forwarded message ----- -------------- 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/20070906/5d23f939/attachment.bin From pavlin at icir.org Fri Sep 7 04:08:01 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 07 Sep 2007 04:08:01 -0700 Subject: [Xorp-users] Question on supporting multiple routing tables [PATCH] In-Reply-To: Message from Ben Greear of "Tue, 04 Sep 2007 17:31:06 PDT." <46DDF8CA.8020507@candelatech.com> Message-ID: <200709071108.l87B81oc087012@possum.icir.org> Ben Greear wrote: > Ben Greear wrote: > > I attempted to change my patch per your (off-list) comments, > > basically to only bind when non-multicast and then immediately > > un-bind. Unfortunately, it appears that the Linux kernel logic > > to un-bind does not work. I sent a mail to the kernel mailing > > list, so hopefully it can be fixed sometime soon (or I can be > > properly beat around the head if it's my mistake.) > > Well, at least part of the problem was self inflicted, as usual. > I'm still not certain the kernel handles un-binds correctly, but > as far as I can tell, that doesn't matter for Xorp since we always > bind on uni-cast, and multi-cast doesn't care. > > I have tested the attached patch, and it seems to work as planned. > > Please review and apply if it meets your specifications. There is > a small change to the original logic: It used to return on some > error cases and not run the loopback multicast setup at the bottom > of the method. With the new patch, it will always run the loopback multicast > test, as well as the un-bindtodevice logic. > > If you want changes to the patch, let me know. Ben, Thank you for the patch. I applied it with some additional modifications. Most notably, the setsockopt(SO_BINDTODEVICE) mechanism is used only when it is needed currently (i.e., only if the unicast forwarding table ID is configured). I just committed it so please let me know whether it works for you: Revision Changes Path 1.12 +57 -7; commitid: 16e2f46e12aeb7ea6; xorp/fea/data_plane/io/io_ip_socket.cc AND 1.13 +4 -2; commitid: 16f2946e1305c7ea6; xorp/fea/data_plane/io/io_ip_socket.cc FYI, I tested the unbinding, and it seems to work on Linux-2.6.20.1. Though, while testing it I discovered that the value of the optlen argument to setsockopt indeed needs to be at least 4. Thanks, Pavlin > Thanks, > Ben > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > ? fea/data_plane/io/io_ip_socket.cc.tmp > Index: fea/data_plane/io/io_ip_socket.cc > =================================================================== > RCS file: /cvs/xorp/fea/data_plane/io/io_ip_socket.cc,v > retrieving revision 1.11 > diff -u -r1.11 io_ip_socket.cc > --- fea/data_plane/io/io_ip_socket.cc 30 Aug 2007 17:37:51 -0000 1.11 > +++ fea/data_plane/io/io_ip_socket.cc 5 Sep 2007 00:26:02 -0000 > @@ -2347,6 +2347,12 @@ > { > bool setloop = false; > int ret_value = XORP_OK; > +#ifdef SO_BINDTODEVICE > + // NOTE: DO NOT RETURN from this method until the very end. Set return > + // value properly and 'goto out' instead. This way we are certain to unbind > + // the interface as needed. > + bool unbind = false; > +#endif > > // > // Adjust some IPv4 header fields > @@ -2366,21 +2372,38 @@ > // Multicast-related setting > // > if (dst_address.is_multicast()) { > - if (set_default_multicast_interface(ifp->ifname(), > - vifp->vifname(), > - error_msg) > + if ((ret_value = set_default_multicast_interface(ifp->ifname(), > + vifp->vifname(), > + error_msg)) > != XORP_OK) { > - return (XORP_ERROR); > + goto out; > } > // > // XXX: we need to enable the multicast loopback so other processes > // on the same host can receive the multicast packets. > // > - if (enable_multicast_loopback(true, error_msg) != XORP_OK) { > - return (XORP_ERROR); > + if ((ret_value = enable_multicast_loopback(true, error_msg)) != XORP_OK) { > + goto out; > } > setloop = true; > } > +#ifdef SO_BINDTODEVICE > + else { > + if (!vifp->ifname().empty()) { > + unbind = true; > + if (setsockopt(_proto_socket_out, SOL_SOCKET, SO_BINDTODEVICE, > + vifp->ifname().c_str(), IFNAMSIZ)) { > + error_msg += c_format("setsockopt(SO_BINDTODEVICE, %s) failed: %s", > + vifp->ifname().c_str(), strerror(errno)); > + XLOG_ERROR("BINDTODEVICE, dev: %s, this: %p src-addr: %s failed: %s", > + vifp->ifname().c_str(), this, cstring(src_address), > + strerror(errno)); > + // Continue on, probably not fatal in most configurations. > + } > + } > + } > +#endif > + > > // > // Transmit the packet > @@ -2406,7 +2429,8 @@ > default: > XLOG_UNREACHABLE(); > error_msg = c_format("Invalid address family %d", family()); > - return (XORP_ERROR); > + ret_value = XORP_ERROR; > + goto out; > } > > if (sendmsg(_proto_socket_out, &_sndmh, 0) < 0) { > @@ -2453,7 +2477,8 @@ > default: > XLOG_UNREACHABLE(); > error_msg = c_format("Invalid address family %d", family()); > - return (XORP_ERROR); > + ret_value = XORP_ERROR; > + goto out; > } > > error = WSASendTo(_proto_socket_out, > @@ -2476,6 +2501,31 @@ > } > #endif // HOST_OS_WINDOWS > > + out: > +#ifdef SO_BINDTODEVICE > + if (unbind) { > + // Un-bind the interface > + // NOTE: The man page indicates one can use a zero-length null-terminated string > + // to un-bind, but as of Linux 2.6.20, optlen must be >= 0. The code below > + // appears to be the correct API. > + // NOTE2: I am not sure if the 2.6.20 kernel code is correct for un-bind, since it does not > + // explicitly free the cached route for the socket, but that route appears to be recalculated > + // properly, because we always (re)bind when sending unicast, and if we are not (re)binding, > + // then it's multicast, which isn't going to use the cached unicast route anyway. > + // --Ben Sept 4, 2007 > + > + int z = 0; > + if (setsockopt(_proto_socket_out, SOL_SOCKET, SO_BINDTODEVICE, > + &z, sizeof(z))) { > + error_msg += c_format("setsockopt(SO_BINDTODEVICE, NULL) failed: %s", > + strerror(errno)); > + XLOG_ERROR("un-BINDTODEVICE, dev: %s, this: %p src-addr: %s failed: %s", > + vifp->ifname().c_str(), this, cstring(src_address), > + strerror(errno)); > + } > + } > +#endif > + > // > // Restore some multicast related settings > // > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From Chris.Robson at nrl.navy.mil Thu Sep 6 11:36:21 2007 From: Chris.Robson at nrl.navy.mil (Chris Robson) Date: Thu, 06 Sep 2007 14:36:21 -0400 Subject: [Xorp-users] Module not foudn problem In-Reply-To: <200709050658.l856wC8p059937@possum.icir.org> References: <200709050658.l856wC8p059937@possum.icir.org> Message-ID: <46E048A5.2020706@nrl.navy.mil> Pavlin Sorry for the delay on this..... as you requested, here is the config file. I am using Linux with both IPv4 and IPv6 multicast enabled. Another issue I'm having is bridge ports. The Linux routers have SmallTree multiport cards which I configure using the brctl command creating a "br0" interface. what I have found is xorp blows up on the br0 interface. I believe the issue here is actually a linux multicast patch problem with both Ipv4 and v6. But if you know anyone who has gotten the br0 interface to work, please let me know. My work around is to use direct configs and not bridging. Wastes IP addresses but will get the job done I think. ....Chris interfaces { restore-original-config-on-shutdown: false interface eth0 { description: "Eth0 interface" disable: false vif eth0 { disable: false address 10.128.142.196 { prefix-length: 24 broadcast: 10.128.142.255 disable: false } address 99999:9999:99999:3:400:8000:0:196 { prefix-length: 84 disable: false } } } } fea { unicast-forwarding4 { disable: false forwarding-entries { retain-on-startup: false retain-on-shutdown: false } } unicast-forwarding6 { disable: false forwarding-entries { retain-on-startup: false retain-on-shutdown: false } } } protocols { static { route 0.0.0.0/0 { next-hop: 192.168.1.1 metric: 1 } } } 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" } } } } protocols { ospf4 { router-id: 192.168.1.106 /* Redistribute of hard interfaces and manual routes */ /* export: "connected" */ /* export: "static" */ area 0.0.0.0 { interface eth0 { /* link-type: "broadcast" */ vif eth0 { address 10.128.142.196 { /* priority: 128 */ /* hello-interval: 10 */ /* router-dead-interval: 40 */ /* interface-cost: 1 */ /* retransmit-interval: 5 */ /* transit-delay: 1 */ /* passive: false */ /* disable: false */ } } } } } ospf6 0 { router-id: 102.168.1.106 area 0.0.0.0 { interface eth0 { vif eth0 { address 9999:9999:9999:3:400:8000:0:196 { /* priority: 128 */ /* hello-interval: 10 */ /* router-dead-interval: 40 */ /* interface-cost: 1 */ /* retransmit-interval: 5 */ /* transit-delay: 1 */ /* passive: false */ /* disable: false */ } } } } } } plumbing { mfea4 { disable: false interface eth0 { vif eth0 { disable: false } } interface register_vif { vif register_vif { /* Note: this vif should be always enabled */ disable: false } } traceoptions { flag all { disable: false } } } mfea6 { disable: false interface eth0 { vif eth0 { disable: false } } interface register_vif { vif register_vif { disable: false } } traceoptions { flag all { disable: false } } } } protocols { igmp { disable: false interface eth0 { vif eth0 { disable: false /* version: 2 */ /* enable-ip-router-alert-option-check: false */ /* query-interval: 125 */ /* query-last-member-interval: 1 */ /* query-response-interval: 10 */ /* robust-count: 2 */ } } traceoptions { flag all { disable: false } } } } protocols { mld { disable: false interface eth0 { vif eth0 { disable: false version: 1 enable-ip-router-alert-option-check: false query-interval: 125 query-last-member-interval: 1 query-response-interval: 10 robust-count: 2 } } traceoptions { flag all { disable: false } } } } 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 register_vif { vif register_vif { /* Note: this vif should be always enabled */ disable: false } } static-rps { rp 10.128.142.196{ group-prefix 224.0.0.0/4 { /* rp-priority: 192 */ /* hash-mask-len: 30 */ } } } bootstrap { disable: false cand-bsr { scope-zone 224.0.0.0/4 { /* is-scope-zone: false */ cand-bsr-by-vif-name: "eth0" /* cand-bsr-by-vif-addr: 192.168.1.106 */ /* bsr-priority: 1 */ /* hash-mask-len: 30 */ } } cand-rp { group-prefix 224.0.0.0/4 { /* is-scope-zone: false */ cand-rp-by-vif-name: "eth0" /* cand-rp-by-vif-addr: 192.168.1.106 */ /* rp-priority: 192 */ /* rp-holdtime: 150 */ } } } switch-to-spt-threshold { /* approx. 1K bytes/s (10Kbps) threshold */ disable: false interval: 100 bytes: 102400 } 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 } } /* * See xorp/mibs/snmpdscripts/README on how to configure Net-SNMP in your host * before uncommenting the snmp section below. * Also check that the "bgp4_mib_1657.so" exists in the correct location. */ /* protocols { snmp { mib-module bgp4_mib_1657 { abs-path: "/usr/local/xorp/mibs/bgp4_mib_1657.so" } } } */ Pavlin Radoslavov wrote: >> Well I thought I had tested the default-system-config configuration but >> it appears not. After deleting all the interface section and >> reprogramming as you suggested using only "default-system-config", its >> working now. However, I did try your second suggesting using both hard >> coded addresses and using the default-system-config and both worked and >> both show commands display the exact same information. So it seems when >> adding other configurations like "mld" have some issue with hard coding >> interface addresses. Besides the simple configuration you suggest of >> just configuring the default interface and mfea6, would you want >> something else tried but with the more complex configuration file that >> works when using just defaults in the interface section? >> >> Output from your second Option (b) suggestion: >> >> xorp at FEON.nrl.gigef.net> show interfaces >> eth0/eth0: Flags: mtu 1500 >> inet6 2001:480:f022:3:400:8000:0:196 prefixlen 84 >> inet6 fe80::21a:6bff:fe69:a875 prefixlen 64 >> inet 10.128.142.196 subnet 10.128.142.0/24 broadcast 10.128.142.255 >> physical index 4 >> ether 0:1a:6b:69:a8:75 >> xorp at FEON.nrl.gigef.net> show mfea6 interface >> Interface State Vif/PifIndex Addr Flags >> eth0 UP 0/4 2001:480:f022:3:400:8000:0:196 >> MULTICAST BROADCAST KERN_UP >> register_vif UP 1/4 2001:480:f022:3:400:8000:0:196 >> PIM_REGISTER KERN_UP >> > > Sorry, the second command should have been > "show mfea6 interface address" and shound print both IPv6 addresses: > 2001:480:f022:3:400:8000:0:196 and fe80::21a:6bff:fe69:a875 . > > Could you send your "interfaces" config section when you explicitly > configure the IP addresses instead of using "default-system-config". > I just tried it, and appears to work, though I had to use FreeBSD > instead of Linux, because the Linux version we have doesn't support > IPv6 multicast routing. > > Regards, > Pavlin > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > > -- Christopher Robson Senior Computer Scientist, GS-15 Naval Research Laboratory Center for Computational Science Networking, Code 5591 4555 Overlook ave. Washington, D.C. 20375-5320 (COM) 202-404-3138 (VoIP) 2024043138 at GIGEF (CHAT) Chris.Robson at GIGEF From greearb at candelatech.com Fri Sep 7 11:14:37 2007 From: greearb at candelatech.com (Ben Greear) Date: Fri, 07 Sep 2007 11:14:37 -0700 Subject: [Xorp-users] Question on supporting multiple routing tables [PATCH] In-Reply-To: <200709071108.l87B81oc087012@possum.icir.org> References: <200709071108.l87B81oc087012@possum.icir.org> Message-ID: <46E1950D.50108@candelatech.com> Pavlin Radoslavov wrote: > Ben Greear wrote: > >> Ben Greear wrote: >>> I attempted to change my patch per your (off-list) comments, >>> basically to only bind when non-multicast and then immediately >>> un-bind. Unfortunately, it appears that the Linux kernel logic >>> to un-bind does not work. I sent a mail to the kernel mailing >>> list, so hopefully it can be fixed sometime soon (or I can be >>> properly beat around the head if it's my mistake.) >> Well, at least part of the problem was self inflicted, as usual. >> I'm still not certain the kernel handles un-binds correctly, but >> as far as I can tell, that doesn't matter for Xorp since we always >> bind on uni-cast, and multi-cast doesn't care. >> >> I have tested the attached patch, and it seems to work as planned. >> >> Please review and apply if it meets your specifications. There is >> a small change to the original logic: It used to return on some >> error cases and not run the loopback multicast setup at the bottom >> of the method. With the new patch, it will always run the loopback multicast >> test, as well as the un-bindtodevice logic. >> >> If you want changes to the patch, let me know. > > Ben, > > Thank you for the patch. > I applied it with some additional modifications. Most notably, > the setsockopt(SO_BINDTODEVICE) mechanism is used only when it is > needed currently (i.e., only if the unicast forwarding table ID is > configured). I just tested this and it seems to work fine. Would it be possible/useful to use two Xorps with the default routing table as long as they are configured for different sets of interfaces? I wouldn't use it like that, so if you can't think of a reason, then we should leave the check for table-id in as you have it... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Fri Sep 7 11:19:39 2007 From: greearb at candelatech.com (Ben Greear) Date: Fri, 07 Sep 2007 11:19:39 -0700 Subject: [Xorp-users] Multiple xorp instances performance improvements. Message-ID: <46E1963B.2000603@candelatech.com> It appears that each Xorp instance effectively listens for all xorp related packets on all interfaces. It does filter out the packets that are received on interfaces it is not configured for, but that is a lot of work. If we are talking about 10 or 100 xorp instances, then each router packet is going to wake 10 or 100 processes (9 or 99 of which don't care), causing serious performance penalty. How hard would it be to make Xorp bind only to the interfaces it cares about (for reading, at least)? I think the write socket can remain as it is... If nothing else, we might could add a bpf filter to the incoming socket so that the kernel discards the non-interesting packets and does not bother waking the xorp processes that don't care... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Fri Sep 7 19:07:47 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 07 Sep 2007 19:07:47 -0700 Subject: [Xorp-users] Question on supporting multiple routing tables [PATCH] In-Reply-To: Message from Ben Greear of "Fri, 07 Sep 2007 11:14:37 PDT." <46E1950D.50108@candelatech.com> Message-ID: <200709080207.l8827lsp094180@possum.icir.org> > Would it be possible/useful to use two Xorps with the default routing table > as long as they are configured for different sets of interfaces? I > wouldn't use it like that, so if you can't think of a reason, then > we should leave the check for table-id in as you have it... Even if the two instances might be configured with different set of interfaces, things will start breaking if both instances try to install a route for the same prefix. Indeed, someone might find a way to avoid same prefix being handled by both instances, but such setup then starts looking a but unusual. In any case if someone really wants to do it, they can get around the table ID check by explicitly setting the forwarding table ID to the default routing table. Regards, Pavlin From pavlin at icir.org Fri Sep 7 21:09:03 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 07 Sep 2007 21:09:03 -0700 Subject: [Xorp-users] Multiple xorp instances performance improvements. In-Reply-To: Message from Ben Greear of "Fri, 07 Sep 2007 11:19:39 PDT." <46E1963B.2000603@candelatech.com> Message-ID: <200709080409.l88493NN095225@possum.icir.org> Ben Greear wrote: > It appears that each Xorp instance effectively listens for all xorp > related packets on all interfaces. It does filter out the packets that > are received on interfaces it is not configured for, but that is a lot > of work. I presume you are talking about the raw IP interface. > If we are talking about 10 or 100 xorp instances, then each router packet > is going to wake 10 or 100 processes (9 or 99 of which don't care), > causing serious performance penalty. This might or might not be the case, but I wouldn't call that "serious performance penalty" without doing some profiling or measurements that quantify it. > How hard would it be to make Xorp bind only to the interfaces it > cares about (for reading, at least)? I think the write socket can > remain as it is... There is a trade-off. By doing something like this you need to create and bind a receiving socket for each configured IP address (even in the case when an interface has 2+ alias IP addresses). If there is a huge number of configured interfaces/addresses (e.g., think 1000 virtual tunnel interfaces), this will eat up lots of socket resources. For example, if each socket is configured with 256KB kernel buffer space, then you need total of 256MB buffer space which is a lot! > If nothing else, we might could add a bpf filter to the incoming socket > so that the kernel discards the non-interesting packets and does not bother > waking the xorp processes that don't care... I don't think you can apply BPF filters on raw IP sockets. If you are thinking about link-layer I/O, actually the link-raw pcap-based I/O sockets are created and "bind" per interface (simply because the pcap API mandates that). Hence, if you really worry about waking up the processes, then you could try using the link-based I/O sockets. Though, I wouldn't recommend that for raw IP purpose, because you would end-up doing lots of extra stuff. In any case, my feeling is that the extra overhead of waking-up the FEAa when there are 10 XORP instances is going to be pretty small. If you are considering 100 XORP instances, the bottleneck probably is going to be somewhere else (e.g., memory usage or control packet processing in the protocol modules themselves). Though, in general I'd say to hold back premature optimizations until it is clear the optimization is necessary. Regards, Pavlin > Thanks, > Ben > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at icir.org Fri Sep 7 22:14:55 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 07 Sep 2007 22:14:55 -0700 Subject: [Xorp-users] Module not foudn problem In-Reply-To: Message from Chris Robson of "Thu, 06 Sep 2007 14:36:21 EDT." <46E048A5.2020706@nrl.navy.mil> Message-ID: <200709080514.l885EtUX000914@possum.icir.org> > Sorry for the delay on this..... as you requested, here is the config > file. I am using Linux with both IPv4 and IPv6 multicast enabled. In the configuration below you are explicitly configuring the IP addresses. In that case you must add to the XORP configuration the IPv6 link-local address as well (exactly as it appears in the kernel). Yes, currently it is hassle to require explicit configuration of the IPv6 link-local address, so the "default-system-config" alternative can be a simpler solution for you. BTW, "99999:9999:99999:3:400:8000:0:196" is not a valid IPv6 address. Also, in your PIM-SM configuration you should use either the "static-rps" or the "bootstrap" mechanism, but not both. BTW, if you want to play with IPv6 multicast routing, then you need to enable/configure pimsm6 as well. > Another issue I'm having is bridge ports. The Linux routers have > SmallTree multiport cards which I configure using the brctl command > creating a "br0" interface. what I have found is xorp blows up on the > br0 interface. I believe the issue here is actually a linux multicast > patch problem with both Ipv4 and v6. But if you know anyone who has > gotten the br0 interface to work, please let me know. My work around is > to use direct configs and not bridging. Wastes IP addresses but will > get the job done I think. Unfortunately I haven't played with bridge ports so I don't know the exact steps to get it working. Did you try to: 1) Configure the br0 interface inside Linux before starting XORP. Also, make sure that it has IP address. 2) Use the "default-system-config" config statement like before to configure the interface inside XORP: interfaces { interface br0 { default-system-config } } Regards, Pavlin > ....Chris > > > interfaces { > restore-original-config-on-shutdown: false > interface eth0 { > description: "Eth0 interface" > disable: false > vif eth0 { > disable: false > address 10.128.142.196 { > prefix-length: 24 > broadcast: 10.128.142.255 > disable: false > } > address 99999:9999:99999:3:400:8000:0:196 { > prefix-length: 84 > disable: false > } > } > } > } > > fea { > unicast-forwarding4 { > disable: false > forwarding-entries { > retain-on-startup: false > retain-on-shutdown: false > } > } > unicast-forwarding6 { > disable: false > forwarding-entries { > retain-on-startup: false > retain-on-shutdown: false > } > } > } > > protocols { > static { > route 0.0.0.0/0 { > next-hop: 192.168.1.1 > metric: 1 > } > } > } > > 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" > } > } > } > } > > protocols { > ospf4 { > router-id: 192.168.1.106 > /* Redistribute of hard interfaces and manual routes */ > /* export: "connected" */ > /* export: "static" */ > area 0.0.0.0 { > interface eth0 { > /* link-type: "broadcast" */ > vif eth0 { > address 10.128.142.196 { > /* priority: 128 */ > /* hello-interval: 10 */ > /* router-dead-interval: 40 */ > /* interface-cost: 1 */ > /* retransmit-interval: 5 */ > /* transit-delay: 1 */ > /* passive: false */ > /* disable: false */ > } > } > } > } > } > ospf6 0 { > router-id: 102.168.1.106 > area 0.0.0.0 { > interface eth0 { > vif eth0 { > address 9999:9999:9999:3:400:8000:0:196 { > /* priority: 128 */ > /* hello-interval: 10 */ > /* router-dead-interval: 40 */ > /* interface-cost: 1 */ > /* retransmit-interval: 5 */ > /* transit-delay: 1 */ > /* passive: false */ > /* disable: false */ > } > } > } > } > } > } > > plumbing { > mfea4 { > disable: false > interface eth0 { > vif eth0 { > disable: false > } > } > interface register_vif { > vif register_vif { > /* Note: this vif should be always enabled */ > disable: false > } > } > traceoptions { > flag all { > disable: false > } > } > } > mfea6 { > disable: false > interface eth0 { > vif eth0 { > disable: false > } > } > interface register_vif { > vif register_vif { > disable: false > } > } > traceoptions { > flag all { > disable: false > } > } > } > } > > protocols { > igmp { > disable: false > interface eth0 { > vif eth0 { > disable: false > /* version: 2 */ > /* enable-ip-router-alert-option-check: false */ > /* query-interval: 125 */ > /* query-last-member-interval: 1 */ > /* query-response-interval: 10 */ > /* robust-count: 2 */ > } > } > traceoptions { > flag all { > disable: false > } > } > } > } > > protocols { > mld { > disable: false > interface eth0 { > vif eth0 { > disable: false > version: 1 > enable-ip-router-alert-option-check: false > query-interval: 125 > query-last-member-interval: 1 > query-response-interval: 10 > robust-count: 2 > } > } > traceoptions { > flag all { > disable: false > } > } > } > } > > 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 register_vif { > vif register_vif { > /* Note: this vif should be always enabled */ > disable: false > } > } > > static-rps { > rp 10.128.142.196{ > group-prefix 224.0.0.0/4 { > /* rp-priority: 192 */ > /* hash-mask-len: 30 */ > } > } > } > > bootstrap { > disable: false > cand-bsr { > scope-zone 224.0.0.0/4 { > /* is-scope-zone: false */ > cand-bsr-by-vif-name: "eth0" > /* cand-bsr-by-vif-addr: 192.168.1.106 */ > /* bsr-priority: 1 */ > /* hash-mask-len: 30 */ > } > } > > cand-rp { > group-prefix 224.0.0.0/4 { > /* is-scope-zone: false */ > cand-rp-by-vif-name: "eth0" > /* cand-rp-by-vif-addr: 192.168.1.106 */ > /* rp-priority: 192 */ > /* rp-holdtime: 150 */ > } > } > } > > switch-to-spt-threshold { > /* approx. 1K bytes/s (10Kbps) threshold */ > disable: false > interval: 100 > bytes: 102400 > } > > 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 > } > } > > > > /* > * See xorp/mibs/snmpdscripts/README on how to configure Net-SNMP in > your host > * before uncommenting the snmp section below. > * Also check that the "bgp4_mib_1657.so" exists in the correct location. > */ > > /* > protocols { > snmp { > mib-module bgp4_mib_1657 { > abs-path: "/usr/local/xorp/mibs/bgp4_mib_1657.so" > } > } > } > */ > > Pavlin Radoslavov wrote: > >> Well I thought I had tested the default-system-config configuration but > >> it appears not. After deleting all the interface section and > >> reprogramming as you suggested using only "default-system-config", its > >> working now. However, I did try your second suggesting using both hard > >> coded addresses and using the default-system-config and both worked and > >> both show commands display the exact same information. So it seems when > >> adding other configurations like "mld" have some issue with hard coding > >> interface addresses. Besides the simple configuration you suggest of > >> just configuring the default interface and mfea6, would you want > >> something else tried but with the more complex configuration file that > >> works when using just defaults in the interface section? > >> > >> Output from your second Option (b) suggestion: > >> > >> xorp at FEON.nrl.gigef.net> show interfaces > >> eth0/eth0: Flags: mtu 1500 > >> inet6 2001:480:f022:3:400:8000:0:196 prefixlen 84 > >> inet6 fe80::21a:6bff:fe69:a875 prefixlen 64 > >> inet 10.128.142.196 subnet 10.128.142.0/24 broadcast 10.128.142.255 > >> physical index 4 > >> ether 0:1a:6b:69:a8:75 > >> xorp at FEON.nrl.gigef.net> show mfea6 interface > >> Interface State Vif/PifIndex Addr Flags > >> eth0 UP 0/4 2001:480:f022:3:400:8000:0:196 > >> MULTICAST BROADCAST KERN_UP > >> register_vif UP 1/4 2001:480:f022:3:400:8000:0:196 > >> PIM_REGISTER KERN_UP > >> > > > > Sorry, the second command should have been > > "show mfea6 interface address" and shound print both IPv6 addresses: > > 2001:480:f022:3:400:8000:0:196 and fe80::21a:6bff:fe69:a875 . > > > > Could you send your "interfaces" config section when you explicitly > > configure the IP addresses instead of using "default-system-config". > > I just tried it, and appears to work, though I had to use FreeBSD > > instead of Linux, because the Linux version we have doesn't support > > IPv6 multicast routing. > > > > Regards, > > Pavlin > > > > _______________________________________________ > > Xorp-users mailing list > > Xorp-users at xorp.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > > > > > > > -- > Christopher Robson > Senior Computer Scientist, GS-15 > Naval Research Laboratory > Center for Computational Science > Networking, Code 5591 > 4555 Overlook ave. > Washington, D.C. 20375-5320 > (COM) 202-404-3138 > (VoIP) 2024043138 at GIGEF > (CHAT) Chris.Robson at GIGEF > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From quamar_niyaz at yahoo.co.in Fri Sep 7 23:22:47 2007 From: quamar_niyaz at yahoo.co.in (quamar niyaz) Date: Sat, 8 Sep 2007 07:22:47 +0100 (BST) Subject: [Xorp-users] help:initialization problem Message-ID: <867916.30585.qm@web8404.mail.in.yahoo.com> dear friends, i have installed xorp-1.4 on fedora core 5 (linux kernel -2.6.x.x) in the root's home directory.installation was complete but when i'm trying to execute the command [root at niyaz ~]# /root/xorp-1.4/rtrmgr/xorpsh it's output is Waiting for xorp_rtrmgr... [ 2007/09/06 15:25:15 ERROR xorpsh:3446 RTRMGR +90 xorpsh_main.cc wait_for_xrl_router_ready ] XrlRouter failed. No Finder? [ 2007/09/06 15:25:15 ERROR xorpsh:3446 RTRMGR +897 xorpsh_main.cc main ] xorpsh exiting due to an init error: Failed to connect to the router manager. And after that no xorp interface is coming similar output is comin by executing the command ./xorpsh .Please help me out to overcome this problem as soon as possible i need of it. --------------------------------- Unlimited freedom, unlimited storage. Get it now -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070908/17751ed2/attachment.html From quamar_niyaz at yahoo.co.in Sat Sep 8 00:20:37 2007 From: quamar_niyaz at yahoo.co.in (quamar niyaz) Date: Sat, 8 Sep 2007 08:20:37 +0100 (BST) Subject: [Xorp-users] help:problem Message-ID: <347992.19090.qm@web8411.mail.in.yahoo.com> dear friends, i have installed xorp-1.4 on fedora core 5 (linux kernel -2.6.x.x) in the root's home directory.installation was complete but when i'm trying to execute the command [root at niyaz ~]# /root/xorp-1.4/rtrmgr/xorpsh it's output is Waiting for xorp_rtrmgr... [ 2007/09/06 15:25:15 ERROR xorpsh:3446 RTRMGR +90 xorpsh_main.cc wait_for_xrl_router_ready ] XrlRouter failed. No Finder? [ 2007/09/06 15:25:15 ERROR xorpsh:3446 RTRMGR +897 xorpsh_main.cc main ] xorpsh exiting due to an init error: Failed to connect to the router manager. And after that no xorp interface is coming similar output is comin by executing the command ./xorpsh .Please help me out to overcome this problem as soon as possible i need of it. --------------------------------- Why delete messages? Unlimited storage is just a click away. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070908/0a006870/attachment.html From pavlin at icir.org Sat Sep 8 01:04:20 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Sat, 08 Sep 2007 01:04:20 -0700 Subject: [Xorp-users] help:initialization problem In-Reply-To: Message from quamar niyaz of "Sat, 08 Sep 2007 07:22:47 BST." <867916.30585.qm@web8404.mail.in.yahoo.com> Message-ID: <200709080804.l8884KO5002161@possum.icir.org> quamar niyaz wrote: > dear friends, > i have installed xorp-1.4 on fedora core 5 (linux kernel -2.6.x.x) in the root's home directory.installation was complete but when i'm trying to execute the command [root at niyaz ~]# /root/xorp-1.4/rtrmgr/xorpsh it's output is > Waiting for xorp_rtrmgr... > [ 2007/09/06 15:25:15 ERROR xorpsh:3446 RTRMGR +90 xorpsh_main.cc wait_for_xrl_router_ready ] XrlRouter failed. No Finder? > [ 2007/09/06 15:25:15 ERROR xorpsh:3446 RTRMGR +897 xorpsh_main.cc main ] xorpsh exiting due to an init error: Failed to connect to the router manager. And after that no xorp interface is coming similar output is comin by executing the command ./xorpsh .Please help me out to overcome this problem as soon as possible i need of it. You need to start first the xorp_rtrmgr. E.g.: cd /root/xorp-1.4/rtrmgr ./xorp_rtrmgr -b my_config.boot where my_config.boot is your XORP configuration file. Only after that you can run xorpsh. Hope that helps, Pavlin > > > --------------------------------- > Unlimited freedom, unlimited storage. Get it now_______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From flash at preferance.ru Sat Sep 8 03:03:36 2007 From: flash at preferance.ru (Yuri Kirsanov) Date: Sat, 8 Sep 2007 14:03:36 +0400 Subject: [Xorp-users] help:problem References: <347992.19090.qm@web8411.mail.in.yahoo.com> Message-ID: <002501c7f1ff$86002760$3ac111ac@FLASH> You have to start xorp_rtrmgr first. Please read the manual how to start and configure xorp correctly. http://www.xorp.org/getting_started.html ----- Original Message ----- From: quamar niyaz To: xorp-users at xorp.org ; pavlin at ICSI.Berkeley.EDU ; zec at tel.fer.hr ; atanu at ICSI.Berkeley.EDU Sent: Saturday, September 08, 2007 11:20 AM Subject: [Xorp-users] help:problem dear friends, i have installed xorp-1.4 on fedora core 5 (linux kernel -2.6.x.x) in the root's home directory.installation was complete but when i'm trying to execute the command [root at niyaz ~]# /root/xorp-1.4/rtrmgr/xorpsh it's output is Waiting for xorp_rtrmgr... [ 2007/09/06 15:25:15 ERROR xorpsh:3446 RTRMGR +90 xorpsh_main.cc wait_for_xrl_router_ready ] XrlRouter failed. No Finder? [ 2007/09/06 15:25:15 ERROR xorpsh:3446 RTRMGR +897 xorpsh_main.cc main ] xorpsh exiting due to an init error: Failed to connect to the router manager. And after that no xorp interface is coming similar output is comin by executing the command ./xorpsh .Please help me out to overcome this problem as soon as possible i need of it. ------------------------------------------------------------------------------ Why delete messages? Unlimited storage is just a click away. ------------------------------------------------------------------------------ _______________________________________________ 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/20070908/99bd3bc0/attachment.html From Chris.Robson at nrl.navy.mil Sat Sep 8 03:17:17 2007 From: Chris.Robson at nrl.navy.mil (Chris Robson) Date: Sat, 08 Sep 2007 06:17:17 -0400 Subject: [Xorp-users] Module not foudn problem In-Reply-To: <200709080514.l885EtUX000914@possum.icir.org> References: <200709080514.l885EtUX000914@possum.icir.org> Message-ID: <46E276AD.7060503@nrl.navy.mil> > Yes, currently it is hassle to require explicit configuration of the > IPv6 link-local address, so the "default-system-config" alternative > can be a simpler solution for you. > Not a problem.... Other than..... It seems if a port, even if its configured completely and correct but not disabled, xorp will crash. But think I read something that this was being looked into. > BTW, "99999:9999:99999:3:400:8000:0:196" is not a valid IPv6 > address. > Yes, I know, for policy reasons the real address has been removed. > Also, in your PIM-SM configuration you should use either the > "static-rps" or the "bootstrap" mechanism, but not both. > BTW, if you want to play with IPv6 multicast routing, then you need > to enable/configure pimsm6 as well. > > Agree, right now I'm still trying to get a handle on how this works with xorp.... thanks for the insight. >> Another issue I'm having is bridge ports. The Linux routers have >> SmallTree multiport cards which I configure using the brctl command >> addresses but will >> >> Unfortunately I haven't played with bridge ports so I don't know the >> exact steps to get it working. >> Did you try to: >> >> 1) Configure the br0 interface inside Linux before starting >> XORP. Also, make sure that it has IP address. >> 2) Use the "default-system-config" config statement like before to >> configure the interface inside XORP: >> >> interfaces { >> interface br0 { >> default-system-config >> } >> } >> >> Yes, I have done this, I've been using the bridge interface successfully with unicast for some time. Again, I think the issue isnt xorps but the multicast patch for linux not working with bridge ports. In fact the patch may have a problem with tunnel ports like OpenVPN's tun interfaces as well. I was hoping someone else might have run into this problem also. In the mean time and because of a schedule crunch, I've reconfigured without the bridge port assignment. As a side question for linux people out there, what is the word on linux IPv6 multicast support ? Its curious that the patch has been out for sometime but hasnt made it into the mainstream linux kernel? Thanks again.....chris >> ....Chris >> >> >> interfaces { >> restore-original-config-on-shutdown: false >> interface eth0 { >> description: "Eth0 interface" >> disable: false >> vif eth0 { >> disable: false >> address 10.128.142.196 { >> prefix-length: 24 >> broadcast: 10.128.142.255 >> disable: false >> } >> address 99999:9999:99999:3:400:8000:0:196 { >> prefix-length: 84 >> disable: false >> } >> } >> } >> } >> >> fea { >> unicast-forwarding4 { >> disable: false >> forwarding-entries { >> retain-on-startup: false >> retain-on-shutdown: false >> } >> } >> unicast-forwarding6 { >> disable: false >> forwarding-entries { >> retain-on-startup: false >> retain-on-shutdown: false >> } >> } >> } >> >> protocols { >> static { >> route 0.0.0.0/0 { >> next-hop: 192.168.1.1 >> metric: 1 >> } >> } >> } >> >> 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" >> } >> } >> } >> } >> >> protocols { >> ospf4 { >> router-id: 192.168.1.106 >> /* Redistribute of hard interfaces and manual routes */ >> /* export: "connected" */ >> /* export: "static" */ >> area 0.0.0.0 { >> interface eth0 { >> /* link-type: "broadcast" */ >> vif eth0 { >> address 10.128.142.196 { >> /* priority: 128 */ >> /* hello-interval: 10 */ >> /* router-dead-interval: 40 */ >> /* interface-cost: 1 */ >> /* retransmit-interval: 5 */ >> /* transit-delay: 1 */ >> /* passive: false */ >> /* disable: false */ >> } >> } >> } >> } >> } >> ospf6 0 { >> router-id: 102.168.1.106 >> area 0.0.0.0 { >> interface eth0 { >> vif eth0 { >> address 9999:9999:9999:3:400:8000:0:196 { >> /* priority: 128 */ >> /* hello-interval: 10 */ >> /* router-dead-interval: 40 */ >> /* interface-cost: 1 */ >> /* retransmit-interval: 5 */ >> /* transit-delay: 1 */ >> /* passive: false */ >> /* disable: false */ >> } >> } >> } >> } >> } >> } >> >> plumbing { >> mfea4 { >> disable: false >> interface eth0 { >> vif eth0 { >> disable: false >> } >> } >> interface register_vif { >> vif register_vif { >> /* Note: this vif should be always enabled */ >> disable: false >> } >> } >> traceoptions { >> flag all { >> disable: false >> } >> } >> } >> mfea6 { >> disable: false >> interface eth0 { >> vif eth0 { >> disable: false >> } >> } >> interface register_vif { >> vif register_vif { >> disable: false >> } >> } >> traceoptions { >> flag all { >> disable: false >> } >> } >> } >> } >> >> protocols { >> igmp { >> disable: false >> interface eth0 { >> vif eth0 { >> disable: false >> /* version: 2 */ >> /* enable-ip-router-alert-option-check: false */ >> /* query-interval: 125 */ >> /* query-last-member-interval: 1 */ >> /* query-response-interval: 10 */ >> /* robust-count: 2 */ >> } >> } >> traceoptions { >> flag all { >> disable: false >> } >> } >> } >> } >> >> protocols { >> mld { >> disable: false >> interface eth0 { >> vif eth0 { >> disable: false >> version: 1 >> enable-ip-router-alert-option-check: false >> query-interval: 125 >> query-last-member-interval: 1 >> query-response-interval: 10 >> robust-count: 2 >> } >> } >> traceoptions { >> flag all { >> disable: false >> } >> } >> } >> } >> >> 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 register_vif { >> vif register_vif { >> /* Note: this vif should be always enabled */ >> disable: false >> } >> } >> >> static-rps { >> rp 10.128.142.196{ >> group-prefix 224.0.0.0/4 { >> /* rp-priority: 192 */ >> /* hash-mask-len: 30 */ >> } >> } >> } >> >> bootstrap { >> disable: false >> cand-bsr { >> scope-zone 224.0.0.0/4 { >> /* is-scope-zone: false */ >> cand-bsr-by-vif-name: "eth0" >> /* cand-bsr-by-vif-addr: 192.168.1.106 */ >> /* bsr-priority: 1 */ >> /* hash-mask-len: 30 */ >> } >> } >> >> cand-rp { >> group-prefix 224.0.0.0/4 { >> /* is-scope-zone: false */ >> cand-rp-by-vif-name: "eth0" >> /* cand-rp-by-vif-addr: 192.168.1.106 */ >> /* rp-priority: 192 */ >> /* rp-holdtime: 150 */ >> } >> } >> } >> >> switch-to-spt-threshold { >> /* approx. 1K bytes/s (10Kbps) threshold */ >> disable: false >> interval: 100 >> bytes: 102400 >> } >> >> 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 >> } >> } >> >> >> >> /* >> * See xorp/mibs/snmpdscripts/README on how to configure Net-SNMP in >> your host >> * before uncommenting the snmp section below. >> * Also check that the "bgp4_mib_1657.so" exists in the correct location. >> */ >> >> /* >> protocols { >> snmp { >> mib-module bgp4_mib_1657 { >> abs-path: "/usr/local/xorp/mibs/bgp4_mib_1657.so" >> } >> } >> } >> */ >> >> Pavlin Radoslavov wrote: >> >>>> Well I thought I had tested the default-system-config configuration but >>>> it appears not. After deleting all the interface section and >>>> reprogramming as you suggested using only "default-system-config", its >>>> working now. However, I did try your second suggesting using both hard >>>> coded addresses and using the default-system-config and both worked and >>>> both show commands display the exact same information. So it seems when >>>> adding other configurations like "mld" have some issue with hard coding >>>> interface addresses. Besides the simple configuration you suggest of >>>> just configuring the default interface and mfea6, would you want >>>> something else tried but with the more complex configuration file that >>>> works when using just defaults in the interface section? >>>> >>>> Output from your second Option (b) suggestion: >>>> >>>> xorp at FEON.nrl.gigef.net> show interfaces >>>> eth0/eth0: Flags: mtu 150