[Xorp-users] Multicast traffic is not forwarded in a specific deployment as mentioned in the mail
Ganesh Reddy K
ganeshreddyk at gmail.com
Mon Jul 16 04:30:51 PDT 2012
Hi,
I have tried adding alternate subnet configuration, Even now, the
traffic is not forwarded.
But this time, i saw that multicast route () is disappearing in kernel
when Listener is on.
Setup:------
H1 -------------- eth1 DEVICE eth0 -------------- H2
Sender listener.
Observation1)
Device status:--
tcpdump -ni eth1 device eth1 entered promiscuous mode
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode listening on eth1, link-type EN10MB (Ethernet), capture size 68
bytes
03:14:07.573648 IP 192.168.11.54.46442 > 226.0.6.130.5000: UDP, length: 36
03:14:08.573617 IP 192.168.11.54.46442 > 226.0.6.130.5000: UDP, length: 36
..
.
[root at P2020RDB igateway]# cat /proc/net/ip_mr_*
Group Origin Iif Pkts Bytes Wrong Oifs
Interface BytesIn PktsIn BytesOut PktsOut Flags Local Remote
0 eth0 0 0 0 0 00000 C0A80164 00000000
1 pimreg 0 0 0 0 00004 C0A80164 00000000
2 eth1 175296 2739 0 0 00000 C0A80264 00000000
..
.
[root at P2020RDB igateway]# cat /proc/net/ip_mr_cache
Group Origin Iif Pkts Bytes Wrong Oifs
E2000682 C0A80B36 2 3 192 0 (After Alternate
subnet configuration is done on eth1, this route is disappeared, when
Listener is runnig on eth0 side of Device)
After enabling DEBUG prints in source code, below messages looks to
be problematic.:-----
pim_mre_join_prune.c:--
"WARNING xorp_pimsm4 PIM JoinDesired (S,G) = false; upstream
neighbor for source 192.168.11.54 and group 226.0.6.130: not found"
Observation 2 ) I am going through xorp-notes RELEASE notes
http://fossies.org/unix/misc/xorp-1.8.5-src.tar.gz:a/xorp/pim/TODO
* PIM IMPL:
21 If the PIM-SM module doesn't know the RP address, then it shouldn't
22 include the register_vif in the MFC entry's outgoing interface set.
My comment/DOUBT In the above traffic scenario, does the above
statement confirms the xorp existing behavior .
Observation 3) While going through source pim_mrt.cc,
below function has the warning comment :-- saying order is important.
i.e, does the traffic in above scenario follows search/creation
order properly ?
(S,G)
(S,G,rpt)
(*,G)
(*,*,RP)
How exactly order differentiates ..given below the source ?
// XXX: @create_flags must be a subset of @lookup_flags
// XXX: if no creation allowed, the entry that it returns may be the
// next one in the map.
//
// XXX: if the entry to lookup and/or create is (*,*,RP), then:
// - If group is IPvX::ZERO(family()), then we lookup/create the
// entry by using 'source' which is the RP address
// - If group is NOT IPvX::ZERO(family()), then we lookup/create the
// entry by lookup first which is the RP for 'group'.
// - Regardless of the group address, the created (*,*,RP) entry
// always has a group address of IPvX::MULTICAST_BASE(family())
PimMre *
PimMrt::pim_mre_find(const IPvX& source, const IPvX& group,
uint32_t lookup_flags, uint32_t create_flags)
{
PimMre *pim_mre = NULL;
create_flags &= lookup_flags;
//
// Try to lookup if entry was installed already.
// XXX: the order is important, because we want the longest-match.
//
XLOG_INFO("%s(%d)-TEST: src = %s dst = %s, lookup_flags %X
create_flags %X\r\n",__FUNCTION__, __LINE__,
cstring(source), cstring(group),lookup_flags, create_flags);
do {
if (lookup_flags & PIM_MRE_SG) {
//
// (S,G) entry
//
pim_mre = _pim_mrt_sg.find(source, group);
if (pim_mre != NULL)
break;
}
if (lookup_flags & PIM_MRE_SG_RPT) {
//
// (S,G,rpt) entry
//
pim_mre = _pim_mrt_sg_rpt.find(source, group);
if (pim_mre != NULL)
break;
}
if (lookup_flags & PIM_MRE_WC) {
//
// (*,G) entry
//
pim_mre = _pim_mrt_g.find(IPvX::ZERO(family()), group);
if (pim_mre != NULL)
break;
}
if (lookup_flags & PIM_MRE_RP) {
//
// (*,*,RP) entry
//
if (group == IPvX::ZERO(family())) {
// XXX: the entry is specified by the RP address ('source')
pim_mre = _pim_mrt_rp.find(source,
IPvX::MULTICAST_BASE(family()));
if (pim_mre != NULL)
break;
} else {
// XXX: the entry is specified by the group address
PimRp *pim_rp = pim_node()->rp_table().rp_find(group);
if (pim_rp != NULL)
pim_mre = _pim_mrt_rp.find(pim_rp->rp_addr(),
IPvX::MULTICAST_BASE(family()));
}
if (pim_mre != NULL)
break;
}
} while (false);
if (pim_mre != NULL)
return (pim_mre);
//
// Lookup failed. Create the entry if creation is allowed.
//
// If creation allowed, create the entry, insert it and return it.
// XXX: the order is important, because we want the longest-match.
do {
if (create_flags & (PIM_MRE_SG)) {
//
// (S,G) entry
//
// Create and insert the entry
if (create_flags & PIM_MRE_SG_RPT) {
//
// (S,G,rpt) entry
//
// Create and insert the entry
...
..
}
if (create_flags & PIM_MRE_WC) {
//
// (*,G) entry
//
// Create and insert the entry
...
..
}
if (create_flags & PIM_MRE_RP) {
//
// (*,*,RP) entry
//
// Create and insert the entry
...
..
}
..
.
}
On Fri, Jul 13, 2012 at 12:38 PM, Ganesh Reddy K <ganeshreddyk at gmail.com> wrote:
> 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