From: ccie2be (ccie2be@nyc.rr.com)
Date: Tue Jul 20 2004 - 23:52:42 GMT-3
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