From: Joseph Brunner (joe@affirmedsystems.com)
Date: Tue Oct 02 2007 - 12:10:17 ART
Auto-rp listener STILL floods dense mode the auto-rp groups across normally
sparse mode interfaces, kind of a poor mans bootstrap.
With the dm-fallback no one moves any data if they want to "PUSH" instead of
"PULL" the feed. Check it out with debugs. build a sparse-dense network
Kill the RP's with ACL's, multicast boundaries (I prefer shutdowns) and
watch the debugs fly. Print them out. With and without no|ip pim
dm-fallback. Use recent very recent IOS.
For my question, same subnet. And do lots of debugs. use the doc cd
extensively.
_____
From: Rich Collins [mailto:nilsi2002@gmail.com]
Sent: Tuesday, October 02, 2007 10:57 AM
To: Joseph Brunner
Cc: Herbert Maosa; Bob Sinclair; Cisco certification
Subject: Re: default multicast pim mode
I still feel like I don't understand "no ip pim dm-fallback".
Please compare : ip pim sparse-dense (with autorp), no ip pim dm-fallack
with
ip pim sparse-mode (with either static ip or autorp + listener)
Joe, I will take a crack at your scenario soon. You said shared lan
interface - so you mean all in the same subnet?
On 10/1/07, Joseph Brunner <joe@affirmedsystems.com> wrote:
Nope, you're right. I mean to say in my task "at no time should ANY groups
operate in dense mode". That is what I made in my lab, but it never made it
like that in to the question. My question was to test whether or not you
knew the auto-rp was a bad little flooder on sparse mode interfaces.
Check it now.
* "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 ANY 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)
So we know these two tricks now (i.e. the difference between autorp-listener
and no ip pim dm-fallback)
If you haven't had the pleasure of lab'ing them up, do so and run all
relevant debugs. Here is another cool one. Enjoy
Configure multicast routing between R3, R4, R5 and R6 using their shared lan
interfaces of
R3 F0/0
R4 F0/1
R5 F0/0
R6 G0/0.101
Do not use BSR for this task, or static rp assignments. All routers running
multicast should prefer R6 as the RP for the following groups
224.5.5.5 & 239.2.2.2. If R6 is unavailable, R5 should be selected as the
RP. If both R6 and R5 are unavailable the remaining routers should switch
To using dense mode in the shortest time possible for the groups.
Don't answer it here. lab it up first. This is from my evil lab, newly
tempered in the UNIVERCD beta kappa.
I'm counting on not having access to the DOC CD on my next real lab,
considering the UNIVERCD is down today online.
So I'm spending a lot of time with it now.
-Joe
_____
From: Herbert Maosa [mailto: asawilunda@googlemail.com]
Sent: Monday, October 01, 2007 8:00 PM
To: Joseph Brunner
Cc: Rich Collins; Bob Sinclair; Cisco certification
Subject: Re: default multicast pim mode
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
<mailto: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: <mailto:nobody@groupstudy.com>
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 <http://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 <http://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