firepower脅威対策のハイアベイラビリティに関する問題のトラブルシューティング
内容
概要
このドキュメントでは、Firepower Threat Defense(FTD)のハイアベイラビリティ(HA)の運用、検証、およびトラブルシューティングの手順について説明します。
前提条件
要件
次の項目に関する知識があることが推奨されます。
- FTDおよびASAプラットフォーム
- FTDアプライアンスでのパケットキャプチャ
このドキュメントで説明されているコンセプトをよりよく理解するために、『Firepower設定ガイド：FirepowerアプライアンスでのFTDハイアベイラビリティの設定』を参照することを強くお勧めします。
使用するコンポーネント
このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。
- シスコFTD
- Cisco Firepower Management Center（FMC）
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
背景説明
情報と例はFTDに基づいていますが、概念のほとんどは適応型セキュリティアプライアンス(ASA)にも完全に適用できます。
FTDは、次の2つの主要な管理モードをサポートしています。
- FMC経由のオフボックス：リモート管理とも呼ばれます。
- firepower Device Manager(FDM)経由のオンボックス – ローカル管理とも呼ばれます。
設計オプション
FTDの設計上の観点からは、次の図に示すように直接接続できます。
または、次の図に示すように、レイヤ2(L2)スイッチを介して接続できます。
HA用語
| アクティブ |
アクティブASAはすべてのトラフィックフローを受信し、すべてのネットワークトラフィックをフィルタリングします。設定の変更はアクティブASAで行われます。 |
| HAリンク |
フェールオーバーペアの2台のユニットは、フェールオーバーリンクを通じて常に通信し、各ユニットの動作ステータスを判別して、設定変更を同期します。リンク上で共有される情報は次のとおりです。
|
| プライマリ |
これは、通常、HAを作成するときに最初に設定されるユニットです。この重要な点は、ASA HAの両方のデバイスがまったく同じ瞬間に起動した場合、プライマリがアクティブな役割を担うことです。 |
| セカンダリ |
これは、HAを作成するときに通常2番目に設定されるユニットです。この重要な点は、ASA HAの両方のデバイスがまったく同じ瞬間に起動した場合、セカンダリがスタンバイロールを引き継ぐことです。 |
| スタンバイ |
スタンバイASAはライブトラフィックを処理せず、アクティブデバイスからの接続と設定を同期し、フェールオーバーが発生した場合にアクティブロールを引き継ぎます。 |
| 状態リンク |
アクティブユニットは、状態リンクを使用して、接続の状態情報をスタンバイデバイスに渡します。したがって、スタンバイユニットは特定のタイプの接続を維持でき、ユーザには影響しません。この情報は、フェールオーバーが発生したときに存在する接続をスタンバイユニットが維持するのに役立ちます。注：フェールオーバーとステートフルフェールオーバーに同じリンクを使用すると、インターフェイスを最適に維持できます。ただし、大規模な設定でトラフィック量の多いネットワークを使用している場合は、ステートリンクとフェールオーバーリンク用に専用のインターフェイスを検討する必要があります。ステートフルフェールオーバーリンクの帯域幅は、デバイスのデータインターフェイスの最大帯域幅と一致する必要があることを推奨します。 |
HA状態
| アクティブ |
デバイスは現在ネットワーク上のライブトラフィックを処理しており、実行する必要があるすべての設定変更をこのデバイスで実行する必要があります。 |
| アプリの同期 |
この状態のデバイスは、アクティブデバイスの設定を同期します。 |
| 一括同期 |
この状態のデバイスは、アクティブデバイスの設定を同期します。 |
| Disabled |
ユニットのフェールオーバーがディセーブルになっている（コマンド：no failover）。 |
| ネゴシエーション |
デバイスはアクティブデバイスの可用性をチェックし、アクティブデバイスがスタンバイ状態でないとアクティブロールを引き継ぎます。 |
| スタンバイ準備完了 |
現在、デバイスはトラフィックを処理しませんが、アクティブデバイスにヘルスチェックの問題が発生した場合はアクティブロールが引き継がれます。 |
| 同期の設定 |
設定は、アクティブデバイスからスタンバイデバイスに複製されます。 |
| コールドスタンバイ |
デバイスはフェールオーバー時にアクティブとして引き継ぎますが、接続イベントは複製しません。 |
HA状態のフロー図
プライマリ（ピアが接続されていない）:
セカンダリ（アクティブ接続ピアあり）:
UIの検証
Firepower Management CenterマネージドFTD HA
FTD HAの状態は、次の図に示すように、Device > Device Managementの順に移動するとFMC UIから確認できます。
FDM管理対象FTD HA
プライマリFDM概要ページ：
セカンダリFDM概要ページ：
ASDMマネージドASA HA
プライマリASAへのASDMホームページ：
セカンダリASAへのASDMホームページ：
FTD/ASA HAを実行する4100/9300用Firepowerシャーシマネージャ
プライマリFCM論理デバイスページ：
セカンダリFCM論理デバイスページ：
CLIの確認
> show running-config failover
failover
failover lan unit secondary
failover lan interface failover-link GigabitEthernet0/2
failover replication http
failover link failover-link GigabitEthernet0/2
failover interface ip failover-link 10.10.69.49 255.255.255.0 standby 10.10.69.89
ここで考慮すべき重要なポイントは次のとおりです。
フェールオーバー
failover lan unit secondary —>ユニットがプライマリかセカンダリか
failover lan interface failover-link GigabitEthernet0/2 —>デバイスのフェールオーバーリンク物理インターフェイス
フェールオーバーレプリケーションHTTP
フェールオーバーリンクfailover-link GigabitEthernet0/2
failover interface ip failover-link 10.10.69.49 255.255.255.0 standby 10.10.69.89 —>プライマリおよびスタンバイデバイスフェールオーバーリンクのipアドレス。
> show failover
Failover On
Failover unit Secondary
Failover LAN Interface: failover-link GigabitEthernet0/2 (up)
Reconnect timeout 0:00:00
Unit Poll frequency 1 seconds, holdtime 15 seconds
Interface Poll frequency 5 seconds, holdtime 25 seconds
Interface Policy 1
Monitored Interfaces 0 of 311 maximum
MAC Address Move Notification Interval not set
failover replication http
Version: Ours 9.16(0)26, Mate 9.16(0)26
Serial Number: Ours 9A1JSSKW48J, Mate 9ABR3HWFG12
Last Failover at: 01:18:19 UTC Nov 25 2021
This host: Secondary - Standby Ready
Active time: 0 (sec)
slot 0: ASAv hw/sw rev (/9.16(0)26) status (Up Sys)
Interface outside (0.0.0.0): Normal (Not-Monitored)
Interface inside (192.168.45.2): Normal (Not-Monitored)
Interface diagnostic (0.0.0.0): Normal (Not-Monitored)
slot 1: snort rev (1.0) status (up)
slot 2: diskstatus rev (1.0) status (up)
Other host: Primary - Active
Active time: 707216 (sec)
Interface outside (0.0.0.0): Normal (Not-Monitored)
Interface inside (192.168.45.1): Normal (Not-Monitored)
Interface diagnostic (0.0.0.0): Normal (Not-Monitored)
slot 1: snort rev (1.0) status (up)
slot 2: diskstatus rev (1.0) status (up)
Stateful Failover Logical Update Statistics
Link : failover-link GigabitEthernet0/2 (up)
Stateful Obj xmit xerr rcv rerr
General 95752 0 115789 0
sys cmd 95752 0 95752 0
up time 0 0 0 0
RPC services 0 0 0 0
TCP conn 0 0 0 0
UDP conn 0 0 0 0
ARP tbl 0 0 20036 0
Xlate_Timeout 0 0 0 0
IPv6 ND tbl 0 0 0 0
VPN IKEv1 SA 0 0 0 0
VPN IKEv1 P2 0 0 0 0
VPN IKEv2 SA 0 0 0 0
VPN IKEv2 P2 0 0 0 0
VPN CTCP upd 0 0 0 0
VPN SDI upd 0 0 0 0
VPN DHCP upd 0 0 0 0
SIP Session 0 0 0 0
SIP Tx 0 0 0 0
SIP Pinhole 0 0 0 0
Route Session 0 0 0 0
Router ID 0 0 0 0
User-Identity 0 0 1 0
CTS SGTNAME 0 0 0 0
CTS PAC 0 0 0 0
TrustSec-SXP 0 0 0 0
IPv6 Route 0 0 0 0
STS Table 0 0 0 0
Rule DB B-Sync 0 0 0 0
Rule DB P-Sync 0 0 0 0
Rule DB Delete 0 0 0 0
Logical Update Queue Information
Cur Max Total
Recv Q: 0 5 504656
Xmit Q: 0 1 95752
Failover On：フェールオーバーは有効または無効です。
このホスト：セカンダリ – Standby Ready このデバイスの役割とインターフェイスの状態。
その他のホスト：プライマリ – アクティブ。 もう1つのデバイスはアクティブ状態で、現在のデバイスと通信します。
> show failover history
==========================================================================
From State To State Reason
==========================================================================
01:18:14 UTC Nov 25 2021
Not Detected Negotiation No Error
01:18:27 UTC Nov 25 2021
Negotiation Just Active No Active unit found
01:18:27 UTC Nov 25 2021
Just Active Active Drain No Active unit found
01:18:27 UTC Nov 25 2021
Active Drain Active Applying Config No Active unit found
01:18:27 UTC Nov 25 2021
Active Applying Config Active Config Applied No Active unit found
01:18:27 UTC Nov 25 2021
Active Config Applied Active No Active unit found
==========================================================================
デバイスの過去の状態と、それらの状態変更の理由を確認するには、次のコマンドを使用します。
> show failover state
State Last Failure Reason Date/Time
This host - Secondary
Standby Ready None
Other host - Primary
Active None
====Configuration State===
Sync Done - STANDBY
====Communication State===
Mac set
デバイスの現在の状態と最後のフェールオーバーの理由を確認します。
| フィールド |
説明 |
|---|---|
| 設定状態 |
設定同期の状態を表示します。 スタンバイユニットで可能な設定状態：
アクティブユニットで可能な設定状態：
|
| 通信状態 |
MACアドレスの同期のステータスを表示します。
|
| 日付/時刻 |
失敗の日付とタイムスタンプが表示されます。 |
| 最後の失敗の理由 |
最後に報告された障害の理由が表示されます。この情報は、障害状態がクリアされてもクリアされません。この情報は、フェールオーバーが発生した場合にのみ変更されます。 考えられる障害の原因：
|
| 都道府県 |
ユニットのプライマリ/セカンダリおよびアクティブ/スタンバイのステータスを表示します。 |
| このホスト/その他のホスト |
このホストは、コマンドが実行されたデバイスの情報を示します。別のホストは、フェールオーバーペアの他のデバイスの情報を示します。 |
> show failover descriptor
outside send: 00020000ffff0000 receive: 00020000ffff0000
inside send: 00020100ffff0000 receive: 00020100ffff0000
diagnostic send: 01020000ffff0000 receive: 01020000ffff0000
トラブルシュート
デバッグ
> debug fover ?
cable Failover LAN status
cmd-exec Failover EXEC command execution
fail Failover internal exception
fmsg Failover message
ifc Network interface status trace
open Failover device open
rx Failover Message receive
rxdmp Failover recv message dump (serial console only)
rxip IP network failover packet recv
snort Failover NGFW mode snort processing
switch Failover Switching status
sync Failover config/command replication
tx Failover Message xmit
txdmp Failover xmit message dump (serial console only)
txip IP network failover packet xmit
verify Failover message verify
キャプチャ：
フェールオーバーインターフェイスのキャプチャ：
このキャプチャを参照すると、フェールオーバーhelloパケットが送信された速度でフェールオーバーリンクに送信されているかどうかを確認できます。
> show capture
capture capfail type raw-data interface Failover [Capturing - 452080 bytes]
match ip host 10.197.200.69 host 10.197.200.89
> show capture capfail
15 packets captured
1: 09:53:18.506611 10.197.200.69 > 10.197.200.89 ip-proto-105, length 54
2: 09:53:18.506687 10.197.200.89 > 10.197.200.69 ip-proto-105, length 54
3: 09:53:18.813800 10.197.200.89 > 10.197.200.69 ip-proto-105, length 46
4: 09:53:18.814121 10.197.200.69 > 10.197.200.89 ip-proto-105, length 50
5: 09:53:18.814151 10.197.200.69 > 10.197.200.89 ip-proto-105, length 62
6: 09:53:18.815143 10.197.200.89 > 10.197.200.69 ip-proto-105, length 62
7: 09:53:18.815158 10.197.200.89 > 10.197.200.69 ip-proto-105, length 50
8: 09:53:18.815372 10.197.200.69 > 10.197.200.89 ip-proto-105, length 50
9: 09:53:19.514530 10.197.200.89 > 10.197.200.69 ip-proto-105, length 54
10: 09:53:19.514972 10.197.200.69 > 10.197.200.89 ip-proto-105, length 54
11: 09:53:19.718041 10.197.200.69 > 10.197.200.89 ip-proto-9, length 70
12: 09:53:20.533084 10.197.200.69 > 10.197.200.89 ip-proto-105, length 54
13: 09:53:20.533999 10.197.200.89 > 10.197.200.69 ip-proto-105, length 54
14: 09:53:20.686625 10.197.200.89 > 10.197.200.69 ip-proto-9, length 74
15: 09:53:20.686732 10.197.200.69 > 10.197.200.89 ip-proto-9, length 74
15 packets shown
フェールオーバーリンクでのARPキャプチャ：
このキャプチャを取得して、ピアのARPテーブルにMacエントリが含まれているかどうかを確認できます。
> show capture
capture caparp type raw-data ethernet-type arp interface Failover [Capturing - 1492 bytes]
> show capture caparp
22 packets captured
1: 11:02:38.235873 arp who-has 10.197.200.69 tell 10.197.200.89
2: 11:02:38.235934 arp reply 10.197.200.69 is-at 0:50:56:a0:85:6c
3: 11:03:47.228793 arp who-has 10.197.200.69 tell 10.197.200.89
4: 11:03:47.228870 arp reply 10.197.200.69 is-at 0:50:56:a0:85:6c
5: 11:08:52.231296 arp who-has 10.197.200.69 tell 10.197.200.89
6: 11:08:52.231387 arp reply 10.197.200.69 is-at 0:50:56:a0:85:6c
7: 11:32:49.134163 arp who-has 0.0.0.0 (ff:ff:ff:ff:ff:ff) tell 0.0.0.0 (0:0:0:0:0:0)
8: 11:32:50.226443 arp who-has 10.197.200.1 tell 10.197.200.28
9: 11:42:17.220081 arp who-has 10.197.200.89 tell 10.197.200.69
10: 11:42:17.221652 arp reply 10.197.200.89 is-at 0:50:56:a0:72:4d
11: 11:42:20.224124 arp who-has 10.197.200.89 tell 10.197.200.69
12: 11:42:20.225726 arp reply 10.197.200.89 is-at 0:50:56:a0:72:4d
13: 11:42:25.288849 arp who-has 10.197.200.69 tell 10.197.200.89
14: 11:42:25.288956 arp reply 10.197.200.69 is-at 0:50:56:a0:85:6c
15: 11:46:17.219638 arp who-has 10.197.200.89 tell 10.197.200.69
16: 11:46:17.220295 arp reply 10.197.200.89 is-at 0:50:56:a0:72:4d
17: 11:47:08.135857 arp who-has 10.197.200.69 tell 10.197.200.89
18: 11:47:08.135994 arp reply 10.197.200.69 is-at 0:50:56:a0:85:6c
19: 11:47:11.142418 arp who-has 10.197.200.89 tell 10.197.200.69
20: 11:47:11.143150 arp reply 10.197.200.89 is-at 0:50:56:a0:72:4d
21: 11:47:18.213993 arp who-has 10.197.200.69 tell 10.197.200.89
22: 11:47:18.214084 arp reply 10.197.200.69 is-at 0:50:56:a0:85:6c
22 packets shown
>
シナリオ
アクティブユニットから変更を展開する際に、ピアユニットがHAグループへの参加に失敗したり失敗したりする場合は、失敗したユニットにログインし、High Availabilityページに移動して、Failover Historyリンクをクリックします。
アプリ同期エラー
show failover historyの出力にアプリケーション同期の失敗が示されている場合、HA検証フェーズの時点で問題が発生しています。このフェーズでは、ユニットが高可用性グループとして正しく機能できるかどうかをシステムがチェックします。
「From State is App Sync」というメッセージが表示され、ノードが「Standby Ready」状態に移行すると、「All validation passed」というメッセージが表示されます。
検証が失敗すると、ピアは無効（失敗）状態に移行します。問題を解決して、ピアをハイアベイラビリティグループとして再度機能させます。
App Syncエラーを修正してアクティブユニットに変更を加えた場合は、それらを展開してから、ピアノードが参加できるようにHAを再開する必要があることに注意してください。
このメッセージは、問題の解決方法を説明するエラーを示します。これらのエラーは、ノードの参加と、その後の各展開で発生する可能性があります。
ノードの参加時に、アクティブユニットに最後に展開されたコンフィギュレーションに対してチェックが実行されます。
スタンバイノードが「CD App Sync error is App Config Apply Failed」でHAに参加できない
スタンバイFTDコマンドラインで、/ngfw/var/log/action_queue.logに設定エラーの理由が設定されている必要があります。
修復：設定エラーを特定し、必要な変更を行った後に、HAを再開できます。
Cisco Bug IDCSCvu15611を参照してください。
==========================================================================
From State To State Reason
==========================================================================
15:10:16 CDT Sep 28 2021
Not Detected Disabled No Error
15:10:18 CDT Sep 28 2021
Disabled Negotiation Set by the config command
15:10:24 CDT Sep 28 2021
Negotiation Cold Standby Detected an Active mate
15:10:25 CDT Sep 28 2021
Cold Standby App Sync Detected an Active mate
15:10:55 CDT Sep 28 2021
App Sync Disabled CD App Sync error is App Config Apply Failed
==========================================================================
スタンバイノードが「APP SYNC timeoutが原因でHA状態の進行が失敗した」というメッセージでHAに参加できない
スタンバイFTDコマンドラインで、/ngfw/var/log/ngfwmanager.logにapp-sync timeoutの理由が設定されている必要があります。
この段階では、アクティブユニットがアプリケーションの同期がまだ進行中であると認識しているため、ポリシーの展開も失敗します。
ポリシーの導入により、「newNode join/AppSyncプロセスが進行中であるため、設定の変更は許可されず、導入要求が拒否されます。しばらくしてから展開を再試行してください。」
修復：スタンバイノードでハイアベイラビリティを再開すると、問題が解決する場合があります。
Cisco Bug ID CSCvt48941を参照してください。
Cisco Bug ID CSCvx11636を参照してください。
==========================================================================
From State To State Reason
==========================================================================
19:07:01 EST MAY 31 2021
Not Detected Disabled No Error
19:07:04 EST MAY 31 2021
Disabled Negotiation Set by the config command
19:07:06 EST MAY 31 2021
Negotiation Cold Standby Detected an Active mate
19:07:07 EST MAY 31 2021
Cold Standby App Sync Detected an Active mate
21:11:18 EST Jun 30 2021
App Sync Disabled HA state progression failed due to APP SYNC timeout
==========================================================================
スタンバイノードが「CD App Sync error is Failed to apply SSP config on standby」でHAに参加できない
スタンバイFTDコマンドラインで、/ngfw/var/log/ngfwmanager.logに障害の正確な理由が示されている必要があります。
修復：スタンバイノードでハイアベイラビリティを再開すると、問題が解決する場合があります。
Cisco Bug IDを参照 CSCvy04965
==========================================================================
From State To State Reason
==========================================================================
04:15:15 UTC Apr 17 2021
Not Detected Disabled No Error
04:15:24 UTC Apr 17 2021
Disabled Negotiation Set by the config command
04:16:12 UTC Apr 17 2021
Negotiation Cold Standby Detected an Active mate
04:16:13 UTC Apr 17 2021
Cold Standby App Sync Detected an Active mate
04:17:44 UTC Apr 17 2021
App Sync Disabled CD App Sync error is Failed to apply SSP config on standby
==========================================================================
ヘルスチェックの失敗
「HELLO not heard from mate」とは、相手がオフラインであるか、フェールオーバーリンクがHELLOキープアライブメッセージを通信していないことを意味します。
もう一方のデバイスにログインしてみます。SSHが機能しない場合は、コンソールアクセスを取得し、デバイスが動作しているかオフラインであるかを確認します。
動作している場合は、show failover stateコマンドを使用して障害の原因を特定します。
正常に動作しない場合は、グレースフルリブートを実行して、コンソールにブートログが表示されるかどうかを確認します。表示されない場合は、デバイスにハードウェア障害がある可能性があります。
==========================================================================
From State To State Reason
==========================================================================
04:53:36 UTC Feb 6 2021
Failed Standby Ready Interface check
02:12:46 UTC Jul 11 2021
Standby Ready Just Active HELLO not heard from mate
02:12:46 UTC Jul 11 2021
Active Config Applied Active HELLO not heard from mate
==========================================================================
Snortのダウンまたはディスク障害
FTDで「Detect Inspection engine failure due to disk failure」というエラーが表示される場合は、2つの可能性があります。
検出エンジン（SNORTインスタンス）がダウンしている
これは、Linux側でコマンドpmtool statusを使用して検証できます。 | grep -i de,
修復：いずれかのインスタンスがダウンしている場合は、/ngfw/var/log/messagesを確認して原因を特定します。
デバイスのディスク使用率が高い
これは、Linux側でコマンドdf -Thを使用して検証できます。
修復：ディスクの大半を消費しているディレクトリを特定し、TACに連絡して不要なファイルを削除してください。
==========================================================================
From State To State Reason
==========================================================================
Active Config Applied Active No Active unit found
16:07:18 UTC Dec 5 2020
Active Standby Ready Other unit wants me Standby
16:07:20 UTC Dec 5 2020
Standby Ready Failed Detect Inspection engine failure due to disk failure
16:07:29 UTC Dec 5 2020
Failed Standby Ready My Inspection engine is as good as peer due to disk recovery
==========================================================================
サービスカードの障害
このような問題は、通常、ASA 5500-XデバイスのFirepowerモジュールの障害が原因で報告されます。show module sfr detailsを使用して、モジュールの健全性を確認してください。
修復：障害発生時にASA Syslogを収集します。これには、コントロールプレーンやデータプレーンの障害などの詳細が含まれる場合があります。
これは、SFRモジュールのさまざまな理由が原因である可能性があります。TACを開いてIPSのこの問題の根本原因を見つけることを推奨します。
==========================================================================
From State To State Reason
==========================================================================
21:48:19 CDT Aug 1 2021
Active Standby Ready Set by the config command
21:48:19 CDT Aug 1 2021
Standby Ready Just Active Service card in other unit has failed
21:48:19 CDT Aug 1 2021
Active Config Applied Active Service card in other unit has failed
==========================================================================
MIOハートビート障害
Firepower脅威対策/ASAは、FPR1K、2K、4K、9Kで「MIOブレードのハートビート障害」による障害を報告します。
Cisco Bug IDを参照 CSCvy14484
Cisco Bug IDを参照 CSCvh26447
==========================================================================
From State To State Reason
==========================================================================
20:14:45 EDT Apr 14 2021
Active Config Applied Active No Active unit found
20:15:18 EDT Apr 14 2021
Active Failed MIO-blade heartbeat failure
20:15:19 EDT Apr 14 2021
Failed Negotiation MIO-blade heartbeat recovered
==========================================================================
関連情報
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
2.0 |
18-Apr-2023 |
再認定 |
1.0 |
06-Apr-2022 |
初版 |
フィードバック