DNA Centerインベントリサービスと一般的な問題の調査

はじめに

このドキュメントでは、Cisco DNA Center Inventory Serviceの基本概念と、実稼働環境で見られる一般的な問題について説明します。

使用するコンポーネント

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

インベントリサービスの詳細

Cisco DNA Center Inventory Serviceは、Kubernetes(K8s)Podに基づいています。このポッドは、展開環境タイプとして「apic-em-inventory-manager-service-<id>」という名前の名前空間「fusion」で実行されていることがわかります。

K8sポッドの内部には、「apic-em-inventory-manager-service」というDockerコンテナがあります。

「apic-em-inventory-manager-service」ポッドの主なタスクは、デバイス検出およびデバイスライフサイクル管理です。

これにより、デバイスデータがPostgres SQL （Fusion Servicesで使用されるデータベース）で使用できるようになります。

「fusion」ネームスペース(Appstack)は、ネットワークコントローラプラットフォーム(NCP)とも呼ばれ、すべてのネットワーク自動化要件に対応するサービスプロビジョニングフレームワーク(SPF)サービスを提供します。

これには、検出、インベントリ、トポロジ、ポリシー、ソフトウェアイメージ管理(SWIM)、設定アーカイブ、ネットワークプログラマ、サイト、グループ化、テレメトリ、テスト統合、テンプレートプログラマ、マップ、IPAM、センサー、オーケストレーション/ワークフロー/スケジューリング、ISE統合などが含まれます。

インベントリポッドのステータスは、次のコマンドを実行して確認できます。 

$ magctl appstack status | grep inventory

インベントリサービスのステータスは、次のコマンドで確認できます。

$ magctl service status

インベントリサービスログは、次のコマンドを使用して確認できます。

$ magctl service logs -r

このドキュメントでは、「Inventory device Manageability」と「Last Syncing」のステータスに焦点を当てて、一般的な問題を確認できます。

管理容易性の状態

• 緑のティックアイコンで管理:デバイスは到達可能で、完全に管理されています。
• オレンジ色のエラーアイコンで管理:デバイスは、到達不能、認証障害、Netconfポートの欠落、内部エラーなどのエラーで管理されています。エラーメッセージにカーソルを合わせると、エラーと影響を受けるアプリケーションの詳細が表示されます。
• Unmanaged:デバイスに到達できず、デバイスの接続の問題によりインベントリ情報が収集されませんでした。

前回の同期ステータス

• Managed:デバイスは完全に管理対象の状態です。

• 部分的な収集の失敗:デバイスが部分的に収集された状態にあり、一部のインベントリ情報が収集されていない。情報(i)アイコンの上にカーソルを移動すると、障害に関する追加情報が表示されます。

• 到達不能:デバイスに到達できず、デバイスの接続の問題によってインベントリ情報が収集されませんでした。この状態は、定期的な収集が行われる場合に発生します。

• 誤ったクレデンシャル:デバイスをインベントリに追加した後にデバイスのクレデンシャルを変更すると、この状態が記録されます。

• 進行中:在庫の収集が行われています。

課題

Internal Error

Cisco DNA Centerインベントリページでは、データ収集を妨げる何らかの矛盾があるデバイスのマネージャビリティーのステータスに警告メッセージを表示できます。 

“内部エラー： NCIM12024：デバイスからのすべての情報を正常に収集できなかったか、またはこのデバイスのインベントリ収集がまだ開始されていません。これは、自動的に解決できる一時的な問題である可能性があります。デバイスを再同期しても問題が解決しない場合は、Cisco TACにお問い合わせください」

エラーが自動的に解決されない場合、またはデバイスの再同期後に解決されない場合は、最初のトラブルシューティングから始めることができます。このエラーは複数の原因で発生する可能性がありますが、ここでは最も一般的な原因の一部のみを示します。 

• SNMP、SSH、およびNetconfのデバイスクレデンシャルが正しくない。
• SNMP、SSH、Netconfに関連するネットワーク接続の問題
• デバイスのNetconf設定の問題が原因で、Netconfが正しく動作しません。
• デバイスの同期中にデバイスの再同期をトリガーします。 
• デバイスから複数のトラップが受信され、短時間のうちに複数の再同期トリガーが発生しました。
• デバイスに関連する複数のテーブルのインベントリデータベースエントリに関するバックエンドの問題。

Device Credentials

デバイスのクレデンシャルを確認するには、Cisco DNA Centerのメニュー> Provision -> Inventory -> Select Device -> Actions -> Inventory -> Edit Deviceの順に選択し、Validateをクリックして、必須クレデンシャル（CLIとSNMP）が緑色のチェック（適用される場合はnetconfを含む）で検証に合格したことを確認します。

検証が失敗した場合は、Cisco DNA Centerがネットワークデバイスの管理に使用しているユーザ名とパスワードが、デバイスのコマンドラインで直接有効であることを確認してください。

