ディスカバリーが SNMP デバイスのシリアル番号を返さない理由Issue ディスカバリー 識別は主にシリアル番号に基づいて行われます プローブによってデバイスから抽出されます。それが失敗した場合は、名前とIPアドレスにフォールバックしますが、名前は一意ではなく、IPアドレスが移動していることがよくあります。つまり デバイスがシリアル番号を返さない場合、誤認の可能性が実際にあります、間違った CI が更新されたり、重複した CI が作成されたりする可能性があります。 シリアル番号なしで作成された CI が表示される場合もあります。 この記事では、いくつかの一般的な原因と解決策を一覧表示することを目的としています。 Cause認証情報がありません インスタンスに入力された SNMP 認証情報がデバイスへのアクセスを許可しない場合、ディスカバリー SNMP プローブはフォールバックしてパブリックコミュニティ文字列を使用できます。 ただし、一部のデバイスでは、Public コミュニティ文字列を使用して読み取ることができる内容が制限される場合があります。 ソリューション: SNMP デバイスが、識別データへのパブリックコミュニティ文字列アクセスを許可するように構成されていることを確認するか、新しい認証情報を使用してデバイスをセットアップし、その認証情報をインスタンスに追加します。 データ受信前のプローブタイムアウト 一部のSNMP対応ネットワークデバイスは、非常に単純な組み込みマイクロコントローラの実装であり、低速です。例:PDU、UPS。シリアル番号データを提供しますが、その前にタイムアウトすることもあります。 L2スイッチなどのより高度な高速デバイスは、機能スイッチコードと同じマルチタスクCPUでSNMPインターフェイスコードを実行し、負荷が高いと、SNMPスレッドが応答しなくなったり、データを非常に速く返したりする可能性があります。これは、大きなCiscoスイッチなどで見られました。 これにより、主に2つの問題が発生します。 プローブのタイムアウト前に データがまったく受信されなかった ため、プローブがタイムアウトします。この状況では、センサーがエラーになり、識別が失敗します。プローブをタイムアウトする前にデータが受信されましたが、不完全でしたSNMPはUDPに基づいているため、この状況を検出することは困難であり、デバイスから部分的なデータしか受信していないことに気付かない可能性があります。これは、巨大なルーティングテーブルを持つCiscoスイッチなど、転送するデータが多い大型デバイスにも当てはまります。 その後、重要なシリアル番号情報が欠落している不完全なデータを持つセンサーの分類と識別を引き続き実行します。 ソリューション: 応答が遅くなる可能性があるデバイスを特定したら、問題が解決されるまで SNMP プローブのタイムアウトを 段階的に増やすできます。これらの MID サーバーパラメーターを使用して、SNMP ポートを構成できます。これらの詳細については、「MID サーバーパラメーター」または「SNMP プローブパラメーター」のドキュメントを参照してください。 mid.snmp.request.timeout :最初の OID 要求に対する応答を待機する最大時間mid.snmp.session.timeout :セッションが確立された後に OID 要求への応答を待機する最大時間。timeout と established_session_timeout はプローブパラメーターで、上記の 2 つの MID サーバーパラメーターを上書きしますが、「SNMP - 分類」や「SNMP - ID」などの特定のプローブ用です。これらは、任意の MID サーバーを介してディスカバリーに適用されます。 SNMP の実装には、標準のシリアル番号 OID は含まれません シリアル番号を返さないことがわかっているデバイスには、一部のプリンターが含まれ、他の種類のデバイスもあります。 これを確認するには、ID プローブの ECC キュー入力レコードを確認します。OID が存在しないか、値が空になっている可能性があります。 ソリューション: これについて、デバイスのメーカーに報告する以外に ServiceNow にできることはあまりありません。デバイスが一意の名前、IPアドレス、MACアドレスを返す限り、識別を行うのに十分なデータがあります。 IP が以前に使用されており、まだ CMDB 内の別の CI にリンクされている場合、古いデバイスのメイン CI、ネットワークアダプター、および IP アドレス CI から IP アドレス情報をクリアすると、IP に基づく識別が機能します。 デバイスに一般的な名前 (「AFICIO MP 2550」や「RACKPDU」など) がある場合は、CI を手動で追加するか、識別子をカスタマイズする必要があります。その後、ディスカバリーで CI を照合して追加フィールドを更新できます。 デバイスで利用可能なシリアル番号データがありますが、それをフェッチするための現在のプローブがありません デバイスのタイプとメーカー、実装されている標準またはベンダーの MIB に応じて、シリアル番号データはさまざまな OID に存在する可能性があります。例:sysSerialNumber、prtGeneralSerialNumber、chassisSerialNumberString、entPhysicalSerialNum など。 ほとんどの標準デバイスタイプと、Cisco などの特定のメーカー向けにすぐに使用できるプローブとセンサーがありますが、一部が欠落している可能性があります。 ソリューション: この状況では、 カスタムプローブ/センサーを記述する ことが可能です。場合によっては、デバイスベンダーからインスタンス MIB テーブルに新しい MIB を追加してから、その MIB から特定の OID をフェッチするセンサーを作成してから、そのデータを取得して CI を更新するセンサーを作成する必要があります。 一般的なデバイスの場合は、デバイスの詳細と、シリアル番号データが SNMP MIB および OID にある場所を HI で拡張要求を作成する に非常に役立ちます。その後、開発者は、デバイスを認識するすぐに使用できるコードを記述する機会を得ることができます。 センサーがデータの処理に失敗しました また、プローブによって返されたデータに予期しないデータ、フォーマット、または拡張文字が含まれていて、センサーが解析と処理に失敗する可能性もあります。センサーによってスローされたエラーまたは例外が発生する可能性もあります。 ソリューション: ECC キュー入力レコードにシリアル番号を含む完全な SNMP データが含まれていることをすでに確認している場合は、センサーコードに問題がある可能性があり、HI でサポートインシデントを開く必要がある場合があります。 Shazzam が SNMP - 分類プローブを起動しませんでした SNMP は UDP プロトコルであり、ディスカバリーにとって大きな欠点があります。TCPとは異なり、実際のSNMPクエリから結果を取得しない限り、デバイスがそこにあるかどうかを知ることは不可能であり、それでもすべてのデータを持っているかどうかはわかりません。Shazzam は sysObjectID OID (New York より前は sysDescr) を要求して SNMP ポートプローブを実行します。そのための値が返されない場合は、「SNMP - 分類」プローブや「SNMP - ID」プローブは実行されません。