ディスカバリーで SNMP デバイスが間違ったテーブル/CI クラスに配置されるのはなぜですか?Issue <!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #7057C7; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: block; max-width: ; width: auto; height: auto; } } ディスカバリーが SNMP 対応デバイスをスキャンするときに、誤って識別されることがあります。たとえば、サーバーはディスカバリーからプリンターのように見える場合があります。または、プリンターがルーターとして分類されます。その後、CI は間違った CMDB テーブルに挿入されるか、間違った CMDB テーブルに移動されます。 Release<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #7057C7; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: block; max-width: ; width: auto; height: auto; } } Resolution<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #7057C7; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: block; max-width: ; width: auto; height: auto; } } 原因となる可能性は複数あります。たとえば サーバーで 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 カードではありません。 <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 プローブを使用することはできません。これらのポートが開いていたら、これらの分類子が優先され、デバイス上で SNMP 分類を行うことさえなかったでしょう。 これにより、サーバー/OS の IP も別々にスキャンされる場合 (おそらく同じディスカバリースケジュールの後半で) レコードが重複したり、CI クラスが反転したりする可能性があります。 解決策:ディスカバリースケジュールから iLOカードのIP範囲を除外 、代わりにサーバー/OSのメインIPがスキャンされるようにします。 注:iLOがパススルーを使用するように 設定されていない場合 、これらのデバイスは独自の詳細とHP iLOカードバージョンに固有の固有のOIDを報告するため、問題ありません。この場合、これらの iLO カードを検出するための標準提供のものがないため、CI は作成されませんが、理論的にはカスタム実装が可能です。 SNMP OID 分類レコードが正しく追加されていない インスタンスには、オーバーライドを入力できるテーブルがあり、すぐに使用できるコードでクラスを作成する代わりに、 誤って入力される可能性のある特定の一意のシステム OID 値に指定されたテーブルと識別子を使用します。 例:「Xerox WorkCentre Pro」プリンターをスキャンする場合、「SNMP - 分類」プローブの結果には次の「システム」データが含まれます。 <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 のテーブルに誤って追加されたレコードがあり、単に間違ったテーブルや分類子に設定されている場合、 それを使用します。 解決策:その 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 Bad 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 Network Printer C model / RICOH Network Scanner C model / RICOH Network Facsimile C modelSystem OID: 1.3.6.1.4.1.367.1.1 また、生の SNMP - 同じ OID を使用して異なるモデルの入力データを分類する別の例を次に示します。 <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> リコーのプリンターには、他にもいくつかの珍しい点があります。 他のメーカーの一部のプリンターは、実際にはリコープリンターにリバッジされ、リコーOIDを備えています。sysName 値は、プリンターの (DNS) 名ではなく、プリンターモデルのデフォルト値として設定される場合があります。これには、CI の名前と CI の識別のために SNMP によって返される名前よりも逆引き DNS 名を信頼するように、ディスカバリーのプロパティ設定が必要になる場合があります。または、 名前を基準として使用しないプリンター固有の識別ルール。デバイスはルーターと見なすことができます。デバイスが印刷できるだけでなく、ルーティングも可能であることを示す手がかりがある場合、そのデバイスはルーターとして分類されます。「ipForwarding」OID が 1 に設定され、「ipForwDatagrams」OID が 0 より大きい数値に設定されている場合、デバイスはルーターと見なされます。デバイスの場合、両方の条件が一致しています。これは、[SNMP - 分類] 入力で次の OID を探すことで確認できます。これを解決するには、いずれにせよ OID を追加する必要がありますが、CI が間違ったモデル名を取得しないように、モデル名は「不明」のままにしておきます。 <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> 解決策:センサースクリプトがデバイスで何ができるかを正しく判断し、プリンターとして分類できるように、プローブしたすべての OID を返す SNMP - 分類プローブを使用する必要があります。タイムアウトを増やすと、これに役立ちます (以下を参照)。ただし、デバイスが転送を行っているように見える場合、デバイスがルーターとして識別されるリスクがあります。 Linux ベースのネットワークデバイスが「Linux」OID を使用する 多くのネットワークデバイスは、基本的にLinux OSを実行しているARMまたはMIPSベースの組み込みシステムであり、さらにいくつかの専用ハードウェアとインターフェイスを備えています。これらは Linux のように見える可能性があるため、Router を Linux Server テーブルに入れることができます。 場合によっては、メーカーが独自の SNMP SnmpObjectId およびメーカーとモデルに固有のその他の SNMP データを割り当てず、デフォルトの「Linux」OID のままになります。 例:Net-SNMP SNMP MIB モジュールソフトウェアを使用する組み込み Linux デバイスは、sysObjectID "1.3.6.1.4.1.8072.3.2.10" を返します。次の非サーバーデバイスが、一意でない SnmpObjectId を報告していることが確認されています。 リバーベッドテクノロジー、SteelCentralフローゲートウェイ/ユーザーインターフェースモジュールAruba ネットワーク、CP-HW-5K IP ルーターDell、iDRAC7リモートアクセスコントローラExtraHop、Discover 8100Intermec PM43プリンター 解決策: この状況では複数の異なるメーカー/モデルで使用される可能性があるため、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 サーバーを介してディスカバリーに適用されます。