From: Scott Morris (swm@emanon.com)
Date: Sun Aug 08 2004 - 01:10:52 GMT-3
Mmmmm.... Well...
My first inclination (again off-the-cuff and not labbed) would be that this
used to be true. Back when we could stick things like the "ip pim
rp-address" command on any router except the RP and the RP would figure it
out. Now-days though, that's not the case. So what they may answer is that
the magic of saying "hey, I'm the RP" went away so this is no longer a
condition.
So by the description of the command, the usage would be to make sure that
IT doesn't become an RP rather than worrying about other devices becoming
that. And I don't believe that is a problem any longer. Doesn't mean I'm
100% right though, so labbing it up will be the best way to figure that out.
And the command I was referring to was not the SEND-rp-announce command
(which is as you describe it) but one more geared towards listeners....
For the example you have though, the command seems to handle problems of
that nature. Will be intersting to see what your lab attempt shows!
http://www.cisco.com/en/US/products/sw/iosswrel/ps1828/products_configuratio
n_guide_chapter09186a00800d6b79.html#4898
Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, CISSP,
JNCIP, et al.
IPExpert CCIE Program Manager
IPExpert Sr. Technical Instructor
swm@emanon.com/smorris@ipexpert.net
http://www.ipexpert.net
-----Original Message-----
From: ccie2be [mailto:ccie2be@nyc.rr.com]
Sent: Saturday, August 07, 2004 11:45 PM
To: swm@emanon.com; 'john matijevic'; 'Group Study'
Subject: Re: ip pim rp-accept <rp-address> [acl#] command
Here's the source. this is from page 38 of module 6 of the Multicast
training slides which I found somewhere on cco.
Controlling RP Acceptance
. What really determines if a router is the RP
- Any Any router will assume the duties of the RP if:
. It receives a (*,G) Join that contains an RP address that is
the IP address of one of its interfaces AND
. The interface is multicast enabled AND
. The RP address matches the RP in the Group-to-RP
mapping cache OR
. There is no entry in the Group-to-RP mapping cache.
- Misconfigured routers could create multiple RPs in the
network
. Each sends a (*,G) Join with a different RP address
. Each (*,G) Join results in another RP for the same group
- The 'Accept-RP' command provides additional control
(insurance?) to prevent this.
. By default, a router operates as an RP for a group if:
- It receives a (*, G) Join containing one of its addresses as the RP or
- It receives a (S, G) Register message.
. Basic sanity check
- Routers will perform a rudimentary sanity check to see if it actually
should be the
RP for group "G" by searching the Group-to-RP mapping cache for an entry for
group "G". If an entry is found and the RP for the group is not this router,
then
the router will discard the (*, G) Join or (S,G) Register and will not
become the
RP. Otherwise, it will assume that it is the RP for group "G" and assume
duties
of the RP.
. Extended sanity checking
- In order to provide additional control and sanity checking over which
router
should be accepted as the RP, the IOS command 'ip pim accept-rp' was
created.
*************************************************************
As you can see, it seems to imply that any router could become a rp under
certain very specific conditions. I agree that given the conditions
necessary for a MA to become inadvertently a rp, it's somewhat unlikely.
And, I also agree that the ip pim rp-send-announce-filter is the more
appropriate command to use on the MA.
Correct me if I'm wrong, but, it seems that these 2 commands aren't mutually
exclusive.
The ip pim rp-send-announce-filter command filters only c-rp announcements
but not joins and is designed to prevent against rogue rp's being confgured
in the mcast domain.
The ip pim rp-accept <rp-address> [acl#] command, on the other hand, works
differently. It filters joins which can come from anywhere in the mcst
domain and can go anywhere in a mcast domain if another router is
misconfigured. Do you agree?
What's missing from the slide is any mention of on which routers this
command should be configured and I want to confirm what seems to be implied
- that this command could be configured on all routers - including the rp
and MA - in a mcast domain.
For example, imagine that 2 rp are configured for mcast groups 224.0.130.10
thru 224.0.130.20
Now, suppose the MA receives a join for froup 224.0.10.130 addresses to one
of it's pim enabled interfaces. Since the MA doesn't have this mcast group
in it's group to rp mapping cache, what does the MA do?
Won't the MA become the rp for that group?
Tim
----- Original Message -----
From: "Scott Morris" <swm@emanon.com>
To: "'ccie2be'" <ccie2be@nyc.rr.com>; "'john matijevic'"
<matijevi@bellsouth.net>; "'Group Study'" <ccielab@groupstudy.com>
Sent: Saturday, August 07, 2004 11:07 PM
Subject: RE: ip pim rp-accept <rp-address> [acl#] command
> Right... It's about filtering messages destined to one RP or the other
(and
> you can use the auto-rp part to verify with that cache).
>
> The mapping agent in and of itself will not become the RP. If it happens
to
> BE an RP, then it is not a MA for itself.
>
> It's not so much that you are worrying that devices "accidently" become
the
> RP (weird), but more that you make sure you're on the RP's tree.
>
> Look at the command section there. It says that the commmand causes the
> router to only accept (*,G) join messages destined for the specific RP
> address/groups. That's determining it's action in forwarding join/leave
> messages throughout a domain, not so much anything about how IT acts, just
> how it acts in forwarding.
>
> The difference also becomes that you can use this command on the RP itself
> and acheieve a different kind of filtering.
>
> Now, mind you, I haven't labbed anyhting up striving for the accidental RP
> assignment to watch behavior, but I would think that the "ip pim
> rp-announce-filter" command would be a better fit for what you appear to
be
> describing to me.
>
>
> Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, CISSP,
> JNCIP, et al.
> IPExpert CCIE Program Manager
> IPExpert Sr. Technical Instructor
> swm@emanon.com/smorris@ipexpert.net
> http://www.ipexpert.net
>
>
>
> -----Original Message-----
> From: ccie2be [mailto:ccie2be@nyc.rr.com]
> Sent: Saturday, August 07, 2004 10:53 PM
> To: swm@emanon.com; 'john matijevic'; 'Group Study'
> Subject: Re: ip pim rp-accept <rp-address> [acl#] command
>
> Hey Scott,
>
> I'm not sure we're on the same page.
>
> I think of this command as added protection against, for example, a static
> rp command being mis-configured. Suppose for example, the ip pim
rp-address
> <ip ad> command had the address of the MA entered by mistake.
>
> Couldn't, under some circumstances, the MA become the rp for some mcast
> groups? And, wouldn't the above command prevent that?
>
> Also, from a lab point of view, suppose we were instructed to configure
> Auto-rp. And, suppose we were also told to make sure that no routers
except
> those explicitly meant to be rp's ever accidentally became rp's. In this
> case, wouldn't we use the above command on all routers in the mcast
domain?
>
>
> ----- Original Message -----
> From: "Scott Morris" <swm@emanon.com>
> To: "'john matijevic'" <matijevi@bellsouth.net>; "'ccie2be'"
> <ccie2be@nyc.rr.com>; "'Group Study'" <ccielab@groupstudy.com>
> Sent: Saturday, August 07, 2004 10:31 PM
> Subject: RE: ip pim rp-accept <rp-address> [acl#] command
>
>
> > As an add-on, the candidate-RP or MA portion of the question... If you
> are
> > a mapping agent, you are just forwarding things anyway, so the rp-accept
> > command doesn't reference that IP at all. It will be WHAT is being
> learned,
> > not who from. (otherwise in BSR-land, that would always be your
directly
> > connected neighbors)
> >
> > HTH,
> >
> >
> > Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713,
CISSP,
> > JNCIP, et al.
> > IPExpert CCIE Program Manager
> > IPExpert Sr. Technical Instructor
> > swm@emanon.com/smorris@ipexpert.net
> > http://www.ipexpert.net
> >
> >
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> john
> > matijevic
> > Sent: Saturday, August 07, 2004 8:33 PM
> > To: 'ccie2be'; 'Group Study'
> > Subject: RE: ip pim rp-accept <rp-address> [acl#] command
> >
> > Hi Tim,
> > The command can best be explained as follows, from the doccd:
> > "ip pim accept-rp
> > To configure a router to accept join or prune messages destined for a
> > specified rendezvous point (RP) and for a specific list of groups, use
the
> > ip pim accept-rp command in global configuration mode"
> > So you are correct that this can be used on any mcast router in a mcast
> > domain. But don't take my word for it, test yourself, that's part of the
> > fun. :)
> >
> >
> > Sincerely,
> >
> > John Matijevic, CCIE #13254, MCSE, CNE, CCEA
> > Network Consultant
> > Hablo Espanol
> > 305-321-6232
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> > ccie2be
> > Sent: Saturday, August 07, 2004 7:29 PM
> > To: Group Study
> > Subject: ip pim rp-accept <rp-address> [acl#] command
> >
> > Hi guys,
> >
> > I just wanted to confirm my understanding of the above command.
> >
> > My sense is that this command can be used and useful on any mcast router
> > in a
> > mcast domain. This is true regardless of whether Auto-RP or BSR is
> > used. And,
> > this is true regardless of whether the router is a c-rp or a MA.
> >
> > Can anyone confirm this?
> >
> > TIA, Tim
> >
> > _______________________________________________________________________
> > Please help support GroupStudy by purchasing your study materials from:
> > http://shop.groupstudy.com
> >
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> > _______________________________________________________________________
> > Please help support GroupStudy by purchasing your study materials from:
> > http://shop.groupstudy.com
> >
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Sep 03 2004 - 07:02:35 GMT-3