ローカルで設定されている場合、またはAAAサーバ（TACACSまたはRADIUS）で設定されている場合は、ユーザ名とパスワードがAAAサーバで正しく設定されていることを確認してください。

また、Cisco DNA CのDevice Credentials Settingsで「Enable」パスワード設定を必要とするユーザ名権限があるかどうかも確認しますinventoryと入力します。

CLIクレデンシャルのエラーにより、Inventory: CLI Authentication Failureでマネージャビリティー（管理容易性）のエラーメッセージが表示される場合があります。

Netconf

Netconfは、リモートプロシージャコール(RPC)を介して互換性のあるネットワークデバイスをリモートで管理するためのプロトコルです。

Cisco DNA CenterはNetconf機能を使用してネットワークデバイスの設定をプッシュまたは削除し、Assuranceによるモニタリングなどの機能を有効にします。

Cisco DNA Centerインベントリでは、Netconf要件が正しいことの検証もできます。これには、次のものが含まれます。

• Netconfのデフォルトポート830は、ネットワーク内で開かれ、機能します。
• ネットワークデバイス（ローカルまたはAAAで設定）へのSSHアクセスを持つ、特権15のユーザ。
• ネットワークデバイスでNetconfを有効にします。

(config)#netconf-yang

• aaa new-modelがイネーブルになっている場合は、AAAのデフォルト設定要件：

(config)#aaa authorization exec default 
     
(config)#aaa authentication login default 
     

Netconfクレデンシャルのエラーにより、インベントリに「Netconf Connection Failure」というマネージャビリティーのエラーメッセージが表示される場合があります。

ネットワークチェック

バージョンに応じて、ネットワーク接続とプロトコル設定(SNMP設定など)を検証することもできます。

たとえば、コミュニティ、ユーザ、グループ、エンジンID、認証および暗号化の設定などを、SNMPのバージョンに応じてダブルチェックできます。 

また、デバイスのコマンドラインでpingコマンドとtracerouteコマンドを使用し、ファイアウォール、プロキシ、またはアクセスリストでSSH(22)とSNMP（161と162）のポートを使用して、SSHとSNMPの接続を確認することもできます。

Cisco DNA Centerのmaglev CLIから、ip routeコマンドを使用して、ネットワークデバイスへの接続を確認します。

SNMP walkはトラブルシューティングにも使用できます。

SNMPクレデンシャルのエラーにより、インベントリに「SNMP Authentication Failure」または「Device Unreachable」というマネージャビリティーのエラーメッセージが表示される場合があります。

データベーステーブル

エンドユーザは、Cisco DNA Center GUIとGrafanaを使用してSQLクエリを実行できるため、maglev CLI経由でPostgresシェルにアクセスする必要はありません。

インベントリ内のネットワークデバイスに問題がある場合に確認するpostgresデータベーステーブルには、次のものがあります。

• ネットワークデバイス
• managedelementinterface
• ネットワーク要素
• ネットワークリソース
• デバイスif
• IPアドレス

同期ループとトラップ

Cisco DNA Centerは、デバイス自体に大きな変更が加えられた後、デバイスからトラップを受信するたびにデバイスResyncを実行して、Cisco DNA Centerインベントリの更新を維持するように設計されています。 Cisco DNA Center InventoryページのManageabilityセクションで、ネットワークデバイスが長時間またはいつまでも「Syncing」状態のままになる場合があります。

デバイスの同期を強制するAPI

ネットワークデバイスが長すぎる、または数日にわたって同期ステータスのままになっている場合は、最初に基本的なチェックを行って到達可能性と接続を確認します。次に、APIコールを介してデバイスを強制的に再同期します。

1.- Cisco DNA Center maglev CLIセッションを開きます。

2.- APIを介してCisco DNA Center認証トークンを取得します。

curl -s -X POST -u admin  https://kong-frontend.maglev-system.svc.cluster.local/api/system/v1/identitymgmt/token

3. – 前の手順のトークンを使用してAPIを実行し、デバイスを強制的に同期させます。

curl -X PUT -H "X-AUTH-TOKEN: 
     
       " -H "content-type: application/json" -d ' 
      
        ' https:// 
       
         /api/v1/network-device/sync-with-cleanup?forceSync=true --insecure 
        
       
     

4.- API経由でForce Syncオプションを使用すると、デバイスの同期が再び行われます。

トラップの確認

デバイスで強制的に同期タスクを実行した後も問題が解決しない場合は、Cisco DNA Centerの「event-service」で受信されるトラップの数が多すぎるかどうかを確認し、イベントサービスログを読み取って、どのタイプのトラップであるかを確認できます。

1. – ログを読み取る前に、次のコマンドを使用してトラップの総数を確認します。

