Risoluzione dei problemi relativi al protocollo SNMP in Cisco ACI Fabric

Introduzione

In questo documento viene descritto come configurare, verificare e risolvere i problemi di SNMP in Cisco ACI per ACI release 5.x e successive. Il documento descrive il modello di regole SNMP, i contratti di gestione richiesti, la configurazione trap, la verifica operativa tramite query CLI e MO (Managed Object) e i flussi di lavoro per la risoluzione strutturata dei problemi relativi agli scenari di errore più comuni tra switch foglia/spine e controller APIC.

Premesse

Il materiale illustrato in questo documento viene tratto dalla nota tecnica interna SNMP del Cisco ACI Solutions Delivery Team in ACI: Panoramica, configurazione, risoluzione dei problemi e avvertenze/problemi scritti da Tomas de Leon, integrati dalla Cisco APIC System Management Configuration Guide (versione 5.x) e dalla Cisco ACI MIB Quick Reference Guide.

Panoramica

Architettura SNMP in ACI

SNMP (Simple Network Management Protocol) è un protocollo basato su UDP che gestisce la gestione e il monitoraggio della rete. In ACI, il protocollo SNMP funziona in modo indipendente su ciascuna entità gestita. Ogni switch foglia, switch spine e controller APIC è il proprio agente SNMP; è necessario eseguire il polling o il monitoraggio di ciascuno in modo indipendente.

ACI supporta le seguenti funzionalità SNMP:

• Operazioni di lettura (Get, GetNext, BulkGet, Walk) — supportate su switch foglia/dorso e controller APIC.
• Notifiche (Trap): trap SNMPv1, v2c e v3 supportate su switch foglia/dorso e controller APIC.
• SNMPv3: supportato su switch foglia/dorso e controller APIC.
• Operazioni di scrittura (Set) - NON supportate su nessun dispositivo ACI.
• IPv6: SNMP è supportato solo su IPv4.

Nota: In un cluster APIC, ogni APIC fornisce oggetti MIB locali a se stesso. Il polling di ciascun APIC deve essere eseguito in modo indipendente; nessuna aggregazione SNMP a livello di cluster. Analogamente, ciascun interruttore a foglia e dorso deve essere interrogato in modo indipendente.

Architettura SNMPD sull'APIC

L'APIC esegue il processo snmpd, che ha due componenti interni:

• Agent: un agente net-snmp open-source (versione 5.7.6 o successive) che gestisce l'elaborazione del protocollo SNMP e la gestione delle sessioni.
• DME (Data Model Engine): si interfaccia con l'MIT (Management Information Tree) APIC per leggere oggetti gestiti e convertire gli attributi MO in formato oggetto SNMP. Le trap SNMP vengono generate da eventi e guasti generati sui dischi magneto-ottici.

Modello di policy SNMP e catena di distribuzione

ACI utilizza un modello basato su regole per SNMP. La configurazione SNMP viene astratta come un oggetto gestito snmpPol e deve essere associata al gruppo di criteri POD dell'infrastruttura prima di essere distribuita in qualsiasi nodo. La catena di distribuzione completa è:

1. SNMP Policy (snmpPol): definisce lo stato di amministrazione, le stringhe della community, i criteri di gruppo dei client (ACL) e gli utenti SNMPv3.
2. Pod Policy Group: fa riferimento alla policy SNMP insieme ad altre policy a livello di pod (BGP, ISIS, NTP, ecc.).
3. Pod Profile Selector — applica il Pod Policy Group ai pod fabric.

Inoltre, la configurazione delle trap SNMP richiede:

1. SNMP Monitoring Destination Group (snmpGroup): definisce gli host di destinazione delle trap, la porta, la versione SNMP e la community.
2. Origini di monitoraggio (snmpSrc): collegare il gruppo di destinazione a tre ambiti di criteri di monitoraggio distinti: Predefinito fabric, Criterio comune fabric e Predefinito criterio di accesso.

