Catalyst CenterのWLC 9800からの保証なしデータのトラブルシューティング

はじめに

このドキュメントでは、Catalyst CenterでCatalyst 9800シリーズWLCの保証データが表示されない場合のトラブルシューティング方法について説明します。

前提条件

要件

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

• Catalyst Center maglev CLIの使用
• 基本的なLinux基盤
• Catalyst CenterおよびCatalyst 9800プラットフォームの証明書に関する知識

使用するコンポーネント

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

• Catalyst Centerアプライアンス第2および第3世代、バージョン2.3.7.7以降
• Catalyst 9800シリーズワイヤレスLANコントローラ(WLC)

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

注：このドキュメントは2.3.7.9に基づいて作成されましたが、この関数は、3.1.Xリリースにも存在します。

注:Catalyst 9800 WLCは、Catalyst Centerによってすでに検出され、サイトに割り当てられている必要があります。また、互換性のあるCisco IOS® XEバージョンを実行している必要があります。相互運用性の詳細については、『Catalyst Center互換性マトリクス』を参照してください。

背景説明

サイト割り当ての時点で、Catalyst CenterはSNMPおよびSyslog設定に加えて、テレメトリ設定を9800にプッシュします。

注：この例は、Catalyst 9800-CLクラウドワイヤレスLANコントローラのものです。一部の詳細は、物理Catalyst 9800シリーズアプライアンスを使用する場合によって異なります。X.X.X.XはCatalyst Centerエンタープライズインターフェイスの仮想IP(VIP)アドレスで、Y.Y.Y.YはWLCの管理IPアドレスです。

crypto pki trustpoint sdn-network-infra-iwan
 enrollment pkcs12
 revocation-check crl
 rsakeypair sdn-network-infra-iwan

crypto pki trustpoint DNAC-CA
 enrollment mode ra
 enrollment terminal
 usage ssl-client
 revocation-check crl none
 source interface GigabitEthernet1

crypto pki certificate chain sdn-network-infra-iwan
 certificate 14CFB79EFB61506E
  3082037D 30820265 A0030201 02020814 CFB79EFB 61506E30 0D06092A 864886F7 
  <snip>
        quit

 certificate ca 7C773F9320DC6166
  30820323 3082020B A0030201 0202087C 773F9320 DC616630 0D06092A 864886F7 
  <snip>
        quit

crypto pki certificate chain DNAC-CA
 certificate ca 113070AFD2D12EA443A8858FF1272F2A
  30820396 3082027E A0030201 02021011 3070AFD2 D12EA443 A8858FF1 272F2A30 
  <snip>
        quit

telemetry ietf subscription 1011
 encoding encode-tdl
 filter tdl-uri /services;serviceName=ewlc/wlan_config
 source-address Y.Y.Y.Y
 stream native
 update-policy on-change
 receiver ip address X.X.X.X 25103 protocol tls-native profile sdn-network-infra-iwan

telemetry ietf subscription 1012
<snip - many different "telemetry ietf subscription" sections - which ones depends on 
Cisco IOS® version and Catalyst Center version>

network-assurance enable
network-assurance icap server port 32626
network-assurance url https://X.X.X.X
network-assurance na-certificate PROTOCOL_HTTP X.X.X.X /ca/ pem

Catalyst CenterのWLCからの保証なしデータのトラブルシューティング

WLC360での保証「トラブルシューティング」のマシン推論エンジン(MRE)ツールの使用

WLC360ページに移動します。ヘルスの横に、青色のテキスト「Troubleshoot」が表示されます。

これをクリックして、マシン推論エンジンを実行します。

推論エンジンを実行して完了できるようにします。

「結論」タブをチェックして、考えられる問題が何であるかを確認します。「結論」に問題のない完全なデータが示された場合は、このドキュメントの「インバウンドデータの検証」のセクションに進んでください。

この「Troubleshoot」リンクが表示されない場合は、GUIのTools > Network Reasonerページで手動で実行できます。「保証テレメトリ分析」ワークフローを検索します。

