LACP レート slow と fast の違い｜タイムアウトと障害検出時間の仕組み

はじめに

LACP の設定には、slow / fast と呼ばれるレート設定があります。「fast にすると障害検出が速くなる」という理解で使われることが多い一方、「そもそも何の間隔なのか」「両端で不一致だとどうなるのか」「既定の slow のままでよいのか」を正確に説明できるエンジニアは意外に多くありません。メーカーによって設定の呼称や指定方法が異なる（Cisco は rate、FortiGate は speed、YAMAHA SWX は timeout）ことも、理解を難しくしている一因です。

この記事では、LACP レートの仕組みを規格の考え方から整理し、メーカー別の設定方法、不一致時の挙動、fast を選ぶべきケースまでを解説します。

結論を先に述べると、slow は 30 秒間隔の LACPDU 送信で 90 秒タイムアウト、fast は 1 秒間隔で 3 秒タイムアウトです。規格上の実体は「自分が対向に要求するタイムアウト値」であり、要求は LACPDU に載って対向へ伝わり、対向がそれに合わせて送信間隔を調整します。多くの機器の既定値は slow で、通常はそのままで問題ありません。リンクダウンを伴わない障害の検出を高速化したい構成でのみ fast を検討し、その場合も両端で設定を揃えることを推奨します。

なお、LACP の基本動作（アクティブ / パッシブ、LACPDU によるネゴシエーション）は、関連記事『リンクアグリゲーションの仕組みと方式の違い』で解説しています。

LACP レート（slow / fast）の仕組み

LACPDU の送信間隔とタイムアウトの関係

「slow＝30 秒間隔、fast＝1 秒間隔」という説明は結果としては正しいのですが、仕組みを正確に理解するには、規格（IEEE 802.1AX）で定義されているのはタイムアウト値の方だと捉えるのが近道です。

LACP には 2 つのタイムアウトが定義されています。

タイムアウト	値	対応する送信間隔	一般的な呼称
Long Timeout	90 秒	30 秒（Slow Periodic）	slow レート
Short Timeout	3 秒	1 秒（Fast Periodic）	fast レート

ポイントは、この 2 つの数値の関係です。タイムアウトは「LACPDU を 3 回連続で受信できなかったら対向を失ったとみなす」という設計であり、送信間隔の 3 倍がタイムアウト値になります。

参考: show lacp timeouts, Junos OS CLI Reference（Juniper 公式）
“LACP timeout occurs when 3 consecutive PDUs are missed.”
（LACP タイムアウトは、3 つの連続する PDU を受信できなかった場合に発生します）
https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/command/show-lacp-timeouts.html

そして重要なのは、タイムアウトの要求が LACPDU に載って対向へ伝わるという点です。各ポートは、自分が要求するタイムアウト（Long か Short か）を LACPDU の状態フィールドで対向に通知します。それを受け取った対向側は、要求されたタイムアウトの 3 分の 1 の間隔で LACPDU を送信します。つまり、「自分の設定」が制御するのは「対向の送信間隔」であり、自分の送信間隔は「対向の設定」で決まる、という相互の関係になっています。

YAMAHA SWX が設定コマンドを lacp timeout（Long / Short）という名前にしているのは、この規格の考え方に忠実な体系です。一方、Cisco の lacp rate や FortiGate の lacp-speed は送信間隔側から見た呼称ですが、内部で行われていることは同じ「タイムアウト要求の通知」です。この視点は、後述するレート不一致時の挙動を理解する土台になります。

障害検出時間の違い（90 秒と 3 秒）

slow と fast の実質的な違いは、LACPDU の途絶による障害検出にかかる時間です。slow では最大 90 秒、fast では最大 3 秒で、応答のなくなったリンクを LAG から切り離します。90 秒という時間は、その間障害リンクへトラフィックが送られ続ける（破棄され続ける）可能性があることを意味し、シビアな要件の環境では無視できない長さです。

ただし、ここで見落とされがちな重要な前提があります。物理リンクダウンを伴う障害は、LACP のタイムアウトを待たずにリンクダウン検出によって即座に切り離されるという点です。ケーブル抜けや対向ポートの故障といった典型的な障害では、slow でも fast でも切り離しの速さはほぼ変わりません。

LACP タイムアウトが障害検出の主役になるのは、リンクダウンを伴わない障害、たとえば次のようなケースです。

• 両機器の間にメディアコンバーターや中継機器が存在し、対向側の区間で障害が発生しても自機器側のリンクはアップしたままの構成
• 対向機器のソフトウェア的なハングアップ（ポートは物理的にアップだが LACP 処理が停止）
• 設定変更ミスによる片側の LACP 停止

メーカー別のレート設定と既定値

この章では、本クラスターで扱ってきた主要機器のレート設定を整理します。設定手順の詳細は各機器の記事に譲り、ここではレート設定に絞って比較します。

Cisco・FortiGate・Linux の設定（送信間隔を指定する方式）

