From: Venkataramanaiah.R (vramanaiah@gmail.com)
Date: Sun Dec 04 2005 - 03:27:17 GMT-3
Hello Joshua,
Static mroutes were added. It does not make any difference.
Probably this is a limitation which can not be overcome.
-Venkat
On 12/4/05, joshua lauer <jslauer@hotmail.com> wrote:
>
> I'm not sure of the situation but you'll likely need a Static Mroute to
> make
> this fly,
>
> there are examples of this on CCO
>
> HTH,
>
> JL
>
>
>
> ----- 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