Ad Widget

Collapse

Zabbix handling of SNMPv3 secureEngineID non-conforming or compliant with RFC1910

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • GarrettCO
    Member
    • Jan 2024
    • 44

    #1

    Zabbix handling of SNMPv3 secureEngineID non-conforming or compliant with RFC1910

    Our Enterprise is moving from Spectrum to Zabbix for several thousand hosts for Video,Voice, and Internet. One of the issues just seeing is how Zabbix handles or doesn't handle devices with the same secureEngineID. Apparently Spectrum did not have a problem processing incoming SNMP with the same secureEngineID with some proprietary magic. I get the issue Zabbix has for polling with the same ID is an issue, but unclear on incoming SNMPv3 data.

    My question is,is there a way Zabbix can be configured in snmptrapd.conf to handle non-conforming SNMPv3 secureEngineID to process data? Hosts with conforming secureEngineIDs do work and process correctly, just not the non-conforming ones.

    One note, there was an Ansible automation playbook that duplicated this ID because of some original issue with Alerta. So there was architecture to send SNMPv3 to both Alerta and Spectrum. Whereas now using Zabbix to handle both.

    Click image for larger version  Name:	Screenshot 2024-12-20 at 6.46.20 AM.png Views:	0 Size:	94.6 KB ID:	496264

    06:24:05 2024/12/20 ZBXTRAP
    PDU INFO:
    messageid 205187
    securityName xxxxxxxxxxxxx
    requestid 213529
    securitymodel 3
    transactionid 3475692
    receivedfrom UDP: [xx.xx.xx.xx]:59928->[xx.xx.xx.xx.xx]:162
    securitylevel 3
    notificationtype TRAP
    version 3
    securityEngineID 0x1122334455
    errorindex 0
    contextEngineID 0x1122334455
    contextName
    errorstatus 0
    VARBINDS:
    DISMAN-EVENT-MIB::sysUpTimeInstance type=67 value=1670689254
    SNMPv2-MIB::snmpTrapOID.0 type=6 value=OID: SNMPv2-MIB::authenticationFailure
    SNMPv2-MIB::snmpTrapEnterprise.0 type=6 value=OID: SNMPv2-SMI::enterprises.232.9.4.11
    Last edited by GarrettCO; 20-12-2024, 15:54.
Working...