Catalyst 9800 WLC を使用した AP 参加プロセスの理解

はじめに

このドキュメントでは、Cisco Catalyst 9800 WLC を使用した AP 参加プロセスについて詳しく説明します。

前提条件

要件

次の項目に関する知識があることが推奨されます。

• Control and Provisioning Wireless Access Points(CAPWAP)の基本的な知識
• ワイヤレスLANコントローラ(WLC)の使用に関する基本的な知識

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。

• Catalyst 9800-L WLC、Cisco IOS® XE Cupertino 17.9.3
• Catalyst 9120AXEアクセスポイント

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

背景説明

CAPWAPセッションの確立

Control And Provisioning Wireless Access Point(CAPWAP)は、アクセスポイント(AP)とワイヤレスLANコントローラ(WLC)で使用される転送メカニズムを提供するプロトコルです。CAPWAPコントロール用のセキュアな通信トンネルを介して、コントロールとデータプレーンの情報を交換します。

AP加入プロセスを詳しく説明するには、Control And Provisioning Wireless Access Point(CAPWAP)セッション確立プロセスを理解することが重要です。

CAPWAPプロセスを開始するには、APにIPアドレスが必要であることに注意してください。APにIPアドレスがない場合、APはCAPWAPセッション確立プロセスを開始しません。

1. アクセスポイントがディスカバリ要求を送信します。詳細については、「WLCの検出方法」セクションを参照してください
2. WLCがディスカバリ応答を送信します。
3. DTLSセッションの確立。この後、この後のすべてのメッセージは暗号化され、パケット分析ツールでDTLSアプリケーションデータパケットとして表示されます。
4. アクセスポイントが接続要求を送信
5. WLCが参加応答を送信します。
6. APはイメージチェックを実行します。WLCと同じイメージバージョンが含まれている場合は、次の手順に進みます。存在しない場合は、WLCからイメージをダウンロードし、リブートして新しいイメージをロードします。この場合は、ステップ1の処理を繰り返します。
7. アクセスポイントが設定状態要求を送信します。
8. WLCが設定ステータス応答を送信する
9. アクセスポイントがRUN状態になる
10. RUN状態の間、CAPWAPトンネルメンテナンスは次の2つの方法で実行されます。
    1. キープアライブは、CAPWAPデータトンネルを維持するために交換されます
    2. APがWLCにエコー要求を送信します。WLCには、それぞれのエコー応答で応答する必要があります。これは、CAPWAP制御トンネルを維持するためです。

CAPWAPセッション確立プロセス

注：RFC 5415に従い、CAPWAPはUDPポート5246（CAPWAP制御用）および5247（CAPWAPデータ用）を使用します。

DTLSセッションの確立

アクセスポイントがWLCから有効なディスカバリ応答を受信すると、アクセスポイント間にDTLSトンネルが確立され、以降のすべてのパケットが安全なトンネルを介して送信されます。次に、DTLSセッションを確立するプロセスを示します。

1. APがClient Helloメッセージを送信
2. WLCが、検証に使用されるcookieを含むHelloVerifyRequestメッセージを送信します。
3. APが検証に使用されるcookieを含むClientHelloメッセージを送信します。
4. WLCは次のパケットを順に送信します。
   1. サーバHello
   2. 証明書
   3. サーバキー交換
   4. 証明書要求
   5. サーバHelloDone
5. APは次のパケットを順番に送信します。
   1. 証明書
   2. ClientKeyExchange（必須）
   3. 証明書の確認
   4. ChangeCipherSpec
6. WLCはAPのChangeCipherSpecに対し、独自のChangedCipherSpecで応答します。
   1. ChangeCipherSpec

WLCによって最後に送信されたChangedCipherSpecメッセージの後、セキュアトンネルが確立され、両方向で送信されるすべてのトラフィックが暗号化されるようになります。

ワイヤレスLANコントローラの検出方法

アクセスポイントにネットワーク内の1つのWLCの存在を知らせる方法はいくつかあります。