Per i nodi APIC sono richiesti contratti di gestione che consentano l'uso della porta UDP 161 (richieste SNMP) e della porta UDP 162 (trap SNMP). I nodi foglia e spine richiedono inoltre regole iptables corrette, che vengono programmate automaticamente quando vengono configurati Criteri di gruppo client.

MIB supportati

I MIB supportati su APIC includono:

• Entità MIB — PhysicalTable
• Cisco Entity Ext MIB - PhysicalProcessorTable, tabella LEDT
• MIB controllo FRU entità Cisco: PowerSupplyGroupTable, PowerStatusTable, FanTrayStatusTable, PhysicalTable
• MIB sensore entità Cisco: SensorValueTable, SensorThresholdTable
• MIB processo Cisco: CPUTotalTable, ProcessTable, ProcessExtRevTable, ThreadTable

Gli switch foglia e spine espongono i MIB NX-OS standard, tra cui IF-MIB, IP-MIB, CISCO-CDP-MIB, CISCO-ENTITY-QFP-MIB e la suite completa CISCO-ENTITY-FRU-CONTROL-MIB.

Le trap SNMP generate sull'APIC includono: cefcFRUInserted, cefcFRURemoved, cefcFanTrayStatusChange, cefcModuleStatusChange, entSensorThresholdNotification, cefcPowerStatusChange, cpmCPURisingThreshold, cpmCPUFallingThreshold.

Configurazione di SNMP in ACI

Nota: In questa sezione viene fornito un riepilogo del flusso di lavoro di configurazione come contesto per le sezioni di verifica e risoluzione dei problemi riportate di seguito. Per procedure di configurazione complete, consultare la guida alla configurazione di Cisco APIC System Management.

Passaggio 1: Configurare il criterio SNMP

Selezionare Fabric > Fabric Policies > Policies > Pod > SNMP. Selezionare (o creare) il criterio SNMP, in genere denominato default. Configurazione:

• Stato amministrazione — impostato su Abilitato.
• Criteri di community — aggiungere la stringa della community utilizzata dal proprio NMS.
• Criteri gruppo client: definire uno o più profili di gruppo client, ciascuno dei quali specifica gli IP client SNMP consentiti e la gestione associata EPG (Out-of-Band o In-Band).
• Utenti SNMPv3: se si utilizza SNMPv3, aggiungere qui gli utenti con i parametri di autenticazione e privacy.

Passaggio 2: Associare i criteri SNMP al gruppo di criteri POD

Passare a Fabric > Fabric Policies > Pods > Policy Groups (Infrastruttura > Criteri fabric > Pod > Gruppi di criteri). Selezionare il gruppo di criteri POD attivo (in genere denominato predefinito). Impostare il campo Criteri SNMP in modo che punti al criterio SNMP creato nel passaggio 1. Verificare che il campo Criteri SNMP risolti visualizzi il nome corretto del criterio.

Quindi, selezionare Fabric > Fabric Policies > Pods > Profiles (Infrastruttura > Criteri fabric > Profilati), espandere il profilo predefinito del pod e verificare che il selettore attivo faccia riferimento al gruppo di criteri del pod corretto.

Passaggio 3: Configura contratti di gestione per la porta UDP 161

Passare a Tenant > Gestione > Contratti > Contratti fuori banda. Verificare che l'oggetto del contratto OOB attivo faccia riferimento a una voce di filtro che consente la porta UDP 161 (richieste SNMP). Senza questo contratto sull'APIC, tutti i pacchetti GET/WALK SNMP verranno eliminati automaticamente.

Le voci di filtro associate all'oggetto del contratto devono includere una voce con EtherType IP, Protocol UDP e Destination Port 161. L'esempio precedente mostra un filtro allow-all (unspecified protocol): consente l'uso del protocollo SNMP ma è più ampio di quello consigliato per la produzione. È preferibile una voce di filtro SNMP dedicata con voci UDP/161 e UDP/162 specifiche.

