Skip to Content.
Sympa Menu

wg-multicast - Re: PowerQuest and Mcast causing Cisco65xx SUP 720 CPU utilization to 90% and higher

Subject: All things related to multicast

List archive

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


Chronological Thread 
  • From: Stig Venaas <>
  • To: Paul Chang <>
  • Cc:
  • Subject: Re: PowerQuest and Mcast causing Cisco65xx SUP 720 CPU utilization to 90% and higher
  • Date: Tue, 06 Jun 2006 10:55:03 +0200

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_tech_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_paper0900aecd802ca5d6.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








Archive powered by MHonArc 2.6.16.

Top of Page