C9166でAP Disconnect - Max packet retransmission reached for APが発生する

[Yuki T]

お世話になっております。

C9166シリーズを利用していますが、DNAC上で頻繁に【AP Disconnect - Max packet retransmission reached for AP】が発生しており、原因が分かりません（数分間、無線LAN通信が停止します）

全ての9166シリーズで発生しているわけではありません。

機種：CW9166I-Q（Ver：17.15.2.52）

PoEインジェクター：AIR-PWRINJ6

Wireless Controller：Catalyst9800-40（Ver：17.15.2）

9166シリーズで同様の事象が発生したことがある or 原因が分かる方がいらっしゃいましたら、ご教示いただけますでしょうか。

よろしくお願いいたします。

※2025.4.15補足　9166シリーズのみならず1852Iシリーズでも発生しているようです。

[MyHomeNWLab]

Catalyst Center (DNA Center)側の情報だけだと詳細が追いにくいと思うので、
「事象が発生した該当時間のWLCとAPのログ」を見て切り分ける方法があるかと存じます。
Catalyst Centerが高価で気軽に検証しにくく情報が少ないので、WLCとAPとしてのログがあった方が情報を探しやすいと思います。

また、APのJoinが一時的に外れているのか、Joinが外れた場合はSecondary側にFail Overしているか、
それともAPが再起動しているのかで調査観点が変わるので明確化した方が良いです。
例えば通信経路に問題がありそうなのか、PoE Switchにも被疑がありそうなのか。

もしJoinが外れやすいように見える場合は、
AP Join ProfileのCAPWAP Timer関連の値が短くなっていないか、
特にFast Heartbeatが有効化 (1～10)されていないかの把握をした方が良いです。

例えばWANの回線品質に影響されていれば、下記の例のようにRetransmit (Re-Tx)系のログが大量が頻繁に出ている可能性があるかなと。

【ログの例】
[*03/28/2025 00:34:13.2669] Re-Tx Count=1, Max Re-Tx Value=3, SendSeqNum=82, NumofPendingMsgs=1
[*03/28/2025 00:34:13.2669]
[*03/28/2025 00:34:16.2681] Re-Tx Count=2, Max Re-Tx Value=3, SendSeqNum=82, NumofPendingMsgs=1
[*03/28/2025 00:34:16.2681]
[*03/28/2025 00:34:19.2692] Re-Tx Count=3, Max Re-Tx Value=3, SendSeqNum=83, NumofPendingMsgs=2

関連設定としては「AP Join Profile」の「CAPWAP」タブの「High Availability」タブより
「CAPWAP Timers」と「Retransmit Timers」のセクションが該当します。

改めて上述の確認観点をリスト化すると下記になります。

・該当時間のWLCのログ

・該当時間のAPのログ

・無線APのJoinが外れただけか、Secondary側にFail Overしたか、それとも再起動した形跡があるか (Uptimeなどより)

・CAPWAP Timerの設定値は現状どうなっているか

[Yuki T]

ありがとうございます。

確認事項についてですが、分かっている範囲では以下です。

・該当時間のWLCのログ

→Disjoined Max Retransmission to APのログが出ておりました。

・該当時間のAPのログ

→これと言って不自然なログはありませんでしたが、WLCからのレスポンスが無かったようです。

Discovery Response from WLCのIPアドレス

・無線APのJoinが外れただけか、Secondary側にFail Overしたか、それとも再起動した形跡があるか (Uptimeなどより)

→無線APのログは消えていなかったため、再起動はしておらずJoinが外れただけだと思います。

・CAPWAP Timerの設定値は現状どうなっているか

→Fast Heartbeatの値についてですが、1になっておりました。

以上です。

[MyHomeNWLab]

Fast Heartbeatが「1」だとAPが「1 秒間隔でWLCの応答をチェック」して、
それが途切れると、再送 (Retransmit)状態に入って
「(再送としての)Interval: デフォルトで 3 秒」 x 「再送回数: 固定で 3 回」で通信する挙動になっており、間隔が短すぎるのが気になりました。

別原因の可能性もあるかもしれませんが、参考程度にFast Heartbeatの視点を掘り下げてみます。

障害検知の時間が理論値で「Fast Hearbeatの間隔 + 再送分」になるはずで、
Intervalがデフォルトだと「1 + (3 * 3)」で「10」秒ですかね。

【補足】
Fast Heartbeatだと再送回数は"固定"で 3 回です。
設定項目「Count」を変更しても、下記ログのように「Max Re-Tx Value=3」の値が3から変わらないので固定値であるのを確認できます。

Re-Tx Count=1, Max Re-Tx Value=3, SendSeqNum=82, NumofPendingMsgs=1

ちなみに私の環境で「APの電源断」や「ACLでCAPWAPをdeny」して恣意的にJoinが外れるようにしたケースだと
基本的には「Disjoined Heart beat timer expiry」のログだったので、Fast Heartbeatが起因してそうかの確証がなかったです。

【ログのサンプル】
%CAPWAPAC_SMGR_TRACE_MESSAGE-5-AP_JOIN_DISJOIN: Chassis 1 R0/0: wncd: AP Event: AP Name: testap01 Mac: ****.****.**** Session-IP: 198.51.100.11[5248] 198.51.100.241[5246] Disjoined Heart beat timer expiry