• DHCPオプション43:このオプションは、加入するWLCのIPv4アドレスをAPに提供します。このプロセスは、APとWLCが異なるサイトにある大規模な導入に便利です。
• DHCPオプション52:このオプションは、加入するWLCのIPv6アドレスをAPに提供します。このコマンドは、DHCPオプション43と同じシナリオで便利に使用できます。
• DNSディスカバリ:APはドメイン名CISCO-CAPWAP-CONTROLLER.localdomainを照会します。参加するWLCのIPv4またはIPv6アドレスを解決するようにDNSサーバを設定する必要があります。このオプションは、WLCがAPと同じサイトに保存されている導入に便利です。
• レイヤ3ブロードキャスト:APは自動的にブロードキャストメッセージを255.255.255.255に送信します。APと同じサブネット内のすべてのWLCが、このディスカバリ要求に応答すると想定されます。
• スタティック設定：次のコマンドを使用できます。 capwap ap primary-base <wlc-hostname> <wlc-IP-address>コマンドを使用して、APでWLCのスタティックエントリを設定します。
• モビリティディスカバリ：以前、APがモビリティグループの一部であったWLCに加入していた場合、APはそのモビリティグループ内にあるWLCのレコードも保存します。

注：次に示すWLCディスカバリ方式には優先順位がありません。

ワイヤレスLANコントローラの選択

いずれかのWLCディスカバリ方法を使用して、任意のWLCからディスカバリ応答を受信したAPは、この基準で加入するコントローラを1つ選択します。

1. プライマリコントローラ(capwap ap primary-base <wlc-hostname> <wlc-IP-address>コマンドで設定)
2. セカンダリコントローラ(capwap ap secondary-base <wlc-hostname> <wlc-IP-address>コマンドで設定) 
3. ターシャリコントローラ(capwap ap tertiary-base <wlc-hostname> <wlc-IP-address> コマンドで設定)
4. プライマリ、セカンダリ、またはターシャリWLCが以前に設定されていなかった場合、APは、使用可能なAPの最大キャパシティを持つ独自のディスカバリ応答を使用して、ディスカバリ要求に応答した最初のWLC(つまり、任意の時点でほとんどのAPをサポートできるWLC)への加入を試みます。

CAPWAPステートマシン

APコンソールでは、CAPWAPステートマシンを追跡できます。この追跡は、「CAPWAPセッションの確立」セクションで説明されている手順を実行します。

CAPWAP状態：検出

ここでは、ディスカバリ要求とディスカバリ応答を確認できます。APがDHCP（オプション43）経由でWLC IPを受信し、既知のWLCにディスカバリ要求を送信する方法を確認します。

[*09/14/2023 04:12:09.7740] CAPWAP State: Init
[*09/14/2023 04:12:09.7770] 
[*09/14/2023 04:12:09.7770] CAPWAP State: Discovery
[*09/14/2023 04:12:09.7790] Discovery Request sent to 172.16.0.20, discovery type STATIC_CONFIG(1)
[*09/14/2023 04:12:09.7800] Discovery Request sent to 172.16.5.11, discovery type STATIC_CONFIG(1)
[*09/14/2023 04:12:09.7800] Got WLC address 172.16.5.11 from DHCP.
[*09/14/2023 04:12:09.7820] Discovery Request sent to 172.16.0.20, discovery type STATIC_CONFIG(1)
[*09/14/2023 04:12:09.7830] Discovery Request sent to 172.16.5.11, discovery type STATIC_CONFIG(1)
[*09/14/2023 04:12:09.7840] Discovery Request sent to 255.255.255.255, discovery type UNKNOWN(0)
[*09/14/2023 04:12:09.7850] 
[*09/14/2023 04:12:09.7850] CAPWAP State: Discovery
[*09/14/2023 04:12:09.7850] Discovery Response from 172.16.0.20
[*09/14/2023 04:12:09.8030] Discovery Response from 172.16.5.11
[*09/14/2023 04:12:09.8060] Discovery Response from 172.16.0.20
[*09/14/2023 04:12:09.8060] Discovery Response from 172.16.5.11
[*09/14/2023 04:12:09.8060] Discovery Response from 172.16.5.11
[*09/14/2023 04:12:09.8060] Discovery Response from 172.16.0.20
[*09/14/2023 04:12:09.8060] Discovery Response from 172.16.5.169
[*09/14/2023 04:12:09.8060] Discovery Response from 172.16.5.169

