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

概要

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

使用するコンポーネント

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

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

Cisco DNA Centerインベントリサービスは、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ポートの欠落、内部エラーなどのエラーで管理されています。エラーメッセージにカーソルを合わせると、エラーと影響を受けるアプリケーションの詳細が表示されます。
• 管理対象外:デバイスに到達できず、デバイスの接続の問題が原因でインベントリ情報が収集されませんでした。

前回の同期ステータス

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

• 部分的な収集の失敗:デバイスは部分的に収集された状態にあり、すべてのインベントリ情報が収集されたわけではありません。情報(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クレデンシャルのエラーにより、インベントリに「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経由の強制同期オプションを使用して、デバイスが再び同期していることが確認できます。

トラップの確認

デバイスで強制的に同期タスクを実行した後も問題が解決しない場合は、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応答が得られるのを待ってから、ネットワークデバイスがインベントリページに表示されなくなったことを確認します。