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

المقدمة

يصف هذا المستند إجراء أستكشاف أخطاء عدم إنهاء جلسات عمل PPPoE وإصلاحها بعد تغيير الاشتراك في Cisco Policy Suite (CPS) عبر بروتوكول RADIUS.

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

المتطلبات

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

• لينكس
• CPS
• بروتوكول RADIUS

cisco يوصي أن أنت ينبغي يتلقى امتياز منفذ:

• الوصول الجذري إلى واجهة سطر الأوامر ل CPS
• وصول المستخدم "QNS-SVN" إلى واجهة المستخدم الرسومية (GUI) ل CPS (أداة إنشاء السياسة ومركز التحكم)

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

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

• CPS 13.1
• UCS-B

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

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

تم تصميم CPS للعمل كنموذج خادم/عميل (AAA) للمصادقة والتفويض والمحاسبة (AAA) لدعم المشتركين في بروتوكول الاتصال من نقطة إلى نقطة عبر شبكة إيثرنت (PPPoE). يتفاعل CPS مع أجهزة ASR9K أو ASR1K لإدارة جلسات عمل PPPoE.

المشكلة

لا تقوم جلسات عمل PPPoE بقطع الاتصال وإعادة الاتصال بعد تحديد اشتراك جديد في CPS من خلال طلب واجهة برمجة تطبيقات بروتوكول الوصول البسيط إلى الكائن (SOAP) من نظام إمداد خارجي.

الملاحظة هي، أن CPS قادر على توليد طلب تغيير الإجراء (COA) وإرساله إلى الجهاز ASR9K، غير أن هذه الطلبات تحصل على وقت الإنهاء بواسطة جهاز ASR9K مع "خطأ مهلة عدم الاستجابة".

هنا العينة خطأ رسالة:

dc1-lb01  dc1-lb01 2021-09-28 21:26:13,331 [pool-2-thread-1] ERROR c.b.p.r.jms.PolicyActionJmsReceiver - Error executing RemoteAction.  Returning Error Message response
com.broadhop.exception.BroadhopException: Timeout: No Response from RADIUS Server
        at com.broadhop.radius.impl.actions.AsynchCoARequest.execute(AsynchCoARequest.java:213) ~[com.broadhop.radius.service_13.0.1.r150127.jar:na]
        at com.broadhop.utilities.policy.remote.RemoteActionStub.execute(RemoteActionStub.java:62) ~[com.broadhop.utility_13.0.0.release.jar:na]
        at com.broadhop.policy.remote.jms.PolicyActionJmsReceiver$RemoteActionExecutor.run(PolicyActionJmsReceiver.java:98) ~[com.broadhop.policy.remote.jms_13.0.0.release.jar:na]
        at com.broadhop.utilities.policy.async.PolicyRemoteAsyncActionRunnable.run(PolicyRemoteAsyncActionRunnable.java:24) [com.broadhop.utility_13.0.0.release.jar:na]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_72]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_72]
        at com.broadhop.utilities.policy.async.AsyncPolicyActionExecutionManager$GenericThead.run(AsyncPolicyActionExecutionManager.java:301) [com.broadhop.utility_13.0.0.release.jar:na]
Caused by: net.jradius.exception.TimeoutException: Timeout: No Response from RADIUS Server
        at net.jradius.client.RadiusClientTransport.sendReceive(RadiusClientTransport.java:112) ~[na:na]
        at net.jradius.client.RadiusClient.changeOfAuth(RadiusClient.java:383) ~[na:na]
        at com.broadhop.radius.impl.actions.AsynchCoARequest.execute(AsynchCoARequest.java:205) ~[com.broadhop.radius.service_13.0.1.r150127.jar:na]
        ... 6 common frames omitted

إصدار خطوات النسخ

الخطوة 1. ابدأ جلسات عمل PPPoE من أجهزة ASR9K أو ASR1K، تأكد من أنك ترى تلك الجلسات في CPS عبر مركز التحكم.

الخطوة 2. ابدأ طلب واجهة برمجة تطبيقات SOAP لتحديث اشتراك الخدمات المقترنة بالمشترك.

الخطوة 3. تبدأ CPS طلبات COA نحو ASR9K أو ASR1K. يمكنك ملاحظة أن CPS تقوم بإعادة محاولة نفس المرجع مع الطلب المتكرر لنفس COA.

ملاحظة: لا يتم التعرف على الحزمة الأولى بواسطة جهاز النظير (ASR9K)، وبالتالي فإن المنطق الداخلي في CPS يقوم بتشغيل آلية إعادة محاولة وإرسال طلبات مكررة.

الخطوة 4. الملاحظة هي، أن نظام تحديد المواقع (CPS) يسقط جميع إجراءات تحديث الجلسات الأخرى، حيث لا يوجد رد على طلب تقييم المواد الكيميائية للجلسة الأولى وإعادة المحاولة الخاصة به.

مع هذا، أنت يستطيع رأيت ال PPPoE جلسة ما زال نشط في ASR9K، وما من جلسة أرسلت طلب قطع اتصال باتجاه CPS للجلسة تحديث. تتوقع CPS طلب "إيقاف المحاسبة" من ASR9K فيما يتعلق بطلب COA.

النقاط الرئيسية التي ينبغي ملاحظتها فيما يتعلق بمشتريات الكاكاو والمتقاعدين لها

1. يقوم CPS ببدء طلبات COA لجميع جلسات العمل النشطة/الموجودة في قاعدة بياناته الخاصة بمشترك معين.
2. إذا لم يتلقى CPS ACK أو NACK لطلب COA معين، فإنه يبدأ آلية إعادة محاولة بناء على التكوين في منشئ النهج.
3. عدد عمليات إعادة المحاولة والمدة بين عمليات إعادة المحاولة قابل للتكوين.

تكوين إعادة المحاولة العينة

الحل

لحل هذه المشكلة، تحتاج إلى إجراء مزيد من التحليل باتجاه ASR9K، كما تحتاج إلى معرفة سبب عدم الرد على CPS لطلب COA وإعادة المحاولة الخاصة به.

أنت يستطيع رأيت في ال sniffer أثر أن ال load موازن (LB01) من CPS مصدر COA من <IP-1> ويوجه الربط عبر ETH1، أي يكون التقصير ممر.

أما موازن الأحمال الآخر (LB02) فيصدر الكاكاو من <IP-2>، ويأخذ طريقا محددا عبر ETH2.

تحتوي ASR9K على قائمة الوصول (ACL) لقبول COA فقط إذا كانت تأتي من <IP-2>، وليس من <IP-1>.

لذلك تحتاج إلى تصحيح جدول المسار في LB01 من CPS لإرسال COA مع مصدر IP المناسب، أي <IP-2> عبر مسار محدد.

هنا يمكنك مشاهدة حركة RADIUS الناجحة التي تنتهي لتغيير الاشتراك، ترحيل التصحيح اللازم في جدول مسار CPS LB.