機器	設定コマンド	既定値	設定単位
Cisco（IOS-XE）	lacp rate {normal｜fast}	normal（30 秒）	物理インターフェース
Cisco（NX-OS）	lacp rate fast（戻す場合は lacp rate normal）	30 秒	物理インターフェース
FortiGate	set lacp-speed {slow｜fast}	slow	aggregate インターフェース
Linux（bonding）	lacp_rate={slow｜fast}	slow	bond インターフェース

参考: Cisco Nexus 5000 Series NX-OS Layer 2 Interfaces Command Reference（Cisco 公式）
“The normal rate at which LACP packets are sent is 30 seconds.”
（LACP パケットが送信される通常のレートは 30 秒です）
https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5000/sw/command/reference/layer2/n5k-l2-cr/n5k-l2_cmds_l.html

いずれも「レート」「スピード」という送信間隔側の呼称ですが、注意深く公式ドキュメントを読むと、Cisco の説明は「LACP 制御パケットが LACP 対応インターフェースへ送られてくるレートを設定する」という記述になっています。つまり、設定しているのは自分の送信間隔ではなく、「対向にこの間隔で送ってほしい」というタイムアウト要求です。前章で整理した規格の仕組みが、Cisco の設定体系にもそのまま表れています。

各機器の設定手順の全体像は、関連記事『Cisco EtherChannel の設定手順』『FortiGate リンクアグリゲーションの設定手順』を参照してください。

YAMAHA SWX の設定（タイムアウト値を指定する方式）

YAMAHA SWX シリーズは、他メーカーと異なり、タイムアウト値そのものを指定する体系です。

設定値	タイムアウト	対向に要求する送信間隔	他メーカーの呼称との対応
lacp timeout long（既定値）	90 秒	30 秒	slow 相当
lacp timeout short	3 秒	1 秒	fast 相当

公式技術資料には、指定したタイムアウト値が LACP フレームで対向機器へ伝えられ、受信した対向機器がその 3 分の 1 の間隔で LACPDU を送信する、という仕組みが明記されています。呼称こそ他メーカーと異なりますが、規格の動作をそのまま設定名にした、最も誤解の少ない体系といえます。「slow＝Long＝30 秒送信＝90 秒タイムアウト」という対応さえ押さえれば、異メーカー間の設定の突き合わせで混乱することはありません。

SWX の設定手順の詳細は、関連記事『YAMAHA リンクアグリゲーションの設定手順』を参照してください。

レート不一致時の挙動

「片側が fast、もう片側が slow のままだったら何が起こるのか」は、このテーマで最も質問の多いポイントです。規格の仕組みから導ける範囲と、実装に依存する範囲を分けて整理します。

タイムアウト値は LACPDU で対向に伝わる

前章で整理したとおり、各ポートは自分が要求するタイムアウトを LACPDU で対向に通知し、対向はそれに合わせて送信間隔を調整します。この仕組みを、機器 A が fast、機器 B が slow という不一致構成に当てはめると、次のようになります。

方向	何が起こるか
A（fast）の要求 → B	B は「Short Timeout（3 秒）」の要求を受け取り、1 秒間隔で LACPDU を送信する
B（slow）の要求 → A	A は「Long Timeout（90 秒）」の要求を受け取り、30 秒間隔で LACPDU を送信する

各方向が独立して動作するため、規格上、この構成でも LAG 自体は成立します。「不一致だと LAG が組めない」というのは、モード（アクティブ / パッシブ）の不一致と混同された誤解であることが多く、レートの不一致は成立可否ではなく障害検出の非対称性の問題として現れます。

不一致構成が招く非対称な障害検出

上記の構成で障害（リンクダウンを伴わない LACPDU の途絶）が発生すると、検出時間が方向によって大きく異なります。

• A 側: B からの LACPDU が 3 秒途絶えた時点で、該当リンクを LAG から切り離す
• B 側: A からの LACPDU が 90 秒途絶えるまで、該当リンクを LAG メンバーとして使い続ける

この非対称性が問題になるのは、片方向だけ通信が途絶するタイプの障害です。A 側は素早くリンクを切り離して残りのメンバーへ迂回する一方、B 側は最大 90 秒間、すでに死んでいるリンクへトラフィックを送り続ける可能性があります。LAG は成立しているのに、障害時の挙動だけが両側で食い違うという、切り分けの難しい状態を生むのが不一致構成の実害です。

また、これは規格のモデルから導かれる整理であり、実装によっては不一致構成でネゴシエーションが不安定になる・リンクがフラップするといった事例も報告されています。規格上成立するからといって不一致のまま運用する理由はなく、ベンダー各社が推奨するとおり、レートは両端で一致させることを推奨します。

実機での不一致の確認は、これまでの個別記事で解説した確認コマンドの出力で可能です。

 Cisco

show lacp internal/show lacp neighbor の Flags 欄（S＝Slow 要求、F＝Fast 要求）自分と対向でフラグが異なれば不一致です。

 FortiGate

diagnose netlink aggregate name <名前> の actor state / partner state（6 文字フラグの 2 文字目が S / F）

