Re: Multicast Data

Yes, you can:

ip pim sparse sg-expiry-timer

To adjust the (S, G) expiry timer interval for Protocol Independent
Multicast sparse mode (PIM-SM) (S, G) multicast routes (mroutes), use
the ip pim sparse sg-expiry-timer command in global configuration mode.
To restore the default setting with respect to this command, use the no
form of this command.

Default, as I said, is 180 seconds, or 3 minutes.

But I would think about what is the problem and see if changing this
is the better way to go about it. If S -> RP traffic does not generate
any problems in your setup, I might just join the RP to the group to
keep the mcast path established.

-Carlos

Tharindu Rukshan Bamunuarachchi @ 11/04/2010 22:51 -0300 dixit:
> hm ...
>
> okay, so if i join the tree after starting the show (e.g. after 20
> seconds) ... as RP does not keep potential sources ... i wont receive
> multicast data until 3 minutes timeout.
>
> is it possible to minimize 3 minutes ...
> __
> tharindu rukshan
> blog.tharindu.info <http://blog.tharindu.info>
>
>
>
> On Fri, Apr 9, 2010 at 5:28 PM, Carlos G Mendioroz <tron_at_huapi.ba.ar
> <mailto:tron_at_huapi.ba.ar>> wrote:
>
> I'd prefer you making the effort and ask what is that is unclear.
> But there are lots of cases in multicast where things get fixed
> after some timeout, and it happens to be 3 minutes by default.
> The RP keeps no info on potential sources if there are no receivers
> for a group, and will kill the registration attempt w/o joining in
> that case.
>
> Makes sense ?
>
> Tharindu Rukshan Bamunuarachchi @ 9/04/2010 8:31 -0300 dixit:
> > bit unclear about last point .... please clarify further if you
> can ....
> > __
> > btharindu.blogspot.com <http://btharindu.blogspot.com>
> >
> >
> >
> > On Fri, Apr 9, 2010 at 4:01 PM, Carlos G Mendioroz
> <tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>> wrote:
> >
> >> Adding to that that has been said:
> >> -yes, you can loose first, second, third... any, cause Mcast runs
> >> over UDP and there are no L4 delivery warranties. Actually, there
> >> are very few L7 protocols that have assured delivery over mcast.
> >>
> >> -registration does not stop when S (source router) receives join from
> >> RP, so there can be many packets going unicast to RP.
> >> RP tells S to stop registration after it receives direct mcast
> from S,
> >> so no packets lost in between.
> >>
> >> -sending can start before receivers have joined the RP, in which case
> >> the RP will stop registration w/o joining the source. Then you it
> will
> >> start a slow "flapping", trying to register every 3 mins, and being
> >> call to silence untill a receiver shows up.
> >>
> >> I guess you can loose up to 3 minutes of the show if nobody was
> >> listening and you are late to the start :)
> >>
> >> -Carlos
> >>
> >>
> >>
> >> Kambiz Agahian @ 9/04/2010 3:44 -0300 dixit:
> >>> Hi Tharin,
> >>>
> >>> Good point!
> >>> First off, I'm hoping that my interpretation of your question is
> correct
> >>> anyway correct me if your question if not exactly this but
> actually the
> >>> problem is that almost all resources (including most pages on
> cisco.comand
> >>> juniper.com <http://juniper.com> as well as the RFC!) focus on
> the "second" action taken by
> >> the RP
> >>> after receiving the registration request! and the first (but the
> less
> >>> important action) is somehow ignored (or underestimated)....
> >>>
> >>> Here is the process (briefly):
> >>>
> >>> Your Windows 2003 Media server starts sending the Multicast
> packets of
> >> (analog
> >>> term : broadcasting) "The Family guy". The first Mcast packets
> hit their
> >>> gateway and the DR of that segment tries to get a hold of the RP
> to kick
> >> off
> >>> the registration process. You know the encapsulation process
> (the actual
> >> mcast
> >>> content inside a unicast packet - right?) so the RP gets the first
> >> capsule and
> >>> "extracts" the multicast content. At this stage the RP has to
> take two
> >>> actions:
> >>>
> >>> 1- It sends the extracted Multicast packet down the tree based
> on the
> >> (*,G).
> >>> Where did you get that from? my Visa client had talked to his DR
> and his
> >> DR to
> >>> his upstream then to his upstream...all the way up to the RP to
> indicate
> >> his
> >>> interest. So before getting the first packet (the capsule) as you
> >> mentioned
> >>> the RP does know that I'm waiting to watch Quagmire (there is a
> receiver
> >> down
> >>> there). In fact the (*,G) is on the RP waiting for the source to
> come up.
> >>>
> >>> 2- The RP then tries to join the group and now everyone knows what's
> >> gonna
> >>> happen afterwards...I save some key strokes.
> >>>
> >>> Well, as you see (the first action), even the first packet
> (probably the
> >> first
> >>> frame of the Fox ad!) is delivered by the RP to (*,G) to ensure
> nothing's
> >>> going to be missed.
> >>>
> >>> HTH
> >>>
> >>>
> >>>
> >>>
> >>> Kambiz Agahian
> >>> CCIE (R&S)
> >>> CCSI, WAASSE, RSSSE
> >>> Technical Instructor
> >>> CCBOOTCAMP - Cisco Learning Solutions Partner (CLSP)
> >>> Email: kagahian_at_ccbootcamp.com <mailto:kagahian_at_ccbootcamp.com>
> >>> Toll Free: 877-654-2243
> >>> International: +1-702-968-5100
> >>> Skype: skype:ccbootcamp?call
> >>> FAX: +1-702-446-8012
> >>> YES! We take Cisco Learning Credits!
> >>> Training And Remote Racks: http://www.ccbootcamp.com
> >>> OEQ Voice Waiver: http://www.ccbootcamp.com/noeqvoice.html
> >>> OEQ R&S Waiver: http://www.ccbootcamp.com/noeqrs.html
> >>> OEQ Commercial: http://www.ccbootcamp.com/noeq.mpg
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: nobody_at_groupstudy.com <mailto:nobody_at_groupstudy.com> on
> behalf of Tharindu Rukshan Bamunuarachchi
> >>> Sent: Thu 4/8/2010 10:04 PM
> >>> To: ccielab_at_groupstudy.com <mailto:ccielab_at_groupstudy.com>
> >>> Subject: Multicast Data
> >>>
> >>> hi Experts,
> >>>
> >>> In sparse-mode, AFAIK first packet is forwarded to RP as
> unicast. (In
> >>> Register Unicast process).
> >>>
> >>> Is there any possibility to lose first packet without being
> delivered to
> >>> destination. (assuming destination is already subcribed to multicast
> >> tree)?
> >>>
> >>> __
> >>> btharindu.blogspot.com <http://btharindu.blogspot.com>
> >>>
> >>>
> >>> Blogs and organic groups at http://www.ccie.net
> >>>
> >>>
> _______________________________________________________________________
> >>> Subscription information may be found at:
> >>> http://www.groupstudy.com/list/CCIELab.html
> >>>
> >>>
> >>> Blogs and organic groups at http://www.ccie.net
> >>>
> >>>
> _______________________________________________________________________
> >>> Subscription information may be found at:
> >>> http://www.groupstudy.com/list/CCIELab.html
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >> --
> >> Carlos G Mendioroz <tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>>
> LW7 EQI Argentina
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> >
> _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> >
> >
> >
> >
> >
>
> --
> Carlos G Mendioroz <tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>>
> LW7 EQI Argentina
>
>

-- 
Carlos G Mendioroz  <tron_at_huapi.ba.ar>  LW7 EQI  Argentina
Blogs and organic groups at http://www.ccie.net