All things related to multicast

["Field, Brian" <>]

One other detail and a question.  

The rate-limiters are per DFC line card so if one has N DFC line cards,
sets a limiter to k PPS, and sees loads on all line cards, then
theoretically, the CPU might see kN PPS get punted collectively to the
CPU (for this one type of traffic).

My question is similar to Paul's-- how much CPU load are folks willing
to tolerate on the CPU to handle certain types of software switched
traffic (TTL=1, m-cast related fib-miss, partial short-cut, etc.).
Please ignore if this is consider too off-topic.

Thanks
Brian

-----Original Message-----
From: Paul Chang 
[mailto:]
 
Sent: Tuesday, June 06, 2006 9:21 AM
To: 

Subject: Re: PowerQuest and Mcast causing Cisco65xx SUP 720 CPU
utilization to 90% and higher

Thanks to everyone about the suggestion regarding mcast rate limit 
option at SUP720.

I have set up the followings to protect the control plan but feel this 
still a trial and error situation depending on type of applications the 
switch serves since the rate can varies as <10-1000000>  packets per
second

mls rate-limit multicast ipv4 fib-miss 3000 100
mls rate-limit multicast ipv4 connected 3000 100
mls rate-limit multicast ipv4 ip-options 3000 100
mls rate-limit multicast ipv4 partial 3000 100
mls rate-limit all ttl-failure 2000 10

A quick poll for site running AccessGrid application, what is the 
optimal number you use without sacrifice performance?

Suggestions or comments will be greatly appreciated.

- Paul C.






Stig Venaas wrote:

> Paul Chang wrote:
>
>>
>> Folks,
>>
>> Anyone has similar problem on this?
>>
>> When Powerquest drivemage set TTL=1, the nearest L3 switch (6513 in 
>> this case) has CPU utilization goes beyond 98%. If I adjusted the 
>> TTL=x to match how many hop the RP is, both the nearest L3 switch and

>> RP has high CPU utilzation goes beyond 90%. The switch did not die in

>> this case, but all software relate process were crawling.
>
>
> There was a mail regarding this sent to the list by Brian Field in 
> February. He wrote:
>
> > Re hardware rate limiting of TTL=1 on the sup 720, check out
> > "mls rate-limit all ttl-failure pps burst". Note that this
> > applies to both multicast and unicast traffic.
> >
> > There are a number of other handy multicast specific hardware
> > rate limiters under "mls rate-limit multicast".
>
> This is for 6509 with sup720, but is probably valid for some other 
> systems (at least recent ones, not older supervisors).
>
> You may also see
>
http://www.cisco.com/en/US/partner/products/hw/switches/ps708/products_t
ech_note09186a00804916e0.shtml 
>
>
> Stig
>
>>
>> My work-around is to turn off the "ip PIM sparse-mode" at the vlan 
>> where Mcast source and destinations are taken place (all within on 
>> vlan). This works fine since L2 Cisco 35xx has IGMP-snooping turned 
>> on. Usually, 1 /40 source/destination ratio for computer lab imaging 
>> building is conducted.
>>
>> I have Cisco TAC given me the followings
>>
>>
http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_pap
er0900aecd802ca5d6.shtml 
>>
>>
>> Some data-plane traffic may have to be processed in software as well.

>> This type of traffic is referred to as data-plane "punt" traffic. 
>> Examples of software-processed data-plane packets include:
>>
>> * Packets with IP options
>>
>> * Packets with time-to-live (TTL) field equal to 1
>>
>>
>> which looks to me a design flaw of the control plane.
>>
>> Anyone has a better way to deal with this? Please advice,
>>
>> P a u l C h a n g Network Engineer
>> University of New Mexico
>> Computer & Information Resources & Technology
>> 2701 Campus Boulevard NE, Albuquerque, NM 87131
>> Phone: (505) 277-8257 FAX: (505) 277-8101
>>
>>
>>
>
>