[Xorp-users] Multicast traffic is not forwarded in a specific deployment as mentioned in the mail

Ganesh Reddy K ganeshreddyk at gmail.com
Fri Jul 13 00:08:26 PDT 2012


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&#246;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
>
>



More information about the Xorp-users mailing list