Nota: Nelle versioni precedenti del firmware ACI, alcune porte erano sempre aperte su nodi foglia e dorso e non era necessario un contratto di gestione per SNMP. In ACI 5.x, il contratto è obbligatorio per i nodi APIC. I nodi foglia e colonna vertebrale utilizzano le regole iptable derivate dai Criteri di gruppo del client anziché i contratti di gestione.

Passaggio 4: Configurazione delle destinazioni delle trap SNMP

Selezionare Admin > External Data Collectors > Monitoring Destinations > SNMP (Amministratore > Raccoglitori di dati esterni > Destinazioni di controllo > SNMP). Fare clic con il pulsante destro del mouse e selezionare Crea gruppo di destinazione di monitoraggio SNMP. La scheda SNMP mostra tutti i gruppi di destinazione configurati. Una tabella vuota indica che non è stata ancora configurata alcuna destinazione di trap.

Definisci:

• Nome gruppo
• Destinazioni trap: hostname/IP, porta UDP (predefinito: 162), versione SNMP, stringa della community e gestione EPG

Passaggio 5: Configura origini di monitoraggio

Le origini di monitoraggio collegano il gruppo di destinazione SNMP ai criteri di monitoraggio che controllano quali eventi e errori generano le trap. È necessario configurare un'origine di monitoraggio in tutti e tre i percorsi seguenti, altrimenti le trap da alcuni tipi di nodi non verranno inviate:

