أستكشاف أخطاء أداء معالجة DOCSIS الخاصة ب RPD وإصلاحها

المقدمة

يوضح هذا المستند كيفية أستكشاف أخطاء أداء جهاز Cisco Remote PHY (RPD) وإصلاحها.

المتطلبات الأساسية

المتطلبات

توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:

• RPD
• الموجه Cisco Converged Broadband (cBR)-8
• البيانات عبر مواصفات واجهة خدمة الكبلات (DOCSIS)

المكونات المستخدمة

لا يقتصر هذا المستند على إصدارات برامج ومكونات مادية معينة.

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

معلومات أساسية

يتضمن السيناريو الوارد في هذه المقالة ملف RPD المزود من قبل Cisco cBR-8 كنظام الوصول إلى الكبلات المجمعة (CCAP). يتم إستخدام بروتوكول وقت الدقة (PTP) لمزامنة ساعة أساسية خارجية مع cBR-8 و RPD اللذين يعملان كثانويين. لمزيد من المعلومات حول كيفية تصميم PTP في هذه البيئة، يمكنك الرجوع إلى توصيات تصميم PTP لشبكات R-PHY.

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

استكشاف الأخطاء وإصلاحها

إذا لاحظت حدوث انخفاض في الأداء مع نشر RPD، وترغب في إجراء أستكشاف أولي للأخطاء وإصلاحها، فلن يكون من الواضح من أين تبدأ.

يصف هذا القسم بعض المشاكل الشائعة التي يمكن أن تكون السبب المحتمل لمشاكل أداء RPDs.

رسائل الخريطة المتأخرة

يحدث أحد حالات رسالة تخصيص مخطط عرض النطاق الترددي لتدفق عرض النطاق الترددي (MAP) المتأخر عندما يستقبل المودم رسالة MAP في نقطة زمنية معينة، بعد حدوث فتحات الوقت الموضحة في الرسالة بالفعل.  يتعذر على المودم إستخدام رسالة MAP هذه، وبالتالي يتعذر إرسال أي حركة مرور على المنح المعينة.

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

هناك عرض آخر يمكن أن يكون عمليات إسقاط الحزم عند إجراء إختبار اتصال docsis <MAC_ADDR>من cBR-8 إلى مودم متصل ب RPD.

باستخدام PHY (R-PHY) البعيد، يرسل cBR-8 رسائل الخريطة إلى أجهزة المودم في نفق واجهة PHY الخارجية (DEPI) لتدفق الخادم وإلى RPD في نفق واجهة PHY الخارجية للتدفق (UEPI). تحتوي هذه الرسائل على علامة جودة خدمة (QoS) أعلى مع قيمة نقطة رمز الخدمات (DSCP) المميزة التي تبلغ 46 (إعادة التوجيه السريع - EF).

إذا تم إسقاط رسالة MAP الموجهة ل RPD في CIN، فلن يتمكن RPD من إستخدام حقول الألغام هذه واعتبارها "غير معينة". إذا وصلت رسالة الخريطة متأخرة إلى RPD، فإنها في البداية تحسب المساحات الصغيرة على أنها غير معينة وبعد ذلك إستلمت آخر خريطة، إنها تزيد من تأخر عدد المساحات الصغيرة.

والخرائط الأولى ممكنة أيضا، لكنها لا تحدث عادة إلا عندما تكون ساعة PTP متوقفة إما في cBR-8 أو في RPD.

يمكن أن تحدث خرائط التداخل عندما تكون رسائل الخريطة خارجة عن التسلسل ولكن مع تردد 2 ميللي ثانية فقط، لا تكون هذه مشكلة عادة. يعتمد العدد الفعلي لقطع الصغيرة في رسالة MAP على تكوين مساحة صغيرة لكل قناة من قنوات الخادم. إذا كان المنبع يستخدم قرتين لكل قطعة صغيرة (شائعة ل 6.4 ميجاهرتز SC-QAM)، فإن الخريطة التي يبلغ حجمها 2 مللي ثانية تحتوي على 160 قطعة صغيرة.

للتحقق مما إذا كنت تتلقى رسائل متأخرة على RPD، قم بتنفيذ هذه الأوامر للوصول إلى وحدة تحكم RPD. بعد ذلك، قم بتشغيل الأمر show upstream map counter <rf port> <channel>عدة مرات وتحقق مما إذا كان العداد "Discard minislots (الخرائط المتأخرة)" يزيد:

cbr8# ssh <RPD_IP_ADDR> -l admin
R-PHY>enable
R-PHY#show upstream map counter 0 0
Map Processor Counters
==============================================
Mapped minislots                  :     553309
Discarded minislots (chan disable):          0
Discarded minislots (overlap maps):          0
Discarded minislots (early maps)  :          0
Discarded minislots (late maps)   :          0 <= check if the counter increases
Unmapped minislots                :          0
Last mapped minislot              :   21900956

