From arthur at layese.com Fri Jun 1 01:48:46 2007 From: arthur at layese.com (Arthur N. Layese) Date: Fri, 01 Jun 2007 16:48:46 +0800 Subject: [Xorp-users] Cannot enable vif register_vif In-Reply-To: References: Message-ID: <465FDD6E.2070904@layese.com> To whom it may concern, Why is it I cannot be able to start the xorp_rtrmgr with the below plumbing configuration for mfea4? plumbing { mfea4 { disable: false interface register_vif { vif register_vif { disable: false } } } } When I have this configuration, the xorp_rtrmgr will start. :) plumbing { mfea4 { disable: false interface em0 { vif em0 { disable: false } } interface register_vif { vif register_vif { disable: false } } } } Can someone explain why? Regards, artiskool Here is the logs: root at art:~# /usr/local/xorp/bin/xorp_rtrmgr -b /usr/local/xorp/config.boot [ 2007/06/01 08:24:39 INFO xorp_rtrmgr:3043 RTRMGR +239 master_conf_tree.cc execute ] Changed modules: interfaces, fea, mfea4, rib, fib2mrib, igmp, pimsm4 [ 2007/06/01 08:24:39 INFO xorp_rtrmgr:3043 RTRMGR +96 module_manager.cc execute ] Executing module: interfaces (fea/xorp_fea) [ 2007/06/01 08:24:41 INFO xorp_fea MFEA ] MFEA enabled [ 2007/06/01 08:24:41 INFO xorp_fea MFEA ] CLI enabled [ 2007/06/01 08:24:41 INFO xorp_fea MFEA ] CLI started [ 2007/06/01 08:24:41 INFO xorp_fea MFEA ] MFEA enabled [ 2007/06/01 08:24:41 INFO xorp_fea MFEA ] CLI enabled [ 2007/06/01 08:24:41 INFO xorp_fea MFEA ] CLI started [ 2007/06/01 08:24:41 INFO xorp_rtrmgr:3043 RTRMGR +96 module_manager.cc execute ] Executing module: fea (fea/xorp_fea) [ 2007/06/01 08:24:47 INFO xorp_rtrmgr:3043 RTRMGR +96 module_manager.cc execute ] Executing module: mfea4 (fea/xorp_fea) [ 2007/06/01 08:24:48 INFO xorp_fea MFEA ] Interface added: Vif[em0] pif_index: 1 vif_index: 0 addr: 192.168.10.2 subnet: 192.168.10.0/24 broadcast: 192.168.10.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 [ 2007/06/01 08:24:48 INFO xorp_fea MFEA ] Interface added: Vif[em1] pif_index: 2 vif_index: 1 addr: 10.3.3.112 subnet: 10.0.0.0/8 broadcast: 10.255.255.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 [ 2007/06/01 08:24:48 INFO xorp_fea MFEA ] MFEA started [ 2007/06/01 08:24:48 ERROR xorp_fea:3044 MFEA +857 mfea_node.cc enable_vif ] Cannot enable vif register_vif: no such vif [ 2007/06/01 08:24:48 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfea/0.1/enable_vif failed: XrlCmdError 102 Command failed Cannot enable vif register_vif: no such vif [ 2007/06/01 08:24:48 ERROR xorp_rtrmgr:3043 RTRMGR +675 master_conf_tree.cc commit_pass2_done ] Commit failed: 102 Command failed Cannot enable vif register_vif: no such vif [ 2007/06/01 08:24:48 ERROR xorp_rtrmgr:3043 RTRMGR +251 master_conf_tree.cc config_done ] Configuration failed: 102 Command failed Cannot enable vif register_vif: no such vif [ 2007/06/01 08:24:48 INFO xorp_rtrmgr:3043 RTRMGR +2228 task.cc run_task ] No more tasks to run [ 2007/06/01 08:24:48 INFO xorp_rtrmgr:3043 RTRMGR +171 module_manager.cc terminate ] Terminating module: fea [ 2007/06/01 08:24:48 INFO xorp_rtrmgr:3043 RTRMGR +171 module_manager.cc terminate ] Terminating module: interfaces [ 2007/06/01 08:24:48 INFO xorp_rtrmgr:3043 RTRMGR +171 module_manager.cc terminate ] Terminating module: mfea4 [ 2007/06/01 08:24:48 INFO xorp_rtrmgr:3043 RTRMGR +194 module_manager.cc terminate ] Killing module: mfea4 [ 2007/06/01 08:24:48 ERROR xorp_rtrmgr:3043 RTRMGR +747 module_manager.cc done_cb ] Command "/usr/local/xorp/fea/xorp_fea": terminated with signal 15. [ 2007/06/01 08:24:48 INFO xorp_rtrmgr:3043 RTRMGR +282 module_manager.cc module_exited ] Module killed during shutdown: mfea4 Here is the contents of /usr/local/xorp/config.boot interfaces { interface em0 { disable: false default-system-config } interface em1 { disable: false default-system-config } } protocols { fib2mrib { disable: false } } plumbing { mfea4 { disable: false interface register_vif { vif register_vif { disable: false } } } } fea { unicast-forwarding4 { disable: false } } -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070601/f954ddd3/attachment.bin From pavlin at icir.org Mon Jun 4 10:25:21 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Mon, 04 Jun 2007 10:25:21 -0700 Subject: [Xorp-users] Cannot enable vif register_vif In-Reply-To: Message from "Arthur N. Layese" of "Fri, 01 Jun 2007 16:48:46 +0800." <465FDD6E.2070904@layese.com> Message-ID: <200706041725.l54HPLYA078203@possum.icir.org> > Why is it I cannot be able to start the xorp_rtrmgr with the below plumbing > configuration for mfea4? > > plumbing { > mfea4 { > disable: false > interface register_vif { > vif register_vif { > disable: false > } > } > } > } > > > When I have this configuration, the xorp_rtrmgr will start. :) > > plumbing { > mfea4 { > disable: false > interface em0 { > vif em0 { > disable: false > } > } > interface register_vif { > vif register_vif { > disable: false > } > } > } > } > > > > Can someone explain why? The register_vif is special. It is used by PIM-SM and has meaning only when configured in the kernel for multicast forwarding purpose. It doesn't have its own IP address, but instead (re)uses the IP address of some other interface. Hence, the MFEA must have some other interfaces configured, so register_vif can reuse the IP address from one of them. Regards, Pavlin > > > Regards, > artiskool > > > > > Here is the logs: > > root at art:~# /usr/local/xorp/bin/xorp_rtrmgr -b /usr/local/xorp/config.boot > [ 2007/06/01 08:24:39 INFO xorp_rtrmgr:3043 RTRMGR +239 master_conf_tree.cc > execute ] Changed modules: interfaces, fea, mfea4, rib, fib2mrib, igmp, pimsm4 > [ 2007/06/01 08:24:39 INFO xorp_rtrmgr:3043 RTRMGR +96 module_manager.cc > execute ] Executing module: interfaces (fea/xorp_fea) > [ 2007/06/01 08:24:41 INFO xorp_fea MFEA ] MFEA enabled > [ 2007/06/01 08:24:41 INFO xorp_fea MFEA ] CLI enabled > [ 2007/06/01 08:24:41 INFO xorp_fea MFEA ] CLI started > [ 2007/06/01 08:24:41 INFO xorp_fea MFEA ] MFEA enabled > [ 2007/06/01 08:24:41 INFO xorp_fea MFEA ] CLI enabled > [ 2007/06/01 08:24:41 INFO xorp_fea MFEA ] CLI started > [ 2007/06/01 08:24:41 INFO xorp_rtrmgr:3043 RTRMGR +96 module_manager.cc > execute ] Executing module: fea (fea/xorp_fea) > [ 2007/06/01 08:24:47 INFO xorp_rtrmgr:3043 RTRMGR +96 module_manager.cc > execute ] Executing module: mfea4 (fea/xorp_fea) > [ 2007/06/01 08:24:48 INFO xorp_fea MFEA ] Interface added: Vif[em0] > pif_index: 1 vif_index: 0 addr: 192.168.10.2 subnet: 192.168.10.0/24 > broadcast: 192.168.10.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST > UNDERLYING_VIF_UP MTU: 1500 > [ 2007/06/01 08:24:48 INFO xorp_fea MFEA ] Interface added: Vif[em1] > pif_index: 2 vif_index: 1 addr: 10.3.3.112 subnet: 10.0.0.0/8 broadcast: > 10.255.255.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: > 1500 > [ 2007/06/01 08:24:48 INFO xorp_fea MFEA ] MFEA started > [ 2007/06/01 08:24:48 ERROR xorp_fea:3044 MFEA +857 mfea_node.cc enable_vif ] > Cannot enable vif register_vif: no such vif > [ 2007/06/01 08:24:48 WARNING xorp_fea XrlMfeaTarget ] Handling method for > mfea/0.1/enable_vif failed: XrlCmdError 102 Command failed Cannot enable vif > register_vif: no such vif > [ 2007/06/01 08:24:48 ERROR xorp_rtrmgr:3043 RTRMGR +675 master_conf_tree.cc > commit_pass2_done ] Commit failed: 102 Command failed Cannot enable vif > register_vif: no such vif > [ 2007/06/01 08:24:48 ERROR xorp_rtrmgr:3043 RTRMGR +251 master_conf_tree.cc > config_done ] Configuration failed: 102 Command failed Cannot enable vif > register_vif: no such vif > [ 2007/06/01 08:24:48 INFO xorp_rtrmgr:3043 RTRMGR +2228 task.cc run_task ] > No more tasks to run > [ 2007/06/01 08:24:48 INFO xorp_rtrmgr:3043 RTRMGR +171 module_manager.cc > terminate ] Terminating module: fea > [ 2007/06/01 08:24:48 INFO xorp_rtrmgr:3043 RTRMGR +171 module_manager.cc > terminate ] Terminating module: interfaces > [ 2007/06/01 08:24:48 INFO xorp_rtrmgr:3043 RTRMGR +171 module_manager.cc > terminate ] Terminating module: mfea4 > [ 2007/06/01 08:24:48 INFO xorp_rtrmgr:3043 RTRMGR +194 module_manager.cc > terminate ] Killing module: mfea4 > [ 2007/06/01 08:24:48 ERROR xorp_rtrmgr:3043 RTRMGR +747 module_manager.cc > done_cb ] Command "/usr/local/xorp/fea/xorp_fea": terminated with signal 15. > [ 2007/06/01 08:24:48 INFO xorp_rtrmgr:3043 RTRMGR +282 module_manager.cc > module_exited ] Module killed during shutdown: mfea4 > > > > > > > Here is the contents of /usr/local/xorp/config.boot > > interfaces { > interface em0 { > disable: false > default-system-config > } > interface em1 { > disable: false > default-system-config > } > } > > protocols { > > fib2mrib { > disable: false > } > > } > > plumbing { > > mfea4 { > disable: false > > interface register_vif { > vif register_vif { > disable: false > } > } > } > } > > fea { > > unicast-forwarding4 { > disable: false > } > } > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From mgbernstein at gmail.com Sat Jun 9 15:25:00 2007 From: mgbernstein at gmail.com (matt bernstein) Date: Sat, 9 Jun 2007 18:25:00 -0400 Subject: [Xorp-users] multicast routing and pim-sm on linux 2.6 problems Message-ID: <5b7195810706091525r30e2fbc2y8f36aedd87323bff@mail.gmail.com> Hi guys, I've been desperately trying to get multicast routing working with kernel 2.6 and pim-sm but to no avail. I'm trying to become a listener on an internal multicast feed but striking out. I am currently using xorp cvs, and any help is greatly appreciated. Details of my configuration are as follows. Topology [host A 10.49.49.230/28] -- 10.49.49.232/28 [ host B xorp router ] 10.49.49.222/28 -- 10.49.49.210/211 [ cisco hsrp router] -- multicast networks Host A is trying to subscribe and recieve data from multicast group 233.76.146.4 RP for the network is 10.48.254.14 via 10.49.49.210/211 real sources servers are 10.49.48.128/27 via 10.49.49.210/211 my routes go to the real ips, not the hsrp ips. As far as I can tell host A is running igmp v3 on interface eth0 so I matched igmp v3 on host B eth0. I can see igmp messages being exchanged between the hosts. Although in the output below the multicast group does not show up in the igmp groups. If i run multicast client/server on host A and host B on the same network they can communicate. Any help is appreciated, thanks. The following output is generated by xorp on multicast join from host A, emcast 233.76.146.4 show pim join Group Source RP Flags 224.0.1.40 0.0.0.0 10.48.254.14 WC Upstream interface (RP): eth1 Upstream MRIB next hop (RP): 10.49.49.211 Upstream RPF'(*,G): 10.49.49.211 Upstream state: Joined Join timer: 13 Local receiver include WC: .O. Joins RP: ... Joins WC: ... Join state: ... Prune state: ... Prune pending state: ... I am assert winner state: ... I am assert loser state: ... Assert winner WC: ... Assert lost WC: ... Assert tracking WC: .O. Could assert WC: ... I am DR: OOO Immediate olist RP: ... Immediate olist WC: .O. Inherited olist SG: .O. Inherited olist SG_RPT: .O. PIM include WC: .O. 233.76.146.4 10.49.49.230 10.48.254.14 SG SPT DirectlyConnectedS Upstream interface (S): eth0 Upstream interface (RP): eth1 Upstream MRIB next hop (RP): 10.49.49.211 Upstream MRIB next hop (S): UNKNOWN Upstream RPF'(S,G): UNKNOWN Upstream state: Joined Register state: RegisterJoin RegisterCouldRegister Join timer: 6 KAT(S,G) running: true Local receiver include WC: ... Local receiver include SG: ... Local receiver exclude SG: ... Joins RP: ... Joins WC: ... Joins SG: ..O Join state: ..O Prune state: ... Prune pending state: ... I am assert winner state: ... I am assert loser state: ... Assert winner WC: ... Assert winner SG: ... Assert lost WC: ... Assert lost SG: ... Assert lost SG_RPT: ... Assert tracking SG: O.O Could assert WC: ... Could assert SG: ..O I am DR: OOO Immediate olist RP: ... Immediate olist WC: ... Immediate olist SG: ..O Inherited olist SG: ..O Inherited olist SG_RPT: ... PIM include WC: ... PIM include SG: ... PIM exclude SG: ... show pim mfc Group Source RP 233.76.146.4 10.49.49.230 10.48.254.14 Incoming interface : eth0 Outgoing interfaces: ..O show pim neighbors Interface DRpriority NeighborAddr V Mode Holdtime Timeout eth1 1 10.49.49.210 2 Sparse 105 80 eth1 1 10.49.49.211 2 Sparse 105 81 show igmp group Interface Group Source LastReported Timeout V State eth0 224.0.0.2 0.0.0.0 10.49.49.232 151 3 E eth0 224.0.0.13 0.0.0.0 10.49.49.232 151 3 E eth0 224.0.0.22 0.0.0.0 10.49.49.232 151 3 E eth1 224.0.0.2 0.0.0.0 10.49.49.222 221 2 E eth1 224.0.0.13 0.0.0.0 10.49.49.222 225 2 E eth1 224.0.0.22 0.0.0.0 10.49.49.222 222 2 E eth1 224.0.1.40 0.0.0.0 10.49.49.210 230 2 E cat ip_mr_cache Group Origin Iif Pkts Bytes Wrong Oifs 04924CE9 E631310A 0 2 66 0 2:1 cat ip_mr_vif Interface BytesIn PktsIn BytesOut PktsOut Flags Local Remote 0 eth0 355 11 0 0 00000 E831310A 00000000 1 eth1 64 2 161 5 00000 DE31310A 00000000 2 pimreg 0 0 355 11 00004 E831310A 00000000 rp_filter is 0 mc_forwarding is 1 ip_forwardig is 1 static routes exist to the RP / source subnets 224 subnet on eth0 Xorp is configured on host B as follows: interfaces { restore-original-config-on-shutdown: false interface eth0 { description: "manage interface" disable: false default-system-config } interface eth1 { description: "data interface" disable: false default-system-config } } fea { unicast-forwarding4 { disable: 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 { static { mrib-route 10.49.48.128/27 { next-hop: 10.49.49.210 metric: 1 } mrib-route 10.49.48.128/27 { next-hop: 10.49.49.211 metric: 2 } mrib-route 10.48.254.14/32 { next-hop: 10.49.49.210 metric: 1 } mrib-route 10.48.254.14/32 { next-hop: 10.49.49.211 metric: 2 } } } protocols { igmp { disable: false interface eth0 { vif eth0 { disable: false version: 3 } } interface eth1 { vif eth1 { disable: false version: 2 } } traceoptions { flag all { disable: false } } } } protocols { pimsm4 { disable: false interface eth0 { vif eth0 { disable: false } } interface eth1 { vif eth1 { disable: false /* enable-ip-router-alert-option-check: false */ /* dr-priority: 1 */ /* hello-period: 30 */ /* hello-triggered-delay: 5 */ /* alternative-subnet 10.49.48.128/27 */ } } interface register_vif { vif register_vif { /* Note: this vif should be always enabled */ disable: false } } static-rps { rp 10.48.254.14 { group-prefix 224.0.0.0/4 { rp-priority: 1 /* hash-mask-len: 30 */ } } } switch-to-spt-threshold { /* approx. 1K bytes/s (10Kbps) threshold */ disable: false interval: 100 bytes: 102400 } traceoptions { flag all { disable: false } } } } protocols { fib2mrib { disable: false } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070609/b94b6225/attachment-0001.html From mgbernstein at gmail.com Sat Jun 9 15:50:10 2007 From: mgbernstein at gmail.com (matt bernstein) Date: Sat, 9 Jun 2007 18:50:10 -0400 Subject: [Xorp-users] multicast routing and pim-sm on linux 2.6 problems Message-ID: <5b7195810706091550h413fb576hdd176cf9b594bafe@mail.gmail.com> Hi, Also just to be thorough here is the xorp log, including when I first initiate a join. Again nothing really jumps out at me, especially based on other comments on this list over time, but again any direction would be great Thanks, - mg XORP startup output bin/xorp_rtrmgr [ 2007/06/09 15:47:09 INFO xorp_rtrmgr:2521 RTRMGR +239 master_conf_tree.cc execute ] Changed modules: interfaces, fea, mfea4, rib, fib2mrib, igmp, pimsm4, policy, static_routes [ 2007/06/09 15:47:09 INFO xorp_rtrmgr:2521 RTRMGR +96 module_manager.cc execute ] Executing module: interfaces (fea/xorp_fea) [ 2007/06/09 15:47:10 INFO xorp_fea MFEA ] MFEA enabled [ 2007/06/09 15:47:10 INFO xorp_fea MFEA ] CLI enabled [ 2007/06/09 15:47:10 INFO xorp_fea MFEA ] CLI started [ 2007/06/09 15:47:10 INFO xorp_fea MFEA ] MFEA enabled [ 2007/06/09 15:47:10 INFO xorp_fea MFEA ] CLI enabled [ 2007/06/09 15:47:10 INFO xorp_fea MFEA ] CLI started [ 2007/06/09 15:47:11 INFO xorp_rtrmgr:2521 RTRMGR +96 module_manager.cc execute ] Executing module: fea (fea/xorp_fea) [ 2007/06/09 15:47:17 INFO xorp_rtrmgr:2521 RTRMGR +96 module_manager.cc execute ] Executing module: mfea4 (fea/xorp_fea) [ 2007/06/09 15:47:17 INFO xorp_fea MFEA ] Interface added: Vif[eth0] pif_index: 1 vif_index: 0 addr: 10.49.49.232 subnet: 10.49.49.224/28broadcast: 10.49.49.239 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 [ 2007/06/09 15:47:17 INFO xorp_fea MFEA ] Interface added: Vif[eth1] pif_index: 2 vif_index: 1 addr: 10.49.49.222 subnet: 10.49.49.208/28broadcast: 10.49.49.223 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 [ 2007/06/09 15:47:17 INFO xorp_fea MFEA ] MFEA started [ 2007/06/09 15:47:17 INFO xorp_fea MFEA ] Interface enabled Vif[eth0] pif_index: 1 vif_index: 0 addr: 10.49.49.232 subnet: 10.49.49.224/28broadcast: 10.49.49.239 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED [ 2007/06/09 15:47:17 INFO xorp_fea MFEA ] Interface started: Vif[eth0] pif_index: 1 vif_index: 0 addr: 10.49.49.232 subnet: 10.49.49.224/28broadcast: 10.49.49.239 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED [ 2007/06/09 15:47:17 INFO xorp_fea MFEA ] Interface added: Vif[register_vif] pif_index: 1 vif_index: 2 addr: 10.49.49.232 subnet: 10.49.49.232/32 broadcast: 10.49.49.232 peer: 0.0.0.0 Flags: PIM_REGISTER UNDERLYING_VIF_UP MTU: 1500 [ 2007/06/09 15:47:17 INFO xorp_fea MFEA ] Interface enabled Vif[eth1] pif_index: 2 vif_index: 1 addr: 10.49.49.222 subnet: 10.49.49.208/28broadcast: 10.49.49.223 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED [ 2007/06/09 15:47:17 INFO xorp_fea MFEA ] Interface started: Vif[eth1] pif_index: 2 vif_index: 1 addr: 10.49.49.222 subnet: 10.49.49.208/28broadcast: 10.49.49.223 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED [ 2007/06/09 15:47:17 INFO xorp_fea MFEA ] Interface enabled Vif[register_vif] pif_index: 1 vif_index: 2 addr: 10.49.49.232 subnet: 10.49.49.232/32 broadcast: 10.49.49.232 peer: 0.0.0.0 Flags: PIM_REGISTER UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED [ 2007/06/09 15:47:17 INFO xorp_fea MFEA ] Interface started: Vif[register_vif] pif_index: 1 vif_index: 2 addr: 10.49.49.232 subnet: 10.49.49.232/32 broadcast: 10.49.49.232 peer: 0.0.0.0 Flags: PIM_REGISTER UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED [ 2007/06/09 15:47:17 INFO xorp_rtrmgr:2521 RTRMGR +96 module_manager.cc execute ] Executing module: rib (rib/xorp_rib) [ 2007/06/09 15:47:19 INFO xorp_rtrmgr:2521 RTRMGR +96 module_manager.cc execute ] Executing module: fib2mrib (fib2mrib/xorp_fib2mrib) [ 2007/06/09 15:47:21 INFO xorp_rtrmgr:2521 RTRMGR +96 module_manager.cc execute ] Executing module: igmp (mld6igmp/xorp_igmp) [ 2007/06/09 15:47:21 WARNING xorp_rtrmgr:2521 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "IGMP" does not exist or is not enabled. [ 2007/06/09 15:47:21 INFO xorp_igmp MLD6IGMP ] Protocol enabled [ 2007/06/09 15:47:21 INFO xorp_igmp MLD6IGMP ] CLI enabled [ 2007/06/09 15:47:21 INFO xorp_igmp MLD6IGMP ] CLI started [ 2007/06/09 15:47:22 INFO xorp_igmp MLD6IGMP ] Protocol started [ 2007/06/09 15:47:22 INFO xorp_igmp MLD6IGMP ] Interface added: Vif[eth0] pif_index: 1 vif_index: 0 addr: 10.49.49.232 subnet: 10.49.49.224/28broadcast: 10.49.49.239 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 [ 2007/06/09 15:47:22 INFO xorp_igmp MLD6IGMP ] Interface added: Vif[eth1] pif_index: 2 vif_index: 1 addr: 10.49.49.222 subnet: 10.49.49.208/28broadcast: 10.49.49.223 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 [ 2007/06/09 15:47:23 INFO xorp_igmp MLD6IGMP ] Interface enabled: Vif[eth0] pif_index: 1 vif_index: 0 addr: 10.49.49.232 subnet: 10.49.49.224/28broadcast: 10.49.49.239 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED [ 2007/06/09 15:47:23 INFO xorp_igmp MLD6IGMP ] Interface started: Vif[eth0] pif_index: 1 vif_index: 0 addr: 10.49.49.232 subnet: 10.49.49.224/28broadcast: 10.49.49.239 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED [ 2007/06/09 15:47:23 INFO xorp_igmp MLD6IGMP ] Interface enabled: Vif[eth1] pif_index: 2 vif_index: 1 addr: 10.49.49.222 subnet: 10.49.49.208/28broadcast: 10.49.49.223 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED [ 2007/06/09 15:47:23 INFO xorp_igmp MLD6IGMP ] Interface started: Vif[eth1] pif_index: 2 vif_index: 1 addr: 10.49.49.222 subnet: 10.49.49.208/28broadcast: 10.49.49.223 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED [ 2007/06/09 15:47:23 INFO xorp_rtrmgr:2521 RTRMGR +96 module_manager.cc execute ] Executing module: pimsm4 (pim/xorp_pimsm4) [ 2007/06/09 15:47:23 WARNING xorp_rtrmgr:2521 XrlFinderTarget +406 ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "PIMSM_4" does not exist or is not enabled. [ 2007/06/09 15:47:23 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V3_MEMBERSHIP_REPORT from 10.49.49.232 to 224.0.0.22 on vif eth0 [ 2007/06/09 15:47:23 TRACE xorp_igmp MLD6IGMP ] Notify routing add membership for ( 0.0.0.0, 224.0.0.22 ) on vif eth0 [ 2007/06/09 15:47:23 TRACE xorp_igmp MLD6IGMP ] Notify routing add membership for (0.0.0.0, 224.0.0.2) on vif eth0 [ 2007/06/09 15:47:23 TRACE xorp_igmp MLD6IGMP ] RX IGMP_MEMBERSHIP_QUERY from 10.49.49.232 to 224.0.0.1 on vif eth0 [ 2007/06/09 15:47:23 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 10.49.49.222 to 224.0.0.2 on vif eth1 [ 2007/06/09 15:47:23 TRACE xorp_igmp MLD6IGMP ] Notify routing add membership for (0.0.0.0 , 224.0.0.2) on vif eth1 [ 2007/06/09 15:47:23 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 10.49.49.222 to 224.0.0.22 on vif eth1 [ 2007/06/09 15:47:23 TRACE xorp_igmp MLD6IGMP ] Notify routing add membership for (0.0.0.0 , 224.0.0.22) on vif eth1 [ 2007/06/09 15:47:23 TRACE xorp_igmp MLD6IGMP ] RX IGMP_MEMBERSHIP_QUERY from 10.49.49.222 to 224.0.0.1 on vif eth1 [ 2007/06/09 15:47:23 INFO xorp_pimsm4 PIM ] Protocol enabled [ 2007/06/09 15:47:23 INFO xorp_pimsm4 PIM ] CLI enabled [ 2007/06/09 15:47:23 INFO xorp_pimsm4 PIM ] CLI started [ 2007/06/09 15:47:23 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 10.49.49.222 to 224.0.0.2 on vif eth1 [ 2007/06/09 15:47:23 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V3_MEMBERSHIP_REPORT from 10.49.49.232 to 224.0.0.22 on vif eth0 [ 2007/06/09 15:47:24 INFO xorp_pimsm4 PIM ] Protocol started [ 2007/06/09 15:47:24 INFO xorp_pimsm4 PIM ] Interface added: Vif[eth0] pif_index: 1 vif_index: 0 addr: 10.49.49.232 subnet: 10.49.49.224/28broadcast: 10.49.49.239 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 [ 2007/06/09 15:47:24 INFO xorp_pimsm4 PIM ] Interface added: Vif[eth1] pif_index: 2 vif_index: 1 addr: 10.49.49.222 subnet: 10.49.49.208/28broadcast: 10.49.49.223 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 [ 2007/06/09 15:47:24 INFO xorp_pimsm4 PIM ] Interface added: Vif[register_vif] pif_index: 1 vif_index: 2 addr: 10.49.49.232 subnet: 10.49.49.232/32 broadcast: 0.0.0.0 peer: 0.0.0.0 Flags: PIM_REGISTER UNDERLYING_VIF_UP MTU: 1500 [ 2007/06/09 15:47:25 INFO xorp_pimsm4 PIM ] Interface enabled: Vif[eth0] pif_index: 1 vif_index: 0 addr: 10.49.49.232 subnet: 10.49.49.224/28broadcast: 10.49.49.239 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED [ 2007/06/09 15:47:25 INFO xorp_pimsm4 PIM ] Interface started: Vif[eth0] pif_index: 1 vif_index: 0 addr: 10.49.49.232 subnet: 10.49.49.224/28broadcast: 10.49.49.239 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED [ 2007/06/09 15:47:25 INFO xorp_pimsm4 PIM ] Interface enabled: Vif[eth1] pif_index: 2 vif_index: 1 addr: 10.49.49.222 subnet: 10.49.49.208/28broadcast: 10.49.49.223 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED [ 2007/06/09 15:47:25 INFO xorp_pimsm4 PIM ] Interface started: Vif[eth1] pif_index: 2 vif_index: 1 addr: 10.49.49.222 subnet: 10.49.49.208/28broadcast: 10.49.49.223 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED [ 2007/06/09 15:47:25 INFO xorp_pimsm4 PIM ] Interface enabled: Vif[register_vif] pif_index: 1 vif_index: 2 addr: 10.49.49.232 subnet: 10.49.49.232/32 broadcast: 0.0.0.0 peer: 0.0.0.0 Flags: PIM_REGISTER UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED [ 2007/06/09 15:47:25 INFO xorp_pimsm4 PIM ] Interface started: Vif[register_vif] pif_index: 1 vif_index: 2 addr: 10.49.49.232 subnet: 10.49.49.232/32 broadcast: 0.0.0.0 peer: 0.0.0.0 Flags: PIM_REGISTER UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED [ 2007/06/09 15:47:25 INFO xorp_rtrmgr:2521 RTRMGR +96 module_manager.cc execute ] Executing module: policy (policy/xorp_policy) [ 2007/06/09 15:47:25 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V3_MEMBERSHIP_REPORT from 10.49.49.232 to 224.0.0.22 on vif eth0 [ 2007/06/09 15:47:25 TRACE xorp_igmp MLD6IGMP ] Notify routing add membership for ( 0.0.0.0, 224.0.0.13 ) on vif eth0 [ 2007/06/09 15:47:25 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 10.49.49.222 to 224.0.0.13 on vif eth1 [ 2007/06/09 15:47:25 TRACE xorp_igmp MLD6IGMP ] Notify routing add membership for ( 0.0.0.0, 224.0.0.13 ) on vif eth1 [ 2007/06/09 15:47:26 TRACE xorp_pimsm4 PIM ] RX PIM_HELLO from 10.49.49.211to 224.0.0.13 on vif eth1 [ 2007/06/09 15:47:26 TRACE xorp_pimsm4 PIM ] Added new neighbor 10.49.49.211 on vif eth1 [ 2007/06/09 15:47:26 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 10.49.49.232to 224.0.0.13 on vif eth0 [ 2007/06/09 15:47:27 INFO xorp_rtrmgr:2521 RTRMGR +96 module_manager.cc execute ] Executing module: static_routes (static_routes/xorp_static_routes) [ 2007/06/09 15:47:29 INFO xorp_rtrmgr:2521 RTRMGR +2228 task.cc run_task ] No more tasks to run [ 2007/06/09 15:47:29 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 10.49.49.222to 224.0.0.13 on vif eth1 [ 2007/06/09 15:47:29 TRACE xorp_pimsm4 PIM ] RX PIM_HELLO from 10.49.49.211to 224.0.0.13 on vif eth1 [ 2007/06/09 15:47:29 TRACE xorp_pimsm4 PIM ] RX PIM_HELLO from 10.49.49.210to 224.0.0.13 on vif eth1 [ 2007/06/09 15:47:29 TRACE xorp_pimsm4 PIM ] Added new neighbor 10.49.49.210 on vif eth1 [ 2007/06/09 15:47:30 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 10.49.49.222 to 224.0.0.13 on vif eth1 [ 2007/06/09 15:47:31 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V3_MEMBERSHIP_REPORT from 10.49.49.232 to 224.0.0.22 on vif eth0 [ 2007/06/09 15:47:31 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 10.49.49.222 to 224.0.0.13 on vif eth1 [ 2007/06/09 15:47:31 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 10.49.49.222 to 224.0.0.22 on vif eth1 [ 2007/06/09 15:47:31 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 10.49.49.210 to 224.0.1.40 on vif eth1 [ 2007/06/09 15:47:31 TRACE xorp_igmp MLD6IGMP ] Notify routing add membership for ( 0.0.0.0, 224.0.1.40 ) on vif eth1 [ 2007/06/09 15:47:31 TRACE xorp_pimsm4 PIM ] Add membership for (0.0.0.0, 224.0.1.40) on vif eth1 [ 2007/06/09 15:47:31 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 10.49.49.222to 224.0.0.13 on vif eth1 [ 2007/06/09 15:47:31 TRACE xorp_pimsm4 PIM ] TX PIM_JOIN_PRUNE from 10.49.49.222 to 224.0.0.13 on vif eth1 [ 2007/06/09 15:47:44 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 1 vif_index = 0 src = 10.49.49.230 dst = 233.76.146.4 [ 2007/06/09 15:47:44 TRACE xorp_pimsm4 PIM ] RX NOCACHE signal from MFEA_4: vif_index = 0 src = 10.49.49.230 dst = 233.76.146.4 [ 2007/06/09 15:47:44 TRACE xorp_pimsm4 PIM ] Add MFC entry: ( 10.49.49.230, 233.76.146.4) iif = 0 olist = ..O olist_disable_wrongvif = OO. [ 2007/06/09 15:47:44 TRACE xorp_pimsm4 PIM ] Add dataflow monitor: source = 10.49.49.230 group = 233.76.146.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 [ 2007/06/09 15:47:44 TRACE xorp_fea MFEA ] Add MFC entry: (10.49.49.230, 233.76.146.4) iif = 0 olist = ..O [ 2007/06/09 15:47:44 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 3 vif_index = 2 src = 10.49.49.230 dst = 233.76.146.4 [ 2007/06/09 15:47:44 TRACE xorp_pimsm4 PIM ] RX WHOLEPKT signal from MFEA_4: vif_index = 2 src = 10.49.49.230 dst = 233.76.146.4 len = 43 [ 2007/06/09 15:47:44 TRACE xorp_pimsm4 PIM ] TX PIM_REGISTER from 10.49.49.222 to 10.48.254.14 on vif eth1 [ 2007/06/09 15:47:46 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 3 vif_index = 2 src = 10.49.49.230 dst = 233.76.146.4 [ 2007/06/09 15:47:46 TRACE xorp_pimsm4 PIM ] RX WHOLEPKT signal from MFEA_4: vif_index = 2 src = 10.49.49.230 dst = 233.76.146.4 len = 43 [ 2007/06/09 15:47:46 TRACE xorp_pimsm4 PIM ] TX PIM_REGISTER from 10.49.49.222 to 10.48.254.14 on vif eth1 [ 2007/06/09 15:47:54 TRACE xorp_igmp MLD6IGMP ] TX IGMP_MEMBERSHIP_QUERY from 10.49.49.232 to 224.0.0.1 [ 2007/06/09 15:47:54 TRACE xorp_igmp MLD6IGMP ] RX IGMP_MEMBERSHIP_QUERY from 10.49.49.232 to 224.0.0.1 on vif eth0 [ 2007/06/09 15:47:54 TRACE xorp_igmp MLD6IGMP ] TX IGMP_MEMBERSHIP_QUERY from 10.49.49.222 to 224.0.0.1 [ 2007/06/09 15:47:54 TRACE xorp_igmp MLD6IGMP ] RX IGMP_MEMBERSHIP_QUERY from 10.49.49.222 to 224.0.0.1 on vif eth1 [ 2007/06/09 15:47:55 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 10.49.49.222 to 224.0.0.13 on vif eth1 [ 2007/06/09 15:47:56 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 10.49.49.232to 224.0.0.13 on vif eth0 [ 2007/06/09 15:47:57 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 10.49.49.222 to 224.0.0.2 on vif eth1 [ 2007/06/09 15:47:58 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V3_MEMBERSHIP_REPORT from 10.49.49.232 to 224.0.0.22 on vif eth0 [ 2007/06/09 15:47:59 TRACE xorp_pimsm4 PIM ] RX PIM_HELLO from 10.49.49.210to 224.0.0.13 on vif eth1 [ 2007/06/09 15:47:59 TRACE xorp_pimsm4 PIM ] RX PIM_HELLO from 10.49.49.211to 224.0.0.13 on vif eth1 [ 2007/06/09 15:47:59 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 10.49.49.222to 224.0.0.13 on vif eth1 [ 2007/06/09 15:48:00 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 10.49.49.210 to 224.0.1.40 on vif eth1 [ 2007/06/09 15:48:00 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 10.49.49.222 to 224.0.0.22 on vif eth1 [ 2007/06/09 15:48:26 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 10.49.49.232to 224.0.0.13 on vif eth0 [ 2007/06/09 15:48:28 TRACE xorp_pimsm4 PIM ] RX PIM_HELLO from 10.49.49.210to 224.0.0.13 on vif eth1 [ 2007/06/09 15:48:29 TRACE xorp_pimsm4 PIM ] RX PIM_HELLO from 10.49.49.211to 224.0.0.13 on vif eth1 [ 2007/06/09 15:48:29 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 10.49.49.222to 224.0.0.13 on vif eth1 [ 2007/06/09 15:48:31 TRACE xorp_pimsm4 PIM ] TX PIM_JOIN_PRUNE from 10.49.49.222 to 224.0.0.13 on vif eth1 [ 2007/06/09 15:48:56 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 10.49.49.232to 224.0.0.13 on vif eth0 [ 2007/06/09 15:48:57 TRACE xorp_igmp MLD6IGMP ] RX IGMP_MEMBERSHIP_QUERY from 10.49.49.210 to 224.0.0.1 on vif eth1 [ 2007/06/09 15:48:58 TRACE xorp_pimsm4 PIM ] RX PIM_HELLO from 10.49.49.211to 224.0.0.13 on vif eth1 [ 2007/06/09 15:48:58 TRACE xorp_pimsm4 PIM ] RX PIM_HELLO from 10.49.49.210to 224.0.0.13 on vif eth1 [ 2007/06/09 15:48:58 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 10.49.49.222 to 224.0.0.13 on vif eth1 [ 2007/06/09 15:48:59 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 10.49.49.222to 224.0.0.13 on vif eth1 [ 2007/06/09 15:49:04 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 10.49.49.222 to 224.0.0.2 on vif eth1 [ 2007/06/09 15:49:05 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 10.49.49.210 to 224.0.1.40 on vif eth1 [ 2007/06/09 15:49:07 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT from 10.49.49.222 to 224.0.0.22 on vif eth1 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070609/f86b6b5c/attachment-0001.html From pavlin at icir.org Mon Jun 11 15:18:48 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Mon, 11 Jun 2007 15:18:48 -0700 Subject: [Xorp-users] multicast routing and pim-sm on linux 2.6 problems In-Reply-To: Message from "matt bernstein" of "Sat, 09 Jun 2007 18:25:00 EDT." <5b7195810706091525r30e2fbc2y8f36aedd87323bff@mail.gmail.com> Message-ID: <200706112218.l5BMImWf014126@possum.icir.org> matt bernstein wrote: > Hi guys, > > I've been desperately trying to get multicast routing working with kernel > 2.6 and pim-sm but to no avail. I'm trying to become a listener on an > internal multicast feed but striking out. I am currently using xorp cvs, and > any help is greatly appreciated. When exactly did you checkout the XORP-CVS code? During recent FEA refactoring there was a window of time when the IGMP support on Linux was broken, but this was fixed around June 1. Make sure that you get the latest XORP CVS code as of today and see whether "show igmp group" will show that host A is a receiver for group 233.76.146.4 on eth0. If you still cannot see it, then run tcpdump on eth0 and make sure that the host is indeed sending IGMP Join messages for group 233.76.146.4. Regards, Pavlin > Details of my configuration are as follows. > > Topology > > [host A 10.49.49.230/28] -- 10.49.49.232/28 [ host B xorp router ] > 10.49.49.222/28 -- 10.49.49.210/211 [ cisco hsrp router] -- multicast > networks > > > > Host A is trying to subscribe and recieve data from multicast group > 233.76.146.4 > > RP for the network is 10.48.254.14 via 10.49.49.210/211 > real sources servers are 10.49.48.128/27 via 10.49.49.210/211 > > my routes go to the real ips, not the hsrp ips. > > As far as I can tell host A is running igmp v3 on interface eth0 so I > matched igmp v3 on host B eth0. I can see igmp messages being exchanged > between the hosts. Although in the output below the multicast group does not > show up in the igmp groups. > > If i run multicast client/server on host A and host B on the same network > they can communicate. > > Any help is appreciated, thanks. > > The following output is generated by xorp on multicast join from host A, > emcast 233.76.146.4 > > > > show pim join > Group Source RP Flags > 224.0.1.40 0.0.0.0 10.48.254.14 WC > Upstream interface (RP): eth1 > Upstream MRIB next hop (RP): 10.49.49.211 > Upstream RPF'(*,G): 10.49.49.211 > Upstream state: Joined > Join timer: 13 > Local receiver include WC: .O. > Joins RP: ... > Joins WC: ... > Join state: ... > Prune state: ... > Prune pending state: ... > I am assert winner state: ... > I am assert loser state: ... > Assert winner WC: ... > Assert lost WC: ... > Assert tracking WC: .O. > Could assert WC: ... > I am DR: OOO > Immediate olist RP: ... > Immediate olist WC: .O. > Inherited olist SG: .O. > Inherited olist SG_RPT: .O. > PIM include WC: .O. > 233.76.146.4 10.49.49.230 10.48.254.14 SG SPT DirectlyConnectedS > Upstream interface (S): eth0 > Upstream interface (RP): eth1 > Upstream MRIB next hop (RP): 10.49.49.211 > Upstream MRIB next hop (S): UNKNOWN > Upstream RPF'(S,G): UNKNOWN > Upstream state: Joined > Register state: RegisterJoin RegisterCouldRegister > Join timer: 6 > KAT(S,G) running: true > Local receiver include WC: ... > Local receiver include SG: ... > Local receiver exclude SG: ... > Joins RP: ... > Joins WC: ... > Joins SG: ..O > Join state: ..O > Prune state: ... > Prune pending state: ... > I am assert winner state: ... > I am assert loser state: ... > Assert winner WC: ... > Assert winner SG: ... > Assert lost WC: ... > Assert lost SG: ... > Assert lost SG_RPT: ... > Assert tracking SG: O.O > Could assert WC: ... > Could assert SG: ..O > I am DR: OOO > Immediate olist RP: ... > Immediate olist WC: ... > Immediate olist SG: ..O > Inherited olist SG: ..O > Inherited olist SG_RPT: ... > PIM include WC: ... > PIM include SG: ... > PIM exclude SG: ... > > > show pim mfc > Group Source RP > 233.76.146.4 10.49.49.230 10.48.254.14 > Incoming interface : eth0 > Outgoing interfaces: ..O > > show pim neighbors > Interface DRpriority NeighborAddr V Mode Holdtime Timeout > eth1 1 10.49.49.210 2 Sparse 105 80 > eth1 1 10.49.49.211 2 Sparse 105 81 > > show igmp group > Interface Group Source LastReported Timeout V State > eth0 224.0.0.2 0.0.0.0 10.49.49.232 151 3 E > eth0 224.0.0.13 0.0.0.0 10.49.49.232 151 3 E > eth0 224.0.0.22 0.0.0.0 10.49.49.232 151 3 E > eth1 224.0.0.2 0.0.0.0 10.49.49.222 221 2 E > eth1 224.0.0.13 0.0.0.0 10.49.49.222 225 2 E > eth1 224.0.0.22 0.0.0.0 10.49.49.222 222 2 E > eth1 224.0.1.40 0.0.0.0 10.49.49.210 230 2 E > > cat ip_mr_cache > Group Origin Iif Pkts Bytes Wrong Oifs > 04924CE9 E631310A 0 2 66 0 2:1 > > cat ip_mr_vif > Interface BytesIn PktsIn BytesOut PktsOut Flags Local Remote > 0 eth0 355 11 0 0 00000 E831310A 00000000 > 1 eth1 64 2 161 5 00000 DE31310A 00000000 > 2 pimreg 0 0 355 11 00004 E831310A 00000000 > > rp_filter is 0 > mc_forwarding is 1 > ip_forwardig is 1 > > static routes exist to the RP / source subnets > 224 subnet on eth0 > > Xorp is configured on host B as follows: > > interfaces { > restore-original-config-on-shutdown: false > interface eth0 { > description: "manage interface" > disable: false > default-system-config > } > > interface eth1 { > description: "data interface" > disable: false > default-system-config > } > } > > > fea { > unicast-forwarding4 { > disable: 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 { > static { > mrib-route 10.49.48.128/27 { > next-hop: 10.49.49.210 > metric: 1 > } > mrib-route 10.49.48.128/27 { > next-hop: 10.49.49.211 > metric: 2 > } > > mrib-route 10.48.254.14/32 { > next-hop: 10.49.49.210 > metric: 1 > } > mrib-route 10.48.254.14/32 { > next-hop: 10.49.49.211 > metric: 2 > } > > } > } > > > protocols { > igmp { > disable: false > interface eth0 { > vif eth0 { > disable: false > version: 3 > } > } > interface eth1 { > vif eth1 { > disable: false > version: 2 > } > } > traceoptions { > flag all { > disable: false > } > } > } > } > > protocols { > pimsm4 { > disable: false > interface eth0 { > vif eth0 { > disable: false > } > } > interface eth1 { > vif eth1 { > disable: false > /* enable-ip-router-alert-option-check: false */ > /* dr-priority: 1 */ > /* hello-period: 30 */ > /* hello-triggered-delay: 5 */ > /* alternative-subnet 10.49.48.128/27 */ > } > } > interface register_vif { > vif register_vif { > /* Note: this vif should be always enabled */ > disable: false > } > } > > static-rps { > rp 10.48.254.14 { > group-prefix 224.0.0.0/4 { > rp-priority: 1 > /* hash-mask-len: 30 */ > } > } > } > > > switch-to-spt-threshold { > /* approx. 1K bytes/s (10Kbps) threshold */ > disable: false > interval: 100 > bytes: 102400 > } > > traceoptions { > flag all { > disable: false > } > } > } > > } > > protocols { > fib2mrib { > disable: false > } > } > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From sd88 at drexel.edu Tue Jun 19 09:57:07 2007 From: sd88 at drexel.edu (Sukrit Dasgupta) Date: Tue, 19 Jun 2007 12:57:07 -0400 Subject: [Xorp-users] Compiling Problem Sun Blade 150+Ubuntu 7.04 Server Message-ID: <0A3CD9F5-A9B6-4C15-BC7A-C0237A970A75@drexel.edu> Hi , I am trying to compile XORP on a Sun Blade running Ubuntu 7.04 and am running into the following error --------------------------------------------- make[3]: Entering directory `/home/sukrit/xorp-1.3/libxorp' source='ipv4.cc' object='ipv4.lo' libtool=yes \ depfile='.deps/ipv4.Plo' tmpdepfile='.deps/ipv4.TPlo' \ depmode=gcc3 /bin/bash ../config/depcomp \ /bin/bash ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. - I. -I.. -I.. -g -W -Wall -Wwrite-strings -Wcast-qual -Werror - Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 - pipe -c -o ipv4.lo `test -f ipv4.cc || echo './'`ipv4.cc g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings - Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual - ftemplate-depth-25 -pipe -c ipv4.cc -MT ipv4.lo -MD -MP -MF .deps/ ipv4.TPlo -o ipv4.o cc1plus: warnings being treated as errors ipv4.cc: In constructor 'IPv4::IPv4(const sockaddr&)': ipv4.cc:50: warning: cast from 'const sockaddr*' to 'const sockaddr_in*' increases required alignment of target type ipv4.cc: In member function 'size_t IPv4::copy_out(sockaddr&) const': ipv4.cc:98: warning: cast from 'sockaddr*' to 'sockaddr_in*' increases required alignment of target type ipv4.cc: In member function 'size_t IPv4::copy_in(const sockaddr&)': ipv4.cc:146: warning: cast from 'const sockaddr*' to 'const sockaddr_in*' increases required alignment of target type make[3]: *** [ipv4.lo] Error 1 make[3]: Leaving directory `/home/sukrit/xorp-1.3/libxorp' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/sukrit/xorp-1.3/libxorp' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/sukrit/xorp-1.3' make: *** [all] Error 2 --------------------------------------------- Scanning the mailing list showed that this was a problem a long time ago because of old GCC. I am running 4.1.2 on Ubuntu. Also, if it is of any significance. I successfully compiled XORP on Fedora 6 using GCC 4.1.1. Seem to be stuck in a corner here and I really need to get XORP up on the Sun. Or move to Quagga :-( (Which I dont want to) Regards, Sukrit From pavlin at icir.org Tue Jun 19 10:55:44 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 19 Jun 2007 10:55:44 -0700 Subject: [Xorp-users] Compiling Problem Sun Blade 150+Ubuntu 7.04 Server In-Reply-To: Message from Sukrit Dasgupta of "Tue, 19 Jun 2007 12:57:07 EDT." <0A3CD9F5-A9B6-4C15-BC7A-C0237A970A75@drexel.edu> Message-ID: <200706191755.l5JHtiOw075498@possum.icir.org> > I am trying to compile XORP on a Sun Blade running Ubuntu 7.04 and am > running into the following error It seems like you are using XORP-1.3 which is a bit out of date. Version 1.4 contains a number of alignment related fixes which fixes the particular problem shown below. However, on Ubuntu 7.04 specifically there was a small compilation issue related to its header files. The issue was fixed few days ago in XORP CVS. Hence I would recommend that you use the latest XORP code from CVS. The following URL contains instructions how to get the code using anon. CVS: http://www.xorp.org/cvs.html If it doesn't compile for you then please let us know and we will try to fix the problem. Regards, Pavlin > --------------------------------------------- > > make[3]: Entering directory `/home/sukrit/xorp-1.3/libxorp' > source='ipv4.cc' object='ipv4.lo' libtool=yes \ > depfile='.deps/ipv4.Plo' tmpdepfile='.deps/ipv4.TPlo' \ > depmode=gcc3 /bin/bash ../config/depcomp \ > /bin/bash ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. - > I. -I.. -I.. -g -W -Wall -Wwrite-strings -Wcast-qual -Werror - > Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 - > pipe -c -o ipv4.lo `test -f ipv4.cc || echo './'`ipv4.cc > g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings - > Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded-virtual - > ftemplate-depth-25 -pipe -c ipv4.cc -MT ipv4.lo -MD -MP -MF .deps/ > ipv4.TPlo -o ipv4.o > cc1plus: warnings being treated as errors > ipv4.cc: In constructor 'IPv4::IPv4(const sockaddr&)': > ipv4.cc:50: warning: cast from 'const sockaddr*' to 'const > sockaddr_in*' increases required alignment of target type > ipv4.cc: In member function 'size_t IPv4::copy_out(sockaddr&) const': > ipv4.cc:98: warning: cast from 'sockaddr*' to 'sockaddr_in*' > increases required alignment of target type > ipv4.cc: In member function 'size_t IPv4::copy_in(const sockaddr&)': > ipv4.cc:146: warning: cast from 'const sockaddr*' to 'const > sockaddr_in*' increases required alignment of target type > make[3]: *** [ipv4.lo] Error 1 > make[3]: Leaving directory `/home/sukrit/xorp-1.3/libxorp' > make[2]: *** [all] Error 2 > make[2]: Leaving directory `/home/sukrit/xorp-1.3/libxorp' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/sukrit/xorp-1.3' > make: *** [all] Error 2 > > --------------------------------------------- > > Scanning the mailing list showed that this was a problem a long time > ago because of old GCC. I am running 4.1.2 on Ubuntu. > Also, if it is of any significance. I successfully compiled XORP on > Fedora 6 using GCC 4.1.1. > > Seem to be stuck in a corner here and I really need to get XORP up on > the Sun. Or move to Quagga :-( (Which I dont want to) > > > Regards, > Sukrit > > > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From sd88 at drexel.edu Tue Jun 19 17:20:42 2007 From: sd88 at drexel.edu (Sukrit Dasgupta) Date: Tue, 19 Jun 2007 20:20:42 -0400 Subject: [Xorp-users] Compiling Problem Sun Blade 150+Ubuntu 7.04 Server In-Reply-To: <200706191755.l5JHtiOw075498@possum.icir.org> References: <200706191755.l5JHtiOw075498@possum.icir.org> Message-ID: <085BD5C9-0B55-4715-87F1-421F82610ECE@drexel.edu> Hi Pavlin, Thanks for the help, still getting stuck though. Got the latest code off the CVS. Getting the same error: ------------------------------- make all-recursive make[1]: Entering directory `/root/xorp' Making all in libxorp make[2]: Entering directory `/root/xorp/libxorp' make all-am make[3]: Entering directory `/root/xorp/libxorp' /bin/bash ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H - I. -I.. -I.. -g -Werror -W -Wall -Wwrite-strings -Wcast-qual - Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 - pipe -MT ipv4.lo -MD -MP -MF .deps/ipv4.Tpo -c -o ipv4.lo ipv4.cc g++ -DHAVE_CONFIG_H -I. -I.. -I.. -g -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual - ftemplate-depth-25 -pipe -MT ipv4.lo -MD -MP -MF .deps/ipv4.Tpo -c ipv4.cc -o ipv4.o cc1plus: warnings being treated as errors ipv4.cc: In constructor 'IPv4::IPv4(const sockaddr&)': ipv4.cc:48: warning: cast from 'const sockaddr*' to 'const sockaddr_in*' increases required alignment of target type ipv4.cc: In member function 'size_t IPv4::copy_out(sockaddr&) const': ipv4.cc:96: warning: cast from 'sockaddr*' to 'sockaddr_in*' increases required alignment of target type ipv4.cc: In member function 'size_t IPv4::copy_in(const sockaddr&)': ipv4.cc:144: warning: cast from 'const sockaddr*' to 'const sockaddr_in*' increases required alignment of target type make[3]: *** [ipv4.lo] Error 1 make[3]: Leaving directory `/root/xorp/libxorp' make[2]: *** [all] Error 2 make[2]: Leaving directory `/root/xorp/libxorp' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/xorp' make: *** [all] Error 2 ------------------------------- Again, thanks a lot for your time. Regards, Sukrit On Jun 19, 2007, at 1:55 PM, Pavlin Radoslavov wrote: >> I am trying to compile XORP on a Sun Blade running Ubuntu 7.04 and am >> running into the following error > > It seems like you are using XORP-1.3 which is a bit out of date. > Version 1.4 contains a number of alignment related fixes which > fixes the particular problem shown below. > > However, on Ubuntu 7.04 specifically there was a small compilation > issue related to its header files. The issue was fixed few days ago > in XORP CVS. > > Hence I would recommend that you use the latest XORP code from CVS. > The following URL contains instructions how to get the code using > anon. CVS: > > http://www.xorp.org/cvs.html > > If it doesn't compile for you then please let us know and we will > try to fix the problem. > > Regards, > Pavlin > >> --------------------------------------------- >> >> make[3]: Entering directory `/home/sukrit/xorp-1.3/libxorp' >> source='ipv4.cc' object='ipv4.lo' libtool=yes \ >> depfile='.deps/ipv4.Plo' tmpdepfile='.deps/ipv4.TPlo' \ >> depmode=gcc3 /bin/bash ../config/depcomp \ >> /bin/bash ../libtool --mode=compile g++ -DHAVE_CONFIG_H - >> I. - >> I. -I.. -I.. -g -W -Wall -Wwrite-strings -Wcast-qual -Werror - >> Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate- >> depth-25 - >> pipe -c -o ipv4.lo `test -f ipv4.cc || echo './'`ipv4.cc >> g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings - >> Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded- >> virtual - >> ftemplate-depth-25 -pipe -c ipv4.cc -MT ipv4.lo -MD -MP -MF .deps/ >> ipv4.TPlo -o ipv4.o >> cc1plus: warnings being treated as errors >> ipv4.cc: In constructor 'IPv4::IPv4(const sockaddr&)': >> ipv4.cc:50: warning: cast from 'const sockaddr*' to 'const >> sockaddr_in*' increases required alignment of target type >> ipv4.cc: In member function 'size_t IPv4::copy_out(sockaddr&) const': >> ipv4.cc:98: warning: cast from 'sockaddr*' to 'sockaddr_in*' >> increases required alignment of target type >> ipv4.cc: In member function 'size_t IPv4::copy_in(const sockaddr&)': >> ipv4.cc:146: warning: cast from 'const sockaddr*' to 'const >> sockaddr_in*' increases required alignment of target type >> make[3]: *** [ipv4.lo] Error 1 >> make[3]: Leaving directory `/home/sukrit/xorp-1.3/libxorp' >> make[2]: *** [all] Error 2 >> make[2]: Leaving directory `/home/sukrit/xorp-1.3/libxorp' >> make[1]: *** [all-recursive] Error 1 >> make[1]: Leaving directory `/home/sukrit/xorp-1.3' >> make: *** [all] Error 2 >> >> --------------------------------------------- >> >> Scanning the mailing list showed that this was a problem a long time >> ago because of old GCC. I am running 4.1.2 on Ubuntu. >> Also, if it is of any significance. I successfully compiled XORP on >> Fedora 6 using GCC 4.1.1. >> >> Seem to be stuck in a corner here and I really need to get XORP up on >> the Sun. Or move to Quagga :-( (Which I dont want to) >> >> >> Regards, >> Sukrit >> >> >> >> >> _______________________________________________ >> Xorp-users mailing list >> Xorp-users at xorp.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at icir.org Tue Jun 19 23:39:52 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 19 Jun 2007 23:39:52 -0700 Subject: [Xorp-users] Compiling Problem Sun Blade 150+Ubuntu 7.04 Server In-Reply-To: Message from Sukrit Dasgupta of "Tue, 19 Jun 2007 20:20:42 EDT." <085BD5C9-0B55-4715-87F1-421F82610ECE@drexel.edu> Message-ID: <200706200639.l5K6dqHC001761@possum.icir.org> Sukrit Dasgupta wrote: > Hi Pavlin, > > Thanks for the help, still getting stuck though. Got the latest code > off the CVS. Getting the same error: Interesting. We have been using Gentoo 2006.1 on x86 with gcc-3.4.5 for cross compilation for various CPUs including sparc64, but so far we haven't seen this error. Would it be possible to get a temporary login account on that machine, because this would be the fastest way for us to investigate the problem and fix it. Otherwise we might have to do a number of email iterations asking you to try different things which could be too tedious. Thanks, Pavlin > ------------------------------- > > make all-recursive > make[1]: Entering directory `/root/xorp' > Making all in libxorp > make[2]: Entering directory `/root/xorp/libxorp' > make all-am > make[3]: Entering directory `/root/xorp/libxorp' > /bin/bash ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H - > I. -I.. -I.. -g -Werror -W -Wall -Wwrite-strings -Wcast-qual - > Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 - > pipe -MT ipv4.lo -MD -MP -MF .deps/ipv4.Tpo -c -o ipv4.lo ipv4.cc > g++ -DHAVE_CONFIG_H -I. -I.. -I.. -g -Werror -W -Wall -Wwrite-strings > -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual - > ftemplate-depth-25 -pipe -MT ipv4.lo -MD -MP -MF .deps/ipv4.Tpo -c > ipv4.cc -o ipv4.o > cc1plus: warnings being treated as errors > ipv4.cc: In constructor 'IPv4::IPv4(const sockaddr&)': > ipv4.cc:48: warning: cast from 'const sockaddr*' to 'const > sockaddr_in*' increases required alignment of target type > ipv4.cc: In member function 'size_t IPv4::copy_out(sockaddr&) const': > ipv4.cc:96: warning: cast from 'sockaddr*' to 'sockaddr_in*' > increases required alignment of target type > ipv4.cc: In member function 'size_t IPv4::copy_in(const sockaddr&)': > ipv4.cc:144: warning: cast from 'const sockaddr*' to 'const > sockaddr_in*' increases required alignment of target type > make[3]: *** [ipv4.lo] Error 1 > make[3]: Leaving directory `/root/xorp/libxorp' > make[2]: *** [all] Error 2 > make[2]: Leaving directory `/root/xorp/libxorp' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/root/xorp' > make: *** [all] Error 2 > > ------------------------------- > > > Again, thanks a lot for your time. > > Regards, > Sukrit > > > > On Jun 19, 2007, at 1:55 PM, Pavlin Radoslavov wrote: > > >> I am trying to compile XORP on a Sun Blade running Ubuntu 7.04 and am > >> running into the following error > > > > It seems like you are using XORP-1.3 which is a bit out of date. > > Version 1.4 contains a number of alignment related fixes which > > fixes the particular problem shown below. > > > > However, on Ubuntu 7.04 specifically there was a small compilation > > issue related to its header files. The issue was fixed few days ago > > in XORP CVS. > > > > Hence I would recommend that you use the latest XORP code from CVS. > > The following URL contains instructions how to get the code using > > anon. CVS: > > > > http://www.xorp.org/cvs.html > > > > If it doesn't compile for you then please let us know and we will > > try to fix the problem. > > > > Regards, > > Pavlin > > > >> --------------------------------------------- > >> > >> make[3]: Entering directory `/home/sukrit/xorp-1.3/libxorp' > >> source='ipv4.cc' object='ipv4.lo' libtool=yes \ > >> depfile='.deps/ipv4.Plo' tmpdepfile='.deps/ipv4.TPlo' \ > >> depmode=gcc3 /bin/bash ../config/depcomp \ > >> /bin/bash ../libtool --mode=compile g++ -DHAVE_CONFIG_H - > >> I. - > >> I. -I.. -I.. -g -W -Wall -Wwrite-strings -Wcast-qual -Werror - > >> Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate- > >> depth-25 - > >> pipe -c -o ipv4.lo `test -f ipv4.cc || echo './'`ipv4.cc > >> g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings - > >> Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded- > >> virtual - > >> ftemplate-depth-25 -pipe -c ipv4.cc -MT ipv4.lo -MD -MP -MF .deps/ > >> ipv4.TPlo -o ipv4.o > >> cc1plus: warnings being treated as errors > >> ipv4.cc: In constructor 'IPv4::IPv4(const sockaddr&)': > >> ipv4.cc:50: warning: cast from 'const sockaddr*' to 'const > >> sockaddr_in*' increases required alignment of target type > >> ipv4.cc: In member function 'size_t IPv4::copy_out(sockaddr&) const': > >> ipv4.cc:98: warning: cast from 'sockaddr*' to 'sockaddr_in*' > >> increases required alignment of target type > >> ipv4.cc: In member function 'size_t IPv4::copy_in(const sockaddr&)': > >> ipv4.cc:146: warning: cast from 'const sockaddr*' to 'const > >> sockaddr_in*' increases required alignment of target type > >> make[3]: *** [ipv4.lo] Error 1 > >> make[3]: Leaving directory `/home/sukrit/xorp-1.3/libxorp' > >> make[2]: *** [all] Error 2 > >> make[2]: Leaving directory `/home/sukrit/xorp-1.3/libxorp' > >> make[1]: *** [all-recursive] Error 1 > >> make[1]: Leaving directory `/home/sukrit/xorp-1.3' > >> make: *** [all] Error 2 > >> > >> --------------------------------------------- > >> > >> Scanning the mailing list showed that this was a problem a long time > >> ago because of old GCC. I am running 4.1.2 on Ubuntu. > >> Also, if it is of any significance. I successfully compiled XORP on > >> Fedora 6 using GCC 4.1.1. > >> > >> Seem to be stuck in a corner here and I really need to get XORP up on > >> the Sun. Or move to Quagga :-( (Which I dont want to) > >> > >> > >> Regards, > >> Sukrit > >> > >> > >> > >> > >> _______________________________________________ > >> Xorp-users mailing list > >> Xorp-users at xorp.org > >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at icir.org Thu Jun 21 01:50:31 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 21 Jun 2007 01:50:31 -0700 Subject: [Xorp-users] Compiling Problem Sun Blade 150+Ubuntu 7.04 Server In-Reply-To: Message from Pavlin Radoslavov of "Tue, 19 Jun 2007 23:39:52 PDT." <200706200639.l5K6dqHC001761@possum.icir.org> Message-ID: <200706210850.l5L8oVge081153@possum.icir.org> Pavlin Radoslavov wrote: > Sukrit Dasgupta wrote: > > > Hi Pavlin, > > > > Thanks for the help, still getting stuck though. Got the latest code > > off the CVS. Getting the same error: > > Interesting. > We have been using Gentoo 2006.1 on x86 with gcc-3.4.5 for cross > compilation for various CPUs including sparc64, but so far we > haven't seen this error. > > Would it be possible to get a temporary login account on that > machine, because this would be the fastest way for us to investigate > the problem and fix it. Thanks to the remote access from Sukrit now the problem is fixed in CVS. The issue was that the compiler was giving warnings in places that it shouldn't (or at least could be safely ignored). It seems that the warning is printed by the gcc-4.1.2 compiler that comes with the Ubuntu 7.0 distribution, but is not printed by the gcc-3.4.5 compiler we were using for the cross-compilation testing. Sigh, unfortunately it seems that the cross-toolchain fails to build gcc-4.x for sparc64: http://kegel.com/crosstool/crosstool-0.43/buildlogs/ Thank you Sukrit! Pavlin > Otherwise we might have to do a number of email iterations asking > you to try different things which could be too tedious. > > Thanks, > Pavlin > > > > ------------------------------- > > > > make all-recursive > > make[1]: Entering directory `/root/xorp' > > Making all in libxorp > > make[2]: Entering directory `/root/xorp/libxorp' > > make all-am > > make[3]: Entering directory `/root/xorp/libxorp' > > /bin/bash ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H - > > I. -I.. -I.. -g -Werror -W -Wall -Wwrite-strings -Wcast-qual - > > Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 - > > pipe -MT ipv4.lo -MD -MP -MF .deps/ipv4.Tpo -c -o ipv4.lo ipv4.cc > > g++ -DHAVE_CONFIG_H -I. -I.. -I.. -g -Werror -W -Wall -Wwrite-strings > > -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual - > > ftemplate-depth-25 -pipe -MT ipv4.lo -MD -MP -MF .deps/ipv4.Tpo -c > > ipv4.cc -o ipv4.o > > cc1plus: warnings being treated as errors > > ipv4.cc: In constructor 'IPv4::IPv4(const sockaddr&)': > > ipv4.cc:48: warning: cast from 'const sockaddr*' to 'const > > sockaddr_in*' increases required alignment of target type > > ipv4.cc: In member function 'size_t IPv4::copy_out(sockaddr&) const': > > ipv4.cc:96: warning: cast from 'sockaddr*' to 'sockaddr_in*' > > increases required alignment of target type > > ipv4.cc: In member function 'size_t IPv4::copy_in(const sockaddr&)': > > ipv4.cc:144: warning: cast from 'const sockaddr*' to 'const > > sockaddr_in*' increases required alignment of target type > > make[3]: *** [ipv4.lo] Error 1 > > make[3]: Leaving directory `/root/xorp/libxorp' > > make[2]: *** [all] Error 2 > > make[2]: Leaving directory `/root/xorp/libxorp' > > make[1]: *** [all-recursive] Error 1 > > make[1]: Leaving directory `/root/xorp' > > make: *** [all] Error 2 > > > > ------------------------------- > > > > > > Again, thanks a lot for your time. > > > > Regards, > > Sukrit > > > > > > > > On Jun 19, 2007, at 1:55 PM, Pavlin Radoslavov wrote: > > > > >> I am trying to compile XORP on a Sun Blade running Ubuntu 7.04 and am > > >> running into the following error > > > > > > It seems like you are using XORP-1.3 which is a bit out of date. > > > Version 1.4 contains a number of alignment related fixes which > > > fixes the particular problem shown below. > > > > > > However, on Ubuntu 7.04 specifically there was a small compilation > > > issue related to its header files. The issue was fixed few days ago > > > in XORP CVS. > > > > > > Hence I would recommend that you use the latest XORP code from CVS. > > > The following URL contains instructions how to get the code using > > > anon. CVS: > > > > > > http://www.xorp.org/cvs.html > > > > > > If it doesn't compile for you then please let us know and we will > > > try to fix the problem. > > > > > > Regards, > > > Pavlin > > > > > >> --------------------------------------------- > > >> > > >> make[3]: Entering directory `/home/sukrit/xorp-1.3/libxorp' > > >> source='ipv4.cc' object='ipv4.lo' libtool=yes \ > > >> depfile='.deps/ipv4.Plo' tmpdepfile='.deps/ipv4.TPlo' \ > > >> depmode=gcc3 /bin/bash ../config/depcomp \ > > >> /bin/bash ../libtool --mode=compile g++ -DHAVE_CONFIG_H - > > >> I. - > > >> I. -I.. -I.. -g -W -Wall -Wwrite-strings -Wcast-qual -Werror - > > >> Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate- > > >> depth-25 - > > >> pipe -c -o ipv4.lo `test -f ipv4.cc || echo './'`ipv4.cc > > >> g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -g -W -Wall -Wwrite-strings - > > >> Wcast-qual -Werror -Wpointer-arith -Wcast-align -Woverloaded- > > >> virtual - > > >> ftemplate-depth-25 -pipe -c ipv4.cc -MT ipv4.lo -MD -MP -MF .deps/ > > >> ipv4.TPlo -o ipv4.o > > >> cc1plus: warnings being treated as errors > > >> ipv4.cc: In constructor 'IPv4::IPv4(const sockaddr&)': > > >> ipv4.cc:50: warning: cast from 'const sockaddr*' to 'const > > >> sockaddr_in*' increases required alignment of target type > > >> ipv4.cc: In member function 'size_t IPv4::copy_out(sockaddr&) const': > > >> ipv4.cc:98: warning: cast from 'sockaddr*' to 'sockaddr_in*' > > >> increases required alignment of target type > > >> ipv4.cc: In member function 'size_t IPv4::copy_in(const sockaddr&)': > > >> ipv4.cc:146: warning: cast from 'const sockaddr*' to 'const > > >> sockaddr_in*' increases required alignment of target type > > >> make[3]: *** [ipv4.lo] Error 1 > > >> make[3]: Leaving directory `/home/sukrit/xorp-1.3/libxorp' > > >> make[2]: *** [all] Error 2 > > >> make[2]: Leaving directory `/home/sukrit/xorp-1.3/libxorp' > > >> make[1]: *** [all-recursive] Error 1 > > >> make[1]: Leaving directory `/home/sukrit/xorp-1.3' > > >> make: *** [all] Error 2 > > >> > > >> --------------------------------------------- > > >> > > >> Scanning the mailing list showed that this was a problem a long time > > >> ago because of old GCC. I am running 4.1.2 on Ubuntu. > > >> Also, if it is of any significance. I successfully compiled XORP on > > >> Fedora 6 using GCC 4.1.1. > > >> > > >> Seem to be stuck in a corner here and I really need to get XORP up on > > >> the Sun. Or move to Quagga :-( (Which I dont want to) > > >> > > >> > > >> Regards, > > >> Sukrit > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> Xorp-users mailing list > > >> Xorp-users at xorp.org > > >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > > > _______________________________________________ > > Xorp-users mailing list > > Xorp-users at xorp.org > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From sd88 at drexel.edu Thu Jun 21 10:07:10 2007 From: sd88 at drexel.edu (Sukrit Dasgupta) Date: Thu, 21 Jun 2007 13:07:10 -0400 Subject: [Xorp-users] Compiling Problem Sun Blade 150+Ubuntu 7.04 Server In-Reply-To: <200706210850.l5L8oVge081153@possum.icir.org> References: <200706210850.l5L8oVge081153@possum.icir.org> Message-ID: <69FF7986-F158-46F5-A5A8-1557C6751270@drexel.edu> Hi Pavlin > > Thanks to the remote access from Sukrit now the problem is fixed in > CVS. > The issue was that the compiler was giving warnings in places that > it shouldn't (or at least could be safely ignored). > > It seems that the warning is printed by the gcc-4.1.2 compiler > that comes with the Ubuntu 7.0 distribution, but is not printed by > the gcc-3.4.5 compiler we were using for the cross-compilation > testing. > Sigh, unfortunately it seems that the cross-toolchain fails to build > gcc-4.x for sparc64: > http://kegel.com/crosstool/crosstool-0.43/buildlogs/ > > Thank you Sukrit! > Thank you very very much. Compiled XORP successfully on three other Sun Blade 150s using the newest code from the CVS and everything works great! Regards, Sukrit From i at levsha.org.ua Sat Jun 23 05:54:37 2007 From: i at levsha.org.ua (Mykola Dzham) Date: Sat, 23 Jun 2007 15:54:37 +0300 Subject: [Xorp-users] update ospf database after policy change Message-ID: <20070623125436.GW83883@expo.ukrweb.net> When i change ospf export policy to "network, that rejected previously, now allow", then changes affect to ospf database immediately. But whe in change policy to "network, that accepted previously, now reject", then changes not affect to ospf database. Is it bug? Is it possible to apply changes without restarting xorp? xorp-1.4 , FreeBSD 6.2-RELEASE Here is a test: Start state: levsha at workstation.levsha.org.ua# run show route table ipv4 unicast final | match 192.168.15[56] 192.168.155.0/24 [connected(0)/0] 192.168.156.0/24 [connected(0)/0] levsha at workstation.levsha.org.ua# run show ospf4 database | match 192.168.15[56] ASExt-2 *192.168.156.0 192.168.0.50 0x80000001 69 0x2 0x3df3 36 levsha at workstation.levsha.org.ua# show protocols ospf4 export export: "to-ospf" [edit] levsha at workstation.levsha.org.ua# show policy policy-statement to-ospf term testnet { from { protocol: "connected" network4: 192.168.155.0/24 } then { reject { } } } term other { from { protocol: "connected" } then { accept { } } } [edit] change "network, that rejected previously,now allow": levsha at workstation.levsha.org.ua# delete policy policy-statement to-ospf term testnet Deleting: testnet { from { protocol: "connected" network4: 192.168.155.0/24 } then { reject { } } } OK [edit] levsha at workstation.levsha.org.ua# commit OK [edit] levsha at workstation.levsha.org.ua# run show ospf4 database | match 192.168.15[56] ASExt-2 *192.168.155.0 192.168.0.50 0x80000001 30 0x2 0x48e9 36 ASExt-2 *192.168.156.0 192.168.0.50 0x80000001 30 0x2 0x3df3 36 change "network, that accepted previously, now reject": levsha at workstation.levsha.org.ua# delete policy policy-statement to-ospf term other Deleting: other { from { protocol: "connected" } then { accept { } } } OK [edit] levsha at workstation.levsha.org.ua# set policy policy-statement to-ospf term rej { > from protocol connected > from network4 192.168.155.0/24 > then reject > } [edit] evsha at workstation.levsha.org.ua# set policy policy-statement to-ospf term acc { > from protocol connected > then accept > } [edit] levsha at workstation.levsha.org.ua# commit OK [edit] levsha at workstation.levsha.org.ua# run show ospf4 database | match 192.168.15[56] ASExt-2 *192.168.155.0 192.168.0.50 0x80000001 1769 0x2 0x48e9 36 ASExt-2 *192.168.156.0 192.168.0.50 0x80000001 1769 0x2 0x3df3 36 -- Mykola Dzham, LEFT-(UANIC|RIPE) JID: levsha at jabber.net.ua From salvador_d13 at yahoo.com.ph Wed Jun 20 06:08:50 2007 From: salvador_d13 at yahoo.com.ph (Diego Salvador) Date: Wed, 20 Jun 2007 06:08:50 -0700 (PDT) Subject: [Xorp-users] XORP and Virtual Routers Message-ID: <502915.8719.qm@web57413.mail.re1.yahoo.com> Hi! Is the XORP project has a plan of implementing virtual router functionality? This is the case wherein one physical XORP machine can simulate multiple virtual XORP machines intended for virtual networks. Thanks. Diego --------------------------------- Tired of spam? Yahoo! Mail has the best spam protection around http://ph.mail.yahoo.com --------------------------------- Tired of spam? Yahoo! Mail has the best spam protection around http://ph.mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070620/84025250/attachment.html From sd88 at drexel.edu Sat Jun 23 12:32:40 2007 From: sd88 at drexel.edu (Sukrit Dasgupta) Date: Sat, 23 Jun 2007 15:32:40 -0400 Subject: [Xorp-users] XORP and Virtual Routers In-Reply-To: <502915.8719.qm@web57413.mail.re1.yahoo.com> References: <502915.8719.qm@web57413.mail.re1.yahoo.com> Message-ID: Hi Diego, You could probably use UML (User Mode Linux) to do so, here is a (very) old link. http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2004-November/ 000278.html Also, there is a paper : http://www.sigcomm.org/sigcomm2006/discussion/showpaper.php?paper_id=1 Where UML is used to make virtual networks by running multiple XORP routers on one physical machine. Sukrit On Jun 20, 2007, at 9:08 AM, Diego Salvador wrote: > Hi! Is the XORP project has a plan of implementing virtual router > functionality? This is the case wherein one physical XORP machine > can simulate multiple virtual XORP machines intended for virtual > networks. > > Thanks. > > Diego > > Tired of spam? Yahoo! Mail has the best spam protection around > http://ph.mail.yahoo.com > > Tired of spam? Yahoo! Mail has the best spam protection around > http://ph.mail.yahoo.com > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070623/86f75af6/attachment.html From ian.chakeres at gmail.com Sat Jun 23 17:56:35 2007 From: ian.chakeres at gmail.com (Ian Chakeres) Date: Sun, 24 Jun 2007 06:26:35 +0530 Subject: [Xorp-users] XORP and Virtual Routers In-Reply-To: <502915.8719.qm@web57413.mail.re1.yahoo.com> References: <502915.8719.qm@web57413.mail.re1.yahoo.com> Message-ID: <374005f30706231756ya52ffe3yb54b7d6443017cd4@mail.gmail.com> I would highly recommend IMUNES. http://imunes-web.tel.fer.hr/ I'd also recommend using the vmware image. Ian On 6/20/07, Diego Salvador wrote: > Hi! Is the XORP project has a plan of implementing virtual router > functionality? This is the case wherein one physical XORP machine can > simulate multiple virtual XORP machines intended for virtual networks. > > Thanks. > > Diego > > > ________________________________ > Tired of spam? Yahoo! Mail has the best spam protection around > http://ph.mail.yahoo.com > > ________________________________ > Tired of spam? Yahoo! Mail has the best spam protection around > http://ph.mail.yahoo.com > > > > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > From pmancheno at gmail.com Sat Jun 23 21:50:56 2007 From: pmancheno at gmail.com (Pepo) Date: Sat, 23 Jun 2007 23:50:56 -0500 Subject: [Xorp-users] XORP and Virtual Routers In-Reply-To: <502915.8719.qm@web57413.mail.re1.yahoo.com> References: <502915.8719.qm@web57413.mail.re1.yahoo.com> Message-ID: <200706232350.56545.pmancheno@gmail.com> When I was testing the LAN for my thesis I've used Qemu on my box (AMD64=3700+, 2GbRam) and the simulation for more than 4 routers and the clients was terrific, and I was using multicast and video streaming. El Mi?rcoles, 20 de Junio de 2007 08:08, Diego Salvador escribi?: > Hi! Is the XORP project has a plan of implementing virtual router > functionality? This is the case wherein one physical XORP machine can > simulate multiple virtual XORP machines intended for virtual networks. > > Thanks. > > Diego -- Linux User Registered #232544 Jabber : pepo at jabberes.org Ekiga : pepo at ekiga.net ICQ : 337889406 GnuPG-key : www.keyserver.net ----------------------------------------------- dum loquimur, fugerit invida aetas: carpe diem, quam minimum credula postero. From i at levsha.org.ua Tue Jun 26 01:04:06 2007 From: i at levsha.org.ua (Mykola Dzham) Date: Tue, 26 Jun 2007 11:04:06 +0300 Subject: [Xorp-users] can not delete interface route Message-ID: <20070626080406.GJ83883@expo.ukrweb.net> When i try to delete interface route i recieve error: root at ruslan.terabit.net.ua# delete interface-route 192.168.0.0/16 Deleting: 192.168.0.0/16 { next-hop-interface: "lo0" next-hop-vif: "lo0" } OK [edit protocols static] root at ruslan# commit Commit Failed Failed to expand XRL xrl $(static.targetname)/static_routes/0.1/delete_interface_route4?unicast:bool=true&multicast:bool=false&network:ipv4net=$(@)&nexthop:ipv4=$(@.next-hop)&ifname:txt=$(@.next-hop-interface)&vifname:txt=$(@.next-hop-vif): failed to expand variable "$(@.next-hop)" associated with node "192.168.0.0/16"[edit protocols static] root at ruslan# -- Mykola Dzham, LEFT-(UANIC|RIPE) JID: levsha at jabber.net.ua From salvador_d13 at yahoo.com.ph Tue Jun 26 03:53:33 2007 From: salvador_d13 at yahoo.com.ph (Diego Salvador) Date: Tue, 26 Jun 2007 03:53:33 -0700 (PDT) Subject: [Xorp-users] XORP and Virtual Routers In-Reply-To: Message-ID: <699604.87840.qm@web57404.mail.re1.yahoo.com> Thanks to all of you replying my concern. I apologize because perhaps I was wrong in building my statement here because what I want to know is the virtual routing and forwarding in XORP based on what I have encountered from the documents http://www.ipinfusion.com/pdf/VirtualRouting_app-note_3rev0302.pdf as well as this http://www.cs.ucl.ac.uk/staff/M.Handley/slides/xorp-virt.pdf. Thanks. Diego Sukrit Dasgupta wrote: Hi Diego, You could probably use UML (User Mode Linux) to do so, here is a (very) old link. http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2004-November/000278.html Also, there is a paper : http://www.sigcomm.org/sigcomm2006/discussion/showpaper.php?paper_id=1 Where UML is used to make virtual networks by running multiple XORP routers on one physical machine. Sukrit On Jun 20, 2007, at 9:08 AM, Diego Salvador wrote: Hi! Is the XORP project has a plan of implementing virtual router functionality? This is the case wherein one physical XORP machine can simulate multiple virtual XORP machines intended for virtual networks. Thanks. Diego --------------------------------- Tired of spam? Yahoo! Mail has the best spam protection around http://ph.mail.yahoo.com --------------------------------- Tired of spam? Yahoo! Mail has the best spam protection around http://ph.mail.yahoo.com_______________________________________________ Xorp-users mailing list Xorp-users at xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users --------------------------------- Tired of spam? Yahoo! Mail has the best spam protection around http://ph.mail.yahoo.com --------------------------------- Tired of spam? Yahoo! Mail has the best spam protection around http://ph.mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070626/72d032d1/attachment.html From pavlin at icir.org Tue Jun 26 10:51:00 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Tue, 26 Jun 2007 10:51:00 -0700 Subject: [Xorp-users] can not delete interface route In-Reply-To: Message from Mykola Dzham of "Tue, 26 Jun 2007 11:04:06 +0300." <20070626080406.GJ83883@expo.ukrweb.net> Message-ID: <200706261751.l5QHp0W2062304@possum.icir.org> Mykola Dzham wrote: > When i try to delete interface route i recieve error: > > root at ruslan.terabit.net.ua# delete interface-route 192.168.0.0/16 > Deleting: > 192.168.0.0/16 { > next-hop-interface: "lo0" > next-hop-vif: "lo0" > } > > OK > [edit protocols static] > root at ruslan# commit > Commit Failed > Failed to expand XRL xrl $(static.targetname)/static_routes/0.1/delete_interface_route4?unicast:bool=true&multicast:bool=false&network:ipv4net=$(@)&nexthop:ipv4=$(@.next-hop)&ifname:txt=$(@.next-hop-interface)&vifname:txt=$(@.next-hop-vif): failed to expand variable "$(@.next-hop)" associated with node "192.168.0.0/16"[edit protocols static] > root at ruslan# There was a bug in the static routes template file. It is now fixed in CVS: Revision Changes Path 1.42 +7 -7; commitid: de9646814f527ea6; xorp/etc/templates/static_routes.tp If you are using XORP-1.4, then it should be sufficient to apply the following patch to etc/templates/static_routes.tp : http://xorpc.icir.org/cgi-bin/cvsweb.cgi/xorp/etc/templates/static_routes.tp.diff?r1=1.41&r2=1.42 Thanks, Pavlin > -- > Mykola Dzham, LEFT-(UANIC|RIPE) > JID: levsha at jabber.net.ua > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From atanu at ICSI.Berkeley.EDU Tue Jun 26 19:54:10 2007 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Tue, 26 Jun 2007 19:54:10 -0700 Subject: [Xorp-users] update ospf database after policy change In-Reply-To: Message from Mykola Dzham of "Sat, 23 Jun 2007 15:54:37 +0300." <20070623125436.GW83883@expo.ukrweb.net> Message-ID: <84060.1182912850@tigger.icir.org> Hi, XORP supports policy reconfigurations without the need to restart. You seem to have found a bug in the updating of the policies, if you "commit" after: levsha at workstation.levsha.org.ua# delete policy policy-statement to-ospf term other then the policies are correctly updated. XORP# run show ospf4 database | match 192.168.15[56] ASExt-2 *192.168.156.0 192.168.0.50 0x80000001 11 0x2 0x3df3 36 Atanu. >>>>> "Mykola" == Mykola Dzham writes: Mykola> When i change ospf export policy to "network, that rejected previously, Mykola> now allow", then changes affect to ospf database immediately. But whe Mykola> in change policy to "network, that accepted previously, now reject", Mykola> then changes not affect to ospf database. Is it bug? Is it possible to Mykola> apply changes without restarting xorp? Mykola> xorp-1.4 , FreeBSD 6.2-RELEASE Mykola> Here is a test: Mykola> Start state: Mykola> levsha at workstation.levsha.org.ua# run show route table ipv4 unicast final | match 192.168.15[56] Mykola> 192.168.155.0/24 [connected(0)/0] Mykola> 192.168.156.0/24 [connected(0)/0] Mykola> levsha at workstation.levsha.org.ua# run show ospf4 database | match 192.168.15[56] Mykola> ASExt-2 *192.168.156.0 192.168.0.50 0x80000001 69 0x2 0x3df3 36 Mykola> levsha at workstation.levsha.org.ua# show protocols ospf4 export Mykola> export: "to-ospf" Mykola> [edit] Mykola> levsha at workstation.levsha.org.ua# show policy policy-statement to-ospf Mykola> term testnet { Mykola> from { Mykola> protocol: "connected" Mykola> network4: 192.168.155.0/24 Mykola> } Mykola> then { Mykola> reject { Mykola> } Mykola> } Mykola> } Mykola> term other { Mykola> from { Mykola> protocol: "connected" Mykola> } Mykola> then { Mykola> accept { Mykola> } Mykola> } Mykola> } Mykola> [edit] Mykola> change "network, that rejected previously,now allow": Mykola> levsha at workstation.levsha.org.ua# delete policy policy-statement to-ospf term testnet Mykola> Deleting: Mykola> testnet { Mykola> from { Mykola> protocol: "connected" Mykola> network4: 192.168.155.0/24 Mykola> } Mykola> then { Mykola> reject { Mykola> } Mykola> } Mykola> } Mykola> OK Mykola> [edit] Mykola> levsha at workstation.levsha.org.ua# commit Mykola> OK Mykola> [edit] Mykola> levsha at workstation.levsha.org.ua# run show ospf4 database | match 192.168.15[56] Mykola> ASExt-2 *192.168.155.0 192.168.0.50 0x80000001 30 0x2 0x48e9 36 Mykola> ASExt-2 *192.168.156.0 192.168.0.50 0x80000001 30 0x2 0x3df3 36 Mykola> change "network, that accepted previously, now reject": Mykola> levsha at workstation.levsha.org.ua# delete policy policy-statement to-ospf term other Mykola> Deleting: Mykola> other { Mykola> from { Mykola> protocol: "connected" Mykola> } Mykola> then { Mykola> accept { Mykola> } Mykola> } Mykola> } Mykola> OK Mykola> [edit] Mykola> levsha at workstation.levsha.org.ua# set policy policy-statement to-ospf term rej { >> from protocol connected >> from network4 192.168.155.0/24 >> then reject >> } Mykola> [edit] Mykola> evsha at workstation.levsha.org.ua# set policy policy-statement to-ospf term acc { >> from protocol connected >> then accept >> } Mykola> [edit] Mykola> levsha at workstation.levsha.org.ua# commit Mykola> OK Mykola> [edit] Mykola> levsha at workstation.levsha.org.ua# run show ospf4 database | match 192.168.15[56] Mykola> ASExt-2 *192.168.155.0 192.168.0.50 0x80000001 1769 0x2 0x48e9 36 Mykola> ASExt-2 *192.168.156.0 192.168.0.50 0x80000001 1769 0x2 0x3df3 36 Mykola> -- Mykola> Mykola Dzham, LEFT-(UANIC|RIPE) Mykola> JID: levsha at jabber.net.ua Mykola> _______________________________________________ Mykola> Xorp-users mailing list Mykola> Xorp-users at xorp.org Mykola> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From pavlin at icir.org Thu Jun 28 19:27:14 2007 From: pavlin at icir.org (Pavlin Radoslavov) Date: Thu, 28 Jun 2007 19:27:14 -0700 Subject: [Xorp-users] update ospf database after policy change In-Reply-To: Message from Atanu Ghosh of "Tue, 26 Jun 2007 19:54:10 PDT." <84060.1182912850@tigger.icir.org> Message-ID: <200706290227.l5T2RE5v099782@possum.icir.org> Mykola, In the process of testing your setup we found some other bugs, but now all of them are fixed in CVS. Hence, please try the latest code and let us know if you still have the issue. Thanks, Pavlin Atanu Ghosh wrote: > Hi, > > XORP supports policy reconfigurations without the need to restart. > > You seem to have found a bug in the updating of the policies, if you > "commit" after: > levsha at workstation.levsha.org.ua# delete policy policy-statement to-ospf term other > > then the policies are correctly updated. > > XORP# run show ospf4 database | match 192.168.15[56] > ASExt-2 *192.168.156.0 192.168.0.50 0x80000001 11 0x2 0x3df3 > 36 > > Atanu. > > >>>>> "Mykola" == Mykola Dzham writes: > Mykola> When i change ospf export policy to "network, that rejected previously, > Mykola> now allow", then changes affect to ospf database immediately. But whe > Mykola> in change policy to "network, that accepted previously, now reject", > Mykola> then changes not affect to ospf database. Is it bug? Is it possible to > Mykola> apply changes without restarting xorp? > > Mykola> xorp-1.4 , FreeBSD 6.2-RELEASE > > Mykola> Here is a test: > > Mykola> Start state: > > Mykola> levsha at workstation.levsha.org.ua# run show route table ipv4 unicast final | match 192.168.15[56] > Mykola> 192.168.155.0/24 [connected(0)/0] > Mykola> 192.168.156.0/24 [connected(0)/0] > Mykola> levsha at workstation.levsha.org.ua# run show ospf4 database | match 192.168.15[56] > Mykola> ASExt-2 *192.168.156.0 192.168.0.50 0x80000001 69 0x2 0x3df3 36 > Mykola> levsha at workstation.levsha.org.ua# show protocols ospf4 export > Mykola> export: "to-ospf" > > Mykola> [edit] > Mykola> levsha at workstation.levsha.org.ua# show policy policy-statement to-ospf > Mykola> term testnet { > Mykola> from { > Mykola> protocol: "connected" > Mykola> network4: 192.168.155.0/24 > Mykola> } > Mykola> then { > Mykola> reject { > Mykola> } > Mykola> } > Mykola> } > Mykola> term other { > Mykola> from { > Mykola> protocol: "connected" > Mykola> } > Mykola> then { > Mykola> accept { > Mykola> } > Mykola> } > Mykola> } > > Mykola> [edit] > > Mykola> change "network, that rejected previously,now allow": > > Mykola> levsha at workstation.levsha.org.ua# delete policy policy-statement to-ospf term testnet > Mykola> Deleting: > Mykola> testnet { > Mykola> from { > Mykola> protocol: "connected" > Mykola> network4: 192.168.155.0/24 > Mykola> } > Mykola> then { > Mykola> reject { > Mykola> } > Mykola> } > Mykola> } > > Mykola> OK > Mykola> [edit] > Mykola> levsha at workstation.levsha.org.ua# commit > Mykola> OK > Mykola> [edit] > Mykola> levsha at workstation.levsha.org.ua# run show ospf4 database | match 192.168.15[56] > Mykola> ASExt-2 *192.168.155.0 192.168.0.50 0x80000001 30 0x2 0x48e9 36 > Mykola> ASExt-2 *192.168.156.0 192.168.0.50 0x80000001 30 0x2 0x3df3 36 > > Mykola> change "network, that accepted previously, now reject": > > Mykola> levsha at workstation.levsha.org.ua# delete policy policy-statement to-ospf term other > Mykola> Deleting: > Mykola> other { > Mykola> from { > Mykola> protocol: "connected" > Mykola> } > Mykola> then { > Mykola> accept { > Mykola> } > Mykola> } > Mykola> } > > Mykola> OK > Mykola> [edit] > Mykola> levsha at workstation.levsha.org.ua# set policy policy-statement to-ospf term rej { > >> from protocol connected > >> from network4 192.168.155.0/24 > >> then reject > >> } > Mykola> [edit] > Mykola> evsha at workstation.levsha.org.ua# set policy policy-statement to-ospf term acc { > >> from protocol connected > >> then accept > >> } > Mykola> [edit] > Mykola> levsha at workstation.levsha.org.ua# commit > Mykola> OK > Mykola> [edit] > Mykola> levsha at workstation.levsha.org.ua# run show ospf4 database | match 192.168.15[56] > Mykola> ASExt-2 *192.168.155.0 192.168.0.50 0x80000001 1769 0x2 0x48e9 36 > Mykola> ASExt-2 *192.168.156.0 192.168.0.50 0x80000001 1769 0x2 0x3df3 36 > > Mykola> -- > Mykola> Mykola Dzham, LEFT-(UANIC|RIPE) > Mykola> JID: levsha at jabber.net.ua > > Mykola> _______________________________________________ > Mykola> Xorp-users mailing list > Mykola> Xorp-users at xorp.org > Mykola> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From salvador_d13 at yahoo.com.ph Fri Jun 29 06:52:09 2007 From: salvador_d13 at yahoo.com.ph (Diego Salvador) Date: Fri, 29 Jun 2007 06:52:09 -0700 (PDT) Subject: [Xorp-users] Routing Capacity in XORP Message-ID: <522780.66113.qm@web57415.mail.re1.yahoo.com> Hi! How to test routing capacity on XORP protocols in unicast (RIP, OSPF, BGP) and multicast (PIM-SM, MLD and IGMP)? Thanks. Diego --------------------------------- Tired of spam? Yahoo! Mail has the best spam protection around http://ph.mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070629/b939a584/attachment.html