From: Herbert Maosa (asawilunda@googlemail.com)
Date: Mon Oct 01 2007 - 20:59:38 ART
Well, the only restriction I see here is At no time should this multicast
group be able to operate in dense mode.
Sparse mode with autorp listener satisfies this requirement, just as
sparse-dense
with no ip pim dm-fallback. I dont see any restriction in requirement number
3 not to use Autorp, unless I am really missing something fundamental.
Herbert.
On 10/2/07, Joseph Brunner <joe@affirmedsystems.com> wrote:
>
> Read the doc cd for #3. I really just think you need "no ip pm
> dm-fallback"
> for the dense mode turn-off on the task, not AUTO-RP.
>
> Auto-rp listener is specifically for instances "where you want the auto-rp
> groups FLOODED in DENSE mode across the sparse mode interface". This
> BREAKS
> the requirements of #3 ;)
>
> #3 is pushing you towards a static rp solution, and no ip pim dm-fallback.
>
> Herbert, read the description of "no ip pim dm-fallback" very
> carefully...
> (note the IOS default is to ALLOW DM FALLBACK.
>
> "Use this command to prevent a router from falling back into PIM dense
> mode
> when the RP becomes unavailable. This command also causes the router to
> block all multicast traffic for groups not specifically configured with an
> RP."
>
> The cool thing is my imagination having been flexed by IE WB's and the
> IPEXPERT proctor guide 9.0 is causing me to lab up weird things, debug
> everything, print out the output and read and read the debugging while
> referencing the DOC CD... Fun stuff.
>
> Gents, what is with univercd home, its down? WTF? Don't tell me,
> forthcoming
> "you must pay for it now" announcement from ROME, or worse its been broken
> up into the support pages for IOS... :(
>
> -Joe
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Herbert Maosa
> Sent: Monday, October 01, 2007 6:28 PM
> To: Joseph Brunner
> Cc: Rich Collins; Bob Sinclair; Cisco certification
> Subject: Re: default multicast pim mode
>
> Number 3 is quite interesting. I believe no ip pim dm-fallback applies to
> groups for which an RP was previously known, but has been lost somehow.
> For
> groups that an RP was never known at any time, these will operate in dense
> mode if an interface is confgured as sparse-dense mode.
>
> So actually, for number 3, I would configure the interface as sparse-mode
> and then enable autorp listener. In that way I guarantee that the only
> groups that will operate in dense mode will be the autorp groups and
> nothing
> else.
>
> Herbert.
>
>
> On 10/1/07, Joseph Brunner <joe@affirmedsystems.com> wrote:
> >
> > Rich, more can be said about this...
> >
> > Here are some of my favorites (I made these up just now, so if I'm wrong
> > about something blame the distracting hold music in my ear, LOL)...
> >
> >
> > "ip pim autorp listener"
> > Configure the following routers using PIM Sparse mode, R1 F0/0, R2 F0/0,
> > R2
> > F0/1, R2 S0/0, R3 S0/0, R4 S0/0. R1 will be the Dr for the following
> > groups
> > 239.1.1.1, 224.4.4.4. Do not use static rp assignments. Do not use BSR.
> >
> > (hint = sparse mode + dynamic rp assignments + no bsr allowed)
> >
> >
> >
> > "ip pim bsr"
> > Configure PIM sparse mode on the following interfaces, R1 F0/0, R2 F0/0,
> > R2
> > F0/1,, R2 S0/0, R3 S0/0, R4 S0/0. R1 will be the DR for the following
> > groups
> > 239.1.1.1, 224.6.6.6. Do not use static rp assignment. No group should
> > require dense mode operation.
> >
> > (hint = sparse mode required, no static rp's allowed, bsr allowed!)
> >
> >
> >
> > "no ip pim dm-fallback & ip igmp static-group"
> > Configure multicast routing between R1 & R6. R1 F0/0, R1 S0/0, R2 S0/0,
> R2
> > F0/1. R2's F0/1 segment will receive a multicast feed originating in
> R1's
> > F0/0 segment. R2's lan clients do not run IGMP and require access to
> > 239.1.1.1. For security reasons R6 should not respond to pings of the
> > multicast group. At no time should this multicast group be able to
> operate
> > in dense mode.
> >
> > (hint = dense mode is never allowed + clients are not allowed to ping
> > 239.1.1.1 and get a response from R6)
> >
> >
> > Please everyone post their favorites too!
> >
> > -Joe
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> > Rich
> > Collins
> > Sent: Monday, October 01, 2007 2:32 PM
> > To: Bob Sinclair
> > Cc: Cisco certification
> > Subject: Re: default multicast pim mode
> >
> > Bob,
> >
> > Thanks for that great summary. My approach is to try to study and
> > practice
> > the technologies but at the same time try to learn the 'terminology' of
> > the
> > task requirements. It is aggravating to actually know the method or
> > technology but then to take the wrong approach because you missed the
> clue
> > in the task requirement statement.
> >
> > Rgds
> > Rich
> >
> >
> >
> > On 10/1/07, Bob Sinclair <bob@bobsinclair.net> wrote:
> > >
> > > Rich Collins wrote:
> > > > I'm curious about BSR. What should you see in the question to point
> > you
> > > in
> > > > that direction versus DM, autorp or static RP?
> > > >
> > > Rich,
> > >
> > > The more you know about these methods, the easier it is to interpret
> the
> > > task requirements. The primary attribute of both Auto-RP and BSR is
> > > dynamic advertising and fail-over. One of the primary
> differentiators
> > > would be Cisco protocol (Auto-RP) versus IETF standard (BSR, PIMv2).
> > > Beyond that, there are many distinctions. For example:
> > >
> > > Auto-RP works with the multicast boundary to enable announcement
> filters
> > > for individual groups, BSR does not.
> > >
> > > Auto-RP RPs and MAs use IP multicast trees to communicate, BSR uses a
> > > combination of subnet-local multicasts and unicast.
> > >
> > > BSR gives us priorities to control candidate RPs and BSRs, Auto-RP
> does
> > > not.
> > >
> > > Auto-RP gives us the scope parameter, BSR does not. This is one of
> the
> > > reasons Beau Williamson is still so hot on Auto-RP.
> > >
> > > As with all topics, the more you know about the protocol and the IOS
> > > options, the easier it is to interpret the task requirements.
> > >
> > > HTH,
> > >
> > >
> > > --
> > >
> > >
> > > Bob Sinclair CCIE 10427 CCSI 30427
> > > www.netmasterclass.net
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
>
>
>
> --
> Kindest regards,
> hm
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
-- Kindest regards, hm
This archive was generated by hypermail 2.1.4 : Fri Nov 16 2007 - 13:11:11 ART