مشغلات SNMP ThreshDNSLookupFailure على عقدة SRP الاحتياطية عندما يرتد اتصال SRP

المقدمة

تصف هذه المقالة المشغل الكاذب الظاهري ل ThreshDNSLookupFailure trap عند حدوث إرتداد اتصال لبروتوكول تكرار الخدمة (SRP) على عقدة إستعداد SRP. يتم إستخدام خدمة اسم مجال البنية الأساسية (DNS) على عقد مختلفة في شبكة التطور طويل المدى (LTE) بشكل غير مباشر كجزء من عملية إعداد الاستدعاء. على عبارة شبكة بيانات الحزمة (PGW)، يمكن إستخدامها لحل أي أسماء مجال مؤهلة بالكامل (FQDNs) يتم إرجاعها في مصادقة S6b، بالإضافة إلى حل FQDNs المحددة كنظراء في تكوينات نقاط نهاية Diameter المختلفة. إذا حدثت حالات انتهاء وقت DNS (حالات الفشل) على مكالمات معالجة عقدة نشطة، فقد يؤثر هذا سلبا على مجموعات المكالمات وفقا لمكونات تشغيل DNS بشكل صحيح.

المشكلة

بداية من StarOS v15، هناك عتبة قابلة للتكوين لقياس معدل فشل DNS للبنية الأساسية. في حالة تنفيذ PGW باستخدام إسترداد جلسة عمل بين الهياكل (ICSR)، من المحتمل أنه إذا تم إيقاف اتصال SRP بين كلا العقد لأي سبب من الأسباب، وأصبحت عقدة الاستعداد التالية في حالة نشاط معلقة (ولكنها ليست نشطة بالكامل لأن العقدة الأخرى تظل نشطة بالكامل SRP مع افتراض عدم وجود مشاكل أخرى)، فسيتم تشغيل تنبيه/ملائمة DNS المرتبطة. وذلك لأنه في حالة وجود عقدة نشطة معلقة، تحاول العقدة إنشاء إتصالات القطر المختلفة لواجهات القطر المختلفة في سياق المدخل تحضيرا لاحتمال أن تصبح SRP نشطة بالكامل. إذا كان تكوين أي من إتصالات القطر يستند إلى تحديد نظراء في تكوين نقطة النهاية التي تكون FQDNs بدلا من عناوين IP، حينئذ يلزم حل هذه النظراء عبر DNS باستخدام استعلامات IPv4 أو AAA (IPv6). وبما أن العقدة في حالة نشطة معلقة، فإن كافة هذه الاستعلامات تفشل لأن الاستجابات للطلبات سيتم توجيهها إلى العقدة النشطة (التي ستسقط الاستجابات)، مما ينتج عنه معدل فشل 100٪ والذي يؤدي بدوره إلى تشغيل التنبيه/الفخ. وفي حين أن هذا هو السلوك المتوقع في هذا السيناريو، فإن النتيجة المحتملة هي تذكرة مفتوحة للعميل فيما يتعلق بأهمية التنبيه.

هنا مثال من هذا تنبيه حيث القطر rf شكلت مع FQDNs وبالتالي يتطلب DNS أن يحل.  "show" هي FQDN التي يلزم حلها بواسطة DNS.

   diameter endpoint PGW-RF
      origin realm cisco.com
      use-proxy
      origin host test.Rf.cisco.com address 2001:5555:200:1001:240:200::
      peer test-0.cisco.COM realm cisco.COM fqdn lte-test-0.txsl.cisco.com 
        send-dpr-before-disconnect disconnect-cause  2

ينقطع اتصال SRP لسبب ما (خارج زوج عقد PGW والسبب غير المهم لأغراض هذا المثال) لمدة 7+ دقيقة، ومشغلات ThreshDNSLookupFailure لبروتوكول SNMP.

Tue Nov 25 08:43:42 2014 Internal trap notification 1037 (SRPConnDown)  
vpn SRP ipaddr 10.211.220.100 rtmod 3

Tue Nov 25 08:43:42 2014 Internal trap notification 120 (SRPActive)  
vpn SRP ipaddr 10.211.208.165 rtmod 3

Tue Nov 25 08:51:14 2014 Internal trap notification 1038 (SRPConnUp)  
vpn SRP ipaddr 10.211.220.100 rtmod 3

Tue Nov 25 08:51:14 2014 Internal trap notification 121 (SRPStandby)  
vpn SRP ipaddr 10.211.208.165 rtmod 9

Tue Nov 25 09:00:08 2014 Internal trap notification 480 (ThreshDnsLookupFailure)
context "XGWin" threshold 5% measured value 12%

هنا التنبيه و السجل المرتبط:

[local]XGW> show alarm outstanding verbose

Severity Object          Timestamp                          Alarm ID
-------- ----------      ---------------------------------- ------------------
  Alarm Details
------------------------------------------------------------------------------
Minor    VPN XGWin       Tuesday November 25 09:00:0        3611583935317278720
<111:dns-lookup-failure> has reached or exceeded the configured threshold <5%>, 
the measured value is <12%>. It is detected at <Context [XGWin]>.

2014-Nov-25+09:00:08.939 [alarmctrl 65201 info] 
[5/0/6050 <evlogd:0> alarmctrl.c:192] 
[context: XGWin, contextID: 6]  [software internal system critical-info syslog] 
Alarm condition: id 321eec7445180000 (Minor): 
<111:dns-lookup-failure> has reached
 or exceeded the configured threshold <5%>, the measured value is <12%>. 
It is detected at <Context [XGWin]>.

تؤكد Bulkstats فشل 100٪ لاستعلامات AAA DNS الأساسية والثانوية في محاولة حل نظراء القطر RF:

الحل

يمكن تجاهل هذا الحدث/التنبيه ومسح ضوئه نظرا لأن العقدة ليست SRP نشطة حقا ولا تتعامل مع أي حركة مرور. لاحظ أن معدل الفشل في المثال أعلاه أقل بكثير من المتوقع بنسبة 100٪ وأن الخطأ CSCuu60841 قد قام الآن بتثبيت هذه المشكلة في إصدار مستقبلي بحيث يتم دائما الإبلاغ عن نسبة 100٪.

تنبيه واضح بارز

أو

لتوضيح هذا التنبيه تحديدا:

معرف التنبيه الواضح <Alarm id>

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

وأخيرا، من نافلة القول إنه يلزم التحقيق فورا في سبب هذا التنبيه على PGW نشط حقا لبروتوكول SRP، نظرا لاحتمال حدوث تأثير المشترك أو تأثير الفوترة اعتمادا على أنواع FQDN التي تحاول حلها.