結論：デバイスの接続

評価のデータと検証

まず、Inventoryページに移動し、WLCのワイヤレス管理IPアドレスを使用して問題のWLCが管理されていることを確認します。

9800アプライアンスの場合：show wireless interface summary

9800-CLの場合：show ip interfaces brief | i GigabitEthernet2
注：これは、ユーザがhttps://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/technical-reference/c9800-cl-dg.html#Introductionの導入ガイドに従っていることを前提としています。

Catalyst CenterのInventoryページに移動します。

これにより、Catalyst Centerとこのデバイスの間に接続の問題があることが確認されます。

トラブルシューティングとチェックの項目

IP 接続

メインメニューから、System > Settingsページに移動します。次に、左側のバナーで「Trust & Privacy」セクションに移動し、「IP Access Control」を選択します。  別の方法として、グローバル検索を使用して「IP Access Control」を検索する方法があります

ここでの設定が、問題のデバイスへの接続を許可していることを確認してください。  次に、ICMP経由でエンドデバイスに到達できることを確認します。これを行うには、Catalyst CenterのCLIにログインし、次の出力に示すように、コマンド「ping [IP_Address]」を発行します。

次に調べる項目は、Catalyst Center CLIからの「traceroute」コマンドの出力です。

次に、「ip -s link show | grep enterprise -A 4」コマンドを使用して、Catalyst Centerにリンクの問題がないことを確認します

インターフェイスのメトリックが許容可能と思われる場合は、次のステップとして、接続の両側からパケットキャプチャ(PCAP)を実行します。このガイドでは、問題のあるデバイスで最初のPCAPセットを実行することを推奨します。この例では、この2台のデバイスは9800とVIPを搭載したCatalyst Centerです。それが不可能な場合は、できるだけデバイスの近くでPCAPを実行してください。

パケットがネットワークに送信され、有線インフラストラクチャを通過しない場合は、有線ネットワークで非同期ルーティング、ファイアウォール、NAT、パケットをブロックするACLなどを調査してください。  これらを解決したら、アシュアランスの「トラブルシューティング」MREを再実行してください。

結論：デバイスは「Catalyst Centerでは現在管理されていない」

2.3.7.10以降では、ワークフローの出力に「contact the TAC」と記載されている場合があります。TACに連絡する前、またはTACケースが正しい緊急処置であるかどうかを判断する前に実行できる処置があります。  最初にInventoryページに移動し、問題のデバイス(メインメニュー>プロビジョニング>インベントリ)を見つけます。  次に、誤って設定されたSSHパスワードの例を示します

次に確認すべき項目は、「到達可能性」ステータスが「到達不能」と表示されないことです。 「Unreachable」または「Unknown」と表示されている場合は、TACに問い合わせる前に、このガイドの「Device Connectivity or Credential Failure」の項を参照してください。「Ping Reachable」または「Reachable」と表示されている場合は、Catalyst Centerで使用されるクレデンシャルのトラブルシューティングに進むことができます。  これを行うには、次に示すように、調査するデバイスの左側にあるボックスをクリックします。ボックスが青のチェックマークで青に変わります。

次に示すように、「Actions」、「Inventory」の順にクリックし、最後に「Edit Device」をクリックします。

この操作により、この設定を「検証」するための新しいウィンドウが表示されます。例については、このスクリーンショットを参照してください。  

注：このページでは、「ユーザ名」はクリアテキストで表示されますが、「パスワード」はクリアテキストで表示されません。その代わり、Catalyst Centerはパスワードを「NO!$DATA!$」と表示します。

正しいクレデンシャルの例を次に示します。  SNMPと無効なクレデンシャルを参照してください。CLIとNetconfを参照してください。

注：ワイヤレスアクセスポイント(AP)はこの方法では管理されません。すべてのAPデータはWLCを経由します。

CLI(SSH)アクセスは、すべてのデバイスで必須です。

