From: Godswill Oletu (oletu@inbox.lv)
Date: Sun Dec 04 2005 - 06:30:37 GMT-3
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
> > >
> > >
This archive was generated by hypermail 2.1.4 : Mon Jan 09 2006 - 07:07:50 GMT-3