Hohe CPU Auslastung Cisco 3750E

[jpzueri]

Hallo zusammen,

ich habe ein komisches Phenomen auf einem 3750E-Stack.
Die CPU Auslastung schaukelt sich bis zu 70% hoch. Sobald die Loadbalancer
durchgestartet werden, geht auch die CPU-Auslastung runter.

sh proc cpu sort | ex 0.00% 0.00% 0.00%
CPU utilization for five seconds: 19%/13%; one minute: 19%; five minutes: 21%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
76 456014805 614354245 742 0.95% 1.05% 1.29% 0 HLFM address lea
297 38481133 275984751 139 0.31% 0.22% 0.19% 0 HSRP IPv4
190 70317046 282230945 249 0.15% 0.44% 0.37% 0 IP Input
142 27884436 16835160 1656 0.15% 0.05% 0.10% 0 HRPC qos request
5 17452 425573 41 0.00% 0.00% 0.00% 0 Pool Manager
6 0 2 0 0.00% 0.00% 0.00% 0 Timers
7 0 1 0 0.00% 0.00% 0.00% 0 HRPC asic-stats

Im normalen Betrieb liegt die Auslastung bei 6-8%. Hat jemand eine Idee, woher dies kommt. Es kommt eindeutig von den Laodbalancer, aber warum und die Loadbalancer werden nicht von unserer Gruppe administriert.
Leider... Gibt es einen debug Befehl, mit dem ich es rauskriege?
Zur Zeit haben wir die c3750-advipservicesk9-mz.122-46.SE.bin Software in Betrieb.

LG
JP

[sessi]

Hallo

Hohe CPU Auslastungen kommen sehr oft vom Debugging selbst. Stell doch erstmal sicher das kein Debugg eingeschaltet ist.

config# no debugg all

Danach diesen Link checken:

http://www.cisco.com/en/US/tech/tk36...80094820.shtml

Gruss

Sessi

[jpzueri]

Hi sessi,

debugging ist immer ausgeschaltet. Das ist wohl klar

sh deb condition


% No conditions found

Gruss
JP

[sessi]

Was meinst Du zum Link?

[jpzueri]

Hi sessi,

bei uns wird ein Loadbalancer eingesetzt und es gibt keine zwei Wege für den Datenverkehr. Der Stack geht auf ein VSS, dass die beiden RZ koppelt. Es gibt nur ein Transfer-Netz in das zweite RZ.

LG
JP

[daking]

Hola,

1. wie sieht dein setup aus?
2:
hohe CPU Auslastung kommt meist durch Flows die nicht in HW geforwarded werden können. Interessant wäre natürlich zu wissen welcher Task hier die CPU auslastet. Dies kannst du herausfinden indem du im richtigen moment sh proc cpu | exc 0.00% absetzt (bla bla ist klar). Falls dies nur sporadisch passiert kannst du entweder über den embedded ressource manager (ERM - falls dies die HW unterstützt) oder über das process cpu threshold feature (falls von der hw unterstützt - habe gerade meinen 3750 nicht zur hand) erkennen welcher task hier stress macht:

process cpu threshold total rising 60 int 5 falling 20 int 5

==> Nun wird falls dir CPU über 60 prozent ist eine log message mit dem Task ausgegeben.

Generell muss man beim 3750 wissen, dass 16 Queues Richtung CPU existieren. Auf diese Queues werden verschiedene Protokolle aufgeteilt, um sich nicht gegenseitig zu beeinflussen. wäre dumm, wenn "normaler" IP Traffic der nicht in der HW gefowarded wird die gesamte STP Kommunikation unterbrechen würde.. deshalb verschiedene Queues.

Im ersten Step könnte man mal sehen, ob es hier Probleme gibt:

sh platform port-asic stats drop (in der ersten page sollten nun die 16 Queues ausgegeben werden) --> in welcher Queue wird gedropped?

wahrscheinlich 6, da diese für Software Forwarding (punted to cpu) verwendet wird. Welche Pakete hier das Problem sind kann mit debug platform cpu-queues software-fwd.. ausgegeben werden. dieser debug sollte eigentlich safe sein ---> würde jedoch eher mal im wartungsfenster (falls vorhanden und möglich) testen und natürlich wie immer mit logging rate-limit. sonst wird man selber zum debugging problem.