• Fabric > Fabric Policies > Policies > Monitoring > default > Callhome/Smart Callhome/SNMP/Syslog/TACACS (copre gli eventi dell'infrastruttura fabric)
• Fabric > Fabric Policies > Policies > Monitoring > Common Policy > Callhome/Smart Callhome/SNMP/Syslog/TACACS (copre gli eventi comuni a livello di fabric)
• Fabric > Criteri di accesso > Criteri > Monitoraggio > predefinito > Callhome/Smart Callhome/SNMP/Syslog (copre gli eventi di accesso/infrastruttura)

In ciascuna posizione, selezionare SNMP come tipo di origine e creare una nuova origine SNMP facendo riferimento al gruppo di destinazione creato nel passaggio 4.

Verifica della configurazione

Verifica della distribuzione dei criteri SNMP

Passare a Fabric > Fabric Policies > Policies > Pod > SNMP e verificare che il criterio SNMP predefinito esista e che il relativo stato Admin sia impostato su Enabled. L'elenco Gruppi di criteri mostra a colpo d'occhio tutti i criteri SNMP configurati con il relativo stato di amministrazione.

Per una verifica dettagliata, fare clic sul nome del criterio per aprirlo. Confermare che l'opzione Admin State sia impostata su Enabled (Abilitata) e che in Client Group Policies (Criteri di gruppo client) siano elencati tutti gli host NMS autorizzati con il rispettivo EPG di gestione associato.

Eseguire la seguente query MO su qualsiasi APIC per verificare che il criterio SNMP sia presente e abilitato nell'infrastruttura:

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

Se adminSet è disabilitato, il protocollo SNMP non funzionerà su alcun nodo. Abilitarlo nella GUI APIC in Fabric > Fabric Policies > Policies > Pod > SNMP > default (Fabric > Criteri fabric > Criteri > Pod > SNMP > Predefinito).

Verifica della configurazione delle stringhe della community

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

Se non viene restituita alcuna community o il nome non corrisponde a quello utilizzato dal servizio NMS, aggiungere o correggere la stringa della community nel criterio SNMP.

Verifica dei criteri di gruppo del client (controllo di accesso SNMP)

I Criteri di gruppo client funzionano come ACL per l'accesso GET/WALK SNMP. Ogni criterio specifica gli indirizzi IP dei client autorizzati a eseguire il polling dei nodi foglia/spine su cui viene eseguito il VRF di gestione. Sui nodi foglia/dorso, questi criteri vengono convertiti in regole 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

Verificare che l'indirizzo IP del server NMS sia presente nelle voci client. Se manca un IP client, le richieste GET/WALK SNMP da tale host verranno eliminate dalle iptable sui nodi foglia/spine.

Nota: Avvertenza SNMPv3: i criteri di gruppo client non vengono applicati all'APIC quando si utilizza SNMPv3. Qualsiasi GET/WALK SNMPv3 a un APIC è consentito indipendentemente dalla configurazione del gruppo client. L'imposizione del gruppo client per SNMPv3 sull'APIC è una limitazione nota. Sugli switch foglia e dorso, l'imposizione dei gruppi di client funziona allo stesso modo sia per SNMPv2c che per SNMPv3.

Verifica dei riferimenti al gruppo di criteri POD per i criteri SNMP

Passare a Fabric > Fabric Policies > Pods > Policy Groups (Infrastruttura > Criteri fabric > Pod > Gruppi di criteri) e aprire il gruppo di criteri per i pod attivo. Verificare che il campo a discesa Criterio SNMP sia impostato sul criterio SNMP desiderato e che il campo Criterio SNMP risolto abbia lo stesso nome. Un criterio mancante o non risolto indica che la configurazione SNMP non viene mai sottoposta a PUSH sugli switch.

Nello screenshot precedente, il campo Criterio SNMP mostra "select a value" (vuoto), mentre il criterio SNMP risolto mostra "default". Ciò significa che il criterio è ereditato dal valore predefinito della struttura, ma non è impostato in modo esplicito. Per evitare ambiguità, si consiglia di impostare in modo esplicito il campo Criteri SNMP.

Verifica tramite API REST:

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"

Se lo stato non è formato, la relazione tra i criteri SNMP viene interrotta. Selezionare nuovamente il criterio SNMP nel gruppo di criteri POD e inviarlo.

Verifica del contratto di gestione per UDP 161 (nodi APIC)

Passare a Tenant > Gestione > Contratti > Contratti fuori banda (e Contratti in banda se si utilizza la gestione INB). Aprire il contratto Fuori sede attivo e fare clic sulla scheda Criterio. Verificare che l'oggetto faccia riferimento a un filtro che consente la porta UDP 161.

Espandere il filtro al quale fa riferimento il soggetto e confermare le voci includendo una voce con EtherType IP, Protocol UDP, Destination Port 161. Le voci del filtro determinano il traffico autorizzato attraverso il contratto di gestione OOB verso l'APIC.

Il filtro dovrebbe mostrare:

• EtherType: IP
• Protocollo IP: UDP
• Porta di destinazione da: 161
• Porta di destinazione: 161

Verificare inoltre che la porta UDP 162 sia consentita se si desidera che l'APIC invii trap SNMP in uscita tramite l'interfaccia OOB.

Verifica tramite query 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

Se non viene restituito alcun risultato, non esiste alcun filtro per UDP 161. Aggiungerne uno al contratto di gestione.

Verifica della configurazione della destinazione delle trap SNMP

Passare a Admin > External Data Collector > Monitoring Destinations > SNMP per visualizzare tutti i gruppi di destinazione SNMP configurati. Un elenco vuoto indica che non sono configurate destinazioni di trap e che non verranno inviate trap da alcun nodo.

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

Verificare che l'indirizzo IP, la porta, la versione, la stringa della community e il file VRF di gestione della destinazione della trap (mgmt:inb o management for OOB) corrispondano all'ambiente. Il VRF deve corrispondere all'EPG di gestione assegnato alla destinazione.

Verifica della configurazione delle origini di monitoraggio in tutti e tre gli ambiti

Le origini SNMP devono esistere in tutti e tre gli ambiti dei criteri di monitoraggio. Se in un ambito manca un'origine, le trap dagli eventi correlati non verranno inoltrate.

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

Se manca una delle tre, creare l'origine SNMP mancante nel criterio di monitoraggio corrispondente utilizzando la GUI.

Verifica operativa

Verifica dello stato SNMP tramite il comando show snmp summary (APIC)

Eseguire questo comando direttamente su ciascuna APIC per verificare che l'agente SNMP sia in esecuzione e che la configurazione sia stata applicata:

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

Cosa verificare nell'output:

• Lo stato dell'amministratore deve essere abilitato.
• La community deve corrispondere all'NMS configurato per l'utilizzo.
• Il gruppo client deve elencare tutti gli IP NMS consentiti con EPG di gestione corretto.
• L'host (destinazione trap) deve elencare il ricevitore trap NMS con la porta e la versione corrette.

Verifica dello stato SNMP tramite il riepilogo show snmp (foglia/dorso)

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

Cosa verificare nell'output:

• Lo stato dell'amministratore deve essere abilitato, in esecuzione con un PID. Se viene visualizzato disabled (disabilitato), il criterio SNMP non viene applicato o la catena di criteri del pod viene interrotta.
• Lo stato della community deve essere corretto. Lo stato di errore indica un problema di distribuzione dei criteri.
• Il VRF del client per ciascun host NMS deve corrispondere al VRF dell'EPG di gestione (mgmt:inb per In-Band, gestione per OOB).
• L'host trap deve elencare la destinazione con il contesto VRF corretto.

Verificare che il processo snmpd sia in esecuzione

Su una foglia o sul dorso:

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

Nell'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

Se non viene trovato alcun processo snmpd su una foglia o su un dorso, il protocollo SNMP non è in esecuzione su tale nodo. Verificare che lo stato di amministrazione del criterio SNMP sia abilitato e che la catena di criteri del pod sia configurata correttamente.

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           :::*

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)

