IPSec トンネルを介した PING ロスを含む Syslog "%CRYPTO-4-RECVD_PKT_MAC_ERR:" エラー メッセージのトラブルシューティング

概要

このドキュメントでは、ボックスに示すように、syslog内の「%CRYPTO-4-RECVD_PKT_MAC_ERR」メッセージと組み合わされたIPSecトンネルでのping損失を解決する方法について説明します。

May 23 11:41:38.139 GMT: %CRYPTO-4-RECVD_PKT_MAC_ERR: 
decrypt: mac verify failed for connection 
id=2989 local=172.16.200.18 remote=172.16.204.18 spi=999CD43B 
seqno=00071328

このような廃棄のごく一部は、正常と見なされます。ただし、この問題によりドロップ レートが高くなると、サービスに影響する可能性があるため、ネットワーク オペレータの注意が必要な場合があります。syslog で報告されるこれらのメッセージは、30 秒間隔で限定された割合であるため、1 つのログ メッセージが、必ずしも 1 つのパケットのみが廃棄されたことを表すわけではないことに注意してください。これらのドロップの正確なカウントを取得するには、コマンドshow crypto ipsec sa detailを発行し、ログに表示される接続IDの横にあるSAを調べます。SA カウンタでは、pkts verify failed error カウンタが、メッセージ認証コード（MAC）確認の失敗による廃棄パケットの総数を示します。

interface: GigabitEthernet0/1
    Crypto map tag: MPLSWanGREVPN, local addr 172.16.204.18

   protected vrf: (none)
   local  ident (addr/mask/prot/port):   (172.16.204.18/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port):   (172.16.205.18/255.255.255.255/47/0)
   current_peer 172.16.205.18 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 51810, #pkts encrypt: 51810, #pkts digest: 51810
    #pkts decaps: 44468, #pkts decrypt: 44468, #pkts verify: 44468
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #pkts no sa (send) 0, #pkts invalid sa (rcv) 0
    #pkts encaps failed (send) 0, #pkts decaps failed (rcv) 0
    #pkts invalid prot (recv) 0, #pkts verify failed: 8
    #pkts invalid identity (recv) 0, #pkts invalid len (rcv) 0
    #pkts replay rollover (send): 0, #pkts replay rollover (rcv) 0
    #pkts replay failed (rcv): 0
    #pkts internal err (send): 0, #pkts internal err (recv) 0

     local crypto endpt.: 172.16.204.18, remote crypto endpt.: 172.16.205.18
     path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/1
     current outbound spi: 0xD660992C(3596654892)

     inbound esp sas:
      spi: 0x999CD43B(2577191995)
        transform: esp-3des esp-sha-hmac ,
        in use settings ={Transport, }
        conn id: 2989, flow_id: AIM-VPN/SSL-3:2989, sibling_flags 80000006,
        crypto map: MPLSWanGREVPN
        sa timing: remaining key lifetime (k/sec): (4257518/24564)
        IV size: 8 bytes
        replay detection support: N
        Status: ACTIVE

     outbound esp sas:
      spi: 0xD660992C(3596654892)
        transform: esp-3des esp-sha-hmac ,
        in use settings ={Transport, }
        conn id: 2990, flow_id: AIM-VPN/SSL-3:2990, sibling_flags 80000006, 
        crypto map: MPLSWanGREVPN
        sa timing: remaining key lifetime (k/sec): (4199729/24564)
        IV size: 8 bytes
        replay detection support: N
        Status: ACTIVE

前提条件

要件

このドキュメントに特有の要件はありません。

使用するコンポーネント

このドキュメントの情報は、Cisco IOS^®リリース15.1(4)M4で行われたテストに基づいています。テストは行われていませんが、両方のアプレットがEEMバージョン3.0(IOSバージョン12.4(22)T以降でサポートされています)。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。

機能情報

「%CRYPTO-4-RECVD_PKT_MAC_ERR:decrypt:」は、MACの検証に失敗した暗号化パケットが受信されたことを意味します。この確認は、次のように設定された証明書トランスフォーム セットの結果です。

Router (config)# crypto ipsec transform transform-1 esp-aes 256 esp-md5-hmac

上の例では、「esp-aes 256」が暗号化アルゴリズムを 256 AES として定義し、「esp-md5」が MD5（HMAC のバリアント）を、認証に使用するハッシュ アルゴリズムとして定義します。MD5 などのハッシュ アルゴリズムは、通常、ファイルの内容のデジタル フィンガープリントを提供するために使用されます。デジタル フィンガープリントは、ファイルが侵入者またはウイルスによって変更されていないことを保証するために、よく使用されます。したがって、このエラー メッセージが表示されることは、通常、次のいずれかを意味します。

• パケットの暗号化または復号化に使用したキーが誤っています。このエラーは非常にまれで、ソフトウェアの不具合が原因で発生することがあります。
                                                       または 
• パケットが転送中に改竄されています。このエラーは、ダーティ回線または不正なイベントが原因である可能性があります。

