[Xorp-users] Multicast traffic is not forwarded in a specific deployment as mentioned in the mail
kesava Srinivas
keshavsrinu at gmail.com
Fri Jul 13 00:45:47 PDT 2012
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 <ganeshreddyk at gmail.com>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
> <B38514 at freescale.com> 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ć <igorm at etf.rs> 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 <ganeshreddyk at gmail.com>:
> >>> 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ć <igorm at etf.rs> 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ć <igorm at etf.rs>:
> >>>>> 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 <B38514 at freescale.com>:
> >>>>>> 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 <ganeshreddyk at gmail.com>:
> >>>>>>> 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
More information about the Xorp-users
mailing list