$ echo;echo;eventsId=$(docker ps | awk '/k8s_apic-em-event/ {print $1}'); docker cp $eventsId:/opt/CSCOlumos/logs/ /tmp/;for ip in $(awk -F\: '/ipAddress / {print $4}' /tmp/logs/ncs* | sort | uniq);do for trap in $(grep -A10 $ip /tmp/logs/ncs* | awk -F\= '/trapType/ {print $2}');do tStamp=$(grep -A10 $ip /tmp/logs/ncs* | awk '/trapType/ {print $2,$3}'); echo "$ip - $trap "| grep -E "^([0-9]{1,3}[\.]){3}[0-9]{1,3}" | awk -F\. '{print $1,$2,$3,$4}';done;done | sort | uniq -c | grep -v address| sort -bgr > /home/maglev/trapCounter.log &

2. – 次に、イベントサービスコンテナにアタッチします。

$ magctl service attach -D event-service

3. – イベントサービスコンテナ内に入ったら、ディレクトリをlogsフォルダに変更します。

 $ cd /opt/CSCOlumos/logs/

4. – ディレクトリ内のファイルを確認すると、名前が「ncs」で始まるログファイルがいくつか見えます。

例：

root@apic-em-event-service-586df7d4b8-f9c74:/opt/CSCOlumos/logs# ls -l
total 90852
drwxr-xr-x 1 maglev maglev     4096 May  9 21:33 ./
drwxr-xr-x 1 maglev maglev     4096 Apr 29 17:56 ../
-rw-r--r-- 1 root root 2937478 May 9 21:37 ncs-0-0.log -rw-r--r-- 1 root root 0 Apr 29 23:59 ncs-0-0.log.lck -rw-r--r-- 1 root root 10002771 May 9 21:33 ncs-1-0.log -rw-r--r-- 1 root root 10001432 May 9 21:16 ncs-2-0.log -rw-r--r-- 1 root root 10005631 May 9 21:01 ncs-3-0.log -rw-r--r-- 1 root root 10000445 May 9 20:47 ncs-4-0.log -rw-r--r-- 1 root root 10000507 May 9 20:33 ncs-5-0.log -rw-r--r-- 1 root root 10003091 May 9 20:21 ncs-6-0.log -rw-r--r-- 1 root root 10001058 May 9 20:06 ncs-7-0.log -rw-r--r-- 1 root root 10001064 May 9 19:53 ncs-8-0.log -rw-r--r-- 1 root root 10000572 May 9 19:39 ncs-9-0.log
-rw-r--r-- 1 root   root        424 Apr 30 00:01 nms_launchout.log
-rw-r--r-- 1 root   root        104 Apr 30 00:01 serverStatus.log

5. – これらの「ncs」ファイルは、受信しているトラップのタイプと数を分析するために必要なものです。ログファイルを確認して、デバイスのホスト名またはキーワード「trapType」でフィルタリングします。

root@apic-em-event-service-586df7d4b8-f9c74:/opt/CSCOlumos/logs# grep trapType ncs*.log
root@apic-em-event-service-586df7d4b8-f9c74:/opt/CSCOlumos/logs# grep 
     
       ncs*.log 
     

トラップのタイプが多すぎると、デバイスの再同期を引き起こす可能性があり、頻繁に送信される場合には同期ループが発生する可能性があります。

トラップを分析することで、根本原因を特定し、再起動サイクルのAPなど、トラップを停止させることができます。

トラップの出力をファイルに保存し、必要に応じてエスカレーションチームと共有できます。 

サービスのクラッシュ状態

ネットワークデバイスの管理中にCisco DNA Center Inventoryページで異常な動作が原因でインベントリポッドがクラッシュしたと思われる場合は、最初にポッドステータスを検証できます。

$ magctl appstack status | grep inventory

$ magctl service status 
     
         
     

ポッドステータスの出力を確認して、再起動またはエラーステータスの数が多い場合は、インベントリコンテナを添付してヒープダンプファイルを収集できます。このファイルには、エスカレーションチームがクラッシュ状態の根本原因を分析および定義するために役立つデータを含めることができます。

$ magctl service attach -D 
     

root@apic-em-inventory-manager-service-76f7f8d7f5-427m5:/# ll /opt/maglev/srv/diagnostics/ | grep heapdump
-rw-r--r-- 1 root root 1804109 Jul 20 21:16 apic-em-inventory-manager-service-76f7f8d7f5-427m5.heapdump

デバイスを削除できない

バックエンドの問題が原因で、Cisco DNA Centerがインベントリユーザインターフェイスからネットワークデバイスを削除できない場合があります。

デバイスを強制的に削除するAPI

Cisco DNA Center GUIを使用してインベントリからデバイスを削除できない場合は、APIを使用してデバイスをIDで削除できます。

1.- Cisco DNA Centerメニュー – > Platform -> Developer Toolkit -> APIsタブに移動し、検索バーでDevicesを検索します。結果から、Know your networkセクションのDevicesをクリックして、DELETE by Device Id APIを検索します。

2.- DELETE by Device Id APIをクリックし、Tryをクリックして、インベントリから削除するデバイスのデバイスIDを指定します。

3.- APIの実行を待機し、200 OK応答を取得します。その後、ネットワークデバイスがインベントリページに表示されなくなったことを確認します。