leaf101# show vrf
VRF-Name                VRF-ID  State   Reason
management              2       Up      --
mgmt:inb                9       Up      --

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

Verifica della connettività di rete alle porte 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

Verificare che le interfacce di gestione siano attive (senza incrementi di RX-ERR) e che il traffico sia in transito. eth0 è l'interfaccia di gestione OOB; kpm_inb è l'interfaccia di gestione in-band dello switch.

Verifica dell'invio di trap SNMP con tcpdump

Per verificare che le trap vengano generate e inviate da un nodo foglia o da una direttrice, acquisire il traffico sull'interfaccia appropriata. Accedere al nodo come admin e utilizzare:

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

Per OOB:

leaf101# tcpdump -i eth0 -f port 162 -vv

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

Verifica delle richieste GET/WALK SNMP con tcpdump

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

Se viene visualizzato GetRequest ma non GetResponse, la richiesta verrà ricevuta ma non riceverà risposta. Controllare il processo snmpd e la stringa della community. Se non vengono visualizzate né la richiesta né la risposta, la richiesta viene bloccata prima di raggiungere il nodo (verificare routing e iptables).

Flusso di lavoro di risoluzione dei problemi

Struttura decisionale Triage

Utilizzare questo albero decisionale quando i tecnici segnalano che il protocollo SNMP non funziona. Iniziare dal sintomo osservato e seguire i rami fino all'isolamento.

Sintomo: Nessuna risposta alle richieste GET/WALK SNMP

