I will try to persuade the management to remove the NBAR at least as a process of elimination.
What still bothers me is that the MSFC that serves as the HSRP standby also shows high CPU at the same time even though its input rates on its interfaces are much lower.
Anchi
-----Original Message-----
From: David Sinn [mailto:dsinn@microsoft.com]
Sent: Wednesday, May 22, 2002 4:27 PM
To: Zhang, Anchi
Subject: RE: [nsp] what uses all the cpu cycles
That is probably it then. It takes the MSFC to delve deep enough in to
the packet to make NBAR usable.
David
-----Original Message-----
From: Zhang, Anchi [mailto:AZhang@reliant.com]
Sent: Wednesday, May 22, 2002 2:19 PM
To: David Sinn
Subject: RE: [nsp] what uses all the cpu cycles
But the heavy traffic is most inbound on other interfaces with NBAR in:
Vlan120 is up, line protocol is up
5 minute input rate 59243000 bits/sec, 5215 packets/sec
5 minute output rate 45000 bits/sec, 27 packets/sec
Vlan142 is up, line protocol is up
5 minute input rate 1091000 bits/sec, 783 packets/sec
5 minute output rate 3000 bits/sec, 3 packets/sec
Vlan120 is up, line protocol is up
5 minute input rate 59243000 bits/sec, 5215 packets/sec
5 minute output rate 45000 bits/sec, 27 packets/sec
Vlan142 is up, line protocol is up
5 minute input rate 1091000 bits/sec, 783 packets/sec
5 minute output rate 3000 bits/sec, 3 packets/sec
Vlan143 is up, line protocol is up
5 minute input rate 24385000 bits/sec, 3474 packets/sec
5 minute output rate 93000 bits/sec, 124 packets/sec
Vlan182 is up, line protocol is up
5 minute input rate 4944000 bits/sec, 613 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
Vlan196 is up, line protocol is up
5 minute input rate 5841000 bits/sec, 927 packets/sec
5 minute output rate 4632000 bits/sec, 815 packets/sec
Vlan197 is up, line protocol is up
5 minute input rate 5376000 bits/sec, 945 packets/sec
5 minute output rate 5714000 bits/sec, 890 packets/sec
Vlan250 is up, line protocol is up
5 minute input rate 12208000 bits/sec, 1835 packets/sec
5 minute output rate 3000 bits/sec, 1 packets/sec
-----Original Message-----
From: David Sinn [mailto:dsinn@microsoft.com]
Sent: Wednesday, May 22, 2002 4:13 PM
To: Zhang, Anchi
Subject: RE: [nsp] what uses all the cpu cycles
NBAR is MSFC processed, but you have a inbound policy and on VLAN 10 you
are switching packets out. As such I wouldn't think that it is the
cause.
I would suggest contact Cisco to see if there is a bug. I've had one of
my systems do the same thing and they are still trying to track down
what the cause it.
David
-----Original Message-----
From: Zhang, Anchi [mailto:AZhang@reliant.com]
Sent: Wednesday, May 22, 2002 1:55 PM
To: David Sinn
Subject: RE: [nsp] what uses all the cpu cycles
They are sup2s:
REP_Dist1_L2> (enable) sho mod 1-2
Mod Slot Ports Module-Type Model Sub Status
--- ---- ----- ------------------------- ------------------- ---
--------
1 1 2 1000BaseX Supervisor WS-X6K-SUP2-2GE yes ok
2 2 2 1000BaseX Supervisor WS-X6K-SUP2-2GE yes standby
Mod Module-Name Serial-Num
--- ------------------- -----------
1 SAD05040AY0
2 SAD05040X3Z
Mod MAC-Address(es) Hw Fw Sw
--- -------------------------------------- ------ ----------
-----------------
1 00-01-c9-da-05-96 to 00-01-c9-da-05-97 2.2 6.1(3) 6.2(2)
00-01-c9-da-05-94 to 00-01-c9-da-05-95
00-d0-02-af-cc-00 to 00-d0-02-af-cf-ff
2 00-01-c9-da-04-92 to 00-01-c9-da-04-93 2.2 6.1(3) 6.2(2)
00-01-c9-da-04-90 to 00-01-c9-da-04-91
Mod Sub-Type Sub-Model Sub-Serial Sub-Hw
--- ----------------------- ------------------- ----------- ------
1 L3 Switching Engine II WS-F6K-PFC2 SAD05040YW4 1.3
2 L3 Switching Engine II WS-F6K-PFC2 SAD050310LB 1.3
I do have NBAR on each interface. Maybe that is it?
class-map match-any http-hacks
match protocol http url "*.ida*"
match protocol http url "*cmd.exe*"
match protocol http url "*root.exe*"
match protocol http url "*readme.eml*"
match protocol http url "*sample.eml"
match protocol http url "*desktop.eml"
match protocol http url "*readme.exe"
match protocol http url "*Readme.eml*"
match protocol http url "*Readme.exe*"
match protocol http url "*PUTA!!.SCR*"
match protocol http url "*PUTA!!.EML*"
match protocol http url "*PUTA!!.eml*"
match protocol http url "*PUTA!!.scr*"
match protocol http url "*puta!!.scr*"
match protocol http url "*puta!!.eml*"
!
policy-map mark-inbound-http-hacks
class http-hacks
set ip dscp 1
!
interface Vlan10
ip address 10.51.10.254 255.255.255.0
ip helper-address 10.51.100.100
ip helper-address 10.51.101.100
no ip redirects
ip pim sparse-mode
carrier-delay msec 0
ipx network 5600029
service-policy input mark-inbound-http-hacks
-----Original Message-----
From: David Sinn [mailto:dsinn@microsoft.com]
Sent: Wednesday, May 22, 2002 3:45 PM
To: Zhang, Anchi
Subject: RE: [nsp] what uses all the cpu cycles
Your .txt files definitely back up that your MSFC is switching a bunch
of packets, and more troublesome it is switching it in FAST/Cache'd
mode. This means that the PFC SHOULD have been able to do it.
Is this a Sup2, or Sup1A? Do you have ACL's on any of the interfaces,
and if so are they long (hundreds of lines)?
If you overflow the PFC's ACL space, the PFC will punt packets to the
MSFC for switching since it can't make the ACL decision.
If you are on a Spu2, I would suggest running a "sho ip cef sum" on the
MSFC and a "sho mls cef" on the Sup and verify that they both have the
same number of prefixes (or close if you have 'normal' routing changes
in your network.
If this is a Sup1A, then you may have too many flows, and you can "fix"
the problem by changing your flow cache ager to a lower value. It
doesn't actually prevent the problem, it just gives you more head room.
David
-----Original Message-----
From: Zhang, Anchi [mailto:AZhang@reliant.com]
Sent: Wednesday, May 22, 2002 1:32 PM
To: David Sinn
Subject: RE: [nsp] what uses all the cpu cycles
Many thanks. -anchi
-----Original Message-----
From: David Sinn [mailto:dsinn@microsoft.com]
Sent: Wednesday, May 22, 2002 3:30 PM
To: Zhang, Anchi; cisco-nsp@puck.nether.net
Subject: RE: [nsp] what uses all the cpu cycles
Your MSFC is switching a bunch of packets (64%), and then you have
somewhere around 30% doing process level things. The output of the
"show proc cpu" will tell you which set of processes are causing that
30% load (which sounds a little high).
I'd be happy to take a look at what you have captured so far if you
want.
David
-----Original Message-----
From: Zhang, Anchi [mailto:AZhang@reliant.com]
Sent: Wednesday, May 22, 2002 1:12 PM
To: cisco-nsp@puck.nether.net
Subject: [nsp] what uses all the cpu cycles
Greetings,
Several times a day two of my MSFC2s/6509s show high CPU usage:
CPU utilization for five seconds: 91%/64%; one minute: 89%; five
minutes: 86%
One MSFC2 serves mostly as an HSRP standby for the other.
I captured the output of the commands below during low CPU and during
high CPU but was unable to figure out what contributed to the high CPU.
show processes cpu
show interfaces
show interfaces switching
show interfaces stat
show align
show version
show log
If someone on the list is experienced in analyzing the CPU usage and is
willing to help, I can send the stats to him/her.
Anchi
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:13:45 EDT