From arvind at macil.in Tue Jun 3 20:56:50 2008 From: arvind at macil.in (arvind) Date: Wed, 04 Jun 2008 09:26:50 +0530 Subject: [Xorp-users] BGP: error while starting xorpsh Message-ID: <48461282.7060106@macil.in> While running xorp_rtrmgr i have the following om the terminal: [root at localhost xorp.cvs.org]# ./rtrmgr/xorp_rtrmgr [ 2008/06/04 09:16:57 INFO xorp_rtrmgr:9504 RTRMGR +239 master_conf_tree.cc execute ] Changed modules: interfaces, fea, rib, policy, static_routes, bgp [ 2008/06/04 09:16:57 INFO xorp_rtrmgr:9504 RTRMGR +96 module_manager.cc execute ] Executing module: interfaces (fea/xorp_fea) [ 2008/06/04 09:16:58 INFO xorp_fea MFEA ] MFEA enabled [ 2008/06/04 09:16:58 INFO xorp_fea MFEA ] CLI enabled [ 2008/06/04 09:16:58 INFO xorp_fea MFEA ] CLI started [ 2008/06/04 09:16:58 INFO xorp_fea MFEA ] MFEA enabled [ 2008/06/04 09:16:58 INFO xorp_fea MFEA ] CLI enabled [ 2008/06/04 09:16:58 INFO xorp_fea MFEA ] CLI started [ 2008/06/04 09:16:59 INFO xorp_rtrmgr:9504 RTRMGR +96 module_manager.cc execute ] Executing module: fea (fea/xorp_fea) [ 2008/06/04 09:17:03 INFO xorp_rtrmgr:9504 RTRMGR +96 module_manager.cc execute ] Executing module: rib (rib/xorp_rib) [ 9505 +2333 xrl_fea_target.cc ] redist_transaction4_0_1_add_route(): dst = 192.168.49.0/24 nexthop = 192.168.49.16 ifname = eth0 vifname = eth0 metric = 0 admin_distance = 0 protocol_origin = connected [ 2008/06/04 09:17:05 INFO xorp_rtrmgr:9504 RTRMGR +96 module_manager.cc execute ] Executing module: policy (policy/xorp_policy) [ 2008/06/04 09:17:07 INFO xorp_rtrmgr:9504 RTRMGR +96 module_manager.cc execute ] Executing module: static_routes (static_routes/xorp_static_routes) [ 9506 +1395 xrl_target.cc ] Target Birth: class = static_routes instance = static_routes-de9f2f65f9bf1184f3632c0bbd526285 at 127.0.0.1 [ 2008/06/04 09:17:09 INFO xorp_rtrmgr:9504 RTRMGR +96 module_manager.cc execute ] Executing module: bgp (bgp/xorp_bgp) [ 9509 +54 bgp.cc ] BGPMain object created [ 9509 +75 main.cc ] By default assume there is a rib running [ 9509 +1698 bgp.cc ] BGPMain::register_ribname [ 9509 +1699 bgp.cc ] rib [ 9506 +1395 xrl_target.cc ] Target Birth: class = bgp instance = bgp-3bcaa06ba79c588b0f6eb1f438827b2c at 127.0.0.1 [ 9509 +682 bgp.cc ] interface eth0 vif eth0 address 192.168.49.16 prefix_len 24 state true [ 9509 +777 bgp.cc ] BGPMain::main_loop started [ 9509 +1009 bgp.cc ] Creating new Peer: {192.168.49.16(179) 192.168.49.16(179)} [ 9509 +1011 bgp.cc ] Using local address 10.10.1.2 for our nexthop [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} [ 9509 +988 bgp.cc ] No match [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} [ 9509 +988 bgp.cc ] No match [ 9509 +946 bgp.cc ] Peer added (fd -1) [ 9509 +1203 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ 9509 +982 bgp.cc ] Succeeded [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ 9509 +982 bgp.cc ] Succeeded [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ 9509 +982 bgp.cc ] Succeeded [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ 9509 +982 bgp.cc ] Succeeded [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ 9509 +982 bgp.cc ] Succeeded [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ 9509 +982 bgp.cc ] Succeeded [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ 9509 +982 bgp.cc ] Succeeded [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ 9509 +982 bgp.cc ] Succeeded [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ 9509 +982 bgp.cc ] Succeeded [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ 9509 +982 bgp.cc ] Succeeded [ 9509 +1960 bgp.cc ] IPv4 Unicast [ 9509 +1977 bgp.cc ] Peer {192.168.49.16(179) 192.168.49.16(179)}. true [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ 9509 +982 bgp.cc ] Succeeded [ 9509 +1963 bgp.cc ] IPv4 Multicast [ 9509 +1977 bgp.cc ] Peer {192.168.49.16(179) 192.168.49.16(179)}. false [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ 9509 +982 bgp.cc ] Succeeded [ 9509 +1966 bgp.cc ] IPv6 Unicast [ 9509 +1977 bgp.cc ] Peer {192.168.49.16(179) 192.168.49.16(179)}. false [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ 9509 +982 bgp.cc ] Succeeded [ 9509 +1969 bgp.cc ] IPv6 Multicast [ 9509 +1977 bgp.cc ] Peer {192.168.49.16(179) 192.168.49.16(179)}. false [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ 9509 +982 bgp.cc ] Succeeded [ 2008/06/04 09:17:11 WARNING xorp_policy:9507 XifFinderEventNotifier +275 filter_manager.cc birth ] XXX HACK: PUSHING ROUTES OF connected FOR bgp [ 2008/06/04 09:17:11 WARNING xorp_policy:9507 XifFinderEventNotifier +275 filter_manager.cc birth ] XXX HACK: PUSHING ROUTES OF static FOR bgp [ 9509 +1820 bgp.cc ] nlri 192.168.49.0/24 next hop 192.168.49.16 unicast 1 multicast 0 [ 9509 +1820 bgp.cc ] nlri 192.168.49.0/24 next hop 192.168.49.16 unicast 0 multicast 1 [ 9506 +1141 xrl_target.cc ] register_interest4 target = bgp addr = 192.168.49.16 When i started to run the Xorpsh then i got the following error on my terminal(xorp_rtrmgr): [ 2008/06/04 09:24:17 WARNING xorp_rtrmgr:9504 XrlFinderTarget +668 ../xrl/targets/finder_base.cc handle_finder_event_notifier_0_1_register_class_event_interest ] Handling method for finder_event_notifier/0.1/register_class_event_interest failed: XrlCmdError 102 Command failed failed to add watch [ 2008/06/04 09:24:17 ERROR xorp_rtrmgr:9504 RTRMGR +326 xrl_rtrmgr_interface.cc finder_register_done ] Failed to register with finder about XRL xorpsh-9524-localhost (err: Command failed) [ 2008/06/04 09:24:19 WARNING xorp_rtrmgr:9504 XrlFinderTarget +668 ../xrl/targets/finder_base.cc handle_finder_event_notifier_0_1_register_class_event_interest ] Handling method for finder_event_notifier/0.1/register_class_event_interest failed: XrlCmdError 102 Command failed failed to add watch [ 2008/06/04 09:24:19 ERROR xorp_rtrmgr:9504 RTRMGR +326 xrl_rtrmgr_interface.cc finder_register_done ] Failed to register with finder about XRL xorpsh-9524-localhost (err: Command failed) [ 2008/06/04 09:24:21 WARNING xorp_rtrmgr:9504 XrlFinderTarget +668 ../xrl/targets/finder_base.cc handle_finder_event_notifier_0_1_register_class_event_interest ] Handling method for finder_event_notifier/0.1/register_class_event_interest failed: XrlCmdError 102 Command failed failed to add watch [ 2008/06/04 09:24:21 ERROR xorp_rtrmgr:9504 RTRMGR +326 xrl_rtrmgr_interface.cc finder_register_done ] Failed to register with finder about XRL xorpsh-9524-localhost (err: Command failed) Can any one give the solution/idea for the above problem. I have also run the xorpsh from the user "xorp" but still same problem Configuration file has the following:(config.boot) interfaces { restore-original-config-on-shutdown: true interface eth0 { mtu: 1500 description: "data interface" disable: false /* default-system-config */ vif eth0 { disable: false address 192.168.49.16 { prefix-length: 24 broadcast: 192.168.49.255 disable: false } } } } protocols { static { disable: false route 172.16.2.0/24 { next-hop: 172.16.2.1 metric: 1 } } bgp { bgp-id: 192.168.49.16 local-as: 10 peer 192.168.49.16 { local-ip: 192.168.49.16 as: 8 next-hop: 10.10.1.2 } export: "connected,static" } } 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" } } } } From atanu at ICSI.Berkeley.EDU Wed Jun 4 08:16:19 2008 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Wed, 04 Jun 2008 08:16:19 -0700 Subject: [Xorp-users] BGP: error while starting xorpsh In-Reply-To: Message from arvind of "Wed, 04 Jun 2008 09:26:50 +0530." <48461282.7060106@macil.in> Message-ID: <50284.1212592579@tigger.icir.org> Hi, I don't see a BGP error, what I see is the xorpsh printing warning (and error) messages because it is unable to register with the router mananger. While the router manager is starting the routing processes it may not be listening for xorpsh requests. Although the xorpsh prints warning messages if it is started before the router manager has completed starting the routing processes I have never seen a problem, eventually you should see the xorpsh prompt. Did the xorpsh fail to start correctly? Atanu. arvind wrote: > While running xorp_rtrmgr i have the following om the terminal: > > > [root at localhost xorp.cvs.org]# ./rtrmgr/xorp_rtrmgr > [ 2008/06/04 09:16:57 INFO xorp_rtrmgr:9504 RTRMGR +239 > master_conf_tree.cc execute ] Changed modules: interfaces, fea, rib, > policy, static_routes, bgp > [ 2008/06/04 09:16:57 INFO xorp_rtrmgr:9504 RTRMGR +96 > module_manager.cc execute ] Executing module: interfaces (fea/xorp_fea) > [ 2008/06/04 09:16:58 INFO xorp_fea MFEA ] MFEA enabled > [ 2008/06/04 09:16:58 INFO xorp_fea MFEA ] CLI enabled > [ 2008/06/04 09:16:58 INFO xorp_fea MFEA ] CLI started > [ 2008/06/04 09:16:58 INFO xorp_fea MFEA ] MFEA enabled > [ 2008/06/04 09:16:58 INFO xorp_fea MFEA ] CLI enabled > [ 2008/06/04 09:16:58 INFO xorp_fea MFEA ] CLI started > [ 2008/06/04 09:16:59 INFO xorp_rtrmgr:9504 RTRMGR +96 > module_manager.cc execute ] Executing module: fea (fea/xorp_fea) > [ 2008/06/04 09:17:03 INFO xorp_rtrmgr:9504 RTRMGR +96 > module_manager.cc execute ] Executing module: rib (rib/xorp_rib) > [ 9505 +2333 xrl_fea_target.cc ] redist_transaction4_0_1_add_route(): > dst = 192.168.49.0/24 nexthop = 192.168.49.16 ifname = eth0 vifname = > eth0 metric = 0 admin_distance = 0 protocol_origin = connected > [ 2008/06/04 09:17:05 INFO xorp_rtrmgr:9504 RTRMGR +96 > module_manager.cc execute ] Executing module: policy (policy/xorp_policy) > [ 2008/06/04 09:17:07 INFO xorp_rtrmgr:9504 RTRMGR +96 > module_manager.cc execute ] Executing module: static_routes > (static_routes/xorp_static_routes) > [ 9506 +1395 xrl_target.cc ] Target Birth: class = static_routes > instance = static_routes-de9f2f65f9bf1184f3632c0bbd526285 at 127.0.0.1 > [ 2008/06/04 09:17:09 INFO xorp_rtrmgr:9504 RTRMGR +96 > module_manager.cc execute ] Executing module: bgp (bgp/xorp_bgp) > [ 9509 +54 bgp.cc ] BGPMain object created > [ 9509 +75 main.cc ] By default assume there is a rib running > > [ 9509 +1698 bgp.cc ] BGPMain::register_ribname > [ 9509 +1699 bgp.cc ] rib > [ 9506 +1395 xrl_target.cc ] Target Birth: class = bgp instance = > bgp-3bcaa06ba79c588b0f6eb1f438827b2c at 127.0.0.1 > [ 9509 +682 bgp.cc ] interface eth0 vif eth0 address 192.168.49.16 > prefix_len 24 state true > [ 9509 +777 bgp.cc ] BGPMain::main_loop started > [ 9509 +1009 bgp.cc ] Creating new Peer: {192.168.49.16(179) > 192.168.49.16(179)} > [ 9509 +1011 bgp.cc ] Using local address 10.10.1.2 for our nexthop > [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} > [ 9509 +988 bgp.cc ] No match > [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} > [ 9509 +988 bgp.cc ] No match > [ 9509 +946 bgp.cc ] Peer added (fd -1) > [ 9509 +1203 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ > 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} > [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ > 9509 +982 bgp.cc ] Succeeded > [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} > [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ > 9509 +982 bgp.cc ] Succeeded > [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} > [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ > 9509 +982 bgp.cc ] Succeeded > [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} > [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ > 9509 +982 bgp.cc ] Succeeded > [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} > [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ > 9509 +982 bgp.cc ] Succeeded > [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} > [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ > 9509 +982 bgp.cc ] Succeeded > [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} > [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ > 9509 +982 bgp.cc ] Succeeded > [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} > [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ > 9509 +982 bgp.cc ] Succeeded > [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} > [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ > 9509 +982 bgp.cc ] Succeeded > [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} > [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ > 9509 +982 bgp.cc ] Succeeded > [ 9509 +1960 bgp.cc ] IPv4 Unicast > [ 9509 +1977 bgp.cc ] Peer {192.168.49.16(179) 192.168.49.16(179)}. true > [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} > [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ > 9509 +982 bgp.cc ] Succeeded > [ 9509 +1963 bgp.cc ] IPv4 Multicast > [ 9509 +1977 bgp.cc ] Peer {192.168.49.16(179) 192.168.49.16(179)}. false > [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} > [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ > 9509 +982 bgp.cc ] Succeeded > [ 9509 +1966 bgp.cc ] IPv6 Unicast > [ 9509 +1977 bgp.cc ] Peer {192.168.49.16(179) 192.168.49.16(179)}. false > [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} > [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ > 9509 +982 bgp.cc ] Succeeded > [ 9509 +1969 bgp.cc ] IPv6 Multicast > [ 9509 +1977 bgp.cc ] Peer {192.168.49.16(179) 192.168.49.16(179)}. false > [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} > [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ > 9509 +982 bgp.cc ] Succeeded > [ 2008/06/04 09:17:11 WARNING xorp_policy:9507 XifFinderEventNotifier > +275 filter_manager.cc birth ] XXX HACK: PUSHING ROUTES OF connected FOR bgp > [ 2008/06/04 09:17:11 WARNING xorp_policy:9507 XifFinderEventNotifier > +275 filter_manager.cc birth ] XXX HACK: PUSHING ROUTES OF static FOR bgp > [ 9509 +1820 bgp.cc ] nlri 192.168.49.0/24 next hop 192.168.49.16 > unicast 1 multicast 0 > [ 9509 +1820 bgp.cc ] nlri 192.168.49.0/24 next hop 192.168.49.16 > unicast 0 multicast 1 > [ 9506 +1141 xrl_target.cc ] register_interest4 target = bgp addr = > 192.168.49.16 > > > When i started to run the Xorpsh then i got the following error on my > terminal(xorp_rtrmgr): > > > [ 2008/06/04 09:24:17 WARNING xorp_rtrmgr:9504 XrlFinderTarget +668 > ../xrl/targets/finder_base.cc > handle_finder_event_notifier_0_1_register_class_event_interest ] > Handling method for > finder_event_notifier/0.1/register_class_event_interest failed: > XrlCmdError 102 Command failed failed to add watch > [ 2008/06/04 09:24:17 ERROR xorp_rtrmgr:9504 RTRMGR +326 > xrl_rtrmgr_interface.cc finder_register_done ] Failed to register with > finder about XRL xorpsh-9524-localhost (err: Command failed) > [ 2008/06/04 09:24:19 WARNING xorp_rtrmgr:9504 XrlFinderTarget +668 > ../xrl/targets/finder_base.cc > handle_finder_event_notifier_0_1_register_class_event_interest ] > Handling method for > finder_event_notifier/0.1/register_class_event_interest failed: > XrlCmdError 102 Command failed failed to add watch > [ 2008/06/04 09:24:19 ERROR xorp_rtrmgr:9504 RTRMGR +326 > xrl_rtrmgr_interface.cc finder_register_done ] Failed to register with > finder about XRL xorpsh-9524-localhost (err: Command failed) > [ 2008/06/04 09:24:21 WARNING xorp_rtrmgr:9504 XrlFinderTarget +668 > ../xrl/targets/finder_base.cc > handle_finder_event_notifier_0_1_register_class_event_interest ] > Handling method for > finder_event_notifier/0.1/register_class_event_interest failed: > XrlCmdError 102 Command failed failed to add watch > [ 2008/06/04 09:24:21 ERROR xorp_rtrmgr:9504 RTRMGR +326 > xrl_rtrmgr_interface.cc finder_register_done ] Failed to register with > finder about XRL xorpsh-9524-localhost (err: Command failed) > > > Can any one give the solution/idea for the above problem. I have also > run the xorpsh from the user "xorp" but still same problem > > Configuration file has the following:(config.boot) > > interfaces { > restore-original-config-on-shutdown: true > interface eth0 { > mtu: 1500 > description: "data interface" > disable: false > /* default-system-config */ > vif eth0 { > disable: false > address 192.168.49.16 { > prefix-length: 24 > broadcast: 192.168.49.255 > disable: false > } > } > } > } > > protocols { > static { > disable: false > route 172.16.2.0/24 { > next-hop: 172.16.2.1 > metric: 1 > } > } > bgp { > bgp-id: 192.168.49.16 > local-as: 10 > peer 192.168.49.16 { > local-ip: 192.168.49.16 > as: 8 > next-hop: 10.10.1.2 > } > > export: "connected,static" > } > } > 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" > } > } > } > } > > > > > > > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From arvind at macil.in Wed Jun 4 20:14:40 2008 From: arvind at macil.in (arvind) Date: Thu, 05 Jun 2008 08:44:40 +0530 Subject: [Xorp-users] BGP: error while starting xorpsh In-Reply-To: <50284.1212592579@tigger.icir.org> References: <50284.1212592579@tigger.icir.org> Message-ID: <48475A20.3010504@macil.in> Yes It was unable to register with the router manager What may be the reason. If i enable only OSPF it was working fine. If i enable BGP it came to that error. I have started the the xorpsh after the xorp_rtrmgr. I feel the xorp_rtrmgr was not fully executed, because in OSPF the following line is printed No more tasks to run But in BGP it was not printed But unfortunately it was started to work sometimes at that time "No more tasks to run" is printed in the xorp_rtrmgr terminal. Atanu Ghosh wrote: > Hi, > > I don't see a BGP error, what I see is the xorpsh printing warning (and error) > messages because it is unable to register with the router > mananger. While the router manager is starting the routing processes it > may not be listening for xorpsh requests. Although the xorpsh prints > warning messages if it is started before the router manager has > completed starting the routing processes I have never seen a problem, > eventually you should see the xorpsh prompt. > > Did the xorpsh fail to start correctly? > > Atanu. > > arvind wrote: > >> While running xorp_rtrmgr i have the following om the terminal: >> >> >> [root at localhost xorp.cvs.org]# ./rtrmgr/xorp_rtrmgr >> [ 2008/06/04 09:16:57 INFO xorp_rtrmgr:9504 RTRMGR +239 >> master_conf_tree.cc execute ] Changed modules: interfaces, fea, rib, >> policy, static_routes, bgp >> [ 2008/06/04 09:16:57 INFO xorp_rtrmgr:9504 RTRMGR +96 >> module_manager.cc execute ] Executing module: interfaces (fea/xorp_fea) >> [ 2008/06/04 09:16:58 INFO xorp_fea MFEA ] MFEA enabled >> [ 2008/06/04 09:16:58 INFO xorp_fea MFEA ] CLI enabled >> [ 2008/06/04 09:16:58 INFO xorp_fea MFEA ] CLI started >> [ 2008/06/04 09:16:58 INFO xorp_fea MFEA ] MFEA enabled >> [ 2008/06/04 09:16:58 INFO xorp_fea MFEA ] CLI enabled >> [ 2008/06/04 09:16:58 INFO xorp_fea MFEA ] CLI started >> [ 2008/06/04 09:16:59 INFO xorp_rtrmgr:9504 RTRMGR +96 >> module_manager.cc execute ] Executing module: fea (fea/xorp_fea) >> [ 2008/06/04 09:17:03 INFO xorp_rtrmgr:9504 RTRMGR +96 >> module_manager.cc execute ] Executing module: rib (rib/xorp_rib) >> [ 9505 +2333 xrl_fea_target.cc ] redist_transaction4_0_1_add_route(): >> dst = 192.168.49.0/24 nexthop = 192.168.49.16 ifname = eth0 vifname = >> eth0 metric = 0 admin_distance = 0 protocol_origin = connected >> [ 2008/06/04 09:17:05 INFO xorp_rtrmgr:9504 RTRMGR +96 >> module_manager.cc execute ] Executing module: policy (policy/xorp_policy) >> [ 2008/06/04 09:17:07 INFO xorp_rtrmgr:9504 RTRMGR +96 >> module_manager.cc execute ] Executing module: static_routes >> (static_routes/xorp_static_routes) >> [ 9506 +1395 xrl_target.cc ] Target Birth: class = static_routes >> instance = static_routes-de9f2f65f9bf1184f3632c0bbd526285 at 127.0.0.1 >> [ 2008/06/04 09:17:09 INFO xorp_rtrmgr:9504 RTRMGR +96 >> module_manager.cc execute ] Executing module: bgp (bgp/xorp_bgp) >> [ 9509 +54 bgp.cc ] BGPMain object created >> [ 9509 +75 main.cc ] By default assume there is a rib running >> >> [ 9509 +1698 bgp.cc ] BGPMain::register_ribname >> [ 9509 +1699 bgp.cc ] rib >> [ 9506 +1395 xrl_target.cc ] Target Birth: class = bgp instance = >> bgp-3bcaa06ba79c588b0f6eb1f438827b2c at 127.0.0.1 >> [ 9509 +682 bgp.cc ] interface eth0 vif eth0 address 192.168.49.16 >> prefix_len 24 state true >> [ 9509 +777 bgp.cc ] BGPMain::main_loop started >> [ 9509 +1009 bgp.cc ] Creating new Peer: {192.168.49.16(179) >> 192.168.49.16(179)} >> [ 9509 +1011 bgp.cc ] Using local address 10.10.1.2 for our nexthop >> [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} >> [ 9509 +988 bgp.cc ] No match >> [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} >> [ 9509 +988 bgp.cc ] No match >> [ 9509 +946 bgp.cc ] Peer added (fd -1) >> [ 9509 +1203 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ >> 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} >> [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ >> 9509 +982 bgp.cc ] Succeeded >> [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} >> [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ >> 9509 +982 bgp.cc ] Succeeded >> [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} >> [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ >> 9509 +982 bgp.cc ] Succeeded >> [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} >> [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ >> 9509 +982 bgp.cc ] Succeeded >> [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} >> [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ >> 9509 +982 bgp.cc ] Succeeded >> [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} >> [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ >> 9509 +982 bgp.cc ] Succeeded >> [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} >> [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ >> 9509 +982 bgp.cc ] Succeeded >> [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} >> [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ >> 9509 +982 bgp.cc ] Succeeded >> [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} >> [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ >> 9509 +982 bgp.cc ] Succeeded >> [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} >> [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ >> 9509 +982 bgp.cc ] Succeeded >> [ 9509 +1960 bgp.cc ] IPv4 Unicast >> [ 9509 +1977 bgp.cc ] Peer {192.168.49.16(179) 192.168.49.16(179)}. true >> [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} >> [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ >> 9509 +982 bgp.cc ] Succeeded >> [ 9509 +1963 bgp.cc ] IPv4 Multicast >> [ 9509 +1977 bgp.cc ] Peer {192.168.49.16(179) 192.168.49.16(179)}. false >> [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} >> [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ >> 9509 +982 bgp.cc ] Succeeded >> [ 9509 +1966 bgp.cc ] IPv6 Unicast >> [ 9509 +1977 bgp.cc ] Peer {192.168.49.16(179) 192.168.49.16(179)}. false >> [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} >> [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ >> 9509 +982 bgp.cc ] Succeeded >> [ 9509 +1969 bgp.cc ] IPv6 Multicast >> [ 9509 +1977 bgp.cc ] Peer {192.168.49.16(179) 192.168.49.16(179)}. false >> [ 9509 +974 bgp.cc ] Searching for: {192.168.49.16(179) 192.168.49.16(179)} >> [ 9509 +979 bgp.cc ] Trying: {192.168.49.16(179) 192.168.49.16(179)} [ >> 9509 +982 bgp.cc ] Succeeded >> [ 2008/06/04 09:17:11 WARNING xorp_policy:9507 XifFinderEventNotifier >> +275 filter_manager.cc birth ] XXX HACK: PUSHING ROUTES OF connected FOR bgp >> [ 2008/06/04 09:17:11 WARNING xorp_policy:9507 XifFinderEventNotifier >> +275 filter_manager.cc birth ] XXX HACK: PUSHING ROUTES OF static FOR bgp >> [ 9509 +1820 bgp.cc ] nlri 192.168.49.0/24 next hop 192.168.49.16 >> unicast 1 multicast 0 >> [ 9509 +1820 bgp.cc ] nlri 192.168.49.0/24 next hop 192.168.49.16 >> unicast 0 multicast 1 >> [ 9506 +1141 xrl_target.cc ] register_interest4 target = bgp addr = >> 192.168.49.16 >> >> >> When i started to run the Xorpsh then i got the following error on my >> terminal(xorp_rtrmgr): >> >> >> [ 2008/06/04 09:24:17 WARNING xorp_rtrmgr:9504 XrlFinderTarget +668 >> ../xrl/targets/finder_base.cc >> handle_finder_event_notifier_0_1_register_class_event_interest ] >> Handling method for >> finder_event_notifier/0.1/register_class_event_interest failed: >> XrlCmdError 102 Command failed failed to add watch >> [ 2008/06/04 09:24:17 ERROR xorp_rtrmgr:9504 RTRMGR +326 >> xrl_rtrmgr_interface.cc finder_register_done ] Failed to register with >> finder about XRL xorpsh-9524-localhost (err: Command failed) >> [ 2008/06/04 09:24:19 WARNING xorp_rtrmgr:9504 XrlFinderTarget +668 >> ../xrl/targets/finder_base.cc >> handle_finder_event_notifier_0_1_register_class_event_interest ] >> Handling method for >> finder_event_notifier/0.1/register_class_event_interest failed: >> XrlCmdError 102 Command failed failed to add watch >> [ 2008/06/04 09:24:19 ERROR xorp_rtrmgr:9504 RTRMGR +326 >> xrl_rtrmgr_interface.cc finder_register_done ] Failed to register with >> finder about XRL xorpsh-9524-localhost (err: Command failed) >> [ 2008/06/04 09:24:21 WARNING xorp_rtrmgr:9504 XrlFinderTarget +668 >> ../xrl/targets/finder_base.cc >> handle_finder_event_notifier_0_1_register_class_event_interest ] >> Handling method for >> finder_event_notifier/0.1/register_class_event_interest failed: >> XrlCmdError 102 Command failed failed to add watch >> [ 2008/06/04 09:24:21 ERROR xorp_rtrmgr:9504 RTRMGR +326 >> xrl_rtrmgr_interface.cc finder_register_done ] Failed to register with >> finder about XRL xorpsh-9524-localhost (err: Command failed) >> >> >> Can any one give the solution/idea for the above problem. I have also >> run the xorpsh from the user "xorp" but still same problem >> >> Configuration file has the following:(config.boot) >> >> interfaces { >> restore-original-config-on-shutdown: true >> interface eth0 { >> mtu: 1500 >> description: "data interface" >> disable: false >> /* default-system-config */ >> vif eth0 { >> disable: false >> address 192.168.49.16 { >> prefix-length: 24 >> broadcast: 192.168.49.255 >> disable: false >> } >> } >> } >> } >> >> protocols { >> static { >> disable: false >> route 172.16.2.0/24 { >> next-hop: 172.16.2.1 >> metric: 1 >> } >> } >> bgp { >> bgp-id: 192.168.49.16 >> local-as: 10 >> peer 192.168.49.16 { >> local-ip: 192.168.49.16 >> as: 8 >> next-hop: 10.10.1.2 >> } >> >> export: "connected,static" >> } >> } >> 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" >> } >> } >> } >> } >> >> >> >> >> >> >> >> >> _______________________________________________ >> Xorp-users mailing list >> Xorp-users at xorp.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > From james.dutton at gmail.com Thu Jun 5 03:31:25 2008 From: james.dutton at gmail.com (James Courtier-Dutton) Date: Thu, 5 Jun 2008 11:31:25 +0100 Subject: [Xorp-users] Using XORP for PIM-SM Message-ID: Hi, 1) If I have two virtual networks running through a single box. I know I can have two unicast routing tables. How do I get XORP to handle two multicast routing tables and be able to isolate the traffic between them. Essentially, I want to have two isolated IP networks running through a single box and have XORP maintain the isolation for the multicast traffic running over those two networks. 2) I am trying to use tunX interfaces with XORP. If I place an any source multicast (ASM) source at the remote end of the tunX interface. Will XORP be able to treat it as a directly connected interface and correctly forward it in register messages to the RP? 3) How many tunX interfaces can XORP handle? 4) How up to date is the current documentation? 5) If my tunX interfaces dynamically appear and disappear, is xorpsh still the only way to inform XORP that there is a new interface that the PIM-SM should talk to. Is it possible to inform XORP about this change without impacting multicast traffic going through the current XORP instance? 6) I have an application that might mean that I would want to modify the olist from PIM-SM. For example, If I receive a PIM-Join on interface tun1, I would actually want the multicast for that particular group to leave via tun10 instead. So, I would be adding a dynamic config item to the tun1 interface, saying, if I receive a PIM-Join(S,G1), instead of actually forwarding multicast traffic out of tun1, divert (S,G1) traffic to tun10 by adding tun10 to the olist instead of tun1 for that particular group. Where in XORP is the olist calculations done? Kind Regards James From greearb at candelatech.com Thu Jun 5 08:57:08 2008 From: greearb at candelatech.com (Ben Greear) Date: Thu, 05 Jun 2008 08:57:08 -0700 Subject: [Xorp-users] Using XORP for PIM-SM In-Reply-To: References: Message-ID: <48480CD4.9020803@candelatech.com> James Courtier-Dutton wrote: > Hi, > > 1) If I have two virtual networks running through a single box. I know > I can have two unicast routing tables. How do I get XORP to handle two > multicast routing tables and be able to isolate the traffic between > them. Essentially, I want to have two isolated IP networks running > through a single box and have XORP maintain the isolation for the > multicast traffic running over those two networks. > This requires linux kernel patches and xorp hacks. I am working on implementing both currently..but it is not working quite yet. > 2) I am trying to use tunX interfaces with XORP. > If I place an any source multicast (ASM) source at the remote end of > the tunX interface. Will XORP be able to treat it as a directly > connected interface and correctly forward it in register messages to > the RP? > > 3) How many tunX interfaces can XORP handle? > Multicast will have a limit of 32 interfaces per table in my implementation. It would require even more API change and kernel hacking to remove this limitation..and I don't need more, so I don't plan to do this. I'll post a patch as soon as I get something working. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From james.dutton at gmail.com Thu Jun 5 11:25:21 2008 From: james.dutton at gmail.com (James Courtier-Dutton) Date: Thu, 5 Jun 2008 19:25:21 +0100 Subject: [Xorp-users] Using XORP for PIM-SM In-Reply-To: <48480CD4.9020803@candelatech.com> References: <48480CD4.9020803@candelatech.com> Message-ID: >2008/6/5 Ben Greear : >> James Courtier-Dutton wrote: >> 3) How many tunX interfaces can XORP handle? >> > > Multicast will have a limit of 32 interfaces per table in my implementation. > It would require > even more API change and kernel hacking to remove this limitation..and I > don't need more, > so I don't plan to do this. > Ben, Thank you for the quick response. :-) I am interested to understand why the 32 interfaces limit is there. Which kernel API calls are limited to 32 interfaces? I might want to add support for more than 32 interfaces. I am thinking of maybe 1000 interfaces. The total packet bandwidth over all the 1000 interfaces is likely to be low, about 4MBytes/s. Kind Regards James From greearb at candelatech.com Thu Jun 5 13:23:19 2008 From: greearb at candelatech.com (Ben Greear) Date: Thu, 05 Jun 2008 13:23:19 -0700 Subject: [Xorp-users] Using XORP for PIM-SM In-Reply-To: References: <48480CD4.9020803@candelatech.com> Message-ID: <48484B37.1010609@candelatech.com> James Courtier-Dutton wrote: >> 2008/6/5 Ben Greear : >>> James Courtier-Dutton wrote: >>> 3) How many tunX interfaces can XORP handle? >>> >> Multicast will have a limit of 32 interfaces per table in my implementation. >> It would require >> even more API change and kernel hacking to remove this limitation..and I >> don't need more, >> so I don't plan to do this. >> > > Ben, > > Thank you for the quick response. :-) > I am interested to understand why the 32 interfaces limit is there. > Which kernel API calls are limited to 32 interfaces? > I might want to add support for more than 32 interfaces. I am thinking > of maybe 1000 interfaces. > The total packet bandwidth over all the 1000 interfaces is likely to > be low, about 4MBytes/s. The linux kernel uses a 32-bit number as a bitfield, and at least some of that is visible in the user-space to kernel API as well. According to comments, seems to be derived from ancient BSD logic, or something like that. I don't plan on making these changes for my own needs, but I know people who do this sort of thing for hire if you are interested in paying for the feature... Thanks, Ben > > Kind Regards > > James -- Ben Greear Candela Technologies Inc http://www.candelatech.com From james.dutton at gmail.com Thu Jun 5 15:00:40 2008 From: james.dutton at gmail.com (James Courtier-Dutton) Date: Thu, 5 Jun 2008 23:00:40 +0100 Subject: [Xorp-users] Using XORP for PIM-SM In-Reply-To: <48484B37.1010609@candelatech.com> References: <48480CD4.9020803@candelatech.com> <48484B37.1010609@candelatech.com> Message-ID: >2008/6/5 Ben Greear : > > The linux kernel uses a 32-bit number as a bitfield, and at least some of > that > is visible in the user-space to kernel API as well. This only references to bitmaps that I can find relating to network interfaces are vifbitmap_t This is now not used at all by the Linux kernel or xorp. Are you able to identify an example of where this 32-bit bitfield is used in the Linux kernel or the xorp source code? Kind Regards James From pavlin at ICSI.Berkeley.EDU Thu Jun 5 15:18:22 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Thu, 05 Jun 2008 15:18:22 -0700 Subject: [Xorp-users] Using XORP for PIM-SM In-Reply-To: References: Message-ID: <200806052218.m55MIM7K009045@fruitcake.ICSI.Berkeley.EDU> James Courtier-Dutton wrote: > Hi, > > 1) If I have two virtual networks running through a single box. I know > I can have two unicast routing tables. How do I get XORP to handle two > multicast routing tables and be able to isolate the traffic between > them. Essentially, I want to have two isolated IP networks running > through a single box and have XORP maintain the isolation for the > multicast traffic running over those two networks. As Ben said in his reply, this is not possible without modifying both the UNIX kernel and XORP. This is a new frontier for the UNIX multicast world, so it might take a while until it becomes mainstream. In the mean time your best bet is to work with Ben and use his patches (when they are ready) for both Linux and XORP. > 2) I am trying to use tunX interfaces with XORP. > If I place an any source multicast (ASM) source at the remote end of > the tunX interface. Will XORP be able to treat it as a directly > connected interface and correctly forward it in register messages to > the RP? It should. However, XORP itself cannot create tunX interfaces on its own so you have to create them outside of XORP. Configuration-wise (IP addresses, etc), you might be able to configure them via XORP, but if it doesn't work, then you should use the default-system-config statement in configuraiton like: interfaces { interface tun0 { default-system-config } interface tun1 { default-system-config } ... } > 3) How many tunX interfaces can XORP handle? As Ben mentioned in another email, there is the 32 interfaces limit in the BSD multicast routing model. There is a work-around this, but then you will start hitting other limits in the system (number of max. joined multicast groups, etc). Please see entries "MLD/IGMP" and "PIM-SM" inside file xorp/ERRATA. There you will find information how to get around those limits. Note that the information there is from July 2006 so it might or might not work for more recent OS-es. Please let us know whether that information is sufficient to get around the limit or whether something else is missing. > 4) How up to date is the current documentation? What is on the Web site is for XORP-1.4 release. The documentation that you get from anon CVS (in the xorp/docs sub-directory) should be up to date with the current code (note that you need LaTeX to compile all the documents). The notable exception is the FEA: it has been through major design changes since the 1.4 release, but its internals shouldn't matter to you. > 5) If my tunX interfaces dynamically appear and disappear, is xorpsh > still the only way to inform XORP that there is a new interface that > the PIM-SM should talk to. Is it possible to inform XORP about this > change without impacting multicast traffic going through the current > XORP instance? If you use the default-system-config statement (see above), and if you use the latest XORP code from CVS then you should be able to start XORP even if the interfaces are not there. Once they are configured, then the XORP FEA should pick-up the new information and propagate it to the routing processes. However, I am not sure whether all routing protocols will be able to work properly. The multicast protocols (IGMP/MLD and PIM-SM) for example have some old outstanding bugs that are related to not being able to start if some of the interfaces are not configured/operating properly. Make sure you use the latest code from CVS and give it a try to see whether it works. If this fails to work, then you need to have a script that uses xorpsh to manipulate the XORP configuration (adding/deleting interfaces, etc). > 6) I have an application that might mean that I would want to modify > the olist from PIM-SM. For example, If I receive a PIM-Join on > interface tun1, I would actually want the multicast for that > particular group to leave via tun10 instead. So, I would be adding a > dynamic config item to the tun1 interface, saying, if I receive a > PIM-Join(S,G1), instead of actually forwarding multicast traffic out > of tun1, divert (S,G1) traffic to tun10 by adding tun10 to the olist > instead of tun1 for that particular group. Where in XORP is the olist > calculations done? One good interception point in the olist calculation is method PimMfc::update_mfc() inside file pim/pim_mfc.cc I would be interested to see what solution you will use at the end to achieve this inter-interface mechanism. Regards, Pavlin From pavlin at ICSI.Berkeley.EDU Thu Jun 5 15:28:37 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Thu, 05 Jun 2008 15:28:37 -0700 Subject: [Xorp-users] Using XORP for PIM-SM In-Reply-To: <48484B37.1010609@candelatech.com> References: <48480CD4.9020803@candelatech.com> <48484B37.1010609@candelatech.com> Message-ID: <200806052228.m55MSbYZ010479@fruitcake.ICSI.Berkeley.EDU> Ben Greear wrote: > James Courtier-Dutton wrote: > >> 2008/6/5 Ben Greear : > >>> James Courtier-Dutton wrote: > >>> 3) How many tunX interfaces can XORP handle? > >>> > >> Multicast will have a limit of 32 interfaces per table in my implementation. > >> It would require > >> even more API change and kernel hacking to remove this limitation..and I > >> don't need more, > >> so I don't plan to do this. > >> > > > > Ben, > > > > Thank you for the quick response. :-) > > I am interested to understand why the 32 interfaces limit is there. > > Which kernel API calls are limited to 32 interfaces? > > I might want to add support for more than 32 interfaces. I am thinking > > of maybe 1000 interfaces. > > The total packet bandwidth over all the 1000 interfaces is likely to > > be low, about 4MBytes/s. > > The linux kernel uses a 32-bit number as a bitfield, and at least some of that > is visible in the user-space to kernel API as well. The 32-bit bitfield was probably used in older kernels and/or userland programs. Now the olist in the kernel for example should be specified in an array of size MAXVIFS which can be redefined as appropriate. Approx. 2 years ago I had an interaction with a fellow who also wanted to increase the number of max. vifs in the Linux kernel. I believe he was able to achieve few hundred vifs, but I don't know whether he needed any more than this or whether he was hitting some other limits. The notes (and the discoveries re. other system limits) in the xorp/ERRATA file on the subject are from that experiment with him. In other words, it should be possible, but requires kernel and XORP recompilation, and system parameters tweaking. See the IGMP/MLD and PIM-SM entries in the xorp/ERRATA file for details. If you find some other limits, please us know so we can update the documentation. Regards, Pavlin > According to comments, seems to be derived from ancient BSD logic, > or something like that. > > I don't plan on making these changes for my own needs, but > I know people who do this sort of thing for hire if you are interested > in paying for the feature... > > Thanks, > Ben > > > > > > Kind Regards > > > > James > > > -- > 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 james.dutton at gmail.com Fri Jun 6 02:08:42 2008 From: james.dutton at gmail.com (James Courtier-Dutton) Date: Fri, 6 Jun 2008 10:08:42 +0100 Subject: [Xorp-users] Using XORP for PIM-SM In-Reply-To: <200806052228.m55MSbYZ010479@fruitcake.ICSI.Berkeley.EDU> References: <48480CD4.9020803@candelatech.com> <48484B37.1010609@candelatech.com> <200806052228.m55MSbYZ010479@fruitcake.ICSI.Berkeley.EDU> Message-ID: >2008/6/5 Pavlin Radoslavov : >> Ben Greear wrote: >> >> The linux kernel uses a 32-bit number as a bitfield, and at least some of that >> is visible in the user-space to kernel API as well. > > The 32-bit bitfield was probably used in older kernels and/or > userland programs. > Now the olist in the kernel for example should be specified in an > array of size MAXVIFS which can be redefined as appropriate. > > Approx. 2 years ago I had an interaction with a fellow who also > wanted to increase the number of max. vifs in the Linux kernel. > I believe he was able to achieve few hundred vifs, but I don't know > whether he needed any more than this or whether he was hitting some > other limits. > The notes (and the discoveries re. other system limits) in the > xorp/ERRATA file on the subject are from that experiment with him. > In other words, it should be possible, but requires kernel and XORP > recompilation, and system parameters tweaking. See the IGMP/MLD and > PIM-SM entries in the xorp/ERRATA file for details. > If you find some other limits, please us know so we can update the > documentation. > Thank you Ben and Pavlin very much. The ERRATA file seems to agree with what I found in the kernel, in that the bitfield is not used anymore and an array of size MAXVIFS combined with other limit adjustments is used instead. The number of multicast interfaces limit of 32 was going to be a problem. It does not seem so much of a problem now. I will report back if I end up getting XORP to work with my somewhat different network setup. As a general backround, the network has a mix of PTP (Point-to-Point) and P2MP (Point to Multipoint) links, so the PIM-Hello, Join/Prune etc, will be going down the PTP links, with some of the multicast traffic being diverted to go down the P2MP links. PIM-SM RFC4601 only covers PTP and hub/switch based LAN networks link types. It is a shame we don't have an PIM-SM RFC to cover P2MP link types. Kind Regards James From james.dutton at gmail.com Fri Jun 6 06:07:17 2008 From: james.dutton at gmail.com (James Courtier-Dutton) Date: Fri, 6 Jun 2008 14:07:17 +0100 Subject: [Xorp-users] Using XORP for PIM-SM In-Reply-To: <200806052218.m55MIM7K009045@fruitcake.ICSI.Berkeley.EDU> References: <200806052218.m55MIM7K009045@fruitcake.ICSI.Berkeley.EDU> Message-ID: >2008/6/5 Pavlin Radoslavov : >> James Courtier-Dutton wrote: > > >> 4) How up to date is the current documentation? > > What is on the Web site is for XORP-1.4 release. > The documentation that you get from anon CVS (in the xorp/docs > sub-directory) should be up to date with the current code > (note that you need LaTeX to compile all the documents). > The notable exception is the FEA: it has been through major design > changes since the 1.4 release, but its internals shouldn't matter > to you. > I noticed in the documentation that XORP-1.4 does not do SSM. Is this statement correct? Does XORP only do ASM? Kind Regards James From pavlin at ICSI.Berkeley.EDU Fri Jun 6 08:21:44 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Fri, 06 Jun 2008 08:21:44 -0700 Subject: [Xorp-users] Using XORP for PIM-SM In-Reply-To: References: <200806052218.m55MIM7K009045@fruitcake.ICSI.Berkeley.EDU> Message-ID: <200806061521.m56FLiY1026971@fruitcake.ICSI.Berkeley.EDU> > I noticed in the documentation that XORP-1.4 does not do SSM. > Is this statement correct? Does XORP only do ASM? XORP does SSM as well so the documentation is incorrect. Could you point us where exactly in the documentation you found that statement so we can correct it. FYI, the default IGMP and MLD versions in XORP are 2 and 1 respectively so if you want to use IGMP/MLD with SSM receivers you need to set the version to 3 and 2 resp. For PIM-SM you don't need any special configuration. Regards, Pavlin From mayank.kandari at gmail.com Sun Jun 8 22:29:10 2008 From: mayank.kandari at gmail.com (Mayank Kandari) Date: Mon, 9 Jun 2008 10:59:10 +0530 Subject: [Xorp-users] Routing using click Message-ID: <328b1be80806082229q60c29602x58eb89590da922d9@mail.gmail.com> Hello, I have installed click in my system in kernel mode and using click as a forwarding engine. What changes I will have to make that all the packets generated in my system routed via click not linux networking stack. -- regards Mayank Kandari Staff Scientist C-DAC Mumbai Juhu - 400049 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080609/c7cbc386/attachment.html From pavlin at ICSI.Berkeley.EDU Mon Jun 9 09:08:16 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Mon, 09 Jun 2008 09:08:16 -0700 Subject: [Xorp-users] Routing using click In-Reply-To: <328b1be80806082229q60c29602x58eb89590da922d9@mail.gmail.com> References: <328b1be80806082229q60c29602x58eb89590da922d9@mail.gmail.com> Message-ID: <200806091608.m59G8GUJ025889@fruitcake.ICSI.Berkeley.EDU> Mayank Kandari wrote: > Hello, > I have installed click in my system in kernel mode and using click > as a forwarding engine. What changes I will have to make that all the > packets generated in my system routed via click not linux networking stack. You could try to set the following flag in the XORP configuration to false: fea { click { duplicate-routes-to-kernel: false ... } ... } This should stop the routes generated by XORP from being installed into the kernel, though all the routes that were already in the kernel will remain there. If the above doesn't work for you, then what you need to do is to get it working by using only Click (i.e., without using XORP). For that you might need to ask on the Click mailing list. Once you get it working (e.g., if you need a special Click config), then go back to XORP and apply the fix/configuration. Regards, Pavlin > -- > regards > Mayank Kandari > Staff Scientist > C-DAC Mumbai > Juhu - 400049 > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From james.dutton at gmail.com Mon Jun 9 12:46:07 2008 From: james.dutton at gmail.com (James Courtier-Dutton) Date: Mon, 9 Jun 2008 20:46:07 +0100 Subject: [Xorp-users] Using XORP for PIM-SM In-Reply-To: <200806061521.m56FLiY1026971@fruitcake.ICSI.Berkeley.EDU> References: <200806052218.m55MIM7K009045@fruitcake.ICSI.Berkeley.EDU> <200806061521.m56FLiY1026971@fruitcake.ICSI.Berkeley.EDU> Message-ID: 2008/6/6 Pavlin Radoslavov : >> I noticed in the documentation that XORP-1.4 does not do SSM. >> Is this statement correct? Does XORP only do ASM? > > XORP does SSM as well so the documentation is incorrect. > Could you point us where exactly in the documentation you found that > statement so we can correct it. I cannot find the document I found it in. I assume I was accidentally looking in an old document, as I cannot find the statement in any of the 1.4 docs now. > > FYI, the default IGMP and MLD versions in XORP are 2 and 1 > respectively so if you want to use IGMP/MLD with SSM receivers you > need to set the version to 3 and 2 resp. For PIM-SM you don't need > any special configuration. > I had read the docs enough to work out that, but thankyou anyway. I can't seem to find any simple tools to generate IGMP V3 messages so I can test SSM properly. I will probably just have to write my own. James From james.dutton at gmail.com Mon Jun 9 12:50:30 2008 From: james.dutton at gmail.com (James Courtier-Dutton) Date: Mon, 9 Jun 2008 20:50:30 +0100 Subject: [Xorp-users] Using XORP for PIM-SM In-Reply-To: <200806052228.m55MSbYZ010479@fruitcake.ICSI.Berkeley.EDU> References: <48480CD4.9020803@candelatech.com> <48484B37.1010609@candelatech.com> <200806052228.m55MSbYZ010479@fruitcake.ICSI.Berkeley.EDU> Message-ID: 2008/6/5 Pavlin Radoslavov : > > The 32-bit bitfield was probably used in older kernels and/or > userland programs. > Now the olist in the kernel for example should be specified in an > array of size MAXVIFS which can be redefined as appropriate. > > Approx. 2 years ago I had an interaction with a fellow who also > wanted to increase the number of max. vifs in the Linux kernel. > I believe he was able to achieve few hundred vifs, but I don't know > whether he needed any more than this or whether he was hitting some > other limits. > The notes (and the discoveries re. other system limits) in the > xorp/ERRATA file on the subject are from that experiment with him. > In other words, it should be possible, but requires kernel and XORP > recompilation, and system parameters tweaking. See the IGMP/MLD and > PIM-SM entries in the xorp/ERRATA file for details. > If you find some other limits, please us know so we can update the > documentation. > Thank you. I followed the ERRATA, and managed to test 40 interfaces all doing IGMP and PIM-SM today. Only one minor gripe left, and that is the documented, non handling of un-numbered PTP links. It is not that important to the project at the moment, but if I implement it, I will post a patch. James From james.dutton at gmail.com Wed Jun 11 05:36:05 2008 From: james.dutton at gmail.com (James Courtier-Dutton) Date: Wed, 11 Jun 2008 13:36:05 +0100 Subject: [Xorp-users] setsockopt(MRT_ADD_MFC, (192.168.155.1, 231.1.2.4)) failed: Invalid argument Message-ID: Hi, Can anyone help me with reasons why the MRT_ADD_MFC failed? I have tried the most obvious things, like checking for the correct kernel support for multicast etc. See log below Kind Regards James [ 2008/06/11 13:18:19 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 1 vif_index = 4 src = 192.168.155.1 dst = 231.1.2.4 [ 2008/06/11 13:18:19 TRACE xorp_pimsm4 PIM ] RX NOCACHE signal from MFEA_4: vif_index = 4 src = 192.168.155.1 dst = 231.1.2.4 [ 2008/06/11 13:18:19 TRACE xorp_pimsm4 PIM ] Add MFC entry: (192.168.155.1, 231.1.2.4) iif = 4 olist = ......O olist_disable_wrongvif = OOOOOO. [ 2008/06/11 13:18:19 TRACE xorp_pimsm4 PIM ] Add dataflow monitor: source = 192.168.155.1 group = 231.1.2.4 threshold_interval_sec = 210 threshold_interval_usec = 0 threshold_packets = 0 threshold_bytes = 0 is_threshold_in_packets = 1 is_threshold_in_bytes = 0 is_geq_upcall = 0 is_leq_upcall = 1 [ 2008/06/11 13:18:19 TRACE xorp_fea MFEA ] Add MFC entry: (192.168.155.1, 231.1.2.4) iif = 4 olist = ......O [ 2008/06/11 13:18:19 ERROR xorp_fea:2766 MFEA +1210 mfea_mrouter.cc add_mfc ] setsockopt(MRT_ADD_MFC, (192.168.155.1, 231.1.2.4)) failed: Invalid argument [ 2008/06/11 13:18:19 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfea/0.1/add_mfc4 failed: XrlCmdError 102 Command failed Cannot add MFC for source 192.168.155.1 and group 231.1.2.4 with iif_vif_index = 4 [ 2008/06/11 13:18:19 ERROR xorp_pimsm4:2786 PIM +1854 xrl_pim_node.cc mfea_client_send_add_delete_mfc_cb ] Cannot add a multicast forwarding entry with the MFEA: 102 Command failed Cannot add MFC for source 192.168.155.1 and group 231.1.2.4 with iif_vif_index = 4 [ 2008/06/11 13:18:19 ERROR xorp_fea:2766 MFEA +1903 mfea_mrouter.cc get_sg_count ] ioctl(SIOCGETSGCNT, (192.168.155.1 231.1.2.4)) failed: Cannot assign requested address [ 2008/06/11 13:18:19 ERROR xorp_fea:2766 MFEA +126 mfea_dataflow.cc add_entry ] Cannot add dataflow monitor for (192.168.155.1, 231.1.2.4): invalid request [ 2008/06/11 13:18:19 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfea/0.1/add_dataflow_monitor4 failed: XrlCmdError 102 Command failed Cannot add dataflow monitor for (192.168.155.1, 231.1.2.4): invalid request [ 2008/06/11 13:18:19 ERROR xorp_pimsm4:2786 PIM +2133 xrl_pim_node.cc mfea_client_send_add_delete_dataflow_monitor_cb ] Cannot add a dataflow monitor with the MFEA: 102 Command failed Cannot add dataflow monitor for (192.168.155.1, 231.1.2.4): invalid request From james.dutton at gmail.com Wed Jun 11 05:54:18 2008 From: james.dutton at gmail.com (James Courtier-Dutton) Date: Wed, 11 Jun 2008 13:54:18 +0100 Subject: [Xorp-users] setsockopt(MRT_ADD_MFC, (192.168.155.1, 231.1.2.4)) failed: Invalid argument In-Reply-To: References: Message-ID: No matter. I have found the problem. The value on MAXVIFS in the kernel did not match the value used by XORP. 2008/6/11 James Courtier-Dutton : > Hi, > > Can anyone help me with reasons why the MRT_ADD_MFC failed? > I have tried the most obvious things, like checking for the correct > kernel support for multicast etc. > > See log below > > Kind Regards > > James > > > > [ 2008/06/11 13:18:19 TRACE xorp_fea MFEA ] RX kernel signal: > message_type = 1 vif_index = 4 src = 192.168.155.1 dst = 231.1.2.4 > [ 2008/06/11 13:18:19 TRACE xorp_pimsm4 PIM ] RX NOCACHE signal from > MFEA_4: vif_index = 4 src = 192.168.155.1 dst = 231.1.2.4 > [ 2008/06/11 13:18:19 TRACE xorp_pimsm4 PIM ] Add MFC entry: > (192.168.155.1, 231.1.2.4) iif = 4 olist = ......O > olist_disable_wrongvif = OOOOOO. > [ 2008/06/11 13:18:19 TRACE xorp_pimsm4 PIM ] Add dataflow monitor: > source = 192.168.155.1 group = 231.1.2.4 threshold_interval_sec = 210 > > threshold_interval_usec = 0 threshold_packets = 0 threshold_bytes = 0 > is_threshold_in_packets = 1 is_threshold_in_bytes = 0 is_geq_upcall = > 0 is_leq_upcall = > > 1 > [ 2008/06/11 13:18:19 TRACE xorp_fea MFEA ] Add MFC entry: > (192.168.155.1, 231.1.2.4) iif = 4 olist = ......O > [ 2008/06/11 13:18:19 ERROR xorp_fea:2766 MFEA +1210 mfea_mrouter.cc > add_mfc ] setsockopt(MRT_ADD_MFC, (192.168.155.1, 231.1.2.4)) failed: > Invalid argument > [ 2008/06/11 13:18:19 WARNING xorp_fea XrlMfeaTarget ] Handling method > for mfea/0.1/add_mfc4 failed: XrlCmdError 102 Command failed Cannot > add MFC for source > > 192.168.155.1 and group 231.1.2.4 with iif_vif_index = 4 > [ 2008/06/11 13:18:19 ERROR xorp_pimsm4:2786 PIM +1854 > xrl_pim_node.cc mfea_client_send_add_delete_mfc_cb ] Cannot add a > multicast forwarding entry with the > > MFEA: 102 Command failed Cannot add MFC for source 192.168.155.1 and > group 231.1.2.4 with iif_vif_index = 4 > [ 2008/06/11 13:18:19 ERROR xorp_fea:2766 MFEA +1903 mfea_mrouter.cc > get_sg_count ] ioctl(SIOCGETSGCNT, (192.168.155.1 231.1.2.4)) failed: > Cannot assign > > requested address > [ 2008/06/11 13:18:19 ERROR xorp_fea:2766 MFEA +126 mfea_dataflow.cc > add_entry ] Cannot add dataflow monitor for (192.168.155.1, > 231.1.2.4): invalid request > [ 2008/06/11 13:18:19 WARNING xorp_fea XrlMfeaTarget ] Handling method > for mfea/0.1/add_dataflow_monitor4 failed: XrlCmdError 102 Command > failed Cannot add > > dataflow monitor for (192.168.155.1, 231.1.2.4): invalid request > [ 2008/06/11 13:18:19 ERROR xorp_pimsm4:2786 PIM +2133 > xrl_pim_node.cc mfea_client_send_add_delete_dataflow_monitor_cb ] > Cannot add a dataflow monitor with > > the MFEA: 102 Command failed Cannot add dataflow monitor for > (192.168.155.1, 231.1.2.4): invalid request > From nezleshmil at gmail.com Wed Jun 11 12:27:15 2008 From: nezleshmil at gmail.com (NezLeShmil) Date: Wed, 11 Jun 2008 21:27:15 +0200 Subject: [Xorp-users] BGP update never sent out - why ? References: Message-ID: <007801c8cbf9$295bb3b0$0300000a@sweisslt> Somebody knows why sometimes a BGP update is not sent ? it is enter the ribin and never go out. I am getting a debug message like "route already queued" from the file resolver_nexthop. thanks. From nezleshmil at gmail.com Thu Jun 12 03:36:13 2008 From: nezleshmil at gmail.com (NezLeShmil) Date: Thu, 12 Jun 2008 12:36:13 +0200 Subject: [Xorp-users] BGP update never sent out - why ? References: <4850E2D4.70909@incunabulum.net> Message-ID: <00d001c8cc78$2500cb50$54000a0a@sweisslt> I am using XORP Release-1.4. The exact Debug Message I am getting is: [ 6965 +723 ../../bgp/next_hop_resolver.cc ] This registration is already queued When I am seeing this message the BGP Update which is supposed by the xorp_bgp is not sent. That is a part of my log which is HUGE ! the xorp is connecting to a real Core Router and receving around 250 000 routes, and updates at a rate of 10 TPS. Xorp LOG: [ 6965 +111 ../../bgp/bgp_trie.cc ] deleting route for 167.203.144.0/20 with attributes 0xc858068[ 6965 +117 ../../bgp/bgp_trie.cc ] and erasing chain [ 6965 +127 ../../bgp/bgp_trie.cc ] [ 6965 +69 ../../bgp/attribute_manager.cc ] AttributeManager::delete_attribute_list 0xc858068 [ 6965 +76 ../../bgp/attribute_manager.cc ] ** (-) ref count for 0xc858068 now 1 [ 6965 +39 ../../bgp/attribute_manager.cc ] AttributeManager::add_attribute_list [ 6965 +55 ../../bgp/attribute_manager.cc ] ** (+) ref count for 0xc90ab58 now 3 [ 6965 +56 ../../bgp/attribute_manager.cc ] done [ 6965 +83 ../../bgp/bgp_trie.cc ] storing route for 167.203.144.0/20 with attributes 0xc90ab58[ 6965 +1103 ../../libxorp/ref_trie.hh ] ++ insert 167.203.144.0/20 [ 6965 +1150 ../../libxorp/ref_trie.hh ] case D: |----.-x--| [ 6965 +1146 ../../libxorp/ref_trie.hh ] case C: |--x-.----| [ 6965 +1150 ../../libxorp/ref_trie.hh ] case D: |----.-x--| [ 6965 +1146 ../../libxorp/ref_trie.hh ] case C: |--x-.----| [ 6965 +1146 ../../libxorp/ref_trie.hh ] case C: |--x-.----| [ 6965 +1150 ../../libxorp/ref_trie.hh ] case D: |----.-x--| [ 6965 +1150 ../../libxorp/ref_trie.hh ] case D: |----.-x--| [ 6965 +1150 ../../libxorp/ref_trie.hh ] case D: |----.-x--| [ 6965 +1150 ../../libxorp/ref_trie.hh ] case D: |----.-x--| [ 6965 +1150 ../../libxorp/ref_trie.hh ] case D: |----.-x--| [ 6965 +1146 ../../libxorp/ref_trie.hh ] case C: |--x-.----| [ 6965 +1146 ../../libxorp/ref_trie.hh ] case C: |--x-.----| [ 6965 +1150 ../../libxorp/ref_trie.hh ] case D: |----.-x--| [ 6965 +1146 ../../libxorp/ref_trie.hh ] case C: |--x-.----| [ 6965 +1150 ../../libxorp/ref_trie.hh ] case D: |----.-x--| [ 6965 +1150 ../../libxorp/ref_trie.hh ] case D: |----.-x--| [ 6965 +1150 ../../libxorp/ref_trie.hh ] case D: |----.-x--| [ 6965 +39 ../../bgp/attribute_manager.cc ] AttributeManager::add_attribute_list [ 6965 +55 ../../bgp/attribute_manager.cc ] ** (+) ref count for 0xc90ab58 now 4 [ 6965 +56 ../../bgp/attribute_manager.cc ] done [ 6965 +90 ../../bgp/bgp_trie.cc ] on new chain[ 6965 +93 ../../bgp/bgp_trie.cc ] [ 6965 +69 ../../bgp/attribute_manager.cc ] AttributeManager::delete_attribute_list 0xc90ab58 [ 6965 +76 ../../bgp/attribute_manager.cc ] ** (-) ref count for 0xc90ab58 now 3 [ 6965 +80 ../../bgp/next_hop_resolver.cc ] E nexthop 24.30.219.200 net 167.203.144.0/20 requested 0x84270b8 [ 6965 +565 ../../bgp/next_hop_resolver.cc ] C nexthop 24.30.219.200 reference count incr 1 [ 6965 +711 ../../bgp/next_hop_resolver.cc ] R nexthop 24.30.219.200 net 167.203.144.0/20 requested 0x84270b8 [ 6965 +723 ../../bgp/next_hop_resolver.cc ] This registration is already queued [ 6965 +69 ../../bgp/attribute_manager.cc ] AttributeManager::delete_attribute_list 0xc90ab58 [ 6965 +76 ../../bgp/attribute_manager.cc ] ** (-) ref count for 0xc90ab58 now 2 [ 2008/06/02 09:57:01 TRACE xorp_bgp:6965 BGP +281 ../../bgp/peer.cc get_message ] Peer {24.28.212.18(179) 24.30.219.207(179)}: Receive: Update Packet - Next Hop Attribute 24.30.219.1 - Origin Path Attribute - IGP - AS Path Attribute AsPath: [AS/65201, AS/65199, AS/65200, AS/64990, AS/13560, AS/7843, AS/3549, AS/10026, AS/18485, AS/18880, AS/18880] - Local Preference Attribute - 100 - Community Attribute 65300:1300 0xff140514 - Nlri 198.175.161.0/24 ----- Original Message ----- From: "Bruce M Simpson" To: "NezLeShmil" Cc: Sent: Thursday, June 12, 2008 10:48 AM Subject: Re: [Xorp-users] BGP update never sent out - why ? > Hi, > > I was forwarded your question. > However, it's difficult to say what the problem could be without more data. > > Can you please provide further information: > > * your full XORP configuration > > * the version of XORP which you are using > > * the *exact* error message which you are seeing when an update is not > sent. > * Have you looked at what is being sent to your BGP peers with a > packet capture utility e.g. Wireshark? > > * Also, have you compiled XORP with debugging messages enabled? > The messages you are seeing should not be seen otherwise. > > thanks! > BMS > > P.S. I am not on xorp-users@ just at the moment so please Cc any replies > to the list. > From ssohn at gmu.edu Thu Jun 12 16:46:24 2008 From: ssohn at gmu.edu (Eric Sohn) Date: Thu, 12 Jun 2008 19:46:24 -0400 Subject: [Xorp-users] Latest version of xorp Message-ID: <000601c8cce6$867f4050$937dc0f0$@edu> Hello, I heard that there is a new version of xorp which is 1.5.2. Would you let me know how to get it? I am working on Linux kernel 2.6.11. Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080612/9d0cd831/attachment.html From bms at incunabulum.net Fri Jun 13 02:20:41 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Fri, 13 Jun 2008 10:20:41 +0100 Subject: [Xorp-users] Latest version of xorp In-Reply-To: <000601c8cce6$867f4050$937dc0f0$@edu> References: <000601c8cce6$867f4050$937dc0f0$@edu> Message-ID: <48523BE9.2020606@incunabulum.net> Eric Sohn wrote: > > I heard that there is a new version of xorp which is 1.5.2. > > Would you let me know how to get it? I am working on Linux kernel 2.6.11. > Hi, A new release is on the cards, but has not been cut yet. We hope to make the release within the next 6-9 weeks. thanks BMS From yocosty at yahoo.com Fri Jun 13 07:33:00 2008 From: yocosty at yahoo.com (grumazescu costi) Date: Fri, 13 Jun 2008 07:33:00 -0700 (PDT) Subject: [Xorp-users] problem starting xorp Message-ID: <825538.16998.qm@web36303.mail.mud.yahoo.com> I'm new to xorp...just a couple of days. I'm trying to run xorp in a virtual machine(netkit) but it won't start. Other colegues use it with no problem but on my computer won't run. What am I doing wrong? pc:~#/etc/init.d/xorp start Starting eXtensible Open Router Platform : xorp. pc:~#xorpsh Waiting for xorp_rtrmgr... pc:~#/etc/init.d/xorp stop Stopping eXtensible Open Router Platform : xorp apparently not running. pc:~# -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080613/beeae4f5/attachment.html From bms at incunabulum.net Fri Jun 13 09:44:52 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Fri, 13 Jun 2008 17:44:52 +0100 Subject: [Xorp-users] problem starting xorp In-Reply-To: <825538.16998.qm@web36303.mail.mud.yahoo.com> References: <825538.16998.qm@web36303.mail.mud.yahoo.com> Message-ID: <4852A404.60002@incunabulum.net> grumazescu costi wrote: > I'm new to xorp...just a couple of days. I'm trying to run xorp in a > virtual machine(netkit) but it won't start. Other colegues use it with > no problem but on my computer won't run. What am I doing wrong? Hi, Please post your configuration file so someone can help you. cheers BMS From yocosty at yahoo.com Fri Jun 13 12:24:59 2008 From: yocosty at yahoo.com (grumazescu costi) Date: Fri, 13 Jun 2008 12:24:59 -0700 (PDT) Subject: [Xorp-users] problem starting xorp Message-ID: <866940.64775.qm@web36304.mail.mud.yahoo.com> I'm new to xorp...just a couple of days. I'm trying to run xorp in a virtual machine(netkit) but it won't start. Other colegues use it with no problem but on my computer won't run. What am I doing wrong? pc:~#/etc/init.d/xorp start Starting eXtensible Open Router Platform : xorp. pc:~#xorpsh Waiting for xorp_rtrmgr... pc:~#/etc/init.d/xorp stop Stopping eXtensible Open Router Platform : xorp apparently not running. pc:~# CONF.BOOT interfaces { restore-original-config-on-shutdown: false interface eth0 { description: "Ethernet Interface #1" disable: false default-system-config } interface eth1 { description: "Ethernet Interface #2" disable: false default-system-config }} fea { unicast-forwarding4 { disable: false forwarding-entries { retain-on-startup: false retain-on-shutdown: false }}} plumbing { mfea4 { disable: false interface eth0 { vif eth0 { disable: false }} interface eth1 { vif eth1 { 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 } } interface eth1 { vif eth1 { disable: false }} traceoptions { flag all { disable: false } } }} protocols { pimsm4 { disable: false interface eth0 { vif eth0 { disable: false } } interface eth1 { vif eth1 { disable: false } } bootstrap { disable: false cand-bsr { scope-zone 224.0.0.0/4 { cand-bsr-by-vif-name: "eth0" }} cand-rp { group-prefix 224.0.0.0/4 { cand-rp-by-vif-name: "eth0" } } } switch-to-spt-threshold { disable: false interval: 100 bytes: 102400 } traceoptions { flag all { disable: false } } } } protocols { fib2mrib { disable: false }} -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080613/6b34b970/attachment.html From bms at incunabulum.net Sun Jun 15 03:19:34 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Sun, 15 Jun 2008 11:19:34 +0100 Subject: [Xorp-users] problem starting xorp In-Reply-To: <866940.64775.qm@web36304.mail.mud.yahoo.com> References: <866940.64775.qm@web36304.mail.mud.yahoo.com> Message-ID: <4854ECB6.80703@incunabulum.net> grumazescu costi wrote: > I'm new to xorp...just a couple of days. I'm trying to run xorp in a > virtual machine(netkit) but it won't start. Other colegues use it with > no problem but on my computer won't run. What am I doing wrong? OK. I don't see anything obviously wrong in the configuration file. We need to see what the Router Manager logs on startup, can you provide this too? From yocosty at yahoo.com Mon Jun 16 04:53:26 2008 From: yocosty at yahoo.com (grumazescu costi) Date: Mon, 16 Jun 2008 04:53:26 -0700 (PDT) Subject: [Xorp-users] problem starting xorp Message-ID: <787017.5598.qm@web36308.mail.mud.yahoo.com> I have a problem with starting xorp daemon in a virtual machine(router). I thought it might be a problem with my vm but I also tried to run it on a router from an official netkit lab(the one with rip - router r5). Here's how it is: I tried running normally...won't work. r5 login: root (automatic login) Last login: Mon Jun 16 10:56:47 UTC 2008 on tty1 r5:~# /etc/init.d/xorp start Starting eXtensible Open Router Platform : xorp. r5:~# xorpsh Waiting for xorp_rtrmgr... r5:~# /etc/init.d/xorp stop Stopping eXtensible Open Router Platform: xorp apparently not running. It seems like it's not starting at all. r5:~# xorp xorp_profiler xorp_rtrmgr xorpsh r5:~# xorp_rtrmgr [ 2008/06/16 11:22:37 ERROR xorp_rtrmgr:438 RTRMGR +330 main_rtrmgr.cc run ] rt rmgr shutting down due to an init error: Failed to open config file: /usr/lib/xo rp/config.boot Then I discovered this...so I tried to fix it r5:~# cp /etc/xorp/config.boot /usr/lib/xorp/ r5:~# /etc/init.d/xorp start Starting eXtensible Open Router Platform : xorp. r5:~# xorpsh Waiting for xorp_rtrmgr... r5:~# So...again...nothing r5:~# xorp xorp_profiler xorp_rtrmgr xorpsh r5:~# xorp_rtrmgr [ 2008/06/16 11:41:14 INFO xorp_rtrmgr:467 RTRMGR +239 master_conf_tree.cc exec ute ] Changed modules: interfaces, fea, mfea4, rib, fib2mrib, igmp, pimsm4 [ 2008/06/16 11:41:14 INFO xorp_rtrmgr:467 RTRMGR +96 module_manager.cc execute ] Executing module: interfaces (fea/xorp_fea) [ 2008/06/16 11:41:16 INFO xorp_fea MFEA ] MFEA enabled [ 2008/06/16 11:41:16 INFO xorp_fea MFEA ] CLI enabled [ 2008/06/16 11:41:16 INFO xorp_fea MFEA ] CLI started [ 2008/06/16 11:41:16 INFO xorp_fea MFEA ] MFEA enabled [ 2008/06/16 11:41:16 INFO xorp_fea MFEA ] CLI enabled [ 2008/06/16 11:41:16 INFO xorp_fea MFEA ] CLI started [ 2008/06/16 11:41:17 WARNING xorp_fea XrlFeaTarget ] Handling method for ifmgr/ 0.1/commit_transaction failed: XrlCmdError 102 Command failed Failed executing: "ConfigureInterfaceFromSystem: eth1" [ 2008/06/16 11:41:17 ERROR xorp_rtrmgr:467 RTRMGR +675 master_conf_tree.cc com mit_pass2_done ] Commit failed: 102 Command failed Failed executing: "ConfigureI nterfaceFromSystem: eth1" [ 2008/06/16 11:41:17 ERROR xorp_rtrmgr:467 RTRMGR +251 master_conf_tree.cc con fig_done ] Configuration failed: 102 Command failed Failed executing: "Configure InterfaceFromSystem: eth1" [ 2008/06/16 11:41:17 INFO xorp_rtrmgr:467 RTRMGR +2228 task.cc run_task ] No m ore tasks to run [ 2008/06/16 11:41:17 INFO xorp_rtrmgr:467 RTRMGR +171 module_manager.cc termin ate ] Terminating module: interfaces [ 2008/06/16 11:41:17 INFO xorp_rtrmgr:467 RTRMGR +194 module_manager.cc termin ate ] Killing module: interfaces [ 2008/06/16 11:41:17 ERROR xorp_rtrmgr:467 RTRMGR +747 module_manager.cc done_ cb ] Command "/usr/lib/xorp/fea/xorp_fea": terminated with signal 15. [ 2008/06/16 11:41:17 INFO xorp_rtrmgr:467 RTRMGR +282 module_manager.cc module _exited ] Module killed during shutdown: interfaces r5:~# So this I find weird and I don't know how to interpret and solve. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080616/e67d9cdd/attachment.html From bms at incunabulum.net Mon Jun 16 10:15:51 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Mon, 16 Jun 2008 18:15:51 +0100 Subject: [Xorp-users] problem starting xorp In-Reply-To: <787017.5598.qm@web36308.mail.mud.yahoo.com> References: <787017.5598.qm@web36308.mail.mud.yahoo.com> Message-ID: <48569FC7.3050002@incunabulum.net> grumazescu costi wrote: > ... > So this I find weird and I don't know how to interpret and solve. > Sounds like the XORP FEA does not see your eth1 interface. Can you post your ifconfig -a output? From sirmikey1 at gmail.com Mon Jun 16 19:39:17 2008 From: sirmikey1 at gmail.com (Sir Mikey1) Date: Mon, 16 Jun 2008 21:39:17 -0500 Subject: [Xorp-users] confirm 2be68895459e46dec1a34879ba5f1ac5c4883465 In-Reply-To: References: Message-ID: <3277769b0806161939l261cdc37kc7446ac00eaf2786@mail.gmail.com> Sirs, Three questions/situations please: Your frequent questions page, what does this mean? Quote: "At the present time, XORP *does not* implement its own forwarding system. It is reliant on the forwarding of the underlying host operating system. We would like to support forwarding in custom hardware and software architectures in future. An example being the Clickmodular router." ??? Does xorp utilize one host computer to share Modem Nic with Office Nics and IP subnet range, like Microsoft Internet Connection Wizard???? I had hoped to be able to put xorp router software on all machines, with modem plugged into the uplink slot on the hub, where all computers would see the sitation and resolve. Wishful drinking, or is this even possible? Many Thanks, SirMikey1 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080616/6bbe3aff/attachment.html From bms at incunabulum.net Tue Jun 17 00:06:32 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Tue, 17 Jun 2008 08:06:32 +0100 Subject: [Xorp-users] confirm 2be68895459e46dec1a34879ba5f1ac5c4883465 In-Reply-To: <3277769b0806161939l261cdc37kc7446ac00eaf2786@mail.gmail.com> References: <3277769b0806161939l261cdc37kc7446ac00eaf2786@mail.gmail.com> Message-ID: <48576278.3010602@incunabulum.net> Sir Mikey1 wrote: > Does xorp utilize one host computer to share Modem Nic with Office > Nics and IP subnet range, like Microsoft Internet Connection Wizard???? > > I had hoped to be able to put xorp router software on all machines, > with modem plugged into the uplink slot on the hub, where all > computers would see the sitation and resolve. Wishful drinking, or is > this even possible? Currently XORP does not implement its own NAT or proxy suite, which are necessary components to implement what you're describing (a SoHo internet gateway on the end of a NATted ADSL line). Driver support for the modem will also be required. If you or someone else is interested in porting this to the XORP platform, we'd be very interested to hear from you. The XORP LiveCD currently builds on top of the FreeBSD operating system, so the forwarding plane in use is that of FreeBSD. cheers BMS From tapio.nolvi at gmail.com Tue Jun 17 06:12:40 2008 From: tapio.nolvi at gmail.com (Tapio Nolvi) Date: Tue, 17 Jun 2008 16:12:40 +0300 Subject: [Xorp-users] BGP local preference Message-ID: <177e274a0806170612wa28b8e4obcc3d9b0744cb243@mail.gmail.com> Hi all. I'm new to BGP and XORP and surprisingly I have run into troubles. I'm working on a testbed and currently I'm playing around with BGP attributes. I have tried but can't find a correct way of using local preferences. Could someone please assist me on this one? I have 4 xorp routers (some are virtualised machines) all fysically connected to each other and I have succesfully tested the effect of med value changes to the routing tables on a simple topology. I would now like to do the same with the localpref. If we use the following topology as an example, where R1-R3 are BGP routers, R4 is a "normal" machine and R2 and R3 are on the same AS. Where should I put the policy that sets localpref of the R2 and R3 routers when considering the route from R1 to R4 and vice versa? A simple example would be great. R1 / \ R2 R3 \ / R4 Thanks. Tapio Nolvi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080617/34888fe3/attachment.html From jjajal at gmail.com Wed Jun 18 05:56:53 2008 From: jjajal at gmail.com (Jigar) Date: Wed, 18 Jun 2008 18:26:53 +0530 Subject: [Xorp-users] trouble in multicast forwarding with XORP 1.4 Message-ID: <48590615.1080307@gmail.com> Query: -> we want to activate multicast forwarding on the XORP router -> we are now not able to send any UDP multicast data packet from (H1 to H2) or (H2 to H1) Doubt: -> we are in doubt about the static routing setting or may be in PIM protocol configuration -> we are not clear with the mrib setting in the configuration file -> Also in setting RP statically which should be selected ( H1, H2 or XORP itself )? -> is fib2mrib section required for multicast forwarding? Setup: -> H1 and H2 are connected through XORP 1.4 router( having 2 NIC card i.e. eth0 and eth1 ) on different NICs. -> They both are now able ping each other. so unicast forwording is working fine. -> IGMPv3 and PIM-SMv2 both protocol are currently running on both NIC(eth0 and eth1) of the XORP router -> fea and mfea are also activated for both NIC(eth0 and eth1) of the XORP router. -> IGMPv3 query and PIM Hello packets are coming nicely -> In PIM-SM bootstrap for RP is disable as we are going with the static RP setting. It is now set as a H1. Note: -> Here we have attached the configuration file of XORP which we are using now for our setup and also setup image CONFIG FILE: /* $XORP: xorp/rtrmgr/config.boot.sample,v 1.46 2007/03/12 10:16:05 atanu Exp $ */ interfaces { restore-original-config-on-shutdown: false interface eth0 { description: "data interface" disable: false default-system-config } interface eth1 { description: "data interface" disable: false default-system-config } } fea { targetname: "fea" unicast-forwarding4 { disable: false forwarding-entries { retain-on-startup: false retain-on-shutdown: false } } } protocols { static { targetname: "static_routes" disable: false mrib-route 224.0.0.0/8 { next-hop: 10.100.3.226 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" } } } } plumbing { mfea4 { disable: false interface eth0 { vif eth0 { disable: false } } interface eth1 { vif eth1 { disable: false } } interface register_vif { vif register_vif { /* Note: this vif should be always enabled */ disable: false } } traceoptions { flag all { disable: false } } } } protocols { igmp { targetname: "IGMP" disable: false interface eth0 { vif eth0 { disable: false version: 3 /* enable-ip-router-alert-option-check: false */ /* query-interval: 125 */ /* query-last-member-interval: 1 */ /* query-response-interval: 10 */ /* robust-count: 2 */ } } interface eth1 { vif eth1 { disable: false version: 3 /* 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 { targetname: "PIMSM_4" disable: false interface eth0 { vif eth0 { disable: false /* enable-ip-router-alert-option-check: false */ /* dr-priority: 1 */ hello-period: 10 /* hello-triggered-delay: 5 */ /* alternative-subnet 10.40.0.0/16 */ } } interface eth1 { vif eth1 { disable: false /* enable-ip-router-alert-option-check: false */ /* dr-priority: 1 */ hello-period: 10 /* 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.100.3.225 { group-prefix 224.0.0.0/4 { /* rp-priority: 192 */ /* hash-mask-len: 30 */ } } } bootstrap { disable: true cand-bsr { scope-zone 224.0.0.0/4 { /* is-scope-zone: false */ cand-bsr-by-vif-name: "eth0" /* cand-bsr-by-vif-addr: 10.10.10.10 */ /* 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: 10.10.10.10 */ /* 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 } } -------------- next part -------------- A non-text attachment was scrubbed... Name: configuration.jpg Type: image/jpeg Size: 46109 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080618/d71b9c3d/attachment-0001.jpg From ben at sparkcomputing.co.uk Wed Jun 18 17:34:15 2008 From: ben at sparkcomputing.co.uk (Dr Ben G Wu) Date: Thu, 19 Jun 2008 01:34:15 +0100 Subject: [Xorp-users] multicast routing not working Message-ID: Hello, I just found xorp 2 days ago and try to setup a multicast network. The source is at 192.168.1.0/24 subnet and the multicast subscribers are in 192.168.2.0/24 subnet. Centos 5 is running xorp with 2 physical interfaces connecting the 2 subnets. xorp is installed and xorp_rtrmgr running fine. The src is playing a stream on 244.0.0.1:1234 using vcl player. but the client could not connect to 244.0.0.1. the command " show mfea dataflow" returns nothing. My configuration file is as below. -------started----- interfaces { restore-original-config-on-shutdown: false interface eth2 { description: "vlan2" default-system-config } interface eth1 { description: "vlan11" default-system-config } } fea { unicast-forwarding4 { disable: false forwarding-entries { retain-on-startup: false retain-on-shutdown: false } } } plumbing { mfea4 { disable: false interface eth1 { vif eth1 { disable: false } } interface eth2 { vif eth2 { 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 eth2 { vif eth2 { disable: false } } interface eth1 { vif eth1 { disable: false } } traceoptions { flag all { disable: false } } } } protocols { pimsm4 { disable: false interface eth2 { vif eth2 { disable: false } } interface eth1 { vif eth1 { disable: false } } interface register_vif { vif register_vif { /* Note: this vif should be always enabled */ disable: false } } static-rps { rp 192.168.1.1 { group-prefix 224.0.0.0/4 { /*rp-priority: 192 hash-mask-len: 30*/ } } rp 192.168.2.1 { group-prefix 224.0.0.0/4 { rp-priority: 192 hash-mask-len: 30 } } } switch-to-spt-threshold { /* approx. 1K bytes/s (10Kbps) threshold */ disable: false interval: 100 bytes: 102400 } traceoptions { flag all { disable: false } } } } protocols { fib2mrib { disable: false } } policy { /* Describe connected routes for redistribution */ policy-statement connected { term export { from { protocol: "connected" } } } } policy { /* Describe static routes for redistribution */ policy-statement static { term export { from { protocol: "static" } } } } protocols { rip { /* Connected interfaces will only be advertised if explicitly exported */ export: "connected" /* Run on specified network interface addresses */ interface eth1 { vif eth1 { address 192.168.1.1 { disable: false /* authentication { simple-password: "password"; md5 @: u32 { password: "password"; start-time: "2006-01-01.12:00" end-time: "2007-01-01.12:00" } } */ } } } interface eth2 { vif eth2 { address 192.168.2.1 { disable: false } } } protocols { static { disable: false route 192.168.110.0/24 { next-hop: 192.168.110.1 metric: 1 } mrib-route 192.168.1.0/24 { next-hop: 192.168.1.1 metric: 1 } mrib-route 192.168.2.0/24 { next-hop: 192.168.2.1 metric: 1 } } } ----ended------- -- Dr. Ben G Wu, Ph.D, B. Eng, M.BCS 5 Dargate, Shrewsbury, Shropshire, SY3 9QE, UK T: +44(0)1743 290009 M: +44(0) 7980546757 F: +44(0)7092 861166 W: http://www.sparkcomputing.co.uk Website & Software development From bms at incunabulum.net Thu Jun 19 00:28:24 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Thu, 19 Jun 2008 08:28:24 +0100 Subject: [Xorp-users] multicast routing not working In-Reply-To: References: Message-ID: <485A0A98.1090101@incunabulum.net> Dr Ben G Wu wrote: > Hello, > I just found xorp 2 days ago and try to setup a multicast network. The > source is at 192.168.1.0/24 subnet and the multicast subscribers are > in 192.168.2.0/24 subnet. Centos 5 is running xorp with 2 physical > interfaces connecting the 2 subnets. > I believe CentOS is similar to Red Hat. Do you have multicast routing compiled into your kernel? It has to be specifically selected during "make menuconfig" or whatever tool your Linux distro uses. From ben at sparkcomputing.co.uk Thu Jun 19 04:27:06 2008 From: ben at sparkcomputing.co.uk (Dr Ben G Wu) Date: Thu, 19 Jun 2008 12:27:06 +0100 Subject: [Xorp-users] multicast routing not working -- Sorted Message-ID: Hello Bruce, Centos is mutlicast touting compiled by default. I now get it working. For those who is interested. I attach my config.boot as below. It is a very simple sample and I think get use it as a starter. ---------start----------- interfaces { restore-original-config-on-shutdown: false interface eth2 { description: "vlan2" default-system-config } interface eth1 { description: "vlan11" default-system-config } } fea { unicast-forwarding4 { disable: false forwarding-entries { retain-on-startup: false retain-on-shutdown: false } } } plumbing { mfea4 { disable: false interface eth1 { vif eth1 { disable: false } } interface eth2 { vif eth2 { 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 eth2 { vif eth2 { disable: false } } interface eth1 { vif eth1 { disable: false } } traceoptions { flag all { disable: false } } } } protocols { pimsm4 { disable: false interface eth2 { vif eth2 { disable: false } } interface eth1 { vif eth1 { disable: false } } interface register_vif { vif register_vif { /* Note: this vif should be always enabled */ disable: false } } static-rps { rp 192.168.1.1 { group-prefix 239.255.0.0/16 { /*rp-priority: 192 hash-mask-len: 30*/ } } } switch-to-spt-threshold { /* approx. 1K bytes/s (10Kbps) threshold */ disable: false interval: 100 bytes: 102400 } traceoptions { flag all { disable: false } } } } protocols { fib2mrib { disable: false } } policy { /* Describe connected routes for redistribution */ policy-statement connected { term export { from { protocol: "connected" } } } } policy { /* Describe static routes for redistribution */ policy-statement static { term export { from { protocol: "static" } } } } protocols { rip { /* Connected interfaces will only be advertised if explicitly exported */ export: "connected" /* Run on specified network interface addresses */ interface eth1 { vif eth1 { address 192.168.1.1 { disable: false /* authentication { simple-password: "password"; md5 @: u32 { password: "password"; start-time: "2006-01-01.12:00" end-time: "2007-01-01.12:00" } } */ } } } interface eth2 { vif eth2 { address 192.168.2.1 { disable: false } } } } } protocols { static { disable: false route 192.168.110.0/24 { next-hop: 192.168.110.1 metric: 1 } mrib-route 239.255.0.0/16 { next-hop: 192.168.2.1 metric: 1 } } } ---------------------end------------------ On Thu, Jun 19, 2008 at 8:28 AM, Bruce M Simpson wrote: > Dr Ben G Wu wrote: >> >> Hello, >> I just found xorp 2 days ago and try to setup a multicast network. The >> source is at 192.168.1.0/24 subnet and the multicast subscribers are >> in 192.168.2.0/24 subnet. Centos 5 is running xorp with 2 physical >> interfaces connecting the 2 subnets. >> > > I believe CentOS is similar to Red Hat. Do you have multicast routing > compiled into your kernel? It has to be specifically selected during "make > menuconfig" or whatever tool your Linux distro uses. > -- Dr. Ben G Wu, Ph.D, B. Eng, M.BCS 5 Dargate, Shrewsbury, Shropshire, SY3 9QE, UK T: +44(0)1743 290009 M: +44(0) 7980546757 F: +44(0)7092 861166 W: http://www.sparkcomputing.co.uk Website & Software development From james.dutton at gmail.com Thu Jun 19 08:07:03 2008 From: james.dutton at gmail.com (James Courtier-Dutton) Date: Thu, 19 Jun 2008 16:07:03 +0100 Subject: [Xorp-users] multicast routing not working In-Reply-To: References: Message-ID: 2008/6/19 Dr Ben G Wu : > Hello, > I just found xorp 2 days ago and try to setup a multicast network. The > source is at 192.168.1.0/24 subnet and the multicast subscribers are > in 192.168.2.0/24 subnet. Centos 5 is running xorp with 2 physical > interfaces connecting the 2 subnets. > > xorp is installed and xorp_rtrmgr running fine. The src is playing a > stream on 244.0.0.1:1234 using vcl player. but the client could not > connect to 244.0.0.1. the command " show mfea dataflow" returns > nothing. > > My configuration file is as below. > static-rps { > rp 192.168.1.1 { > group-prefix 224.0.0.0/4 { > /*rp-priority: 192 > hash-mask-len: 30*/ > } > } > rp 192.168.2.1 { > group-prefix 224.0.0.0/4 { > rp-priority: 192 > hash-mask-len: 30 > } > } > } > The problem was that you had two rp entries when you should have had just one. From jjajal at gmail.com Thu Jun 19 05:13:09 2008 From: jjajal at gmail.com (Jigar) Date: Thu, 19 Jun 2008 17:43:09 +0530 Subject: [Xorp-users] communication between IGMP and PIM Message-ID: <485A4D55.1060609@gmail.com> Please refer following setup....: -- I have a setup of XORP (version 1.4 ) with PIM and IGMP enabled on all PCs. Setup is as shown in figure (PIM_config.jpg) -- I am having H1 which is joined in multicast group 224.0.0.50. It is sending IGMP report for that group with correct interval. This group entry can also be seen on xorpsh through "show igmp group". It is connected to eth0 interface of R2, so group is added for that interface only. -- This means that IGMP is runing fine on my R2. But this group informations should be forwarded by PIM-SM. This is not happening in my setup scenario. PIM-SM router should send JOIN messages towards RP periodically for particular group. I have configured R1 as RP of 224.0.0.0/4 statically. -- I can see that R2 (on eth1) has recognized R1 as its RP in not_joined state. -- I have configured RP as itself in R1. *Is there any configuration missing?* Here I am providing XORP configuration file on *R1 and R2 *for your reference. config.boot file-------> ON R1 .................start................. interfaces { restore-original-config-on-shutdown: false interface eth0 { description: "data interface" disable: false default-system-config } } fea { targetname: "fea" unicast-forwarding4 { disable: false forwarding-entries { retain-on-startup: false retain-on-shutdown: false } } } protocols { static { targetname: "static_routes" disable: false /* mrib-route 224.0.0.0/8 { next-hop: 10.100.3.226 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" } } } } 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 } } } } protocols { igmp { targetname: "IGMP" disable: false interface eth0 { vif eth0 { disable: false version: 3 /* enable-ip-router-alert-option-check: false */ query-interval: 15 /* query-last-member-interval: 1 */ /* query-response-interval: 10 */ /* robust-count: 2 */ } } traceoptions { flag all { disable: false } } } } protocols { pimsm4 { targetname: "PIMSM_4" disable: false interface eth0 { vif eth0 { disable: false /* enable-ip-router-alert-option-check: false */ /* dr-priority: 1 */ hello-period: 10 /* 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.100.3.225 { group-prefix 224.0.0.0/4 { /* rp-priority: 192 */ /* hash-mask-len: 30 */ } } } switch-to-spt-threshold { /* approx. 1K bytes/s (10Kbps) threshold */ disable: false interval: 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 } } .................end................. config.boot file-------> ON R2 .................start................. /* $XORP: xorp/rtrmgr/config.boot.sample,v 1.46 2007/03/12 10:16:05 atanu Exp $ */ interfaces { restore-original-config-on-shutdown: false interface eth0 { description: "data interface" disable: false default-system-config } interface eth1 { description: "data interface" disable: false default-system-config } } fea { targetname: "fea" unicast-forwarding4 { disable: false forwarding-entries { retain-on-startup: false retain-on-shutdown: false } } } /* protocols { ip { interface eth0 { vif eth0 { address 192.168.1.10 { disable: false } } } interface eth1 { vif eth1 { address 10.100.3.226 { disable: false } } } } } */ protocols { static { targetname: "static_routes" disable: false /* mrib-route 224.0.0.0/4 { next-hop: 192.168.1.10 metric: 1 } mrib-route 10.100.3.0/8 { next-hop: 10.100.3.1 metric: 1 } */ } } policy { policy-statement connected { term export { from { protocol: "connected" } } } } policy { policy-statement static { term export { from { protocol: "static" } } } } plumbing { mfea4 { disable: false interface eth0 { vif eth0 { disable: false } } interface eth1 { vif eth1 { disable: false } } interface register_vif { vif register_vif { /* Note: this vif should be always enabled */ disable: false } } traceoptions { flag all { disable: false } } } } protocols { igmp { targetname: "IGMP" disable: false interface eth0 { vif eth0 { disable: false version: 3 /* enable-ip-router-alert-option-check: false */ query-interval: 15 /* query-last-member-interval: 1 */ /* query-response-interval: 10 */ /* robust-count: 2 */ } } interface eth1 { vif eth1 { disable: false version: 3 /* enable-ip-router-alert-option-check: false */ query-interval: 15 /* query-last-member-interval: 1 */ /* query-response-interval: 10 */ /* robust-count: 2 */ } } traceoptions { flag all { disable: false } } } } protocols { pimsm4 { targetname: "PIMSM_4" disable: false interface eth0 { vif eth0 { disable: false /* enable-ip-router-alert-option-check: false */ dr-priority: 200 hello-period: 10 /* hello-triggered-delay: 5 */ /* alternative-subnet 10.40.0.0/16 */ } } interface eth1 { vif eth1 { disable: false /* enable-ip-router-alert-option-check: false */ dr-priority: 200 hello-period: 10 /* 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.100.3.225 { group-prefix 224.0.0.0/4 { } } } 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: true } } .................end................. -------------- next part -------------- A non-text attachment was scrubbed... Name: PIM_config.jpg Type: image/jpeg Size: 51872 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080619/46a51181/attachment-0001.jpg From pavlin at ICSI.Berkeley.EDU Thu Jun 19 08:58:25 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Thu, 19 Jun 2008 08:58:25 -0700 Subject: [Xorp-users] communication between IGMP and PIM In-Reply-To: <485A4D55.1060609@gmail.com> References: <485A4D55.1060609@gmail.com> Message-ID: <200806191558.m5JFwP4E005669@fruitcake.ICSI.Berkeley.EDU> Jigar wrote: > Please refer following setup....: > > -- I have a setup of XORP (version 1.4 ) with PIM and IGMP enabled on all > PCs. Setup is as shown in figure (PIM_config.jpg) > -- I am having H1 which is joined in multicast group 224.0.0.50. It is sending > IGMP report for that group with correct interval. This group entry can also be > seen on xorpsh through "show igmp group". It is connected to eth0 interface of > R2, so group is added for that interface only. > -- This means that IGMP is runing fine on my R2. But this group informations > should be forwarded by PIM-SM. This is not happening in my setup > scenario. PIM-SM router should send JOIN messages towards RP periodically for > particular group. I have configured R1 as RP of 224.0.0.0/4 statically. > -- I can see that R2 (on eth1) has recognized R1 as its RP in not_joined state. > -- I have configured RP as itself in R1. > > *Is there any configuration missing?* Multicast group 224.0.0.50 belongs to the link-local multicast address space 224.0.0.0 - 224.0.0.255 which are never forwarded by multicast routers. You should use some other multicast address outside of that range. FYI, the mrib-route entries should specify unicast prefixes that are to be used for the multicast reverse path forwarding check (toward the sender or the RP). I.e., a mrib-route entry should not be used to specify a multicast group range. Pavlin > Here I am providing XORP configuration file on *R1 and R2 *for your reference. > config.boot file-------> ON R1 > .................start................. > > interfaces { > restore-original-config-on-shutdown: false > interface eth0 { > description: "data interface" > disable: false > default-system-config } > } > > fea { > targetname: "fea" > unicast-forwarding4 { > disable: false > forwarding-entries { > retain-on-startup: false > retain-on-shutdown: false > } > } } > > protocols { > static { > targetname: "static_routes" > disable: false > /* mrib-route 224.0.0.0/8 { > next-hop: 10.100.3.226 > 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" > } > } > } > } > > 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 > } > } > } > } > > protocols { > igmp { > targetname: "IGMP" > disable: false > interface eth0 { > vif eth0 { > disable: false > version: 3 > /* enable-ip-router-alert-option-check: false */ > query-interval: 15 > /* query-last-member-interval: 1 */ > /* query-response-interval: 10 */ > /* robust-count: 2 */ > } > } > traceoptions { > flag all { > disable: false > } > } > } > } > > protocols { > pimsm4 { > targetname: "PIMSM_4" > disable: false > interface eth0 { > vif eth0 { > disable: false > /* enable-ip-router-alert-option-check: false */ > /* dr-priority: 1 */ > hello-period: 10 > /* 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.100.3.225 { > group-prefix 224.0.0.0/4 { > /* rp-priority: 192 */ > /* hash-mask-len: 30 */ > } > } > } switch-to-spt-threshold { > /* approx. 1K bytes/s (10Kbps) threshold */ > disable: false > interval: 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 > } > } > > .................end................. > > > config.boot file-------> ON R2 > .................start................. > /* $XORP: xorp/rtrmgr/config.boot.sample,v 1.46 2007/03/12 10:16:05 atanu Exp > $ */ > > > interfaces { > restore-original-config-on-shutdown: false > interface eth0 { > description: "data interface" > disable: false > default-system-config > } > > interface eth1 { > description: "data interface" > disable: false > default-system-config > } > } > > fea { > targetname: "fea" > unicast-forwarding4 { > disable: false > forwarding-entries { > retain-on-startup: false > retain-on-shutdown: false > } > } } > /* > protocols { > ip { > interface eth0 { > vif eth0 { > address 192.168.1.10 { > disable: false > } > } > } > > interface eth1 { > vif eth1 { > address 10.100.3.226 { > disable: false > } > } > } > } > } > > */ > > > protocols { > static { > targetname: "static_routes" > disable: false > /* > mrib-route 224.0.0.0/4 { > next-hop: 192.168.1.10 > metric: 1 > } > > mrib-route 10.100.3.0/8 { > next-hop: 10.100.3.1 > metric: 1 > } > */ } > > } > > policy { > policy-statement connected { > term export { > from { > protocol: "connected" > } > } > } > } > > > policy { > policy-statement static { > term export { > from { > protocol: "static" > } > } > } > } > > > > > plumbing { > mfea4 { > disable: false > > interface eth0 { > vif eth0 { > disable: false > } > } > > interface eth1 { > vif eth1 { > disable: false > } > } > > interface register_vif { > vif register_vif { > /* Note: this vif should be always enabled */ > disable: false > } > } > > traceoptions { > flag all { > disable: false > } > } > } > } > > protocols { > igmp { > targetname: "IGMP" > disable: false > interface eth0 { > vif eth0 { > disable: false > version: 3 > /* enable-ip-router-alert-option-check: false */ > query-interval: 15 > /* query-last-member-interval: 1 */ > /* query-response-interval: 10 */ > /* robust-count: 2 */ > } > } > > interface eth1 { > vif eth1 { > disable: false > version: 3 > /* enable-ip-router-alert-option-check: false */ > query-interval: 15 > /* query-last-member-interval: 1 */ > /* query-response-interval: 10 */ > /* robust-count: 2 */ > } > } traceoptions { > flag all { > disable: false > } > } > } > } > > protocols { > pimsm4 { > targetname: "PIMSM_4" > disable: false > interface eth0 { > vif eth0 { > disable: false > /* enable-ip-router-alert-option-check: false */ > dr-priority: 200 > hello-period: 10 > /* hello-triggered-delay: 5 */ > /* alternative-subnet 10.40.0.0/16 */ > } > } > > interface eth1 { > vif eth1 { > disable: false > /* enable-ip-router-alert-option-check: false */ > dr-priority: 200 > hello-period: 10 > /* 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.100.3.225 { > group-prefix 224.0.0.0/4 { > } > } > } > > 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: true > } > } > .................end................. > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From ben at sparkcomputing.co.uk Thu Jun 19 09:55:30 2008 From: ben at sparkcomputing.co.uk (Dr Ben G Wu) Date: Thu, 19 Jun 2008 17:55:30 +0100 Subject: [Xorp-users] communication between IGMP and PIM In-Reply-To: <200806191558.m5JFwP4E005669@fruitcake.ICSI.Berkeley.EDU> References: <485A4D55.1060609@gmail.com> <200806191558.m5JFwP4E005669@fruitcake.ICSI.Berkeley.EDU> Message-ID: 1. I got the same problem. I just found out that i should not use 224.0.0.0/4. I used 239.255.0.0/16 and my simple multicast routing just starts working! my network is vlan1 ------ Rotuer ----- vlan2 2. i do not need mrib-route configured in my case. that's that mean the multicast source will not be known then? I run 'show igmp group' command i got these: Interface Group Source LastReported Timeout V State eth2 239.255.1.10 0.0.0.0 192.168.2.253 227 2 E The Source is 0.0.0.0. I will try to put mrib-route back to see if the source ip can be listed correctly cheers, Ben On Thu, Jun 19, 2008 at 4:58 PM, Pavlin Radoslavov wrote: > Jigar wrote: > >> Please refer following setup....: >> >> -- I have a setup of XORP (version 1.4 ) with PIM and IGMP enabled on all >> PCs. Setup is as shown in figure (PIM_config.jpg) >> -- I am having H1 which is joined in multicast group 224.0.0.50. It is sending >> IGMP report for that group with correct interval. This group entry can also be >> seen on xorpsh through "show igmp group". It is connected to eth0 interface of >> R2, so group is added for that interface only. >> -- This means that IGMP is runing fine on my R2. But this group informations >> should be forwarded by PIM-SM. This is not happening in my setup >> scenario. PIM-SM router should send JOIN messages towards RP periodically for >> particular group. I have configured R1 as RP of 224.0.0.0/4 statically. >> -- I can see that R2 (on eth1) has recognized R1 as its RP in not_joined state. >> -- I have configured RP as itself in R1. >> >> *Is there any configuration missing?* > > Multicast group 224.0.0.50 belongs to the link-local multicast > address space 224.0.0.0 - 224.0.0.255 which are never forwarded by > multicast routers. > You should use some other multicast address outside of that range. > > FYI, the mrib-route entries should specify unicast prefixes that are > to be used for the multicast reverse path forwarding check (toward > the sender or the RP). I.e., a mrib-route entry should not be used > to specify a multicast group range. > > Pavlin > > >> Here I am providing XORP configuration file on *R1 and R2 *for your reference. >> config.boot file-------> ON R1 >> .................start................. >> >> interfaces { >> restore-original-config-on-shutdown: false >> interface eth0 { >> description: "data interface" >> disable: false >> default-system-config } >> } >> >> fea { >> targetname: "fea" >> unicast-forwarding4 { >> disable: false >> forwarding-entries { >> retain-on-startup: false >> retain-on-shutdown: false >> } >> } } >> >> protocols { >> static { >> targetname: "static_routes" >> disable: false >> /* mrib-route 224.0.0.0/8 { >> next-hop: 10.100.3.226 >> 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" >> } >> } >> } >> } >> >> 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 >> } >> } >> } >> } >> >> protocols { >> igmp { >> targetname: "IGMP" >> disable: false >> interface eth0 { >> vif eth0 { >> disable: false >> version: 3 >> /* enable-ip-router-alert-option-check: false */ >> query-interval: 15 >> /* query-last-member-interval: 1 */ >> /* query-response-interval: 10 */ >> /* robust-count: 2 */ >> } >> } >> traceoptions { >> flag all { >> disable: false >> } >> } >> } >> } >> >> protocols { >> pimsm4 { >> targetname: "PIMSM_4" >> disable: false >> interface eth0 { >> vif eth0 { >> disable: false >> /* enable-ip-router-alert-option-check: false */ >> /* dr-priority: 1 */ >> hello-period: 10 >> /* 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.100.3.225 { >> group-prefix 224.0.0.0/4 { >> /* rp-priority: 192 */ >> /* hash-mask-len: 30 */ >> } >> } >> } switch-to-spt-threshold { >> /* approx. 1K bytes/s (10Kbps) threshold */ >> disable: false >> interval: 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 >> } >> } >> >> .................end................. >> >> >> config.boot file-------> ON R2 >> .................start................. >> /* $XORP: xorp/rtrmgr/config.boot.sample,v 1.46 2007/03/12 10:16:05 atanu Exp >> $ */ >> >> >> interfaces { >> restore-original-config-on-shutdown: false >> interface eth0 { >> description: "data interface" >> disable: false >> default-system-config >> } >> >> interface eth1 { >> description: "data interface" >> disable: false >> default-system-config >> } >> } >> >> fea { >> targetname: "fea" >> unicast-forwarding4 { >> disable: false >> forwarding-entries { >> retain-on-startup: false >> retain-on-shutdown: false >> } >> } } >> /* >> protocols { >> ip { >> interface eth0 { >> vif eth0 { >> address 192.168.1.10 { >> disable: false >> } >> } >> } >> >> interface eth1 { >> vif eth1 { >> address 10.100.3.226 { >> disable: false >> } >> } >> } >> } >> } >> >> */ >> >> >> protocols { >> static { >> targetname: "static_routes" >> disable: false >> /* >> mrib-route 224.0.0.0/4 { >> next-hop: 192.168.1.10 >> metric: 1 >> } >> >> mrib-route 10.100.3.0/8 { >> next-hop: 10.100.3.1 >> metric: 1 >> } >> */ } >> >> } >> >> policy { >> policy-statement connected { >> term export { >> from { >> protocol: "connected" >> } >> } >> } >> } >> >> >> policy { >> policy-statement static { >> term export { >> from { >> protocol: "static" >> } >> } >> } >> } >> >> >> >> >> plumbing { >> mfea4 { >> disable: false >> >> interface eth0 { >> vif eth0 { >> disable: false >> } >> } >> >> interface eth1 { >> vif eth1 { >> disable: false >> } >> } >> >> interface register_vif { >> vif register_vif { >> /* Note: this vif should be always enabled */ >> disable: false >> } >> } >> >> traceoptions { >> flag all { >> disable: false >> } >> } >> } >> } >> >> protocols { >> igmp { >> targetname: "IGMP" >> disable: false >> interface eth0 { >> vif eth0 { >> disable: false >> version: 3 >> /* enable-ip-router-alert-option-check: false */ >> query-interval: 15 >> /* query-last-member-interval: 1 */ >> /* query-response-interval: 10 */ >> /* robust-count: 2 */ >> } >> } >> >> interface eth1 { >> vif eth1 { >> disable: false >> version: 3 >> /* enable-ip-router-alert-option-check: false */ >> query-interval: 15 >> /* query-last-member-interval: 1 */ >> /* query-response-interval: 10 */ >> /* robust-count: 2 */ >> } >> } traceoptions { >> flag all { >> disable: false >> } >> } >> } >> } >> >> protocols { >> pimsm4 { >> targetname: "PIMSM_4" >> disable: false >> interface eth0 { >> vif eth0 { >> disable: false >> /* enable-ip-router-alert-option-check: false */ >> dr-priority: 200 >> hello-period: 10 >> /* hello-triggered-delay: 5 */ >> /* alternative-subnet 10.40.0.0/16 */ >> } >> } >> >> interface eth1 { >> vif eth1 { >> disable: false >> /* enable-ip-router-alert-option-check: false */ >> dr-priority: 200 >> hello-period: 10 >> /* 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.100.3.225 { >> group-prefix 224.0.0.0/4 { >> } >> } >> } >> >> 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: true >> } >> } >> .................end................. >> _______________________________________________ >> 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 > -- Dr. Ben G Wu, Ph.D, B. Eng, M.BCS 5 Dargate, Shrewsbury, Shropshire, SY3 9QE, UK T: +44(0)1743 290009 M: +44(0) 7980546757 F: +44(0)7092 861166 W: http://www.sparkcomputing.co.uk Website & Software development From pavlin at ICSI.Berkeley.EDU Thu Jun 19 11:11:27 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Thu, 19 Jun 2008 11:11:27 -0700 Subject: [Xorp-users] communication between IGMP and PIM In-Reply-To: References: <485A4D55.1060609@gmail.com> <200806191558.m5JFwP4E005669@fruitcake.ICSI.Berkeley.EDU> Message-ID: <200806191811.m5JIBRrB005081@fruitcake.ICSI.Berkeley.EDU> Dr Ben G Wu wrote: > 1. I got the same problem. I just found out that i should not use > 224.0.0.0/4. I used 239.255.0.0/16 and my simple multicast routing > just starts working! > > my network is vlan1 ------ Rotuer ----- vlan2 > > 2. i do not need mrib-route configured in my case. that's that mean > the multicast source will not be known then? I run 'show igmp group' > command i got these: > Interface Group Source LastReported Timeout V State > eth2 239.255.1.10 0.0.0.0 192.168.2.253 227 2 E > > The Source is 0.0.0.0. I will try to put mrib-route back to see if the > source ip can be listed correctly If you don't use mrib-route, then the multicast RPF will use exactly same information as unicast routing. The mrib-route statements are needed if, say, your multicast traffic should use different path from unicast. Source 0.0.0.0 in the above output is normal. It means that the multicast join state is (*, 239.255.1.10), i.e., any-source multicast for that group. Only if you use source-specific multicast (in IGMPv3) the Source field will be set to something else. Pavlin From greearb at candelatech.com Sun Jun 22 22:55:31 2008 From: greearb at candelatech.com (Ben Greear) Date: Sun, 22 Jun 2008 22:55:31 -0700 Subject: [Xorp-users] Questions on multicast routing. Message-ID: <485F3AD3.90405@candelatech.com> As you might recall, I am working on adding linux kernel and xorp support for multiple multicast routing tables. I currently have a patch to the kernel that lets me send mcast through one virtual router to another host on another leg of the router. However, I am not able to get one router to forward to another, and I'm not too sure how to go about debugging this because I'm unsure of how it's all supposed to work together... I am attaching a diagram of my (virtual) network. I have an mcast generator on rddR2 and consumers on rddVR6 and rddVR7. The multicast address is 224.1.2.3. I have one instance of xorp running for each virtual router. It *appears* that the kernel vif tables are set up correctly. Here is router-0: root at lanforge-65-AF> show igmp group Interface Group Source LastReported Timeout V State rddVR0 224.0.0.2 0.0.0.0 1.1.6.2 170 2 E rddVR0 224.0.0.5 0.0.0.0 1.1.6.1 172 2 E rddVR0 224.0.0.6 0.0.0.0 1.1.6.1 175 2 E rddVR0 224.0.0.13 0.0.0.0 1.1.6.2 171 2 E rddVR0 224.0.0.22 0.0.0.0 1.1.6.1 170 2 E rddVR3 224.0.0.2 0.0.0.0 5.4.3.2 175 2 E rddVR3 224.0.0.5 0.0.0.0 5.4.3.2 170 2 E rddVR3 224.0.0.6 0.0.0.0 5.4.3.2 171 2 E rddVR3 224.0.0.13 0.0.0.0 5.4.3.2 171 2 E rddVR3 224.0.0.22 0.0.0.0 5.4.3.2 169 2 E rddVR4 224.0.0.2 0.0.0.0 2.3.4.1 171 2 E rddVR4 224.0.0.5 0.0.0.0 2.3.4.1 174 2 E rddVR4 224.0.0.6 0.0.0.0 2.3.4.1 169 2 E rddVR4 224.0.0.13 0.0.0.0 2.3.4.1 176 2 E rddVR4 224.0.0.22 0.0.0.0 2.3.4.1 174 2 E rddVR4 224.1.2.3 0.0.0.0 2.3.4.2 169 2 E root at lanforge-65-AF> show pim neighbors Interface DRpriority NeighborAddr V Mode Holdtime Timeout rddVR0 125 1.1.6.2 2 Sparse 105 95 root at lanforge-65-AF> I was expecting to see 224.1.2.3 on rddVR0 since it connects to the other router. Here is router-1: root at lanforge-65-AF> show igmp group Interface Group Source LastReported Timeout V State rddVR1 224.0.0.2 0.0.0.0 1.1.6.1 238 2 E rddVR1 224.0.0.5 0.0.0.0 1.1.6.1 239 2 E rddVR1 224.0.0.6 0.0.0.0 1.1.6.1 237 2 E rddVR1 224.0.0.13 0.0.0.0 1.1.6.2 239 2 E rddVR1 224.0.0.22 0.0.0.0 1.1.6.2 237 2 E rddVR7 224.0.0.2 0.0.0.0 1.1.7.1 242 2 E rddVR7 224.0.0.5 0.0.0.0 1.1.7.1 248 2 E rddVR7 224.0.0.6 0.0.0.0 1.1.7.1 247 2 E rddVR7 224.0.0.13 0.0.0.0 1.1.7.1 246 2 E rddVR7 224.0.0.22 0.0.0.0 1.1.7.1 240 2 E rddVR7 224.1.2.3 0.0.0.0 1.1.7.2 243 2 E root at lanforge-65-AF> show pim neighbors Interface DRpriority NeighborAddr V Mode Holdtime Timeout rddVR1 125 1.1.6.1 2 Sparse 105 99 Please let me know if I can provide any additional info to help clarify the issue. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -------------- next part -------------- A non-text attachment was scrubbed... Name: mcast_routers.png Type: image/png Size: 5595 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080622/df84cba7/attachment.bin From yueli.m at gmail.com Mon Jun 23 14:13:48 2008 From: yueli.m at gmail.com (Yue Li) Date: Mon, 23 Jun 2008 17:13:48 -0400 Subject: [Xorp-users] BGP down with "Internal fatal error: unreachable code reached" Message-ID: <49567c360806231413g41c06e79o253ba1f06c5a7625@mail.gmail.com> Hi All, BGP crashes down under some particular scenarios, with following output: [ 2008/06/05 13:31:34 FATAL xorp_bgp:10028 BGP +83 route_table_cache.cc add_route ] Internal fatal error: unreachable code reached [ 2008/06/05 13:31:34 ERROR xorp_rtrmgr:10024 RTRMGR +747 module_manager.cc done_cb ] Command "/usr/local/xorp/bgp/xorp_bgp": terminated with signal 6. [ 2008/06/05 13:31:34 INFO xorp_rib RIB ] Received death event for protocol bgp shutting down ------- I found an earlier post which talks about the same problem: http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2007-December/002284.html Thanks! From agaviola at infoweapons.com Mon Jun 23 21:01:47 2008 From: agaviola at infoweapons.com (Archimedes S. Gaviola) Date: Tue, 24 Jun 2008 12:01:47 +0800 Subject: [Xorp-users] ASM Configuration Options with XORP Message-ID: <486071AB.40906@infoweapons.com> To Whom It May Concerned: Hello and good day! I have 2 multicast routers running XORP 1.4 and I want to configure it with ASM. I have tried SSM which is more straightforward to configure because only few configurations options were being set in the configuration file (config.boot). In the manual, I could see the options like static-rps bootstrap (with sub options of candidate BSR and candidate RP) In my scenario were there are 2 ASM multicast routers, I am going to have the same RP address in the static-rps option? When I am going to use bootstrap option? Is it used to configure both the multicast routers? What about candidate BSR and candidate RP, when to use them? My goal is to setup a very simple ASM network with a streaming server on one side of the network behind a multicast router and streaming clients on the other side with another multicast router. Thanks, Archimedes From bms at incunabulum.net Tue Jun 24 05:41:49 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Tue, 24 Jun 2008 13:41:49 +0100 Subject: [Xorp-users] BGP down with "Internal fatal error: unreachable code reached" In-Reply-To: <49567c360806231413g41c06e79o253ba1f06c5a7625@mail.gmail.com> References: <49567c360806231413g41c06e79o253ba1f06c5a7625@mail.gmail.com> Message-ID: <4860EB8D.2050108@incunabulum.net> Yue Li wrote: > [ 2008/06/05 13:31:34 FATAL xorp_bgp:10028 BGP +83 route_table_cache.cc > add_route ] Internal fatal error: unreachable code reached > Hi, Is it possible for you to make a core dump available to us? It is OK if this done privately. Please contact me off list with details. thanks BMS From greearb at candelatech.com Tue Jun 24 08:53:18 2008 From: greearb at candelatech.com (Ben Greear) Date: Tue, 24 Jun 2008 08:53:18 -0700 Subject: [Xorp-users] How to choose a good cand-rp-by-vif-name ? In-Reply-To: <200805221631.m4MGVetP017517@fruitcake.ICSI.Berkeley.EDU> References: <48349905.1060509@candelatech.com> <200805221631.m4MGVetP017517@fruitcake.ICSI.Berkeley.EDU> Message-ID: <4861186E.5050303@candelatech.com> Pavlin Radoslavov wrote: > Ben Greear wrote: > > >> I'm working on configuring Xorp with multicast support. >> >> The bootstrap configuration wants a candidate VIF. >> >> Supposing there are lots of interfaces, how does one decide which one to use for >> the cand-rp-by-vif-name? >> > > The primary IP address of the chosen vif must be reachable > (routable) by all other PIM-SM routers in your network. > > Regards, > Pavlin > I don't think my 'cand-rp' is working properly. Should I see any sort of broadcasts/multicasts on the interface chosen for cand-rp? How about other interfaces in the router? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at ICSI.Berkeley.EDU Tue Jun 24 09:01:23 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Tue, 24 Jun 2008 09:01:23 -0700 Subject: [Xorp-users] How to choose a good cand-rp-by-vif-name ? In-Reply-To: <4861186E.5050303@candelatech.com> References: <48349905.1060509@candelatech.com> <200805221631.m4MGVetP017517@fruitcake.ICSI.Berkeley.EDU> <4861186E.5050303@candelatech.com> Message-ID: <200806241601.m5OG1N8I003084@fruitcake.ICSI.Berkeley.EDU> Ben Greear wrote: > Pavlin Radoslavov wrote: > > Ben Greear wrote: > > > > > >> I'm working on configuring Xorp with multicast support. > >> > >> The bootstrap configuration wants a candidate VIF. > >> > >> Supposing there are lots of interfaces, how does one decide which one to use for > >> the cand-rp-by-vif-name? > >> > > > > The primary IP address of the chosen vif must be reachable > > (routable) by all other PIM-SM routers in your network. > > > > Regards, > > Pavlin > > > I don't think my 'cand-rp' is working properly. Should I see any sort of > broadcasts/multicasts on > the interface chosen for cand-rp? How about other interfaces in the router? If the Bootstrap Router (BSR) election has completed, you should see periodic unicast PIM Cand-RP messages from this router to the BSR. Those messages should come on the interface used to route unicast traffic toward the BSR. The Cand-RP address inside the message should be the primary address of the interface selected by the cand-rp-by-vif-name statement. On startup it might take up to 1-2 minutes to complete the BSR election, so in the mean time you won't see any Cand-RP messages. If the local Cand-RP router is also the elected BSR, then the Cand-RP messages are not transmitted on the wire, because that state is propagated internally. Hope that helps, Pavlin From pavlin at ICSI.Berkeley.EDU Tue Jun 24 09:16:30 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Tue, 24 Jun 2008 09:16:30 -0700 Subject: [Xorp-users] Questions on multicast routing. In-Reply-To: <485F3AD3.90405@candelatech.com> References: <485F3AD3.90405@candelatech.com> Message-ID: <200806241616.m5OGGUDF004808@fruitcake.ICSI.Berkeley.EDU> Ben Greear wrote: > As you might recall, I am working on adding linux kernel and xorp support for > multiple multicast routing tables. > > I currently have a patch to the kernel that lets me send mcast through one > virtual > router to another host on another leg of the router. > > However, I am not able to get one router to forward to another, and I'm not > too sure > how to go about debugging this because I'm unsure of how it's all supposed to > work > together... > > I am attaching a diagram of my (virtual) network. I have an mcast generator > on rddR2 and > consumers on rddVR6 and rddVR7. The multicast address is 224.1.2.3. ~~~~~~~ I presume you mean rddVR5. > I have one instance of xorp running for each virtual router. It *appears* > that the kernel > vif tables are set up correctly. > > Here is router-0: > root at lanforge-65-AF> show igmp group > Interface Group Source LastReported Timeout V State > rddVR0 224.0.0.2 0.0.0.0 1.1.6.2 170 2 E > rddVR0 224.0.0.5 0.0.0.0 1.1.6.1 172 2 E > rddVR0 224.0.0.6 0.0.0.0 1.1.6.1 175 2 E > rddVR0 224.0.0.13 0.0.0.0 1.1.6.2 171 2 E > rddVR0 224.0.0.22 0.0.0.0 1.1.6.1 170 2 E > rddVR3 224.0.0.2 0.0.0.0 5.4.3.2 175 2 E > rddVR3 224.0.0.5 0.0.0.0 5.4.3.2 170 2 E > rddVR3 224.0.0.6 0.0.0.0 5.4.3.2 171 2 E > rddVR3 224.0.0.13 0.0.0.0 5.4.3.2 171 2 E > rddVR3 224.0.0.22 0.0.0.0 5.4.3.2 169 2 E > rddVR4 224.0.0.2 0.0.0.0 2.3.4.1 171 2 E > rddVR4 224.0.0.5 0.0.0.0 2.3.4.1 174 2 E > rddVR4 224.0.0.6 0.0.0.0 2.3.4.1 169 2 E > rddVR4 224.0.0.13 0.0.0.0 2.3.4.1 176 2 E > rddVR4 224.0.0.22 0.0.0.0 2.3.4.1 174 2 E > rddVR4 224.1.2.3 0.0.0.0 2.3.4.2 169 2 E Looks good. > root at lanforge-65-AF> show pim neighbors > Interface DRpriority NeighborAddr V Mode Holdtime Timeout > rddVR0 125 1.1.6.2 2 Sparse 105 95 > root at lanforge-65-AF> Looks good. > I was expecting to see 224.1.2.3 on rddVR0 since it connects to the > other router. No, it shouldn't. The IGMP membership information has only LAN-scope and appears only on the LAN with the receiver(*). A multicast routing protocol like PIM-SM is then used to propagate the IGMP membership information across subnets. (*) Note: The above is not true if IGMP proxy is used, but this is not the case in your setup. > Here is router-1: > > root at lanforge-65-AF> show igmp group > Interface Group Source LastReported Timeout V State > rddVR1 224.0.0.2 0.0.0.0 1.1.6.1 238 2 E > rddVR1 224.0.0.5 0.0.0.0 1.1.6.1 239 2 E > rddVR1 224.0.0.6 0.0.0.0 1.1.6.1 237 2 E > rddVR1 224.0.0.13 0.0.0.0 1.1.6.2 239 2 E > rddVR1 224.0.0.22 0.0.0.0 1.1.6.2 237 2 E > rddVR7 224.0.0.2 0.0.0.0 1.1.7.1 242 2 E > rddVR7 224.0.0.5 0.0.0.0 1.1.7.1 248 2 E > rddVR7 224.0.0.6 0.0.0.0 1.1.7.1 247 2 E > rddVR7 224.0.0.13 0.0.0.0 1.1.7.1 246 2 E > rddVR7 224.0.0.22 0.0.0.0 1.1.7.1 240 2 E > rddVR7 224.1.2.3 0.0.0.0 1.1.7.2 243 2 E > root at lanforge-65-AF> show pim neighbors > Interface DRpriority NeighborAddr V Mode Holdtime Timeout > rddVR1 125 1.1.6.1 2 Sparse 105 99 Looks good. > Please let me know if I can provide any additional info to help clarify the > issue. The IGMP information seems fine. After that use "show pim rps" to check that all PIM-SM routers have same Cand-RP set. The next thing to check is whether the PIM Join information is correct. The "show pim join" xorpsh command should tell you a number of things: the entries in the multicast routing table, the RP for each entry (where applicable), the RPF information, the incoming and outgoing interfaces and their state, etc. If the PIM Join information is correct, start transmission, but make sure the multicast TTL is large enough to reach the receivers. Also, make sure there are no firewall rules that might affect multicast. After the sender is started, use "show pim mfc" to see the multicast forwarding state (as installed by PIM-SM). If you got that far and is still not working, please send another email with the output from the above commands. Pavlin From greearb at candelatech.com Tue Jun 24 10:15:37 2008 From: greearb at candelatech.com (Ben Greear) Date: Tue, 24 Jun 2008 10:15:37 -0700 Subject: [Xorp-users] Questions on multicast routing. In-Reply-To: <200806241616.m5OGGUDF004808@fruitcake.ICSI.Berkeley.EDU> References: <485F3AD3.90405@candelatech.com> <200806241616.m5OGGUDF004808@fruitcake.ICSI.Berkeley.EDU> Message-ID: <48612BB9.8020009@candelatech.com> Pavlin Radoslavov wrote: > Ben Greear wrote: > >> As you might recall, I am working on adding linux kernel and xorp support for >> multiple multicast routing tables. >> >> I currently have a patch to the kernel that lets me send mcast through one >> virtual >> router to another host on another leg of the router. >> >> However, I am not able to get one router to forward to another, and I'm not >> too sure >> how to go about debugging this because I'm unsure of how it's all supposed to >> work >> together... >> >> I am attaching a diagram of my (virtual) network. I have an mcast generator >> on rddR2 and >> consumers on rddVR6 and rddVR7. The multicast address is 224.1.2.3. > ~~~~~~~ > > I presume you mean rddVR5. Yes. > The IGMP information seems fine. > After that use "show pim rps" to check that all PIM-SM routers have > same Cand-RP set. This is on a different machine, but logically it is the same setup, though the interface names are a bit different. I think that it's not doing the BSR stuff correctly. That cli output is at the bottom of the email. I tried sniffing the link between the two routers, but I don't see anything that is obviously BSR stuff. Any idea what those packets look like in wireshark? Router-0: root at lanforge-D0-20> show pim rps RP Type Pri Holdtime Timeout ActiveGroups GroupPrefix root at lanforge-D0-20> Router-1: root at lanforge-D0-20> show pim rps RP Type Pri Holdtime Timeout ActiveGroups GroupPrefix root at lanforge-D0-20> Router-0: root at lanforge-D0-20> show pim join created new heap in find_heap, ptr: 0x8103d00 created new heap in find_heap, ptr: 0x81055c8 Group Source RP Flags 224.2.3.4 0.0.0.0 RP_ADDR_UNKNOWN WC Upstream interface (RP): UNKNOWN Upstream MRIB next hop (RP): UNKNOWN Upstream RPF'(*,G): UNKNOWN Upstream state: Joined Join timer: 42 Local receiver include WC: ..O.. Joins RP: ..... Joins WC: ..... Join state: ..... Prune state: ..... Prune pending state: ..... I am assert winner state: ..... I am assert loser state: ..... Assert winner WC: ..... Assert lost WC: ..... Assert tracking WC: ..O.. Could assert WC: ..O.. I am DR: .OO.O Immediate olist RP: ..... Immediate olist WC: ..O.. Inherited olist SG: ..O.. Inherited olist SG_RPT: ..O.. PIM include WC: ..O.. 224.2.3.4 2.3.4.137 RP_ADDR_UNKNOWN SG SPT DirectlyConnectedS Upstream interface (S): rddVR1 Upstream interface (RP): UNKNOWN Upstream MRIB next hop (RP): UNKNOWN Upstream MRIB next hop (S): UNKNOWN Upstream RPF'(S,G): UNKNOWN Upstream state: Joined Register state: RegisterJoin RegisterCouldRegister Join timer: 42 KAT(S,G) running: true Local receiver include WC: ..O.. Local receiver include SG: ..... Local receiver exclude SG: ..... Joins RP: ..... Joins WC: ..... Joins SG: ....O Join state: ....O Prune state: ..... Prune pending state: ..... I am assert winner state: ..... I am assert loser state: ..... Assert winner WC: ..... Assert winner SG: ..... Assert lost WC: ..... Assert lost SG: ..... Assert lost SG_RPT: ..... Assert tracking SG: .OO.O Could assert WC: ..O.. Could assert SG: ..O.O I am DR: .OO.O Immediate olist RP: ..... Immediate olist WC: ..O.. Immediate olist SG: ....O Inherited olist SG: ..O.O Inherited olist SG_RPT: ..O.. PIM include WC: ..O.. PIM include SG: ..... PIM exclude SG: ..... root at lanforge-D0-20> Router-1: root at lanforge-D0-20> show pim join created new heap in find_heap, ptr: 0x8103d00 created new heap in find_heap, ptr: 0x81055c8 Group Source RP Flags 224.2.3.4 0.0.0.0 RP_ADDR_UNKNOWN WC Upstream interface (RP): UNKNOWN Upstream MRIB next hop (RP): UNKNOWN Upstream RPF'(*,G): UNKNOWN Upstream state: Joined Join timer: 7 Local receiver include WC: ..O. Joins RP: .... Joins WC: .... Join state: .... Prune state: .... Prune pending state: .... I am assert winner state: .... I am assert loser state: .... Assert winner WC: .... Assert lost WC: .... Assert tracking WC: ..O. Could assert WC: ..O. I am DR: .OOO Immediate olist RP: .... Immediate olist WC: ..O. Inherited olist SG: ..O. Inherited olist SG_RPT: ..O. PIM include WC: ..O. root at lanforge-D0-20> Router-0: root at lanforge-D0-20> show pim mfc Group Source RP 224.2.3.4 2.3.4.137 0.0.0.0 Incoming interface : rddVR1 Outgoing interfaces: ..O.O Router-1: root at lanforge-D0-20> show pim mfc Group Source RP Router-1: root at lanforge-D0-20> show pim bootstrap created new heap in find_heap, ptr: 0x8103d10 created new heap in find_heap, ptr: 0x81055d8 Active zones: BSR Pri LocalAddress Pri State Timeout SZTimeout Expiring zones: BSR Pri LocalAddress Pri State Timeout SZTimeout Configured zones: BSR Pri LocalAddress Pri State Timeout SZTimeout 0.0.0.0 0 0.0.0.0 0 Init -1 -1 root at lanforge-D0-20> Router-0: root at lanforge-D0-20> show pim bootstrap created new heap in find_heap, ptr: 0x8103d10 created new heap in find_heap, ptr: 0x81055d8 Active zones: BSR Pri LocalAddress Pri State Timeout SZTimeout Expiring zones: BSR Pri LocalAddress Pri State Timeout SZTimeout Configured zones: BSR Pri LocalAddress Pri State Timeout SZTimeout 0.0.0.0 0 0.0.0.0 0 Init -1 -1 -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at ICSI.Berkeley.EDU Tue Jun 24 10:18:32 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Tue, 24 Jun 2008 10:18:32 -0700 Subject: [Xorp-users] ASM Configuration Options with XORP In-Reply-To: <486071AB.40906@infoweapons.com> References: <486071AB.40906@infoweapons.com> Message-ID: <200806241718.m5OHIWxA014115@fruitcake.ICSI.Berkeley.EDU> Archimedes S. Gaviola wrote: > To Whom It May Concerned: > > Hello and good day! I have 2 multicast routers running XORP 1.4 and I > want to configure it with ASM. I have tried SSM which is more > straightforward to configure because only few configurations options > were being set in the configuration file (config.boot). In the manual, I > could see the options like > > static-rps > bootstrap (with sub options of candidate BSR and candidate RP) > > In my scenario were there are 2 ASM multicast routers, I am going to > have the same RP address in the static-rps option? When I am going to Yes, if you decide that you are going to use static RPs in your network, then all PIM-SM routers must have exactly same set of static RPs configuration. > use bootstrap option? Is it used to configure both the multicast > routers? What about candidate BSR and candidate RP, when to use them? My > goal is to setup a very simple ASM network with a streaming server on > one side of the network behind a multicast router and streaming clients > on the other side with another multicast router. If you have a very small number of PIM-SM routers, then static RPs is a simpler mechanism: simpler to understand, configure and debug. The downside is that it is static and error-prone. If you decide to change the Cand-RP set then you need to reconfigure all of your routers. The reconfiguration should happen while there is no multicast streaming otherwise you might create a multicast loop and bring the whole network down. Another downside is that if you have redundant links and the current RP (as defined in the static config) is disconnected, the rest of the network won't be able to use multicast. The Bootstrap mechanism is dynamic and doesn't have the disadvantages listed above. However, it is more complex to understand and is more difficult to debug. It looks like you have a very simple topology: just two multicast routers with a single link between them. In that case I think a single static RP should be fine. For efficiency (to avoid the PIM Register encapsulation) you might want to select the RP to be the router that is directly connected to the sender. Just don't forget to have same state-rps statement in both routers :) Pavlin > Thanks, > Archimedes > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at ICSI.Berkeley.EDU Tue Jun 24 10:42:49 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Tue, 24 Jun 2008 10:42:49 -0700 Subject: [Xorp-users] Questions on multicast routing. In-Reply-To: <48612BB9.8020009@candelatech.com> References: <485F3AD3.90405@candelatech.com> <200806241616.m5OGGUDF004808@fruitcake.ICSI.Berkeley.EDU> <48612BB9.8020009@candelatech.com> Message-ID: <200806241742.m5OHgnuC018340@fruitcake.ICSI.Berkeley.EDU> > > After that use "show pim rps" to check that all PIM-SM routers have > > same Cand-RP set. > > This is on a different machine, but logically it is the same setup, > though the interface names are a bit different. I think that it's not > doing the BSR stuff correctly. That cli output is at the bottom > of the email. I tried sniffing the link between the two routers, but > I don't see anything that is obviously BSR stuff. Any idea what those > packets look like in wireshark? > > Router-0: > root at lanforge-D0-20> show pim rps > RP Type Pri Holdtime Timeout ActiveGroups GroupPrefix > root at lanforge-D0-20> > > Router-1: > root at lanforge-D0-20> show pim rps > RP Type Pri Holdtime Timeout ActiveGroups GroupPrefix > root at lanforge-D0-20> Empty Cand-RP set is the reason you don't have multicast routing working. Debugging the BSR mechanism can be time consuming and for your purpose I don't think it is important. You might want to use a static RP which is much easier to configure and understand. Anyway, if you really want to debug the BSR issue, use commands like "show pim bootstrap" and "show pim bootstrap rps". After the Bootstrap router is elected, all Cand RPs will start unicasting Cand-RP-Adv messages to it. The PIM Bootstrap message is multicast periodically (group 224.0.0.13) and propagated hop-by-hop. Pavlin > Router-0: > root at lanforge-D0-20> show pim join > created new heap in find_heap, ptr: 0x8103d00 > created new heap in find_heap, ptr: 0x81055c8 > Group Source RP Flags > 224.2.3.4 0.0.0.0 RP_ADDR_UNKNOWN WC > Upstream interface (RP): UNKNOWN > Upstream MRIB next hop (RP): UNKNOWN > Upstream RPF'(*,G): UNKNOWN > Upstream state: Joined > Join timer: 42 > Local receiver include WC: ..O.. > Joins RP: ..... > Joins WC: ..... > Join state: ..... > Prune state: ..... > Prune pending state: ..... > I am assert winner state: ..... > I am assert loser state: ..... > Assert winner WC: ..... > Assert lost WC: ..... > Assert tracking WC: ..O.. > Could assert WC: ..O.. > I am DR: .OO.O > Immediate olist RP: ..... > Immediate olist WC: ..O.. > Inherited olist SG: ..O.. > Inherited olist SG_RPT: ..O.. > PIM include WC: ..O.. > 224.2.3.4 2.3.4.137 RP_ADDR_UNKNOWN SG SPT DirectlyConnectedS > Upstream interface (S): rddVR1 > Upstream interface (RP): UNKNOWN > Upstream MRIB next hop (RP): UNKNOWN > Upstream MRIB next hop (S): UNKNOWN > Upstream RPF'(S,G): UNKNOWN > Upstream state: Joined > Register state: RegisterJoin RegisterCouldRegister > Join timer: 42 > KAT(S,G) running: true > Local receiver include WC: ..O.. > Local receiver include SG: ..... > Local receiver exclude SG: ..... > Joins RP: ..... > Joins WC: ..... > Joins SG: ....O > Join state: ....O > Prune state: ..... > Prune pending state: ..... > I am assert winner state: ..... > I am assert loser state: ..... > Assert winner WC: ..... > Assert winner SG: ..... > Assert lost WC: ..... > Assert lost SG: ..... > Assert lost SG_RPT: ..... > Assert tracking SG: .OO.O > Could assert WC: ..O.. > Could assert SG: ..O.O > I am DR: .OO.O > Immediate olist RP: ..... > Immediate olist WC: ..O.. > Immediate olist SG: ....O > Inherited olist SG: ..O.O > Inherited olist SG_RPT: ..O.. > PIM include WC: ..O.. > PIM include SG: ..... > PIM exclude SG: ..... > root at lanforge-D0-20> > > Router-1: > root at lanforge-D0-20> show pim join > created new heap in find_heap, ptr: 0x8103d00 > created new heap in find_heap, ptr: 0x81055c8 > Group Source RP Flags > 224.2.3.4 0.0.0.0 RP_ADDR_UNKNOWN WC > Upstream interface (RP): UNKNOWN > Upstream MRIB next hop (RP): UNKNOWN > Upstream RPF'(*,G): UNKNOWN > Upstream state: Joined > Join timer: 7 > Local receiver include WC: ..O. > Joins RP: .... > Joins WC: .... > Join state: .... > Prune state: .... > Prune pending state: .... > I am assert winner state: .... > I am assert loser state: .... > Assert winner WC: .... > Assert lost WC: .... > Assert tracking WC: ..O. > Could assert WC: ..O. > I am DR: .OOO > Immediate olist RP: .... > Immediate olist WC: ..O. > Inherited olist SG: ..O. > Inherited olist SG_RPT: ..O. > PIM include WC: ..O. > root at lanforge-D0-20> > > Router-0: > root at lanforge-D0-20> show pim mfc > Group Source RP > 224.2.3.4 2.3.4.137 0.0.0.0 > Incoming interface : rddVR1 > Outgoing interfaces: ..O.O > > Router-1: > root at lanforge-D0-20> show pim mfc > Group Source RP > > > Router-1: > root at lanforge-D0-20> show pim bootstrap > created new heap in find_heap, ptr: 0x8103d10 > created new heap in find_heap, ptr: 0x81055d8 > Active zones: > BSR Pri LocalAddress Pri State Timeout SZTimeout > Expiring zones: > BSR Pri LocalAddress Pri State Timeout SZTimeout > Configured zones: > BSR Pri LocalAddress Pri State Timeout SZTimeout > 0.0.0.0 0 0.0.0.0 0 Init -1 -1 > root at lanforge-D0-20> > > Router-0: > root at lanforge-D0-20> show pim bootstrap > created new heap in find_heap, ptr: 0x8103d10 > created new heap in find_heap, ptr: 0x81055d8 > Active zones: > BSR Pri LocalAddress Pri State Timeout SZTimeout > Expiring zones: > BSR Pri LocalAddress Pri State Timeout SZTimeout > Configured zones: > BSR Pri LocalAddress Pri State Timeout SZTimeout > 0.0.0.0 0 0.0.0.0 0 Init -1 -1 > > > > > -- > 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 Tue Jun 24 10:51:51 2008 From: greearb at candelatech.com (Ben Greear) Date: Tue, 24 Jun 2008 10:51:51 -0700 Subject: [Xorp-users] Questions on multicast routing. In-Reply-To: <200806241742.m5OHgnuC018340@fruitcake.ICSI.Berkeley.EDU> References: <485F3AD3.90405@candelatech.com> <200806241616.m5OGGUDF004808@fruitcake.ICSI.Berkeley.EDU> <48612BB9.8020009@candelatech.com> <200806241742.m5OHgnuC018340@fruitcake.ICSI.Berkeley.EDU> Message-ID: <48613437.2030208@candelatech.com> Pavlin Radoslavov wrote: >>> After that use "show pim rps" to check that all PIM-SM routers have >>> same Cand-RP set. >> This is on a different machine, but logically it is the same setup, >> though the interface names are a bit different. I think that it's not >> doing the BSR stuff correctly. That cli output is at the bottom >> of the email. I tried sniffing the link between the two routers, but >> I don't see anything that is obviously BSR stuff. Any idea what those >> packets look like in wireshark? >> >> Router-0: >> root at lanforge-D0-20> show pim rps >> RP Type Pri Holdtime Timeout ActiveGroups GroupPrefix >> root at lanforge-D0-20> >> >> Router-1: >> root at lanforge-D0-20> show pim rps >> RP Type Pri Holdtime Timeout ActiveGroups GroupPrefix >> root at lanforge-D0-20> > > Empty Cand-RP set is the reason you don't have multicast routing > working. Debugging the BSR mechanism can be time consuming and for > your purpose I don't think it is important. You might want to use a > static RP which is much easier to configure and understand. > > Anyway, if you really want to debug the BSR issue, use commands like > "show pim bootstrap" and "show pim bootstrap rps". After the > Bootstrap router is elected, all Cand RPs will start unicasting > Cand-RP-Adv messages to it. > The PIM Bootstrap message is multicast periodically (group 224.0.0.13) > and propagated hop-by-hop. > > Pavlin Ok, thanks for that info. I think I'll spend a few minutes trying to understand the BSR code a bit to make sure it's not just some simple problem. I like the idea of everything just being automated, since my routers may come and go from the network. The bootstrap code is in pim/pim_bsr.cc primarily? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at ICSI.Berkeley.EDU Tue Jun 24 11:07:41 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Tue, 24 Jun 2008 11:07:41 -0700 Subject: [Xorp-users] Questions on multicast routing. In-Reply-To: <48613437.2030208@candelatech.com> References: <485F3AD3.90405@candelatech.com> <200806241616.m5OGGUDF004808@fruitcake.ICSI.Berkeley.EDU> <48612BB9.8020009@candelatech.com> <200806241742.m5OHgnuC018340@fruitcake.ICSI.Berkeley.EDU> <48613437.2030208@candelatech.com> Message-ID: <200806241807.m5OI7fUV022488@fruitcake.ICSI.Berkeley.EDU> > Ok, thanks for that info. I think I'll spend a few minutes > trying to understand the BSR code a bit to make sure it's not just > some simple problem. I like the idea of everything just being automated, > since my routers may come and go from the network. > > The bootstrap code is in pim/pim_bsr.cc primarily? It is in pim/pim_bsr.cc and pim/pim_proto_bootstrap.cc. The related PIM Cand-RP-Adv code is in pim/pim_proto_cand_rp_adv.cc. Note that when a multicast PIM Bootstrap message is received, it might be rejected for some reasons. One reason could be if the message didn't come from the RPF router toward the Cand-BSR router in the message. Hence, if the unicast routing is not working properly, the Bootstrap mechanism might fail. If you want to understand how the BSR works in general, it is better to read the BSR spec (RFC 5059). Regards, Pavlin From greearb at candelatech.com Tue Jun 24 12:08:31 2008 From: greearb at candelatech.com (Ben Greear) Date: Tue, 24 Jun 2008 12:08:31 -0700 Subject: [Xorp-users] Questions on multicast routing. In-Reply-To: <200806241807.m5OI7fUV022488@fruitcake.ICSI.Berkeley.EDU> References: <485F3AD3.90405@candelatech.com> <200806241616.m5OGGUDF004808@fruitcake.ICSI.Berkeley.EDU> <48612BB9.8020009@candelatech.com> <200806241742.m5OHgnuC018340@fruitcake.ICSI.Berkeley.EDU> <48613437.2030208@candelatech.com> <200806241807.m5OI7fUV022488@fruitcake.ICSI.Berkeley.EDU> Message-ID: <4861462F.40200@candelatech.com> Pavlin Radoslavov wrote: >> Ok, thanks for that info. I think I'll spend a few minutes >> trying to understand the BSR code a bit to make sure it's not just >> some simple problem. I like the idea of everything just being automated, >> since my routers may come and go from the network. >> >> The bootstrap code is in pim/pim_bsr.cc primarily? > > It is in pim/pim_bsr.cc and pim/pim_proto_bootstrap.cc. The related > PIM Cand-RP-Adv code is in pim/pim_proto_cand_rp_adv.cc. > Note that when a multicast PIM Bootstrap message is received, it > might be rejected for some reasons. One reason could be if the > message didn't come from the RPF router toward the Cand-BSR router > in the message. Hence, if the unicast routing is not working > properly, the Bootstrap mechanism might fail. > > If you want to understand how the BSR works in general, it is better > to read the BSR spec (RFC 5059). My problem was embarrassingly simple: I just didn't have a cand-bsr entry in the bootstrap section, just a cand-rp. Is that ever valid? If not, maybe it would be worth warning loudly on startup to help clueless users? It seems to be routing fine in my 2-router scenario...I'll try much larger configs shortly! Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From pavlin at ICSI.Berkeley.EDU Tue Jun 24 12:17:46 2008 From: pavlin at ICSI.Berkeley.EDU (Pavlin Radoslavov) Date: Tue, 24 Jun 2008 12:17:46 -0700 Subject: [Xorp-users] Questions on multicast routing. In-Reply-To: <4861462F.40200@candelatech.com> References: <485F3AD3.90405@candelatech.com> <200806241616.m5OGGUDF004808@fruitcake.ICSI.Berkeley.EDU> <48612BB9.8020009@candelatech.com> <200806241742.m5OHgnuC018340@fruitcake.ICSI.Berkeley.EDU> <48613437.2030208@candelatech.com> <200806241807.m5OI7fUV022488@fruitcake.ICSI.Berkeley.EDU> <4861462F.40200@candelatech.com> Message-ID: <200806241917.m5OJHlR7005791@fruitcake.ICSI.Berkeley.EDU> > My problem was embarrassingly simple: > > I just didn't have a cand-bsr entry in the bootstrap section, just a cand-rp. > > Is that ever valid? If not, maybe it would be worth warning loudly on > startup to help clueless users? Yes, it is valid. You could have a Cand-BSR that is not Cand-RP and vice-versa. Pavlin > It seems to be routing fine in my 2-router scenario...I'll try much larger > configs shortly! > > 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 agaviola at infoweapons.com Tue Jun 24 22:14:28 2008 From: agaviola at infoweapons.com (Archimedes S. Gaviola) Date: Wed, 25 Jun 2008 13:14:28 +0800 Subject: [Xorp-users] ASM Configuration Options with XORP In-Reply-To: <200806241718.m5OHIWxA014115@fruitcake.ICSI.Berkeley.EDU> References: <486071AB.40906@infoweapons.com> <200806241718.m5OHIWxA014115@fruitcake.ICSI.Berkeley.EDU> Message-ID: <4861D434.8030705@infoweapons.com> Pavlin Radoslavov wrote: > Archimedes S. Gaviola wrote: > > >> To Whom It May Concerned: >> >> Hello and good day! I have 2 multicast routers running XORP 1.4 and I >> want to configure it with ASM. I have tried SSM which is more >> straightforward to configure because only few configurations options >> were being set in the configuration file (config.boot). In the manual, I >> could see the options like >> >> static-rps >> bootstrap (with sub options of candidate BSR and candidate RP) >> >> In my scenario were there are 2 ASM multicast routers, I am going to >> have the same RP address in the static-rps option? When I am going to >> > > Yes, if you decide that you are going to use static RPs in your > network, then all PIM-SM routers must have exactly same set of > static RPs configuration. > > >> use bootstrap option? Is it used to configure both the multicast >> routers? What about candidate BSR and candidate RP, when to use them? My >> goal is to setup a very simple ASM network with a streaming server on >> one side of the network behind a multicast router and streaming clients >> on the other side with another multicast router. >> > > If you have a very small number of PIM-SM routers, then static RPs > is a simpler mechanism: simpler to understand, configure and debug. > The downside is that it is static and error-prone. > If you decide to change the Cand-RP set then you need to reconfigure > all of your routers. The reconfiguration should happen while there > is no multicast streaming otherwise you might create a multicast > loop and bring the whole network down. > Another downside is that if you have redundant links and the current > RP (as defined in the static config) is disconnected, the rest of > the network won't be able to use multicast. > > The Bootstrap mechanism is dynamic and doesn't have the > disadvantages listed above. However, it is more complex to > understand and is more difficult to debug. > > It looks like you have a very simple topology: just two multicast > routers with a single link between them. > In that case I think a single static RP should be fine. For > efficiency (to avoid the PIM Register encapsulation) you might want > to select the RP to be the router that is directly connected to the > sender. > Just don't forget to have same state-rps statement in both routers :) > > Pavlin > > Thanks Pavlin for a wonderful explanation! For now this is just a simple multicast topology but I may reconfigure my routers soon when needed for more additional multicast routers. I can now proceed with my ASM configuration. From arvind at macil.in Fri Jun 27 03:07:31 2008 From: arvind at macil.in (arvind) Date: Fri, 27 Jun 2008 15:37:31 +0530 Subject: [Xorp-users] Issues related to OSPF path selection Message-ID: <4864BBE3.8000809@macil.in> A , B--> Server running router manager with 2 ethernet ports (With OSPF) C------> Its a server running router manager with 10 ethernet ports(with static and OSPF protocols) This picture May not be clear in some systems for those I have explained the setup below. _________ _________ | | 172.16.3.1 172.16.3.2 | | | A 1|<----------------------------->|1 B | | 0 | | 0 | --------- --------- 172.16.2.1 ^ ^ 172.16.1.1 | | | | | | | | | | | | | | | | | | | | | _________ | | | | | ----------->| C |<----------------- 172.16.2.2 | | 172.16.1.2 --------- Server C has the following in configuration file: protocols { static { disable: false route 10.10.10.0/24 { next-hop: 172.16.10.10 metric: 1 } route 10.10.11.0/24 { next-hop: 172.16.11.10 metric: 1 } } ospf4 { router-id: 172.16.1.2 area 0.0.0.0 { interface eth2 { vif eth2.0 { address 172.16.2.2 { } } } interface eth4 { vif eth4.0 { address 172.16.1.2 { } } } } export: "connected,static" } } policy { policy-statement connected { term export { from { protocol: "connected" } } } policy-statement static { term export { from { protocol: "static" } } } } interfaces { restore-original-config-on-shutdown: true interface eth0 { disable: false discard: false description: "data interface" mac: 00:bb:cc:dd:ee:00 mtu: 1500 vif eth0.0 { disable: false vlan { vlan-id: 0 } address 172.16.10.2 { prefix-length: 24 broadcast: 172.16.10.255 disable: false } } } interface eth1 { disable: false discard: false description: "data interface" mac: 00:bb:cc:dd:ee:01 mtu: 1500 vif eth1.0 { disable: false vlan { vlan-id: 0 } address 172.16.11.2 { prefix-length: 24 broadcast: 172.16.11.255 disable: false } } } interface eth2 { disable: false discard: false description: "data interface" mac: 00:bb:cc:dd:ee:02 mtu: 1500 vif eth2.0 { disable: false vlan { vlan-id: 0 } address 172.16.2.2 { prefix-length: 24 broadcast: 172.16.2.255 disable: false } } } interface eth4 { disable: false discard: false description: "data interface" mac: 00:bb:cc:dd:ee:04 mtu: 1500 vif eth4.0 { disable: false vlan { vlan-id: 0 } address 172.16.1.2 { prefix-length: 24 broadcast: 172.16.1.255 disable: false } } } } I will explain the set-up (the Above diagram may not be clear while receiving) 3 systems are there running with router manager A,B,C A and B is connected with the network 172.16.3.1 nad 172.16.3.2 A and C is connected with the network 172.16.2.1 nad 172.16.2.2 B and C is connected with the network 172.16.1.1 nad 172.16.1.2 After running router manager in all the systems the OSPF states are "full" and the "show route table ipv4 unicast ospf" is showing the shortest path.But the issue is whenever the path is remove/broken (2 or 3 times) between any 2 systems and replacing then the back again it was not showing the shortest path.. By giving "clear ospf database" the shortest paths are coming back again. My Test: I remove the path between A and C and replaced it back again but it was not showing the shortest path. Output checked in A: output before removing the connection: root at test1> show ospf4 neighbor Address Interface State ID Pri Dead 172.16.2.2 eth0/eth0 Full 172.16.1.2 128 30 172.16.3.2 eth1/eth1 Full 172.16.1.1 128 30 root at test1> show route table ipv4 unicast ospf 10.10.10.0/24 [ospf(110)/1] > to 172.16.2.2 via eth0/eth0 10.10.11.0/24 [ospf(110)/1] > to 172.16.2.2 via eth0/eth0 172.16.1.0/24 [ospf(110)/2] > to 172.16.3.2 via eth1/eth1 172.16.10.0/24 [ospf(110)/1] > to 172.16.2.2 via eth0/eth0 172.16.11.0/24 [ospf(110)/1] > to 172.16.2.2 via eth0/eth0 root at test1> output after removing the connection: root at test1> show ospf4 neighbor Address Interface State ID Pri Dead 172.16.2.2 eth0/eth0 Down 172.16.1.2 0 0 172.16.3.2 eth1/eth1 Full 172.16.1.1 128 38 root at test1> show route table ipv4 unicast ospf 10.10.10.0/24 [ospf(110)/1] > to 172.16.3.2 via eth1/eth1 10.10.11.0/24 [ospf(110)/1] > to 172.16.3.2 via eth1/eth1 172.16.1.0/24 [ospf(110)/2] > to 172.16.3.2 via eth1/eth1 172.16.10.0/24 [ospf(110)/1] > to 172.16.3.2 via eth1/eth1 172.16.11.0/24 [ospf(110)/1] > to 172.16.3.2 via eth1/eth1 root at test1> Its fine still now, but the problem is after replacing the path between A and C, It was not taking.... output after replacing the connection: root at test1> show route table ipv4 unicast ospf 10.10.10.0/24 [ospf(110)/1] > to 172.16.3.2 via eth1/eth1 10.10.11.0/24 [ospf(110)/1] > to 172.16.3.2 via eth1/eth1 172.16.1.0/24 [ospf(110)/2] > to 172.16.3.2 via eth1/eth1 172.16.10.0/24 [ospf(110)/1] > to 172.16.3.2 via eth1/eth1 172.16.11.0/24 [ospf(110)/1] > to 172.16.3.2 via eth1/eth1 root at test1> If I give "clear ospf database" and then "show route table ipv4 unicast ospf" then the paths are coming as shortest path. At this situation If I remove the path between C and B, System A doesnot know any route about the neighbors. Can any one give the solution/idea for the above problem. From minlanyu at cs.princeton.edu Fri Jun 27 06:27:46 2008 From: minlanyu at cs.princeton.edu (Minlan Yu) Date: Fri, 27 Jun 2008 09:27:46 -0400 Subject: [Xorp-users] xorp in openvz Message-ID: Hi, I tried to run xorp in openvz using ./xorp_rtrmgr -b xorp.conf It doesn't output anything but goes back the console. Can anyone tell me what's happening? or how can I figure it out? Thanks, -- Minlan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080627/e9b47dbb/attachment.html From yueli.m at gmail.com Fri Jun 27 06:41:27 2008 From: yueli.m at gmail.com (Yue Li) Date: Fri, 27 Jun 2008 09:41:27 -0400 Subject: [Xorp-users] xorp in openvz In-Reply-To: References: Message-ID: <49567c360806270641x1bb5e531i74776440c9ac2b61@mail.gmail.com> Hi, Please check if there is stderr device in your virtual machine, On Fri, Jun 27, 2008 at 9:27 AM, Minlan Yu wrote: > Hi, > > I tried to run xorp in openvz using ./xorp_rtrmgr -b xorp.conf > It doesn't output anything but goes back the console. > > Can anyone tell me what's happening? or how can I figure it out? > > Thanks, > > -- Minlan > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > From agaviola at infoweapons.com Mon Jun 30 01:17:43 2008 From: agaviola at infoweapons.com (Archimedes S. Gaviola) Date: Mon, 30 Jun 2008 16:17:43 +0800 Subject: [Xorp-users] IPv4-to-IPv6 Multicast Translation Message-ID: <486896A7.5080801@infoweapons.com> Hi! I need to know if XORP project have some roadmap for unicast and multicast transition mechanisms since it fairly supports both IPv4 and IPv6 for all the routing protocols implemented? Co-existence between the legacy IPv4 and the new IPv6 protocol is nowadays the trend to deploy the new Internet. Is it possible if we can add a feature on XORP wherein it can translate IPv4 multicast to IPv6 multicast just like one of the link here http://forskningsnett.uninett.no/testnett/multicast/mcgw/? Thanks, Archimedes From bms at incunabulum.net Mon Jun 30 03:45:36 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Mon, 30 Jun 2008 11:45:36 +0100 Subject: [Xorp-users] IPv4-to-IPv6 Multicast Translation In-Reply-To: <486896A7.5080801@infoweapons.com> References: <486896A7.5080801@infoweapons.com> Message-ID: <4868B950.6070102@incunabulum.net> Archimedes S. Gaviola wrote: > Hi! I need to know if XORP project have some roadmap for unicast and > multicast transition mechanisms since it fairly supports both IPv4 and > IPv6 for all the routing protocols implemented? Co-existence between the > legacy IPv4 and the new IPv6 protocol is nowadays the trend to deploy > the new Internet. Is it possible if we can add a feature on XORP wherein > it can translate IPv4 multicast to IPv6 multicast just like one of the > link here http://forskningsnett.uninett.no/testnett/multicast/mcgw/? > XORP is router control plane software. What you are describing is something which requires cooperation from both the forwarding plane and the control plane. As far as I am aware, there are no current plans to offer such functionality. If anyone is willing to contribue this work then it would be very welcome. A good starting point for this work would be to work on adding proxy functionality to the existing xorp_mld and xorp_igmp processes. thanks BMS From atanu at ICSI.Berkeley.EDU Mon Jun 30 08:26:10 2008 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Mon, 30 Jun 2008 08:26:10 -0700 Subject: [Xorp-users] Issues related to OSPF path selection In-Reply-To: Message from arvind of "Fri, 27 Jun 2008 15:37:31 +0530." <4864BBE3.8000809@macil.in> Message-ID: <46695.1214839570@tigger.icir.org> Hi, Could you try this experiment with the latest code from CVS. Atanu. arvind wrote: > > > > A , B--> Server running router manager with 2 ethernet ports (With OSPF) > C------> Its a server running router manager with 10 ethernet ports(with > static and OSPF protocols) > > > This picture May not be clear in some systems for those I have explained > the setup below. > > _________ _________ | | 172.16.3.1 172.16.3.2 | | > | A 1|<----------------------------->|1 B | > | 0 | | 0 | --------- --------- 172.16.2.1 ^ > ^ 172.16.1.1 > | | > | | > | | > | | > | | > | | > | | > | | > | | > | | > | _________ | | | | | > ----------->| C |<----------------- > 172.16.2.2 | | 172.16.1.2 > --------- > > > > Server C has the following in configuration file: > > > protocols { > static { > disable: false > route 10.10.10.0/24 { > next-hop: 172.16.10.10 > metric: 1 > } > route 10.10.11.0/24 { > next-hop: 172.16.11.10 > metric: 1 > } > } > ospf4 { > router-id: 172.16.1.2 > area 0.0.0.0 { > interface eth2 { > vif eth2.0 { > address 172.16.2.2 { > } > } > } > interface eth4 { > vif eth4.0 { > address 172.16.1.2 { > } > } > } > } > export: "connected,static" > } > } > > policy { > policy-statement connected { > term export { > from { > protocol: "connected" > } > } > } > policy-statement static { > term export { > from { > protocol: "static" > } > } > } > } > > interfaces { > restore-original-config-on-shutdown: true > interface eth0 { > disable: false > discard: false > description: "data interface" > mac: 00:bb:cc:dd:ee:00 > mtu: 1500 > vif eth0.0 { > disable: false > vlan { > vlan-id: 0 > } > address 172.16.10.2 { > prefix-length: 24 > broadcast: 172.16.10.255 > disable: false > } > } > } > interface eth1 { > disable: false > discard: false > description: "data interface" > mac: 00:bb:cc:dd:ee:01 > mtu: 1500 > vif eth1.0 { > disable: false > vlan { > vlan-id: 0 > } > address 172.16.11.2 { > prefix-length: 24 > broadcast: 172.16.11.255 > disable: false > } > } > } > interface eth2 { > disable: false > discard: false > description: "data interface" > mac: 00:bb:cc:dd:ee:02 > mtu: 1500 > vif eth2.0 { > disable: false > vlan { > vlan-id: 0 > } > address 172.16.2.2 { > prefix-length: 24 > broadcast: 172.16.2.255 > disable: false > } > } > } > interface eth4 { > disable: false > discard: false > description: "data interface" > mac: 00:bb:cc:dd:ee:04 > mtu: 1500 > vif eth4.0 { > disable: false > vlan { > vlan-id: 0 > } > address 172.16.1.2 { > prefix-length: 24 > broadcast: 172.16.1.255 > disable: false > } > } > } > } > > > > I will explain the set-up (the Above diagram may not be clear while > receiving) > 3 systems are there running with router manager A,B,C > > A and B is connected with the network 172.16.3.1 nad 172.16.3.2 > > A and C is connected with the network 172.16.2.1 nad 172.16.2.2 > > B and C is connected with the network 172.16.1.1 nad 172.16.1.2 > > > After running router manager in all the systems the OSPF states are > "full" and the "show route table ipv4 unicast ospf" is showing the > shortest path.But the issue is whenever the path is remove/broken (2 or > 3 times) between any 2 systems and replacing then the back again it was > not showing the shortest path.. > > > By giving "clear ospf database" the shortest paths are coming back again. > > > > > My Test: > I remove the path between A and C and replaced it back again but it was > not showing the shortest path. > > Output checked in A: > output before removing the connection: > > > root at test1> show ospf4 neighbor > Address Interface State ID Pri > Dead > 172.16.2.2 eth0/eth0 Full 172.16.1.2 128 30 > 172.16.3.2 eth1/eth1 Full 172.16.1.1 128 30 > > root at test1> show route table ipv4 unicast ospf > 10.10.10.0/24 [ospf(110)/1] > > to 172.16.2.2 via eth0/eth0 > 10.10.11.0/24 [ospf(110)/1] > > to 172.16.2.2 via eth0/eth0 > 172.16.1.0/24 [ospf(110)/2] > > to 172.16.3.2 via eth1/eth1 > 172.16.10.0/24 [ospf(110)/1] > > to 172.16.2.2 via eth0/eth0 > 172.16.11.0/24 [ospf(110)/1] > > to 172.16.2.2 via eth0/eth0 > root at test1> > > > > > > output after removing the connection: > > root at test1> show ospf4 neighbor > Address Interface State ID Pri > Dead > 172.16.2.2 eth0/eth0 Down 172.16.1.2 0 0 > 172.16.3.2 eth1/eth1 Full 172.16.1.1 128 38 > > root at test1> show route table ipv4 unicast ospf > 10.10.10.0/24 [ospf(110)/1] > > to 172.16.3.2 via eth1/eth1 > 10.10.11.0/24 [ospf(110)/1] > > to 172.16.3.2 via eth1/eth1 > 172.16.1.0/24 [ospf(110)/2] > > to 172.16.3.2 via eth1/eth1 > 172.16.10.0/24 [ospf(110)/1] > > to 172.16.3.2 via eth1/eth1 > 172.16.11.0/24 [ospf(110)/1] > > to 172.16.3.2 via eth1/eth1 > root at test1> > > > Its fine still now, but the problem is after replacing the path between > A and C, It was not taking.... > > > > > output after replacing the connection: > > > root at test1> show route table ipv4 unicast ospf > 10.10.10.0/24 [ospf(110)/1] > > to 172.16.3.2 via eth1/eth1 > 10.10.11.0/24 [ospf(110)/1] > > to 172.16.3.2 via eth1/eth1 > 172.16.1.0/24 [ospf(110)/2] > > to 172.16.3.2 via eth1/eth1 > 172.16.10.0/24 [ospf(110)/1] > > to 172.16.3.2 via eth1/eth1 > 172.16.11.0/24 [ospf(110)/1] > > to 172.16.3.2 via eth1/eth1 > root at test1> > > > > > If I give "clear ospf database" and then "show route table ipv4 unicast > ospf" then the paths are coming as shortest path. > > > At this situation If I remove the path between C and B, > > System A doesnot know any route about the neighbors. > > > > Can any one give the solution/idea for the above problem. > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From agaviola at infoweapons.com Mon Jun 30 20:06:09 2008 From: agaviola at infoweapons.com (Archimedes S. Gaviola) Date: Tue, 01 Jul 2008 11:06:09 +0800 Subject: [Xorp-users] IPv4-to-IPv6 Multicast Translation In-Reply-To: <4868B950.6070102@incunabulum.net> References: <486896A7.5080801@infoweapons.com> <4868B950.6070102@incunabulum.net> Message-ID: <48699F21.9000100@infoweapons.com> Bruce M Simpson wrote: > Archimedes S. Gaviola wrote: >> Hi! I need to know if XORP project have some roadmap for unicast and >> multicast transition mechanisms since it fairly supports both IPv4 >> and IPv6 for all the routing protocols implemented? Co-existence >> between the legacy IPv4 and the new IPv6 protocol is nowadays the >> trend to deploy the new Internet. Is it possible if we can add a >> feature on XORP wherein it can translate IPv4 multicast to IPv6 >> multicast just like one of the link here >> http://forskningsnett.uninett.no/testnett/multicast/mcgw/? >> > > XORP is router control plane software. What you are describing is > something which requires cooperation from both the forwarding plane > and the control plane. > > As far as I am aware, there are no current plans to offer such > functionality. If anyone is willing to contribue this work then it > would be very welcome. > > A good starting point for this work would be to work on adding proxy > functionality to the existing xorp_mld and xorp_igmp processes. > > thanks > BMS > Thanks Bruce for your reply! At least I know at the moment that this is not yet a planned functionality of XORP but this is really a nice-to-have feature as far as IPv6 transition is concerned. Archimedes From arvind at macil.in Mon Jun 30 20:20:23 2008 From: arvind at macil.in (arvind) Date: Tue, 01 Jul 2008 08:50:23 +0530 Subject: [Xorp-users] Issues related to OSPF path selection In-Reply-To: <46695.1214839570@tigger.icir.org> References: <46695.1214839570@tigger.icir.org> Message-ID: <4869A277.1050906@macil.in> An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20080701/c2a86bad/attachment.html