From: John Jones (acer0001@gmail.com)
Date: Tue Oct 02 2007 - 12:31:16 ART
Anytime no RP is not available for sparse mode, dense mode will take over.
Thie no ip pim dm-fallback command prevents this from happening. So, if your
RP goes down for some reason, your network won't be flooded and pruned over
and over again. A good reason for RP redundancy for multicast groups.
ip pim sparse-dense - sparse groups will convert to dense; all groups will
be dense
ip pim sparse - sparse groups will convert to dense; all groups will be
dense
John
On 10/2/07, Rich Collins <nilsi2002@gmail.com> wrote:
>
> 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
> >
> >
> >
> > X "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> 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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Nov 16 2007 - 13:11:11 ART