سنستخدم في هذا الدرس نموذج OSI وواجهة سطر الأوامر لنظام سيسكو IOS للتعرف على المشاكل الشائعة في الشبكات؛ سنصنِّف المشاكل في مجموعات، فمثلًا مجموعة مشاكل الوسائط (media) كالتصادمات والتشويش (noise)؛ ومشاكل المنافذ مثل السرعة ونمط duplex؛ ومشاكل الضبط مثل إدارة كلمة المرور وملف الضبط.
النهج الطبقي
أفضل مكان لنبدأ فيه عند استكشاف الأخطاء هو نموذج OSI؛ حيث يسمح لنا النهج الطبقي (layered approach) بالتركيز على وظائف معيّنة لطبقاتٍ محددة، لنعلم ماذا يمكن لكل طبقةٍ أن تفعله؛ فسيساعدنا نهج «فرِّق تسد» على تصنيف الأدوات التي سنستعملها لاستكشاف الأخطاء في كل طبقة. فالمبدِّلات التقليدية (layer 2 switch) تعمل في الطبقتين 1 و 2 وهذا يعني أنَّ عليها التعامل مع الاتصالات الفيزيائية، كواصلات RJ-45 والأكبال ووصول إيثرنت للوسائط.
ستتعامل المبدِّلات متعددة الطبقات مع الطبقة الثالثة أيضًا، وفيها ميزة التوجيه، وهذا يتطلب استكشافًا للأخطاء في الطبقة الثالثة. وفي حالة المبدِّلات في الطبقة الثانية (layer 2 switches)، فربما يكون لديك مشاكل في الطبقة الثالثة، لكنها متعلقةٌ عمومًا بالوظائف الإدارية للمبدِّل؛ أي بكلامٍ آخر، ستتعامل منافذ المبدِّل مع مشاكل إيثرنت ومكونات الطبقة الثانية؛ لكن المبدِّل -كجهاز- سيملك عنوان IP وبوابة افتراضية، ولذلك تستطيع الاتصال عبر Telnet أو SSH إليه، واستخدام SNMP لمراقبته. في هذا السياق، ربما يكون لديك مشاكل في الطبقة الثالثة متعلقة بعناوين IP والبوابات الافتراضية.
المشاكل المتعلقة بالوسائط الفيزيائية
يبدأ بعض الأشخاص بالطبقة الأولى وينظرون إن كانت هنالك مشاكلٌ محتملة في الوسائط الفيزيائية كوجود ضرر في الأكبال أو تتداخل مع مصادر الأمواج الكهرومغناطيسية؛ تصنيف الأكبال المجدولة هو عاملٌ مؤثِّر، فستكون أكبال Cat-3 حساسةً لمصادرٍ معيّنة من الأمواج الكهرومغناطيسية مثل أنظمة تكييف الهواء؛ أما أكبال Cat-5، فلها تغليفٌ أفضل حول الأسلاك لحمايتها من تلك التداخلات. الحماية السيئة للأكبال قد تؤدي -مثلًا- إلى شد واصلات RJ-45 مما يسبب انقطاع بعض الأكبال.
يمكن أن تكون الحماية الفيزيائية سببًا لمشاكل الوسائط؛ فإذا سمحت للأشخاص بوصل الموزِّعات بمبدِّلاتك أو وصل مصادر غير مرغوبة للبيانات إلى المبدِّل؛ فقد تحدث تغييرات في أنماط البيانات التي ستُرسَل (التي قد لا تكون متعلقةً بالطبقة الفيزيائية) لكنها قد تتسبب في زيادة التصادمات إن وصلت موزِّعًا إلى مبدِّلاتك.
الأمر show interface
بعد أن تضع النهج الذي ستسير عليه لاستكشاف المشكلة، ولنقل مثلًا أنك ستبدأ بالطبقة الأولى وستحاول العثور على مشاكل فيها، فمن الضروري فهم مخرجات الأوامر وربطها بالطبقات؛ يعرض الأمر show interface معلومات قيّمة مفيدة؛ فمثلًا، أول سطر في مخرجات المثال الآتي سيُظهِر أنَّ Fast Ethernet 0/1 يعمل (الطبقة الأولى) وكذلك بروتوكول line (الطبقة الثانية)، فإذا وجدت أن البطاقة لا تعمل في الطبقة الفيزيائية، فستعرف أين تكمن المشكلة، وقد تكون مشكلة في الأكبال أو في التوصيلات، أو ببساطة أن الكابل ليس موصولًا، أو غير ذلك من الأخطاء التي ستجعل المبدِّلات تُعطِّل البطاقة.
Switch#sh interfaces fa 0/1 FastEthernet0/1 is up, line protocol is up (connected) Hardware is Fast Ethernet, address is 0023.aca4.f091 (bia 0023.aca4.f091) MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 100Mb/s, media type is 10/100BaseTX input flow-control is off, output flow-control is unsupported ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:14, output 00:00:00, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 1 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 5000 bits/sec, 6 packets/sec 1065544 packets input, 229455974 bytes, 0 no buffer Received 109157 broadcasts (99147 multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 99147 multicast, 0 pause input 0 input packets with dribble condition detected 8430743 packets output, 1316399122 bytes, 0 underruns 0 output errors, 0 collisions, 1 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 PAUSE output 0 output buffer failures, 0 output buffers swapped out
ويمكن أيضًا أن يكون معطلًا إداريًا، الذي يعني أنه قد أُغلِقَ يدويًا من مدير وسيتم تفعيله مرةً أخرى بأمرٍ بسيط. والإحصائيات مهمةٌ أيضًا، لأن وجود رسائل خطأ هنالك تعني وجود مشاكل فيزيائية، فلو كانت هنالك أخطاء عدِّة من نوع CRC، فهذا يعني وجود تشويش (noise) في الشبكة أو وجود عطب في معدات إيثرنت؛ وبشكلٍ مشابه، أخطاء «overruns» تعني أن معدَّل الدخل تجاوز قدرة معالجة المبدِّلات للبيانات، وتجاهل الإطارات يعني أن ذاكرة التخزين المؤقت قد أصبحت منخفضةً في المبدِّل. ستحصل أيضًا على إشارة لأخطاء الخرج، وعدد التصادمات (الذي لن يمثِّل دلالةً على حدوث مشكلة، بل تغير الرقم يدل على حدوثها)، وأيضًا عدد إعادات تشغيل المبدِّل يشير إلى عدد مرات إعادة تشغيل متحكِّم إيثرنت بسبب الأخطاء.
التشويش في الخلفية
إذا كنت تشك في وجود تشويش (noise)، فعليك النظر إلى عدد أخطاء CRC أو بالأحرى التغير في عدد أخطاء CRC غير المتعلقة بالتصادمات؛ بكلامٍ آخر، قد تكون أخطاء CRC نتيجةً للتصادمات، لكن عدد التصادمات ذا وتيرةٍ ثابتة، ولا يكون فيه تغييرات كبيرة؛ وبهذا تكون أخطاء CRC نتيجةً للتشويش (excessive noise).
عندما يحدث ذلك، فإن أول خطوة هي التحقق من الكابل، ويمكنك استخدام أدواتٍ خاصة بهذا الغرض؛ ربما يكون السبب هو التصميم السيئ للشبكة عبر استخدام أكبال ليست من تصنيف CAT-5 في شبكات Fast Ethernet و 100 Mb/s؛ فربما تستطيع حلّ هذه المشكلة عبر اختبار الأكبال وعبر قراءة توثيق تصميم الشبكة.
التصادمات
إذا تجاوز تواتر حدوث تصادمات حدًا معيّنًا في شبكتك، فهنالك أنواعٌ مختلفة من الحلول لهذه المشكلة؛ وهنالك عدِّة قواعد تتعلق بتلك الحدود. أغلبيتها تشير إلى أن التصادمات يجب أن تكون أقل من 0.1 بالمئة من الرزم.
إن شكَّلت التصادمات مشكلةً، فربما السبب هو جهازٌ معيب، على سبيل المثال، بطاقةٌ شبكيّة تُرسِل رزمًا غير مفهومة إلى الشبكة؛ وهذا يحدث عادةً عندما يكون هنالك تماس أو أخطاء منطقية أو فيزيائية في الجهاز. يمكن استخدام جهاز «time domain reflectometer» أو TDR للعثور على أكبال إيثرنت ذات النهايات غير الموصولة؛ التي قد تعكس الإشارات إلى الشبكة وتسبب تصادمات.
التصادمات المتأخرة
نحن نعلم أنَّ التصادمات تحدث عندما تكتشف إحدى محطات إيثرنت إشارةً عندما تحاول إرسال إطار. التصادمات المتأخرة (late collisions) هي نوعٌ خاصٌ من التصادمات؛ إذا حصل التصادم بعد إرسال أول 512 بت من البيانات، فيقال أن «تصادمًا متأخرًا» قد حدث. وأهم ما هنالك أنَّ التصادمات المتأخرة لا يُعاد إرسالها عبر بروتوكول إيثرنت، على العكس من التصادمات التي تحدث قبل إرسال أول 64 بايت؛ إذ ستصبح مهمة الطبقات العليا من تجميعة البروتوكولات أن تُحدِّد إن كان قد حصل تفقدان للبيانات، ثم ستتخذ قرارًا بطلب إعادة الإرسال.
لا يجب أن تحدث التصادمات المتأخرة في شبكات إيثرنت مصمّمة جيدًا؛ المسببات المحتملة هي استخدام أكبال غير ملائمة، أو عدد كبير من الموزِّعات في الشبكة، أو ربما بطاقة شبكيّة سيئة تسبب تصادماتٍ متأخرة. يمكن الكشف عن التصادمات المتأخرة عبر برمجيات تحليل البروتوكولات (protocol analyzers) وبالتحقق من المسافات الفيزيائية للأكبال وحدود (limits) بروتوكول إيثرنت.
مشاكل في الوصول إلى المنافذ
يكون عادةً للمشاكل في الوصول إلى المنافذ أعراضٌ ظاهرةٌ للعيان، فلن يتمكن المستخدمون من الاتصال إلى الشبكة، وسيلاحظ فريق الدعم المشكلة بسرعة لأن المستخدمين سيشتكون منها؛ كل تلك المشاكل متعلقةٌ بالوسائط والمعدِّات والبطاقات الشبكية المعيبة ...إلخ. وجزءٌ كبيرٌ منها سيكون متعلقًا بإعدادات duplex و السرعة.
يحدث أحد أكبر مسببات مشاكل الأداء في خطوط Fast Ethernet عندما يعمل منفذٌ من الوصلة باتجاهٍ وحيد (half-duplex)، بينما يعمل المنفذ الثاني من الوصلة باتجاهين (full-duplex)؛ وهذا يحدث عندما لا تثمر المفاوضة التلقائية (auto-negotiation) بحصول المنفذين على نفس الضبط؛ وهذا قد يحدث عندما يضبط المستخدم أحد المنافذ وينسى أن يضبط الآخر؛ بكلامٍ عام، يجب أن تكون المفاوضة التلقائية مفعّلةً على كلا الجانبين أو معطلةً؛ لكن ضبط duplex تابع لضبط السرعة، فلو ضُبِطَت السرعة إلى auto، فلن يمكن أن يُضبَط duplex يدويًا؛ ربما تجد رسائل أخطاء CRC عندما تُضبَط خيارات السرعة و duplex يدويًا على كلي الجهازين.
مشاكل متعلقة بنمط Duplex
هذا ملخصٌ عن المشاكل المتعلقة بنمط duplex؛ عندما تكون نهايةٌ مضبوطةٌ إلى full والأخرى إلى half فالنتيجة هي رسالة خطأٍ ظاهرة. نهاية مضبوطة إلى full والثانية إلى المفاوضة التلقائية ستؤدي إلى الرجوع إلى نمط الاتصالات أحادية الاتجاه إن فشلت المفاوضة التلقائية. ستؤدي التشكيلات الأخرى إلى الرجوع إلى نمط الاتصال أحادي الاتجاه؛ وحتى النهايات المضبوطة للمفاوضة التلقائية قد تستعمل ضبطًا مختلفًا، على سبيل المثال، القيمة الافتراضية لاتصالات gigabit Ethernet هي full-duplex، بينما القيمة الافتراضي لمنافذ 10/100 هي half-duplex. وبغض النظر أنَّ المفاوضة التلقائية هي ميزة مفيدة، لأنها تسمح لك بالحصول على منافذ شاملة (generic) تسمح بأي نوع من الاتصال، لكنها قد تكون مشكلةً ويتم تجنبها بتفضيل الضبط الثابت عليها.
المشاكل المتعلقة بالسرعة
أمرٌ مشابهٌ يحدث مع المشاكل المتعلقة بالسرعة؛ فإذا ضبطت نهايةً إلى سرعةٍ ما وضبطت الأخرى إلى سرعةٍ أخرى، فلن يحدث تطابق؛ وحتى لو كنت تستخدم ميزة المفاوضة التلقائية، فإن النتيجة هي عدم تطابق إن كان أحد الجانبين مضبوطًا على المفاوضة التلقائية ولكن لم يُضبَط الطرف الآخر عليها. نمط duplex متعلق كثيرًا بالسرعة وقد تؤدي المفاوضة التلقائية على السرعة إلى تغيير نمط الاتصال إلى أحادي الاتجاه.
المشاكل المتعلقة بالضبط
قد تتعلق بعض المشاكل بالضبط، فبعضها مرتبطٌ بفقدان الضبط وعدم وجود نسخ احتياطية منه، وبعضها متعلقٌ بمشاكل تغيير الإدارة؛ ففي تلك الحالة، فيستحسن أن تُصمَّم منهجية ضبط إدارة جيدة. أولى الخطوات هي إنشاء نسخ فيزيائية من الملفات النصية، وجعل الضبط مركزيًا في خوادم TFTP مثلًا، لكن خذ بعين الاعتبار المحدوديات الأمنية لاستخدام TFTP.
بخصوص تغيير الإدارة، خذ نسخًا متعددة قبل وبعد التغييرات، وتأكد من أنَّك قادرٌ على الرجوع إلى الإعدادات القديمة إن سببت مشاكل في أماكن أخرى؛ احفظ دومًا الضبط في NVRAM، كي يكون متاحًا في المرة القادمة التي تعيد فيها التشغيل.
أخيرًا، أمّن الضبط بحماية الطرفية و VTY وغيرها من طرق الوصول إلى الأجهزة بكلمة مرور؛ وأمِّن أيضًا النسخ الاحتياطية من ملفات الضبط على الخواديم وغيرها من الأماكن.
ترجمة -وبتصرّف- للمقال Troubleshooting Switch Issues.
أفضل التعليقات
لا توجد أية تعليقات بعد
انضم إلى النقاش
يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.