トラブルシューティング手法

このエラー メッセージは、通常、パケットの破損によって発生するため、根本原因を分析する方法は、EPC を使用して、両方のトンネル エンドポイントの WAN 側の完全なパケットのキャプチャを取得し、比較することだけです。キャプチャを取得する前に、これらのログをトリガーするトラフィックの種類を特定することを推奨します。場合によっては、特定の種類のトラフィックである可能性があります。また、トラフィックの種類に無関係だが、簡単に再現できる場合もあります（100 回の ping ごとに 5 ～ 7 回の廃棄など）。 このような場合は、問題の特定が、やや容易になります。最も効率よくトリガーを特定する方法は、DSCP マーキングでテスト トラフィックをマークし、パケットをキャプチャすることです。DSCP 値は、ESP ヘッダーにコピーされ、その後、Wireshark でフィルタリングできます。100 回の ping によるテストを想定したこの設定を使用して、次のように ICMP パケットをマークできます。

ip access-list extended VPN_TRAFFIC
  permit icmp <source> <destination>
class-map match-all MARK
  match access-group name VPN_TRAFFIC
policy-map MARKING
  class MARK
    set dscp af21

今度は、このポリシーを、clear traffic が暗号化ルータで受信される入力インターフェイスに適用する必要があります。

interface GigabitEthernet0/0
 service-policy MARKING in

また、このテストを、ルータが生成するトラフィックで実行するという方法もあります。この場合は、Quality of Service（QoS）を使用してパケットをマークすることはできませんが、ポリシー ベース ルーティング（PBR）を使用できます。

注：重大な (5) DSCP マーキングを見つけるには、Wireshark フィルタ ip.dsfield.dscp == 0x28 を使用します。

ip access-list extended VPN_TRAFFIC
  permit icmp <source> <destination>
route-map markicmp permit 10
 match ip address vpn
 set ip precedence critical 
ip local policy route-map markicmp

QoS マーキングを ICMP トラフィックに対して設定したら、埋め込みパケット キャプチャを設定できます。

Router(config)# ip access-list ext vpn_capo
Router(config)# permit ip host 
     
      
       
       
     
Router(config)# permit ip host 
     
      
       
       
     
Router(config)#  exit //the capture is only configured in enable mode.
Router# monitor capture buffer vpncap size 256 max-size 100 circular
Router# monitor capture buffer vpncap filter access-list vpn_capo
Router# monitor capture point ip cef capo fastEthernet 0/1 both
Router# monitor capture point associate capo vpncap
Router# monitor capture point start capo //starts the capture. 
To stop replace the "start" keyword with "stop"

注：これは、Cisco IOS リリース 12.4(20)T で導入された機能です。EPC に関する詳細については、「埋め込みパケット キャプチャ」を参照してください。

このタイプの問題のトラブルシューティングのためにパケット キャプチャを使用するには、パケットの一部だけでなく、全体をキャプチャする必要があります。15.0(1)M より前の Cisco IOS リリースの EPC 機能には、512K のバッファ制限と 1024 バイトの最大パケット サイズ制限があります。この制限を回避するには、15.0(1)M 以降のコードにアップグレードしてください。これで、100M のキャプチャ バッファ サイズと、9500 バイトの最大パケット サイズがサポートされます。

問題が 100 回の ping ごとに確実に再生できる場合、最悪のシナリオは、制御されたテストとしてのみ ping トラフィックを許可し、キャプチャを取得するためにメンテナンス時間帯をスケジュールすることです。このプロセスにかかる時間は数分だけですが、その時間の実稼働トラフィックが中断されます。QoS マーキングを使用する場合は、パケットを ping のみに制限するために要件を排除する必要があります。1 つのバッファのすべての ping パケットをキャプチャするには、ピーク時間帯にテストが行われないようにする必要があります。

問題が容易には再現されない場合は、EEM のスクリプトを使用してパケット キャプチャを自動化することができます。この理論は、両側で循環バッファへとキャプチャを開始し、EEM を使用して片側でキャプチャを停止することです。EEM でキャプチャを停止すると同時に、snmp トラップをピアに送信し、ピアでもキャプチャを停止します。このプロセスは機能する可能性があります。ただし、負荷が大きい場合は、2 番目のルータの反応が間に合わず、キャプチャが停止されない場合があります。そのため、制御されたテストを推奨します。プロセスを実行する EEM スクリプトを次に示します。

Receiver
========
event manager applet detect_bad_packet
event syslog pattern "RECVD_PKT_MAC_ERR"
 action 1.0 cli command "enable"
 action 2.0 cli command "monitor capture point stop test"
 action 3.0 syslog msg "Packet corruption detected and capture stopped!"
 action 4.0 snmp-trap intdata1 123456 strdata ""