設計の観点だと、Fast Heartbeatは「障害検知のプロセス」を短くできますが、
Secondary WLCへの「Fail Overのプロセス」により、Re-Joinにかかる分だけ、通信できない時間が増えてしまう可能性があるので、
短くしすぎると本末転倒になりかねないので注意が必要になります。

・障害検知のプロセス <<<< ここは短くチューニングできます。
・Fail Over (Join/Re-Join)のプロセス <<<< ここは一定時間の処理がかかるため、多発すると逆効果になります。

例えばPrimary WLCの障害が起こるのを早く気づくために
・検知時間を短く n "秒"レベルにチューニングして、その結果として頻繁にフラップして累積的に断時間が増えるより、
・障害が起こったのを検知するのに約 1 "分"かかるし、Fail Overを含めると数分約かかるけど、フラップしにくくする方向に寄せるのもあるかと存じます。

現実味のある具体的なシナリオとしては、
HA SSOで冗長化しているPrimary WLCのActive/Standbyがとも同時Downする可能性は(Issueでもなければ)低くなりますし、
メインDCレベルでPrimary WLCを巻き込んでダウンするのは大規模災害クラスの緊急事態かもしれないし、
それなら障害検知を極端に早めるのはやめて、フラップしない方に寄せて、数分程度の通信断は許容する方向とするなど。
Primary WLCをバージョンアップで止めるにしても、計画的なメンテナンス時間を設ければよいですし。


またCisco PressのC9800の本に記述がありましたが、
Fast Heartbeatは「WLCとAPが同一拠点内にある展開」で主に利用される「Central Switching (Local mode)」で活用するような機能で、
WAN跨ぎで回線遅延が発生するFlexConnect modeだと向かない可能性があります。

Understanding and Troubleshooting Cisco Catalyst 9800 Series Wireless Controllers | Cisco Press
https://www.ciscopress.com/store/understanding-and-troubleshooting-cisco-catalyst-9800-9780137492329
【書籍からの引用】
「Chapter10: C9800 High Availability」より

> This capability is typically more useful in central switching deployments as compared to FlexConnect deployments. The allowed range is 0–10 seconds with the default being disabled /0 seconds.

※備考: PDF版だとページ: 387 / 657

つらつらと書いてしまいましたが、
Fast Heartbeatは障害検知を早めるので、利用したくなる機能かなとは思いますけど、
設計における留意点があるので他の方への参考情報も兼ねての共有でした。

[Yuki T]

ご確認いただきましてありがとうございます。

こちらのログではDisjoined Heart beat timer expiryは出ていなかったため、Fast Heartbeatが原因ではない可能性が高いということですね。収集した情報をTACへお送りし、調査していただくようにいたします。

CAPWAPタイマーの箇所は気にしたことがなかったので、参考になりました。ありがとうございました。

[MyHomeNWLab]

私の環境では当該ログが出る再現性がある状態までは持っていけませんでしたが、
Fast Heartbeatを短くするとJoinが外れやすくなるの自体は、実機を一定時間稼働試験で確認した経験があります。
(念のための補足として、ログが出なかったと言って、要素としては除外はできない可能性が残っている意図となります。)

詳細はTACによる解析になると思いますが、
もしFast Heartbeatが起因する可能性が残っている場合は、
予備機があればHeartbeatを長めに調整したTagを割り振って、経過観察を仕込む方法があるかと存じます。

AP Join Profileが分かれるとそれに紐づくSite Tagも分かれるので。
予備機用は無線LANには繋がらないようにRadioを無効化して、事象が発生しやすい拠点に設置するなどすると、より比較しやすいかもしれません。

WAN回線などを含む通信経路や、AP台数のスケールも関係ある都合上、
その環境で試して実際の情報を取得した方が確実だと思うので、簡単なアイデアですが参考程度の共有でした。

[Yuki T]

本事象は再現性がなく不定期にランダムな無線AP（同じ無線APで複数回発生していることもほとんどない）で発生しているため、検証するには本番環境のタグを変更するしかないと考えてます。

（一部の無線APのタグのみを変更しても、そもそもその無線APで発生する可能性があったのか判断できないため）

しかし、Fast Heartbeatが1というのはあまりよろしくないと理解しましたので、今後見直すようにいたします。

ありがとうございました。

[MyHomeNWLab]

ランダム性があって対象を絞り込むのも、予備機に仕込んで再現するかも難しいんですね。
他の環境でも同様な事象が発生する可能性がありそうか気になってたので、実運用視点のリアルな情報を連携頂けて私も助かります。

[Yuki T]

そうなんです。

AIR-PWRINJ6は同じ型式でも2種類あり、こちらの環境では混在しているのでPoEインジェクターが原因の可能性もあります。

何がともあれ事象の再現が出来ないことが原因特定を難しくしています。。

原因が判明し解決しましたら、こちらに共有させていただきます。

[Yuki T]

（共有）原因はまだ判明しておりませんが、1852シリーズでも発生しているようです。

PoEインジェクター・スイッチが原因ではなさそうなので、WLCもしくは無線APのバージョンが原因の可能性が高そうです。