このAPは、スタティックに設定されたWLC(172.16.0.20)とDHCPオプション43(172.16.5.11)で示されたWLCの両方からディスカバリ応答を受信するだけでなく、ブロードキャストディスカバリメッセージを受信したため、同じサブネット内の別のWLC(172.16.5.169)からもディスカバリ応答をを受信しました。

CAPWAPの状態：DTLSのセットアップ。

ここでは、APとWLCの間のDTLSセッションが交換されます。

[*09/27/2023 21:50:41.0000] CAPWAP State: DTLS Setup
[*09/27/2023 21:50:41.7140] sudi99_request_check_and_load: Use HARSA SUDI certificat

CAPWAP状態：参加

DTLSセッションを確立した後、WLCへの接続要求がセキュアセッション経由で送信されます。WLCからの参加応答を使用して、この要求にただちに応答する方法を確認します

[*09/27/2023 21:50:41.9880] CAPWAP State: Join
[*09/27/2023 21:50:41.9910] Sending Join request to 172.16.5.11 through port 5270
[*09/27/2023 21:50:41.9950] Join Response from 172.16.5.11 
[*09/27/2023 21:50:41.9950] AC accepted join request with result code: 0
[*09/27/2023 21:50:41.9990] Received wlcType 0, timer 30
[*09/27/2023 21:50:41.9990] TLV ID 2216 not found
[*09/27/2023 21:50:41.9990] TLV-DEC-ERR-1: No proc for 2216

CAPWAP状態：イメージデータ

APは自身のイメージをWLCのイメージと比較します。この場合、APのアクティブパーティションとバックアップパーティションの両方に、WLCとは異なるイメージがあるため、upgrade.shスクリプトを呼び出します。このスクリプトは、WLCに適切なイメージを要求し、現在の非アクティブパーティションにそれをダウンロードするようにAPに指示します。

[*09/27/2023 21:50:42.0430] CAPWAP State: Image Data
[*09/27/2023 21:50:42.0430] AP image version 8.10.185.0 backup 8.10.105.0, Controller 17.9.3.50
[*09/27/2023 21:50:42.0430] Version does not match.
[*09/27/2023 21:50:42.0680] upgrade.sh: Script called with args:[PRECHECK]
[*09/27/2023 21:50:42.1060] do PRECHECK, part2 is active part
[*09/27/2023 21:50:42.1240] upgrade.sh: /tmp space: OK available 101476, required 40000 
[*09/27/2023 21:50:42.1250] wtpImgFileReadRequest: request ap1g7, local /tmp/part.tar
[*09/27/2023 21:50:42.1310] Image Data Request sent to 172.16.5.11, fileName [ap1g7], slaveStatus 0
[*09/27/2023 21:50:42.1340] Image Data Response from 172.16.5.11
[*09/27/2023 21:50:42.1340] AC accepted join request with result code: 0
[*09/27/2023 21:50:42.1450] <..................................................
[*09/27/2023 21:50:55.4980] ..................................................
[*09/27/2023 21:51:11.6290] ...............................Discarding msg CAPWAP_WTP_EVENT_REQUEST(type 9) in CAPWAP state: Image Data(10).
[*09/27/2023 21:51:19.7220] ...................
[*09/27/2023 21:51:24.6880] ..................................................
[*09/27/2023 21:51:37.7790] ..................................................
[*09/27/2023 21:51:50.9440] ...................................> 76738560 bytes, 57055 msgs, 930 last
[*09/27/2023 21:51:59.9160] Last block stored, IsPre 0, WriteTaskId 0
[*09/27/2023 21:51:59.9160] Image transfer completed from WLC, last 1

