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

From: Ganesh Reddy K <[email-masked]>
Date: Mon, 16 Jul 2012 17:00:51 +0530

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@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@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 <[email-masked]> 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
> <[email-masked]> 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:[email-masked]]
>> Sent: Friday, July 06, 2012 10:31 PM
>> To: Ganesh Reddy K; [email-masked]; [email-masked]
>> Cc: Bv Rajesh-B35907; sridhar pothuganti; [email-masked]; 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: [email-masked] [[email-masked]] f&#246;r Ganesh Reddy K [[email-masked]]
>> Skickat: den 6 juli 2012 07:03
>> Till: [email-masked]; [email-masked]
>> Kopia: Bv Rajesh-B35907; sridhar pothuganti; [email-masked]; 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ć <[email-masked]> 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 <[email-masked]>:
>>>> 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ć <[email-masked]> 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ć <[email-masked]>:
>>>>>> 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 <[email-masked]>:
>>>>>>> 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:[email-masked]]
>>>>>>> Sent: Thursday, July 05, 2012 12:50 PM
>>>>>>> To: Ganesh Reddy K
>>>>>>> Cc: [email-masked]; Bv Rajesh-B35907;
>>>>>>> [email-masked]; 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 <[email-masked]>:
>>>>>>>> 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@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
>>>>>>>> [email-masked]
>>>>>>>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>>>>>>>
>>>>>>>
>>
>> _______________________________________________
>> Xorp-users mailing list
>> [email-masked]
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>>
>>