From: Cisco Nuts (cisconuts@hotmail.com)
Date: Mon Nov 07 2005 - 14:06:52 GMT-3
Another great one from you, Chris....
I just went over Doyle, Vol II and this helped me understand things much
better.
Thank you.
Sincerely.
--------------------------------------------------------------------
From: Chris Lewis <chrlewiscsco@yahoo.com>
Reply-To: Chris Lewis <chrlewiscsco@yahoo.com>
To: kevin gannon <kevin@gannons.net>, Imal kalutotage
<imal.kalutotage@gmail.com>
CC: "Edwards, Andrew M" <andrew.m.edwards@boeing.com>, "Balogh, Jim"
<jim.balogh@gwl.com>, Chris Lewis <chrlewiscsco@yahoo.com>,
ccielab@groupstudy.com
Subject: Re: Sparse mode multicast ?
Date: Mon, 7 Nov 2005 08:02:00 -0800 (PST)
>Hello Kevin,
>
>My initial question (to which Anderw replied) was intended to
stimulate people studying multiacst to ask themselves about the
process of setting up shared and source trees in sparse mode. Your
initial toppology is interesting because the RP is in the middle and
therefore the physical path taken by the shared tree and source tree
are the same, which is not normally the case when these things are
illustrated in documentation.
>
>Assuming a fair amount of time has elapsed for those interested to
consider this situation, I'll look at how this works in a bit more
detail now.
>
>Consider the case where an RP is someway off in the network and
therefore the shared tree and source tree are in fact using different
paths, what happens when a source first comes up and there is no
source based tree, so there is multiacst transport from the source to
the RP?
>
>
>The First-Hop Designated router unicasts the data in what is called
a Register. The FHDR is the one receiving the IGMP join from
configuration or an attached host. Since there is no distribution
tree between the RP and source, this is the only way to get the
packets to the RP so they can be distributed down the shared tree.
>
>When the RP receives the Registers, it de-encapsulates the packet
and forwards it down the shared tree. At the same time, this
triggers the RP to send a source tree (aka Shortest-Path-First / SPT
Tree) join towards the source. The source joins are sent hop by hop
towards the source until the tree is formed between the source and
RP.
>
>
>
>Now, the first-hop DR will send 2 copies of multicast packets to the
RP; one via Register messages and another via the source tree. When
the RP receives the first packet from the source tree, it will send a
Register-Stop (which is also unicasted) to the first-hop DR to notify
it that there is no need for it to send Registers anymore. At this
point, the first-hop DR stops Registering and sends data only on the
source tree.
>
>
>
>The traffic which flows from the RP down the shared tree is
eventually delivered to the receiver. By default, all last-hop DRs
(the last hop DR router is the last router in the tree before the
traffic is delivered to hosts) will perform a switchover to the
source creating a separate source tree. This is done because the RP
may not always be the most efficient path between the source and
receivers (however in your case the RP is in the path of the source
tree).
>
>As a result of the switchover, additional (s,g) state is created
along the path towards the source.
>
>When the source tree and shared tree paths diverge, a special prune
message is sent to the RP to prune off the shared tree traffic. This
is necessary so duplicate packets are not received and forwarded
towards the receiver(s). Basically all this means is that the router
where the divergence between shared and source tree exists tells teh
RP to stop sending data to it, as it is gettting data via the source
tree and does not need it from the RP any more.
>
>
>
>Next, the RP will prune off the source tree it established during
the Register process with the first-hop DR when it realizes there are
no interfaces in its Outgoing Interface List.
>
>
>
>This triggers a source tree, (S,G) Prune towards the source. This
still leaves teh source tree from the source to destination in tact,
all it does is stop teh RP from receiving a copy of teh multiacst
data as it is no longer sending it out to anyone.
>
>
>
>Finally, only multicast data flows along the shortest path tree
between the source and sender. In the background, PIM Sparse Mode
periodically sends joins to keep the branch alive.
>
>
>
>Now this may be a little difficult to digest without whiteboard
diagrams, however, this is the process of how it works, and it should
be possible to see all of this happening via the show ip mroute
output. It makes it interesting to watch though when the source and
shared tree are the same path.
>
>
>
>The key thing to look at is where you need to apply the
spt-threshold command.
>
>
>
>When the Last-Hop DR receives the first packet down the shared tree,
by default it will perform a switchover to the source, creating a
source tree represented by (S,G) where S is the source IP address and
G is the multicast group. Unless the Last-Hop DR has the command ip
pim spt-threshold infinity configured globally (meaning always use
the shared tree; do not perform switchover), a (S,G) entry should be
created. In your case, the last hop DR is the RP.
>
>
>
>
>Chris
>
>
>kevin gannon <kevin@gannons.net> wrote:
>Guys thanks a lot it was in fact the SPT threhold I had set to
infinity
>and looking at it again with the explanations it makes sense.
>The *.G was confusing me at first but I have it cracked now I
>think.
>
>I think that the ping will get sent encaped in a register message
towards
>the RP until it move to an SPT. However in debugs I usually only
>see one message. Are they ratelimited or exclduded from the debug
>fro safety so you only see "normal" S,G registers and not the
encaped
>packet version ?
>
>Thanks & Regards
>Kevin
>
>On 11/5/05, Imal kalutotage wrote:
> > Nice explanation Andy,
> >
> > So what do we need to do to overcome this problem..in NBMA
> > 2 solutions comes to my mind.
> >
> > 1. static mroute to the source, pointing towards hub
> > 2. Spoke to spoke tunnel
> >
> > Am I right on this, I just need to verify my thinking..
> >
> > Cheers
> > Imal
> >
> > On 11/5/05, Edwards, Andrew M wrote:
> > >
> > > If they're congruent then there would be no issue for spt
failover on
> > > the leaf router.
> > >
> > > The main issues are this:
> > >
> > > Did you pass the RPF to the BSR/AUTORP mapper?
> > > Did you pass the RPF towards the RP?
> > > Did you pass the RPF towards the source of (S,G) for the
default SPT
> > > failover?
> > >
> > > As indicated, SPT failover is the default behavior for a router
in
> > > sparse mode.
> > >
> > > So, it will build a SPT to the source NOT the RP by default.
> > >
> > > What does this mean? It means we spent a lot of time setting up
the
> > > routers to pass the RPF check for the RP in order to get your
first
> > > response to a test packet on the group. However, once you send
data to
> > > the group, the leaf (end routers) will by default change from
using the
> > > RP to the SPT and potentially stop receiving (symptomatically
we see
> > > them stop responding) to the test data.
> > >
> > > This can be a problem is the route to the Source for the group
is out a
> > > different interface than where you are receiving it from. IOW,
you
> > > failed the RPF check and stop passing data because the paths to
RP and
> > > Source (S,G) are not congruent.
> > >
> > > This can happen on NBMA topologies where there is a known route
towards
> > > a source that is NOT directly connected (e.g. its reachable via
another
> > > spoke on hub and spoke frame cloud at L2, but at L3 looks like
its
> > > directly attached).
> > >
> > >
> > > Andy
> > >
> > > -----Original Message-----
> > > From: Balogh, Jim [mailto:jim.balogh@gwl.com]
> > > Sent: Friday, November 04, 2005 4:43 PM
> > > To: Chris Lewis; kevin gannon; ccielab@groupstudy.com
> > > Subject: RE: Sparse mode multicast ?
> > >
> > >
> > > Not sure....good question! Anyone know?
> > >
> > > Jim
> > >
> > > ________________________________
> > >
> > > From: Chris Lewis [mailto:chrlewiscsco@yahoo.com]
> > > Sent: Friday, November 04, 2005 5:29 PM
> > > To: Balogh, Jim; kevin gannon; ccielab@groupstudy.com
> > > Subject: RE: Sparse mode multicast ?
> > >
> > >
> > > what if the shared tree and source tree are congruent?
> > >
> > > Chris
> > >
> > > "Balogh, Jim" wrote:
> > >
> > > Kevin,
> > >
> > > Just gave the scenario a quick glance, and you need the ip pim
> > > spt-threshold command on the last-hop router....in this case
R2.
> > >
> > >
> > > The switch from shared to source tree (with Sparse Mode)
happens
> > > upon
> > > the arrival of the first data packet at the last hop router.
> > > This switch
> > > occurs because the ip pim spt-threshold interface configuration
> > > command
> > > controls that timing, and its default setting is 0 kbps.
> > >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
> > > Behalf Of
> > > kevin gannon
> > > Sent: Wednesday, November 02, 2005 12:12 PM
> > > To: ccielab@groupstudy.com
> > > Subject: Re: Sparse mode multicast ?
> > >
> > > Anyone any ideas ?
> > >
> > > Regards
> > > Kevin
> > >
> > > On 11/1/05, kevin gannon wrote:
> > > > Have a simple set with three routers
> > > >
> > > > R2--------R5(RP)--------R3
> > > >
> > > > Its running all sparse mode. R2 has an igmp join statement
for
> > >
> > > > 225.25.25.25 and R3 is sending a ping to this
> > > group source
> > > from
> > > > 35.35.35.3 . Below is the mroutes I see on R3 the
> > > source of the
> > > stream.
> > >
> > > > I am experimenting with set the spt threshold to infinity on
> > > R3 below
> > > > is the different mroute
> > > > outputs:
> > > >
> > > > Default setup no SPT threshold changed
> > > > ####################################################
> > > > (*, 225.25.25.25 ), 00:36:46/stopped, RP
> > 5.5.5.5,
> > > flags: SJPCL
> > > > Incoming interface: Serial0/1, RPF nbr 35.35.35.5
> > > > Outgoing interface list: Null
> > > >
> > > > (35.35.35.3 , 225.25.25.25 ),
> > > 00:05:20/00:02:59, flags: PLT
> > > > Incoming interface: Serial0/1, RPF nbr 0.0.0.0 ,
> > > Registering
> > > > Outgoing interface list: Null
> > > >
> > > > (*, 224.0.1.40 ), 00:37:22/stopped, RP
> > 5.5.5.5,
> > > flags: SJPCL
> > > > Incoming interface: Serial0/1, RPF nbr 35.35.35.5
> > > > Outgoing interface list: Null
> > > >
> > > > SPT Threshold set to infinity
> > > > ###################################################
> > > >
> > > > (*, 225.25.25.25 ), 00:40:15/stopped, RP
> > 5.5.5.5,
> > > flags: SPCL
> > > > Incoming interface: Serial0/1, RPF nbr 35.35.35.5
> > > > Outgoing interface list: Null
> > > >
> > > > (35.35.35.3 , 225.25.25.25 ),
> > > 00:08:49/00:02:58, flags: PLT
> > > > Incoming interface: Serial0/1, RPF nbr 0.0.0.0 ,
> > > Registering
> > > > Outgoing interface list: Null
> > > >
> > > > (*, 224.0.1.40 ), 00:40:51/stopped, RP
> > 5.5.5.5,
> > > flags: SPCL
> > > > Incoming interface: Serial0/1, RPF nbr 35.35.35.5
> > > > Outgoing interface list: Null
> > > >
> > > > My questions:
> > > > 1. Why do I not see any outgoing interfaces in either output
> > > > for (35.35.35.3 , 225.25.25.25
> > > ),
> > > >
> > > > 2. In the default SPT setup how come I see the "Registering"
> > > > going on and on and on.....
> > > >
> > > >
> > > > Thanks & Regards
> > > > Kevin
> > >
> > >
> > >
_______________________________________________________________________
> > > 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
> > >
> > >
> > > ________________________________
> > >
> > > Yahoo! FareChase - Search multiple travel sites in one click.
> > > > >
gxNjkEcG9zAzEEc2VjA21haWwtZm9vdGVyBHNsawNmYw--/SIG=110oav78o/**http%3a//
> > > farechase.yahoo.com/ >
> > >
> > >
_______________________________________________________________________
> > > 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
> >
> >
_______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> > --
> > This message has been scanned for viruses and
> > dangerous content by MailScanner, and is
> > believed to be clean.
> >
> >
>
>
>---------------------------------
> Yahoo! FareChase - Search multiple travel sites in one click.
>
>_______________________________________________________________________
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Thu Dec 01 2005 - 09:12:05 GMT-3