RE: Multicast Data

OOOK!

Now I know where your problem is:

No timers expire if you have a live Multicast source - why?

If your Windows multicast server sends Multicast packets to its segment but no
receiver is known to the RP, his closest router (say R1) receives a (S,G)
Register-stop message from the RP and it stops shooting encapsulated packets
towards the RP.

R1 also gets rid of the "registering" flag for the (S ,G) entry. It also
discards all other packets from your Windows server.

Now, what do you reckon?

Does R1 removes the (S,G)? any timers to expire? no.

Actually the IETF has done a nice job here; although your timer is still
counting down but as soon as you reach T=0 IF your Multicast source is still
sending data IT RECREATES the entry and the little (S,G) never gets removed;
again as long as your source is alive.

How about the Register process?
As soon as R1 automagically recreates the (S,G) because of the existence of
multicast stream it sends another Register message towards the RP.

How about the Stop register message?
Same concept as before. The RP (if no receivers still out there) does send a
Stop reg. message towards R1.

Then again, if you don't shut down your Windows server you see the registering
process every 3 minutes but the logic behind it is the fact that R1 maintains
the (S,G) - again if there is a live Multicast source.

Problem?
Many students try to test this using Ping and they lose the (S,G)! eager to
test? use IP SLA to simulate a multicast source or a larger ping.

HTH
--------------------------
Kambiz Agahian
CCIE (R&S)
CCSI, WAASSE, RSSSE
Technical Instructor
CCBOOTCAMP - Cisco Learning Solutions Partner (CLSP)
Email: 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: Carlos G Mendioroz [mailto:tron_at_huapi.ba.ar]
Sent: Mon 4/12/2010 2:31 AM
To: Tharindu Rukshan Bamunuarachchi
Cc: Kambiz Agahian; ccielab_at_groupstudy.com
Subject: 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