From: Bajo (bajoalex@gmail.com)
Date: Wed May 17 2006 - 18:38:21 ART
Hi Scott,
Is my understanding wrong about "the RPF override"via "ip mroute"?. I
assumed we are overriding the unicast route table so that we do not use its
next-hop for the RPF check.
Thanks in advance for your explanation,
Bajo
On 5/17/06, Scott Morris <swm@emanon.com> wrote:
>
> Plain and simple. If you are being told it's a static route, that is not
> correct. It's about as accurate as telling you that a banana is like a
> grape. They share some common characteristics, but they are NOT the same
> thing by any stretch of the imagination.
>
> I agree with you about not doing NDA, but know your options.
>
>
> Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, JNCIE
> #153, CISSP, et al.
> CCSI/JNCI
> IPExpert CCIE Program Manager
> IPExpert Sr. Technical Instructor
> smorris@ipexpert.com
> http://www.ipexpert.com
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Curt
> Girardin
> Sent: Wednesday, May 17, 2006 2:18 PM
> To: Scott Morris; CCIEin2006; Kulcsar Andras Benjamin
> Cc: Brian McGahan; Tony Paterra; Cisco certification
> Subject: RE: IEWB Vol. 1 Lab 1 Multicast RPF checks against the RP...
>
> Hmmmm...
>
> Well I guess it might depend on how the restrictions are written. Does it
> say something like "do not use any static routes", or "do not use static
> routes of ANY kind?"
>
> In order to avoid breaking the NDA, my personal policy is "if it happened
> in
> the lab, don't discuss it", so I'm not going to tell you what the proctor
> told me. It is possible that I mis-understood him too - those guys can be
> cryptic!
>
> However, you might definitely consider asking the proctor to clarify their
> interpretation of a static route.
>
> Just my 2 cents,
>
> Thanks,
>
> Curt
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Scott Morris
> Sent: Wednesday, May 17, 2006 1:02 PM
> To: 'CCIEin2006'; 'Kulcsar Andras Benjamin'
> Cc: 'Brian McGahan'; 'Tony Paterra'; 'Cisco certification'
> Subject: RE: IEWB Vol. 1 Lab 1 Multicast RPF checks against the RP...
>
> "ip mroute" is NOT a static route, despite what the DocCD says. It is an
> override for the RPF check (alternate arriving interface). By using "ip
> mroute" you will not do ANYTHING to your normal unicast decision making
> process, so they are two unrelated things.
>
> If you are feeling particularly bored or paranoid, you can also use MBGP
> and
> the multicast address family to work with this too. Though it's a bit
> more
> of a hassle, and (IMHO) would be over-engineering!
>
> HTH,
>
>
> Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, JNCIE
> #153, CISSP, et al.
> CCSI/JNCI
> IPExpert CCIE Program Manager
> IPExpert Sr. Technical Instructor
> smorris@ipexpert.com
> http://www.ipexpert.com
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> CCIEin2006
> Sent: Wednesday, May 17, 2006 10:50 AM
> To: Kulcsar Andras Benjamin
> Cc: Brian McGahan; Tony Paterra; Cisco certification
> Subject: Re: IEWB Vol. 1 Lab 1 Multicast RPF checks against the RP...
>
> I believe static mroutes are a special case. I guess this falls under the
> "ask the proctor" category.
>
> On 5/17/06, Kulcsar Andras Benjamin <Kulcsar.Andras@kfki-lnx.hu> wrote:
> >
> > I also had a problem with this task. I had to use static mroute to
> > resolve the RPF check, but the general requierement said not to use
> > any static routes unless permitted.
> > Was this some kind of exception?
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> > Of Brian McGahan
> > Sent: Tuesday, May 16, 2006 4:07 PM
> > To: Tony Paterra; Cisco certification
> > Subject: RE: IEWB Vol. 1 Lab 1 Multicast RPF checks against the RP...
> >
> >
> > > interface? If R2 is the mapping agent, does it matter that it can't
> > > pass around the multicast address for cisco-rp-discovery?
> >
> > Yes it does matter. Since the candidate RP sends its
> > announcements as a multicast to the mapping agent these must pass RPF
> > as they are forwarded. Likewise the mapping agents advertisements to
> > the rest of the PIM neighbors are multicast and must also pass RPF.
> > An alternative would
> be
> > to use BSR because it uses a combination of unicast and hop-by-hop
> > communication.
> >
> >
> > HTH,
> >
> > Brian McGahan, CCIE #8593
> > bmcgahan@internetworkexpert.com
> >
> > Internetwork Expert, Inc.
> > http://www.InternetworkExpert.com
> > Toll Free: 877-224-8987 x 705
> > Outside US: 775-826-4344 x 705
> > 24/7 Support: http://forum.internetworkexpert.com
> > Live Chat: http://www.internetworkexpert.com/chat/
> >
> >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> > Of
> > > Tony Paterra
> > > Sent: Monday, May 15, 2006 11:10 PM
> > > To: Cisco certification
> > > Subject: IEWB Vol. 1 Lab 1 Multicast RPF checks against the RP...
> > >
> > > I was going through the multicast portion of the first lab and
> > > (being a little fresh to mcast) have noticed some unexpected
> > > behaviors. R3 is supposed to announce it's loopback as the RP for
> > > all multicast groups and R2 is supposed to announce it's loopback as
> > > the mapping agent. I understand these pieces, the real question...
> > > Is that I'm running debugs and seeing RPF check failures on R5 for
> > > (150.1.2.2,
> > > 224.0.1.40) because of the unicast routing table.
> > >
> > > Is this the way this is supposed to operate? Are there any other
> > > ways around this outside of static mroutes or enabling multicast on
> > > the necessary interfaces to reach R5 on the proper (ethernet0/0)
> > > interface? If R2 is the mapping agent, does it matter that it can't
> > > pass around the multicast address for cisco-rp-discovery?
> > >
> > > Thanks in advance,
> > > --
> > > Tony Paterra
> > > apaterra@gmail.com
> > >
> > >
> > ______________________________________________________________________
> > _
> > > 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
>
> _______________________________________________________________________
> 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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
-- Kind Regards,Bajo
This archive was generated by hypermail 2.1.4 : Thu Jun 01 2006 - 06:33:21 ART