From: Scott Morris (swm@emanon.com)
Date: Mon Nov 07 2005 - 17:22:36 GMT-3
Got it, I think I missed the word "not" in your explanation and was trying
to figure out where the stream was coming from. I need alcohol. ;) (or
caffeine and let 'em battle it out)
_____
From: Chris Lewis [mailto:chrlewiscsco@yahoo.com]
Sent: Monday, November 07, 2005 2:47 PM
To: swm@emanon.com; 'kevin gannon'
Cc: 'Imal kalutotage'; 'Edwards, Andrew M'; 'Balogh, Jim';
ccielab@groupstudy.com
Subject: RE: Sparse mode multicast ?
Scott,
Perhaps we have an issue with terminology and nothing more.
The point I was trying to communicate to Kevin was that PIM registers only
happen while there is no distribution tree between the first hop DR and the
RP. So the only option is to encapsulate the multicast in to unicast, which
is what the first hop DR does. When the RP receives the first packet from
that source via a source tree, it will unicast a register stop message to
the first hop DR.
Basically I was stating that one should not expect to see a stream of
registers happening, it is only a temporary phenomenon while the source tree
is built.
Chris
Scott Morris <swm@emanon.com> wrote:
I'm not sure that direction/concept of registers is accurate... Perhaps I'm
not understanding where you're going with it though.
The first-hop DR (by the multicast source) is responsible to unicast SA
message (which are part of the Register functions) to the RP. This happens
periodically just to keep everything refreshed and up to date. If the RP
has nobody interested, nothing happens in a multicast stream.
Once someone is interested and the RP sends a Join request up, and the
multicast stream is flowing this doesn't do anything to the duty of the PIM
DR to send SA/Register messages. That never happens "in stream" as I'm
reading your post to mean (which I could be reading it wrong since I have an
alcohol deficiency this afternoon!).
So we may be saying the same thing here, I just want to talk it out.... :)
Scott
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Chris Lewis
Sent: Monday, November 07, 2005 1:04 PM
To: kevin gannon
Cc: Imal kalutotage; Edwards, Andrew M; Balogh, Jim; ccielab@groupstudy.com
Subject: Re: Sparse mode multicast ?
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 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