From: Joseph Brunner (joe@affirmedsystems.com)
Date: Mon Oct 01 2007 - 20:44:03 ART
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
This archive was generated by hypermail 2.1.4 : Fri Nov 16 2007 - 13:11:11 ART