From: Curt Girardin (curt.girardin@chicos.com)
Date: Wed May 17 2006 - 15:18:10 ART
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
This archive was generated by hypermail 2.1.4 : Thu Jun 01 2006 - 06:33:21 ART