最低限の読み取り専用アクセス権を持つSNMPは、すべてのデバイスで必須です。

9800(Cisco IOS® XEベース)のWLCにはNetconfが必須です。Netconfは、Cisco IOS® XEベーススイッチのPoEダッシュボードなどの追加のモニタリングを提供するため、オプションです。Netconfは、AireOSまたはCisco IOS®ベースのデバイスでは使用されません。 

すべての問題を修正し、「Validate」オプションを再度実行すると、次のように表示されます。

エラーに対処したら、左下の「Update」ボタンをクリックします。これが完了すると、Catalyst Centerはこのデバイスを「同期」のためにキューに入れます。 キューが空の場合は、「Sync」がすぐに開始されます。

この作業が完了したら、MREの出力の「トラブルシューティング」に戻り、他の項目に対処する必要があるかどうかを確認してください。他に何も表示されない場合は、15 ～ 20分待って更新された情報を確認してください。それ以降に情報が更新されない場合は、TACに問い合せて、さらにサポートを受けてください。

結論：「DNAC-CA(swim)証明書」の問題

次に、いくつかの可能性を示します。

• 証明書は別のCatalyst Center用です
• デバイスの「現在の日付/時刻」が有効範囲外です 
• 証明書は置き換えられ、デバイスは古い証明書を使用しています。

MREが示している内容を確認してください。ここから、9800に移動し、いくつかのコマンドを実行して、問題の原因となっている問題を確認できます。  まず、デバイスが使用している日付と時刻を確認するために、show clockコマンドを実行します。

次に、show crypto pki certificates DNAC-CAを実行して、DNAC-CA証明書の詳細を取得します。

まず、「開始日」と「終了日」を、デバイスが認識している現在の日時と比較します。  「Conduction」に証明書が一致しないと示されている場合は、ブラウザで証明書情報を取得します。シリアル番号が一致している必要があります。これは、一致する証明書シリアル番号のChromeからの例です。

結論：「Serial Number of the sdn-network-infra-iwan certificate」の問題

まず、デバイスの日付が正しいことを確認します

次に、show crypto pki certificates sdn-network-infra-iwanを使用してsdn-network-infra-iwan証明書の詳細を取得します。

その際には、デバイスが認識している日付の範囲内に有効期間があることを確認してください。

次にCatalyst Centerに移動し、証明書のシリアル番号が一致することを確認します。

Main Menu > System > Settingsページに移動します。そのページで「デバイス証明書」ページを見つけます。そのページで、該当するデバイスに絞り込み、「証明書シリアル番号」が一致することを確認します。

これが一致しない場合は、デバイスがここに存在することが予期されており、別のCatalyst Centerクラスタによって管理されていないことを確認してください。障害が最近発生したか、証明書の有効期限がまだ切れていない場合は、必要に応じてTACに連絡し、根本原因の分析を依頼してください。それ以外の場合は、「Inventory」ページに移動し、デバイスが「Reachable」および「Managed」で、緑のチェックマークが付いていることを確認します。このページで問題が発生した場合は、このガイドのセクション「結論：デバイスがCatalyst Centerで現在管理されていない」に進み、手順を完了してください。

すべてが緑色で完全に管理されている場合は、強制的なテレメトリの更新を実行してください。詳細については、「強制的なテレメトリの更新」の項を参照してください。

インバウンドデータの検証

System > System 360 > Monitorの順に選択し、Grafanaに移動します。Grafanaの新しい画面が表示されます

次に、左側の列の虫眼鏡をクリックして「Device Processor」と入力し、Assurance - Device Processorダッシュボードに進みます。

「Received WLC schema per 5min」の表で、「Memory」の数を確認します。この数は、トラフィックを送信しているCatalyst 9800(Cisco IOS® XE)WLCの数と一致します。

「強制」テレメトリ更新の実行

Inventoryに移動し、次に示すようにUpdate Telemetry Settingsを選択します。