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

المقدمة

يصف هذا وثيقة كيف أن يتحرى EGTP ممر إخفاق إصدار.

نظرة عامة

تشير حالات فشل مسار بروتوكول GPRS المتطور (EGTP) إلى مشاكل في مسار الاتصال بين عقد GTP في شبكة متنقلة. GTP هو بروتوكول يستخدم في نقل بيانات المستخدم ورسائل إرسال الإشارات بين عناصر الشبكة المختلفة.

الأسباب المحتملة لفشل مسار EGTP

1. مشكلة إمكانية الوصول - مشاكل اتصال الشبكة

2. إعادة تشغيل تغييرات قيم العداد

3. طلب حركة مرور قادم ضخم - إزدحام الشبكة

4. مشكلة التكوين من حيث DSCP/جودة الخدمة وما إلى ذلك

5. لا يوجد مشتركون/جلسات على إرتباط EGTPC

السجلات المطلوبة

1. محركات الأقراص المزودة بذاكرة مصنوعة من مكونات صلبة (SSD)/syslogs حول وقت إشكالي يغطي الإطار الزمني قبل ساعتين على الأقل من بدء المشكلة حتى الوقت الحالي.

2. تأكيد إمكانية الوصول باستخدام السجلات، أي إختبار الاتصال و traceroute للمسار الذي يتم رؤية حالات فشل المسار له.

3. التحقق من التكوين بين العقد التي تنطوي على مشاكل وتلك التي لا تنطوي على مشكلات.

4. ضرورة التأكيد على ما إذا كانت هناك أي زيادة مفاجئة في حركة المرور أو أي زيادة في الرفض على نفس المسار.

5. البوكستات خلال الأوقات الإشكالية التي تغطي الإطار الزمني قبل القضية بيومين أو ثلاثة أيام على الأقل.

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

show egtpc peers interface

show egtpc peers path-failure-history

show egtpc statistics path-failure-reasons

show egtp-service all

show egtpc sessions

show egtpc statistics

egtpc test echo gtp-version 2 src-address <source node IP address>  peer-address <remote node IP address>

For more details related to above command refer doc as mentioned below

https://www.cisco.com/c/en/us/support/docs/wireless-mobility/gateway-gprs-support-node-ggsn/119246-technote-ggsn-00.html

إختبارات SNMP:

Sun Feb 05 03:00:20 2023 Internal trap notification 1112 (EGTPCPathFail) context s11mme, service s11-mme, interface type mme, self address x.x.x.x.,  peer address 10.0.219.57, peer old restart counter 4,  peer new restart counter 4,  peer session count  240, failure reason no-response-from-peer,  path failure detection Enabled

Tue Jul 09 18:41:36 2019 Internal trap notification 1112 (EGTPCPathFail) context pgw, service s5-s8-sgw-egtp, interface type sgw-egress, self address x.x.x.x,  peer address x.x.x.x, peer old restart counter 27,  peer new restart counter 27,  peer session count  1, failure reason no-response-from-peer,  path failure detection Enabled

السيناريو/الأسباب بإيجاز

مشكلة إمكانية الوصول - مشاكل اتصال الشبكة

تحدث مشاكل إمكانية الوصول عندما يمكن أن تكون مشكلة في مسار المسار في نهاية الموجه أو في جدار الحماية بين SGSN/MME و SPGW/GGSN.

ping <destination IP>

traceroute <destination IP> src <source IP>

إعادة تشغيل تغييرات قيم العداد

يحافظ مسار EGTP على عدادات إعادة التشغيل في كلا طرفي المسار بين SGSN/MME و GGSN/SPGW.

ارجع إلى الارتباط https://www.cisco.com/c/en/us/support/docs/wireless/asr-5000-series/200026-ASR-5000-Series-Troubleshooting-GTPC-and.html لفهم هذا النوع من المشاكل بالتفصيل.

طلب حركة مرور وارد ضخم - إزدحام الشبكة

كلما وجدت حركات حركة مرور عالية مفاجئة، تكون هناك فرصة لإنزال حزم EGTP Tx و Rx. عمليات التحقق الأساسية لتأكيد هذا السيناريو:

1. يجب التحقق مما إذا كان هناك أي إستخدام عال لوحدة المعالجة المركزية (CPU) ل egtpinmgr.

Mar 25 14:30:48 10.224.240.132 evlogd: [local-60sec48.142] [resmgr 14907 debug] [6/0/10088 <rmmgr:60> _resource_log.c:1391] [software internal system critical-info syslog] RM-60: rmmgr_collect_cpustats_coproc_done: ahm cpustats logged for egtpinmgr instance 2 in cpu warn state file <cpustats-5e7b40db-06-00-egtpinmgr-2-6192>
Mar 25 14:31:05 10.224.240.132 evlogd: [local-60sec5.707] [resmgr 14907 debug] [6/0/10088 <rmmgr:60> _resource_log.c:1391] [software internal system critical-info syslog] RM-60: rmmgr_collect_cpustats_coproc_done: ahm cpustats logged for egtpinmgr instance 2 in cpu warn state file <cpustats-5e7b40f9-06-00-egtpinmgr-2-6192>

