Re: mcast tshoot tips?

Thanks for this, you and others are helping to build my confidence. The
other nice thing (IMO) is that the docs on mcast are fairly
straightforward. For most configs, everything is found on the same page.

Not too much on RPF failures, the hardest thing is identifying that this is
the problem.

Would you agree?

BTW - that link from Petr is great. Thanks Petr for writing it!

Andrew Lissitz

.
On Mon, May 2, 2011 at 3:23 AM, Jeferson Guardia <jefersonf_at_gmail.com>wrote:

> On both attempts I had mcast stuff, if you solid understand the tickets
> narbik made on his tshoot wb with Dan, you will find the ts section easier
> (personal experience). I remember doing his ts wb and remember spending more
> than one hour to fix something he made up, once I attempted the lab there
> were no crazy ninja tickets, just straightforward stuff.
>
> Cheers,
>
>
>
> On 01/05/2011, at 23:27, ALL From_NJ <all.from.nj_at_gmail.com> wrote:
>
> > Wowsers!!! A nice link and some good info.
> >
> > Dave, I forgot about the 'active' keyword at the end of the mroute
> command
> > ... that sure is helpful and I used to use that command a lot when I used
> to
> > work with mcast on my job ...
> >
> > From Jason:
> >
> >
> http://blog.ine.com/2010/09/17/troubleshooting-multicast-routing/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+ine+%28INE+CCIE+Blog%29
> >
> > Some good reading this will be.
> >
> > Thank you team. I will have some more playtime tomorrow ... it is past
> my
> > bedtime now ;-)
> >
> > Chat soon and thanks again!!!
> >
> >
> >
> >
> > On Sun, May 1, 2011 at 10:58 PM, Jason Witover <jwitover_at_itproserv.com
> >wrote:
> >
> >> I find this a helpful link:
> >>
> >>
> http://blog.ine.com/2010/09/17/troubleshooting-multicast-routing/?utm_sourc
> >>
> e=feedburner&utm_medium=feed&utm_campaign=Feed%3A+ine+%28INE+CCIE+Blog%29<
> http://blog.ine.com/2010/09/17/troubleshooting-multicast-routing/?utm_sourc%0Ae=feedburner&utm_medium=feed&utm_campaign=Feed%3A+ine+%28INE+CCIE+Blog%29
> >
> >>
> >>
> >>
> >> On 5/1/11 9:17 PM, "ALL From_NJ" <all.from.nj_at_gmail.com> wrote:
> >>
> >>> Hey team,
> >>>
> >>> Was doing some mcast tshooting today, and wanted to get some ideas or
> >>> links
> >>> that you think will be helpful for the lab and tshoot section. I am
> >>> worried
> >>> about the amount of time, and complexity of this ... especially since
> in
> >>> the
> >>> config section of the lab, this mcast technology will 'sit on top of'
> the
> >>> other technologies I have already configured; IGPs, etc ...
> >>>
> >>> On the RP:
> >>> Whenever you add a source or destination, it should show up in the
> mroute
> >>> table. So in this way, you can tshoot either the source or group
> >>> membership
> >>> problems. Which direction has the problem; from the source or from the
> >>> join-group? For those who want to lab this, try it since it is a quick
> >>> lab
> >>> test. Add a source or join-group, and then check the RP's table. It
> is
> >>> quite cool to see this show up in the mroute table.
> >>>
> >>> Team question - what is the fastest way to tell if you have a RPF
> failure?
> >>> I can imagine being in the lab and getting confused with topology and
> >>> direction of routes.
> >>>
> >>> What is the quickest way to resolve a RPF failure? My thoughts below,
> >>> please add to this:
> >>>
> >>> 1) Static mroute (How many routers could potentially need these
> static
> >>> mroutes?)
> >>> 2) Admin distance, cost, etc ... or other tweaks to prefer a path
> without
> >>> removing the routes? Trying to maintain the reachability, which making
> >>> the
> >>> mcast route also the best IGP route ...
> >>> 3) Any preferred debugs that might tell you what to configure to solve
> the
> >>> RPF failure?
> >>>
> >>> Suggestion for problem resolution: start a long ping process from the
> >>> source, and as you are resolving the problem, when you fixed the
> problem,
> >>> the ping will start to work. Is this a good method, anyone else try
> this?
> >>>
> >>> From Narbik - add loopbacks with the igmp join-group. Do this along
> the
> >>> path, and where the ping stops, there is the problem router. Any
> >>> additional
> >>> suggestions to this? Sounds like a good idea.
> >>>
> >>> Likely potential problems IMO ...
> >>>
> >>> 1) PIM or ip multicast-routing not enabled
> >>> 2) RP not reachable?
> >>> 3) RPF failure
> >>> 4) ACL or firewall? Should this also affect the RP not being reached?
> >>> Meaning ... can I skip this check if the RP is reachable and the PIM
> >>> messaging is working
> >>> 5) RP not learning sources or join-groups
> >>> 6) ???
> >>>
> >>> Team - I am worried about the time I have to resolve tshooting; caused
> by
> >>> me
> >>> or the tshoot section. I look forward to hearing your thoughts on this
> >>> matter.
> >>>
> >>> TIA team and please accept my wishes for you to have a great week!!!
> >>>
> >>> --
> >>> Andrew Lee Lissitz
> >>> all.from.nj_at_gmail.com
> >>>
> >>>
> >>> Blogs and organic groups at http://www.ccie.net
> >>>
> >>> _______________________________________________________________________
> >>> Subscription information may be found at:
> >>> http://www.groupstudy.com/list/CCIELab.html
> >>
> >>
> >> Blogs and organic groups at http://www.ccie.net
> >>
> >> _______________________________________________________________________
> >> Subscription information may be found at:
> >> http://www.groupstudy.com/list/CCIELab.html
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> > --
> > Andrew Lee Lissitz
> > all.from.nj_at_gmail.com
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> >
> >
> >
> >
> >
>

-- 
Andrew Lee Lissitz
all.from.nj_at_gmail.com
Blogs and organic groups at http://www.ccie.net