لهذه المادة غرضان. أولا، يحتوي على توصيات حول كيفية تكوين Cisco Network Registrar (CNR) لتحقيق الأداء والاستقرار المثاليين وكيفية مراقبة تثبيت CNR. ثانيا، يحتوي على توصيات حول كيفية التصرف في حال حدوث مشكلة. في الحالة المثالية، ستقرأ هذا المقال وتعمل على تنفيذ توصيات التكوين والمراقبة قبل حدوث أي مشاكل. وبذلك تتجنبون المشاكل. إذا كنت تقرأ هذا المقال للمرة الأولى بسبب وجود مشكلة لديك مع CNR، انتقل فورا إلى الإجراءات الفورية عند مواجهة قسم المشاكل. للحصول على شرح أكثر عن التوصيات، يرجى الرجوع إلى أدلة إستخدام CNR ومراجع الأوامر.
لا توجد متطلبات خاصة لهذا المستند.
لا يقتصر هذا المستند على إصدارات برامج ومكونات مادية معينة.
للحصول على مزيد من المعلومات حول اصطلاحات المستندات، ارجع إلى اصطلاحات تلميحات Cisco التقنية.
تمثل توصيات التكوين المقدمة هنا نقطة بداية. إذا تم تكوين النظام بشكل مختلف عن هذا، راجع إعداداتك. ربما تم تطوير التكوين الخاص بك من إصدارات سابقة من CNR. يوفر CNR 5.0 والإصدارات الأحدث أداء محسنا كثيرا مقارنة بالإصدارات السابقة، ولكن يجب إجراء تغييرات في المعايير لتحقيق أقصى إستفادة. يركز هذا المستند على بيئات موفري الخدمات الكبيرة، ولكن تنطبق العديد من التوصيات على بيئات CNR الأخرى أيضا. يفترض هذا المستند ما يلي:
أنت مزود خدمة تقوم بتشغيل شبكة ذات نطاق ترددي عريض ب 10000 مشترك أو أكثر.
أنت تستخدم CNR 5.0.3 أو أحدث.
أنت تستخدم البروتوكول الخفيف للوصول للدليل (LDAP). يتم تشغيل CNR بدون LDAP، ولكن يستخدم العديد من موفري الخدمة LDAP.
شبكتك لها تشبع عنوان IP متوسط.
تقوم بتشغيل CNR على خوادم UNIX. تنطبق معظم التوصيات بشكل متساو على Windows NT، ولكن معظم مزودي الخدمة يشغلون CNR على خوادم UNIX، بحيث يتم إستخدام مثال UNIX و NT حيث يختلفان.
لديك إتصالات بأنظمة أخرى (مثل إعداد الفواتير أو رعاية العملاء أو الإمداد) قيد التشغيل على خوادم أخرى.
نظام اسم المجال الديناميكي (DDNS) غير نشط في موقعك (لا يستخدم معظم موفري الخدمة DDNS).
تخصيص عنوان IP للخطة والمستندات.
عمليات منفصلة تتطلب أقراص كثيرة: ضع خادم DHCP الأساسي على جهاز مختلف عن خادم LDAP وخادم DNS الأساسي.
قم بتوثيق تكوين نظام توصيل المودم الكابلي (CMTS)؛ وتأكد من تطابق تكوينات CMTS و CNR.
إعداد خطط إستعادة البيانات بعد الكوارث.
توثيق مخطط الشبكة.
لاحظ إصدارات برنامج Cisco IOS® ل CMTS.
الخطوات الأكثر فعالية لسلامة شبكتك على المدى البعيد هي: أ) خطط التكوين الخاص بك، ب) سجل هذه الخطط، و ج) تسجيل التغييرات عند تخطيط التغييرات وتنفيذها. توثيق أسباب الاختيارات يمكن أن يساعد أثناء جلسات التخطيط المستقبلية.
إستخدام تجاوز الفشل الآمن. ويوصى بشدة بتجاوز الأعطال ببساطة حيث يكون أحد الخوادم هو الخادم الرئيسي لكافة النطاقات، بينما يقوم الخادم الآخر بالنسخ الاحتياطي لجميع النطاقات (وذلك على العكس من عملية التغلب على الأعطال المتماثلة، حيث يكون كلا الخادمين هو الخادم الرئيسي وميزة النسخ الاحتياطي في نفس الوقت، وذلك وفقا للنطاق الفردي)، حيث يعمل هذا الخادم على تبسيط مهام الإدارة بدرجة كبيرة.
قم بتشغيل إختبارات بروتوكول إدارة الشبكات البسيط (SNMP). هذه الأمثلة للتوضيح:
nrcmd> trap enable address-conflict nrcmd> trap enable dhcp-failover-config-mismatch nrcmd> trap enable other-server-not-responding nrcmd> trap set free-address-low-threshold=15% nrcmd> trap set free-address-high-threshold=30% nrcmd> trap enable free-address-low
تأكد من توفر ذاكرة وصول عشوائي كافية (سعة 512 ميجابايت أو أكثر).
تأكد من أن تقسيم البيانات كبير بما يكفي (2.5 جيجابايت أو أكثر).
إستخدام أقسام منفصلة للسجلات والبيانات.
تأكد من وجود إتصالات فائقة السرعة وزمن وصول أقل بين الخوادم، تحقق من إعدادات الواجهة.
تتيح لك ملائمات SNMP إمكانية مراقبة خادم DHCP من شاشة الشبكة. تأكد من تكوين الملائمات على خادم DHCP، وقم بتكوين الشاشة لاستقبالها وعرضها، ومن الواضح أنك تتأكد من إيلاء الاهتمام للشاشة.
ويتطلب تكوين نظام إنتاج مقايضة التكلفة مقابل فعالية النظام. نقترح هذه القيم بافتراض وجود حوالي 100000 مشترك على الأنظمة فئة E250 التي تقوم بتشغيل تجاوز الأعطال. يؤثر إستخدام العديد من النهج وفئات العملاء والنطاقات ومخازن الطلب والاستجابة ومنافذ DHCP والمضاعفات الأخرى على إحتياجات الذاكرة والأداء.
يجب زيادة قسم السجل (/var/nwreg2) إذا تم زيادة عدد السجلات وحجمها.
تعيين المخازن المؤقتة للطلب والاستجابة للحصول على أفضل إخراج. لاحظ أن هذه التوصيات قد تغيرت بالنسبة إلى CNR 5.0.
nrcmd> DHCP set max-dhcp-requests=500 nrcmd> DHCP set max-dhcp-responses=2000
وقت إستئجار مودم الكبل = 604800 (7 أيام) أو أكثر.
مدة إيجار معدات أماكن عمل العملاء: أطول فترة ممكنة (انظر الملاحظة الخاصة بالمقايضات).
زيادة أحجام سجلات DHCP و TFTP:
nrcmd> server DHCP serverLogs nlogs=15 logsize=10M nrcmd> server DNS serverLogs nlogs=15 logsize=10M nrcmd> server TFTP serverLogs nlogs=10 logsize=10M
قم بتكوين إعدادات السجل التي توفر تفاصيل كافية لتحديد المشاكل، ولكن لا تقوم بإنشاء تفاصيل مفرطة (مما يجعل من الصعب تمييز المشاكل ووضع حمل غير ضروري على الخادم). هذه هي الإعدادات الموصى بها التي يمكن تطبيقها بشكل عام. اضبط إعداداتك إذا لزم الأمر للتعامل مع المشاكل في شبكتك:
ملخص النشاط
افتراضي
عدم تجاوز الفشل
تمكين ملحقات التأجير المؤجلة
تعيين دقة الحركة الأخيرة-الوقت = 1/2 فترة الإيجار
قم بتعطيل تجاوز السماح-العميل-التأجير للسياسات التي تعرض عقود إيجار الإنتاج.
قم بتمكين الرجوع إلى المحلي، عندما لا يكون LDAP متوفرا، يستخدم CNR البيانات المحلية:
nrcmd> session set visibility=3 nrcmd> dhcp enable fallback-to-local-client-data nrcmd> session set visibility=5
في حالة إستخدام CNR 5.5 أو إصدار أحدث، قم بتكوين إمكانية ذاكرة التخزين المؤقت للعميل لتقليل استعلامات LDAP بمقدار النصف.
nrcmd> dhcp set client-cache-count=2000 nrcmd> dhcp set client-cache-ttl=5
وللاستفادة على نحو أكثر فعالية من قدرة الإنتاج الخاصة بالمعهد الوطني للأبحاث، ينبغي أن يكون عدد المخازن المؤقتة للاستجابة أكبر بثلاث إلى أربع مرات من عدد المخازن المؤقتة للطلب. يستخدم النظام عدد المخازن المؤقتة الذي يحتاجه فقط. ونظرا لأن مدة الإيجار تصبح أقصر، يلزم المزيد من المخازن المؤقتة للاستجابة.
ملاحظة: ينبغي تحديد أوقات الإيجار ما دامت عملية. تأتي عمليات تأجير مودم الكبل من مساحة عنوان خاصة (عادة NET-10)، ونادرا ما تنتقل أجهزة المودم إلى مواقع مختلفة على الشبكة. وينبغي أن يتم عقد هذه الإيجارات لمدة أسبوع أو أكثر. ومن ناحية أخرى، تأتي عقود إيجار خدمة CPE من مساحة العنوان العامة، ولا تنتقل خدمات CPE (وخاصة أجهزة الكمبيوتر المحمولة). هنا يجب تعيين مدة التأجير لتطابق عادات مجموعة المستخدمين لديك. تخفض التأجيرات الطويلة الحمل على خادم DHCP. عند إستخدام عقود إيجار قصيرة (أقل من 8 ساعات)، قم بزيادة مخازن الاستجابة المؤقتة إلى 2500.
قم بتعطيل تجاوز السماح للعميل - التأجير لضمان التزام العملاء بأوقات التأجير المحددة في تكوين CNR الخاص بك - يحاول بعض العملاء تجاوز الإعداد المحدد.
قم بتمكين الرجوع إلى المحلي للحفاظ على تشغيل الشبكة في حالة حدوث فشل في خادم LDAP. مع هذا الإعداد، يستمر خادم DHCP في الوفاء بطلبات الإيجار على الرغم من عدم إستجابة خادم LDAP. لن يتمكن الخادم من الوصول إلى معلومات العميل المحددة المخزنة في خادم LDAP، لذا سيتم استيفاء كل طلب بإعداد افتراضي. يجب تكوين إعداد افتراضي منطقي لشبكتك.
وأخيرا، تحتفظ ميزة ذاكرة التخزين المؤقت للعميل ببيانات العميل التي تم إستردادها من LDAP في الذاكرة، وبالتالي يحتاج خادم DHCP إلى الاستعلام عن LDAP مرة واحدة فقط أثناء دورة الاكتشاف-عرض-طلب-ack، مما يزيد من سرعة أداء خادم DHCP.
تمكين ميزة النقل التزايدي:
nrcmd> dns enable ixfr-enable
تمكين الإعلام. ارجع إلى مراجع أوامر واجهة سطر الأوامر (CLI) ل CNR للوسيطات التي تحتاج إلى تمكينها للإشعار.
ضع خوادم DNS الأساسية والثانوية على مقاطع شبكة منفصلة.
قم بتكوين العملاء للاستعلام عن خادم DNS ثانوي.
تتلقى خوادم DNS الثانوية بياناتها من الخادم الرئيسي إحدى الطريقتين التاليتين: أ) "النقل الكامل للمنطقة" أو ب) "الإعلام/ixfr" (النقل التزايدي). يؤدي إستخدام NOTIFY/IXFR إلى تقليل عدد السجلات التي يجب نقلها من الخوادم الأساسية إلى الخوادم الثانوية. هذا مهم عندما يكون الاسم فراغ ديناميكي نسبيا.
تعيين مهلة الحزمة الأولية على 2:
nrcmd> tftp set initial-packet-timeout = 2
في حالة إستخدام CNR 5.5 أو إصدار أحدث، قم بتمكين التخزين المؤقت لملف TFTP لتحسين الأداء:
nrcmd> tftp set home-directory=/var/nwreg2/data/tftp nrcmd> tftp set file-cache-directory=CacheDir nrcmd> tftp set file-cache-max-memory-size=32000 nrcmd> tftp enable file-cache nrcmd> tftp reload
يحتفظ التخزين المؤقت لملف TFTP بملفات تكوين مودم الكبل المخزنة في الذاكرة، مما يساعد على تجنب عمليات القراءة على القرص في كل مرة يطلب فيها مودم الكبل ملف تكوين. يجب إنشاء دليل ذاكرة التخزين المؤقت للملفات في محرك الأقراص الثابتة (CacheDir في المثال أعلاه)، ويتم تعيين الحد الأقصى للحجم. أختر الحجم مع مراعاة المبلغ الإجمالي لذاكرة الوصول العشوائي (RAM) في نظامك وعدد ملفات التكوين المختلفة المطلوبة.
لا يتطلب بروتوكول TFTP من العميل إرسال حزمة إقرار نهائي (ACK) عند إستلام ملف. في حالة عدم تلقي ACK، يجب على الخادم الاحتفاظ باتصال العميل لفترة المهلة، التي تحد من قدرته على خدمة الطلبات الجديدة. إذا كان خادم TFTP لديك لديه سعة الموارد، فيمكنك أيضا زيادة قيمة max-tftp-packet لدعم عدد أكبر من إتصالات العملاء. القيمة الافتراضية لهذه المعلمة هي 512. الحد الأقصى للقيمة هو 1000.
تظهر هذه الإعدادات تكوين حيث يقوم CNR بكتابة تحديثات تأجير LDAP. إن أمكن، قم بتصميم شبكتك بحيث لا يكون ذلك ضروريا. يتم عرض هذا الخيار هنا لتقديم توصيات إذا كان يتعين عليك كتابة تحديثات التأجير. تحسين إتصالات LDAP باستخدام كائنات LDAP القابلة للضبط بشكل منفصل للقراءة/الكتابة. (يحصل كل كائن على مجموعته الخاصة من الارتباطات).
# Create and Configure a New LDAP Create/Update object ldap LDAP-Write create csrc-ldap ldap LDAP-Write set password=changeme ldap LDAP-Write set port=389 ldap LDAP-Write set preference=1 ldap LDAP-Write setEntry query-dictionary csrcclientclass=client-class-name ldap LDAP-Write set reactivate-interval=60s ldap LDAP-Write set search-filter= (&(macaddress=%s)(|(csrcclassname=Computer)(csrcclassname=Modem))) ldap LDAP-Write set search-path=csrcprogramname=csrc,o=NetscapeRoot ldap LDAP-Write set username= "uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot" ldap LDAP-Write set can-query=disabled ldap LDAP-Write set can-create=enabled ldap LDAP-Write set can-update=enabled ldap LDAP-Write set connections=2 ldap LDAP-Write set limit-requests=enabled ldap LDAP-Write set max-requests=8 ldap LDAP-Write set timeout=30s ### Create and Configure a New LDAP Read object ldap LDAP-Read create csrc-ldap ldap LDAP-Read set password=changeme ldap LDAP-Read set port=389 ldap LDAP-Read set preference=1 ldap LDAP-Read setEntry query-dictionary csrcclientclass=client-class-name ldap LDAP-Read set reactivate-interval=60s ldap LDAP-Read set search-filter= (&(macaddress=%s)(|(csrcclassname=Computer)(csrcclassname=Modem))) ldap LDAP-Read set search-path=csrcprogramname=csrc,o=NetscapeRoot ldap LDAP-Read set username= "uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot" ldap LDAP-Read set can-query=enabled ldap LDAP-Read set can-create=disabled ldap LDAP-Read set can-update=disabled ldap LDAP-Read set connections=3 ldap LDAP-Read set limit-requests=enabled ldap LDAP-Read set max-requests=12 ldap LDAP-Read set timeout=3s
يتضمن التكوين الموضح وجود تحديثات لتأجير كتابة CNR ل LDAP. قد ترغب في القيام بذلك لتمكين التطبيقات من الاستعلام عن LDAP لمعلومات الإيجار الحالية، ولكن يجب محاولة تجنب هيكلة التطبيق بحيث يكون ذلك ضروريا. إذا كنت بحاجة إلى توفير معلومات حول حالة تأجير عنوان IP، فيمكنك إستخدام أمر تأجير NRCMD للحصول على عنوان MAC وانتهاء الصلاحية ومعلومات أخرى حول الحالة الحالية للتأجير.
تم تصميم أدلة LDAP ليتم قراءتها بسرعة وكفاءة، ولكن الكتابة إلى دليل LDAP غير فعالة. إذا قمت بتكوين CNR لكتابة معلومات الإيجار إلى LDAP، فإن LDAP يصبح عنق زجاجة بالنسبة للأداء الكلي للنظام. إذا كان يجب تكوين عمليات كتابة تأجير LDAP، فاستخدم الإعدادات الموصى بها. لاحظ أن وصول CNR إلى LDAP قد تم تحسينه من خلال إستخدام كائنات "قراءة" و"تحديث LDAP" المنفصلة. لاحظ أيضا مهلة الكتابة 30 ثانية. بمهلة أقصر تقوم بتشغيل خطر LDAP يكتب وقت انتهاء التوقيت عندما يكون LDAP تحت حمل ثقيل. ثم يعيد CNR الكتابة، مما يضيف حمولة إضافية إلى LDAP.
يجب ألا يتجاوز إجمالي عدد الاتصالات بخادم LDAP الحد الأقصى لعدد مؤشرات الترابط المتوفرة. إذا كان خادم LDAP يدعم عدة مؤشرات ترابط لكل اتصال، فإن العدد الأمثل للاتصالات هو إجمالي عدد مؤشرات الترابط المقسمة على عدد مؤشرات الترابط لكل اتصال.
إنشاء فهارس لحقول البحث.
قم بتكوين حجم ذاكرة التخزين المؤقت لزيادة عدد الإدخالات المخزنة مؤقتا في الذاكرة، بالرغم من أنه يجب ألا تتجاوز ذاكرة التخزين المؤقت ثلث الذاكرة المتوفرة.
قم بتكوين الحد الأقصى لمؤشرات الترابط لزيادة عدد الاتصالات المتزامنة التي يمكن دعمها، على الرغم من أنه يجب ألا يتجاوز ذلك نصف الموارد المتاحة.
قم بتكوين إعدادات السجل التي توفر تفاصيل كافية لتحديد المشاكل ولكن لا تقوم بإنشاء تفاصيل مفرطة (مما يجعل من الصعب تمييز المشاكل ووضع حمل غير ضروري على الخادم).
إستخدام أقسام منفصلة للسجلات والبيانات.
تختلف عمليات تنفيذ خادم LDAP المحددة. ارجع إلى وثائق الخادم لتنفيذ هذه الاقتراحات.
نسخ قواعد بيانات CNR إحتياطيا بشكل منتظم. أحلت المستعمل مرشد لتعليم. يجب نسخ قواعد بيانات CNR إحتياطيا مرة واحدة على الأقل في اليوم. الاحتفاظ بملفات النسخ الاحتياطي لمدة أسبوعين على الأقل.
النسخ الاحتياطي لبروتوكول LDAP بشكل منتظم.
النسخ الاحتياطي للسجلات وأرشفتها بشكل منتظم.
بعد إجراء تغييرات على CNR، تأكد من أن تكوين الخوادم الرئيسية والخوادم الاحتياطية في سيناريو تجاوز الفشل يظل متسقا. أستخدم أداة CNRfailoverConfig -المقارنة في CNR الإصدار 5.5 والإصدارات الأقدم، أو مقارنة التكوينات باستخدام WebUI في CNR 6.0 والإصدارات الأحدث.
عند تخطيط تغييرات مخطط الشبكة، قم بتعيين زمن تجديد DHCP وتأجيره إلى قيم صغيرة.
مراقبة إستخدام عنوان IP (إستخدام إختبارات SNMP).
مراقبة إستخدام النظام (الذاكرة والقرص ووحدة المعالجة المركزية (CPU) والمبادلة). قمة الأداة المساعدة مفيدة لهذا الغرض.
راجع السجلات دوريا لتتعرف على الحالات العادية. يتيح لك فهم السجلات العادية معالجة المشكلات بسرعة أكبر.
راجع السجلات بشكل دوري للاستثناءات: GREP for "error" أو "warn" أو "connect" (على سبيل المثال، في UNIX، أستخدم grep -i يحذر name_dhcp_1_log).
يتطلب DHCP Safe-Failover أن تكون إعدادات التكوين لنطاق ما متطابقة على الخادم الأساسي وخادم النسخ الاحتياطي لهذا النطاق. تأكد من أنك تقوم بالتغيير على كلا الخادمين عندما تقوم بإجراء تغيير على إعداد ما. أستخدم CNRfailoverConfig -المقارنة أو WebUI في CNR 6.0 وما بعده للتحقق للتأكد من عدم وجود إختلافات.
يمكن أن تجعل تغييرات مخطط الشبكة أو تغييرات تخصيص عنوان IP من الضروري للعملاء الحصول على عنوان مختلف. يجب عليك التخطيط لفترة من الوقت عندما يكون لبعض العملاء على شبكة فرعية عنوان من النطاق القديم وقد قام البعض بتجديد والحصول على عنوان من النطاق الجديد. يمكنك تقليل مقدار الوقت الذي تكون فيه كلتا مجموعتي العناوين نشطة عن طريق تقليل طول عقود الإيجار قبل إجراء التغيير بحيث يكون لجميع العملاء عقود إيجار قصيرة الأجل. وهذا يضمن أنهم يجب عليهم تجديد عقود الإيجار بشكل متكرر وبالتالي الحصول على عقد إيجار من النطاق الجديد مباشرة بعد إجراء التغيير. تأكد من عدم تعيين وقت التأجير قصيرا إلى الحد الذي يؤدي إلى نفاد عمليات التأجير أثناء توقفك وبدء تشغيل الخادم لإجراء التغيير. بعد إجراء التغيير، تأكد من إستعادة فترة التأجير الأصلية حتى لا تزيد الحمل على الخادم.
والنهج الأكثر فعالية لحل المشاكل هو تجنبها. يساعدك اتباع التوصيات الموضحة أعلاه على المحافظة على توافق المسؤولين لديك مع العملية التي تقوم بها، فضلا عن تمكينك من تجنب المشكلات الخطيرة. عندما تظهر مشكلات (مثل زيادة وقت الانتظار للإدخال/الإخراج أو زيادة إستخدام الذاكرة دون سبب معروف)، قم بالمتابعة باستخدام السجلات. راجع التغييرات الأخيرة التي تم إجراؤها على بيئتك المادية أو تكوين CNR لمعرفة ما إذا كان ذلك يمكن أن يكون مصدر المشاكل.
سجلات CNR هي أصدقائك. عند البدء في إستخدام CNR، أو ترقية CNR، أو تغيير تكوين CNR، أستخدم الأمر grep الموضح للتحقق من السجلات لأي مشاكل. ثم تراجعوا إلى الوراء في السجل لكي تفهموا متى وكيف نشأت القضية، وأن تصلحوا المشكلة.
لا تقم بإعادة تشغيل CMTS ما لم يطلب منك ذلك من قبل موظفي دعم Cisco (يطبق على بيئات الكبلات فقط).
لا تقم بإعادة تشغيل CNR ما لم يطلب منك ذلك بواسطة موظفي دعم Cisco.
لا تقم بتعطيل تجاوز الفشل الآمن ما لم يطلب منك ذلك من قبل موظفي دعم Cisco.
لا تقم بإعادة تحميل CNR أو إعادة تشغيله أو تعطيله بأية طريقة مع وجود عملية إعادة مزامنة آمنة لتجاوز الفشل قيد التقدم.
قم بنسخ ملفات السجلات إلى دليل لن يتم الكتابة فوقها. إذا تعطل CNR، انسخ الملف الأساسي إلى دليل حيث لن يتم الكتابة فوقه.
هل تستخدم:
nrcmd> server dhcp getRelatedServers
لعزل سوء تكوين تجاوز الفشل الآمن.
قم بالنظر إلى السجلات للحصول على إستثناءات. تحقق بشكل خاص من تسلسل بدء التشغيل (قد يكون هذا في سجل قديم): GREP for "error" أو "warn" أو "connect" (على سبيل المثال grep -i error name_dhcp_1_log*).
عندما تواجه مشكلة، من المهم ألا تسبب أذى آخر في حين تعزل المشكلة الاولية وتصلحها. يؤدي إعادة تشغيل CMTS أو إعادة تشغيل CNR إلى حدوث زيادات فورية في الأحمال أثناء الوقت الذي يكون فيه النظام هشا بالفعل. يتمثل الهدف في إعادة تشغيل النظام لديك بشكل كامل مرة أخرى في أقصر فترة زمنية. الوقت المنقضي حتى يتم حساب الإجراء الأخير؛ الوقت إلى الإجراء الأول غير محسوب. وبكلمات أخرى، لا تتخذوا إجراء سريعا لمجرد العمل السريع. فكر قبل أن تتصرف.
ابدأ سجلا بكافة الخطوات التي تم إتخاذها وجميع التغييرات التي تم إجراؤها في أي مكان في النظام: خوادم DHCP أو DNS أو TFTP، والتغييرات التي تم إجراؤها على أي من أجهزة CMTS أو مودم الكبل. صف المشكلة وسجل، بالتفصيل، السلوك القابل للملاحظة فقط.
تجميع السجلات (/var/nwreg2/log). حللها، بحثا عن أخطاء أو تحذيرات. أستخدم محرر نصوص لمزيد من تحليل الأخطاء ذات الأهمية. بداية من الخطأ، ابحث مرة أخرى في السجل عن كل الإدخالات المتعلقة بعنوان MAC أو عنوان IP أو اسم المجال المرتبط بالخطأ.
قد تحتاج إلى تشغيل التسجيل الإضافي لتشخيص مشاكل DHCP. يدعم خادم DHCP نطاقا واسعا من إمكانيات التسجيل. ارجع إلى مراجع أوامر واجهة سطر الأوامر (CLI) الخاصة ب CNR للحصول على قائمة بخيارات التسجيل وشرح لكل منها. كن حذرا، حيث أن كل رسالة سجل تضع التحميل على الخادم. يجب إجراء مقايضة بين مقدار المعلومات التي تطلبها من CNR لتسجيل أداء الخادم.
قد تكون المشكلة في خادم LDAP. يقوم CNR بإنشاء قائمة انتظار من الطلبات إلى خادم LDAP. إذا تعذر على خادم LDAP مواكبة التحميل، سيتم إنشاء قائمة الانتظار. ابحث في دليل /var/nwreg2/data/dhcpeventstore. تم تثبيت ملفات مخزن الأحداث في الحجم، لذلك إذا كانت قائمة الانتظار قيد الإنشاء، يقوم CNR بإنشاء المزيد من الملفات. إذا كان هناك أكثر من ملف في الدليل، فإن ذلك يشير إلى أن قائمة الانتظار يتم نسخها إحتياطيا. يتم إستخدام نفس قائمة الانتظار في قوائم الانتظار للطلبات إلى خادم DNS، لذلك إذا كانت قائمة الانتظار تقوم بإجراء نسخ إحتياطي لها، وكنت تستخدم DDNS، فقد يتم ملء هذه القائمة بالطلبات إلى خادم DNS. لتحديد ما إذا كانت المشكلة مع LDAP، قم بتشغيل تسجيل واجهة CNR LDAP الإضافية. قم بتمكين علامات السجل ldap-create-detail، وldap-query-detail، وldap-update-detail. تتضمن رسالة السجل الطوابع الزمنية التي تساعدك على تحديد ما إذا كان LDAP هو إزدحام النظام أم لا.
إذا كنت تشك في أن المشكلة قد تكمن في أن واحدة أو أكثر من قواعد بيانات CNR الداخلية قد فقدت التكامل، ارجع إلى أدلة المستخدم CNR لمعرفة كيفية تشغيل أدوات مساعدة التحقق من صحة قاعدة البيانات. إذا دل أحد هذه الأدوات على مشكلة، استمر في اتباع التوجيهات في أدلة المستخدم لحلها.
يتم تضمين الأداة المساعدة nslookup مع أنظمة UNIX ومع Windows NT. يمكن إستخدامه لاستجواب خادم DNS وبالتالي فهو مفيد في التحقق من البيانات المخزنة بواسطة الخادم. توفر وثائق نظام التشغيل الخاص بك معلومات تفصيلية حول إمكانياته.