異メーカー接続の設定の突き合わせ全般は、関連記事『リンクアグリゲーションのメーカー相互接続』を参照してください。

fast を選ぶべきケースと注意点

ここまでの整理を踏まえ、実務で fast を選ぶべきかどうかの判断基準をまとめます。結論から言えば、既定の slow を基本とし、fast は「リンクダウンで検出できない障害への備えが必要な区間」に限定して採用するのが推奨方針です。

障害検出の高速化が必要な構成

物理リンクダウンを伴う障害は slow でも即座に検出されます。fast の価値が出るのは、次のような構成・要件です。

 メディアコンバーターや中継装置を挟む区間

対向側の区間の障害が自機器側のリンクダウンとして現れない構成では、LACP タイムアウトが事実上唯一の自動検出手段になります。90 秒と 3 秒の差がそのまま障害の継続時間の差になるため、fast の効果が最も大きいケースです。

 対向機器のソフトウェア障害への備え

ポートは物理的にアップしたまま LACP 処理が停止する（機器のハングアップ等）シナリオを想定する場合、fast であれば 3 秒で該当リンクを切り離せます。

 秒単位の停止許容時間が定義されている区間

データセンター内のコアリンクなど、障害時の縮退が 90 秒かかることが要件上許容できない場合です。

fast の副作用と導入時の確認ポイント

fast の 3 秒タイムアウトは、障害だけでなく「機器が正常だが LACP 処理が一時的に止まる場面」でも発動します。これが fast の最大の注意点です。

無停止アップグレード（ISSU）との相性

代表例が Cisco Nexus の ISSU です。ISSU の実行可否を確認する show lacp issu-impact コマンドの事前チェックには、fast が無効であることが条件として含まれています。

switch# show lacp issu-impact
For ISSU to Proceed, Check the following:
1. All port-channel member port should be in a steady state.
2. LACP rate fast should not be enabled on member ports.
The following ports are not ISSU ready
Eth5/15 , Eth6/15 , （以下略）

（出力例の出典: Cisco Community https://community.cisco.com/t5/data-center-switches/nexus-upgrade-incompatible/td-p/3834777）

理屈は明快で、ISSU 中はスーパーバイザ切替等で LACP の制御処理が数秒間停止しうるため、3 秒タイムアウトの fast では対向がタイムアウトを検出してリンクを切り離してしまい、「無停止」が成立しなくなるためです。fast を有効にした区間は、ISSU のような無停止メンテナンスの前提条件から外れる可能性があることを、運用設計に織り込んでおく必要があります。

HA・スタック構成の系切替との相性

同じ理屈は、FortiGate の HA フェイルオーバーやスイッチスタックのマスター切替など、制御プレーンが一時的に引き継がれる動作全般に当てはまります。切替に要する時間が 3 秒を超える機器・構成では、fast が誤検出によるリンクフラップの引き金になりえます。採用前に、対象機器の構成ガイド・リリースノートで fast と冗長化機能の組み合わせに関する記述を確認することを推奨します。

対向機器がレートを変更できないケース

サーバーの NIC チーミングなど、実装によっては LACP タイムアウトの変更手段が提供されていない（または既定から変えにくい）ものがあります。両端を fast に揃えられない場合は、前章で述べた非対称構成になるため、片側だけの fast 化は行わず、slow のまま運用する判断が無難です。

導入時の確認ポイント（チェックリスト）

 両端の機器がレート設定に対応しており、両方を fast に揃えられるか

 ISSU・ファームウェア更新・系切替などのメンテナンス手順に fast との相性問題がないか（構成ガイド・リリースノートで確認）

 導入後、show lacp counters（Cisco）や show lacp-counter（YAMAHA SWX）等で LACPDU の送受信間隔が意図どおりかを確認したか

まとめ

LACP レートの実体は、slow / fast という送信間隔の呼称の裏にある「対向へ要求するタイムアウト値」（Long＝90 秒 / Short＝3 秒）です。この仕組みを押さえると、不一致構成で LAG が成立する理由も、障害検出が非対称になる理由も一本の線でつながります。fast は強力な高速化手段ですが、メンテナンス動作との相性という副作用を持つため、要件が明確な区間に限定して両端一致で採用することが、安定運用との両立につながります。

• LACP レートの規格上の実体は対向へ要求するタイムアウト値（90 秒 / 3 秒）
• 要求は LACPDU で対向に伝わり対向が送信間隔（30 秒 / 1 秒）を調整する
• 物理リンクダウンを伴う障害では slow と fast の検出速度に差はほぼ出ない
• fast が効くのはリンクダウンを伴わない障害の検出（中継装置経由の構成等）
• レート不一致でも LAG は成立するが障害検出時間が方向によって非対称になる
• fast は ISSU や系切替など制御プレーン停止を伴う動作と相性問題がありうる
• 既定の slow を基本とし要件が明確な区間のみ両端一致で fast を採用する

以上、最後までお読みいただきありがとうございました。