الخلاصة

  • وضعت RFC 1452 وكيلاً أو مديراً ثنائي اللغة بين تطبيق SNMPv2 ووكيل SNMPv1، واختارت النسخة من قاعدة محلية.
  • لم تعبر GetBulk كما هي؛ تحولت إلى GetNext بعد تصفير التكرار، بينما بقيت بعض أخطاء النسخة القديمة بصيغتها.
  • أثبت الرد المترجم حدوث تبادل وفق خريطة، لا تنفيذ العملية الأصلية ولا حفظ المعلومات أو الأمن أو النتيجة التشغيلية كاملة.

القرار سبق الرسالة

وزعت RFC 1452 عبء الانتقال على طبقة وسيطة بدلاً من كل تطبيق. يمكن لكيان SNMPv2 أن يعمل وكيلاً أمام SNMPv1، أو لمدير واحد أن يتكلم النسختين.

قبل الاتصال بالهدف كان المدير يرجع إلى قاعدة بيانات محلية. الطلب سجل للنية، وصف الهدف قرار لاختيار النسخة، وقاعدة التحويل أنتجت PDU الفعلي. قد تظل الواجهة متاحة مع سجل قديم يختار بروتوكولاً خاطئاً. القدرة على التكلم بلغتين لم تصدّق معرفة الهدف.

ضاع الحجم وبقيت خطوة

مرت GetRequest وGetNextRequest وSetRequest من SNMPv2 إلى SNMPv1 بلا تغيير. أما GetBulk فصفّر الوكيل non-repeaters وmax-repetitions وغيّر الوسم إلى GetNextRequest.

نفّذ الطرف القديم خلفاً واحداً لكل ارتباط. حافظت الخريطة على إمكانية التقدم، لكنها لم تنفذ عدد المواضع الذي طلبه التطبيق في جولة واحدة. تعرّف RFC 1448 عملية SNMPv2 الأصلية؛ RFC 1452 تسجل تضييقها عند الحد.

لا يكفي request-id لإثبات المسار. يلزم PDU المصدر، واختيار النسخة، وقاعدة التحويل، وPDU المرسل فعلاً، والرد.

الخطأ القديم ظل دليلاً على مصدره

إذا حمل GetResponse من SNMPv1 القيم noSuchName أو badValue أو readOnly وجب ألا يغيرها الوكيل، مع أن كيان SNMPv2 لا يولدها أصلاً. اختراع استثناء أدق كان سيضيف معلومة لم يقلها الوكيل القديم.

أبقى القرار أثر المصدر، لكنه منع اعتبار الرد أصلياً للنسخة الجديدة. وفي حالة tooBig حُذفت variable bindings قبل رفع الخطأ. أمكن إذن لطلب GetBulk في الأعلى أن يرى نتيجة تنتمي إلى عملية GetNext القديمة في الأسفل.

أعاد الوكيل بناء trap

أضاف تحويل Trap-PDU الكائن sysUpTime.0، وحسب snmpTrapOID.0 من الحقول العامة أو الخاصة بالمؤسسة، ثم أرفق enterprise binding. كانت الرسالة الجديدة مشتقة من القديمة لا نسخة بايتية منها.

شارك الوكيل أيضاً في اختيار الوجهات، مع استثناء محدد لفحص وجود في view. لذلك يجب أن يفصل سجل المنشأ بين قيمة منسوخة وأخرى محسوبة وقرار توجيه.

استمر OID وتغير عقد الوصف

سمحت RFC 1452 باستعمال وحدات MIB القديمة، ورفضت إهمال كائن ما لم يتغير معناه فعلاً. لكن التحويل غيّر imports والأنواع والوصول والحالة والوصف والفهارس. أصبحت ACCESS هي MAX-ACCESS، وتحولت mandatory إلى current وoptional إلى obsolete، وصارت Counter وGauge بعرض صريح.

استمرار OID دليل على الاسم لا على الإذن أو نتيجة القراءة. أوضحت RFC 1908 لاحقاً أن استخراج group من subtree قد يصبح ملتبساً إذا اختلفت الأوراق الإلزامية بين مراجعات MIB القديمة.

كشفت النسخ اللاحقة كلفة الوسط

أدخلت RFC 2576 وBCP RFC 3584 نسخة SNMPv3. قد تنهار عدة استثناءات خاصة بالارتباطات إلى noSuchName واحد، وقد يمنع Counter64 ترجمة إخطار، وقد يكرر الوكيل GetNext لتجاوز قيم لا تمثلها SNMPv1. حذرت RFC 3584 من كلفة ذلك.

هذه حدود لاحقة وليست إثباتاً لنشر معين في 1993. لكنها تظهر أن الشفافية تعتمد على حالة وموارد وحكم داخل الوسيط.

لم تناقش RFC 1452 الأمن. عبور الوكيل لا يثبت هوية أو تخويلاً أو سرية أو سلامة، والرد لا يثبت أن تغييراً إدارياً أحدث أثره المقصود.

المصادر