はじめに
Fortinet は 2026 年 9 月 3 日、FortiGate のインターフェースが物理的に Down のままとなり、NP7Lite 関連のエラーが記録される事象について、Fortinet Community に Troubleshooting Tip を公開しました。管理上は有効化しているにもかかわらず、複数のインターフェースが物理リンクを確立しない状態が対象です。
記事のタイトルには G series と記載されていますが、Scope 欄は FortiGate とのみ記載されており、具体的な対象モデルと FortiOS バージョンは示されていません。根本原因、Bug ID、修正版も本記事の作成時点では公表されていません。
複数ポートが同時に Link Down している場合も、まずケーブル、光モジュール、対向ポートなどの基本的な物理層を確認します。それでも状況が変わらず、NP7Lite 関連エラーも確認できる場合は、自己判断で再起動や初期化へ進むのではなく、指定された診断情報とコンソール出力を採取して Fortinet TAC へ相談します。TFTP によるファームウェア再導入は、TAC から指示があった場合の手段です。
- 管理状態と物理リンク状態の違い
- Fortinet が公表している事実と、未公表のまま残っている項目
- ケーブル・SFP 起因の切り分けと、NP7Lite 関連事象を疑う目安
- TAC へ提出する診断情報の採取手順と、提出時に注意する情報
- 再起動と TFTP 再導入を自己判断で実施すべきでない理由
- ファームウェア再導入後、設定を復元する前に確認する項目
FortiGate G シリーズで確認されている症状
この事象は、インターフェースの管理状態と物理リンク状態が食い違う形で現れます。まず両者の違いを整理したうえで、記録されるエラーと、現時点で公表されている範囲を確認します。
管理状態と物理リンク状態は別の情報
- 管理状態
-
管理者が設定として有効・無効を指定する論理的な状態です。設定上で有効にしていれば、対向との接続状況に関係なく有効として扱われます。
- 物理リンク状態
-
対向機器との間で物理リンクが確立しているかどうかの状態です。ケーブル、光モジュール、対向ポート、機器内部の処理のいずれかに問題があると Down のままになります。
今回の事象は、管理状態が有効であるにもかかわらず、物理リンク状態が Down のまま復帰しないという組み合わせで現れます。設定画面だけを見ていると設定に問題がないように見えるため、物理リンク状態を個別に確認しないと状況を把握しにくい点が特徴です。
参考: Fortinet Community – Troubleshooting Tip: Troubleshooting FortiGate interfaces remaining physically down NP7Lite (G serries)
“multiple interfaces may remain physically down even when they are administratively enabled”
（管理上は有効化されている場合でも、複数のインターフェースが物理的に Down のまま残ることがあります）
https://community.fortinet.com/fortigate-3/troubleshooting-tip-troubleshooting-fortigate-interfaces-remaining-physically-down-np7lite-g-serries-229766
起動時または稼働中に記録される NP7Lite 関連エラー
Fortinet は、システム起動中または稼働中のコンソール出力に NP7Lite 関連のエラーが表示される場合があるとしています。公開記事に掲載されているエラーは、次の形式です。
NP7LITE_ERR(2026/08/19 10:20:44.642197109 np7lite_hw_mii_cmd:506) :data0 = ffff, phy = 0b, op = 0, cmd = 8031, data = 0000 0000 0000 0000 0000タイムスタンプや phy の値は環境によって異なります。公開記事では、対象となる phy の値が異なる同種のエラーが複数行にわたって記録される例が示されています。各フィールドの意味について、Fortinet は公式な説明を公開していないため、本記事でも解釈は行いません。
判明していることと未公表のこと
現時点で確認できる情報と、公表されていない情報を整理すると次のとおりです。
| 項目 | 現時点の状況 |
|---|---|
| 症状 | 管理上有効な複数インターフェースが物理的に Down のまま |
| 関連エラー | 起動時または稼働中に np7lite_hw_mii_cmd を含む NP7Lite 関連エラーが記録される場合がある |
| 情報源と公開日 | Fortinet Community の Troubleshooting Tip（2026 年 9 月 3 日、Fortinet Staff 投稿） |
| Scope の記載 | 記事タイトルは G series、Scope 欄は FortiGate |
| 対象モデル・対象 FortiOS | 未公表 |
| Bug ID・根本原因 | 未公表 |
| 修正版・推奨 FortiOS | 未公表 |
| 再起動のみで復旧するケース | 公式な記載なし |
| ハードウェア交換の判定条件 | 未公表（TAC が判断） |
NP7Lite 関連エラーが記録されているという事実だけでは、根本原因を確定できません。Fortinet も原因を示しておらず、案内されているのは診断情報の採取と TAC への提供までです。この事象はセキュリティ上の脆弱性として公表されたものではないため、脆弱性対応としての緊急パッチ適用とは切り分けて扱うことが適切です。
ケーブルや SFP の問題と NP7Lite 関連事象を切り分ける
物理リンクが確立しない場合は、NP7Lite 関連の診断に進む前に、ケーブル、光モジュール、対向機器側の要因を確認します。一般的な物理層の確認を先に済ませておくと、TAC への説明も整理しやすくなります。
一般的な物理層の要因を先に確認する
次の確認は、Fortinet の当該記事に記載された手順ではなく、物理リンクが確立しない場合の一般的な初動切り分けです。単一ポートだけで発生している場合も、まず次の一般的な物理層の確認から進めます。
- ケーブルの抜き差しと、既知の正常なケーブルへの交換
- 光モジュールの抜き差しと、対応する型番のモジュールへの交換
- 対向機器側のポート状態、速度・デュプレックス設定、シャットダウン状態
- 同じ機器の別ポートへ差し替えた場合にリンクが確立するか
- 対向を別の機器へ変更した場合に挙動が変わるか
NP7Lite 関連事象を疑う目安
一般的な物理層の確認で状況が変わらず、次の条件が重なる場合は、Fortinet が案内する NP7Lite 関連の診断情報の採取へ進む段階と考えられます。
- 複数のインターフェースが同時に物理的に Down のままになっている
- 該当インターフェースが管理上は有効な状態になっている
- 起動時または稼働中のコンソール出力に NP7Lite 関連エラーが記録されている
- ケーブル、光モジュール、対向ポートを入れ替えても状態が変わらない
これらが重なっても原因が NP7Lite にあると確定できるわけではなく、TAC へ調査を依頼する目安として扱います。切り分けの目的は原因の断定ではなく、調査に必要な情報を漏れなく揃えることです。
自機の NP7Lite 搭載有無を確認する
Fortinet が案内する診断コマンドのうち、SerDes 状態と内部ログの採取は NP7Lite を搭載したモデルが対象です。搭載しているプロセッサーと接続インターフェースは、FortiOS の管理ガイドに記載された次のコマンドで確認できます（https://docs.fortinet.com/document/fortigate/7.6.6/administration-guide/926361/diagnosing-npu-based-interfaces）
diagnose npu np7lite port-listNP7Lite は、NP7 より処理容量を抑えたネットワークプロセッサーです。FortiOS 7.6.5 のハードウェアアクセラレーションガイドでは、NP7Lite アーキテクチャを掲載しているモデルとして FortiGate 50G/51G、70G/71G、Rugged 70G、90G/91G、120G/121G、200G/201G が挙げられています。
参考: Fortinet Document Library – NP7Lite processors（Hardware Acceleration）
“The NP7Lite processor is a lower capacity version of the NP7 processor”
（NP7Lite プロセッサーは、NP7 プロセッサーより処理容量を抑えたバージョンです）
https://docs.fortinet.com/document/fortigate/8.0.0/hardware-acceleration/512774/np7lite-processors
NP7Lite を搭載していることと、今回の事象の影響を受けることは別の話です。Fortinet は対象モデルを公表していないため、搭載機種の一覧から影響有無を判断するのは避けたほうが安全です。
TAC へ提出する診断情報と採取手順
ここからのコマンドは、Fortinet Community の当該 Troubleshooting Tip に記載されているものです（https://community.fortinet.com/fortigate-3/troubleshooting-tip-troubleshooting-fortigate-interfaces-remaining-physically-down-np7lite-g-serries-229766）。出力項目の詳細な意味は公開されていないため、解釈は行わず、指定された出力をそのまま保存して提出することが基本になります。
インターフェース単位のリンク状態やカウンターを採取します。事象を認識した直後に、Down しているポートごとに実行します。
diagnose hardware deviceinfo nic <interface_name>対象ポートが複数ある場合は、すべてのポートについて出力を保存します。正常にリンクしているポートの出力も併せて採取しておくと、比較材料になります。
システム側で記録されたクラッシュログを採取します。NIC 情報の採取に続けて実行し、出力全文を保存します。
diagnose debug crashlog readNP7Lite を搭載したモデルでは、SerDes 状態とプラットフォーム情報、内部ログを採取します。前の手順に続けて実行します。
diagnose npu np7lite serdes-statusfnsysctl cat /proc/net/np7lite/platformfnsysctl cat /proc/net/np7lite/np7lite_0/x1-logfnsysctl cat /proc/net/np7lite/np7lite_0/x2-log4 つの出力をそれぞれ個別に保存します。ログは事象の発生後に上書きや切り詰めが起きる可能性があるため、状況を確認したらできるだけ早い段階で採取しておくことが推奨されます。
Fortinet は、NP7Lite 関連エラーが表示される場合、システム起動時のコンソール出力も採取することを推奨しています。コンソールケーブルで接続し、ターミナルソフトのログ保存を有効にしたうえで、起動開始からログインプロンプトが表示されるまでを記録します。
この採取は、復旧を目的として再起動を実施するためのものではありません。再起動を伴う作業が発生する場合に、その機会を利用して起動シーケンスを記録するという位置付けで扱います。
コマンド出力と併せて、状況を文章で整理しておくと調査が進みやすくなります。発生日時、対象ポート名、接続構成（対向機器とメディアの種別）、再現状況、直前に実施した作業やファームウェア更新の有無をまとめます。
採取した出力と発生状況をまとめ、Fortinet TAC へチケットを作成します。チケット作成の手順は Fortinet Community で公開されています（https://community.fortinet.com/customer-service-42/customer-service-tip-how-to-create-a-ticket-for-fortinet-tac-177144）
提出する情報に含まれる内容を確認する
診断出力や設定ファイルには、シリアル番号、管理 IP アドレス、ホスト名、インターフェース構成といった情報が含まれます。社内規程で外部提供に制限がある場合は、提出前に含まれる内容を確認しておくことが推奨されます。
対応する FortiOS で設定ファイルを TAC へ提出する場合は、機密値をマスキングした難読化バックアップも選択できます。ただし、TAC 提出用のファイルと、TFTP 再導入後の復旧に使用する設定バックアップは目的が異なります。難読化バックアップだけを唯一の復旧用ファイルとせず、復元に使用する通常の設定バックアップを別に取得してください。詳細は関連記事『FortiGate 設定ファイルのバックアップとリストアの手順と HA 構成の注意点』で解説しています。
再起動と TFTP 再導入を判断する際の注意
物理リンクが復帰しない状況では、機器の再起動やファームウェアの入れ直しを試したくなりますが、今回の一次情報はこれらを復旧策として案内しているわけではありません。位置付けを確認しておきます。
Fortinet の記載における前後関係
Fortinet の記載は、TAC エンジニアからの要請がある場合を前提として、再起動後も物理 Down と NP7Lite エラーが継続するときに、設定をバックアップしたうえで TFTP によるフォーマットとファームウェア再導入へ進む、という順序になっています。再起動によって復旧するケースが公式に示されているわけではなく、再起動は復旧手段ではなく状態確認の一過程として現れています。
TFTP によるフォーマットとファームウェア再導入は、TAC の指示がある場合に限って実施することが推奨されます。適用するファームウェアの選定も自己判断では行わず、対象モデルと指示されたバージョンを確認します。今回の一次情報は、特定バージョンへの更新によって事象が解消すると案内しているわけではありません。
フォーマット前に必要なバックアップ
TFTP によるフォーマットは、機器を工場出荷状態へ戻す操作です。実施前に設定を保存し、カスタム IPS シグネチャを使用している場合はそちらも保存します。
execute backup config
execute backup ipsuserdefsig参考: Fortinet Community – Technical Tip: Formatting and loading FortiGate firmware image using TFTP
“will reset the FortiGate unit to factory default settings”
（FortiGate ユニットは工場出荷時の設定にリセットされます）
https://community.fortinet.com/fortigate-3/technical-tip-formatting-and-loading-fortigate-firmware-image-using-tftp-99151
コンソール接続、TFTP サーバーの準備、ブートメニューでの操作といった一連の手順は上記の公式記事に整理されているため、本記事では重複して掲載しません。
通常の初期化と TFTP 再導入は別の操作
同じ「工場出荷状態へ戻る」という結果でも、両者は操作の対象が異なります。execute factoryreset は稼働中の FortiOS 上から設定を初期化する操作で、ファームウェアそのものは入れ替わりません。一方の TFTP 再導入は、ブートデバイスをフォーマットしたうえでファームウェアを書き直す操作です。TAC から TFTP 再導入を指示された場合に、通常の初期化コマンドで代替することはできません。
初期化コマンドの種類と使い分けについては、関連記事『FortiGate を工場出荷状態に初期化する手順と factoryreset コマンドの違い』で整理しています。
設定復元前の初期状態で確認すること
ファームウェアの再導入後は、設定を復元する前の初期状態のまま動作を確認します。先に設定を戻してしまうと、設定起因かどうかを切り分ける材料が失われます。
- 物理インターフェースが正常に Link Up するか
- 起動時のコンソール出力に
np7lite_hw_serdes_checkのエラーが残っているか - NP7Lite のログに初期化時のエラーが継続して記録されているか
- 事象発生時と同じインターフェースが物理的に Down のままか
- 設定を復元していない状態でも同じ事象が再現するか
初期状態でも再現する場合、Fortinet は同じ採取ログを添えて新しい TAC チケットとして報告するよう案内しています。この段階で設定起因の可能性は切り分けられますが、ハードウェア交換へ進むかどうかの判定条件は公表されていないため、次の判断は TAC に委ねる形になります。
初期状態での確認は、設定を復元する前に行います。確認項目とログの保存先を事前に決めておくと、確認漏れを防ぎやすくなります。
まとめ
今回の事象は、対象モデル、FortiOS バージョン、Bug ID、根本原因、修正版のいずれも公表されていない段階にあります。運用側でできるのは、原因を推測することではなく、切り分けの結果と指定された診断情報を揃えて TAC の調査へつなぐことです。
- 対象モデルと修正版が未公表の段階にある事象
- 管理状態が有効でも物理リンクが Down のままとなる症状
- 複数ポートの同時 Down と NP7Lite 関連エラーという手掛かり
- ケーブルや光モジュールの確認を先に済ませる初動切り分け
- NIC 情報、crashlog、SerDes 状態、内部ログ、起動出力の採取
- TAC の指示がある場合に限って実施する TFTP 再導入
- 設定を復元する前の初期状態での再現有無の確認
以上、最後までお読みいただきありがとうございました。
