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