ملاحظة: في كل مرة تقوم فيها بتشغيل عداد خريطة تدفق الأوامر، يتم إعادة تعيين جميع العدادات إلى 0 ولكن آخر قطعة صغيرة تم تعيينها

تلميح: من RPD الإصدار 6.x، يمكنك تشغيل الأمر show tech-support، الذي يجمع تكرارات متعددة لعداد خريطة تدفق أوامر أخرى، وبالتالي مفيدة لمقارنة العدادات.

إذا قمت بتشغيل برنامج RPD الإصدار 5.x أو أقل، فيمكنك تشغيل الأمر show tech باستخدام البرنامج النصي المتاح هنا: التقاط تقنية العرض على RPD أو أمر محدود على كل من RPD، المشرف.

تحتوي الصفحة المرتبطة على تعليمات حول كيفية تثبيت البرنامج النصي وأمثلة الاستخدام، والتي يمكنك في نهايتها العثور على الملف Script-Readme.tar المتوفر للتنزيل. يحتوي هذا الملف على البرنامج النصي sh_tech_rpd.tcl وملف sh_tech_rpd-readme.txt مع الإرشادات وأمثلة الاستخدام.

يحتوي البرنامج النصي على خيار (-c) لتجميع مجموعة إضافية من الأوامر المسرودة في ملف نصي، يتم قبول كل من الأوامر التي سيتم إصدارها على RPD نفسه وعلى المشرف cBR-8 (كل الإجراءات الموضحة في الرابط المذكور سابقا وملف القراءة).

هذه الميزة تستخدم هذا البرنامج النصي، بشكل مثير للاهتمام، أيضا في إصدارات RPD التي تتضمن الأمر show tech-support.

السبب المحتمل 1. تأخير CIN، زمن الانتقال، الرجفان

يمكن أن تؤدي شبكة الاتصال البيني المجمع (CIN) التي تربط بين CCAP Core و RPDs إلى حدوث تأخيرات يجب حسابها في مؤقت MAP المتقدم. إذا كان هناك تغيير في CIN، مثل إضافة موجه آخر على سبيل المثال، فمن المحتمل أن تكون قد أدخلت تأخيرا أعلى.

يستخدم CCAP مؤقت MAP المتقدم لمنع رسائل MAP المتأخرة. μ يستند هذا المؤقت إلى ميكروثانية (ثوان)، ويمكن تكوينه بشكل ثابت لكل واجهة كبل بواسطة المشغل، أو حسابه ديناميكيا بواسطة cBR-8.

القيمة الديناميكية، هي مجموع نقطة تقاطع وقت تدفق البيانات من الخادم (680 μ مع SC-QAM مع 256-QAM) وتأخير معالجة خريطة المودم (600 μ) وتأخر شبكة CCAP الداخلية (300 μ) وقيمة أمان تقدم الخريطة (1000 μ افتراضيا) والإزاحة الزمنية القصوى للمودم (استنادا إلى المودم الأكثر بعدا).

باستخدام R-PHY، يتم الآن إستبدال التأخير الداخلي ل CCAP بتأخير الشبكة، والذي يتم تعيينه افتراضيا على 500 μ. مع مراعاة تصميم CIN، يمكن أن تكون هذه القيمة أكبر من المعلمة الافتراضية ويمكن أن تتغير عبر الوقت.

يمكن عرض قيم متقدمة للخريطة لتدفق ما باستخدام هذا الأمر:

cbr8#show controllers upstream-Cable 2/0/5 us-channel 0 cdm-ump
<output omitted>
nom_map_adv_usecs 2899, max_map_adv_usecs 4080 mtn_map_adv 8080
map_adv_alg 1 dyn_map_adv_safety 1000 max_plant_delay 1800
cm_map_proc 600 intlv_delay 680 network_delay 500 max_tmoff 119
<output omitted>

MAPadvance = map_adv_safety (1000) + cm_map_proc (600) + intlv_delay (680) + network_delay (500)+ max_tmoff (119) = 2899 μ.

إذا كانت المسافة بين cBR-8 و RPD مجتمعة مع تأخيرات أجهزة CIN تتجاوز القيمة الافتراضية لتأخير الشبكة التي تبلغ 500 μ، فقد تكون رسائل الخريطة المتأخرة ممكنة.

هناك طريقتان للتعامل مع معلمة تأخير الشبكة الافتراضية عندما يمثل هذا مشكلة، ويتم تعيين كليهما لكل RPD على cBR-8:

• قم بتكوين التأخير بشكل ثابت.
• قم بتعيين cBR-8 لقياس التأخير وتعديله بشكل دوري.