1. Controllare lo stato di amministrazione di SNMP su APIC. Eseguire moquery -c snmpPol. Se adminSet è disabilitato, abilitarlo e procedere al Passaggio 7.
2. Controllare il processo snmpd. Sul nodo interessato, eseguire ps aux | grep snmp o pidof snmpd. Se non è in esecuzione alcun processo, il criterio SNMP non viene distribuito. Verificare la catena di criteri pod (Criteri SNMP → Gruppo di criteri POD → Profilo POD).
3. Verificare che la porta 161 sia in ascolto. Esegui netstat -lutn | grep 161. Se la porta 161 non è in stato LISTEN, il processo snmpd non è riuscito; raccogliere i log da /var/log/dme/log/svc_ifc_dbgrelem.log* e riavviare il processo.
4. Controllare il routing. Eseguire show ip route vrf management e show ip route vrf mgmt:inb. Verificare che esista un percorso verso l'host NMS nel VRF corretto.
5. Controllare il contratto di gestione su APIC. Se la destinazione è un APIC (non una foglia o un dorso), verificare che nel contratto di gestione OOB o INB sia consentito l'UDP 161. 
6. Eseguire tcpdump sul nodo. Eseguire tcpdump -i kpm_inb -f port 161 -v (o eth0 per OOB). Se viene visualizzato GetRequest ma non GetResponse, la richiesta raggiunge il nodo ma snmpd non risponde — controllare la stringa della community. Se non viene visualizzata alcuna richiesta, il problema è a monte (routing o contratto).
7. Test da un client autorizzato. Eseguire snmpget -v2c -c [community] [node-ip] SNMPv2-MIB::sysDescr.0 da un host NMS elencato nel gruppo client. Una risposta positiva conferma che il protocollo SNMP è pienamente operativo.

Sintomo: Nessun trap SNMP ricevuto sul sistema NMS

1. Controllare la configurazione della destinazione trap. Eseguire moquery -c snmpTrapDest. Confermare che l'indirizzo IP, la porta, la versione e la community del server dei nomi corrispondano ai valori previsti dal server dei nomi.
2. Verificare che le origini di monitoraggio siano presenti in tutti e tre gli ambiti. Esegui moquery -c snmpSrc | egrep "snmp.Src|name|dn". Confermare l'esistenza di voci con valori monPolDn per uni/fabric/monfab-default, uni/fabric/moncommon e uni/infra/moninfra-default. Se mancano alcune, aggiungere l'origine SNMP nel criterio di monitoraggio corrispondente.
3. Controllare il processo snmpd. Verificare che snmpd sia in esecuzione nel nodo che deve inviare la trap.
4. Generare un evento di test e acquisirlo con tcpdump. Inversione di un'interfaccia o modifica di uno stato per generare un evento. Sul nodo, eseguire tcpdump -i kpm_inb -f port 162 -v. Se sul cavo non viene visualizzato traffico di trap, l'evento non genera una trap - ricontrolla origine di monitoraggio con attributo (deve includere errori o eventi).
5. Controllare la connettività al ricevitore trap. Verificare che il ricevitore trap sia raggiungibile dal VRF di gestione: show ip route vrf mgmt:inb deve visualizzare un percorso all'host NMS.
6. Se i trap vengono visualizzati su tcpdump ma non su NMS, il problema è relativo alla rete: firewall, routing o configurazione NMS. Verificare che il sistema NMS sia in ascolto su UDP 162 dall'indirizzo IP di origine della gestione del nodo ACI.

Scenari comuni

Scenario 1: Criterio SNMP abilitato ma nessun dato restituito da foglia/dorso

Problema: Nel criterio SNMP sull'APIC è indicato che lo stato dell'amministratore è abilitato. L'NMS può raggiungere l'IP di gestione della foglia. snmpget timeout senza risposta.

Controllo configurazione: Verificare che il gruppo di criteri POD faccia riferimento al criterio SNMP e che il criterio SNMP risolto visualizzi il nome corretto. Se il campo Criteri SNMP del gruppo di criteri POD è vuoto o la relazione non è formata, il processo snmpd potrebbe non avviarsi sugli switch.

Controllo operativo: SSH sulla foglia interessata ed eseguire show snmp summary. Se nell'output viene visualizzato Admin State: disattivato anche se l'APIC è attivato, il criterio non è stato distribuito. Verificare se nella catena di criteri del pod è presente un gruppo di criteri del pod mancante o a cui si fa riferimento in modo errato.

