Discovery が 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: ; } } Discovery が SNMP 対応デバイスをスキャンすると、デバイスを誤って識別する場合があります。たとえば、サーバーが Discovery にはプリンターのように見える場合があります。または、プリンターがルーターとして分類されます。その場合、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 プローブが失敗するHP サーバーに「Passthrough」が有効になっている iLO カードがあり、そのカードの IP がスキャンされるSNMP OID Classification レコードが誤って追加されているデバイスが非標準であるため、SNMP OID Classification レコードを追加する必要があるメーカーがモデルごとに一意の OID を使用していないか、デバイスが OEM によってブランド変更されているため、SNMP OID Classification レコードを使用できないLinux ベースのネットワークデバイスが「Linux」OID を使用するデータを受信する前にプローブがタイムアウトするITOM Content Service によって不正または不完全な OID/Classifier が追加される サーバーで SNMP が有効になっており、通常の SSH または WMI/PowerShell/WinRM プローブが失敗する 通常の Linux/Solaris/HP-UX または Windows 識別子が、おそらく接続または資格情報の問題が原因で失敗した場合、Shazzam は SNMP を使用したデバイスの識別にフォールバックします。SNMP - Classify プローブによって返された OID 値に、デバイスがルーティング、スイッチング、印刷、またはサーバーにも存在する可能性があるその他の機能を実行できるかどうかを示す手掛かりが含まれている場合、Discovery はサーバーを別のものとして誤って識別する可能性があります。 したがって、Linux サーバーがルーターとして識別される可能性があります。 解決策：SNMP のみではサーバーを検出できないため、SSH または WMI/PowerShell/WinRM プローブの失敗の原因となっているものを修正します。その後、SNMP プローブは使用されません。 HP サーバーに「Passthrough」が有効になっている iLO カードがあり、そのカードの IP がスキャンされる Compaq/HP サーバーには通常、独自のイーサネットポートと IP アドレスを持つ iLO デバイスが搭載されています。これは同じ筐体内にある独立したウォッチドッグまたはモニターのようなものであり、Discovery の観点では「サーバー」の一部ではありません。 これらは SNMP を実装しており、「SNMP Pass-through」用に設定されている場合、それ自体について報告する代わりに、カードをサーバーのように見せます。iLO IP アドレスの SNMP 結果は、サーバーのハードウェアおよびオペレーティングシステムに関するものであるように見えます。 たとえば、「SNMP - Classify」プローブからの入力は次のいずれかのように見える場合があり、これらは明らかにサーバーのオペレーティングシステムであり、iLO カードではありません。 <sysDescr oid="1.3.6.1.2.1.1.1" type="SnmpOctetString">HP-UX atksts00 B.11.31 U ia64 3910543201</sysDescr><sysObjectID oid="1.3.6.1.2.1.1.2" type="SnmpObjectId">.1.3.6.1.4.1.11.2.3.2.6</sysObjectID> <sysDescr oid="1.3.6.1.2.1.1.1" type="SnmpOctetString">Hardware: Intel64 Family 6 Model 47 Stepping 2 AT/AT COMPATIBLE - Software: Windows Version 6.3 (Build 9600 Multiprocessor Free)</sysDescr><sysObjectID oid="1.3.6.1.2.1.1.2" type="SnmpObjectId">.1.3.6.1.4.1.311.1.1.3.1.2</sysObjectID> これに関する大きな問題は、iLO カードには SSH または WMI のパススルーもないため、Shazzam には開いている SNMP ポートしか見えないことです。この IP を介して Windows または Unix プローブを使用することはできません。これらのポートが開いていた場合は、それらの Classifier が優先され、デバイスに対して SNMP Classify を実行することさえありませんでした。 サーバー/OS の IP も、おそらく同じ Discovery スケジュール内で後から個別にスキャンされる場合、これによってレコードの重複または CI クラスの切り替わりが発生する可能性があります。 解決策：Discovery スケジュールから iLO カードの IP 範囲を除外し、代わりにサーバー/OS のメイン IP がスキャンされるようにします。 注：iLO がパススルーを使用するように設定されていない場合、問題はありません。この場合、これらのデバイスは自身の詳細と、HP iLO カードのバージョンに固有の一意の OID を報告するためです。この場合、これらの iLO カードを検出するための標準機能がないため、CI は作成されませんが、理論上はカスタム実装が可能です。 SNMP OID Classification レコードが誤って追加されている インスタンスには、標準コードによってクラスを判別する代わりに、特定の一意の System OID 値に対して指定されたテーブルと識別子を使用するようにオーバーライドを入力できるテーブルがあり、そこに誤った値が入力される場合があります。 たとえば、「Xerox WorkCentre Pro」プリンターをスキャンすると、「SNMP - Classify」プローブの結果には次の「system」データが含まれます。 <system oid="1.3.6.1.2.1.1"> <sysName oid="1.3.6.1.2.1.1.5" type="SnmpOctetString">P01IT08</sysName> <sysDescr oid="1.3.6.1.2.1.1.1" type="SnmpOctetString">Xerox WorkCentre Pro Multifunction System; ESS 0.040.010.51172, IOT 50.0.0, UI 0.12.50.3, Finisher 3.20.0, Scanner 4.9.0</sysDescr> <sysUpTime oid="1.3.6.1.2.1.1.3" type="SnmpTimeTicks">51948316</sysUpTime> <sysObjectID oid="1.3.6.1.2.1.1.2" type="SnmpObjectId">.1.3.6.1.4.1.253.8.62.1.20.1.24.1</sysObjectID></system> OID=1.3.6.1.4.1.253.8.62.1.20.1.24.1 のレコードが誤ってテーブルに追加され、単純に誤っているテーブルまたは Classifier、あるいはその両方が設定されている場合、それに関係なく、その設定が使用されます。 解決策：その OID の SNMP OID Classification レコードを削除または修正します。 注：過去に、製品に標準で含まれていた不正な OID がいくつかあり、その後削除されています。 PRB1412617：HP/Compaq iLO の OID 1.3.6.1.4.1.232.9.4.10 によって、サーバーが IP Switch として再分類または重複される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. で始まる 3 つの不正な OID が追加されている。これらは汎用 Linux SNMP スタックの OID であり、特定の種類の一意のデバイスではない デバイスが非標準であるため、SNMP OID Classification レコードを追加する必要がある 一部の製造元のデバイスには非常に特殊な SNMP 実装があり、標準 MIB の規則に基づいてプログラムで正確に分類することが不可能です。 解決策：この製造元およびモデルの SNMP OID Classification レコードを作成します。 このデバイスの IP アドレスに対する SNMP - Classify プローブの入力レコードを ECC Queue テーブルで検索する必要があります。次に、上記で強調表示されているような sysObjectID 値を使用します。 メーカーがモデルごとに一意の OID を使用していないか、デバイスが OEM によってブランド変更されているため、SNMP OID Classification レコードを使用できない 一部の製造元のデバイスでは、Ricoh のネットワークプリンター製品群など、複数のモデル間で標準コンポーネントが共有されている場合があります。SNMP - Classify プローブは、RICOH MP C6503 プリンターの CI の説明フィールドに対して次のデータを返す場合がありますが、同じ製品群の他のすべてのモデルも同じ OID を使用します。 RICOH MP C6503 1.03 / RICOH Network Printer C model / RICOH Network Scanner C model / RICOH Network Facsimile C modelSystem OID: 1.3.6.1.4.1.367.1.1 同じ OID を使用する別のモデルの未加工の SNMP - Classify 入力データの別の例を次に示します。 <system oid="1.3.6.1.2.1.1"><sysName oid="1.3.6.1.2.1.1.5" type="SnmpOctetString">Aficio MP C305</sysName><sysObjectID oid="1.3.6.1.2.1.1.2" type="SnmpObjectId">.1.3.6.1.4.1.367.1.1</sysObjectID><sysDescr oid="1.3.6.1.2.1.1.1" type="SnmpOctetString">RICOH Aficio MP C305 4.10 / RICOH Network Printer C model / RICOH Network Scanner C model / RICOH Network Facsimile C model</sysDescr></system> Ricoh プリンターには、その他にもいくつかの特殊な点があります。 他の製造元の一部のプリンターは、実際にはブランド名を変更した Ricoh プリンターであり、Ricoh の OID を持っています。sysName 値には、プリンターの (DNS) 名ではなく、プリンターモデルのデフォルト値が設定されている場合があります。CI の名前および CI の識別に対して SNMP から返された名前よりも逆引き DNS 名を信頼するように Discovery プロパティを設定する必要がある場合があります。または、名前を条件として使用しないプリンター固有の Identification Rule が必要になる場合があります。デバイスがルーターとして認識される場合があります。デバイスに印刷可能であることを示す手掛かりがあり、さらにルーティングも可能である場合、そのデバイスはルーターとして分類されます。「ipForwarding」OID が 1 に設定され、「ipForwDatagrams」OID が 0 より大きい任意の数値に設定されている場合、デバイスはルーターとして認識されます。対象のデバイスでは、両方の条件が一致しています。これは、SNMP - Classify 入力でこれらの OID を検索することによって確認できます。これを解決するには、いずれにしても OID を追加する必要がある場合がありますが、CI に誤ったモデル名が設定されないように、モデル名は「unknown」のままにします。 <ip oid="1.3.6.1.2.1.4"><ipForwarding oid="1.3.6.1.2.1.4.1" type="SnmpInt32">1</ipForwarding><ipForwDatagrams oid="1.3.6.1.2.1.4.6" type="SnmpCounter32">4581</ipForwDatagrams> 解決策：センサースクリプトがデバイスで実行できる機能を正しく判別し、そのデバイスをプリンターとして分類できるように、SNMP - Classify プローブがプローブ対象のすべての OID を返すことに依存する必要があります。タイムアウトを長くすると、これに役立つ場合があります（以下を参照）。ただし、転送を実行しているように見える場合、デバイスがルーターとして識別される可能性があります。 Linux ベースのネットワークデバイスが「Linux」OID を使用する 多くのネットワークデバイスは、基本的に Linux OS を実行する ARM または MIPS ベースの組み込みシステムであり、さらに専用のハードウェアとインターフェイスを備えています。これらは Linux のように見える場合があるため、ルーターが Linux Server テーブルに配置される可能性があります。 場合によっては、製造元が独自の 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 Flow Gateway/User Interface ModuleAruba Network、CP-HW-5K IP RouterDell、iDRAC7 Remote Access ControllerExtraHop、Discover 8100Intermec PM43 Printer 解決策：この状況では、複数の異なる製造元またはモデルが使用している可能性があるため、その OID を SNMP OID Classification テーブルに追加しないでください。SNMP データ内の他の手掛かりに基づいて、デバイスを自動的に分類できるはずです。それができない場合、製造元とモデルに一意の OID を使用するように修正してもらうため、デバイスの製造元への問い合わせを検討できます。 注： この原因を、SNMP が有効になっている Linux サーバーの分類に失敗することと混同しないでください。SSH が正しく設定されている場合、SNMP は使用されません。理論上、これは Net-SNMP SNMP MIB モジュールを使用する任意の組み込みデバイスで確認される可能性があり、オペレーティングシステムごとに OID の最後の数字が異なります。10=Linux、3=Solaris などです。 データを受信する前にプローブがタイムアウトする 一部の SNMP 対応ネットワークデバイスは、PDU や UPS など、非常に単純で低速な組み込みマイクロコントローラー実装です。これらはシリアル番号データを提供しますが、提供する前にタイムアウトする場合があります。 L2 Switch などのより高度で高速なデバイスでは、スイッチ機能のコードと同じマルチタスク CPU で SNMP インターフェイスコードが実行されます。負荷が高い場合、SNMP スレッドが迅速に応答しなかったり、データを迅速に返さなかったりする可能性があります。これは大型の Cisco Switch などで確認されています。 これによって、主に 2 つの問題が発生します。 プローブのタイムアウトまでにデータがまったく受信されなかったため、プローブがタイムアウトします。この状況ではセンサーでエラーが発生し、識別に失敗します。プローブがタイムアウトする前にデータが受信されましたが、不完全でした。SNMP は UDP に基づいているため、この状況を検出することは困難であり、デバイスから一部のデータのみが返されたことに気付かない場合があります。これは、巨大なルーティングテーブルを持つ Cisco Switch など、転送するデータが多い大型デバイスでも発生する可能性があります。 その場合、不完全なデータを使用して Classify センサーと Identify センサーの実行を続行し、重要な分類情報を見落とす可能性があります。 解決策： 応答に時間がかかる可能性があるデバイスを識別した後、問題が解決されるまで SNMP プローブのタイムアウトを段階的に長くすることができます。これらの MID Server パラメーターを使用して、SNMP プローブを設定できます。詳細については、「MID Server Parameters」または「SNMP probe parameters」のドキュメントを参照してください。 mid.snmp.request.timeout：最初の OID リクエストに対する応答を待機する最大時間 mid.snmp.session.timeout：セッションの確立後に OID リクエストへの応答を待機する最大時間 timeout および established_session_timeout は、前述の 2 つの MID Server パラメーターをオーバーライドするプローブパラメーターですが、「SNMP - Classify」や「SNMP - Identity」など、特定のプローブに対して設定されます。これらは、任意の MID Server を介した Discovery に適用されます。 ITOM Content Service によって不正または不完全な OID/Classifier が追加される ITOM Content Service は、顧客が行った OID および Classifier の変更を他の顧客と共有することによって、新しいデバイスをより迅速にサポートするための方法です。不正または不完全な OID レコードやその他の Classifier が紛れ込む場合があります。 たとえば、顧客から提供された SNMP OID レコードがカスタムテーブルを参照していたり、他の顧客のインスタンスには存在しないカスタム Classifier を使用していたりする場合があります。または、OID が単純に誤っており、誤ったテーブルと Classifier が設定されている場合があります。または、デバイスに対して存在しないか、完全には機能しないパターンをトリガーする Classifier が設定されている場合があります。 解決策： コンテンツを修正できるように、コンテンツリクエストまたはサポートケースで問題を報告する必要があります。コンテンツは、サンドボックスまたは本番前の手順なしで、本番環境を含むすべてのインスタンスにプッシュされますが、多くの場合 1 週間以内に非常に迅速に修正することもできます。 レコードを修正できない場合は、無効にする必要がある可能性があります。Discovery でサポートされていないためにデバイスタイプまたはファミリが機能しない場合は、Enhancement Idea を登録できます。