From: Godswill Oletu (oletu@inbox.lv)
Date: Sun Dec 04 2005 - 07:37:31 GMT-3
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
To: Godswill Oletu
Cc: Josef A ; Cisco certification
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 >
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