イメージ転送が完了すると、APはイメージ署名検証プロセスを開始して検証します。その後、upgrade.shスクリプトによって、現在の非アクティブパーティションにイメージがインストールされ、ブート元のパーティションがスワップされます。最後に、APはそれ自体をリロードし、プロセスを最初から繰り返します(CAPWAP State: Discover)。

[*09/27/2023 21:52:01.1280] Image signing verify success.
[*09/27/2023 21:52:01.1440] 
[*09/27/2023 21:52:01.1440] [9/27/2023 21:53:2] : Shadow is now in-synced with master
[*09/27/2023 21:52:01.1440] 
[*09/27/2023 21:52:01.1440] [9/27/2023 21:53:2] : Verifying against bundle image btldr.img...
[*09/27/2023 21:52:01.1570] upgrade.sh: part to upgrade is part1
[*09/27/2023 21:52:01.1780] upgrade.sh: AP version1: part1 8.10.105.0, img 17.9.3.50
[*09/27/2023 21:52:01.1960] upgrade.sh: Extracting and verifying image in part1...
[*09/27/2023 21:52:01.2080] upgrade.sh: BOARD generic case execute
[*09/27/2023 21:52:01.5280] upgrade.sh: Untar /tmp/part.tar to /bootpart/part1...
[*09/27/2023 21:52:01.7890] upgrade.sh: Sync image to disk...
[*09/27/2023 21:52:31.4970] upgrade.sh: status 'Successfully verified image in part1.'
[*09/27/2023 21:52:32.5270] upgrade.sh: AP version2: part1 17.9.3.50, img 17.9.3.50
[*09/27/2023 21:52:32.5540] upgrade.sh: AP backup version: 17.9.3.50
[*09/27/2023 21:52:32.5700] upgrade.sh: Finished upgrade task.
[*09/27/2023 21:52:32.5840] upgrade.sh: Cleanup for do_upgrade...
[*09/27/2023 21:52:32.5970] upgrade.sh: /tmp/upgrade_in_progress cleaned
[*09/27/2023 21:52:32.6090] upgrade.sh: Cleanup tmp files ...
[*09/27/2023 21:52:32.6720] upgrade.sh: Script called with args:[ACTIVATE]
[*09/27/2023 21:52:32.7100] do ACTIVATE, part2 is active part
[*09/27/2023 21:52:32.7640] upgrade.sh: Verifying image signature in part1
[*09/27/2023 21:52:33.7730] upgrade.sh: status 'Successfully verified image in part1.'
[*09/27/2023 21:52:33.7850] upgrade.sh: activate part1, set BOOT to part1
[*09/27/2023 21:52:34.2940] upgrade.sh: AP primary version after reload: 17.9.3.50
[*09/27/2023 21:52:34.3070] upgrade.sh: AP backup version after reload: 8.10.185.0
[*09/27/2023 21:52:34.3190] upgrade.sh: Create after-upgrade.log
[*09/27/2023 21:52:37.3520] AP Rebooting: Reset Reason - Image Upgrade

警告：証明書の期限切れが原因で、Wave 1アクセスポイントが新しいイメージのダウンロードに失敗する可能性があります。詳細については、『Field Notice 72524』を参照してください。また、このドキュメントの影響とソリューションについては、『2022年12月4日(CSCwd80290)サポート文書』で「Cisco IOS APイメージのダウンロードが、イメージ署名証明書の期限切れにより失敗する」を慎重にお読みください。

APがリロードされ、CAPWAP DiscoverおよびJoin状態に戻ると、Image Data状態の間に、適切なイメージが取得されたことを検出します。

[*09/27/2023 21:56:13.7640] CAPWAP State: Image Data
[*09/27/2023 21:56:13.7650] AP image version 17.9.3.50 backup 8.10.185.0, Controller 17.9.3.50
[*09/27/2023 21:56:13.7650] Version is the same, do not need update.
[*09/27/2023 21:56:13.7650] status 'upgrade.sh: Script called with args:[NO_UPGRADE]'
[*09/27/2023 21:56:13.7850] do NO_UPGRADE, part1 is active part

