EEM SNMPv3

[Jaime Gomez]

Does EEM support SNMPv3? I have written some scripts that send snmp-traps from one router to another configured as an "snmp-server manager" but it looks like they only get sent as v2. I need to use v3 for IA reasons.

If it doesn't support SNMPv3, is there another reliable way of sending data between routers? I mainly need one router to know when another router gets a new OSPF neighbor and what interface the neighbor came up on. I've been using applets and I'm not as familiar as I'd like to be with TCL so maybe someone with more knowledge could tell me if there's an easier way to accomplish this in that format? Thanks.

[Joe Clarke · Accepted solution]

There is no such thing as a v3 trap.  There are only TRAPS and INFORMS in terms of PDU types.  You can send in SNMPv1 or SNMPv2 format.  That said, if you configure your SNMP trap host as a v3 host, the trap or inform notification will go out as an SNMPv3 PDU (in v2 format).

That said, I have a bug pending where EEM can only receive v1-formatted traps.  I'm surprised you're seeing this work with v2-formatted traps as the bug is still open.  Maybe it was fixed without them knowing about it.  If v2-formatted traps are working, then sending them as SNMPv3 notifications may work.  I have not tested this, though.

[Jaime Gomez]

Thanks for the explanation. I was confused by the debug message I was getting below, but now it makes sense.

*Nov 13 16:15:44.163: SNMP: Queuing packet to 10.XX.YY.50

*Nov 13 16:15:44.163: Outgoing SNMP packet

*Nov 13 16:15:44.163: v3 packet         security model: v3       security level: priv

*Nov 13 16:15:44.163: username: user1

*Nov 13 16:15:44.163: snmpEngineID: 80000009030046513E551B00

*Nov 13 16:15:44.163: snmpEngineBoots: 19       snmpEngineTime: 68016

*Nov 13 16:15:44.163: SNMP: V2 Trap, reqid 3831, errstat 0, erridx 0

My EEM script on the snmp-server manager is able to see the v2 trap data, but the debug output is throwing out some weird errors. This was with "debug snmp packets" and "debug snmp detail" enabled. I'm not sure why it has the "Failed" message if it's still able to see the v2 trap. It also mentions v2 to v1 conversion failure, but my EEM script can see the data fine. Could you shed more light on these messages?

*Nov 13 08:44:30.363: SNMP: Packet received via UDP from 10.XX.YY.2 on GigabitEthernet0/0/0SrParseV3SnmpMessage: Failed.

*Nov 13 08:44:30.363: SNMP: V2 Trap, reqid 3831, errstat 0, erridx 0

sysUpTime.0 = 172168969

snmpTrapOID.0 = cEventMgrMIB.0.2

ceemHistoryEventEntry.2.223 = 131

ceemHistoryEventEntry.3.223 = 0

ceemHistoryEventEntry.4.223 = 0

ceemHistoryEventEntry.5.223 = 0

ceemHistoryEventEntry.6.223 = 

ceemHistoryEventEntry.7.223 = applet: ts 

ceemHistoryEventEntry.9.223 = 0

ceemHistoryEventEntry.10.223 = 0

ceemHistoryEventEntry.11.223 = test-data

ceemHistoryEventEntry.13.223 = 0

ceemHistoryEventEntry.14.223 = 0

ceemHistoryEventEntry.15.223 = 0

ceemHistoryEventEntry.16.223 = 0

*Nov 13 08:44:30.414:  dest ip addr= 10.XX.YY.50

*Nov 13 08:44:30.414:  dest if_index = 1

convert_pdu:Conversion between V2 and V1 notification failed.

SrGenerateNotification: Failed to find Group name in GroupTable.

SrV2GenerateNotification:Function has reached clean up routine.

One last thing in case anyone else tries this. On the snmp-server manager router, I had to configure an SNMP user with the remote engineID of the router sending the trap like shown below. Without the right engineID, the manager was rejecting the traps and displaying "Wrong username".

snmp-server engineID remote 10.XX.YY.2 80000009030046513E551B00

snmp-server group AuthPrivGroup v3 priv

snmp-server enable traps event-manager

snmp-server manager

ASR_1002#sh snmp user

User name: user1

Engine ID: 80000009030046513E551B00

storage-type: nonvolatile        active

Authentication Protocol: MD5

Privacy Protocol: AES128

Group-name: AuthPrivGroup

[Joe Clarke]

This looks like a minor bug.  It doesn't appear to affect functionality.  The bug is still open, though: CSCtz47501.

[Jaime Gomez]

Alright, thanks again. It says I have insufficient permissions to view the bug though.

[Joe Clarke]

Yes, the bug is currently internal-only.