Re: Multicast Data

Yes. Can you answer the question ?

Kambiz Agahian @ 12/04/2010 21:50 -0300 dixit:
> Did you get a chance to read my previous post?
>
> --------------------------
> 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 begin_of_the_skype_highlighting
> 877-654-2243 end_of_the_skype_highlighting
> International: +1-702-968-5100 begin_of_the_skype_highlighting
> +1-702-968-5100 end_of_the_skype_highlighting
> 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.htmljavascript:SetCmd(cmdSend);
> 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 4:18 PM
> To: Kambiz Agahian
> Cc: Tharindu Rukshan Bamunuarachchi; ccielab_at_groupstudy.com
> Subject: Re: Multicast Data
>
> Dear,
> would you please answer straight one question ?
> (So we can discuss some facts and not what we imagine is happening in
> the other people heads ?)
>
> Topology:
>
> S -- RS -/- RP -/- RD -- D
>
> S: source of mcast (say, vlc mcasting a movie)
> RS: router serving S, mcast enabled with sparse
> RP: the RP for the group in question (say group G)
> RD: router serving D, mcast enabled with sparse
> D: the recipient (say, vlc playing the movie)
>
> No other clients involved.
> Now, T0 (that is , time zero) S starts bcasting the movie.
> At T1, 30 seconds after T0, D starts "playing" the data mcasted to group
> G port X.
>
> *Question*
> How much time will lapse until D starts viewing video ?
>
> 1) No time, it will start immediatelly (less than 5 seconds)
> 2) No time, video will not start
> 3) Some 2 1/2 minutes
> 4) None of the above
>
>
> -Carlos
>
>
> Kambiz Agahian @ 12/04/2010 11:39 -0300 dixit:
>> 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
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
>>
>>
>>
>>
>
> --
> Carlos G Mendioroz <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>  LW7 EQI  Argentina
Blogs and organic groups at http://www.ccie.net