يمكن تكوين تأخير الشبكة بشكل ثابت لكل RPD على cBR-8 كما هو موضح هنا:

cbr8#conf t
cbr8(config)#cable rpd <name>
cbr8(config-rpd)#core-interface <interface_name>
cbr8(config-rpd-core)#network-delay static <CIN_delay_in_us>

بالنسبة لتأخير الشبكة الديناميكي، يعتمد cBR-8 على ميزة قياس زمن الوصول تسمى DEPI Latency Measurements (DLM)، والتي تحدد التأخير باتجاه واحد في مسار تدفق البيانات من الخادم.

يرسل cBR-8 حزمة DLM مع الطابع الزمني الخاص به، ثم يقوم RPD بتعليم الطابع الزمني الخاص به على حزمة DLM عند إستلامه، وإعادة توجيهه إلى cBR-8.

لاحظ أن Cisco يدعم الخيار المطلوب حيث يقوم RPD بتعليم الحزمة الأقرب إلى واجهة الدخول الخاصة بها، وليس إلى المخرج.

يأخذ cBR-8 متوسط آخر 10 قيم DLM ويستخدمه كقيمة تأخير الشبكة في حساب تقدم الخريطة. تستند الطوابع الزمنية من كل من cBR-8 و RPD إلى ساعات مرجع PTP.

تحذير: إذا كان بروتوكول PTP غير مستقر، فكذلك قيم DLM وانتهى الأمر إلى مؤقت MAP advanced.

وبشكل افتراضي، يتم تعطيل DLM، ويمكن تمكينها باستخدام الأمر network-delay dlm <ثوان>كما هو موضح. وبمجرد تمكينها، يتم إرسال حزمة DLM إلى RPD بشكل دوري وفقا للقيمة التي تم تكوينها.

هناك أيضا خيار القياس فقط الذي يمكن إضافته، والذي يقوم فقط بقياس تأخر CIN دون تعديل قيمة تأخير الشبكة.

يوصى بتمكين DLM على الأقل في المعلمة measure-only، من أجل مراقبة تأخير CIN.

cbr8#conf t
cbr8(config)#cable rpd <name>
cbr8(config-rpd)#core-interface <interface_name>
cbr8(config-rpd-core)#network-delay dlm <interval_in_seconds> [measure-only]

Usage:

cbr8#show cable rpd a0f8.496f.eee2 dlm
DEPI Latency Measurement (ticks) for a0f8.496f.eee2
  Last Average DLM:              481
  Average DLM (last 10 samples): 452
  Max DLM since system on:       2436
  Min DLM since system on:       342
  Sample #     Latency (usecs)
  x------------x------------
  0            52
  1            41
  2            48
  3            41
  4            41
  5            44
  6            40
  7            45
  8            44
  9            41

يمكن العثور على مزيد من المعلومات حول هذه الميزة هنا، قياس زمن انتقال DEPI

كما يمكن تغيير أمان MAP المتقدم يدويا في تكوين واجهة الكبل (القيم الافتراضية هي 1000 μ لعامل الأمان و 18000 μ لتقدم الخريطة الأقصى):

cbr8#conf t
cbr8(config)#interface Cable1/0/0
cbr8(config-if)# cable map-advance dynamic 1000 18000

OR (if a mac-domain profile is used)

cbr8#conf t
cbr8(config)# cable profile mac-domain RPD
cbr8(config-profile-md)# cable map-advance dynamic 1000 18000

تحذير: يمكن أن تتسبب التأخيرات القصيرة جدا في رسائل الخريطة المتأخرة

تمت ملاحظة مشاكل مع حركة مرور DOCSIS المسقطة عند انخفاض مؤقت تقدم الخريطة عن 2500 μ.

قد تستغرق بعض أجهزة المودم وقتا أطول لمعالجة رسائل MAP، وقد يؤدي هذا التأخير الإضافي إلى تأخر رسائل MAP لهذه الأجهزة (قد لا يظهر RPD عدد مرات MAP المتأخرة إذا كان قادرا على الحصول على الرسالة في الوقت المناسب).

يمكن إستخدام مؤقت متقدم منخفض الخريطة مع قيم DLM منخفضة جدا، أو مع تأخر شبكة يدوي منخفض أو تكوين أمان متقدم للخريطة. يمكن أن تكون قيم تأخير الشبكة في حساب تقدم الخريطة أقل من 30 μ (حتى إذا كان متوسط DLM أقل).

يوصى باستخدام خيار "القياس فقط" الخاص ب DLM أو زيادة عامل الأمان لتقدم "الخريطة الديناميكية" حتى يبلغ موقت تقدم "الخريطة" أكثر من 2500 μ.

