تسعى مجموعة الوثائق لهذا المنتج جاهدة لاستخدام لغة خالية من التحيز. لأغراض مجموعة الوثائق هذه، يتم تعريف "خالية من التحيز" على أنها لغة لا تعني التمييز على أساس العمر، والإعاقة، والجنس، والهوية العرقية، والهوية الإثنية، والتوجه الجنسي، والحالة الاجتماعية والاقتصادية، والتمييز متعدد الجوانب. قد تكون الاستثناءات موجودة في الوثائق بسبب اللغة التي يتم تشفيرها بشكل ثابت في واجهات المستخدم الخاصة ببرنامج المنتج، أو اللغة المستخدمة بناءً على وثائق RFP، أو اللغة التي يستخدمها منتج الجهة الخارجية المُشار إليه. تعرّف على المزيد حول كيفية استخدام Cisco للغة الشاملة.
ترجمت Cisco هذا المستند باستخدام مجموعة من التقنيات الآلية والبشرية لتقديم محتوى دعم للمستخدمين في جميع أنحاء العالم بلغتهم الخاصة. يُرجى ملاحظة أن أفضل ترجمة آلية لن تكون دقيقة كما هو الحال مع الترجمة الاحترافية التي يقدمها مترجم محترف. تخلي Cisco Systems مسئوليتها عن دقة هذه الترجمات وتُوصي بالرجوع دائمًا إلى المستند الإنجليزي الأصلي (الرابط متوفر).
يصف هذا المستند كيفية مراقبة إستخدام وحدة المعالجة المركزية (CPU) على وحدات التحكم في الشبكة المحلية (LAN) اللاسلكية Catalyst 9800، بالإضافة إلى تغطية العديد من توصيات التكوين.
قبل أستكشاف أخطاء تحميل وحدة المعالجة المركزية (CPU) وإصلاحها، يلزمك فهم المبادئ الأساسية لكيفية إستخدام وحدات المعالجة المركزية (CPU) في وحدات التحكم في الشبكة المحلية (LAN) اللاسلكية Catalyst 9800 وبعض التفاصيل حول بنية البرنامج.
بشكل عام، يحدد مستند أفضل الممارسات Catalyst 9800 مجموعة من إعدادات التكوين الجيدة التي يمكن أن تمنع المشاكل على مستوى التطبيق. على سبيل المثال، إستخدام تصفية الموقع ل mDNS، أو ضمان إستبعاد العميل يتم تمكينه دائما. ينصح بتطبيق تلك التوصيات مع الموضوعات الموضحة هنا.
تم تصميم وحدات التحكم Catalyst 9800 كنظام أساسي مرن يستهدف أحمال شبكة مختلفة، ويركز على التطوير الأفقي. تم تسمية التطوير الداخلي ب eWLC مع e للمرونة، للإشارة إلى أن بنية البرنامج نفسها، ستكون قادرة على التشغيل من نظام صغير مضمن لوحدة المعالجة المركزية (CPU) إلى العديد من أجهزة وحدة المعالجة المركزية (CPU)/الأجهزة الأساسية واسعة النطاق.
ولكل عنصر من عناصر عنصر التحكم في الشبكة المحلية اللاسلكية جانبان متميزان:
في طريقة عرض مبسطة، تحتوي وحدة التحكم على آليات اتصال بين مستوى التحكم ومستوى البيانات، والنسخ، وإرسال حركة مرور البيانات من الشبكة إلى مستوى التحكم، والحقن، تدفع الإطارات من مستوى التحكم إلى الشبكة.
كجزء من تحقيق عالي محتمل لاستكشاف أخطاء وحدة المعالجة المركزية (CPU) وإصلاحها، تحتاج إلى مراقبة آلية الضرب، وتقييم حركة المرور التي تصل إلى مستوى التحكم، وقد تؤدي إلى حمل مرتفع.
بالنسبة لوحدة التحكم Catalyst 9800، يتم تشغيل هذا كجزء من معالج الحزمة (CPP) من Cisco، وهو إطار عمل برنامج لتطوير محركات إعادة توجيه الحزمة، المستخدمة عبر منتجات وتقنيات متعددة.
تتيح البنية مجموعة ميزات مشتركة، عبر عمليات تنفيذ أجهزة أو برامج مختلفة. على سبيل المثال، السماح بمزايا مماثلة ل 9800CL مقابل 9800-40، على مستويات إنتاج مختلفة.
تقوم عنصر التحكم في الشبكة المحلية اللاسلكية (WLC) بموازنة الأحمال عبر وحدات المعالجة المركزية (CPU) أثناء عملية الانضمام إلى نقطة الوصول (CAPWAP AP)، حيث يكون مميز المفاتيح هو اسم علامة موقع نقطة الوصول. تتمثل الفكرة في أن كل نقطة وصول تمثل حمل وحدة معالجة مركزية معينة تمت إضافته، يأتي من نشاط العميل الخاص بها، ونقطة الوصول نفسها. هناك العديد من الآليات اللازمة لتحقيق هذا التوازن:
على سبيل المثال، إذا كان لديك من 9800 إلى 40، يشغل مكتبا رئيسيا واحدا، بالإضافة إلى 5 مكاتب فرعية، وعدد نقاط وصول (AP) مختلف، فقد يبدو التكوين كما يلي:
wireless tag site office-main
load 120
wireless tag site branch-1
load 10
wireless tag site branch-2
load 12
wireless tag site branch-3
load 45
wireless tag site branch-4
load 80
wireless tag site branch-5
load 5
في هذا السيناريو، لا تريد أن تكون علامة المكتب الرئيسية على نفس WNCD مثل Branch-3 و Branch-4، هناك إجمالي 6 علامات مواقع، وفي النظام الأساسي 5 WNCDs، لذلك قد يكون هناك فرصة لأن تظهر أعلى علامات المواقع المحملة على نفس وحدة المعالجة المركزية. باستخدام الأمر load، يمكنك إنشاء مخطط موازنة حمل نقطة الوصول (AP) متوقع.
إن الحمل هو حجم متوقع.ليس من الضروري أن يتطابق مع عدد نقاط الوصول تماما، ولكنه عادة ما يتم ضبطه على نقاط الوصول المتوقعة التي يمكن أن تنضم.
بالنسبة للأنظمة الأساسية للأجهزة، تم إصلاح عدد شاشات WNCD: يحتوي 9800-40 على 5 و 9800-80 على 8. وبالنسبة ل 9800CL (افتراضي)، يعتمد عدد شاشات WNCD على قالب الجهاز الظاهري المستخدم أثناء النشر الأولي.
كقاعدة عامة، إذا كنت تريد معرفة عدد شاشات WNCD التي تعمل في النظام، فيمكنك إستخدام هذا الأمر عبر جميع أنواع وحدات التحكم:
9800-40#show processes cpu platform sorted | count wncd
Number of lines which match regexp = 5
في حالة 9800-CL على وجه التحديد، يمكنك إستخدام الأمر show platform software system all
لجمع التفاصيل على النظام الظاهري:
9800cl-1#show platform software system all
Controller Details:
=================
VM Template: small
Throughput Profile: low
AP Scale: 1000
Client Scale: 10000
WNCD instances: 1
يتم تطبيق تعيين نقطة الوصول إلى WNCD أثناء عملية ربط AP CAPWAP، لذلك لا يتوقع أن يتغير أثناء العمليات، بغض النظر عن طريقة الموازنة، إلا إذا كان هناك حدث إعادة تعيين CAPWAP على مستوى الشبكة حيث تقوم جميع نقاط الوصول بفصل وإعادة الانضمام.
يمكن أن يوفر أمرshow wireless loadbalance tag affinity
CLI طريقة سهلة لرؤية الحالة الحالية لتوازن حمل نقطة الوصول عبر جميع مثيلات WNCD:
98001#show wireless loadbalance tag affinity
Tag Tag type No of AP's Joined Load Config Wncd Instance
---------------------------------------------------------------------------------------------
Branch-tag SITE TAG 10 0 0
Main-tag SITE TAG 200 0 1
default-site-tag SITE TAG 1 NA 2
إذا كنت ترغب في ربط توزيع نقطة الوصول مع عدد العملاء وحمل وحدة المعالجة المركزية، فإن أسهل طريقة هي إستخدام أداة دعم WCAE وتحميلshow tech wireless
ما يتم أخذه أثناء أوقات العمل. تلخص الأداة عدد عملاء WNCD، المأخوذ من كل نقطة وصول مقترنة بها.
مثال على وحدة تحكم متوازنة بشكل صحيح، أثناء الاستخدام المنخفض وعدد العملاء:
مثال آخر، لوحدة تحكم أكثر تحميل، يظهر إستخدام وحدة المعالجة المركزية (CPU) العادي:
باختصار، يمكنك تلخيص الخيارات المختلفة في:
هذا 500 ap عتبة، s أن يعين عندما يكون هو فعال أن يطبق الحمل موازنة آلية، بما أن هو يجمع APs في قالب من 100 وحدة افتراضيا.
هناك سيناريوهات تريد فيها إجراء موازنة AP أكثر تقدما، ومن المفضل أن يكون لديك تحكم دقيق في كيفية توزيع نقاط الوصول عبر وحدات المعالجة المركزية. على سبيل المثال، سيناريوهات عالية الكثافة حيث يكون قياس الحمل الأساسي هو عدد العملاء مقابل التركيز المحض على عدد نقاط الوصول الموجودة في النظام.
ومن بين الأمثلة الجيدة لهذا الموقف تلك الأحداث الكبرى: يمكن أن يستضيف المبنى آلاف العملاء، وأكثر من عدة مئات من نقاط الوصول، وستحتاج إلى تقسيم الحمل عبر أكبر عدد ممكن من وحدات المعالجة المركزية (CPU) ولكن مع تحسين التجوال في نفس الوقت. لذا، لا يمكنك التجوال عبر WNCD ما لم تكن هناك حاجة إليه. أنت تريد منع حالات الملح والفلفل حيث يتم مزج نقاط وصول متعددة في WNCDs/علامات مواقع مختلفة في نفس المكان الفعلي.
للمساعدة في الضبط الدقيق، وتوفير مرئيات للتوزيع، يمكنك إستخدام أداة WCAE، والاستفادة من ميزة عرض AP RF:
وهذا يتيح لك مشاهدة توزيع AP/WNCD، تمView Type
تعيينه على WNCD فقط. هنا، كل لون يمثل WNCD/CPU. كما يمكنك تعيين عامل تصفية RSSI على -85، لتجنب إتصالات الإشارات المنخفضة، التي تتم تصفيتها أيضا بواسطة خوارزمية RRM في وحدة التحكم.
في المثال السابق، المتوافق مع Cisco EMEA 24، يمكنك أن ترى أن معظم نقاط الوصول المتجاورة مجمعة بشكل جيد عبر نفس شاشة WNCD، مع تداخل محدود جدا.
علامات الموقع المخصصة لنفس WNCD، احصل على نفس اللون.
من المهم تذكر مفهوم بنية Cisco IOS XE وتذكر أن هناك طريقتين رئيسيتين لاستخدام وحدة المعالجة المركزية. أحدها يأتي من دعم Cisco IOS التاريخي، والمصدر الرئيسي، مع نظرة شاملة على وحدة المعالجة المركزية (CPU) عبر جميع العمليات ومراكز المعالجة.
بصفة عامة، يمكنك إستخدام الأمرshow processes cpu platform sorted
لجمع معلومات تفصيلية لجميع العمليات عبر برنامج Cisco IOS XE:
9800cl-1#show processes cpu platform sorted
CPU utilization for five seconds: 8%, one minute: 14%, five minutes: 11%
Core 0: CPU utilization for five seconds: 6%, one minute: 11%, five minutes: 5%
Core 1: CPU utilization for five seconds: 2%, one minute: 8%, five minutes: 5%
Core 2: CPU utilization for five seconds: 4%, one minute: 12%, five minutes: 12%
Core 3: CPU utilization for five seconds: 19%, one minute: 23%, five minutes: 24%
Pid PPid 5Sec 1Min 5Min Status Size Name
--------------------------------------------------------------------------------
19953 19514 44% 44% 44% S 190880 ucode_pkt_PPE0
28947 8857 3% 10% 4% S 1268696 linux_iosd-imag
19503 19034 3% 3% 3% S 247332 fman_fp_image
30839 2 0% 0% 0% I 0 kworker/0:0
30330 30319 0% 0% 0% S 5660 nginx
30329 30319 0% 1% 0% S 20136 nginx
30319 30224 0% 0% 0% S 12480 nginx
30263 1 0% 0% 0% S 4024 rotee
30224 8413 0% 0% 0% S 4600 pman
30106 2 0% 0% 0% I 0 kworker/u11:0
30002 2 0% 0% 0% S 0 SarIosdMond
29918 29917 0% 0% 0% S 1648 inet_gethost
هناك العديد من النقاط الرئيسية التي ينبغي تسليط الضوء عليها هنا:
show tech wireless
إمكانية توليد حمل ذروة على عمليات IOS و SMAND و PUBD، حيث يتم تجميع إخراج نص كبير جدا، مع تنفيذ مئات أوامر CLI. هذه ليست مشكلة، وينخفض الحمل بعد اكتمال الإخراج.Pid PPid 5Sec 1Min 5Min Status Size Name
--------------------------------------------------------------------------------
19371 19355 62% 83% 20% R 128120 smand
27624 27617 53% 59% 59% S 1120656 pubd
4192 4123 11% 5% 4% S 1485604 linux_iosd-imag
Pid PPid 5Sec 1Min 5Min Status Size Name
--------------------------------------------------------------------------------
21094 21086 25% 25% 25% S 978116 wncd_0
21757 21743 21% 20% 20% R 1146384 wncd_4
22480 22465 18% 18% 18% S 1152496 wncd_7
22015 21998 18% 17% 17% S 840720 wncd_5
21209 21201 16% 18% 18% S 779292 wncd_1
21528 21520 14% 15% 14% S 926528 wncd_3
show processes cpu sorted
. وهذا يتوافق مع النشاط في جزء عملية linux_iosd-imag من قائمة Cisco IOS XE.9800cl-1#show processes cpu sorted
CPU utilization for five seconds: 2%/0%; one minute: 3%; five minutes: 3%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
215 81 88 920 1.51% 0.12% 0.02% 1 SSH Process
673 164441 7262624 22 0.07% 0.00% 0.00% 0 SBC main process
137 2264141 225095413 10 0.07% 0.04% 0.05% 0 L2 LISP Punt Pro
133 534184 21515771 24 0.07% 0.04% 0.04% 0 IOSXE-RP Punt Se
474 1184139 56733445 20 0.07% 0.03% 0.00% 0 MMA DB TIMER
5 0 1 0 0.00% 0.00% 0.00% 0 CTS SGACL db cor
6 0 1 0 0.00% 0.00% 0.00% 0 Retransmission o
2 198433 726367 273 0.00% 0.00% 0.00% 0 Load Meter
7 0 1 0 0.00% 0.00% 0.00% 0 IPC ISSU Dispatc
10 3254791 586076 5553 0.00% 0.11% 0.07% 0 Check heaps
4 57 15 3800 0.00% 0.00% 0.00% 0 RF Slave Main Th
8 0 1 0 0.00% 0.00% 0.00% 0 EDDRI_MAIN
هذا متاح فيMonitoring/System/CPU Utilization
علامة التبويب.
قد تختلف قائمة العمليات الدقيقة حسب نموذج وحدة التحكم، وإصدار Cisco IOS XE. هذه قائمة ببعض العمليات الرئيسية، وليس الغرض منها تغطية كل الإدخالات الممكنة.
اسم العملية |
شو بيساوي |
التقييم |
wncd_x |
يعالج معظم العمليات اللاسلكية. طبقا لنموذج 9800، يمكنك أن يكون لديك بين 1 إلى 8 تواجدات. |
يمكنك أن ترى ذروة الاستخدام العالي خلال ساعات العمل. قم بالإبلاغ إذا كان الاستخدام متعلقا بنسبة 95٪ أو أكثر لعدة دقائق. |
linux_iosd-imag |
عملية IOS |
من المتوقع رؤية معدل إستخدام مرتفع في حالة تجميع إخراج واجهة سطر الأوامر (show tech). يمكن أن تؤدي عمليات SNMP الكبيرة أو المتكررة إلى إستخدام وحدة معالجة مركزية (CPU) عالية. |
نغنكس |
خادم ويب |
ويمكن لهذه العملية إظهار القمم، ولا يمكن الإبلاغ عنها إلا على الحمل المرتفع المستمر. |
ucode_pkt_ppe0 |
مستوى البيانات في 9800CL/9800L |
أستخدم الأمر |
عزمان |
مدير مجموعة الشرائح للواجهات |
يمكن أن تشير وحدة المعالجة المركزية (CPU) المرتفعة المستمرة هنا إلى مشكلة في الأجهزة أو مشكلة محتملة في برامج kernel. ويمكن الإبلاغ عن ذلك. |
DBM |
مدير قاعدة البيانات |
يمكن الإبلاغ عن وحدة معالجة مركزية عالية بشكل دائم هنا. |
ODM_X |
تقوم "إدارة بيانات العملية" بمعالجة قاعدة البيانات المدمجة عبر العمليات. |
متوقع وجود وحدة معالجة مركزية (CPU) عالية في الأنظمة المحملة. |
جروا |
يعالج الوظائف المخادعة |
يمكن الإبلاغ عن وحدة معالجة مركزية عالية بشكل دائم هنا. |
سمند |
يهتم Shell Manager بتحليل واجهة سطر الأوامر والتفاعل عبر العمليات المختلفة. |
متوقع وجود وحدة معالجة مركزية (CPU) عالية أثناء معالجة إخراج واجهة سطر الأوامر (CLI) كبير الحجم. ويمكن الإبلاغ عن إستمرار إرتفاع مستوى وحدة المعالجة المركزية (CPU) في غياب الحمل. |
EMD |
برنامج Shell Manager. يهتم بتحليل واجهة سطر الأوامر، والتفاعل عبر العمليات المختلفة. |
متوقع وجود وحدة معالجة مركزية (CPU) عالية أثناء معالجة إخراج واجهة سطر الأوامر (CLI) كبير الحجم. ويمكن الإبلاغ عن إرتفاع مستمر في وحدة المعالجة المركزية (CPU) عند عدم وجود حمل. |
حانة |
جزء من معالجة القياس عن بعد |
متوقع مستوى عال من وحدة المعالجة المركزية (CPU) لاشتراكات بيانات تتبع الاستخدام الكبيرة. ويمكن الإبلاغ عن إرتفاع مستمر في وحدة المعالجة المركزية (CPU) عند عدم وجود حمل. |
تحتوي وحدات التحكم في الشبكة المحلية (LAN) اللاسلكية Catalyst 9800 على آليات حماية شاملة حول نشاط الشبكة أو العميل اللاسلكي لمنع زيادة وحدة المعالجة المركزية (CPU) بسبب السيناريوهات العرضية أو المتعمدة. هناك العديد من الميزات الرئيسية المصممة خصيصا لمساعدتك على إحتواء الأجهزة التي تمثل مشكلة:
يتم تمكين هذا بشكل افتراضي، وهو جزء من سياسات الحماية اللاسلكية، ويمكن تمكينه أو تعطيله لكل توصيف نهج. ويمكن أن يؤدي ذلك إلى اكتشاف العديد من مشاكل السلوك المختلفة وإزالة العميل من الشبكة وتعيينه في قائمة إستثناء مؤقتة. في حين أن العميل في هذه الحالة المستبعدة، فإن نقاط الوصول لا تتحدث إليهم، مما يمنع أي إجراءات أخرى.
بعد مرور مؤقت الاستثناء (60 ثانية بشكل افتراضي)، يتم السماح للعميل بالاقتران مرة أخرى.
هناك العديد من المشغلات لاستبعاد العملاء:
يحمي إستبعاد العميل وحدة التحكم لديك وبنية AP و AAA الأساسية (RADIUS) من العديد من أنواع النشاط العالي التي قد تؤدي إلى وحدة معالجة مركزية (CPU) عالية. بشكل عام، لا ينصح بتعطيل أي من طرق الاستثناء، ما لم تكن هناك حاجة لتمرين أستكشاف الأخطاء وإصلاحها أو متطلبات التوافق.
تعمل الإعدادات الافتراضية لكل الحالات تقريبا، وفي بعض السيناريوهات الاستثنائية فقط، تكون هناك حاجة لزيادة وقت الاستبعاد، أو تعطيل مشغل معين. على سبيل المثال، يلزم تعطيل مشغل فشل الاقتران لدى بعض العملاء القدامى أو المتخصصين (IOT/Medical)، نظرا لوجود عيوب من جانب العميل لا يمكن تصحيحها بسهولة
يمكنك تخصيص المشغلات في واجهة المستخدم: سياسات التكوين/الحماية اللاسلكية/إستثناء العملاء:
تم تصميم مشغل إستثناء ARP ليتم تمكينه بشكل دائم على المستوى العام، ولكن يمكن تخصيصه على كل ملف تعريف نهج. يمكنك التحقق من الحالة باستخدام الأمرsh wireless profile policy all
بحث عن هذا الإخراج المحدد:
ARP Activity Limit
Exclusion : ENABLED
PPS : 100
Burst Interval : 5
هذا آلية متقدمة في مستوى البيانات، لضمان أن حركة المرور المرسلة إلى مستوى التحكم لا تتجاوز مجموعة محددة مسبقا من الحدود. وتسمى الميزة "شرطيين الحزم"، وفي جميع السيناريوهات تقريبا، ليس من الضروري لمسهم، وحتى في ذلك الحين، يجب القيام فقط أثناء العمل معا مع دعم Cisco.
فائدة هذه الحماية هي أنها توفر نظرة متعمقة جدا على ما يحدث في الشبكة، وإذا كان هناك أي نشاط محدد له معدل مرتفع أو حزم عالية بشكل غير متوقع في الثانية.
يتم الكشف عن هذا الإجراء فقط من خلال واجهة سطر الأوامر (CLI)، نظرا لأنها عادة جزء من الوظائف المتقدمة التي نادرا ما تكون هناك حاجة لتعديلها.
للحصول على عرض لكافة نهج العقوبة:
9800-l#show platform software punt-policer
Per Punt-Cause Policer Configuration and Packet Counters
Punt Config Rate(pps) Conform Packets Dropped Packets Config Burst(pkts) Config Alert
Cause Description Normal High Normal High Normal High Normal High Normal High
-------------------------------------------------------------------------------------------------------------------------------------------------------------
2 IPv4 Options 874 655 0 0 0 0 874 655 Off Off
3 Layer2 control and legacy 8738 2185 33 0 0 0 8738 2185 Off Off
4 PPP Control 437 1000 0 0 0 0 437 1000 Off Off
5 CLNS IS-IS Control 8738 2185 0 0 0 0 8738 2185 Off Off
6 HDLC keepalives 437 1000 0 0 0 0 437 1000 Off Off
7 ARP request or response 437 1000 0 330176 0 0 437 1000 Off Off
8 Reverse ARP request or repso 437 1000 0 24 0 0 437 1000 Off Off
9 Frame-relay LMI Control 437 1000 0 0 0 0 437 1000 Off Off
10 Incomplete adjacency 437 1000 0 0 0 0 437 1000 Off Off
11 For-us data 40000 5000 442919246 203771 0 0 40000 5000 Off Off
12 Mcast Directly Connected Sou 437 1000 0 0 0 0 437 1000 Off Off
يمكن أن تكون هذه قائمة كبيرة، بها أكثر من 160 إدخال، حسب إصدار البرنامج.
على إخراج الجدول، تريد التحقق من عمود الحزمة المسقطة مع أي إدخال له قيمة غير صفرية على عدد الإسقاط العالي.
لتبسيط تجميع البيانات، يمكنك إستخدام الأمرshow platform software punt-policer drop-only
، للتصفية فقط لإدخالات المنظم مع حالات السقوط.
يمكن أن تكون هذه الميزة مفيدة لتحديد ما إذا كانت هناك عواصف ARP أو فيضانات بالمسبار 802.11 (يستخدمون حزم 802.11 في قائمة الانتظار إلى LFTS. LFTS ترمز إلى خدمة نقل إعادة توجيه لينوكس).
في جميع إصدارات الصيانة الأخيرة، تحتوي وحدة التحكم على مراقبة نشاط، وذلك للرد بشكل ديناميكي على وحدة المعالجة المركزية (CPU) العالية، وضمان بقاء أنفاق AP CAPWAP نشطة، في مواجهة الضغط غير المستدام. تقوم الميزة بالتحقق من حمل WNCD، وتبدأ في تقييد نشاط عميل جديد، لضمان بقاء موارد كافية لمعالجة الاتصالات الموجودة وحماية إستقرار CAPWAP. يتم تمكين هذا بشكل افتراضي، ولا تتوفر لديها خيارات تكوين.
وهناك ثلاثة مستويات محددة من الحماية، المستوى 1 عند حمل 80٪، والمستوى 2 عند حمل 85٪، والمستوى 3 عند 89٪، كل مستوى يطلق إسقاطات مختلفة للبروتوكول القادم كآليات حماية. وتتم إزالة الحماية تلقائيا بمجرد انخفاض الحمل.
في الشبكة السليمة، لا يمكنك رؤية أحداث تحميل L2 أو L3، وإذا كانت تحدث بشكل متكرر، يمكن التحقيق فيها.
لمراقبة إستخدام الأمرwireless stats cac
كما هو موضح في الصورة.
9800-l# show wireless stats cac
WIRESLESS CAC STATISTICS
---------------------------------------------
L1 CPU Threshold: 80 L2 CPU Threshold: 85 L3 CPU Threshold: 89
Total Number of CAC throttle due to IP Learn: 0
Total Number of CAC throttle due to AAA: 0
Total Number of CAC throttle due to Mobility Discovery: 0
Total Number of CAC throttle due to IPC: 0
CPU Throttle Stats
L1-Assoc-Drop: 0 L2-Assoc-Drop: 0 L3-Assoc-Drop: 0
L1-Reassoc-Drop: 0 L2-Reassoc-Drop: 0 L3-Reassoc-Drop: 0
L1-Probe-Drop: 12231 L2-Probe-Drop: 11608 L3-Probe-Drop: 93240
L1-RFID-Drop: 0 L2-RFID-Drop: 0 L3-RFID-Drop: 0
L1-MDNS-Drop: 0 L2-MDNS-Drop: 0 L3-MDNS-Drop: 0
ويتيح نظام أسماء المجالات (DNS) كبروتوكول نهج عدم اللمس لاكتشاف الخدمات عبر الأجهزة، ولكن في الوقت نفسه، يمكن أن تكون نشطة للغاية وتحميل محركات الأقراص بشكل كبير، إذا لم يتم تكوينها بشكل صحيح.
يمكن ل DNS، بدون أي تصفية، زيادة إستخدام وحدة المعالجة المركزية ل WNCD بسهولة، نظرا لعدة عوامل:
يمكنك التحقق من حجم قائمة DNS لكل خدمة باستخدام هذا الأمر:
9800-l# show mdns-sd service statistics
Service Name Service Count
-----------------------------------------------------------------------------
_ipp._tcp.local 84
_ipps._tcp.local 52
_raop._tcp.local 950
_airplay._tcp.local 988
_printer._tcp.local 13
_googlerpc._tcp.local 12
_googlecast._tcp.local 70
_googlezone._tcp.local 37
_home-sharing._tcp.local 7
_cups._sub._ipp._tcp.local 26
يمكن أن يوفر ذلك فكرة عن حجم أي استعلام محدد. إنها لا تشير إلى مشكلة بحد ذاتها، إنها مجرد طريقة لمراقبة ما يتم تعقبه.
هناك بعض توصيات تكوين DNS الهامة:
9800-1(config)# mdns-sd gateway
9800-1(config-mdns-sd)# transport ipv4
وبشكل افتراضي، يستخدم نقل IPv4. للأداء، من المستحسن إستخدام IPv6 أو IPv4، وليس كلاهما.
في حالة ظهور حمل مرتفع لوحدة المعالجة المركزية، وعدم مساعدة أي من الخطوات السابقة، يرجى الاتصال ب CX في حالة ما، وإضافة هذه البيانات كنقطة بداية:
show tech-support wireless
request platform software trace archive last <days> to-file bootflash:<archive file>
المراجعة | تاريخ النشر | التعليقات |
---|---|---|
2.0 |
06-Jun-2025
|
نص بديل محدث ومتطلبات النمط والترجمة الآلية ومتطلبات العلامة التجارية والتنسيق للامتثال لإرشادات Cisco للتحويل إلى الخارج |
1.0 |
09-May-2024
|
الإصدار الأولي |