CAPWAP状態：設定

APは、WLCと同じバージョンであることを確認した後、現在の設定をWLCに通知します。一般に、これはAPが（WLCで使用可能な場合）設定を維持するように要求することを意味します。

[*09/27/2023 21:56:14.8680] CAPWAP State: Configure
[*09/27/2023 21:56:15.8890] Telnet is not supported by AP, should not encode this payload
[*09/27/2023 21:56:15.8890] Radio [1] Administrative state DISABLED change to ENABLED 
[*09/27/2023 21:56:16.0650] Radio [0] Administrative state DISABLED change to ENABLED 
[*09/27/2023 21:56:16.0750] DOT11_CFG[1]: Starting radio 1
[*09/27/2023 21:56:16.1150] DOT11_DRV[1]: Start Radio1
[*09/27/2023 21:56:16.1160] DOT11_DRV[1]: set_channel Channel set to 36/20
[*09/27/2023 21:56:16.4380] Started Radio 1
[*09/27/2023 21:56:16.4880] DOT11_CFG[0]: Starting radio 0
[*09/27/2023 21:56:17.5220] DOT11_DRV[0]: Start Radio0
[*09/27/2023 21:56:16.5650] DOT11_DRV[0]: set_channel Channel set to 1/20
[*09/27/2023 21:56:16.5650] Started Radio 0
[*09/27/2023 21:56:16.5890] sensord psage_base init: RHB Sage base ptr a1030000

CAPWAP状態：Run

この時点で、APはコントローラに正常に加入しています。この状態の間、WLCはAPによって要求された設定を上書きするメカニズムをトリガーします。WLCは以前にこのAPを認識しなかったため、APが無線とクレデンシャルの設定をプッシュされて、デフォルトポリシータグに割り当てられることも確認できます。

[*09/27/2023 21:56:17.4870] CAPWAP State: Run
[*09/27/2023 21:56:17.4870] AP has joined controller uwu-9800
[*09/27/2023 21:56:17.4940] DOT11_DRV[0]: set_channel Channel set to 1/20
[*09/27/2023 21:56:17.5440] sensord split_glue psage_base: RHB Sage base ptr a1030000
[*09/27/2023 21:56:17.6010] sensord split_glue sage_addr: RHB Sage base ptr a1030000
[*09/27/2023 21:56:17.6230] ptr a1030000
[*09/27/2023 21:56:17.6420] DOT11_DRV[0]: set_channel Channel set to 1/20
[*09/27/2023 21:56:17.8120] DOT11_DRV[1]: set_channel Channel set to 36/20
[*09/27/2023 21:56:17.9350] Previous AP mode is 0, change to 0
[*09/27/2023 21:56:18.0160] Current session mode: ssh, Configured: Telnet-No, SSH-Yes, Console-Yes
[*09/27/2023 21:56:18.1220] Current session mode: telnet, Configured: Telnet-No, SSH-Yes, Console-Yes
[*09/27/2023 21:56:18.1310] Current session mode: console, Configured: Telnet-No, SSH-Yes, Console-Yes
[*09/27/2023 21:56:18.1340] chpasswd: password for user changed
[*09/27/2023 21:56:18.1350] chpasswd: password for user changed
[*09/27/2023 21:56:18.1520] systemd[1]: Starting Cisco rsyslog client watcher...
[*09/27/2023 21:56:18.1610] Same LSC mode, no action needed
[*09/27/2023 21:56:18.1640] CLSM[00:00:00:00:00:00]: U3 Client RSSI Stats feature is deprecated; can no longer be enabled
[*09/27/2023 21:56:18.1720] systemd[1]: Stopping rsyslog client...
[*09/27/2023 21:56:18.2120] systemd[1]: Starting Cisco syslog service...
[*09/27/2023 21:56:18.2230] systemd[1]: Started Cisco syslog service.
[*09/27/2023 21:56:18.2410] systemd[1]: Started rsyslog client.
[*09/27/2023 21:56:18.2440] AP is in good condition, BLE is off
[*09/27/2023 21:56:18.2510] SET_SYS_COND_INTF: allow_usb state: 1 (up) condition 
[*09/27/2023 21:56:18.2530] systemd[1]: Starting dhcpv6 client watcher...
[*09/27/2023 21:56:18.2530] systemd[1]: Stopping DHCPv6 client...
[*09/27/2023 21:56:18.2530] systemd[1]: Starting DHCPv6 client...
[*09/27/2023 21:56:18.2530] systemd[1]: Started DHCPv6 client.
[*09/27/2023 21:56:18.2530] systemd[1]: Started dhcpv6 client watcher.
[*09/27/2023 21:56:18.2560] Set radio 0 power 4 antenna mask 15
[*09/27/2023 21:56:18.2530] Set radio 1 power 4 antenna mask 15
[*09/27/2023 21:56:18.2530] Got WSA Server config TLVs
[*09/27/2023 21:56:18.2720] AP tag change to default-policy-tag
[*09/27/2023 21:56:18.2780] Chip flash OK

