المحتويات

المقدمة

المشكلة

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

الحل

الشرح الفني

المقدمة

يصف هذا المستند سيناريو محددا عندما تكون سجلات بيانات المكالمات (G-CDRs) لعقدة دعم GPRS (GGSN) الخاصة ب Gateway-GPRS عالقة بسبب تكوين غير صحيح في اسم نقطة الوصول (APN) ينتج عنه فوترة خاطئة للمشتركين، وتتلقى وظيفة عبارة الشحن (CGF) بروتوكولات CDR متأخرة والتي أصبحت عالقة في GGSN. يتم الإبلاغ عن هذه المشكلة في سلسلة موجهات الخدمات المجمعة (ASR) 5x00 من Cisco.

المشكلة

ترجع CDRs إلى المجموعة الافتراضية لأسباب متعددة (على الأرجح تكوينات خاطئة) لبعض APNs. في المجموعة الافتراضية، ليس لدينا خوادم CGF تم تكوينها، وبالتالي تصبح الطلبات عالقة.

على سبيل المثال:

apn blackberry.net.40413pre

selection-mode subscribed sent-by-ms chosen-by-sgsn

accounting-mode none

timeout idle 10800

ip access-group ECS in

ip access-group ECS out

ip address pool name blackberry

credit-control-group GY_LIVE_PRE

active-charging rulebase test_prepaid

exit

apn blackberry.net.40443pre

selection-mode subscribed sent-by-ms chosen-by-sgsn

accounting-mode none

timeout idle 10800

ip access-group ECS in

ip access-group ECS out

ip address pool name blackberry

credit-control-group GY_LIVE_PRE

active-charging rulebase test_prepaid

exit

apn blackberry.net.40446pre

selection-mode subscribed sent-by-ms chosen-by-sgsn

accounting-mode none

timeout idle 10800

ip access-group ECS in

ip access-group ECS out

ip address pool name blackberry

credit-control-group GY_LIVE_PRE

active-charging rulebase test_prepaid

exit

apn blackberry.net.40484pre

selection-mode subscribed sent-by-ms chosen-by-sgsn

accounting-mode none

timeout idle 10800

ip access-group ECS in

ip access-group ECS out

ip address pool name blackberry

credit-control-group GY_LIVE_PRE

active-charging rulebase test_prepaid

exit

apn blackberry.net.40486pre

selection-mode subscribed sent-by-ms chosen-by-sgsn

accounting-mode none

timeout idle 10800

ip access-group ECS in

ip access-group ECS out

ip address pool name blackberry

credit-control-group GY_LIVE_PRE

active-charging rulebase test_prepaid

exit

aaa group default

#exit

gtpp group default

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

في إخراج إظهار تفاصيل الدعم، تحقق من إخراج الأمر

******** show session subsystem data-info verbose *******

647274 Total gtpp acct requests           1 Current gtpp acct requests

0 Total gtpp acct cancelled          0 Total gtpp acct purged

0 Total gtpp sec acct requests       0 Total gtpp sec acct purged

248 Total null acct requests           0 Current null acct requests

2482018515 Total aaa acct sessions       265064 Current aaa acct sessions

14529031 Total aaa acct archived       6518761 Current aaa acct archived

265064 Current recovery archives     259073 Current valid recovery records

1108 Total aaa sockets opened         932 Current aaa sockets opened

تظهر إمكانية الوصول الحالية التي تمت أرشفتها 6 ملايين من وحدات المعالجة المركزية (CDR) عالقة في جميع الأجزاء والتي من خلالها لا تتم معالجة وحدات المعالجة المركزية (CDR) الجديدة ونقلها إلى CGF في وضع الدفق.

وبمجرد الوصول إلى الحد الأقصى لكل ذاكرة، تتم إزالة وحدات المعالجة المركزية (CDR) مما يؤدي إلى فقد وحدات المعالجة المركزية (CDR) وفقدان الإيرادات للعميل.

من بين 6 ملايين وحدة ذاكرة CDR محفوظة في الأرشيف، ترى بعض وحدات CDR يتم إزالتها

******** show session subsystem data-info verbose *******

1228764750 Total gtpp charg              6534523 Current gtpp charg

1221919009 Total gtpp charg success       311218 Total gtpp charg failure

0 Total gtpp charg cancelled     311218 Total gtpp charg purged

