From: Edwards, Andrew M (andrew.m.edwards@boeing.com)
Date: Wed Jul 21 2004 - 13:00:51 GMT-3
I'd actually like to chime in here on multicast because no matter how
many times I configure it, it just doesn't seem to want to behave the
same way time after time....
With that in mind, I think we had a post that asked a question that's
been bugging me but I never saw an answer to it nor have I found it in
the archive...
I was working on a practice lab where one of the requirements was to
ensure multicast groups do NOT revert to dense mode. Statically set all
RPs.
So it was pretty straight forward to set sparse mode only and statically
set RPs.
Does the group interpret this requirement to also include instances
where the source is closer than the RP and SPT uses (S,G) instead of
(*,G)? IOW, if I have (S,G) mroutes would that violate the requirement?
Any input is appreciated...
andy
-----Original Message-----
From: ccie2be [mailto:ccie2be@nyc.rr.com]
Sent: Tuesday, July 20, 2004 7:53 PM
To: Group Study; Kenneth Wygand
Subject: Re: Multicast - Sparse Mode
Actually, I've never tried that myself so I can't say from 1st hand
experience what would happen.
However, one of the few mcast concepts that stuck with me is what I told
Gerry in my earlier post, "The mode of the interface DOES NOT determine
whether a mcast group runs in sparse or dense mode." .
I'm pretty sure (99%), the mode of the mcast group is determined solely
by whether or not the rtr knows and can reach the rp for that mcast
group.
I think, but I'm far from 100% on this, the interface mode has more to
do with things like determining which rtr is the designated forwarder
and some other dense mode specific functions.
I suspect but again I don't for sure that if all interfaces were
config'd as dense mode but all mcast groups were pointing to a
statically config'd rp, the rtr would operate in sparse mode for all
mcast groups.
But, from the practical point of view of the lab, I don't think this
stuff matters all that much. As I said to Gerry, I don't the "trick" to
getting all the mcast points will turn on whether you can figure out if
sparse mode or dense mode should be configured on the interfaces. I
think the instructions will be rather straighforward on this.
I think the key to mcast on the lab will be knowing things like mapping
mcast to broadcast, filtering igmp requests, preventing rogue rtr's from
becoming the rp, knowing whether to config BSR or Auto-rp, and the
difference between join-group and static-group.
Also, I think it's important to keep in mind how many points one can
realistically expect on mcast. My guess is from 4 to around 8 with 5 or
6 about average.
Furthermore, I think the best way to prepare for mcast is to go over the
mcast section from each IE pratice lab. If you can do the mcast portion
from each practice lab, you've got nothing to be concerned about when it
comes to mcast.
Of course, this is only my humble opinion and should be taken with a
grain a salt.
HTH, Tim
----- Original Message -----
From: "Kenneth Wygand" <KWygand@customonline.com>
To: "ccie2be" <ccie2be@nyc.rr.com>
Sent: Tuesday, July 20, 2004 10:09 PM
Subject: RE: Multicast - Sparse Mode
Tim,
As I am -far- from a multicast expert, the answer here is "I have no
idea!".
Do you know the answer? All of the situations I've ever seen have been
a single PIM mode through the entire domain, or, for the sake of ccie
lab discussion, throughout the entire lab.
Have you seen different? Can you elaborate on your understanding
pehaps?
Feel free to include the group on your reply if you think the info would
be of value to everyone else.
Thanks in advance,
Ken
________________________________
From: ccie2be [mailto:ccie2be@nyc.rr.com]
Sent: Tue 7/20/2004 10:02 PM
To: Kenneth Wygand
Subject: Re: Multicast - Sparse Mode
Hey Ken,
I think you're not 100% correct in what you're saying about interfaces
running in either saprse or dense mode.
Consider this situation.
Suppose you had a rtr which had some interfaces config'd as sparse mode
and other interfaces config'd as dense mode. On this same rtr, you also
had a rp statically configured for a range of mcast groups.
This same rtr also had pim neighbors for all it's active interfaces and
they were configured the same way.
Now, a client joins a mcast group for which an rp is defined.
What happens on each interface? Dense mode? Sparse mode?
Tim
----- Original Message -----
From: "Kenneth Wygand" <KWygand@customonline.com>
To: "Gerry Hilton" <gerry.hilton@rogers.com>
Cc: <ccielab@groupstudy.com>
Sent: Tuesday, July 20, 2004 8:05 PM
Subject: RE: Multicast - Sparse Mode
> Gerry,
>
> In light of the lab, here are my comments and thoughts.
>
> First, the PIM mode is configured on an interface. That mode
> restricts
the forwarding of group traffic in a certain fashion. Running pim
sparse-dense mode on an interface allows each group to receive streams
in either fashion: sparse or dense mode. Running pure sparse or pure
dense mode PIM on an interface only allows multicast traffic to flow
from source to group in that fashion.
>
> What you are saying is correct. If you run PIM sparse-dense mode on
> an
interface, groups -WITH- an RP will run in Sparse mode, which groups
-WITHOUT- an RP will run in Dense Mode. Thus the auto-rp groups, which
obviously don't have an automatic RP themselves, will run in dense mode
and all other groups can run in either fashion.
>
> If all groups have an RP, all groups will be running in sparse mode.
However, you must read what the requirements of the question are. Does
it say "the interface should run Pim Sparse-mode"? If so, even if all
the groups are running in sparse mode, Pim is running in sparse-dense
mode if you configure it that way.
>
> Look for other subtle clues, such as "ensure shared trees are never
> used".
Since sparse-mode initially starts using a shared tree (even if it
switches to a SPT after that), running any kind of sparse mode would
violate these requirements. Maybe you are to "ensure traffic switched
over the frame-relay network does not impact critical routing
processes". In this case, you must run "ip pim nbma-mode" so multicast
traffic is not "accidentally" put into the hardware strict priority
queue, and in order to run "ip pim nbma-mode", you must be in
sparse-only mode.
>
> Yes, there are a lot of times where multiple solutions can satisfy the
requirements for a particular set of exam questions. Maybe you can
configure subinterfaces on an interface or run a protocol on a physical
interface and both solutions satisfy a given set of requirements.
However, with a topic as large as multicast, I'd be hard-pressed to
think the requirements they set forth on you will be loose enough that
you can choose either version of PIM and still satisfy all of the
requirements. Now, whether or not you actually -realize- the implied
requirement to know which way to configure it, that's a whole different
ball game. ;-)
>
> I know on my attempts thus far, I thought I could satisfy a set of
requirements in multiple ways, so I just picked one way of doing it.
However, since that time I've learned a lot more, and usually (sometimes
several weeks apart), I'll learn something new and say "Ahh, -THAT'S-
why I couldn't configure it the way I did and still satisfy the
requirements". That's a hard lesson to learn when you give up 2, 3 or 4
points per concept. God Bless the CCIE exam and all those who have gone
before me! :)
>
> Hope this helps a bit,
> Ken
>
> ________________________________
>
> From: Gerry Hilton [mailto:gerry.hilton@rogers.com]
> Sent: Tue 7/20/2004 7:45 PM
> To: Kenneth Wygand
> Cc: ccielab@groupstudy.com
> Subject: Re: Multicast - Sparse Mode
>
>
>
> Hi. I agree - if it is clearly stated to configure sparse mode, and
> there are no other requirements, then I too would configure sparse
> mode, and probably use the ip pim auto-rp listener command.
>
> In my email though, I was referring to the less clear case where there
> were additional requirements so that configuring sparse mode only
> would probably not work. I keep reading that interfaces are treated
> as sparse if they know of an RP, so in that case I was thinking that
> configuring them as sparse-dense and making sure that an RP was known,
> would meet the requirements of sparse mode as well as some additional
> requirements.
>
> Thanks,
> Gerry
>
> Kenneth Wygand wrote:
>
> >Gerry,
> >
> >My opinion... If "one is asked to configure sparse mode", hey, you'd
better be configuring SPARSE mode... not Dense mode, not Sparse-Dense
mode, but SPARSE mode... This is just my opinion.
> >
> >However, take a look at the following command in the Doc CD:
> >
> >"ip pim auto-rp listener"
> >
> >It may answer some of your question for things that previously
> >"required"
dense-mode...
> >
> >HTH,
> >Ken
> >
> >________________________________
> >
> >From: nobody@groupstudy.com on behalf of Gerry Hilton
> >Sent: Tue 7/20/2004 7:12 PM
> >To: ccielab@groupstudy.com
> >Subject: Multicast - Sparse Mode
> >
> >
> >
> >Hi there. A few questions about multicast and sparse mode:
> >
> >If one is asked to configure sparse mode, then is it valid to
> >configure ip pim sparse-dense mode and have a known RP, as then the
> >interfaces would be treated as sparse mode (this would be if there
> >was a case where just configuring sparse mode would not meet all
> >requirements)?
> >
> > If the interfaces are configured as sparse-dense and the RP is known
> >via auto-RP, then are they still considered to be acting in sparse
> >mode? If not, then is the only way to know the address of the RP and
> >still be considered sparse mode, to manually configure the RP address
> >on each router?
> >
> >This is only in the case where one requires the interfaces to be
> >configured in sparse-dense mode but treated as sparse.
> >
> >Thanks,
> > Gerry
> >
> >_____________________________________________________________________
> >__
> >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
>
> ______________________________________________________________________
> _
> 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 : Sun Aug 01 2004 - 10:12:00 GMT-3