From: Learn Cisco (cisco.learn@yahoo.com)
Date: Tue Jul 08 2008 - 11:56:34 ART
that makes sense. even though normal sparse mode reverts to SPT after first
consulting the RP, i don't think it truly revets to dense mode unless there is
no known RP. i think the flag for dense mode would be "D" vs. the "SJT" flags
for SM using spt (show ip mroute output).
this is starting to get a bit
clearer for me now i think. thanks!
i wonder why no ip pim dm-fallback would
ever be desired (besides being a potential lab requirement)? if no RP is
known, no mcast is going to work without a DM fallback it seems.
thanks
----- Original Message ----
From: Harindha Fernando <pottaharry@gmail.com>
To:
Learn Cisco <cisco.learn@yahoo.com>
Cc: ccielab@groupstudy.com
Sent: Tuesday,
July 8, 2008 8:19:14 AM
Subject: Re: Multicast Features
PIM DM Fallback
will come into picture if there is no RP available for the group, isn't it?
but if there is a RP then first packets will go via shared tree and switched
to shortest path tree if it finds better path to source, isn't ? but
following the SPT does not mean it is Dense mode, isn't it?
we can avoid SPT
by configuring ip pim spt-threshold infinity so that all the packets will
follow shared tree. but if there is a failure in RP and if we have not
configured no ip pim dm-fallback then it will flood on every interface if
PIM-SM-DM is configured in all the interfaces. but I have a doubt what will be
the case if we have mix of PIM-SM and PIM-SM-DM interfaces in same PE. will it
flood through the PIM-SM interface ? hope not ...
On Tue, Jul 8, 2008 at
5:08 PM, Learn Cisco <cisco.learn@yahoo.com> wrote:
all sparse mode
implementations (sparse-mode + sparse-dense-mode) immediately
revert to a
source-based / shortest-path tree after first polling the RP for
the multicast
source IP address....unless the spt-threshold is adjusted.
-----Original
Message-----
From: nobody@groupstudy.com
[mailto:nobody@groupstudy.com] On
Behalf Of
Harindha Fernando
Sent: Tuesday,
July 08, 2008 2:39 AM
To: John
Cc:
Learn Cisco; ccielab@groupstudy.com
Subject: Re: Multicast Features
Hi,
If
you have configured all the
interfaces to PIM-SM then fallback mode will
be
sparse , if you have at least
one interface with SM-DM then
fallback mode
will be Dense, by putting
no ip pim dm-fallback
guaranties that fallback
will be in Sparse mode.
Rgds,
Harri
On Tue, Jul 8, 2008 at 3:31 AM, John
<jgarrison1@austin.rr.com>
wrote:
> spt-threshhold is for source tree. The
default is 0 kbs, which
means that
> anything over 0 kbs will go to a source
tree. no ip pim-dm
fallback is to
> prevent, at least sparse-dense mode from
falling back to
dense mode for
> unknown groups. In the docs I've seen it
used in sparse mode
and
sometimes
> not. I'm still trying to find a
definitive answer on that.
Ill probably
> end up labbing it on friday and then
I'll know for sure.
>
>
>
> "The mind is like a parachute it works best when
it's open"
> ----- Original
Message ----- From: "Learn Cisco"
<cisco.learn@yahoo.com>
> To:
<ccielab@groupstudy.com>
> Cc:
<cisco.learn@yahoo.com>
> Sent: Monday, July
07, 2008 5:27 PM
> Subject:
Multicast Features
>
>
>
> hi, i'm trying to get
a better grasp on multicast
topics. any feedback
to
>> the following
questions would be much appreciated:
>>
>> 1.) was wondering if anyone can
help differentiate between the use of
"ip
>> pim spt-threshold infinity" and
"no ip pim dm-fallback". they both
seem
to
>> prevent sparse-dense-mode
and/or sparse-mode pim from reverting
back to a
>> sourced-tree /
shortest-path tree unless I'm missing something.
>>
>> 2.) would "ip pim
accept-rp auto-rp" be needed along with one of the
cmds
>> above to ensure no
spt paths form?
>>
>> 3.) when would "ip pim
accept-rp x.x.x.x x" be used? i
guess if i get a
>> question/requirement that
states to have a device accept
join/prune
messages
>> for an rp i'd know to
use this feature, but it seems as
though their
might
>> be more to this
thing???
>>
>> 4.) "ip pim autorp
listener" is the feature to use when
desiring to use
>> sparse-mode along with
auto-rp, right? (without statically
assigning the
rp
>> mapping on all
sparse-mode devices)
>>
>> thanks in
advance for any input,
>>
>>
>>
This archive was generated by hypermail 2.1.4 : Mon Aug 04 2008 - 06:11:54 ART