0 Total gtpp sec charg                0 Total gtpp sec charg purged

0 Total prepaid online requests       0 Current prepaid online requests

0 Total prepaid online success        0 Current prepaid online failure

0 Total prepaid online retried        0 Total prepaid online cancelled

0 Current prepaid online purged

فيما يلي قوائم التحقق من أوامر CLI المستخدمة بشكل شائع لتصحيح أخطاء المشاكل ذات الصلة ب CDR.

- show gtpp accounting servers

- show gtpp accounting servers group name <CGF>

- show gtpp counters all

- show gtpp counters cgf-address 172.16.10.11

- show gtpp counters cgf-address 172.16.10.11 gcdrs

- show gtpp counters group name CGF

- show gtpp counters group name CGF gcdrs

- show gtpp group all

- show gtpp group name CGF

- show gtpp statistics

- show gtpp statistics cgf-address 172.16.10.11

- show gtpp statistics group name CGF

- show gtpp storage-server streaming file counters all

- show gtpp storage-server streaming file counters group name CGF

- show gtpp storage-server streaming file statistics

- show gtpp storage-server streaming file statistics group name CGF

الحل

أسلوب الإجراء (MOP) لتنظيف CDRs التي تنتمي إلى المجموعة الافتراضية في عملية الوكيل.

الخطوة 1. لاحظ وحدات CDR التي تمت أرشفتها. إظهار عدادات gtpp الكل

الخطوة 2. قم بتكوين الوضع إلى محلي في gaggsnctx config context gaggsnctx gtp group default gtpp storage-server mode local

الخطوة 3. الرجاء قتل وكيل باستخدام هذا الأمر في الوضع المخفي. Task Kill Facility هو وكيل الكل. (سوف يؤدي قتل المهام إلى تطبيق الوضع المحلي على المجموعة الافتراضية.)

الخطوة 4. الخروج من الوضع المخفي

الخطوة 5. حدد عرض إحصائيات الملفات المحلية ل GTPP storage-server في أزدياد.

الخطوة 6. قم بتشغيل إظهار عدادات gtpp الكل كل 30 ثوان. هذا ينبغي أن يهبط إلى صفر في فسحة بين دعامتين 5 دقائق.

الخطوة 7. قم بتحويل الوضع إلى وضع بعيد. تكوين سياق gaggsnctx gtpp مجموعة gtpp الافتراضية وضع التخزين-الخادم البعيد

الخطوة 8. تحقق من أن العداد الذي تمت أرشفته (show gtpp counters all) لا يزيد وإظهار إحصائيات الملف المحلي ل gtpp storage-server لا تتزايد.

الخطوة 9. قم بأخذ SSD وأرسل مرة أخرى إلينا للتحقق للتأكد من أن التكوين سليم ومن أنه يتم اتباع جميع الخطوات.

ملاحظة: بعد اكتمال النشاط، إذا كنت تعرف الإجراء الخاص بإزالة ملفات CDR من HDD. تفضل. (إذا لم تكن هناك مساحة، فالرجاء الاتصال بمهندس TAC لهذا النشاط يوما آخر)

إذا لم يتم إسترداد Aaproxy بعد دقيقة واحدة، فارجع إجراء الاسترداد.

إجراء إسترداد الوكيل

a. Issue the command to check which controller takes care of aaaproxy task

show task table | grep aaaproxy

task                           Parent

cpu facility   inst   pid pri   facility      inst pid

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

4/0 aaaproxy  1 6721  0  sessctrl      0 10565

b. Please execute the below commands and look out for instance of sessctrl on Active SMC

#Show task table | grep sessctrl

Task                     parent

cpu facility inst pid pri facility inst pid

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

8/0 sessctrl 0 10565 -4 sitparent 80 2812

c. Issue the sessctrl instance kill command

Task kill facility sessctrl instance <>.

d. After the execution of command, wait for 30 secs and issue the commands to check state of sessctrl and aaaproxy

1. Show task table | grep "8/0 sessctrl"

2. Show task resources | grep aaaproxy

الشرح الفني

ترجع CDR إلى المجموعة الافتراضية لأسباب متعددة (على الأرجح تكوينات خاطئة) لبعض APNs. في المجموعة الافتراضية، ليس لديك خوادم CGF تم تكوينها، وبالتالي تصبح الطلبات عالقة. بالنسبة إلى نقاط الوصول الخاصة (APN) التي تم تكوين مجموعة GTP صالحة لها، يجب عدم أرشفة وحدات التحكم في الوصول الخاصة بالذاكرة (CDR) ولكن قد تنتقل إلى قائمة انتظار الأرشيف.