設定

スタティックWLCの選択

GUIでは、Configuration > Wireless > Access Pointsの順に選択し、APを選択して、High Availabilityタブに移動できます。ここでは、このドキュメントの「ワイヤレスLANコントローラの選択」セクションで説明されているように、プライマリ、セカンダリ、およびターシャリ WLCを設定できます。この設定は、アクセスポイントごとに行います。

APのプライマリ、セカンダリ、ターシャリWLC。

注:Cisco IOS XE 17.9.2以降では、プライミングプロファイルを使用して、正規表現(regex)に一致するAPのグループまたは個々のAPに対して、プライマリ、セカンダリ、ターシャリコントローラを設定できます。詳細については、『設定ガイド』の「APプライミングプロファイルで設定されたコントローラへのAPフォールバック」セクションを参照してください。

AP High Availabilityタブで設定されるプライマリ、セカンダリ、ターシャリコントローラは、CAPWAP > High AvailabilityタブでAP Join Profileごとに設定できるバックアッププライマリおよびセカンダリ WLCとは異なることに注意してください。プライマリ、セカンダリ、ターシャリコントローラは、それぞれプライオリティ1、2、および3のWLCと見なされ、バックアッププライマリおよびセカンダリは、プライオリティ4および5のWLCと見なされます。

AP Fallbackが有効な場合、APは別のWLCに加入するときにプライマリコントローラをアクティブに検索します。CAPWAPダウンイベントが発生し、バックアッププライマリおよびセカンダリコントローラが使用できない場合、APはプライオリティ4および5のWLCのみを検索します。

AP加入プロファイルのハイアベイラビリティオプション

注：AP Join ProfileでBackup PrimaryおよびBackup Secondary WLCを設定しても、アクセスポイントのHigh AvailabilityタブのStatic PrimaryおよびSecondaryエントリは入力されません。

APへのTelnet/SSHアクセスの有効化

Configuration > Tags & Profiles > AP Join > Management > Deviceの順に選択し、SSHかTelnet、またはその両方を選択します。

AP加入プロファイルでのTelnet/SSHアクセスの有効化

SSH/Telnetクレデンシャルを設定するには、同じウィンドウでUserタブに移動し、Username、Password、およびSecretを設定して、APにアクセスします。

APのSSHおよびTelnetクレデンシャル

データリンク暗号化

APトラフィックのパケットキャプチャの取得を必要とするクライアントの問題をトラブルシューティングする必要がある場合は、Configuration > Tags & Profiles > AP Join > CAPWAP > AdvancedでData Link Encryptionが有効になっていないことを確認します。そうしないと、トラフィックは暗号化されます。

データリンク暗号化

