أستكشاف أخطاء مسار EGTP وإصلاحها بسبب عدم تطابق قيم عداد إعادة التشغيل

المقدمة

يصف هذا المستند أستكشاف أخطاء مسار بروتوكول GPRS المتطور (EGTP) التي تم ملاحظتها وإصلاحها بسبب عدم تطابق في قيم العداد لإعادة التشغيل بين SGSN/MME و GGSN/Service Gateway أو عبارة PDN (SPGW).

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

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 about this commands refer this mentioned link

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

تحليل

من السجلات والحالات، تم تحديد أن قيمة العداد لإعادة التشغيل في نهاية وحدة إدارة التنقل (MME) هي 11، وفي نهاية EPG هي 12.

يمكنكم ملاحظة الفخاخ كما هو مذكور هنا:

Internal trap notification 1112 (EGTPCPathFail) context s11mme, service s11-mme, interface type mme, self address <X.X.X.X>,  peer address <Y.Y.Y.Y>, peer old restart counter 4,  peer new restart counter 4,  peer session count  240, failure reason no-response-from-peer,  path failure detection Enabled.
Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address <X.X.X.X>,  peer address <Y.Y.Y.Y>, peer old restart counter 54,  peer new restart counter 12,  peer session count  1107240, failure reason restart-counter-change
Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address <X.X.X.X>,  peer address <Y.Y.Y.Y>, peer old restart counter 12,  peer new restart counter 54,  peer session count  1107207, failure reason create-sess-restart-counter-change

تحتوي عبارة المورد (GW) على مشكلة في قبول القيم الأقل من عقدة دعم GPRS (SGSN) لخدمة إذا تم تغيير عداد إعادة التشغيل. إذا قام المورد GW بتخزين قيمة أعلى (قيمة قديمة) وبعد إعادة تحميل العقدة إذا كان Cisco SGSN يرسل قيمة أقل، فإن المورد GW لا يقبلها.

ملاحظة: وفقا لمعيار TS 29.060:

1. إذا كان SGSN على اتصال بعقدة دعم GPRS للعبارة (GGSN) لأول مرة أو تم إعادة تشغيله مؤخرا دون الإشارة إلى قيمة "عداد إعادة التشغيل" الجديدة إلى GGSN، فإنه يدمج عنصر معلومات الاسترداد في طلب سياق "إنشاء نقطة قرار السياسة (PDP)". يتم تضمين هذا العنصر بواسطة SGSN عند الضرورة. يقوم GGSN الذي يستلم عنصر معلومات الاسترداد في عنصر "إنشاء رسالة طلب سياق PDP" بمعالجته مثل عند تلقي رسالة إستجابة Echo. تعتبر رسالة "إنشاء طلب سياق PDP" طلب تنشيط صالح لسياق PDP المضمن في الرسالة.

2. يتضمن GGSN عنصر معلومات الاسترداد في إستجابة سياق PDP إذا كان GGSN على اتصال ب SGSN للمرة الأولى أو أن GGSN قد تم إعادة تشغيله مؤخرا ولم تتم الإشارة إلى قيمة "عداد إعادة التشغيل" الجديدة إلى SGSN بعد. يقوم SGSN الذي يستقبل عنصر معلومات الاسترداد بمعالجته كما هو الحال عند تلقي رسالة إستجابة Echo. ومع ذلك، فإنه يعتبر سياق PDP الذي يتم إنشاؤه نشطا إذا كانت الاستجابة تشير إلى تنشيط سياق ناجح في GGSN.

3. تستخدم واجهة GTP عداد إعادة التشغيل لتعقب عدد عمليات إعادة التشغيل. وفقا ل TS 23.060، يجب أن تستخدم عقد GTP التخزين الدائم لتتبع عدادات إعادة تشغيل GTP المحلية الخاصة بها حتى يتوقع المرء أن تستمر عدادات إعادة التشغيل هذه إلى أعلى دائما. ومع ذلك، في حالة كشف عقدة نظير عن انخفاض في عداد إعادة التشغيل، يتم توضيح سلوك عقدة GTP في جلسة عمل "إجراءات إعادة التشغيل المستندة إلى GTP-C-18" ل TS 23.007. لنفترض أن قيمة عداد إعادة التشغيل المخزن مسبقا لنظير أكبر من قيمة عداد إعادة التشغيل المتلقاة في رسالة إستجابة صدى صدى الصوت أو رسالة GTP-C، مع أخذ إعادة توجيه العدد الصحيح في الاعتبار. في هذه الحالة، يشير ذلك إلى حالة عرق محتملة (وصول رسالة أحدث قبل الأقدم). تم تجاهل قيمة عداد "إعادة التشغيل الجديدة" المستلمة ويمكن تسجيل خطأ. بمعنى آخر، عندما تكتشف عقدة GTP عداد إعادة تشغيل أقل من النظير، فإنها لا تسجل أبدا عداد إعادة التشغيل الجديد.

منظور StarOS

من نهاية StarOS، يمكنك بشكل صريح تغيير قيمة RC في StarOS من المسار /flash/restart_file_cntr.txt الذي يتم تنفيذه في وقت الترقية.

