ディスカバリーで SNMP デバイスが間違ったテーブル/CI クラスに配置されたのはなぜですか?Issue <!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } ディスカバリーが SNMP 対応デバイスをスキャンすると、デバイスを誤って識別することがあります。たとえば、サーバーはディスカバリーをプリンターのように見ることができます。または、プリンターがルーターとして分類されます。CI は間違った CMDB テーブルに挿入または移動されます。 Release<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Resolution<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } 原因はたくさんあります。たとえば サーバーで SNMP が有効になっていて、通常の SSH または WMI/Powershell/WinRM プローブが失敗する 接続または認証情報の問題などが原因で、通常の Linux/Solaris/HP-UX または Windows 識別子に障害が発生した場合、Shazzam は SNMP を使用したデバイスの識別にフォールバックします。SNMP - 分類プローブによって返された OID 値に、デバイスがルーティング、スイッチ、印刷、またはサーバーにも存在する可能性のあるその他の機能を示す手がかりが含まれている場合、ディスカバリーはサーバーを別のものとして誤認する可能性があります。 したがって、このため、Linux サーバーはルーターとして識別される可能性があります。 解決策:SNMP だけではサーバーを検出できないため、 SSH または WMI/Powershell/WinRM プローブが失敗する原因を修正します。SNMP プローブは使用されません。 HP サーバーに「パススルー」が有効になっている iLO カードがあり、カードの IP がスキャンされます Compaq/HP サーバーには通常、独自のイーサネット ポートと IP アドレスを持つ iLO デバイスが搭載されています。これは、同じボックス内の独立したウォッチドッグまたはモニターのようなものであり、ディスカバリーの観点からは「サーバー」の一部ではありません。 これらは SNMP を実装し、「SNMP パススルー」用に設定されている場合、それ自体をレポートする代わりに、カードをサーバーのように見せます。iLO IP アドレスの SNMP 結果は、サーバーのハードウェアとオペレーティングシステムに対するものであるように見えます。 たとえば、「SNMP - 分類」プローブからの入力は次のいずれかのようになります。これらは明らかに iLO カードではなくサーバーオペレーティングシステムです。 HP-UX atksts00 B.11.31 U ia64 3910543201.1.3.6.1.4.1.11.2.3.2.6 ハードウェア:Intel64 ファミリー 6 モデル 47 ステップ 2 AT/AT 互換 - ソフトウェア:Windows バージョン 6.3 (ビルド 9600 マルチプロセッサ無料).1.3.6.1.4.1.311.1.1.3.1.2 これの大きな問題は、iLO カードには SSH や WMI のパススルーもないため、すべての Shazzam で SNMP ポートが開いていることがわかります。この IP を介して Windows プローブまたは Unix プローブを使用することはできません。これらのポートが開いていたら、これらの分類子が優先され、デバイス上でSNMP分類も実行されなかったでしょう。 これにより、サーバー/OS の IP も個別にスキャンされる場合 (おそらく同じディスカバリースケジュールの後半で) レコードが重複したり、CI クラスが反転したりする可能性があります。 解決策:ディスカバリースケジュールから iLO カードの IP 範囲を除外 、代わりにサーバー/OS のメイン IP がスキャンされるようにします。 注:iLOがパススルーを使用するように 設定されていない 場合、これらのデバイスは独自の詳細と、HP iLOカードバージョンに固有の一意のOIDを報告するため、問題はありません。この場合、これらの iLO カードを検出するための初期設定はないため、CI は作成されませんが、理論的にはカスタム実装が可能です。 SNMP OID 分類レコードが誤って追加されました インスタンスにはオーバーライドを入力できるテーブルがあるため、クラスを計算するための初期設定のコードの代わりに、 誤って入力される可能性がある特定の一意のシステム OID 値に指定されたテーブルと識別子を使用します。 たとえば、「Xerox WorkCentre Pro」プリンタをスキャンする場合、「SNMP - 分類」プローブの結果には次の「システム」データが含まれます。 P01IT08Xerox WorkCentre Pro 多機能システム;ESS 0.040.010.51172、IOT 50.0.0、UI 0.12.50.3、フィニッシャー 3.20.0、スキャナー 4.9.051948316.1.3.6.1.4.1.253.8.62.1.20.1.24.1 OID=1.3.6.1.4.1.253.8.62.1.20.1.24.1 のレコードが誤ってテーブルに追加され、単に間違っているテーブルや分類子に設定された場合、 関係なくそれが使用されます。 解決策 ：その OID の [SNMP OID 分類] レコードを削除または修正します。 注: すぐに利用可能な不適切な OID がいくつかあり、その後製品から削除されました。 PRB1412617 HP/Compaq iLO の OID 1.3.6.1.4.1.232.9.4.10 により、サーバーが IP スイッチとして再分類または複製されるPRB1408983 1.3.6.1.4.1.311.1.1.3 で始まる 3 つの汎用 Microsoft OID。により、Windows サーバーがコンピューター、プリンター、またはルーターとして再分類されるPRB1376883 1.3.6.1.4.1.8072.3.2 以降の 3x 不正な OID が追加されました。これらは汎用 Linux SNMP スタック OID であり、特定のタイプの一意のデバイスではありません デバイスが非標準であるため、SNMP OID 分類レコードを追加する必要があります 一部の製造元のデバイスには、非常に珍しい SNMP 実装があり、標準 MIB のルールに基づいてプログラムで正確に分類することは不可能です。 ソリューション:このメーカーとモデルのSNMP OID 分類レコードを作成 ECC キューテーブルで、このデバイスの IP アドレスの SNMP - 分類プローブ入力レコードを検索する必要があります。上で強調表示したような sysObjectID 値を使用します。 メーカーがモデルごとに一意の OID を使用していないか、デバイスが OEM によってブランド変更されているため、SNMP OID 分類レコードを使用できません 一部のメーカーのデバイスは、リコーのネットワークプリンタなど、複数のモデル間で標準コンポーネントを共有する場合があります。SNMP - 分類プローブは、RICOH MP C6503 プリンターの CI の説明フィールドに対してこのデータを返す場合がありますが、同じ範囲内の他のすべてのモデルも同じ OID を使用します。 RICOH MP C6503 1.03 / RICOH ネットワークプリンター C モデル / RICOH ネットワークスキャナー C モデル / RICOH ネットワークファクシミリ C モデルシステム OID: 1.3.6.1.4.1.367.1.1 生のSNMP - 同じOIDを使用して別のモデルの入力データを分類する別の例: Aficio MP C305.1.3.6.1.4.1.367.1.1RICOH Aficio MP C305 4.10 / RICOH ネットワークプリンター Cモデル / RICOH ネットワークスキャナー C モデル / RICOH ネットワークファクシミリ C モデル リコープリンターには他にもいくつかの珍しい点があります。 他のメーカーのプリンタの中には、実際にはリコープリンタのバッジが再付与され、リコー OID が付いているものもあります。sysName 値は、プリンターの (DNS) 名ではなく、プリンターモデルのデフォルト値として設定できます。これには、CI の名前と CI の識別のために、SNMP によって返される名前よりもリバース DNS 名を信頼するようにディスカバリープロパティの設定が必要になる場合があります。または、名前を基準として使用しないプリンター固有の識別ルールを使用します。デバイスはルーターと見なされる場合があります。デバイスに、印刷できるがルーティングも可能であることを示唆する手がかりがある場合、そのデバイスはルーターとして分類されます。「ipForwarding」OID が 1 に設定され、「ipForwDatagrams」OID が 0 より大きい数値に設定されている場合、デバイスはルーターとして表示されます。ご利用のデバイスのケースでは、両方の条件が一致しています。これは、[SNMP - 分類] 入力でこれらの OID を探すことで確認できます。これを解決するには、いずれにしても OID を追加する必要がありますが、CI が間違ったモデル名を取得しないように、モデル名を「不明」のままにします。 14581 解決策:センサースクリプトがデバイスで何ができるかを正しく判断し、デバイスをプリンターとして分類できるように、プローブするすべての OID を返す SNMP - 分類プローブに依存する必要があります。タイムアウトを増やすと、これに役立ちます (下記参照)。ただし、転送を行っているように見える場合、デバイスがルーターとして識別されるリスクがあります。 Linux ベースのネットワークデバイスが「Linux」OID を使用する 多くのネットワーク デバイスは、基本的に Linux OS を実行する ARM または MIPS ベースの組み込みシステムに加えて、いくつかの専用のハードウェアとインターフェイスです。これらは Linux のように見える場合があるため、ルーターが Linux サーバーテーブルに配置されている可能性があります。 場合によっては、メーカーが独自の SNMP、SnmpObjectId、およびメーカーとモデルに固有の他の SNMP データを割り当てることができず、デフォルトの「Linux」OID が残ります。 たとえば、Net-SNMP SNMP MIBモジュールソフトウェアを使用する組み込みLinuxデバイスは、sysObjectID「1.3.6.1.4.1.8072.3.2.10」を返します。次の非サーバーデバイスが、一意でない SnmpObjectId を報告していることが確認されています。 Riverbed Technology、SteelCentral フローゲートウェイ/ユーザーインターフェイスモジュールAruba Network、CP-HW-5K IP ルーターDell、iDRAC7リモートアクセスコントローラExtraHop、Discover 8100Intermec PM43プリンター 解決策: この状況では複数の異なるメーカー/モデルで OID が使用される可能性があるため、その OID を SNMP OID 分類テーブルに追加しないでください。SNMP データの他の手がかりに基づいてデバイスを自動的に分類することはできるはずです。そうでない場合は、デバイスの製造元に問い合わせて、メーカーとモデルに一意の OID を使用するように修正してもらうことを検討してください。 注意： この原因は、SNMP が有効になっている Linux サーバーが分類に失敗したことと混同しないでください。SSH が正しく構成されている場合、SNMP は使用されません。これは理論的には、Net-SNMP SNMP MIBモジュールを使用する組み込みデバイスで見られ、オペレーティングシステムごとにOIDの最後の桁が異なります。10=Linux、3=Solarisなど プローブ:データを受信するまでのタイムアウト 一部の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 サーバーを介したディスカバリーに適用されます。