السبب المحتمل 2. خطأ برمجي

للتحقق من ما إذا كان خطأ برنامج يتسبب في فشل مزامنة، فمن المستحسن فتح طلب خدمة مع Cisco لمزيد من التحقق من الحالة المحددة.

غالبا ما يكون الحل في حالة إصابة أحد أعطال البرامج بترقية برنامج إلى أحد الإصدارات التي تحتوي على الإصلاح. نظرا لوجود إرتباط توافق بين إصدارات برامج cBR-8 و RPD، فمن المهم إختيار الإصدار المناسب لكلا الجهازين.

للمساعدة في إختيار Cisco IOS® XE الصحيح لكل برنامج RPD، يمكنك العثور على توافقات إصدار البرنامج بين cBR-8 و RPD في أدلة تثبيت وترقية Cisco Remote PHY.

في هذا الجدول، يمكنك العثور على ملخص لتوافق إصدار البرنامج بين cBR-8 و RPD، مع إصدارات البرامج المتاحة في وقت الكتابة:

توافق الإصدار بين Cisco cBR-8 و Cisco RPD
إصدار Cisco cBR-8	إصدار إصدار RPD المتوافق
Cisco IOS® XE Everest، الإصدار 16.6.x	برنامج Cisco 1x2 RPD 2.x
Cisco IOS® XE Fuji 16.7.x	برنامج Cisco 1x2 RPD، الإصدار 3.x
Cisco IOS® XE Fuji، الإصدار 16.8.x	برنامج Cisco 1x2 RPD، الإصدار 4.x
Cisco IOS® XE Fuji 16.9.x	برنامج Cisco 1x2 RPD 5.x
Cisco IOS® XE Gibraltar، الإصدار 16.10.1c	برنامج Cisco 1x2 RPD 6.1 و 6.2 و 6.3
Cisco IOS® XE Gibraltar، الإصدار 16.10.1d	برنامج Cisco 1x2 RPD، الإصدار 6.4 و 6.5 و 6.7
Cisco IOS® XE Gibraltar، الإصدار 16.10.1f	برنامج Cisco 1x2 RPD، الإصدار 6.6 و 6.7
Cisco IOS® XE Gibraltar، الإصدار 16.10.1g	برنامج Cisco 1x2 RPD 7.1 و 7.2 و 7.3 و 7.4.x و 7.5
Cisco IOS® XE Gibraltar، الإصدار 16.12.1	برنامج Cisco 1x2 RPD 7.1 و 7.2 و 7.3 و 7.4.x و 7.5
Cisco IOS® XE Gibraltar، الإصدار 16.12.1w	برنامج Cisco 1x2 RPD 7.1 و 7.2 و 7.3 و 7.4.x و 7.5
Cisco IOS® XE Gibraltar، الإصدار 16.12.1x	برنامج Cisco 1x2 RPD، الإصدار 7.6 و 7.7
Cisco IOS® XE Gibraltar، الإصدار 16.12.1y	برنامج Cisco 1x2 RPD 7.8، 7.8.1، 8.2
Cisco IOS® XE Gibraltar، الإصدار 16.12.1z	برنامج Cisco 1x2 RPD 8.3 و 8.4 و 8.5
Cisco IOS® XE Gibraltar، الإصدار 17.2.1	برنامج Cisco 1x2 RPD 8.1 و 8.2 و 8.3 و 8.4 و 8.5

زمن انتقال المنبع

كما تمت مناقشته في القسم السابق، قد تتسبب التأخيرات الطويلة للإدخال في المصنع في حدوث مشاكل في رسائل الخريطة المتأخرة، ويمكن معالجتها باستخدام زيادة مؤقت MAP المتقدم. وهذا بدوره يؤدي إلى تأخير أطول في منح الطلب، مما يؤدي إلى زيادة زمن الوصول إلى الخادم.

بما أن تدفقات حركة مرور البيانات الثابتة من الخادم تستخدم طلبات تدفق البيانات، فيمكن أن يظهر إختبار سرعة حركة مرور البيانات من الخادم بشكل طبيعي، كما أن تدفق الصوت باستخدام خدمة المنح غير المرغوب فيها (UGS) لا يتأثر، نظرا لعدم الحاجة إلى أي طلبات.

ومع ذلك، يمكن تقليل سرعات حركة مرور TCP من الخادم بسبب نقص وحدات التحكم في الوصول (ACK) إلى الخادم في الوقت المناسب. على الرغم من أنه من الممكن معالجة حالات التأخير في المعالجة والانتظار على CIN، إلا أنه من غير المرجح أن تجعل الإشارات تنتقل بسرعة أكبر عبر مسافة معينة.

