From: Leigh Harrison (ccileigh@gmail.com)
Date: Sun Dec 04 2005 - 08:46:22 GMT-3
Hey Venkat,
This will work with tunnels - I assure you.
There must be a problem with either your tunnels or your static
mroutes. Make sure that you have put the static mroutes on both sides
of the link and do "sh ip mroute" to see if there are active.
Also, try using an "mtrace" to see where it's being sent to.
Honestly, it does work.
LH
Venkataramanaiah.R wrote:
>i am doing ip unnumbered lo0 on my tunnels, so i think it does not make any
>difference then..
>
>-V
>
>On 12/4/05, Godswill Oletu <oletu@inbox.lv> wrote:
>
>
>>Venkat,
>>
>>I meant mroute to R2/R3's tunnel interface (eg tunnel 0) not lo0, the lo0
>>might still be obeying the IGP path..
>>
>>----- Original Message -----
>>*From:* Venkataramanaiah.R <vramanaiah@gmail.com>
>>*To:* Godswill Oletu <oletu@inbox.lv>
>>*Cc:* Josef A <josefnet@gmail.com> ; Cisco
>>
>>
>certification<ccielab@groupstudy.com>
>
>
>>*Sent:* Sunday, December 04, 2005 5:18 AM
>>*Subject:* Re: Multicast question..
>>
>>Yes mroute points to R2 lo0.. if i add mroute for R2 serial via tunnel,
>>the sho ip rpf on R3 does not accept this change, as it considers R2 serial
>>as directly connected.
>>
>>Someone interested can recreate and test it.. May be i am overlooking
>>something in my lab..
>>
>>
>>-Venkat
>>
>>On 12/4/05, Godswill Oletu <oletu@inbox.lv> wrote:
>>
>>
>>>Even with a static mroute pointing to the tunnel interface as the next
>>>hop
>>>for R2?
>>>
>>>----- Original Message -----
>>>From: "Venkataramanaiah.R" <vramanaiah@gmail.com <vramanaiah@gmail.com+>
>>>
>>>
>>>To: "Josef A" <josefnet@gmail.com>
>>>Cc: "Cisco certification" <ccielab@groupstudy.com>
>>>Sent: Saturday, December 03, 2005 4:38 PM
>>>Subject: Re: Multicast question..
>>>
>>>
>>>
>>>
>>>>Hi Josef,
>>>>
>>>> I thought about using the tunnel, however when i tested it,
>>>>
>>>>
>>>the
>>>
>>>
>>>>multicast traffic does not seem to take the tunnel. It still flows
>>>>
>>>>
>>>through
>>>
>>>
>>>>the FR network natively and the situation does not change..
>>>>
>>>>-Venkat
>>>>
>>>>On 12/3/05, Josef A <josefnet@gmail.com> wrote:
>>>>
>>>>
>>>>>Thought of a tunnel between R2 and R3 ?
>>>>>
>>>>>Josef
>>>>>
>>>>>
>>>>>On 12/2/05, Venkataramanaiah.R < vramanaiah@gmail.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Hi,
>>>>>>
>>>>>> I have the following FR topology..
>>>>>>
>>>>>>
>>>>>> ______R2_____R4
>>>>>> /
>>>>>>R1--
>>>>>> \______R3_____R5 ( 239.5.5.5)
>>>>>>
>>>>>>
>>>>>> I have PIM Sparse mode running everywhere.. and of course with
>>>>>>
>>>>>>
>>>PIM
>>>
>>>
>>>>>>nbma
>>>>>>mode at R1.
>>>>>>
>>>>>> R2 is the RP and R1 is the MA. R5 has joined some group, Say
>>>>>>239.5.5.5 (Will call this Grp5 henceforth).
>>>>>>
>>>>>> There are two issues in this topology. Let me discuss them one
>>>>>>
>>>>>>
>>>by
>>>
>>>
>>>>>>one.
>>>>>>
>>>>>>1) When R5 sends PIM join to the RP (R2) via R3, the joins are
>>>>>>
>>>>>>
>>>sent
>>>
>>>
>>>>>>directed
>>>>>>to R2 from R3. This prevents the join to become successful. We can
>>>>>>
>>>>>>
>>>fix
>>>
>>>
>>>>>>this
>>>>>>by adding a static mroute at R3 for the RP pointing to R1. THis
>>>>>>
>>>>>>
>>>will
>>>let
>>>
>>>
>>>>>>the
>>>>>>shared tree to be built from the RP R2 via, R1-R3 and the receiver
>>>>>>
>>>>>>
>>>R5.
>>>
>>>
>>>>>>Hope
>>>>>>there are no other solutions for this problem.
>>>>>>
>>>>>>2) When we ping the Grp5 from R4, the packets would reach the
>>>>>>
>>>>>>
>>>receiver
>>>
>>>
>>>>>>for a
>>>>>>while. After sometime, the last hop DR (i.,e R5) tries to
>>>>>>
>>>>>>
>>>switchover
>>>to
>>>
>>>
>>>>>>SPT
>>>>>>and this breaks the multicast flow in the FR cloud. We can
>>>>>>
>>>>>>
>>>probably
>>>fix
>>>
>>>
>>>>>>this
>>>>>>by using SPT threshold infinity at R5. Then the traffic would flow
>>>>>>smoothly
>>>>>>to R5. The main issue that i am unable to address is when we have
>>>>>>
>>>>>>
>>>some
>>>
>>>
>>>>>>group
>>>>>>say Grp3 joined at R3 and if we ping this group from R2. In this
>>>>>>
>>>>>>
>>>case,
>>>
>>>
>>>>>>setting spt-threshold infinity at R3, does not seem to help. Since
>>>>>>
>>>>>>
>>>the
>>>
>>>
>>>>>>source is on the same network address in the FR cloud, the ping
>>>>>>
>>>>>>
>>>works
>>>
>>>
>>>>>>for a
>>>>>>while through the shared tree via R1, but after sometime, R3 seem
>>>>>>
>>>>>>
>>>to
>>>be
>>>
>>>
>>>>>>tearing down the source tree because it thinks the source is
>>>>>>
>>>>>>
>>>directly
>>>
>>>
>>>>>>connected and it stops the mulitcast flow for a while. I am sure
>>>>>>
>>>>>>
>>>you
>>>
>>>
>>>>>>guys
>>>>>>would have faced this issue, so I am wondering if there is any
>>>>>>
>>>>>>
>>>solution
>>>
>>>
>>>>>>for
>>>>>>this problem..
>>>>>>
>>>>>>Thank you
>>>>>>-Venkat
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>_______________________________________________________________________
>>>
>>>
>>>>>>Subscription information may be found at:
>>>>>>http://www.groupstudy.com/list/CCIELab.html
>>>>>>
>>>>>>
>>>>
>>>>
>>>_______________________________________________________________________
>>>
>>>
>>>>Subscription information may be found at:
>>>>http://www.groupstudy.com/list/CCIELab.html
>>>>
>>>>
>
>_______________________________________________________________________
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Mon Jan 09 2006 - 07:07:50 GMT-3