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

Igor Maravić igorm at etf.rs
Thu Jul 5 09:34:03 PDT 2012


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



More information about the Xorp-users mailing list