RE: mcast tshoot tips?

What about SSM (no *,G) or BiDir (just *,G). "sh ip rpf" is very useful. On
a network with real traffic, "sh ip mroute active" and "sh ip mroute count"
can be very useful.

David

--
http://dcp.dcptech.com
> -----Original Message-----
> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
> ALL From_NJ
> Sent: Sunday, May 01, 2011 10:18 PM
> To: Cisco certification; Cisco certification
> Subject: mcast tshoot tips?
> 
> 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