قامت Cisco بتطوير الجدولة التنبؤية DOCSIS (DPS) للحد من تأخر منح الطلب في تطبيقات R-PHY مع تأخيرات CIN أطول. توفر DPS منح بشكل استباقي لأجهزة المودم استنادا إلى الاستخدام السابق، وذلك لتقليل تأخر منح الطلب.

DPS هي طريقة جدولة سابقة للمعايير، مشابهة لخدمة المنح الاستباقية (PGS) الموضحة في مواصفات DOCSIS (LLD) التي تتميز بزمن وصول أقل مؤخرا.  ومع ذلك، يمكن تمكين DPS لكل واجهة وتطبيقها على جميع تدفقات خدمة البث الخاصة بأفضل الجهود. يتم تطبيق PGS على حركة المرور كنوع تدفق الخدمة، لذلك فإنها تتطلب تغييرات في ملف تكوين المودم.

يمكن تمكين DPS باستخدام أمر الواجهة: cbr8(config-if)#cable upstream dps

على الرغم من توفر DPS منذ إضافة دعم R-PHY إلى cBR-8، إلا أنها ليست ميزة مدعومة رسميا في الوقت الحالي. ومع ذلك، يمكن أن تكون DPS فعالة لحل معدل إخراج إخراج TCP من الخادم البطيء المرتبط بوحدات ACK المتأخرة.

حزم بروتوكول الاتصال النفقي للطبقة 2 (L2TP) خارج الأمر

على وحدة تحكم RPD، اكتب هذا الأمر عدة مرات للتحقق من ما إذا كان العددان "SeqErr-pkts" و"SeqErr-sum-pkts" موجبين وزياديين، وهو إشارة إلى حزم L2TP الخارجة عن الترتيب:

R-PHY# show downstream channel counter dpmi
Chan Flow_id SessionId(dec/hex)      Octs       Sum-octs   SeqErr-pkts SeqErr-sum-pkts
0    0       4390912    / 00430000   328        22770      0           1         
0    1       4390912    / 00430000   25074      1179672    0           1         
0    2       4390912    / 00430000   6022168    271459412  0           1         
0    3       4390912    / 00430000   0          0          0           0      

السبب المحتمل 1. رصيد الحمل

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

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

السبب المحتمل 2. عمليات إسقاط الحزمة

1. تحقق من وجود أي أخطاء وحالات إسقاط متزايدة على عدادات cBR-8 على واجهة بطاقة DPIC حيث يكون RPD متصلا، باستخدام أمر show interface كما هو موضح هنا.

cbr8#sh run | s cable rpd SHELF-RPD0
cable rpd SHELF-RPD0
 description SHELF-RPD0
 identifier a0f8.496f.eee2
[…]
 core-interface Te6/1/2
[…]
cbr8#show interface Te6/1/2
TenGigabitEthernet6/1/2 is up, line protocol is up
  Hardware is CBR-DPIC-8X10G, address is cc8e.7168.a27e (bia cc8e.7168.a27e)
  Internet address is 10.27.62.1/24
  MTU 1500 bytes, BW 10000000 Kbit/sec, DLY 10 usec,
     reliability 255/255, txload 90/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full Duplex, 10000Mbps, link type is force-up, media type is SFP_PLUS_10G_SR
  output flow-control is on, input flow-control is on
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:01, output 00:00:05, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/375/0/22 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 1002000 bits/sec, 410 packets/sec
  5 minute output rate 3535163000 bits/sec, 507528 packets/sec
     88132313 packets input, 26831201592 bytes, 0 no buffer
     Received 0 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 229326 multicast, 0 pause input
     179791508347 packets output, 164674615424484 bytes, 0 underruns
     0 output errors, 0 collisions, 1 interface resets
     13896 unknown protocol drops
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 pause output
     0 output buffer failures, 0 output buffers swapped out

2. تحقق من جانب RPD إذا كانت هناك أخطاء وإفلات وحزم خارج الأمر على الواجهات وعدادات تدفق البيانات من الخادم.

R-PHY#show interface info
eth0      Link encap:Ethernet  HWaddr A0:F8:49:6F:EE:E4
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::a2f8:49ff:fe6f:eee4/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:303 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:44034 (43.0 KiB)
          Memory:1ae2000-1ae2fff
vbh0      Link encap:Ethernet  HWaddr A0:F8:49:6F:EE:E2
          inet addr:10.7.62.7  Bcast:10.7.62.255  Mask:255.255.255.0
          inet6 addr: fe80::a2f8:49ff:fe6f:eee2/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1174200 errors:0 dropped:0 overruns:0 frame:0
          TX packets:593404 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:90888838 (86.6 MiB)  TX bytes:52749774 (50.3 MiB)
vbh1      Link encap:Ethernet  HWaddr A0:F8:49:6F:EE:E3
          inet6 addr: fe80::a2f8:49ff:fe6f:eee3/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:2438 (2.3 KiB)

