From: Chris Lewis (chrlewiscsco@gmail.com)
Date: Wed Apr 19 2006 - 13:00:03 GMT-3
Agreed,
As well as seeing the debug output, I have seen the lack of no ip
mroute-cache on a PIM interface make pings fail. I have never got to the
bottom of it, as it seems to be a fast switching versus process switching
thing I don't know about and not had the need to try, just configuring no ip
mroute-cache as a safety precaution is all I've felt I needed to know.
Anyway, as was pointed out, the issue is with the Olist. Really there are
two issues to be concerned with for multicast, RPF and Olist. RPF does not
seem to be the problem and we are reporting Olist null on R6. So why is
that? What can be done to fix it.
Try putting ip igmp join 228.28.28.28 on the R2 interface facing R6, you
should then be able to ping 228.28.28.28 from BB1 and get replies from both
R2 and R3. Is that allowed by the wording of the question? If not can you
thinnk of another way around the problem?
Chris
On 4/19/06, Nick Griffin <ngriffin@sio.midco.net> wrote:
>
> I use it on mcast neighbors between the source and destination to see
> the mcast packet input and output destinations. If you don't disable it
> on interfaces along the path you won't see transit traffic in the debug
> ip mpacket.
>
> Schulz, Dave wrote:
> > Hi Chris - Just curious about the no ip mroute .... how does insuring
> the
> > multicast traffic being fast-switched help find the issue?
> >
> > Dave
> >
> > ________________________________
> >
> > From: nobody@groupstudy.com on behalf of Chris Lewis
> > Sent: Wed 4/19/2006 9:58 AM
> > To: Vikram Dadlaney
> > Cc: ccielab@groupstudy.com; ccie.xpert@gmail.com
> > Subject: Re: Multicast problems
> >
> >
> >
> > Forget that, you've probably got dynamic mappings. I'd check to make
> sure
> > all your PIM neighbors are setup first and simplify your config to the
> bare
> > minimum and look at the output of debug ip mpack. You will probbaly want
> to
> > configure no ip mroute-cache on all PIM interfaces also.
> >
> > Chris
> >
> >
> > On 4/19/06, Chris Lewis <chrlewiscsco@gmail.com> wrote:
> >
> >> It looks like you are using the physical interfaces for teh frame
> relay
> >> connection between BB1 and R6. If so, I would have expected to see
> frame
> >> relay map statements in those interfaces.
> >>
> >> You won't get multicast connectivity until unicast is working!
> >>
> >> Chris
> >>
> >>
> >> On 4/19/06, Vikram Dadlaney <vdadlaney@gmail.com> wrote:
> >>
> >>> Hi Shameen,
> >>>
> >>> From your topology it doesn't seem like you have any alternate paths.
> >>> Can
> >>> you confirm this? Your OIL list on R6 is empty hence you are not
> >>> forwarding
> >>> the multicast traffic. Can you post the the configs of R2. Also have
> you
> >>> tried clearing all your neighbors. The 'ip mroute' influences the RPF
> >>> check.
> >>> If you have multicast enabled on all interfaces than it should not
> >>> matter
> >>> but say you have an alternate path and you haven't enabled multicast
> on
> >>> that
> >>> but the unicast routing table is choosing that path than you will have
> a
> >>> RPF
> >>> failure. Please do let us know if the problem has been resolved. HTH.
> >>>
> >>> Regards,
> >>>
> >>> Vikram
> >>>
> >>>
> _______________________________________________________________________
> >>> 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 May 01 2006 - 11:41:58 GMT-3