وحدة SFP ONU بدلاً من ONT روستيليكوم: العصا لا تُسجَّل على OLT ولا يرتفع PPPoE
في المنزل ألياف روستيليكوم، ويوجد ONT خاص بالمشغّل، وأريد إزالة الصندوق الزائد من الخزانة: أُدخل عصا SFP ONU مباشرة في الموجّه وأوزّع الاتصال بنفسي بعد ذلك. اشتريت العصا، لكن الأمر لا يتجاوز الخطوة الأولى.
- موجّه Keenetic Giga، منفذ SFP فارغ
- عصا Eltex NTU-SFP-100
- كابل تصحيح SC/APC من المقبس، متر واحد
- في المنطقة، على ما يبدو، محوّل OLT من نوع Huawei MA5683
ما رأيته، جمعته في كتلة واحدة:
لينك على المنفذ: up/down كل بضع ثوانٍ
ONU على OLT: not registered
PPPoE: الجلسة لا تُنشأ
هيكل العصا بعد نصف ساعة: نحو 80 درجة مئوية، لا يمكن الإمساك بها باليدما جُرّب:
- نقل العصا إلى MikroTik - نفس الصورة، لا تسجيل؛
- فحص كابل التصحيح وتنظيف الموصل، لا يوجد انقطاع؛
- مراجعة إعدادات PPPoE، نفس اسم المستخدم وكلمة المرور التي تعمل بشكل طبيعي على ONT الرسمي.
هل أفهم بشكل صحيح أنه بدون مشاركة المشغّل لن ترتفع العصا إطلاقاً، أم أن هناك ما يمكنني ضبطه من جانبي؟ وإن نجحوا في تشغيل الوحدة، ماذا أتوقع بخصوص VLAN وIPTV؟
Show original (Русский)
Also available in: Русский
العربية
Deutsch
English
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Türkçe
Tiếng Việt
简体中文
Comments 5
باختصار: وحدة SFP ONU ليست "وحدة بدلاً من ONT"، بل طرفية كاملة يتحكم فيها المشغّل. طالما أن الرقم التسلسلي للعصا غير مُسجَّل على OLT، فهي غير موجودة بالنسبة للشبكة: لا تسجيل، لا منافذ GEM مُخصَّصة، والحفر أكثر من ذلك عديم الجدوى.
كل شيء آخر يصل عبر OMCI من جانب المشغّل: منافذ GEM، وCVLAN (عند روستيليكوم عادة هو 10)، وملفات التعريف؛ جزء من المعاملات يصل عبر TR-069. لن تكتب هذا يدوياً على العصا، فليس هناك واجهة ويب معتادة لـONT أصلاً.
ما يجب فعله: الذهاب إلى المشغّل بالرقم التسلسلي وطلب التسجيل كطرفية مشترك. البعض يُسجّل دون نقاش، والبعض الآخر لا يتعامل مبدئياً مع ONU من طرف ثالث - وحينها لا توجد خيارات.
وفوراً بخصوص التوقعات، حتى لا تكون هناك خيبة أمل لاحقاً. العصي تنقل نقل GEM بشكل طبيعي، لكن وضع الجسر (bridge) والبث المتعدد لأجل IPTV يعملان فقط إن كانت ملفات التعريف المطابقة مرفوعة على OLT. إن لم يمنحوها - سيكون هناك إنترنت، ولن يكون هناك IPTV. بخصوص 80 درجة لم تُخطئ، هي فعلاً بهذه السخونة، ومن الحرارة الزائدة تحدث بالضبط نفس ترنّحات المنفذ وتراجعات السرعة. لذا التهوية والمكان ذو الهواء ليسا رفاهية، بل جزء من التركيب.
السؤال الأول المهم: هل سلّمت الرقم التسلسلي للعصا إلى المشغّل؟ طالما لم يُسجَّل على OLT، فلن يتغيّر شيء بعد not registered - لا PPPoE، ولا رابط بالشكل المعتاد. أنت نفسك تكتب "على ما يبدو" بخصوص OLT - تحقق من الدعم بدقة، فالتزويد (provisioning) مختلف بين Huawei وZTE. أيضاً أخبرني ما البرنامج الثابت الحالي على العصا وهل جربت كابل تصحيح آخر: جزء من هذه الترنّحات يُعالَج باستبدال الكابل وليس بالإعدادات. وانظر هل يترنّح المنفذ مع إدخال الألياف أم أنه يقفز بنفس الشكل عندما تكون العصا فارغة - هاتان قصتان مختلفتان.
قصة مشابهة، لكن العتاد مختلف: شغّلت GPON في EdgeSwitch Fiber 12، وخلفه بوابة أمان (Security Gateway)، بدلاً من HG8245XGC الرسمي. جرّبت HPSP2120 وSSX1LTC وMA5671A. النتيجة نفسها - كل شيء يتوقف عند تسجيل الرقم التسلسلي، وعلى سؤال مباشر أجاب المزوّد أن ONU من طرف ثالث على الأرجح لن يُقبل. في المقابل، ارتفعت U Fiber Nano G عند معارف على MTS، وكان هناك OLT من Huawei وVLAN رقم 30. ملاحظة صغيرة أخرى يتعثر بها الناس: تحت GPON تحتاج SC/APC، الموصل الأخضر. مع كابل تصحيح UPC يمكن البحث طويلاً عن مشكلة غير موجودة.
سأضيف بخصوص اختيار الطراز. غالباً ما يكون لدى المشغّلين قائمة قصيرة من العصي التي يوافقون على تسجيلها أصلاً: في بعض الأماكن هي D-Link DPN-100 وHuawei MA5671A وZyxel PMG3000 وTechnicolor AFM0002/AFM0003، وكل ما هو خارج القائمة غير قابل للنقاش. الأفضل السؤال قبل الشراء بهذا الشكل بالضبط: ما هي وحدات ONU التي تُسجّلونها.
والنصف الثاني من السؤال هو المضيف نفسه. على hAP ax S يتصرف منفذ SFP وLAN1 بشكل غير مستقر، ولا يُنصح بالاعتماد على 800-900 ميجابت هناك؛ إن كنت تحتاج هامشاً، فمن الأفضل RB5009 أو ONU منفصل أمام الموجّه. وبخصوص PMG3000 سأحذّر بشكل منفصل: سلوك IPv6 فيه يتغيّر من إصدار برنامج ثابت إلى آخر.
كل هذا صحيح، لكن لا يجدر اختزاله في التزويد (provisioning) وحده: المضيف أيضاً قادر على الرفض. على Turris Omnia مع Turris OS 5.0.3 تُكتشف MA5671A بعد إعادة تحميل برنامج ثابت HL23446، لكن eth2 لا ترتفع، ويصل في السجل "SFP module encoding does not support 8b10b nor 64b66b". مع البرنامج الثابت المُعدَّل تُبلغ الوحدة أيضاً عن transmit fault، ومع البرنامج الثابت الأصلي - خطأ في قراءة EEPROM.
إجبار السرعة لم يُجدِ نفعاً، والفرع بنواة 5.4 وغرائبه الإضافية أيضاً لم ينفع. في المقابل، في نفس الموجّه ارتفعت DFP-34G-2C2 على شريحة ZTE بهدوء عند 1Gbps/إرسال ثنائي كامل، بينما ZISA OP151S وG-010S-A لم ترتفعا، والأخيرة برمز توافق (compliance code) غير معروف. نفس العصا المُعاد تحميل برنامجها تعمل على MikroTik إذا ضُبطت السرعة يدوياً. أي أن جزءاً من هذه القصص ليس عن OLT إطلاقاً، بل عن معالجة SFP على المضيف.