[Xorp-users] Multicast traffic is not forwarded in a specific deployment as mentioned in the mail
Dan Rosenqvist
danro at kth.se
Fri Jul 6 10:00:35 PDT 2012
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