ciao

[jpzueri]

Hola daking,

ich habe jetzt mal den Befehl sh platform port-asic stats drop eingegeben und es wird in keiner Queue gedropped.

3750G:sh platform port-asic stats drop
Port-asic Port Drop Statistics - Summary
========================================
RxQueue 0 Drop Stats: 0
RxQueue 1 Drop Stats: 0
RxQueue 2 Drop Stats: 0
RxQueue 3 Drop Stats: 0

Port 0 TxQueue Drop Stats: 0
Port 1 TxQueue Drop Stats: 0
Port 2 TxQueue Drop Stats: 0
Port 3 TxQueue Drop Stats: 0

Supervisor TxQueue Drop Statistics
Queue 0: 0
Queue 1: 0
Queue 2: 0
Queue 3: 0
Queue 4: 0
Queue 5: 0
Queue 6: 0
Queue 7: 0
Queue 8: 0
Queue 9: 0
Queue 10: 0
Queue 11: 0
Queue 12: 0
Queue 13: 0
Queue 14: 0
Queue 15: 0
3750E:sh platform port-asic stats drop

Port-asic Port Drop Statistics - Summary
========================================
RxQueue Drop Statistics Slice0
RxQueue 0 Drop Stats Slice0: 0
RxQueue 1 Drop Stats Slice0: 0
RxQueue 2 Drop Stats Slice0: 0
RxQueue 3 Drop Stats Slice0: 0
RxQueue Drop Statistics Slice1
RxQueue 0 Drop Stats Slice1: 0
RxQueue 1 Drop Stats Slice1: 0
RxQueue 2 Drop Stats Slice1: 0
RxQueue 3 Drop Stats Slice1: 0

Port 0 TxQueue Drop Stats: 0
Port 1 TxQueue Drop Stats: 0
Port 2 TxQueue Drop Stats: 0
Port 3 TxQueue Drop Stats: 0
Port 4 TxQueue Drop Stats: 0
Port 5 TxQueue Drop Stats: 0
Port 6 TxQueue Drop Stats: 0
Port 7 TxQueue Drop Stats: 0
Port 8 TxQueue Drop Stats: 0
Port 9 TxQueue Drop Stats: 0
Port 10 TxQueue Drop Stats: 0
Port 11 TxQueue Drop Stats: 0
Port 12 TxQueue Drop Stats: 0
Port 13 TxQueue Drop Stats: 0
Port 14 TxQueue Drop Stats: 0
Port 15 TxQueue Drop Stats: 0
Port 16 TxQueue Drop Stats: 0
Port 17 TxQueue Drop Stats: 0
Port 18 TxQueue Drop Stats: 0
Port 19 TxQueue Drop Stats: 0
Port 20 TxQueue Drop Stats: 0
Port 21 TxQueue Drop Stats: 0
Port 22 TxQueue Drop Stats: 0
Port 23 TxQueue Drop Stats: 0
Port 24 TxQueue Drop Stats: 0
Port 25 TxQueue Drop Stats: 0
Port 26 TxQueue Drop Stats: 0
Port 27 TxQueue Drop Stats: 0

Supervisor TxQueue Drop Statistics
Queue 0: 0
Queue 1: 0
Queue 2: 0
Queue 3: 0
Queue 4: 0
Queue 5: 0
Queue 6: 0
Queue 7: 0
Queue 8: 0
Queue 9: 0
Queue 10: 0
Queue 11: 0
Queue 12: 0
Queue 13: 0
Queue 14: 0
Queue 15: 0

Mit dem ERM habe ich noch keine Erfahrung, aber der 3750G und E unterstützt es.
(config)#process cpu threshold type total rising ?
<1-100> .

Wie sieht mein Setup aus:

3750G-Stack ----8 Gig channel----- VSS -----8 gig channel ----- 3750E-Stack

Es werden zur Zeit zwei DMZen in dieser Zone betrieben. Eine alte DMZ auf Layer 2 und die neue DMZ auf Layer 3. Also zwischen den Switchen ein Transfer Netz. Für die Loadbalancer wurde ein eingenes Netz eingerichtet mit HSRP auf beiden Switchen.

