Cisco ACIファブリックのSNMPのトラブルシューティング
はじめに
このドキュメントでは、ACIリリース5.x以降のCisco ACIでSNMPを設定、確認、およびトラブルシューティングする方法について説明します。リーフ/スパイン型スイッチとAPICコントローラの最も一般的な障害シナリオにおける、SNMPポリシーモデル、必要な管理契約、トラップ設定、CLIおよび管理対象オブジェクト(MO)クエリを使用した動作検証、構造化されたトラブルシューティングワークフローについて説明します。
バックグラウンド情報
このドキュメントの資料は、Tomas de Leonによって執筆されたCisco ACI Solutions Delivery Team(ACI)の内部テクニカルノート『ACIのSNMP：概要、設定、トラブルシューティング、および注意/問題』から引用され、Cisco APICシステム管理設定ガイド（リリース5.x）およびCisco ACI MIBクイックリファレンスガイドで補足されています。
概要
ACIのSNMPアーキテクチャ
SNMP(Simple Network Management Protocol)は、ネットワーク管理とモニタリングを制御するUDPベースのプロトコルです。ACIでは、SNMPは各管理対象エンティティで独立して動作します。すべてのリーフスイッチ、スパインスイッチ、およびAPICコントローラは、それぞれ独自のSNMPエージェントです。各エージェントは個別にポーリングまたはモニタする必要があります。
ACIは次のSNMP機能をサポートしています。
- 読み取り操作(Get、GetNext、BulkGet、Walk)：リーフ/スパインスイッチおよびAPICコントローラでサポートされます。
- 通知（トラップ）：リーフ/スパインスイッチおよびAPICコントローラでサポートされるSNMPv1、v2c、およびv3トラップ。
- SNMPv3：リーフ/スパインスイッチおよびAPICコントローラでサポートされます。
- 書き込み操作（設定）：どのACIデバイスでもサポートされません。
- IPv6:SNMPはIPv4でのみサポートされます。
APICでのSNMPDアーキテクチャ
APICは、次の2つの内部コンポーネントを持つsnmpdプロセスを実行します。
- Agent:SNMPプロトコル処理とセッション管理を処理するオープンソースのnet-snmpエージェント（バージョン5.7.6以降）。
- DME（データモデルエンジン）:APIC Management Information Tree（MIT；管理情報ツリー）とインターフェイスし、管理対象オブジェクト(MO)を読み取って、MO属性をSNMPオブジェクト形式に変換します。SNMPトラップは、MOで発生したイベントと障害から生成されます。
SNMPポリシーモデルと導入チェーン
ACIはSNMPにポリシー駆動型モデルを使用します。SNMP設定は、snmpPol管理オブジェクトとして抽象化されます。また、ファブリックを任意のノードに展開する前に、ファブリックのポッドポリシーグループに関連付ける必要があります。完全な導入チェーンは次のとおりです。
- SNMPポリシー(
snmpPol)：管理状態、コミュニティストリング、クライアントグループポリシー(ACL)、およびSNMPv3ユーザを定義します。 - ポッドポリシーグループ：他のポッドレベルのポリシー（BGP、ISIS、NTPなど）とともにSNMPポリシーを参照します。
- ポッドプロファイルセレクタ：ファブリックポッドにポッドポリシーグループを適用します。
また、SNMPトラップの設定には次が必要です。
- SNMP Monitoring Destination Group(
snmpGroup)：トラップ宛先ホスト、ポート、SNMPバージョン、およびコミュニティを定義します。 - Monitoring Sources(snmpSrc)：宛先グループを3つの別個のモニタリングポリシースコープ（ファブリックデフォルト、ファブリック共通ポリシー、およびアクセスポリシーデフォルト）にリンクします。
APICノードには、UDPポート161（SNMP要求）およびUDPポート162（SNMPトラップ）を許可する管理契約が必要です。リーフノードとスパインノードにも正しいiptablesルールが必要です。このルールは、クライアントグループポリシーの設定時に自動的にプログラムされます。
サポートされたMIB
APICでサポートされるMIBは次のとおりです。
- エンティティMIB:PhysicalTable
- シスコエンティティ拡張MIB:PhysicalProcessorTable、LEDTable
- シスコエンティティFRU制御MIB:PowerSupplyGroupTable、PowerStatusTable、FanTrayStatusTable、PhysicalTable
- Cisco Entity Sensor MIB:SensorValueTable、SensorThresholdTable
- シスコプロセスMIB:CPUTotalTable、ProcessTable、ProcessExtRevTable、ThreadTable
リーフスイッチとスパインスイッチは、IF-MIB、IP-MIB、CISCO-CDP-MIB、CISCO-ENTITY-QFP-MIB、および完全なCISCO-ENTITY-FRU-CONTROL-MIBスイートを含む標準のNX-OS MIBを公開します。
APICで生成されるSNMPトラップには、cefcFRUInserted、cefcFRURemoved、cefcFanTrayStatusChange、cefcModuleStatusChange、entSensorThresholdNotification、cefcPowerStatusChange、cpmCPURisingThreshold、cpmCPUFallingThresholdがあります。
ACIでのSNMPの設定
ステップ1:SNMPポリシーの設定
Fabric > Fabric Policies > Policies > Pod > SNMPの順に移動します。SNMPポリシー(通常はdefault)を選択（または作成）します。設定例:
- Admin State:Enabledに設定します。
- Community Policies:NMSで使用するコミュニティストリングを追加します。
- Client Group Policies:1つ以上のクライアントグループプロファイルを定義し、各プロファイルで許可されるSNMPクライアントIP(Outside-of-Band)および関連する管理EPG（Out-of-BandまたはIn-Band）を指定します。
- SNMPv3ユーザ:SNMPv3を使用する場合は、ここで認証とプライバシーパラメータを使用してユーザを追加します。
ステップ2:SNMPポリシーをポッドポリシーグループに関連付けます。
Fabric > Fabric Policies > Pods > Policy Groupsの順に移動します。アクティブなポッドポリシーグループ(通常defaultという名前)を選択します。 SNMP Policyフィールドが、ステップ1で作成したSNMPポリシーをポイントするように設定します。Resolved SNMP Policyフィールドに正しいポリシー名が表示されていることを確認します。
次に、Fabric > Fabric Policies > Pods > Profilesの順に移動し、デフォルトのポッドプロファイルを展開して、アクティブなセレクタが正しいポッドポリシーグループを参照していることを確認します。
ステップ3:UDPポート161の管理コントラクトを設定します
Tenants > mgmt > Contracts > Out-Of-Band Contractsの順に移動します。アクティブなOOBコントラクトのサブジェクトが、UDPポート161（SNMP要求）を許可するフィルタエントリを参照していることを確認します。 APICでこのコントラクトがないと、すべてのSNMP GET/WALKパケットは通知なしにドロップされます。
コントラクト対象に添付されるフィルタエントリには、EtherType IP、プロトコルUDP、および宛先ポート161を含むエントリが含まれている必要があります。上記の例は、allow-all（未指定プロトコル）フィルタを示しています。これはSNMPを許可しますが、実稼働環境で推奨されるよりも範囲が広くなります。特定のUDP/161およびUDP/162エントリを持つ専用のSNMPフィルタエントリが推奨されます。
ステップ4:SNMPトラップ送信先の設定
Admin > External Data Collectors > Monitoring Destinations > SNMPの順に移動します。右クリックして、Create SNMP Monitoring Destination Groupを選択します。SNMPタブには、設定されているすべての宛先グループが表示されます。空のテーブルは、トラップの宛先がまだ設定されていないことを意味します。
定義：
- グループ名
- トラップ宛先：ホスト名/IP、UDPポート（デフォルトは162）、SNMPバージョン、コミュニティストリング、および管理EPG
ステップ5：モニタリングソースの設定
モニタリングソースは、SNMP宛先グループを、トラップを生成するイベントと障害を制御するモニタリングポリシーにリンクします。モニタリングソースは、次のロケーションの3つすべてのロケーションで設定する必要があります。設定されていないと、一部のノードタイプからのトラップが送信されません。
- Fabric > Fabric Policies > Policies > Monitoring > default > Callhome/Smart Callhome/SNMP/Syslog/TACACS（ファブリックインフラストラクチャイベントを対象）
- Fabric > Fabric Policies > Policies > Monitoring > Common Policy > Callhome/Smart Callhome/SNMP/Syslog/TACACS（ファブリック全体の一般的なイベントを対象）
- Fabric > Access Policies > Policies > Monitoring > default > Callhome/Smart Callhome/SNMP/Syslog（アクセス/インフラストラクチャイベントを対象）
それぞれの場所で、送信元タイプとしてSNMPを選択し、ステップ4で作成した宛先グループを参照する新しいSNMPソースを作成します。
設定の確認
SNMPポリシー展開の確認
Fabric > Fabric Policies > Policies > Pod > SNMPの順に移動し、default SNMPポリシーが存在し、そのAdmin StateがEnabledに設定されていることを確認します。ポリシーグループリストには、設定されているすべてのSNMPポリシーとその管理状態が一目でわかります。
詳細な検証を行うには、ポリシー名をクリックして開きます。Admin State toggleがEnabledに設定されており、許可されたすべてのNMSホストがクライアントグループポリシーに関連付けられた管理EPGとともにリストされていることを確認します。
APICで次のMOクエリを実行して、SNMPポリシーがファブリックに存在し、有効になっていることを確認します。
apic1# moquery -c snmpPol Total Objects shown: 1 # snmp.Pol name : default adminSt : enabled <--- must be "enabled" contact : NOC Team descr : ACI Fabric SNMP Policy dn : uni/fabric/snmppol-default loc : DC1 ACI Fabric monPolDn : uni/fabric/monfab-default
adminStがdisabledになっている場合は、SNMPはどのノードでも機能しません。APIC GUIのFabric > Fabric Policies > Policies > Pod > SNMP > defaultで有効にします。
コミュニティストリング設定の確認
apic1# moquery -c snmpCommunityP Total Objects shown: 1 # snmp.CommunityP name : public <--- confirm this matches your NMS community string dn : uni/fabric/snmppol-default/community-public descr : SNMP Community String
コミュニティが返されない場合、または名前がNMSで使用されているものと一致しない場合は、SNMPポリシーでコミュニティストリングを追加または修正します。
クライアントグループポリシーの確認（SNMPアクセスコントロール）
クライアントグループポリシーは、SNMP GET/WALKアクセスのACLとして機能します。各ポリシーは、どのクライアントIPアドレスがどの管理VRF経由でリーフ/スパインノードをポーリングできるかを指定します。リーフ/スパインノードでは、これらのポリシーはiptablesルールに変換されます。
apic1# moquery -c snmpClientGrpP -x query-target=children Total Objects shown: 3 # snmp.ClientP addr : 10.1.1.50 <--- NMS server IP dn : uni/fabric/snmppol-default/clgrp-NMS-Clients/client-[10.1.1.50] name : nms-server1 # snmp.ClientP addr : 10.1.1.51 dn : uni/fabric/snmppol-default/clgrp-NMS-Clients/client-[10.1.1.51] name : nms-server2 # snmp.ClientGrpP name : NMS-Clients dn : uni/fabric/snmppol-default/clgrp-NMS-Clients
NMSサーバのIPアドレスがクライアントエントリに存在することを確認します。クライアントIPが欠落している場合、そのホストからのSNMP GET/WALK要求は、リーフ/スパインノードのiptablesによってドロップされます。
ポッドポリシーグループがSNMPポリシーを参照していることを確認する
Fabric > Fabric Policies > Pods > Policy Groupsの順に移動し、アクティブなポッドポリシーグループを開きます。SNMP Policyドロップダウンフィールドに目的のSNMPポリシーが設定され、Resolved SNMP Policyフィールドに同じ名前が表示されていることを確認します。ポリシーが存在しないか未解決の場合、SNMP設定がスイッチにプッシュされることはありません。
上記のスクリーンショットでは、SNMP Policyフィールドに「select a value」（空）が表示され、解決済みSNMPポリシーに「default」が表示されています。これは、ポリシーがファブリックのデフォルトから継承されているが、明示的に設定されていないことを意味します。あいまいさを避けるために、SNMP Policyフィールドを明示的に設定することをお勧めします。
REST APIによる確認：
apic1# moquery -c fabricPodPGrp -x rsp-subtree=full # fabric.PodPGrp name : default dn : uni/fabric/funcprof/podpgrp-default # fabric.RsSnmpPol tnSnmpPolName : default <--- must reference the SNMP policy state : formed <--- must be "formed"
stateがformedでない場合、SNMPポリシー関係は壊れています。ポッドポリシーグループでSNMPポリシーを再選択して送信します。
UDP 161（APICノード）の管理コントラクトの確認
Tenants > mgmt > Contracts > Out-Of-Band Contracts（および、INB管理を使用している場合はIn-Band Contracts）に移動します。 アクティブなOOBコントラクトを開き、Policyタブをクリックします。SubjectがUDPポート161を許可するフィルタを参照していることを確認します。
件名で参照されているフィルタを展開し、そのエントリにEtherType IP、プロトコルUDP、宛先ポート161のエントリが含まれていることを確認します。フィルタエントリにより、OOB管理コントラクトを介してAPICに許可されるトラフィックが決まります。
フィルタには次のように表示されます。
- EtherType:IP
- IPプロトコル：UDP
- 宛先ポート：自：161
- 宛先ポート：161
また、OOBインターフェイス経由でSNMPトラップを発信するようにAPICに設定する場合は、UDPポート162が許可されていることを確認します。
MOクエリによる確認：
apic1# moquery -c vzEntry -x query-target-filter='and(eq(vzEntry.dFromPort,"161"),eq(vzEntry.prot,"17"))' Total Objects shown: 2 # vz.Entry name : snmp-get dn : uni/tn-mgmt/flt-snmp-filter/e-snmp-get dFromPort : 161 <--- destination port 161 dToPort : 161 prot : 17 <--- UDP stateful : no
結果が返されない場合は、UDP 161のフィルタは存在しません。1つを管理契約に追加します。
SNMPトラップ送信先の設定の確認
Admin > External Data Collectors > Monitoring Destinations > SNMPの順に移動し、設定されているすべてのSNMP宛先グループを表示します。空のリストは、トラップの宛先が設定されておらず、どのノードからもトラップが送信されないことを意味します。
apic1# moquery -c snmpTrapDest Total Objects shown: 1 # snmp.TrapDest host : 10.1.1.50 <--- NMS trap receiver IP port : 162 <--- trap UDP port ver : v2c <--- SNMP version secName : public <--- community string (v2c) or username (v3) v3SecLvl : noauth notifT : traps vrfName : mgmt:inb <--- VRF used to reach the trap receiver epgDn : uni/tn-mgmt/mgmtp-default/inb-default dn : uni/fabric/snmpgroup-NMS-DestGrp/trapdest-10.1.1.50-port-162
トラップの宛先IP、ポート、バージョン、コミュニティストリング、および管理VRF(OOBの場合はmgmt:inbまたはmanagement)が環境に一致していることを確認します。VRFは、宛先に割り当てられた管理EPGと一致する必要があります。
3つのスコープすべてに監視送信元が設定されていることを確認します。
SNMPソースは、3つすべてのモニタリングポリシースコープに存在する必要があります。いずれのスコープでも送信元が欠落している場合、関連するイベントからのトラップは転送されません。
apic1# moquery -c snmpSrc | egrep "snmp.Src|name|dn|incl|minSev|monPolDn" # snmp.Src name : NMS-snmpSrc dn : uni/fabric/monfab-default/snmpsrc-NMS-snmpSrc <--- Fabric Default incl : audits,events,faults minSev : info monPolDn : uni/fabric/monfab-default # snmp.Src name : NMS-snmpSrc dn : uni/fabric/moncommon/snmpsrc-NMS-snmpSrc <--- Fabric Common incl : audits,events,faults minSev : info monPolDn : uni/fabric/moncommon # snmp.Src name : NMS-snmpSrc dn : uni/infra/moninfra-default/snmpsrc-NMS-snmpSrc <--- Access Default incl : audits,events,faults minSev : info monPolDn : uni/infra/moninfra-default
3つのいずれかが欠落している場合は、GUIを使用して、対応するモニタリングポリシーで欠落しているSNMPソースを作成します。
動作検証
show snmp summary(APIC)を使用したSNMP状態の確認
各APICで次のコマンドを直接実行して、SNMPエージェントが実行されており、設定が適用されていることを確認します。
apic1# show snmp summary
Active Policy:
default, Admin State: enabled <--- admin state must be "enabled"
Local SNMP engineID: [Hex] 0x8000000980e2b692088976c75600000000
----------------------------------------
Community Description
----------------------------------------
public SNMP Community String <--- community must be present
------------------------------------------------------------
User Authentication Privacy
------------------------------------------------------------
<--- empty if using v2c only
------------------------------------------------------------
Client-Group Mgmt-Epg Clients
------------------------------------------------------------
NMS-Clients default (In-Band) 10.1.1.50,10.1.1.51 <--- verify client IPs
------------------------------------------------------------
Host Port Version Level SecName
------------------------------------------------------------
10.1.1.50 162 v2c noauth public <--- trap destination
出力で確認する内容：
- Admin Stateは
enabledである必要があります。 - コミュニティは、NMSで使用するように設定されているものと一致している必要があります。
- Client-Groupは、正しい管理EPGを持つ、許可されたすべてのNMS IPをリストする必要があります。
- Host(trap destination)は、正しいポートとバージョンのNMSトラップレシーバをリストする必要があります。
show snmp summary（リーフ/スパイン）を使用してSNMPの状態を確認する
leaf101# show snmp summary Admin State : enabled, running (pid:8192) <--- must show "enabled, running" with a PID Local SNMP engineID: [Hex] 80000009037C69F6105BF9 ---------------------------------------------------------------------- Community Context Status ---------------------------------------------------------------------- public ok <--- community status must be "ok" ---------------------------------------------------------------------- Client VRF Status ---------------------------------------------------------------------- 10.1.1.50 mgmt:inb ok <--- client entry must be "ok" 10.1.1.51 mgmt:inb ok ------------------------------------------------------------------------------- Host Port Ver Level SecName VRF ------------------------------------------------------------------------------- 10.1.1.50 162 v2c noauth public mgmt:inb <--- trap destination
出力で確認する内容：
- Admin Stateは
enabledで、pidで実行されている必要があります。disabledと表示されている場合は、SNMPポリシーが適用されていないか、ポッドポリシーチェーンが壊れています。 - Community Statusはokである必要があります。
errorステータスは、ポリシーの導入に問題があることを示します。 - 各NMSホストのクライアントVRFは、管理EPGのVRF(インバンドの場合は
mgmt:inb、OOBの場合はmanagement)と一致している必要があります。 - トラップホストは、正しいVRFコンテキストで宛先をリストする必要があります。
snmpdプロセスが実行されていることの確認
リーフまたはスパイン：
leaf101# ps aux | grep snmp root 5881 2.5 1907404 411444 ? Ssl Apr05 /isan/bin/snmpd -f -s -d udp:161 udp6:161 tcp:161 leaf101# pidof snmpd 5881
APICで次の手順を実行します。
apic1# ps aux | grep snmp ifc 32182 1.4 0.1 641196 239716 ? Ssl Apr10 /mgmt//bin/snmpd.bin \ -f -p /tmp/snmpd2.pid -a -A -LE 0-2 -c /data//snmp/snmpd.conf
リーフまたはスパインでsnmpdプロセスが見つからない場合、SNMPはそのノードで実行されていません。SNMPポリシーの管理状態が有効になっており、ポッドポリシーチェーンが正しく設定されていることを確認します。
SNMPポートがリッスンしていることを確認する
leaf101# netstat -lutn | grep 161 Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:161 0.0.0.0:* LISTEN <--- SNMP agent is accepting requests udp 0 0 0.0.0.0:161 0.0.0.0:* udp6 0 0 :::161 :::*
ポート161がLISTEN状態にない場合は、snmpdプロセスが実行されていないか、ポートへのバインドに失敗しています。
リーフ/スパインのiptablesルールの確認
クライアントグループポリシーは、各リーフおよびスパインでiptablesルールに変換されます。ルールを検査するには、次の手順に従います。
leaf101# iptables -S | grep -i snmp -N snmp_rules -N vrf_2_snmp_rules -N vrf_9_snmp_rules -A INPUT -p udp -m udp --dport 161 -j snmp_rules <--- SNMP port 161 redirects to snmp_rules chain -A snmp_rules -m vrf --vrf 2 -j vrf_2_snmp_rules <--- VRF 2 = OOB management -A snmp_rules -m vrf --vrf 9 -j vrf_9_snmp_rules <--- VRF 9 = In-Band management -A snmp_rules -j DROP <--- default drop; only permitted clients pass -A vrf_2_snmp_rules -s 10.1.1.50/32 -j ACCEPT <--- permitted NMS client (OOB VRF) -A vrf_9_snmp_rules -s 10.1.1.50/32 -j ACCEPT <--- permitted NMS client (INB VRF)
ファブリックの正しいVRF IDを特定するには、次のコマンドを実行します。
leaf101# show vrf VRF-Name VRF-ID State Reason management 2 Up -- mgmt:inb 9 Up --
iptablesルール内のVRF IDは、show vrfレポートの内容と一致している必要があります。クライアントIPがiptablesルールにない場合、snmpdプロセスが実行されていても、そのホストからのSNMP要求は通知なしにドロップされます。
カウンタを使用して、SNMPパケットが一致またはドロップされたかどうかを確認します。
leaf101# iptables -nvL | grep -A 20 "Chain snmp_rules"
Chain snmp_rules (1 references)
pkts bytes target prot opt in out source destination
1 73 vrf_9_snmp_rules all -- * * 0.0.0.0/0 0.0.0.0/0 vrf 9
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 <--- if pkts>0 here, client IPs are missing
SNMPポートへのネットワーク接続の確認
leaf101# netstat -ai | grep eth0 Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg eth0 1500 0 501277 0 0 0 633546 0 0 0 BMRU leaf101# netstat -ai | grep kpm_inb Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg kpm_inb 9300 0 10361421 0 0 0 8958506 0 126 0 BMRU
管理インターフェイスがアクティブで（RX-ERRの増分がない）、トラフィックが通過していることを確認します。eth0はOOB管理インターフェイスで、kpm_inbはスイッチのインバンド管理インターフェイスです。
tcpdumpを使用したSNMPトラップ送信の確認
トラップが生成され、リーフ/スパインノードから送信されていることを確認するには、適切なインターフェイスでトラフィックをキャプチャします。adminとしてノードにアクセスし、次のコマンドを使用します。
leaf101# tcpdump -i kpm_inb -f port 162 -vv
tcpdump: listening on kpm_inb, link-type EN10MB (Ethernet), capture size 65535 bytes
17:21:49.810052 IP (tos 0x0, ttl 64, id 63116, proto UDP, length 218)
172.18.242.14.35582 > 10.1.1.50.snmp-trap: { SNMPv2c C=public
{ V2Trap(171) R=253 system.sysUpTime.0=5888267
S:1.1.4.1.0=E:cisco.9.276.0.1
interfaces.ifTable.ifEntry.ifIndex.436224000=436224000
interfaces.ifTable.ifEntry.ifOperStatus.436224000=2 }} <--- verify trap is being sent to NMS
OOBの場合：
leaf101# tcpdump -i eth0 -f port 162 -vv
APICトラップ(INB)の場合：
apic1# tcpdump -i bond0.1100 -f port 162 20:01:08.453473 IP apic1-inb.cisco.com.59417 > 10.1.1.50.snmptrap: C=public V2Trap(85) S: 1.1.4.1.0=E:cisco.9.117.2.0.2 E:cisco.9.117.1.1.2.1.1.10548=1 E:cisco.9.117.1.1.2.1.2.10548=2
tcpdumpを使用したSNMP GET/WALK要求の確認
leaf101# tcpdump -i kpm_inb -f port 161 -vv
17:26:08.548149 IP 10.1.1.50.64245 > leaf101.cisco.com.snmp: { SNMPv2c C=public
{ GetRequest(28) R=949769396 system.sysDescr.0 }} <--- GET request received
17:26:08.552290 IP leaf101.cisco.com.snmp > 10.1.1.50.64245: { SNMPv2c C=public
{ GetResponse(191) R=949769396
system.sysDescr.0="Cisco NX-OS(tm) aci, Software (aci-n9000-system), \
Version 15.0(1k), RELEASE SOFTWARE" }} <--- response returned; SNMP working
GetRequestは表示されるがGetResponseが表示されない場合、要求は受信されているが応答がない。snmpdプロセスとコミュニティストリングを確認します。要求も応答もない場合は、ノードに到達する前に要求がブロックされています（ルーティングとiptablesを確認してください）。
トラブルシューティングワークフロー
トリアージ決定ツリー
エンジニアがSNMPが動作していないと報告した場合に、このDecision Treeを使用します。観察された症状から始めて、ブランチに従って分離します。
症状：SNMP GET/WALK要求に応答がありません
- APICのSNMP管理状態を確認します。
moquery -c snmpPolを実行します。adminStがdisabledになっている場合は、イネーブルにしてステップ7に進みます。 - snmpdプロセスを確認します。影響を受けるノードで、
ps aux | grep snmpまたはpidof snmpdを実行します。実行中のプロセスがない場合、SNMPポリシーは展開されません。ポッドポリシーチェーン(SNMPポリシー→ポッドポリシーグループ→ポッドプロファイル)を確認します。 - ポート161がリッスンしていることを確認します。
netstat -lutn | grep 161を実行します。ポート161がLISTEN状態でない場合は、snmpdプロセスが失敗しています。/var/log/dme/log/svc_ifc_dbgrelem.log*からログを収集して、プロセスを再起動します。 - ルーティングをチェックします。
show ip route vrf managementおよびshow ip route vrf mgmt:inbを実行します。NMSホストへのルートが正しいVRFに存在することを確認します。 - APICの管理契約を確認します。ターゲットがAPIC（リーフ/スパインではない）の場合、OOBまたはINB管理コントラクトでUDP 161が許可されていることを確認します。
- ノードでtcpdumpを実行します。
tcpdump -i kpm_inb -f port 161 -vv(またはOOBの場合はeth0)を実行します。 GetRequestが表示されてもGetResponseが続かない場合、要求はノードに到達しますが、snmpd is not responding – コミュニティストリングを確認します。要求がまったく表示されない場合は、アップストリーム（ルーティングまたはコントラクト）に問題があります。 - 許可されたクライアントからテストします。クライアントグループにリストされているNMSホストから
snmpget -v2c -c [community] [node-ip] SNMPv2-MIB::sysDescr.0を実行します。正常な応答により、SNMPが完全に動作していることが確認されます。
症状：NMSでSNMPトラップが受信されない
- トラップ送信先の設定を確認します。
moquery -c snmpTrapDestを実行します。NMSのIP、ポート、バージョン、およびコミュニティが、NMSの期待値と一致していることを確認します。 - モニタリングソースが3つのスコープすべてに存在することを確認します。
moquery -c snmpSrc | egrep "snmp.Src|name|dn"を実行します。 エントリが、uni/fabric/monfab-default、uni/fabric/moncommon、およびuni/infra/moninfra-defaultのmonPolDn値とともに存在することを確認します。欠落している場合は、対応するモニタリングポリシーにSNMPソースを追加します。 - snmpdプロセスを確認します。トラップを送信するノードでsnmpdが実行されていることを確認します。
- テストイベントを生成し、tcpdumpを使用してキャプチャします。インターフェイスをフラップするか、状態を変更してイベントを生成する。ノードで、
tcpdump -i kpm_inb -f port 162 -vvを実行します。トラップトラフィックがネットワークに表示されない場合、イベントはトラップを生成していません。incl属性を再確認してモニタリングします(faultsまたはeventsを含める必要があります)。 - トラップレシーバへの接続をチェックします。管理VRFからトラップレシーバに到達可能であることを確認します。
show ip route vrf mgmt:inbを実行すると、NMSホストへのパスが表示されます。 - トラップがtcpdumpに表示されてもNMSに表示されない場合、問題はネットワーク側（ファイアウォール、ルーティング、またはNMS設定）にあります。NMSがACIノードの管理ソースIPからUDP 162をリッスンしていることを確認します。
一般的なシナリオ
シナリオ1:SNMPポリシーは有効になっているが、リーフ/スパインからデータが返されない
問題：APICのSNMPポリシーに「Admin State enabled」と表示されます。NMSはリーフの管理IPに到達できます。snmpgetは応答なしでタイムアウトします。
設定確認：ポッドポリシーグループがSNMPポリシーを参照し、解決されたSNMPポリシーが正しい名前を示していることを確認します。ポッドポリシーグループのSNMPポリシーフィールドが空であるか、関係が形成されていない場合、スイッチでsnmpdプロセスが開始されない可能性があります。
動作確認：影響を受けるリーフにSSHで接続し、show snmp summaryを実行します。APICでenabledと表示されていても出力にAdmin State: disabledと表示される場合、ポリシーは展開されていません。ポッドポリシーチェーンで、ポッドポリシーグループが欠落しているか、正しく参照されていないかを確認します。
根本原因： SNMPポリシーがポッドポリシーグループにリンクされていないか、ポッドプロファイルセレクタが正しいポッドポリシーグループをこのポッドに適用していません。
ソリューション：
- Fabric > Fabric Policies > Pods > Policy Groups > defaultの順に移動します。
- SNMP Policyフィールドに、有効になっているSNMPポリシーが示されていることを確認します。
- Fabric > Fabric Policies > Pods > Profilesの順に移動し、アクティブなセレクタがこのポッドポリシーグループを参照していることを確認します。
- 保存後、2分以内にリーフの
show snmp summaryを再確認してください。
シナリオ2:SNMP GET/WALKが一部のNMSホストでは機能するが、他のホストでは機能しない
問題：1台のNMSサーバがACIノードを正常にポーリングできる。異なるサブネット上の2番目のNMSサーバは応答を受け取りません。
設定チェック：APICでmoquery -c snmpClientGrpP -x query-target=childrenを実行します。2番目のNMSサーバのIPがクライアントエントリとしてリストされていることを確認します。欠落している場合、そのIPはsnmp_rulesチェーンの最後にあるiptables DROPルールによってブロックされます。
動作確認：該当するリーフで、OOBまたはINB管理コントラクトでUDP 161が許可されていることを確認します。SNMPポートを持つコントラクトまたはフィルタがない場合、要求はドロップされます。
根本原因：2番目のNMSサーバのIPがクライアントグループポリシーに含まれていません。
解決策：SNMPクライアントグループポリシーのFabric > Fabric Policies > Policies > Pod > SNMP > default > Client Group Policiesの下に、欠落しているNMS IPをクライアントエントリとして追加します。すべてのノードのiptablesルールは、ポリシーの保存後数分以内に更新されます。
シナリオ3:SNMPトラップが受信されない – トラップは生成されるが配信されない
問題： APIC障害テーブルに障害が表示されます。moquery -c snmpTrapDestは正しいNMS IPを示します。NMSはトラップを受信しません。
設定チェック：moquery -c snmpSrc | egrep "snmp.Src|name|dn"を実行します。 モニタリングソースが3つのスコープ(monfab-default、moncommon、moninfra-default)すべてに存在することを確認します。 よくある見落としとしては、送信元をFabric Defaultポリシーだけで設定し、アクセスポリシーイベントが失われることです。
動作確認：テストイベントをトリガーします（インターフェイスをadmin-down状態に切り替えるなど）。 該当するノードで、tcpdump -i kpm_inb -f port 162を実行します。トラップパケットがノードのインターフェイスに表示される場合、ACI側は機能しており、問題はNMSへのネットワークパス（ファイアウォール、ルーティング）にあります。 トラップがワイヤに表示されない場合、ACIモニタリングソースが欠落しているか、またはイベントタイプがソースのincl属性に含まれていません。
根本的な原因1:必要なスコープに1つ以上の監視ソースがありません。
根本原因2:送信元のincl属性を監視すると、生成されるイベントタイプが除外されます(例：incl:events without faultsは、障害ベースのトラップが送信されないことを意味します)。
ソリューション：
- GUIで、3つのスコープ(Fabric Default、Fabric Common、Access Default)のそれぞれに不足しているモニタリングソースを追加します。 宛先グループを、設定したSNMP宛先グループに設定します。
incl属性に包括的なトラップカバレッジの監査、イベント、障害が含まれていることを確認します。- 変更後、テストイベントを再トリガーし、tcpdumpを再確認します。
シナリオ4:APICでSNMPv3クライアントグループの適用が機能しない
問題：クライアントグループポリシーに含まれていないSNMPクライアントは、リーフ/スパインノードで同じクエリが失敗した場合でも、SNMPv3を使用してAPICに正常にクエリできます。
根本原因：これは既知の警告です。クライアントグループポリシー（iptablesベースのソースIPの適用）は、SNMPv3 GETs/WalksからAPICコントローラには適用されません。すべてのホストは、クライアントグループの設定に関係なく、SNMPv3経由でAPICに照会できます。リーフスイッチとスパインスイッチでは、クライアントグループの強制はSNMPv2cとSNMPv3で同じように機能します。
緩和策：APICで管理コントラクトフィルタを使用して、発信元サブネットごとにSNMPアクセスを制限します。クライアントグループは、リーフ/スパインノードに対して有効です。SNMPv3を使用するAPICでは、アクセス制御メカニズムとして管理契約のソースベースのフィルタリングに依存します。
シナリオ5:SNMPクエリは成功するが、MIBデータが不完全または古い
問題：SNMP GET/WALKがデータを返しますが、特定のMIB OIDが空または古い値を返します。特に、インターフェイスの統計情報や動作状態のデータには、現在のファブリックの状態は反映されません。
動作チェック：どのAPICが照会されているかを確認します。各APICは、ローカルのデータのMIBオブジェクトのみを返します。照会されるAPICでshow snmp summaryを実行し、その結果を予想される結果と比較します。スイッチレベルのデータ(IF-MIB、entityMIB)については、APICではなく、スイッチに直接クエリーを実行します。
根本原因：リーフレベルMIBデータのAPICへのクエリ。各APICは、独自の管理オブジェクトに対してのみMIBオブジェクトを提供します。スイッチレベルのデータ（インターフェイス統計情報、CPU、メモリ、環境センサー）は、リーフ/スパインごとに直接ポーリングして取得する必要があります。
解決策：インターフェイスおよびハードウェアMIBデータに対してリーフ/スパイン管理IPを直接ポーリングするようにNMSを設定します。APIC管理IPは、APICネイティブMIB（エンティティ、FRU、プロセス、APICサーバハードウェアに関連するセンサー）にのみ使用します。
シナリオ6:SNMPがリーフ/スパインに対して機能するが、APICに対しては機能しない
問題：NMSからリーフ/スパイン型ノードへのSNMPv2c GETが成功する。同じNMSはAPICをポーリングできません。
設定チェック：APIC SNMPには、UDP 161を許可する明示的な管理契約が必要です。Tenants > mgmtに移動し、OOB/INBコントラクトとUDP 161のフィルタを確認します。
動作確認：APICで、iptables -S | grep 161を実行します。UDP 161のACCEPTルールがfp-137（または同等のOOBコントラクト）チェーンの下に表示されない場合、UDP 161のコントラクトフィルタが存在しないか、展開されていません。
apic1# iptables -S | grep 161
-A fp-137 -s 10.0.0.0/8 -p udp -m udp --dport 161 -j ACCEPT <--- permit SNMP from the management subnet
-A fp-137 -s 172.18.0.0/16 -p udp -m udp --dport 161 -j ACCEPT <--- permit SNMP from INB management subnet
これらのルールが存在しない場合は、UDP 161のフィルタエントリを管理契約の件名に追加し、再検証します。
根本的な原因：管理コントラクトが見つからないか、正しく設定されていません。ACI 5.xでは、APICノードは管理契約を厳密に適用します。明示的な許可が存在しない限り、SNMPパケットはドロップされます。
ソリューション：
- Tenants > mgmt > Security Policies > Out-Of-Band Contractsの順に移動します。
- OOBコントラクトを展開し、Subjectを選択して、UDPポート161のフィルタを確認および追加します。
- NMSがINB管理を介してAPICに到達する場合は、インバンド契約に対して手順を繰り返します。
- 保存後、APICで
iptables -S | grep 161を使用して確認します。
シナリオ7:SNMP iptablesルールがないか正しくない
問題：show snmp summaryを実行すると、SNMPポリシーは適用されているが、iptables -S | grep snmpによってルールが返されないか、NMSクライアントのIPがルールに含まれていない。
動作確認：pidof snmpdを使用してsnmpdが実行されていることを確認します。snmpdが実行されているが、iptablesにSNMPルールがない場合、クライアントのグループポリシーが展開される前にプロセスが開始されています。再起動の数が250未満の場合にsnmpdを再起動して、ルールの再プログラミングを強制します。
leaf101# pidof snmpd
5881
leaf101# show system internal sysmgr service name snmpd
Service "snmpd" ("snmpd", 127):
UUID = 0x1A, PID = 5881, SAP = 1545
State: SRV_STATE_HANDSHAKED (entered at time Mon Aug 25 19:23:50 2025).
Restart count: 3
Time of last restart: Mon Aug 25 19:23:48 2025.
Previous PID: 32080
Reason of last termination: SYSMGR_DEATH_REASON_FAILURE_SIGNAL
Tag = N/A
Plugin ID: 0
leaf101# kill -9 5881
ACIプロセスマネージャが自動的にsnmpdを再起動します。再起動後、次のことを確認します。
leaf101# iptables -S | grep -i snmp
これで、snmp_rulesチェーンとVRFごとのクライアントACCEPTルールが表示されるようになります。
根本的な原因：クライアントのグループポリシーがノードに完全に展開される前にsnmpdプロセスが再起動または開始されたため、SNMPアクセスルールが設定されていないiptablesが残っています。
詳細なトラブルシューティングのためのログファイル
上記の検証手順で問題が解決しない場合、リーフ、スパイン、およびAPICノードの次のログファイルに、SNMP関連の診断情報が記録されます。
leaf101# zgrep "snmp" /var/log/dme/log/svc_ifc_dbgrelem.log*
leaf101# zgrep "snmpd" /var/log/dme/log/svc_ifc_dbgrelem.log*
leaf101# zgrep "snmpd_log" /var/log/dme/log/*
これらのログには、snmpd再起動イベント、ポリシー展開イベント、およびshow snmp summaryでは確認できないコミュニティ/クライアント設定エラーが含まれています。
参照資料
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
1.0 |
21-Apr-2026
|
初版 |
フィードバック