From: Scott Morris (swm@emanon.com)
Date: Thu May 18 2006 - 01:10:26 ART
Yes and no. An RPF check, by definition, will consult the unicast routing
table to ask "if I were going back out, does this incoming interface
match?". RPF in general doesn't affect outbound unicast routing, it's just
a comparison. So the "ip mroute" command provides an alternate path.
So a route to 1.1.1.1 may be out s0/0 per your routing table. Multicast you
want to come in through s1/1 instead. RPF would fail since things coming
FROM 1.1.1.1 should not be coming in s1/1. An "ip mroute 1.1.1.1
255.255.255.255 s1/1" would alleviate this problem. When you traceroute or
ping (or whatever) TO 1.1.1.1, you'll still exit the s0/0 interface. But
multicast packets arriving IN s1/1 are allowed to pass the RPF check.
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
_____
From: Bajo [mailto:bajoalex@gmail.com]
Sent: Wednesday, May 17, 2006 5:38 PM
To: Scott Morris
Cc: Curt Girardin; CCIEin2006; Kulcsar Andras Benjamin; Brian McGahan; Tony
Paterra; Cisco certification
Subject: Re: IEWB Vol. 1 Lab 1 Multicast RPF checks against the RP...
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 <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 <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