From: ccie2be (ccie2be@nyc.rr.com)
Date: Sun Aug 08 2004 - 07:50:06 GMT-3
Used to be true???
What happened that makes this not true?
----- 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: Sunday, August 08, 2004 12:10 AM
Subject: RE: ip pim rp-accept <rp-address> [acl#] command
> 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
> > >
> > >
This archive was generated by hypermail 2.1.4 : Fri Sep 03 2004 - 07:02:35 GMT-3