質問 1「DFS 対応で Upgrade する場合、UpgradePath の途中のOS入手はサポート契約必要でしょうか」
DFS 対応でアップグレードをする場合は契約は不要です。FN74035 の対応としてアップグレードをしたいので、そのアップグレードパスの途中のリリースを提供して欲しいと記載の上、サービスリクエストをオープンしてください。詳しいお問い合わせ方法については次のリンクもご参照ください。
Field Notice: FN74035 の TACへのお問い合わせ方法
質問 2「AireOSv8.5 台の推奨バージョンは、P.19 では 8.5.182.7 となっていますが、FN74035 対応の 8.5.182.11 ではないのでしょうか」
AireOS 8.5 リリースについては、8.5.182.7 も 8.5.182.11 も推奨です。8.5.182.11 は 8.5.182.7 での不具合修正に加えて FN74035 の修正を含むという差分がありますので、Wave2 AP を利用されていて FN 対応をする場合は 8.5.182.11 を選択してください。AP2700 向けの修正 CSCwc81656 も 8.5.182.11 には含まれています。
質問 3「EWC については今後どのバージョンまで対応するのかという情報はありますでしょうか。6EAP には EWC 対応をしないとなるので収束方向に向かうものと推測しておりますが、9100 シリーズ AP の EoSM までは対応していく形でしょうか 」
EWC は既存 IOS-XE と同じライフサイクルですので、IOS-XE の EoS アナウンスの通りです。EoSM になるまでは新規不具合の修正などを対応いたします。ただし、リリースには一定程度の期間が空きますので、EoSM 間近に新規の不具合が見つかったとしても、すでに最後のリリースが発行されてしまっていて修正が提供できない場合も出てくる可能性があります。Wi-Fi6E AP で EWC を復活させるという予定はありません。
質問 4「17.9.5 のリリース予定について教えてください」
2024 年の 2 月から 3 月を予定しています。順調にいけば 2 月の早い段階になるかと存じますが、予定は変更される可能性が常にありますのでご了承ください。
質問 5「17.6.5 に挙げた際に DCA のチャネルリストに W56 の 144ch が追加されていることを確認しています。AP2802 や C9120 において設定してみましたが、not support と表示されました。日本のドメインにおいて、今後のリリースで 144 チャネルは利用可能とするエンハンス予定はありますか」
144 チャネルを使用可能な国内モデルの AP は CW9163/9166 などの Wi-Fi6E 対応 AP からサポートされていますが、以前の Wave2 AP などではサポートしていません。従来の AP でサポートを開始する予定はございません。今後の製品ロードマップについては営業へも合わせてご確認ください。Wave2 AP などに対しても 144 チャネルが設定可能なように見えてしまう問題がありましたので、次の記事もご参照ください。
WLC の表示でチャネル 144 が利用されているように見える問題
質問 6「ISSU は MD 間のダウングレードでもサポートしている認識でよろしいでしょうか」
恐れ入りますが、ISSU (In-Service Software "Upgrade") はダウングレードはサポートしておりません。
質問 7「CIMC の不具合は、事象発生後、100% 継続して事象が継続しますでしょうか。それともタイミングによって自然復旧する場合もある不具合でしょうか。例えば、AP の帰属に問題が発生した場合に自然復旧するかどうかになります。VerUp の緊急性、必要性を判断できる情報を頂きたいと考えております」
タイミングで自然復旧するというケースは確認されていないため、一度起きると継続して発生するとお考えください。
質問 8「restconf のサポートは現状もされていないでしょうか」
restconf コマンドを設定すること自体は問題ありませんが、API を使った応答のやり取りに関しては TAC でのサポートではなく、devnet でのコミュニティベースのサポートとなります。
質問 9「ベストプラクティスに記載のある vty 数ですが、こちらは restconf にも影響しますでしょうか」
はい、ラインを消費しますので影響します。
質問 10「WNCd の Load 値の設定で負荷が高そうな場合は AP の 2 倍に増やすのが推奨とのことですが、"負荷が高そう"の部分の目安 (想定クライアント数がこれくらい等) の情報はございますでしょうか」
通常のキュービック状オフィスや病院では AP の数と同じ値を load に設定していただき、スタジアム、食堂、カンファレンスルームなどでは1.5倍から2倍程度を設定することを推奨します。CPU の利用率 (wncd プロセスの利用率）は次のコマンドなどで確認できますので、コア間、プロセス間の利用率のバランスを見ていただくことも一つの目安になると考えます。
(コマンドと出力例)
C9800-40#show processes cpu platform sorted | inc Core | wncd
Core 0: CPU utilization for five seconds: 1%, one minute: 0%, five minutes: 0%
Core 1: CPU utilization for five seconds: 0%, one minute: 1%, five minutes: 1%
Core 2: CPU utilization for five seconds: 0%, one minute: 0%, five minutes: 0%
Core 3: CPU utilization for five seconds: 0%, one minute: 0%, five minutes: 0%
Core 4: CPU utilization for five seconds: 0%, one minute: 0%, five minutes: 0%
Core 5: CPU utilization for five seconds: 0%, one minute: 0%, five minutes: 0%
Core 6: CPU utilization for five seconds: 0%, one minute: 0%, five minutes: 0%
Core 7: CPU utilization for five seconds: 0%, one minute: 0%, five minutes: 0%
Core 8: CPU utilization for five seconds: 0%, one minute: 1%, five minutes: 0%
Core 9: CPU utilization for five seconds: 0%, one minute: 2%, five minutes: 0%
Core 10: CPU utilization for five seconds: 2%, one minute: 1%, five minutes: 0%
Core 11: CPU utilization for five seconds: 1%, one minute: 2%, five minutes: 0%
Core 12: CPU utilization for five seconds: 0%, one minute: 0%, five minutes: 0%
Core 13: CPU utilization for five seconds: 0%, one minute: 0%, five minutes: 0%
Core 14: CPU utilization for five seconds: 0%, one minute: 0%, five minutes: 0%
Core 15: CPU utilization for five seconds: 0%, one minute: 2%, five minutes: 1%
21872 21470 0% 0% 0% S 276564 wncd_4
21632 21241 0% 0% 0% S 277064 wncd_3
21409 21012 0% 0% 0% S 274876 wncd_2
21184 20783 0% 0% 0% S 307444 wncd_1
20963 20608 0% 0% 0% S 277148 wncd_0
また、どの Site タグがどの wncd に割当たっているかは次のコマンドで確認可能です。
show wireless loadbalance tag affinity
質問 11「WNCd のAutomatic Load-Balacing は RF 環境に左右される部分はあるにしても、まずは有効にしてみるのがベターという認識でいいでしょうか。有効にしても高 CPU 等になったら、OFF にして手動で Load 設定をするというイメージでいいでしょうか」
有効にする前に、Neighbor が見えているかをチェックした方が良いと思います。DNAC があれば可視化された形で容易に確認できますが、本日紹介した WCAE でもある程度確認できます。およそユーザの動く範囲内でNeighborが組まれている状況がわかったら、この機能を有効にすることで最適化できると考えます。一部のコアだけHigh CPU という形になったら、あるいは AP が偏ったら、手動で load を設定という方法に戻すことをお考えください。AP がどのコアにどれくらい割り当てられているかは次のコマンドで確認できます。
show wireless loadbalance ap affinity wncd [0-15]
質問 12「WPA3 + dot1 x 認証（外部 RADIUS サーバ）の利用予定があります。既存環境適用時の考慮事項や不具合の事例などがあれば教えていただきたいです」
考慮する点はいろいろあると思いますが、例えば RADIUS 認証をどのようにスキップして高速ローミングを実施するかということです。→ WPA3 + OKC + dot1x なのか WPA3 + FT + dot1x なのか。
前者ではうまくいかない場合があるとの報告があります。2023 年も暮れる時期となりましたので、相当の現行クライアントが FT に対応してきていると考えられます。WPA3+802.11r で高速ローミングを実施いただくことをお勧めします。
また、Local mode なのか Flexconnect AP なのかという観点もあると思います。Flex の場合、Central Authentication にするか Local Authentication にするかを選択しなければなりません。セッション中に述べた dead criteria 未設定によりうまく RADIUS サーバのロードバランスができないことがあると、問題になると思います。AireOS の頃は気にすることのあまりないパラメタでした。
質問 13「WLAN セッションタイムアウト時間の推奨値が長くなったことの理由はありますか 」
昔のデフォルト値の 30 分だと、長くとも 30 分おきに必ず再認証が走ります。例えば 9 時 17 時で勤務する方の場合、16 回くらいの再認証ということになります。その際に PTK の作り直し、EAPOL 4way-handshake のやり直しといった処理が発生し、それに付随して DHCP によるアドレス取得なども生じます。これが全部うまくいっているうちは良いのですが、中には互換性の問題や電波の問題で失敗する回もあるかもしれません。つまり残念ながら再認証の機会は接続断となる機会でもありうるわけです。8 時間勤務されるのであれば、8時間はこのような機会がない方がより安定している可能性があります。また、再認証の回数が多ければそれだけ RADIUS サーバや DHCP サーバに負荷がかかることも予想されます。AireOS の時代はこの値は30分間でしたが、それは当時はより弱い暗号化スイートが広く使われていたため、その弱さを補うために短い値が採用されていた背景があります。今や AES-CCMP は当然サポートしている端末がほとんどです。メリットとデメリットを比較した結果、17.12.1 以降では 8時間をデフォルト値とすることにしました。
質問 14「9800-L はコアが 1 つという説明でしたが、この場合、サイトタグはあまり意識する必要がないという理解でよいでしょうか」
はい、コア間の負荷分散という意味では SIte タグを分ける意味はありません。ただ、トラブルシューティングの時の切り分けに役立つ可能性があります。また、mDNS サービスは CPU 負荷を高める大きな要因の一つですが、mDNS のサービス提供範囲を site tag で区切ることも可能になりますので、その意味ではパフォーマンス向上に寄与する可能性があります。
質問 15「17.12. 台がリリースされているが、推奨の台が 17.9. から 17.12. へ変わるのはいつごろでしょうか」
通常、推奨とするためにはリリースから少なくとも1ヶ月程度はおきたいということと、十分な数が利用され（ダウンロードされ）ているかどうかということ、オープンされている SR および不具合でのバージョンの確認、現在推奨にしているリリースの安定度など、いくつかの観点から多角的、総合的に判断をいたしますので、明確な時期は申し上げられません。現時点では 17.12.2 を推奨とする判断は出しておりません。
質問 16「6E 出力の SSID でステルス設定にするとうまくつながらないという話を聞いたことがあるのですが、こうした 6E 関連で何かトラブルがまとまっている等のページや情報はありますでしょうか」
恐れ入りますがまとまったページはないため、Community 内での記事作成などを検討したいと存じます。6E ではビーコンのフォーマットに変更が加わっていますので、それを認識できていないのかもしれません。
質問 17「meraki dashboard で c9800 も 24/august に GA になるそうですが、このときのサポート先は、meraki 側になる予定でしょうか」
Meraki Dashboard を使った Cloud Monitoring ソリューションについては 2024 年に GA 予定です。サポート体制については準備を進めておりますが、適切な手段で変更内容をお伝えしたいと思います。その上で、Meraki Dashboard については Meraki のエンジニアによる対応となる可能性もあると考えておいていただけますでしょうか。
質問 18「17.12で AP を初期化再起動すると Console BaudRate が 115200 へ変更されてしまい困ってます。これを防止したり、AP の BaudRate を 9600 へ戻す方法はありませんか？WLC から AP の設定をしたいです」
リリースノートや AP の HW インストールガイドに記載の通り 17.12.1 から baud rate 初期値が 115200 へ変更されています。単純に 17.12 へアップグレードした場合は以前の 9600 のままを維持しますが、capwap ap erase all などで初期化すると 115200 へ変更されます。その場合は AP へ "SSHで" 接続し、下記のコマンドを入れ、その後 AP を再起動することで boot 後の baud rate を変更できます。
configure boot baudrate 9600
show boot により現在の baud rate を確認できます。
Console Baudrate: 9600
質問 19「Essential のライセンスで ISSU を実行しようとするとどの様な動作となりますか？（コマンドがない？実行されない？ライセンス違反だが実行される？※もし回答可能であればで大丈夫です）」
Essential のまま ISSU を実行するという動作を想定しておらず、サポート対象外の操作となりますので、恐れ入りますが期待される動作結果についてもお答えすることが難しいです。
質問 20「WCAEはEWCもサポートしますか」
はい、動作します。
質問 21「C9800-L:ROMMON と PHY のアップグレードで、先に ROMMON 入れてしまったらどうなりますか？即、TAC SR でしょうか」
まず、これは C9800-L 特有の問題です (CSCvx1253)。この場合最初の ROMMON のアップデートが反映されていない状態になりますので、慌てず一旦再起動いただき、その後に目的の ROMMON へ再度アップグレードを実施いただければ問題ありません。
質問 22「DNAC から c9800 に設定プッシュすると何がプッシュされているのかが分かりにくいので，c9800 側のデバッグコマンド等でプッシュの最中に CLI 形式でログを表示することができませんか」
プッシュの最中に、というとなかなか難しいかと思いますが、show logging により TACACS+ のコマンド履歴として何が実行されたのかを追うことは可能です。それを Syslog などへ出力することもできると思います。
質問 23「144ch の利用についての関連なのですが、先ほどの回答ですと現行リリースされているAPでは 144ch の技適取得はしていないので使用不可の理解でよろしいでしょうか。使用可能な AP が TAC 側で把握されておりましたら情報をいただけますでしょうか」
CW9162/9163/9164/9166/IW9167 などの Wi-Fi6E 対応モデルでは 144 チャネルが認められています。その他今後も含めたものについては下記のコンプライアンス確認サイトからもご確認いただけます。
Cisco Product Approval Status
公開の難しい情報などは掲載を見送らせていただくこともございます。ご容赦いただけますと幸いです。
当オンラインセミナーのご参加、誠にありがとうございました。 またのご参加をお待ちしております。