R-PHY#show downstream channel counter

------------------- Packets counter in TPMI -------------------

Level     Rx-pkts    Rx-sum-pkts
Node Rcv  4673022    2108792873
Depi Pkt  1696       774495

Port Chan SessionId(dec/hex)    Rx-pkts    Rx-sum-pkts
DS_0 0    4390912    /0x00430000 49032      22125274
DS_0 1    4390913    /0x00430001 49025      22116541
[…]
US_0 0    13893632   /0x00D40000 12193      5502543
US_0 1    13893633   /0x00D40001 12193      5501739
[…]

Port      Rx-pkts    Rx-sum-pkts Drop-pkts  Drop-sum-pkts
DS_0      3095440    1396529318  0          0
US_0      49215      22207507    0          0
US_1      0          4679        0          0

------------------- Packets counter in DPMI -------------------

Field        Pkts       Sum-pkts
Dpmi Ingress 12275995   1231753344
Pkt Delete   0          0
Data Len Err 0          0

Chan Flow_id SessionId(dec/hex)      Octs       Sum-octs   SeqErr-pkts SeqErr-sum-pkts
0    0       4390912    / 0x00430000   75         130496     0           1
0    1       4390912    / 0x00430000   15657      7208826    0           1
0    2       4390912    / 0x00430000   3181212    1431951867 0           1
0    3       4390912    / 0x00430000   0          0          0           0
[…]

------------------- Packets counter in DPS -------------------

Chan Tx-packets Tx-octets  Drop-pkts  Tx-sum-pkts Tx-sum-octs Drop-sum-pkts
0    50316      3273636    0          22126173    1439340721  0
1    50311      3272896    0          22117442    1438506648  0
2    50311      3272640    0          22121500    1438772715  0
3    50309      3272640    0          22122038    1438807607  0
[…]

3. تحقق من عدادات InterLaken لتدفق البيانات عدة مرات لمعرفة ما إذا كانت هناك أخطاء وما إذا كانت العدادات تتزايد. للقيام بذلك، يلزمك إدخال واجهة وحدة تحكم بطاقة الخط كما هو موضح هنا.

cbr8#request platform software console attach 6/0
#
# Connecting to the CLC console on 6/0.
# Enter Control-C to exit the console connection.
#
Slot-6-0>enable
Slot-6-0#
Slot-6-0#test jib4ds show ilkstat ?
  <0-3>  ILK Link (0-BaseStar0, 1-BaseStar1, 2-Cpu0, 3-Cpu1)

Slot-6-0#test jib4ds show ilkstat 0
Send Show-ilkstat IPC to CDMAN...Wait for output

Slot-6-0#
Jib4DS InterLaken Stats for BaseStar 0:
                    RX-Packets             RX-Bytes            TX-Packets             TX-Bytes
HUB Stats:         10425879607       14415939325556              75237425           8249683443
Chan    0:             4714787            360160866                109750             36594720
Chan    1:         10254597081       14397444921888                     0                    0
Chan    3:               63828             17214818                     0                    0
Chan    5:           166503829          18117169182              75127675           8213088761
PRBS  Err:                   0                    0                     0                    0
CRC32 Err:                   0                    0                     0                    0
CRC24 Err:                          0
Test-pattern-err:                   0

ILK Error log: ptr 0
Idx      Err1     Err2      Rst     Gtx0     Gtx1     Gtx2     Gtx3

Slot-6-0#

4. قم بأخذ مودم متصل ب RPD هذا (قنوات DS مرتبطة فقط)، وأرسل الحزم (على سبيل المثال، إختبارات الاتصال) إليه، للتحقق من ما إذا كانت الحزم المرسلة تطابق التدفق المتدفق المتدفق من الخادم على عدادات وحدة GBU النمطية. تأكد من أن DS Cube أرسل جميع حزم بيانات DS لإطار DEPI على وحدة تحكم بطاقة الخط. في هذا الإخراج، يمكنك رؤية كيفية رؤية رقم تسلسل الحزمة من إخراج تدفق خدمة المودم. يزداد رقم التسلسل هذا لكل حزمة بيانات يتم إرسالها.

Slot-6-0#show cable modem 2cab.a40c.5ac0 service-flow verbose | i DS HW Flow
DS HW Flow Index			: 12473
Slot-6-0#test jib4ds show flow 12473
Send Show-FLOW IPC to CDMAN flow 12473 seg 6...Wait for output