وفقا لهذه النظرية، عند مقارنتها بالتكوين الحالي، كانت قيمة MME RC أقل من قيمة GW RC للمورد. من أجل معالجة المشكلة، تم تعديل قيمة RC في عقدة GW الخاصة بالمورد.

الآن بعد تغيير قيمة RC، يرى أن فشل مسار EGTPC توقف ولكن لا يزال، الجلسات لا تزيد وارتباطات EGTPC لا تزال تظهر غير نشطة.

هذه هي الأوامر التي تم إستخدامها أثناء أستكشاف الأخطاء وإصلاحها:

show sgtp-service all | grep "restart"  ----------------- to check RC value

[local]Nodename# show egtp-service all | more
  Service name                          : egtpc_sv_service
  Service-Id                            : 5
  Context                               : SGs
  Interface Type                        : mme
  Status                                : STARTED
  Restart Counter                       : 11   ----------------- RC value to verify
  Max Remote Restart Counter Change     : 255
  Message Validation Mode               : Standard
  GTPU-Context                          :
  GTPC Retransmission Timeout           : 5000 (milliseconds)
  GTPC Maximum Request Retransmissions  : 4
  GTPC IP QOS DSCP value                : 10
  GTPC Echo                             : Enabled
  GTPC Echo Mode                        : Default


[local]Nodename# show egtpc peers           ------------ To check link status
Sunday February 05 15:31:00 IST 2023
+----Status:                 (I) - Inactive  (A) - Active                        
|                                                                                
|+---GTPC Echo:              (D) - Disabled  (E) - Enabled                       
||                                                                               
||+--Restart Counter Sent:   (S) - Sent      (N) - Not Sent                      
|||                                                                              
|||+-Peer Restart Counter:   (K) - Known     (U) - Unknown                       
||||                                                                             
||||+-Type of Node:          (S) - SGW       (P) - PGW                           
|||||                        (M) - MME       (G) - SGSN                          
|||||                        (L) - LGW       (E) - ePDG                          
|||||                        (C) - CGW       (B) - MBMS                          
|||||                        (U) - Unknown                                       
|||||                                                                            
|||||  Service                       Restart--------+  No. of                    
|||||  ID                            Counter        |  restarts                  
|||||   |                                           |   |   Current       Max    
vvvvv   v              Peer Address                 v   v   sessions    sessions  LCI OCI
-----  --- --------------------------------------- --- --- ----------- ------------------
IDSKS  10                           X.X.X.X         91   0           0           0   X   X
IDNKS  11                           Y.Y.Y.Y          4  95           0       34005   X   X
IDNKS  11                           Z.Z.Z.Z         10 103           0       16805   X   X
IDNKS  11                           A.A.A.A        104  95           0        7250   X   X
AESKS  11                           B.B.B.B          0   0        4004       47649   X   X
AESKS  11                           C.C.C.C          0   0        4053       46571   X   X
AESKS  11                           D.D.D.D          0   0        4026       46734   X   X

ABove output peers if you see no sessions on this peer and also link are inactive

المزيد. تحقق من طلب/إستجابة الارتداد (ليتم التحقق في الوضع المخفي):

egtpc test echo gtp-version 2 src-address <MME end IP> peer-address <EPG end IP> 

هذا هو المخرج عند تصحيح قيمة "عداد إعادة التشغيل" وتكوينها بنفس مستوى تكوين MME للواجهة S11 لنظير EGTP المتأثر ثم يكون طلب/إستجابة ECHO جيدا ولكن الارتباط لا يزال غير نشط.

[s11mme]Nodename# egtpc test echo gtp-version 2 src-address <X.X.X.X> peer-address <Y.Y.Y.Y>

Sunday February 05 16:22:42 IST 2023

EGTPC test echo

---------------

Peer: X.X.X.X                          Tx/Rx:  1/1  RTT(ms): 1    (COMPLETE) Recovery: 10 (0x0A)

بيد أن الأمر نفسه لا يعمل كما هو متوقع بالنسبة لنظم عالمية أخرى متضررة. لا يزال هناك فشل في طلب/إستجابة صدى صدى الصوت كما هو مذكور هنا.

[s11mme]Nodename# egtpc test echo gtp-version 2 src-address <X.X.X.X> peer-address <Y.Y.Y.Y>




Sunday February 05 16:46:11 IST 2023

EGTPC test echo

---------------

Peer: X.X.X.X                         Tx/Rx:  1/0  RTT(ms): 0    (FAILURE)

الحل

1. لإصلاح هذه المشكلة، لاحظ عداد إعادة التشغيل الحالي الموجود /flash/restart_file_cntr.txt قبل إلغاء تنشيط VNF. لاحقا، عندما يتم تنشيطه باستخدام برنامج جديد، قم بتسجيل الدخول إلى CF وقم بتحديث الملف /flash/restart_file_cntr.txt باستخدام عداد إعادة التشغيل القديم. بعد ذلك، كإجراء ترقية عادي، قم بإعادة تحميل VNF باستخدام تكوين اليوم-N.

2. قم بتعديل cat /flash/restart_file_cntr.txt إلى القيمة المطلوبة وأعد تحميل العقدة باستخدام التكوين الحالي.

ملاحظة: يمكنك محاولة إعادة تشغيل SGTPC مرة واحدة كخطوة أولية.