2. تحقق مما إذا كان طلب/إستجابة الارتداد معطلا (تمت مشاركة الأمر سابقا).

3. يمكن التحقق من وجود أي عمليات إسقاط حزم من بطاقة العرض.

يجب أن تمر جميع حركة مرور EGTP الواردة من خلال نفس egtpmgr. إذا تم ملاحظة فشل المسار مع عقدة واحدة، فإن حجم حركة المرور الواردة ربما يرتفع. و، يمكنك تجربة انخفاض حركة المرور على مستوى عملية egtpmgr. حتى العملية التي تشترك في الموقع يجب أن تتم من خلال نفس قائمة انتظار EGTPMGR وأن تتأثر.

هنا الخطوة للتحقق من فقدان الحزمة الذي يجب أخذه مع تكرارات متعددة

debug shell card <> cpu 0

cat /proc/net/boxer



******** card1-cpu0 /proc/net/boxer *******
Wednesday March 25 17:34:54 AST 2020
what                   total_used next    refills     hungry  exhausted  system_rate_kbps      system_credits    max_bhn
bdp_rld           4167990936249KB  094   51064441        292          1  3557021/65000000 7825602KB/7934570KB   793457KB
what                 bhn local            remote                   ver         rx    rx_drop         tx    tx_drop    no_dest     no_src
total cpu 34         *   *                *                          *    3274522         59         60          0    1307242          0
total cpu 35         *   *                *                          *    6330639         46        121          0    1086591          0
total cpu 46         *   *                *                          *    5076520         27      15524          0     786982          0
total cpu 47         *   *                *                          * 4163101019      83922  133540922          0     886241          0

4. يجب التقاط إخراج منشئ ملفات تعريف وحدة المعالجة المركزية (CPU) الخاص ب egtpinmgr إذا رأيت وحدة معالجة مركزية (CPU) عالية ل egtpinmgr.

إذا كانت جميع الشروط المذكورة أعلاه صحيحة، فيمكنك البحث عن الحل المحتمل المذكور.

الحل

1. زيادة مهلة صدى EGTP - إذا لم تساعد 5 ثوان، يمكنك تجربة 15 أو 25. يمكنك مناقشة هذا الأمر مع فريق AS لديك لمعايرة هذا.

2. تقليل مهلة خلاص النظير - كلما انخفضت قيمة المهلة، قل عدد النظراء غير النشطين، لذلك، يمكنك تغيير قيمة الوقت باستخدام هذا الأمر:

gtpc peer-salvation min-peers 2000 timeout 24

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

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

4. لا يوجد مشتركون/جلسات على إرتباط EGTPC - عند عدم وجود جلسات عبر نفق محدد، يتم إيقاف وظيفة صدى GTP. إذا كان هناك مشترك متصل صفر/لا، فيجب عدم إرسال صدى GTPC.

فيما يلي الأخطاء التي تراها عند إيقاف وظيفة الارتداد:

2019-Jul-26+08:41:51.261 [egtpmgr 143047 debug] [1/0/4626 <egtpinmgr:2> egtpmgr_pm.c:798] [context: EPC, contextID: 2]  [software internal system syslog] service : S5-S8-PGW - GTP-C Periodic ECHO timer stopped for peer address 10.2.1.51
2019-Jul-26+08:41:51.261 [egtpmgr 143048 debug] [1/0/4626 <egtpinmgr:2> egtpmgr_pm.c:818] [context: EPC, contextID: 2]  [software internal system syslog] service : S5-S8-PGW - GTP-C ECHO stopped towards peer 10.2.1.51

الحل

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

يجب أن تستغرق هذه العملية أقل من ثانية واحدة حتى تكتمل.

1. تعطيل اكتشاف فشل المسار:

    egtp-service S5-PGW

       no gtpc path-failure detection-policy

2. اقتل المهمة:

task kill facility egtpinmgr  all

3. قم بتمكين اكتشاف فشل المسار:

    egtp-service S5-PGW

       gtpc path-failure detection-policy

تغييرات التكوين

يمكن التحقق من التكوين فيما يتعلق بتعيين مسار/خدمة DSCP/Qos/EGTP.

سجلات التصحيح

(إذا لزم الأمر)

logging filter active facility egtpc level<critical/error/debug>
logging filter active facility egtpmgr level<critical/error/debug>
logging filter active facility egtpinmgr level<critical/error/debug>