منافذ FortiGate 101F المشتركة RJ45/SFP من 17 إلى 20 تنطفئ بعد ترقية FortiOS
نشغّل زوجًا من أجهزة FortiGate 101F لمكتب من 40 شخصًا، لا شيء غريب. port17 يحمل رابط uplink من نوع SFP إلى محول النواة، وport19 هو وصلة RJ45 إلى غرفة الخوادم، وكلاهما ضمن الكتلة المشتركة RJ45/SFP (المنافذ 17-20). في نافذة الصيانة الشهر الماضي رقّينا الزوج إلى FortiOS 7.4.4، ومنذ ذلك الحين هذه الكتلة ميتة.
- FortiGate 101F، وجهاز FortiGate 100F في الموقع الثاني يتصرف بنفس الطريقة
- port17: وحدة SFP بسرعة 1G إلى محول وصول مكدّس
- port19: RJ45 إلى منفذ محول بسرعة 1G
- FortiOS 7.4.4، تمت الترقية من إصدار 7.2
المنافذ من 1 إلى 16 سليمة، فقط المنافذ المشتركة تعطلت. ما لفت انتباهي هو أن خيارات السرعة في الواجهة الرسومية لم تعد تبدو كما كانت قبل الترقية، والإعداد الحالي الآن يحتوي على هذا:
config system interface
edit "port17"
set speed 1000full
next
endلم يكتب أحد هنا ذلك. كل منفذ على هذا الجهاز كان على auto قبل الترقية.
ما جُرّب حتى الآن:
- أعدت تركيب SFP واستبدلتها بأخرى معروفة السلامة، لا تغيير
- نقلت الطرف البعيد إلى منفذ محول مختلف
- إعادة تشغيل كاملة (cold reboot) لجدار الحماية، والإعداد يبقى كما هو أعلاه
هل من المتوقع أن تفقد الكتلة المشتركة RJ45/SFP على 100F/101F وضع auto أثناء الترقية، أم أن إعدادنا تعطّل في مكان ما؟ وما الطريقة الصحيحة لإعادته؟
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 5
لم يُتلف أحد في المكتب إعدادك، الترقية هي التي فعلت ذلك. على 100F و101F تفرض الترقية بصمت قيمة ثابتة 1000full على المنافذ المشتركة RJ45/SFP حيث كان auto موجودًا سابقًا، دون أن تسأل عمّا إذا كان بإمكان الطرف الآخر التعايش مع تلك السرعة. حسب الطرف البعيد تحصل إما على منفذ يعمل بسرعة خاطئة، أو منفذ لا يعمل إطلاقًا، وهذا بالضبط سبب إظلام المنافذ 17-20 بينما المنافذ المخصصة لم تُمس. سجّلت Fortinet هذا كمشكلة معروفة برقم 989629، موثقة في ملاحظات إصدار 7.2.9؛ والإصدارات المتأثرة هي v7.2.8 وما بعده، وv7.4.2 وما بعده، وv7.6.0 وما بعده.
أعد ضبط السرعة يدويًا، لكل منفذ:
على v7.2.8 وعلى v7.4.2 حتى v7.4.4 خيار auto البسيط غير معروض في القائمة، وهذا بالضبط سبب اختلاف الواجهة الرسومية لديك، لذا استخدم 1000auto هناك. على v7.2.9 وv7.4.5 وv7.6.0 وما بعده عاد الخيار العادي وتريد:
كرر ذلك لـport18 حتى port20 إذا كانت مستخدمة. وللنافذة التالية: تحقق أولًا من عدم مرور أي جزء من مسار الإدارة عبر المنافذ 17-20، وإلا سيعود الجهاز بمنفذ الوصول لديك مفروضًا على 1000full وستقود إلى الموقع لإصلاحه من وحدة التحكم (console).
من أي إصدار جئت فعليًا؟ "إصدار 7.2" تغطي مساحة واسعة، وما يجب أن تكتبه لإصلاح هذا يختلف بين الفروع. الشيء الآخر الذي يستحق المعرفة هو ما إذا كانت الأطراف البعيدة تعرض التفاوض التلقائي أم أنها مثبّتة بنفسها: طرف يتفاوض تلقائيًا دائمًا سيبقى دون فعل شيء أمام منفذ مثبّت على سرعة ثابتة.
شيء واحد يجب حسمه قبل تغيير أي شيء: هل يمر مسار الإدارة لديك عبر أي من المنافذ 17-20؟ إن كان كذلك، نفّذ التغيير التالي من وحدة التحكم (console) بدلًا من عبر الشبكة.
يستحق إضافة النقطة العامة لأي شخص يصل إلى هنا بمنفذ مشترك يسيء التصرف: على معظم الأجهزة، الزوج فعليًا حصري. تسمي NETGEAR ذلك بالشخصية المزدوجة (dual personality) على GS716T-200، حيث يُقرن كل من مقبسي SFP بأحد منافذ النحاس الأخيرة، ولا يمكن أن يكون سوى نصف واحد من ذلك الزوج نشطًا في وقت واحد، لذا فإن تركيب وحدة يُخرج بصمت منفذ RJ-45 المقابل من الخدمة. كل منفذ في هذا الطراز هو بسرعة غيغابت على أي حال، لذا فإن رابط الصعود البصري يشتري لك مسار كابل، وليس عرض نطاق.
نفس الفكرة على كتلة FortiGate، لذا تأكد من أي نصف من port17 تنظر إليه فعليًا. وحدة في المقبس بالإضافة إلى كابل وصل في نصف النحاس من نفس المنفذ هدف خطأ كلاسيكي، ويبدو من سطر الأوامر تمامًا وكأنه مشكلة سرعة.
مورّد مختلف، نفس نوع الألم. EX4200 مع وحدة uplink من نوع EX-UM-2X4SFP: xe-0/1/0 يعمل بسرعة 10G بسعادة، وxe-0/1/1 لم يكن ممكنًا حتى إضافته إلى VLAN ولم ينقل أي حركة مرور. كلا المنفذين عملا بسرعة 1G، وكانت SFP+ مرئية بالكامل في show chassis hardware، بدّلت الوحدات، جربت وحدة EX-UM-2X4SFP احتياطية وأجريت إعادة ضبط لإعدادات المصنع قبل أن يخبرني أحد بحقيقة تلك الوحدة.
لم يكن هناك شيء معطوب. تلك الوحدة تقبل SFP+ في اثنين فقط من مقابسها، المرقّمين 0 و2 في العتاد؛ أما الزوج الآخر فسيحمل بصرية بسرعة 1G ولا شيء أسرع. إذن الواجهات بسرعة 10G التي ستحصل عليها هي xe-0/1/0 وxe-0/1/2، وxe-0/1/1، الذي كنت أصارعه، لم يكن ليعمل أبدًا بسرعة 10G مهما وصلت به. نقلت الوحدة البصرية مقبسًا واحدًا، هيّأت xe-0/1/2، وانتهى الأمر. مع المقابس ذات الأنماط المختلطة، اقرأ ما تدعمه الكتلة قبل أن تعيد أي شيء للمورّد (RMA).
احذر من زاوية حصرية المنفذ المدمج، فهي لا تفسر هذه الحالة. المنافذ كانت تعمل قبل الترقية، وتعطلت الكتلة المشتركة فقط بعد ذلك، وهناك سطر سرعة في الإعداد لم يكتبه أحد. هذا هو إعادة الكتابة، وليس أولوية المقبس.
مع ذلك، الخطأ المعاكس يحرق الناس أيضًا. قضيت مرة أسبوعًا مع محولات D-Link DES-1210-52 موصولة عبر ألياف بـuplink إلى OSNOVO NS-SW-8GX2G: إشارة رابط على المنافذ البصرية، بلا شبكة محلية، بلا إنترنت إطلاقًا، بينما نفس المحولات عملت بشكل جيد عند التسلسل عبر النحاس، وتحديث البرنامج الثابت لم يغيّر شيئًا. المنفذ المدمج كان المشتبه به الرئيسي لأيام. العطل الحقيقي كان في الطرف البعيد: منافذ OSNOVO التي تحمل تلك الوحدات كانت ميتة داخليًا، محترقة، بينما البصريات الجالسة فيها سليمة تمامًا.
إذن بمجرد أن يكون الإعداد المحلي صحيحًا، ضع وحدة معروفة السلامة في منفذ معروف السلامة في الطرف الآخر قبل أن تستنتج أي شيء عن جهازك الخاص.