SRP 接続がバウンスするとき、SRP スタンバイ ノードで SNMP の ThreshDNSLookupFailure トラップがトリガーする

概要

この記事では、サービス冗長プロトコル（SRP）の接続バウンスが SRP スタンバイ ノードで発生した場合の、ThreshDNSLookupFailure トラップの false トリガーについて説明します。インフラストラクチャのドメイン ネーム サービス（DNS）が、コール セットアップ プロセスの一部としてロングターム エボリューション（LTE）ネットワークのさまざまなノードで使用されています。これは、S6b 認証で返される完全修飾ドメイン名（FQDN）を解決するため、またさまざまなダイアメーター エンドポイント設定でピアとして指定された FQDN を解決するために、Packet Data Network Gateway（PGW）で使用できます。コールを処理するアクティブ ノードで DNS タイムアウト（障害）が発生した場合、DNS の正常な機能に依存しているコンポーネントによっては、コール設定に悪影響が生じる場合があります。

問題

StarOS v15 以降、インフラストラクチャ DNS の障害発生率を測定する設定可能なしきい値が用意されています。PGW がシャーシ間セッション回復（ICSR）で実装されるケースでは、ノード間の SRP 接続が何らかの理由によりダウンし、次のスタンバイ ノードが保留アクティブ状態になる場合（他のノードが完全な SRP アクティブ状態であるため（他に問題はないと想定します）、完全にはアクティブになりません）、関連付けられた DNS アラーム/トラップがトリガーされます。これは、保留アクティブ状態では、ノードが完全な SRP アクティブになる可能性に備え、入力のコンテキストのさまざまなダイアメーター インターフェイスに対してさまざまなダイアメーター接続の確立を試行するためです。ダイアメーター接続のいずれかの設定が IP アドレスではなく FQDN であるエンドポイント設定のピアの指定に基づく場合、それらのピアは A（IPv4）または AAAA（IPv6）クエリーを使用して DNS によって解決される必要があります。ノードが保留アクティブ状態にあるため、このようなクエリーはすべて失敗します。要求への応答が、応答を廃棄するアクティブ ノードにルーティングされるためです。その結果、100% の障害発生率になり、アラーム/トラップがトリガーされることになります。これはこのシナリオの想定されている動作ですが、アラームの重要性に関するカスタマー チケットが開かれる可能性があります。

ダイアメーター Rf が FQDN で設定され、DNS を解決する必要がある、このようなアラームの例を次に示します。  DNS によって解決される必要がある FQDN が示されています。

   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 分間以上ダウンし、SNMP トラップ ThreshDNSLookupFailure がトリガーされます。

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 は、ダイアメーター Rf ピアを解決しようとするプライマリおよびセカンダリ AAAA DNS クエリーについて、すべての障害を完全に確認します。

解決方法

このトラップ/アラームは、本当の意味で SRP アクティブはなく、トラフィックを処理することはないため、無視してクリアすることができます。上記の例の障害発生率は想定されている 100% よりも大幅に低く、バグ CSCuu60841 でこの問題が解決されています。今後のリリースでは、常に 100% が報告されます。

clear alarm outstanding

または

特定のアラームだけをクリアするには、以下を実行します。

clear alarm id <alarm id>

SRP スイッチオーバーが実行された後、新しい SRP スタンバイ シャーシでこの問題から派生した別の問題が発生する可能性があります。シャーシは SRP スタンバイであり、DNS 障害とは関係がないので、そのシナリオでもアラームは無視してください。

最後に、当然ではありますが、このアラームの原因を真の SRP アクティブ PGW ですぐに調査する必要があります。解決しようとしている FQDN の種類によってはサブスクライバまたは請求に影響が生じてしまう可能性があります。