Re: Core knowledge Q from Anthony J. Sequeira - Diagrams for

Hey Johnny and Anthony,

Many thanks for your responses. Yeah, this is a good scenario IMO.

I am also wondering if the same restrictions apply: no static routes, no ip
mroute routes, etc ...

Yeah Johnny, I was thinking route metrics too.

2 hours for the tshooting tickets does not sound like much too me ... I am
most interested to see the tshooting section. Hope I can do alright with
this ...

Take it easy team, and have a good night,

Andrew

On Fri, Sep 25, 2009 at 7:51 PM, Johnny B CCIE <jbccie_at_gmail.com> wrote:

> Andrew this is an excellent question.
>
> The problem typically associated with rpf failure is that the unicast
> routing table and the multicast rpf path are not the same. In the
> example of the tunnel we may face this issue and by checkign both we
> may quicly determine that the two are not in agreement and therefore
> we might use the ip mroute command to quickly resolve the issue.
> However, suppose a tunnel is not the scenario presented. Suppose you
> are restricted from using the ip mroute command to provide a quick fix
> to this well-known problem. How would you then propose to resolve the
> issue?
>
> Well I suppose I would first verify that I have enabled all interface
> with the correct ip pim command as specified in my workbook. If this
> fxes the problem due to an interface not being configured correctly
> then it is working and I am done. However if it still is broken and
> the rt still failes to be in sync with the rpf check, then I might
> consider altering my routing metrics to take the desired path. Notice
> I have not broken the given restrictions of using ip mroute. Many
> people seem to suggest this solution. In my experiments with the
> command I can usually fix this by altering the metrics of my routing
> protocols and therefore alter the best path in my rt and this results
> in an agreement with my rpf. We proceed to take this method and employ
> it on a hop-by-hop basis until we reach the source.
>
>
>
> On Fri, Sep 25, 2009 at 1:35 PM, ALL From_NJ <all.from.nj_at_gmail.com>
> wrote:
> > Hello Team, happy Friday.
> >
> > Was thinking about the tshooting section and I saw an old post from
> Anthony
> > which included this Q&A:
> >
> > Q: If you create a tunnel for multicast traffic and do not enable an
> > IGP over the tunnel, what command is needed on the router that needs
> > to receive the multicast feeds?
> > A: ip mroute
> >
> > I was like wow ... ok, cool. This would not have crossed my mind in the
> > past and I got to thinking about how a tshooting ticket might look.
> >
> > Question for the team -
> >
> > 1) How would you have gone about tshooting this? Start w/ a ping or
> > mtrace?
> > 2) How to discover these things quickly?
> > 3) Does it help to see that the routers register the s,g correctly, but
> that
> > a ping fails?
> >
> > My guess is that a question like this would state something like
> > "administrator bob has configured his network for mcast, however when bob
> > starts a mcast stream, traffic does not go through. Fix bob's network".
> >
> > Also - will we have a separate set of diagrams and addressing for the
> > tshooting section?
> >
> > Rock on team, and many TIA,
> >
> > --
> > 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