From: Scott Morris (swm@emanon.com)
Date: Mon Nov 07 2005 - 15:12:15 GMT-3
Great explanantion all in all, although I think there's a couple things a
little off. You reference the IGMP-receiving device as the first hop DR and
then later it shows up as the last hop. From a PIM tree perspective the
IGMP receiver is the last-hop PIM. The first-hop PIM (as you do mention
(duplicate) is the one by the multicast source that actually is responsible
for the SA (Source Active) messages so that the RP knows about it.
I think this clarification may help your explanation here, although as Kevin
mentioned, a whiteboard and some beer may help as well!
The "stream" of messages you may be alluding to depends on the timeframe
that it takes all the rest of the stuff to occur. Your
IGMP-receiving-router will send a Register message to the RP via unicast.
Any intermmediate routers won't necessarily see this (since it's unicast as
all routers know about the RP but not much more). Once the initial PIM
Register message is done, that's when the RP starts sending information down
the shared tree (back towards the IGMP-receiving-router that started this
whole mess). That allows routers in the middle (between the RP and
IGMP-receiving-router) that may have been oblivious to this exchange to
actually build their tree and get things ready! In my experience I've only
seen one Register message needed, but if it took a while for the
IGMP-receiving-router to hear anything back, it could get impatient and send
more. The spec allows it to be whiny.
The RP, as you note, sends a join message up to the PIM router that is
nearest to the multicast source (the first-hop). That initiates a
source-specific tree from the multicast source to the RP, and then shared
tree back to the IGMP-receiving-router.
Everything else, as you note with the SPT is done on behalf of the last-hop
PIM router (aka IGMP-receiving-router). Only the RP or the last-hop routers
on a branch are capable of making this switch from *,G ro S,G.
Intermmediate routers are not allowed to make these kinds of decisions even
though they may theorhetically see an opportunity.
RFC2362 spells out a lot of these things in case you're bored some night and
need an alternative to counting sheep.
;)
In the meantime, I'm all for beer 'n' whiteboards!
Scott
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
kevin gannon
Sent: Monday, November 07, 2005 12:08 PM
To: Chris Lewis
Cc: Imal kalutotage; Edwards, Andrew M; Balogh, Jim; ccielab@groupstudy.com
Subject: Re: Sparse mode multicast ?
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 <chrlewiscsco@yahoo.com> 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 <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 message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean.
This archive was generated by hypermail 2.1.4 : Thu Dec 01 2005 - 09:12:05 GMT-3