Firepower Threat Defenseのハイアベイラビリティに関する問題のトラブルシューティング
内容
はじめに
このドキュメントでは、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(FMC)マネージド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 Chassis Manager
プライマリ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：フェールオーバーが有効または無効です。
このホスト：セカンダリ – スタンバイ準備完了。 このデバイスの役割とインターフェイスの状態。
その他のホスト：プライマリ – アクティブ 他方のデバイスはアクティブ状態で、現在のデバイスと通信します。
> 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グループへの参加に失敗したり失敗したりする場合は、失敗したユニットにログインし、ハイアベイラビリティページに移動して、フェールオーバー履歴リンクをクリックします。
APP-SYNCエラー
show failover historyの出力に、App Syncの障害が示された場合、HA検証フェーズの時点で問題が発生しています。このフェーズでは、ユニットが高可用性グループとして正しく機能できるかどうかをシステムがチェックします。
「From State is App Sync」というメッセージが表示され、ノードが「Standby Ready」状態に移行すると、「All validation passed」というメッセージが表示されます。
検証に失敗すると、ピアはDisabled (Failed)状態に移行します。ピアが高可用性グループとして機能するように、問題を解決してください。
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
==========================================================================
スタンバイノードが「HA state progression failed due to APP SYNC timeout」でHAに参加できない
スタンバイFTDコマンドラインで、/ngfw/var/log/ngfwmanager.logにapp-syncタイムアウトの理由が表示される必要があります。
この段階では、アクティブユニットがアプリケーションの同期がまだ進行中であると認識しているため、ポリシーの展開も失敗します。
ポリシーの導入により、「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 keepaliveメッセージを通知しないことを意味します。
もう一方のデバイスにログインしてみます。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 DownまたはDisk Failure
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モジュールのさまざまな原因が考えられます。IPSでこの問題の根本原因を見つけるには、TACを開くことを推奨します。
==========================================================================
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 Threat Defense/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
==========================================================================
関連情報
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
3.0 |
27-Nov-2024 |
再認定 |
1.0 |
06-Apr-2022 |
初版 |
フィードバック