Causa principale: Il criterio SNMP non è collegato al gruppo di criteri per i pod oppure il selettore del profilo di pod non applica il gruppo di criteri per i pod corretto a questo pod.

Soluzione:

1. Passare a Fabric > Fabric Policies > Pods > Policy Groups > default (Fabric > Criteri fabric > Pod > Gruppi di criteri > predefiniti).
2. Verificare che il campo Criteri SNMP punti al criterio SNMP abilitato.
3. Passare a Fabric > Fabric Policies > Pods > Profiles e confermare il selettore attivo che fa riferimento a questo Pod Policy Group.
4. Dopo il salvataggio, ricontrollare show snmp summary sulla foglia entro 2 minuti.

Scenario 2: SNMP GET/WALK funziona per alcuni host NMS ma non per altri

Problema: Un server NMS può eseguire correttamente il polling dei nodi ACI. Un secondo server NMS in una subnet diversa non riceve alcuna risposta.

Controllo configurazione: Eseguire moquery -c snmpClientGrpP -x query-target=children su APIC. Verificare che l'indirizzo IP del secondo server NMS sia elencato come voce client. Se manca, l'IP verrà bloccato dalla regola iptables DROP nella parte inferiore della catena snmp_rules.

Controllo operativo: sull'elemento foglia interessato, confermare che l'UDP 161 è consentito nel contratto di gestione OOB o INB. Se nessun contratto o filtro dispone di porte SNMP, la richiesta viene eliminata.

Causa principale: Il secondo indirizzo IP del server NMS non è incluso nei Criteri di gruppo del client.

Soluzione: Aggiungere l'indirizzo IP NMS mancante come voce client in Criteri di gruppo client SNMP in Fabric > Criteri fabric > Criteri > Pod > SNMP > predefinito > Criteri di gruppo client. Le regole iptables su tutti i nodi verranno aggiornate entro pochi minuti dal salvataggio del criterio.

Scenario 3: Trap SNMP non ricevute — Le trap vengono generate ma non consegnate

Problema: Gli errori sono visibili nella tabella degli errori APIC. moquery -c snmpTrapDest mostra l'indirizzo IP NMS corretto. Il sistema NMS non riceve trap.

Controllo configurazione: Esegui moquery -c snmpSrc | egrep "snmp.Src|name|dn". Verificare che le origini di monitoraggio siano presenti in tutti e tre gli ambiti (monfab-default, moncommon, moninfra-default). Una supervisione comune consiste nella configurazione dell'origine solo nei criteri predefiniti dell'infrastruttura, che non prevedono eventi dei criteri di accesso.

Controllo operativo: Attivazione di un evento di test (ad esempio, attivazione o disattivazione di un'interfaccia). Sul nodo corrispondente, eseguire tcpdump -i kpm_inb -f porta 162. Se i pacchetti trap vengono visualizzati sull'interfaccia del nodo, il lato ACI funziona e il problema si trova nel percorso di rete dell'NMS (firewall, routing). Se non viene visualizzata alcuna trap, l'origine di monitoraggio ACI risulta mancante o il tipo di evento non è incluso nell'attributo incl dell'origine.

Causa principale 1: Una o più origini di monitoraggio mancanti dagli ambiti richiesti.

Causa principale 2: L'attributo di origine di monitoraggio incl esclude il tipo di evento generato (ad esempio, incl: eventi senza errori significa che le trap basate su errori non verranno inviate).

Soluzione:

1. Aggiungere le origini di monitoraggio mancanti nella GUI per ognuno dei tre ambiti (Fabric Default, Fabric Common, Access Default). Impostare il gruppo di destinazione sul gruppo di destinazione SNMP configurato.
2. Verificare che l'attributo incl includa controlli, eventi e errori per la copertura completa delle trap.
3. Dopo le modifiche, riattivare l'evento di test e controllare nuovamente tcpdump.

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

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

leaf101# iptables -S | grep -i 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/*