From: Herbert Maosa (asawilunda@googlemail.com)
Date: Tue Oct 02 2007 - 12:21:29 ART
Rich,
When you configure an interface as pim dense-mode, ALL groups for which
there is no known RP will be flooded off that interface. However, If a group
has a known RP, it will operate in sparse mode off this same interface.
Now, assume that there is group that has a known RP and therefore is being
sent in sparse mode fashion off this interface. IF due to some network
conditions reachability to this RP is lost, the group which was previoulsy
operating in Sparse mode now gets flooded in dense mode fashion since there
is no RP anymore. This is the dense mode fall back problem. Configuring no
ip pim dm-fallback prevents this fallback to dense mode from happening when
the RP is lost.
When you configure ip pim autorp listener , you now put the interface in
sparse mode thereby ensuring that no groups will be dense mode flooded.
However, this commands still permits the autorp groups ( 224.0.1.39,
224.0.1.40 ) to still be dense-mode flooded off an interface that is
operating in sparse-mode, thereby still allowing the automatic distribution
of RP to Group Mappings in dense mode off an interface that is in sparse
mode.
Herbert.
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
> >
>
>
-- Kindest regards, hm
This archive was generated by hypermail 2.1.4 : Fri Nov 16 2007 - 13:11:11 ART