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

Ganesh Reddy K ganeshreddyk at gmail.com
Thu Jul 5 09:19:07 PDT 2012


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



More information about the Xorp-users mailing list