RE: Multicast Data

So probably you should sign a contract with us to make it almost zero. As a
proposal we will reset things back to default.

--------------------------
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.comjavascript:SetCmd(cmdSend);
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 6:47 PM
To: Kambiz Agahian
Cc: Tharindu Rukshan Bamunuarachchi; ccielab_at_groupstudy.com
Subject: Re: Multicast Data

Ok, FTR my answer would be 3, inline with all the posts I made.

Take care,
-Carlos

Kambiz Agahian @ 12/04/2010 22:37 -0300 dixit:
> No.
> I guess Mr. Williams in chapter 7 and 11 of his master piece has said
enough
> on this. So no more characters necessary. You can find your answer in my
> previous post or his book :)
>
> 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 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.comjavascript:SetCmd(cmdSend);
> 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 6:13 PM
> To: Kambiz Agahian
> Cc: Tharindu Rukshan Bamunuarachchi; ccielab_at_groupstudy.com
> Subject: 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
>
> _______________________________________________________________________
> 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