From: Venkataramanaiah.R (vramanaiah@gmail.com)
Date: Sun Dec 04 2005 - 07:18:45 GMT-3
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>
> 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
This archive was generated by hypermail 2.1.4 : Mon Jan 09 2006 - 07:07:50 GMT-3