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 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 >> > > > -- 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 Sat Sep 8 17:07:33 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Sat, 08 Sep 2007 17:07:33 -0700 Subject: [Xorp-users] Module not foudn problem In-Reply-To: Message from Chris Robson of "Sat, 08 Sep 2007 06:17:17 EDT." <46E276AD.7060503@nrl.navy.mil> Message-ID: <200709090007.l8907X5q009292@possum.icir.org> > 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? I believe the patch has been added to the USAGI tree (http://www.linux-ipv6.org/) so probably it is up to them to add it to the mainstream Linux kernel. You might want to send your question to the usagi-users ML: usagi-users at linux-ipv6.org Regards, Pavlin From ror.sanjeev at gmail.com Sun Sep 9 02:07:00 2007 From: ror.sanjeev at gmail.com (sanjeev kumar) Date: Sun, 9 Sep 2007 14:37:00 +0530 Subject: [Xorp-users] failed to run rtrmgr: Message-ID: <477942240709090207h69b13252ye383c69af7bec762@mail.gmail.com> i failed to run rtrmgr..could u plz go through these.. root at cmj-cnie-advait:/home/sanjeev/Desktop/xorp-1.4/rtrmgr# ./xorp_rtrmgr [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.ccadd_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.ccadd_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.ccadd_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.ccadd_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.ccadd_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.ccadd_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.ccadd_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.ccadd_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.ccadd_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.ccadd_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.ccadd_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.ccadd_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.ccadd_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.ccadd_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.ccadd_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.ccadd_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.ccadd_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.ccadd_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.ccadd_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.ccadd_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.ccadd_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.ccadd_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.ccadd_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.ccadd_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.ccadd_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.ccadd_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.ccadd_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.ccadd_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.ccadd_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.ccadd_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +330 main_rtrmgr.cc run ] rtrmgr shutting down due to an init error: Failed to open config file: /home/sanjeev/Desktop/xorp-1.4/rtrmgr/config.boot -- Efforts may fail,But don't Fail to make efforts. --------- Sanjeev Kumar Project Engineer CDAC(Formerly NCST) Juhu,Mumbai-400049 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070909/b4b449c7/attachment.html From flash at preferance.ru Sun Sep 9 02:39:47 2007 From: flash at preferance.ru (Yuri Kirsanov) Date: Sun, 9 Sep 2007 13:39:47 +0400 Subject: [Xorp-users] failed to run rtrmgr: References: <477942240709090207h69b13252ye383c69af7bec762@mail.gmail.com> Message-ID: <002301c7f2c5$5c6265a0$3ac111ac@FLASH> useradd -M xorp will solve it. Your system lacks of nececcary users and/or groups. ----- Original Message ----- From: sanjeev kumar To: xorp-users at xorp.org Sent: Sunday, September 09, 2007 1:07 PM Subject: [Xorp-users] failed to run rtrmgr: i failed to run rtrmgr..could u plz go through these.. root at cmj-cnie-advait:/home/sanjeev/Desktop/xorp-1.4/rtrmgr# ./xorp_rtrmgr [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +330 main_rtrmgr.cc run ] rtrmgr shutting down due to an init error: Failed to open config file: /home/sanjeev/Desktop/xorp- 1.4/rtrmgr/config.boot -- Efforts may fail,But don't Fail to make efforts. --------- Sanjeev Kumar Project Engineer CDAC(Formerly NCST) Juhu,Mumbai-400049 ------------------------------------------------------------------------------ _______________________________________________ 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/20070909/fbedd6a2/attachment.html From quamar_niyaz at yahoo.co.in Sun Sep 9 07:37:52 2007 From: quamar_niyaz at yahoo.co.in (quamar niyaz) Date: Sun, 9 Sep 2007 15:37:52 +0100 (BST) Subject: [Xorp-users] help =>how to create groups Message-ID: <96831.48325.qm@web8404.mail.in.yahoo.com> after running the command ./xorp_rtrmgr -b config.boot we got the following output [root at localhost rtrmgr]# ./xorp_rtrmgr -b k_config.boot [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. [ 2007/09/08 18:43:48 INFO xorp_rtrmgr:2517 RTRMGR +239 master_conf_tree.cc execute ] Changed modules: interfaces [ 2007/09/08 18:43:48 INFO xorp_rtrmgr:2517 RTRMGR +96 module_manager.cc execute ] Executing module: interfaces (fea/xorp_fea) [ 2007/09/08 18:43:49 INFO xorp_fea MFEA ] MFEA enabled [ 2007/09/08 18:43:49 INFO xorp_fea MFEA ] CLI enabled [ 2007/09/08 18:43:49 INFO xorp_fea MFEA ] CLI started [ 2007/09/08 18:43:49 INFO xorp_fea MFEA ] MFEA enabled [ 2007/09/08 18:43:49 INFO xorp_fea MFEA ] CLI enabled [ 2007/09/08 18:43:49 INFO xorp_fea MFEA ] CLI started [ 2007/09/08 18:43:50 INFO xorp_rtrmgr:2517 RTRMGR +2228 task.cc run_task ] please help us solve this probelm --------------------------------- Get the freedom to save as many mails as you wish. Click here to know how. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070909/5be2a84a/attachment-0001.html From pavlin at icir.org Sun Sep 9 10:39:17 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Sun, 09 Sep 2007 10:39:17 -0700 Subject: [Xorp-users] failed to run rtrmgr: In-Reply-To: Message from "Yuri Kirsanov" of "Sun, 09 Sep 2007 13:39:47 +0400." <002301c7f2c5$5c6265a0$3ac111ac@FLASH> Message-ID: <200709091739.l89HdHqU027248@possum.icir.org> Yuri Kirsanov wrote: > useradd -M xorp will solve it. Your system lacks of nececcary users and/or groups. You also need to create the config.boot configuration file, and then tell the rtrmgr to use it: ./xorp_rtrmgr -b config.boot Regards, Pavlin > ----- Original Message ----- > From: sanjeev kumar > To: xorp-users at xorp.org > Sent: Sunday, September 09, 2007 1:07 PM > Subject: [Xorp-users] failed to run rtrmgr: > > > i failed to run rtrmgr..could u plz go through these.. > > root at cmj-cnie-advait:/home/sanjeev/Desktop/xorp-1.4/rtrmgr# ./xorp_rtrmgr > [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/09 14:38:19 ERROR xorp_rtrmgr:12631 RTRMGR +330 main_rtrmgr.cc run ] rtrmgr shutting down due to an init error: Failed to open config file: /home/sanjeev/Desktop/xorp- 1.4/rtrmgr/config.boot > > > -- > Efforts may fail,But don't Fail to make efforts. > --------- > Sanjeev Kumar > Project Engineer > CDAC(Formerly NCST) > Juhu,Mumbai-400049 > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at icir.org Sun Sep 9 10:41:34 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Sun, 09 Sep 2007 10:41:34 -0700 Subject: [Xorp-users] help =>how to create groups In-Reply-To: Message from quamar niyaz of "Sun, 09 Sep 2007 15:37:52 BST." <96831.48325.qm@web8404.mail.in.yahoo.com> Message-ID: <200709091741.l89HfYas027281@possum.icir.org> quamar niyaz wrote: > after running the command ./xorp_rtrmgr -b config.boot This was just answered on the mailing list (in a different thread): http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2007-September/001960.html Regards, Pavlin > > we got the following output > [root at localhost rtrmgr]# ./xorp_rtrmgr -b k_config.boot > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 ERROR xorp_rtrmgr:2517 RTRMGR +136 userdb.cc add_user ] Group "xorp" does not exist on this system. > [ 2007/09/08 18:43:48 INFO xorp_rtrmgr:2517 RTRMGR +239 master_conf_tree.cc execute ] Changed modules: interfaces > [ 2007/09/08 18:43:48 INFO xorp_rtrmgr:2517 RTRMGR +96 module_manager.cc execute ] Executing module: interfaces (fea/xorp_fea) > [ 2007/09/08 18:43:49 INFO xorp_fea MFEA ] MFEA enabled > [ 2007/09/08 18:43:49 INFO xorp_fea MFEA ] CLI enabled > [ 2007/09/08 18:43:49 INFO xorp_fea MFEA ] CLI started > [ 2007/09/08 18:43:49 INFO xorp_fea MFEA ] MFEA enabled > [ 2007/09/08 18:43:49 INFO xorp_fea MFEA ] CLI enabled > [ 2007/09/08 18:43:49 INFO xorp_fea MFEA ] CLI started > [ 2007/09/08 18:43:50 INFO xorp_rtrmgr:2517 RTRMGR +2228 task.cc run_task ] > > please help us solve this probelm > > > > > > --------------------------------- > Get the freedom to save as many mails as you wish. Click here to know how._______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From greearb at candelatech.com Mon Sep 10 21:32:14 2007 From: greearb at candelatech.com (Ben Greear) Date: Mon, 10 Sep 2007 21:32:14 -0700 Subject: [Xorp-users] Multiple xorp instances performance improvements. In-Reply-To: <200709080409.l88493NN095225@possum.icir.org> References: <200709080409.l88493NN095225@possum.icir.org> Message-ID: <46E61A4E.3080603@candelatech.com> Pavlin Radoslavov wrote: > 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. > I think so..I haven't followed the code far enough to see exactly how it is created/bound yet. >> 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. > Fair enough, though if we reach 50 xorps, with each sending 1 pkt per second, that means that all 50 will be receiving 50 per second..and this is about what VOIP costs. I do know that running 50 VOIP calls on a system will drag down a single CPU easily. I'll first patch xorp to not print error messages in this case, which should help a lot, and then we'll run some performance tests. >> 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! > Just for argument's sake..that memory is not actually used unless it is required..the 256 just means the kernel can use it if it wants (at least in Linux). Also, having a packet copied 50 times is probably worse on memory than 50 sockets, 49 of which are empty. > Though, in general I'd say to hold back premature optimizations > until it is clear the optimization is necessary. > Good advice, as always :) Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Tue Sep 11 03:02:48 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 11 Sep 2007 03:02:48 -0700 Subject: [Xorp-users] Xorp now available in Debian [installer@ftp-master.debian.org: xorp_1.5~cvs.20070824-1_i386.changes ACCEPTED] In-Reply-To: Message from Javier =?iso-8859-1?Q?Fern=E1ndez-Sanguino_Pe=F1a?= of "Thu, 06 Sep 2007 23:44:14 +0200." <20070906214414.GA13758@javifsp.no-ip.org> Message-ID: <200709111002.l8BA2mFP061138@possum.icir.org> Thank you for your dedicated and hard work! Well done!! Pavlin Javier Fern?ndez-Sanguino Pe?a wrote: > 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 ----- > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From kristian at spritelink.net Tue Sep 11 03:38:32 2007 From: kristian at spritelink.net (Kristian Larsson) Date: Tue, 11 Sep 2007 12:38:32 +0200 Subject: [Xorp-users] Multiple xorp instances performance improvements. In-Reply-To: <46E61A4E.3080603@candelatech.com> References: <200709080409.l88493NN095225@possum.icir.org> <46E61A4E.3080603@candelatech.com> Message-ID: <46E67028.9020609@spritelink.net> Ben Greear wrote: > Pavlin Radoslavov wrote: >> 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. >> > I think so..I haven't followed the code far enough to see exactly how > it is created/bound yet. >>> 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. >> > Fair enough, though if we reach 50 xorps, with each sending 1 pkt per > second, that means > that all 50 will be receiving 50 per second..and this is about what VOIP > costs. I do know that > running 50 VOIP calls on a system will drag down a single CPU easily. I'm not really in to this discussion, but... 50 VOIP calls does not equal 50 packets per second. Let's say we are using G.729 for coding our voice, it's a 8Kbps codec and we use cRTP (compressed RTP). G.729 sample size being 10ms this equals 80 bits per sample. It's quite normal to use two samples per packet, ie 20 bytes which in turn would equal somewhere around 50 packets per second. Now 50 packets per second is no problem for a normal computer. Everyone is running Skype or something like it and the processing of that is no problem. Not even 50 calls, ie 2500 packets per second should be any trouble to handle as long as you're not doing any transcoding... it's the coding stuff that's CPU intense. Just for a reference note, I've ran computers as media gateways with 120 simultaneous calls. They were loaded but ran fine. Anyway, enough jibberish about VOIP. I don't think 50 packets per second should pose any problem at all to XORP and so I'm with Pavlin. We need some real measurement data to show that there is actually a problem. Cheers, Kristian. From arvind at macil.in Tue Sep 11 04:06:54 2007 From: arvind at macil.in (arvind) Date: Tue, 11 Sep 2007 16:36:54 +0530 Subject: [Xorp-users] xorp process Message-ID: <1189508814.31289.8.camel@localhost.localdomain> i have created my own xorp process(my_test) my_test.xif have the following interface my_test/0.3 { enable_my_test ? msg:txt print_message ? print_message:txt show_message ? show_message:txt } my_test.gif have the following /* $XORP: xorp/xrl/targets/my_test.tgt,v 1.3 2005/01/29 07:14:32 bms Exp $ */ #include "my_test.xif" target my_test implements \ my_test/0.3 I mentioned my_test *.cc *.hh similar to static_routes After I compiled i got exe file. while running exe i got the following ./xorp_my_test (whether this is correct argument) -> gives nothing ./xorp_my_test -F 10.10.10.196:8080 gives the following finder_disconnect_event ] Finder disconnect event. Exiting immediately... [ 2007/09/11 16:28:33 ERROR xorp_my_test:31283 MY_TEST +67 xrl_my_test_node.cc finder_disconnect_event ] Finder disconnect event. Exiting immediately... [ 2007/09/11 16:28:33 ERROR xorp_my_test:31283 MY_TEST +67 xrl_my_test_node.cc finder_disconnect_event ] Finder disconnect event. Exiting immediately... [ 2007/09/11 16:28:33 ERROR xorp_my_test:31283 MY_TEST +67 xrl_my_test_node.cc finder_disconnect_event ] Finder disconnect event. Exiting immediately... [ 2007/09/11 16:28:34 ERROR xorp_my_test:31283 MY_TEST +67 xrl_my_test_node.cc finder_disconnect_event ] Finder disconnect event. Exiting immediately... [ 2007/09/11 16:28:34 ERROR xorp_my_test:31283 MY_TEST +67 xrl_my_test_node.cc finder_disconnect_event ] Finder disconnect event. Exiting immediately... [ 2007/09/11 16:28:34 ERROR xorp_my_test:31283 MY_TEST +67 xrl_my_test_node.cc finder_disconnect_event ] Finder disconnect event. Exiting immediately... [ 2007/09/11 16:28:34 ERROR xorp_my_test:31283 MY_TEST +67 xrl_my_test_node.cc finder_disconnect_event ] Finder disconnect event. Exiting immediately... [ 2007/09/11 16:28:34 ERROR xorp_my_test:31283 MY_TEST +67 xrl_my_test_node.cc finder_disconnect_event ] Finder disconnect event. Exiting immediately... [ 2007/09/11 16:28:34 ERROR xorp_my_test:31283 MY_TEST +67 xrl_my_test_node.cc finder_disconnect_event ] Finder disconnect event. Exiting immediately... [ 2007/09/11 16:28:34 ERROR xorp_my_test:31283 MY_TEST +67 xrl_my_test_node.cc finder_disconnect_event ] Finder disconnect event. Exiting immediately... what is the procedure to work this From greearb at candelatech.com Tue Sep 11 14:59:14 2007 From: greearb at candelatech.com (Ben Greear) Date: Tue, 11 Sep 2007 14:59:14 -0700 Subject: [Xorp-users] Question on OSPF priority. Message-ID: <46E70FB2.7050308@candelatech.com> Suppose I have 3 routers: A, B, C They are connected with links: A==B, B==C I also have them each connected to a switch, so that A can talk directly over that switch to B and C. I want the switch link to not be used unless A cannot get to C through B. I tried setting priority, but it seems OSPF always uses the switch interfaces. The manual isn't clear whether a larger priority value is better or worse, but I tried making rddVR48 (the switch interface to have 11 as well as 200, and each time rddVR44 was effectively ignored.) Any ideas? Thanks, Ben protocols { ospf4 { router-id: 10.0.0.2 area 0.0.0.0 { interface rddVR44 { vif rddVR44 { address 10.4.0.1 { priority: 128 } } } interface rddVR48 { vif rddVR48 { address 10.5.0.3 { priority: 11 } } } ... -- Ben Greear Candela Technologies Inc http://www.candelatech.com From atanu at ICSI.Berkeley.EDU Wed Sep 12 00:40:05 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Wed, 12 Sep 2007 00:40:05 -0700 Subject: [Xorp-users] Question on OSPF priority. In-Reply-To: Message from Ben Greear of "Tue, 11 Sep 2007 14:59:14 PDT." <46E70FB2.7050308@candelatech.com> Message-ID: <69093.1189582805@tigger.icir.org> Hi, The priority is used to bias the selection of the designated router. I think that it is the interface-cost that you should be changing to bias the routing. Atanu. >>>>> "Ben" == Ben Greear writes: Ben> Suppose I have 3 routers: A, B, C Ben> They are connected with links: A==B, B==C Ben> I also have them each connected to a switch, so that A can talk directly Ben> over that switch to B and C. Ben> I want the switch link to not be used unless A cannot get to C through B. Ben> I tried setting priority, but it seems OSPF always uses the switch Ben> interfaces. The manual isn't clear whether a larger priority value Ben> is better or worse, but I tried making rddVR48 (the switch interface Ben> to have 11 as well as 200, and each time rddVR44 was effectively Ben> ignored.) Ben> Any ideas? Ben> Thanks, Ben> Ben Ben> protocols { Ben> ospf4 { Ben> router-id: 10.0.0.2 Ben> area 0.0.0.0 { Ben> interface rddVR44 { Ben> vif rddVR44 { Ben> address 10.4.0.1 { Ben> priority: 128 Ben> } Ben> } Ben> } Ben> interface rddVR48 { Ben> vif rddVR48 { Ben> address 10.5.0.3 { Ben> priority: 11 Ben> } Ben> } Ben> } Ben> ... Ben> -- Ben> Ben Greear Ben> Candela Technologies Inc http://www.candelatech.com Ben> _______________________________________________ Ben> Xorp-users mailing list Ben> Xorp-users at xorp.org Ben> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at icir.org Wed Sep 12 12:30:00 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 12 Sep 2007 12:30:00 -0700 Subject: [Xorp-users] xorp process In-Reply-To: Message from arvind of "Tue, 11 Sep 2007 16:36:54 +0530." <1189508814.31289.8.camel@localhost.localdomain> Message-ID: <200709121930.l8CJU0W2081927@possum.icir.org> arvind wrote: > i have created my own xorp process(my_test) > > my_test.xif have the following > > > interface my_test/0.3 { > enable_my_test ? msg:txt > > print_message ? print_message:txt > show_message ? show_message:txt > } > > > > my_test.gif have the following > > /* $XORP: xorp/xrl/targets/my_test.tgt,v 1.3 2005/01/29 07:14:32 bms > Exp $ */ > > #include "my_test.xif" > > target my_test implements \ > my_test/0.3 > > I mentioned my_test *.cc *.hh similar to static_routes > > After I compiled i got exe file. > > > while running exe i got the following > ./xorp_my_test (whether this is correct argument) -> gives nothing Did you start xorp_finder before running ./xorp_my_test? Also, did ./xorp_my_test exited when you executed the above command? If you start ./xorp_finder and then ./xorp_static_routes for example then you will notice that xorp_static_routes also doesn't print anything. Though, if you set the XRLTRACE environment then you will see some XRL-related log messages: env XRLTRACE=yes ./xorp_static_routes > > ./xorp_my_test -F 10.10.10.196:8080 > gives the following Did you have the XRL Finder running on address 10.10.10.196 and port 8080? Regards, Pavlin > > finder_disconnect_event ] Finder disconnect event. Exiting > immediately... > [ 2007/09/11 16:28:33 ERROR xorp_my_test:31283 MY_TEST +67 > xrl_my_test_node.cc finder_disconnect_event ] Finder disconnect event. > Exiting immediately... > [ 2007/09/11 16:28:33 ERROR xorp_my_test:31283 MY_TEST +67 > xrl_my_test_node.cc finder_disconnect_event ] Finder disconnect event. > Exiting immediately... > [ 2007/09/11 16:28:33 ERROR xorp_my_test:31283 MY_TEST +67 > xrl_my_test_node.cc finder_disconnect_event ] Finder disconnect event. > Exiting immediately... > [ 2007/09/11 16:28:34 ERROR xorp_my_test:31283 MY_TEST +67 > xrl_my_test_node.cc finder_disconnect_event ] Finder disconnect event. > Exiting immediately... > [ 2007/09/11 16:28:34 ERROR xorp_my_test:31283 MY_TEST +67 > xrl_my_test_node.cc finder_disconnect_event ] Finder disconnect event. > Exiting immediately... > [ 2007/09/11 16:28:34 ERROR xorp_my_test:31283 MY_TEST +67 > xrl_my_test_node.cc finder_disconnect_event ] Finder disconnect event. > Exiting immediately... > [ 2007/09/11 16:28:34 ERROR xorp_my_test:31283 MY_TEST +67 > xrl_my_test_node.cc finder_disconnect_event ] Finder disconnect event. > Exiting immediately... > [ 2007/09/11 16:28:34 ERROR xorp_my_test:31283 MY_TEST +67 > xrl_my_test_node.cc finder_disconnect_event ] Finder disconnect event. > Exiting immediately... > [ 2007/09/11 16:28:34 ERROR xorp_my_test:31283 MY_TEST +67 > xrl_my_test_node.cc finder_disconnect_event ] Finder disconnect event. > Exiting immediately... > [ 2007/09/11 16:28:34 ERROR xorp_my_test:31283 MY_TEST +67 > xrl_my_test_node.cc finder_disconnect_event ] Finder disconnect event. > Exiting immediately... > > > what is the procedure to work this > > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From greearb at candelatech.com Wed Sep 12 13:43:28 2007 From: greearb at candelatech.com (Ben Greear) Date: Wed, 12 Sep 2007 13:43:28 -0700 Subject: [Xorp-users] Question on OSPF priority. In-Reply-To: <69093.1189582805@tigger.icir.org> References: <69093.1189582805@tigger.icir.org> Message-ID: <46E84F70.2010407@candelatech.com> Atanu Ghosh wrote: > Hi, > > The priority is used to bias the selection of the designated router. I > think that it is the interface-cost that you should be changing to bias > the routing. Yes, that works much better. Thanks. Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Wed Sep 12 13:44:51 2007 From: greearb at candelatech.com (Ben Greear) Date: Wed, 12 Sep 2007 13:44:51 -0700 Subject: [Xorp-users] Build error: rtrmgr/config/Makefile.in Message-ID: <46E84FC3.4020909@candelatech.com> When I do a build after updating cvs, I get this error. It doesn't seem to be critical since I can just run make again and it works: ... config.status: creating rip/tools/Makefile config.status: creating rtrmgr/Makefile config.status: error: cannot find input file: rtrmgr/config/Makefile.in make: *** [Makefile] Error 1 Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Wed Sep 12 14:07:57 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 12 Sep 2007 14:07:57 -0700 Subject: [Xorp-users] Build error: rtrmgr/config/Makefile.in In-Reply-To: Message from Ben Greear of "Wed, 12 Sep 2007 13:44:51 PDT." <46E84FC3.4020909@candelatech.com> Message-ID: <200709122107.l8CL7vhB006139@possum.icir.org> Ben Greear wrote: > When I do a build after updating cvs, I get this error. It doesn't > seem to be critical since I can just run make again and it works: > > ... > config.status: creating rip/tools/Makefile > config.status: creating rtrmgr/Makefile > config.status: error: cannot find input file: rtrmgr/config/Makefile.in > make: *** [Makefile] Error 1 File rtrmgr/config/Makefile.in is suppose to be in the CVS repository, so please make sure you have recent CVS checkout and/or the file hasn't been deleted by accident: http://xorpc.icir.org/cgi-bin/cvsweb.cgi/xorp/rtrmgr/config/ Regards, Pavlin From greearb at candelatech.com Wed Sep 12 14:26:31 2007 From: greearb at candelatech.com (Ben Greear) Date: Wed, 12 Sep 2007 14:26:31 -0700 Subject: [Xorp-users] Build error: rtrmgr/config/Makefile.in In-Reply-To: <200709122107.l8CL7vhB006139@possum.icir.org> References: <200709122107.l8CL7vhB006139@possum.icir.org> Message-ID: <46E85987.5050606@candelatech.com> Pavlin Radoslavov wrote: > Ben Greear wrote: > >> When I do a build after updating cvs, I get this error. It doesn't >> seem to be critical since I can just run make again and it works: >> >> ... >> config.status: creating rip/tools/Makefile >> config.status: creating rtrmgr/Makefile >> config.status: error: cannot find input file: rtrmgr/config/Makefile.in >> make: *** [Makefile] Error 1 > > File rtrmgr/config/Makefile.in is suppose to be in the CVS > repository, so please make sure you have recent CVS checkout > and/or the file hasn't been deleted by accident: > > http://xorpc.icir.org/cgi-bin/cvsweb.cgi/xorp/rtrmgr/config/ Right..I had forgotten the -d argument to cvs to tell it to grab new directories when checking out. Thanks, Ben > > Regards, > Pavlin -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Wed Sep 12 15:12:37 2007 From: greearb at candelatech.com (Ben Greear) Date: Wed, 12 Sep 2007 15:12:37 -0700 Subject: [Xorp-users] Unreachable default route. In-Reply-To: <200708301706.l7UH6uGQ048960@possum.icir.org> References: <200708301706.l7UH6uGQ048960@possum.icir.org> Message-ID: <46E86455.2000102@candelatech.com> Pavlin Radoslavov wrote: > Tim Durack wrote: > >> On a Cisco you would configure a floating static route - that is a >> static with a higher administrative distance than a dynamic routing >> protocol. The static will be overridden by the dynamic, but if the >> dynamic default goes away, the static will be installed. >> >> Not sure if XORP supports this (I don't think you can change admin >> distance), so this probably doesn't help. > > No, unfortunately XORP doesn't support floating static routes (yet). > The RIB itself has already XRL interface to set the admin distance > per protocol, but this interface is not used yet, and it will set > the admin distance for all routes for a given protocol. > > If modifying the admin distance for all static routes (so they are > less preferred than, say, OSPF) is acceptable to you, the easiest > hack is to modify rib/rib.cc (the RIB constructor) and change the > "static" entry for _admin_distances to a value that is larger than > the dynamic protocols (e.g., 220). Does this still use the 'discard0' method that you suggested before? It doesn't seem I can just make up an interface on Linux..it needs to exist or Xorp complains. I tried using 'eth2' on my system instead, and now I get no errors, but I also do not see any routes created. I have not actually loaded the build with the patch you mentioned here, but I figured I should at least get some sort of default route even if it is at too-high priority... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Wed Sep 12 18:16:50 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 12 Sep 2007 18:16:50 -0700 Subject: [Xorp-users] Unreachable default route. In-Reply-To: Message from Ben Greear of "Wed, 12 Sep 2007 15:12:37 PDT." <46E86455.2000102@candelatech.com> Message-ID: <200709130116.l8D1Godo026763@possum.icir.org> Ben Greear wrote: > Pavlin Radoslavov wrote: > > Tim Durack wrote: > > > >> On a Cisco you would configure a floating static route - that is a > >> static with a higher administrative distance than a dynamic routing > >> protocol. The static will be overridden by the dynamic, but if the > >> dynamic default goes away, the static will be installed. > >> > >> Not sure if XORP supports this (I don't think you can change admin > >> distance), so this probably doesn't help. > > > > No, unfortunately XORP doesn't support floating static routes (yet). > > The RIB itself has already XRL interface to set the admin distance > > per protocol, but this interface is not used yet, and it will set > > the admin distance for all routes for a given protocol. > > > > If modifying the admin distance for all static routes (so they are > > less preferred than, say, OSPF) is acceptable to you, the easiest > > hack is to modify rib/rib.cc (the RIB constructor) and change the > > "static" entry for _admin_distances to a value that is larger than > > the dynamic protocols (e.g., 220). > > Does this still use the 'discard0' method that you suggested before? No. > It doesn't seem I can just make up an interface on Linux..it needs > to exist or Xorp complains. I tried using 'eth2' on my system > instead, and now I get no errors, but I also do not see any routes > created. You could use the following configuration on Linux to configure a discard interface and a static route that is blackhole: interfaces { interface my_discard { discard: true vif my_discard { } } } fea { unicast-forwarding4 { disable: false } } protocols { static { interface-route 10.10.10.0/24 { next-hop-interface: "my_discard" next-hop-vif: "my_discard" } } } Then use the "ip route" command to see the blackhole 10.10.10.0/24 route: pavlin at xorp1[20] ip route blackhole 10.10.10.0/24 proto xorp metric 1 notify However, before doing that you might want to update with the latest CVS, because I just fixed a blackhole-related bug. FYI, this bug wasn't the show-stopper but is good to have it fixed in your code: Revision Changes Path 1.5 +40 -31; commitid: 1551046e88e867ea6; xorp/fea/data_plane/control_socket/netlink_socket_utilities.cc Regards, Pavlin > I have not actually loaded the build with the patch you mentioned here, but I figured > I should at least get some sort of default route even if it is at too-high > priority... > > 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 hantongs at gmail.com Thu Sep 13 02:38:31 2007 From: hantongs at gmail.com (Hansi) Date: Thu, 13 Sep 2007 17:38:31 +0800 Subject: [Xorp-users] Questions on OSPF Message-ID: <2f9e317b0709130238v5bce4d5an9d5f9560e7f288f@mail.gmail.com> Hello All, I'm currently learning how to configure OSPFv2 on two XORP machines just to establish adjacency with one another. In a p2p link type, is it still necessary to explicitly set the 'neighbor' parameter of each machine before adjacency is established? Furthermore, would it be possible to set the router-id to its loopback address? instead of say.. the ip address of the interface on which ospf will be used? This is the layout of my network w/c is relatively very simple: -------------- eth0 vr0 -------------- | xorp1 |-------------------| xorp2 | -------------- -------------- eth0: 200.10.0.1 vr0: 200.10.0.2 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070913/42938905/attachment.html From kristian at spritelink.net Thu Sep 13 06:45:12 2007 From: kristian at spritelink.net (Kristian Larsson) Date: Thu, 13 Sep 2007 15:45:12 +0200 Subject: [Xorp-users] Questions on OSPF In-Reply-To: <2f9e317b0709130238v5bce4d5an9d5f9560e7f288f@mail.gmail.com> References: <2f9e317b0709130238v5bce4d5an9d5f9560e7f288f@mail.gmail.com> Message-ID: <46E93EE8.7@spritelink.net> Hansi wrote: > Hello All, > > I'm currently learning how to configure OSPFv2 on two XORP machines just > to establish adjacency with one another. In a p2p link type, is it still > necessary to explicitly set the 'neighbor' parameter of each machine > before adjacency is established? Furthermore, would it be possible to > set the router-id to its loopback address? instead of say.. the ip > address of the interface on which ospf will be used? The neighbor command is only useful if you are using a medium on which the routers cannot broadcast and thus cannot discover each other. If you're using ethernet (which I presume from your NIC names) you do not have to use the neighbor statements. I would advice configuring the interfaces as link-type p2p as this avoids DR election and unnecessary CPU load. Yes, you can use your loopback as router-id, it's actually the prefered way of configuring things. Kristian. From greearb at candelatech.com Thu Sep 13 11:43:19 2007 From: greearb at candelatech.com (Ben Greear) Date: Thu, 13 Sep 2007 11:43:19 -0700 Subject: [Xorp-users] Unreachable default route. In-Reply-To: <200709130116.l8D1Godo026763@possum.icir.org> References: <200709130116.l8D1Godo026763@possum.icir.org> Message-ID: <46E984C7.8080103@candelatech.com> Pavlin Radoslavov wrote: > You could use the following configuration on Linux to configure a > discard interface and a static route that is blackhole: > > interfaces { > interface my_discard { > discard: true > vif my_discard { > } > } > } [snip] Ok, this does indeed create a blackhole route. But, it seems this will just silently eat packets. What I really want is unreachable, which will return the proper ICMP packet saying the destination is unreachable. Any idea how hard it would be to add this functionality? In the meantime, I'll work on a patch that makes the 'static' priority configurable with an environment variable. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From atanu at ICSI.Berkeley.EDU Thu Sep 13 11:51:32 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Thu, 13 Sep 2007 11:51:32 -0700 Subject: [Xorp-users] Questions on OSPF In-Reply-To: Message from Kristian Larsson of "Thu, 13 Sep 2007 15:45:12 +0200." <46E93EE8.7@spritelink.net> Message-ID: <99480.1189709492@tigger.icir.org> >>>>> "Kristian" == Kristian Larsson writes: Kristian> Hansi wrote: >> Hello All, >> >> I'm currently learning how to configure OSPFv2 on two XORP >> machines just to establish adjacency with one another. In a p2p >> link type, is it still necessary to explicitly set the 'neighbor' >> parameter of each machine before adjacency is established? >> Furthermore, would it be possible to set the router-id to its >> loopback address? instead of say.. the ip address of the >> interface on which ospf will be used? Kristian> The neighbor command is only useful if you are using a Kristian> medium on which the routers cannot broadcast and thus Kristian> cannot discover each other. If you're using ethernet Kristian> (which I presume from your NIC names) you do not have to Kristian> use the neighbor statements. I would advice configuring Kristian> the interfaces as link-type p2p as this avoids DR election Kristian> and unnecessary CPU load. I am fairly sure that it is necessary to use the neighbour statements. Kristian> Yes, you can use your loopback as router-id, it's actually Kristian> the prefered way of configuring things. The requirement is that the router-id is unique for each router so any value can be used. By convention either the loopback address or the lowest IP address of all the interfaces is used, hence reducing the chance of collision. Kristian> Kristian. Atanu. From kristian at spritelink.net Thu Sep 13 11:52:03 2007 From: kristian at spritelink.net (kristian at spritelink.net) Date: Thu, 13 Sep 2007 20:52:03 +0200 Subject: [Xorp-users] Questions on OSPF In-Reply-To: <99480.1189709492@tigger.icir.org> References: <99480.1189709492@tigger.icir.org> Message-ID: <4cfe4c3ba67b049473b1d94a88052842@Mail.SpriteLink.NET> On Thu, 13 Sep 2007 11:51:32 -0700, Atanu Ghosh wrote: >>>>>> "Kristian" == Kristian Larsson writes: > > Kristian> Hansi wrote: > >> Hello All, > >> > >> I'm currently learning how to configure OSPFv2 on two XORP > >> machines just to establish adjacency with one another. In a p2p > >> link type, is it still necessary to explicitly set the 'neighbor' > >> parameter of each machine before adjacency is established? > >> Furthermore, would it be possible to set the router-id to its > >> loopback address? instead of say.. the ip address of the > >> interface on which ospf will be used? > > Kristian> The neighbor command is only useful if you are using a > Kristian> medium on which the routers cannot broadcast and thus > Kristian> cannot discover each other. If you're using ethernet > Kristian> (which I presume from your NIC names) you do not have to > Kristian> use the neighbor statements. I would advice configuring > Kristian> the interfaces as link-type p2p as this avoids DR election > Kristian> and unnecessary CPU load. > > I am fairly sure that it is necessary to use the neighbour statements. Are you serious? I haven't used the XORP code in quite some time now.. but at least I thought XORP implemented the OSPF standard. AFAIK, that includes being able to discover neighbors and turn up adjacencies to them. Is this not the case? Observe that he is running an Ethernet point-to-point link, ie, it is not a non-broadcast medium. Or are you saying that you can't do link-type p2p without configuring neighbours ? -K From atanu at ICSI.Berkeley.EDU Thu Sep 13 12:18:42 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Thu, 13 Sep 2007 12:18:42 -0700 Subject: [Xorp-users] Questions on OSPF In-Reply-To: Message from of "Thu, 13 Sep 2007 20:52:03 +0200." <4cfe4c3ba67b049473b1d94a88052842@Mail.SpriteLink.NET> Message-ID: <6353.1189711122@tigger.icir.org> >>>>> "kristian" == kristian writes: kristian> On Thu, 13 Sep 2007 11:51:32 -0700, Atanu Ghosh kristian> wrote: >>>>>>> "Kristian" == Kristian Larsson >>>>>>> writes: >> Kristian> Hansi wrote: >> >> Hello All, >> >> >> >> I'm currently learning how to configure OSPFv2 on two XORP >> >> machines just to establish adjacency with one another. In a p2p >> >> link type, is it still necessary to explicitly set the >> 'neighbor' >> parameter of each machine before adjacency is >> established? >> Furthermore, would it be possible to set the >> router-id to its >> loopback address? instead of say.. the ip >> address of the >> interface on which ospf will be used? >> Kristian> The neighbor command is only useful if you are using a Kristian> medium on which the routers cannot broadcast and thus Kristian> cannot discover each other. If you're using ethernet Kristian> (which I presume from your NIC names) you do not have to Kristian> use the neighbor statements. I would advice configuring Kristian> the interfaces as link-type p2p as this avoids DR election Kristian> and unnecessary CPU load. >> I am fairly sure that it is necessary to use the neighbour >> statements. kristian> Are you serious? I haven't used the XORP code in quite kristian> some time now.. but at least I thought XORP implemented kristian> the OSPF standard. AFAIK, that includes being able to kristian> discover neighbors and turn up adjacencies to them. Is kristian> this not the case? Observe that he is running an Ethernet kristian> point-to-point link, ie, it is not a non-broadcast medium. kristian> Or are you saying that you can't do link-type p2p without kristian> configuring neighbours ? If the link-type is set to "broadcast" then the neighbours will be correctly discovered. If the link-type is set to "p2p" (Point-to-point) or "p2m" (Point-to-multipoint) then it is necessary to configure the neighbours. It has been argued that it should not be necessary to configure the neighbours if the routers are connected via a true Point-to-point link, but unfortunately even in this case it is necessary to configure the neighbour. Atanu. From kristian at spritelink.net Thu Sep 13 12:31:49 2007 From: kristian at spritelink.net (kristian at spritelink.net) Date: Thu, 13 Sep 2007 21:31:49 +0200 Subject: [Xorp-users] Questions on OSPF In-Reply-To: <6353.1189711122@tigger.icir.org> References: <6353.1189711122@tigger.icir.org> Message-ID: <93a9e57afbb58e1bf4d6d68740135f89@Mail.SpriteLink.NET> On Thu, 13 Sep 2007 12:18:42 -0700, Atanu Ghosh wrote: >>>>>> "kristian" == kristian writes: > > kristian> On Thu, 13 Sep 2007 11:51:32 -0700, Atanu Ghosh > kristian> wrote: > >>>>>>> "Kristian" == Kristian Larsson > >>>>>>> writes: > >> > Kristian> Hansi wrote: > >> >> Hello All, > >> >> > >> >> I'm currently learning how to configure OSPFv2 on two XORP >> > >> machines just to establish adjacency with one another. In a p2p > >> >> link type, is it still necessary to explicitly set the > >> 'neighbor' >> parameter of each machine before adjacency is > >> established? >> Furthermore, would it be possible to set the > >> router-id to its >> loopback address? instead of say.. the ip > >> address of the >> interface on which ospf will be used? > >> > Kristian> The neighbor command is only useful if you are using a > Kristian> medium on which the routers cannot broadcast and thus > Kristian> cannot discover each other. If you're using ethernet > Kristian> (which I presume from your NIC names) you do not have to > Kristian> use the neighbor statements. I would advice configuring > Kristian> the interfaces as link-type p2p as this avoids DR election > Kristian> and unnecessary CPU load. > > >> I am fairly sure that it is necessary to use the neighbour > >> statements. > > kristian> Are you serious? I haven't used the XORP code in quite > kristian> some time now.. but at least I thought XORP implemented > kristian> the OSPF standard. AFAIK, that includes being able to > kristian> discover neighbors and turn up adjacencies to them. Is > kristian> this not the case? Observe that he is running an Ethernet > kristian> point-to-point link, ie, it is not a non-broadcast medium. > kristian> Or are you saying that you can't do link-type p2p without > kristian> configuring neighbours ? > > If the link-type is set to "broadcast" then the neighbours will be > correctly discovered. If the link-type is set to "p2p" (Point-to-point) > or "p2m" (Point-to-multipoint) then it is necessary to configure the > neighbours. It has been argued that it should not be necessary to > configure the neighbours if the routers are connected via a true > Point-to-point link, but unfortunately even in this case it is necessary > to configure the neighbour. Okey, that "kinda" makes sense. I apparently forgot or missed the conversation on this. What I want to configure with link-type p2p is not whether or not the router should try to broadcast but if it should setup one of those virtual router thingys, hehe. I'm not very familiar with the terminology but (as you know) on a broadcast medium you first have a DR selection and all that and then you're gonna run your SPF. Since SPF can't handle the concept of a broadcast medium it creates a "virtual router" to represent the broadcast medium and connects all routers in that broadcast domain as adjacencies to the virtual router. When I configure 'isis network point-to-point' on a Cisco router I expect it to not setup one of these "virtual routers" in it's SPF topology. And this is different with XORP? Perhaps the increase in simplicity to the SPF topology that 'isis network point-to-point' brings is so small that it's negligable. I think SPF runs take in the order of 10ms or so for a network with a couple of hundred routers on a normal routing engine these days. -K From atanu at ICSI.Berkeley.EDU Thu Sep 13 14:58:01 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Thu, 13 Sep 2007 14:58:01 -0700 Subject: [Xorp-users] Questions on OSPF In-Reply-To: Message from of "Thu, 13 Sep 2007 21:31:49 +0200." <93a9e57afbb58e1bf4d6d68740135f89@Mail.SpriteLink.NET> Message-ID: <44891.1189720681@tigger.icir.org> >>>>> "kristian" == kristian writes: kristian> On Thu, 13 Sep 2007 12:18:42 -0700, Atanu Ghosh kristian> wrote: >>>>>>> "kristian" == kristian writes: >> kristian> On Thu, 13 Sep 2007 11:51:32 -0700, Atanu Ghosh kristian> wrote: >> >>>>>>> "Kristian" == Kristian Larsson >> >>>>>>> writes: >> >> Kristian> Hansi wrote: >> >> >> Hello All, >> >> >> >> >> >> I'm currently learning how to configure OSPFv2 on two XORP >> >> >> machines just to establish adjacency with one another. In a >> p2p >> >> link type, is it still necessary to explicitly set the >> >> 'neighbor' >> parameter of each machine before adjacency is >> >> established? >> Furthermore, would it be possible to set the >> >> router-id to its >> loopback address? instead of say.. the ip >> >> address of the >> interface on which ospf will be used? >> >> Kristian> The neighbor command is only useful if you are using a Kristian> medium on which the routers cannot broadcast and thus Kristian> cannot discover each other. If you're using ethernet Kristian> (which I presume from your NIC names) you do not have to Kristian> use the neighbor statements. I would advice configuring Kristian> the interfaces as link-type p2p as this avoids DR election Kristian> and unnecessary CPU load. >> >> I am fairly sure that it is necessary to use the neighbour >> >> statements. >> kristian> Are you serious? I haven't used the XORP code in quite kristian> some time now.. but at least I thought XORP implemented kristian> the OSPF standard. AFAIK, that includes being able to kristian> discover neighbors and turn up adjacencies to them. Is kristian> this not the case? Observe that he is running an Ethernet kristian> point-to-point link, ie, it is not a non-broadcast medium. kristian> Or are you saying that you can't do link-type p2p without kristian> configuring neighbours ? >> If the link-type is set to "broadcast" then the neighbours will >> be correctly discovered. If the link-type is set to "p2p" >> (Point-to-point) or "p2m" (Point-to-multipoint) then it is >> necessary to configure the neighbours. It has been argued that it >> should not be necessary to configure the neighbours if the >> routers are connected via a true Point-to-point link, but >> unfortunately even in this case it is necessary to configure the >> neighbour. kristian> Okey, that "kinda" makes sense. I apparently forgot or kristian> missed the conversation on this. What I want to configure kristian> with link-type p2p is not whether or not the router should kristian> try to broadcast but if it should setup one of those kristian> virtual router thingys, hehe. I'm not very familiar with kristian> the terminology but (as you know) on a broadcast medium kristian> you first have a DR selection and all that and then you're kristian> gonna run your SPF. Since SPF can't handle the concept of kristian> a broadcast medium it creates a "virtual router" to kristian> represent the broadcast medium and connects all routers in kristian> that broadcast domain as adjacencies to the virtual kristian> router. When I configure 'isis network point-to-point' on kristian> a Cisco router I expect it to not setup one of these kristian> "virtual routers" in it's SPF topology. And this is kristian> different with XORP? Setting the link type to "broadcast" or "p2p" will both result in the hello packets being broadcast, the distinction is that if the link-type is set to "p2p" no DR election will be attempted. The XORP OSPF behaves as specified in the relevant RFCs and interoperates with other OSPF implementations, the only difference is in configuration of a "p2p" where we require the neighbour to be specified, which as I mentioned before should not strictly be necessary. Atanu. From kristian at spritelink.net Thu Sep 13 14:51:06 2007 From: kristian at spritelink.net (kristian at spritelink.net) Date: Thu, 13 Sep 2007 23:51:06 +0200 Subject: [Xorp-users] Questions on OSPF In-Reply-To: <44891.1189720681@tigger.icir.org> References: <44891.1189720681@tigger.icir.org> Message-ID: <5f7ec0f76565b4e68ed2457fdf8df3b8@Mail.SpriteLink.NET> On Thu, 13 Sep 2007 14:58:01 -0700, Atanu Ghosh wrote: >>>>>> "kristian" == kristian writes: > > kristian> On Thu, 13 Sep 2007 12:18:42 -0700, Atanu Ghosh > kristian> wrote: > >>>>>>> "kristian" == kristian writes: > >> > kristian> On Thu, 13 Sep 2007 11:51:32 -0700, Atanu Ghosh > kristian> wrote: > >> >>>>>>> "Kristian" == Kristian Larsson > >> >>>>>>> writes: > >> >> > Kristian> Hansi wrote: > >> >> >> Hello All, > >> >> >> > >> >> >> I'm currently learning how to configure OSPFv2 on two XORP > >> >> >> machines just to establish adjacency with one another. In a > >> p2p >> >> link type, is it still necessary to explicitly set the > >> >> 'neighbor' >> parameter of each machine before adjacency is >> > >> established? >> Furthermore, would it be possible to set the >> > >> router-id to its >> loopback address? instead of say.. the ip >> > >> address of the >> interface on which ospf will be used? > >> >> > Kristian> The neighbor command is only useful if you are using a > Kristian> medium on which the routers cannot broadcast and thus > Kristian> cannot discover each other. If you're using ethernet > Kristian> (which I presume from your NIC names) you do not have to > Kristian> use the neighbor statements. I would advice configuring > Kristian> the interfaces as link-type p2p as this avoids DR election > Kristian> and unnecessary CPU load. > >> >> I am fairly sure that it is necessary to use the neighbour >> > >> statements. > >> > kristian> Are you serious? I haven't used the XORP code in quite > kristian> some time now.. but at least I thought XORP implemented > kristian> the OSPF standard. AFAIK, that includes being able to > kristian> discover neighbors and turn up adjacencies to them. Is > kristian> this not the case? Observe that he is running an Ethernet > kristian> point-to-point link, ie, it is not a non-broadcast medium. > kristian> Or are you saying that you can't do link-type p2p without > kristian> configuring neighbours ? > > >> If the link-type is set to "broadcast" then the neighbours will > >> be correctly discovered. If the link-type is set to "p2p" > >> (Point-to-point) or "p2m" (Point-to-multipoint) then it is > >> necessary to configure the neighbours. It has been argued that it > >> should not be necessary to configure the neighbours if the > >> routers are connected via a true Point-to-point link, but > >> unfortunately even in this case it is necessary to configure the > >> neighbour. > > kristian> Okey, that "kinda" makes sense. I apparently forgot or > kristian> missed the conversation on this. What I want to configure > kristian> with link-type p2p is not whether or not the router should > kristian> try to broadcast but if it should setup one of those > kristian> virtual router thingys, hehe. I'm not very familiar with > kristian> the terminology but (as you know) on a broadcast medium > kristian> you first have a DR selection and all that and then you're > kristian> gonna run your SPF. Since SPF can't handle the concept of > kristian> a broadcast medium it creates a "virtual router" to > kristian> represent the broadcast medium and connects all routers in > kristian> that broadcast domain as adjacencies to the virtual > kristian> router. When I configure 'isis network point-to-point' on > kristian> a Cisco router I expect it to not setup one of these > kristian> "virtual routers" in it's SPF topology. And this is > kristian> different with XORP? > > Setting the link type to "broadcast" or "p2p" will both result in the > hello packets being broadcast, the distinction is that if the link-type > is set to "p2p" no DR election will be attempted. Alright, just as I expected. > The XORP OSPF behaves > as specified in the relevant RFCs and interoperates with other OSPF > implementations, the only difference is in configuration of a "p2p" > where we require the neighbour to be specified, which as I mentioned > before should not strictly be necessary. Okey, not what I expected. Why is it so? Just lack of time to do the actual implementation (although I don't see how it would actually be more code than it is today) or has there been a policy decision against it? -K From pavlin at icir.org Thu Sep 13 16:11:57 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 13 Sep 2007 16:11:57 -0700 Subject: [Xorp-users] Unreachable default route. In-Reply-To: Message from Ben Greear of "Thu, 13 Sep 2007 11:43:19 PDT." <46E984C7.8080103@candelatech.com> Message-ID: <200709132312.l8DNBvsa040733@possum.icir.org> Ben Greear wrote: > Pavlin Radoslavov wrote: > > > You could use the following configuration on Linux to configure a > > discard interface and a static route that is blackhole: > > > > interfaces { > > interface my_discard { > > discard: true > > vif my_discard { > > } > > } > > } > > [snip] > > Ok, this does indeed create a blackhole route. But, it seems this will just > silently eat packets. What I really want is unreachable, which will return ~~~~~~~~~~~~~~~~~~~~ Correct. This is the definition of "blackhole" :) > the proper ICMP packet saying the destination is unreachable. > > Any idea how hard it would be to add this functionality? You need to install a different type of route in the kernel which I believe in Linux is RTN_UNREACHABLE instead of RTN_BLACKHOLE. However, XORP doesn't support such routes. You could try experimenting with such routes by replacing all references (I counted two references) of RTN_BLACKHOLE with RTN_UNREACHABLE inside file fea/data_plane/fibconfig/fibconfig_entry_set_netlink_socket.cc This is not the right solution, but allows you to play with such routes. Just curious, could you describe your particular scenario you have that requires installing RTN_UNREACHABLE routes. > In the meantime, I'll work on a patch that makes the 'static' priority > configurable with an environment variable. I should tell you upfront that configurable admin distances in RIB has been on our TODO list for quite some time. However it is not trivial if we want to do it properly by taking into account various considerations. E.g., one of the goals is to be able to configure the priorities (on the fly) inside the XORP config file. Hence, most likely we won't use a solution that is based on setting an environmental variable (or something like this). In other words, don't be offended if your patch is not applied to the CVS. Though, if I were in your position I would use such shortcut in my local XORP copy. 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 greearb at candelatech.com Thu Sep 13 16:32:01 2007 From: greearb at candelatech.com (Ben Greear) Date: Thu, 13 Sep 2007 16:32:01 -0700 Subject: [Xorp-users] Unreachable default route. In-Reply-To: <200709132312.l8DNBvsa040733@possum.icir.org> References: <200709132312.l8DNBvsa040733@possum.icir.org> Message-ID: <46E9C871.5040807@candelatech.com> Pavlin Radoslavov wrote: > You need to install a different type of route in the kernel which I > believe in Linux is RTN_UNREACHABLE instead of RTN_BLACKHOLE. > However, XORP doesn't support such routes. > You could try experimenting with such routes by replacing all > references (I counted two references) of RTN_BLACKHOLE with > RTN_UNREACHABLE inside file > fea/data_plane/fibconfig/fibconfig_entry_set_netlink_socket.cc > > This is not the right solution, but allows you to play with such > routes. Yeah, I figured I could do this..but I am also interested in learning how to do it the right way: new option for Interface: unreachable: true And propagate that through like you do the "discard: true" option currently. Is this a major task, or just a few hours of work? I'm willing to attempt it assuming it's not horribly complex or requires all new infrastructure. > Just curious, could you describe your particular scenario you have > that requires installing RTN_UNREACHABLE routes. Suppose I have a virtual router with subnets A, B, C hanging off of it and no default gateway. When I ping through this VR to subnet D, I would like to get an ICMP message that says something like 'no route to host', not just no response (which can take a while to realize). The reason I need a bogus default route (unreachable and/or blackhole) is that it appears Linux will try other routing tables if there is no matching route in the table you specify. This basically breaks VRs if you don't have a catch-all default route entry because it will try the local routing table and may immediately find a destination (that does not go through the virtual routes & links.) >> In the meantime, I'll work on a patch that makes the 'static' priority >> configurable with an environment variable. > > I should tell you upfront that configurable admin distances in RIB > has been on our TODO list for quite some time. However it is not > trivial if we want to do it properly by taking into account various > considerations. > E.g., one of the goals is to be able to configure the priorities (on > the fly) inside the XORP config file. > > Hence, most likely we won't use a solution that is based on > setting an environmental variable (or something like this). > In other words, don't be offended if your patch is not applied to > the CVS. > Though, if I were in your position I would use such shortcut in my > local XORP copy. I agree. It would be much nicer to be able to specify it in the config file on a per-route basis. But, this will probably work for me. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Thu Sep 13 17:01:27 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 13 Sep 2007 17:01:27 -0700 Subject: [Xorp-users] Unreachable default route. In-Reply-To: Message from Ben Greear of "Thu, 13 Sep 2007 16:32:01 PDT." <46E9C871.5040807@candelatech.com> Message-ID: <200709140001.l8E01R5E041251@possum.icir.org> > > You need to install a different type of route in the kernel which I > > believe in Linux is RTN_UNREACHABLE instead of RTN_BLACKHOLE. > > However, XORP doesn't support such routes. > > You could try experimenting with such routes by replacing all > > references (I counted two references) of RTN_BLACKHOLE with > > RTN_UNREACHABLE inside file > > fea/data_plane/fibconfig/fibconfig_entry_set_netlink_socket.cc > > > > This is not the right solution, but allows you to play with such > > routes. > > Yeah, I figured I could do this..but I am also interested in learning > how to do it the right way: > > new option for Interface: > unreachable: true > > And propagate that through like you do the "discard: true" option currently. > > Is this a major task, or just a few hours of work? > > I'm willing to attempt it assuming it's not horribly complex or requires all new infrastructure. It could be relatively complex and it could easily take at least a day or two for someone who is not familiar with all the internals. To implement it, you need to follow the "discard" interface mechanism: * Start with interfaces.tp and add the new flag and the new XRL. * Add the new XRL to xrl/interfaces/fea_ifmgr.xif * Add the processing front-end to the FEA * Add the processing back-end to the FEA * Add the new flag to the generic fea/iftree.hh * Update libfeaclient to support and carry the new flag * Add the appropriate hooks to the fibconfig backend to set/install the RTN_UNREACHABLE routes. Note that I am skipping a number of important details. Usually, when I add something like this that goes in parallel with something similar that already exists, I always do deep search (case insensitive) for the appropriate keyword. In this case it will be "discard". Said that, the simplest thing for you would be to add a bugzilla entry for this new feature and I will try to implement it when time allows me. Sorry, right now I am occupied with the VLAN task and I need to finish it without sidetracks. > > Just curious, could you describe your particular scenario you have > > that requires installing RTN_UNREACHABLE routes. > > Suppose I have a virtual router with subnets A, B, C hanging off of it and no default gateway. > When I ping through this VR to subnet D, I would like to > get an ICMP message that says something like 'no route to host', not > just no response (which can take a while to realize). > > The reason I need a bogus default route (unreachable and/or blackhole) is that > it appears Linux will try other routing tables if there is no matching route > in the table you specify. This basically breaks VRs if you don't have a > catch-all default route entry because it will try the local routing table and > may immediately find a destination (that does not go through the virtual > routes & links.) I see. Though, if I remember correctly, I believe you could apply some policies to the multiple route tables to get around this issue. In the worst case, if it is really important you could always install that "unreachable" default route by hand before starting the virtual XORP instances. Not very elegant solution, but should get you going :) Regards, Pavlin From greearb at candelatech.com Thu Sep 13 21:29:10 2007 From: greearb at candelatech.com (Ben Greear) Date: Thu, 13 Sep 2007 21:29:10 -0700 Subject: [Xorp-users] How to configure simple static subnet route? Message-ID: <46EA0E16.9020800@candelatech.com> I'm feeling quite lame, but I cannot figure out how to get Xorp to configure regular old subnet routes on it's interfaces. I've been trying things like: static { interface-route 0.0.0.0/0 { next-hop-interface: "my_discard" next-hop-vif: "my_discard" } route 10.0.0.0/24 { next-hop: 10.0.0.2 } route 10.2.0.0/24 { next-hop: 10.2.0.1 } But, only the discard default route shows up! All of the examples I can find in the user-guide seem to be wierd non-subnet routes...surely Xorp can do this? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Thu Sep 13 22:04:52 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 13 Sep 2007 22:04:52 -0700 Subject: [Xorp-users] How to configure simple static subnet route? In-Reply-To: Message from Ben Greear of "Thu, 13 Sep 2007 21:29:10 PDT." <46EA0E16.9020800@candelatech.com> Message-ID: <200709140504.l8E54qh5069452@possum.icir.org> Ben Greear wrote: > I'm feeling quite lame, but I cannot figure out how to get Xorp to > configure regular old subnet routes on it's interfaces. I've been > trying things like: > > static { > interface-route 0.0.0.0/0 { > next-hop-interface: "my_discard" > next-hop-vif: "my_discard" > } > route 10.0.0.0/24 { > next-hop: 10.0.0.2 > } > > route 10.2.0.0/24 { > next-hop: 10.2.0.1 > } > > But, only the discard default route shows up! > > All of the examples I can find in the user-guide seem to be wierd non-subnet > routes...surely Xorp can do this? Make sure that the next-hop IP address is directly connected to an XORP-configured interface. In your second and third example the next-hop address belongs to the subnet route itself which is a bit odd. In any case the "show route ipv4 unicast static" xorpsh command will tell you whether any static route has been sent to the RIB. 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 greearb at candelatech.com Thu Sep 13 22:08:06 2007 From: greearb at candelatech.com (Ben Greear) Date: Thu, 13 Sep 2007 22:08:06 -0700 Subject: [Xorp-users] How to configure simple static subnet route? In-Reply-To: <200709140504.l8E54qh5069452@possum.icir.org> References: <200709140504.l8E54qh5069452@possum.icir.org> Message-ID: <46EA1736.7000304@candelatech.com> Pavlin Radoslavov wrote: > Ben Greear wrote: > > >> I'm feeling quite lame, but I cannot figure out how to get Xorp to >> configure regular old subnet routes on it's interfaces. I've been >> trying things like: >> >> static { >> interface-route 0.0.0.0/0 { >> next-hop-interface: "my_discard" >> next-hop-vif: "my_discard" >> } >> route 10.0.0.0/24 { >> next-hop: 10.0.0.2 >> } >> >> route 10.2.0.0/24 { >> next-hop: 10.2.0.1 >> } >> >> But, only the discard default route shows up! >> >> All of the examples I can find in the user-guide seem to be wierd non-subnet >> routes...surely Xorp can do this? >> > > Make sure that the next-hop IP address is directly connected to an > XORP-configured interface. > In your second and third example the next-hop address belongs to the > subnet route itself which is a bit odd. > > In any case the "show route ipv4 unicast static" xorpsh command will > tell you whether any static route has been sent to the RIB. > There isn't even a next-hop for a local subnet address...I just want something like: 172.99.2.0/24 dev rddVR17 scope link unreachable default (Nevermind the unreachable for now...that's a separate issue.) Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Thu Sep 13 22:21:09 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 13 Sep 2007 22:21:09 -0700 Subject: [Xorp-users] How to configure simple static subnet route? In-Reply-To: Message from Ben Greear of "Thu, 13 Sep 2007 22:08:06 PDT." <46EA1736.7000304@candelatech.com> Message-ID: <200709140521.l8E5L98u069613@possum.icir.org> Ben Greear wrote: > Pavlin Radoslavov wrote: > > Ben Greear wrote: > > > > > >> I'm feeling quite lame, but I cannot figure out how to get Xorp to > >> configure regular old subnet routes on it's interfaces. I've been > >> trying things like: > >> > >> static { > >> interface-route 0.0.0.0/0 { > >> next-hop-interface: "my_discard" > >> next-hop-vif: "my_discard" > >> } > >> route 10.0.0.0/24 { > >> next-hop: 10.0.0.2 > >> } > >> > >> route 10.2.0.0/24 { > >> next-hop: 10.2.0.1 > >> } > >> > >> But, only the discard default route shows up! > >> > >> All of the examples I can find in the user-guide seem to be wierd non-subnet > >> routes...surely Xorp can do this? > >> > > > > Make sure that the next-hop IP address is directly connected to an > > XORP-configured interface. > > In your second and third example the next-hop address belongs to the > > subnet route itself which is a bit odd. > > > > In any case the "show route ipv4 unicast static" xorpsh command will > > tell you whether any static route has been sent to the RIB. > > > There isn't even a next-hop for a local subnet address...I just want > something like: > > 172.99.2.0/24 dev rddVR17 scope link > unreachable default > > (Nevermind the unreachable for now...that's a separate issue.) So, are 10.0.0.0/24 and 10.2.0.0/24 the subnet addresses? In that case even if the routes are sent to the RIB, they will lose to the directly connected routes (introduced internally by RIB). Hence, please clarify whether those two addresses are indeed the subnet addresses and whether you see them with the "show route ipv4 unicast static" command. 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 kristian at spritelink.net Fri Sep 14 03:29:45 2007 From: kristian at spritelink.net (Kristian Larsson) Date: Fri, 14 Sep 2007 12:29:45 +0200 Subject: [Xorp-users] Questions on OSPF In-Reply-To: <2f9e317b0709140216xff0abd5q62de11cce4fe9c47@mail.gmail.com> References: <44891.1189720681@tigger.icir.org> <5f7ec0f76565b4e68ed2457fdf8df3b8@Mail.SpriteLink.NET> <2f9e317b0709140216xff0abd5q62de11cce4fe9c47@mail.gmail.com> Message-ID: <46EA6299.4090607@spritelink.net> Hansi wrote: > Hello Kristian, Atanu, > > Thank you answering for my queries. Let me see if I understood it clearly. > > For link-types: p2p or p2m, it is necessary to explicitly set the > neighbor parameter in order for the router running OSPF to establish > adjacency with another router. Broadcast link-types on the other hand > does not require the neighbor parameter to be explicitly set, am I > correct? :) > > I concur with Atanu that p2p link-types requires the neighbor statement > to be explicitly stated. My initial configuration does not include > setting the neighbor parameter, upon invoking "show ospf4 neighbor", > nothing comes up even though dumps from the network shows OSPF hello > packets have been multicast already.. The neighbor router only displays > [upon invoking show ospf4 neighbor] after setting the neighbor parameter > on both routers. Yepp, I was simply wrong. I expected XORP to work like Cisco or Juniper. > Regarding setting router-ID parameters to loopback 127.0.0.1 > , would it be possible for two routers running OSPF to > use the same router-ID? that is both of them are configured to 127.0.0.1 > ? Since conventionally the router-ID is usually set to > the loopback, would it be possible to configure all routers in an OSPF > network to have the same router-ID of 127.0.0.1 ? No, you cannot use 127.0.0.1, at least not on both routers. Router-id have to be unique within your OSPF domain, one common way of ensuring this is to use the loopback address that you assign to a router. Although you are correct that 127.0.0.1 is a loopback adress, routes normally get one assigned from your address pool. iBGP session for example are normally established between loopback addresses to not be dependant upon a specific interface being up. So assign 172.16.0.1-254 (if your are using private addressing) or something to your loopbacks as well and you can use those. -K > On 9/14/07, *kristian at spritelink.net * < > kristian at spritelink.net > wrote: > > On Thu, 13 Sep 2007 14:58:01 -0700, Atanu Ghosh < > atanu at icsi.berkeley.edu > > wrote: > >>>>>> "kristian" == kristian > writes: > > > > kristian> On Thu, 13 Sep 2007 12:18:42 -0700, Atanu Ghosh > > kristian> > wrote: > > >>>>>>> "kristian" == kristian < kristian at spritelink.net > > writes: > > >> > > kristian> On Thu, 13 Sep 2007 11:51:32 -0700, Atanu Ghosh > > kristian> < atanu at icsi.berkeley.edu > > wrote: > > >> >>>>>>> "Kristian" == Kristian Larsson > > > > >> >>>>>>> writes: > > >> >> > > Kristian> Hansi wrote: > > >> >> >> Hello All, > > >> >> >> > > >> >> >> I'm currently learning how to configure OSPFv2 on > two XORP > > >> >> >> machines just to establish adjacency with one > another. In a > > >> p2p >> >> link type, is it still necessary to explicitly > set the > > >> >> 'neighbor' >> parameter of each machine before > adjacency is >> > > >> established? >> Furthermore, would it be possible to set > the >> > > >> router-id to its >> loopback address? instead of say.. the > ip >> > > >> address of the >> interface on which ospf will be used? > > >> >> > > Kristian> The neighbor command is only useful if you are using a > > Kristian> medium on which the routers cannot broadcast and thus > > Kristian> cannot discover each other. If you're using ethernet > > Kristian> (which I presume from your NIC names) you do not > have to > > Kristian> use the neighbor statements. I would advice configuring > > Kristian> the interfaces as link-type p2p as this avoids DR > election > > Kristian> and unnecessary CPU load. > > >> >> I am fairly sure that it is necessary to use the > neighbour >> > > >> statements. > > >> > > kristian> Are you serious? I haven't used the XORP code in > quite > > kristian> some time now.. but at least I thought XORP implemented > > kristian> the OSPF standard. AFAIK, that includes being able to > > kristian> discover neighbors and turn up adjacencies to them. Is > > kristian> this not the case? Observe that he is running an > Ethernet > > kristian> point-to-point link, ie, it is not a non-broadcast > medium. > > kristian> Or are you saying that you can't do link-type p2p > without > > kristian> configuring neighbours ? > > > > >> If the link-type is set to "broadcast" then the > neighbours will > > >> be correctly discovered. If the link-type is set to "p2p" > > >> (Point-to-point) or "p2m" (Point-to-multipoint) then it is > > >> necessary to configure the neighbours. It has been argued > that it > > >> should not be necessary to configure the neighbours if the > > >> routers are connected via a true Point-to-point link, but > > >> unfortunately even in this case it is necessary to > configure the > > >> neighbour. > > > > kristian> Okey, that "kinda" makes sense. I apparently forgot or > > kristian> missed the conversation on this. What I want to > configure > > kristian> with link-type p2p is not whether or not the router > should > > kristian> try to broadcast but if it should setup one of those > > kristian> virtual router thingys, hehe. I'm not very familiar > with > > kristian> the terminology but (as you know) on a broadcast medium > > kristian> you first have a DR selection and all that and then > you're > > kristian> gonna run your SPF. Since SPF can't handle the > concept of > > kristian> a broadcast medium it creates a "virtual router" to > > kristian> represent the broadcast medium and connects all > routers in > > kristian> that broadcast domain as adjacencies to the virtual > > kristian> router. When I configure 'isis network > point-to-point' on > > kristian> a Cisco router I expect it to not setup one of these > > kristian> "virtual routers" in it's SPF topology. And this is > > kristian> different with XORP? > > > > Setting the link type to "broadcast" or "p2p" will both result in > the > > hello packets being broadcast, the distinction is that if the > link-type > > is set to "p2p" no DR election will be attempted. > > Alright, just as I expected. > > > The XORP OSPF behaves > > as specified in the relevant RFCs and interoperates with other OSPF > > implementations, the only difference is in configuration of a "p2p" > > where we require the neighbour to be specified, which as I mentioned > > before should not strictly be necessary. > > Okey, not what I expected. Why is it so? Just lack of time to do the > actual > implementation (although I don't see how it would actually be more code > than it is today) or has there been a policy decision against it? > > -K > > From joshihirenn at gmail.com Fri Sep 14 22:08:50 2007 From: joshihirenn at gmail.com (hiren joshi) Date: Sat, 15 Sep 2007 10:38:50 +0530 Subject: [Xorp-users] can i use zebra/quagga and XORP together Message-ID: <29820bf40709142208u36a9f76fu7d51a39fd694eb10@mail.gmail.com> hello all, i am already having a system running quagga. but as quagga lacks multicast routing support i need to use XORP PIM-SM part only. is it possible to run quagga together with XORP PIM-SM part? thanks in advance. regards, -hiren -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070915/dd8cc0ef/attachment.html From pavlin at icir.org Fri Sep 14 23:44:20 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 14 Sep 2007 23:44:20 -0700 Subject: [Xorp-users] can i use zebra/quagga and XORP together In-Reply-To: Message from "hiren joshi" of "Sat, 15 Sep 2007 10:38:50 +0530." <29820bf40709142208u36a9f76fu7d51a39fd694eb10@mail.gmail.com> Message-ID: <200709150644.l8F6iKK1002569@possum.icir.org> > i am already having a system running quagga. but as quagga lacks multicast > routing support i need to use XORP PIM-SM part only. > is it possible to run quagga together with XORP PIM-SM part? Yes. However, when configuring the XORP interfaces, you should use the "default-system-config" statement rather than explicitly configuring the interfaces. Though, if you change any of the Quagga interfaces configuration on the fly, XORP won't pick-up the change. This is a bug in XORP that should be fixed for the next release. Also, make sure that fib2mrib is enabled in the XORP configuration. Finally, don't enable any unicast routing in XORP, otherwise the result is unpredictable (mrib-route static routes are OK). Regards, Pavlin From a.greenhalgh at cs.ucl.ac.uk Sat Sep 15 00:54:47 2007 From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh) Date: Sat, 15 Sep 2007 08:54:47 +0100 Subject: [Xorp-users] can i use zebra/quagga and XORP together In-Reply-To: <29820bf40709142208u36a9f76fu7d51a39fd694eb10@mail.gmail.com> References: <29820bf40709142208u36a9f76fu7d51a39fd694eb10@mail.gmail.com> Message-ID: <4769af410709150054n72149dfcq90134828061bb496@mail.gmail.com> Hiren, It would be very useful to know which features in quagga you are using that aren't present in xorp at the moment. Adam On 9/15/07, hiren joshi wrote: > hello all, > > i am already having a system running quagga. but as quagga lacks multicast > routing support i need to use XORP PIM-SM part only. > is it possible to run quagga together with XORP PIM-SM part? > > thanks in advance. > > regards, > -hiren > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > From ror.sanjeev at gmail.com Mon Sep 17 04:49:00 2007 From: ror.sanjeev at gmail.com (sanjeev kumar) Date: Mon, 17 Sep 2007 17:19:00 +0530 Subject: [Xorp-users] Is it possible to configure the NAT on XORP?? Message-ID: <477942240709170449h6a3e030brd5ffbd4bab8c44b4@mail.gmail.com> Hi, Is it possible to configure NATing on XORP router.If then please suggest me some steps.. Thanks, Sanjeev -- Efforts may fail,But don't Fail to make efforts. --------- Sanjeev Kumar Project Engineer CDAC(Formerly NCST) Juhu,Mumbai-400049 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070917/809eba7e/attachment.html From Frederic.Gilloteau at alcatel.fr Mon Sep 17 03:20:32 2007 From: Frederic.Gilloteau at alcatel.fr (Frederic Gilloteau) Date: Mon, 17 Sep 2007 12:20:32 +0200 Subject: [Xorp-users] Xorp compilation with SNMP Message-ID: <002701c7f914$614b1080$025ca8c0@ad2.ad.alcatel.com> Hello, I got some errors trying to compile xorp with the snmp module: (./configure --with-snmp --enable-shared) Could you please help me ? Thanks in advance Fred -- Making install in snmpdscripts mkdir -p -- /home/fgilloteau/DEV/TIERS/xorp/TMP/xorp-1.4-0.1-root/usr/local/xorp/snmpdsc ripts /usr/bin/install -c getbgppeertable /home/fgilloteau/DEV/TIERS/xorp/TMP/xorp-1.4-0.1-root/usr/local/xorp/snmpdsc ripts/getbgppeertable /usr/bin/install -c getbgpversion /home/fgilloteau/DEV/TIERS/xorp/TMP/xorp-1.4-0.1-root/usr/local/xorp/snmpdsc ripts/getbgpversion /usr/bin/install -c startsnmp /home/fgilloteau/DEV/TIERS/xorp/TMP/xorp-1.4-0.1-root/usr/local/xorp/snmpdsc ripts/startsnmp /usr/bin/install -c stopsnmp /home/fgilloteau/DEV/TIERS/xorp/TMP/xorp-1.4-0.1-root/usr/local/xorp/snmpdsc ripts/stopsnmp Making install in tests /bin/sh ./libtool --mode=install /usr/bin/install -c libnetsnmpxorp.la /home/fgilloteau/DEV/TIERS/xorp/TMP/xorp-1.4-0.1-root/usr/local/xorp/./libne tsnmpxorp.la /usr/bin/install -c .libs/libnetsnmpxorp.so /home/fgilloteau/DEV/TIERS/xorp/TMP/xorp-1.4-0.1-root/usr/local/xorp/./libne tsnmpxorp.so /usr/bin/install -c .libs/libnetsnmpxorp.lai /home/fgilloteau/DEV/TIERS/xorp/TMP/xorp-1.4-0.1-root/usr/local/xorp/./libne tsnmpxorp.la libtool: install: warning: remember to run `libtool --finish /usr/local/xorp/mibs/.' /bin/sh ./libtool --mode=install /usr/bin/install -c bgp4_mib_1657.la /home/fgilloteau/DEV/TIERS/xorp/TMP/xorp-1.4-0.1-root/usr/local/xorp/./bgp4_ mib_1657.la libtool: install: warning: relinking `bgp4_mib_1657.la' cd /home/fgilloteau/DEV/TIERS/xorp/BUILD/xorp-1.4/mibs; /bin/sh ./libtool --mode=relink g++ -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m32 -march=i386 -mtune=pentium4 -fasynchronous-unwind-tables -DNETSNMP_NO_INLINE -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-22 -pipe -o bgp4_mib_1657.la -rpath /usr/local/xorp/mibs/. -module -avoid-version bgp4_mib_1657.lo bgp4_mib_1657_bgpversion.lo bgp4_mib_1657_bgplocalas.lo bgp4_mib_1657_bgpidentifier.lo bgp4_mib_1657_bgppeertable.lo bgp4_mib_1657_bgp4pathattrtable.lo bgp4_mib_xrl_target.lo ./libnetsnmpxorp.la ../xrl/targets/libbgp4mibbase.la ../xrl/interfaces/libbgpxif.la -lcrypto g++ -shared bgp4_mib_1657.lo bgp4_mib_1657_bgpversion.lo bgp4_mib_1657_bgplocalas.lo bgp4_mib_1657_bgpidentifier.lo bgp4_mib_1657_bgppeertable.lo bgp4_mib_1657_bgp4pathattrtable.lo bgp4_mib_xrl_target.lo -Wl,--whole-archive ../xrl/targets/.libs/libbgp4mibbase.al ../xrl/interfaces/.libs/libbgpxif.al -Wl,--no-whole-archive -L/usr/local/xorp/mibs/. -lnetsnmpxorp ../xrl/targets/.libs/libbgp4mibbase.al ../xrl/interfaces/.libs/libbgpxif.al -lcrypto -Wl,-soname -Wl,bgp4_mib_1657.so -o .libs/bgp4_mib_1657.so /usr/bin/ld: cannot find -lnetsnmpxorp collect2: ld returned 1 exit status libtool: install: error: relink `bgp4_mib_1657.la' with the above command before installing it libtool: install: warning: remember to run `libtool --finish /usr/local/xorp/mibs/.' /bin/sh ./libtool --mode=install /usr/bin/install -c ospf_mib_1850.la /home/fgilloteau/DEV/TIERS/xorp/TMP/xorp-1.4-0.1-root/usr/local/xorp/./ospf_ mib_1850.la libtool: install: warning: relinking `ospf_mib_1850.la' cd /home/fgilloteau/DEV/TIERS/xorp/BUILD/xorp-1.4/mibs; /bin/sh ./libtool --mode=relink g++ -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m32 -march=i386 -mtune=pentium4 -fasynchronous-unwind-tables -DNETSNMP_NO_INLINE -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-22 -pipe -o ospf_mib_1850.la -rpath /usr/local/xorp/mibs/. -module -avoid-version ospf_mib_1850.lo ./libnetsnmpxorp.la -lcrypto g++ -shared ospf_mib_1850.lo -L/usr/local/xorp/mibs/. -lnetsnmpxorp -lcrypto -Wl,-soname -Wl,ospf_mib_1850.so -o .libs/ospf_mib_1850.so /usr/bin/ld: cannot find -lnetsnmpxorp collect2: ld returned 1 exit status libtool: install: error: relink `ospf_mib_1850.la' with the above command before installing it libtool: install: warning: remember to run `libtool --finish /usr/local/xorp/mibs/.' /bin/sh ./libtool --mode=install /usr/bin/install -c xorp_if_mib_module.la /home/fgilloteau/DEV/TIERS/xorp/TMP/xorp-1.4-0.1-root/usr/local/xorp/./xorp_ if_mib_module.la libtool: install: warning: relinking `xorp_if_mib_module.la' cd /home/fgilloteau/DEV/TIERS/xorp/BUILD/xorp-1.4/mibs; /bin/sh ./libtool --mode=relink g++ -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m32 -march=i386 -mtune=pentium4 -fasynchronous-unwind-tables -DNETSNMP_NO_INLINE -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-22 -pipe -o xorp_if_mib_module.la -rpath /usr/local/xorp/mibs/. -module -avoid-version xorp_if_mib_module.lo xorp_if_mib_xrl_target.lo ./libnetsnmpxorp.la ../xrl/targets/libxorpifmibbase.la -lcrypto g++ -shared xorp_if_mib_module.lo xorp_if_mib_xrl_target.lo -Wl,--whole-archive ../xrl/targets/.libs/libxorpifmibbase.al -Wl,--no-whole-archive -L/usr/local/xorp/mibs/. -lnetsnmpxorp ../xrl/targets/.libs/libxorpifmibbase.al -lcrypto -Wl,-soname -Wl,xorp_if_mib_module.so -o .libs/xorp_if_mib_module.so /usr/bin/ld: cannot find -lnetsnmpxorp collect2: ld returned 1 exit status libtool: install: error: relink `xorp_if_mib_module.la' with the above command before installing it libtool: install: warning: remember to run `libtool --finish /usr/local/xorp/mibs/.' -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070917/318ec2ab/attachment.html From ror.sanjeev at gmail.com Mon Sep 17 04:33:22 2007 From: ror.sanjeev at gmail.com (sanjeev kumar) Date: Mon, 17 Sep 2007 17:03:22 +0530 Subject: [Xorp-users] Is it possible to configure the NAT on XORP?? Message-ID: <477942240709170433n5da29aa2jac04f8dbff636cae@mail.gmail.com> Hi, I want to configure the NATing on XORP,but i do not know how ..could u please suggest me some steps. One more thing : I want to test OSPF on two machines,both of them running XORP router..instead of say..i want to connect two machines back to back,then want to configure OSPF..Is it possible and provide me some guidance. Thanks... Sanjeev On 9/14/07, xorp-users-request at xorp.org wrote: > > Send Xorp-users mailing list submissions to > xorp-users at xorp.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > or, via email, send a message with subject or body 'help' to > xorp-users-request at xorp.org > > You can reach the person managing the list at > xorp-users-owner at xorp.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Xorp-users digest..." > > > Today's Topics: > > 1. Re: Questions on OSPF (kristian at spritelink.net) > 2. Re: Questions on OSPF (Atanu Ghosh) > 3. Re: Questions on OSPF (kristian at spritelink.net) > 4. Re: Questions on OSPF (Atanu Ghosh) > 5. Re: Questions on OSPF (kristian at spritelink.net) > 6. Re: Unreachable default route. (Pavlin Radoslavov) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 13 Sep 2007 20:52:03 +0200 > From: > Subject: Re: [Xorp-users] Questions on OSPF > To: atanu at ICSI.Berkeley.EDU > Cc: xorp > Message-ID: <4cfe4c3ba67b049473b1d94a88052842 at Mail.SpriteLink.NET> > Content-Type: text/plain; charset="UTF-8" > > On Thu, 13 Sep 2007 11:51:32 -0700, Atanu Ghosh > wrote: > >>>>>> "Kristian" == Kristian Larsson writes: > > > > Kristian> Hansi wrote: > > >> Hello All, > > >> > > >> I'm currently learning how to configure OSPFv2 on two XORP > > >> machines just to establish adjacency with one another. In a p2p > > >> link type, is it still necessary to explicitly set the 'neighbor' > > >> parameter of each machine before adjacency is established? > > >> Furthermore, would it be possible to set the router-id to its > > >> loopback address? instead of say.. the ip address of the > > >> interface on which ospf will be used? > > > > Kristian> The neighbor command is only useful if you are using a > > Kristian> medium on which the routers cannot broadcast and thus > > Kristian> cannot discover each other. If you're using ethernet > > Kristian> (which I presume from your NIC names) you do not have to > > Kristian> use the neighbor statements. I would advice configuring > > Kristian> the interfaces as link-type p2p as this avoids DR election > > Kristian> and unnecessary CPU load. > > > > I am fairly sure that it is necessary to use the neighbour statements. > > Are you serious? > I haven't used the XORP code in quite some time now.. but at least I > thought XORP implemented the OSPF standard. AFAIK, that includes being > able > to discover neighbors and turn up adjacencies to them. Is this not the > case? > Observe that he is running an Ethernet point-to-point link, ie, it is not > a > non-broadcast medium. > Or are you saying that you can't do link-type p2p without configuring > neighbours ? > > -K > > > > ------------------------------ > > Message: 2 > Date: Thu, 13 Sep 2007 12:18:42 -0700 > From: Atanu Ghosh > Subject: Re: [Xorp-users] Questions on OSPF > To: kristian at spritelink.net > Cc: xorp > Message-ID: <6353.1189711122 at tigger.icir.org> > > >>>>> "kristian" == kristian writes: > > kristian> On Thu, 13 Sep 2007 11:51:32 -0700, Atanu Ghosh > kristian> wrote: > >>>>>>> "Kristian" == Kristian Larsson > >>>>>>> writes: > >> > Kristian> Hansi wrote: > >> >> Hello All, > >> >> > >> >> I'm currently learning how to configure OSPFv2 on two XORP >> > >> machines just to establish adjacency with one another. In a p2p > >> >> link type, is it still necessary to explicitly set the > >> 'neighbor' >> parameter of each machine before adjacency is > >> established? >> Furthermore, would it be possible to set the > >> router-id to its >> loopback address? instead of say.. the ip > >> address of the >> interface on which ospf will be used? > >> > Kristian> The neighbor command is only useful if you are using a > Kristian> medium on which the routers cannot broadcast and thus > Kristian> cannot discover each other. If you're using ethernet > Kristian> (which I presume from your NIC names) you do not have to > Kristian> use the neighbor statements. I would advice configuring > Kristian> the interfaces as link-type p2p as this avoids DR election > Kristian> and unnecessary CPU load. > > >> I am fairly sure that it is necessary to use the neighbour > >> statements. > > kristian> Are you serious? I haven't used the XORP code in quite > kristian> some time now.. but at least I thought XORP implemented > kristian> the OSPF standard. AFAIK, that includes being able to > kristian> discover neighbors and turn up adjacencies to them. Is > kristian> this not the case? Observe that he is running an Ethernet > kristian> point-to-point link, ie, it is not a non-broadcast medium. > kristian> Or are you saying that you can't do link-type p2p without > kristian> configuring neighbours ? > > If the link-type is set to "broadcast" then the neighbours will be > correctly discovered. If the link-type is set to "p2p" (Point-to-point) > or "p2m" (Point-to-multipoint) then it is necessary to configure the > neighbours. It has been argued that it should not be necessary to > configure the neighbours if the routers are connected via a true > Point-to-point link, but unfortunately even in this case it is necessary > to configure the neighbour. > > Atanu. > > > > ------------------------------ > > Message: 3 > Date: Thu, 13 Sep 2007 21:31:49 +0200 > From: > Subject: Re: [Xorp-users] Questions on OSPF > To: atanu at ICSI.Berkeley.EDU > Cc: xorp > Message-ID: <93a9e57afbb58e1bf4d6d68740135f89 at Mail.SpriteLink.NET> > Content-Type: text/plain; charset="UTF-8" > > > > On Thu, 13 Sep 2007 12:18:42 -0700, Atanu Ghosh > wrote: > >>>>>> "kristian" == kristian writes: > > > > kristian> On Thu, 13 Sep 2007 11:51:32 -0700, Atanu Ghosh > > kristian> wrote: > > >>>>>>> "Kristian" == Kristian Larsson > > >>>>>>> writes: > > >> > > Kristian> Hansi wrote: > > >> >> Hello All, > > >> >> > > >> >> I'm currently learning how to configure OSPFv2 on two XORP >> > > >> machines just to establish adjacency with one another. In a p2p > > >> >> link type, is it still necessary to explicitly set the > > >> 'neighbor' >> parameter of each machine before adjacency is > > >> established? >> Furthermore, would it be possible to set the > > >> router-id to its >> loopback address? instead of say.. the ip > > >> address of the >> interface on which ospf will be used? > > >> > > Kristian> The neighbor command is only useful if you are using a > > Kristian> medium on which the routers cannot broadcast and thus > > Kristian> cannot discover each other. If you're using ethernet > > Kristian> (which I presume from your NIC names) you do not have to > > Kristian> use the neighbor statements. I would advice configuring > > Kristian> the interfaces as link-type p2p as this avoids DR election > > Kristian> and unnecessary CPU load. > > > > >> I am fairly sure that it is necessary to use the neighbour > > >> statements. > > > > kristian> Are you serious? I haven't used the XORP code in quite > > kristian> some time now.. but at least I thought XORP implemented > > kristian> the OSPF standard. AFAIK, that includes being able to > > kristian> discover neighbors and turn up adjacencies to them. Is > > kristian> this not the case? Observe that he is running an Ethernet > > kristian> point-to-point link, ie, it is not a non-broadcast medium. > > kristian> Or are you saying that you can't do link-type p2p without > > kristian> configuring neighbours ? > > > > If the link-type is set to "broadcast" then the neighbours will be > > correctly discovered. If the link-type is set to "p2p" (Point-to-point) > > or "p2m" (Point-to-multipoint) then it is necessary to configure the > > neighbours. It has been argued that it should not be necessary to > > configure the neighbours if the routers are connected via a true > > Point-to-point link, but unfortunately even in this case it is necessary > > to configure the neighbour. > > Okey, that "kinda" makes sense. I apparently forgot or missed the > conversation on this. > What I want to configure with link-type p2p is not whether or not the > router should try to broadcast but if it should setup one of those virtual > router thingys, hehe. I'm not very familiar with the terminology but (as > you know) on a broadcast medium you first have a DR selection and all that > and then you're gonna run your SPF. Since SPF can't handle the concept of > a > broadcast medium it creates a "virtual router" to represent the broadcast > medium and connects all routers in that broadcast domain as adjacencies to > the virtual router. > When I configure 'isis network point-to-point' on a Cisco router I expect > it to not setup one of these "virtual routers" in it's SPF topology. And > this is different with XORP? > > Perhaps the increase in simplicity to the SPF topology that 'isis network > point-to-point' brings is so small that it's negligable. I think SPF runs > take in the order of 10ms or so for a network with a couple of hundred > routers on a normal routing engine these days. > > -K > > > > ------------------------------ > > Message: 4 > Date: Thu, 13 Sep 2007 14:58:01 -0700 > From: Atanu Ghosh > Subject: Re: [Xorp-users] Questions on OSPF > To: kristian at spritelink.net > Cc: xorp > Message-ID: <44891.1189720681 at tigger.icir.org> > > >>>>> "kristian" == kristian writes: > > kristian> On Thu, 13 Sep 2007 12:18:42 -0700, Atanu Ghosh > kristian> wrote: > >>>>>>> "kristian" == kristian writes: > >> > kristian> On Thu, 13 Sep 2007 11:51:32 -0700, Atanu Ghosh > kristian> wrote: > >> >>>>>>> "Kristian" == Kristian Larsson > >> >>>>>>> writes: > >> >> > Kristian> Hansi wrote: > >> >> >> Hello All, > >> >> >> > >> >> >> I'm currently learning how to configure OSPFv2 on two XORP > >> >> >> machines just to establish adjacency with one another. In a > >> p2p >> >> link type, is it still necessary to explicitly set the > >> >> 'neighbor' >> parameter of each machine before adjacency is >> > >> established? >> Furthermore, would it be possible to set the >> > >> router-id to its >> loopback address? instead of say.. the ip >> > >> address of the >> interface on which ospf will be used? > >> >> > Kristian> The neighbor command is only useful if you are using a > Kristian> medium on which the routers cannot broadcast and thus > Kristian> cannot discover each other. If you're using ethernet > Kristian> (which I presume from your NIC names) you do not have to > Kristian> use the neighbor statements. I would advice configuring > Kristian> the interfaces as link-type p2p as this avoids DR election > Kristian> and unnecessary CPU load. > >> >> I am fairly sure that it is necessary to use the neighbour >> > >> statements. > >> > kristian> Are you serious? I haven't used the XORP code in quite > kristian> some time now.. but at least I thought XORP implemented > kristian> the OSPF standard. AFAIK, that includes being able to > kristian> discover neighbors and turn up adjacencies to them. Is > kristian> this not the case? Observe that he is running an Ethernet > kristian> point-to-point link, ie, it is not a non-broadcast medium. > kristian> Or are you saying that you can't do link-type p2p without > kristian> configuring neighbours ? > > >> If the link-type is set to "broadcast" then the neighbours will > >> be correctly discovered. If the link-type is set to "p2p" > >> (Point-to-point) or "p2m" (Point-to-multipoint) then it is > >> necessary to configure the neighbours. It has been argued that it > >> should not be necessary to configure the neighbours if the > >> routers are connected via a true Point-to-point link, but > >> unfortunately even in this case it is necessary to configure the > >> neighbour. > > kristian> Okey, that "kinda" makes sense. I apparently forgot or > kristian> missed the conversation on this. What I want to configure > kristian> with link-type p2p is not whether or not the router should > kristian> try to broadcast but if it should setup one of those > kristian> virtual router thingys, hehe. I'm not very familiar with > kristian> the terminology but (as you know) on a broadcast medium > kristian> you first have a DR selection and all that and then you're > kristian> gonna run your SPF. Since SPF can't handle the concept of > kristian> a broadcast medium it creates a "virtual router" to > kristian> represent the broadcast medium and connects all routers in > kristian> that broadcast domain as adjacencies to the virtual > kristian> router. When I configure 'isis network point-to-point' on > kristian> a Cisco router I expect it to not setup one of these > kristian> "virtual routers" in it's SPF topology. And this is > kristian> different with XORP? > > Setting the link type to "broadcast" or "p2p" will both result in the > hello packets being broadcast, the distinction is that if the link-type > is set to "p2p" no DR election will be attempted. The XORP OSPF behaves > as specified in the relevant RFCs and interoperates with other OSPF > implementations, the only difference is in configuration of a "p2p" > where we require the neighbour to be specified, which as I mentioned > before should not strictly be necessary. > > Atanu. > > > > ------------------------------ > > Message: 5 > Date: Thu, 13 Sep 2007 23:51:06 +0200 > From: > Subject: Re: [Xorp-users] Questions on OSPF > To: atanu at ICSI.Berkeley.EDU > Cc: xorp > Message-ID: <5f7ec0f76565b4e68ed2457fdf8df3b8 at Mail.SpriteLink.NET> > Content-Type: text/plain; charset="UTF-8" > > On Thu, 13 Sep 2007 14:58:01 -0700, Atanu Ghosh > wrote: > >>>>>> "kristian" == kristian writes: > > > > kristian> On Thu, 13 Sep 2007 12:18:42 -0700, Atanu Ghosh > > kristian> wrote: > > >>>>>>> "kristian" == kristian writes: > > >> > > kristian> On Thu, 13 Sep 2007 11:51:32 -0700, Atanu Ghosh > > kristian> wrote: > > >> >>>>>>> "Kristian" == Kristian Larsson > > >> >>>>>>> writes: > > >> >> > > Kristian> Hansi wrote: > > >> >> >> Hello All, > > >> >> >> > > >> >> >> I'm currently learning how to configure OSPFv2 on two XORP > > >> >> >> machines just to establish adjacency with one another. In a > > >> p2p >> >> link type, is it still necessary to explicitly set the > > >> >> 'neighbor' >> parameter of each machine before adjacency is >> > > >> established? >> Furthermore, would it be possible to set the >> > > >> router-id to its >> loopback address? instead of say.. the ip >> > > >> address of the >> interface on which ospf will be used? > > >> >> > > Kristian> The neighbor command is only useful if you are using a > > Kristian> medium on which the routers cannot broadcast and thus > > Kristian> cannot discover each other. If you're using ethernet > > Kristian> (which I presume from your NIC names) you do not have to > > Kristian> use the neighbor statements. I would advice configuring > > Kristian> the interfaces as link-type p2p as this avoids DR election > > Kristian> and unnecessary CPU load. > > >> >> I am fairly sure that it is necessary to use the neighbour >> > > >> statements. > > >> > > kristian> Are you serious? I haven't used the XORP code in quite > > kristian> some time now.. but at least I thought XORP implemented > > kristian> the OSPF standard. AFAIK, that includes being able to > > kristian> discover neighbors and turn up adjacencies to them. Is > > kristian> this not the case? Observe that he is running an Ethernet > > kristian> point-to-point link, ie, it is not a non-broadcast medium. > > kristian> Or are you saying that you can't do link-type p2p without > > kristian> configuring neighbours ? > > > > >> If the link-type is set to "broadcast" then the neighbours will > > >> be correctly discovered. If the link-type is set to "p2p" > > >> (Point-to-point) or "p2m" (Point-to-multipoint) then it is > > >> necessary to configure the neighbours. It has been argued that it > > >> should not be necessary to configure the neighbours if the > > >> routers are connected via a true Point-to-point link, but > > >> unfortunately even in this case it is necessary to configure the > > >> neighbour. > > > > kristian> Okey, that "kinda" makes sense. I apparently forgot or > > kristian> missed the conversation on this. What I want to configure > > kristian> with link-type p2p is not whether or not the router should > > kristian> try to broadcast but if it should setup one of those > > kristian> virtual router thingys, hehe. I'm not very familiar with > > kristian> the terminology but (as you know) on a broadcast medium > > kristian> you first have a DR selection and all that and then you're > > kristian> gonna run your SPF. Since SPF can't handle the concept of > > kristian> a broadcast medium it creates a "virtual router" to > > kristian> represent the broadcast medium and connects all routers in > > kristian> that broadcast domain as adjacencies to the virtual > > kristian> router. When I configure 'isis network point-to-point' on > > kristian> a Cisco router I expect it to not setup one of these > > kristian> "virtual routers" in it's SPF topology. And this is > > kristian> different with XORP? > > > > Setting the link type to "broadcast" or "p2p" will both result in the > > hello packets being broadcast, the distinction is that if the link-type > > is set to "p2p" no DR election will be attempted. > > Alright, just as I expected. > > > The XORP OSPF behaves > > as specified in the relevant RFCs and interoperates with other OSPF > > implementations, the only difference is in configuration of a "p2p" > > where we require the neighbour to be specified, which as I mentioned > > before should not strictly be necessary. > > Okey, not what I expected. Why is it so? Just lack of time to do the > actual > implementation (although I don't see how it would actually be more code > than it is today) or has there been a policy decision against it? > > -K > > > > ------------------------------ > > Message: 6 > Date: Thu, 13 Sep 2007 16:11:57 -0700 > From: Pavlin Radoslavov > Subject: Re: [Xorp-users] Unreachable default route. > To: Ben Greear > Cc: xorp-users at xorp.org, Pavlin Radoslavov , Tim > Durack > Message-ID: <200709132312.l8DNBvsa040733 at possum.icir.org> > > Ben Greear wrote: > > > Pavlin Radoslavov wrote: > > > > > You could use the following configuration on Linux to configure a > > > discard interface and a static route that is blackhole: > > > > > > interfaces { > > > interface my_discard { > > > discard: true > > > vif my_discard { > > > } > > > } > > > } > > > > [snip] > > > > Ok, this does indeed create a blackhole route. But, it seems this will > just > > silently eat packets. What I really want is unreachable, which will > return > ~~~~~~~~~~~~~~~~~~~~ > > Correct. This is the definition of "blackhole" :) > > > the proper ICMP packet saying the destination is unreachable. > > > > Any idea how hard it would be to add this functionality? > > You need to install a different type of route in the kernel which I > believe in Linux is RTN_UNREACHABLE instead of RTN_BLACKHOLE. > However, XORP doesn't support such routes. > You could try experimenting with such routes by replacing all > references (I counted two references) of RTN_BLACKHOLE with > RTN_UNREACHABLE inside file > fea/data_plane/fibconfig/fibconfig_entry_set_netlink_socket.cc > > This is not the right solution, but allows you to play with such > routes. > > Just curious, could you describe your particular scenario you have > that requires installing RTN_UNREACHABLE routes. > > > In the meantime, I'll work on a patch that makes the 'static' priority > > configurable with an environment variable. > > I should tell you upfront that configurable admin distances in RIB > has been on our TODO list for quite some time. However it is not > trivial if we want to do it properly by taking into account various > considerations. > E.g., one of the goals is to be able to configure the priorities (on > the fly) inside the XORP config file. > > Hence, most likely we won't use a solution that is based on > setting an environmental variable (or something like this). > In other words, don't be offended if your patch is not applied to > the CVS. > Though, if I were in your position I would use such shortcut in my > local XORP copy. > > 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 > > > > ------------------------------ > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > > End of Xorp-users Digest, Vol 18, Issue 15 > ****************************************** > -- Efforts may fail,But don't Fail to make efforts. --------- Sanjeev Kumar Project Engineer CDAC(Formerly NCST) Juhu,Mumbai-400049 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070917/54b8c6f1/attachment-0001.html From atanu at ICSI.Berkeley.EDU Mon Sep 17 07:58:03 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Mon, 17 Sep 2007 07:58:03 -0700 Subject: [Xorp-users] Xorp compilation with SNMP In-Reply-To: Message from "Frederic Gilloteau" of "Mon, 17 Sep 2007 12:20:32 +0200." <002701c7f914$614b1080$025ca8c0@ad2.ad.alcatel.com> Message-ID: <76785.1190041083@tigger.icir.org> Hi, XORP uses the Net-SNMP package (http://www.net-snmp.org/), try building this first. Atanu. >>>>> "Frederic" == Frederic Gilloteau writes: Frederic> Hello, Frederic> I got some errors trying to compile xorp with the snmp Frederic> module: Frederic> (./configure --with-snmp --enable-shared) Frederic> Could you please help me ? Frederic> Thanks in advance Frederic> Fred Frederic> -- Frederic> Making install in snmpdscripts mkdir -p -- Frederic> /home/fgilloteau/DEV/TIERS/xorp/TMP/xorp-1.4-0.1-root/usr/local/xorp/s Frederic> nmpdscripts /usr/bin/install -c getbgppeertable Frederic> /home/fgilloteau/DEV/TIERS/xorp/TMP/xorp-1.4-0.1-root/usr/local/xorp/s Frederic> nmpdscripts/getbgppeertable Frederic> /usr/bin/install -c getbgpversion Frederic> /home/fgilloteau/DEV/TIERS/xorp/TMP/xorp-1.4-0.1-root/usr/local/xorp/s Frederic> nmpdscripts/getbgpversion Frederic> /usr/bin/install -c startsnmp Frederic> /home/fgilloteau/DEV/TIERS/xorp/TMP/xorp-1.4-0.1-root/usr/local/xorp/s Frederic> nmpdscripts/startsnmp Frederic> /usr/bin/install -c stopsnmp Frederic> /home/fgilloteau/DEV/TIERS/xorp/TMP/xorp-1.4-0.1-root/usr/local/xorp/s Frederic> nmpdscripts/stopsnmp Frederic> Making install in tests /bin/sh ./libtool Frederic> --mode=install /usr/bin/install -c libnetsnmpxorp.la Frederic> /home/fgilloteau/DEV/TIERS/xorp/TMP/xorp-1.4-0.1-root/usr/local/xorp/. Frederic> /libnetsnmpxorp.la Frederic> /usr/bin/install -c .libs/libnetsnmpxorp.so Frederic> /home/fgilloteau/DEV/TIERS/xorp/TMP/xorp-1.4-0.1-root/usr/local/xorp/. Frederic> /libnetsnmpxorp.so Frederic> /usr/bin/install -c .libs/libnetsnmpxorp.lai Frederic> /home/fgilloteau/DEV/TIERS/xorp/TMP/xorp-1.4-0.1-root/usr/local/xorp/. Frederic> /libnetsnmpxorp.la Frederic> libtool: install: warning: remember to run `libtool Frederic> --finish /usr/local/xorp/mibs/.' /bin/sh ./libtool Frederic> --mode=install /usr/bin/install -c bgp4_mib_1657.la Frederic> /home/fgilloteau/DEV/TIERS/xorp/TMP/xorp-1.4-0.1-root/usr/local/xorp/. Frederic> /bgp4_mib_1657.la Frederic> libtool: install: warning: relinking `bgp4_mib_1657.la' Frederic> cd /home/fgilloteau/DEV/TIERS/xorp/BUILD/xorp-1.4/mibs; Frederic> /bin/sh ./libtool --mode=relink g++ -pipe Frederic> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m32 -march=i386 Frederic> -mtune=pentium4 -fasynchronous-unwind-tables Frederic> -DNETSNMP_NO_INLINE -g -W -Wall -Wwrite-strings Frederic> -Wcast-qual -Werror -Wpointer-arith -Wcast-align Frederic> -Woverloaded-virtual -ftemplate-depth-22 -pipe -o Frederic> bgp4_mib_1657.la -rpath /usr/local/xorp/mibs/. -module Frederic> -avoid-version bgp4_mib_1657.lo Frederic> bgp4_mib_1657_bgpversion.lo bgp4_mib_1657_bgplocalas.lo Frederic> bgp4_mib_1657_bgpidentifier.lo Frederic> bgp4_mib_1657_bgppeertable.lo Frederic> bgp4_mib_1657_bgp4pathattrtable.lo bgp4_mib_xrl_target.lo Frederic> ./libnetsnmpxorp.la ../xrl/targets/libbgp4mibbase.la Frederic> ../xrl/interfaces/libbgpxif.la -lcrypto Frederic> g++ -shared bgp4_mib_1657.lo Frederic> bgp4_mib_1657_bgpversion.lo bgp4_mib_1657_bgplocalas.lo Frederic> bgp4_mib_1657_bgpidentifier.lo Frederic> bgp4_mib_1657_bgppeertable.lo Frederic> bgp4_mib_1657_bgp4pathattrtable.lo bgp4_mib_xrl_target.lo Frederic> -Wl,--whole-archive ../xrl/targets/.libs/libbgp4mibbase.al Frederic> ../xrl/interfaces/.libs/libbgpxif.al Frederic> -Wl,--no-whole-archive Frederic> -L/usr/local/xorp/mibs/. -lnetsnmpxorp Frederic> ../xrl/targets/.libs/libbgp4mibbase.al Frederic> ../xrl/interfaces/.libs/libbgpxif.al -lcrypto -Wl,-soname Frederic> -Wl,bgp4_mib_1657.so -o .libs/bgp4_mib_1657.so Frederic> /usr/bin/ld: cannot find -lnetsnmpxorp collect2: ld Frederic> returned 1 exit status libtool: install: error: relink Frederic> `bgp4_mib_1657.la' with the above command before Frederic> installing it libtool: install: warning: remember to run Frederic> `libtool --finish /usr/local/xorp/mibs/.' Frederic> /bin/sh ./libtool --mode=install /usr/bin/install -c Frederic> ospf_mib_1850.la Frederic> /home/fgilloteau/DEV/TIERS/xorp/TMP/xorp-1.4-0.1-root/usr/local/xorp/. Frederic> /ospf_mib_1850.la Frederic> libtool: install: warning: relinking `ospf_mib_1850.la' Frederic> cd /home/fgilloteau/DEV/TIERS/xorp/BUILD/xorp-1.4/mibs; Frederic> /bin/sh ./libtool --mode=relink g++ -pipe Frederic> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m32 -march=i386 Frederic> -mtune=pentium4 -fasynchronous-unwind-tables Frederic> -DNETSNMP_NO_INLINE -g -W -Wall -Wwrite-strings Frederic> -Wcast-qual -Werror -Wpointer-arith -Wcast-align Frederic> -Woverloaded-virtual -ftemplate-depth-22 -pipe -o Frederic> ospf_mib_1850.la -rpath /usr/local/xorp/mibs/. -module Frederic> -avoid-version ospf_mib_1850.lo ./libnetsnmpxorp.la Frederic> -lcrypto Frederic> g++ -shared ospf_mib_1850.lo Frederic> -L/usr/local/xorp/mibs/. -lnetsnmpxorp -lcrypto Frederic> -Wl,-soname -Wl,ospf_mib_1850.so -o .libs/ospf_mib_1850.so Frederic> /usr/bin/ld: cannot find -lnetsnmpxorp collect2: ld Frederic> returned 1 exit status libtool: install: error: relink Frederic> `ospf_mib_1850.la' with the above command before Frederic> installing it libtool: install: warning: remember to run Frederic> `libtool --finish /usr/local/xorp/mibs/.' Frederic> /bin/sh ./libtool --mode=install /usr/bin/install -c Frederic> xorp_if_mib_module.la Frederic> /home/fgilloteau/DEV/TIERS/xorp/TMP/xorp-1.4-0.1-root/usr/local/xorp/. Frederic> /xorp_if_mib_module.la Frederic> libtool: install: warning: relinking Frederic> `xorp_if_mib_module.la' cd Frederic> /home/fgilloteau/DEV/TIERS/xorp/BUILD/xorp-1.4/mibs; Frederic> /bin/sh ./libtool --mode=relink g++ -pipe Frederic> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m32 -march=i386 Frederic> -mtune=pentium4 -fasynchronous-unwind-tables Frederic> -DNETSNMP_NO_INLINE -g -W -Wall -Wwrite-strings Frederic> -Wcast-qual -Werror -Wpointer-arith -Wcast-align Frederic> -Woverloaded-virtual -ftemplate-depth-22 -pipe -o Frederic> xorp_if_mib_module.la -rpath Frederic> /usr/local/xorp/mibs/. -module -avoid-version Frederic> xorp_if_mib_module.lo xorp_if_mib_xrl_target.lo Frederic> ./libnetsnmpxorp.la ../xrl/targets/libxorpifmibbase.la Frederic> -lcrypto Frederic> g++ -shared xorp_if_mib_module.lo Frederic> xorp_if_mib_xrl_target.lo -Wl,--whole-archive Frederic> ../xrl/targets/.libs/libxorpifmibbase.al Frederic> -Wl,--no-whole-archive Frederic> -L/usr/local/xorp/mibs/. -lnetsnmpxorp Frederic> ../xrl/targets/.libs/libxorpifmibbase.al -lcrypto Frederic> -Wl,-soname -Wl,xorp_if_mib_module.so -o Frederic> .libs/xorp_if_mib_module.so Frederic> /usr/bin/ld: cannot find -lnetsnmpxorp collect2: ld Frederic> returned 1 exit status libtool: install: error: relink Frederic> `xorp_if_mib_module.la' with the above command before Frederic> installing it libtool: install: warning: remember to run Frederic> `libtool --finish /usr/local/xorp/mibs/.' Frederic> _______________________________________________ Xorp-users Frederic> mailing list Xorp-users at xorp.org Frederic> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From atanu at ICSI.Berkeley.EDU Mon Sep 17 07:59:09 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Mon, 17 Sep 2007 07:59:09 -0700 Subject: [Xorp-users] Is it possible to configure the NAT on XORP?? In-Reply-To: Message from "sanjeev kumar" of "Mon, 17 Sep 2007 17:19:00 +0530." <477942240709170449h6a3e030brd5ffbd4bab8c44b4@mail.gmail.com> Message-ID: <77086.1190041149@tigger.icir.org> Hi, It isn't possible to configure NAT from within XORP at the moment. Atanu. >>>>> "sanjeev" == sanjeev kumar writes: sanjeev> Hi, Is it possible to configure NATing on XORP router.If sanjeev> then please suggest me some steps.. Thanks, Sanjeev -- sanjeev> Efforts may fail,But don't Fail to make efforts. --------- sanjeev> Sanjeev Kumar Project Engineer CDAC(Formerly NCST) sanjeev> Juhu,Mumbai-400049 sanjeev> _______________________________________________ Xorp-users sanjeev> mailing list Xorp-users at xorp.org sanjeev> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From atanu at ICSI.Berkeley.EDU Mon Sep 17 08:01:14 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Mon, 17 Sep 2007 08:01:14 -0700 Subject: [Xorp-users] Is it possible to configure the NAT on XORP?? In-Reply-To: Message from "sanjeev kumar" of "Mon, 17 Sep 2007 17:03:22 +0530." <477942240709170433n5da29aa2jac04f8dbff636cae@mail.gmail.com> Message-ID: <77648.1190041274@tigger.icir.org> Hi, The getting started web page (http://www.xorp.org/getting_started.html) contains examples of basic protocol configurations. Atanu. >>>>> "sanjeev" == sanjeev kumar writes: sanjeev> Hi, I want to configure the NATing on XORP,but i do not sanjeev> know how ..could u please suggest me some steps. One more sanjeev> thing : I want to test OSPF on two machines,both of them sanjeev> running XORP router..instead of say..i want to connect two sanjeev> machines back to back,then want to configure OSPF..Is it sanjeev> possible and provide me some guidance. Thanks... Sanjeev sanjeev> On 9/14/07, xorp-users-request at xorp.org < sanjeev> xorp-users-request at xorp.org> wrote: sanjeev> Send Xorp-users mailing list submissions to sanjeev> xorp-users at xorp.org To subscribe or unsubscribe via the sanjeev> World Wide Web, visit sanjeev> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-user sanjeev> s or, via email, send a message with subject or body 'help' sanjeev> to xorp-users-request at xorp.org You can reach the person sanjeev> managing the list at xorp-users-owner at xorp.org When sanjeev> replying, please edit your Subject line so it is more sanjeev> specific than "Re: Contents of Xorp-users digest..." sanjeev> Today's Topics: 1. Re: Questions on OSPF sanjeev> (kristian at spritelink.net) 2. Re: Questions on OSPF (Atanu sanjeev> Ghosh) 3. Re: Questions on OSPF ( kristian at spritelink.net) sanjeev> 4. Re: Questions on OSPF (Atanu Ghosh) 5. Re: Questions on sanjeev> OSPF (kristian at spritelink.net) 6. Re: Unreachable default sanjeev> route. (Pavlin Radoslavov) sanjeev> ------------------------------------------------------------------- sanjeev> --- Message: 1 Date: Thu, 13 Sep 2007 20:52:03 +0200 From: sanjeev> Subject: Re: [Xorp-users] sanjeev> Questions on OSPF To: atanu at ICSI.Berkeley.EDU Cc: xorp sanjeev> Message-ID: < sanjeev> 4cfe4c3ba67b049473b1d94a88052842 at Mail.SpriteLink.NET> sanjeev> Content-Type: text/plain; charset="UTF-8" On Thu, 13 Sep sanjeev> 2007 11:51:32 -0700, Atanu Ghosh < atanu at icsi.berkeley.edu> sanjeev> wrote: >>>>>>> "Kristian" == Kristian Larsson sanjeev> writes: >> Kristian> Hansi wrote: >> >> Hello All, >> >> >> >> I'm currently learning how to configure OSPFv2 on two XORP >> >> machines just to establish adjacency with one another. In sanjeev> a p2p >> >> link type, is it still necessary to explicitly set the sanjeev> 'neighbor' >> >> parameter of each machine before adjacency is established? >> >> Furthermore, would it be possible to set the router-id to sanjeev> its >> >> loopback address? instead of say.. the ip address of the >> >> interface on which ospf will be used? >> Kristian> The neighbor command is only useful if you are sanjeev> using a Kristian> medium on which the routers cannot broadcast and sanjeev> thus Kristian> cannot discover each other. If you're using sanjeev> ethernet Kristian> (which I presume from your NIC names) you do not sanjeev> have to Kristian> use the neighbor statements. I would advice sanjeev> configuring Kristian> the interfaces as link-type p2p as this avoids DR sanjeev> election Kristian> and unnecessary CPU load. >> I am fairly sure that it is necessary to use the neighbour sanjeev> statements. Are you serious? I haven't used the XORP sanjeev> code in quite some time now.. but at least I thought XORP sanjeev> implemented the OSPF standard. AFAIK, that includes being sanjeev> able to discover neighbors and turn up adjacencies to sanjeev> them. Is this not the case? Observe that he is running an sanjeev> Ethernet point-to-point link, ie, it is not a non-broadcast sanjeev> medium. Or are you saying that you can't do link-type p2p sanjeev> without configuring neighbours ? -K sanjeev> ------------------------------ Message: 2 Date: Thu, 13 Sep sanjeev> 2007 12:18:42 -0700 From: Atanu Ghosh sanjeev> Subject: Re: [Xorp-users] sanjeev> Questions on OSPF To: kristian at spritelink.net Cc: xorp sanjeev> Message-ID: < sanjeev> 6353.1189711122 at tigger.icir.org> >>>>>> "kristian" == kristian writes: kristian> On Thu, 13 Sep 2007 11:51:32 -0700, Atanu Ghosh kristian> wrote: >>>>>>>> "Kristian" == Kristian Larsson < sanjeev> kristian at spritelink.net> >>>>>>>> writes: >>> Kristian> Hansi wrote: >>> >> Hello All, >>> >> >>> >> I'm currently learning how to configure OSPFv2 on two sanjeev> XORP >> >>> machines just to establish adjacency with one another. In a sanjeev> p2p >>> >> link type, is it still necessary to explicitly set the >>> 'neighbor' >> parameter of each machine before adjacency is >>> established? >> Furthermore, would it be possible to set sanjeev> the >>> router-id to its >> loopback address? instead of say.. the sanjeev> ip >>> address of the >> interface on which ospf will be used? >>> Kristian> The neighbor command is only useful if you are using sanjeev> a Kristian> medium on which the routers cannot broadcast and thus Kristian> cannot discover each other. If you're using ethernet Kristian> (which I presume from your NIC names) you do not have sanjeev> to Kristian> use the neighbor statements. I would advice sanjeev> configuring Kristian> the interfaces as link-type p2p as this avoids DR sanjeev> election Kristian> and unnecessary CPU load. >>> I am fairly sure that it is necessary to use the neighbour >>> statements. kristian> Are you serious? I haven't used the XORP code in sanjeev> quite kristian> some time now.. but at least I thought XORP sanjeev> implemented kristian> the OSPF standard. AFAIK, that includes being able to kristian> discover neighbors and turn up adjacencies to them. sanjeev> Is kristian> this not the case? Observe that he is running an sanjeev> Ethernet kristian> point-to-point link, ie, it is not a non-broadcast sanjeev> medium. kristian> Or are you saying that you can't do link-type p2p sanjeev> without kristian> configuring neighbours ? sanjeev> If the link-type is set to "broadcast" then the sanjeev> neighbours will be correctly discovered. If the link-type sanjeev> is set to "p2p" (Point-to-point) or "p2m" sanjeev> (Point-to-multipoint) then it is necessary to configure the sanjeev> neighbours. It has been argued that it should not be sanjeev> necessary to configure the neighbours if the routers are sanjeev> connected via a true Point-to-point link, but unfortunately sanjeev> even in this case it is necessary to configure the sanjeev> neighbour. Atanu. ------------------------------ Message: sanjeev> 3 Date: Thu, 13 Sep 2007 21:31:49 +0200 From: sanjeev> Subject: Re: [Xorp-users] sanjeev> Questions on OSPF To: atanu at ICSI.Berkeley.EDU Cc: xorp < sanjeev> xorp-users at xorp.org> Message-ID: sanjeev> <93a9e57afbb58e1bf4d6d68740135f89 at Mail.SpriteLink.NET> sanjeev> Content-Type: text/plain; charset="UTF-8" On Thu, 13 Sep sanjeev> 2007 12:18:42 -0700, Atanu Ghosh sanjeev> wrote: >>>>>>> "kristian" == kristian < kristian at spritelink.net> writes: >> kristian> On Thu, 13 Sep 2007 11:51:32 -0700, Atanu Ghosh kristian> wrote: >> >>>>>>> "Kristian" == Kristian Larsson sanjeev> >> >>>>>>> writes: >> >> Kristian> Hansi wrote: >> >> >> Hello All, >> >> >> >> >> >> I'm currently learning how to configure OSPFv2 on two sanjeev> XORP >> >> >> machines just to establish adjacency with one another. In sanjeev> a p2p >> >> >> link type, is it still necessary to explicitly set the >> >> 'neighbor' >> parameter of each machine before adjacency sanjeev> is >> >> established? >> Furthermore, would it be possible to set sanjeev> the >> >> router-id to its >> loopback address? instead of say.. the sanjeev> ip >> >> address of the >> interface on which ospf will be used? >> >> Kristian> The neighbor command is only useful if you are sanjeev> using a Kristian> medium on which the routers cannot broadcast and sanjeev> thus Kristian> cannot discover each other. If you're using sanjeev> ethernet Kristian> (which I presume from your NIC names) you do not sanjeev> have to Kristian> use the neighbor statements. I would advice sanjeev> configuring Kristian> the interfaces as link-type p2p as this avoids DR sanjeev> election Kristian> and unnecessary CPU load. >> >> I am fairly sure that it is necessary to use the sanjeev> neighbour >> >> statements. >> kristian> Are you serious? I haven't used the XORP code in sanjeev> quite kristian> some time now.. but at least I thought XORP sanjeev> implemented kristian> the OSPF standard. AFAIK, that includes being able sanjeev> to kristian> discover neighbors and turn up adjacencies to them. sanjeev> Is kristian> this not the case? Observe that he is running an sanjeev> Ethernet kristian> point-to-point link, ie, it is not a non-broadcast sanjeev> medium. kristian> Or are you saying that you can't do link-type p2p sanjeev> without kristian> configuring neighbours ? >> If the link-type is set to "broadcast" then the neighbours will sanjeev> be >> correctly discovered. If the link-type is set to "p2p" sanjeev> (Point-to-point) >> or "p2m" (Point-to-multipoint) then it is necessary to configure sanjeev> the >> neighbours. It has been argued that it should not be necessary to >> configure the neighbours if the routers are connected via a true >> Point-to-point link, but unfortunately even in this case it is sanjeev> necessary >> to configure the neighbour. sanjeev> Okey, that "kinda" makes sense. I apparently forgot or sanjeev> missed the conversation on this. What I want to configure sanjeev> with link-type p2p is not whether or not the router should sanjeev> try to broadcast but if it should setup one of those sanjeev> virtual router thingys, hehe. I'm not very familiar with sanjeev> the terminology but (as you know) on a broadcast medium you sanjeev> first have a DR selection and all that and then you're sanjeev> gonna run your SPF. Since SPF can't handle the concept of a sanjeev> broadcast medium it creates a "virtual router" to represent sanjeev> the broadcast medium and connects all routers in that sanjeev> broadcast domain as adjacencies to the virtual router. sanjeev> When I configure 'isis network point-to-point' on a Cisco sanjeev> router I expect it to not setup one of these "virtual sanjeev> routers" in it's SPF topology. And this is different with sanjeev> XORP? Perhaps the increase in simplicity to the SPF sanjeev> topology that 'isis network point-to-point' brings is so sanjeev> small that it's negligable. I think SPF runs take in the sanjeev> order of 10ms or so for a network with a couple of hundred sanjeev> routers on a normal routing engine these days. -K sanjeev> ------------------------------ Message: 4 Date: Thu, 13 Sep sanjeev> 2007 14:58:01 -0700 From: Atanu Ghosh < sanjeev> atanu at ICSI.Berkeley.EDU> Subject: Re: [Xorp-users] sanjeev> Questions on OSPF To: kristian at spritelink.net Cc: xorp sanjeev> Message-ID: sanjeev> <44891.1189720681 at tigger.icir.org> >>>>>> "kristian" == kristian < kristian at spritelink.net> writes: kristian> On Thu, 13 Sep 2007 12:18:42 -0700, Atanu Ghosh kristian> wrote: >>>>>>>> "kristian" == kristian < kristian at spritelink.net> sanjeev> writes: >>> kristian> On Thu, 13 Sep 2007 11:51:32 -0700, Atanu Ghosh < kristian> atanu at icsi.berkeley.edu> wrote: >>> >>>>>>> "Kristian" == Kristian Larsson sanjeev> >>> >>>>>>> writes: >>> >> Kristian> Hansi wrote: >>> >> >> Hello All, >>> >> >> >>> >> >> I'm currently learning how to configure OSPFv2 on two sanjeev> XORP >>> >> >> machines just to establish adjacency with one another. sanjeev> In a >>> p2p >> >> link type, is it still necessary to explicitly set sanjeev> the >>> >> 'neighbor' >> parameter of each machine before adjacency sanjeev> is >> >>> established? >> Furthermore, would it be possible to set sanjeev> the >> >>> router-id to its >> loopback address? instead of say.. the sanjeev> ip >> >>> address of the >> interface on which ospf will be used? >>> >> Kristian> The neighbor command is only useful if you are using sanjeev> a Kristian> medium on which the routers cannot broadcast and thus Kristian> cannot discover each other. If you're using ethernet Kristian> (which I presume from your NIC names) you do not have sanjeev> to Kristian> use the neighbor statements. I would advice sanjeev> configuring Kristian> the interfaces as link-type p2p as this avoids DR sanjeev> election Kristian> and unnecessary CPU load. >>> >> I am fairly sure that it is necessary to use the sanjeev> neighbour >> >>> statements. >>> kristian> Are you serious? I haven't used the XORP code in sanjeev> quite kristian> some time now.. but at least I thought XORP sanjeev> implemented kristian> the OSPF standard. AFAIK, that includes being able to kristian> discover neighbors and turn up adjacencies to them. sanjeev> Is kristian> this not the case? Observe that he is running an sanjeev> Ethernet kristian> point-to-point link, ie, it is not a non-broadcast sanjeev> medium. kristian> Or are you saying that you can't do link-type p2p sanjeev> without kristian> configuring neighbours ? >>> If the link-type is set to "broadcast" then the neighbours sanjeev> will >>> be correctly discovered. If the link-type is set to "p2p" >>> (Point-to-point) or "p2m" (Point-to-multipoint) then it is >>> necessary to configure the neighbours. It has been argued sanjeev> that it >>> should not be necessary to configure the neighbours if the >>> routers are connected via a true Point-to-point link, but >>> unfortunately even in this case it is necessary to configure sanjeev> the >>> neighbour. kristian> Okey, that "kinda" makes sense. I apparently forgot sanjeev> or kristian> missed the conversation on this. What I want to sanjeev> configure kristian> with link-type p2p is not whether or not the router sanjeev> should kristian> try to broadcast but if it should setup one of those kristian> virtual router thingys, hehe. I'm not very familiar sanjeev> with kristian> the terminology but (as you know) on a broadcast sanjeev> medium kristian> you first have a DR selection and all that and then sanjeev> you're kristian> gonna run your SPF. Since SPF can't handle the sanjeev> concept of kristian> a broadcast medium it creates a "virtual router" to kristian> represent the broadcast medium and connects all sanjeev> routers in kristian> that broadcast domain as adjacencies to the virtual kristian> router. When I configure 'isis network sanjeev> point-to-point' on kristian> a Cisco router I expect it to not setup one of these kristian> "virtual routers" in it's SPF topology. And this is kristian> different with XORP? sanjeev> Setting the link type to "broadcast" or "p2p" will sanjeev> both result in the hello packets being broadcast, the sanjeev> distinction is that if the link-type is set to "p2p" no DR sanjeev> election will be attempted. The XORP OSPF behaves as sanjeev> specified in the relevant RFCs and interoperates with other sanjeev> OSPF implementations, the only difference is in sanjeev> configuration of a "p2p" where we require the neighbour to sanjeev> be specified, which as I mentioned before should not sanjeev> strictly be necessary. Atanu. sanjeev> ------------------------------ Message: 5 Date: Thu, 13 Sep sanjeev> 2007 23:51:06 +0200 From: sanjeev> Subject: Re: [Xorp-users] Questions on OSPF To: sanjeev> atanu at ICSI.Berkeley.EDU Cc: xorp sanjeev> Message-ID: < sanjeev> 5f7ec0f76565b4e68ed2457fdf8df3b8 at Mail.SpriteLink.NET> sanjeev> Content-Type: text/plain; charset="UTF-8" On Thu, 13 Sep sanjeev> 2007 14:58:01 -0700, Atanu Ghosh sanjeev> wrote: >>>>>>> "kristian" == kristian writes: >> kristian> On Thu, 13 Sep 2007 12:18:42 -0700, Atanu Ghosh kristian> wrote: >> >>>>>>> "kristian" == kristian < kristian at spritelink.net> sanjeev> writes: >> >> kristian> On Thu, 13 Sep 2007 11:51:32 -0700, Atanu Ghosh kristian> wrote: >> >> >>>>>>> "Kristian" == Kristian Larsson sanjeev> >> >> >>>>>>> writes: >> >> >> Kristian> Hansi wrote: >> >> >> >> Hello All, >> >> >> >> >> >> >> >> I'm currently learning how to configure OSPFv2 on sanjeev> two XORP >> >> >> >> machines just to establish adjacency with one sanjeev> another. In a >> >> p2p >> >> link type, is it still necessary to explicitly sanjeev> set the >> >> >> 'neighbor' >> parameter of each machine before sanjeev> adjacency is >> >> >> established? >> Furthermore, would it be possible to set sanjeev> the >> >> >> router-id to its >> loopback address? instead of say.. the sanjeev> ip >> >> >> address of the >> interface on which ospf will be used? >> >> >> Kristian> The neighbor command is only useful if you are sanjeev> using a Kristian> medium on which the routers cannot broadcast and sanjeev> thus Kristian> cannot discover each other. If you're using sanjeev> ethernet Kristian> (which I presume from your NIC names) you do not sanjeev> have to Kristian> use the neighbor statements. I would advice sanjeev> configuring Kristian> the interfaces as link-type p2p as this avoids DR sanjeev> election Kristian> and unnecessary CPU load. >> >> >> I am fairly sure that it is necessary to use the sanjeev> neighbour >> >> >> statements. >> >> kristian> Are you serious? I haven't used the XORP code in sanjeev> quite kristian> some time now.. but at least I thought XORP sanjeev> implemented kristian> the OSPF standard. AFAIK, that includes being able sanjeev> to kristian> discover neighbors and turn up adjacencies to them. sanjeev> Is kristian> this not the case? Observe that he is running an sanjeev> Ethernet kristian> point-to-point link, ie, it is not a non-broadcast sanjeev> medium. kristian> Or are you saying that you can't do link-type p2p sanjeev> without kristian> configuring neighbours ? >> >> If the link-type is set to "broadcast" then the sanjeev> neighbours will >> >> be correctly discovered. If the link-type is set to "p2p" >> >> (Point-to-point) or "p2m" (Point-to-multipoint) then it is >> >> necessary to configure the neighbours. It has been argued sanjeev> that it >> >> should not be necessary to configure the neighbours if the >> >> routers are connected via a true Point-to-point link, but >> >> unfortunately even in this case it is necessary to sanjeev> configure the >> >> neighbour. >> kristian> Okey, that "kinda" makes sense. I apparently forgot sanjeev> or kristian> missed the conversation on this. What I want to sanjeev> configure kristian> with link-type p2p is not whether or not the router sanjeev> should kristian> try to broadcast but if it should setup one of sanjeev> those kristian> virtual router thingys, hehe. I'm not very familiar sanjeev> with kristian> the terminology but (as you know) on a broadcast sanjeev> medium kristian> you first have a DR selection and all that and then sanjeev> you're kristian> gonna run your SPF. Since SPF can't handle the sanjeev> concept of kristian> a broadcast medium it creates a "virtual router" to kristian> represent the broadcast medium and connects all sanjeev> routers in kristian> that broadcast domain as adjacencies to the virtual kristian> router. When I configure 'isis network sanjeev> point-to-point' on kristian> a Cisco router I expect it to not setup one of sanjeev> these kristian> "virtual routers" in it's SPF topology. And this is kristian> different with XORP? >> Setting the link type to "broadcast" or "p2p" will both result >> in sanjeev> the >> hello packets being broadcast, the distinction is that if the sanjeev> link-type >> is set to "p2p" no DR election will be attempted. sanjeev> Alright, just as I expected. >> The XORP OSPF behaves as specified in the relevant RFCs and >> interoperates with other sanjeev> OSPF >> implementations, the only difference is in configuration of a sanjeev> "p2p" >> where we require the neighbour to be specified, which as I sanjeev> mentioned >> before should not strictly be necessary. sanjeev> Okey, not what I expected. Why is it so? Just lack of sanjeev> time to do the actual implementation (although I don't see sanjeev> how it would actually be more code than it is today) or has sanjeev> there been a policy decision against it? -K sanjeev> ------------------------------ Message: 6 Date: Thu, 13 Sep sanjeev> 2007 16:11:57 -0700 From: Pavlin Radoslavov sanjeev> Subject: Re: [Xorp-users] Unreachable sanjeev> default route. To: Ben Greear sanjeev> Cc: xorp-users at xorp.org, Pavlin Radoslavov >, Tim Durack Message-ID: sanjeev> <200709132312.l8DNBvsa040733 at possum.icir.org > Ben Greear sanjeev> wrote: >> Pavlin Radoslavov wrote: >> >> > You could use the following configuration on Linux to configure sanjeev> a >> > discard interface and a static route that is blackhole: >> > >> > interfaces { > interface my_discard { > discard: true > vif >> my_discard { > } > } > } >> >> [snip] >> >> Ok, this does indeed create a blackhole route. But, it seems sanjeev> this will just >> silently eat packets. What I really want is unreachable, which sanjeev> will return ~~~~~~~~~~~~~~~~~~~~ Correct. This is the sanjeev> definition of "blackhole" :) >> the proper ICMP packet saying the destination is unreachable. >> >> Any idea how hard it would be to add this functionality? sanjeev> You need to install a different type of route in the sanjeev> kernel which I believe in Linux is RTN_UNREACHABLE instead sanjeev> of RTN_BLACKHOLE. However, XORP doesn't support such sanjeev> routes. You could try experimenting with such routes by sanjeev> replacing all references (I counted two references) of sanjeev> RTN_BLACKHOLE with RTN_UNREACHABLE inside file sanjeev> fea/data_plane/fibconfig/fibconfig_entry_set_netlink_socket.cc sanjeev> This is not the right solution, but allows you to play with sanjeev> such routes. Just curious, could you describe your sanjeev> particular scenario you have that requires installing sanjeev> RTN_UNREACHABLE routes. >> In the meantime, I'll work on a patch that makes the 'static' sanjeev> priority >> configurable with an environment variable. sanjeev> I should tell you upfront that configurable admin sanjeev> distances in RIB has been on our TODO list for quite some sanjeev> time. However it is not trivial if we want to do it sanjeev> properly by taking into account various considerations. sanjeev> E.g., one of the goals is to be able to configure the sanjeev> priorities (on the fly) inside the XORP config file. sanjeev> Hence, most likely we won't use a solution that is based on sanjeev> setting an environmental variable (or something like this). sanjeev> In other words, don't be offended if your patch is not sanjeev> applied to the CVS. Though, if I were in your position I sanjeev> would use such shortcut in my local XORP copy. Regards, sanjeev> 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 sanjeev> ------------------------------ sanjeev> _______________________________________________ Xorp-users sanjeev> mailing list Xorp-users at xorp.org sanjeev> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users sanjeev> End of Xorp-users Digest, Vol 18, Issue 15 sanjeev> ****************************************** sanjeev> -- Efforts may fail,But don't Fail to make efforts. sanjeev> --------- Sanjeev Kumar Project Engineer CDAC(Formerly sanjeev> NCST) Juhu,Mumbai-400049 sanjeev> _______________________________________________ Xorp-users sanjeev> mailing list Xorp-users at xorp.org sanjeev> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From allan at vyatta.com Mon Sep 17 08:28:24 2007 From: allan at vyatta.com (Allan Leinwand) Date: Mon, 17 Sep 2007 08:28:24 -0700 (PDT) Subject: [Xorp-users] Is it possible to configure the NAT on XORP?? In-Reply-To: <77086.1190041149@tigger.icir.org> Message-ID: <31274389.696721190042904041.JavaMail.root@tahiti.vyatta.com> At the risk of being slapped for a blatant promotion.... Check out www.vyatta.com. We're XORP-based for our routing protocols and have added additional functionality (NAT, VLAN, firewall, VPN) for our community (free) edition. Thanks, allan ----- Original Message ----- From: "Atanu Ghosh" To: "sanjeev kumar" Cc: xorp-users at xorp.org Sent: Monday, September 17, 2007 7:59:09 AM (GMT-0800) America/Los_Angeles Subject: Re: [Xorp-users] Is it possible to configure the NAT on XORP?? Hi, It isn't possible to configure NAT from within XORP at the moment. Atanu. >>>>> "sanjeev" == sanjeev kumar writes: sanjeev> Hi, Is it possible to configure NATing on XORP router.If sanjeev> then please suggest me some steps.. Thanks, Sanjeev -- sanjeev> Efforts may fail,But don't Fail to make efforts. --------- sanjeev> Sanjeev Kumar Project Engineer CDAC(Formerly NCST) sanjeev> Juhu,Mumbai-400049 sanjeev> _______________________________________________ Xorp-users sanjeev> mailing list Xorp-users at xorp.org sanjeev> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users _______________________________________________ Xorp-users mailing list Xorp-users at xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From sommere at gac.edu Mon Sep 17 10:08:50 2007 From: sommere at gac.edu (Ethan Sommer) Date: Mon, 17 Sep 2007 12:08:50 -0500 Subject: [Xorp-users] BGP not advertising our route? Message-ID: <46EEB4A2.6070702@gac.edu> We recently noticed that our BGP setup isn't working correctly. We have two ip connections, one to I2 (which uses BGP) and the other for commodity Internet (which uses a default route and our ISP presumably advertises our route.) We receive all 11000+ I2 routes, and send things out over our I2 connection, but we must not be advertising our route properly because starting when we started using xorp (rather than quagga) people have been routing back to us over I1. I assuming I'm doing something wrong in the BGP section of the config, but I don't know where to start to find the problem. Our IP Our BGP config is as follows: (our ip range is 138.236.0.0/16) bgp { bgp-id: 192.42.152.93 local-as: 17234 peer 192.42.152.94 { local-ip: 192.42.152.93 as: 57 next-hop: 192.42.152.94 /* is this necesary? */ } peer 216.114.193.145 { local-ip: 216.114.193.146 as: 12112 next-hop: 216.114.193.145 /* is this necesary? */ } } We'd appreciate any tips you have, thanks, Ethan -- Ethan Sommer Associate Director of Core Services Gustavus Adolphus College 507-933-7042 sommere at gustavus.edu From atanu at ICSI.Berkeley.EDU Mon Sep 17 13:54:06 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Mon, 17 Sep 2007 13:54:06 -0700 Subject: [Xorp-users] BGP not advertising our route? In-Reply-To: Message from Ethan Sommer of "Mon, 17 Sep 2007 12:08:50 CDT." <46EEB4A2.6070702@gac.edu> Message-ID: <63580.1190062446@tigger.icir.org> Hi, You need to explicity announce your own address space via policy. ---------------------------------------- protocols { static { route 138.236.0.0/16 { next-hop: 216.114.193.145 metric: 1 } } } policy { policy-statement static { term export { from { protocol: "static" } } } } protocols { bgp { export: "static" /* Rest of your config below */ ... } } ---------------------------------------- Something like the above should work. Atanu. >>>>> "Ethan" == Ethan Sommer writes: Ethan> We recently noticed that our BGP setup isn't working correctly. We have Ethan> two ip connections, one to I2 (which uses BGP) and the other for Ethan> commodity Internet (which uses a default route and our ISP presumably Ethan> advertises our route.) Ethan> We receive all 11000+ I2 routes, and send things out over our I2 Ethan> connection, but we must not be advertising our route properly because Ethan> starting when we started using xorp (rather than quagga) people have Ethan> been routing back to us over I1. I assuming I'm doing something wrong in Ethan> the BGP section of the config, but I don't know where to start to find Ethan> the problem. Ethan> Our IP Ethan> Our BGP config is as follows: (our ip range is 138.236.0.0/16) Ethan> bgp { Ethan> bgp-id: 192.42.152.93 Ethan> local-as: 17234 Ethan> peer 192.42.152.94 { Ethan> local-ip: 192.42.152.93 Ethan> as: 57 Ethan> next-hop: 192.42.152.94 /* is this necesary? */ Ethan> } Ethan> peer 216.114.193.145 { Ethan> local-ip: 216.114.193.146 Ethan> as: 12112 Ethan> next-hop: 216.114.193.145 /* is this necesary? */ Ethan> } Ethan> } Ethan> We'd appreciate any tips you have, thanks, Ethan> Ethan Ethan> -- Ethan> Ethan Sommer Ethan> Associate Director of Core Services Ethan> Gustavus Adolphus College Ethan> 507-933-7042 Ethan> sommere at gustavus.edu Ethan> _______________________________________________ Ethan> Xorp-users mailing list Ethan> Xorp-users at xorp.org Ethan> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From hantongs at gmail.com Mon Sep 17 17:50:19 2007 From: hantongs at gmail.com (Hansi) Date: Tue, 18 Sep 2007 08:50:19 +0800 Subject: [Xorp-users] Fwd: Questions on OSPF In-Reply-To: <2f9e317b0709170141h615fe803v75f357e848f8d58a@mail.gmail.com> References: <44891.1189720681@tigger.icir.org> <5f7ec0f76565b4e68ed2457fdf8df3b8@Mail.SpriteLink.NET> <2f9e317b0709140216xff0abd5q62de11cce4fe9c47@mail.gmail.com> <46EA6299.4090607@spritelink.net> <2f9e317b0709170141h615fe803v75f357e848f8d58a@mail.gmail.com> Message-ID: <2f9e317b0709171750k44164cefj523106debd1ef9bd@mail.gmail.com> looping in the mailing list. Thank you. One more question though.. I noticed that before RIP can be configured, the policy parameter must be set first in order for RIP to either advertise static and/or connected routes. Although RIP already sends out udp packets once you configure it, it does not send out its routing table entries not until after a policy is either imported/exported to it. Does this also apply to OSPF? Thanks. Hansi. On 9/14/07, Kristian Larsson wrote: > > Hansi wrote: > > Hello Kristian, Atanu, > > > > Thank you answering for my queries. Let me see if I understood it > clearly. > > > > For link-types: p2p or p2m, it is necessary to explicitly set the > > neighbor parameter in order for the router running OSPF to establish > > adjacency with another router. Broadcast link-types on the other hand > > does not require the neighbor parameter to be explicitly set, am I > > correct? :) > > > > I concur with Atanu that p2p link-types requires the neighbor statement > > to be explicitly stated. My initial configuration does not include > > setting the neighbor parameter, upon invoking "show ospf4 neighbor", > > nothing comes up even though dumps from the network shows OSPF hello > > packets have been multicast already.. The neighbor router only displays > > [upon invoking show ospf4 neighbor] after setting the neighbor parameter > > on both routers. > > Yepp, I was simply wrong. I expected XORP to work like Cisco or Juniper. > > > > Regarding setting router-ID parameters to loopback 127.0.0.1 > > , would it be possible for two routers running OSPF to > > > use the same router-ID? that is both of them are configured to 127.0.0.1 > > ? Since conventionally the router-ID is usually set to > > > the loopback, would it be possible to configure all routers in an OSPF > > network to have the same router-ID of 127.0.0.1 ? > > No, you cannot use 127.0.0.1, at least not on both routers. > Router-id have to be unique within your OSPF domain, one common way of > ensuring this is to use the loopback address that you assign to a > router. Although you are correct that 127.0.0.1 is a loopback adress, > routes normally get one assigned from your address pool. iBGP session > for example are normally established between loopback addresses to not > be dependant upon a specific interface being up. > So assign 172.16.0.1-254 (if your are using private addressing) or > something to your loopbacks as well and you can use those. > > -K > > > On 9/14/07, * kristian at spritelink.net * > < > > kristian at spritelink.net > wrote: > > > > On Thu, 13 Sep 2007 14:58:01 -0700, Atanu Ghosh < > > atanu at icsi.berkeley.edu > > > wrote: > > >>>>>> "kristian" == kristian < kristian at spritelink.net > > > writes: > > > > > > kristian> On Thu, 13 Sep 2007 12:18:42 -0700, Atanu Ghosh > > > kristian> > > wrote: > > > >>>>>>> "kristian" == kristian < kristian at spritelink.net > > > writes: > > > >> > > > kristian> On Thu, 13 Sep 2007 11:51:32 -0700, Atanu Ghosh > > > kristian> < atanu at icsi.berkeley.edu > > > wrote: > > > >> >>>>>>> "Kristian" == Kristian Larsson > > > > > > >> >>>>>>> writes: > > > >> >> > > > Kristian> Hansi wrote: > > > >> >> >> Hello All, > > > >> >> >> > > > >> >> >> I'm currently learning how to configure OSPFv2 on > > two XORP > > > >> >> >> machines just to establish adjacency with one > > another. In a > > > >> p2p >> >> link type, is it still necessary to explicitly > > set the > > > >> >> 'neighbor' >> parameter of each machine before > > adjacency is >> > > > >> established? >> Furthermore, would it be possible to set > > the >> > > > >> router-id to its >> loopback address? instead of say.. the > > ip >> > > > >> address of the >> interface on which ospf will be used? > > > >> >> > > > Kristian> The neighbor command is only useful if you are > using a > > > Kristian> medium on which the routers cannot broadcast and > thus > > > Kristian> cannot discover each other. If you're using > ethernet > > > Kristian> (which I presume from your NIC names) you do not > > have to > > > Kristian> use the neighbor statements. I would advice > configuring > > > Kristian> the interfaces as link-type p2p as this avoids DR > > election > > > Kristian> and unnecessary CPU load. > > > >> >> I am fairly sure that it is necessary to use the > > neighbour >> > > > >> statements. > > > >> > > > kristian> Are you serious? I haven't used the XORP code in > > quite > > > kristian> some time now.. but at least I thought XORP > implemented > > > kristian> the OSPF standard. AFAIK, that includes being able > to > > > kristian> discover neighbors and turn up adjacencies to them. > Is > > > kristian> this not the case? Observe that he is running an > > Ethernet > > > kristian> point-to-point link, ie, it is not a non-broadcast > > medium. > > > kristian> Or are you saying that you can't do link-type p2p > > without > > > kristian> configuring neighbours ? > > > > > > >> If the link-type is set to "broadcast" then the > > neighbours will > > > >> be correctly discovered. If the link-type is set to "p2p" > > > >> (Point-to-point) or "p2m" (Point-to-multipoint) then it is > > > >> necessary to configure the neighbours. It has been argued > > that it > > > >> should not be necessary to configure the neighbours if the > > > > >> routers are connected via a true Point-to-point link, but > > > >> unfortunately even in this case it is necessary to > > configure the > > > >> neighbour. > > > > > > kristian> Okey, that "kinda" makes sense. I apparently forgot > or > > > kristian> missed the conversation on this. What I want to > > configure > > > kristian> with link-type p2p is not whether or not the router > > should > > > kristian> try to broadcast but if it should setup one of > those > > > kristian> virtual router thingys, hehe. I'm not very familiar > > > with > > > kristian> the terminology but (as you know) on a broadcast > medium > > > kristian> you first have a DR selection and all that and then > > you're > > > kristian> gonna run your SPF. Since SPF can't handle the > > concept of > > > kristian> a broadcast medium it creates a "virtual router" to > > > kristian> represent the broadcast medium and connects all > > routers in > > > kristian> that broadcast domain as adjacencies to the virtual > > > kristian> router. When I configure 'isis network > > point-to-point' on > > > kristian> a Cisco router I expect it to not setup one of > these > > > kristian> "virtual routers" in it's SPF topology. And this is > > > kristian> different with XORP? > > > > > > Setting the link type to "broadcast" or "p2p" will both result in > > the > > > hello packets being broadcast, the distinction is that if the > > link-type > > > is set to "p2p" no DR election will be attempted. > > > > Alright, just as I expected. > > > > > The XORP OSPF behaves > > > as specified in the relevant RFCs and interoperates with other > OSPF > > > implementations, the only difference is in configuration of a > "p2p" > > > where we require the neighbour to be specified, which as I > mentioned > > > before should not strictly be necessary. > > > > Okey, not what I expected. Why is it so? Just lack of time to do the > > actual > > implementation (although I don't see how it would actually be more > code > > than it is today) or has there been a policy decision against it? > > > > -K > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070918/db56d7d5/attachment-0001.html From hantongs at gmail.com Mon Sep 17 17:50:43 2007 From: hantongs at gmail.com (Hansi) Date: Tue, 18 Sep 2007 08:50:43 +0800 Subject: [Xorp-users] Fwd: Questions on OSPF In-Reply-To: <2f9e317b0709170202x6f0a4428i8ccd358199540743@mail.gmail.com> References: <44891.1189720681@tigger.icir.org> <5f7ec0f76565b4e68ed2457fdf8df3b8@Mail.SpriteLink.NET> <2f9e317b0709140216xff0abd5q62de11cce4fe9c47@mail.gmail.com> <46EA6299.4090607@spritelink.net> <2f9e317b0709170141h615fe803v75f357e848f8d58a@mail.gmail.com> <2f9e317b0709170202x6f0a4428i8ccd358199540743@mail.gmail.com> Message-ID: <2f9e317b0709171750l651db68cobaf246f044813f3@mail.gmail.com> including the mailing list hmm... seems like after changing my loopback address from 127.0.0.1 to any private address such as 172.16.0.1, this error was encountered: [ 2007/09/17 16:53:31 ERROR xorp_rtrmgr:6201 LIBCOMM +359 comm_sock.c comm_sock_bind4 ] Error binding socket (family = 2, my_addr = 127.0.0.1, my_port = 19999): Cannot assign requested address [ 2007/09/17 16:53:31 ERROR xorp_rtrmgr:6201 RTRMGR +243 main_rtrmgr.cc run ] Cannot assign requested address: a finder may already be running. seems like the rtrmgr binds to 127.0.0.1 only. is there any way to change this? just in case i want my router-id to bind to a loopback interface with a private assigned IP instead of 127.0.0.1? :) On 9/17/07, Hansi wrote: > > Thank you Kristian. One more question though.. I noticed that before RIP > can be configured, the policy parameter must be set first in order for RIP > to either advertise static and/or connected routes. Although RIP already > sends out udp packets once you configure it, it does not send out its > routing table entries not until after a policy is either imported/exported > to it. Does this also apply to OSPF? > > Thanks. > Hansi. > > On 9/14/07, Kristian Larsson < kristian at spritelink.net> wrote: > > > > Hansi wrote: > > > Hello Kristian, Atanu, > > > > > > Thank you answering for my queries. Let me see if I understood it > > clearly. > > > > > > For link-types: p2p or p2m, it is necessary to explicitly set the > > > neighbor parameter in order for the router running OSPF to establish > > > adjacency with another router. Broadcast link-types on the other hand > > > does not require the neighbor parameter to be explicitly set, am I > > > correct? :) > > > > > > I concur with Atanu that p2p link-types requires the neighbor > > statement > > > to be explicitly stated. My initial configuration does not include > > > setting the neighbor parameter, upon invoking "show ospf4 neighbor", > > > nothing comes up even though dumps from the network shows OSPF hello > > > packets have been multicast already.. The neighbor router only > > displays > > > [upon invoking show ospf4 neighbor] after setting the neighbor > > parameter > > > on both routers. > > > > Yepp, I was simply wrong. I expected XORP to work like Cisco or Juniper. > > > > > > > > > Regarding setting router-ID parameters to loopback 127.0.0.1 > > > < http://127.0.0.1>, would it be possible for two routers running OSPF > > to > > > use the same router-ID? that is both of them are configured to > > 127.0.0.1 > > > < http://127.0.0.1>? Since conventionally the router-ID is usually set > > to > > > the loopback, would it be possible to configure all routers in an OSPF > > > network to have the same router-ID of 127.0.0.1 ? > > > > No, you cannot use 127.0.0.1, at least not on both routers. > > Router-id have to be unique within your OSPF domain, one common way of > > ensuring this is to use the loopback address that you assign to a > > router. Although you are correct that 127.0.0.1 is a loopback adress, > > routes normally get one assigned from your address pool. iBGP session > > for example are normally established between loopback addresses to not > > be dependant upon a specific interface being up. > > So assign 172.16.0.1-254 (if your are using private addressing) or > > something to your loopbacks as well and you can use those. > > > > -K > > > > > On 9/14/07, * kristian at spritelink.net * > > < > > > kristian at spritelink.net > wrote: > > > > > > On Thu, 13 Sep 2007 14:58:01 -0700, Atanu Ghosh < > > > atanu at icsi.berkeley.edu > > > > wrote: > > > >>>>>> "kristian" == kristian < kristian at spritelink.net > > > > writes: > > > > > > > > kristian> On Thu, 13 Sep 2007 12:18:42 -0700, Atanu Ghosh > > > > kristian> > > > wrote: > > > > >>>>>>> "kristian" == kristian < kristian at spritelink.net > > > > writes: > > > > >> > > > > kristian> On Thu, 13 Sep 2007 11:51:32 -0700, Atanu Ghosh > > > > kristian> < atanu at icsi.berkeley.edu > > > > wrote: > > > > >> >>>>>>> "Kristian" == Kristian Larsson > > > > > > > > >> >>>>>>> writes: > > > > >> >> > > > > Kristian> Hansi wrote: > > > > >> >> >> Hello All, > > > > >> >> >> > > > > >> >> >> I'm currently learning how to configure OSPFv2 on > > > two XORP > > > > >> >> >> machines just to establish adjacency with one > > > another. In a > > > > >> p2p >> >> link type, is it still necessary to explicitly > > > > > set the > > > > >> >> 'neighbor' >> parameter of each machine before > > > adjacency is >> > > > > >> established? >> Furthermore, would it be possible to > > set > > > the >> > > > > >> router-id to its >> loopback address? instead of say.. > > the > > > ip >> > > > > >> address of the >> interface on which ospf will be used? > > > > >> >> > > > > Kristian> The neighbor command is only useful if you are > > using a > > > > Kristian> medium on which the routers cannot broadcast and > > thus > > > > Kristian> cannot discover each other. If you're using > > ethernet > > > > Kristian> (which I presume from your NIC names) you do not > > > have to > > > > Kristian> use the neighbor statements. I would advice > > configuring > > > > Kristian> the interfaces as link-type p2p as this avoids DR > > > election > > > > Kristian> and unnecessary CPU load. > > > > >> >> I am fairly sure that it is necessary to use the > > > neighbour >> > > > > >> statements. > > > > >> > > > > kristian> Are you serious? I haven't used the XORP code in > > > quite > > > > kristian> some time now.. but at least I thought XORP > > implemented > > > > kristian> the OSPF standard. AFAIK, that includes being > > able to > > > > kristian> discover neighbors and turn up adjacencies to > > them. Is > > > > kristian> this not the case? Observe that he is running an > > > > > Ethernet > > > > kristian> point-to-point link, ie, it is not a > > non-broadcast > > > medium. > > > > kristian> Or are you saying that you can't do link-type p2p > > > without > > > > kristian> configuring neighbours ? > > > > > > > > >> If the link-type is set to "broadcast" then the > > > neighbours will > > > > >> be correctly discovered. If the link-type is set to > > "p2p" > > > > >> (Point-to-point) or "p2m" (Point-to-multipoint) then it > > is > > > > >> necessary to configure the neighbours. It has been > > argued > > > that it > > > > >> should not be necessary to configure the neighbours if > > the > > > > >> routers are connected via a true Point-to-point link, > > but > > > > >> unfortunately even in this case it is necessary to > > > configure the > > > > >> neighbour. > > > > > > > > kristian> Okey, that "kinda" makes sense. I apparently > > forgot or > > > > kristian> missed the conversation on this. What I want to > > > configure > > > > kristian> with link-type p2p is not whether or not the > > router > > > should > > > > kristian> try to broadcast but if it should setup one of > > those > > > > kristian> virtual router thingys, hehe. I'm not very > > familiar > > > with > > > > kristian> the terminology but (as you know) on a broadcast > > medium > > > > kristian> you first have a DR selection and all that and > > then > > > you're > > > > kristian> gonna run your SPF. Since SPF can't handle the > > > concept of > > > > kristian> a broadcast medium it creates a "virtual router" > > to > > > > kristian> represent the broadcast medium and connects all > > > routers in > > > > kristian> that broadcast domain as adjacencies to the > > virtual > > > > kristian> router. When I configure 'isis network > > > point-to-point' on > > > > kristian> a Cisco router I expect it to not setup one of > > these > > > > kristian> "virtual routers" in it's SPF topology. And this > > is > > > > kristian> different with XORP? > > > > > > > > Setting the link type to "broadcast" or "p2p" will both result > > in > > > the > > > > hello packets being broadcast, the distinction is that if the > > > link-type > > > > is set to "p2p" no DR election will be attempted. > > > > > > Alright, just as I expected. > > > > > > > The XORP OSPF behaves > > > > as specified in the relevant RFCs and interoperates with other > > OSPF > > > > implementations, the only difference is in configuration of a > > "p2p" > > > > where we require the neighbour to be specified, which as I > > mentioned > > > > before should not strictly be necessary. > > > > > > Okey, not what I expected. Why is it so? Just lack of time to do > > the > > > actual > > > implementation (although I don't see how it would actually be more > > code > > > than it is today) or has there been a policy decision against it? > > > > > > -K > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070918/4d643398/attachment-0001.html From hengjuen at gmail.com Tue Sep 18 00:08:13 2007 From: hengjuen at gmail.com (HJ) Date: Tue, 18 Sep 2007 15:08:13 +0800 Subject: [Xorp-users] BGP setup Message-ID: <686b91b0709180008nce8c333gaa443db5456d0406@mail.gmail.com> Hi, I try to play around with BGP using with below configuration and test setup, but it seems like i am not able to send a packet over the other side. Can anyone help to access my configuration file below? Thanks in advance. Heng Juen Host (send packet / ping) -------> (Eth0) BGP Router (Eth1) ----------> Receiving PC Host IP:10.0.0.2 BGP Router IP Eth0: 10.0.0.1 BGP Router IP Eth1: 10.10.10.1 Receiving PC IP: 10.10.10.2 Here is my configuration file: restore-original-config-on-shutdown: false interface eth0 { description: "data interface 0" disable: false /* default-system-config */ vif eth0 { disable: false address 10.0.0.1 { prefix-length: 24 broadcast: 10.0.0.255 disable: false } } } interface eth1 { description: "data interface 1" disable: false /* default-system-config */ vif eth1 { disable: false address 10.10.10.1 { prefix-length: 24 broadcast: 10.10.10.255 disable: false } } } } fea { unicast-forwarding4 { disable: false forwarding-entries { retain-on-startup: false retain-on-shutdown: false } } } protocols { bgp { bgp-id: 10.10.10.1 local-as: 65002 peer 10.0.0.1 { local-ip: 10.10.10.1 as: 65000 next-hop: 10.10.10.2 holdtime: 90 local-port: 179 peer-port:179 } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070918/5c49071a/attachment.html From kristian at spritelink.net Tue Sep 18 00:43:50 2007 From: kristian at spritelink.net (Kristian Larsson) Date: Tue, 18 Sep 2007 09:43:50 +0200 Subject: [Xorp-users] Fwd: Questions on OSPF In-Reply-To: <2f9e317b0709171750l651db68cobaf246f044813f3@mail.gmail.com> References: <44891.1189720681@tigger.icir.org> <5f7ec0f76565b4e68ed2457fdf8df3b8@Mail.SpriteLink.NET> <2f9e317b0709140216xff0abd5q62de11cce4fe9c47@mail.gmail.com> <46EA6299.4090607@spritelink.net> <2f9e317b0709170141h615fe803v75f357e848f8d58a@mail.gmail.com> <2f9e317b0709170202x6f0a4428i8ccd358199540743@mail.gmail.com> <2f9e317b0709171750l651db68cobaf246f044813f3@mail.gmail.com> Message-ID: <46EF81B6.1090005@spritelink.net> Hansi wrote: > including the mailing list Sorry for not replying earlier. > hmm... seems like after changing my loopback address from 127.0.0.1 > to any private address such as 172.16.0.1 > , this error was encountered: Yes, XORP uses the loopback interface for IPC communication, it therefore by default, binds to 127.0.0.1. You should not replace 127.0.0.1 with 172.16.0.1 but rather just add 172.16.0.1 Can be accomplished with ip address add 172.16.0.1/32 dev lo on a Linux machine. Kristian. > > [ 2007/09/17 16:53:31 ERROR xorp_rtrmgr:6201 LIBCOMM +359 comm_sock.c > comm_sock_bind4 ] Error binding socket (family = 2, my_addr = 127.0.0.1 > , my_port = 19999): Cannot assign requested address > [ 2007/09/17 16:53:31 ERROR xorp_rtrmgr:6201 RTRMGR +243 main_rtrmgr.cc > run ] Cannot assign requested address: a finder may already be running. > > seems like the rtrmgr binds to 127.0.0.1 only. is > there any way to change this? just in case i want my router-id to bind > to a loopback interface with a private assigned IP instead of 127.0.0.1 > ? :) > > > On 9/17/07, * Hansi* > wrote: > > Thank you Kristian. One more question though.. I noticed that before > RIP can be configured, the policy parameter must be set first in > order for RIP to either advertise static and/or connected routes. > Although RIP already sends out udp packets once you configure it, > it does not send out its routing table entries not until after a > policy is either imported/exported to it. Does this also apply to OSPF? > > Thanks. > Hansi. > > > On 9/14/07, *Kristian Larsson* < kristian at spritelink.net > > wrote: > > Hansi wrote: > > Hello Kristian, Atanu, > > > > Thank you answering for my queries. Let me see if I understood > it clearly. > > > > For link-types: p2p or p2m, it is necessary to explicitly set the > > neighbor parameter in order for the router running OSPF to > establish > > adjacency with another router. Broadcast link-types on the > other hand > > does not require the neighbor parameter to be explicitly set, am I > > correct? :) > > > > I concur with Atanu that p2p link-types requires the neighbor > statement > > to be explicitly stated. My initial configuration does not include > > setting the neighbor parameter, upon invoking "show ospf4 > neighbor", > > nothing comes up even though dumps from the network shows OSPF > hello > > packets have been multicast already.. The neighbor router only > displays > > [upon invoking show ospf4 neighbor] after setting the neighbor > parameter > > on both routers. > > Yepp, I was simply wrong. I expected XORP to work like Cisco or > Juniper. > > > > Regarding setting router-ID parameters to loopback 127.0.0.1 > > > < http://127.0.0.1>, would it be possible for two routers > running OSPF to > > use the same router-ID? that is both of them are configured to > 127.0.0.1 > > < http://127.0.0.1>? Since conventionally the router-ID is > usually set to > > the loopback, would it be possible to configure all routers in > an OSPF > > network to have the same router-ID of 127.0.0.1 > ? > > No, you cannot use 127.0.0.1 , at least not on > both routers. > Router-id have to be unique within your OSPF domain, one common > way of > ensuring this is to use the loopback address that you assign to a > router. Although you are correct that 127.0.0.1 > is a loopback adress, > routes normally get one assigned from your address pool. iBGP > session > for example are normally established between loopback addresses > to not > be dependant upon a specific interface being up. > So assign 172.16.0.1-254 (if your are using private addressing) or > something to your loopbacks as well and you can use those. > > -K > > > On 9/14/07, * kristian at spritelink.net > kristian at spritelink.net >* < > > kristian at spritelink.net > >> wrote: > > > > On Thu, 13 Sep 2007 14:58:01 -0700, Atanu Ghosh < > > atanu at icsi.berkeley.edu > >> > > wrote: > > >>>>>> "kristian" == kristian < kristian at spritelink.net > > > >> writes: > > > > > > kristian> On Thu, 13 Sep 2007 12:18:42 -0700, Atanu > Ghosh > > > kristian> > > >> wrote: > > > >>>>>>> "kristian" == kristian < > kristian at spritelink.net > > >> writes: > > > >> > > > kristian> On Thu, 13 Sep 2007 11:51:32 -0700, Atanu > Ghosh > > > kristian> < atanu at icsi.berkeley.edu > > > >> wrote: > > > >> >>>>>>> "Kristian" == Kristian Larsson > > > >> > > > >> >>>>>>> writes: > > > >> >> > > > Kristian> Hansi wrote: > > > >> >> >> Hello All, > > > >> >> >> > > > >> >> >> I'm currently learning how to configure > OSPFv2 on > > two XORP > > > >> >> >> machines just to establish adjacency with one > > another. In a > > > >> p2p >> >> link type, is it still necessary to > explicitly > > set the > > > >> >> 'neighbor' >> parameter of each machine before > > adjacency is >> > > > >> established? >> Furthermore, would it be > possible to set > > the >> > > > >> router-id to its >> loopback address? instead of > say.. the > > ip >> > > > >> address of the >> interface on which ospf will be > used? > > > >> >> > > > Kristian> The neighbor command is only useful if you > are using a > > > Kristian> medium on which the routers cannot > broadcast and thus > > > Kristian> cannot discover each other. If you're > using ethernet > > > Kristian> (which I presume from your NIC names) you > do not > > have to > > > Kristian> use the neighbor statements. I would > advice configuring > > > Kristian> the interfaces as link-type p2p as this > avoids DR > > election > > > Kristian> and unnecessary CPU load. > > > >> >> I am fairly sure that it is necessary to use the > > neighbour >> > > > >> statements. > > > >> > > > kristian> Are you serious? I haven't used the XORP > code in > > quite > > > kristian> some time now.. but at least I thought > XORP implemented > > > kristian> the OSPF standard. AFAIK, that includes > being able to > > > kristian> discover neighbors and turn up adjacencies > to them. Is > > > kristian> this not the case? Observe that he is > running an > > Ethernet > > > kristian> point-to-point link, ie, it is not a > non-broadcast > > medium. > > > kristian> Or are you saying that you can't do > link-type p2p > > without > > > kristian> configuring neighbours ? > > > > > > >> If the link-type is set to "broadcast" then the > > neighbours will > > > >> be correctly discovered. If the link-type is set > to "p2p" > > > >> (Point-to-point) or "p2m" (Point-to-multipoint) > then it is > > > >> necessary to configure the neighbours. It has > been argued > > that it > > > >> should not be necessary to configure the > neighbours if the > > > >> routers are connected via a true Point-to-point > link, but > > > >> unfortunately even in this case it is necessary to > > configure the > > > >> neighbour. > > > > > > kristian> Okey, that "kinda" makes sense. I > apparently forgot or > > > kristian> missed the conversation on this. What I > want to > > configure > > > kristian> with link-type p2p is not whether or not > the router > > should > > > kristian> try to broadcast but if it should setup > one of those > > > kristian> virtual router thingys, hehe. I'm not very > familiar > > with > > > kristian> the terminology but (as you know) on a > broadcast medium > > > kristian> you first have a DR selection and all that > and then > > you're > > > kristian> gonna run your SPF. Since SPF can't handle the > > concept of > > > kristian> a broadcast medium it creates a "virtual > router" to > > > kristian> represent the broadcast medium and > connects all > > routers in > > > kristian> that broadcast domain as adjacencies to > the virtual > > > kristian> router. When I configure 'isis network > > point-to-point' on > > > kristian> a Cisco router I expect it to not setup > one of these > > > kristian> "virtual routers" in it's SPF topology. > And this is > > > kristian> different with XORP? > > > > > > Setting the link type to "broadcast" or "p2p" will both > result in > > the > > > hello packets being broadcast, the distinction is that > if the > > link-type > > > is set to "p2p" no DR election will be attempted. > > > > Alright, just as I expected. > > > > > The XORP OSPF behaves > > > as specified in the relevant RFCs and interoperates with > other OSPF > > > implementations, the only difference is in configuration > of a "p2p" > > > where we require the neighbour to be specified, which as > I mentioned > > > before should not strictly be necessary. > > > > Okey, not what I expected. Why is it so? Just lack of time > to do the > > actual > > implementation (although I don't see how it would actually > be more code > > than it is today) or has there been a policy decision > against it? > > > > -K > > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From kristian at spritelink.net Tue Sep 18 00:55:57 2007 From: kristian at spritelink.net (Kristian Larsson) Date: Tue, 18 Sep 2007 09:55:57 +0200 Subject: [Xorp-users] Fwd: Questions on OSPF In-Reply-To: <46EF81B6.1090005@spritelink.net> References: <44891.1189720681@tigger.icir.org> <5f7ec0f76565b4e68ed2457fdf8df3b8@Mail.SpriteLink.NET> <2f9e317b0709140216xff0abd5q62de11cce4fe9c47@mail.gmail.com> <46EA6299.4090607@spritelink.net> <2f9e317b0709170141h615fe803v75f357e848f8d58a@mail.gmail.com> <2f9e317b0709170202x6f0a4428i8ccd358199540743@mail.gmail.com> <2f9e317b0709171750l651db68cobaf246f044813f3@mail.gmail.com> <46EF81B6.1090005@spritelink.net> Message-ID: <46EF848D.3020604@spritelink.net> Atanu, could you perhaps add a note about this on the xorp.org site (under the Getting started section). Ie, that using a lo is recommended and how to configure it. Kristian. Kristian Larsson wrote: > Hansi wrote: >> including the mailing list > > Sorry for not replying earlier. > >> hmm... seems like after changing my loopback address from 127.0.0.1 >> to any private address such as 172.16.0.1 >> , this error was encountered: > > Yes, XORP uses the loopback interface for IPC communication, it > therefore by default, binds to 127.0.0.1. You should not replace > 127.0.0.1 with 172.16.0.1 but rather just add 172.16.0.1 > Can be accomplished with > > ip address add 172.16.0.1/32 dev lo > > on a Linux machine. > > Kristian. > > >> >> [ 2007/09/17 16:53:31 ERROR xorp_rtrmgr:6201 LIBCOMM +359 comm_sock.c >> comm_sock_bind4 ] Error binding socket (family = 2, my_addr = >> 127.0.0.1 , my_port = 19999): Cannot assign >> requested address >> [ 2007/09/17 16:53:31 ERROR xorp_rtrmgr:6201 RTRMGR +243 >> main_rtrmgr.cc run ] Cannot assign requested address: a finder may >> already be running. >> >> seems like the rtrmgr binds to 127.0.0.1 only. is >> there any way to change this? just in case i want my router-id to bind >> to a loopback interface with a private assigned IP instead of >> 127.0.0.1 ? :) >> >> >> On 9/17/07, * Hansi* > >> wrote: >> >> Thank you Kristian. One more question though.. I noticed that before >> RIP can be configured, the policy parameter must be set first in >> order for RIP to either advertise static and/or connected routes. >> Although RIP already sends out udp packets once you configure it, >> it does not send out its routing table entries not until after a >> policy is either imported/exported to it. Does this also apply to >> OSPF? >> >> Thanks. >> Hansi. >> >> >> On 9/14/07, *Kristian Larsson* < kristian at spritelink.net >> > wrote: >> >> Hansi wrote: >> > Hello Kristian, Atanu, >> > >> > Thank you answering for my queries. Let me see if I understood >> it clearly. >> > >> > For link-types: p2p or p2m, it is necessary to explicitly >> set the >> > neighbor parameter in order for the router running OSPF to >> establish >> > adjacency with another router. Broadcast link-types on the >> other hand >> > does not require the neighbor parameter to be explicitly >> set, am I >> > correct? :) >> > >> > I concur with Atanu that p2p link-types requires the neighbor >> statement >> > to be explicitly stated. My initial configuration does not >> include >> > setting the neighbor parameter, upon invoking "show ospf4 >> neighbor", >> > nothing comes up even though dumps from the network shows OSPF >> hello >> > packets have been multicast already.. The neighbor router only >> displays >> > [upon invoking show ospf4 neighbor] after setting the neighbor >> parameter >> > on both routers. >> >> Yepp, I was simply wrong. I expected XORP to work like Cisco or >> Juniper. >> >> >> > Regarding setting router-ID parameters to loopback 127.0.0.1 >> >> > < http://127.0.0.1>, would it be possible for two routers >> running OSPF to >> > use the same router-ID? that is both of them are configured to >> 127.0.0.1 >> > < http://127.0.0.1>? Since conventionally the router-ID is >> usually set to >> > the loopback, would it be possible to configure all routers in >> an OSPF >> > network to have the same router-ID of 127.0.0.1 >> ? >> >> No, you cannot use 127.0.0.1 , at least not on >> both routers. >> Router-id have to be unique within your OSPF domain, one common >> way of >> ensuring this is to use the loopback address that you assign to a >> router. Although you are correct that 127.0.0.1 >> is a loopback adress, >> routes normally get one assigned from your address pool. iBGP >> session >> for example are normally established between loopback addresses >> to not >> be dependant upon a specific interface being up. >> So assign 172.16.0.1-254 (if your are using private >> addressing) or >> something to your loopbacks as well and you can use those. >> >> -K >> >> > On 9/14/07, * kristian at spritelink.net >> > kristian at spritelink.net >* < >> > kristian at spritelink.net >> > >> wrote: >> > >> > On Thu, 13 Sep 2007 14:58:01 -0700, Atanu Ghosh < >> > atanu at icsi.berkeley.edu >> > >> >> > wrote: >> > >>>>>> "kristian" == kristian < kristian at spritelink.net >> >> > > >> writes: >> > > >> > > kristian> On Thu, 13 Sep 2007 12:18:42 -0700, Atanu >> Ghosh >> > > kristian> > >> > > >> wrote: >> > > >>>>>>> "kristian" == kristian < >> kristian at spritelink.net >> > > >> writes: >> > > >> >> > > kristian> On Thu, 13 Sep 2007 11:51:32 -0700, Atanu >> Ghosh >> > > kristian> < atanu at icsi.berkeley.edu >> >> > > >> wrote: >> > > >> >>>>>>> "Kristian" == Kristian Larsson >> > >> > >> >> > > >> >>>>>>> writes: >> > > >> >> >> > > Kristian> Hansi wrote: >> > > >> >> >> Hello All, >> > > >> >> >> >> > > >> >> >> I'm currently learning how to configure >> OSPFv2 on >> > two XORP >> > > >> >> >> machines just to establish adjacency >> with one >> > another. In a >> > > >> p2p >> >> link type, is it still necessary to >> explicitly >> > set the >> > > >> >> 'neighbor' >> parameter of each machine before >> > adjacency is >> >> > > >> established? >> Furthermore, would it be >> possible to set >> > the >> >> > > >> router-id to its >> loopback address? instead of >> say.. the >> > ip >> >> > > >> address of the >> interface on which ospf will be >> used? >> > > >> >> >> > > Kristian> The neighbor command is only useful if you >> are using a >> > > Kristian> medium on which the routers cannot >> broadcast and thus >> > > Kristian> cannot discover each other. If you're >> using ethernet >> > > Kristian> (which I presume from your NIC names) you >> do not >> > have to >> > > Kristian> use the neighbor statements. I would >> advice configuring >> > > Kristian> the interfaces as link-type p2p as this >> avoids DR >> > election >> > > Kristian> and unnecessary CPU load. >> > > >> >> I am fairly sure that it is necessary to >> use the >> > neighbour >> >> > > >> statements. >> > > >> >> > > kristian> Are you serious? I haven't used the XORP >> code in >> > quite >> > > kristian> some time now.. but at least I thought >> XORP implemented >> > > kristian> the OSPF standard. AFAIK, that includes >> being able to >> > > kristian> discover neighbors and turn up adjacencies >> to them. Is >> > > kristian> this not the case? Observe that he is >> running an >> > Ethernet >> > > kristian> point-to-point link, ie, it is not a >> non-broadcast >> > medium. >> > > kristian> Or are you saying that you can't do >> link-type p2p >> > without >> > > kristian> configuring neighbours ? >> > > >> > > >> If the link-type is set to "broadcast" then the >> > neighbours will >> > > >> be correctly discovered. If the link-type is set >> to "p2p" >> > > >> (Point-to-point) or "p2m" (Point-to-multipoint) >> then it is >> > > >> necessary to configure the neighbours. It has >> been argued >> > that it >> > > >> should not be necessary to configure the >> neighbours if the >> > > >> routers are connected via a true Point-to-point >> link, but >> > > >> unfortunately even in this case it is >> necessary to >> > configure the >> > > >> neighbour. >> > > >> > > kristian> Okey, that "kinda" makes sense. I >> apparently forgot or >> > > kristian> missed the conversation on this. What I >> want to >> > configure >> > > kristian> with link-type p2p is not whether or not >> the router >> > should >> > > kristian> try to broadcast but if it should setup >> one of those >> > > kristian> virtual router thingys, hehe. I'm not very >> familiar >> > with >> > > kristian> the terminology but (as you know) on a >> broadcast medium >> > > kristian> you first have a DR selection and all that >> and then >> > you're >> > > kristian> gonna run your SPF. Since SPF can't >> handle the >> > concept of >> > > kristian> a broadcast medium it creates a "virtual >> router" to >> > > kristian> represent the broadcast medium and >> connects all >> > routers in >> > > kristian> that broadcast domain as adjacencies to >> the virtual >> > > kristian> router. When I configure 'isis network >> > point-to-point' on >> > > kristian> a Cisco router I expect it to not setup >> one of these >> > > kristian> "virtual routers" in it's SPF topology. >> And this is >> > > kristian> different with XORP? >> > > >> > > Setting the link type to "broadcast" or "p2p" will both >> result in >> > the >> > > hello packets being broadcast, the distinction is that >> if the >> > link-type >> > > is set to "p2p" no DR election will be attempted. >> > >> > Alright, just as I expected. >> > >> > > The XORP OSPF behaves >> > > as specified in the relevant RFCs and interoperates with >> other OSPF >> > > implementations, the only difference is in configuration >> of a "p2p" >> > > where we require the neighbour to be specified, which as >> I mentioned >> > > before should not strictly be necessary. >> > >> > Okey, not what I expected. Why is it so? Just lack of time >> to do the >> > actual >> > implementation (although I don't see how it would actually >> be more code >> > than it is today) or has there been a policy decision >> against it? >> > >> > -K >> > >> > >> >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Xorp-users mailing list >> Xorp-users at xorp.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > From kristian at spritelink.net Tue Sep 18 05:05:38 2007 From: kristian at spritelink.net (Kristian Larsson) Date: Tue, 18 Sep 2007 14:05:38 +0200 Subject: [Xorp-users] Fwd: Questions on OSPF In-Reply-To: <2f9e317b0709180317n25da6facp83875fa890188e9c@mail.gmail.com> References: <44891.1189720681@tigger.icir.org> <5f7ec0f76565b4e68ed2457fdf8df3b8@Mail.SpriteLink.NET> <2f9e317b0709140216xff0abd5q62de11cce4fe9c47@mail.gmail.com> <46EA6299.4090607@spritelink.net> <2f9e317b0709170141h615fe803v75f357e848f8d58a@mail.gmail.com> <2f9e317b0709170202x6f0a4428i8ccd358199540743@mail.gmail.com> <2f9e317b0709171750l651db68cobaf246f044813f3@mail.gmail.com> <46EF81B6.1090005@spritelink.net> <2f9e317b0709180317n25da6facp83875fa890188e9c@mail.gmail.com> Message-ID: <46EFBF12.6090005@spritelink.net> Hansi wrote: > Thanks Kristian. It appears that a loopback interface alias is created > in order to use the loopback interface as the router ID. One more > question though.. does OSPF use policies to announce routes? Is it > necessary to import/export policy in ospf similar to what was done with > RIP before RIP starts announcing its routes? Oh, I don't remember the behaviour of XORP, you'll have to try for yourself, or if anyone else can answer ;) I haven't worked with OSPF in some time now but I believe most implementations only advertise LSAs for those interfaces where you actually talk OSPF and that you have to redistribute connected and static routes. Somewhere in the back of my head I have a memory of Juniper redisting direct routes by default but I'm probably wrong. Just try it out ;) -K > Hansi. > > On 9/18/07, *Kristian Larsson* > wrote: > > Hansi wrote: > > including the mailing list > > Sorry for not replying earlier. > > > hmm... seems like after changing my loopback address from > 127.0.0.1 > > < http://127.0.0.1> to any private address such as 172.16.0.1 > > > , this error was encountered: > > Yes, XORP uses the loopback interface for IPC communication, it > therefore by default, binds to 127.0.0.1 . You > should not replace > 127.0.0.1 with 172.16.0.1 but > rather just add 172.16.0.1 > Can be accomplished with > > ip address add 172.16.0.1/32 dev lo > > on a Linux machine. > > Kristian. > > > > > > [ 2007/09/17 16:53:31 ERROR xorp_rtrmgr:6201 LIBCOMM +359 > comm_sock.c > > comm_sock_bind4 ] Error binding socket (family = 2, my_addr = > 127.0.0.1 > > , my_port = 19999): Cannot assign requested > address > > [ 2007/09/17 16:53:31 ERROR xorp_rtrmgr:6201 RTRMGR +243 > main_rtrmgr.cc > > run ] Cannot assign requested address: a finder may already be > running. > > > > seems like the rtrmgr binds to 127.0.0.1 > only. is > > there any way to change this? just in case i want my router-id to > bind > > to a loopback interface with a private assigned IP instead of > 127.0.0.1 > > ? :) > > > > > > On 9/17/07, * Hansi* >> wrote: > > > > Thank you Kristian. One more question though.. I noticed that > before > > RIP can be configured, the policy parameter must be set first in > > order for RIP to either advertise static and/or connected routes. > > Although RIP already sends out udp packets once you > configure it, > > it does not send out its routing table entries not until after a > > policy is either imported/exported to it. Does this also > apply to OSPF? > > > > Thanks. > > Hansi. > > > > > > On 9/14/07, *Kristian Larsson* < kristian at spritelink.net > > > >> wrote: > > > > Hansi wrote: > > > Hello Kristian, Atanu, > > > > > > Thank you answering for my queries. Let me see if I > understood > > it clearly. > > > > > > For link-types: p2p or p2m, it is necessary to > explicitly set the > > > neighbor parameter in order for the router running OSPF to > > establish > > > adjacency with another router. Broadcast link-types on the > > other hand > > > does not require the neighbor parameter to be > explicitly set, am I > > > correct? :) > > > > > > I concur with Atanu that p2p link-types requires the > neighbor > > statement > > > to be explicitly stated. My initial configuration does > not include > > > setting the neighbor parameter, upon invoking "show ospf4 > > neighbor", > > > nothing comes up even though dumps from the network > shows OSPF > > hello > > > packets have been multicast already.. The neighbor > router only > > displays > > > [upon invoking show ospf4 neighbor] after setting the > neighbor > > parameter > > > on both routers. > > > > Yepp, I was simply wrong. I expected XORP to work like > Cisco or > > Juniper. > > > > > > > Regarding setting router-ID parameters to loopback > 127.0.0.1 > > > > > < http://127.0.0.1>, would it be possible for two routers > > running OSPF to > > > use the same router-ID? that is both of them are > configured to > > 127.0.0.1 > > > > < http://127.0.0.1>? Since conventionally the router-ID is > > usually set to > > > the loopback, would it be possible to configure all > routers in > > an OSPF > > > network to have the same router-ID of 127.0.0.1 > > > < http://127.0.0.1>? > > > > No, you cannot use 127.0.0.1 > , at least not on > > both routers. > > Router-id have to be unique within your OSPF domain, one > common > > way of > > ensuring this is to use the loopback address that you > assign to a > > router. Although you are correct that 127.0.0.1 > > > < http://127.0.0.1> is a loopback adress, > > routes normally get one assigned from your address pool. iBGP > > session > > for example are normally established between loopback > addresses > > to not > > be dependant upon a specific interface being up. > > So assign 172.16.0.1-254 (if your are using private > addressing) or > > something to your loopbacks as well and you can use those. > > > > -K > > > > > On 9/14/07, * kristian at spritelink.net > > > > > kristian at spritelink.net > >>* < > > > kristian at spritelink.net > > > > > > >>> wrote: > > > > > > On Thu, 13 Sep 2007 14:58:01 -0700, Atanu Ghosh < > > > atanu at icsi.berkeley.edu > > > > >>> > > > wrote: > > > >>>>>> "kristian" == kristian < > kristian at spritelink.net > > > > > > > > >>> writes: > > > > > > > > kristian> On Thu, 13 Sep 2007 12:18:42 > -0700, Atanu > > Ghosh > > > > kristian> > > > > > > > > >>> wrote: > > > > >>>>>>> "kristian" == kristian < > > kristian at spritelink.net > > > > > > > >>> writes: > > > > >> > > > > kristian> On Thu, 13 Sep 2007 11:51:32 > -0700, Atanu > > Ghosh > > > > kristian> < atanu at icsi.berkeley.edu > > > > > > > > > >>> wrote: > > > > >> >>>>>>> "Kristian" == Kristian Larsson > > > > > > >>> > > > > >> >>>>>>> writes: > > > > >> >> > > > > Kristian> Hansi wrote: > > > > >> >> >> Hello All, > > > > >> >> >> > > > > >> >> >> I'm currently learning how to > configure > > OSPFv2 on > > > two XORP > > > > >> >> >> machines just to establish > adjacency with one > > > another. In a > > > > >> p2p >> >> link type, is it still > necessary to > > explicitly > > > set the > > > > >> >> 'neighbor' >> parameter of each > machine before > > > adjacency is >> > > > > >> established? >> Furthermore, would it be > > possible to set > > > the >> > > > > >> router-id to its >> loopback address? > instead of > > say.. the > > > ip >> > > > > >> address of the >> interface on which ospf > will be > > used? > > > > >> >> > > > > Kristian> The neighbor command is only > useful if you > > are using a > > > > Kristian> medium on which the routers cannot > > broadcast and thus > > > > Kristian> cannot discover each other. If you're > > using ethernet > > > > Kristian> (which I presume from your NIC > names) you > > do not > > > have to > > > > Kristian> use the neighbor statements. I would > > advice configuring > > > > Kristian> the interfaces as link-type p2p as > this > > avoids DR > > > election > > > > Kristian> and unnecessary CPU load. > > > > >> >> I am fairly sure that it is necessary > to use the > > > neighbour >> > > > > >> statements. > > > > >> > > > > kristian> Are you serious? I haven't used > the XORP > > code in > > > quite > > > > kristian> some time now.. but at least I thought > > XORP implemented > > > > kristian> the OSPF standard. AFAIK, that > includes > > being able to > > > > kristian> discover neighbors and turn up > adjacencies > > to them. Is > > > > kristian> this not the case? Observe that > he is > > running an > > > Ethernet > > > > kristian> point-to-point link, ie, it is not a > > non-broadcast > > > medium. > > > > kristian> Or are you saying that you can't do > > link-type p2p > > > without > > > > kristian> configuring neighbours ? > > > > > > > > >> If the link-type is set to "broadcast" > then the > > > neighbours will > > > > >> be correctly discovered. If the link-type > is set > > to "p2p" > > > > >> (Point-to-point) or "p2m" > (Point-to-multipoint) > > then it is > > > > >> necessary to configure the neighbours. It has > > been argued > > > that it > > > > >> should not be necessary to configure the > > neighbours if the > > > > >> routers are connected via a true > Point-to-point > > link, but > > > > >> unfortunately even in this case it is > necessary to > > > configure the > > > > >> neighbour. > > > > > > > > kristian> Okey, that "kinda" makes sense. I > > apparently forgot or > > > > kristian> missed the conversation on > this. What I > > want to > > > configure > > > > kristian> with link-type p2p is not whether > or not > > the router > > > should > > > > kristian> try to broadcast but if it should > setup > > one of those > > > > kristian> virtual router thingys, hehe. I'm > not very > > familiar > > > with > > > > kristian> the terminology but (as you know) on a > > broadcast medium > > > > kristian> you first have a DR selection and > all that > > and then > > > you're > > > > kristian> gonna run your SPF. Since SPF > can't handle the > > > concept of > > > > kristian> a broadcast medium it creates a > "virtual > > router" to > > > > kristian> represent the broadcast medium and > > connects all > > > routers in > > > > kristian> that broadcast domain as > adjacencies to > > the virtual > > > > kristian> router. When I configure 'isis > network > > > point-to-point' on > > > > kristian> a Cisco router I expect it to not > setup > > one of these > > > > kristian> "virtual routers" in it's SPF > topology. > > And this is > > > > kristian> different with XORP? > > > > > > > > Setting the link type to "broadcast" or "p2p" > will both > > result in > > > the > > > > hello packets being broadcast, the distinction > is that > > if the > > > link-type > > > > is set to "p2p" no DR election will be attempted. > > > > > > Alright, just as I expected. > > > > > > > The XORP OSPF behaves > > > > as specified in the relevant RFCs and > interoperates with > > other OSPF > > > > implementations, the only difference is in > configuration > > of a "p2p" > > > > where we require the neighbour to be specified, > which as > > I mentioned > > > > before should not strictly be necessary. > > > > > > Okey, not what I expected. Why is it so? Just lack > of time > > to do the > > > actual > > > implementation (although I don't see how it would > actually > > be more code > > > than it is today) or has there been a policy decision > > against it? > > > > > > -K > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Xorp-users mailing list > > Xorp-users at xorp.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > From ror.sanjeev at gmail.com Tue Sep 18 05:39:10 2007 From: ror.sanjeev at gmail.com (sanjeev kumar) Date: Tue, 18 Sep 2007 18:09:10 +0530 Subject: [Xorp-users] unable to registor with router manager process?? Message-ID: <477942240709180539g2c205717tf1ccb15e57af2971@mail.gmail.com> Hi, I m not able to run rtrmgr.Could you please go through this: root at isea:/home/sharda/xorp-1.4/rtrmgr# ./xorpsh [ 2007/09/18 18:04:47 WARNING xorpsh RTRMGR ] [Operational Command File: /home/sharda/xorp-1.4/etc/templates/misc.cmds line 29]: Executable file not found: traceroute Failed to register with router manager process 102 Command failed Failed to chown temporary file /tmp/rtrmgr-xorpsh-16748-isea to user_id 0 Thanks & Regards, Sanjeev -- Efforts may fail,But don't Fail to make efforts. --------- Sanjeev Kumar Project Engineer CDAC(Formerly NCST) Juhu,Mumbai-400049 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070918/289eeb31/attachment.html From kristian at spritelink.net Tue Sep 18 05:47:33 2007 From: kristian at spritelink.net (Kristian Larsson) Date: Tue, 18 Sep 2007 14:47:33 +0200 Subject: [Xorp-users] unable to registor with router manager process?? In-Reply-To: <477942240709180539g2c205717tf1ccb15e57af2971@mail.gmail.com> References: <477942240709180539g2c205717tf1ccb15e57af2971@mail.gmail.com> Message-ID: <46EFC8E5.6080904@spritelink.net> sanjeev kumar wrote: > Hi, > > I m not able to run rtrmgr.Could you please go through this: Please start xorp_rtrmgr as root first. -K From kristian at spritelink.net Tue Sep 18 05:50:56 2007 From: kristian at spritelink.net (Kristian Larsson) Date: Tue, 18 Sep 2007 14:50:56 +0200 Subject: [Xorp-users] BGP setup In-Reply-To: <686b91b0709180008nce8c333gaa443db5456d0406@mail.gmail.com> References: <686b91b0709180008nce8c333gaa443db5456d0406@mail.gmail.com> Message-ID: <46EFC9B0.4070900@spritelink.net> HJ wrote: > Hi, > I try to play around with BGP using with below configuration and test > setup, but it seems like i am not able to send a packet over the other > side. Can anyone help to access my configuration file below? > Thanks in advance. > Heng Juen You don't need BGP for this setup. You only need a routing protocol if you have several routers that need to talk to each other. In this case something else is wrong. Are you running on Linux? Perhaps you've forgot to enable ip forwarding (echo 1 > /proc/sys/net/ipv4/ip_forward). Make sure the default gateways of your end hosts are the routers interface addresses. Please provide more details on your setup. -K From hantongs at gmail.com Tue Sep 18 03:17:06 2007 From: hantongs at gmail.com (Hansi) Date: Tue, 18 Sep 2007 18:17:06 +0800 Subject: [Xorp-users] Fwd: Questions on OSPF In-Reply-To: <46EF81B6.1090005@spritelink.net> References: <44891.1189720681@tigger.icir.org> <5f7ec0f76565b4e68ed2457fdf8df3b8@Mail.SpriteLink.NET> <2f9e317b0709140216xff0abd5q62de11cce4fe9c47@mail.gmail.com> <46EA6299.4090607@spritelink.net> <2f9e317b0709170141h615fe803v75f357e848f8d58a@mail.gmail.com> <2f9e317b0709170202x6f0a4428i8ccd358199540743@mail.gmail.com> <2f9e317b0709171750l651db68cobaf246f044813f3@mail.gmail.com> <46EF81B6.1090005@spritelink.net> Message-ID: <2f9e317b0709180317n25da6facp83875fa890188e9c@mail.gmail.com> Thanks Kristian. It appears that a loopback interface alias is created in order to use the loopback interface as the router ID. One more question though.. does OSPF use policies to announce routes? Is it necessary to import/export policy in ospf similar to what was done with RIP before RIP starts announcing its routes? Hansi. On 9/18/07, Kristian Larsson wrote: > > Hansi wrote: > > including the mailing list > > Sorry for not replying earlier. > > > hmm... seems like after changing my loopback address from 127.0.0.1 > > to any private address such as 172.16.0.1 > > , this error was encountered: > > Yes, XORP uses the loopback interface for IPC communication, it > therefore by default, binds to 127.0.0.1. You should not replace > 127.0.0.1 with 172.16.0.1 but rather just add 172.16.0.1 > Can be accomplished with > > ip address add 172.16.0.1/32 dev lo > > on a Linux machine. > > Kristian. > > > > > > [ 2007/09/17 16:53:31 ERROR xorp_rtrmgr:6201 LIBCOMM +359 comm_sock.c > > comm_sock_bind4 ] Error binding socket (family = 2, my_addr = 127.0.0.1 > > , my_port = 19999): Cannot assign requested address > > [ 2007/09/17 16:53:31 ERROR xorp_rtrmgr:6201 RTRMGR +243 main_rtrmgr.cc > > run ] Cannot assign requested address: a finder may already be running. > > > > seems like the rtrmgr binds to 127.0.0.1 only. is > > there any way to change this? just in case i want my router-id to bind > > to a loopback interface with a private assigned IP instead of 127.0.0.1 > > ? :) > > > > > > On 9/17/07, * Hansi* > > wrote: > > > > Thank you Kristian. One more question though.. I noticed that before > > RIP can be configured, the policy parameter must be set first in > > order for RIP to either advertise static and/or connected routes. > > Although RIP already sends out udp packets once you configure it, > > it does not send out its routing table entries not until after a > > policy is either imported/exported to it. Does this also apply to > OSPF? > > > > Thanks. > > Hansi. > > > > > > On 9/14/07, *Kristian Larsson* < kristian at spritelink.net > > > wrote: > > > > Hansi wrote: > > > Hello Kristian, Atanu, > > > > > > Thank you answering for my queries. Let me see if I > understood > > it clearly. > > > > > > For link-types: p2p or p2m, it is necessary to explicitly set > the > > > neighbor parameter in order for the router running OSPF to > > establish > > > adjacency with another router. Broadcast link-types on the > > other hand > > > does not require the neighbor parameter to be explicitly set, > am I > > > correct? :) > > > > > > I concur with Atanu that p2p link-types requires the neighbor > > statement > > > to be explicitly stated. My initial configuration does not > include > > > setting the neighbor parameter, upon invoking "show ospf4 > > neighbor", > > > nothing comes up even though dumps from the network shows > OSPF > > hello > > > packets have been multicast already.. The neighbor router > only > > displays > > > [upon invoking show ospf4 neighbor] after setting the > neighbor > > parameter > > > on both routers. > > > > Yepp, I was simply wrong. I expected XORP to work like Cisco or > > Juniper. > > > > > > > Regarding setting router-ID parameters to loopback 127.0.0.1 > > > > > < http://127.0.0.1>, would it be possible for two routers > > running OSPF to > > > use the same router-ID? that is both of them are configured > to > > 127.0.0.1 > > > < http://127.0.0.1>? Since conventionally the router-ID is > > usually set to > > > the loopback, would it be possible to configure all routers > in > > an OSPF > > > network to have the same router-ID of 127.0.0.1 > > ? > > > > No, you cannot use 127.0.0.1 , at least not on > > both routers. > > Router-id have to be unique within your OSPF domain, one common > > way of > > ensuring this is to use the loopback address that you assign to > a > > router. Although you are correct that 127.0.0.1 > > is a loopback adress, > > routes normally get one assigned from your address pool. iBGP > > session > > for example are normally established between loopback addresses > > to not > > be dependant upon a specific interface being up. > > So assign 172.16.0.1-254 (if your are using private addressing) > or > > something to your loopbacks as well and you can use those. > > > > -K > > > > > On 9/14/07, * kristian at spritelink.net > > > kristian at spritelink.net >* < > > > kristian at spritelink.net > > > >> wrote: > > > > > > On Thu, 13 Sep 2007 14:58:01 -0700, Atanu Ghosh < > > > atanu at icsi.berkeley.edu > > >>> > > > wrote: > > > >>>>>> "kristian" == kristian < kristian at spritelink.net > > > > > > >> writes: > > > > > > > > kristian> On Thu, 13 Sep 2007 12:18:42 -0700, Atanu > > Ghosh > > > > kristian> > > > > > >> wrote: > > > > >>>>>>> "kristian" == kristian < > > kristian at spritelink.net > > > > >> writes: > > > > >> > > > > kristian> On Thu, 13 Sep 2007 11:51:32 -0700, Atanu > > Ghosh > > > > kristian> < atanu at icsi.berkeley.edu > > > > > > >> wrote: > > > > >> >>>>>>> "Kristian" == Kristian Larsson > > > > > >>> > > > > >> >>>>>>> writes: > > > > >> >> > > > > Kristian> Hansi wrote: > > > > >> >> >> Hello All, > > > > >> >> >> > > > > >> >> >> I'm currently learning how to configure > > OSPFv2 on > > > two XORP > > > > >> >> >> machines just to establish adjacency with > one > > > another. In a > > > > >> p2p >> >> link type, is it still necessary to > > explicitly > > > set the > > > > >> >> 'neighbor' >> parameter of each machine > before > > > adjacency is >> > > > > >> established? >> Furthermore, would it be > > possible to set > > > the >> > > > > >> router-id to its >> loopback address? instead of > > say.. the > > > ip >> > > > > >> address of the >> interface on which ospf will > be > > used? > > > > >> >> > > > > Kristian> The neighbor command is only useful if > you > > are using a > > > > Kristian> medium on which the routers cannot > > broadcast and thus > > > > Kristian> cannot discover each other. If you're > > using ethernet > > > > Kristian> (which I presume from your NIC names) you > > do not > > > have to > > > > Kristian> use the neighbor statements. I would > > advice configuring > > > > Kristian> the interfaces as link-type p2p as this > > avoids DR > > > election > > > > Kristian> and unnecessary CPU load. > > > > >> >> I am fairly sure that it is necessary to use > the > > > neighbour >> > > > > >> statements. > > > > >> > > > > kristian> Are you serious? I haven't used the XORP > > code in > > > quite > > > > kristian> some time now.. but at least I thought > > XORP implemented > > > > kristian> the OSPF standard. AFAIK, that includes > > being able to > > > > kristian> discover neighbors and turn up > adjacencies > > to them. Is > > > > kristian> this not the case? Observe that he is > > running an > > > Ethernet > > > > kristian> point-to-point link, ie, it is not a > > non-broadcast > > > medium. > > > > kristian> Or are you saying that you can't do > > link-type p2p > > > without > > > > kristian> configuring neighbours ? > > > > > > > > >> If the link-type is set to "broadcast" then the > > > neighbours will > > > > >> be correctly discovered. If the link-type is set > > to "p2p" > > > > >> (Point-to-point) or "p2m" (Point-to-multipoint) > > then it is > > > > >> necessary to configure the neighbours. It has > > been argued > > > that it > > > > >> should not be necessary to configure the > > neighbours if the > > > > >> routers are connected via a true Point-to-point > > link, but > > > > >> unfortunately even in this case it is necessary > to > > > configure the > > > > >> neighbour. > > > > > > > > kristian> Okey, that "kinda" makes sense. I > > apparently forgot or > > > > kristian> missed the conversation on this. What I > > want to > > > configure > > > > kristian> with link-type p2p is not whether or not > > the router > > > should > > > > kristian> try to broadcast but if it should setup > > one of those > > > > kristian> virtual router thingys, hehe. I'm not > very > > familiar > > > with > > > > kristian> the terminology but (as you know) on a > > broadcast medium > > > > kristian> you first have a DR selection and all > that > > and then > > > you're > > > > kristian> gonna run your SPF. Since SPF can't > handle the > > > concept of > > > > kristian> a broadcast medium it creates a "virtual > > router" to > > > > kristian> represent the broadcast medium and > > connects all > > > routers in > > > > kristian> that broadcast domain as adjacencies to > > the virtual > > > > kristian> router. When I configure 'isis network > > > point-to-point' on > > > > kristian> a Cisco router I expect it to not setup > > one of these > > > > kristian> "virtual routers" in it's SPF topology. > > And this is > > > > kristian> different with XORP? > > > > > > > > Setting the link type to "broadcast" or "p2p" will both > > result in > > > the > > > > hello packets being broadcast, the distinction is that > > if the > > > link-type > > > > is set to "p2p" no DR election will be attempted. > > > > > > Alright, just as I expected. > > > > > > > The XORP OSPF behaves > > > > as specified in the relevant RFCs and interoperates > with > > other OSPF > > > > implementations, the only difference is in > configuration > > of a "p2p" > > > > where we require the neighbour to be specified, which > as > > I mentioned > > > > before should not strictly be necessary. > > > > > > Okey, not what I expected. Why is it so? Just lack of time > > to do the > > > actual > > > implementation (although I don't see how it would actually > > be more code > > > than it is today) or has there been a policy decision > > against it? > > > > > > -K > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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/20070918/41664dee/attachment-0001.html From greearb at candelatech.com Tue Sep 18 10:54:22 2007 From: greearb at candelatech.com (Ben Greear) Date: Tue, 18 Sep 2007 10:54:22 -0700 Subject: [Xorp-users] Multiple xorp instances performance improvements. In-Reply-To: <200709080409.l88493NN095225@possum.icir.org> References: <200709080409.l88493NN095225@possum.icir.org> Message-ID: <46F010CE.2010103@candelatech.com> Pavlin Radoslavov wrote: > I don't think you can apply BPF filters on raw IP sockets. Just FYI, it appears that we *can* apply filters to IP and other sockets, at least on Linux, so I'm adding this to my Xorp TODO list. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Tue Sep 18 11:16:59 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 18 Sep 2007 11:16:59 -0700 Subject: [Xorp-users] Multiple xorp instances performance improvements. In-Reply-To: Message from Ben Greear of "Tue, 18 Sep 2007 10:54:22 PDT." <46F010CE.2010103@candelatech.com> Message-ID: <200709181816.l8IIGxo2040384@possum.icir.org> Ben Greear wrote: > Pavlin Radoslavov wrote: > > > I don't think you can apply BPF filters on raw IP sockets. Sorry, I should have clarified that I was thinking within the pcap(3) framework which internally might be using BPF (depends on the system). > Just FYI, it appears that we *can* apply filters to IP and other > sockets, at least on Linux, so I'm adding this to my Xorp TODO list. For portability reasons we are using pcap(3) (for I/O purpose) instead of the OS-specific BPF. With the PCAP API you get a pcap handler when you use, say, pcap_open_live(). Then all pcap operations are with that handler. If you need a file descriptor associated with that pcap handler, then you use the apprpriate pcap_*() function. Said that, it is pcap itself that gives you the file descriptor hence you cannot apply it on pre-existing socket. Indeed, in your case you wanted to use BPF for different purpose: filtering incoming packets. Again, I am yet to be convinced that this is the bottleneck and is worth the extra complexity, so I wouldn't have it too high on the TODO list. Thanks, 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 Tue Sep 18 11:50:12 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 18 Sep 2007 11:50:12 -0700 Subject: [Xorp-users] Fwd: Questions on OSPF In-Reply-To: Message from Hansi of "Tue, 18 Sep 2007 08:50:43 +0800." <2f9e317b0709171750l651db68cobaf246f044813f3@mail.gmail.com> Message-ID: <200709181850.l8IIoCW3041020@possum.icir.org> Hansi wrote: > including the mailing list > > hmm... seems like after changing my loopback address from 127.0.0.1 to any > private address such as 172.16.0.1, this error was encountered: > > [ 2007/09/17 16:53:31 ERROR xorp_rtrmgr:6201 LIBCOMM +359 comm_sock.c > comm_sock_bind4 ] Error binding socket (family = 2, my_addr = 127.0.0.1, > my_port = 19999): Cannot assign requested address > [ 2007/09/17 16:53:31 ERROR xorp_rtrmgr:6201 RTRMGR +243 main_rtrmgr.cc run > ] Cannot assign requested address: a finder may already be running. > > seems like the rtrmgr binds to 127.0.0.1 only. is there any way to change > this? just in case i want my router-id to bind to a loopback interface with > a private assigned IP instead of 127.0.0.1? :) Yes, XORP uses the default 127.0.0.1 loopback address for in-host XRL IPC communications. You could overwrite that address by setting the XORP_FINDER_SERVER_ADDRESS environmental variable before starting xorp_rtrmgr. Note that you need to set it before starting any other XORP-related program including xorpsh otherwise it won't know know how to connect to the XORP finder. Why do you want to change the loopback address? If it is for the purpose of assigning unique loopback address for configuring OSPF, then you could try to add that unique address as an alias IP address to the loopback interface. On the other hand, I could be wrong, but assigning the unique protocols/ospf4/router-id doesn't require that the value really is an IP address that is assigned to an interface. For management purpose you might want to do that, but strictly speaking it is sufficient to be unique within the OSPF domain. Pavlin > On 9/17/07, Hansi wrote: > > > > Thank you Kristian. One more question though.. I noticed that before RIP > > can be configured, the policy parameter must be set first in order for RIP > > to either advertise static and/or connected routes. Although RIP already > > sends out udp packets once you configure it, it does not send out its > > routing table entries not until after a policy is either imported/exported > > to it. Does this also apply to OSPF? > > > > Thanks. > > Hansi. > > > > On 9/14/07, Kristian Larsson < kristian at spritelink.net> wrote: > > > > > > Hansi wrote: > > > > Hello Kristian, Atanu, > > > > > > > > Thank you answering for my queries. Let me see if I understood it > > > clearly. > > > > > > > > For link-types: p2p or p2m, it is necessary to explicitly set the > > > > neighbor parameter in order for the router running OSPF to establish > > > > adjacency with another router. Broadcast link-types on the other hand > > > > does not require the neighbor parameter to be explicitly set, am I > > > > correct? :) > > > > > > > > I concur with Atanu that p2p link-types requires the neighbor > > > statement > > > > to be explicitly stated. My initial configuration does not include > > > > setting the neighbor parameter, upon invoking "show ospf4 neighbor", > > > > nothing comes up even though dumps from the network shows OSPF hello > > > > packets have been multicast already.. The neighbor router only > > > displays > > > > [upon invoking show ospf4 neighbor] after setting the neighbor > > > parameter > > > > on both routers. > > > > > > Yepp, I was simply wrong. I expected XORP to work like Cisco or Juniper. > > > > > > > > > > > > > Regarding setting router-ID parameters to loopback 127.0.0.1 > > > > < http://127.0.0.1>, would it be possible for two routers running OSPF > > > to > > > > use the same router-ID? that is both of them are configured to > > > 127.0.0.1 > > > > < http://127.0.0.1>? Since conventionally the router-ID is usually set > > > to > > > > the loopback, would it be possible to configure all routers in an OSPF > > > > network to have the same router-ID of 127.0.0.1 ? > > > > > > No, you cannot use 127.0.0.1, at least not on both routers. > > > Router-id have to be unique within your OSPF domain, one common way of > > > ensuring this is to use the loopback address that you assign to a > > > router. Although you are correct that 127.0.0.1 is a loopback adress, > > > routes normally get one assigned from your address pool. iBGP session > > > for example are normally established between loopback addresses to not > > > be dependant upon a specific interface being up. > > > So assign 172.16.0.1-254 (if your are using private addressing) or > > > something to your loopbacks as well and you can use those. > > > > > > -K > > > > > > > On 9/14/07, * kristian at spritelink.net * > > > < > > > > kristian at spritelink.net > wrote: > > > > > > > > On Thu, 13 Sep 2007 14:58:01 -0700, Atanu Ghosh < > > > > atanu at icsi.berkeley.edu > > > > > wrote: > > > > >>>>>> "kristian" == kristian < kristian at spritelink.net > > > > > writes: > > > > > > > > > > kristian> On Thu, 13 Sep 2007 12:18:42 -0700, Atanu Ghosh > > > > > kristian> > > > > wrote: > > > > > >>>>>>> "kristian" == kristian < kristian at spritelink.net > > > > > writes: > > > > > >> > > > > > kristian> On Thu, 13 Sep 2007 11:51:32 -0700, Atanu Ghosh > > > > > kristian> < atanu at icsi.berkeley.edu > > > > > wrote: > > > > > >> >>>>>>> "Kristian" == Kristian Larsson > > > > > > > > > > >> >>>>>>> writes: > > > > > >> >> > > > > > Kristian> Hansi wrote: > > > > > >> >> >> Hello All, > > > > > >> >> >> > > > > > >> >> >> I'm currently learning how to configure OSPFv2 on > > > > two XORP > > > > > >> >> >> machines just to establish adjacency with one > > > > another. In a > > > > > >> p2p >> >> link type, is it still necessary to explicitly > > > > > > > set the > > > > > >> >> 'neighbor' >> parameter of each machine before > > > > adjacency is >> > > > > > >> established? >> Furthermore, would it be possible to > > > set > > > > the >> > > > > > >> router-id to its >> loopback address? instead of say.. > > > the > > > > ip >> > > > > > >> address of the >> interface on which ospf will be used? > > > > > >> >> > > > > > Kristian> The neighbor command is only useful if you are > > > using a > > > > > Kristian> medium on which the routers cannot broadcast and > > > thus > > > > > Kristian> cannot discover each other. If you're using > > > ethernet > > > > > Kristian> (which I presume from your NIC names) you do not > > > > have to > > > > > Kristian> use the neighbor statements. I would advice > > > configuring > > > > > Kristian> the interfaces as link-type p2p as this avoids DR > > > > election > > > > > Kristian> and unnecessary CPU load. > > > > > >> >> I am fairly sure that it is necessary to use the > > > > neighbour >> > > > > > >> statements. > > > > > >> > > > > > kristian> Are you serious? I haven't used the XORP code in > > > > quite > > > > > kristian> some time now.. but at least I thought XORP > > > implemented > > > > > kristian> the OSPF standard. AFAIK, that includes being > > > able to > > > > > kristian> discover neighbors and turn up adjacencies to > > > them. Is > > > > > kristian> this not the case? Observe that he is running an > > > > > > > Ethernet > > > > > kristian> point-to-point link, ie, it is not a > > > non-broadcast > > > > medium. > > > > > kristian> Or are you saying that you can't do link-type p2p > > > > without > > > > > kristian> configuring neighbours ? > > > > > > > > > > >> If the link-type is set to "broadcast" then the > > > > neighbours will > > > > > >> be correctly discovered. If the link-type is set to > > > "p2p" > > > > > >> (Point-to-point) or "p2m" (Point-to-multipoint) then it > > > is > > > > > >> necessary to configure the neighbours. It has been > > > argued > > > > that it > > > > > >> should not be necessary to configure the neighbours if > > > the > > > > > >> routers are connected via a true Point-to-point link, > > > but > > > > > >> unfortunately even in this case it is necessary to > > > > configure the > > > > > >> neighbour. > > > > > > > > > > kristian> Okey, that "kinda" makes sense. I apparently > > > forgot or > > > > > kristian> missed the conversation on this. What I want to > > > > configure > > > > > kristian> with link-type p2p is not whether or not the > > > router > > > > should > > > > > kristian> try to broadcast but if it should setup one of > > > those > > > > > kristian> virtual router thingys, hehe. I'm not very > > > familiar > > > > with > > > > > kristian> the terminology but (as you know) on a broadcast > > > medium > > > > > kristian> you first have a DR selection and all that and > > > then > > > > you're > > > > > kristian> gonna run your SPF. Since SPF can't handle the > > > > concept of > > > > > kristian> a broadcast medium it creates a "virtual router" > > > to > > > > > kristian> represent the broadcast medium and connects all > > > > routers in > > > > > kristian> that broadcast domain as adjacencies to the > > > virtual > > > > > kristian> router. When I configure 'isis network > > > > point-to-point' on > > > > > kristian> a Cisco router I expect it to not setup one of > > > these > > > > > kristian> "virtual routers" in it's SPF topology. And this > > > is > > > > > kristian> different with XORP? > > > > > > > > > > Setting the link type to "broadcast" or "p2p" will both result > > > in > > > > the > > > > > hello packets being broadcast, the distinction is that if the > > > > link-type > > > > > is set to "p2p" no DR election will be attempted. > > > > > > > > Alright, just as I expected. > > > > > > > > > The XORP OSPF behaves > > > > > as specified in the relevant RFCs and interoperates with other > > > OSPF > > > > > implementations, the only difference is in configuration of a > > > "p2p" > > > > > where we require the neighbour to be specified, which as I > > > mentioned > > > > > before should not strictly be necessary. > > > > > > > > Okey, not what I expected. Why is it so? Just lack of time to do > > > the > > > > actual > > > > implementation (although I don't see how it would actually be more > > > code > > > > than it is today) or has there been a policy decision against it? > > > > > > > > -K > > > > > > > > > > > > > > > > > _______________________________________________ > 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 18 11:56:00 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 18 Sep 2007 11:56:00 -0700 Subject: [Xorp-users] BGP setup In-Reply-To: Message from Kristian Larsson of "Tue, 18 Sep 2007 14:50:56 +0200." <46EFC9B0.4070900@spritelink.net> Message-ID: <200709181856.l8IIu0eD041135@possum.icir.org> Kristian Larsson wrote: > HJ wrote: > > Hi, > > I try to play around with BGP using with below configuration and test > > setup, but it seems like i am not able to send a packet over the other > > side. Can anyone help to access my configuration file below? > > Thanks in advance. > > Heng Juen > > You don't need BGP for this setup. You only need a routing protocol if > you have several routers that need to talk to each other. > In this case something else is wrong. > Are you running on Linux? Perhaps you've forgot to enable ip forwarding > (echo 1 > /proc/sys/net/ipv4/ip_forward). Make sure the default gateways If fea/unicast-forwarding4 is enabled (as it appears in the original configuration) then the FEA will take care of enabling the forwarding in the kernel and there is no need for "echo 1 > /proc/sys/net/ipv4/ip_forward". My $0.02 :) Pavlin > of your end hosts are the routers interface addresses. > Please provide more details on your setup. > > -K > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From atanu at ICSI.Berkeley.EDU Tue Sep 18 12:06:31 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Tue, 18 Sep 2007 12:06:31 -0700 Subject: [Xorp-users] Fwd: Questions on OSPF In-Reply-To: Message from Hansi of "Tue, 18 Sep 2007 08:50:19 +0800." <2f9e317b0709171750k44164cefj523106debd1ef9bd@mail.gmail.com> Message-ID: <97264.1190142391@tigger.icir.org> Hi, OSPF will advertise the the subnets for the interfaces on which it is configured. In the case of OSPFv2 one subnet has to be explicitly configured in the config, for OSPFv3 just specifying the interface will advertise all associated subnets (the subnets can also be explicitly configured). Routes from other protocols must be explicity exported using policy. Atanu. >>>>> "Hansi" == Hansi writes: Hansi> looping in the mailing list. Thank you. One more question Hansi> though.. I noticed that before RIP can be configured, the Hansi> policy parameter must be set first in order for RIP to either Hansi> advertise static and/or connected routes. Although RIP Hansi> already sends out udp packets once you configure it, it does Hansi> not send out its routing table entries not until after a Hansi> policy is either imported/exported to it. Does this also Hansi> apply to OSPF? Thanks. Hansi. Hansi> On 9/14/07, Kristian Larsson < kristian at spritelink.net> Hansi> wrote: Hansi> Hansi wrote: >> Hello Kristian, Atanu, >> >> Thank you answering for my queries. Let me see if I understood it Hansi> clearly. >> For link-types: p2p or p2m, it is necessary to explicitly set >> the neighbor parameter in order for the router running OSPF to Hansi> establish >> adjacency with another router. Broadcast link-types on the other Hansi> hand >> does not require the neighbor parameter to be explicitly set, am Hansi> I >> correct? :) >> >> I concur with Atanu that p2p link-types requires the neighbor Hansi> statement >> to be explicitly stated. My initial configuration does not Hansi> include >> setting the neighbor parameter, upon invoking "show ospf4 Hansi> neighbor", >> nothing comes up even though dumps from the network shows OSPF Hansi> hello >> packets have been multicast already.. The neighbor router only Hansi> displays >> [upon invoking show ospf4 neighbor] after setting the neighbor Hansi> parameter >> on both routers. Hansi> Yepp, I was simply wrong. I expected XORP to work like Hansi> Cisco or Juniper. >> Regarding setting router-ID parameters to loopback 127.0.0.1 < >> http://127.0.0.1>, would it be possible for two routers running Hansi> OSPF to >> use the same router-ID? that is both of them are configured to Hansi> 127.0.0.1 >> < http://127.0.0.1>? Since conventionally the router-ID is Hansi> usually set to >> the loopback, would it be possible to configure all routers in an Hansi> OSPF >> network to have the same router-ID of 127.0.0.1 Hansi> ? No, you cannot use 127.0.0.1, at Hansi> least not on both routers. Router-id have to be unique Hansi> within your OSPF domain, one common way of ensuring this is Hansi> to use the loopback address that you assign to a Hansi> router. Although you are correct that 127.0.0.1 is a loopback Hansi> adress, routes normally get one assigned from your address Hansi> pool. iBGP session for example are normally established Hansi> between loopback addresses to not be dependant upon a Hansi> specific interface being up. So assign 172.16.0.1-254 (if Hansi> your are using private addressing) or something to your Hansi> loopbacks as well and you can use those. -K >> On 9/14/07, * kristian at spritelink.net kristian at spritelink.net>* < >> kristian at spritelink.net > wrote: >> >> On Thu, 13 Sep 2007 14:58:01 -0700, Atanu Ghosh < >> atanu at icsi.berkeley.edu > wrote: >> >>>>>> "kristian" == kristian < kristian at spritelink.net >> > writes: >> > >> > kristian> On Thu, 13 Sep 2007 12:18:42 -0700, Atanu Hansi> Ghosh >> > kristian> > atanu at icsi.berkeley.edu>> wrote: > >>>>>>> "kristian" == kristian >> < Hansi> kristian at spritelink.net >> > writes: >> > >> >> > kristian> On Thu, 13 Sep 2007 11:51:32 -0700, Atanu Hansi> Ghosh >> > kristian> < atanu at icsi.berkeley.edu > atanu at icsi.berkeley.edu>> wrote: > >> >>>>>>> "Kristian" == >> Kristian Larsson > kristian at spritelink.net>> > >> >>>>>>> writes: >> > >> >> >> > Kristian> Hansi wrote: > >> >> >> Hello All, >> > >> >> >> >> > >> >> >> I'm currently learning how to configure Hansi> OSPFv2 on >> two XORP > >> >> >> machines just to establish adjacency with one >> another. In a > >> p2p >> >> link type, is it still necessary to Hansi> explicitly >> set the > >> >> 'neighbor' >> parameter of each machine before >> adjacency is >> > >> established? >> Furthermore, would it be >> possible Hansi> to set >> the >> > >> router-id to its >> loopback address? instead of Hansi> say.. the >> ip >> > >> address of the >> interface on which ospf will be Hansi> used? >> > >> >> > Kristian> The neighbor command is only useful if you Hansi> are using a >> > Kristian> medium on which the routers cannot broadcast Hansi> and thus >> > Kristian> cannot discover each other. If you're using Hansi> ethernet >> > Kristian> (which I presume from your NIC names) you do Hansi> not >> have to > Kristian> use the neighbor statements. I would advice Hansi> configuring >> > Kristian> the interfaces as link-type p2p as this Hansi> avoids DR >> election > Kristian> and unnecessary CPU load. > >> >> I am >> fairly sure that it is necessary to use Hansi> the >> neighbour >> > >> statements. >> > >> >> > kristian> Are you serious? I haven't used the XORP Hansi> code in >> quite > kristian> some time now.. but at least I thought XORP Hansi> implemented >> > kristian> the OSPF standard. AFAIK, that includes Hansi> being able to >> > kristian> discover neighbors and turn up adjacencies Hansi> to them. Is >> > kristian> this not the case? Observe that he is Hansi> running an >> Ethernet > kristian> point-to-point link, ie, it is not a Hansi> non-broadcast >> medium. > kristian> Or are you saying that you can't do Hansi> link-type p2p >> without > kristian> configuring neighbours ? >> > >> > >> If the link-type is set to "broadcast" then the neighbours >> will > >> be correctly discovered. If the link-type is set to Hansi> "p2p" >> > >> (Point-to-point) or "p2m" (Point-to-multipoint) Hansi> then it is >> > >> necessary to configure the neighbours. It has been Hansi> argued >> that it > >> should not be necessary to configure the neighbours Hansi> if the >> > >> routers are connected via a true Point-to-point Hansi> link, but >> > >> unfortunately even in this case it is necessary to configure >> the > >> neighbour. >> > >> > kristian> Okey, that "kinda" makes sense. I apparently Hansi> forgot or >> > kristian> missed the conversation on this. What I Hansi> want to >> configure > kristian> with link-type p2p is not whether or not >> the Hansi> router >> should > kristian> try to broadcast but if it should setup one Hansi> of those >> > kristian> virtual router thingys, hehe. I'm not very Hansi> familiar >> with > kristian> the terminology but (as you know) on a Hansi> broadcast medium >> > kristian> you first have a DR selection and all that Hansi> and then >> you're > kristian> gonna run your SPF. Since SPF can't handle Hansi> the >> concept of > kristian> a broadcast medium it creates a "virtual Hansi> router" to >> > kristian> represent the broadcast medium and connects Hansi> all >> routers in > kristian> that broadcast domain as adjacencies to >> the Hansi> virtual >> > kristian> router. When I configure 'isis network >> point-to-point' on > kristian> a Cisco router I expect it to not >> setup one Hansi> of these >> > kristian> "virtual routers" in it's SPF topology. And Hansi> this is >> > kristian> different with XORP? >> > >> > Setting the link type to "broadcast" or "p2p" will both Hansi> result in >> the > hello packets being broadcast, the distinction is that if Hansi> the >> link-type > is set to "p2p" no DR election will be attempted. >> >> Alright, just as I expected. >> >> > The XORP OSPF behaves > as specified in the relevant RFCs and >> interoperates with Hansi> other OSPF >> > implementations, the only difference is in configuration Hansi> of a "p2p" >> > where we require the neighbour to be specified, which as I Hansi> mentioned >> > before should not strictly be necessary. >> >> Okey, not what I expected. Why is it so? Just lack of time to Hansi> do the >> actual implementation (although I don't see how it would actually >> be Hansi> more code >> than it is today) or has there been a policy decision against Hansi> it? >> -K >> >> Hansi> _______________________________________________ Xorp-users Hansi> mailing list Xorp-users at xorp.org Hansi> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From greearb at candelatech.com Tue Sep 18 13:49:36 2007 From: greearb at candelatech.com (Ben Greear) Date: Tue, 18 Sep 2007 13:49:36 -0700 Subject: [Xorp-users] adding/removing interfaces with xorp-cli Message-ID: <46F039E0.3090405@candelatech.com> We tried several things related to dynamically re-configuring xorp. First, we tried using two relatively simple config files, identical except that the IPs for interfaces were different. We tried to load the new file and commit, but we got errors relating to interfaces. Is that supposed to work? Second, we tried manually removing an IP and re-adding it. This only worked if we did a commit between the remove and the add (and another commit at the end of the add). Are we supposed to have to commit to make this work? Finally, we'd like to be able to add/remove interfaces through the CLI w/out restarting Xorp. It seems the CLI has the proper commands, but does anyone know if this actually works? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Tue Sep 18 18:16:21 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 18 Sep 2007 18:16:21 -0700 Subject: [Xorp-users] adding/removing interfaces with xorp-cli In-Reply-To: Message from Ben Greear of "Tue, 18 Sep 2007 13:49:36 PDT." <46F039E0.3090405@candelatech.com> Message-ID: <200709190116.l8J1GLMI048033@possum.icir.org> Ben Greear wrote: > We tried several things related to dynamically re-configuring > xorp. > > First, we tried using two relatively simple config files, identical except that > the IPs for interfaces were different. We tried to load the new file and > commit, but we got errors relating to interfaces. > > Is that supposed to work? Yes. I believe this is related to the second observation below, because loading a new configuration file is compared with the current configuration and results in internal "delete" and "add" operations. > Second, we tried manually removing an IP and re-adding it. This only > worked if we did a commit between the remove and the add (and another > commit at the end of the add). > > Are we supposed to have to commit to make this work? It shouldn't be required. I just tested it on Gentoo 2006.1 with 2.6.20.1 kernel and it worked for me. For reference purpose, here is what I did: Startup config: interfaces { interface eth1 { vif eth1 { address 10.0.0.1 { prefix-length: 8 } } } } delete interfaces interface eth1 vif eth1 address 10.0.0.1 set interfaces interface eth1 vif eth1 address 10.1.0.1 prefix-length 8 commit > Finally, we'd like to be able to add/remove interfaces through the > CLI w/out restarting Xorp. It seems the CLI has the proper commands, > but does anyone know if this actually works? Please be more specific what you mean by "add/remove" interfaces and provide the exact CLI commands you are planning to use. Thanks, 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 hantongs at gmail.com Tue Sep 18 21:04:26 2007 From: hantongs at gmail.com (Hansi) Date: Wed, 19 Sep 2007 12:04:26 +0800 Subject: [Xorp-users] Fwd: Questions on OSPF In-Reply-To: <97264.1190142391@tigger.icir.org> References: <2f9e317b0709171750k44164cefj523106debd1ef9bd@mail.gmail.com> <97264.1190142391@tigger.icir.org> Message-ID: <2f9e317b0709182104q4dbce1f2h8fe6da0648901b5e@mail.gmail.com> Dear All, Thank you for the enlightenment. :) Now, I have a deeper understanding on configuring ospf4 in xorp. Regards, Hansi On 9/19/07, Atanu Ghosh wrote: > > Hi, > > OSPF will advertise the the subnets for the interfaces on which it is > configured. In the case of OSPFv2 one subnet has to be explicitly > configured in the config, for OSPFv3 just specifying the interface will > advertise all associated subnets (the subnets can also be explicitly > configured). > > Routes from other protocols must be explicity exported using policy. > > Atanu. > > >>>>> "Hansi" == Hansi writes: > > Hansi> looping in the mailing list. Thank you. One more question > Hansi> though.. I noticed that before RIP can be configured, the > Hansi> policy parameter must be set first in order for RIP to either > Hansi> advertise static and/or connected routes. Although RIP > Hansi> already sends out udp packets once you configure it, it does > Hansi> not send out its routing table entries not until after a > Hansi> policy is either imported/exported to it. Does this also > Hansi> apply to OSPF? Thanks. Hansi. > > Hansi> On 9/14/07, Kristian Larsson < kristian at spritelink.net> > Hansi> wrote: > > Hansi> Hansi wrote: > >> Hello Kristian, Atanu, > >> > >> Thank you answering for my queries. Let me see if I understood it > Hansi> clearly. > >> For link-types: p2p or p2m, it is necessary to explicitly set > >> the neighbor parameter in order for the router running OSPF to > Hansi> establish > >> adjacency with another router. Broadcast link-types on the other > Hansi> hand > >> does not require the neighbor parameter to be explicitly set, am > Hansi> I > >> correct? :) > >> > >> I concur with Atanu that p2p link-types requires the neighbor > Hansi> statement > >> to be explicitly stated. My initial configuration does not > Hansi> include > >> setting the neighbor parameter, upon invoking "show ospf4 > Hansi> neighbor", > >> nothing comes up even though dumps from the network shows OSPF > Hansi> hello > >> packets have been multicast already.. The neighbor router only > Hansi> displays > >> [upon invoking show ospf4 neighbor] after setting the neighbor > Hansi> parameter > >> on both routers. > Hansi> Yepp, I was simply wrong. I expected XORP to work like > Hansi> Cisco or Juniper. > >> Regarding setting router-ID parameters to loopback 127.0.0.1 < > >> http://127.0.0.1>, would it be possible for two routers running > Hansi> OSPF to > >> use the same router-ID? that is both of them are configured to > Hansi> 127.0.0.1 > >> < http://127.0.0.1>? Since conventionally the router-ID is > Hansi> usually set to > >> the loopback, would it be possible to configure all routers in an > Hansi> OSPF > >> network to have the same router-ID of 127.0.0.1 > Hansi> ? No, you cannot use 127.0.0.1, at > Hansi> least not on both routers. Router-id have to be unique > Hansi> within your OSPF domain, one common way of ensuring this is > Hansi> to use the loopback address that you assign to a > Hansi> router. Although you are correct that 127.0.0.1 is a loopback > Hansi> adress, routes normally get one assigned from your address > Hansi> pool. iBGP session for example are normally established > Hansi> between loopback addresses to not be dependant upon a > Hansi> specific interface being up. So assign 172.16.0.1-254 (if > Hansi> your are using private addressing) or something to your > Hansi> loopbacks as well and you can use those. -K > >> On 9/14/07, * kristian at spritelink.net Hansi> kristian at spritelink.net>* < > >> kristian at spritelink.net > wrote: > >> > >> On Thu, 13 Sep 2007 14:58:01 -0700, Atanu Ghosh < > >> atanu at icsi.berkeley.edu > wrote: > >> >>>>>> "kristian" == kristian < kristian at spritelink.net > >> > writes: > >> > > >> > kristian> On Thu, 13 Sep 2007 12:18:42 -0700, Atanu > Hansi> Ghosh > >> > kristian> >> atanu at icsi.berkeley.edu>> wrote: > >>>>>>> "kristian" == kristian > >> < > Hansi> kristian at spritelink.net > >> > writes: > >> > >> > >> > kristian> On Thu, 13 Sep 2007 11:51:32 -0700, Atanu > Hansi> Ghosh > >> > kristian> < atanu at icsi.berkeley.edu >> atanu at icsi.berkeley.edu>> wrote: > >> >>>>>>> "Kristian" == > >> Kristian Larsson >> kristian at spritelink.net>> > >> >>>>>>> writes: > >> > >> >> > >> > Kristian> Hansi wrote: > >> >> >> Hello All, > >> > >> >> >> > >> > >> >> >> I'm currently learning how to configure > Hansi> OSPFv2 on > >> two XORP > >> >> >> machines just to establish adjacency with one > >> another. In a > >> p2p >> >> link type, is it still necessary to > Hansi> explicitly > >> set the > >> >> 'neighbor' >> parameter of each machine before > >> adjacency is >> > >> established? >> Furthermore, would it be > >> possible > Hansi> to set > >> the >> > >> router-id to its >> loopback address? instead of > Hansi> say.. the > >> ip >> > >> address of the >> interface on which ospf will be > Hansi> used? > >> > >> >> > Kristian> The neighbor command is only useful if you > Hansi> are using a > >> > Kristian> medium on which the routers cannot broadcast > Hansi> and thus > >> > Kristian> cannot discover each other. If you're using > Hansi> ethernet > >> > Kristian> (which I presume from your NIC names) you do > Hansi> not > >> have to > Kristian> use the neighbor statements. I would advice > Hansi> configuring > >> > Kristian> the interfaces as link-type p2p as this > Hansi> avoids DR > >> election > Kristian> and unnecessary CPU load. > >> >> I am > >> fairly sure that it is necessary to use > Hansi> the > >> neighbour >> > >> statements. > >> > >> > >> > kristian> Are you serious? I haven't used the XORP > Hansi> code in > >> quite > kristian> some time now.. but at least I thought XORP > Hansi> implemented > >> > kristian> the OSPF standard. AFAIK, that includes > Hansi> being able to > >> > kristian> discover neighbors and turn up adjacencies > Hansi> to them. Is > >> > kristian> this not the case? Observe that he is > Hansi> running an > >> Ethernet > kristian> point-to-point link, ie, it is not a > Hansi> non-broadcast > >> medium. > kristian> Or are you saying that you can't do > Hansi> link-type p2p > >> without > kristian> configuring neighbours ? > >> > > >> > >> If the link-type is set to "broadcast" then the neighbours > >> will > >> be correctly discovered. If the link-type is set to > Hansi> "p2p" > >> > >> (Point-to-point) or "p2m" (Point-to-multipoint) > Hansi> then it is > >> > >> necessary to configure the neighbours. It has been > Hansi> argued > >> that it > >> should not be necessary to configure the neighbours > Hansi> if the > >> > >> routers are connected via a true Point-to-point > Hansi> link, but > >> > >> unfortunately even in this case it is necessary to configure > >> the > >> neighbour. > >> > > >> > kristian> Okey, that "kinda" makes sense. I apparently > Hansi> forgot or > >> > kristian> missed the conversation on this. What I > Hansi> want to > >> configure > kristian> with link-type p2p is not whether or not > >> the > Hansi> router > >> should > kristian> try to broadcast but if it should setup one > Hansi> of those > >> > kristian> virtual router thingys, hehe. I'm not very > Hansi> familiar > >> with > kristian> the terminology but (as you know) on a > Hansi> broadcast medium > >> > kristian> you first have a DR selection and all that > Hansi> and then > >> you're > kristian> gonna run your SPF. Since SPF can't handle > Hansi> the > >> concept of > kristian> a broadcast medium it creates a "virtual > Hansi> router" to > >> > kristian> represent the broadcast medium and connects > Hansi> all > >> routers in > kristian> that broadcast domain as adjacencies to > >> the > Hansi> virtual > >> > kristian> router. When I configure 'isis network > >> point-to-point' on > kristian> a Cisco router I expect it to not > >> setup one > Hansi> of these > >> > kristian> "virtual routers" in it's SPF topology. And > Hansi> this is > >> > kristian> different with XORP? > >> > > >> > Setting the link type to "broadcast" or "p2p" will both > Hansi> result in > >> the > hello packets being broadcast, the distinction is that if > Hansi> the > >> link-type > is set to "p2p" no DR election will be attempted. > >> > >> Alright, just as I expected. > >> > >> > The XORP OSPF behaves > as specified in the relevant RFCs and > >> interoperates with > Hansi> other OSPF > >> > implementations, the only difference is in configuration > Hansi> of a "p2p" > >> > where we require the neighbour to be specified, which as I > Hansi> mentioned > >> > before should not strictly be necessary. > >> > >> Okey, not what I expected. Why is it so? Just lack of time to > Hansi> do the > >> actual implementation (although I don't see how it would actually > >> be > Hansi> more code > >> than it is today) or has there been a policy decision against > Hansi> it? > >> -K > >> > >> > Hansi> _______________________________________________ Xorp-users > Hansi> mailing list Xorp-users at xorp.org > Hansi> 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/20070919/5ac080b7/attachment-0001.html From hantongs at gmail.com Tue Sep 18 23:32:13 2007 From: hantongs at gmail.com (Hansi) Date: Wed, 19 Sep 2007 14:32:13 +0800 Subject: [Xorp-users] Fwd: Questions on OSPF In-Reply-To: <97264.1190142391@tigger.icir.org> References: <2f9e317b0709171750k44164cefj523106debd1ef9bd@mail.gmail.com> <97264.1190142391@tigger.icir.org> Message-ID: <2f9e317b0709182332k38aee193teb5e73561c55f0a1@mail.gmail.com> Hello Atanu, How about static routes and connected routes? Do I still need to explicitly use policies in order for them to be announced? What I'm seeing on a network dump is only indeed the subnet for the interfaces on w/c OSPF is configured. I also want OSPF to announce static and connected routes just like what is done w/ RIP when policy static and connected is exported, can this be possible? Thanks Hansi. On 9/19/07, Atanu Ghosh wrote: > > Hi, > > OSPF will advertise the the subnets for the interfaces on which it is > configured. In the case of OSPFv2 one subnet has to be explicitly > configured in the config, for OSPFv3 just specifying the interface will > advertise all associated subnets (the subnets can also be explicitly > configured). > > Routes from other protocols must be explicity exported using policy. > > Atanu. > > >>>>> "Hansi" == Hansi writes: > > Hansi> looping in the mailing list. Thank you. One more question > Hansi> though.. I noticed that before RIP can be configured, the > Hansi> policy parameter must be set first in order for RIP to either > Hansi> advertise static and/or connected routes. Although RIP > Hansi> already sends out udp packets once you configure it, it does > Hansi> not send out its routing table entries not until after a > Hansi> policy is either imported/exported to it. Does this also > Hansi> apply to OSPF? Thanks. Hansi. > > Hansi> On 9/14/07, Kristian Larsson < kristian at spritelink.net> > Hansi> wrote: > > Hansi> Hansi wrote: > >> Hello Kristian, Atanu, > >> > >> Thank you answering for my queries. Let me see if I understood it > Hansi> clearly. > >> For link-types: p2p or p2m, it is necessary to explicitly set > >> the neighbor parameter in order for the router running OSPF to > Hansi> establish > >> adjacency with another router. Broadcast link-types on the other > Hansi> hand > >> does not require the neighbor parameter to be explicitly set, am > Hansi> I > >> correct? :) > >> > >> I concur with Atanu that p2p link-types requires the neighbor > Hansi> statement > >> to be explicitly stated. My initial configuration does not > Hansi> include > >> setting the neighbor parameter, upon invoking "show ospf4 > Hansi> neighbor", > >> nothing comes up even though dumps from the network shows OSPF > Hansi> hello > >> packets have been multicast already.. The neighbor router only > Hansi> displays > >> [upon invoking show ospf4 neighbor] after setting the neighbor > Hansi> parameter > >> on both routers. > Hansi> Yepp, I was simply wrong. I expected XORP to work like > Hansi> Cisco or Juniper. > >> Regarding setting router-ID parameters to loopback 127.0.0.1 < > >> http://127.0.0.1>, would it be possible for two routers running > Hansi> OSPF to > >> use the same router-ID? that is both of them are configured to > Hansi> 127.0.0.1 > >> < http://127.0.0.1>? Since conventionally the router-ID is > Hansi> usually set to > >> the loopback, would it be possible to configure all routers in an > Hansi> OSPF > >> network to have the same router-ID of 127.0.0.1 > Hansi> ? No, you cannot use 127.0.0.1, at > Hansi> least not on both routers. Router-id have to be unique > Hansi> within your OSPF domain, one common way of ensuring this is > Hansi> to use the loopback address that you assign to a > Hansi> router. Although you are correct that 127.0.0.1 is a loopback > Hansi> adress, routes normally get one assigned from your address > Hansi> pool. iBGP session for example are normally established > Hansi> between loopback addresses to not be dependant upon a > Hansi> specific interface being up. So assign 172.16.0.1-254 (if > Hansi> your are using private addressing) or something to your > Hansi> loopbacks as well and you can use those. -K > >> On 9/14/07, * kristian at spritelink.net Hansi> kristian at spritelink.net>* < > >> kristian at spritelink.net > wrote: > >> > >> On Thu, 13 Sep 2007 14:58:01 -0700, Atanu Ghosh < > >> atanu at icsi.berkeley.edu > wrote: > >> >>>>>> "kristian" == kristian < kristian at spritelink.net > >> > writes: > >> > > >> > kristian> On Thu, 13 Sep 2007 12:18:42 -0700, Atanu > Hansi> Ghosh > >> > kristian> >> atanu at icsi.berkeley.edu>> wrote: > >>>>>>> "kristian" == kristian > >> < > Hansi> kristian at spritelink.net > >> > writes: > >> > >> > >> > kristian> On Thu, 13 Sep 2007 11:51:32 -0700, Atanu > Hansi> Ghosh > >> > kristian> < atanu at icsi.berkeley.edu >> atanu at icsi.berkeley.edu>> wrote: > >> >>>>>>> "Kristian" == > >> Kristian Larsson >> kristian at spritelink.net>> > >> >>>>>>> writes: > >> > >> >> > >> > Kristian> Hansi wrote: > >> >> >> Hello All, > >> > >> >> >> > >> > >> >> >> I'm currently learning how to configure > Hansi> OSPFv2 on > >> two XORP > >> >> >> machines just to establish adjacency with one > >> another. In a > >> p2p >> >> link type, is it still necessary to > Hansi> explicitly > >> set the > >> >> 'neighbor' >> parameter of each machine before > >> adjacency is >> > >> established? >> Furthermore, would it be > >> possible > Hansi> to set > >> the >> > >> router-id to its >> loopback address? instead of > Hansi> say.. the > >> ip >> > >> address of the >> interface on which ospf will be > Hansi> used? > >> > >> >> > Kristian> The neighbor command is only useful if you > Hansi> are using a > >> > Kristian> medium on which the routers cannot broadcast > Hansi> and thus > >> > Kristian> cannot discover each other. If you're using > Hansi> ethernet > >> > Kristian> (which I presume from your NIC names) you do > Hansi> not > >> have to > Kristian> use the neighbor statements. I would advice > Hansi> configuring > >> > Kristian> the interfaces as link-type p2p as this > Hansi> avoids DR > >> election > Kristian> and unnecessary CPU load. > >> >> I am > >> fairly sure that it is necessary to use > Hansi> the > >> neighbour >> > >> statements. > >> > >> > >> > kristian> Are you serious? I haven't used the XORP > Hansi> code in > >> quite > kristian> some time now.. but at least I thought XORP > Hansi> implemented > >> > kristian> the OSPF standard. AFAIK, that includes > Hansi> being able to > >> > kristian> discover neighbors and turn up adjacencies > Hansi> to them. Is > >> > kristian> this not the case? Observe that he is > Hansi> running an > >> Ethernet > kristian> point-to-point link, ie, it is not a > Hansi> non-broadcast > >> medium. > kristian> Or are you saying that you can't do > Hansi> link-type p2p > >> without > kristian> configuring neighbours ? > >> > > >> > >> If the link-type is set to "broadcast" then the neighbours > >> will > >> be correctly discovered. If the link-type is set to > Hansi> "p2p" > >> > >> (Point-to-point) or "p2m" (Point-to-multipoint) > Hansi> then it is > >> > >> necessary to configure the neighbours. It has been > Hansi> argued > >> that it > >> should not be necessary to configure the neighbours > Hansi> if the > >> > >> routers are connected via a true Point-to-point > Hansi> link, but > >> > >> unfortunately even in this case it is necessary to configure > >> the > >> neighbour. > >> > > >> > kristian> Okey, that "kinda" makes sense. I apparently > Hansi> forgot or > >> > kristian> missed the conversation on this. What I > Hansi> want to > >> configure > kristian> with link-type p2p is not whether or not > >> the > Hansi> router > >> should > kristian> try to broadcast but if it should setup one > Hansi> of those > >> > kristian> virtual router thingys, hehe. I'm not very > Hansi> familiar > >> with > kristian> the terminology but (as you know) on a > Hansi> broadcast medium > >> > kristian> you first have a DR selection and all that > Hansi> and then > >> you're > kristian> gonna run your SPF. Since SPF can't handle > Hansi> the > >> concept of > kristian> a broadcast medium it creates a "virtual > Hansi> router" to > >> > kristian> represent the broadcast medium and connects > Hansi> all > >> routers in > kristian> that broadcast domain as adjacencies to > >> the > Hansi> virtual > >> > kristian> router. When I configure 'isis network > >> point-to-point' on > kristian> a Cisco router I expect it to not > >> setup one > Hansi> of these > >> > kristian> "virtual routers" in it's SPF topology. And > Hansi> this is > >> > kristian> different with XORP? > >> > > >> > Setting the link type to "broadcast" or "p2p" will both > Hansi> result in > >> the > hello packets being broadcast, the distinction is that if > Hansi> the > >> link-type > is set to "p2p" no DR election will be attempted. > >> > >> Alright, just as I expected. > >> > >> > The XORP OSPF behaves > as specified in the relevant RFCs and > >> interoperates with > Hansi> other OSPF > >> > implementations, the only difference is in configuration > Hansi> of a "p2p" > >> > where we require the neighbour to be specified, which as I > Hansi> mentioned > >> > before should not strictly be necessary. > >> > >> Okey, not what I expected. Why is it so? Just lack of time to > Hansi> do the > >> actual implementation (although I don't see how it would actually > >> be > Hansi> more code > >> than it is today) or has there been a policy decision against > Hansi> it? > >> -K > >> > >> > Hansi> _______________________________________________ Xorp-users > Hansi> mailing list Xorp-users at xorp.org > Hansi> 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/20070919/c5c7abe4/attachment-0001.html From kristian at spritelink.net Wed Sep 19 01:05:29 2007 From: kristian at spritelink.net (Kristian Larsson) Date: Wed, 19 Sep 2007 10:05:29 +0200 Subject: [Xorp-users] Fwd: Questions on OSPF In-Reply-To: <2f9e317b0709182332k38aee193teb5e73561c55f0a1@mail.gmail.com> References: <2f9e317b0709171750k44164cefj523106debd1ef9bd@mail.gmail.com> <97264.1190142391@tigger.icir.org> <2f9e317b0709182332k38aee193teb5e73561c55f0a1@mail.gmail.com> Message-ID: <46F0D849.4020109@spritelink.net> Hansi wrote: > Hello Atanu, > > How about static routes and connected routes? Do I still need to > explicitly use policies in order for them to be announced? What I'm > seeing on a network dump is only indeed the subnet for the interfaces on > w/c OSPF is configured. I also want OSPF to announce static and > connected routes just like what is done w/ RIP when policy static and > connected is exported, can this be possible? Yes, use a policy, just like with RIP. Kristian. > On 9/19/07, *Atanu Ghosh* > wrote: > > Hi, > > OSPF will advertise the the subnets for the interfaces on which it is > configured. In the case of OSPFv2 one subnet has to be explicitly > configured in the config, for OSPFv3 just specifying the interface will > advertise all associated subnets (the subnets can also be explicitly > configured). > > Routes from other protocols must be explicity exported using policy. > > Atanu. > > >>>>> "Hansi" == Hansi < hantongs at gmail.com > > writes: > > Hansi> looping in the mailing list. Thank you. One more question > Hansi> though.. I noticed that before RIP can be configured, the > Hansi> policy parameter must be set first in order for RIP to either > Hansi> advertise static and/or connected routes. Although RIP > Hansi> already sends out udp packets once you configure it, it does > Hansi> not send out its routing table entries not until after a > Hansi> policy is either imported/exported to it. Does this also > Hansi> apply to OSPF? Thanks. Hansi. > > Hansi> On 9/14/07, Kristian Larsson < kristian at spritelink.net > > > Hansi> wrote: > > Hansi> Hansi wrote: > >> Hello Kristian, Atanu, > >> > >> Thank you answering for my queries. Let me see if I > understood it > Hansi> clearly. > >> For link-types: p2p or p2m, it is necessary to explicitly set > >> the neighbor parameter in order for the router running OSPF to > Hansi> establish > >> adjacency with another router. Broadcast link-types on the other > Hansi> hand > >> does not require the neighbor parameter to be explicitly set, am > Hansi> I > >> correct? :) > >> > >> I concur with Atanu that p2p link-types requires the neighbor > Hansi> statement > >> to be explicitly stated. My initial configuration does not > Hansi> include > >> setting the neighbor parameter, upon invoking "show ospf4 > Hansi> neighbor", > >> nothing comes up even though dumps from the network shows OSPF > Hansi> hello > >> packets have been multicast already.. The neighbor router only > Hansi> displays > >> [upon invoking show ospf4 neighbor] after setting the neighbor > Hansi> parameter > >> on both routers. > Hansi> Yepp, I was simply wrong. I expected XORP to work like > Hansi> Cisco or Juniper. > >> Regarding setting router-ID parameters to loopback 127.0.0.1 > < > >> http://127.0.0.1>, would it be possible for two routers running > Hansi> OSPF to > >> use the same router-ID? that is both of them are configured to > Hansi> 127.0.0.1 > >> < http://127.0.0.1>? Since conventionally the router-ID is > Hansi> usually set to > >> the loopback, would it be possible to configure all routers > in an > Hansi> OSPF > >> network to have the same router-ID of 127.0.0.1 > > Hansi> ? No, you cannot use 127.0.0.1 > , at > Hansi> least not on both routers. Router-id have to be unique > Hansi> within your OSPF domain, one common way of ensuring this is > Hansi> to use the loopback address that you assign to a > Hansi> router. Although you are correct that 127.0.0.1 > is a loopback > Hansi> adress, routes normally get one assigned from your address > Hansi> pool. iBGP session for example are normally established > Hansi> between loopback addresses to not be dependant upon a > Hansi> specific interface being up. So assign 172.16.0.1-254 (if > Hansi> your are using private addressing) or something to your > Hansi> loopbacks as well and you can use those. -K > >> On 9/14/07, * kristian at spritelink.net > Hansi> kristian at spritelink.net > >* < > >> kristian at spritelink.net > >> > wrote: > >> > >> On Thu, 13 Sep 2007 14:58:01 -0700, Atanu Ghosh < > >> atanu at icsi.berkeley.edu > >> > wrote: > >> >>>>>> "kristian" == kristian < kristian at spritelink.net > > >> >> writes: > >> > > >> > kristian> On Thu, 13 Sep 2007 12:18:42 -0700, Atanu > Hansi> Ghosh > >> > kristian> < atanu at icsi.berkeley.edu > >> atanu at icsi.berkeley.edu >> > wrote: > >>>>>>> "kristian" == kristian > >> < > Hansi> kristian at spritelink.net > >> >> writes: > >> > >> > >> > kristian> On Thu, 13 Sep 2007 11:51:32 -0700, Atanu > Hansi> Ghosh > >> > kristian> < atanu at icsi.berkeley.edu > >> atanu at icsi.berkeley.edu >> > wrote: > >> >>>>>>> "Kristian" == > >> Kristian Larsson < kristian at spritelink.net > >> kristian at spritelink.net >> > > >> >>>>>>> writes: > >> > >> >> > >> > Kristian> Hansi wrote: > >> >> >> Hello All, > >> > >> >> >> > >> > >> >> >> I'm currently learning how to configure > Hansi> OSPFv2 on > >> two XORP > >> >> >> machines just to establish adjacency with one > >> another. In a > >> p2p >> >> link type, is it still necessary to > Hansi> explicitly > >> set the > >> >> 'neighbor' >> parameter of each machine before > >> adjacency is >> > >> established? >> Furthermore, would it be > >> possible > Hansi> to set > >> the >> > >> router-id to its >> loopback address? instead of > Hansi> say.. the > >> ip >> > >> address of the >> interface on which ospf will be > Hansi> used? > >> > >> >> > Kristian> The neighbor command is only useful if you > Hansi> are using a > >> > Kristian> medium on which the routers cannot broadcast > Hansi> and thus > >> > Kristian> cannot discover each other. If you're using > Hansi> ethernet > >> > Kristian> (which I presume from your NIC names) you do > Hansi> not > >> have to > Kristian> use the neighbor statements. I would advice > Hansi> configuring > >> > Kristian> the interfaces as link-type p2p as this > Hansi> avoids DR > >> election > Kristian> and unnecessary CPU load. > >> >> I am > >> fairly sure that it is necessary to use > Hansi> the > >> neighbour >> > >> statements. > >> > >> > >> > kristian> Are you serious? I haven't used the XORP > Hansi> code in > >> quite > kristian> some time now.. but at least I thought XORP > Hansi> implemented > >> > kristian> the OSPF standard. AFAIK, that includes > Hansi> being able to > >> > kristian> discover neighbors and turn up adjacencies > Hansi> to them. Is > >> > kristian> this not the case? Observe that he is > Hansi> running an > >> Ethernet > kristian> point-to-point link, ie, it is not a > Hansi> non-broadcast > >> medium. > kristian> Or are you saying that you can't do > Hansi> link-type p2p > >> without > kristian> configuring neighbours ? > >> > > >> > >> If the link-type is set to "broadcast" then the neighbours > >> will > >> be correctly discovered. If the link-type is set to > Hansi> "p2p" > >> > >> (Point-to-point) or "p2m" (Point-to-multipoint) > Hansi> then it is > >> > >> necessary to configure the neighbours. It has been > Hansi> argued > >> that it > >> should not be necessary to configure the neighbours > Hansi> if the > >> > >> routers are connected via a true Point-to-point > Hansi> link, but > >> > >> unfortunately even in this case it is necessary to configure > >> the > >> neighbour. > >> > > >> > kristian> Okey, that "kinda" makes sense. I apparently > Hansi> forgot or > >> > kristian> missed the conversation on this. What I > Hansi> want to > >> configure > kristian> with link-type p2p is not whether or not > >> the > Hansi> router > >> should > kristian> try to broadcast but if it should setup one > Hansi> of those > >> > kristian> virtual router thingys, hehe. I'm not very > Hansi> familiar > >> with > kristian> the terminology but (as you know) on a > Hansi> broadcast medium > >> > kristian> you first have a DR selection and all that > Hansi> and then > >> you're > kristian> gonna run your SPF. Since SPF can't handle > Hansi> the > >> concept of > kristian> a broadcast medium it creates a "virtual > Hansi> router" to > >> > kristian> represent the broadcast medium and connects > Hansi> all > >> routers in > kristian> that broadcast domain as adjacencies to > >> the > Hansi> virtual > >> > kristian> router. When I configure 'isis network > >> point-to-point' on > kristian> a Cisco router I expect it to not > >> setup one > Hansi> of these > >> > kristian> "virtual routers" in it's SPF topology. And > Hansi> this is > >> > kristian> different with XORP? > >> > > >> > Setting the link type to "broadcast" or "p2p" will both > Hansi> result in > >> the > hello packets being broadcast, the distinction is that if > Hansi> the > >> link-type > is set to "p2p" no DR election will be attempted. > >> > >> Alright, just as I expected. > >> > >> > The XORP OSPF behaves > as specified in the relevant RFCs and > >> interoperates with > Hansi> other OSPF > >> > implementations, the only difference is in configuration > Hansi> of a "p2p" > >> > where we require the neighbour to be specified, which as I > Hansi> mentioned > >> > before should not strictly be necessary. > >> > >> Okey, not what I expected. Why is it so? Just lack of time to > Hansi> do the > >> actual implementation (although I don't see how it would actually > >> be > Hansi> more code > >> than it is today) or has there been a policy decision against > Hansi> it? > >> -K > >> > >> > Hansi> _______________________________________________ Xorp-users > Hansi> mailing list Xorp-users at xorp.org > Hansi> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From hengjuen at gmail.com Wed Sep 19 01:29:22 2007 From: hengjuen at gmail.com (HJ) Date: Wed, 19 Sep 2007 16:29:22 +0800 Subject: [Xorp-users] BGP setup In-Reply-To: <200709181856.l8IIu0eD041135@possum.icir.org> References: <46EFC9B0.4070900@spritelink.net> <200709181856.l8IIu0eD041135@possum.icir.org> Message-ID: <686b91b0709190129r19c1f139hf8befaad2de6ea80@mail.gmail.com> Thanks Pavlin and Kristian, for you input. My intention is trying to get BGP up and play with loading it and see my CPU performance. I found some interesting test scripts in the harness folder, which can serve similar purpose. May I know what is the way to write our own dump file for the router, since i am not able to view icsi1.mrtd used in test_peering2.sh. What is the content of icsi1.mrtd? Also i found out that there is a function call on "get_ready_priority" under xorp_bgp function consume the most CPU cycle. May i know what is the reason? I counldn't get into the source code since it is showing assembly rather then C. Thanks. Heng Juen. On 9/19/07, Pavlin Radoslavov wrote: > > Kristian Larsson wrote: > > > HJ wrote: > > > Hi, > > > I try to play around with BGP using with below configuration and test > > > setup, but it seems like i am not able to send a packet over the other > > > side. Can anyone help to access my configuration file below? > > > Thanks in advance. > > > Heng Juen > > > > You don't need BGP for this setup. You only need a routing protocol if > > you have several routers that need to talk to each other. > > In this case something else is wrong. > > Are you running on Linux? Perhaps you've forgot to enable ip forwarding > > (echo 1 > /proc/sys/net/ipv4/ip_forward). Make sure the default gateways > > If fea/unicast-forwarding4 is enabled (as it appears in the original > configuration) then the FEA will take care of enabling the > forwarding in the kernel and there is no need for > "echo 1 > /proc/sys/net/ipv4/ip_forward". > > My $0.02 :) > > Pavlin > > > of your end hosts are the routers interface addresses. > > Please provide more details on your setup. > > > > -K > > > > _______________________________________________ > > 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/20070919/5fde471e/attachment.html From atanu at ICSI.Berkeley.EDU Wed Sep 19 08:44:35 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Wed, 19 Sep 2007 08:44:35 -0700 Subject: [Xorp-users] Fwd: Questions on OSPF In-Reply-To: Message from Hansi of "Wed, 19 Sep 2007 14:32:13 +0800." <2f9e317b0709182332k38aee193teb5e73561c55f0a1@mail.gmail.com> Message-ID: <5238.1190216675@tigger.icir.org> Hi, If you want to announce static routes then you need to use policy. Connected routes that not already being advertised due to OSPF being configured on the interface can be advertised using policy. Another strategy for connected routes for interfaces that are not configured for OSPF is to configure the interface but mark it as passive, if an interface is marked as passive then no protocol interactions will be attempted but the subnet will be announced. There was a bug that marking an interface as passive only advertised the host route, but I think that this was fixed. Atanu. >>>>> "Hansi" == Hansi writes: Hansi> Hello Atanu, How about static routes and connected routes? Hansi> Do I still need to explicitly use policies in order for them Hansi> to be announced? What I'm seeing on a network dump is only Hansi> indeed the subnet for the interfaces on w/c OSPF is Hansi> configured. I also want OSPF to announce static and connected Hansi> routes just like what is done w/ RIP when policy static and Hansi> connected is exported, can this be possible? Thanks Hansi. Hansi> On 9/19/07, Atanu Ghosh wrote: Hansi> Hi, OSPF will advertise the the subnets for the Hansi> interfaces on which it is configured. In the case of OSPFv2 Hansi> one subnet has to be explicitly configured in the config, for Hansi> OSPFv3 just specifying the interface will advertise all Hansi> associated subnets (the subnets can also be explicitly Hansi> configured). Routes from other protocols must be explicity Hansi> exported using policy. Atanu. >>>>>> "Hansi" == Hansi < hantongs at gmail.com> writes: Hansi> looping in the mailing list. Thank you. One more question Hansi> though.. I noticed that before RIP can be configured, the Hansi> policy parameter must be set first in order for RIP to either Hansi> advertise static and/or connected routes. Although RIP Hansi> already sends out udp packets once you configure it, it does Hansi> not send out its routing table entries not until after a Hansi> policy is either imported/exported to it. Does this also Hansi> apply to OSPF? Thanks. Hansi. On 9/14/07, Kristian Larsson Hansi> < kristian at spritelink.net> wrote: Hansi wrote: >>> Hello Kristian, Atanu, >>> >>> Thank you answering for my queries. Let me see if I Hansi> understood it clearly. >>> For link-types: p2p or p2m, it is necessary to explicitly Hansi> set >>> the neighbor parameter in order for the router running OSPF Hansi> to establish >>> adjacency with another router. Broadcast link-types on the Hansi> other hand >>> does not require the neighbor parameter to be explicitly Hansi> set, am I >>> correct? :) >>> >>> I concur with Atanu that p2p link-types requires the Hansi> neighbor statement >>> to be explicitly stated. My initial configuration does not Hansi> include >>> setting the neighbor parameter, upon invoking "show ospf4 Hansi> neighbor", >>> nothing comes up even though dumps from the network shows Hansi> OSPF hello >>> packets have been multicast already.. The neighbor router Hansi> only displays >>> [upon invoking show ospf4 neighbor] after setting the Hansi> neighbor parameter >>> on both routers. Hansi> Yepp, I was simply wrong. I expected XORP to work like Cisco Hansi> or Juniper. >>> Regarding setting router-ID parameters to loopback 127.0.0.1 Hansi> < >>> http://127.0.0.1>, would it be possible for two routers Hansi> running OSPF to >>> use the same router-ID? that is both of them are configured Hansi> to 127.0.0.1 >>> < http://127.0.0.1>? Since conventionally the router-ID is Hansi> usually set to >>> the loopback, would it be possible to configure all routers Hansi> in an OSPF >>> network to have the same router-ID of 127.0.0.1 Hansi> ? No, you cannot use 127.0.0.1, at least Hansi> not on both routers. Router-id have to be unique within your Hansi> OSPF domain, one common way of ensuring this is to use the Hansi> loopback address that you assign to a router. Although you Hansi> are correct that 127.0.0.1 is a loopback adress, routes Hansi> normally get one assigned from your address pool. iBGP Hansi> session for example are normally established between loopback Hansi> addresses to not be dependant upon a specific interface being Hansi> up. So assign 172.16.0.1-254 (if your are using private Hansi> addressing) or something to your loopbacks as well and you Hansi> can use those. -K >>> On 9/14/07, * kristian at spritelink.net kristian at spritelink.net>* < >>> kristian at spritelink.net > Hansi> wrote: >>> On Thu, 13 Sep 2007 14:58:01 -0700, Atanu Ghosh < >>> atanu at icsi.berkeley.edu > Hansi> wrote: >>> >>>>>> "kristian" == kristian < kristian at spritelink.net >> kristian at spritelink.net>> writes: >>> > >>> > kristian> On Thu, 13 Sep 2007 12:18:42 -0700, Atanu Hansi> Ghosh >>> > kristian> < atanu at icsi.berkeley.edu >> atanu at icsi.berkeley.edu>> wrote: > >>>>>>> "kristian" == Hansi> kristian >>> < Hansi> kristian at spritelink.net >>> > writes: >>> > >> >>> > kristian> On Thu, 13 Sep 2007 11:51:32 -0700, Atanu Hansi> Ghosh >>> > kristian> < atanu at icsi.berkeley.edu >> atanu at icsi.berkeley.edu>> wrote: > >> >>>>>>> "Kristian" == >>> Kristian Larsson < kristian at spritelink.net >> kristian at spritelink.net>> > >> >>>>>>> writes: >>> > >> >> >>> > Kristian> Hansi wrote: > >> >> >> Hello All, >>> > >> >> >> >>> > >> >> >> I'm currently learning how to configure Hansi> OSPFv2 on >>> two XORP > >> >> >> machines just to establish adjacency Hansi> with one >>> another. In a > >> p2p >> >> link type, is it still Hansi> necessary to explicitly >>> set the > >> >> 'neighbor' >> parameter of each machine Hansi> before >>> adjacency is >> > >> established? >> Furthermore, would it Hansi> be >>> possible Hansi> to set >>> the >> > >> router-id to its >> loopback address? instead of Hansi> say.. the >>> ip >> > >> address of the >> interface on which ospf will be Hansi> used? >>> > >> >> > Kristian> The neighbor command is only useful if Hansi> you are using a >>> > Kristian> medium on which the routers cannot broadcast Hansi> and thus >>> > Kristian> cannot discover each other. If you're using Hansi> ethernet >>> > Kristian> (which I presume from your NIC names) you do Hansi> not >>> have to > Kristian> use the neighbor statements. I would Hansi> advice configuring >>> > Kristian> the interfaces as link-type p2p as this Hansi> avoids DR >>> election > Kristian> and unnecessary CPU load. > >> >> I am >>> fairly sure that it is necessary to use Hansi> the >>> neighbour >> > >> statements. >>> > >> >>> > kristian> Are you serious? I haven't used the XORP Hansi> code in >>> quite > kristian> some time now.. but at least I thought Hansi> XORP implemented >>> > kristian> the OSPF standard. AFAIK, that includes Hansi> being able to >>> > kristian> discover neighbors and turn up adjacencies Hansi> to them. Is >>> > kristian> this not the case? Observe that he is Hansi> running an >>> Ethernet > kristian> point-to-point link, ie, it is not a Hansi> non-broadcast >>> medium. > kristian> Or are you saying that you can't do Hansi> link-type p2p >>> without > kristian> configuring neighbours ? >>> > >>> > >> If the link-type is set to "broadcast" then the Hansi> neighbours >>> will > >> be correctly discovered. If the link-type is set Hansi> to "p2p" >>> > >> (Point-to-point) or "p2m" (Point-to-multipoint) Hansi> then it is >>> > >> necessary to configure the neighbours. It has been Hansi> argued >>> that it > >> should not be necessary to configure the Hansi> neighbours if the >>> > >> routers are connected via a true Point-to-point Hansi> link, but >>> > >> unfortunately even in this case it is necessary to Hansi> configure >>> the > >> neighbour. >>> > >>> > kristian> Okey, that "kinda" makes sense. I apparently Hansi> forgot or >>> > kristian> missed the conversation on this. What I Hansi> want to >>> configure > kristian> with link-type p2p is not whether or Hansi> not >>> the Hansi> router >>> should > kristian> try to broadcast but if it should setup Hansi> one of those >>> > kristian> virtual router thingys, hehe. I'm not very Hansi> familiar >>> with > kristian> the terminology but (as you know) on a Hansi> broadcast medium >>> > kristian> you first have a DR selection and all that Hansi> and then >>> you're > kristian> gonna run your SPF. Since SPF can't Hansi> handle the >>> concept of > kristian> a broadcast medium it creates a Hansi> "virtual router" to >>> > kristian> represent the broadcast medium and connects Hansi> all >>> routers in > kristian> that broadcast domain as adjacencies Hansi> to >>> the Hansi> virtual >>> > kristian> router. When I configure 'isis network >>> point-to-point' on > kristian> a Cisco router I expect it to Hansi> not >>> setup one Hansi> of these >>> > kristian> "virtual routers" in it's SPF topology. And Hansi> this is >>> > kristian> different with XORP? >>> > >>> > Setting the link type to "broadcast" or "p2p" will both Hansi> result in >>> the > hello packets being broadcast, the distinction is that Hansi> if the >>> link-type > is set to "p2p" no DR election will be Hansi> attempted. >>> Alright, just as I expected. >>> >>> > The XORP OSPF behaves > as specified in the relevant RFCs Hansi> and >>> interoperates with Hansi> other OSPF >>> > implementations, the only difference is in configuration Hansi> of a "p2p" >>> > where we require the neighbour to be specified, which as I Hansi> mentioned >>> > before should not strictly be necessary. >>> >>> Okey, not what I expected. Why is it so? Just lack of time Hansi> to do the >>> actual implementation (although I don't see how it would Hansi> actually >>> be Hansi> more code >>> than it is today) or has there been a policy decision Hansi> against it? >>> -K >>> >>> Hansi> _______________________________________________ Xorp-users Hansi> mailing list Xorp-users at xorp.org Hansi> Hansi> Hansi> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From atanu at ICSI.Berkeley.EDU Wed Sep 19 08:58:02 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Wed, 19 Sep 2007 08:58:02 -0700 Subject: [Xorp-users] BGP setup In-Reply-To: Message from HJ of "Wed, 19 Sep 2007 16:29:22 +0800." <686b91b0709190129r19c1f139hf8befaad2de6ea80@mail.gmail.com> Message-ID: <8688.1190217482@tigger.icir.org> Hi, Just runnning gmake check in the bgp/harnesses directory should give you some insight into how to run the scripts. The format of the icsi1.mrtd is MRTd, this is the format used by the Route Views project (http://www.routeviews.org/) the tool route_btoa from the MRTd (http://mrt.sourceforge.net/) can be used to view the dump file. We decided to use a commonly used format rather then invent our own. The implementation of "get_ready_priority" is in the file selector.cc in the libxorp directory. This method tries to find the highest priority file descriptor event, it is part of the task scheduling code. Atanu. >>>>> "HJ" == HJ writes: HJ> Thanks Pavlin and Kristian, for you input. My intention is HJ> trying to get BGP up and play with loading it and see my CPU HJ> performance. HJ> I found some interesting test scripts in the harness folder, HJ> which can serve similar purpose. HJ> May I know what is the way to write our own dump file for the HJ> router, since i am not able to view icsi1.mrtd used in HJ> test_peering2.sh. HJ> What is the content of icsi1.mrtd? HJ> Also i found out that there is a function call on HJ> "get_ready_priority" under xorp_bgp function consume the most HJ> CPU cycle. May i know what is the reason? I counldn't get into HJ> the source code since it is showing assembly rather then C. HJ> Thanks. Heng Juen. HJ> On 9/19/07, Pavlin Radoslavov wrote: HJ> Kristian Larsson wrote: >> HJ wrote: > Hi, > I try to play around with BGP using with below >> configuration HJ> and test >> > setup, but it seems like i am not able to send a packet over HJ> the other >> > side. Can anyone help to access my configuration file below? > >> Thanks in advance. > Heng Juen >> >> You don't need BGP for this setup. You only need a routing HJ> protocol if >> you have several routers that need to talk to each other. In >> this case something else is wrong. Are you running on Linux? >> Perhaps you've forgot to enable ip HJ> forwarding >> (echo 1 > /proc/sys/net/ipv4/ip_forward). Make sure the default HJ> gateways If fea/unicast-forwarding4 is enabled (as it HJ> appears in the original configuration) then the FEA will take HJ> care of enabling the forwarding in the kernel and there is no HJ> need for "echo 1 > /proc/sys/net/ipv4/ip_forward". My $0.02 :) HJ> Pavlin >> of your end hosts are the routers interface addresses. Please >> provide more details on your setup. >> >> -K >> >> _______________________________________________ Xorp-users >> mailing list Xorp-users at xorp.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users HJ> _______________________________________________ Xorp-users HJ> mailing list Xorp-users at xorp.org HJ> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From greearb at candelatech.com Wed Sep 19 14:59:59 2007 From: greearb at candelatech.com (Ben Greear) Date: Wed, 19 Sep 2007 14:59:59 -0700 Subject: [Xorp-users] Unreachable default route. In-Reply-To: <200709140001.l8E01R5E041251@possum.icir.org> References: <200709140001.l8E01R5E041251@possum.icir.org> Message-ID: <46F19BDF.1000600@candelatech.com> Ok, I think this is working now...patch is attached. In addition to the 'unreachable' feature, this also includes the hack to let the 'static' priority be set though an environment variable, and a slight modification of the error logging for receiving pkts not destined for this Xorp's interfaces. If it is more convenient, I can cut those extra two things out of the patch, but I would also be happy if they went into Xorp proper. I understand the getenv hack is not a long term solution, but it is better than nothing, and if the variable is not set, you get the current default behaviour. Please look for 'TODO' in the patch, as I had a few questions as to whether I did it right. It seems to be working right on Linux: 10.2.0.0/24 via 10.0.0.1 dev rddVR1 proto xorp metric 2 notify 10.0.0.0/24 dev rddVR1 scope link 10.4.0.0/24 dev rddVR44 scope link 10.1.0.0/24 via 10.4.0.2 dev rddVR44 proto xorp metric 2 notify 10.3.0.0/24 via 10.0.0.1 dev rddVR1 proto xorp metric 2 notify unreachable default proto xorp metric 1 notify cfg-file snippets: interfaces { interface my_discard { unreachable: true vif my_discard { } } } protocols { static { interface-route 0.0.0.0/0 { next-hop-interface: "my_discard" next-hop-vif: "my_discard" } } } Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -------------- next part -------------- A non-text attachment was scrubbed... Name: xorp_unreachable.patch Type: text/x-patch Size: 88254 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070919/a0dfa53f/attachment-0001.bin From pavlin at icir.org Wed Sep 19 18:45:44 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 19 Sep 2007 18:45:44 -0700 Subject: [Xorp-users] Unreachable default route. In-Reply-To: Message from Ben Greear of "Wed, 19 Sep 2007 14:59:59 PDT." <46F19BDF.1000600@candelatech.com> Message-ID: <200709200145.l8K1jiBE060335@possum.icir.org> Ben Greear wrote: > Ok, I think this is working now...patch is attached. This is one big almost 100K patch! At quick glance it seems right. Accidentally, right now I am tied with refactoring some of the interface-related bottom pieces of the FEA and some of the changes overlap with your patch. Only after the refactoring is completed I can look into your patch in more details. Please ping me again on the subject if you don't hear anything from me within few days or so. Thanks, Pavlin From coloradus at msn.com Wed Sep 19 19:32:46 2007 From: coloradus at msn.com (Damian D.) Date: Wed, 19 Sep 2007 23:32:46 -0300 Subject: [Xorp-users] New on this Message-ID: Hi, I am new on this. My name is Damian Demasi and I am studing Telecommunications Engineering in Argentina. My teacher of Information Networks told us about the XORP project, and refer to it as a posible future for the routing software. I have been reading a lot sense then, and found many information, but no so much clear, about the operation of XORP. I have the sufficient knowledge to configure a Cisco router to do NAT, DHCP, and have the theorical concept of RIP and OSPF. Can anyone tell me where can I found information about the operation and implementation of XORP from zero, whit an explanation for "dummies"? I whant to learn more of XORP to implement it on a PC whit Linux. Sorry if this email is to basic for this group of people, but I don?t know anyone who can explain XORP to me. Successes to all!! Damian.- P.S.: Sorry for my english... and I would like to cooperate whit you in all I can (i.e.: translating something to spanish). _________________________________________________________________ Descubre Live.com - tu mundo en l?nea reunido: noticias, deportes, el tiempo, y mucho m?s. http://www.live.com/getstarted -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070919/9db33c61/attachment.html From kristian at spritelink.net Thu Sep 20 00:54:31 2007 From: kristian at spritelink.net (Kristian Larsson) Date: Thu, 20 Sep 2007 09:54:31 +0200 Subject: [Xorp-users] New on this In-Reply-To: References: Message-ID: <46F22737.5070300@spritelink.net> Damian D. wrote: > Hi, I am new on this. My name is Damian Demasi and I am studing > Telecommunications Engineering in Argentina. My teacher of Information > Networks told us about the XORP project, and refer to it as a posible > future for the routing software. I have been reading a lot sense then, > and found many information, but no so much clear, about the operation of > XORP. I have the sufficient knowledge to configure a Cisco router to do > NAT, DHCP, and have the theorical concept of RIP and OSPF. Great, then you have the underlying knowledge... > Can anyone tell me where can I found information about the operation and > implementation of XORP from zero, whit an explanation for "dummies"? If you just take a look under the "getting started" page on www.xorp.org you should be able to get a grip of the XORP configuration and "adapt" you Cisco skillz to XORP :) If you have any specific questions then just mail the list again (and don't forget to include your XORP conf) and we'll help you out to the best of our ability :) > P.S.: Sorry for my english... and I would like to cooperate whit you in > all I can (i.e.: translating something to spanish). I don't know if there is a translation project yet, but it would of course be great to have documentation in local languages! Regards, Kristian. From sureshkannan at gmail.com Thu Sep 20 01:35:02 2007 From: sureshkannan at gmail.com (Suresh Kannan) Date: Thu, 20 Sep 2007 14:05:02 +0530 Subject: [Xorp-users] New on this In-Reply-To: <46F22737.5070300@spritelink.net> References: <46F22737.5070300@spritelink.net> Message-ID: <46F230B6.5090008@gmail.com> Hi Kristian, The documentation provides high level design of XORP and "how to" to write own task on xorp. Though from the Xorp goal perspective, its gives enough information. It would be great if we have some documentation on code level in the sense of XORP system as such for application protocol. If we could add common system flow documentation, might really help for developers. my 2 cents,Thanks, Suresh Kannan. Kristian Larsson wrote: > Damian D. wrote: > >> Hi, I am new on this. My name is Damian Demasi and I am studing >> Telecommunications Engineering in Argentina. My teacher of Information >> Networks told us about the XORP project, and refer to it as a posible >> future for the routing software. I have been reading a lot sense then, >> and found many information, but no so much clear, about the operation of >> XORP. I have the sufficient knowledge to configure a Cisco router to do >> NAT, DHCP, and have the theorical concept of RIP and OSPF. >> > > Great, then you have the underlying knowledge... > > >> Can anyone tell me where can I found information about the operation and >> implementation of XORP from zero, whit an explanation for "dummies"? >> > > If you just take a look under the "getting started" page on www.xorp.org > you should be able to get a grip of the XORP configuration and "adapt" > you Cisco skillz to XORP :) > If you have any specific questions then just mail the list again (and > don't forget to include your XORP conf) and we'll help you out to the > best of our ability :) > > >> P.S.: Sorry for my english... and I would like to cooperate whit you in >> all I can (i.e.: translating something to spanish). >> > > I don't know if there is a translation project yet, but it would of > course be great to have documentation in local languages! > > Regards, > Kristian. > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > From ror.sanjeev at gmail.com Thu Sep 20 04:47:05 2007 From: ror.sanjeev at gmail.com (sanjeev kumar) Date: Thu, 20 Sep 2007 17:17:05 +0530 Subject: [Xorp-users] Not able to run XORP: Message-ID: <477942240709200447w433c2d1bw234198aaa3c41c59@mail.gmail.com> Hi, I am not able to run xorp,Please go through this: # ./xorp_rtrmgr -b config.boot [ 2007/09/20 17:12:32 ERROR xorp_rtrmgr:24314 LIBCOMM +360 comm_sock.c comm_sock_bind4 ] Error binding socket (family = 2, my_addr = 127.0.0.1, my_port = 19999): Address already in use [ 2007/09/20 17:12:32 ERROR xorp_rtrmgr:24314 RTRMGR +243 main_rtrmgr.cc run ] Address already in use: a finder may already be running. -- Efforts may fail,But don't Fail to make efforts. --------- Sanjeev Kumar Project Engineer CDAC(Formerly NCST) Juhu,Mumbai-400049 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070920/09bfea9e/attachment.html From a.greenhalgh at cs.ucl.ac.uk Thu Sep 20 04:53:25 2007 From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh) Date: Thu, 20 Sep 2007 12:53:25 +0100 Subject: [Xorp-users] Not able to run XORP: In-Reply-To: <477942240709200447w433c2d1bw234198aaa3c41c59@mail.gmail.com> References: <477942240709200447w433c2d1bw234198aaa3c41c59@mail.gmail.com> Message-ID: <4769af410709200453p50e76058j4c4b9bfc57384419@mail.gmail.com> Hi It would seem like a xorp_rtrmgr is already running, ps axf | grep xorp should show what xorp processes are still running. Equally the socket could be being held open by another process. Or equally something not xorp related, something else is already listening on that socket. netstat -n -l -p -t -u will tell you what is listening on the local tcp and udp ports. Adam On 9/20/07, sanjeev kumar wrote: > Hi, > I am not able to run xorp,Please go through this: > > # ./xorp_rtrmgr -b config.boot > [ 2007/09/20 17:12:32 ERROR xorp_rtrmgr:24314 LIBCOMM +360 comm_sock.c > comm_sock_bind4 ] Error binding socket (family = 2, my_addr = 127.0.0.1, > my_port = 19999): Address already in use > [ 2007/09/20 17:12:32 ERROR xorp_rtrmgr:24314 RTRMGR +243 main_rtrmgr.cc > run ] Address already in use: a finder may already be running. > > > -- > Efforts may fail,But don't Fail to make efforts. > --------- > Sanjeev Kumar > Project Engineer > CDAC(Formerly NCST) > Juhu,Mumbai-400049 > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > From arun.punj at ericsson.com Thu Sep 20 05:03:07 2007 From: arun.punj at ericsson.com (Arun Punj) Date: Thu, 20 Sep 2007 07:03:07 -0500 Subject: [Xorp-users] Not able to run XORP: In-Reply-To: <477942240709200447w433c2d1bw234198aaa3c41c59@mail.gmail.com> References: <477942240709200447w433c2d1bw234198aaa3c41c59@mail.gmail.com> Message-ID: <2D7CEF7F8F759C4AB79D7C46666F329C019BBCA9@eusrcmw721.eamcs.ericsson.se> Hi Sanjeev, I myself am new to Xorp ( less than 2 days using it) so take my inputs with lumps of salt. I have seen a lot of tasks with name xorp_xxxx (like xorp_igmp etc) keep running if xorp_rtrmgr dies or is killed using CTL-C /CTL-D/CTL-/ ( stop, quit, kill ). My solution is to check for such tasks using ps -ef | grep xorp and then kill those tasks using killall before starting rtrmgr again. hope it helps. Arun ________________________________ From: xorp-users-bounces at xorp.org [mailto:xorp-users-bounces at xorp.org] On Behalf Of sanjeev kumar Sent: Thursday, September 20, 2007 7:47 AM To: xorp-users at xorp.org Subject: [Xorp-users] Not able to run XORP: Hi, I am not able to run xorp,Please go through this: # ./xorp_rtrmgr -b config.boot [ 2007/09/20 17:12:32 ERROR xorp_rtrmgr:24314 LIBCOMM +360 comm_sock.c comm_sock_bind4 ] Error binding socket (family = 2, my_addr = 127.0.0.1, my_port = 19999): Address already in use [ 2007/09/20 17:12:32 ERROR xorp_rtrmgr:24314 RTRMGR +243 main_rtrmgr.cc run ] Address already in use: a finder may already be running. -- Efforts may fail,But don't Fail to make efforts. --------- Sanjeev Kumar Project Engineer CDAC(Formerly NCST) Juhu,Mumbai-400049 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070920/12e1d1ba/attachment-0001.html From greearb at candelatech.com Thu Sep 20 11:17:56 2007 From: greearb at candelatech.com (Ben Greear) Date: Thu, 20 Sep 2007 11:17:56 -0700 Subject: [Xorp-users] Unreachable default route. In-Reply-To: <200709200145.l8K1jiBE060335@possum.icir.org> References: <200709200145.l8K1jiBE060335@possum.icir.org> Message-ID: <46F2B954.2060101@candelatech.com> Pavlin Radoslavov wrote: > Ben Greear wrote: > >> Ok, I think this is working now...patch is attached. > > This is one big almost 100K patch! Yeah, one might say that Xorp was a bit bloated :P > At quick glance it seems right. > > Accidentally, right now I am tied with refactoring some of the > interface-related bottom pieces of the FEA and some of the changes > overlap with your patch. > Only after the refactoring is completed I can look into your patch > in more details. > > Please ping me again on the subject if you don't hear anything from > me within few days or so. Ok, sounds good. Thanks, Ben > > Thanks, > Pavlin -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Thu Sep 20 11:58:01 2007 From: greearb at candelatech.com (Ben Greear) Date: Thu, 20 Sep 2007 11:58:01 -0700 Subject: [Xorp-users] adding/removing interfaces with xorp-cli In-Reply-To: <200709190116.l8J1GLMI048033@possum.icir.org> References: <200709190116.l8J1GLMI048033@possum.icir.org> Message-ID: <46F2C2B9.6020401@candelatech.com> I tried these commands: delete interfaces interface rddVR44 vif rddVR44 address 10.4.0.1 delete protocols ospf4 area 0.0.0.0 interface rddVR44 vif rddVR44 address 10.4.0.1 set protocols ospf4 area 0.0.0.0 interface rddVR44 vif rddVR44 address 10.4.0.10 set interfaces interface rddVR44 vif rddVR44 address 10.4.0.10 prefix-length 24 commit I get this error on commit: root at lanforge-33-46# commit Commit Failed 102 Command failed BadPeer from line 479 of peer_manager.cc: Unable to get prefix length for rddVR44/rddVR44/10.4.0.10[edit] I also tried this: delete interfaces interface rddVR44 vif rddVR44 address 10.4.0.1 delete protocols ospf4 area 0.0.0.0 interface rddVR44 vif rddVR44 address 10.4.0.1 commit This failed with: root at lanforge-33-46# commit Commit Failed 102 Command failed Failed executing: "RemoveAddr4: rddVR44 rddVR44 10.4.0.1"[edit] And, I tried removing just the ospf portion: root at lanforge-33-46> configure Entering configuration mode. There are no other users in configuration mode. [edit] root at lanforge-33-46# delete protocols ospf4 area 0.0.0.0 interface rddVR44 vif rddVR44 address 10.4.0.1 Deleting: 10.4.0.1 { } OK [edit] root at lanforge-33-46# commit Commit Failed 102 Command failed BadPeer from line 392 of peer_manager.cc: No mapping for rddVR44/rddVR44 exists[edit] I tried just changing the interface info: root at lanforge-33-46> configure Entering configuration mode. There are no other users in configuration mode. [edit] root at lanforge-33-46# delete interfaces interface rddVR44 vif rddVR44 address 10.4.0.1 Deleting: 10.4.0.1 { prefix-length: 24 } OK [edit] root at lanforge-33-46# set interfaces interface rddVR44 vif rddVR44 address 10.4.0.10 prefix-length 24 [edit] root at lanforge-33-46# commit Commit Failed 102 Command failed Failed executing: "RemoveAddr4: rddVR44 rddVR44 10.4.0.1"[edit] root at lanforge-33-46# Any ideas? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Thu Sep 20 12:21:57 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 20 Sep 2007 12:21:57 -0700 Subject: [Xorp-users] adding/removing interfaces with xorp-cli In-Reply-To: Message from Ben Greear of "Thu, 20 Sep 2007 11:58:01 PDT." <46F2C2B9.6020401@candelatech.com> Message-ID: <200709201921.l8KJLvrQ071338@possum.icir.org> Ben Greear wrote: The errors seem to be coming from OSPF (or at least from the FEA-OSPF interaction). Please try deleting/adding addresses when running the FEA only as in my sample configuration. Pavlin > I tried these commands: > > delete interfaces interface rddVR44 vif rddVR44 address 10.4.0.1 > delete protocols ospf4 area 0.0.0.0 interface rddVR44 vif rddVR44 address 10.4.0.1 > set protocols ospf4 area 0.0.0.0 interface rddVR44 vif rddVR44 address 10.4.0.10 > set interfaces interface rddVR44 vif rddVR44 address 10.4.0.10 prefix-length 24 > commit > > I get this error on commit: > > root at lanforge-33-46# commit Commit Failed > 102 Command failed BadPeer from line 479 of peer_manager.cc: Unable to get prefix length for rddVR44/rddVR44/10.4.0.10[edit] > > I also tried this: > delete interfaces interface rddVR44 vif rddVR44 address 10.4.0.1 > delete protocols ospf4 area 0.0.0.0 interface rddVR44 vif rddVR44 address 10.4.0.1 > commit > > This failed with: > root at lanforge-33-46# commit > Commit Failed > 102 Command failed Failed executing: "RemoveAddr4: rddVR44 rddVR44 10.4.0.1"[edit] > > And, I tried removing just the ospf portion: > root at lanforge-33-46> configure Entering configuration mode. > There are no other users in configuration mode. > [edit] > root at lanforge-33-46# delete protocols ospf4 area 0.0.0.0 interface rddVR44 vif rddVR44 address 10.4.0.1 > Deleting: > 10.4.0.1 { > } > > OK > [edit] > root at lanforge-33-46# commit > Commit Failed > 102 Command failed BadPeer from line 392 of peer_manager.cc: No mapping for rddVR44/rddVR44 exists[edit] > > > I tried just changing the interface info: > > root at lanforge-33-46> configure Entering configuration mode. > There are no other users in configuration mode. > [edit] > root at lanforge-33-46# delete interfaces interface rddVR44 vif rddVR44 address 10.4.0.1 > Deleting: > 10.4.0.1 { > prefix-length: 24 > } > > OK > [edit] > root at lanforge-33-46# set interfaces interface rddVR44 vif rddVR44 address 10.4.0.10 prefix-length 24 > [edit] > root at lanforge-33-46# commit > Commit Failed > 102 Command failed Failed executing: "RemoveAddr4: rddVR44 rddVR44 10.4.0.1"[edit] > root at lanforge-33-46# > > > Any ideas? > > 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 greearb at candelatech.com Thu Sep 20 12:43:20 2007 From: greearb at candelatech.com (Ben Greear) Date: Thu, 20 Sep 2007 12:43:20 -0700 Subject: [Xorp-users] adding/removing interfaces with xorp-cli In-Reply-To: <200709201921.l8KJLvrQ071338@possum.icir.org> References: <200709201921.l8KJLvrQ071338@possum.icir.org> Message-ID: <46F2CD58.8040805@candelatech.com> Pavlin Radoslavov wrote: > Ben Greear wrote: > > > The errors seem to be coming from OSPF (or at least from the > FEA-OSPF interaction). > Please try deleting/adding addresses when running the FEA only as in > my sample configuration. That very well might work..but doesn't do me any good. I'll try to dig into the error messages and see if I can fix OSPF. Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From atanu at ICSI.Berkeley.EDU Thu Sep 20 12:48:51 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Thu, 20 Sep 2007 12:48:51 -0700 Subject: [Xorp-users] adding/removing interfaces with xorp-cli In-Reply-To: Message from Pavlin Radoslavov of "Thu, 20 Sep 2007 12:21:57 PDT." <200709201921.l8KJLvrQ071338@possum.icir.org> Message-ID: <23760.1190317731@tigger.icir.org> Hi, The first error seems to be an OSPF bug, it is supposed to be possible to configure OSPF with and an interface and vif that are not configured in the interfaces section. When the interface and vif are configured in the interfaces OSPF should respond to the update. Unfortunately OSPF is attempting to get the prefix length of the interface and vif before checking if it is configured. A work around would be to commit the changes to the interfaces section before committing the OSPF changes. Atanu. >>>>> "Pavlin" == Pavlin Radoslavov writes: Pavlin> Ben Greear wrote: Pavlin> The errors seem to be coming from OSPF (or at least from the Pavlin> FEA-OSPF interaction). Pavlin> Please try deleting/adding addresses when running the FEA only as in Pavlin> my sample configuration. Pavlin> Pavlin >> I tried these commands: >> >> delete interfaces interface rddVR44 vif rddVR44 address 10.4.0.1 >> delete protocols ospf4 area 0.0.0.0 interface rddVR44 vif rddVR44 address 10.4.0.1 >> set protocols ospf4 area 0.0.0.0 interface rddVR44 vif rddVR44 address 10.4.0.10 >> set interfaces interface rddVR44 vif rddVR44 address 10.4.0.10 prefix-length 24 >> commit >> >> I get this error on commit: >> >> root at lanforge-33-46# commit Commit Failed >> 102 Command failed BadPeer from line 479 of peer_manager.cc: Unable to get prefix length for rddVR44/rddVR44/10.4.0.10[edit] >> >> I also tried this: >> delete interfaces interface rddVR44 vif rddVR44 address 10.4.0.1 >> delete protocols ospf4 area 0.0.0.0 interface rddVR44 vif rddVR44 address 10.4.0.1 >> commit >> >> This failed with: >> root at lanforge-33-46# commit >> Commit Failed >> 102 Command failed Failed executing: "RemoveAddr4: rddVR44 rddVR44 10.4.0.1"[edit] >> >> And, I tried removing just the ospf portion: >> root at lanforge-33-46> configure Entering configuration mode. >> There are no other users in configuration mode. >> [edit] >> root at lanforge-33-46# delete protocols ospf4 area 0.0.0.0 interface rddVR44 vif rddVR44 address 10.4.0.1 >> Deleting: >> 10.4.0.1 { >> } >> >> OK >> [edit] >> root at lanforge-33-46# commit >> Commit Failed >> 102 Command failed BadPeer from line 392 of peer_manager.cc: No mapping for rddVR44/rddVR44 exists[edit] >> >> >> I tried just changing the interface info: >> >> root at lanforge-33-46> configure Entering configuration mode. >> There are no other users in configuration mode. >> [edit] >> root at lanforge-33-46# delete interfaces interface rddVR44 vif rddVR44 address 10.4.0.1 >> Deleting: >> 10.4.0.1 { >> prefix-length: 24 >> } >> >> OK >> [edit] >> root at lanforge-33-46# set interfaces interface rddVR44 vif rddVR44 address 10.4.0.10 prefix-length 24 >> [edit] >> root at lanforge-33-46# commit >> Commit Failed >> 102 Command failed Failed executing: "RemoveAddr4: rddVR44 rddVR44 10.4.0.1"[edit] >> root at lanforge-33-46# >> >> >> Any ideas? >> >> 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 Pavlin> _______________________________________________ Pavlin> Xorp-users mailing list Pavlin> Xorp-users at xorp.org Pavlin> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From greearb at candelatech.com Thu Sep 20 13:02:38 2007 From: greearb at candelatech.com (Ben Greear) Date: Thu, 20 Sep 2007 13:02:38 -0700 Subject: [Xorp-users] adding/removing interfaces with xorp-cli In-Reply-To: <23760.1190317731@tigger.icir.org> References: <23760.1190317731@tigger.icir.org> Message-ID: <46F2D1DE.4060107@candelatech.com> Atanu Ghosh wrote: > Hi, > > The first error seems to be an OSPF bug, it is supposed to be possible > to configure OSPF with and an interface and vif that are not configured > in the interfaces section. When the interface and vif are configured in > the interfaces OSPF should respond to the update. Unfortunately OSPF is > attempting to get the prefix length of the interface and vif before > checking if it is configured. A work around would be to commit the > changes to the interfaces section before committing the OSPF changes. If you check a bit farther down my email, you will see that I tried that and couldn't get that working either. Ahh, part of the problem is that even though the commits failed, it seems it did manage to set the IP on the interface, so my subsequent commands to remove the old IP failed. One suggestion there: If asked to remove something that does not exist, do not fail. At most, issue a warning. Let me try some more commands now that I understand this IP issue a bit better.. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Thu Sep 20 14:35:18 2007 From: greearb at candelatech.com (Ben Greear) Date: Thu, 20 Sep 2007 14:35:18 -0700 Subject: [Xorp-users] adding/removing interfaces with xorp-cli In-Reply-To: <46F2D1DE.4060107@candelatech.com> References: <23760.1190317731@tigger.icir.org> <46F2D1DE.4060107@candelatech.com> Message-ID: <46F2E796.9030508@candelatech.com> Ok, I restarted Xorp and re-did the CLI commands as remove ip from interface add ip to interface commit remove ip from ospf add ip to ospf commit This worked with no errors. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Thu Sep 20 18:51:00 2007 From: greearb at candelatech.com (Ben Greear) Date: Thu, 20 Sep 2007 18:51:00 -0700 Subject: [Xorp-users] adding/removing interfaces with xorp-cli In-Reply-To: <23760.1190317731@tigger.icir.org> References: <23760.1190317731@tigger.icir.org> Message-ID: <46F32384.1070504@candelatech.com> While doing some testing, I noticed that the 'config' command takes multiple seconds, even if you are just adding an IP to a VIF and an OSPF interface entry. Any idea why it takes so long to do this? When the 'unreachable' patch gets merged, I'll send you all a new diff that makes the delete commands work a bit better (primarily by not generating errors if you try to delete an entity that doesn't exist..) Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Sat Sep 22 15:59:19 2007 From: greearb at candelatech.com (Ben Greear) Date: Sat, 22 Sep 2007 15:59:19 -0700 Subject: [Xorp-users] xorp_rib SEGV when removing interface while using OSPF. Message-ID: <46F59E47.7080203@candelatech.com> While testing removing interfaces & OSPF, I get a core from rib_xorp. The backtrace shows that the net object has a _vif that is bad memory (ie, already deleted as far as I can tell.) I believe it might be because of this code in rib.cc. It is cleaning out all of the 'directly connected' routes, but maybe it is not cleaning up OSPF routes? Since we are deleting the vif object, I think we should notify all tables that the vif is being deleted and have it delete any route that references the vif, regardless of what IP the route is. Otherwise, stale memory will be referenced next time something messes with the routes on the dead interface. int RIB::delete_vif(const string& vifname) { debug_msg("RIB::delete_vif: %s\n", vifname.c_str()); map::iterator vi = _vifs.find(vifname); if (vi == _vifs.end()) { return XORP_ERROR; } Vif& vif = vi->second; if (vif.is_underlying_vif_up()) { // // Delete the directly connected routes associated with this vif // list::const_iterator ai; for (ai = vif.addr_list().begin(); ai != vif.addr_list().end(); ++ai) { if (ai->addr().af() != A::af()) continue; IPNet subnet_addr; A peer_addr; ai->subnet_addr().get(subnet_addr); ai->peer_addr().get(peer_addr); delete_connected_route(vif, subnet_addr, peer_addr); } } _vifs.erase(vi); return XORP_OK; } Here's the backtrace. _vif is corrupted by frame 11. #0 0x473b680f in std::basic_string, std::allocator >::basic_string () from /usr/lib/libstdc++.so.6 #1 0x080b81b4 in DeleteRoute (this=0x82b6020, parent=0x82aca28, ipr=@0x82b6bf0) at redist_xrl.cc:236 #2 0x080b82a0 in DeleteTransactionRoute (this=0x82b6020, parent=0x82aca28, ipr=@0x82b6bf0) at redist_xrl.cc:618 #3 0x080b9fbd in RedistTransactionXrlOutput::delete_route (this=0x82aca28, ipr=@0x82b6bf0) at redist_xrl.cc:1062 #4 0x08057e23 in Redistributor::RedistEventInterface::did_delete (this=0x82ac3d8, ipr=@0x82b6bf0) at rt_tab_redist.cc:294 #5 0x08059768 in RedistTable::delete_route (this=0x82a3c20, r=0x82b6bf0, caller=0x82a3bb0) at rt_tab_redist.cc:441 #6 0x080a6a77 in PolicyRedistTable::delete_route (this=0x82a3bb0, route=0x82b6bf0, caller=0x82a3b70) at rt_tab_pol_redist.cc:101 #7 0x080ad732 in RegisterTable::delete_route (this=0x82a3b70, route=0x82b6bf0, caller=0x82b5ce0) at rt_tab_register.cc:271 #8 0x0809bcf2 in MergedTable::delete_route (this=0x82b5ce0, route=0x82b6bf0, caller=0x82b6bd8) at rt_tab_merged.cc:109 #9 0x0809bcf2 in MergedTable::delete_route (this=0x82b6bd8, route=0x82b6bf0, caller=0x82b5f20) at rt_tab_merged.cc:109 #10 0x080597e1 in RedistTable::delete_route (this=0x82b5f20, r=0x82b6bf0, caller=0x82b60d0) at rt_tab_redist.cc:445 #11 0x0809f470 in OriginTable::delete_route (this=0x82b60d0, net=@0x82b1200) at rt_tab_origin.cc:131 #12 0x08086604 in RIB::delete_route (this=0xbfdac034, tablename=@0x82b5ea0, net=@0x82b1200) at rib.cc:878 #13 0x08066379 in XrlRibTarget::rib_0_1_delete_route4 (this=0xbfdac3d8, protocol=@0x82b5ea0, unicast=@0x82b6a7c, multicast=@0x82b1224, network=@0x82b1200) at xrl_target.cc:581 #14 0x0811c335 in XrlRibTargetBase::handle_rib_0_1_delete_route4 (this=0xbfdac3d8, xa_inputs=@0xbfda3eac) at rib_base.cc:855 #15 0x0811d203 in XorpMemberCallback2B0::dispatch (this=0x829f1b0, a1=@0xbfda3eac, a2=0xbfda3e90) at ../../libxorp/callback_nodebug.hh:4615 #16 0x08190339 in XrlCmdEntry::dispatch (this=0x829f204, inputs=@0xbfda3eac, outputs=0xbfda3e90) at xrl_cmd_map.hh:37 #17 0x08196f5a in XrlDispatcher::dispatch_xrl (this=0xbfdac638, method_name=@0xbfda3e20, inputs=@0xbfda3eac, outputs=@0xbfda3e90) at xrl_dispatcher.cc:60 ... (gdb) print *found->_vif $9 = {_vptr.Vif = 0x4d0a322e, _name = {static npos = 4294967295, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x79546773
}}, _ifname = {static npos = 4294967295, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x78206570
}}, _pif_index = 1902465802, _vif_index = 840986446, _is_pim_register = 55, _is_p2p = 49, _is_loopback = 55, _is_discard = 10, _is_unreachable = 77, _is_multicast_capable = 115, _is_broadcast_capable = 103, _is_underlying_vif_up = 68, _mtu = 543257697, _addr_list = { >> = { _M_impl = { >> = {<__gnu_cxx::new_allocator >> = {}, }, _M_node = {_M_next = 0x646e6966, _M_prev = 0x2f3a7265}}}, }} (gdb) Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Mon Sep 24 10:13:01 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Mon, 24 Sep 2007 10:13:01 -0700 Subject: [Xorp-users] xorp_rib SEGV when removing interface while using OSPF. In-Reply-To: Message from Ben Greear of "Sat, 22 Sep 2007 15:59:19 PDT." <46F59E47.7080203@candelatech.com> Message-ID: <200709241713.l8OHD13q067018@possum.icir.org> Ben Greear wrote: > While testing removing interfaces & OSPF, I get a core from rib_xorp. > The backtrace shows that > the net object has a _vif that is bad memory (ie, already deleted as far > as I can tell.) > > I believe it might be because of this code in rib.cc. It is cleaning > out all of the > 'directly connected' routes, but maybe it is not cleaning up OSPF routes? > > Since we are deleting the vif object, I think we should notify all > tables that the > vif is being deleted and have it delete any route that references the > vif, regardless > of what IP the route is. Otherwise, stale memory will be referenced > next time > something messes with the routes on the dead interface. Without looking into all details, I think your intuition is right. Could you open a Bugzilla entry for the issue and include instuctions how to reproduce the issue. Without such instructions it will be much more difficult to track and fix the issue. Thanks, Pavlin > int > RIB::delete_vif(const string& vifname) > { > debug_msg("RIB::delete_vif: %s\n", vifname.c_str()); > map::iterator vi = _vifs.find(vifname); > if (vi == _vifs.end()) { > return XORP_ERROR; > } > Vif& vif = vi->second; > > if (vif.is_underlying_vif_up()) { > // > // Delete the directly connected routes associated with this vif > // > list::const_iterator ai; > for (ai = vif.addr_list().begin(); ai != vif.addr_list().end(); > ++ai) { > if (ai->addr().af() != A::af()) > continue; > > IPNet subnet_addr; > A peer_addr; > ai->subnet_addr().get(subnet_addr); > ai->peer_addr().get(peer_addr); > delete_connected_route(vif, subnet_addr, peer_addr); > } > } > > _vifs.erase(vi); > return XORP_OK; > } > > Here's the backtrace. _vif is corrupted by frame 11. > > #0 0x473b680f in std::basic_string, > std::allocator >::basic_string () from /usr/lib/libstdc++.so.6 > #1 0x080b81b4 in DeleteRoute (this=0x82b6020, parent=0x82aca28, > ipr=@0x82b6bf0) at redist_xrl.cc:236 > #2 0x080b82a0 in DeleteTransactionRoute (this=0x82b6020, > parent=0x82aca28, ipr=@0x82b6bf0) at redist_xrl.cc:618 > #3 0x080b9fbd in RedistTransactionXrlOutput::delete_route > (this=0x82aca28, ipr=@0x82b6bf0) at redist_xrl.cc:1062 > #4 0x08057e23 in Redistributor::RedistEventInterface::did_delete > (this=0x82ac3d8, ipr=@0x82b6bf0) at rt_tab_redist.cc:294 > #5 0x08059768 in RedistTable::delete_route (this=0x82a3c20, > r=0x82b6bf0, caller=0x82a3bb0) at rt_tab_redist.cc:441 > #6 0x080a6a77 in PolicyRedistTable::delete_route (this=0x82a3bb0, > route=0x82b6bf0, caller=0x82a3b70) at rt_tab_pol_redist.cc:101 > #7 0x080ad732 in RegisterTable::delete_route (this=0x82a3b70, > route=0x82b6bf0, caller=0x82b5ce0) at rt_tab_register.cc:271 > #8 0x0809bcf2 in MergedTable::delete_route (this=0x82b5ce0, > route=0x82b6bf0, caller=0x82b6bd8) at rt_tab_merged.cc:109 > #9 0x0809bcf2 in MergedTable::delete_route (this=0x82b6bd8, > route=0x82b6bf0, caller=0x82b5f20) at rt_tab_merged.cc:109 > #10 0x080597e1 in RedistTable::delete_route (this=0x82b5f20, > r=0x82b6bf0, caller=0x82b60d0) at rt_tab_redist.cc:445 > #11 0x0809f470 in OriginTable::delete_route (this=0x82b60d0, > net=@0x82b1200) at rt_tab_origin.cc:131 > #12 0x08086604 in RIB::delete_route (this=0xbfdac034, > tablename=@0x82b5ea0, net=@0x82b1200) at rib.cc:878 > #13 0x08066379 in XrlRibTarget::rib_0_1_delete_route4 (this=0xbfdac3d8, > protocol=@0x82b5ea0, unicast=@0x82b6a7c, multicast=@0x82b1224, > network=@0x82b1200) at xrl_target.cc:581 > #14 0x0811c335 in XrlRibTargetBase::handle_rib_0_1_delete_route4 > (this=0xbfdac3d8, xa_inputs=@0xbfda3eac) at rib_base.cc:855 > #15 0x0811d203 in XorpMemberCallback2B0 XrlRibTargetBase, XrlArgs const&, XrlArgs*>::dispatch (this=0x829f1b0, > a1=@0xbfda3eac, a2=0xbfda3e90) at ../../libxorp/callback_nodebug.hh:4615 > #16 0x08190339 in XrlCmdEntry::dispatch (this=0x829f204, > inputs=@0xbfda3eac, outputs=0xbfda3e90) at xrl_cmd_map.hh:37 > #17 0x08196f5a in XrlDispatcher::dispatch_xrl (this=0xbfdac638, > method_name=@0xbfda3e20, inputs=@0xbfda3eac, outputs=@0xbfda3e90) > at xrl_dispatcher.cc:60 > ... > (gdb) print *found->_vif > $9 = {_vptr.Vif = 0x4d0a322e, _name = {static npos = 4294967295, > _M_dataplus = {> = > {<__gnu_cxx::new_allocator> = {}, }, > _M_p = 0x79546773
}}, _ifname = > {static npos = 4294967295, > _M_dataplus = {> = > {<__gnu_cxx::new_allocator> = {}, }, > _M_p = 0x78206570
}}, _pif_index > = 1902465802, _vif_index = 840986446, _is_pim_register = 55, > _is_p2p = 49, _is_loopback = 55, _is_discard = 10, _is_unreachable = > 77, _is_multicast_capable = 115, _is_broadcast_capable = 103, > _is_underlying_vif_up = 68, _mtu = 543257697, _addr_list = > { >> = { > _M_impl = { >> = > {<__gnu_cxx::new_allocator >> = { fields>}, }, _M_node = {_M_next = 0x646e6966, _M_prev = > 0x2f3a7265}}}, }} > (gdb) > > 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 digravin at umn.edu Mon Sep 24 14:18:33 2007 From: digravin at umn.edu (Frank DiGravina) Date: Mon, 24 Sep 2007 16:18:33 -0500 Subject: [Xorp-users] XORP checks out after 210 seconds!! Message-ID: <46F829A9.1000400@umn.edu> All, We have pim neighbors between a Juniper m10 and a generic unix box (GUB) running XORP. The Juniper is the rendez-vous point (RP). The GUB sources a transmission, which is visible across the RP. What is being noticed is that the transmission stops after 210 seconds - predictably. The pim logs from the downstream side include the folowing: [ 2007/09/24 12:43:56 TRACE xorp_pimsm4 PIM ] RX WHOLEPKT signal from MFEA_4: vif_index = 3 src = 138.236.128.60 dst = 233.67.82.80 len = 1344 [ 2007/09/24 12:43:56 WARNING xorp_pimsm4 PIM ] RX WHOLEPKT signal from MFEA_4: vif_index = 3 src = 138.236.128.60 dst = 233.67.82.80 len = 1344: no RPF inte rface toward the RP (146.57.248.194) [ 2007/09/24 12:43:56 TRACE xorp_pimsm4 PIM ] RX WHOLEPKT signal from MFEA_4: vif_index = 3 src = 138.236.128.60 dst = 233.67.82.80 len = 1344 [ 2007/09/24 12:43:56 WARNING xorp_pimsm4 PIM ] RX WHOLEPKT signal from MFEA_4: vif_index = 3 src = 138.236.128.60 dst = 233.67.82.80 len = 1344: no RPF inte rface toward the RP (146.57.248.194) The last message is interesting but may not have any significance. Any ideas? Cordially, Frank -- Frank DiGravina University of Minnesota Networking & Telecommunications Network Operations Phone: 612-626-9074 Cell: 612-386-0449 E-Mail: digravin at umn.edu Helpline: 612-301-HELP From pavlin at icir.org Mon Sep 24 14:38:13 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Mon, 24 Sep 2007 14:38:13 -0700 Subject: [Xorp-users] XORP checks out after 210 seconds!! In-Reply-To: Message from Frank DiGravina of "Mon, 24 Sep 2007 16:18:33 CDT." <46F829A9.1000400@umn.edu> Message-ID: <200709242138.l8OLcD4j069315@possum.icir.org> > We have pim neighbors between a Juniper m10 and a generic unix box (GUB) > running > XORP. The Juniper is the rendez-vous point (RP). The GUB sources a > transmission, > which is visible across the RP. What is being noticed is that the > transmission stops after > 210 seconds - predictably. The pim logs from the downstream side > include the folowing: > > [ 2007/09/24 12:43:56 TRACE xorp_pimsm4 PIM ] RX WHOLEPKT signal from > MFEA_4: vif_index = 3 src = 138.236.128.60 dst = 233.67.82.80 len = 1344 > [ 2007/09/24 12:43:56 WARNING xorp_pimsm4 PIM ] RX WHOLEPKT signal from > MFEA_4: vif_index = 3 src = 138.236.128.60 dst = 233.67.82.80 len = > 1344: no RPF inte > rface toward the RP (146.57.248.194) > [ 2007/09/24 12:43:56 TRACE xorp_pimsm4 PIM ] RX WHOLEPKT signal from > MFEA_4: vif_index = 3 src = 138.236.128.60 dst = 233.67.82.80 len = 1344 > [ 2007/09/24 12:43:56 WARNING xorp_pimsm4 PIM ] RX WHOLEPKT signal from > MFEA_4: vif_index = 3 src = 138.236.128.60 dst = 233.67.82.80 len = > 1344: no RPF inte > rface toward the RP (146.57.248.194) > > The last message is interesting but may not have any significance. Actually the "no RPF interface toward the RP" message is directly related to the problem. It indicates that the XORP box has no RPF interface toward the RP that can be used to send the encapsulated PIM Register packets with the original multicast data. I presume you have fib2mrib enabled in your configuration. What unicast routing do you use for XORP to learn the route toward the RP? Also, could you check the output of "show pim mrib" before and after the problem occurs. Eventually there should be a mrib entry to the RP before the problem occurs, but this entry has probably disappeared after 210 seconds. If this is the case, the next step is to track why the entry has disappeared. For that you have to look into the unicast routing which should be providing that entry. Regards, Pavlin > Any ideas? > > Cordially, > Frank > > -- > Frank DiGravina > University of Minnesota > Networking & Telecommunications > Network Operations > Phone: 612-626-9074 > Cell: 612-386-0449 > E-Mail: digravin at umn.edu > Helpline: 612-301-HELP > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From greearb at candelatech.com Tue Sep 25 09:43:31 2007 From: greearb at candelatech.com (Ben Greear) Date: Tue, 25 Sep 2007 09:43:31 -0700 Subject: [Xorp-users] xorp_rib SEGV when removing interface while using OSPF. In-Reply-To: <200709241713.l8OHD13q067018@possum.icir.org> References: <200709241713.l8OHD13q067018@possum.icir.org> Message-ID: <46F93AB3.6090603@candelatech.com> Pavlin Radoslavov wrote: > Ben Greear wrote: > >> While testing removing interfaces & OSPF, I get a core from rib_xorp. >> The backtrace shows that >> the net object has a _vif that is bad memory (ie, already deleted as far >> as I can tell.) >> >> I believe it might be because of this code in rib.cc. It is cleaning >> out all of the >> 'directly connected' routes, but maybe it is not cleaning up OSPF routes? >> >> Since we are deleting the vif object, I think we should notify all >> tables that the >> vif is being deleted and have it delete any route that references the >> vif, regardless >> of what IP the route is. Otherwise, stale memory will be referenced >> next time >> something messes with the routes on the dead interface. > > Without looking into all details, I think your intuition is right. > Could you open a Bugzilla entry for the issue and include > instuctions how to reproduce the issue. Without such instructions it > will be much more difficult to track and fix the issue. A great many things fail when you try to add/remove interfaces and/or addresses, at least when using OSPF. I think you will find bugs in almost any action you take, so it's not really worth writing a detailed bug at this point. (Try just changing an IP address w/out doing a commit between the remove and the add of the new IP, for instance.) Try a 'commit' and wonder why it takes multiple seconds to complete, etc. I will work on this crash bug and others as time permits. Due to the fun of CVS, it's difficult for me to send you specific change-sets, but if you can put the 'unreachable' patch into CVS I can send you a new diff with my other changes. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From kulkarni at research.ge.com Tue Sep 25 12:34:57 2007 From: kulkarni at research.ge.com (Amit B Kulkarni) Date: Tue, 25 Sep 2007 15:34:57 -0400 Subject: [Xorp-users] XORP checks out after 210 seconds!! In-Reply-To: References: Message-ID: <46F962E1.3010203@research.ge.com> What is probably happening is that one of your multicast nodes is sending a "Delete Multicast membership" message to the multicast router after exactly 210 seconds. This may be because PIM has a default timeout of 210 seconds for membership entries . Somehow, the multicast receivers are not sending a refresh (MLD QUERY/MEMBERSHIP REPORT packet?) to the multicast router causing the router to drop the entry from its MFC table and terminate the session. - Amit Research Scientist GE Global Research > Message: 1 > Date: Mon, 24 Sep 2007 16:18:33 -0500 > From: Frank DiGravina > Subject: [Xorp-users] XORP checks out after 210 seconds!! > To: Xorp-users at xorp.org > Message-ID: <46F829A9.1000400 at umn.edu> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > All, > > We have pim neighbors between a Juniper m10 and a generic unix box (GUB) > running > XORP. The Juniper is the rendez-vous point (RP). The GUB sources a > transmission, > which is visible across the RP. What is being noticed is that the > transmission stops after > 210 seconds - predictably. The pim logs from the downstream side > include the folowing: > > [ 2007/09/24 12:43:56 TRACE xorp_pimsm4 PIM ] RX WHOLEPKT signal from > MFEA_4: vif_index = 3 src = 138.236.128.60 dst = 233.67.82.80 len = 1344 > [ 2007/09/24 12:43:56 WARNING xorp_pimsm4 PIM ] RX WHOLEPKT signal from > MFEA_4: vif_index = 3 src = 138.236.128.60 dst = 233.67.82.80 len = > 1344: no RPF inte > rface toward the RP (146.57.248.194) > [ 2007/09/24 12:43:56 TRACE xorp_pimsm4 PIM ] RX WHOLEPKT signal from > MFEA_4: vif_index = 3 src = 138.236.128.60 dst = 233.67.82.80 len = 1344 > [ 2007/09/24 12:43:56 WARNING xorp_pimsm4 PIM ] RX WHOLEPKT signal from > MFEA_4: vif_index = 3 src = 138.236.128.60 dst = 233.67.82.80 len = > 1344: no RPF inte > rface toward the RP (146.57.248.194) > > The last message is interesting but may not have any significance. > > Any ideas? > > Cordially, > Frank > > From greearb at candelatech.com Tue Sep 25 16:22:11 2007 From: greearb at candelatech.com (Ben Greear) Date: Tue, 25 Sep 2007 16:22:11 -0700 Subject: [Xorp-users] xorp_rib SEGV when removing interface while using OSPF. In-Reply-To: <200709241713.l8OHD13q067018@possum.icir.org> References: <200709241713.l8OHD13q067018@possum.icir.org> Message-ID: <46F99823.9050603@candelatech.com> Pavlin Radoslavov wrote: > Without looking into all details, I think your intuition is right. > Could you open a Bugzilla entry for the issue and include > instuctions how to reproduce the issue. Without such instructions it > will be much more difficult to track and fix the issue. I started looking into this code today, and it appears quite difficult to properly clean up the various routing table structures that hold references to Vifs. What do you think about removing the _vif pointer from RouteEntry and just using vifname and/or ifname strings? If we ever really need an vif object, can look it up then in the rib's global list? Another option would be to use a reference counting scheme, but those usually suck to code & debug, especially when templates are involved... Any suggestions? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Wed Sep 26 02:01:07 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 26 Sep 2007 02:01:07 -0700 Subject: [Xorp-users] VLAN support in XORP Message-ID: <200709260901.l8Q9178c004775@possum.icir.org> All, The first-cut VLAN support is now committed in the CVS tree. Below is some high-level information about the current configuration mechanism. Nothing is final so here is your chance to suggest improvements or alternative solutions. Currently, the configuration looks like: interfaces { interface fxp0 { vif vlan10 { vlan { vlan-id: 10 } address 10.10.10.10 { ... } ... } } } I.e., the "vlan {}" block inside the "vif {}" block is used to identify the vif as a VLAN and to apply the VLAN-specific configuration. For now the VLAN-specific configuration is only the VLAN ID. The topic what the VLAN configuration should look like has been discussed in the past. E.g., see the long "Some thoughts" thread from November 2005: http://mailman.icsi.berkeley.edu/pipermail/xorp-hackers/2005-November/thread.html However, at the end it didn't seem there was a concensus what the final solution should look like. To add yet another possible solution, my personal preference and my original intention was to use configuration like the following: interfaces { interface fxp0 { vlan vlan10 { vlan-id: 10 address 10.10.10.10 { ... } ... } } } In both cases the protocols' configuration will remain same as is now and won't need any changes: protocols { rip { interface fxp0 { vif vlan10 { ... } } ... } } I don't want to go into details comparing those two solutions (or some of the solutions proposed in the November 2005 thread), because this can become a very long subject. At the end I agreed with Atanu to start with the first solution for the simple reason that the delta to the interfaces.tp is much smaller so it is obvious what needs to be moved around if at the end we decide to change it to something else. Each solution has some pros and cons so I think at the end we should choose something that is practical and works reasonably well instead of beating the subject to death. In term of VLAN naming, the situation is the following. In FreeBSD (and I believe in other BSDs as well, but I haven't double-checked it yet), the vlan name has to be "vlan%d". However, the integer after "vlan" doesn't need to match the VLAN ID. E.g., vlan10 could have VLAN ID of, say, 20. In Linux the naming scheme can be programmed in advance using ioctl(SET_VLAN_NAME_TYPE_CMD). The choices are names like: (a) vlan0005 (b) eth1.0005 (c) vlan5 (d) eth0.5 Unlike FreeBSD, in Linux the integer value at the end of the name must match the VLAN ID. I believe (d) is the default naming scheme (where eth0 is the parent interface). However, for consistency with BSD and for naming clarity, currently the FEA explicitly selects (c) as the naming scheme. Therefore the sample configuration in the beginning of this email should work for both BSD and Linux (except that in Linux "fxp0" needs to be replaced with the parent interface name, say, "eth0"). If someone has suggestions or preferences what the configuration should look like now is the time to speak. The same applies for the choice of the naming scheme in Linux. Thanks, Pavlin P.S. Currently the protocols haven't been tested yet whether they need any fixes to use the VLAN vifs. P.P.S. Special thanks to Ben Greear for the Linux VLAN implementation in the kernel :) From dan at obluda.cz Wed Sep 26 03:35:25 2007 From: dan at obluda.cz (Dan Lukes) Date: Wed, 26 Sep 2007 12:35:25 +0200 Subject: [Xorp-users] VLAN support in XORP In-Reply-To: <200709260901.l8Q9178c004775@possum.icir.org> References: <200709260901.l8Q9178c004775@possum.icir.org> Message-ID: <46FA35ED.10505@obluda.cz> Pavlin Radoslavov napsal/wrote, On 09/26/07 11:01: > The first-cut VLAN support is now committed in the CVS tree. ... > In term of VLAN naming, the situation is the following. > In FreeBSD (and I believe in other BSDs as well, but I haven't > double-checked it yet), the vlan name has to be "vlan%d". However, > the integer after "vlan" doesn't need to match the VLAN ID. E.g., > vlan10 could have VLAN ID of, say, 20. Unfortunately, no. It is "default" name, but the real interface name can be set to anything the administrator wish. On out network, the number after 'vlan' often match the VLAN ID. But I have interface named DEVILLAN also. You shall not derive any information about interface type nor underlying configuration from it's name. If you need specific information about a interface (as a type, VLAN ID or parent interface), you need to use os-specific routines to obtain it. By the way, configuration file shall contain configuration, not description of the OS that can be obtained from OS itself. Dis-synchronisation between real system configurations and it's description in xorp.conf is common source of problems. I mean - why I need to encode that interface vlan10 is virtual interface derived from parent fxp0 into xorp.conf ? It's information that can be extracted from OS (if you really need it), so it shall be extracted from OS, not from configuration file. The BSD make those informations available for application. I'm sure the Linux does it also as well. Dan -- Dan Lukes SISAL MFF UK AKA: dan at obluda.cz, dan at freebsd.cz, dan at (kolej.)mff.cuni.cz From kristian at spritelink.net Wed Sep 26 05:00:45 2007 From: kristian at spritelink.net (Kristian Larsson) Date: Wed, 26 Sep 2007 14:00:45 +0200 Subject: [Xorp-users] VLAN support in XORP In-Reply-To: <20070926115027.GA89290@spritelink.se> References: <200709260901.l8Q9178c004775@possum.icir.org> <20070926115027.GA89290@spritelink.se> Message-ID: <20070926120045.GA14510@spritelink.se> On Wed, Sep 26, 2007 at 02:01:07AM -0700, Pavlin Radoslavov wrote: > All, > > The first-cut VLAN support is now committed in the CVS tree. > > Below is some high-level information about the current configuration > mechanism. Nothing is final so here is your chance to suggest > improvements or alternative solutions. > > Currently, the configuration looks like: > > interfaces { > interface fxp0 { > vif vlan10 { > vlan { > vlan-id: 10 > } > address 10.10.10.10 { > ... > } > ... > } > } > } What do the actual interface look like if I check with `ifconfig` ? Do I manually have to make sure that the "vif vlan10" section doesn't collide with other interfaces, ie do vlan 10 have to be unique and will XORP or the user keep track of that? > I.e., the "vlan {}" block inside the "vif {}" block is used to > identify the vif as a VLAN and to apply the VLAN-specific > configuration. For now the VLAN-specific configuration is only the > VLAN ID. Can't you put this thing under the main interface, like adding "vlan-tagging" or something? I don't want another two lines of configuration per sub-interface. > To add yet another possible solution, my personal preference and > my original intention was to use configuration like the following: > > interfaces { > interface fxp0 { > vlan vlan10 { > vlan-id: 10 > address 10.10.10.10 { > ... > } > ... > } > } > } I support this one. Having an extra vlan { branch just adds more lines and doesn't really bring anything useful, imho. > In term of VLAN naming, the situation is the following. > In FreeBSD (and I believe in other BSDs as well, but I haven't > double-checked it yet), the vlan name has to be "vlan%d". However, > the integer after "vlan" doesn't need to match the VLAN ID. E.g., > vlan10 could have VLAN ID of, say, 20. I don't think so. I think you can rename the interface to whatever you wish. > In Linux the naming scheme can be programmed in advance using > ioctl(SET_VLAN_NAME_TYPE_CMD). The choices are names like: > (a) vlan0005 > (b) eth1.0005 > (c) vlan5 > (d) eth0.5 > > Unlike FreeBSD, in Linux the integer value at the end of the name > must match the VLAN ID. Are you sure? I'm pretty sure you can rename the interfaces in Linux as well. Let me get back on this. > I believe (d) is the default naming scheme (where eth0 is the parent > interface). > However, for consistency with BSD and for naming clarity, currently > the FEA explicitly selects (c) as the naming scheme. Therefore the > sample configuration in the beginning of this email should work for > both BSD and Linux (except that in Linux "fxp0" needs to be replaced > with the parent interface name, say, "eth0"). Kristian. -- Kristian Larsson KLL-RIPE Network Engineer & Peering Coordinator SpriteLink [AS39525] +46 704 910401 kll at spritelink.net From kristian at spritelink.net Wed Sep 26 05:01:03 2007 From: kristian at spritelink.net (Kristian Larsson) Date: Wed, 26 Sep 2007 14:01:03 +0200 Subject: [Xorp-users] VLAN support in XORP In-Reply-To: <20070926115750.GA14437@spritelink.se> References: <200709260901.l8Q9178c004775@possum.icir.org> <20070926115750.GA14437@spritelink.se> Message-ID: <20070926120102.GB14510@spritelink.se> Uhh, I'm tired today.. I totally forgot... ;) I am very very pleased to see XORPs new support for VLANs. It's a big leap forward in the ease of use of the suite. From what I understand it's mostly thanks to Pavling - great work, keep it up :) Kristian. -- Kristian Larsson KLL-RIPE Network Engineer & Peering Coordinator SpriteLink [AS39525] +46 704 910401 kll at spritelink.net From greearb at candelatech.com Wed Sep 26 08:47:14 2007 From: greearb at candelatech.com (Ben Greear) Date: Wed, 26 Sep 2007 08:47:14 -0700 Subject: [Xorp-users] VLAN support in XORP In-Reply-To: <200709260901.l8Q9178c004775@possum.icir.org> References: <200709260901.l8Q9178c004775@possum.icir.org> Message-ID: <46FA7F02.8010306@candelatech.com> Pavlin Radoslavov wrote: > If someone has suggestions or preferences what the configuration > should look like now is the time to speak. > The same applies for the choice of the naming scheme in Linux. > Maybe let the user use any name they want in the config file, and have xorp rename the interface as needed? You can rename interfaces in Linux. You can find all of the pertinent VLAN info in Linux with IOCTL calls (and coming soon in .23, netlink calls.) THanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Wed Sep 26 10:02:07 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 26 Sep 2007 10:02:07 -0700 Subject: [Xorp-users] VLAN support in XORP In-Reply-To: Message from Dan Lukes of "Wed, 26 Sep 2007 12:35:25 +0200." <46FA35ED.10505@obluda.cz> Message-ID: <200709261702.l8QH28Z4009365@possum.icir.org> Dan Lukes wrote: > Pavlin Radoslavov napsal/wrote, On 09/26/07 11:01: > > The first-cut VLAN support is now committed in the CVS tree. > ... > > In term of VLAN naming, the situation is the following. > > In FreeBSD (and I believe in other BSDs as well, but I haven't > > double-checked it yet), the vlan name has to be "vlan%d". However, > > the integer after "vlan" doesn't need to match the VLAN ID. E.g., > > vlan10 could have VLAN ID of, say, 20. > > Unfortunately, no. It is "default" name, but the real interface name > can be set to anything the administrator wish. > > On out network, the number after 'vlan' often match the VLAN ID. But I > have interface named DEVILLAN also. What system are you using? On FreeBSD-6.2 the name of the interface that is created by the user needs to follow some pattern. As you can see from the example below, both "vlanfoo" and "DEVILLAN" couldn't be created, but the "vlan51" creation was successful: root at xorp13[1] ifconfig vlanfoo create ifconfig: SIOCIFCREATE: Invalid argument Exit 1 root at xorp13[2] ifconfig DEVILLAN create ifconfig: SIOCIFCREATE: Invalid argument Exit 1 root at xorp13[3] ifconfig vlan51 create root at xorp13[4] > You shall not derive any information about interface type nor > underlying configuration from it's name. > > If you need specific information about a interface (as a type, VLAN ID > or parent interface), you need to use os-specific routines to obtain it. Actually this is exactly how it is done currently inside the FEA. We try to use only OS-specific routines to configure VLANs, etc. The VLAN naming restrictions I described above are imposed by the OS itself. Currently, the model in XORP is to use same VLAN name in the XORP configuration as it would appear in the system. The reason for this is to avoid any confusion if you are looking into the XORP configuration and by using system tool like "ifconfig". > By the way, configuration file shall contain configuration, not > description of the OS that can be obtained from OS itself. > Dis-synchronisation between real system configurations and it's > description in xorp.conf is common source of problems. > > I mean - why I need to encode that interface vlan10 is virtual > interface derived from parent fxp0 into xorp.conf ? It's information > that can be extracted from OS (if you really need it), so it shall be > extracted from OS, not from configuration file. The BSD make those > informations available for application. I'm sure the Linux does it also > as well. Probably I don't understand your question here, but when you create a VLAN you need to explicitly specify two things: its parent interface and its VLAN ID. The same is true even if you use UNIX command line tools. E.g., in case of FreeBSD-6.2 you need to do the following: ifconfig vlan0 create ifconfig vlan0 vlan 34 vlandev sk0 ifconfig vlan0 10.11.11.11 netmask 0xffffff00 In XORP, the parent interface information is naturally specified by the virtue of the the "interface/vif" hierarchy. Of course, there are other ways of specifying the parent information, but the point is you (the user) have to do it one way or another. Of course, all this applies in case you want XORP to create the VLANs for you. If you have already created the VLANs before XORP was started, then you can still use them as any other network interface by using configuration like: interfaces { interface vlan10 { vif vlan10 { address 10.10.10.10 { ... } } } } You could do this even without the recent VLAN support in XORP. The new addition to XORP is that you can have XORP itself create the VLANs for you instead of using the system tools. Please let me know if I misunderstand something. Thanks, Pavlin From pavlin at icir.org Wed Sep 26 10:29:36 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 26 Sep 2007 10:29:36 -0700 Subject: [Xorp-users] VLAN support in XORP In-Reply-To: Message from Kristian Larsson of "Wed, 26 Sep 2007 14:00:45 +0200." <20070926120045.GA14510@spritelink.se> Message-ID: <200709261729.l8QHTahd009714@possum.icir.org> Kristian Larsson wrote: > On Wed, Sep 26, 2007 at 02:01:07AM -0700, Pavlin Radoslavov wrote: > > All, > > > > The first-cut VLAN support is now committed in the CVS tree. > > > > Below is some high-level information about the current configuration > > mechanism. Nothing is final so here is your chance to suggest > > improvements or alternative solutions. > > > > Currently, the configuration looks like: > > > > interfaces { > > interface fxp0 { > > vif vlan10 { > > vlan { > > vlan-id: 10 > > } > > address 10.10.10.10 { > > ... > > } > > ... > > } > > } > > } > > > What do the actual interface look like if I check > with `ifconfig` ? There will be interface named "vlan10". E.g., on FreeBSD-6.2 it will look like: root at xorp13[7] ifconfig vlan10 vlan10: flags=8843 mtu 1500 inet 10.10.10.10 netmask 0xffffff00 broadcast 10.10.10.255 inet6 fe80::xxx:xxxx:xxxx:xxxx%vlan10 prefixlen 64 scopeid 0xd ether xx:xx:xx:xx:xx:xx media: Ethernet autoselect (none) status: no carrier vlan: 10 parent interface: fxp0 > Do I manually have to make sure that the "vif > vlan10" section doesn't collide with other > interfaces, ie do vlan 10 have to be unique and > will XORP or the user keep track of that? If the system doesn't allow you to have more than one VLANs with the same name (even if they have different parent interfaces), then you need to manually make sure that there is only one vlan10 in your configuration. E.g., on FreeBSD you cannot have configuration like: interfaces { interface fxp0 { vif vlan10 { vlan { vlan-id: 10 } address 10.10.10.10 { prefix-length: 24 } } } interface sk0 { vif vlan10 { vlan { vlan-id: 10 } address 10.44.44.44 { prefix-length: 24 } } } } > > > I.e., the "vlan {}" block inside the "vif {}" block is used to > > identify the vif as a VLAN and to apply the VLAN-specific > > configuration. For now the VLAN-specific configuration is only the > > VLAN ID. > > Can't you put this thing under the main interface, > like adding "vlan-tagging" or something? > I don't want another two lines of configuration > per sub-interface. We could, but the reason I prefer to have an explicit "vlan {}" block is for clarity. E.g., if we keep the above model, then in the future all VLAN-specific parameters will go to that block rather than cluttering everything together inside the generic "vif {}" block. > > To add yet another possible solution, my personal preference and > > my original intention was to use configuration like the following: > > > > interfaces { > > interface fxp0 { > > vlan vlan10 { > > vlan-id: 10 > > address 10.10.10.10 { > > ... > > } > > ... > > } > > } > > } > > I support this one. > Having an extra vlan { branch just adds more lines > and doesn't really bring anything useful, imho. My preference is also for this one (again, for clarity reason), but I would like to see some rough concensus before making any changes. > > In term of VLAN naming, the situation is the following. > > In FreeBSD (and I believe in other BSDs as well, but I haven't > > double-checked it yet), the vlan name has to be "vlan%d". However, > > the integer after "vlan" doesn't need to match the VLAN ID. E.g., > > vlan10 could have VLAN ID of, say, 20. > > I don't think so. I think you can rename the > interface to whatever you wish. Which OS and OS version? In another email, Dan Lukes said the same thing, but it doesn't seem to be the case for FreeBSD-6.2. > > In Linux the naming scheme can be programmed in advance using > > ioctl(SET_VLAN_NAME_TYPE_CMD). The choices are names like: > > (a) vlan0005 > > (b) eth1.0005 > > (c) vlan5 > > (d) eth0.5 > > > > Unlike FreeBSD, in Linux the integer value at the end of the name > > must match the VLAN ID. > > Are you sure? > I'm pretty sure you can rename the interfaces in > Linux as well. Let me get back on this. I was looking into the ioctl() API (I was reading the source code of vconfig(8) from Ben Greear and I was checking ), but I couldn't see anything that indicates that you could explicitly assign your own VLAN name. Ben, if the Linux ioctl() API allows me to specify the VLAN name to any string, could you tell me the exact API setup I need to use. In my testing I am using Gentoo 2006.1 with 2.6.20 kernel. Thanks, Pavlin > > > I believe (d) is the default naming scheme (where eth0 is the parent > > interface). > > However, for consistency with BSD and for naming clarity, currently > > the FEA explicitly selects (c) as the naming scheme. Therefore the > > sample configuration in the beginning of this email should work for > > both BSD and Linux (except that in Linux "fxp0" needs to be replaced > > with the parent interface name, say, "eth0"). > > > Kristian. > > -- > Kristian Larsson KLL-RIPE > Network Engineer & Peering Coordinator SpriteLink [AS39525] > +46 704 910401 kll at spritelink.net > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at icir.org Wed Sep 26 10:39:14 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 26 Sep 2007 10:39:14 -0700 Subject: [Xorp-users] VLAN support in XORP In-Reply-To: Message from Ben Greear of "Wed, 26 Sep 2007 08:47:14 PDT." <46FA7F02.8010306@candelatech.com> Message-ID: <200709261739.l8QHdERq009878@possum.icir.org> Ben Greear wrote: > Pavlin Radoslavov wrote: > > If someone has suggestions or preferences what the configuration > > should look like now is the time to speak. > > The same applies for the choice of the naming scheme in Linux. > > > Maybe let the user use any name they want in the config file, and have xorp > rename the interface as needed? You can rename interfaces in Linux. Renaming the interfaces internally by XORP is one possibility. The reason we currently chose to keep same name inside the XORP configuration and what you see by "ifconfig" is to make it easier to the user in case they want to match the XORP configuration with the system's view of the interface names. Otherwise we have to provide somewhere a map between those names which makes things more complicated. > You can find all of the pertinent VLAN info in Linux with IOCTL calls > (and coming > soon in .23, netlink calls.) As I mentioned in my earlier email I was looking exactly into the VLAN-related ioctl() API, but I couldn't see any indication that you could use that particular API to change the VLAN name. Could you provide me with an example of how to do that. I wasn't aware of the effort to add VLAN support to Netlink. I was looking into the iproute source code but I didn't see any reference. Please let us know when the Netlink support is available, and we will try to add Netlink-based VLAN plugin at the bottom of the FEA. Thanks, 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 greearb at candelatech.com Wed Sep 26 10:49:38 2007 From: greearb at candelatech.com (Ben Greear) Date: Wed, 26 Sep 2007 10:49:38 -0700 Subject: [Xorp-users] VLAN support in XORP In-Reply-To: <200709261739.l8QHdERq009878@possum.icir.org> References: <200709261739.l8QHdERq009878@possum.icir.org> Message-ID: <46FA9BB2.6090700@candelatech.com> Pavlin Radoslavov wrote: > Renaming the interfaces internally by XORP is one possibility. > The reason we currently chose to keep same name inside the XORP > configuration and what you see by "ifconfig" is to make it easier to > the user in case they want to match the XORP configuration with the > system's view of the interface names. Otherwise we have to provide > somewhere a map between those names which makes things more > complicated. If you rename the interface, it will show up in ifconfig with the new name as well. > As I mentioned in my earlier email I was looking exactly into the > VLAN-related ioctl() API, but I couldn't see any indication that you > could use that particular API to change the VLAN name. > Could you provide me with an example of how to do that. Linux allows any interface to be renamed: [root at fc7-build ~]# ifconfig eth1 eth1 Link encap:Ethernet HWaddr 00:30:48:5B:6E:F1 inet addr:10.0.0.1 Bcast:10.0.0.255 Mask:255.255.255.0 inet6 addr: fe80::230:48ff:fe5b:6ef1/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:20065 errors:0 dropped:0 overruns:0 frame:0 TX packets:119353 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:6722385 (6.4 MiB) TX bytes:9838070 (9.3 MiB) Base address:0x5000 Memory:ed300000-ed320000 [root at fc7-build ~]# ip link set dev eth1 name vlan-sort-of SIOCSIFNAME: Device or resource busy [root at fc7-build ~]# ip link set eth1 down [root at fc7-build ~]# ip link set dev eth1 name vlan-sort-of [root at fc7-build ~]# ifconfig vlan-sort-of vlan-sort-of Link encap:Ethernet HWaddr 00:30:48:5B:6E:F1 inet addr:10.0.0.1 Bcast:10.0.0.255 Mask:255.255.255.0 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:20066 errors:0 dropped:0 overruns:0 frame:0 TX packets:119356 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:6722731 (6.4 MiB) TX bytes:9838316 (9.3 MiB) Base address:0x5000 Memory:ed300000-ed320000 > I wasn't aware of the effort to add VLAN support to Netlink. I was > looking into the iproute source code but I didn't see any reference. > Please let us know when the Netlink support is available, and we > will try to add Netlink-based VLAN plugin at the bottom of the FEA. I think it's in kernel 2.6.23 and the latest iproute package from the git repository. I was just using the similar API to support mac-vlans a few days ago. Here's another idea for you as well: 802.1Q VLANs are just some of the possible virtual interfaces that Xorp could support. Instead of having a vlan { foo } section in your config, you could have something like: interface eth0 virtual-dev vlan0.5 { type: vlan vid: 5 } virtual-dev eth0#0 { type: macvlan mac: 00:11:22:33:44:55 } ... } With the netlink api, you can create the new device with a specified name, so you don't even have to rename it later. Using the 802.1Q VLAN ioctls, you would have to rename it after creation, but you can guess the initial name based on the naming-scheme, VID, and the parent interface. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From dan at obluda.cz Wed Sep 26 10:51:41 2007 From: dan at obluda.cz (Dan Lukes) Date: Wed, 26 Sep 2007 19:51:41 +0200 Subject: [Xorp-users] VLAN support in XORP In-Reply-To: <200709261702.l8QH28Z4009365@possum.icir.org> References: <200709261702.l8QH28Z4009365@possum.icir.org> Message-ID: <46FA9C2D.5030808@obluda.cz> Pavlin Radoslavov napsal/wrote, On 09/26/07 19:02: >> Pavlin Radoslavov napsal/wrote, On 09/26/07 11:01: >> > In FreeBSD (and I believe in other BSDs as well, but I haven't >> > double-checked it yet), the vlan name has to be "vlan%d". However, >> > the integer after "vlan" doesn't need to match the VLAN ID. E.g., >> > vlan10 could have VLAN ID of, say, 20. >> Unfortunately, no. It is "default" name, but the real interface name >> can be set to anything the administrator wish. > What system are you using? > On FreeBSD-6.2 the name of the interface that is created by the user > needs to follow some pattern. > root at xorp13[1] ifconfig vlanfoo create > ifconfig: SIOCIFCREATE: Invalid argument Correct syntax is ifconfig vlan666 name DEVILLAN The 'name' parameter is optional. > The new addition to XORP is that you can have XORP itself create the > VLANs for you instead of using the system tools. > > Please let me know if I misunderstand something. Misunderstanding on my side. Forget it, please. Dan -- Dan Lukes SISAL MFF UK AKA: dan at obluda.cz, dan at freebsd.cz, dan at (kolej.)mff.cuni.cz From kristian at spritelink.net Wed Sep 26 11:23:26 2007 From: kristian at spritelink.net (Kristian Larsson) Date: Wed, 26 Sep 2007 20:23:26 +0200 Subject: [Xorp-users] VLAN support in XORP In-Reply-To: <200709261729.l8QHTahd009714@possum.icir.org> References: <200709261729.l8QHTahd009714@possum.icir.org> Message-ID: <46FAA39E.7070603@spritelink.net> Pavlin Radoslavov wrote: > Kristian Larsson wrote: > >> On Wed, Sep 26, 2007 at 02:01:07AM -0700, Pavlin Radoslavov wrote: >>> All, >>> >>> The first-cut VLAN support is now committed in the CVS tree. >>> >>> Below is some high-level information about the current configuration >>> mechanism. Nothing is final so here is your chance to suggest >>> improvements or alternative solutions. >>> >>> Currently, the configuration looks like: >>> >>> interfaces { >>> interface fxp0 { >>> vif vlan10 { >>> vlan { >>> vlan-id: 10 >>> } >>> address 10.10.10.10 { >>> ... >>> } >>> ... >>> } >>> } >>> } >> >> What do the actual interface look like if I check >> with `ifconfig` ? > > There will be interface named "vlan10". E.g., on FreeBSD-6.2 it will > look like: > > root at xorp13[7] ifconfig vlan10 > vlan10: flags=8843 mtu 1500 > inet 10.10.10.10 netmask 0xffffff00 broadcast 10.10.10.255 > inet6 fe80::xxx:xxxx:xxxx:xxxx%vlan10 prefixlen 64 scopeid 0xd > ether xx:xx:xx:xx:xx:xx > media: Ethernet autoselect (none) > status: no carrier > vlan: 10 parent interface: fxp0 > >> Do I manually have to make sure that the "vif >> vlan10" section doesn't collide with other >> interfaces, ie do vlan 10 have to be unique and >> will XORP or the user keep track of that? > > If the system doesn't allow you to have more than one VLANs with the > same name (even if they have different parent interfaces), then you > need to manually make sure that there is only one vlan10 in your > configuration. E.g., on FreeBSD you cannot have configuration like: > > interfaces { > interface fxp0 { > vif vlan10 { > vlan { > vlan-id: 10 > } > address 10.10.10.10 { > prefix-length: 24 > } > } > } > interface sk0 { > vif vlan10 { > vlan { > vlan-id: 10 > } > address 10.44.44.44 { > prefix-length: 24 > } > } > } > } I think this makes it very difficult to use. Having to make sure that the interface name is unique is a typical task for a computer, not a human :) I'm seeing a configuration with hundreds of interfaces, it would be unbearable. >>> I.e., the "vlan {}" block inside the "vif {}" block is used to >>> identify the vif as a VLAN and to apply the VLAN-specific >>> configuration. For now the VLAN-specific configuration is only the >>> VLAN ID. >> Can't you put this thing under the main interface, >> like adding "vlan-tagging" or something? >> I don't want another two lines of configuration >> per sub-interface. > > We could, but the reason I prefer to have an explicit "vlan {}" > block is for clarity. E.g., if we keep the above model, then in the > future all VLAN-specific parameters will go to that block rather > than cluttering everything together inside the generic "vif {}" > block. I see your point. I'm just fond of "vlan-tagging" directly under vif since that is how Junipers work. In the future I see adding support for inner and outer vlans (ie, QinQ), VLAN rewriting and stuff. I'm not sure how much we should plan for now. A simple way would be to simply duplicate Junipers effort, I can imagine they already put some thought into it and a lot of people are used to how JUNOS works. >>> To add yet another possible solution, my personal preference and >>> my original intention was to use configuration like the following: >>> >>> interfaces { >>> interface fxp0 { >>> vlan vlan10 { >>> vlan-id: 10 >>> address 10.10.10.10 { >>> ... >>> } >>> ... >>> } >>> } >>> } >> I support this one. >> Having an extra vlan { branch just adds more lines >> and doesn't really bring anything useful, imho. > > My preference is also for this one (again, for clarity reason), but > I would like to see some rough concensus before making any changes. > >>> In term of VLAN naming, the situation is the following. >>> In FreeBSD (and I believe in other BSDs as well, but I haven't >>> double-checked it yet), the vlan name has to be "vlan%d". However, >>> the integer after "vlan" doesn't need to match the VLAN ID. E.g., >>> vlan10 could have VLAN ID of, say, 20. >> I don't think so. I think you can rename the >> interface to whatever you wish. > > Which OS and OS version? > In another email, Dan Lukes said the same thing, but it doesn't seem > to be the case for FreeBSD-6.2. I believe you can rename the interface after it has been created. I don't have a FreeBSD machine to test with, right now... >>> In Linux the naming scheme can be programmed in advance using >>> ioctl(SET_VLAN_NAME_TYPE_CMD). The choices are names like: >>> (a) vlan0005 >>> (b) eth1.0005 >>> (c) vlan5 >>> (d) eth0.5 >>> >>> Unlike FreeBSD, in Linux the integer value at the end of the name >>> must match the VLAN ID. >> Are you sure? >> I'm pretty sure you can rename the interfaces in >> Linux as well. Let me get back on this. > > I was looking into the ioctl() API (I was reading the source code of > vconfig(8) from Ben Greear and I was checking ), > but I couldn't see anything that indicates that you could explicitly > assign your own VLAN name. > > Ben, if the Linux ioctl() API allows me to specify the VLAN name to > any string, could you tell me the exact API setup I need to use. > In my testing I am using Gentoo 2006.1 with 2.6.20 kernel. See Ben's mail. I was thinking about the iproute2 functionality for renaming interfaces :) Kristian. From dan at obluda.cz Wed Sep 26 10:53:04 2007 From: dan at obluda.cz (Dan Lukes) Date: Wed, 26 Sep 2007 19:53:04 +0200 Subject: [Xorp-users] VLAN support in XORP In-Reply-To: <200709261702.l8QH28Z4009365@possum.icir.org> References: <200709261702.l8QH28Z4009365@possum.icir.org> Message-ID: <46FA9C80.50603@obluda.cz> > Correct syntax is > ifconfig vlan666 name DEVILLAN No! Correct syntax is ifconfig vlan666 create name DEVILLAN Sorry Dan -- Dan Lukes SISAL MFF UK AKA: dan at obluda.cz, dan at freebsd.cz, dan at (kolej.)mff.cuni.cz From greearb at candelatech.com Wed Sep 26 11:49:42 2007 From: greearb at candelatech.com (Ben Greear) Date: Wed, 26 Sep 2007 11:49:42 -0700 Subject: [Xorp-users] Assert in OSPF when adding interface with mcast-addr already assigned. In-Reply-To: <46F99823.9050603@candelatech.com> References: <200709241713.l8OHD13q067018@possum.icir.org> <46F99823.9050603@candelatech.com> Message-ID: <46FAA9C6.6000105@candelatech.com> I coded up the method of storing a vifname in the route instead of the vif pointer, and that seems to have fixed the rib crash. Now, I am getting an assert in OSPF because it cannot add the multicast address. However, this is because the mcast addr is already on that interface, probably because the code that removes an interface does not clean it up properly. My current plan is to just ignore the error if it is 'address in use'. I think this will be fine, but I am not the best at understanding multicast... Here's the stack trace for reference: #0 0xffffe410 in __kernel_vsyscall () #1 0x46fc1069 in raise () from /lib/libc.so.6 #2 0x46fc2671 in abort () from /lib/libc.so.6 #3 0x08278b65 in xlog_fatal (module_name=Could not find the frame base for "xlog_fatal". ) at xlog.c:435 #4 0x080ed502 in XrlIO::join_multicast_group_cb (this=0xbf9ec96c, xrl_error=@0xbf9e8540, interface=@0xbf9e4580, vif=@0xbf9e457c) at xrl_io.cc:637 #5 0x080ec418 in XorpMemberCallback1B2, XrlError const&, std::string, std::string>::dispatch (this=0x8386f28, a1=@0xbf9e8540) at ../libxorp/callback_nodebug.hh:3060 #6 0x082093b7 in XrlRawPacket4V0p1Client::unmarshall_join_multicast_group (this=0xbf9dc468, e=@0xbf9e8540, a=0xbf9e8530, cb=@0xbf9e652c) at fea_rawpkt4_xif.cc:172 #7 0x0820a841 in XorpMemberCallback2B1 > >::dispatch (this=0x8383e68, a1=@0xbf9e8540, a2=0xbf9e8530) at ../../libxorp/callback_nodebug.hh:4927 #8 0x08231fa3 in XrlRouter::send_callback (this=0xbf9eca94, e=@0xbf9e8540, reply=0xbf9e8530, user_callback=@0xbf9e658c) at xrl_router.cc:365 #9 0x08237823 in XorpMemberCallback2B2 > >::dispatch (this=0x8388550, a1=@0xbf9e8540, a2=0xbf9e8530) at ../libxorp/callback_nodebug.hh:5225 #10 0x082540f9 in XrlPFSTCPSender::read_event (this=0x8386428, ev=BufferedAsyncReader::DATA, buffer=0xb7e69cfe "STCP\001\001", buffer_bytes=140) at xrl_pf_stcp.cc:878 #11 0x08258b24 in XorpMemberCallback4B0::dispatch (this=0x83853a8, a1=0x8385360, a2=BufferedAsyncReader::DATA, a3=0xb7e69cfe "STCP\001\001", a4=140) at ../libxorp/callback_nodebug.hh:8965 #12 0x0827d5bb in BufferedAsyncReader::announce_event (this=0x8385360, ev=BufferedAsyncReader::DATA) at buffered_asyncio.cc:248 #13 0x0827e0d7 in XorpMemberCallback0B1::dispatch ( this=0x83898e0) at ../libxorp/callback_nodebug.hh:597 #14 0x0829495c in OneoffTimerNode2::expire (this=0x8381f48) at timer.cc:184 #15 0x08293892 in TimerList::expire_one (this=0xbf9ec5f4, worst_priority=4) at timer.cc:481 #16 0x082939f6 in TimerList::run (this=0xbf9ec5f4) at timer.cc:428 #17 0x08280044 in EventLoop::run (this=0xbf9ec5f0) at eventloop.cc:114 #18 0x0804c016 in main (argv=0xbf9ecbb4) at xorp_ospfv2.cc:72 (gdb) frame 4 #4 0x080ed502 in XrlIO::join_multicast_group_cb (this=0xbf9ec96c, xrl_error=@0xbf9e8540, interface=@0xbf9e4580, vif=@0xbf9e457c) at xrl_io.cc:637 637 xrl_io.cc: No such file or directory. in xrl_io.cc (gdb) print xrl_error $1 = (const XrlError &) @0xbf9e8540: {_errlet = 0x8364bf8, _note = {static npos = 4294967295, _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x8388d6c "Cannot join group 224.0.0.5 on interface rddVR44 vif rddVR44: Address already in use"}}} Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Wed Sep 26 18:29:28 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Wed, 26 Sep 2007 18:29:28 -0700 Subject: [Xorp-users] Unreachable default route. In-Reply-To: Message from Ben Greear of "Wed, 19 Sep 2007 14:59:59 PDT." <46F19BDF.1000600@candelatech.com> Message-ID: <200709270129.l8R1TSrN044066@possum.icir.org> Ben Greear wrote: > Ok, I think this is working now...patch is attached. > > In addition to the 'unreachable' feature, this also includes the > hack to let the 'static' priority be set though an environment > variable, and a slight modification of the error logging for > receiving pkts not destined for this Xorp's interfaces. > > If it is more convenient, I can cut those extra two things > out of the patch, but I would also be happy if they went into > Xorp proper. I understand the getenv hack is not a long term > solution, but it is better than nothing, and if the variable is > not set, you get the current default behaviour. > > Please look for 'TODO' in the patch, as I had a few questions > as to whether I did it right. It seems to be working right on > Linux: > > 10.2.0.0/24 via 10.0.0.1 dev rddVR1 proto xorp metric 2 notify > 10.0.0.0/24 dev rddVR1 scope link > 10.4.0.0/24 dev rddVR44 scope link > 10.1.0.0/24 via 10.4.0.2 dev rddVR44 proto xorp metric 2 notify > 10.3.0.0/24 via 10.0.0.1 dev rddVR1 proto xorp metric 2 notify > unreachable default proto xorp metric 1 notify > > > cfg-file snippets: > > interfaces { > interface my_discard { > unreachable: true > vif my_discard { > } > } > } > > protocols { > static { > interface-route 0.0.0.0/0 { > next-hop-interface: "my_discard" > next-hop-vif: "my_discard" > } > } > } Ben, I committed your patch modulo some changes as described below: * In your patch there was a reference to RTF_UNREACHABLE. This flag doesn't exist on BSD (actually Web search didn't return any match), so I removed it. * I didn't commit the changes related to the "no vif found" XLOG_WARNING() inside fea/data_plane/io/io_ip_socket.cc for the following two reasons: - Rate-limiting of warning messages should be implemented in a generic way rather than adding extra code everywhere we might have XLOG_WARNING() message. - We don't want to have any hard-coding like "pif_index == 1", because it might be true for Linux, but not in general. Also, someone might be playing with the loopback interface and might want to see the warning messages. Said that, I think my preference is to change the XLOG_WARNING() to XLOG_TRACE() so the log message can be explicitly enabled or disabled as needed. I haven't committed yet the XLOG_TRACE() change, pending to see whether it will work for you. * I didn't commit any of the OSPF changes, because on closer investigation there was no place where the "unreachable" flag for a route was actually set. After discussing it with Atanu, it is not clear what exactly means to have "unreachable" support inside OSPF. According to Atanu, OSPF uses internally the discard routes to add them to the kernel when announcing aggregated routes. If you have something specific in mind with regard to OSPF, please discuss it with Atanu, and after that we can add it to XORP. * I didn't commit the getenv("XORP_RIB_STATIC_DISTANCE") hack, because my preference is that we stay away from such hacks. Adding it in one place will open the door to start doing the same elsewhere. Instead, you should keep pushing on us to implement it properly :) Alternatively, you could submit the patch with the proper solution ;) BTW, I tested it on both Linux and FreeBSD-6.2, and it seems to work. Nice job! Thanks, Pavlin From greearb at candelatech.com Wed Sep 26 20:37:17 2007 From: greearb at candelatech.com (Ben Greear) Date: Wed, 26 Sep 2007 20:37:17 -0700 Subject: [Xorp-users] Unreachable default route. In-Reply-To: <200709270129.l8R1TSrN044066@possum.icir.org> References: <200709270129.l8R1TSrN044066@possum.icir.org> Message-ID: <46FB256D.2090007@candelatech.com> Pavlin Radoslavov wrote: > Ben Greear wrote: > > >> Ok, I think this is working now...patch is attached. >> >> In addition to the 'unreachable' feature, this also includes the >> hack to let the 'static' priority be set though an environment >> variable, and a slight modification of the error logging for >> receiving pkts not destined for this Xorp's interfaces. >> >> If it is more convenient, I can cut those extra two things >> out of the patch, but I would also be happy if they went into >> Xorp proper. I understand the getenv hack is not a long term >> solution, but it is better than nothing, and if the variable is >> not set, you get the current default behaviour. >> >> Please look for 'TODO' in the patch, as I had a few questions >> as to whether I did it right. It seems to be working right on >> Linux: >> >> 10.2.0.0/24 via 10.0.0.1 dev rddVR1 proto xorp metric 2 notify >> 10.0.0.0/24 dev rddVR1 scope link >> 10.4.0.0/24 dev rddVR44 scope link >> 10.1.0.0/24 via 10.4.0.2 dev rddVR44 proto xorp metric 2 notify >> 10.3.0.0/24 via 10.0.0.1 dev rddVR1 proto xorp metric 2 notify >> unreachable default proto xorp metric 1 notify >> >> >> cfg-file snippets: >> >> interfaces { >> interface my_discard { >> unreachable: true >> vif my_discard { >> } >> } >> } >> >> protocols { >> static { >> interface-route 0.0.0.0/0 { >> next-hop-interface: "my_discard" >> next-hop-vif: "my_discard" >> } >> } >> } >> > > Ben, > > I committed your patch modulo some changes as described below: > > * In your patch there was a reference to RTF_UNREACHABLE. > This flag doesn't exist on BSD (actually Web search didn't return > any match), so I removed it. > Ok, sounds fine. > * I didn't commit the changes related to the "no vif found" > XLOG_WARNING() inside fea/data_plane/io/io_ip_socket.cc for the > following two reasons: > - Rate-limiting of warning messages should be implemented in a > generic way rather than adding extra code everywhere we might > have XLOG_WARNING() message. > - We don't want to have any hard-coding like "pif_index == 1", > because it might be true for Linux, but not in general. > Also, someone might be playing with the loopback interface and > might want to see the warning messages. > Said that, I think my preference is to change the XLOG_WARNING() > to XLOG_TRACE() so the log message can be explicitly enabled or > disabled as needed. > I haven't committed yet the XLOG_TRACE() change, pending to see > whether it will work for you. > When I get interface add/deletion working, and the busy-spin in xorpsh fixed, I plan to add bpf filters to the sockets, which should make that error message truly an error. Either way, I can keep a small patch in the code I use if needed. > * I didn't commit any of the OSPF changes, because on closer > investigation there was no place where the "unreachable" flag for > a route was actually set. > After discussing it with Atanu, it is not clear what exactly means > to have "unreachable" support inside OSPF. > According to Atanu, OSPF uses internally the discard routes to add > them to the kernel when announcing aggregated routes. > If you have something specific in mind with regard to OSPF, please > discuss it with Atanu, and after that we can add it to XORP. > Ok, that sounds fine too. > * I didn't commit the getenv("XORP_RIB_STATIC_DISTANCE") hack, > because my preference is that we stay away from such hacks. Adding > it in one place will open the door to start doing the same > elsewhere. > Instead, you should keep pushing on us to implement it properly :) > Alternatively, you could submit the patch with the proper solution ;) > For now, I'll keep the hack in my version of xorp. The interface add/delete problems are of higher priority, but I might get to working on this eventually if you don't beat me to it. > BTW, I tested it on both Linux and FreeBSD-6.2, and it seems to > work. Nice job! > Excellent! Thanks for the help and for accepting the patch! Ben > Thanks, > Pavlin > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From ahmadyudo at yahoo.com Wed Sep 26 20:46:34 2007 From: ahmadyudo at yahoo.com (oduy ahmad) Date: Wed, 26 Sep 2007 20:46:34 -0700 (PDT) Subject: [Xorp-users] xorp ospf6 badpeer Message-ID: <812968.43142.qm@web62002.mail.re1.yahoo.com> hallo iam new on configuring xorp i want to run ospf6 on my bsd box xorp installed via cvs but i have some trouble this is my example configuration root at bakabsd.net# show -all protocols { ospf6 1 { > router-id: 192.168.1.1 ip-router-alert: false area 0.0.0.0 { area-type: "normal" area-range 2001:5c0:9741:779::/64 { advertise: true } > interface xl0 { > link-type: "broadcast" > vif xl0 { > address 2001:5c0:9741:779::1 { > disable: false > } > priority: 128 > hello-interval: 10 > router-dead-interval: 40 > interface-cost: 1 > retransmit-interval: 5 > transit-delay: 1 > passive: false > disable: false > } > } } > area 0.0.0.1 { > area-type: "normal" > area-range 2001:5c0:9741::/64 { > advertise: true > } > interface fxp0 { > link-type: "broadcast" > vif fxp0 { > address 2001:5c0:9741::1 { > disable: false > } > priority: 128 > hello-interval: 10 > router-dead-interval: 40 > interface-cost: 1 > retransmit-interval: 5 > transit-delay: 1 > passive: false > disable: false > } > } > } } } fea { unicast-forwarding6 { disable: false } } interfaces { restore-original-config-on-shutdown: false interface xl0 { disable: false discard: false description: "" vif xl0 { disable: false address 192.168.1.1 { prefix-length: 24 disable: false } address 2001:5c0:9741:779::1 { prefix-length: 64 disable: false } } } } [edit] the problem when commit the "set protocols ospf6 1 area 0.0.0.0 interface xl0 vif xl0" root at bakabsd.net# commit Commit Failed 102 Command failed BadPeer from line 466 of peer_manager.cc: Unable to get link local address for xl0/xl0[edit] and this is xorp_rtrmgr log [root at bakabsd /]# tail -f nohup.out [ 2007/09/04 13:34:37 ERROR xorp_rtrmgr:1287 XRL +55 xrl_pf_factory.cc create_sender ] XrlPFSenderFactory::create failed: XrlPFConstructorError from line 585 of xrl_pf_stcp.cc: Could not connect to 127.0.0.1:54547 [ 2007/09/04 13:34:37 ERROR xorp_rtrmgr:1287 XRL +402 xrl_router.cc send_resolved ] Could not create XrlPFSender for protocol = "stcp" address = "127.0.0.1:54547" [ 2007/09/04 13:34:37 WARNING xorp_rtrmgr:1287 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 "ospfv3" does not exist or is not enabled. [ 2007/09/04 13:34:38 INFO xorp_rtrmgr:1287 RTRMGR +1019 task.cc shutdown ] Shutting down module: policy [ 2007/09/04 13:34:38 WARNING xorp_rtrmgr:1287 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 "policy" does not exist or is not enabled. [ 2007/09/04 13:34:38 WARNING xorp_rtrmgr:1287 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 "policy" does not exist or is not enabled. [ 2007/09/04 13:34:39 INFO xorp_rtrmgr:1287 RTRMGR +1019 task.cc shutdown ] Shutting down module: rib [ 2007/09/04 13:34:39 WARNING xorp_rtrmgr:1287 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 "rib" does not exist or is not enabled. [ 2007/09/04 13:34:39 WARNING xorp_rtrmgr:1287 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 "rib" does not exist or is not enabled. but i tried to run ospf4 and running well when i commit the "set protocols ospf6 1 area 0.0.0.0 interface xl0 vif xl0" running well anyone can help me ? ____________________________________________________________________________________ Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 From atanu at ICSI.Berkeley.EDU Thu Sep 27 08:57:29 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Thu, 27 Sep 2007 08:57:29 -0700 Subject: [Xorp-users] xorp ospf6 badpeer In-Reply-To: Message from oduy ahmad of "Wed, 26 Sep 2007 20:46:34 PDT." <812968.43142.qm@web62002.mail.re1.yahoo.com> Message-ID: <27564.1190908649@tigger.icir.org> Hi, You need to configure the link-local address for vif xl0 as described in the file RELEASE_NOTES. I am working on a patch at the moment so this error will only generate a warning and not be fatal. Atanu. >>>>> "oduy" == oduy ahmad writes: oduy> hallo iam new on configuring xorp oduy> i want to run ospf6 on my bsd box oduy> xorp installed via cvs oduy> but i have some trouble oduy> this is my example configuration oduy> root at bakabsd.net# show -all oduy> protocols { oduy> ospf6 1 { >> router-id: 192.168.1.1 oduy> ip-router-alert: false oduy> area 0.0.0.0 { oduy> area-type: "normal" oduy> area-range 2001:5c0:9741:779::/64 { oduy> advertise: true oduy> } >> interface xl0 { >> link-type: "broadcast" >> vif xl0 { >> address 2001:5c0:9741:779::1 { >> disable: false >> } >> priority: 128 >> hello-interval: 10 >> router-dead-interval: 40 >> interface-cost: 1 >> retransmit-interval: 5 >> transit-delay: 1 >> passive: false >> disable: false >> } >> } oduy> } >> area 0.0.0.1 { >> area-type: "normal" >> area-range 2001:5c0:9741::/64 { >> advertise: true >> } >> interface fxp0 { >> link-type: "broadcast" >> vif fxp0 { >> address 2001:5c0:9741::1 { >> disable: false >> } >> priority: 128 >> hello-interval: 10 >> router-dead-interval: 40 >> interface-cost: 1 >> retransmit-interval: 5 >> transit-delay: 1 >> passive: false >> disable: false >> } >> } >> } oduy> } oduy> } oduy> fea { oduy> unicast-forwarding6 { oduy> disable: false oduy> } oduy> } oduy> interfaces { oduy> restore-original-config-on-shutdown: false oduy> interface xl0 { oduy> disable: false oduy> discard: false oduy> description: "" oduy> vif xl0 { oduy> disable: false oduy> address 192.168.1.1 { oduy> prefix-length: 24 oduy> disable: false oduy> } oduy> address 2001:5c0:9741:779::1 { oduy> prefix-length: 64 oduy> disable: false oduy> } oduy> } oduy> } oduy> } oduy> [edit] oduy> the problem when commit the "set protocols ospf6 1 oduy> area 0.0.0.0 interface xl0 vif xl0" oduy> root at bakabsd.net# commit oduy> Commit Failed oduy> 102 Command failed BadPeer from line 466 of oduy> peer_manager.cc: Unable to get link local address for oduy> xl0/xl0[edit] oduy> and this is xorp_rtrmgr log oduy> [root at bakabsd /]# tail -f nohup.out oduy> [ 2007/09/04 13:34:37 ERROR xorp_rtrmgr:1287 XRL +55 oduy> xrl_pf_factory.cc create_sender ] oduy> XrlPFSenderFactory::create failed: oduy> XrlPFConstructorError from line 585 of xrl_pf_stcp.cc: oduy> Could not connect to 127.0.0.1:54547 oduy> [ 2007/09/04 13:34:37 ERROR xorp_rtrmgr:1287 XRL +402 oduy> xrl_router.cc send_resolved ] Could not create oduy> XrlPFSender for protocol = "stcp" address = oduy> "127.0.0.1:54547" oduy> [ 2007/09/04 13:34:37 WARNING xorp_rtrmgr:1287 oduy> XrlFinderTarget +406 ../xrl/targets/finder_base.cc oduy> handle_finder_0_2_resolve_xrl ] Handling method for oduy> finder/0.2/resolve_xrl failed: XrlCmdError 102 Command oduy> failed Target "ospfv3" does not exist or is not oduy> enabled. oduy> [ 2007/09/04 13:34:38 INFO xorp_rtrmgr:1287 RTRMGR oduy> +1019 task.cc shutdown ] Shutting down module: policy oduy> [ 2007/09/04 13:34:38 WARNING xorp_rtrmgr:1287 oduy> XrlFinderTarget +406 ../xrl/targets/finder_base.cc oduy> handle_finder_0_2_resolve_xrl ] Handling method for oduy> finder/0.2/resolve_xrl failed: XrlCmdError 102 Command oduy> failed Target "policy" does not exist or is not oduy> enabled. oduy> [ 2007/09/04 13:34:38 WARNING xorp_rtrmgr:1287 oduy> XrlFinderTarget +406 ../xrl/targets/finder_base.cc oduy> handle_finder_0_2_resolve_xrl ] Handling method for oduy> finder/0.2/resolve_xrl failed: XrlCmdError 102 Command oduy> failed Target "policy" does not exist or is not oduy> enabled. oduy> [ 2007/09/04 13:34:39 INFO xorp_rtrmgr:1287 RTRMGR oduy> +1019 task.cc shutdown ] Shutting down module: rib oduy> [ 2007/09/04 13:34:39 WARNING xorp_rtrmgr:1287 oduy> XrlFinderTarget +406 ../xrl/targets/finder_base.cc oduy> handle_finder_0_2_resolve_xrl ] Handling method for oduy> finder/0.2/resolve_xrl failed: XrlCmdError 102 Command oduy> failed Target "rib" does not exist or is not enabled. oduy> [ 2007/09/04 13:34:39 WARNING xorp_rtrmgr:1287 oduy> XrlFinderTarget +406 ../xrl/targets/finder_base.cc oduy> handle_finder_0_2_resolve_xrl ] Handling method for oduy> finder/0.2/resolve_xrl failed: XrlCmdError 102 Command oduy> failed Target "rib" does not exist or is not enabled. oduy> but i tried to run ospf4 and running well oduy> when i commit the "set protocols ospf6 1 area 0.0.0.0 oduy> interface xl0 vif xl0" running well oduy> anyone can help me ? oduy> ____________________________________________________________________________________ oduy> Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 oduy> _______________________________________________ oduy> Xorp-users mailing list oduy> Xorp-users at xorp.org oduy> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From greearb at candelatech.com Thu Sep 27 09:36:51 2007 From: greearb at candelatech.com (Ben Greear) Date: Thu, 27 Sep 2007 09:36:51 -0700 Subject: [Xorp-users] Patch for making it harder to crash rib when removing interfaces. Message-ID: <46FBDC23.5050508@candelatech.com> Attached is a patch that helps keep from referencing stale Vif pointers in routes when deleting interfaces. This may only be trigerable when you have non-local routes (ie, those generated by OSPF). There are a couple of other changes related to removing interfaces. I still don't have this working, and these patches are not necessarily correct. In particular, the rib changes probably should search all of the RIB tables for interfaces if it is not found in the unicast ipv4 table. Or, keep a separate list of Vifs outside of the routing table structures. Please let me know what you think. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -------------- next part -------------- A non-text attachment was scrubbed... Name: xorp2.patch Type: text/x-patch Size: 13235 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070927/6e0fdcd1/attachment-0001.bin From pavlin at icir.org Thu Sep 27 10:32:10 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 27 Sep 2007 10:32:10 -0700 Subject: [Xorp-users] VLAN support in XORP In-Reply-To: Message from Dan Lukes of "Wed, 26 Sep 2007 19:53:04 +0200." <46FA9C80.50603@obluda.cz> Message-ID: <200709271732.l8RHWAxM002090@possum.icir.org> > > Correct syntax is > > ifconfig vlan666 name DEVILLAN > > No! > > Correct syntax is > ifconfig vlan666 create name DEVILLAN Thank you for the info. Now the FEA uses that mechanism so it has support for VLAN interface renaming for both FreeBSD and Linux. For the record, the mechanism is ioctl(SIOCSIFNAME) though FreeBSD and Linux use slightly different argument setup. Also, interface renaming might not always exist so the user-selectable name might not always work. E.g., ioctl(SIOCSIFNAME) doesn't exist for NetBSD (as of NetBSD-3.1) and OpenBSD (as of OpenBSD-4.1) and older FreeBSD such as FreeBSD-4.10. Regards, Pavlin From pavlin at icir.org Thu Sep 27 11:16:54 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 27 Sep 2007 11:16:54 -0700 Subject: [Xorp-users] VLAN support in XORP In-Reply-To: Message from Ben Greear of "Wed, 26 Sep 2007 10:49:38 PDT." <46FA9BB2.6090700@candelatech.com> Message-ID: <200709271816.l8RIGsA7002439@possum.icir.org> > > As I mentioned in my earlier email I was looking exactly into the > > VLAN-related ioctl() API, but I couldn't see any indication that you > > could use that particular API to change the VLAN name. > > Could you provide me with an example of how to do that. > > Linux allows any interface to be renamed: Thanks for the info. Now the FEA supports VLAN interface renaming. > > I wasn't aware of the effort to add VLAN support to Netlink. I was > > looking into the iproute source code but I didn't see any reference. > > Please let us know when the Netlink support is available, and we > > will try to add Netlink-based VLAN plugin at the bottom of the FEA. > > I think it's in kernel 2.6.23 and the latest iproute package from the > git repository. I was just using the similar API to support mac-vlans > a few days ago. Hmmm, it seems 2.6.23 is not released yet. As of today, the latest kernel available from http://www.kernel.org/ is 2.6.22.9. I think I will wait until it is released before looking into the Netlink-based VLAN support. For the time being the ioctl()-based support should be sufficient. > Here's another idea for you as well: > > 802.1Q VLANs are just some of the possible virtual interfaces > that Xorp could support. Instead of having a vlan { foo } section > in your config, you could have something like: > > interface eth0 > virtual-dev vlan0.5 { > type: vlan > vid: 5 > } > virtual-dev eth0#0 { > type: macvlan > mac: 00:11:22:33:44:55 > } > ... > } If you replace "virtual-dev" with "vif" then we get the current structure we have. Then the question is whether the vif type-specific attributes are all together at the vif level or grouped in child nodes like "vlan {}" and "macvlan {}". I will wait a bit longer for other suggestions before choosing between those two solutions. > With the netlink api, you can create the new device with a specified > name, so you don't even have to rename it later. Using the 802.1Q VLAN > ioctls, you would have to rename it after creation, but you can guess the > initial name based on the naming-scheme, VID, and the parent interface. Indeed this is exactly what I did with the ioctl() solution and it seems to work fine. Thanks, Pavlin From pavlin at icir.org Thu Sep 27 11:26:54 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 27 Sep 2007 11:26:54 -0700 Subject: [Xorp-users] VLAN support in XORP In-Reply-To: Message from Kristian Larsson of "Wed, 26 Sep 2007 20:23:26 +0200." <46FAA39E.7070603@spritelink.net> Message-ID: <200709271826.l8RIQsbP002624@possum.icir.org> > > If the system doesn't allow you to have more than one VLANs with the > > same name (even if they have different parent interfaces), then you > > need to manually make sure that there is only one vlan10 in your > > configuration. E.g., on FreeBSD you cannot have configuration like: > > > > interfaces { > > interface fxp0 { > > vif vlan10 { > > vlan { > > vlan-id: 10 > > } > > address 10.10.10.10 { > > prefix-length: 24 > > } > > } > > } > > interface sk0 { > > vif vlan10 { > > vlan { > > vlan-id: 10 > > } > > address 10.44.44.44 { > > prefix-length: 24 > > } > > } > > } > > } > > > I think this makes it very difficult to use. Having to make sure that > the interface name is unique is a typical task for a computer, not a > human :) > I'm seeing a configuration with hundreds of interfaces, it would be > unbearable. How is it different from, say, using directly the UNIX tools to create VLANs and making sure each one will have an unique name. > >>> I.e., the "vlan {}" block inside the "vif {}" block is used to > >>> identify the vif as a VLAN and to apply the VLAN-specific > >>> configuration. For now the VLAN-specific configuration is only the > >>> VLAN ID. > >> Can't you put this thing under the main interface, > >> like adding "vlan-tagging" or something? > >> I don't want another two lines of configuration > >> per sub-interface. > > > > We could, but the reason I prefer to have an explicit "vlan {}" > > block is for clarity. E.g., if we keep the above model, then in the > > future all VLAN-specific parameters will go to that block rather > > than cluttering everything together inside the generic "vif {}" > > block. > > I see your point. > I'm just fond of "vlan-tagging" directly under vif since that is how > Junipers work. > In the future I see adding support for inner and outer vlans (ie, QinQ), > VLAN rewriting and stuff. I'm not sure how much we should plan for now. > A simple way would be to simply duplicate Junipers effort, I can imagine > they already put some thought into it and a lot of people are used to > how JUNOS works. I see. I am not strongly opposed against moving the stuff from the "vlan {}" block to its parent "vif {}" block, so lets wait and see if there are other alternative proposals. After that we can decide whether we should do the change. Thanks, Pavlin From pavlin at icir.org Thu Sep 27 13:00:40 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 27 Sep 2007 13:00:40 -0700 Subject: [Xorp-users] Unreachable default route. In-Reply-To: Message from Ben Greear of "Wed, 26 Sep 2007 20:37:17 PDT." <46FB256D.2090007@candelatech.com> Message-ID: <200709272000.l8RK0eUg003417@possum.icir.org> > > * I didn't commit the changes related to the "no vif found" > > XLOG_WARNING() inside fea/data_plane/io/io_ip_socket.cc for the > > following two reasons: > > - Rate-limiting of warning messages should be implemented in a > > generic way rather than adding extra code everywhere we might > > have XLOG_WARNING() message. > > - We don't want to have any hard-coding like "pif_index == 1", > > because it might be true for Linux, but not in general. > > Also, someone might be playing with the loopback interface and > > might want to see the warning messages. > > Said that, I think my preference is to change the XLOG_WARNING() > > to XLOG_TRACE() so the log message can be explicitly enabled or > > disabled as needed. > > I haven't committed yet the XLOG_TRACE() change, pending to see > > whether it will work for you. > > > When I get interface add/deletion working, and the busy-spin in xorpsh > fixed, > I plan to add bpf filters to the sockets, which should make that error > message > truly an error. Either way, I can keep a small patch in the code I use > if needed. >From educational purpose I'd be interested to see what the particular BPF filters will look like. However, as I mentioned in some of the earlier emails on the subject I still need to be convinced (with numbers) that this is a bottleneck issue. The numbers I am looking at is something along the lines: currently there could be up to X concurrently XORP instances. With BPF filters the number is X*Y (where Y should be larger than 1.0 :) If there is no practical difference then there is no point of adding the extra complexity. Also, I'd prefer there is a generic solution that can be applied, because BPF might not always be available. > > * I didn't commit the getenv("XORP_RIB_STATIC_DISTANCE") hack, > > because my preference is that we stay away from such hacks. Adding > > it in one place will open the door to start doing the same > > elsewhere. > > Instead, you should keep pushing on us to implement it properly :) > > Alternatively, you could submit the patch with the proper solution ;) > > > For now, I'll keep the hack in my version of xorp. The interface > add/delete problems > are of higher priority, but I might get to working on this eventually if > you don't > beat me to it. I don't want to discourage you, but fixing it properly might not be trivial and might require considerable amout of changes and understanding lots of details about RIB (including probably changing the add_route XRL API between the protocols and the RIB). Said that, if it is not high priority for you, your best strategy could be to keep pushing us to do it :) Regards, Pavlin From pavlin at icir.org Thu Sep 27 14:04:52 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 27 Sep 2007 14:04:52 -0700 Subject: [Xorp-users] Patch for making it harder to crash rib when removing interfaces. In-Reply-To: Message from Ben Greear of "Thu, 27 Sep 2007 09:36:51 PDT." <46FBDC23.5050508@candelatech.com> Message-ID: <200709272104.l8RL4qd0004135@possum.icir.org> Ben Greear wrote: > Attached is a patch that helps keep from referencing stale Vif pointers in > routes when > deleting interfaces. This may only be trigerable when you have non-local > routes (ie, > those generated by OSPF). > > There are a couple of other changes related to removing interfaces. I still > don't have > this working, and these patches are not necessarily correct. In particular, > the rib changes > probably should search all of the RIB tables for interfaces if it is not found > in the unicast ipv4 table. > Or, keep a separate list of Vifs outside of the routing table structures. > > Please let me know what you think. The patch seems to be around the introduction of a global RibManager variable "glb_rib_manager" which is a big NO. We try very hard to avoid any global variables, otherwise you lose many (object-oriented) properties. For example, you automatically lose the ability to generate 2+ RIB instances within the same binary. However, the idea of saving the vif name itself instead of a pointer to the Vif instance might be worth considering in case the route class itself needs only the vif name. I am not completely convinced it is the right solution in case, say, some of the code toward the end of the RIB processing needs to look into the status of the Vif before sending a route to the FEA, but is a proposal that should be kept on the table. Let me try to step back and look into the problem from high level. If an interface/vif is deleted from the system, all protocols and RIB will receive the "delete" action from the FEA. I believe all protocols will try to withdraw the routes they sent to RIB if those routes use the deleted interface. The RIB itself will withdraw its own "connected" routes and will remove the Vif instance itself. Therefore, after the Vif instance deletion the "route delete" requests from an unicast routing protocol might refer to the Vif that doesn't exist. Also, the RIB stored routes from those protocols might still be referring to the deleted Vif instance. To solve the problem it needs to be decided who is responsible for deleting the unicast routes that refer to the deleted vif. Currently it is the protocol that added the routes, but this creates a race condition. If the RIB becomes responsible for deleting those routes, then we need to change the route add/delete semantics between the RIB and the routing protocols, because currently the protocols assume they have complete control over the adding/deletion of their own routes. One possible solution of breaking the race condition is to keep the Vif instance around (e.g., marked as DELETED or in some different container) until no RIB routes refer to it. This eventually will be until all protocols finish deleting the routes they had installed and were using this particular vif. The trickiest part will be how to keep track of when the Vif is not needed by any route, but techniques like reference counters or the ref_ptr mechanism can be used to simplify it. I believe this is a relatively clean solution that also doesn't break existing properties/assumptions/semantics. Regards, Pavlin > Thanks, > Ben > > -- > Ben Greear Candela Technologies Inc > http://www.candelatech.com > > > ? fea/data_plane/io/io_ip_socket.cc.ben > ? rib/xorp_rib.bz2 > ? xrl/interfaces/fea_ifmgr_mirror_xif.cc.flc > ? xrl/targets/fea_base.cc.flc > ? xrl/targets/fea_base.hh.flc > ? xrl/targets/fea_ifmgr_mirror_base.cc.flc > Index: fea/iftree.cc > =================================================================== > RCS file: /cvs/xorp/fea/iftree.cc,v > retrieving revision 1.51 > diff -u -r1.51 iftree.cc > --- fea/iftree.cc 27 Sep 2007 00:33:33 -0000 1.51 > +++ fea/iftree.cc 27 Sep 2007 16:18:19 -0000 > @@ -1079,7 +1079,7 @@ > IfTreeAddr4* ap = find_addr(addr); > > if (ap == NULL) > - return (XORP_ERROR); > + return XORP_OK; // Already deleted it seems... (XORP_ERROR); > ap->mark(DELETED); > return (XORP_OK); > } > Index: fea/data_plane/control_socket/netlink_socket_utilities.cc > =================================================================== > RCS file: /cvs/xorp/fea/data_plane/control_socket/netlink_socket_utilities.cc,v > retrieving revision 1.7 > diff -u -r1.7 netlink_socket_utilities.cc > --- fea/data_plane/control_socket/netlink_socket_utilities.cc 27 Sep 2007 00:33:35 -0000 1.7 > +++ fea/data_plane/control_socket/netlink_socket_utilities.cc 27 Sep 2007 16:18:19 -0000 > @@ -411,7 +411,7 @@ > return (XORP_OK); // No error > errno = -err->error; > last_errno = errno; > - error_msg = c_format("AF_NETLINK NLMSG_ERROR message: %s", > + error_msg = c_format("AF_NETLINK NLMSG_ERROR request message: %s", > strerror(errno)); > return (XORP_ERROR); > } > Index: ospf/peer_manager.cc > =================================================================== > RCS file: /cvs/xorp/ospf/peer_manager.cc,v > retrieving revision 1.145 > diff -u -r1.145 peer_manager.cc > --- ospf/peer_manager.cc 24 Aug 2007 02:07:07 -0000 1.145 > +++ ospf/peer_manager.cc 27 Sep 2007 16:18:22 -0000 > @@ -369,9 +369,12 @@ > debug_msg("Interface %s Vif %s\n", interface.c_str(), vif.c_str()); > string concat = interface + "/" + vif; > > - if (0 != _pmap.count(concat)) > - xorp_throw(BadPeer, > - c_format("Mapping for %s already exists", concat.c_str())); > + if (0 != _pmap.count(concat)) { > + // Don't think we really need to error here, just return what we already have. --Ben > + //xorp_throw(BadPeer, > + // c_format("Mapping for %s already exists", concat.c_str())); > + return _pmap[concat]; > + } > > OspfTypes::PeerID peerid = _next_peerid++; > _pmap[concat] = peerid; > Index: ospf/xrl_io.cc > =================================================================== > RCS file: /cvs/xorp/ospf/xrl_io.cc,v > retrieving revision 1.47 > diff -u -r1.47 xrl_io.cc > --- ospf/xrl_io.cc 16 Aug 2007 01:05:51 -0000 1.47 > +++ ospf/xrl_io.cc 27 Sep 2007 16:18:23 -0000 > @@ -634,8 +634,17 @@ > case BAD_ARGS: > case COMMAND_FAILED: > case INTERNAL_ERROR: > - XLOG_FATAL("Cannot join a multicast group on interface %s vif %s: %s", > - interface.c_str(), vif.c_str(), xrl_error.str().c_str()); > + if (strstr(xrl_error.str().c_str(), "Address already in use")) { > + // Just a warning > + XLOG_ERROR("Cannot join a multicast group on interface %s vif %s err_code: %i: %s", > + interface.c_str(), vif.c_str(), (int)(xrl_error.error_code()), > + xrl_error.str().c_str()); > + } > + else { > + XLOG_FATAL("Cannot join a multicast group on interface %s vif %s err_code: %i: %s", > + interface.c_str(), vif.c_str(), (int)(xrl_error.error_code()), > + xrl_error.str().c_str()); > + } > break; > } > } > Index: rib/main_rib.cc > =================================================================== > RCS file: /cvs/xorp/rib/main_rib.cc,v > retrieving revision 1.29 > diff -u -r1.29 main_rib.cc > --- rib/main_rib.cc 16 Feb 2007 22:47:06 -0000 1.29 > +++ rib/main_rib.cc 27 Sep 2007 16:18:24 -0000 > @@ -26,6 +26,15 @@ > #include > #endif > > +RibManager* glb_rib_manager = NULL; > + > +Vif* __find_vif(const string& nm) { > + if (glb_rib_manager) { > + return glb_rib_manager->urib4().find_vif(nm); > + } > + return NULL; > +} > + > int > main (int /* argc */, char* argv[]) > { > @@ -50,13 +59,13 @@ > // > // The RIB manager > // > - RibManager rib_manager(eventloop, xrl_std_router_rib, "fea"); > - rib_manager.enable(); > + glb_rib_manager = new RibManager(eventloop, xrl_std_router_rib, "fea"); > + glb_rib_manager->enable(); > > wait_until_xrl_router_is_ready(eventloop, xrl_std_router_rib); > > // Add the FEA as a RIB client > - rib_manager.add_redist_xrl_output4("fea", /* target_name */ > + glb_rib_manager->add_redist_xrl_output4("fea", /* target_name */ > "all", /* from_protocol */ > true, /* unicast */ > false, /* multicast */ > @@ -64,7 +73,7 @@ > "all", /* cookie */ > true /* is_xrl_transaction_output */ > ); > - rib_manager.add_redist_xrl_output6("fea", /* target_name */ > + glb_rib_manager->add_redist_xrl_output6("fea", /* target_name */ > "all", /* from_protocol */ > true, /* unicast */ > false, /* multicast */ > @@ -73,13 +82,13 @@ > true /* is_xrl_transaction_output */ > ); > > - rib_manager.start(); > + glb_rib_manager->start(); > > // > // Main loop > // > string reason; > - while (rib_manager.status(reason) != PROC_DONE) { > + while (glb_rib_manager->status(reason) != PROC_DONE) { > eventloop.run(); > } > } catch (...) { > Index: rib/redist_xrl.cc > =================================================================== > RCS file: /cvs/xorp/rib/redist_xrl.cc,v > retrieving revision 1.31 > diff -u -r1.31 redist_xrl.cc > --- rib/redist_xrl.cc 23 May 2007 12:12:46 -0000 1.31 > +++ rib/redist_xrl.cc 27 Sep 2007 16:18:26 -0000 > @@ -151,12 +151,19 @@ > : RedistXrlTask(parent), > _net(ipr.net()), > _nexthop(ipr.nexthop_addr()), > - _ifname(ipr.vif()->ifname()), > - _vifname(ipr.vif()->name()), > _metric(ipr.metric()), > _admin_distance(ipr.admin_distance()), > _protocol_origin(ipr.protocol().name()) > { > + Vif* vif = ipr.findVif(); > + if (vif) { > + _ifname = vif->ifname(); > + _vifname = vif->name(); > + } > + else { > + _vifname = ipr.vifName(); > + // TODO: Default _ifname to same?? > + } > } > > template <> > @@ -229,12 +236,18 @@ > : RedistXrlTask(parent), > _net(ipr.net()), > _nexthop(ipr.nexthop_addr()), > - _ifname(ipr.vif()->ifname()), > - _vifname(ipr.vif()->name()), > _metric(ipr.metric()), > _admin_distance(ipr.admin_distance()), > _protocol_origin(ipr.protocol().name()) > { > + Vif* vif = ipr.findVif(); > + if (vif) { > + _ifname = vif->ifname(); > + _vifname = vif->name(); > + } > + else { > + _vifname = ipr.vifName(); > + } > } > > template <> > Index: rib/rib.cc > =================================================================== > RCS file: /cvs/xorp/rib/rib.cc,v > retrieving revision 1.67 > diff -u -r1.67 rib.cc > --- rib/rib.cc 27 Sep 2007 00:33:38 -0000 1.67 > +++ rib/rib.cc 27 Sep 2007 16:18:26 -0000 > @@ -521,6 +529,18 @@ > return XORP_OK; > } > > +/** Return instance of specified VIF if we can find it, NULL otherwise. > + */ > +template > +Vif* > +RIB::find_vif(const string& vifname) { > + map::iterator vi = _vifs.find(vifname); > + if (vi == _vifs.end()) { > + return NULL; > + } > + return &(vi->second); > +} > + > template > int > RIB::delete_vif(const string& vifname) > @@ -762,7 +782,7 @@ > const IPRouteEntry* re = _final_table->lookup_route(nexthop_addr); > if (re != NULL) { > // We found a route for the nexthop > - vif = re->vif(); > + vif = re->findVif(); > if ((vif != NULL) > && (vif->is_underlying_vif_up()) > && (vif->is_same_subnet(IPvXNet(re->net())) > @@ -895,7 +915,7 @@ > // 1. Check for an expected route miss. > // 2. Check table entry validity and existence. > re = _final_table->lookup_route(lookup_addr); > - if (re == NULL || re->vif() == NULL) { > + if (re == NULL || re->vifName().empty() || re->findVif() == NULL) { > if (matchtype == RibVerifyType(MISS)) { > debug_msg("****ROUTE MISS SUCCESSFULLY VERIFIED****\n"); > return XORP_OK; > @@ -951,14 +971,14 @@ > nexthop_addr.str().c_str(), > route_nexthop->addr().str().c_str()); > } > - if (ifname != re->vif()->name()) { > + if (ifname != re->vifName()) { > XLOG_ERROR("Interface \"%s\" does not match expected \"%s\".", > - re->vif()->str().c_str(), ifname.c_str()); > + re->vifName().c_str(), ifname.c_str()); > return XORP_ERROR; > } else { > debug_msg("Ifname: Exp: %s == Got: %s\n", > ifname.c_str(), > - re->vif()->name().c_str()); > + re->vifName().c_str()); > } > if (metric != re->metric()) { > XLOG_ERROR("Metric \"%u\" does not match expected \"%u\".", > @@ -982,7 +1002,7 @@ > const IPRouteEntry* re = _final_table->lookup_route(lookupaddr); > // Case 1: Route miss. Return the null IP address. > // Vif cannot be NULL for a valid route. > - if (re == NULL || re->vif() == NULL) > + if (re == NULL || re->vifName().empty() || re->findVif() == NULL) > return A::ZERO(); > > #ifdef notyet > Index: rib/rib.hh > =================================================================== > RCS file: /cvs/xorp/rib/rib.hh,v > retrieving revision 1.40 > diff -u -r1.40 rib.hh > --- rib/rib.hh 27 Sep 2007 00:33:39 -0000 1.40 > +++ rib/rib.hh 27 Sep 2007 16:18:27 -0000 > @@ -175,6 +175,10 @@ > */ > virtual int new_vif(const string& vifname, const Vif& vif); > > + /** Return instance of specified VIF if we can find it, NULL otherwise. > + */ > + virtual Vif* find_vif(const string& vifname); > + > /** > * Inform the RIB that a VIF no longer exists. > * > Index: rib/rib_manager.hh > =================================================================== > RCS file: /cvs/xorp/rib/rib_manager.hh,v > retrieving revision 1.36 > diff -u -r1.36 rib_manager.hh > --- rib/rib_manager.hh 16 Feb 2007 22:47:08 -0000 1.36 > +++ rib/rib_manager.hh 27 Sep 2007 16:18:27 -0000 > @@ -448,6 +448,8 @@ > */ > XrlRibTarget& xrl_rib_target() { return _xrl_rib_target; } > > + VifManager& getVifManager() { return _vif_manager; } > + > private: > ProcessStatus _status_code; > string _status_reason; > Index: rib/route.hh > =================================================================== > RCS file: /cvs/xorp/rib/route.hh,v > retrieving revision 1.23 > diff -u -r1.23 route.hh > --- rib/route.hh 23 May 2007 12:12:47 -0000 1.23 > +++ rib/route.hh 27 Sep 2007 16:18:27 -0000 > @@ -31,6 +31,7 @@ > > #include "protocol.hh" > > +Vif* __find_vif(const string& nm); > > /** > * @short Base class for RIB routing table entries. > @@ -52,7 +53,7 @@ > */ > RouteEntry(Vif* vif, NextHop* nexthop, const Protocol& protocol, > uint16_t metric) > - : _vif(vif), _nexthop(nexthop), _protocol(protocol), > + : _vifname(vif ? vif->name().c_str() : ""), _nexthop(nexthop), _protocol(protocol), > _admin_distance(UNKNOWN_ADMIN_DISTANCE), _metric(metric) > { > } > @@ -69,7 +70,11 @@ > * @return the Virtual Interface on which packets matching this > * routing table entry should be forwarded. > */ > - Vif* vif() const { return _vif; } > + Vif* findVif() const { > + return __find_vif(_vifname); > + } > + > + const string& vifName() const { return _vifname; } > > /** > * Get the NextHop router. > @@ -132,7 +137,8 @@ > uint16_t metric() const { return _metric; } > > protected: > - Vif* _vif; > + //Vif* _vif; > + string _vifname; > NextHop* _nexthop; // The next-hop router > // The routing protocol that instantiated this route > const Protocol& _protocol; > @@ -238,8 +244,8 @@ > */ > string str() const { > string dst = (_net.is_valid()) ? _net.str() : string("NULL"); > - string vif = (_vif) ? string(_vif->name()) : string("NULL"); > - return string("Dst: ") + dst + string(" Vif: ") + vif + > + //string vif = (_vif) ? string(_vif->name()) : string("NULL"); > + return string("Dst: ") + dst + string(" Vif: ") + _vifname + > string(" NextHop: ") + _nexthop->str() + > string(" Metric: ") + c_format("%d", _metric) + > string(" Protocol: ") + _protocol.name() + > Index: rib/rt_tab_extint.cc > =================================================================== > RCS file: /cvs/xorp/rib/rt_tab_extint.cc,v > retrieving revision 1.32 > diff -u -r1.32 rt_tab_extint.cc > --- rib/rt_tab_extint.cc 27 Sep 2007 00:33:39 -0000 1.32 > +++ rib/rt_tab_extint.cc 27 Sep 2007 16:18:28 -0000 > @@ -99,7 +99,7 @@ > const IPRouteEntry* nexthop_route; > nexthop_route = lookup_route_in_igp_parent(nexthop_addr); > if (nexthop_route != NULL) { > - Vif* vif = nexthop_route->vif(); > + Vif* vif = nexthop_route->findVif(); > if ((vif != NULL) > && (vif->is_same_subnet(IPvXNet(nexthop_route->net())) > || vif->is_same_p2p(IPvX(nexthop_addr)))) { > @@ -160,7 +160,7 @@ > this->next_table()->delete_route(found, this); > } > > - Vif* vif = nexthop_route->vif(); > + Vif* vif = nexthop_route->findVif(); > if ((vif != NULL) > && (vif->is_same_subnet(IPvXNet(nexthop_route->net())) > || vif->is_same_p2p(IPvX(nexthop_addr)))) { > @@ -200,7 +200,7 @@ > { > ResolvedIPRouteEntry* resolved_route; > resolved_route = new ResolvedIPRouteEntry(route.net(), > - nexthop_route->vif(), > + nexthop_route->findVif(), > nexthop_route->nexthop(), > route.protocol(), > route.metric(), > @@ -350,6 +350,7 @@ > return XORP_OK; > } > > + > template > const ResolvedIPRouteEntry* > ExtIntTable::lookup_in_resolved_table(const IPNet& net) > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at icir.org Thu Sep 27 14:14:48 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 27 Sep 2007 14:14:48 -0700 Subject: [Xorp-users] xorp_rib SEGV when removing interface while using OSPF. In-Reply-To: Message from Ben Greear of "Tue, 25 Sep 2007 16:22:11 PDT." <46F99823.9050603@candelatech.com> Message-ID: <200709272114.l8RLEmVq004247@possum.icir.org> [Note: I left this email in my inbox for more careful thoughts until I finish the VLAN stuff, so I just had the chance to look into it]. > > Without looking into all details, I think your intuition is right. > > Could you open a Bugzilla entry for the issue and include > > instuctions how to reproduce the issue. Without such instructions it > > will be much more difficult to track and fix the issue. > > I started looking into this code today, and it appears quite difficult > to properly clean up the various routing table structures that hold > references to Vifs. > > What do you think about removing the _vif pointer from RouteEntry > and just using vifname and/or ifname strings? If we ever really need > an vif object, can look it up then in the rib's global list? Yes, this is one possible strategy, though I could imagine the lookup can become a bottleneck if there are lots of routes referring to the deleted Vif. > Another option would be to use a reference counting scheme, but > those usually suck to code & debug, especially when templates > are involved... Actually, in my email I just sent on the subject I was thinking about the same thing. I don't see the templates being show-stoppers. The more important would be whether the reference couting can be done cleanly in the right place (e.g., in the route constructor and destructor) so there is no danger of incorrect counting. Also, the ref_ptr mechanism used in XORP can be of big help here. Regards, Pavlin > Any suggestions? > > 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 greearb at candelatech.com Thu Sep 27 14:35:10 2007 From: greearb at candelatech.com (Ben Greear) Date: Thu, 27 Sep 2007 14:35:10 -0700 Subject: [Xorp-users] Patch for making it harder to crash rib when removing interfaces. In-Reply-To: <200709272104.l8RL4qd0004135@possum.icir.org> References: <200709272104.l8RL4qd0004135@possum.icir.org> Message-ID: <46FC220E.3060505@candelatech.com> Pavlin Radoslavov wrote: > The patch seems to be around the introduction of a global RibManager > variable "glb_rib_manager" which is a big NO. > We try very hard to avoid any global variables, otherwise you lose > many (object-oriented) properties. > For example, you automatically lose the ability to generate 2+ RIB > instances within the same binary. Well, if we go with a lookup scheme, the route objects need to be able to look up a vif by name. That implies a global list of vifs somewhere (could be in a singleton, which allows global variables wrapped up in something that looks OO, but it's logically the same). With my hack, you can have only one RibManager at a time, but that did not seem to be a problem. You can have all the RIBs you want... > However, the idea of saving the vif name itself instead of a pointer > to the Vif instance might be worth considering in case the route > class itself needs only the vif name. > I am not completely convinced it is the right solution in case, say, > some of the code toward the end of the RIB processing needs to look > into the status of the Vif before sending a route to the FEA, but > is a proposal that should be kept on the table. It can do a lookup at this time and find the one & only instance of the Vif object if it currently exists. If not, it can take evasive action. > > Let me try to step back and look into the problem from high level. > If an interface/vif is deleted from the system, all protocols and > RIB will receive the "delete" action from the FEA. > I believe all protocols will try to withdraw the routes they sent to > RIB if those routes use the deleted interface. > The RIB itself will withdraw its own "connected" routes and will > remove the Vif instance itself. > Therefore, after the Vif instance deletion the "route delete" > requests from an unicast routing protocol might refer to the Vif > that doesn't exist. Also, the RIB stored routes from those protocols > might still be referring to the deleted Vif instance. This appears to be my crash...a route from OSPF had a stale ref to a Vif. It was trying to delete the route when it crashed accessing the vif. > > To solve the problem it needs to be decided who is responsible for > deleting the unicast routes that refer to the deleted vif. Currently > it is the protocol that added the routes, but this creates a race > condition. > If the RIB becomes responsible for deleting those routes, then we > need to change the route add/delete semantics between the RIB and > the routing protocols, because currently the protocols assume they > have complete control over the adding/deletion of their own routes. > > One possible solution of breaking the race condition is to keep the > Vif instance around (e.g., marked as DELETED or in some different > container) until no RIB routes refer to it. This eventually will be > until all protocols finish deleting the routes they had installed > and were using this particular vif. This sounds promising, and saves the lookup of the Vif. We would have to check all accesses of the vif pointer to make sure the vif has not been logically deleted before taking actions on it. There may be a related problem where we don't un-register multicast addresses on deleted vifs as well. This doesn't appear to cause crashes, just keeps things from working. If you get a patch of this nature, I'd be happy to test it. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Thu Sep 27 14:47:55 2007 From: greearb at candelatech.com (Ben Greear) Date: Thu, 27 Sep 2007 14:47:55 -0700 Subject: [Xorp-users] select timeout question Message-ID: <46FC250B.9010009@candelatech.com> If you pass a timeout of 0 to selector::wait_and_dispatch, it causes select to wait 'forever'. Is that on purpose or a bug? If you want to wait for zero time in select, pass a time-val with all zero values (not 0, which is actually treated as NULL). if (timeout == 0 || *timeout == TimeVal::MAXIMUM()) { n = ::select(_maxfd + 1, &testfds[SEL_RD_IDX], &testfds[SEL_WR_IDX], &testfds[SEL_EX_IDX], 0); } else { -- Ben Greear Candela Technologies Inc http://www.candelatech.com From kristian at spritelink.net Thu Sep 27 14:59:33 2007 From: kristian at spritelink.net (Kristian Larsson) Date: Thu, 27 Sep 2007 23:59:33 +0200 Subject: [Xorp-users] VLAN support in XORP In-Reply-To: <200709271826.l8RIQsbP002624@possum.icir.org> References: <46FAA39E.7070603@spritelink.net> <200709271826.l8RIQsbP002624@possum.icir.org> Message-ID: <20070927215932.GC16242@spritelink.se> On Thu, Sep 27, 2007 at 11:26:54AM -0700, Pavlin Radoslavov wrote: > > I think this makes it very difficult to use. Having to make sure that > > the interface name is unique is a typical task for a computer, not a > > human :) > > I'm seeing a configuration with hundreds of interfaces, it would be > > unbearable. > > How is it different from, say, using directly the UNIX tools to > create VLANs and making sure each one will have an unique name. I'm seing this mostly from a Cisco / Juniper side of things where you don't have to keep track. The PC based routers I've dealt with have mostly been based on Linux and then again you don't have to deal with it since it's . :) > I see. > I am not strongly opposed against moving the stuff from the > "vlan {}" block to its parent "vif {}" block, so lets wait and see > if there are other alternative proposals. > After that we can decide whether we should do the change. Yepp, and the mac vlan thing that Ben brings up is quite interesting as well, never used it but looks kinda cool :) The XORP solution should of course, if possible, cater for all possible uses. -K -- Kristian Larsson KLL-RIPE Network Engineer & Peering Coordinator SpriteLink [AS39525] +46 704 910401 kll at spritelink.net From pavlin at icir.org Thu Sep 27 22:51:39 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 27 Sep 2007 22:51:39 -0700 Subject: [Xorp-users] select timeout question In-Reply-To: Message from Ben Greear of "Thu, 27 Sep 2007 14:47:55 PDT." <46FC250B.9010009@candelatech.com> Message-ID: <200709280551.l8S5pdfx011762@possum.icir.org> Ben Greear wrote: > If you pass a timeout of 0 to selector::wait_and_dispatch, it causes select to wait 'forever'. > Is that on purpose or a bug? If you want to wait for zero time in select, pass a time-val > with all zero values (not 0, which is actually treated as NULL). > > if (timeout == 0 || *timeout == TimeVal::MAXIMUM()) { > n = ::select(_maxfd + 1, > &testfds[SEL_RD_IDX], > &testfds[SEL_WR_IDX], > &testfds[SEL_EX_IDX], > 0); > } else { I believe it is on purpose. Part of the logic behind it is probably because select(2) with "timeout" argument of NULL also blocks forever. One extreme scenario that comes to mind is, say, if there are no timeout events scheduled. In that case you want to select() until a file descriptor is ready (for reading/writing/etc). Strictly speaking, the "timeout" argument doesn't need to be a pointer; instead, it could be pass-by-reference argument. In fact, the more I think, the more I believe it should be pass-by-reference. Then, if some code really wants to select(2) without timeout, the caller should use TimeVal::MAXIMUM() as an argument. And yes, TimeVal::ZERO() is used typically to schedule a timer that will expire immediately. Thanks, Pavlin > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From greearb at candelatech.com Thu Sep 27 23:17:38 2007 From: greearb at candelatech.com (Ben Greear) Date: Thu, 27 Sep 2007 23:17:38 -0700 Subject: [Xorp-users] select timeout question In-Reply-To: <200709280551.l8S5pdfx011762@possum.icir.org> References: <200709280551.l8S5pdfx011762@possum.icir.org> Message-ID: <46FC9C82.6080904@candelatech.com> Pavlin Radoslavov wrote: > Ben Greear wrote: > >> If you pass a timeout of 0 to selector::wait_and_dispatch, it causes select to wait 'forever'. >> Is that on purpose or a bug? If you want to wait for zero time in select, pass a time-val >> with all zero values (not 0, which is actually treated as NULL). >> >> if (timeout == 0 || *timeout == TimeVal::MAXIMUM()) { >> n = ::select(_maxfd + 1, >> &testfds[SEL_RD_IDX], >> &testfds[SEL_WR_IDX], >> &testfds[SEL_EX_IDX], >> 0); >> } else { > > I believe it is on purpose. > Part of the logic behind it is probably because select(2) with > "timeout" argument of NULL also blocks forever. > One extreme scenario that comes to mind is, say, if there are no > timeout events scheduled. In that case you want to select() until a > file descriptor is ready (for reading/writing/etc). > > Strictly speaking, the "timeout" argument doesn't need to be a > pointer; instead, it could be pass-by-reference argument. > In fact, the more I think, the more I believe it should be > pass-by-reference. Then, if some code really wants to select(2) > without timeout, the caller should use TimeVal::MAXIMUM() as an > argument. > > And yes, TimeVal::ZERO() is used typically to schedule a timer that > will expire immediately. Unless I am confused, passing in timeout == 0 will cause it to potentially block forever, instead of doing a select that will return immediately, which is what I would expect. If you want TimeVal::MAXIMUM() to mean block forever, then that currently seems to work that way. Thanks, Ben > > Thanks, > Pavlin > >> -- >> 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 -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Thu Sep 27 23:19:35 2007 From: greearb at candelatech.com (Ben Greear) Date: Thu, 27 Sep 2007 23:19:35 -0700 Subject: [Xorp-users] select timeout question In-Reply-To: <200709280551.l8S5pdfx011762@possum.icir.org> References: <200709280551.l8S5pdfx011762@possum.icir.org> Message-ID: <46FC9CF7.8020004@candelatech.com> Pavlin Radoslavov wrote: > Ben Greear wrote: > >> If you pass a timeout of 0 to selector::wait_and_dispatch, it causes select to wait 'forever'. >> Is that on purpose or a bug? If you want to wait for zero time in select, pass a time-val >> with all zero values (not 0, which is actually treated as NULL). >> >> if (timeout == 0 || *timeout == TimeVal::MAXIMUM()) { >> n = ::select(_maxfd + 1, >> &testfds[SEL_RD_IDX], >> &testfds[SEL_WR_IDX], >> &testfds[SEL_EX_IDX], >> 0); >> } else { > > I believe it is on purpose. > Part of the logic behind it is probably because select(2) with > "timeout" argument of NULL also blocks forever. > One extreme scenario that comes to mind is, say, if there are no > timeout events scheduled. In that case you want to select() until a > file descriptor is ready (for reading/writing/etc). > > Strictly speaking, the "timeout" argument doesn't need to be a > pointer; instead, it could be pass-by-reference argument. > In fact, the more I think, the more I believe it should be > pass-by-reference. Then, if some code really wants to select(2) > without timeout, the caller should use TimeVal::MAXIMUM() as an > argument. > > And yes, TimeVal::ZERO() is used typically to schedule a timer that > will expire immediately. Bleh, I see. Timeout is a pointer. Would have been more clear if the code was: timeout == NULL Ben > > Thanks, > Pavlin > >> -- >> 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 -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Thu Sep 27 23:38:30 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 27 Sep 2007 23:38:30 -0700 Subject: [Xorp-users] select timeout question In-Reply-To: Message from Ben Greear of "Thu, 27 Sep 2007 23:19:35 PDT." <46FC9CF7.8020004@candelatech.com> Message-ID: <200709280638.l8S6cU8v023750@possum.icir.org> > Bleh, I see. Timeout is a pointer. Would have been more > clear if the code was: timeout == NULL I am with you on this :) Personally I always use NULL instead of 0 when comparing a pointer for exactly same reason. Anyway, I just changed the timeout argument so it is passed as a reference instead of being a pointer. Thanks, Pavlin From pavlin at icir.org Fri Sep 28 14:00:59 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 28 Sep 2007 14:00:59 -0700 Subject: [Xorp-users] Patch for making it harder to crash rib when removing interfaces. In-Reply-To: Message from Ben Greear of "Thu, 27 Sep 2007 14:35:10 PDT." <46FC220E.3060505@candelatech.com> Message-ID: <200709282100.l8SL0xab003545@possum.icir.org> > > To solve the problem it needs to be decided who is responsible for > > deleting the unicast routes that refer to the deleted vif. Currently > > it is the protocol that added the routes, but this creates a race > > condition. > > If the RIB becomes responsible for deleting those routes, then we > > need to change the route add/delete semantics between the RIB and > > the routing protocols, because currently the protocols assume they > > have complete control over the adding/deletion of their own routes. > > > > One possible solution of breaking the race condition is to keep the > > Vif instance around (e.g., marked as DELETED or in some different > > container) until no RIB routes refer to it. This eventually will be > > until all protocols finish deleting the routes they had installed > > and were using this particular vif. > > This sounds promising, and saves the lookup of the Vif. We would have > to check all accesses of the vif pointer to make sure the vif has not > been logically deleted before taking actions on it. > > There may be a related problem where we don't un-register multicast > addresses on deleted vifs as well. This doesn't appear to cause crashes, > just keeps things from working. > > If you get a patch of this nature, I'd be happy to test it. Ben, I just implemented the reference counting for the vif entries inside the RIB. I believe the reference counting needs to be done only inside the RouteEntry constructor and destructor which reduces significantly the amount of changes. I will send you the patch in a private email to reduce the unnecessary traffic on the list. Please test it and let me know whether it fixes the problem. Thanks, Pavlin From pavlin at icir.org Fri Sep 28 16:31:52 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Fri, 28 Sep 2007 16:31:52 -0700 Subject: [Xorp-users] VLAN support in XORP In-Reply-To: Message from Kristian Larsson of "Thu, 27 Sep 2007 23:59:33 +0200." <20070927215932.GC16242@spritelink.se> Message-ID: <200709282331.l8SNVqhe004824@possum.icir.org> Kristian Larsson wrote: > On Thu, Sep 27, 2007 at 11:26:54AM -0700, Pavlin Radoslavov wrote: > > > I think this makes it very difficult to use. Having to make sure that > > > the interface name is unique is a typical task for a computer, not a > > > human :) > > > I'm seeing a configuration with hundreds of interfaces, it would be > > > unbearable. > > > > How is it different from, say, using directly the UNIX tools to > > create VLANs and making sure each one will have an unique name. > > I'm seing this mostly from a Cisco / Juniper side > of things where you don't have to keep track. > The PC based routers I've dealt with have mostly > been based on Linux and then again you don't have > to deal with it since it's . :) If we had complete control over the underlying system, then we will have the freedom to choose whatever naming scheme we like and then adjust the underlying system to support it. In our case we need to consider the multi-platform support we try to offer, and some of those systems don't even offer the option of renaming the vlan interface name. Well, there are alternatives like the following. I am mentioning it not because it is my preference, but just for completness: interfaces { interface fxp0 { vlan 200 { vif-name: "vlan200" address { ... } } } } where "200" is the VLAN ID and "vif-name" is optional. But then if the users don't specify "vif-name", it becomes more complicated to them because they need to figure out the vlan interface name (as appears in the system), and need to use that name in the rest of the XORP configuration like: ospf4 { interface fxp0 { vif vlan200 { ... } } } >From all the discussion so far (including the long thread 2 years ago), it doesn't seem there is a single solution everyone is happy with so I think we need to draw the line somewhere and move on. > > I see. > > I am not strongly opposed against moving the stuff from the > > "vlan {}" block to its parent "vif {}" block, so lets wait and see > > if there are other alternative proposals. > > After that we can decide whether we should do the change. > > Yepp, and the mac vlan thing that Ben brings up is > quite interesting as well, never used it but looks > kinda cool :) > The XORP solution should of course, if possible, > cater for all possible uses. I did some search re. macvlan and it seems interesting, but according to Ben's Web site you need to patch your kernel to add the support for it. Hence, my personal preference (with the risk to offend Ben :) is to wait until it becomes part of the Linux kernel before we add it to our TODO list. Thanks, Pavlin > -K > > -- > Kristian Larsson KLL-RIPE > Network Engineer & Peering Coordinator SpriteLink [AS39525] > +46 704 910401 kll at spritelink.net > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From greearb at candelatech.com Fri Sep 28 18:34:11 2007 From: greearb at candelatech.com (Ben Greear) Date: Fri, 28 Sep 2007 18:34:11 -0700 Subject: [Xorp-users] VLAN support in XORP In-Reply-To: <200709282331.l8SNVqhe004824@possum.icir.org> References: <200709282331.l8SNVqhe004824@possum.icir.org> Message-ID: <46FDAB93.9080405@candelatech.com> Pavlin Radoslavov wrote: > I did some search re. macvlan and it seems interesting, but > according to Ben's Web site you need to patch your kernel to add the > support for it. > Hence, my personal preference (with the risk to offend Ben :) is to > wait until it becomes part of the Linux kernel before we add it to > our TODO list. I suggest the same...but it will be in 2.6.23, so it's not far away. It will use netlink for add/delete, not ioctls, btw. Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Sat Sep 29 11:30:15 2007 From: greearb at candelatech.com (Ben Greear) Date: Sat, 29 Sep 2007 11:30:15 -0700 Subject: [Xorp-users] CLI spin fix (hack) Message-ID: <46FE99B7.8090203@candelatech.com> It seems that if you pipe multiple commands into the CLI, it will busy spin waiting for the previous command to complete. Since 'commit' can take multiple seconds when adding an interface, this eats a lot of CPU. This hack below to cli/cli_node_net.cc 'fixes' the busy spin. It actually seems to me that we should block instead on receiving response from the manager process, or create the timer with a timeout, but I got lost in a maze of typedefs and templates trying to figure out how to do it right. Hopefully someone will know the right way to do this. if (! _pending_input_data.empty()) { schedule_process_input_data(); // Sleep so we don't busy-spin when we have multiple // commands queued up and are waiting on response before // allowing the next command. usleep(50 * 1000); //50ms } Also, this patch below allows multiple -c "cmd" arguments to allow multiple commands to be piped into xorpsh from the command line. This patch may actually be worth applying as is. [root at nx5000 rtrmgr]# cvs diff -u xorpsh_main.cc Index: xorpsh_main.cc =================================================================== RCS file: /cvs/xorp/rtrmgr/xorpsh_main.cc,v retrieving revision 1.67 diff -u -r1.67 xorpsh_main.cc --- xorpsh_main.cc 23 May 2007 04:08:30 -0000 1.67 +++ xorpsh_main.cc 29 Sep 2007 18:28:00 -0000 @@ -851,7 +853,8 @@ while ((c = getopt(argc, argv, "c:t:x:vh")) != EOF) { switch(c) { case 'c': - commands = optarg; + commands += optarg; + commands += "\n"; break; case 't': template_dir = optarg; -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at icir.org Sat Sep 29 21:15:02 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Sat, 29 Sep 2007 21:15:02 -0700 Subject: [Xorp-users] CLI spin fix (hack) In-Reply-To: Message from Ben Greear of "Sat, 29 Sep 2007 11:30:15 PDT." <46FE99B7.8090203@candelatech.com> Message-ID: <200709300415.l8U4F2Va029432@possum.icir.org> Ben Greear wrote: > It seems that if you pipe multiple commands into the CLI, it will busy > spin waiting for the previous command to complete. Since 'commit' > can take multiple seconds when adding an interface, this eats a lot > of CPU. Could you clarify what you mean by piping multiple commands into the CLI. Is it when you use multiple "-c " arguments after applying your second patch. > This hack below to cli/cli_node_net.cc 'fixes' the busy spin. It actually seems > to me that we should block instead on receiving response from the manager > process, or create the timer with a timeout, but I got lost in a maze of > typedefs and templates trying to figure out how to do it right. Hopefully > someone will know the right way to do this. > > if (! _pending_input_data.empty()) { > schedule_process_input_data(); > // Sleep so we don't busy-spin when we have multiple > // commands queued up and are waiting on response before > // allowing the next command. > usleep(50 * 1000); //50ms > } > > Also, this patch below allows multiple -c "cmd" arguments to allow multiple commands > to be piped into xorpsh from the command line. This patch may actually be > worth applying as is. Thanks, this seems a nice new feature so I just committed it. Pavlin > > [root at nx5000 rtrmgr]# cvs diff -u xorpsh_main.cc > Index: xorpsh_main.cc > =================================================================== > RCS file: /cvs/xorp/rtrmgr/xorpsh_main.cc,v > retrieving revision 1.67 > diff -u -r1.67 xorpsh_main.cc > --- xorpsh_main.cc 23 May 2007 04:08:30 -0000 1.67 > +++ xorpsh_main.cc 29 Sep 2007 18:28:00 -0000 > @@ -851,7 +853,8 @@ > while ((c = getopt(argc, argv, "c:t:x:vh")) != EOF) { > switch(c) { > case 'c': > - commands = optarg; > + commands += optarg; > + commands += "\n"; > break; > case 't': > template_dir = optarg; > > > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From greearb at candelatech.com Sun Sep 30 11:22:57 2007 From: greearb at candelatech.com (Ben Greear) Date: Sun, 30 Sep 2007 11:22:57 -0700 Subject: [Xorp-users] CLI spin fix (hack) In-Reply-To: <200709300415.l8U4F2Va029432@possum.icir.org> References: <200709300415.l8U4F2Va029432@possum.icir.org> Message-ID: <46FFE981.90106@candelatech.com> Pavlin Radoslavov wrote: > Ben Greear wrote: > > >> It seems that if you pipe multiple commands into the CLI, it will busy >> spin waiting for the previous command to complete. Since 'commit' >> can take multiple seconds when adding an interface, this eats a lot >> of CPU. >> > > Could you clarify what you mean by piping multiple commands into the > CLI. Is it when you use multiple "-c " arguments after applying > your second patch. > Yes, or when you do xorpsh < cmd_file.txt where cmd_file.txt has several lines in it, like: configure remove interface foo commit ... exit exit -- Ben Greear Candela Technologies Inc http://www.candelatech.com From i at levsha.org.ua Sun Sep 30 14:29:37 2007 From: i at levsha.org.ua (Mykola Dzham) Date: Mon, 1 Oct 2007 00:29:37 +0300 Subject: [Xorp-users] VLAN support in XORP In-Reply-To: <200709260901.l8Q9178c004775@possum.icir.org> References: <200709260901.l8Q9178c004775@possum.icir.org> Message-ID: <20070930212937.GF30765@expo.ukrweb.net> Pavlin Radoslavov wrote: > > In term of VLAN naming, the situation is the following. > In FreeBSD (and I believe in other BSDs as well, but I haven't > double-checked it yet), the vlan name has to be "vlan%d". However, > the integer after "vlan" doesn't need to match the VLAN ID. E.g., > vlan10 could have VLAN ID of, say, 20. > > In Linux the naming scheme can be programmed in advance using > ioctl(SET_VLAN_NAME_TYPE_CMD). The choices are names like: > (a) vlan0005 > (b) eth1.0005 > (c) vlan5 > (d) eth0.5 FreeBSD can use naming scheme like . : # ifconfig bfe0.10 create # ifconfig bfe0.10 bfe0.10: flags=8842 metric 0 mtu 1500 ether 00:17:a4:db:e1:78 media: Ethernet autoselect (100baseTX ) status: active vlan: 10 parent interface: bfe0 # Support of such syntax commited 3 years ago This scheme hawe some problems in FreeBSD : you cannot write in rc.conf line like ifconfig_bfe0.10="inet ..." - dots is not allowed in variable names; ng_ether cannot name ether node, attached to this interface, as bfe0.10 - dots is use in netgraph as delimiters in path But this scheme also has some advantages: you can create several interfaces with same vlan id (on different parent interfaces), syntax is cisco-like ;) Is it possible to implement in xorp both naming schemes: vlan%d and ifname.%d ? -- Mykola Dzham, LEFT-(UANIC|RIPE) JID: levsha at jabber.net.ua