From: Chris Lewis (chrlewiscsco@yahoo.com)
Date: Mon Nov 07 2005 - 15:04:19 GMT-3
If I am understanding your post correctly, setting the SPT threshold to infinity should not mean that you should see a stream of register messages.
spt threeshold infinity is set on the last hop DR, and leaves the shared tree from the RP to the last hop designated router in tact. This is nothing to do with sending registers or not.
Registers are sent from the first hop DR to the RP until a multicast route from the first hop DR to the RP is setup. After that point, the first hop DR can use multicast to get to the RP and does not have to encapsulate the multicast packet in to unicast (AKA a register) in order to reach the RP. This is described in my post below as the register stop process. Basically this is all independent of the spt threshold effects.
Just for clarity, the first hop DR is the one connected to the source and the last hop DR is the one connected to the receiver.
Cheers
Chris
kevin gannon <kevin@gannons.net> wrote:
Excellant post even with the white board and free beer.
What I dont seem to see is a stream of register messages
with the encapsulated data when I have the SPT threshold
set to infinity. Maybe IOS ratelimits them ??
Must test it again it was late last time I tested.
Regards
Kevin
On 11/7/05, Chris Lewis wrote:
> 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 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 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.
This archive was generated by hypermail 2.1.4 : Thu Dec 01 2005 - 09:12:05 GMT-3