[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ö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