From: Schulz, Dave (DSchulz@dpsciences.com)
Date: Fri Nov 18 2005 - 00:11:39 GMT-3
Ah yes, Gustavo. I am clear on dense mode (sometimes I'm dense
myself...;-))....but isn't what you have described really sparse-dense mode?
Where it opts for the source path, rather than the shared path?
Dave
-----Original Message-----
From: Gustavo Novais
To: Schulz, Dave; Scott Morris; Drew Whitaker; Cisco certification
Sent: 11/17/2005 8:00 PM
Subject: RE: Preventing DM Fallback
If I may, as I understood it, as soon as the Rp gets a register message
from the source, a shortest path tree is built between the RP and
designated router of the sources' segment.
When the RP gets a Join from a DR of the members subnet, the flow starts
going through the RP. But now the router is aware of the IP of the
source, which he consults on its unicast routing table and sees that is
reachable through another interface. Hence this router sends a Join
directly to the next hop router closer to the source RPF-wise. When
finally it gets the flow (S,G) (having the shortest path tree built) it
simply sends a Prune message to the RP, which detaches him from the
shared path tree, leaving him with the spt tree. This can also explain
why you have to set spt threshold to infinity on all routers on the
path.
This is a bit different of dense mode, since we really are not "pushing"
the traffic from the source in order to see who wants it, but we are
demanding a more efficient path to the source. The result from both
processes is the same. A shortest path tree.
I hope it made sense.
As someone said, trying to explain something to someone is the real test
if you got it yourself.
You can check TCPIP Vol2 page 526 or so
HTH
Gustavo Novais
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Schulz, Dave
Sent: quinta-feira, 17 de Novembro de 2005 20:59
To: Scott Morris; Drew Whitaker; Cisco certification
Subject: RE: Preventing DM Fallback
Scott -
Are your last statement, are you saying that sparse mode has a dense
mode as well, and that it is able to fallback to dense mode? I thought
that sparse mode only will keep everything communicating through the RP
(shared tree). Do I have something backwards?
Dave Schulz,
Email: dschulz@dpsciences.com
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Scott Morris
Sent: Thursday, November 17, 2005 3:31 PM
To: 'Drew Whitaker'; 'Cisco certification'
Subject: RE: Preventing DM Fallback
Two different pieces actually....
DM Fallback refers to the process when you are running sparse-dense mode
and
an RP (or shared tree) cannot be found for the group you are looking
for,
then dense mode will work. So in that case, there never is a shared
tree to
keep traffic on.
In sparse mode once you hit the RP and shared tree, the spt-threshold
will
keep things on that tree instead of finding the better source tree
someplace
along the way.
HTH,
Scott
-----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/hi
mc_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