الخلاصة

  • أضاف RFC 2358 متطلبات 100 Mb/s وعدّاد أخطاء الرموز مع إبقاء هوية Ethernet واحدة وربط الإحصاءات الخاصة بالوسط بفهرس الواجهة العام.
  • كان كل عدّاد يثبت حدثاً مضبوط التعريف، لا فاعله؛ فالقدرة والسرعة والازدواج والعصر الزمني والآلة والسبب ونتيجة الإصلاح أدلة منفصلة.

تعطي لوحة المراقبة انطباعاً بأن الاسم الموجود فوق الرقم يفسّر الرقم. في يونيو 1998، جعل RFC 2358 الأرقام الخاصة بـFast Ethernet أكثر دقة، لكنه أظهر أيضاً أن الدقة النحوية لا تساوي اليقين السببي. فالعدّاد لا يرى إلا ما عرّفه معيار القياس وما استطاعت الشريحة والوكيل تصديره.

حلت الوثيقة، وهي على مسار المعايير، محل RFC 1650 وأضافت معلومات لإدارة واجهات 100 Mb/s. ولم تدّع أنها نهاية السلسلة؛ إذ قالت إن تطور السرعات والكابلات والميزات سيستدعي تعديلات أخرى. حل RFC 2665 محلها في 1999 مضيفاً الغيغابت والازدواج الكامل، ثم وسّع RFC 3635 النموذج إلى 10 Gb/s. لذا تمثل RFC 2358 لحظة تاريخية، لا MIB نهائية للحاضر.

بدأت الاستمرارية من الهوية. أوصت الوثيقة بأن تستخدم واجهات Ethernet قيمة ethernetCsmacd(6) مهما كانت السرعة، وألا تتحول fastEther(62) وfastEtherFX(69) إلى هويات جديدة. وُضعت السرعة التشغيلية في ifSpeed، ونوع الوسط وحالة الازدواج في ifMauType ضمن MIB لوحدة MAU. بقي السؤال «ما هذه الواجهة؟» منفصلاً عن «كيف تعمل الآن؟».

منع هذا الفصل جمع الاتجاهين حسابياً. فالوصلة ذات 100 Mb/s والازدواج الكامل تظل 100 Mb/s في ifSpeed، لا 200. ولم يسمح غياب معلومة الازدواج باستنتاجها من حجم المرور. اشترط RFC 2358 MIB الخاصة بـMAU لأن وحدته وحدها لا تقدم وسيلة معيارية لمعرفة الازدواج.

وفصل القدرة عن الحالة أيضاً. كان على واجهة قادرة على 100 Mb/s تطبيق ether100MbsCompliance حتى إن كانت تعمل مؤقتاً بسرعة أدنى. وقد تبقى العدّادات الخاصة بسرعة المئة ساكنة. تثبت المطابقة ما يجب أن يتيحه الوكيل، لا السرعة المتفاوض عليها ولا سلامة الخدمة.

ربط dot3StatsIndex الواجهة نفسها التي يحددها ifIndex بالقيمة ذاتها. بذلك اجتمعت عدّادات الحزم والبايتات العامة مع اصطدامات Ethernet وأخطائها. لكن الربط نفسه جزء من الدليل: بعد إعادة تشغيل أو إعادة ترقيم، قد تُلصق قراءة صحيحة بمنفذ خاطئ إذا بقي الجرد قديماً.

كانت الإضافة المميزة هي dot3StatsSymbolErrors. يزيد عندما يظهر رمز بيانات غير صالح مع وجود حامل صالح، مرة واحدة على الأكثر لكل حدث حامل ولو احتوى الحدث رموزاً سيئة عدة. لذلك لا تعني الزيادة واحداً بتاً فاسداً أو إطاراً واحداً أو انقطاعاً واحداً للمستخدم؛ إنها واقعة واحدة وافقت قاعدة العد.

وللاصطدامات حدود مماثلة. الاصطدام المتأخر هو المكتشف بعد 512 زمن بت من الإرسال؛ وعند 10 Mb/s يساوي ذلك 51.2 ميكروثانية. الاصطدامات المفرطة تعد الأطر التي فشل إرسالها بسبب كثرة الاصطدام. والإرسال المؤجل انتظر لأن الوسط كان مشغولاً ولا يشمل الأطر التي اصطدمت. أما المدرج الاختياري فيجمع الأطر بحسب عدد الاصطدامات الدقيق.

تجعل هذه التعريفات المقارنة ممكنة، لكنها لا تحدد الجاني. قد يتوافق الاصطدام المتأخر مع عدم تطابق الازدواج أو مع طوبولوجيا تتجاوز الحدود. وقد تصاحب أخطاء FCS والمحاذاة والرموز تلف الوسط أو الضجيج أو البصريات أو الشريحة أو برنامج التشغيل. لا يختار اسم الكائن واحداً منها.

أقر dot3StatsInternalMacTransmitErrors بالحد صراحة. فهو يجمع أخطاء الإرسال الداخلية التي لم تُحسب كاصطدامات متأخرة أو مفرطة أو أخطاء استشعار حامل، ومعناه الدقيق خاص بالتنفيذ. إنه وعاء للباقي، لا تشخيص عالمي.

أما dot3StatsEtherChipSet فيحدد الشريحة التي جمعت الإحصاءات وإشارات الخطأ كي يأخذ المدير شواذها المعروفة في الحسبان. هذه منشئية القياس: مَن أنتج الشهادة. وليست اعترافاً بأن الشريحة سببت العطل.

حتى جمع الأعمدة يحتاج حذراً. إذا حقق إطار مستقبل شروط أخطاء متعددة، يُحسب حصراً وفق الحالة التي قدمتها خدمة MAC إلى مستخدمها. فالجدول يسجل نتيجة المصنف، لا كل الأعراض الفيزيائية التي كانت حاضرة في الإطار.

ويحتاج Counter32 إلى زمن. لا تكون الفروق صالحة من دون فترة العينة وعصر الانقطاع؛ فإعادة التشغيل أو الضبط أو تبدل الفهرس قد يبطل الطرح. القيمة والواجهة وأداة القياس والعصر وحدة إثبات واحدة.

لم تكن الاختبارات الفعالة حلاً سحرياً. ذكر النص loopback وTDR عبر ifTestTable التي كانت قديمة بالفعل، وجعل الدعم اختيارياً، ولم توفر MIB القياسية نتيجة TDR. بدء الاختبار واكتماله واسترجاع النتيجة وتحديد الموضع والتحقق بعد الإصلاح سجلات مختلفة.

وأخيراً، القراءة فقط لا تعني النشر الآمن. لم توجد كائنات قابلة للكتابة أو الإنشاء عبر SNMP SET، لكن هوية الشريحة قد تكشف مورّد المعدات. كان SNMPv1 غير آمن بذاته، وحتى IPsec لا يحدد من يحق له تنفيذ GET داخل الشبكة المحمية. أوصى النص بأمن المستخدم والتحكم في الرؤية في SNMPv3.

ترك RFC 2358 دفتراً عملياً: الجهاز، المنفذ، الفهرس، العصر، السرعة، القدرة، الوسط، الازدواج، الزيادات المصنفة، الشريحة، مشاهدة الطرف الآخر، الفرضية، التغيير، ثم إعادة التحقق. صحة سطر لا تملأ ما بعده.