From: Gerry Hilton (gerry.hilton@rogers.com)
Date: Thu Jul 22 2004 - 11:24:55 GMT-3
In regards to your question below:
"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)?"
I don't know the answer (my guess would be that it would not violate the requirements
when the source is closer than the RP) but if it did violate the requirements,
you could use the command ip pim spt-threshold infinity and that would
prevent it from ever using a shortest path source tree.
Gerry
Edwards, Andrew M wrote:
>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
>>
>>
>
>_______________________________________________________________________
>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