Den debug Befehl werde ich jetzt nicht eingeben

Brauchst du noch mehr Info´s?

LG
JP

[jpzueri]

Hi,

#sh sdm pref
The current template is "desktop routing" template.
The selected template optimizes the resources in
the switch to support this level of features for
8 routed interfaces and 1024 VLANs.

number of unicast mac addresses: 3K
number of IPv4 IGMP groups + multicast routes: 1K
number of IPv4 unicast routes: 11K
number of directly-connected IPv4 hosts: 3K
number of indirect IPv4 routes: 8K
number of IPv4 policy based routing aces: 0.5K
number of IPv4/MAC qos aces: 0.5K
number of IPv4/MAC security aces: 1K

#sh mac-address-table | in Total
Total Mac Addresses for this criterion: 183
#sh mac-address-table count | in Available
Total Mac Address Space Available: 2880

#show processes cpu sorted | ex 0.00%
CPU utilization for five seconds: 21%/10%; one minute: 21%; five minutes: 19%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
82 242736461 193102266 1257 1.43% 0.86% 0.85% 0 HLFM address lea
104 77170188 13980157 5519 1.11% 0.96% 0.96% 0 hpm counter proc
117 2692 1228 2192 0.95% 1.00% 0.38% 6 SSH Process
197 17973291 67656814 265 0.63% 0.46% 0.28% 0 IP Input
203 14271692 53933135 264 0.31% 0.16% 0.14% 0 Spanning Tree
147 17460372 1356315 12873 0.15% 0.22% 0.21% 0 HQM Stack Proces
306 10688722 66592999 160 0.15% 0.28% 0.16% 0 HSRP IPv4
68 10536161 2239115 4705 0.15% 0.09% 0.10% 0 Adjust Regions
148 10448564 5418387 1928 0.15% 0.14% 0.15% 0 HRPC qos request
100 52865364 136063265 388 0.15% 0.37% 0.36% 0 hpm main process
139 17549378 254071959 69 0.15% 0.17% 0.12% 0 Hulc LED Process
44 3786667 1361850 2780 0.15% 0.04% 0.04% 0 Compute load avg

#show processes cpu sorted 5sec | ex 0.00%
CPU utilization for five seconds: 23%/11%; one minute: 20%; five minutes: 20%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
82 242740113 193110705 1257 2.07% 1.04% 0.94% 0 HLFM address lea
104 77173720 13980750 5520 1.43% 0.98% 0.96% 0 hpm counter proc
100 52866929 136068828 388 0.95% 0.48% 0.40% 0 hpm main process
191 3325132 2420795 1373 0.63% 0.09% 0.06% 0 CDP Protocol
147 17461148 1356373 12873 0.15% 0.24% 0.22% 0 HQM Stack Proces
44 3786846 1361908 2780 0.15% 0.03% 0.04% 0 Compute load avg
105 3156845 14330178 220 0.15% 0.02% 0.02% 0 HRPC pm-counters
197 17973836 67659925 265 0.15% 0.15% 0.19% 0 IP Input
203 14272076 53934954 264 0.15% 0.13% 0.12% 0 Spanning Tree
139 17549812 254082797 69 0.15% 0.13% 0.12% 0 Hulc LED Process
65 9808865 172679873 56 0.15% 0.13% 0.12% 0 RedEarth Tx Mana

[jpzueri]

Hi und Guten Morgen,

hat noch jemand eine Idee wie man die Ursache der hohen CPU-Last herrausfinden kann?

Gruß
JP

[daking]

Hallo,

habt ihr eigentlich Probleme durch die hohe control plane Last?
Im Moment ist noch immer unklar welcher task hier ressourcen frisst.
die cpu threshold config erzeugt keine probleme und keine zusätzliche last. habe die config schon 100mal in größeren netzen verwendet. Also sollte nun erst mal gecheckt werden welcher task hier last erzeugt.
Welche Features hast du aktiviert? pbr?

Im oben angegeben output sind 10% der 21% gesamt cpu last interrupt basierend. also bis jetzt max 11% cpu und 10% software forwarding - wo sind die 70%?

ciao