من قائمة انتظار الأرشيف، يمكنك معالجة خمسة طلبات فقط في كل مرة. في حالة انتماء كافة الطلبات الخمسة إلى APN التي تحتوي على تكوين خاطئ، لا يتم تحرير أكبر خمسة طلبات على الإطلاق وبالتالي يتم حظر كافة CDR الموجودة خلف قائمة الانتظار. وهذا يعني أن وحدات CDR التي تم إنشاؤها في شهر محدد قد علقت هناك وتمت معالجتها بشكل خاطئ.

يوجد حد أقصى ل ASR5x00 هو عدد وحدات ذاكرة CDR التي يمكن أرشفتها. بمجرد تجاوز الحد، يتم إزالة وحدات التحكم في الوصول للذاكرة (CDR) التي تمت أرشفتها. يفسح هذا المجال لوحدات CDR الصالحة التي تم إنشاؤها في شهر محدد ويتم إصدارها.

على سبيل المثال,

إذا كانت قائمة الانتظار تحتوي على خمسة طلبات وكانت باقي الطلبات تنتمي إلى APN الصحيح بتكوين صحيح وعندما تقوم بالمعالجة، لا يتم تحرير الطلبات الخمسة في كل مرة حيث لا يوجد خادم تم تكوينه وأنت معلق للأبد حيث تقوم بمعالجة خمسة CDR فقط في كل مرة. ومع ذلك، إذا تم إزالة أحد الطلبات، فهذا يعني أن لديك 4 طلبات تنتمي إلى APN الخاص بالتكوين غير الصحيح والمطلب التالي هو APN صالح. الآن، عندما تقوم بمعالجة خمسة طلبات، تبقى الطلبات الأربعة عالقة، لكن الطلبات الخامسة تتم معالجتها الآن. بهذه الطريقة، سترى CDR القديمة التي تم إرسالها إلى CGF مثل CGF سيتم معالجة CDR شهر ديسمبر في يناير لأن GGSN قامت بإطلاقها في وقت متأخر.

لماذا يتم إرسال وحدات CDR للمجموعة الصحيحة إلى قائمة انتظار الأرشيف: الحد الأقصى للحزمة التي يمكن إرسالها في بروتوكول مخطط بيانات المستخدم (UDP) هو 64 ك بما في ذلك الرأس. الآن نظرا لأننا قمنا بتكوين الحد الأقصى لذاكرة CDRS 255 وقت الانتظار 60، فمن المحتمل أن تكون سعة المخزن المؤقت التي تبلغ 64 كيلوبايت ممتلئة قبل الوصول إلى الحد الأقصى لذاكرة CDR التي تبلغ 255. سيقوم النظام بالتحقق مما إذا كان يمكن إحتواء CDR الجديدة في المخزن المؤقت الذي يبلغ سعته 64 كيلو أم لا. وإذا لم يكن الأمر كذلك، سيقوم النظام بإعادتها إلى قائمة انتظار الأرشيف. أرجعت ذاكرة CDR هذه إلى قائمة انتظار الأرشيف المعلقة لمدة شهر واحد حتى يتم إزالة وحدات CDR الخاصة بالمجموعة غير الصحيحة. إذا كان هناك تكوين صحيح، فلن يكون لدى قائمة انتظار الأرشيف CDRs الخاصة ب APN التي لا تحتوي على خوادم، ولن ترى هذه المشكلة أبدا لأنه حتى إذا تم إدخال CDR إلى قائمة انتظار الأرشيف، فسيتم معالجتها.

منطق

أنت تقتل Aproxy وتغير وضع خادم تخزين GTPP محلي، لذلك يتم دفع وحدات التحكم في الوصول إلى الذاكرة (CDR) المعلقة إلى القرص الثابت المحلي وستتجنب إزالة وحدات التحكم في الوصول إلى الذاكرة (CDR) بمجرد الوصول إلى الحدود لكل وحدة تحكم. بمجرد كتابة جميع وحدات ذاكرة CDR إلى Harddisk المحلية، يمكنك الرجوع إلى الوضع البعيد وهو الوضع الافتراضي.