From: Le Anh Duong (duongla@vnn.vn)
Date: Thu Nov 10 2005 - 04:10:17 GMT-3
Hi,
Can we make the RP not to create the source tree towards the first-hop DR so
that the FHDR always send multicast packets in Register message ? If yes, it
is a solution for a source connected to a spoke router sending multicast
traffic to other spokes.
Thanks
Duong
----- Original Message -----
From: "Chris Lewis" <chrlewiscsco@yahoo.com>
To: "simon hart" <simon@harttel.com>; <swm@emanon.com>; "'kevin gannon'"
<kevin@gannons.net>
Cc: "'Imal kalutotage'" <imal.kalutotage@gmail.com>; "'Edwards, Andrew M'"
<andrew.m.edwards@boeing.com>; "'Balogh, Jim'" <jim.balogh@gwl.com>;
<ccielab@groupstudy.com>
Sent: Tuesday, November 08, 2005 4:06 AM
Subject: RE: Sparse mode multicast ?
> Correct, my aim was to describe the process and try to help people
studying multicast to see the reasons why registers would not be seen. I
just didn't feel saying everything was OK would help much :)
>
> Chris
>
> simon hart <simon@harttel.com> wrote:
> Chris, Scott et al,
>
> The explanations so far have hit the point but I have a reservation.
>
> There is one thing I think that is missing from the posts, and that is the
> behaviour of R3 when it is generating a Ping. R3 will send an mpacket out
> of every interface (default behaviour), and as such is behaving as an
mcast
> source. If there is an mcast router that recieves this packet and has an
RP
> mapped, it will then send a register to the RP prior to building the SPT
> back to the mcast router.
> In Kevin's scenario there is no intermediate mcast router, just the RP
next
> to R3. Therefore R3 does not need to send a register as it is a source and
> will continue to send mcast packets out of every interface, and also the
RP
> does not need to send registers because, well its the RP.
>
> I think the behaviour you are describing would be more accurately
replicated
> if you had an mcast router between R3 (the source) and the RP (R5).
>
> Simon
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Chris
> Lewis
> Sent: 07 November 2005 19:53
> To: swm@emanon.com; 'kevin gannon'
> Cc: 'Imal kalutotage'; 'Edwards, Andrew M'; 'Balogh, Jim';
> ccielab@groupstudy.com
> Subject: RE: Sparse mode multicast ?
>
>
> Correct, the first statement of the FHDR is a typo, the router receiving
the
> IGMP report is the LHDR, I need some alcohol too :)
>
> Chris
>
> Scott Morris wrote:
> 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 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.
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
> ---------------------------------
> Yahoo! FareChase - Search multiple travel sites in one click.
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.362 / Virus Database: 267.12.8/162 - Release Date: 05/11/2005
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.362 / Virus Database: 267.12.8/162 - Release Date: 05/11/2005
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
> ---------------------------------
> 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:06 GMT-3