Sender
======
event manager applet detect_bad_packet
event snmp-notification oid 1.3.6.1.4.1.9.10.91.1.2.3.1.9. 
oid-val "123456" op eq src-ip-address 20.1.1.1
 action 1.0 cli command "enable"
 action 2.0 cli command "monitor capture point stop test"
 action 3.0 syslog msg "Packet corruption detected and capture stopped!"

前のボックスのコードは、15.0(1)M でテストされた設定であることに注意してください。このコードをお客様の環境で実行する前に、お客様が使用する特定の Cisco IOS バージョンでテストすることをお勧めします。

データ分析

1. キャプチャが完了したら、TFTP を使用して PC にエクスポートします。
2. ネットワーク プロトコル アナライザ（Wireshark など）を使用してキャプチャを開きます。
3. QoS マーキングを使用した場合は、各パケットをフィルタリングします。
   

   ip.dsfield.dscp==0x08

   
   

   "0x08"は、DSCP値AF21に固有です。別のDSCP値を使用すると、パケットキャプチャ自体またはDSCP値の変換チャートのリストから正しい値を取得できます。詳細については、「DSCP 値と優先値」を参照してください。

4. 送信者からのキャプチャの廃棄 ping を特定し、そのパケットを、受信側と送信側の両方のキャプチャで見つけます。
5. 次の図に示すように、そのパケットを両方のキャプチャからエクスポートします。
   

   

   

6. 2つのバイナリ比較を行います。これらが同じ場合、送信中にエラーはなく、Cisco IOSが受信側でfalse negativeをスローしたか、送信側で誤ったキーを使用しました。どちらの場合も、Cisco IOSのバグが問題です。パケットが異なる場合、パケットは送信で改ざんされています。
   
   FC の暗号化エンジンから送信されるパケットを次に示します。
   

   *Mar  1 00:01:38.923: After encryption:
   05F032D0:                   45000088 00000000          E.......
   05F032E0: FF3266F7 0A01201A 0A012031 7814619F  .2fw.. ... 1x.a.
   05F032F0: 00000001 DE9B4CEF ECD9178C 3E7A7F24  ....^.LolY..>z.$
   05F03300: 83DCF16E 7FD64265 79F624FB 74D5AEF2  .\qn.VBeyv${tU.r
   05F03310: 5EC0AC16 B1F9F3AB 89524205 A20C4E58  ^@,.1ys+.RB.".NX
   05F03320: 09CE001B 70CC56AB 746D6A3A 63C2652B  .N..pLV+tmj:cBe+
   05F03330: 1992E8AF 2CE2A279 46367BDB 660854ED  ..h/,b"yF6{[f.Tm
   05F03340: 77B69453 83E47778 1470021F 09436285  w6.S.dwx.p...Cb.
   05F03350: CB94AEF5 20A65B1F 480D86F6 125BA12E  K..u &[.H..v.[!. 

   
   
   ピアで受信した、同じパケットを次に示します。
   

   4F402C90:                   45000088 00000000          E.......
   4F402CA0: FF3266F7 0A01201A 0A012031 7814619F  .2fw.. ... 1x.a.
   4F402CB0: 00000001 DE9B4CEF ECD9178C 3E7A7F24  ....^.LolY..>z.$
   4F402CC0: 83DCF16E 7FD64265 79F624FB 74D5AEF2  .\qn.VBeyv${tU.r
   4F402CD0: 5EC0AC16 B1F9F3AB 89524205 A20C4E58  ^@,.1ys+.RB.".NX
   4F402CE0: 09CE001B 70CC56AB 00000000 00000000  .N..pLV+........
   4F402CF0: 00000000 00000000 00000000 00000000  ................
   4F402D00: 00000000 00000000 00000000 00000000  ................
   4F402D10: 00000000 00000000 00000000 00000000  ................

   
   
   この時点では、ISPの問題である可能性が高く、そのグループがトラブルシューティングに関与している必要があります。

一般的な問題

• Cisco Bug ID CSCed87408 は、83xs の暗号化エンジンのハードウェア問題について説明しています。これは、任意の発信パケットが暗号化時に破損したために認証エラーが発生し（認証が使用されている場合）、受信側でパケットがドロップされるという問題です。ここで重要なのは、これらのエラーが表示されるのが 83x 自体ではなく、着信側デバイスであることを認識することです。
  
  
• また、このエラーが、古いコード ショーを実行するルータで表示される場合もあります。15.1(4)M4 などの最新バージョンのコードにアップグレードすると、問題を解決できます。
  
  
• ハードウェアとソフトウェアのどちらの問題であるかを確認するには、ハードウェア暗号化を無効にします。引き続きログ メッセージが表示される場合は、ソフトウェアの問題です。そうでない場合は、RMA で問題を解できます。
  ハードウェア暗号化を無効にすると、負荷の大きい VPN トンネルの重大なネットワーク劣化を引き起こす場合があることに注意してください。そのため、このドキュメントで説明したプロシージャはメンテナンス時間帯に実行することをお勧めします。

関連情報

• テクニカル サポートとドキュメント – Cisco Systems

更新履歴