Slot-6-0#
Jib4DS Show Flow: [Bufsz 4400]: HW Flow id:12473 [0x30b9] for segment 0
Valid        : TRUE
DSID         :            3 [       0x3]
Priority     :            0
Bonding Group:           62 [      0x3e]
Channel      :        65535 [    0xffff]
DS-EH        :            3 [       0x3]
Data Prof 1  :            0 [         0]
Data Prof 2  :            0 [         0]
No Sniff Enabled.

Slot-6-0#test jib4ds show dsid 3
Send Show-DSID 3 10 IPC to CDMAN...Wait for output

Slot-6-0#

Jib4DS DSID entry for DSID 3 [Bufsz 4400]:
SCC Bit         = 0x0
Sequence Number = 8

إرسال بعض إختبارات الاتصال إلى هذا المودم من سطر الأوامر cBR-8، على نافذة أخرى:

cbr8#ping 10.0.0.3 rep 100
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 4/7/27 ms
cbr8#

تحقق من دلتا بعد الاختبار:

Slot-6-0#test jib4ds show dsid 3
Send Show-DSID 3 10 IPC to CDMAN...Wait for output

Slot-6-0#

Jib4DS DSID entry for DSID 3 [Bufsz 4400]:
SCC Bit         = 0x0
Sequence Number = 108

حساب الدلتا بعد الاختبار: العداد غير موقع ب 16 بت، لذلك إذا تم تجاوز العداد، سيلزم حساب الدلتا بهذه الصيغة:

(Initial Sequence Number + Number of Packets Sent) % 65536

مثال:

Initial Sequence Number = 50967

Final Sequence Number = 2391

Packets sent: 1000000




(50967+1000000)%65536 = 2391 <== Good, no packet was dropped before DEPI frame.

نتيجة لطبيعة عمليات الإسقاط، يمكن أن تكون المشكلة في CIN (على سبيل المثال، إرتباطات عنق الزجاجة والاصطدام وأخطاء CRC) التي تحتاج إلى مزيد من التحقيق في شبكة CIN بين cBR-8 و RPD. إذا تم ملاحظة عمليات إسقاط في النقطتين 3 و 4 بدلا من ذلك، فيوصى بإشراك Cisco لمزيد من التحقيق في cBR-8.

فقدان PTP أو إلغاء تأمينه بشكل دوري

وكما تعلمون على الأرجح، فإن بروتوكول PTP ضروري لعمليات RPD العادية. لذلك، يجب أن يكون لحزم PTP أولوية عالية في جودة الخدمة، ولا تعد عمليات إسقاط حزم PTP علامة جيدة.

على وحدة تحكم RPD، يمكنك عرض إحصائيات PTP، والتحقق من أن العدادات "طلب التأخير" و"تأخير الاستجابة" متطابقة بشكل وثيق. إذا رأيت فجوة كبيرة بدلا من ذلك، فقد تكون مؤشرا على حالات سقوط PTP في الشبكة:

R-PHY#show ptp clock 0 statistics
 AprState    4  :
           2@0-00:06:25.877          1@0-00:06:16.234          0@0-00:03:42.629
           4@0-00:03:23.428
ClockState  5  :
           5@0-00:07:02.932          4@0-00:06:59.145          3@0-00:06:55.657
           2@0-00:06:26.657          1@0-00:06:25.834
BstPktStrm  1  :
           0@0-00:03:21.014
SetTime     1  :
  1000000000@0-00:03:24.776
StepTime    1  :
  -560112697@0-00:05:39.401
AdjustTime  44 :
          -8@0-00:52:03.776         -5@0-00:51:02.776          4@0-00:50:01.776
          -6@0-00:49:00.776         11@0-00:47:59.776          1@0-00:45:57.776
           5@0-00:44:56.776         -7@0-00:43:55.776        -22@0-00:42:54.776
streamId  msgType           rx          rxProcessed     lost        tx
0        SYNC              47479       47473           0           0
0        DELAY REQUEST     0           0               0           47473
0        P-DELAY REQUEST   0           0               0           0
0        P-DELAY RESPONSE  0           0               0           0
0        FOLLOW UP         0           0               0           0
0        DELAY RESPONSE    47473       47473           0           0
0        P-DELAY FOLLOWUP  0           0               0           0
0        ANNOUNCE          2974        2974            0           0
0        SIGNALING         34          34              0           32
0        MANAGEMENT        0           0               0           0
  TOTAL                    97960       97954           0           47505

ملاحظة: في cBR-8، يتمتع بروتوكول PTP بأعلى أولوية للساعة، مما يعني أنه بمجرد تكوينه، يتم إستخدامه حتى لبطاقات خطوط التردد اللاسلكي. وبالتالي، قد يتسبب مصدر غير موثوق في حدوث مشكلات عبر الهيكل بأكمله.

للحصول على مزيد من المعلومات حول تكوين ساعة PTP واستكشاف أخطاء هذه العملية وإصلاحها، يمكنك قراءة المقال توصيات تصميم PTP لشبكات R-PHY.

