From ganeshreddyk at gmail.com Wed Jul 4 23:15:20 2012 From: ganeshreddyk at gmail.com (Ganesh Reddy K) Date: Thu, 5 Jul 2012 11:45:20 +0530 Subject: [Xorp-users] Multicast traffic is not forwarded in a specific deployment as mentioned in the mail Message-ID: Hi , We are trying to exercise a multicast traffic forwarding scenario on a powerPC device:-- After H2 subscribed for the Group G1, The G1 multicast traffic is not receiving at H2. But, when the H1 ip is in the same subnet, traffic is properly forwarded to H2 without any issues. Test setup:-- H1 ------------------------------------ eth3 XORP eth2 -------------------------------------------- H2 192.168.17.17 192.168.4.2 192.168.3.2 192.168.3.10 UDP-G1 multicaststream Mcast listener for G1 G1-239.7.7.7 1) COnfigured XORP on the device, xorp.conf contents are . ===========XORP configuration =========== protocols { fib2mrib { } igmp { interface eth0 { vif eth0 { version: 3 } } interface eth1 { vif eth1 { version: 3 } } interface eth2 { vif eth2 { version: 3 } } interface eth3 { vif eth3 { version: 3 } } } pimsm4 { interface eth0 { vif eth0 { } } interface "register_vif" { vif "register_vif" { } } interface eth1 { vif eth1 { } } interface eth2 { vif eth2 { } } interface eth3 { vif eth3 { } } } } fea { unicast-forwarding4 { } unicast-forwarding6 { } } interfaces { interface eth0 { vif eth0 { } default-system-config { } } interface eth1 { vif eth1 { } default-system-config { } } interface eth2 { vif eth2 { } default-system-config { } } interface eth3 { vif eth3 { } default-system-config { } } } plumbing { mfea4 { interface eth0 { vif eth0 { } } interface "register_vif" { vif "register_vif" { } } interface eth1 { vif eth1 { } } interface eth2 { vif eth2 { } } interface eth3 { vif eth3 { } } } } ============= xorp configuration ============= 2) From H1, started sending UDP stream targeting G1 using VLC player. Capture of "tcpdump -ni eth3" on Device shows the UDP-G1 packets as below .. 09:27:50.081561 IP 192.168.17.17.4146 > 239.7.7.7.1234: UDP, length 1328 .. 3) added a static route for the unknown network on Device (i.e route add -net 192.168.17.17/32 dev eth3) 4) From H2, started VLC listener for the group G1. It is verified in the Device that, IGMP join is received. capture of " show igmp group" on XORP console Interface Group Source LastReported Timeout V State eth0 224.0.0.2 0.0.0.0 192.168.1.2 223 3 E eth0 224.0.0.13 0.0.0.0 192.168.1.2 223 3 E eth0 224.0.0.22 0.0.0.0 192.168.1.2 223 3 E eth1 224.0.0.2 0.0.0.0 192.168.2.2 225 3 E eth1 224.0.0.13 0.0.0.0 192.168.2.2 225 3 E eth1 224.0.0.22 0.0.0.0 192.168.2.2 225 3 E eth2 224.0.0.2 0.0.0.0 192.168.3.2 231 3 E eth2 224.0.0.13 0.0.0.0 192.168.3.2 231 3 E eth2 224.0.0.22 0.0.0.0 192.168.3.2 231 3 E eth2 239.1.1.1 0.0.0.0 192.168.3.10 228 3 E eth2 239.7.7.7 0.0.0.0 192.168.3.10 228 3 E eth2 239.255.255.250 0.0.0.0 192.168.3.10 228 3 E eth3 224.0.0.2 0.0.0.0 192.168.4.2 230 3 E eth3 224.0.0.13 0.0.0.0 192.168.4.2 230 3 E eth3 224.0.0.22 0.0.0.0 192.168.4.2 230 3 E root at p4080ds> 5) But the traffic is not receiving at H2. Below is the statistics related ip_mr on the device cat /proc/net/ip_mr* Group Origin Iif Pkts Bytes Wrong Oifs EF070707 C0A81111 3 453 614268 0 Interface BytesIn PktsIn BytesOut PktsOut Flags Local Remote 0 eth0 0 0 0 0 00000 C0A80102 00000000 1 eth1 0 0 0 0 00000 C0A80202 00000000 2 eth2 0 0 0 0 00000 C0A80302 00000000 3 eth3 3971724 2929 0 0 00000 C0A80402 00000000 4 pimreg 0 0 0 0 00004 C0A80102 6) But, when the H1 ip is in the same subnet, traffic is properly forwarded to H2 without any issues. Did anybody tried this scenario ? Thanks, Ganesh From igorm at etf.rs Thu Jul 5 00:19:48 2012 From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=) Date: Thu, 5 Jul 2012 09:19:48 +0200 Subject: [Xorp-users] Multicast traffic is not forwarded in a specific deployment as mentioned in the mail In-Reply-To: References: Message-ID: I'm 99% sure that this isn't Xorp problem :) Linux, won't forward packets if the src address in packet is unknown to him. So, at least I think that, you have 2 possible solutions: 1. Turn off rp filtering on Xorp box (reference - http://lartc.org/howto/lartc.kernel.html) 2. Set static interface route to 192.168.17.17/32 on eth3, with Xorp ( interface-route 192.168.17.17/32 { next-hop-interface: "eth3" next-hop-vif: "eth3" } ) Let me know if it worked. :) BR Igor 2012/7/5 Ganesh Reddy K : > Hi , > > We are trying to exercise a multicast traffic forwarding scenario on > a powerPC device:-- > > After H2 subscribed for the Group G1, The G1 multicast traffic is not > receiving at H2. But, when the H1 ip is in the same subnet, traffic > is properly forwarded to H2 without any issues. > > Test setup:-- > > H1 ------------------------------------ eth3 XORP eth2 > -------------------------------------------- H2 > > 192.168.17.17 192.168.4.2 192.168.3.2 > 192.168.3.10 > > UDP-G1 multicaststream > Mcast listener for G1 > > G1-239.7.7.7 > > > 1) COnfigured XORP on the device, xorp.conf contents are . > > ===========XORP configuration =========== > > protocols { > fib2mrib { > } > igmp { > > interface eth0 { > vif eth0 { > version: 3 > } > } > interface eth1 { > vif eth1 { > version: 3 > } > } > interface eth2 { > vif eth2 { > version: 3 > } > } > interface eth3 { > > vif eth3 { > version: 3 > } > } } > > > pimsm4 { > interface eth0 { > > vif eth0 { > } > } > interface "register_vif" { > vif "register_vif" { > } > > } > interface eth1 { > vif eth1 { > > } > } > interface eth2 { > vif eth2 { > } > } > interface eth3 { > > vif eth3 { > } > } > } > } > fea { > unicast-forwarding4 { > } > > > unicast-forwarding6 { > } > } > interfaces { > interface eth0 { > vif eth0 { > } > > default-system-config { > } > } > interface eth1 { > > vif eth1 { > } > default-system-config { > } > } > interface eth2 { > vif eth2 { > > } > default-system-config { > } > } > > interface eth3 { > vif eth3 { > } > > default-system-config { > } > } > } > plumbing { > > mfea4 { > interface eth0 { > vif eth0 { > > } > } > interface "register_vif" { > > vif "register_vif" { > } > } > > interface eth1 { > vif eth1 { > } > > } > > interface eth2 { > vif eth2 { > } > > } > interface eth3 { > vif eth3 { > > } > } > } > } > > ============= xorp configuration ============= > > 2) From H1, started sending UDP stream targeting G1 using VLC player. > > Capture of "tcpdump -ni eth3" on Device shows the UDP-G1 packets as below > .. > 09:27:50.081561 IP 192.168.17.17.4146 > 239.7.7.7.1234: UDP, length 1328 > .. > > 3) added a static route for the unknown network on Device (i.e route > add -net 192.168.17.17/32 dev eth3) > > 4) From H2, started VLC listener for the group G1. > > It is verified in the Device that, IGMP join is received. > capture of " show igmp group" on XORP console > > Interface Group Source LastReported Timeout V State > > eth0 224.0.0.2 0.0.0.0 192.168.1.2 223 3 E > > eth0 224.0.0.13 0.0.0.0 192.168.1.2 223 3 E > > eth0 224.0.0.22 0.0.0.0 192.168.1.2 223 3 E > > eth1 224.0.0.2 0.0.0.0 192.168.2.2 225 3 E > > eth1 224.0.0.13 0.0.0.0 192.168.2.2 225 3 E > > eth1 224.0.0.22 0.0.0.0 192.168.2.2 225 3 E > > eth2 224.0.0.2 0.0.0.0 192.168.3.2 231 3 E > > eth2 224.0.0.13 0.0.0.0 192.168.3.2 231 3 E > > eth2 224.0.0.22 0.0.0.0 192.168.3.2 231 3 E > > eth2 239.1.1.1 0.0.0.0 192.168.3.10 228 3 E > > eth2 239.7.7.7 0.0.0.0 192.168.3.10 228 3 E > > eth2 239.255.255.250 0.0.0.0 192.168.3.10 228 3 E > > eth3 224.0.0.2 0.0.0.0 192.168.4.2 230 3 E > > eth3 224.0.0.13 0.0.0.0 192.168.4.2 230 3 E > > eth3 224.0.0.22 0.0.0.0 192.168.4.2 230 3 E > > root at p4080ds> > > 5) But the traffic is not receiving at H2. Below is the statistics > related ip_mr on the device > > cat /proc/net/ip_mr* > > Group Origin Iif Pkts Bytes Wrong Oifs > EF070707 C0A81111 3 453 614268 0 > Interface BytesIn PktsIn BytesOut PktsOut Flags Local Remote > 0 eth0 0 0 0 0 00000 C0A80102 00000000 > 1 eth1 0 0 0 0 00000 C0A80202 00000000 > 2 eth2 0 0 0 0 00000 C0A80302 00000000 > 3 eth3 3971724 2929 0 0 00000 C0A80402 00000000 > 4 pimreg 0 0 0 0 00004 C0A80102 > > > 6) But, when the H1 ip is in the same subnet, traffic is properly > forwarded to H2 without any issues. > > Did anybody tried this scenario ? > > Thanks, > Ganesh > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users From igorm at etf.rs Thu Jul 5 07:32:40 2012 From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=) Date: Thu, 5 Jul 2012 16:32:40 +0200 Subject: [Xorp-users] Multicast traffic is not forwarded in a specific deployment as mentioned in the mail In-Reply-To: <82B681751FE46F4AB3FCA7390B780FD1051A6AE0@039-SN1MPN1-001.039d.mgd.msft.net> References: <82B681751FE46F4AB3FCA7390B780FD1051A6AE0@039-SN1MPN1-001.039d.mgd.msft.net> Message-ID: My bad... I forgot set protocols static part... command in xorpsh is #set protocols static interface-route 192.168.17.17/32 next-hop-interface eth3 #set protocols static interface-route 192.168.17.17/32 next-hop-vif eth3 If my theory is ok when you send packets from H1 to H2, they are dropped in Linux. You can confirm this if you run netstat -s IP and you see that number of discarded IP packets is increasing. My proposals are for that case. BR Igor 2012/7/5 Reddy Ganesh-B38514 : > Echo 0 > /proc/sys/net/ipv4/conf/eth3/rp_filter > Echo 0 > /proc/sys/net/ipv4/conf/eth2/rp_filter > Echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter > > As per the step 1, I have Disabled the rp_filter on the Device. Still the problem persists. > > I tried to configure commands mentioned in step 2 also, But I could not locate the exact commands in xorp config shell. Did I miss anything ?? > > -----Original Message----- > From: Igor Maravi? [mailto:igorm at etf.rs] > Sent: Thursday, July 05, 2012 12:50 PM > To: Ganesh Reddy K > Cc: xorp-users at xorp.org; Bv Rajesh-B35907; nandakishoreie14 at gmail.com; Reddy Ganesh-B38514 > Subject: Re: [Xorp-users] Multicast traffic is not forwarded in a specific deployment as mentioned in the mail > > I'm 99% sure that this isn't Xorp problem :) Linux, won't forward packets if the src address in packet is unknown to him. > So, at least I think that, you have 2 possible solutions: > 1. Turn off rp filtering on Xorp box (reference - > http://lartc.org/howto/lartc.kernel.html) > 2. Set static interface route to 192.168.17.17/32 on eth3, with Xorp ( > interface-route 192.168.17.17/32 { > next-hop-interface: "eth3" > next-hop-vif: "eth3" > } > ) > > Let me know if it worked. :) > BR > Igor > > 2012/7/5 Ganesh Reddy K : >> Hi , >> >> We are trying to exercise a multicast traffic forwarding scenario on >> a powerPC device:-- >> >> After H2 subscribed for the Group G1, The G1 multicast traffic is not >> receiving at H2. But, when the H1 ip is in the same subnet, traffic >> is properly forwarded to H2 without any issues. >> >> Test setup:-- >> >> H1 ------------------------------------ eth3 XORP eth2 >> -------------------------------------------- H2 >> >> 192.168.17.17 192.168.4.2 192.168.3.2 >> 192.168.3.10 >> >> UDP-G1 multicaststream >> Mcast listener for G1 >> >> G1-239.7.7.7 >> >> >> 1) COnfigured XORP on the device, xorp.conf contents are . >> >> ===========XORP configuration =========== >> >> protocols { >> fib2mrib { >> } >> igmp { >> >> interface eth0 { >> vif eth0 { >> version: 3 >> } >> } >> interface eth1 { >> vif eth1 { >> version: 3 >> } >> } >> interface eth2 { >> vif eth2 { >> version: 3 >> } >> } >> interface eth3 { >> >> vif eth3 { >> version: 3 >> } >> } } >> >> >> pimsm4 { >> interface eth0 { >> >> vif eth0 { >> } >> } >> interface "register_vif" { >> vif "register_vif" { >> } >> >> } >> interface eth1 { >> vif eth1 { >> >> } >> } >> interface eth2 { >> vif eth2 { >> } >> } >> interface eth3 { >> >> vif eth3 { >> } >> } >> } >> } >> fea { >> unicast-forwarding4 { >> } >> >> >> unicast-forwarding6 { >> } >> } >> interfaces { >> interface eth0 { >> vif eth0 { >> } >> >> default-system-config { >> } >> } >> interface eth1 { >> >> vif eth1 { >> } >> default-system-config { >> } >> } >> interface eth2 { >> vif eth2 { >> >> } >> default-system-config { >> } >> } >> >> interface eth3 { >> vif eth3 { >> } >> >> default-system-config { >> } >> } >> } >> plumbing { >> >> mfea4 { >> interface eth0 { >> vif eth0 { >> >> } >> } >> interface "register_vif" { >> >> vif "register_vif" { >> } >> } >> >> interface eth1 { >> vif eth1 { >> } >> >> } >> >> interface eth2 { >> vif eth2 { >> } >> >> } >> interface eth3 { >> vif eth3 { >> >> } >> } >> } >> } >> >> ============= xorp configuration ============= >> >> 2) From H1, started sending UDP stream targeting G1 using VLC player. >> >> Capture of "tcpdump -ni eth3" on Device shows the UDP-G1 packets as >> below .. >> 09:27:50.081561 IP 192.168.17.17.4146 > 239.7.7.7.1234: UDP, length >> 1328 .. >> >> 3) added a static route for the unknown network on Device (i.e route >> add -net 192.168.17.17/32 dev eth3) >> >> 4) From H2, started VLC listener for the group G1. >> >> It is verified in the Device that, IGMP join is received. >> capture of " show igmp group" on XORP console >> >> Interface Group Source LastReported Timeout V State >> >> eth0 224.0.0.2 0.0.0.0 192.168.1.2 223 3 E >> >> eth0 224.0.0.13 0.0.0.0 192.168.1.2 223 3 E >> >> eth0 224.0.0.22 0.0.0.0 192.168.1.2 223 3 E >> >> eth1 224.0.0.2 0.0.0.0 192.168.2.2 225 3 E >> >> eth1 224.0.0.13 0.0.0.0 192.168.2.2 225 3 E >> >> eth1 224.0.0.22 0.0.0.0 192.168.2.2 225 3 E >> >> eth2 224.0.0.2 0.0.0.0 192.168.3.2 231 3 E >> >> eth2 224.0.0.13 0.0.0.0 192.168.3.2 231 3 E >> >> eth2 224.0.0.22 0.0.0.0 192.168.3.2 231 3 E >> >> eth2 239.1.1.1 0.0.0.0 192.168.3.10 228 3 E >> >> eth2 239.7.7.7 0.0.0.0 192.168.3.10 228 3 E >> >> eth2 239.255.255.250 0.0.0.0 192.168.3.10 228 3 E >> >> eth3 224.0.0.2 0.0.0.0 192.168.4.2 230 3 E >> >> eth3 224.0.0.13 0.0.0.0 192.168.4.2 230 3 E >> >> eth3 224.0.0.22 0.0.0.0 192.168.4.2 230 3 E >> >> root at p4080ds> >> >> 5) But the traffic is not receiving at H2. Below is the statistics >> related ip_mr on the device >> >> cat /proc/net/ip_mr* >> >> Group Origin Iif Pkts Bytes Wrong Oifs >> EF070707 C0A81111 3 453 614268 0 >> Interface BytesIn PktsIn BytesOut PktsOut Flags Local Remote >> 0 eth0 0 0 0 0 00000 C0A80102 00000000 >> 1 eth1 0 0 0 0 00000 C0A80202 00000000 >> 2 eth2 0 0 0 0 00000 C0A80302 00000000 >> 3 eth3 3971724 2929 0 0 00000 C0A80402 00000000 >> 4 pimreg 0 0 0 0 00004 C0A80102 >> >> >> 6) But, when the H1 ip is in the same subnet, traffic is properly >> forwarded to H2 without any issues. >> >> Did anybody tried this scenario ? >> >> Thanks, >> Ganesh >> >> _______________________________________________ >> Xorp-users mailing list >> Xorp-users at xorp.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > > From igorm at etf.rs Thu Jul 5 07:37:15 2012 From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=) Date: Thu, 5 Jul 2012 16:37:15 +0200 Subject: [Xorp-users] Multicast traffic is not forwarded in a specific deployment as mentioned in the mail In-Reply-To: References: <82B681751FE46F4AB3FCA7390B780FD1051A6AE0@039-SN1MPN1-001.039d.mgd.msft.net> Message-ID: sysctl -w net.ipv4.conf.eth3.rp_filter=0 sysctl -w net.ipv4.conf.eth2.rp_filter=0 sysctl -w net.ipv4.conf.all.rp_filter=0 sysctl -w net.ipv4.conf.default.rp_filter=0 for me, echo isn't working. I use this commands to set values. 2012/7/5 Igor Maravi? : > My bad... I forgot set protocols static part... > > command in xorpsh is > > #set protocols static interface-route 192.168.17.17/32 next-hop-interface eth3 > #set protocols static interface-route 192.168.17.17/32 next-hop-vif eth3 > > If my theory is ok when you send packets from H1 to H2, they are > dropped in Linux. > You can confirm this if you run > > netstat -s IP > > and you see that number of discarded IP packets is increasing. > My proposals are for that case. > BR > Igor > > 2012/7/5 Reddy Ganesh-B38514 : >> Echo 0 > /proc/sys/net/ipv4/conf/eth3/rp_filter >> Echo 0 > /proc/sys/net/ipv4/conf/eth2/rp_filter >> Echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter >> >> As per the step 1, I have Disabled the rp_filter on the Device. Still the problem persists. >> >> I tried to configure commands mentioned in step 2 also, But I could not locate the exact commands in xorp config shell. Did I miss anything ?? >> >> -----Original Message----- >> From: Igor Maravi? [mailto:igorm at etf.rs] >> Sent: Thursday, July 05, 2012 12:50 PM >> To: Ganesh Reddy K >> Cc: xorp-users at xorp.org; Bv Rajesh-B35907; nandakishoreie14 at gmail.com; Reddy Ganesh-B38514 >> Subject: Re: [Xorp-users] Multicast traffic is not forwarded in a specific deployment as mentioned in the mail >> >> I'm 99% sure that this isn't Xorp problem :) Linux, won't forward packets if the src address in packet is unknown to him. >> So, at least I think that, you have 2 possible solutions: >> 1. Turn off rp filtering on Xorp box (reference - >> http://lartc.org/howto/lartc.kernel.html) >> 2. Set static interface route to 192.168.17.17/32 on eth3, with Xorp ( >> interface-route 192.168.17.17/32 { >> next-hop-interface: "eth3" >> next-hop-vif: "eth3" >> } >> ) >> >> Let me know if it worked. :) >> BR >> Igor >> >> 2012/7/5 Ganesh Reddy K : >>> Hi , >>> >>> We are trying to exercise a multicast traffic forwarding scenario on >>> a powerPC device:-- >>> >>> After H2 subscribed for the Group G1, The G1 multicast traffic is not >>> receiving at H2. But, when the H1 ip is in the same subnet, traffic >>> is properly forwarded to H2 without any issues. >>> >>> Test setup:-- >>> >>> H1 ------------------------------------ eth3 XORP eth2 >>> -------------------------------------------- H2 >>> >>> 192.168.17.17 192.168.4.2 192.168.3.2 >>> 192.168.3.10 >>> >>> UDP-G1 multicaststream >>> Mcast listener for G1 >>> >>> G1-239.7.7.7 >>> >>> >>> 1) COnfigured XORP on the device, xorp.conf contents are . >>> >>> ===========XORP configuration =========== >>> >>> protocols { >>> fib2mrib { >>> } >>> igmp { >>> >>> interface eth0 { >>> vif eth0 { >>> version: 3 >>> } >>> } >>> interface eth1 { >>> vif eth1 { >>> version: 3 >>> } >>> } >>> interface eth2 { >>> vif eth2 { >>> version: 3 >>> } >>> } >>> interface eth3 { >>> >>> vif eth3 { >>> version: 3 >>> } >>> } } >>> >>> >>> pimsm4 { >>> interface eth0 { >>> >>> vif eth0 { >>> } >>> } >>> interface "register_vif" { >>> vif "register_vif" { >>> } >>> >>> } >>> interface eth1 { >>> vif eth1 { >>> >>> } >>> } >>> interface eth2 { >>> vif eth2 { >>> } >>> } >>> interface eth3 { >>> >>> vif eth3 { >>> } >>> } >>> } >>> } >>> fea { >>> unicast-forwarding4 { >>> } >>> >>> >>> unicast-forwarding6 { >>> } >>> } >>> interfaces { >>> interface eth0 { >>> vif eth0 { >>> } >>> >>> default-system-config { >>> } >>> } >>> interface eth1 { >>> >>> vif eth1 { >>> } >>> default-system-config { >>> } >>> } >>> interface eth2 { >>> vif eth2 { >>> >>> } >>> default-system-config { >>> } >>> } >>> >>> interface eth3 { >>> vif eth3 { >>> } >>> >>> default-system-config { >>> } >>> } >>> } >>> plumbing { >>> >>> mfea4 { >>> interface eth0 { >>> vif eth0 { >>> >>> } >>> } >>> interface "register_vif" { >>> >>> vif "register_vif" { >>> } >>> } >>> >>> interface eth1 { >>> vif eth1 { >>> } >>> >>> } >>> >>> interface eth2 { >>> vif eth2 { >>> } >>> >>> } >>> interface eth3 { >>> vif eth3 { >>> >>> } >>> } >>> } >>> } >>> >>> ============= xorp configuration ============= >>> >>> 2) From H1, started sending UDP stream targeting G1 using VLC player. >>> >>> Capture of "tcpdump -ni eth3" on Device shows the UDP-G1 packets as >>> below .. >>> 09:27:50.081561 IP 192.168.17.17.4146 > 239.7.7.7.1234: UDP, length >>> 1328 .. >>> >>> 3) added a static route for the unknown network on Device (i.e route >>> add -net 192.168.17.17/32 dev eth3) >>> >>> 4) From H2, started VLC listener for the group G1. >>> >>> It is verified in the Device that, IGMP join is received. >>> capture of " show igmp group" on XORP console >>> >>> Interface Group Source LastReported Timeout V State >>> >>> eth0 224.0.0.2 0.0.0.0 192.168.1.2 223 3 E >>> >>> eth0 224.0.0.13 0.0.0.0 192.168.1.2 223 3 E >>> >>> eth0 224.0.0.22 0.0.0.0 192.168.1.2 223 3 E >>> >>> eth1 224.0.0.2 0.0.0.0 192.168.2.2 225 3 E >>> >>> eth1 224.0.0.13 0.0.0.0 192.168.2.2 225 3 E >>> >>> eth1 224.0.0.22 0.0.0.0 192.168.2.2 225 3 E >>> >>> eth2 224.0.0.2 0.0.0.0 192.168.3.2 231 3 E >>> >>> eth2 224.0.0.13 0.0.0.0 192.168.3.2 231 3 E >>> >>> eth2 224.0.0.22 0.0.0.0 192.168.3.2 231 3 E >>> >>> eth2 239.1.1.1 0.0.0.0 192.168.3.10 228 3 E >>> >>> eth2 239.7.7.7 0.0.0.0 192.168.3.10 228 3 E >>> >>> eth2 239.255.255.250 0.0.0.0 192.168.3.10 228 3 E >>> >>> eth3 224.0.0.2 0.0.0.0 192.168.4.2 230 3 E >>> >>> eth3 224.0.0.13 0.0.0.0 192.168.4.2 230 3 E >>> >>> eth3 224.0.0.22 0.0.0.0 192.168.4.2 230 3 E >>> >>> root at p4080ds> >>> >>> 5) But the traffic is not receiving at H2. Below is the statistics >>> related ip_mr on the device >>> >>> cat /proc/net/ip_mr* >>> >>> Group Origin Iif Pkts Bytes Wrong Oifs >>> EF070707 C0A81111 3 453 614268 0 >>> Interface BytesIn PktsIn BytesOut PktsOut Flags Local Remote >>> 0 eth0 0 0 0 0 00000 C0A80102 00000000 >>> 1 eth1 0 0 0 0 00000 C0A80202 00000000 >>> 2 eth2 0 0 0 0 00000 C0A80302 00000000 >>> 3 eth3 3971724 2929 0 0 00000 C0A80402 00000000 >>> 4 pimreg 0 0 0 0 00004 C0A80102 >>> >>> >>> 6) But, when the H1 ip is in the same subnet, traffic is properly >>> forwarded to H2 without any issues. >>> >>> Did anybody tried this scenario ? >>> >>> Thanks, >>> Ganesh >>> >>> _______________________________________________ >>> Xorp-users mailing list >>> Xorp-users at xorp.org >>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users >> >> From ganeshreddyk at gmail.com Thu Jul 5 09:19:07 2012 From: ganeshreddyk at gmail.com (Ganesh Reddy K) Date: Thu, 5 Jul 2012 21:49:07 +0530 Subject: [Xorp-users] Multicast traffic is not forwarded in a specific deployment as mentioned in the mail In-Reply-To: References: <82B681751FE46F4AB3FCA7390B780FD1051A6AE0@039-SN1MPN1-001.039d.mgd.msft.net> Message-ID: Thanks a lot for the detailed inputs, I have added the routes as suggested, but still the traffic is not forwarded . Did not observe any discards in ' netstat -s IP'. In general, When multicast UDP cache-miss occurs and subscriber is listened for that group, Then only multicast routing services will add the multicast ROUTE in linux kernel . The forwarding is taken care by Linux routing mechanism. I guess, In this scenario, UDP cache miss is properly given to XORP daemons, but could not fulfill the entire route (i.e ip_mr_cache with valid Oif ) . There may be possible spoof check in PIM daemons . Is my thought justifies the behavior ? ================ netstat -s IP Ip: 67296 total packets received 0 forwarded 0 incoming packets discarded 42784 incoming packets delivered 41760 requests sent out Icmp: 0 ICMP messages received 0 input ICMP message failed. ICMP input histogram: 0 ICMP messages sent 0 ICMP messages failed ICMP output histogram: Tcp: 50 active connections openings 49 passive connection openings 0 failed connection attempts 0 connection resets received 35 connections established 40788 segments received 39837 segments send out 0 segments retransmited 0 bad segments received. 0 resets sent Udp: 0 packets received 0 packets to unknown port received. 0 packet receive errors 0 packets sent RcvbufErrors: 0 SndbufErrors: 0 UdpLite: InDatagrams: 0 NoPorts: 0 InErrors: 0 OutDatagrams: 0 RcvbufErrors: 0 SndbufErrors: 0 error parsing /proc/net/snmp: Success ================ On Thu, Jul 5, 2012 at 8:07 PM, Igor Maravi? wrote: > sysctl -w net.ipv4.conf.eth3.rp_filter=0 > sysctl -w net.ipv4.conf.eth2.rp_filter=0 > sysctl -w net.ipv4.conf.all.rp_filter=0 > sysctl -w net.ipv4.conf.default.rp_filter=0 > > for me, echo isn't working. I use this commands to set values. > > 2012/7/5 Igor Maravi? : >> My bad... I forgot set protocols static part... >> >> command in xorpsh is >> >> #set protocols static interface-route 192.168.17.17/32 next-hop-interface eth3 >> #set protocols static interface-route 192.168.17.17/32 next-hop-vif eth3 >> >> If my theory is ok when you send packets from H1 to H2, they are >> dropped in Linux. >> You can confirm this if you run >> >> netstat -s IP >> >> and you see that number of discarded IP packets is increasing. >> My proposals are for that case. >> BR >> Igor >> >> 2012/7/5 Reddy Ganesh-B38514 : >>> Echo 0 > /proc/sys/net/ipv4/conf/eth3/rp_filter >>> Echo 0 > /proc/sys/net/ipv4/conf/eth2/rp_filter >>> Echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter >>> >>> As per the step 1, I have Disabled the rp_filter on the Device. Still the problem persists. >>> >>> I tried to configure commands mentioned in step 2 also, But I could not locate the exact commands in xorp config shell. Did I miss anything ?? >>> >>> -----Original Message----- >>> From: Igor Maravi? [mailto:igorm at etf.rs] >>> Sent: Thursday, July 05, 2012 12:50 PM >>> To: Ganesh Reddy K >>> Cc: xorp-users at xorp.org; Bv Rajesh-B35907; nandakishoreie14 at gmail.com; Reddy Ganesh-B38514 >>> Subject: Re: [Xorp-users] Multicast traffic is not forwarded in a specific deployment as mentioned in the mail >>> >>> I'm 99% sure that this isn't Xorp problem :) Linux, won't forward packets if the src address in packet is unknown to him. >>> So, at least I think that, you have 2 possible solutions: >>> 1. Turn off rp filtering on Xorp box (reference - >>> http://lartc.org/howto/lartc.kernel.html) >>> 2. Set static interface route to 192.168.17.17/32 on eth3, with Xorp ( >>> interface-route 192.168.17.17/32 { >>> next-hop-interface: "eth3" >>> next-hop-vif: "eth3" >>> } >>> ) >>> >>> Let me know if it worked. :) >>> BR >>> Igor >>> >>> 2012/7/5 Ganesh Reddy K : >>>> Hi , >>>> >>>> We are trying to exercise a multicast traffic forwarding scenario on >>>> a powerPC device:-- >>>> >>>> After H2 subscribed for the Group G1, The G1 multicast traffic is not >>>> receiving at H2. But, when the H1 ip is in the same subnet, traffic >>>> is properly forwarded to H2 without any issues. >>>> >>>> Test setup:-- >>>> >>>> H1 ------------------------------------ eth3 XORP eth2 >>>> -------------------------------------------- H2 >>>> >>>> 192.168.17.17 192.168.4.2 192.168.3.2 >>>> 192.168.3.10 >>>> >>>> UDP-G1 multicaststream >>>> Mcast listener for G1 >>>> >>>> G1-239.7.7.7 >>>> >>>> >>>> 1) COnfigured XORP on the device, xorp.conf contents are . >>>> >>>> ===========XORP configuration =========== >>>> >>>> protocols { >>>> fib2mrib { >>>> } >>>> igmp { >>>> >>>> interface eth0 { >>>> vif eth0 { >>>> version: 3 >>>> } >>>> } >>>> interface eth1 { >>>> vif eth1 { >>>> version: 3 >>>> } >>>> } >>>> interface eth2 { >>>> vif eth2 { >>>> version: 3 >>>> } >>>> } >>>> interface eth3 { >>>> >>>> vif eth3 { >>>> version: 3 >>>> } >>>> } } >>>> >>>> >>>> pimsm4 { >>>> interface eth0 { >>>> >>>> vif eth0 { >>>> } >>>> } >>>> interface "register_vif" { >>>> vif "register_vif" { >>>> } >>>> >>>> } >>>> interface eth1 { >>>> vif eth1 { >>>> >>>> } >>>> } >>>> interface eth2 { >>>> vif eth2 { >>>> } >>>> } >>>> interface eth3 { >>>> >>>> vif eth3 { >>>> } >>>> } >>>> } >>>> } >>>> fea { >>>> unicast-forwarding4 { >>>> } >>>> >>>> >>>> unicast-forwarding6 { >>>> } >>>> } >>>> interfaces { >>>> interface eth0 { >>>> vif eth0 { >>>> } >>>> >>>> default-system-config { >>>> } >>>> } >>>> interface eth1 { >>>> >>>> vif eth1 { >>>> } >>>> default-system-config { >>>> } >>>> } >>>> interface eth2 { >>>> vif eth2 { >>>> >>>> } >>>> default-system-config { >>>> } >>>> } >>>> >>>> interface eth3 { >>>> vif eth3 { >>>> } >>>> >>>> default-system-config { >>>> } >>>> } >>>> } >>>> plumbing { >>>> >>>> mfea4 { >>>> interface eth0 { >>>> vif eth0 { >>>> >>>> } >>>> } >>>> interface "register_vif" { >>>> >>>> vif "register_vif" { >>>> } >>>> } >>>> >>>> interface eth1 { >>>> vif eth1 { >>>> } >>>> >>>> } >>>> >>>> interface eth2 { >>>> vif eth2 { >>>> } >>>> >>>> } >>>> interface eth3 { >>>> vif eth3 { >>>> >>>> } >>>> } >>>> } >>>> } >>>> >>>> ============= xorp configuration ============= >>>> >>>> 2) From H1, started sending UDP stream targeting G1 using VLC player. >>>> >>>> Capture of "tcpdump -ni eth3" on Device shows the UDP-G1 packets as >>>> below .. >>>> 09:27:50.081561 IP 192.168.17.17.4146 > 239.7.7.7.1234: UDP, length >>>> 1328 .. >>>> >>>> 3) added a static route for the unknown network on Device (i.e route >>>> add -net 192.168.17.17/32 dev eth3) >>>> >>>> 4) From H2, started VLC listener for the group G1. >>>> >>>> It is verified in the Device that, IGMP join is received. >>>> capture of " show igmp group" on XORP console >>>> >>>> Interface Group Source LastReported Timeout V State >>>> >>>> eth0 224.0.0.2 0.0.0.0 192.168.1.2 223 3 E >>>> >>>> eth0 224.0.0.13 0.0.0.0 192.168.1.2 223 3 E >>>> >>>> eth0 224.0.0.22 0.0.0.0 192.168.1.2 223 3 E >>>> >>>> eth1 224.0.0.2 0.0.0.0 192.168.2.2 225 3 E >>>> >>>> eth1 224.0.0.13 0.0.0.0 192.168.2.2 225 3 E >>>> >>>> eth1 224.0.0.22 0.0.0.0 192.168.2.2 225 3 E >>>> >>>> eth2 224.0.0.2 0.0.0.0 192.168.3.2 231 3 E >>>> >>>> eth2 224.0.0.13 0.0.0.0 192.168.3.2 231 3 E >>>> >>>> eth2 224.0.0.22 0.0.0.0 192.168.3.2 231 3 E >>>> >>>> eth2 239.1.1.1 0.0.0.0 192.168.3.10 228 3 E >>>> >>>> eth2 239.7.7.7 0.0.0.0 192.168.3.10 228 3 E >>>> >>>> eth2 239.255.255.250 0.0.0.0 192.168.3.10 228 3 E >>>> >>>> eth3 224.0.0.2 0.0.0.0 192.168.4.2 230 3 E >>>> >>>> eth3 224.0.0.13 0.0.0.0 192.168.4.2 230 3 E >>>> >>>> eth3 224.0.0.22 0.0.0.0 192.168.4.2 230 3 E >>>> >>>> root at p4080ds> >>>> >>>> 5) But the traffic is not receiving at H2. Below is the statistics >>>> related ip_mr on the device >>>> >>>> cat /proc/net/ip_mr* >>>> >>>> Group Origin Iif Pkts Bytes Wrong Oifs >>>> EF070707 C0A81111 3 453 614268 0 >>>> Interface BytesIn PktsIn BytesOut PktsOut Flags Local Remote >>>> 0 eth0 0 0 0 0 00000 C0A80102 00000000 >>>> 1 eth1 0 0 0 0 00000 C0A80202 00000000 >>>> 2 eth2 0 0 0 0 00000 C0A80302 00000000 >>>> 3 eth3 3971724 2929 0 0 00000 C0A80402 00000000 >>>> 4 pimreg 0 0 0 0 00004 C0A80102 >>>> >>>> >>>> 6) But, when the H1 ip is in the same subnet, traffic is properly >>>> forwarded to H2 without any issues. >>>> >>>> Did anybody tried this scenario ? >>>> >>>> Thanks, >>>> Ganesh >>>> >>>> _______________________________________________ >>>> Xorp-users mailing list >>>> Xorp-users at xorp.org >>>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users >>> >>> From igorm at etf.rs Thu Jul 5 09:34:03 2012 From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=) Date: Thu, 5 Jul 2012 18:34:03 +0200 Subject: [Xorp-users] Multicast traffic is not forwarded in a specific deployment as mentioned in the mail In-Reply-To: References: <82B681751FE46F4AB3FCA7390B780FD1051A6AE0@039-SN1MPN1-001.039d.mgd.msft.net> Message-ID: Ufffff... Xorp isn't doing any spoof checking in that I'm sure. To me, even if there aren't any discard packets logged, it still looks like reverse path filtering. Try this: sysctl -w net.ipv4.conf.default.rp_filter=0 if that doesn't work I really don't know what the problem is :) BR Igor 2012/7/5 Ganesh Reddy K : > Thanks a lot for the detailed inputs, > > I have added the routes as suggested, but still the traffic is not > forwarded . Did not observe any discards in ' netstat -s IP'. > > In general, When multicast UDP cache-miss occurs and subscriber > is listened for that group, Then only multicast routing services will > add the multicast ROUTE in linux kernel . The forwarding is taken care > by Linux routing mechanism. I guess, In this scenario, UDP cache > miss is properly given to XORP daemons, but could not fulfill the > entire route (i.e ip_mr_cache with valid Oif ) . There may be > possible spoof check in PIM daemons . > > Is my thought justifies the behavior ? > > ================ > netstat -s IP > Ip: > 67296 total packets received > 0 forwarded > 0 incoming packets discarded > 42784 incoming packets delivered > 41760 requests sent out > Icmp: > 0 ICMP messages received > 0 input ICMP message failed. > ICMP input histogram: > 0 ICMP messages sent > 0 ICMP messages failed > ICMP output histogram: > Tcp: > 50 active connections openings > 49 passive connection openings > 0 failed connection attempts > 0 connection resets received > 35 connections established > 40788 segments received > 39837 segments send out > 0 segments retransmited > 0 bad segments received. > 0 resets sent > Udp: > 0 packets received > 0 packets to unknown port received. > 0 packet receive errors > 0 packets sent > RcvbufErrors: 0 > SndbufErrors: 0 > UdpLite: > InDatagrams: 0 > NoPorts: 0 > InErrors: 0 > OutDatagrams: 0 > RcvbufErrors: 0 > SndbufErrors: 0 > error parsing /proc/net/snmp: Success > ================ > > On Thu, Jul 5, 2012 at 8:07 PM, Igor Maravi? wrote: >> sysctl -w net.ipv4.conf.eth3.rp_filter=0 >> sysctl -w net.ipv4.conf.eth2.rp_filter=0 >> sysctl -w net.ipv4.conf.all.rp_filter=0 >> sysctl -w net.ipv4.conf.default.rp_filter=0 >> >> for me, echo isn't working. I use this commands to set values. >> >> 2012/7/5 Igor Maravi? : >>> My bad... I forgot set protocols static part... >>> >>> command in xorpsh is >>> >>> #set protocols static interface-route 192.168.17.17/32 next-hop-interface eth3 >>> #set protocols static interface-route 192.168.17.17/32 next-hop-vif eth3 >>> >>> If my theory is ok when you send packets from H1 to H2, they are >>> dropped in Linux. >>> You can confirm this if you run >>> >>> netstat -s IP >>> >>> and you see that number of discarded IP packets is increasing. >>> My proposals are for that case. >>> BR >>> Igor >>> >>> 2012/7/5 Reddy Ganesh-B38514 : >>>> Echo 0 > /proc/sys/net/ipv4/conf/eth3/rp_filter >>>> Echo 0 > /proc/sys/net/ipv4/conf/eth2/rp_filter >>>> Echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter >>>> >>>> As per the step 1, I have Disabled the rp_filter on the Device. Still the problem persists. >>>> >>>> I tried to configure commands mentioned in step 2 also, But I could not locate the exact commands in xorp config shell. Did I miss anything ?? >>>> >>>> -----Original Message----- >>>> From: Igor Maravi? [mailto:igorm at etf.rs] >>>> Sent: Thursday, July 05, 2012 12:50 PM >>>> To: Ganesh Reddy K >>>> Cc: xorp-users at xorp.org; Bv Rajesh-B35907; nandakishoreie14 at gmail.com; Reddy Ganesh-B38514 >>>> Subject: Re: [Xorp-users] Multicast traffic is not forwarded in a specific deployment as mentioned in the mail >>>> >>>> I'm 99% sure that this isn't Xorp problem :) Linux, won't forward packets if the src address in packet is unknown to him. >>>> So, at least I think that, you have 2 possible solutions: >>>> 1. Turn off rp filtering on Xorp box (reference - >>>> http://lartc.org/howto/lartc.kernel.html) >>>> 2. Set static interface route to 192.168.17.17/32 on eth3, with Xorp ( >>>> interface-route 192.168.17.17/32 { >>>> next-hop-interface: "eth3" >>>> next-hop-vif: "eth3" >>>> } >>>> ) >>>> >>>> Let me know if it worked. :) >>>> BR >>>> Igor >>>> >>>> 2012/7/5 Ganesh Reddy K : >>>>> Hi , >>>>> >>>>> We are trying to exercise a multicast traffic forwarding scenario on >>>>> a powerPC device:-- >>>>> >>>>> After H2 subscribed for the Group G1, The G1 multicast traffic is not >>>>> receiving at H2. But, when the H1 ip is in the same subnet, traffic >>>>> is properly forwarded to H2 without any issues. >>>>> >>>>> Test setup:-- >>>>> >>>>> H1 ------------------------------------ eth3 XORP eth2 >>>>> -------------------------------------------- H2 >>>>> >>>>> 192.168.17.17 192.168.4.2 192.168.3.2 >>>>> 192.168.3.10 >>>>> >>>>> UDP-G1 multicaststream >>>>> Mcast listener for G1 >>>>> >>>>> G1-239.7.7.7 >>>>> >>>>> >>>>> 1) COnfigured XORP on the device, xorp.conf contents are . >>>>> >>>>> ===========XORP configuration =========== >>>>> >>>>> protocols { >>>>> fib2mrib { >>>>> } >>>>> igmp { >>>>> >>>>> interface eth0 { >>>>> vif eth0 { >>>>> version: 3 >>>>> } >>>>> } >>>>> interface eth1 { >>>>> vif eth1 { >>>>> version: 3 >>>>> } >>>>> } >>>>> interface eth2 { >>>>> vif eth2 { >>>>> version: 3 >>>>> } >>>>> } >>>>> interface eth3 { >>>>> >>>>> vif eth3 { >>>>> version: 3 >>>>> } >>>>> } } >>>>> >>>>> >>>>> pimsm4 { >>>>> interface eth0 { >>>>> >>>>> vif eth0 { >>>>> } >>>>> } >>>>> interface "register_vif" { >>>>> vif "register_vif" { >>>>> } >>>>> >>>>> } >>>>> interface eth1 { >>>>> vif eth1 { >>>>> >>>>> } >>>>> } >>>>> interface eth2 { >>>>> vif eth2 { >>>>> } >>>>> } >>>>> interface eth3 { >>>>> >>>>> vif eth3 { >>>>> } >>>>> } >>>>> } >>>>> } >>>>> fea { >>>>> unicast-forwarding4 { >>>>> } >>>>> >>>>> >>>>> unicast-forwarding6 { >>>>> } >>>>> } >>>>> interfaces { >>>>> interface eth0 { >>>>> vif eth0 { >>>>> } >>>>> >>>>> default-system-config { >>>>> } >>>>> } >>>>> interface eth1 { >>>>> >>>>> vif eth1 { >>>>> } >>>>> default-system-config { >>>>> } >>>>> } >>>>> interface eth2 { >>>>> vif eth2 { >>>>> >>>>> } >>>>> default-system-config { >>>>> } >>>>> } >>>>> >>>>> interface eth3 { >>>>> vif eth3 { >>>>> } >>>>> >>>>> default-system-config { >>>>> } >>>>> } >>>>> } >>>>> plumbing { >>>>> >>>>> mfea4 { >>>>> interface eth0 { >>>>> vif eth0 { >>>>> >>>>> } >>>>> } >>>>> interface "register_vif" { >>>>> >>>>> vif "register_vif" { >>>>> } >>>>> } >>>>> >>>>> interface eth1 { >>>>> vif eth1 { >>>>> } >>>>> >>>>> } >>>>> >>>>> interface eth2 { >>>>> vif eth2 { >>>>> } >>>>> >>>>> } >>>>> interface eth3 { >>>>> vif eth3 { >>>>> >>>>> } >>>>> } >>>>> } >>>>> } >>>>> >>>>> ============= xorp configuration ============= >>>>> >>>>> 2) From H1, started sending UDP stream targeting G1 using VLC player. >>>>> >>>>> Capture of "tcpdump -ni eth3" on Device shows the UDP-G1 packets as >>>>> below .. >>>>> 09:27:50.081561 IP 192.168.17.17.4146 > 239.7.7.7.1234: UDP, length >>>>> 1328 .. >>>>> >>>>> 3) added a static route for the unknown network on Device (i.e route >>>>> add -net 192.168.17.17/32 dev eth3) >>>>> >>>>> 4) From H2, started VLC listener for the group G1. >>>>> >>>>> It is verified in the Device that, IGMP join is received. >>>>> capture of " show igmp group" on XORP console >>>>> >>>>> Interface Group Source LastReported Timeout V State >>>>> >>>>> eth0 224.0.0.2 0.0.0.0 192.168.1.2 223 3 E >>>>> >>>>> eth0 224.0.0.13 0.0.0.0 192.168.1.2 223 3 E >>>>> >>>>> eth0 224.0.0.22 0.0.0.0 192.168.1.2 223 3 E >>>>> >>>>> eth1 224.0.0.2 0.0.0.0 192.168.2.2 225 3 E >>>>> >>>>> eth1 224.0.0.13 0.0.0.0 192.168.2.2 225 3 E >>>>> >>>>> eth1 224.0.0.22 0.0.0.0 192.168.2.2 225 3 E >>>>> >>>>> eth2 224.0.0.2 0.0.0.0 192.168.3.2 231 3 E >>>>> >>>>> eth2 224.0.0.13 0.0.0.0 192.168.3.2 231 3 E >>>>> >>>>> eth2 224.0.0.22 0.0.0.0 192.168.3.2 231 3 E >>>>> >>>>> eth2 239.1.1.1 0.0.0.0 192.168.3.10 228 3 E >>>>> >>>>> eth2 239.7.7.7 0.0.0.0 192.168.3.10 228 3 E >>>>> >>>>> eth2 239.255.255.250 0.0.0.0 192.168.3.10 228 3 E >>>>> >>>>> eth3 224.0.0.2 0.0.0.0 192.168.4.2 230 3 E >>>>> >>>>> eth3 224.0.0.13 0.0.0.0 192.168.4.2 230 3 E >>>>> >>>>> eth3 224.0.0.22 0.0.0.0 192.168.4.2 230 3 E >>>>> >>>>> root at p4080ds> >>>>> >>>>> 5) But the traffic is not receiving at H2. Below is the statistics >>>>> related ip_mr on the device >>>>> >>>>> cat /proc/net/ip_mr* >>>>> >>>>> Group Origin Iif Pkts Bytes Wrong Oifs >>>>> EF070707 C0A81111 3 453 614268 0 >>>>> Interface BytesIn PktsIn BytesOut PktsOut Flags Local Remote >>>>> 0 eth0 0 0 0 0 00000 C0A80102 00000000 >>>>> 1 eth1 0 0 0 0 00000 C0A80202 00000000 >>>>> 2 eth2 0 0 0 0 00000 C0A80302 00000000 >>>>> 3 eth3 3971724 2929 0 0 00000 C0A80402 00000000 >>>>> 4 pimreg 0 0 0 0 00004 C0A80102 >>>>> >>>>> >>>>> 6) But, when the H1 ip is in the same subnet, traffic is properly >>>>> forwarded to H2 without any issues. >>>>> >>>>> Did anybody tried this scenario ? >>>>> >>>>> Thanks, >>>>> Ganesh >>>>> >>>>> _______________________________________________ >>>>> Xorp-users mailing list >>>>> Xorp-users at xorp.org >>>>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users >>>> >>>> From ganeshreddyk at gmail.com Thu Jul 5 22:03:33 2012 From: ganeshreddyk at gmail.com (Ganesh Reddy K) Date: Fri, 6 Jul 2012 10:33:33 +0530 Subject: [Xorp-users] Multicast traffic is not forwarded in a specific deployment as mentioned in the mail In-Reply-To: References: <82B681751FE46F4AB3FCA7390B780FD1051A6AE0@039-SN1MPN1-001.039d.mgd.msft.net> Message-ID: Tried this one also, but no progress on this. I hope there is something is happening, need to confirm either expected behavior of XORP/Linux or It is known Issue. I will check implementation details. Thanks in advance, Any quick suggestions welcome.. During this testcase, we are observing XORP statistics on the device are as followss ============================================================ show igmp group Interface Group Source LastReported Timeout V State eth0 224.0.0.2 0.0.0.0 192.168.1.100 157 3 E eth0 224.0.0.13 0.0.0.0 192.168.1.100 157 3 E eth0 224.0.0.22 0.0.0.0 192.168.1.100 157 3 E eth0 224.0.0.251 0.0.0.0 192.168.1.50 160 3 E eth0 239.11.11.11 0.0.0.0 192.168.1.50 160 3 E eth1 224.0.0.2 0.0.0.0 192.168.2.100 155 3 E eth1 224.0.0.13 0.0.0.0 192.168.2.100 155 3 E eth1 224.0.0.22 0.0.0.0 192.168.2.100 155 3 E eth2 224.0.0.2 0.0.0.0 192.168.3.100 158 3 E eth2 224.0.0.13 0.0.0.0 192.168.3.100 158 3 E eth2 224.0.0.22 0.0.0.0 192.168.3.100 158 3 E eth3 224.0.0.2 0.0.0.0 192.168.4.100 161 3 E eth3 224.0.0.13 0.0.0.0 192.168.4.100 161 3 E eth3 224.0.0.22 0.0.0.0 192.168.4.100 161 3 E show mfea dataflow Group Source 239.11.11.11 192.168.11.54 Measured(Start|Packets|Bytes) Type Thresh(Interval|Packets|Bytes) Remain 56253.252679|627|? <= 210.0|0|? 170.767324 show mfea interface Interface State Vif/PifIndex Addr Flags eth0 UP 0/4 192.168.1.100 MULTICAST BROADCAST KERN_UP eth1 UP 1/3 192.168.2.100 MULTICAST BROADCAST KERN_UP eth2 UP 2/5 192.168.3.100 MULTICAST BROADCAST KERN_UP eth3 UP 3/7 192.168.4.100 MULTICAST BROADCAST KERN_UP register_vif UP 4/4 192.168.1.100 PIM_REGISTER KERN_UP ============================================================ On Thu, Jul 5, 2012 at 10:04 PM, Igor Maravi? wrote: > Ufffff... Xorp isn't doing any spoof checking in that I'm sure. > To me, even if there aren't any discard packets logged, > it still looks like reverse path filtering. > > Try this: > > sysctl -w net.ipv4.conf.default.rp_filter=0 > > if that doesn't work I really don't know what the problem is :) > BR > Igor > > 2012/7/5 Ganesh Reddy K : >> Thanks a lot for the detailed inputs, >> >> I have added the routes as suggested, but still the traffic is not >> forwarded . Did not observe any discards in ' netstat -s IP'. >> >> In general, When multicast UDP cache-miss occurs and subscriber >> is listened for that group, Then only multicast routing services will >> add the multicast ROUTE in linux kernel . The forwarding is taken care >> by Linux routing mechanism. I guess, In this scenario, UDP cache >> miss is properly given to XORP daemons, but could not fulfill the >> entire route (i.e ip_mr_cache with valid Oif ) . There may be >> possible spoof check in PIM daemons . >> >> Is my thought justifies the behavior ? >> >> ================ >> netstat -s IP >> Ip: >> 67296 total packets received >> 0 forwarded >> 0 incoming packets discarded >> 42784 incoming packets delivered >> 41760 requests sent out >> Icmp: >> 0 ICMP messages received >> 0 input ICMP message failed. >> ICMP input histogram: >> 0 ICMP messages sent >> 0 ICMP messages failed >> ICMP output histogram: >> Tcp: >> 50 active connections openings >> 49 passive connection openings >> 0 failed connection attempts >> 0 connection resets received >> 35 connections established >> 40788 segments received >> 39837 segments send out >> 0 segments retransmited >> 0 bad segments received. >> 0 resets sent >> Udp: >> 0 packets received >> 0 packets to unknown port received. >> 0 packet receive errors >> 0 packets sent >> RcvbufErrors: 0 >> SndbufErrors: 0 >> UdpLite: >> InDatagrams: 0 >> NoPorts: 0 >> InErrors: 0 >> OutDatagrams: 0 >> RcvbufErrors: 0 >> SndbufErrors: 0 >> error parsing /proc/net/snmp: Success >> ================ >> >> On Thu, Jul 5, 2012 at 8:07 PM, Igor Maravi? wrote: >>> sysctl -w net.ipv4.conf.eth3.rp_filter=0 >>> sysctl -w net.ipv4.conf.eth2.rp_filter=0 >>> sysctl -w net.ipv4.conf.all.rp_filter=0 >>> sysctl -w net.ipv4.conf.default.rp_filter=0 >>> >>> for me, echo isn't working. I use this commands to set values. >>> >>> 2012/7/5 Igor Maravi? : >>>> My bad... I forgot set protocols static part... >>>> >>>> command in xorpsh is >>>> >>>> #set protocols static interface-route 192.168.17.17/32 next-hop-interface eth3 >>>> #set protocols static interface-route 192.168.17.17/32 next-hop-vif eth3 >>>> >>>> If my theory is ok when you send packets from H1 to H2, they are >>>> dropped in Linux. >>>> You can confirm this if you run >>>> >>>> netstat -s IP >>>> >>>> and you see that number of discarded IP packets is increasing. >>>> My proposals are for that case. >>>> BR >>>> Igor >>>> >>>> 2012/7/5 Reddy Ganesh-B38514 : >>>>> Echo 0 > /proc/sys/net/ipv4/conf/eth3/rp_filter >>>>> Echo 0 > /proc/sys/net/ipv4/conf/eth2/rp_filter >>>>> Echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter >>>>> >>>>> As per the step 1, I have Disabled the rp_filter on the Device. Still the problem persists. >>>>> >>>>> I tried to configure commands mentioned in step 2 also, But I could not locate the exact commands in xorp config shell. Did I miss anything ?? >>>>> >>>>> -----Original Message----- >>>>> From: Igor Maravi? [mailto:igorm at etf.rs] >>>>> Sent: Thursday, July 05, 2012 12:50 PM >>>>> To: Ganesh Reddy K >>>>> Cc: xorp-users at xorp.org; Bv Rajesh-B35907; nandakishoreie14 at gmail.com; Reddy Ganesh-B38514 >>>>> Subject: Re: [Xorp-users] Multicast traffic is not forwarded in a specific deployment as mentioned in the mail >>>>> >>>>> I'm 99% sure that this isn't Xorp problem :) Linux, won't forward packets if the src address in packet is unknown to him. >>>>> So, at least I think that, you have 2 possible solutions: >>>>> 1. Turn off rp filtering on Xorp box (reference - >>>>> http://lartc.org/howto/lartc.kernel.html) >>>>> 2. Set static interface route to 192.168.17.17/32 on eth3, with Xorp ( >>>>> interface-route 192.168.17.17/32 { >>>>> next-hop-interface: "eth3" >>>>> next-hop-vif: "eth3" >>>>> } >>>>> ) >>>>> >>>>> Let me know if it worked. :) >>>>> BR >>>>> Igor >>>>> >>>>> 2012/7/5 Ganesh Reddy K : >>>>>> Hi , >>>>>> >>>>>> We are trying to exercise a multicast traffic forwarding scenario on >>>>>> a powerPC device:-- >>>>>> >>>>>> After H2 subscribed for the Group G1, The G1 multicast traffic is not >>>>>> receiving at H2. But, when the H1 ip is in the same subnet, traffic >>>>>> is properly forwarded to H2 without any issues. >>>>>> >>>>>> Test setup:-- >>>>>> >>>>>> H1 ------------------------------------ eth3 XORP eth2 >>>>>> -------------------------------------------- H2 >>>>>> >>>>>> 192.168.17.17 192.168.4.2 192.168.3.2 >>>>>> 192.168.3.10 >>>>>> >>>>>> UDP-G1 multicaststream >>>>>> Mcast listener for G1 >>>>>> >>>>>> G1-239.7.7.7 >>>>>> >>>>>> >>>>>> 1) COnfigured XORP on the device, xorp.conf contents are . >>>>>> >>>>>> ===========XORP configuration =========== >>>>>> >>>>>> protocols { >>>>>> fib2mrib { >>>>>> } >>>>>> igmp { >>>>>> >>>>>> interface eth0 { >>>>>> vif eth0 { >>>>>> version: 3 >>>>>> } >>>>>> } >>>>>> interface eth1 { >>>>>> vif eth1 { >>>>>> version: 3 >>>>>> } >>>>>> } >>>>>> interface eth2 { >>>>>> vif eth2 { >>>>>> version: 3 >>>>>> } >>>>>> } >>>>>> interface eth3 { >>>>>> >>>>>> vif eth3 { >>>>>> version: 3 >>>>>> } >>>>>> } } >>>>>> >>>>>> >>>>>> pimsm4 { >>>>>> interface eth0 { >>>>>> >>>>>> vif eth0 { >>>>>> } >>>>>> } >>>>>> interface "register_vif" { >>>>>> vif "register_vif" { >>>>>> } >>>>>> >>>>>> } >>>>>> interface eth1 { >>>>>> vif eth1 { >>>>>> >>>>>> } >>>>>> } >>>>>> interface eth2 { >>>>>> vif eth2 { >>>>>> } >>>>>> } >>>>>> interface eth3 { >>>>>> >>>>>> vif eth3 { >>>>>> } >>>>>> } >>>>>> } >>>>>> } >>>>>> fea { >>>>>> unicast-forwarding4 { >>>>>> } >>>>>> >>>>>> >>>>>> unicast-forwarding6 { >>>>>> } >>>>>> } >>>>>> interfaces { >>>>>> interface eth0 { >>>>>> vif eth0 { >>>>>> } >>>>>> >>>>>> default-system-config { >>>>>> } >>>>>> } >>>>>> interface eth1 { >>>>>> >>>>>> vif eth1 { >>>>>> } >>>>>> default-system-config { >>>>>> } >>>>>> } >>>>>> interface eth2 { >>>>>> vif eth2 { >>>>>> >>>>>> } >>>>>> default-system-config { >>>>>> } >>>>>> } >>>>>> >>>>>> interface eth3 { >>>>>> vif eth3 { >>>>>> } >>>>>> >>>>>> default-system-config { >>>>>> } >>>>>> } >>>>>> } >>>>>> plumbing { >>>>>> >>>>>> mfea4 { >>>>>> interface eth0 { >>>>>> vif eth0 { >>>>>> >>>>>> } >>>>>> } >>>>>> interface "register_vif" { >>>>>> >>>>>> vif "register_vif" { >>>>>> } >>>>>> } >>>>>> >>>>>> interface eth1 { >>>>>> vif eth1 { >>>>>> } >>>>>> >>>>>> } >>>>>> >>>>>> interface eth2 { >>>>>> vif eth2 { >>>>>> } >>>>>> >>>>>> } >>>>>> interface eth3 { >>>>>> vif eth3 { >>>>>> >>>>>> } >>>>>> } >>>>>> } >>>>>> } >>>>>> >>>>>> ============= xorp configuration ============= >>>>>> >>>>>> 2) From H1, started sending UDP stream targeting G1 using VLC player. >>>>>> >>>>>> Capture of "tcpdump -ni eth3" on Device shows the UDP-G1 packets as >>>>>> below .. >>>>>> 09:27:50.081561 IP 192.168.17.17.4146 > 239.7.7.7.1234: UDP, length >>>>>> 1328 .. >>>>>> >>>>>> 3) added a static route for the unknown network on Device (i.e route >>>>>> add -net 192.168.17.17/32 dev eth3) >>>>>> >>>>>> 4) From H2, started VLC listener for the group G1. >>>>>> >>>>>> It is verified in the Device that, IGMP join is received. >>>>>> capture of " show igmp group" on XORP console >>>>>> >>>>>> Interface Group Source LastReported Timeout V State >>>>>> >>>>>> eth0 224.0.0.2 0.0.0.0 192.168.1.2 223 3 E >>>>>> >>>>>> eth0 224.0.0.13 0.0.0.0 192.168.1.2 223 3 E >>>>>> >>>>>> eth0 224.0.0.22 0.0.0.0 192.168.1.2 223 3 E >>>>>> >>>>>> eth1 224.0.0.2 0.0.0.0 192.168.2.2 225 3 E >>>>>> >>>>>> eth1 224.0.0.13 0.0.0.0 192.168.2.2 225 3 E >>>>>> >>>>>> eth1 224.0.0.22 0.0.0.0 192.168.2.2 225 3 E >>>>>> >>>>>> eth2 224.0.0.2 0.0.0.0 192.168.3.2 231 3 E >>>>>> >>>>>> eth2 224.0.0.13 0.0.0.0 192.168.3.2 231 3 E >>>>>> >>>>>> eth2 224.0.0.22 0.0.0.0 192.168.3.2 231 3 E >>>>>> >>>>>> eth2 239.1.1.1 0.0.0.0 192.168.3.10 228 3 E >>>>>> >>>>>> eth2 239.7.7.7 0.0.0.0 192.168.3.10 228 3 E >>>>>> >>>>>> eth2 239.255.255.250 0.0.0.0 192.168.3.10 228 3 E >>>>>> >>>>>> eth3 224.0.0.2 0.0.0.0 192.168.4.2 230 3 E >>>>>> >>>>>> eth3 224.0.0.13 0.0.0.0 192.168.4.2 230 3 E >>>>>> >>>>>> eth3 224.0.0.22 0.0.0.0 192.168.4.2 230 3 E >>>>>> >>>>>> root at p4080ds> >>>>>> >>>>>> 5) But the traffic is not receiving at H2. Below is the statistics >>>>>> related ip_mr on the device >>>>>> >>>>>> cat /proc/net/ip_mr* >>>>>> >>>>>> Group Origin Iif Pkts Bytes Wrong Oifs >>>>>> EF070707 C0A81111 3 453 614268 0 >>>>>> Interface BytesIn PktsIn BytesOut PktsOut Flags Local Remote >>>>>> 0 eth0 0 0 0 0 00000 C0A80102 00000000 >>>>>> 1 eth1 0 0 0 0 00000 C0A80202 00000000 >>>>>> 2 eth2 0 0 0 0 00000 C0A80302 00000000 >>>>>> 3 eth3 3971724 2929 0 0 00000 C0A80402 00000000 >>>>>> 4 pimreg 0 0 0 0 00004 C0A80102 >>>>>> >>>>>> >>>>>> 6) But, when the H1 ip is in the same subnet, traffic is properly >>>>>> forwarded to H2 without any issues. >>>>>> >>>>>> Did anybody tried this scenario ? >>>>>> >>>>>> Thanks, >>>>>> Ganesh >>>>>> >>>>>> _______________________________________________ >>>>>> Xorp-users mailing list >>>>>> Xorp-users at xorp.org >>>>>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users >>>>> >>>>> From danro at kth.se Fri Jul 6 10:00:35 2012 From: danro at kth.se (Dan Rosenqvist) Date: Fri, 6 Jul 2012 17:00:35 +0000 Subject: [Xorp-users] Multicast traffic is not forwarded in a specific deployment as mentioned in the mail In-Reply-To: References: <82B681751FE46F4AB3FCA7390B780FD1051A6AE0@039-SN1MPN1-001.039d.mgd.msft.net> , Message-ID: <54DD4F682C240845BF5F7D0EECBDB6F20839A4D4@EXDB3.ug.kth.se> Hi, I think the problem you're experiencing is due to the lack of a rendez-vous point (RP). You can use either static RPs or use the bootstrap mechanism. For guidance, please have a look at the examples in www.xorp.org/config (think there should be some examples for both static and bootstrap). Regards, Dan ________________________________________ Fr?n: xorp-users-bounces at xorp.org [xorp-users-bounces at xorp.org] för Ganesh Reddy K [ganeshreddyk at gmail.com] Skickat: den 6 juli 2012 07:03 Till: igorm at etf.rs; xorp-users at xorp.org Kopia: Bv Rajesh-B35907; sridhar pothuganti; nandakishoreie14 at gmail.com; Reddy Ganesh-B38514 ?mne: Re: [Xorp-users] Multicast traffic is not forwarded in a specific deployment as mentioned in the mail Tried this one also, but no progress on this. I hope there is something is happening, need to confirm either expected behavior of XORP/Linux or It is known Issue. I will check implementation details. Thanks in advance, Any quick suggestions welcome.. During this testcase, we are observing XORP statistics on the device are as followss ============================================================ show igmp group Interface Group Source LastReported Timeout V State eth0 224.0.0.2 0.0.0.0 192.168.1.100 157 3 E eth0 224.0.0.13 0.0.0.0 192.168.1.100 157 3 E eth0 224.0.0.22 0.0.0.0 192.168.1.100 157 3 E eth0 224.0.0.251 0.0.0.0 192.168.1.50 160 3 E eth0 239.11.11.11 0.0.0.0 192.168.1.50 160 3 E eth1 224.0.0.2 0.0.0.0 192.168.2.100 155 3 E eth1 224.0.0.13 0.0.0.0 192.168.2.100 155 3 E eth1 224.0.0.22 0.0.0.0 192.168.2.100 155 3 E eth2 224.0.0.2 0.0.0.0 192.168.3.100 158 3 E eth2 224.0.0.13 0.0.0.0 192.168.3.100 158 3 E eth2 224.0.0.22 0.0.0.0 192.168.3.100 158 3 E eth3 224.0.0.2 0.0.0.0 192.168.4.100 161 3 E eth3 224.0.0.13 0.0.0.0 192.168.4.100 161 3 E eth3 224.0.0.22 0.0.0.0 192.168.4.100 161 3 E show mfea dataflow Group Source 239.11.11.11 192.168.11.54 Measured(Start|Packets|Bytes) Type Thresh(Interval|Packets|Bytes) Remain 56253.252679|627|? <= 210.0|0|? 170.767324 show mfea interface Interface State Vif/PifIndex Addr Flags eth0 UP 0/4 192.168.1.100 MULTICAST BROADCAST KERN_UP eth1 UP 1/3 192.168.2.100 MULTICAST BROADCAST KERN_UP eth2 UP 2/5 192.168.3.100 MULTICAST BROADCAST KERN_UP eth3 UP 3/7 192.168.4.100 MULTICAST BROADCAST KERN_UP register_vif UP 4/4 192.168.1.100 PIM_REGISTER KERN_UP ============================================================ On Thu, Jul 5, 2012 at 10:04 PM, Igor Maravi? wrote: > Ufffff... Xorp isn't doing any spoof checking in that I'm sure. > To me, even if there aren't any discard packets logged, > it still looks like reverse path filtering. > > Try this: > > sysctl -w net.ipv4.conf.default.rp_filter=0 > > if that doesn't work I really don't know what the problem is :) > BR > Igor > > 2012/7/5 Ganesh Reddy K : >> Thanks a lot for the detailed inputs, >> >> I have added the routes as suggested, but still the traffic is not >> forwarded . Did not observe any discards in ' netstat -s IP'. >> >> In general, When multicast UDP cache-miss occurs and subscriber >> is listened for that group, Then only multicast routing services will >> add the multicast ROUTE in linux kernel . The forwarding is taken care >> by Linux routing mechanism. I guess, In this scenario, UDP cache >> miss is properly given to XORP daemons, but could not fulfill the >> entire route (i.e ip_mr_cache with valid Oif ) . There may be >> possible spoof check in PIM daemons . >> >> Is my thought justifies the behavior ? >> >> ================ >> netstat -s IP >> Ip: >> 67296 total packets received >> 0 forwarded >> 0 incoming packets discarded >> 42784 incoming packets delivered >> 41760 requests sent out >> Icmp: >> 0 ICMP messages received >> 0 input ICMP message failed. >> ICMP input histogram: >> 0 ICMP messages sent >> 0 ICMP messages failed >> ICMP output histogram: >> Tcp: >> 50 active connections openings >> 49 passive connection openings >> 0 failed connection attempts >> 0 connection resets received >> 35 connections established >> 40788 segments received >> 39837 segments send out >> 0 segments retransmited >> 0 bad segments received. >> 0 resets sent >> Udp: >> 0 packets received >> 0 packets to unknown port received. >> 0 packet receive errors >> 0 packets sent >> RcvbufErrors: 0 >> SndbufErrors: 0 >> UdpLite: >> InDatagrams: 0 >> NoPorts: 0 >> InErrors: 0 >> OutDatagrams: 0 >> RcvbufErrors: 0 >> SndbufErrors: 0 >> error parsing /proc/net/snmp: Success >> ================ >> >> On Thu, Jul 5, 2012 at 8:07 PM, Igor Maravi? wrote: >>> sysctl -w net.ipv4.conf.eth3.rp_filter=0 >>> sysctl -w net.ipv4.conf.eth2.rp_filter=0 >>> sysctl -w net.ipv4.conf.all.rp_filter=0 >>> sysctl -w net.ipv4.conf.default.rp_filter=0 >>> >>> for me, echo isn't working. I use this commands to set values. >>> >>> 2012/7/5 Igor Maravi? : >>>> My bad... I forgot set protocols static part... >>>> >>>> command in xorpsh is >>>> >>>> #set protocols static interface-route 192.168.17.17/32 next-hop-interface eth3 >>>> #set protocols static interface-route 192.168.17.17/32 next-hop-vif eth3 >>>> >>>> If my theory is ok when you send packets from H1 to H2, they are >>>> dropped in Linux. >>>> You can confirm this if you run >>>> >>>> netstat -s IP >>>> >>>> and you see that number of discarded IP packets is increasing. >>>> My proposals are for that case. >>>> BR >>>> Igor >>>> >>>> 2012/7/5 Reddy Ganesh-B38514 : >>>>> Echo 0 > /proc/sys/net/ipv4/conf/eth3/rp_filter >>>>> Echo 0 > /proc/sys/net/ipv4/conf/eth2/rp_filter >>>>> Echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter >>>>> >>>>> As per the step 1, I have Disabled the rp_filter on the Device. Still the problem persists. >>>>> >>>>> I tried to configure commands mentioned in step 2 also, But I could not locate the exact commands in xorp config shell. Did I miss anything ?? >>>>> >>>>> -----Original Message----- >>>>> From: Igor Maravi? [mailto:igorm at etf.rs] >>>>> Sent: Thursday, July 05, 2012 12:50 PM >>>>> To: Ganesh Reddy K >>>>> Cc: xorp-users at xorp.org; Bv Rajesh-B35907; nandakishoreie14 at gmail.com; Reddy Ganesh-B38514 >>>>> Subject: Re: [Xorp-users] Multicast traffic is not forwarded in a specific deployment as mentioned in the mail >>>>> >>>>> I'm 99% sure that this isn't Xorp problem :) Linux, won't forward packets if the src address in packet is unknown to him. >>>>> So, at least I think that, you have 2 possible solutions: >>>>> 1. Turn off rp filtering on Xorp box (reference - >>>>> http://lartc.org/howto/lartc.kernel.html) >>>>> 2. Set static interface route to 192.168.17.17/32 on eth3, with Xorp ( >>>>> interface-route 192.168.17.17/32 { >>>>> next-hop-interface: "eth3" >>>>> next-hop-vif: "eth3" >>>>> } >>>>> ) >>>>> >>>>> Let me know if it worked. :) >>>>> BR >>>>> Igor >>>>> >>>>> 2012/7/5 Ganesh Reddy K : >>>>>> Hi , >>>>>> >>>>>> We are trying to exercise a multicast traffic forwarding scenario on >>>>>> a powerPC device:-- >>>>>> >>>>>> After H2 subscribed for the Group G1, The G1 multicast traffic is not >>>>>> receiving at H2. But, when the H1 ip is in the same subnet, traffic >>>>>> is properly forwarded to H2 without any issues. >>>>>> >>>>>> Test setup:-- >>>>>> >>>>>> H1 ------------------------------------ eth3 XORP eth2 >>>>>> -------------------------------------------- H2 >>>>>> >>>>>> 192.168.17.17 192.168.4.2 192.168.3.2 >>>>>> 192.168.3.10 >>>>>> >>>>>> UDP-G1 multicaststream >>>>>> Mcast listener for G1 >>>>>> >>>>>> G1-239.7.7.7 >>>>>> >>>>>> >>>>>> 1) COnfigured XORP on the device, xorp.conf contents are . >>>>>> >>>>>> ===========XORP configuration =========== >>>>>> >>>>>> protocols { >>>>>> fib2mrib { >>>>>> } >>>>>> igmp { >>>>>> >>>>>> interface eth0 { >>>>>> vif eth0 { >>>>>> version: 3 >>>>>> } >>>>>> } >>>>>> interface eth1 { >>>>>> vif eth1 { >>>>>> version: 3 >>>>>> } >>>>>> } >>>>>> interface eth2 { >>>>>> vif eth2 { >>>>>> version: 3 >>>>>> } >>>>>> } >>>>>> interface eth3 { >>>>>> >>>>>> vif eth3 { >>>>>> version: 3 >>>>>> } >>>>>> } } >>>>>> >>>>>> >>>>>> pimsm4 { >>>>>> interface eth0 { >>>>>> >>>>>> vif eth0 { >>>>>> } >>>>>> } >>>>>> interface "register_vif" { >>>>>> vif "register_vif" { >>>>>> } >>>>>> >>>>>> } >>>>>> interface eth1 { >>>>>> vif eth1 { >>>>>> >>>>>> } >>>>>> } >>>>>> interface eth2 { >>>>>> vif eth2 { >>>>>> } >>>>>> } >>>>>> interface eth3 { >>>>>> >>>>>> vif eth3 { >>>>>> } >>>>>> } >>>>>> } >>>>>> } >>>>>> fea { >>>>>> unicast-forwarding4 { >>>>>> } >>>>>> >>>>>> >>>>>> unicast-forwarding6 { >>>>>> } >>>>>> } >>>>>> interfaces { >>>>>> interface eth0 { >>>>>> vif eth0 { >>>>>> } >>>>>> >>>>>> default-system-config { >>>>>> } >>>>>> } >>>>>> interface eth1 { >>>>>> >>>>>> vif eth1 { >>>>>> } >>>>>> default-system-config { >>>>>> } >>>>>> } >>>>>> interface eth2 { >>>>>> vif eth2 { >>>>>> >>>>>> } >>>>>> default-system-config { >>>>>> } >>>>>> } >>>>>> >>>>>> interface eth3 { >>>>>> vif eth3 { >>>>>> } >>>>>> >>>>>> default-system-config { >>>>>> } >>>>>> } >>>>>> } >>>>>> plumbing { >>>>>> >>>>>> mfea4 { >>>>>> interface eth0 { >>>>>> vif eth0 { >>>>>> >>>>>> } >>>>>> } >>>>>> interface "register_vif" { >>>>>> >>>>>> vif "register_vif" { >>>>>> } >>>>>> } >>>>>> >>>>>> interface eth1 { >>>>>> vif eth1 { >>>>>> } >>>>>> >>>>>> } >>>>>> >>>>>> interface eth2 { >>>>>> vif eth2 { >>>>>> } >>>>>> >>>>>> } >>>>>> interface eth3 { >>>>>> vif eth3 { >>>>>> >>>>>> } >>>>>> } >>>>>> } >>>>>> } >>>>>> >>>>>> ============= xorp configuration ============= >>>>>> >>>>>> 2) From H1, started sending UDP stream targeting G1 using VLC player. >>>>>> >>>>>> Capture of "tcpdump -ni eth3" on Device shows the UDP-G1 packets as >>>>>> below .. >>>>>> 09:27:50.081561 IP 192.168.17.17.4146 > 239.7.7.7.1234: UDP, length >>>>>> 1328 .. >>>>>> >>>>>> 3) added a static route for the unknown network on Device (i.e route >>>>>> add -net 192.168.17.17/32 dev eth3) >>>>>> >>>>>> 4) From H2, started VLC listener for the group G1. >>>>>> >>>>>> It is verified in the Device that, IGMP join is received. >>>>>> capture of " show igmp group" on XORP console >>>>>> >>>>>> Interface Group Source LastReported Timeout V State >>>>>> >>>>>> eth0 224.0.0.2 0.0.0.0 192.168.1.2 223 3 E >>>>>> >>>>>> eth0 224.0.0.13 0.0.0.0 192.168.1.2 223 3 E >>>>>> >>>>>> eth0 224.0.0.22 0.0.0.0 192.168.1.2 223 3 E >>>>>> >>>>>> eth1 224.0.0.2 0.0.0.0 192.168.2.2 225 3 E >>>>>> >>>>>> eth1 224.0.0.13 0.0.0.0 192.168.2.2 225 3 E >>>>>> >>>>>> eth1 224.0.0.22 0.0.0.0 192.168.2.2 225 3 E >>>>>> >>>>>> eth2 224.0.0.2 0.0.0.0 192.168.3.2 231 3 E >>>>>> >>>>>> eth2 224.0.0.13 0.0.0.0 192.168.3.2 231 3 E >>>>>> >>>>>> eth2 224.0.0.22 0.0.0.0 192.168.3.2 231 3 E >>>>>> >>>>>> eth2 239.1.1.1 0.0.0.0 192.168.3.10 228 3 E >>>>>> >>>>>> eth2 239.7.7.7 0.0.0.0 192.168.3.10 228 3 E >>>>>> >>>>>> eth2 239.255.255.250 0.0.0.0 192.168.3.10 228 3 E >>>>>> >>>>>> eth3 224.0.0.2 0.0.0.0 192.168.4.2 230 3 E >>>>>> >>>>>> eth3 224.0.0.13 0.0.0.0 192.168.4.2 230 3 E >>>>>> >>>>>> eth3 224.0.0.22 0.0.0.0 192.168.4.2 230 3 E >>>>>> >>>>>> root at p4080ds> >>>>>> >>>>>> 5) But the traffic is not receiving at H2. Below is the statistics >>>>>> related ip_mr on the device >>>>>> >>>>>> cat /proc/net/ip_mr* >>>>>> >>>>>> Group Origin Iif Pkts Bytes Wrong Oifs >>>>>> EF070707 C0A81111 3 453 614268 0 >>>>>> Interface BytesIn PktsIn BytesOut PktsOut Flags Local Remote >>>>>> 0 eth0 0 0 0 0 00000 C0A80102 00000000 >>>>>> 1 eth1 0 0 0 0 00000 C0A80202 00000000 >>>>>> 2 eth2 0 0 0 0 00000 C0A80302 00000000 >>>>>> 3 eth3 3971724 2929 0 0 00000 C0A80402 00000000 >>>>>> 4 pimreg 0 0 0 0 00004 C0A80102 >>>>>> >>>>>> >>>>>> 6) But, when the H1 ip is in the same subnet, traffic is properly >>>>>> forwarded to H2 without any issues. >>>>>> >>>>>> Did anybody tried this scenario ? >>>>>> >>>>>> Thanks, >>>>>> Ganesh >>>>>> >>>>>> _______________________________________________ >>>>>> 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 ganeshreddyk at gmail.com Wed Jul 11 07:29:22 2012 From: ganeshreddyk at gmail.com (Ganesh Reddy K) Date: Wed, 11 Jul 2012 19:59:22 +0530 Subject: [Xorp-users] regarding debug messages or prints Message-ID: Hi, We are trying to understand the xorp-pimsm4 code flow. To understand, we have added additional XLOG_INFO () statements in the source code. After loading, we could not observe any additional prints/debug messages . Only configuration messages were seen on log-file (which is given in xorp_rtrmgr "-l" argument). Please, somebody guide me how to get the added prints/debug messages visible during packet processing ??? Thanks in advance, Ganesh From greearb at candelatech.com Wed Jul 11 07:50:59 2012 From: greearb at candelatech.com (Ben Greear) Date: Wed, 11 Jul 2012 07:50:59 -0700 Subject: [Xorp-users] regarding debug messages or prints In-Reply-To: References: Message-ID: <4FFD92D3.4020207@candelatech.com> On 07/11/2012 07:29 AM, Ganesh Reddy K wrote: > Hi, > > We are trying to understand the xorp-pimsm4 code flow. To understand, > we have added additional XLOG_INFO () statements in the source > code. After loading, we could not observe any additional prints/debug > messages . Only configuration messages were seen on log-file (which > is given in xorp_rtrmgr "-l" argument). > > Please, somebody guide me how to get the added prints/debug messages > visible during packet processing ??? Try finding a message that is printed to the log file and edit it...make sure you see the edits in the output. That way, you at least know you are installing your new build correctly, etc. Thanks, Ben > > Thanks in advance, > Ganesh > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From fortitude.zhang at gmail.com Thu Jul 12 07:18:58 2012 From: fortitude.zhang at gmail.com (=?GB2312?B?1cW2q9HH?=) Date: Thu, 12 Jul 2012 14:18:58 +0000 Subject: [Xorp-users] Question regarding GPL license Message-ID: Hi lists, Recently I am interest in a company named pica8 which stated they want to build an open source switch platform. I read their blog link regarding license issue (http://pica8.org/blogs/?p=137), they said they will choose the dual-license model as following: Open Source License We decide to use MySQL license model for PicOS, which is a Dual license model, including both GPLv2 and commercial licenses GPLv2 licensed for the developer community OEM/ISV/VAR that does not wish to open source under GPLv2 must obtain a commercial license from Pica8 What is Pica8?s dual license model? Pica8 makes its PicOS available under both the GPL and a commercial license. As a result, developers who use or distribute open source applications under the GPL can use the GPL-licensed Pica8 software, and OEMs, ISVs and VARs that do not want to combine or distribute the Pica8 software with their own commercial software under a GPL license can purchase a commercial license. However, according to the GPL license FAQ: Q: If I add a module to a GPL-covered program, do I have to use the GPL as the license for my module? A: The GPL says that the whole combined program has to be released under the GPL. So your module has to be available for use under the GPL. But you can give additional permission for the use of your code. You can, if you wish, release your program under a license which is more lax than the GPL but compatible with the GPL. The license list page gives a partial list of GPL-compatible licenses. I think it's not proper that they can release their software under a commercial license, what's your opinion about this dula-license model? Thanks a lot. Regards, Dongya ZHang From aidan at highrise.ca Thu Jul 12 07:31:05 2012 From: aidan at highrise.ca (Aidan Van Dyk) Date: Thu, 12 Jul 2012 10:31:05 -0400 Subject: [Xorp-users] Question regarding GPL license In-Reply-To: References: Message-ID: On Thu, Jul 12, 2012 at 10:18 AM, ??? wrote: > I think it's not proper that they can release their software under a > commercial license, what's your opinion about this dula-license model? If the code is their code and they own the copyright, they can offer it to whoever they want, in whatever licence they want. Like it or not, it's not *your* choice, it's their choice. If it's not their code/copyright, then it's a different story. If you/they received code under a licence, you/they can only usr/reuse/re-offer under the terms of that licence. If you/they don't like that licence, your/their choice is accept the licence (and thus get to use/reuse the code under that licence) or not (and thus not get to use/reuse the code). a. -- Aidan Van Dyk Create like a god, aidan at highrise.ca command like a king, http://www.highrise.ca/ work like a slave. From greearb at candelatech.com Thu Jul 12 07:35:20 2012 From: greearb at candelatech.com (Ben Greear) Date: Thu, 12 Jul 2012 07:35:20 -0700 Subject: [Xorp-users] Question regarding GPL license In-Reply-To: References: Message-ID: <4FFEE0A8.1080002@candelatech.com> On 07/12/2012 07:18 AM, ??? wrote: > Hi lists, > Recently I am interest in a company named pica8 which stated they > want to build an open source switch platform. > > I read their blog link regarding license issue > (http://pica8.org/blogs/?p=137), they said they will choose the > dual-license model as following: > > Open Source License > > We decide to use MySQL license model for PicOS, which is a Dual > license model, including both GPLv2 and commercial licenses > > GPLv2 licensed for the developer community > OEM/ISV/VAR that does not wish to open source under GPLv2 must obtain > a commercial license from Pica8 > > What is Pica8?s dual license model? > > Pica8 makes its PicOS available under both the GPL and a commercial > license. As a result, developers who use or distribute open source > applications under the GPL can use the GPL-licensed Pica8 software, > and OEMs, ISVs and VARs that do not want to combine or distribute the > Pica8 software with their own commercial software under a GPL license > can purchase a commercial license. > > However, according to the GPL license FAQ: > > Q: If I add a module to a GPL-covered program, do I have to use the > GPL as the license for my module? > A: The GPL says that the whole combined program has to be released > under the GPL. So your module has to be available for use under the > GPL. > But you can give additional permission for the use of your > code. You can, if you wish, release your program under a license which > is more lax than the GPL but compatible with the GPL. The license list > page gives a partial list of GPL-compatible licenses. > > I think it's not proper that they can release their software under a > commercial license, what's your opinion about this dula-license model? They bought the rights to xorp when it was BSD licensed (and/or the copyright was fully owned by those that sold the rights to Pica8). Pica8 seems to have have forked off at around xorp version 1.6. They do not have rights to the GPL changes that have gone into the xorp.org project since then, but they can do whatever they want with their fork. If they ever release source code that is licensed BSD and/or GPL, then xorp.org could pull in those changes as wanted. They cannot pull changes the other way and still keep the BSD licensing option as I and most likely others will not grant them the right to re-license the patches we have committed to xorp.org under the GPL license. That said, xorp is architected so that modules can be individual processes, and the libraries that glue the processes together are explicitly BSD licensed, so it can be perfectly legal to use proprietary modules in xorp. I have no idea if that is how Pica8 is implementing their code, however. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From ganeshreddyk at gmail.com Thu Jul 12 19:54:23 2012 From: ganeshreddyk at gmail.com (Ganesh Reddy K) Date: Fri, 13 Jul 2012 08:24:23 +0530 Subject: [Xorp-users] regarding debug messages or prints In-Reply-To: <4FFD92D3.4020207@candelatech.com> References: <4FFD92D3.4020207@candelatech.com> Message-ID: In libxorp/xlog.c, i have replaced the const char * default [] = { "/dev/stderr", "/dev/console" "/dev/stdout" }; with . const char * default [] = { "/test1", "/test2" "/test3" }; In addition to above, in each required source file, i have declared below macro's #define DEBUG_LOGGING #define DEBUG_PRINT_FUNCTION_NAME Now i am able to see the messages coming into "/test1" file... Are these changes valid to get the logs into a file ? Thanks in advance, Ganesh On Wed, Jul 11, 2012 at 8:20 PM, Ben Greear wrote: > On 07/11/2012 07:29 AM, Ganesh Reddy K wrote: >>, >> Hi, >> >> We are trying to understand the xorp-pimsm4 code flow. To understand, >> we have added additional XLOG_INFO () statements in the source >> code. After loading, we could not observe any additional prints/debug >> messages . Only configuration messages were seen on log-file (which >> is given in xorp_rtrmgr "-l" argument). >> >> Please, somebody guide me how to get the added prints/debug messages >> visible during packet processing ??? > > > Try finding a message that is printed to the log file and edit it...make > sure > you see the edits in the output. That way, you at least know > you are installing your new build correctly, etc. > > Thanks, > Ben > >> >> Thanks in advance, >> Ganesh >> >> _______________________________________________ >> Xorp-users mailing list >> Xorp-users at xorp.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users >> > > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > > From ganeshreddyk at gmail.com Fri Jul 13 00:08:26 2012 From: ganeshreddyk at gmail.com (Ganesh Reddy K) Date: Fri, 13 Jul 2012 12:38:26 +0530 Subject: [Xorp-users] Multicast traffic is not forwarded in a specific deployment as mentioned in the mail In-Reply-To: <82B681751FE46F4AB3FCA7390B780FD1051AFFDE@039-SN1MPN1-002.039d.mgd.msft.net> References: <82B681751FE46F4AB3FCA7390B780FD1051A6AE0@039-SN1MPN1-001.039d.mgd.msft.net> <54DD4F682C240845BF5F7D0EECBDB6F20839A4D4@EXDB3.ug.kth.se> <82B681751FE46F4AB3FCA7390B780FD1051AFFDE@039-SN1MPN1-002.039d.mgd.msft.net> Message-ID: I was going through xorp-source: xorp source filename: pim/pim_mfc.cc. A comment is added about. is_directly_connected_s() . Any reason for doing this check in couple of places ? If we bypass this check in all places, any side affects ? void PimMfc::recompute_iif_olist_mfc() { // // Compute the new iif and the olist // // XXX: The computation is loosely based on the // "On receipt of data from S to G on interface iif:" procedure. // // Note that the is_directly_connected_s() check is not in the // spec, but for all practical purpose we want it here. // On Mon, Jul 9, 2012 at 6:09 PM, Reddy Ganesh-B38514 wrote: > I have configured "set protocols pimsm4 static-rps rp 192.168.4.2 group-prefix 224.0.0.0/4" on the Device > > After this configuration, the Multicast route is properly added with Oif as eth4 VIF index. But the still the traffic is not receiving at the multicast listener. In /proc/net/ip_mr_cache "Wrong" counter is incrementing for each packet. > > By seeing the linux multicast routing code flow: net/ipv4/ipmr.c, it is understood that, ip_mr_forward () is unsuccessful and returning with "dont_forward" hence "wrong_if" counter is incremented. Seems packet dropped after routing. > > I did not understand this behavior after adding static-RP. Did I miss anything on this scenario/configuration ? > > > > -----Original Message----- > From: Dan Rosenqvist [mailto:danro at kth.se] > Sent: Friday, July 06, 2012 10:31 PM > To: Ganesh Reddy K; igorm at etf.rs; xorp-users at xorp.org > Cc: Bv Rajesh-B35907; sridhar pothuganti; nandakishoreie14 at gmail.com; Reddy Ganesh-B38514 > Subject: SV: [Xorp-users] Multicast traffic is not forwarded in a specific deployment as mentioned in the mail > > Hi, > > I think the problem you're experiencing is due to the lack of a rendez-vous point (RP). You can use either static RPs or use the bootstrap mechanism. For guidance, please have a look at the examples in www.xorp.org/config (think there should be some examples for both static and bootstrap). > > Regards, > Dan > ________________________________________ > Fr?n: xorp-users-bounces at xorp.org [xorp-users-bounces at xorp.org] för Ganesh Reddy K [ganeshreddyk at gmail.com] > Skickat: den 6 juli 2012 07:03 > Till: igorm at etf.rs; xorp-users at xorp.org > Kopia: Bv Rajesh-B35907; sridhar pothuganti; nandakishoreie14 at gmail.com; Reddy Ganesh-B38514 > ?mne: Re: [Xorp-users] Multicast traffic is not forwarded in a specific deployment as mentioned in the mail > > Tried this one also, but no progress on this. I hope there is > something is happening, need to confirm either expected behavior of XORP/Linux or It is known Issue. I will check implementation details. > > Thanks in advance, > > Any quick suggestions welcome.. > > During this testcase, we are observing XORP statistics on the device are as followss ============================================================ > show igmp group > > Interface Group Source LastReported Timeout V State > eth0 224.0.0.2 0.0.0.0 192.168.1.100 157 3 E > eth0 224.0.0.13 0.0.0.0 192.168.1.100 157 3 E > eth0 224.0.0.22 0.0.0.0 192.168.1.100 157 3 E > eth0 224.0.0.251 0.0.0.0 192.168.1.50 160 3 E > eth0 239.11.11.11 0.0.0.0 192.168.1.50 160 3 E > eth1 224.0.0.2 0.0.0.0 192.168.2.100 155 3 E > eth1 224.0.0.13 0.0.0.0 192.168.2.100 155 3 E > eth1 224.0.0.22 0.0.0.0 192.168.2.100 155 3 E > eth2 224.0.0.2 0.0.0.0 192.168.3.100 158 3 E > eth2 224.0.0.13 0.0.0.0 192.168.3.100 158 3 E > eth2 224.0.0.22 0.0.0.0 192.168.3.100 158 3 E > eth3 224.0.0.2 0.0.0.0 192.168.4.100 161 3 E > eth3 224.0.0.13 0.0.0.0 192.168.4.100 161 3 E > eth3 224.0.0.22 0.0.0.0 192.168.4.100 161 3 E > > show mfea dataflow > > Group Source > 239.11.11.11 192.168.11.54 > Measured(Start|Packets|Bytes) Type Thresh(Interval|Packets|Bytes) Remain > 56253.252679|627|? <= 210.0|0|? 170.767324 > > > show mfea interface > > Interface State Vif/PifIndex Addr Flags > eth0 UP 0/4 192.168.1.100 MULTICAST BROADCAST KERN_UP > eth1 UP 1/3 192.168.2.100 MULTICAST BROADCAST KERN_UP > eth2 UP 2/5 192.168.3.100 MULTICAST BROADCAST KERN_UP > eth3 UP 3/7 192.168.4.100 MULTICAST BROADCAST KERN_UP > register_vif UP 4/4 192.168.1.100 PIM_REGISTER KERN_UP > > ============================================================ > > > > On Thu, Jul 5, 2012 at 10:04 PM, Igor Maravi? wrote: >> Ufffff... Xorp isn't doing any spoof checking in that I'm sure. >> To me, even if there aren't any discard packets logged, it still looks >> like reverse path filtering. >> >> Try this: >> >> sysctl -w net.ipv4.conf.default.rp_filter=0 >> >> if that doesn't work I really don't know what the problem is :) BR >> Igor >> >> 2012/7/5 Ganesh Reddy K : >>> Thanks a lot for the detailed inputs, >>> >>> I have added the routes as suggested, but still the traffic is not >>> forwarded . Did not observe any discards in ' netstat -s IP'. >>> >>> In general, When multicast UDP cache-miss occurs and >>> subscriber is listened for that group, Then only multicast routing >>> services will add the multicast ROUTE in linux kernel . The >>> forwarding is taken care by Linux routing mechanism. I guess, In >>> this scenario, UDP cache miss is properly given to XORP daemons, but >>> could not fulfill the entire route (i.e ip_mr_cache with valid Oif ) >>> . There may be possible spoof check in PIM daemons . >>> >>> Is my thought justifies the behavior ? >>> >>> ================ >>> netstat -s IP >>> Ip: >>> 67296 total packets received >>> 0 forwarded >>> 0 incoming packets discarded >>> 42784 incoming packets delivered >>> 41760 requests sent out >>> Icmp: >>> 0 ICMP messages received >>> 0 input ICMP message failed. >>> ICMP input histogram: >>> 0 ICMP messages sent >>> 0 ICMP messages failed >>> ICMP output histogram: >>> Tcp: >>> 50 active connections openings >>> 49 passive connection openings >>> 0 failed connection attempts >>> 0 connection resets received >>> 35 connections established >>> 40788 segments received >>> 39837 segments send out >>> 0 segments retransmited >>> 0 bad segments received. >>> 0 resets sent >>> Udp: >>> 0 packets received >>> 0 packets to unknown port received. >>> 0 packet receive errors >>> 0 packets sent >>> RcvbufErrors: 0 >>> SndbufErrors: 0 >>> UdpLite: >>> InDatagrams: 0 >>> NoPorts: 0 >>> InErrors: 0 >>> OutDatagrams: 0 >>> RcvbufErrors: 0 >>> SndbufErrors: 0 >>> error parsing /proc/net/snmp: Success ================ >>> >>> On Thu, Jul 5, 2012 at 8:07 PM, Igor Maravi? wrote: >>>> sysctl -w net.ipv4.conf.eth3.rp_filter=0 sysctl -w >>>> net.ipv4.conf.eth2.rp_filter=0 sysctl -w >>>> net.ipv4.conf.all.rp_filter=0 sysctl -w >>>> net.ipv4.conf.default.rp_filter=0 >>>> >>>> for me, echo isn't working. I use this commands to set values. >>>> >>>> 2012/7/5 Igor Maravi? : >>>>> My bad... I forgot set protocols static part... >>>>> >>>>> command in xorpsh is >>>>> >>>>> #set protocols static interface-route 192.168.17.17/32 >>>>> next-hop-interface eth3 #set protocols static interface-route >>>>> 192.168.17.17/32 next-hop-vif eth3 >>>>> >>>>> If my theory is ok when you send packets from H1 to H2, they are >>>>> dropped in Linux. >>>>> You can confirm this if you run >>>>> >>>>> netstat -s IP >>>>> >>>>> and you see that number of discarded IP packets is increasing. >>>>> My proposals are for that case. >>>>> BR >>>>> Igor >>>>> >>>>> 2012/7/5 Reddy Ganesh-B38514 : >>>>>> Echo 0 > /proc/sys/net/ipv4/conf/eth3/rp_filter >>>>>> Echo 0 > /proc/sys/net/ipv4/conf/eth2/rp_filter >>>>>> Echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter >>>>>> >>>>>> As per the step 1, I have Disabled the rp_filter on the Device. Still the problem persists. >>>>>> >>>>>> I tried to configure commands mentioned in step 2 also, But I could not locate the exact commands in xorp config shell. Did I miss anything ?? >>>>>> >>>>>> -----Original Message----- >>>>>> From: Igor Maravi? [mailto:igorm at etf.rs] >>>>>> Sent: Thursday, July 05, 2012 12:50 PM >>>>>> To: Ganesh Reddy K >>>>>> Cc: xorp-users at xorp.org; Bv Rajesh-B35907; >>>>>> nandakishoreie14 at gmail.com; Reddy Ganesh-B38514 >>>>>> Subject: Re: [Xorp-users] Multicast traffic is not forwarded in a >>>>>> specific deployment as mentioned in the mail >>>>>> >>>>>> I'm 99% sure that this isn't Xorp problem :) Linux, won't forward packets if the src address in packet is unknown to him. >>>>>> So, at least I think that, you have 2 possible solutions: >>>>>> 1. Turn off rp filtering on Xorp box (reference - >>>>>> http://lartc.org/howto/lartc.kernel.html) >>>>>> 2. Set static interface route to 192.168.17.17/32 on eth3, with Xorp ( >>>>>> interface-route 192.168.17.17/32 { >>>>>> next-hop-interface: "eth3" >>>>>> next-hop-vif: "eth3" >>>>>> } >>>>>> ) >>>>>> >>>>>> Let me know if it worked. :) >>>>>> BR >>>>>> Igor >>>>>> >>>>>> 2012/7/5 Ganesh Reddy K : >>>>>>> Hi , >>>>>>> >>>>>>> We are trying to exercise a multicast traffic forwarding scenario >>>>>>> on a powerPC device:-- >>>>>>> >>>>>>> After H2 subscribed for the Group G1, The G1 multicast traffic >>>>>>> is not receiving at H2. But, when the H1 ip is in the same >>>>>>> subnet, traffic is properly forwarded to H2 without any issues. >>>>>>> >>>>>>> Test setup:-- >>>>>>> >>>>>>> H1 ------------------------------------ eth3 XORP eth2 >>>>>>> -------------------------------------------- H2 >>>>>>> >>>>>>> 192.168.17.17 192.168.4.2 192.168.3.2 >>>>>>> 192.168.3.10 >>>>>>> >>>>>>> UDP-G1 multicaststream >>>>>>> Mcast listener for G1 >>>>>>> >>>>>>> G1-239.7.7.7 >>>>>>> >>>>>>> >>>>>>> 1) COnfigured XORP on the device, xorp.conf contents are . >>>>>>> >>>>>>> ===========XORP configuration =========== >>>>>>> >>>>>>> protocols { >>>>>>> fib2mrib { >>>>>>> } >>>>>>> igmp { >>>>>>> >>>>>>> interface eth0 { >>>>>>> vif eth0 { >>>>>>> version: 3 >>>>>>> } >>>>>>> } >>>>>>> interface eth1 { >>>>>>> vif eth1 { >>>>>>> version: 3 >>>>>>> } } >>>>>>> interface eth2 { >>>>>>> vif eth2 { >>>>>>> version: 3 >>>>>>> } >>>>>>> } >>>>>>> interface eth3 { >>>>>>> >>>>>>> vif eth3 { >>>>>>> version: 3 >>>>>>> } >>>>>>> } } >>>>>>> >>>>>>> >>>>>>> pimsm4 { >>>>>>> interface eth0 { >>>>>>> >>>>>>> vif eth0 { >>>>>>> } >>>>>>> } >>>>>>> interface "register_vif" { >>>>>>> vif "register_vif" { >>>>>>> } >>>>>>> >>>>>>> } >>>>>>> interface eth1 { >>>>>>> vif eth1 { >>>>>>> >>>>>>> } >>>>>>> } >>>>>>> interface eth2 { >>>>>>> vif eth2 { >>>>>>> } >>>>>>> } >>>>>>> interface eth3 { >>>>>>> >>>>>>> vif eth3 { >>>>>>> } >>>>>>> } >>>>>>> } >>>>>>> } >>>>>>> fea { >>>>>>> unicast-forwarding4 { >>>>>>> } >>>>>>> >>>>>>> >>>>>>> unicast-forwarding6 { >>>>>>> } >>>>>>> } >>>>>>> interfaces { >>>>>>> interface eth0 { >>>>>>> vif eth0 { >>>>>>> } >>>>>>> >>>>>>> default-system-config { >>>>>>> } >>>>>>> } >>>>>>> interface eth1 { >>>>>>> >>>>>>> vif eth1 { >>>>>>> } >>>>>>> default-system-config { >>>>>>> } >>>>>>> } >>>>>>> interface eth2 { >>>>>>> vif eth2 { >>>>>>> >>>>>>> } >>>>>>> default-system-config { >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> interface eth3 { >>>>>>> vif eth3 { >>>>>>> } >>>>>>> >>>>>>> default-system-config { >>>>>>> } >>>>>>> } >>>>>>> } >>>>>>> plumbing { >>>>>>> >>>>>>> mfea4 { >>>>>>> interface eth0 { >>>>>>> vif eth0 { >>>>>>> >>>>>>> } >>>>>>> } >>>>>>> interface "register_vif" { >>>>>>> >>>>>>> vif "register_vif" { >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> interface eth1 { >>>>>>> vif eth1 { >>>>>>> } >>>>>>> >>>>>>> } >>>>>>> >>>>>>> interface eth2 { >>>>>>> vif eth2 { >>>>>>> } >>>>>>> >>>>>>> } >>>>>>> interface eth3 { >>>>>>> vif eth3 { >>>>>>> >>>>>>> } >>>>>>> } >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> ============= xorp configuration ============= >>>>>>> >>>>>>> 2) From H1, started sending UDP stream targeting G1 using VLC player. >>>>>>> >>>>>>> Capture of "tcpdump -ni eth3" on Device shows the UDP-G1 >>>>>>> packets as below .. >>>>>>> 09:27:50.081561 IP 192.168.17.17.4146 > 239.7.7.7.1234: UDP, >>>>>>> length >>>>>>> 1328 .. >>>>>>> >>>>>>> 3) added a static route for the unknown network on Device (i.e >>>>>>> route add -net 192.168.17.17/32 dev eth3) >>>>>>> >>>>>>> 4) From H2, started VLC listener for the group G1. >>>>>>> >>>>>>> It is verified in the Device that, IGMP join is received. >>>>>>> capture of " show igmp group" on XORP console >>>>>>> >>>>>>> Interface Group Source LastReported Timeout V State >>>>>>> >>>>>>> eth0 224.0.0.2 0.0.0.0 192.168.1.2 223 3 E >>>>>>> >>>>>>> eth0 224.0.0.13 0.0.0.0 192.168.1.2 223 3 E >>>>>>> >>>>>>> eth0 224.0.0.22 0.0.0.0 192.168.1.2 223 3 E >>>>>>> >>>>>>> eth1 224.0.0.2 0.0.0.0 192.168.2.2 225 3 E >>>>>>> >>>>>>> eth1 224.0.0.13 0.0.0.0 192.168.2.2 225 3 E >>>>>>> >>>>>>> eth1 224.0.0.22 0.0.0.0 192.168.2.2 225 3 E >>>>>>> >>>>>>> eth2 224.0.0.2 0.0.0.0 192.168.3.2 231 3 E >>>>>>> >>>>>>> eth2 224.0.0.13 0.0.0.0 192.168.3.2 231 3 E >>>>>>> >>>>>>> eth2 224.0.0.22 0.0.0.0 192.168.3.2 231 3 E >>>>>>> >>>>>>> eth2 239.1.1.1 0.0.0.0 192.168.3.10 228 3 E >>>>>>> >>>>>>> eth2 239.7.7.7 0.0.0.0 192.168.3.10 228 3 E >>>>>>> >>>>>>> eth2 239.255.255.250 0.0.0.0 192.168.3.10 228 3 E >>>>>>> >>>>>>> eth3 224.0.0.2 0.0.0.0 192.168.4.2 230 3 E >>>>>>> >>>>>>> eth3 224.0.0.13 0.0.0.0 192.168.4.2 230 3 E >>>>>>> >>>>>>> eth3 224.0.0.22 0.0.0.0 192.168.4.2 230 3 E >>>>>>> >>>>>>> root at p4080ds> >>>>>>> >>>>>>> 5) But the traffic is not receiving at H2. Below is the statistics >>>>>>> related ip_mr on the device >>>>>>> >>>>>>> cat /proc/net/ip_mr* >>>>>>> >>>>>>> Group Origin Iif Pkts Bytes Wrong Oifs >>>>>>> EF070707 C0A81111 3 453 614268 0 >>>>>>> Interface BytesIn PktsIn BytesOut PktsOut Flags Local Remote >>>>>>> 0 eth0 0 0 0 0 00000 C0A80102 00000000 >>>>>>> 1 eth1 0 0 0 0 00000 C0A80202 00000000 >>>>>>> 2 eth2 0 0 0 0 00000 C0A80302 00000000 >>>>>>> 3 eth3 3971724 2929 0 0 00000 C0A80402 00000000 >>>>>>> 4 pimreg 0 0 0 0 00004 C0A80102 >>>>>>> >>>>>>> >>>>>>> 6) But, when the H1 ip is in the same subnet, traffic is >>>>>>> properly forwarded to H2 without any issues. >>>>>>> >>>>>>> Did anybody tried this scenario ? >>>>>>> >>>>>>> Thanks, >>>>>>> Ganesh >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 keshavsrinu at gmail.com Fri Jul 13 00:45:47 2012 From: keshavsrinu at gmail.com (kesava Srinivas) Date: Fri, 13 Jul 2012 13:15:47 +0530 Subject: [Xorp-users] Multicast traffic is not forwarded in a specific deployment as mentioned in the mail In-Reply-To: References: <82B681751FE46F4AB3FCA7390B780FD1051A6AE0@039-SN1MPN1-001.039d.mgd.msft.net> <54DD4F682C240845BF5F7D0EECBDB6F20839A4D4@EXDB3.ug.kth.se> <82B681751FE46F4AB3FCA7390B780FD1051AFFDE@039-SN1MPN1-002.039d.mgd.msft.net> Message-ID: HI Ganesh, Can U please try using this Parameter in Your Configuration File? Mostly ; this should suffice Your task. Here is the description from XORP-WIKi ( http://xorp.run.montefiore.ulg.ac.be/latex2wiki/user_manual/pim_sparse_mode ). alternative-subnet: this directive is used to associate additional IP subnets with a network interface. The parameter value is an IPv4 subnet address in the address/prefix-length format. One use of this directive is to make incoming traffic with a non-local source address appear as it is coming from a local subnet. Typically, this is needed as a work-around solution when uni-directional interfaces such as satellite links are used for receiving traffic. The alternative-subnet directive should be used with extreme care, because it is possible to create forwarding loops. Please let us know ; if that really worked ? -Thnx, VKS. On Fri, Jul 13, 2012 at 12:38 PM, Ganesh Reddy K wrote: > I was going through xorp-source: > > xorp source filename: pim/pim_mfc.cc. A comment is added > about. is_directly_connected_s() . Any reason for doing this > check in couple of places ? If we bypass this check in all places, > any side affects ? > > void PimMfc::recompute_iif_olist_mfc() > { > > // > // Compute the new iif and the olist > // > // XXX: The computation is loosely based on the > // "On receipt of data from S to G on interface iif:" procedure. > // > // Note that the is_directly_connected_s() check is not in the > // spec, but for all practical purpose we want it here. > // > > > On Mon, Jul 9, 2012 at 6:09 PM, Reddy Ganesh-B38514 > wrote: > > I have configured "set protocols pimsm4 static-rps rp 192.168.4.2 > group-prefix 224.0.0.0/4" on the Device > > > > After this configuration, the Multicast route is properly added with Oif > as eth4 VIF index. But the still the traffic is not receiving at the > multicast listener. In /proc/net/ip_mr_cache "Wrong" counter is > incrementing for each packet. > > > > By seeing the linux multicast routing code flow: net/ipv4/ipmr.c, it > is understood that, ip_mr_forward () is unsuccessful and returning with > "dont_forward" hence "wrong_if" counter is incremented. Seems packet > dropped after routing. > > > > I did not understand this behavior after adding static-RP. Did I miss > anything on this scenario/configuration ? > > > > > > > > -----Original Message----- > > From: Dan Rosenqvist [mailto:danro at kth.se] > > Sent: Friday, July 06, 2012 10:31 PM > > To: Ganesh Reddy K; igorm at etf.rs; xorp-users at xorp.org > > Cc: Bv Rajesh-B35907; sridhar pothuganti; nandakishoreie14 at gmail.com; > Reddy Ganesh-B38514 > > Subject: SV: [Xorp-users] Multicast traffic is not forwarded in a > specific deployment as mentioned in the mail > > > > Hi, > > > > I think the problem you're experiencing is due to the lack of a > rendez-vous point (RP). You can use either static RPs or use the bootstrap > mechanism. For guidance, please have a look at the examples in > www.xorp.org/config (think there should be some examples for both static > and bootstrap). > > > > Regards, > > Dan > > ________________________________________ > > Fr?n: xorp-users-bounces at xorp.org [xorp-users-bounces at xorp.org] > för Ganesh Reddy K [ganeshreddyk at gmail.com] > > Skickat: den 6 juli 2012 07:03 > > Till: igorm at etf.rs; xorp-users at xorp.org > > Kopia: Bv Rajesh-B35907; sridhar pothuganti; nandakishoreie14 at gmail.com; > Reddy Ganesh-B38514 > > ?mne: Re: [Xorp-users] Multicast traffic is not forwarded in a specific > deployment as mentioned in the mail > > > > Tried this one also, but no progress on this. I hope there is > > something is happening, need to confirm either expected behavior of > XORP/Linux or It is known Issue. I will check implementation details. > > > > Thanks in advance, > > > > Any quick suggestions welcome.. > > > > During this testcase, we are observing XORP statistics on the device > are as followss ============================================================ > > show igmp group > > > > Interface Group Source LastReported Timeout V State > > eth0 224.0.0.2 0.0.0.0 192.168.1.100 157 3 > E > > eth0 224.0.0.13 0.0.0.0 192.168.1.100 157 3 > E > > eth0 224.0.0.22 0.0.0.0 192.168.1.100 157 3 > E > > eth0 224.0.0.251 0.0.0.0 192.168.1.50 160 3 E > > eth0 239.11.11.11 0.0.0.0 192.168.1.50 160 3 E > > eth1 224.0.0.2 0.0.0.0 192.168.2.100 155 3 > E > > eth1 224.0.0.13 0.0.0.0 192.168.2.100 155 3 > E > > eth1 224.0.0.22 0.0.0.0 192.168.2.100 155 3 > E > > eth2 224.0.0.2 0.0.0.0 192.168.3.100 158 3 > E > > eth2 224.0.0.13 0.0.0.0 192.168.3.100 158 3 > E > > eth2 224.0.0.22 0.0.0.0 192.168.3.100 158 3 > E > > eth3 224.0.0.2 0.0.0.0 192.168.4.100 161 3 > E > > eth3 224.0.0.13 0.0.0.0 192.168.4.100 161 3 > E > > eth3 224.0.0.22 0.0.0.0 192.168.4.100 161 3 > E > > > > show mfea dataflow > > > > Group Source > > 239.11.11.11 192.168.11.54 > > Measured(Start|Packets|Bytes) Type Thresh(Interval|Packets|Bytes) > Remain > > 56253.252679|627|? <= 210.0|0|? > 170.767324 > > > > > > show mfea interface > > > > Interface State Vif/PifIndex Addr Flags > > eth0 UP 0/4 192.168.1.100 MULTICAST BROADCAST > KERN_UP > > eth1 UP 1/3 192.168.2.100 MULTICAST BROADCAST > KERN_UP > > eth2 UP 2/5 192.168.3.100 MULTICAST BROADCAST > KERN_UP > > eth3 UP 3/7 192.168.4.100 MULTICAST BROADCAST > KERN_UP > > register_vif UP 4/4 192.168.1.100 PIM_REGISTER KERN_UP > > > > ============================================================ > > > > > > > > On Thu, Jul 5, 2012 at 10:04 PM, Igor Maravi? wrote: > >> Ufffff... Xorp isn't doing any spoof checking in that I'm sure. > >> To me, even if there aren't any discard packets logged, it still looks > >> like reverse path filtering. > >> > >> Try this: > >> > >> sysctl -w net.ipv4.conf.default.rp_filter=0 > >> > >> if that doesn't work I really don't know what the problem is :) BR > >> Igor > >> > >> 2012/7/5 Ganesh Reddy K : > >>> Thanks a lot for the detailed inputs, > >>> > >>> I have added the routes as suggested, but still the traffic is not > >>> forwarded . Did not observe any discards in ' netstat -s IP'. > >>> > >>> In general, When multicast UDP cache-miss occurs and > >>> subscriber is listened for that group, Then only multicast routing > >>> services will add the multicast ROUTE in linux kernel . The > >>> forwarding is taken care by Linux routing mechanism. I guess, In > >>> this scenario, UDP cache miss is properly given to XORP daemons, but > >>> could not fulfill the entire route (i.e ip_mr_cache with valid Oif ) > >>> . There may be possible spoof check in PIM daemons . > >>> > >>> Is my thought justifies the behavior ? > >>> > >>> ================ > >>> netstat -s IP > >>> Ip: > >>> 67296 total packets received > >>> 0 forwarded > >>> 0 incoming packets discarded > >>> 42784 incoming packets delivered > >>> 41760 requests sent out > >>> Icmp: > >>> 0 ICMP messages received > >>> 0 input ICMP message failed. > >>> ICMP input histogram: > >>> 0 ICMP messages sent > >>> 0 ICMP messages failed > >>> ICMP output histogram: > >>> Tcp: > >>> 50 active connections openings > >>> 49 passive connection openings > >>> 0 failed connection attempts > >>> 0 connection resets received > >>> 35 connections established > >>> 40788 segments received > >>> 39837 segments send out > >>> 0 segments retransmited > >>> 0 bad segments received. > >>> 0 resets sent > >>> Udp: > >>> 0 packets received > >>> 0 packets to unknown port received. > >>> 0 packet receive errors > >>> 0 packets sent > >>> RcvbufErrors: 0 > >>> SndbufErrors: 0 > >>> UdpLite: > >>> InDatagrams: 0 > >>> NoPorts: 0 > >>> InErrors: 0 > >>> OutDatagrams: 0 > >>> RcvbufErrors: 0 > >>> SndbufErrors: 0 > >>> error parsing /proc/net/snmp: Success ================ > >>> > >>> On Thu, Jul 5, 2012 at 8:07 PM, Igor Maravi? wrote: > >>>> sysctl -w net.ipv4.conf.eth3.rp_filter=0 sysctl -w > >>>> net.ipv4.conf.eth2.rp_filter=0 sysctl -w > >>>> net.ipv4.conf.all.rp_filter=0 sysctl -w > >>>> net.ipv4.conf.default.rp_filter=0 > >>>> > >>>> for me, echo isn't working. I use this commands to set values. > >>>> > >>>> 2012/7/5 Igor Maravi? : > >>>>> My bad... I forgot set protocols static part... > >>>>> > >>>>> command in xorpsh is > >>>>> > >>>>> #set protocols static interface-route 192.168.17.17/32 > >>>>> next-hop-interface eth3 #set protocols static interface-route > >>>>> 192.168.17.17/32 next-hop-vif eth3 > >>>>> > >>>>> If my theory is ok when you send packets from H1 to H2, they are > >>>>> dropped in Linux. > >>>>> You can confirm this if you run > >>>>> > >>>>> netstat -s IP > >>>>> > >>>>> and you see that number of discarded IP packets is increasing. > >>>>> My proposals are for that case. > >>>>> BR > >>>>> Igor > >>>>> > >>>>> 2012/7/5 Reddy Ganesh-B38514 : > >>>>>> Echo 0 > /proc/sys/net/ipv4/conf/eth3/rp_filter > >>>>>> Echo 0 > /proc/sys/net/ipv4/conf/eth2/rp_filter > >>>>>> Echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter > >>>>>> > >>>>>> As per the step 1, I have Disabled the rp_filter on the Device. > Still the problem persists. > >>>>>> > >>>>>> I tried to configure commands mentioned in step 2 also, But I could > not locate the exact commands in xorp config shell. Did I miss anything ?? > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: Igor Maravi? [mailto:igorm at etf.rs] > >>>>>> Sent: Thursday, July 05, 2012 12:50 PM > >>>>>> To: Ganesh Reddy K > >>>>>> Cc: xorp-users at xorp.org; Bv Rajesh-B35907; > >>>>>> nandakishoreie14 at gmail.com; Reddy Ganesh-B38514 > >>>>>> Subject: Re: [Xorp-users] Multicast traffic is not forwarded in a > >>>>>> specific deployment as mentioned in the mail > >>>>>> > >>>>>> I'm 99% sure that this isn't Xorp problem :) Linux, won't forward > packets if the src address in packet is unknown to him. > >>>>>> So, at least I think that, you have 2 possible solutions: > >>>>>> 1. Turn off rp filtering on Xorp box (reference - > >>>>>> http://lartc.org/howto/lartc.kernel.html) > >>>>>> 2. Set static interface route to 192.168.17.17/32 on eth3, with > Xorp ( > >>>>>> interface-route 192.168.17.17/32 { > >>>>>> next-hop-interface: "eth3" > >>>>>> next-hop-vif: "eth3" > >>>>>> } > >>>>>> ) > >>>>>> > >>>>>> Let me know if it worked. :) > >>>>>> BR > >>>>>> Igor > >>>>>> > >>>>>> 2012/7/5 Ganesh Reddy K : > >>>>>>> Hi , > >>>>>>> > >>>>>>> We are trying to exercise a multicast traffic forwarding scenario > >>>>>>> on a powerPC device:-- > >>>>>>> > >>>>>>> After H2 subscribed for the Group G1, The G1 multicast traffic > >>>>>>> is not receiving at H2. But, when the H1 ip is in the same > >>>>>>> subnet, traffic is properly forwarded to H2 without any issues. > >>>>>>> > >>>>>>> Test setup:-- > >>>>>>> > >>>>>>> H1 ------------------------------------ eth3 XORP eth2 > >>>>>>> -------------------------------------------- H2 > >>>>>>> > >>>>>>> 192.168.17.17 192.168.4.2 192.168.3.2 > >>>>>>> 192.168.3.10 > >>>>>>> > >>>>>>> UDP-G1 multicaststream > >>>>>>> Mcast listener for G1 > >>>>>>> > >>>>>>> G1-239.7.7.7 > >>>>>>> > >>>>>>> > >>>>>>> 1) COnfigured XORP on the device, xorp.conf contents are . > >>>>>>> > >>>>>>> ===========XORP configuration =========== > >>>>>>> > >>>>>>> protocols { > >>>>>>> fib2mrib { > >>>>>>> } > >>>>>>> igmp { > >>>>>>> > >>>>>>> interface eth0 { > >>>>>>> vif eth0 { > >>>>>>> version: 3 > >>>>>>> } > >>>>>>> } > >>>>>>> interface eth1 { > >>>>>>> vif eth1 { > >>>>>>> version: 3 > >>>>>>> } } > >>>>>>> interface eth2 { > >>>>>>> vif eth2 { > >>>>>>> version: 3 > >>>>>>> } > >>>>>>> } > >>>>>>> interface eth3 { > >>>>>>> > >>>>>>> vif eth3 { > >>>>>>> version: 3 > >>>>>>> } > >>>>>>> } } > >>>>>>> > >>>>>>> > >>>>>>> pimsm4 { > >>>>>>> interface eth0 { > >>>>>>> > >>>>>>> vif eth0 { > >>>>>>> } > >>>>>>> } > >>>>>>> interface "register_vif" { > >>>>>>> vif "register_vif" { > >>>>>>> } > >>>>>>> > >>>>>>> } > >>>>>>> interface eth1 { > >>>>>>> vif eth1 { > >>>>>>> > >>>>>>> } > >>>>>>> } > >>>>>>> interface eth2 { > >>>>>>> vif eth2 { > >>>>>>> } > >>>>>>> } > >>>>>>> interface eth3 { > >>>>>>> > >>>>>>> vif eth3 { > >>>>>>> } > >>>>>>> } > >>>>>>> } > >>>>>>> } > >>>>>>> fea { > >>>>>>> unicast-forwarding4 { > >>>>>>> } > >>>>>>> > >>>>>>> > >>>>>>> unicast-forwarding6 { > >>>>>>> } > >>>>>>> } > >>>>>>> interfaces { > >>>>>>> interface eth0 { > >>>>>>> vif eth0 { > >>>>>>> } > >>>>>>> > >>>>>>> default-system-config { > >>>>>>> } > >>>>>>> } > >>>>>>> interface eth1 { > >>>>>>> > >>>>>>> vif eth1 { > >>>>>>> } > >>>>>>> default-system-config { > >>>>>>> } > >>>>>>> } > >>>>>>> interface eth2 { > >>>>>>> vif eth2 { > >>>>>>> > >>>>>>> } > >>>>>>> default-system-config { > >>>>>>> } > >>>>>>> } > >>>>>>> > >>>>>>> interface eth3 { > >>>>>>> vif eth3 { > >>>>>>> } > >>>>>>> > >>>>>>> default-system-config { > >>>>>>> } > >>>>>>> } > >>>>>>> } > >>>>>>> plumbing { > >>>>>>> > >>>>>>> mfea4 { > >>>>>>> interface eth0 { > >>>>>>> vif eth0 { > >>>>>>> > >>>>>>> } > >>>>>>> } > >>>>>>> interface "register_vif" { > >>>>>>> > >>>>>>> vif "register_vif" { > >>>>>>> } > >>>>>>> } > >>>>>>> > >>>>>>> interface eth1 { > >>>>>>> vif eth1 { > >>>>>>> } > >>>>>>> > >>>>>>> } > >>>>>>> > >>>>>>> interface eth2 { > >>>>>>> vif eth2 { > >>>>>>> } > >>>>>>> > >>>>>>> } > >>>>>>> interface eth3 { > >>>>>>> vif eth3 { > >>>>>>> > >>>>>>> } > >>>>>>> } > >>>>>>> } > >>>>>>> } > >>>>>>> > >>>>>>> ============= xorp configuration ============= > >>>>>>> > >>>>>>> 2) From H1, started sending UDP stream targeting G1 using VLC > player. > >>>>>>> > >>>>>>> Capture of "tcpdump -ni eth3" on Device shows the UDP-G1 > >>>>>>> packets as below .. > >>>>>>> 09:27:50.081561 IP 192.168.17.17.4146 > 239.7.7.7.1234: UDP, > >>>>>>> length > >>>>>>> 1328 .. > >>>>>>> > >>>>>>> 3) added a static route for the unknown network on Device (i.e > >>>>>>> route add -net 192.168.17.17/32 dev eth3) > >>>>>>> > >>>>>>> 4) From H2, started VLC listener for the group G1. > >>>>>>> > >>>>>>> It is verified in the Device that, IGMP join is received. > >>>>>>> capture of " show igmp group" on XORP console > >>>>>>> > >>>>>>> Interface Group Source LastReported Timeout > V State > >>>>>>> > >>>>>>> eth0 224.0.0.2 0.0.0.0 192.168.1.2 223 > 3 E > >>>>>>> > >>>>>>> eth0 224.0.0.13 0.0.0.0 192.168.1.2 223 > 3 E > >>>>>>> > >>>>>>> eth0 224.0.0.22 0.0.0.0 192.168.1.2 223 > 3 E > >>>>>>> > >>>>>>> eth1 224.0.0.2 0.0.0.0 192.168.2.2 225 > 3 E > >>>>>>> > >>>>>>> eth1 224.0.0.13 0.0.0.0 192.168.2.2 225 > 3 E > >>>>>>> > >>>>>>> eth1 224.0.0.22 0.0.0.0 192.168.2.2 225 > 3 E > >>>>>>> > >>>>>>> eth2 224.0.0.2 0.0.0.0 192.168.3.2 231 > 3 E > >>>>>>> > >>>>>>> eth2 224.0.0.13 0.0.0.0 192.168.3.2 231 > 3 E > >>>>>>> > >>>>>>> eth2 224.0.0.22 0.0.0.0 192.168.3.2 231 > 3 E > >>>>>>> > >>>>>>> eth2 239.1.1.1 0.0.0.0 192.168.3.10 228 > 3 E > >>>>>>> > >>>>>>> eth2 239.7.7.7 0.0.0.0 192.168.3.10 228 > 3 E > >>>>>>> > >>>>>>> eth2 239.255.255.250 0.0.0.0 192.168.3.10 228 > 3 E > >>>>>>> > >>>>>>> eth3 224.0.0.2 0.0.0.0 192.168.4.2 230 > 3 E > >>>>>>> > >>>>>>> eth3 224.0.0.13 0.0.0.0 192.168.4.2 230 > 3 E > >>>>>>> > >>>>>>> eth3 224.0.0.22 0.0.0.0 192.168.4.2 230 > 3 E > >>>>>>> > >>>>>>> root at p4080ds> > >>>>>>> > >>>>>>> 5) But the traffic is not receiving at H2. Below is the statistics > >>>>>>> related ip_mr on the device > >>>>>>> > >>>>>>> cat /proc/net/ip_mr* > >>>>>>> > >>>>>>> Group Origin Iif Pkts Bytes Wrong Oifs > >>>>>>> EF070707 C0A81111 3 453 614268 0 > >>>>>>> Interface BytesIn PktsIn BytesOut PktsOut Flags Local > Remote > >>>>>>> 0 eth0 0 0 0 0 00000 C0A80102 > 00000000 > >>>>>>> 1 eth1 0 0 0 0 00000 C0A80202 > 00000000 > >>>>>>> 2 eth2 0 0 0 0 00000 C0A80302 > 00000000 > >>>>>>> 3 eth3 3971724 2929 0 0 00000 C0A80402 > 00000000 > >>>>>>> 4 pimreg 0 0 0 0 00004 C0A80102 > >>>>>>> > >>>>>>> > >>>>>>> 6) But, when the H1 ip is in the same subnet, traffic is > >>>>>>> properly forwarded to H2 without any issues. > >>>>>>> > >>>>>>> Did anybody tried this scenario ? > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Ganesh > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120713/1200253e/attachment-0001.html From fortitude.zhang at gmail.com Sun Jul 15 08:22:13 2012 From: fortitude.zhang at gmail.com (=?GB2312?B?1cW2q9HH?=) Date: Sun, 15 Jul 2012 15:22:13 +0000 Subject: [Xorp-users] Question regarding GPL license In-Reply-To: <4FFEE0A8.1080002@candelatech.com> References: <4FFEE0A8.1080002@candelatech.com> Message-ID: Hi Ben Greear, This weekend I found the 1.0 version source code released by pica8, after some quick glance, I noted that in order to implement their CLI shell, they inherit XORP shell class and implement a new CLI shell. Then I am a little confused regarding in your letter about that it can be perfectly legal to use proprietary modules in XORP , because CLI related source code is released under GPL, If I (not pica8) want to build some proprietary module and want implement a different but like XORP CLI shell, the only way I can do is release the CLI shell under GPL ? (Maybe the CLI shell is customed and doesn't mean too much to be released under GPL). Hoping for reply from you or others list members, thanks a lot. 2012/7/12 Ben Greear : > On 07/12/2012 07:18 AM, ??? wrote: >> Hi lists, >> Recently I am interest in a company named pica8 which stated they >> want to build an open source switch platform. >> >> I read their blog link regarding license issue >> (http://pica8.org/blogs/?p=137), they said they will choose the >> dual-license model as following: >> >> Open Source License >> >> We decide to use MySQL license model for PicOS, which is a Dual >> license model, including both GPLv2 and commercial licenses >> >> GPLv2 licensed for the developer community >> OEM/ISV/VAR that does not wish to open source under GPLv2 must obtain >> a commercial license from Pica8 >> >> What is Pica8?s dual license model? >> >> Pica8 makes its PicOS available under both the GPL and a commercial >> license. As a result, developers who use or distribute open source >> applications under the GPL can use the GPL-licensed Pica8 software, >> and OEMs, ISVs and VARs that do not want to combine or distribute the >> Pica8 software with their own commercial software under a GPL license >> can purchase a commercial license. >> >> However, according to the GPL license FAQ: >> >> Q: If I add a module to a GPL-covered program, do I have to use the >> GPL as the license for my module? >> A: The GPL says that the whole combined program has to be released >> under the GPL. So your module has to be available for use under the >> GPL. >> But you can give additional permission for the use of your >> code. You can, if you wish, release your program under a license which >> is more lax than the GPL but compatible with the GPL. The license list >> page gives a partial list of GPL-compatible licenses. >> >> I think it's not proper that they can release their software under a >> commercial license, what's your opinion about this dula-license model? > > They bought the rights to xorp when it was BSD licensed (and/or the copyright > was fully owned by those that sold the rights to Pica8). Pica8 seems to have > have forked off at around xorp version 1.6. > > They do not have rights to the GPL changes that have gone into the xorp.org > project since then, but they can do whatever they want with their fork. > > If they ever release source code that is licensed BSD and/or GPL, then > xorp.org could pull in those changes as wanted. They cannot pull changes > the other way and still keep the BSD licensing option as I and most likely > others will not grant them the right to re-license the patches we have committed to > xorp.org under the GPL license. > > That said, xorp is architected so that modules can be individual processes, > and the libraries that glue the processes together are explicitly BSD licensed, > so it can be perfectly legal to use proprietary modules in xorp. I have no > idea if that is how Pica8 is implementing their code, however. > > Thanks, > Ben > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > From greearb at candelatech.com Sun Jul 15 09:39:56 2012 From: greearb at candelatech.com (Ben Greear) Date: Sun, 15 Jul 2012 09:39:56 -0700 Subject: [Xorp-users] Question regarding GPL license In-Reply-To: References: <4FFEE0A8.1080002@candelatech.com> Message-ID: <5002F25C.8090204@candelatech.com> On 07/15/2012 08:22 AM, ??? wrote: > Hi Ben Greear, > This weekend I found the 1.0 version source code released by pica8, > after some quick glance, I noted that in order to implement their CLI > shell, they inherit XORP shell class and implement a new CLI shell. > Then I am a little confused regarding in your letter about that it > can be perfectly legal to use proprietary modules in XORP , because > CLI related source code is released under GPL, If I (not pica8) want > to build some proprietary module and want implement a different but > like XORP CLI shell, the only way I can do is release the CLI shell > under GPL ? (Maybe the CLI shell is customed and doesn't mean too much > to be released under GPL). > Hoping for reply from you or others list members, thanks a lot. If code is modified version of GPL code, or links with it at compile time, then it is still GPL. This is true no matter how trivial are the changes you made. But, you can write a routing protocol (such as OSPF) that uses BSD or LGPL licensed XRL logic to talk to the xorp core. As long as the XRL and other Xorp BSD/LGPL licensed code is the only Xorp code you use/link-with (and all other code to implement OSPF is your own property), then you can license it proprietary if you want. Any changes you made to the GPL core logic (fea, rib, etc) would still have to be release GPL. Or, if you re-write the CLI module and only use the XRL glue logic from XORP and all other code is yours, then you can license your CLI module proprietary. You just need to make sure that you are not linking with any GPL licensed modules. Please note that I Am Not A Lawyer, and my comments should not be considered to be guaranteed to be correct. If you decide to try using proprietary modules with Xorp you should consult a real lawyer and read the GPL and LGPL licenses closely yourself. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From ganeshreddyk at gmail.com Mon Jul 16 04:30:51 2012 From: ganeshreddyk at gmail.com (Ganesh Reddy K) Date: Mon, 16 Jul 2012 17:00:51 +0530 Subject: [Xorp-users] Multicast traffic is not forwarded in a specific deployment as mentioned in the mail In-Reply-To: References: <82B681751FE46F4AB3FCA7390B780FD1051A6AE0@039-SN1MPN1-001.039d.mgd.msft.net> <54DD4F682C240845BF5F7D0EECBDB6F20839A4D4@EXDB3.ug.kth.se> <82B681751FE46F4AB3FCA7390B780FD1051AFFDE@039-SN1MPN1-002.039d.mgd.msft.net> Message-ID: Hi, I have tried adding alternate subnet configuration, Even now, the traffic is not forwarded. But this time, i saw that multicast route () is disappearing in kernel when Listener is on. Setup:------ H1 -------------- eth1 DEVICE eth0 -------------- H2 Sender listener. Observation1) Device status:-- tcpdump -ni eth1 device eth1 entered promiscuous mode tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 68 bytes 03:14:07.573648 IP 192.168.11.54.46442 > 226.0.6.130.5000: UDP, length: 36 03:14:08.573617 IP 192.168.11.54.46442 > 226.0.6.130.5000: UDP, length: 36 .. . [root at P2020RDB igateway]# cat /proc/net/ip_mr_* Group Origin Iif Pkts Bytes Wrong Oifs Interface BytesIn PktsIn BytesOut PktsOut Flags Local Remote 0 eth0 0 0 0 0 00000 C0A80164 00000000 1 pimreg 0 0 0 0 00004 C0A80164 00000000 2 eth1 175296 2739 0 0 00000 C0A80264 00000000 .. . [root at P2020RDB igateway]# cat /proc/net/ip_mr_cache Group Origin Iif Pkts Bytes Wrong Oifs E2000682 C0A80B36 2 3 192 0 (After Alternate subnet configuration is done on eth1, this route is disappeared, when Listener is runnig on eth0 side of Device) After enabling DEBUG prints in source code, below messages looks to be problematic.:----- pim_mre_join_prune.c:-- "WARNING xorp_pimsm4 PIM JoinDesired (S,G) = false; upstream neighbor for source 192.168.11.54 and group 226.0.6.130: not found" Observation 2 ) I am going through xorp-notes RELEASE notes http://fossies.org/unix/misc/xorp-1.8.5-src.tar.gz:a/xorp/pim/TODO * PIM IMPL: 21 If the PIM-SM module doesn't know the RP address, then it shouldn't 22 include the register_vif in the MFC entry's outgoing interface set. My comment/DOUBT In the above traffic scenario, does the above statement confirms the xorp existing behavior . Observation 3) While going through source pim_mrt.cc, below function has the warning comment :-- saying order is important. i.e, does the traffic in above scenario follows search/creation order properly ? (S,G) (S,G,rpt) (*,G) (*,*,RP) How exactly order differentiates ..given below the source ? // XXX: @create_flags must be a subset of @lookup_flags // XXX: if no creation allowed, the entry that it returns may be the // next one in the map. // // XXX: if the entry to lookup and/or create is (*,*,RP), then: // - If group is IPvX::ZERO(family()), then we lookup/create the // entry by using 'source' which is the RP address // - If group is NOT IPvX::ZERO(family()), then we lookup/create the // entry by lookup first which is the RP for 'group'. // - Regardless of the group address, the created (*,*,RP) entry // always has a group address of IPvX::MULTICAST_BASE(family()) PimMre * PimMrt::pim_mre_find(const IPvX& source, const IPvX& group, uint32_t lookup_flags, uint32_t create_flags) { PimMre *pim_mre = NULL; create_flags &= lookup_flags; // // Try to lookup if entry was installed already. // XXX: the order is important, because we want the longest-match. // XLOG_INFO("%s(%d)-TEST: src = %s dst = %s, lookup_flags %X create_flags %X\r\n",__FUNCTION__, __LINE__, cstring(source), cstring(group),lookup_flags, create_flags); do { if (lookup_flags & PIM_MRE_SG) { // // (S,G) entry // pim_mre = _pim_mrt_sg.find(source, group); if (pim_mre != NULL) break; } if (lookup_flags & PIM_MRE_SG_RPT) { // // (S,G,rpt) entry // pim_mre = _pim_mrt_sg_rpt.find(source, group); if (pim_mre != NULL) break; } if (lookup_flags & PIM_MRE_WC) { // // (*,G) entry // pim_mre = _pim_mrt_g.find(IPvX::ZERO(family()), group); if (pim_mre != NULL) break; } if (lookup_flags & PIM_MRE_RP) { // // (*,*,RP) entry // if (group == IPvX::ZERO(family())) { // XXX: the entry is specified by the RP address ('source') pim_mre = _pim_mrt_rp.find(source, IPvX::MULTICAST_BASE(family())); if (pim_mre != NULL) break; } else { // XXX: the entry is specified by the group address PimRp *pim_rp = pim_node()->rp_table().rp_find(group); if (pim_rp != NULL) pim_mre = _pim_mrt_rp.find(pim_rp->rp_addr(), IPvX::MULTICAST_BASE(family())); } if (pim_mre != NULL) break; } } while (false); if (pim_mre != NULL) return (pim_mre); // // Lookup failed. Create the entry if creation is allowed. // // If creation allowed, create the entry, insert it and return it. // XXX: the order is important, because we want the longest-match. do { if (create_flags & (PIM_MRE_SG)) { // // (S,G) entry // // Create and insert the entry if (create_flags & PIM_MRE_SG_RPT) { // // (S,G,rpt) entry // // Create and insert the entry ... .. } if (create_flags & PIM_MRE_WC) { // // (*,G) entry // // Create and insert the entry ... .. } if (create_flags & PIM_MRE_RP) { // // (*,*,RP) entry // // Create and insert the entry ... .. } .. . } On Fri, Jul 13, 2012 at 12:38 PM, Ganesh Reddy K wrote: > I was going through xorp-source: > > xorp source filename: pim/pim_mfc.cc. A comment is added > about. is_directly_connected_s() . Any reason for doing this > check in couple of places ? If we bypass this check in all places, > any side affects ? > > void PimMfc::recompute_iif_olist_mfc() > { > > // > // Compute the new iif and the olist > // > // XXX: The computation is loosely based on the > // "On receipt of data from S to G on interface iif:" procedure. > // > // Note that the is_directly_connected_s() check is not in the > // spec, but for all practical purpose we want it here. > // > > > On Mon, Jul 9, 2012 at 6:09 PM, Reddy Ganesh-B38514 > wrote: >> I have configured "set protocols pimsm4 static-rps rp 192.168.4.2 group-prefix 224.0.0.0/4" on the Device >> >> After this configuration, the Multicast route is properly added with Oif as eth4 VIF index. But the still the traffic is not receiving at the multicast listener. In /proc/net/ip_mr_cache "Wrong" counter is incrementing for each packet. >> >> By seeing the linux multicast routing code flow: net/ipv4/ipmr.c, it is understood that, ip_mr_forward () is unsuccessful and returning with "dont_forward" hence "wrong_if" counter is incremented. Seems packet dropped after routing. >> >> I did not understand this behavior after adding static-RP. Did I miss anything on this scenario/configuration ? >> >> >> >> -----Original Message----- >> From: Dan Rosenqvist [mailto:danro at kth.se] >> Sent: Friday, July 06, 2012 10:31 PM >> To: Ganesh Reddy K; igorm at etf.rs; xorp-users at xorp.org >> Cc: Bv Rajesh-B35907; sridhar pothuganti; nandakishoreie14 at gmail.com; Reddy Ganesh-B38514 >> Subject: SV: [Xorp-users] Multicast traffic is not forwarded in a specific deployment as mentioned in the mail >> >> Hi, >> >> I think the problem you're experiencing is due to the lack of a rendez-vous point (RP). You can use either static RPs or use the bootstrap mechanism. For guidance, please have a look at the examples in www.xorp.org/config (think there should be some examples for both static and bootstrap). >> >> Regards, >> Dan >> ________________________________________ >> Fr?n: xorp-users-bounces at xorp.org [xorp-users-bounces at xorp.org] för Ganesh Reddy K [ganeshreddyk at gmail.com] >> Skickat: den 6 juli 2012 07:03 >> Till: igorm at etf.rs; xorp-users at xorp.org >> Kopia: Bv Rajesh-B35907; sridhar pothuganti; nandakishoreie14 at gmail.com; Reddy Ganesh-B38514 >> ?mne: Re: [Xorp-users] Multicast traffic is not forwarded in a specific deployment as mentioned in the mail >> >> Tried this one also, but no progress on this. I hope there is >> something is happening, need to confirm either expected behavior of XORP/Linux or It is known Issue. I will check implementation details. >> >> Thanks in advance, >> >> Any quick suggestions welcome.. >> >> During this testcase, we are observing XORP statistics on the device are as followss ============================================================ >> show igmp group >> >> Interface Group Source LastReported Timeout V State >> eth0 224.0.0.2 0.0.0.0 192.168.1.100 157 3 E >> eth0 224.0.0.13 0.0.0.0 192.168.1.100 157 3 E >> eth0 224.0.0.22 0.0.0.0 192.168.1.100 157 3 E >> eth0 224.0.0.251 0.0.0.0 192.168.1.50 160 3 E >> eth0 239.11.11.11 0.0.0.0 192.168.1.50 160 3 E >> eth1 224.0.0.2 0.0.0.0 192.168.2.100 155 3 E >> eth1 224.0.0.13 0.0.0.0 192.168.2.100 155 3 E >> eth1 224.0.0.22 0.0.0.0 192.168.2.100 155 3 E >> eth2 224.0.0.2 0.0.0.0 192.168.3.100 158 3 E >> eth2 224.0.0.13 0.0.0.0 192.168.3.100 158 3 E >> eth2 224.0.0.22 0.0.0.0 192.168.3.100 158 3 E >> eth3 224.0.0.2 0.0.0.0 192.168.4.100 161 3 E >> eth3 224.0.0.13 0.0.0.0 192.168.4.100 161 3 E >> eth3 224.0.0.22 0.0.0.0 192.168.4.100 161 3 E >> >> show mfea dataflow >> >> Group Source >> 239.11.11.11 192.168.11.54 >> Measured(Start|Packets|Bytes) Type Thresh(Interval|Packets|Bytes) Remain >> 56253.252679|627|? <= 210.0|0|? 170.767324 >> >> >> show mfea interface >> >> Interface State Vif/PifIndex Addr Flags >> eth0 UP 0/4 192.168.1.100 MULTICAST BROADCAST KERN_UP >> eth1 UP 1/3 192.168.2.100 MULTICAST BROADCAST KERN_UP >> eth2 UP 2/5 192.168.3.100 MULTICAST BROADCAST KERN_UP >> eth3 UP 3/7 192.168.4.100 MULTICAST BROADCAST KERN_UP >> register_vif UP 4/4 192.168.1.100 PIM_REGISTER KERN_UP >> >> ============================================================ >> >> >> >> On Thu, Jul 5, 2012 at 10:04 PM, Igor Maravi? wrote: >>> Ufffff... Xorp isn't doing any spoof checking in that I'm sure. >>> To me, even if there aren't any discard packets logged, it still looks >>> like reverse path filtering. >>> >>> Try this: >>> >>> sysctl -w net.ipv4.conf.default.rp_filter=0 >>> >>> if that doesn't work I really don't know what the problem is :) BR >>> Igor >>> >>> 2012/7/5 Ganesh Reddy K : >>>> Thanks a lot for the detailed inputs, >>>> >>>> I have added the routes as suggested, but still the traffic is not >>>> forwarded . Did not observe any discards in ' netstat -s IP'. >>>> >>>> In general, When multicast UDP cache-miss occurs and >>>> subscriber is listened for that group, Then only multicast routing >>>> services will add the multicast ROUTE in linux kernel . The >>>> forwarding is taken care by Linux routing mechanism. I guess, In >>>> this scenario, UDP cache miss is properly given to XORP daemons, but >>>> could not fulfill the entire route (i.e ip_mr_cache with valid Oif ) >>>> . There may be possible spoof check in PIM daemons . >>>> >>>> Is my thought justifies the behavior ? >>>> >>>> ================ >>>> netstat -s IP >>>> Ip: >>>> 67296 total packets received >>>> 0 forwarded >>>> 0 incoming packets discarded >>>> 42784 incoming packets delivered >>>> 41760 requests sent out >>>> Icmp: >>>> 0 ICMP messages received >>>> 0 input ICMP message failed. >>>> ICMP input histogram: >>>> 0 ICMP messages sent >>>> 0 ICMP messages failed >>>> ICMP output histogram: >>>> Tcp: >>>> 50 active connections openings >>>> 49 passive connection openings >>>> 0 failed connection attempts >>>> 0 connection resets received >>>> 35 connections established >>>> 40788 segments received >>>> 39837 segments send out >>>> 0 segments retransmited >>>> 0 bad segments received. >>>> 0 resets sent >>>> Udp: >>>> 0 packets received >>>> 0 packets to unknown port received. >>>> 0 packet receive errors >>>> 0 packets sent >>>> RcvbufErrors: 0 >>>> SndbufErrors: 0 >>>> UdpLite: >>>> InDatagrams: 0 >>>> NoPorts: 0 >>>> InErrors: 0 >>>> OutDatagrams: 0 >>>> RcvbufErrors: 0 >>>> SndbufErrors: 0 >>>> error parsing /proc/net/snmp: Success ================ >>>> >>>> On Thu, Jul 5, 2012 at 8:07 PM, Igor Maravi? wrote: >>>>> sysctl -w net.ipv4.conf.eth3.rp_filter=0 sysctl -w >>>>> net.ipv4.conf.eth2.rp_filter=0 sysctl -w >>>>> net.ipv4.conf.all.rp_filter=0 sysctl -w >>>>> net.ipv4.conf.default.rp_filter=0 >>>>> >>>>> for me, echo isn't working. I use this commands to set values. >>>>> >>>>> 2012/7/5 Igor Maravi? : >>>>>> My bad... I forgot set protocols static part... >>>>>> >>>>>> command in xorpsh is >>>>>> >>>>>> #set protocols static interface-route 192.168.17.17/32 >>>>>> next-hop-interface eth3 #set protocols static interface-route >>>>>> 192.168.17.17/32 next-hop-vif eth3 >>>>>> >>>>>> If my theory is ok when you send packets from H1 to H2, they are >>>>>> dropped in Linux. >>>>>> You can confirm this if you run >>>>>> >>>>>> netstat -s IP >>>>>> >>>>>> and you see that number of discarded IP packets is increasing. >>>>>> My proposals are for that case. >>>>>> BR >>>>>> Igor >>>>>> >>>>>> 2012/7/5 Reddy Ganesh-B38514 : >>>>>>> Echo 0 > /proc/sys/net/ipv4/conf/eth3/rp_filter >>>>>>> Echo 0 > /proc/sys/net/ipv4/conf/eth2/rp_filter >>>>>>> Echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter >>>>>>> >>>>>>> As per the step 1, I have Disabled the rp_filter on the Device. Still the problem persists. >>>>>>> >>>>>>> I tried to configure commands mentioned in step 2 also, But I could not locate the exact commands in xorp config shell. Did I miss anything ?? >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Igor Maravi? [mailto:igorm at etf.rs] >>>>>>> Sent: Thursday, July 05, 2012 12:50 PM >>>>>>> To: Ganesh Reddy K >>>>>>> Cc: xorp-users at xorp.org; Bv Rajesh-B35907; >>>>>>> nandakishoreie14 at gmail.com; Reddy Ganesh-B38514 >>>>>>> Subject: Re: [Xorp-users] Multicast traffic is not forwarded in a >>>>>>> specific deployment as mentioned in the mail >>>>>>> >>>>>>> I'm 99% sure that this isn't Xorp problem :) Linux, won't forward packets if the src address in packet is unknown to him. >>>>>>> So, at least I think that, you have 2 possible solutions: >>>>>>> 1. Turn off rp filtering on Xorp box (reference - >>>>>>> http://lartc.org/howto/lartc.kernel.html) >>>>>>> 2. Set static interface route to 192.168.17.17/32 on eth3, with Xorp ( >>>>>>> interface-route 192.168.17.17/32 { >>>>>>> next-hop-interface: "eth3" >>>>>>> next-hop-vif: "eth3" >>>>>>> } >>>>>>> ) >>>>>>> >>>>>>> Let me know if it worked. :) >>>>>>> BR >>>>>>> Igor >>>>>>> >>>>>>> 2012/7/5 Ganesh Reddy K : >>>>>>>> Hi , >>>>>>>> >>>>>>>> We are trying to exercise a multicast traffic forwarding scenario >>>>>>>> on a powerPC device:-- >>>>>>>> >>>>>>>> After H2 subscribed for the Group G1, The G1 multicast traffic >>>>>>>> is not receiving at H2. But, when the H1 ip is in the same >>>>>>>> subnet, traffic is properly forwarded to H2 without any issues. >>>>>>>> >>>>>>>> Test setup:-- >>>>>>>> >>>>>>>> H1 ------------------------------------ eth3 XORP eth2 >>>>>>>> -------------------------------------------- H2 >>>>>>>> >>>>>>>> 192.168.17.17 192.168.4.2 192.168.3.2 >>>>>>>> 192.168.3.10 >>>>>>>> >>>>>>>> UDP-G1 multicaststream >>>>>>>> Mcast listener for G1 >>>>>>>> >>>>>>>> G1-239.7.7.7 >>>>>>>> >>>>>>>> >>>>>>>> 1) COnfigured XORP on the device, xorp.conf contents are . >>>>>>>> >>>>>>>> ===========XORP configuration =========== >>>>>>>> >>>>>>>> protocols { >>>>>>>> fib2mrib { >>>>>>>> } >>>>>>>> igmp { >>>>>>>> >>>>>>>> interface eth0 { >>>>>>>> vif eth0 { >>>>>>>> version: 3 >>>>>>>> } >>>>>>>> } >>>>>>>> interface eth1 { >>>>>>>> vif eth1 { >>>>>>>> version: 3 >>>>>>>> } } >>>>>>>> interface eth2 { >>>>>>>> vif eth2 { >>>>>>>> version: 3 >>>>>>>> } >>>>>>>> } >>>>>>>> interface eth3 { >>>>>>>> >>>>>>>> vif eth3 { >>>>>>>> version: 3 >>>>>>>> } >>>>>>>> } } >>>>>>>> >>>>>>>> >>>>>>>> pimsm4 { >>>>>>>> interface eth0 { >>>>>>>> >>>>>>>> vif eth0 { >>>>>>>> } >>>>>>>> } >>>>>>>> interface "register_vif" { >>>>>>>> vif "register_vif" { >>>>>>>> } >>>>>>>> >>>>>>>> } >>>>>>>> interface eth1 { >>>>>>>> vif eth1 { >>>>>>>> >>>>>>>> } >>>>>>>> } >>>>>>>> interface eth2 { >>>>>>>> vif eth2 { >>>>>>>> } >>>>>>>> } >>>>>>>> interface eth3 { >>>>>>>> >>>>>>>> vif eth3 { >>>>>>>> } >>>>>>>> } >>>>>>>> } >>>>>>>> } >>>>>>>> fea { >>>>>>>> unicast-forwarding4 { >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> unicast-forwarding6 { >>>>>>>> } >>>>>>>> } >>>>>>>> interfaces { >>>>>>>> interface eth0 { >>>>>>>> vif eth0 { >>>>>>>> } >>>>>>>> >>>>>>>> default-system-config { >>>>>>>> } >>>>>>>> } >>>>>>>> interface eth1 { >>>>>>>> >>>>>>>> vif eth1 { >>>>>>>> } >>>>>>>> default-system-config { >>>>>>>> } >>>>>>>> } >>>>>>>> interface eth2 { >>>>>>>> vif eth2 { >>>>>>>> >>>>>>>> } >>>>>>>> default-system-config { >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> interface eth3 { >>>>>>>> vif eth3 { >>>>>>>> } >>>>>>>> >>>>>>>> default-system-config { >>>>>>>> } >>>>>>>> } >>>>>>>> } >>>>>>>> plumbing { >>>>>>>> >>>>>>>> mfea4 { >>>>>>>> interface eth0 { >>>>>>>> vif eth0 { >>>>>>>> >>>>>>>> } >>>>>>>> } >>>>>>>> interface "register_vif" { >>>>>>>> >>>>>>>> vif "register_vif" { >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> interface eth1 { >>>>>>>> vif eth1 { >>>>>>>> } >>>>>>>> >>>>>>>> } >>>>>>>> >>>>>>>> interface eth2 { >>>>>>>> vif eth2 { >>>>>>>> } >>>>>>>> >>>>>>>> } >>>>>>>> interface eth3 { >>>>>>>> vif eth3 { >>>>>>>> >>>>>>>> } >>>>>>>> } >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> ============= xorp configuration ============= >>>>>>>> >>>>>>>> 2) From H1, started sending UDP stream targeting G1 using VLC player. >>>>>>>> >>>>>>>> Capture of "tcpdump -ni eth3" on Device shows the UDP-G1 >>>>>>>> packets as below .. >>>>>>>> 09:27:50.081561 IP 192.168.17.17.4146 > 239.7.7.7.1234: UDP, >>>>>>>> length >>>>>>>> 1328 .. >>>>>>>> >>>>>>>> 3) added a static route for the unknown network on Device (i.e >>>>>>>> route add -net 192.168.17.17/32 dev eth3) >>>>>>>> >>>>>>>> 4) From H2, started VLC listener for the group G1. >>>>>>>> >>>>>>>> It is verified in the Device that, IGMP join is received. >>>>>>>> capture of " show igmp group" on XORP console >>>>>>>> >>>>>>>> Interface Group Source LastReported Timeout V State >>>>>>>> >>>>>>>> eth0 224.0.0.2 0.0.0.0 192.168.1.2 223 3 E >>>>>>>> >>>>>>>> eth0 224.0.0.13 0.0.0.0 192.168.1.2 223 3 E >>>>>>>> >>>>>>>> eth0 224.0.0.22 0.0.0.0 192.168.1.2 223 3 E >>>>>>>> >>>>>>>> eth1 224.0.0.2 0.0.0.0 192.168.2.2 225 3 E >>>>>>>> >>>>>>>> eth1 224.0.0.13 0.0.0.0 192.168.2.2 225 3 E >>>>>>>> >>>>>>>> eth1 224.0.0.22 0.0.0.0 192.168.2.2 225 3 E >>>>>>>> >>>>>>>> eth2 224.0.0.2 0.0.0.0 192.168.3.2 231 3 E >>>>>>>> >>>>>>>> eth2 224.0.0.13 0.0.0.0 192.168.3.2 231 3 E >>>>>>>> >>>>>>>> eth2 224.0.0.22 0.0.0.0 192.168.3.2 231 3 E >>>>>>>> >>>>>>>> eth2 239.1.1.1 0.0.0.0 192.168.3.10 228 3 E >>>>>>>> >>>>>>>> eth2 239.7.7.7 0.0.0.0 192.168.3.10 228 3 E >>>>>>>> >>>>>>>> eth2 239.255.255.250 0.0.0.0 192.168.3.10 228 3 E >>>>>>>> >>>>>>>> eth3 224.0.0.2 0.0.0.0 192.168.4.2 230 3 E >>>>>>>> >>>>>>>> eth3 224.0.0.13 0.0.0.0 192.168.4.2 230 3 E >>>>>>>> >>>>>>>> eth3 224.0.0.22 0.0.0.0 192.168.4.2 230 3 E >>>>>>>> >>>>>>>> root at p4080ds> >>>>>>>> >>>>>>>> 5) But the traffic is not receiving at H2. Below is the statistics >>>>>>>> related ip_mr on the device >>>>>>>> >>>>>>>> cat /proc/net/ip_mr* >>>>>>>> >>>>>>>> Group Origin Iif Pkts Bytes Wrong Oifs >>>>>>>> EF070707 C0A81111 3 453 614268 0 >>>>>>>> Interface BytesIn PktsIn BytesOut PktsOut Flags Local Remote >>>>>>>> 0 eth0 0 0 0 0 00000 C0A80102 00000000 >>>>>>>> 1 eth1 0 0 0 0 00000 C0A80202 00000000 >>>>>>>> 2 eth2 0 0 0 0 00000 C0A80302 00000000 >>>>>>>> 3 eth3 3971724 2929 0 0 00000 C0A80402 00000000 >>>>>>>> 4 pimreg 0 0 0 0 00004 C0A80102 >>>>>>>> >>>>>>>> >>>>>>>> 6) But, when the H1 ip is in the same subnet, traffic is >>>>>>>> properly forwarded to H2 without any issues. >>>>>>>> >>>>>>>> Did anybody tried this scenario ? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Ganesh >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 fortitude.zhang at gmail.com Mon Jul 16 07:39:09 2012 From: fortitude.zhang at gmail.com (=?GB2312?B?1cW2q9HH?=) Date: Mon, 16 Jul 2012 14:39:09 +0000 Subject: [Xorp-users] Question regarding GPL license In-Reply-To: <5002F25C.8090204@candelatech.com> References: <4FFEE0A8.1080002@candelatech.com> <5002F25C.8090204@candelatech.com> Message-ID: Hi Ben Greear, Thanks a lot for your reply, I will take this information into account, if I decide to use XORP as codebase, I will try to consult some real lawyer (though it may be hard to find one in China:() Regards, Dongya Zhang 2012/7/15 Ben Greear : > On 07/15/2012 08:22 AM, ??? wrote: >> Hi Ben Greear, >> This weekend I found the 1.0 version source code released by pica8, >> after some quick glance, I noted that in order to implement their CLI >> shell, they inherit XORP shell class and implement a new CLI shell. >> Then I am a little confused regarding in your letter about that it >> can be perfectly legal to use proprietary modules in XORP , because >> CLI related source code is released under GPL, If I (not pica8) want >> to build some proprietary module and want implement a different but >> like XORP CLI shell, the only way I can do is release the CLI shell >> under GPL ? (Maybe the CLI shell is customed and doesn't mean too much >> to be released under GPL). >> Hoping for reply from you or others list members, thanks a lot. > > If code is modified version of GPL code, or links with it at compile > time, then it is still GPL. This is true no matter how trivial are the > changes you made. > > But, you can write a routing protocol (such as OSPF) that uses BSD or LGPL licensed > XRL logic to talk to the xorp core. As long as the XRL and other Xorp BSD/LGPL licensed > code is the only Xorp code you use/link-with (and all other code to implement OSPF is your > own property), then you can license it proprietary if you want. Any changes you > made to the GPL core logic (fea, rib, etc) would still have to be release GPL. > > Or, if you re-write the CLI module and only use the XRL glue logic > from XORP and all other code is yours, then you can license your > CLI module proprietary. You just need to make sure that you are not linking > with any GPL licensed modules. > > Please note that I Am Not A Lawyer, and my comments should not be considered to > be guaranteed to be correct. If you decide to try using proprietary > modules with Xorp you should consult a real lawyer and read the GPL and > LGPL licenses closely yourself. > > Thanks, > Ben > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > From greearb at candelatech.com Mon Jul 16 07:55:40 2012 From: greearb at candelatech.com (Ben Greear) Date: Mon, 16 Jul 2012 07:55:40 -0700 Subject: [Xorp-users] Question regarding GPL license In-Reply-To: References: <4FFEE0A8.1080002@candelatech.com> <5002F25C.8090204@candelatech.com> Message-ID: <50042B6C.6020606@candelatech.com> On 07/16/2012 07:39 AM, ??? wrote: > Hi Ben Greear, > Thanks a lot for your reply, I will take this information into > account, if I decide to use XORP as codebase, I will try to consult > some real lawyer (though it may be hard to find one in China:() Well, you can always just release code as GPL. What changes are you considering that would be worth making proprietary? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From phil.wiggins at gmail.com Tue Jul 17 09:32:13 2012 From: phil.wiggins at gmail.com (Phil Wiggins) Date: Tue, 17 Jul 2012 13:32:13 -0300 Subject: [Xorp-users] Fwd: Route redistribution issue In-Reply-To: References: Message-ID: Using XORP-1.8.6-WIP-16July2012, or similar 1.8.5++ version to pick up Igor's RR patch from April, we are noticing a route redistribution issue between a RIP domain in xorp and an OSPF domain in Quagga with XORP providing the route redistribution. OSPF routes aren't fully exposed back into the RIP domains. The first routed subnet in OSPF (10.0.2.0/24 or 10.0.6.0/24) is always missing in the RIP domain. In larger configurations with additional OSPF subnets, the same behavior for routed OSPF subnets repeats on the RIP side. |-- RIP --| RR |-- OSPF --| XORP XORP XORP n1 -- 10.0.0.0/24 -- n2 -- 10.0.1.0/24 -- n3 -- 10.0.2.0/24 -- n4 (Quagga) .1 .2 .1 .2 .2 .1 .1 | | 10.0.3.0/24 | | XORP XORP XORP .2 n10 --10.0.8.0/24 -- n9 -- 10.0.7.0/24 -- n8 -- 10.0.6.0/24 -- n5 (Quagga) .2 .1 .2 .1 .1 .2 n4 config ========= interface eth0 ip address 10.0.2.1/24 ! interface eth1 ip address 10.0.3.1/24 ! router ospf router-id 10.0.2.1 network 10.0.2.0/24 area 0 network 10.0.3.0/24 area 0 ! n5 config ========= interface eth0 ip address 10.0.3.2/24 ! interface eth1 ip address 10.0.6.2/24 ! router ospf router-id 10.0.3.2 network 10.0.3.0/24 area 0 network 10.0.6.0/24 area 0 ! n3 config extract ========= protocols { rip { export: "connected-to-rip,ospf4-to-rip" interface eth0 { vif eth0 { address 10.0.1.2 { } } } } ospf4 { export: "connected-to-ospf4,rip-to-ospf4" router-id: 10.0.2.2 area 0.0.0.0 { interface eth1 { vif eth1 { address 10.0.2.2 { interface-cost: 1 } } } } } } policy { policy-statement connected-to-rip { term 100 { from { protocol: "connected" } then { metric: 1 accept } } } policy-statement connected-to-ospf4 { term 200 { from { protocol: "connected" } then { accept } } } policy-statement rip-to-ospf4 { term 300 { from { protocol: "rip" } then { metric add 0 accept } } } policy-statement ospf4-to-rip { term 400 { from { protocol: "ospf4" } then { metric add 0 accept } } } } n8 config extract ========= protocols { ospf4 { export: "connected-to-ospf4,rip-to-ospf4" router-id: 10.0.6.1 area 0.0.0.0 { interface eth0 { vif eth0 { address 10.0.6.1 { } } } interface eth1 { vif eth1 { address 10.0.7.1 { } } } } } rip { export: "connected-to-rip,ospf4-to-rip" interface eth0 { vif eth0 { address 10.0.6.1 { disable: false } } } interface eth1 { vif eth1 { address 10.0.7.1 { disable: false } } } } } fea { unicast-forwarding4 { disable:false } } policy { policy-statement connected-to-rip { term 100 { from { protocol: "connected" } then { metric: 1 accept } } } policy-statement connected-to-ospf4 { term 200 { from { protocol: "connected" } then { accept } } } policy-statement rip-to-ospf4 { term 300 { from { protocol: "rip" } then { metric add 0 accept } } } policy-statement ospf4-to-rip { term 400 { from { protocol: "ospf4" } then { metric add 0 accept } } } } Phil -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120717/dcfe730e/attachment.html From igorm at etf.rs Tue Jul 17 14:39:37 2012 From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=) Date: Tue, 17 Jul 2012 23:39:37 +0200 Subject: [Xorp-users] Fwd: Route redistribution issue In-Reply-To: References: Message-ID: Phil, Could You send whole configuration file for n3 and n8. If I understood correctly, problem is that connected route 10.0.2.0/24 and 10.0.6.0/24aren't redistributed in RIP. I'll try it to look at the problem as soon as I find some time. BR Igor -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120717/139f18e6/attachment.html From phil.wiggins at gmail.com Tue Jul 17 15:27:07 2012 From: phil.wiggins at gmail.com (Phil Wiggins) Date: Tue, 17 Jul 2012 19:27:07 -0300 Subject: [Xorp-users] Fwd: Route redistribution issue In-Reply-To: References: Message-ID: Igor, Thanks for looking into this issue. I've also attached a CORE4.3 imn file, if that helps. Once the network converges, the subnet at 10.0.6.0/24 isn't visible to nodes n1 and n2. Similarly, the subnet at 10.0.2.0/24 isn't visible to nodes n9 and n10. Here are the config.boots for n3 and n8, slightly cleaned up from the previous post: n3:config.boot ============== interfaces { interface eth0 { vif eth0 { address 10.0.1.2 { prefix-length: 24 } } } interface eth1 { vif eth1 { address 10.0.2.2 { prefix-length: 24 } } } } fea { unicast-forwarding4 { disable:false } } protocols { rip { export: "connected-to-rip,ospf4-to-rip" interface eth0 { vif eth0 { address 10.0.1.2 { disable: false } } } } ospf4 { export: "connected-to-ospf4,rip-to-ospf4" router-id: 10.0.2.2 area 0.0.0.0 { interface eth1 { vif eth1 { address 10.0.2.2 { } } } } } } policy { policy-statement connected-to-rip { term 100 { from { protocol: "connected" } then { metric: 1 accept } } } policy-statement connected-to-ospf4 { term 200 { from { protocol: "connected" } then { accept } } } policy-statement rip-to-ospf4 { term 300 { from { protocol: "rip" } then { metric add 0 accept } } } policy-statement ospf4-to-rip { term 400 { from { protocol: "ospf4" } then { metric add 0 accept } } } } n8:config.boot ============== interfaces { interface eth0 { vif eth0 { address 10.0.6.1 { prefix-length: 24 } } } interface eth1 { vif eth1 { address 10.0.7.1 { prefix-length: 24 } } } } fea { unicast-forwarding4 { disable:false } } protocols { ospf4 { export: "connected-to-ospf4,rip-to-ospf4" router-id: 10.0.6.1 area 0.0.0.0 { interface eth0 { vif eth0 { address 10.0.6.1 { disable: false } } } } } rip { export: "connected-to-rip,ospf4-to-rip" interface eth1 { vif eth1 { address 10.0.7.1 { disable: false } } } } } policy { policy-statement connected-to-rip { term 100 { from { protocol: "connected" } then { metric: 1 accept } } } policy-statement connected-to-ospf4 { term 200 { from { protocol: "connected" } then { accept } } } policy-statement rip-to-ospf4 { term 300 { from { protocol: "rip" } then { metric add 0 accept } } } policy-statement ospf4-to-rip { term 400 { from { protocol: "ospf4" } then { metric add 0 accept } } } } Phil On Tue, Jul 17, 2012 at 6:39 PM, Igor Maravi? wrote: > Phil, > Could You send whole configuration file for n3 and n8. If I understood > correctly, problem is that connected route 10.0.2.0/24 and 10.0.6.0/24aren't redistributed in RIP. > I'll try it to look at the problem as soon as I find some time. > BR > Igor > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120717/898e2494/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: xorpmailinglistproblem - xorp-rr-185patched-rip+quagga-ospf.imn Type: application/octet-stream Size: 8605 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120717/898e2494/attachment-0001.obj From ganeshreddyk at gmail.com Wed Jul 18 03:14:54 2012 From: ganeshreddyk at gmail.com (Ganesh Reddy K) Date: Wed, 18 Jul 2012 15:44:54 +0530 Subject: [Xorp-users] Multiple MRIB entries with same destination prefix. Message-ID: Hi All, We have a specific requirement to add multiple MRIB-entries under same destination-prefix (for various interfaces). Multiple MRIB entries addition with same destination-prefix is not allowing in XORP. Always the entry is overwritten by the latest entry. With the present XORP behavior. Lookup/creation is happening based on the unique KEY ?destination-prefix?. Configuration commands sequence is shown below. Is there any way to configure XORP such that, it should work like a light weight IGMPProxy to forward Multicast stream. (i.e Without PIM protocol processing, and extra processing)? Please suggest me to proceed furher? Thanks, Ganesh Configuration commands:-- In the below sequence of commands, the first entry containing ?eth1? is overwritten by the second MRIB route ?eth2?. xorp@# set protocols static mrib-interface-route 192.168.11.54/32 next-hop-interface eth1 xorp@# set protocols static mrib-interface-route 192.168.11.54/32 next-hop-vif eth1 xorp@# commit xorp@# exit xorp@> show pim mrib DestPrefix NextHopRouter VifName VifIndex MetricPref Metric 192.168.1.0/24 192.168.1.100 eth0 0 0 0 192.168.2.0/24 192.168.2.100 eth1 2 0 0 192.168.3.0/24 192.168.3.100 eth2 3 0 0 192.168.11.54/32 0.0.0.0 eth1 2 1 1 xorp at P2020RDB> ==================== xorp@> configure xorp@# set protocols static mrib-interface-route 192.168.11.54/32 next-hop-interface eth2 xorp@# set protocols static mrib-interface-route 192.168.11.54/32 next-hop-vif eth2 xorp@# commit xorp@# exit xorp@> show pim mrib DestPrefix NextHopRouter VifName VifIndex MetricPref Metric 192.168.1.0/24 192.168.1.100 eth0 0 0 0 192.168.2.0/24 192.168.2.100 eth1 2 0 0 192.168.3.0/24 192.168.3.100 eth2 3 0 0 192.168.11.54/32 0.0.0.0 eth2 3 1 1 xorp@> From igorm at etf.rs Fri Jul 20 01:27:00 2012 From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=) Date: Fri, 20 Jul 2012 01:27:00 -0700 Subject: [Xorp-users] Fwd: Route redistribution issue In-Reply-To: References: Message-ID: I really didn't have time to boot up your configuration with Quagga. Could you apply patch that I've attached in email to n3 i n8 machines. After you do that, turn on the network and send me in email what do you see when you enter show route table ipv4 unicast final in xorpsh on n3 and n8. I'm interested in TAG field, which I added via patch that I've attached. BR Igor 2012/7/17 Phil Wiggins > Igor, > > Thanks for looking into this issue. I've also attached a CORE4.3 imn > file, if that helps. Once the network converges, the subnet at > 10.0.6.0/24 isn't visible to nodes n1 and n2. Similarly, the subnet at > 10.0.2.0/24 isn't visible to nodes n9 and n10. > > Here are the config.boots for n3 and n8, slightly cleaned up from the > previous post: > > n3:config.boot > ============== > interfaces { > interface eth0 { > vif eth0 { > address 10.0.1.2 { > prefix-length: 24 > } > } > } > interface eth1 { > vif eth1 { > address 10.0.2.2 { > prefix-length: 24 > } > } > } > } > > fea { > unicast-forwarding4 { > disable:false > } > } > > protocols { > rip { > export: "connected-to-rip,ospf4-to-rip" > interface eth0 { > vif eth0 { > address 10.0.1.2 { > disable: false > } > } > } > } > ospf4 { > export: "connected-to-ospf4,rip-to-ospf4" > router-id: 10.0.2.2 > area 0.0.0.0 { > interface eth1 { > vif eth1 { > address 10.0.2.2 { > } > } > } > } > } > } > > policy { > policy-statement connected-to-rip { > term 100 { > from { > protocol: "connected" > } > then { > metric: 1 > accept > } > } > } > policy-statement connected-to-ospf4 { > term 200 { > from { > protocol: "connected" > } > then { > accept > } > } > } > policy-statement rip-to-ospf4 { > term 300 { > from { > protocol: "rip" > } > then { > metric add 0 > accept > } > } > } > policy-statement ospf4-to-rip { > term 400 { > from { > protocol: "ospf4" > } > then { > metric add 0 > accept > } > } > } > } > n8:config.boot > ============== > interfaces { > interface eth0 { > vif eth0 { > address 10.0.6.1 { > prefix-length: 24 > } > } > } > interface eth1 { > vif eth1 { > address 10.0.7.1 { > prefix-length: 24 > } > } > } > } > > fea { > unicast-forwarding4 { > disable:false > } > } > > protocols { > ospf4 { > export: "connected-to-ospf4,rip-to-ospf4" > router-id: 10.0.6.1 > area 0.0.0.0 { > interface eth0 { > vif eth0 { > address 10.0.6.1 { > disable: false > } > } > } > } > } > rip { > export: "connected-to-rip,ospf4-to-rip" > interface eth1 { > vif eth1 { > address 10.0.7.1 { > disable: false > } > } > } > } > } > > policy { > policy-statement connected-to-rip { > term 100 { > from { > protocol: "connected" > } > then { > metric: 1 > accept > } > } > } > policy-statement connected-to-ospf4 { > term 200 { > from { > protocol: "connected" > } > then { > accept > } > } > } > policy-statement rip-to-ospf4 { > term 300 { > from { > protocol: "rip" > } > then { > metric add 0 > accept > } > } > } > policy-statement ospf4-to-rip { > term 400 { > from { > protocol: "ospf4" > } > then { > metric add 0 > accept > } > } > } > } > > Phil > > > On Tue, Jul 17, 2012 at 6:39 PM, Igor Maravi? wrote: > >> Phil, >> Could You send whole configuration file for n3 and n8. If I understood >> correctly, problem is that connected route 10.0.2.0/24 and 10.0.6.0/24aren't redistributed in RIP. >> I'll try it to look at the problem as soon as I find some time. >> BR >> Igor >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120720/da201914/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-DEBUG-REDISTRIBUTION.patch Type: application/octet-stream Size: 10136 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120720/da201914/attachment-0001.obj From phil.wiggins at gmail.com Fri Jul 20 06:04:43 2012 From: phil.wiggins at gmail.com (Phil Wiggins) Date: Fri, 20 Jul 2012 10:04:43 -0300 Subject: [Xorp-users] Fwd: Route redistribution issue In-Reply-To: References: Message-ID: Igor, Thanks for your persistence. I've enclosed the outputs as needed. I've also provided similar metric info from Quagga (n4, n5). n3 output: ======== root at n3:/tmp/pycore.55456/n3.conf# xorpsh Welcome to XORP v1.8.6-WIP on n3 Version tag: 00000000 Build Date: 2012-07-20 09:44 32-bit root at n3> show route table ipv4 unicast final 10.0.0.0/24 [rip(120)/1] > to 10.0.1.1 via eth0/eth0 TAGS 3 10.0.1.0/24 [connected(0)/0] > via eth0/eth0 TAGS 0, 2 10.0.2.0/24 [connected(0)/0] > via eth1/eth1 TAGS 0, 2 10.0.3.0/24 [ospf(110)/11] > to 10.0.2.1 via eth1/eth1 TAGS 1 10.0.6.0/24 [ospf(110)/21] > to 10.0.2.1 via eth1/eth1 TAGS 1 10.0.7.0/24 [ospf(110)/1] > to 10.0.2.1 via eth1/eth1 TAGS 1 10.0.8.0/24 [ospf(110)/1] > to 10.0.2.1 via eth1/eth1 TAGS 1 root at n3> n8 output: ======= root at n8:/tmp/pycore.55456/n8.conf# xorpsh Welcome to XORP v1.8.6-WIP on n8 Version tag: 00000000 Build Date: 2012-07-20 09:44 32-bit root at n8> show route table ipv4 unicast final 10.0.0.0/24 [ospf(110)/1] > to 10.0.6.2 via eth0/eth0 TAGS 1 10.0.1.0/24 [ospf(110)/1] > to 10.0.6.2 via eth0/eth0 TAGS 1 10.0.2.0/24 [ospf(110)/21] > to 10.0.6.2 via eth0/eth0 TAGS 1 10.0.3.0/24 [ospf(110)/11] > to 10.0.6.2 via eth0/eth0 TAGS 1 10.0.6.0/24 [connected(0)/0] > via eth0/eth0 TAGS 0, 2 10.0.7.0/24 [connected(0)/0] > via eth1/eth1 TAGS 0, 2 10.0.8.0/24 [rip(120)/1] > to 10.0.7.2 via eth1/eth1 TAGS 3 root at n8> n4 output: ======= n4# sho ip ro Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - ISIS, B - BGP, > - selected route, * - FIB route O>* 10.0.0.0/24 [110/1] via 10.0.2.2, eth0, 00:04:01 O>* 10.0.1.0/24 [110/0] via 10.0.2.2, eth0, 00:04:15 O 10.0.2.0/24 [110/10] is directly connected, eth0, 00:04:16 C>* 10.0.2.0/24 is directly connected, eth0 O 10.0.3.0/24 [110/10] is directly connected, eth1, 00:05:02 C>* 10.0.3.0/24 is directly connected, eth1 O>* 10.0.6.0/24 [110/20] via 10.0.3.2, eth1, 00:04:12 O>* 10.0.7.0/24 [110/0] via 10.0.3.2, eth1, 00:04:11 O>* 10.0.8.0/24 [110/1] via 10.0.3.2, eth1, 00:04:11 C>* 127.0.0.0/8 is directly connected, lo n4# n5 output: ======= n5# sho ip ro Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - ISIS, B - BGP, > - selected route, * - FIB route O>* 10.0.0.0/24 [110/1] via 10.0.3.1, eth0, 00:04:20 O>* 10.0.1.0/24 [110/0] via 10.0.3.1, eth0, 00:04:30 O>* 10.0.2.0/24 [110/20] via 10.0.3.1, eth0, 00:04:31 O 10.0.3.0/24 [110/10] is directly connected, eth0, 00:05:31 C>* 10.0.3.0/24 is directly connected, eth0 O 10.0.6.0/24 [110/10] is directly connected, eth1, 00:05:31 C>* 10.0.6.0/24 is directly connected, eth1 O>* 10.0.7.0/24 [110/0] via 10.0.6.1, eth1, 00:04:44 O>* 10.0.8.0/24 [110/1] via 10.0.6.1, eth1, 00:04:44 C>* 127.0.0.0/8 is directly connected, lo n5# Phil On Fri, Jul 20, 2012 at 5:27 AM, Igor Maravi? wrote: > I really didn't have time to boot up your configuration with Quagga. > Could you apply patch that I've attached in email to n3 i n8 machines. > After you do that, turn on the network and send me in email what do you > see when you enter > > show route table ipv4 unicast final > > in xorpsh on n3 and n8. I'm interested in TAG field, which I added via > patch that I've attached. > BR > Igor > > > 2012/7/17 Phil Wiggins > >> Igor, >> >> Thanks for looking into this issue. I've also attached a CORE4.3 imn >> file, if that helps. Once the network converges, the subnet at >> 10.0.6.0/24 isn't visible to nodes n1 and n2. Similarly, the subnet at >> 10.0.2.0/24 isn't visible to nodes n9 and n10. >> >> Here are the config.boots for n3 and n8, slightly cleaned up from the >> previous post: >> >> n3:config.boot >> ============== >> interfaces { >> interface eth0 { >> vif eth0 { >> address 10.0.1.2 { >> prefix-length: 24 >> } >> } >> } >> interface eth1 { >> vif eth1 { >> address 10.0.2.2 { >> prefix-length: 24 >> } >> } >> } >> } >> >> fea { >> unicast-forwarding4 { >> disable:false >> } >> } >> >> protocols { >> rip { >> export: "connected-to-rip,ospf4-to-rip" >> interface eth0 { >> vif eth0 { >> address 10.0.1.2 { >> disable: false >> } >> } >> } >> } >> ospf4 { >> export: "connected-to-ospf4,rip-to-ospf4" >> router-id: 10.0.2.2 >> area 0.0.0.0 { >> interface eth1 { >> vif eth1 { >> address 10.0.2.2 { >> } >> } >> } >> } >> } >> } >> >> policy { >> policy-statement connected-to-rip { >> term 100 { >> from { >> protocol: "connected" >> } >> then { >> metric: 1 >> accept >> } >> } >> } >> policy-statement connected-to-ospf4 { >> term 200 { >> from { >> protocol: "connected" >> } >> then { >> accept >> } >> } >> } >> policy-statement rip-to-ospf4 { >> term 300 { >> from { >> protocol: "rip" >> } >> then { >> metric add 0 >> accept >> } >> } >> } >> policy-statement ospf4-to-rip { >> term 400 { >> from { >> protocol: "ospf4" >> } >> then { >> metric add 0 >> accept >> } >> } >> } >> } >> n8:config.boot >> ============== >> interfaces { >> interface eth0 { >> vif eth0 { >> address 10.0.6.1 { >> prefix-length: 24 >> } >> } >> } >> interface eth1 { >> vif eth1 { >> address 10.0.7.1 { >> prefix-length: 24 >> } >> } >> } >> } >> >> fea { >> unicast-forwarding4 { >> disable:false >> } >> } >> >> protocols { >> ospf4 { >> export: "connected-to-ospf4,rip-to-ospf4" >> router-id: 10.0.6.1 >> area 0.0.0.0 { >> interface eth0 { >> vif eth0 { >> address 10.0.6.1 { >> disable: false >> } >> } >> } >> } >> } >> rip { >> export: "connected-to-rip,ospf4-to-rip" >> interface eth1 { >> vif eth1 { >> address 10.0.7.1 { >> disable: false >> } >> } >> } >> } >> } >> >> policy { >> policy-statement connected-to-rip { >> term 100 { >> from { >> protocol: "connected" >> } >> then { >> metric: 1 >> accept >> } >> } >> } >> policy-statement connected-to-ospf4 { >> term 200 { >> from { >> protocol: "connected" >> } >> then { >> accept >> } >> } >> } >> policy-statement rip-to-ospf4 { >> term 300 { >> from { >> protocol: "rip" >> } >> then { >> metric add 0 >> accept >> } >> } >> } >> policy-statement ospf4-to-rip { >> term 400 { >> from { >> protocol: "ospf4" >> } >> then { >> metric add 0 >> accept >> } >> } >> } >> } >> >> Phil >> >> >> On Tue, Jul 17, 2012 at 6:39 PM, Igor Maravi? wrote: >> >>> Phil, >>> Could You send whole configuration file for n3 and n8. If I understood >>> correctly, problem is that connected route 10.0.2.0/24 and 10.0.6.0/24aren't redistributed in RIP. >>> I'll try it to look at the problem as soon as I find some time. >>> BR >>> Igor >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120720/d183a1ad/attachment-0001.html From igorm at etf.rs Fri Jul 20 07:36:06 2012 From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=) Date: Fri, 20 Jul 2012 16:36:06 +0200 Subject: [Xorp-users] Fwd: Route redistribution issue In-Reply-To: References: Message-ID: Well, This is just as it should be. You're exporting connected routes to rip and ospf, thus they have two tags (0 and 2). You're exporting ospf routes to rip, thus they have only one tag (1). As you can see 10.0.6.0/24 (and 10.0.2.0/24) has the same tag as other OSPF routes. Because of that it should be redistributed the same way as other OSPF routes. It looks like RIP BUG to me. Could you send me routes that you see on n2 and n9. BR Igor 2012/7/20 Phil Wiggins > Igor, > > Thanks for your persistence. I've enclosed the outputs as needed. I've > also provided similar metric info from Quagga (n4, n5). > > n3 output: > ======== > root at n3:/tmp/pycore.55456/n3.conf# xorpsh > Welcome to XORP v1.8.6-WIP on n3 > Version tag: 00000000 Build Date: 2012-07-20 09:44 32-bit > root at n3> show route table ipv4 unicast final > 10.0.0.0/24 [rip(120)/1] > > to 10.0.1.1 via eth0/eth0 TAGS 3 > 10.0.1.0/24 [connected(0)/0] > > via eth0/eth0 TAGS 0, 2 > 10.0.2.0/24 [connected(0)/0] > > via eth1/eth1 TAGS 0, 2 > 10.0.3.0/24 [ospf(110)/11] > > to 10.0.2.1 via eth1/eth1 TAGS 1 > 10.0.6.0/24 [ospf(110)/21] > > to 10.0.2.1 via eth1/eth1 TAGS 1 > 10.0.7.0/24 [ospf(110)/1] > > to 10.0.2.1 via eth1/eth1 TAGS 1 > 10.0.8.0/24 [ospf(110)/1] > > to 10.0.2.1 via eth1/eth1 TAGS 1 > root at n3> > > n8 output: > ======= > root at n8:/tmp/pycore.55456/n8.conf# xorpsh > Welcome to XORP v1.8.6-WIP on n8 > Version tag: 00000000 Build Date: 2012-07-20 09:44 32-bit > root at n8> show route table ipv4 unicast final > 10.0.0.0/24 [ospf(110)/1] > > to 10.0.6.2 via eth0/eth0 TAGS 1 > 10.0.1.0/24 [ospf(110)/1] > > to 10.0.6.2 via eth0/eth0 TAGS 1 > 10.0.2.0/24 [ospf(110)/21] > > to 10.0.6.2 via eth0/eth0 TAGS 1 > 10.0.3.0/24 [ospf(110)/11] > > to 10.0.6.2 via eth0/eth0 TAGS 1 > 10.0.6.0/24 [connected(0)/0] > > via eth0/eth0 TAGS 0, 2 > 10.0.7.0/24 [connected(0)/0] > > via eth1/eth1 TAGS 0, 2 > 10.0.8.0/24 [rip(120)/1] > > to 10.0.7.2 via eth1/eth1 TAGS 3 > root at n8> > > n4 output: > ======= > n4# sho ip ro > Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, > I - ISIS, B - BGP, > - selected route, * - FIB route > > O>* 10.0.0.0/24 [110/1] via 10.0.2.2, eth0, 00:04:01 > O>* 10.0.1.0/24 [110/0] via 10.0.2.2, eth0, 00:04:15 > O 10.0.2.0/24 [110/10] is directly connected, eth0, 00:04:16 > C>* 10.0.2.0/24 is directly connected, eth0 > O 10.0.3.0/24 [110/10] is directly connected, eth1, 00:05:02 > C>* 10.0.3.0/24 is directly connected, eth1 > O>* 10.0.6.0/24 [110/20] via 10.0.3.2, eth1, 00:04:12 > O>* 10.0.7.0/24 [110/0] via 10.0.3.2, eth1, 00:04:11 > O>* 10.0.8.0/24 [110/1] via 10.0.3.2, eth1, 00:04:11 > C>* 127.0.0.0/8 is directly connected, lo > n4# > > n5 output: > ======= > n5# sho ip ro > Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, > I - ISIS, B - BGP, > - selected route, * - FIB route > > O>* 10.0.0.0/24 [110/1] via 10.0.3.1, eth0, 00:04:20 > O>* 10.0.1.0/24 [110/0] via 10.0.3.1, eth0, 00:04:30 > O>* 10.0.2.0/24 [110/20] via 10.0.3.1, eth0, 00:04:31 > O 10.0.3.0/24 [110/10] is directly connected, eth0, 00:05:31 > C>* 10.0.3.0/24 is directly connected, eth0 > O 10.0.6.0/24 [110/10] is directly connected, eth1, 00:05:31 > C>* 10.0.6.0/24 is directly connected, eth1 > O>* 10.0.7.0/24 [110/0] via 10.0.6.1, eth1, 00:04:44 > O>* 10.0.8.0/24 [110/1] via 10.0.6.1, eth1, 00:04:44 > C>* 127.0.0.0/8 is directly connected, lo > n5# > > > Phil > > On Fri, Jul 20, 2012 at 5:27 AM, Igor Maravi? wrote: > >> I really didn't have time to boot up your configuration with Quagga. >> Could you apply patch that I've attached in email to n3 i n8 machines. >> After you do that, turn on the network and send me in email what do you >> see when you enter >> >> show route table ipv4 unicast final >> >> in xorpsh on n3 and n8. I'm interested in TAG field, which I added via >> patch that I've attached. >> BR >> Igor >> >> >> 2012/7/17 Phil Wiggins >> >>> Igor, >>> >>> Thanks for looking into this issue. I've also attached a CORE4.3 imn >>> file, if that helps. Once the network converges, the subnet at >>> 10.0.6.0/24 isn't visible to nodes n1 and n2. Similarly, the subnet at >>> 10.0.2.0/24 isn't visible to nodes n9 and n10. >>> >>> Here are the config.boots for n3 and n8, slightly cleaned up from the >>> previous post: >>> >>> n3:config.boot >>> ============== >>> interfaces { >>> interface eth0 { >>> vif eth0 { >>> address 10.0.1.2 { >>> prefix-length: 24 >>> } >>> } >>> } >>> interface eth1 { >>> vif eth1 { >>> address 10.0.2.2 { >>> prefix-length: 24 >>> } >>> } >>> } >>> } >>> >>> fea { >>> unicast-forwarding4 { >>> disable:false >>> } >>> } >>> >>> protocols { >>> rip { >>> export: "connected-to-rip,ospf4-to-rip" >>> interface eth0 { >>> vif eth0 { >>> address 10.0.1.2 { >>> disable: false >>> } >>> } >>> } >>> } >>> ospf4 { >>> export: "connected-to-ospf4,rip-to-ospf4" >>> router-id: 10.0.2.2 >>> area 0.0.0.0 { >>> interface eth1 { >>> vif eth1 { >>> address 10.0.2.2 { >>> } >>> } >>> } >>> } >>> } >>> } >>> >>> policy { >>> policy-statement connected-to-rip { >>> term 100 { >>> from { >>> protocol: "connected" >>> } >>> then { >>> metric: 1 >>> accept >>> } >>> } >>> } >>> policy-statement connected-to-ospf4 { >>> term 200 { >>> from { >>> protocol: "connected" >>> } >>> then { >>> accept >>> } >>> } >>> } >>> policy-statement rip-to-ospf4 { >>> term 300 { >>> from { >>> protocol: "rip" >>> } >>> then { >>> metric add 0 >>> accept >>> } >>> } >>> } >>> policy-statement ospf4-to-rip { >>> term 400 { >>> from { >>> protocol: "ospf4" >>> } >>> then { >>> metric add 0 >>> accept >>> } >>> } >>> } >>> } >>> n8:config.boot >>> ============== >>> interfaces { >>> interface eth0 { >>> vif eth0 { >>> address 10.0.6.1 { >>> prefix-length: 24 >>> } >>> } >>> } >>> interface eth1 { >>> vif eth1 { >>> address 10.0.7.1 { >>> prefix-length: 24 >>> } >>> } >>> } >>> } >>> >>> fea { >>> unicast-forwarding4 { >>> disable:false >>> } >>> } >>> >>> protocols { >>> ospf4 { >>> export: "connected-to-ospf4,rip-to-ospf4" >>> router-id: 10.0.6.1 >>> area 0.0.0.0 { >>> interface eth0 { >>> vif eth0 { >>> address 10.0.6.1 { >>> disable: false >>> } >>> } >>> } >>> } >>> } >>> rip { >>> export: "connected-to-rip,ospf4-to-rip" >>> interface eth1 { >>> vif eth1 { >>> address 10.0.7.1 { >>> disable: false >>> } >>> } >>> } >>> } >>> } >>> >>> policy { >>> policy-statement connected-to-rip { >>> term 100 { >>> from { >>> protocol: "connected" >>> } >>> then { >>> metric: 1 >>> accept >>> } >>> } >>> } >>> policy-statement connected-to-ospf4 { >>> term 200 { >>> from { >>> protocol: "connected" >>> } >>> then { >>> accept >>> } >>> } >>> } >>> policy-statement rip-to-ospf4 { >>> term 300 { >>> from { >>> protocol: "rip" >>> } >>> then { >>> metric add 0 >>> accept >>> } >>> } >>> } >>> policy-statement ospf4-to-rip { >>> term 400 { >>> from { >>> protocol: "ospf4" >>> } >>> then { >>> metric add 0 >>> accept >>> } >>> } >>> } >>> } >>> >>> Phil >>> >>> >>> On Tue, Jul 17, 2012 at 6:39 PM, Igor Maravi? wrote: >>> >>>> Phil, >>>> Could You send whole configuration file for n3 and n8. If I understood >>>> correctly, problem is that connected route 10.0.2.0/24 and 10.0.6.0/24aren't redistributed in RIP. >>>> I'll try it to look at the problem as soon as I find some time. >>>> BR >>>> Igor >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120720/62b324a4/attachment-0001.html From phil.wiggins at gmail.com Fri Jul 20 09:06:50 2012 From: phil.wiggins at gmail.com (Phil Wiggins) Date: Fri, 20 Jul 2012 13:06:50 -0300 Subject: [Xorp-users] Fwd: Route redistribution issue In-Reply-To: References: Message-ID: n2 output ========= root at n2> show route table ipv4 unicast final 10.0.0.0/24 [connected(0)/0] > via eth0/eth0 TAGS 0 10.0.1.0/24 [connected(0)/0] > via eth1/eth1 TAGS 0 10.0.2.0/24 [rip(120)/2] > to 10.0.1.2 via eth1/eth1 TAGS 10.0.3.0/24 [rip(120)/12] > to 10.0.1.2 via eth1/eth1 TAGS 10.0.7.0/24 [rip(120)/2] > to 10.0.1.2 via eth1/eth1 TAGS 10.0.8.0/24 [rip(120)/2] > to 10.0.1.2 via eth1/eth1 TAGS root at n2> n9 output ========= root at n9> show route table ipv4 unicast final 10.0.0.0/24 [rip(120)/2] > to 10.0.7.1 via eth0/eth0 TAGS 10.0.1.0/24 [rip(120)/2] > to 10.0.7.1 via eth0/eth0 TAGS 10.0.3.0/24 [rip(120)/12] > to 10.0.7.1 via eth0/eth0 TAGS 10.0.6.0/24 [rip(120)/2] > to 10.0.7.1 via eth0/eth0 TAGS 10.0.7.0/24 [connected(0)/0] > via eth0/eth0 TAGS 0 10.0.8.0/24 [connected(0)/0] > via eth1/eth1 TAGS 0 root at n9> Phil On Fri, Jul 20, 2012 at 11:36 AM, Igor Maravi? wrote: > Well, > This is just as it should be. > You're exporting connected routes to rip and ospf, thus they have two tags > (0 and 2). > You're exporting ospf routes to rip, thus they have only one tag (1). > As you can see 10.0.6.0/24 (and 10.0.2.0/24) has the same tag as other > OSPF routes. > Because of that it should be redistributed the same way as other OSPF > routes. > > It looks like RIP BUG to me. > > Could you send me routes that you see on n2 and n9. > BR > Igor > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120720/eccd40e7/attachment.html From phil.wiggins at gmail.com Fri Jul 20 08:57:22 2012 From: phil.wiggins at gmail.com (Phil Wiggins) Date: Fri, 20 Jul 2012 12:57:22 -0300 Subject: [Xorp-users] Fwd: Route redistribution issue In-Reply-To: References: Message-ID: n2 output ========= root at n2> show route table ipv4 unicast final 10.0.0.0/24 [connected(0)/0] > via eth0/eth0 TAGS 0 10.0.1.0/24 [connected(0)/0] > via eth1/eth1 TAGS 0 10.0.2.0/24 [rip(120)/2] > to 10.0.1.2 via eth1/eth1 TAGS 10.0.3.0/24 [rip(120)/12] > to 10.0.1.2 via eth1/eth1 TAGS 10.0.7.0/24 [rip(120)/2] > to 10.0.1.2 via eth1/eth1 TAGS 10.0.8.0/24 [rip(120)/2] > to 10.0.1.2 via eth1/eth1 TAGS root at n2> n9 output ========= root at n9> show route table ipv4 unicast final 10.0.0.0/24 [rip(120)/2] > to 10.0.7.1 via eth0/eth0 TAGS 10.0.1.0/24 [rip(120)/2] > to 10.0.7.1 via eth0/eth0 TAGS 10.0.3.0/24 [rip(120)/12] > to 10.0.7.1 via eth0/eth0 TAGS 10.0.6.0/24 [rip(120)/2] > to 10.0.7.1 via eth0/eth0 TAGS 10.0.7.0/24 [connected(0)/0] > via eth0/eth0 TAGS 0 10.0.8.0/24 [connected(0)/0] > via eth1/eth1 TAGS 0 root at n9> Phil On Fri, Jul 20, 2012 at 11:36 AM, Igor Maravi? wrote: > Well, > This is just as it should be. > You're exporting connected routes to rip and ospf, thus they have two tags > (0 and 2). > You're exporting ospf routes to rip, thus they have only one tag (1). > As you can see 10.0.6.0/24 (and 10.0.2.0/24) has the same tag as other > OSPF routes. > Because of that it should be redistributed the same way as other OSPF > routes. > > It looks like RIP BUG to me. > > Could you send me routes that you see on n2 and n9. > BR > Igor > > > 2012/7/20 Phil Wiggins > >> Igor, >> >> Thanks for your persistence. I've enclosed the outputs as needed. I've >> also provided similar metric info from Quagga (n4, n5). >> >> n3 output: >> ======== >> root at n3:/tmp/pycore.55456/n3.conf# xorpsh >> Welcome to XORP v1.8.6-WIP on n3 >> Version tag: 00000000 Build Date: 2012-07-20 09:44 32-bit >> root at n3> show route table ipv4 unicast final >> 10.0.0.0/24 [rip(120)/1] >> > to 10.0.1.1 via eth0/eth0 TAGS 3 >> 10.0.1.0/24 [connected(0)/0] >> > via eth0/eth0 TAGS 0, 2 >> 10.0.2.0/24 [connected(0)/0] >> > via eth1/eth1 TAGS 0, 2 >> 10.0.3.0/24 [ospf(110)/11] >> > to 10.0.2.1 via eth1/eth1 TAGS 1 >> 10.0.6.0/24 [ospf(110)/21] >> > to 10.0.2.1 via eth1/eth1 TAGS 1 >> 10.0.7.0/24 [ospf(110)/1] >> > to 10.0.2.1 via eth1/eth1 TAGS 1 >> 10.0.8.0/24 [ospf(110)/1] >> > to 10.0.2.1 via eth1/eth1 TAGS 1 >> root at n3> >> >> n8 output: >> ======= >> root at n8:/tmp/pycore.55456/n8.conf# xorpsh >> Welcome to XORP v1.8.6-WIP on n8 >> Version tag: 00000000 Build Date: 2012-07-20 09:44 32-bit >> root at n8> show route table ipv4 unicast final >> 10.0.0.0/24 [ospf(110)/1] >> > to 10.0.6.2 via eth0/eth0 TAGS 1 >> 10.0.1.0/24 [ospf(110)/1] >> > to 10.0.6.2 via eth0/eth0 TAGS 1 >> 10.0.2.0/24 [ospf(110)/21] >> > to 10.0.6.2 via eth0/eth0 TAGS 1 >> 10.0.3.0/24 [ospf(110)/11] >> > to 10.0.6.2 via eth0/eth0 TAGS 1 >> 10.0.6.0/24 [connected(0)/0] >> > via eth0/eth0 TAGS 0, 2 >> 10.0.7.0/24 [connected(0)/0] >> > via eth1/eth1 TAGS 0, 2 >> 10.0.8.0/24 [rip(120)/1] >> > to 10.0.7.2 via eth1/eth1 TAGS 3 >> root at n8> >> >> n4 output: >> ======= >> n4# sho ip ro >> Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, >> I - ISIS, B - BGP, > - selected route, * - FIB route >> >> O>* 10.0.0.0/24 [110/1] via 10.0.2.2, eth0, 00:04:01 >> O>* 10.0.1.0/24 [110/0] via 10.0.2.2, eth0, 00:04:15 >> O 10.0.2.0/24 [110/10] is directly connected, eth0, 00:04:16 >> C>* 10.0.2.0/24 is directly connected, eth0 >> O 10.0.3.0/24 [110/10] is directly connected, eth1, 00:05:02 >> C>* 10.0.3.0/24 is directly connected, eth1 >> O>* 10.0.6.0/24 [110/20] via 10.0.3.2, eth1, 00:04:12 >> O>* 10.0.7.0/24 [110/0] via 10.0.3.2, eth1, 00:04:11 >> O>* 10.0.8.0/24 [110/1] via 10.0.3.2, eth1, 00:04:11 >> C>* 127.0.0.0/8 is directly connected, lo >> n4# >> >> n5 output: >> ======= >> n5# sho ip ro >> Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, >> I - ISIS, B - BGP, > - selected route, * - FIB route >> >> O>* 10.0.0.0/24 [110/1] via 10.0.3.1, eth0, 00:04:20 >> O>* 10.0.1.0/24 [110/0] via 10.0.3.1, eth0, 00:04:30 >> O>* 10.0.2.0/24 [110/20] via 10.0.3.1, eth0, 00:04:31 >> O 10.0.3.0/24 [110/10] is directly connected, eth0, 00:05:31 >> C>* 10.0.3.0/24 is directly connected, eth0 >> O 10.0.6.0/24 [110/10] is directly connected, eth1, 00:05:31 >> C>* 10.0.6.0/24 is directly connected, eth1 >> O>* 10.0.7.0/24 [110/0] via 10.0.6.1, eth1, 00:04:44 >> O>* 10.0.8.0/24 [110/1] via 10.0.6.1, eth1, 00:04:44 >> C>* 127.0.0.0/8 is directly connected, lo >> n5# >> >> >> Phil >> >> On Fri, Jul 20, 2012 at 5:27 AM, Igor Maravi? wrote: >> >>> I really didn't have time to boot up your configuration with Quagga. >>> Could you apply patch that I've attached in email to n3 i n8 machines. >>> After you do that, turn on the network and send me in email what do you >>> see when you enter >>> >>> show route table ipv4 unicast final >>> >>> in xorpsh on n3 and n8. I'm interested in TAG field, which I added via >>> patch that I've attached. >>> BR >>> Igor >>> >>> >>> 2012/7/17 Phil Wiggins >>> >>>> Igor, >>>> >>>> Thanks for looking into this issue. I've also attached a CORE4.3 imn >>>> file, if that helps. Once the network converges, the subnet at >>>> 10.0.6.0/24 isn't visible to nodes n1 and n2. Similarly, the subnet >>>> at 10.0.2.0/24 isn't visible to nodes n9 and n10. >>>> >>>> Here are the config.boots for n3 and n8, slightly cleaned up from the >>>> previous post: >>>> >>>> n3:config.boot >>>> ============== >>>> interfaces { >>>> interface eth0 { >>>> vif eth0 { >>>> address 10.0.1.2 { >>>> prefix-length: 24 >>>> } >>>> } >>>> } >>>> interface eth1 { >>>> vif eth1 { >>>> address 10.0.2.2 { >>>> prefix-length: 24 >>>> } >>>> } >>>> } >>>> } >>>> >>>> fea { >>>> unicast-forwarding4 { >>>> disable:false >>>> } >>>> } >>>> >>>> protocols { >>>> rip { >>>> export: "connected-to-rip,ospf4-to-rip" >>>> interface eth0 { >>>> vif eth0 { >>>> address 10.0.1.2 { >>>> disable: false >>>> } >>>> } >>>> } >>>> } >>>> ospf4 { >>>> export: "connected-to-ospf4,rip-to-ospf4" >>>> router-id: 10.0.2.2 >>>> area 0.0.0.0 { >>>> interface eth1 { >>>> vif eth1 { >>>> address 10.0.2.2 { >>>> } >>>> } >>>> } >>>> } >>>> } >>>> } >>>> >>>> policy { >>>> policy-statement connected-to-rip { >>>> term 100 { >>>> from { >>>> protocol: "connected" >>>> } >>>> then { >>>> metric: 1 >>>> accept >>>> } >>>> } >>>> } >>>> policy-statement connected-to-ospf4 { >>>> term 200 { >>>> from { >>>> protocol: "connected" >>>> } >>>> then { >>>> accept >>>> } >>>> } >>>> } >>>> policy-statement rip-to-ospf4 { >>>> term 300 { >>>> from { >>>> protocol: "rip" >>>> } >>>> then { >>>> metric add 0 >>>> accept >>>> } >>>> } >>>> } >>>> policy-statement ospf4-to-rip { >>>> term 400 { >>>> from { >>>> protocol: "ospf4" >>>> } >>>> then { >>>> metric add 0 >>>> accept >>>> } >>>> } >>>> } >>>> } >>>> n8:config.boot >>>> ============== >>>> interfaces { >>>> interface eth0 { >>>> vif eth0 { >>>> address 10.0.6.1 { >>>> prefix-length: 24 >>>> } >>>> } >>>> } >>>> interface eth1 { >>>> vif eth1 { >>>> address 10.0.7.1 { >>>> prefix-length: 24 >>>> } >>>> } >>>> } >>>> } >>>> >>>> fea { >>>> unicast-forwarding4 { >>>> disable:false >>>> } >>>> } >>>> >>>> protocols { >>>> ospf4 { >>>> export: "connected-to-ospf4,rip-to-ospf4" >>>> router-id: 10.0.6.1 >>>> area 0.0.0.0 { >>>> interface eth0 { >>>> vif eth0 { >>>> address 10.0.6.1 { >>>> disable: false >>>> } >>>> } >>>> } >>>> } >>>> } >>>> rip { >>>> export: "connected-to-rip,ospf4-to-rip" >>>> interface eth1 { >>>> vif eth1 { >>>> address 10.0.7.1 { >>>> disable: false >>>> } >>>> } >>>> } >>>> } >>>> } >>>> >>>> policy { >>>> policy-statement connected-to-rip { >>>> term 100 { >>>> from { >>>> protocol: "connected" >>>> } >>>> then { >>>> metric: 1 >>>> accept >>>> } >>>> } >>>> } >>>> policy-statement connected-to-ospf4 { >>>> term 200 { >>>> from { >>>> protocol: "connected" >>>> } >>>> then { >>>> accept >>>> } >>>> } >>>> } >>>> policy-statement rip-to-ospf4 { >>>> term 300 { >>>> from { >>>> protocol: "rip" >>>> } >>>> then { >>>> metric add 0 >>>> accept >>>> } >>>> } >>>> } >>>> policy-statement ospf4-to-rip { >>>> term 400 { >>>> from { >>>> protocol: "ospf4" >>>> } >>>> then { >>>> metric add 0 >>>> accept >>>> } >>>> } >>>> } >>>> } >>>> >>>> Phil >>>> >>>> >>>> On Tue, Jul 17, 2012 at 6:39 PM, Igor Maravi? wrote: >>>> >>>>> Phil, >>>>> Could You send whole configuration file for n3 and n8. If I understood >>>>> correctly, problem is that connected route 10.0.2.0/24 and 10.0.6.0/24aren't redistributed in RIP. >>>>> I'll try it to look at the problem as soon as I find some time. >>>>> BR >>>>> Igor >>>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120720/65877664/attachment-0001.html From phil.wiggins at gmail.com Sat Jul 21 09:23:31 2012 From: phil.wiggins at gmail.com (Phil Wiggins) Date: Sat, 21 Jul 2012 13:23:31 -0300 Subject: [Xorp-users] Fwd: Route redistribution issue In-Reply-To: References: Message-ID: Igor, The tag issue seems significant for a generalized fix. One of our team members has a workaround using an import policy for ospf4: ... protocols { rip { export: "connected-to-rip,ospf4-to-rip" ... } ospf4 { export: "connected-to-ospf4,rip-to-ospf4" import: "convert-metric" router-id: 10.0.2.2 area 0.0.0.0 { interface eth0 { vif eth0 { address 10.0.2.2 { interface-cost: 1 } } } } } } policy { policy-statement connected-to-rip { ... } policy-statement connected-to-ospf4 { ... } policy-statement rip-to-ospf4 { ... } policy-statement ospf4-to-rip { ... } policy-statement convert-metric { term 100 { from { metric > 13 } then { metric sub 9 accept } } } } Phil On Fri, Jul 20, 2012 at 12:57 PM, Phil Wiggins wrote: > n2 output > ========= > root at n2> show route table ipv4 unicast final > 10.0.0.0/24 [connected(0)/0] > > via eth0/eth0 TAGS 0 > 10.0.1.0/24 [connected(0)/0] > > via eth1/eth1 TAGS 0 > 10.0.2.0/24 [rip(120)/2] > > to 10.0.1.2 via eth1/eth1 TAGS > 10.0.3.0/24 [rip(120)/12] > > to 10.0.1.2 via eth1/eth1 TAGS > 10.0.7.0/24 [rip(120)/2] > > to 10.0.1.2 via eth1/eth1 TAGS > 10.0.8.0/24 [rip(120)/2] > > to 10.0.1.2 via eth1/eth1 TAGS > root at n2> > /snip/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120721/21818d7c/attachment.html From igorm at etf.rs Mon Jul 23 01:51:39 2012 From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=) Date: Mon, 23 Jul 2012 10:51:39 +0200 Subject: [Xorp-users] Fwd: Route redistribution issue In-Reply-To: References: Message-ID: Good catch :) Well if the redistribution was bad, TAGS would be bad. Because they aren't redistribution is good. You're problem is that you've hit RIP_INFINITY. RIP_INFINITY is set to 16. So, routes that have metric larger then 16, won't even enter the RIP code. I have to say that this isn't a redistribution BUG. You're solution with import policy seems logical, but you should refine it a little. BR Igor ---8<--- > The tag issue seems significant for a generalized fix. One of our team > members has a workaround using an import policy for ospf4: > ... > > --->8--- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120723/d40b5d8b/attachment.html From phil.wiggins at gmail.com Mon Jul 23 04:05:13 2012 From: phil.wiggins at gmail.com (Phil Wiggins) Date: Mon, 23 Jul 2012 08:05:13 -0300 Subject: [Xorp-users] Fwd: Route redistribution issue In-Reply-To: References: Message-ID: The problem of redistributing 32-bit metric space to 16-bit metric space and vice versa still remains. The policy tools (add, sub) are fairly crude and error prone for this purpose. As the network scales and goes through other redistributions, then this simple case becomes more complex. Suggestion #1 - Wouldn't it make more sense to have a native 'redistribute' command built into xorp that takes a number of policies with well-chosen defaults and wraps behind a single command? Quagga has a simple redistribute that can be applied to rip and ospf. Suggestion #2 - Further, for redistributing 16/32-bit metrics a "bit shift" function would be helpful for the policy tools to use. Phil On Mon, Jul 23, 2012 at 5:51 AM, Igor Maravi? wrote: > Good catch :) > Well if the redistribution was bad, TAGS would be bad. Because they aren't > redistribution is good. > > You're problem is that you've hit RIP_INFINITY. RIP_INFINITY is set to 16. > So, routes that have metric larger then 16, won't even enter the RIP code. > I have to say that this isn't a redistribution BUG. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120723/3edc88ee/attachment.html From igorm at etf.rs Mon Jul 23 04:47:07 2012 From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=) Date: Mon, 23 Jul 2012 13:47:07 +0200 Subject: [Xorp-users] Fwd: Route redistribution issue In-Reply-To: References: Message-ID: Response is inline 2012/7/23 Phil Wiggins : > The problem of redistributing 32-bit metric space to 16-bit metric space and > vice versa still remains. The policy tools (add, sub) are fairly crude and > error prone for this purpose. As the network scales and goes through other > redistributions, then this simple case becomes more complex. > > Suggestion #1 - Wouldn't it make more sense to have a native 'redistribute' > command built into xorp that takes a number of policies with well-chosen > defaults and wraps behind a single command? Quagga has a simple > redistribute that can be applied to rip and ospf. I totally agree. > > Suggestion #2 - Further, for redistributing 16/32-bit metrics a "bit shift" > function would be helpful for the policy tools to use. > This shouldn't be much of problem to implement. Could you explain your idea in little more detail. If I understood correctly in this case you would shift OSPF metric by 1, or 2, bits and you would got metric that can be used by RIP? (11 >> 1 == 5, 21 >> 1 == 10) BR Igor From phil.wiggins at gmail.com Tue Jul 24 20:55:04 2012 From: phil.wiggins at gmail.com (Phil Wiggins) Date: Wed, 25 Jul 2012 00:55:04 -0300 Subject: [Xorp-users] Fwd: Route redistribution issue In-Reply-To: References: Message-ID: On Mon, Jul 23, 2012 at 8:47 AM, Igor Maravi? wrote:> > > > Suggestion #2 - Further, for redistributing 16/32-bit metrics a "bit > shift" > > function would be helpful for the policy tools to use. > > > > This shouldn't be much of problem to implement. > Could you explain your idea in little more detail. > If I understood correctly in this case you would shift OSPF metric by > 1, or 2, bits > and you would got metric that can be used by RIP? > > (11 >> 1 == 5, > 21 >> 1 == 10) > To work with the metrics for route redistribution between separate metric spaces, it would be useful to have multiply (mult) and divide (div) functions. Slightly more flexible would be a combination of conversion tools to do something like ax+b where a is a multiply factor for metric space conversion, x is the source metric, and b is some addition. Bit shift would be shift left (shiftl) and shift right (shiftr) which could provide some potential savings for embedded environments. The examples that you provide are exactly what was intended. An example for conversion between RIP and OSPF space, RIP to OSPF Conversion could be a simple multiply by 4096. ** RIP Metric**** OSPF Cost**** *0* *0* *1* *4096* *2* *8192* *3* *12288* *4* *16384* *5* *20480* *6* *24576* *7* *28762* *8* *32768* *9* *36864* *10* *40960* *11* *45056* *12* *49152* *13* *53248* *14* *57344* *15* *61440* *16* *65536* OSPF to RIP Conversion could be a divide by 4096 possibly with a modulo or roundup/rounddown**** ****OSPF** **Cost **Range******** RIP Metric**** *0* *0* *1 ? 4096* *1* *4097 ? 8192* *2* *8193 ? 12288* *3* *12289 ? 16384* *4* *16385 ? 20480* *5* *20481 ? 24576* *6* *24577 ? 28762* *7* *28763 ? 32768* *8* *32769 ? 36864* *9* *36865 ? 40960* *10* *40961 ? 45056* *11* *45057 ? 49152* *12* *49153 ? 53248* *13* *53249 ? 57344* *14* *57345 ? 61440* *15* *61441 and up* *16* * * -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20120725/f1b9e2d4/attachment-0001.html From steve at sze.hu Wed Jul 25 14:09:32 2012 From: steve at sze.hu (=?ISO-8859-2?Q?Derka_Istv=E1n?=) Date: Wed, 25 Jul 2012 23:09:32 +0200 Subject: [Xorp-users] RP shutdown Message-ID: <5010608C.9080309@sze.hu> Hi, I've installed and configured a 4-by-4 mesh network from Xorp 1.8.4 routers using Ubuntu 10.04 operating system on virtual machines in VmWare ESxi environment. I configured the PIM-SM4 multicast routing on all routers and some routers was set as Candidate-RP and Candidate-BSR. The streaming through the mesh network is in good working. In my research I measure the RP change time (from the highest prioriyrity RP to second highest's priority RP) when the stream flow through the RP to the receiver. For this simulated RP's mailfunction I delete Cand-RP and Cand-BSR settings from RP's config online (with help of xorpsh) and capture all the packets on the receiver's side with tcpdump. When the measuring program (a bash script) terminated normally I run an other bash script to process the captured packets. My problem with the XORP PIM-SM4 routing when I delete the mentioned above configuration parameters from the RP's config the Xorp doesn't send any Candidate-RP Advertisement (with holdtime=0 setting) to the BSR (RFC5059). So, the BSR will delete only the stopped RP from the BSM RP list when its holdtime timer reaches the zero. Therefore, changing from the first (highest priority) RP to the second is much longer than normally. My question is how can I shutdown the actually operating RP in normal way when the Xorp send a Candidate-RP Adv. message (with holdtime=0 setting) to the BSR? Thanks, Istvan Derka From igorm at etf.rs Mon Jul 30 04:22:03 2012 From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=) Date: Mon, 30 Jul 2012 13:22:03 +0200 Subject: [Xorp-users] XORP Presentation - need HELP Message-ID: Dear Xorp users/developers, I volunteered to help Martin Winter, from OpenSourceRouting, to prepare Xorp slides for RIPE/APNIC conferences. As a part of the presentation we should put who is using Xorp and how. Currently I don't know much about that and I REALLY NEED YOUR HELP! If you are using Xorp, please tell me for which company/customers are you working and how are you using Xorp! I think it's really essential to tell me this stuff, so we could show the world that Xorp is alive. Since RIPE is gathering a large number of operators, we can attract them to use Xorp in future. Martin would put names of your company and/or customers on his slides, which would be a good advertisement for you and them! Please don't be shy! XORP DEPENDS ON YOU! BR Igor From igorm at etf.rs Mon Jul 30 04:25:24 2012 From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=) Date: Mon, 30 Jul 2012 13:25:24 +0200 Subject: [Xorp-users] XORP Presentation - need HELP Message-ID: Dear Xorp users/developers, I volunteered to help Martin Winter, from OpenSourceRouting, to prepare Xorp slides for RIPE/APNIC conferences. As a part of the presentation we should put who is using Xorp and how. Currently I don't know much about that and I REALLY NEED YOUR HELP! If you are using Xorp, please tell me for which company/customers are you working and how are you using Xorp! I think it's really essential to tell me this stuff, so we could show the world that Xorp is alive. Since RIPE is gathering a large number of operators, we can attract them to use Xorp in future. Martin would put names of your company and/or customers on his slides, which would be a good advertisement for you and them! Please don't be shy! XORP DEPENDS ON YOU! BR Igor From greearb at candelatech.com Mon Jul 30 09:03:23 2012 From: greearb at candelatech.com (Ben Greear) Date: Mon, 30 Jul 2012 09:03:23 -0700 Subject: [Xorp-users] XORP Presentation - need HELP In-Reply-To: References: Message-ID: <5016B04B.1010701@candelatech.com> On 07/30/2012 04:25 AM, Igor Maravi? wrote: > Dear Xorp users/developers, > I volunteered to help Martin Winter, from OpenSourceRouting, to > prepare Xorp slides for RIPE/APNIC conferences. > > As a part of the presentation we should put who is using Xorp and how. > Currently I don't know much about that and I REALLY NEED YOUR HELP! > > If you are using Xorp, please tell me for which company/customers are > you working and how are you using Xorp! > > I think it's really essential to tell me this stuff, so we could show > the world that Xorp is alive. Since RIPE is gathering a large number > of operators, we can attract them to use Xorp in future. Martin would > put names of your company and/or customers on his slides, which would > be a good advertisement for you and them! > > Please don't be shy! XORP DEPENDS ON YOU! We use it for our virtual-router feature in our LANforge product (network emulator, network traffic generator products). http://www.candelatech.com/ice_ex9_vrouters.php In particular, xorp is the routing brains behind the WISER product: http://www.candelatech.com/wiser50_product.php I do a bit of consulting related to xorp as well. One customer is using Xorp on windows and Linux to implement a multiple data-center redundancy. Another is using it for something that may be similar to our WISER product...I'll ask them to post some details if they are willing. How are you using Xorp? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From igorm at etf.rs Tue Jul 31 01:15:53 2012 From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=) Date: Tue, 31 Jul 2012 10:15:53 +0200 Subject: [Xorp-users] XORP Presentation - need HELP In-Reply-To: References: <5016B04B.1010701@candelatech.com> Message-ID: Thank you Achmad and Ben! :) We're research group of School of Electrical Engineering of Belgrade University, Serbia. As a part of our research we're building internet router. Our data plane is almost finished, and we needed solution for our control plane. This is where Xorp fits in. :) We still didn't put it on our board, so currently we're just improving it and we're developing MPLS part. Of course, we're going to push our code back to the Xorp, as soon as it becomes operational. Is there anybody else who is using Xorp? BR Igor From peirce at maine.edu Tue Jul 31 07:09:07 2012 From: peirce at maine.edu (Garry Peirce) Date: Tue, 31 Jul 2012 10:09:07 -0400 Subject: [Xorp-users] XORP Presentation - need HELP In-Reply-To: References: <5016B04B.1010701@candelatech.com> Message-ID: <047d01cd6f26$0c98e700$25cab500$@maine.edu> Igor, We in Maine (US) have been using XORP (1.6 moving to CT) within a developed CPE appliance for our K12 environment (~100 in production) for about 3 years now. The device allows us to cost effectively enable more services at the edge , aggregate school district connectivity, and allow a level of local admin control/visibility. We use it for v4 unicast/mcast, and make use of both RIP and OSPF. Some info here: http://www.networkmaine.net/msln/joebox/ This is actually a 'Maine' version of a device derived through a partnership we have with an organization called 'mecnet' - http://www.mecnet.net. > -----Original Message----- > From: xorp-users-bounces at xorp.org [mailto:xorp-users-bounces at xorp.org] > On Behalf Of Igor Maravic > Sent: Tuesday, July 31, 2012 4:16 AM > To: Achmad Basuki > Cc: xorp-hackers at icir.org; xorp-users at icir.org > Subject: Re: [Xorp-users] XORP Presentation - need HELP > > Thank you Achmad and Ben! :) > > We're research group of School of Electrical Engineering of Belgrade > University, Serbia. > As a part of our research we're building internet router. Our data plane is > almost finished, and we needed solution for our control plane. > > This is where Xorp fits in. :) > > We still didn't put it on our board, so currently we're just improving it and > we're developing MPLS part. > Of course, we're going to push our code back to the Xorp, as soon as it > becomes operational. > > Is there anybody else who is using Xorp? > > BR > Igor > > _______________________________________________ > Xorp-users mailing list > Xorp-users at xorp.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users