RE: "rate-limit" vs. "ip multicast rate-limit"

From: Kenneth Wygand (KWygand@customonline.com)
Date: Tue Jul 27 2004 - 09:47:53 GMT-3


Hey Yasser,
 
From the answers I've received, it appears that "ip multicast rate-limit" is best used to provide a certain amount of traffic to each mroute, so it should be applied on the RPF interface for a particular source/group. It also appears that "rate-limit" is most appropriate to use when you want to match all multicast traffic cumulatively and without regard to allowing a particular traffic rate per source/group. Also, the "rate-limit" command allows you to configure both a "conform-action" and an "exceed-action", which is a little more flexible than just being able to set a "maximum" transmission rate.
 
Someone please correct me if I am wrong, but I think this understanding is pretty accurate.
 
Thanks for all of your responses!
Ken

________________________________

From: Yasser Aly [mailto:yasser.aly@noorgroup.net]
Sent: Tue 7/27/2004 2:48 AM
To: Kenneth Wygand; ccielab@groupstudy.com
Subject: RE: "rate-limit" vs. "ip multicast rate-limit"

Hi Ken,

 Might sound to be not a logical answer, but when the lab asks to limit
multicast traffic go for using " ip multicast rate-limit ". It will be the
answer the proctor is expecting and doing it in a more intelligent way other
than the expected way might cost you the question degree.

Just my opinion.
Yasser

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Kenneth Wygand
Sent: Tuesday, July 27, 2004 4:25 AM
To: ccielab@groupstudy.com
Subject: "rate-limit" vs. "ip multicast rate-limit"

Group,

In order to cap multicast traffic off to a certain level, what's the
difference between using the "rate-limit" command vs. the "ip multicast
rate-limit" command (other than the different attributes that can be
applied). This is really both a lab preparation question as well as a
real-world question.

Thanks!
Ken



This archive was generated by hypermail 2.1.4 : Sun Aug 01 2004 - 10:12:04 GMT-3