منفذ ألياف على ERS 8600 مرفوع عند 1G إرسال ثنائي كامل لكن المحوّل لا يتعلّم أي MAC عليه
خادم فيزيائي واحد على ERS 8600 لدينا لا يتحدث مع أحد، والمحوّل مقتنع تماماً أن كل شيء بخير. المنفذ في هذه الحالة منذ نُقل الخادم من النحاس إلى الألياف.
- Avaya ERS 8600، الخادم على منفذ SFP بسرعة 1G في الفتحة 3، المنفذ 12
- بطاقة شبكة الخادم بوحدة SFP خاصة بها، وصلة ألياف عبر لوحة المبنى
- المنفذ متروك عند 1 جيجابت إرسال ثنائي كامل، لا شيء غريب في الإعداد
ما يُبلغه المحوّل عن ذلك المنفذ:
Port 3/12: up, 1000 Mbps, full duplex
FCS errors: 0
Port errors: 0
MAC addresses learned on 3/12: none
إذن المنفذ يتدرّب، يبقى مرفوعاً لأيام، لا يُحصي أي أخطاء إطلاقاً، ومع ذلك لا تحصل قاعدة بيانات التوجيه أبداً على أي عنوان منه. الخادم غير قابل للوصول من بقية VLAN.
ما جربته:
- أعدت تدوير المنفذ عدة مرات، لا شيء يتغيّر
- بدّلت التحكم بالتدفق في كلا الاتجاهين، أيضاً لا شيء
- تصفّحت FDB لـVLAN الخادم: عناوين من كل منفذ آخر، ولا واحد من 3/12
- الخادم يصرّ على أن رابطه الخاص مرفوع بسرعة جيجابت
أين تنظر بعد ذلك، جانب المحوّل أم البصريات في الخادم؟
Comments 3
هذا النمط - رابط مرفوع، إرسال ثنائي كامل، عدادات نظيفة، قاعدة بيانات توجيه فارغة - يعني تقريباً دائماً أن الطرف البعيد يضع ضوءاً على الألياف لكن ليس إطارات صالحة. الوحدة في الخادم هي أول مشتبه به لديك، وليس إعداد المحوّل.
ابرِئ جانب المحوّل أولاً حتى لا يجادل أحد لاحقاً. في صدفة تشخيص ERS 8600 شغّل
dumpPortStateوpsDump(<port index>)لذلك المنفذ. انتبه للفهرس: ليس slot/port من واجهة سطر الأوامر العادية، بل هو slot * 64 + (رقم المنفذ - 1). إن عادت هذه بمنفذ محلي سليم وعدادات نظيفة، فقد أدى المحوّل عمله والعطل يعيش في الجانب الآخر من الألياف.قبل أن تشتري أي شيء، أخرج المنشأة من المعادلة: صل ذلك المنفذ مباشرة إلى نفسه عبر وحدة احتياطية من نفس النوع، ثم قِس ما يخرج وما يعود وانظر ما إذا كانت كلتا القراءتين ثابتة حيث تقول مواصفات الوحدة أنها يجب أن تكون. بعد ذلك، استبدل SFP في بطاقة شبكة الخادم. في الحالة الموثّقة بهذه الأعراض كان ذلك الحل الكامل: منفذ المحوّل حافظ على الرابط لأيام، لم يخرج أي شيء قابل للاستخدام من الألياف أبداً، وظهرت العناوين لحظة استبدال وحدة الخادم.
تنبيه واحد إن لم يغيّر استبدال بوحدة سليمة معروفة شيئاً: بعض المنصات لديها عيب برمجي يبدو مطابقاً. لدى ERS 5900 عيب موثّق: استبدل وحدات uplink بسرعة 1 جيجابت بوحدات SFP+ بسرعة 10 جيجابت وترتفع الروابط نشطة دون أن ينقل أي منها شيئاً. إصدار برنامج لاحق يذكرها كمُصلَحة، وإعادة تعيين منفذ أو محوّل تُحرّك الأمور في الأثناء. لذا إن لم يساعد الاستبدال، اقرأ ملاحظات الإصدار لبرنامجك أولاً.
صفر أخطاء مع صفر عناوين متعلَّمة تركيبة محددة جداً، لذا حدد أي اتجاه ميت فعلياً. هل تُظهر عدادات المنفذ أي إطارات مستقبَلة إطلاقاً، أم لا شيء وارد إطلاقاً؟ إن كان جانب الاستقبال ثابتاً عند الصفر بينما يستمر جانب الإرسال في التصاعد، فالمحوّل يتحدث إلى فراغ وFDB الفارغ لديك عرض وليس المشكلة.
يستحق أيضاً تفريغ أياً كان ما استطاع المحوّل سحبه من الوحدة نفسها. على سلسلة VSP 7000 ذلك هو
show interfaces gbic-info، مضيّق بـport <port number>إن أردت واحداً فقط، ويخبرك أي جهاز يظن الجهاز أنه مثبَّت وما إذا كان يعتبره مدعوماً؛ إن كان إصدار ERS لديك يملك مكافئاً، انشر مخرجاته لـ3/12. وقل أي وحدة جالسة في بطاقة شبكة الخادم، الشركة المصنّعة والنوع، وليس فقط 'وحدة SFP'.دخلت إلى صدفة التشخيص كما اقتُرح. للفتحة 3 المنفذ 12 يُحسب الفهرس 3 * 64 + 11 = 203، إذن
psDump(203)بالإضافة إلىdumpPortState- منفذ محلي سليم، عدادات نظيفة، لا شيء خاطئ على المحوّل إطلاقاً، بالضبط كما تنبّأت.إذن سحبت SFP من بطاقة شبكة الخادم ووضعت احتياطية من نفس النوع. كان عنوان MAC في قاعدة بيانات التوجيه قبل أن أعود إلى مكتبي، والخادم قابل للوصول منذ ذلك الحين. وحدة ميتة في جانب الخادم لا تزال تُنتج ما يكفي من الضوء لرفع المنفذ وإبقائه مرفوعاً. شكراً، كنت سأمضي يوماً آخر في إعادة قراءة إعداد المحوّل.