注：データ暗号化では、CAPWAPデータトラフィックのみが暗号化されます。CAPWAP制御トラフィックはすでにDTLSで暗号化されています。

確認

APコンソールでCAPWAPステートマシンを追跡するだけでなく、WLCで組み込みパケットキャプチャを実行して、AP加入プロセスを分析することもできます。

WLCの組み込みパケットキャプチャに見られるAP加入プロセス

チャンス暗号仕様パケット（パケット番号1182）の後のすべてのトラフィックがDTLSv1.2を介したアプリケーションデータとしてのみ表示される点に注意してください。これは、DTLSセッションが確立された後のすべての暗号化データです。

トラブルシュート

既知の問題

APがWLCに加入するのを妨げる可能性がある既知の問題を参照してください。

• Wave 2およびCatalyst 11axアクセスポイント(CSCvx32806)の破損したイメージが原因でブートループが発生したAP
• フィールド通知72424: 2022年9月以降に製造されたC9105/C9120/C9130アクセスポイントは、ワイヤレスLANコントローラに加入するためにソフトウェアアップグレードが必要な場合があります。
• フィールド通知72524：ソフトウェアのアップグレード/ダウングレードの間、証明書の期限切れのために2022年12月4日の後でCisco IOS APがダウンロード状態のままになる可能性 – ソフトウェアのアップグレードを推奨
• Cisco Bug ID CSCwb13784:AP加入要求に無効なパスMTUがあるため、APが9800に加入できない
• Cisco Bug ID CSCvu22886:17.7へのアップグレード時のC9130：メッセージ「unlzma: write: No space left on device」、/tmpの最大サイズの増加

アップグレードの前に、必ず各バージョンの『リリースノート』の「アップグレードパス」セクションを参照してください。

注:Cisco IOS XE Cuppertino 17.7.1以降のCisco Catalyst 9800-CLワイヤレスコントローラは、スマートライセンスが接続されておらず、起動していない場合、50を超えるAPを受け入れません。

WLC GUIのチェック

WLCで、Monitoring > Wireless > AP Statistics > Join Statistics の順に選択すると、任意のAPによって報告されたLast Reboot Reasonと、WLCによって登録されたLast Disconnect Reasonを確認できます。

WLCのAP Join Statisticsページ

任意のAPをクリックして、AP加入統計情報の詳細を確認できます。ここでは、APが最後に加入してWLCの検出を試行した日時などの詳細情報を確認できます。

一般的なAP加入統計情報

詳細については、同じウィンドウの[統計情報]タブを参照してください。ここで、加入応答送信数と受信済み加入要求数、および設定応答送信数と受信済み設定要求数を比較できます。

詳細なAP加入統計情報

コマンド

次のコマンドは、APの加入に関する問題のトラブルシューティングに役立ちます。

WLCから

• show ap summary（WLCで実行）
• debug capwapエラー
• debug capwap packet（登録ユーザ専用）

Wave 2およびCatalyst 11ax APから

• debug capwap client events
• debug capwap client error
• debug dtls clientエラー
• debug dtls clientイベント
• CAPWAPクライアントキープアライブのデバッグ
• CAPWAP再起動のテスト
• capwap ap ap erase all（すべて消去）

Wave 1 APから

• CAPWAPコンソールCLIのデバッグ
• debug capwap client no-reload
• show dtls stats（すべてのDTLS統計情報の表示）
• clear cawap ap all-config

注:TelnetまたはSSHを使用してAPに接続してトラブルシューティングを行う場合、必ずコマンドterminal monitorを発行し、APでデバッグを有効にした後で問題を再現してください。それ以外の場合、デバッグからの出力は表示されません。

放射性物質トレース

APの加入に関する問題をトラブルシューティングする場合は、まず、加入に関する問題が発生しているAPの無線MACアドレスとイーサネットMACアドレスの両方の放射性トレースを取得します。これらのログを生成する方法の詳細は、『Catalyst 9800 WLCでのデバッグとログの収集』ドキュメントを参照してください。