سين مزدحم

يمكن إعتبار CIN كامتداد لمستوى التحكم الخاص ب CCAP core، لذلك إذا كان هناك 1000 ميجابت في الثانية من DOCSIS وحركة مرور الفيديو في الخادم ل RPD محدد، فيجب تخصيص سعة كبيرة في CIN، بالإضافة إلى بعض السعة الإضافية الخاصة بالنفقات العامة ل L2TPv3 المستخدمة من قبل أنفاق DEPI.

إن هناك إزدحام في ال cin، بعد ذلك بعض ربط يستطيع كنت أخرت أو فقدت.

السبب المحتمل 1. جودة الخدمة

بشكل افتراضي، يقوم cBR-8 و RPDs بوضع علامة على الحزم المرتبطة بحركة مرور PTP ورسائل الخريطة باستخدام DSCP 46 (EF).  تستخدم رسائل التحكم في DOCSIS الأخرى مثل واصفي قناة البث (UCD) وطلب عرض النطاق الترددي للمودم واستجابة النطاق أيضا DSCP 46:

العنصر	سلوك كل خطوة (PHB)	قيمة DSCP
بيانات DOCSIS (L2TP)	بذل قصارى الجهود	0
PTP	EF	46
GCP	بذل قصارى الجهود	0
الخريطة/UCD (L2TP، التحكم في DOCSIS)	EF	46
BWR و RNG-Reg	EF	46
الفيديو	سي إس 4	32
MDD (L2TP، التحكم في DOCSIS)، الصوت	سي إس 5	40

المصدر: دليل تكوين برنامج Cisco Remote PHY Device ل Cisco 1x2 / Compact Shelf RPD Software 5.x

يجب أن تكون CIN على دراية بجودة الخدمة، لذلك تواجه هذه الحزم ذات الأولوية العالية حدا أدنى من التأخير.

أدى الازدحام الذي يؤدي إلى إنشاء حزم مسقطة أو تأخيرات طويلة في قائمة الانتظار إلى إنشاء مشاكل في PTP ورسائل خريطة متأخرة وسعة معالجة أقل. يمكن رؤية هذه الأنواع من المشاكل من خلال ملاحظة قوائم انتظار الواجهة على أجهزة cBR-8 و RPD و CIN.

إذا تم إسقاط رسائل PTP أو MAP أو تأخيرها، كما هو موضح مع عدم إستقرار الساعة أو رسائل MAP المتأخرة، فيجب معالجة سعة CIN أو تصميم جودة الخدمة، نظرا لأنه يتم إرسالها بأولوية عالية.

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

السبب المحتمل 2. حركة مرور متأخرة لأفضل الجهود

حاليا، علامات حزمة DLM غير قابلة للتكوين وتستخدم أفضل الجهود (DSCP 0). هناك حالات حيث يختبر CIN إزدحام يؤدي إلى تأخر طويل في قائمة الانتظار يقتصر على أفضل حركة مرور للجهد.

وعادة ما يظهر هذا كمعدلات مرور بيانات منخفضة عند تدفق تدفق TCP، حيث يمكن أن تتسبب تأخيرات CIN في حدوث حالات انخفاض كبير نسبيا في السرعة بسبب رسائل التحكم في الوصول (ACK) المفقودة أو المتأخرة إلى الخادم.

في هذه الحالة، لا يلاحظ أي رسائل خريطة متأخرة أو مشاكل PTP، لأن هذه الحزم ذات الأولوية العالية لا تتأخر.

ونظرا لأنه يتم وضع علامة على حزم DLM كأفضل حركة مرور للجهد، فإن هذا النوع من رجفان CIN يمكن أن يتسبب في حدوث زيادات هائلة في قيم DLM. إذا تم إستخدام DLM لضبط تأخير الشبكة بشكل ديناميكي، فقد يتسبب هذا التشوه في زيادة غير ضرورية في مؤقت MAP المتقدم، مما يؤدي إلى زيادة حالات تأخير منح الطلب عند الخادم.

في هذه الحالة، يوصى باستخدام قيمة تأخير شبكة ثابتة. تبحث Cisco أيضا في الخيارات الخاصة بتمكين قيم DSCP فيما وراء أفضل جهد فقط على DLM في الإصدارات المستقبلية. يمكن أن يساعد هذا على تقليل تأخر منح طلب البث ولكن من المحتمل ألا يعالج مشاكل معدل إخراج بروتوكول TCP إذا تم تأخير وحدات ACK عبر CIN.

معلومات ذات صلة

• قياس زمن وصول DEPI
• توصيات تصميم PTP لشبكات R-PHY
• الدعم التقني والمستندات - Cisco Systems