From: Tim (ccie2be@nyc.rr.com)
Date: Thu Nov 17 2005 - 19:02:33 GMT-3
Drew,
It's been a while since I thought about or played around with this but I'll
take a crack at it anyway.
First, let me address the "ip pim spt-threshold infinity" command. The way
I understand it, once mcast traffic starts to flow down the share tree to
the last hop router, by default, that last hop router will switchover to a
shortest path tree. This doesn't have anything to do dense-mode. True, the
last hop router will send a prune up towards the RP to stop the mcast
traffic flow down the shared tree, but that's not following the dense mode
model of flood and prune.
Also, that command only affects traffic for one mcast group. So, other
mcast groups could be running in dense mode while the mcast group where the
last hop just switched-over is still running in sparse mode.
Now, if I remember correctly, here's the issue with dense mode fallback. A
mcast traffic flow will be treated as dense mode or sparse mode depending
upon whether the router knows the RP for that mcast group.
If, for some reason the router doesn't know the RP for that mcast group,
that router will treat the mcast traffic as dense mode even if that flow
should be sparse mode.
I remember a studying and learning about creating that "sink-hole" you
mentioned as a way to prevent a mcast flow ever being treated as dense mode
but I don't recall all the details anymore.
If I can find it, I'll try to dig out the material that explained that
topic.
HTH, Tim
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Drew
Whitaker
Sent: Thursday, November 17, 2005 12:48 PM
To: Cisco certification
Subject: Preventing DM Fallback
This question for the group revolves around the idea of how to keep traffic
on a shared tree.
To disable dense mode fallback, I can type 'no ip dm-fallback' (thus keeping
traffic on a shared tree). Yet, in my reading, I have also come across the
command 'ip spim spt-threshold infinity' which, according to the Cisco
documentation, "causes all sources for the specified group to use the shared
tree." By using the shared tree, doesn't this also prevent DM fallback like
the 'no ip dm-fallback' command?
Also, in the "IP Multicasting Technology Overview" document (
http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/himc_c
/
ch05/mcbcncpt.htm#wp1075142)
it says you can create a sink RP (RP of last resort) to ensure that no
groups (other than PIM v1 224.0.1.39 <http://224.0.1.39> and
224.0.1.40<http://224.0.1.40>groups) resort to a source tree. So
wouldn't this do it as well?
I am trying to understand the differences between these three methods. Are
these three different methods to prevent multicast traffic from using a
source tree?
This archive was generated by hypermail 2.1.4 : Thu Dec 01 2005 - 09:12:07 GMT-3