jpzueri 10 Geschrieben 21. Juli 2009 Melden Teilen Geschrieben 21. Juli 2009 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 Zitieren Link zu diesem Kommentar
sessi 10 Geschrieben 21. Juli 2009 Melden Teilen Geschrieben 21. Juli 2009 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/tk365/technologies_tech_note09186a0080094820.shtml Gruss Sessi Zitieren Link zu diesem Kommentar
jpzueri 10 Geschrieben 21. Juli 2009 Autor Melden Teilen Geschrieben 21. Juli 2009 Hi sessi, debugging ist immer ausgeschaltet. Das ist wohl klar :) sh deb condition % No conditions found Gruss JP Zitieren Link zu diesem Kommentar
sessi 10 Geschrieben 21. Juli 2009 Melden Teilen Geschrieben 21. Juli 2009 Was meinst Du zum Link? Zitieren Link zu diesem Kommentar
jpzueri 10 Geschrieben 21. Juli 2009 Autor Melden Teilen Geschrieben 21. Juli 2009 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 Zitieren Link zu diesem Kommentar
daking 10 Geschrieben 21. Juli 2009 Melden Teilen Geschrieben 21. Juli 2009 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 Zitieren Link zu diesem Kommentar
jpzueri 10 Geschrieben 22. Juli 2009 Autor Melden Teilen Geschrieben 22. Juli 2009 (bearbeitet) 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 bearbeitet 22. Juli 2009 von jpzueri Zitieren Link zu diesem Kommentar
jpzueri 10 Geschrieben 22. Juli 2009 Autor Melden Teilen Geschrieben 22. Juli 2009 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 Zitieren Link zu diesem Kommentar
jpzueri 10 Geschrieben 23. Juli 2009 Autor Melden Teilen Geschrieben 23. Juli 2009 Hi und Guten Morgen, hat noch jemand eine Idee wie man die Ursache der hohen CPU-Last herrausfinden kann? Gruß JP Zitieren Link zu diesem Kommentar
daking 10 Geschrieben 24. Juli 2009 Melden Teilen Geschrieben 24. Juli 2009 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 Zitieren Link zu diesem Kommentar
ansolut 10 Geschrieben 26. Juli 2009 Melden Teilen Geschrieben 26. Juli 2009 Hi, zum Test: löse mal den Stack auf und verbinde diesen mit einem Trunking. Ich habe es im 3750er System schon oft erlebt das aus unerklärlichen Gründen die CPU Last aufgrund des Stackings nach oben ging. Falls dies der Fall ist wirds übel. Stackingkabel , Stacking Port...etc... Du sagst dein Loadbalancer spielt eine Rolle? Kann es sein das du Zeitweise evtl. eine Netzwerkloop verursachst? Eine Konfig vom Stack wäre interessant. Zitieren Link zu diesem Kommentar
jpzueri 10 Geschrieben 27. Juli 2009 Autor Melden Teilen Geschrieben 27. Juli 2009 Hallo daking, die CPU Last steigt ständig an, ist jetzt zur Zeit bei 30%. Welcher Task die Auslastung erzeugt, kann ich dir nicht sagen. Zitieren Link zu diesem Kommentar
jpzueri 10 Geschrieben 29. Juli 2009 Autor Melden Teilen Geschrieben 29. Juli 2009 Hi ansolut, ein Netzwerkloop kann ich mir nicht vorstellen. Dann hätten wir ganz andere Probleme. Die Config läuft seit dem September 2007. Ich habe echt keine Lösung für dieses Problem. Aber zum Glück sind wit noch im GRÜNEN Bereich. Gruß JP Zitieren Link zu diesem Kommentar
daking 10 Geschrieben 30. Juli 2009 Melden Teilen Geschrieben 30. Juli 2009 Hi, scheint wohl eher interrupt traffic / sw switched traffic zu sein. welchen Traffic teilt der Loadbalancer auf? Was ist die Aufgabe? Folgende Pakete werden via SW Pfad geforwarded: - Pakete mit gesetzten IP Optionen - Pakete mit abgelaufener TTL - ARP - Software ACL's - Pakete die an die CPU gesendet werden müssen (:-) (show controller CPU) ==> ist hier igmp/mcast im einsatz? ==> pbr? ==> fehlende ressourcen (show platform tcam utilization) ciao Zitieren Link zu diesem Kommentar
jpzueri 10 Geschrieben 4. August 2009 Autor Melden Teilen Geschrieben 4. August 2009 Hi daking, igmp/mcast ist nicht im Einsatz. pbr - Policy Based Routing nein, aber wir haben VRF show platform tcam utilization CAM Utilization for ASIC# 0 Max Used Masks/Values Masks/values Unicast mac addresses: 400/3200 90/620 IPv4 IGMP groups + multicast routes: 144/1152 6/26 IPv4 unicast directly-connected routes: 400/3200 90/620 IPv4 unicast indirectly-connected routes: 1040/8320 22/109 IPv4 policy based routing aces: 384/512 1/2 IPv4 qos aces: 768/768 388/388 IPv4 security aces: 1024/1024 27/27 Note: Allocation of TCAM entries per feature uses a complex algorithm. The above information is meant to provide an abstract view of the current TCAM utilization show controller CPU ASIC Rxbiterr Rxunder Fwdctfix Txbuflos Rxbufloc Rxbufdrain ------------------------------------------------------------------------- ASIC0 0 0 0 0 0 0 ASIC1 0 0 0 0 0 0 ASIC2 0 0 0 0 0 0 ASIC3 0 0 0 0 0 0 ASIC4 0 0 0 0 0 0 ASIC5 0 0 0 0 0 0 ASIC6 0 0 0 0 0 0 cpu-queue-frames retrieved dropped invalid hol-block stray ----------------- ---------- ---------- ---------- ---------- ---------- rpc 279227604 0 0 0 0 stp 257580916 0 0 0 0 ipc 26116003 0 0 0 0 routing protocol 811688788 0 0 0 0 L2 protocol 19301345 0 0 0 0 remote console 0 0 0 0 0 sw forwarding 3800158745 0 0 0 0 host 5539150 0 0 0 0 broadcast 404564382 0 0 0 0 cbt-to-spt 0 0 0 0 0 igmp snooping 406175019 0 0 0 0 icmp 692939 0 0 0 0 logging 0 0 0 0 0 rpf-fail 0 0 0 0 0 dstats 0 0 0 0 0 cpu heartbeat 443184417 0 0 0 0 Wir stochern immer noch im dunkeln, aber wir haben in einem Vlan Trafic gesehen, der der CPU-Auslastung gleicht. Aber die Serverjungs können oder wollen nicht helfen. LG JP Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.