SNMPv3 traps not seen in Spectrum...

[karen_brooks]

Everyone,

 

We are working to get SNMPv3 traps into Spectrum.  We are sending the traps to a single lab server. I have done the following:

• validated that we can see the raw, unencrypted trap using tcpdump
• enabled Trap Director
• created an SNMPv3 profile with the applicable credentials
• have an EventAdmin model created with the IP of the device sending the SNMPv3 trap

 

The trap was manually mapped from a v1 trap, so I'm not sure if any additional mapping is required for the v3 trap since I cannot see it in Spectrum. I removed the mapping to see if there were any events for the trap, but there weren't any.

 

What else can we look at to get this working?

[ackjo04]

Karen,

 

Did you create the V3 profile on both the Trap Director server and the server receiving the redirected trap?

 

Joe

[Rene Cantwell]

Karen are you all set with this question?  Did creating a V3 profile as Joe suggested resolve this?

 

--

Rene'

[karen_brooks]

I have the trap being sent to the server where the model lives.  I do have the SNMPv3 profile enabled/created there. I've also enabled Trap Director on the same server.  

 

I can validate the trap is coming in using tcpdump, but I don't see anything on the applicable device model.  I do have a manually created event mapping (based on the v2 trap we received prior) - I'm not sure if this should make a different or not.

[ackjo04]

Karen,

 

Verify the v3 creds sent with the trap are the same as the ones used to model the device in Spectrum. I have seen where the v3 trap creds and the v3 snmp creds are different.

 

Joe

[karen_brooks]

I've asked the customer to validate that and they say that the creds I have been given are used on that device.  I cannot model the host with the credentials they've provided me which I believe I should be able to do, correct?  

[ackjo04]

One way to verify if the creds are correct is to get a sniffer of the trap. Import the sniffer into wireshark and then Edit the wireshark User Table in the Preferences to add the creds and see if they are decoded. If they do not decode them then the Spectrum profile using them cannot.

 

Joe

[karen_brooks]

Hello Joe,

 

So basically, if I cannot decode the RAW trap, then the creds I have are invalid, correct?  I'll give that a try.

[karen_brooks]

Hello Joe,

 

Wireshark is reporting the following.  

 

[Bradley Gray]

Hi Karen,

 

Based on your packet capture, it appears to be related to the privacy parameters. Please verify the privacy encryption algorithm is set correctly. Spectrum 10.2.1 supports the following encryption algorithms for privacy:

• DES: Data Encryption Standard (DES) is a 64-bit standard that encrypts and decrypts data.
• 3DES: Data Encryption Standard (DES) is a 64-bit standard that encrypts and decrypts data three times.
• AES: Advanced Encryption Standard (AES) is a 128-bit standard, cryptographic algorithm that encrypts and decrypts data.
• AES256: Advanced Encryption Standard (AES 256) is a 256-bit standard, cryptographic algorithm that encrypts and decrypts data.

 

By default Spectrum uses DES.

 

I would try modeling the device with the SNMPv3 profile first, however, I think the traps could use a completely different profile than that used to model the device. But typically they should be the same. If you try modeling the device, get a packet capture. If the modeling fails, look for any Report PDU's coming back from the device, they should help determine why the modeling failed.

1. usmStatsUnsupportedSecurityLevel (1.3.6.1.6.3.15.1.1.1.0) - This is set when the security level specified is not supported by the agent.
2. usmStatsNotInTimeWindows (1.3.6.1.6.3.15.1.1.2.0) - This is set when the engineTime specified is not within the timeWindow of agent.
3. usmStatsUnknownUserNames (1.3.6.1.6.3.15.1.1.3.0) - This is set when the user name specified is not present in the agent.
4. usmStatsUnknownEngineIDs (1.3.6.1.6.3.15.1.1.4.0) - This is set when the snmpEngineID specified in the request message does not match with that of the agent.
5. usmStatsWrongDigests (1.3.6.1.6.3.15.1.1.5.0) - This is set when the password specified is not correct.
6. usmStatsDecryptionErrors (1.3.6.1.6.3.15.1.1.6.0) - This is set when the packet is unable to decrypt on the agent side. This error occurs while querying an AuthPriv user.

 

Hope this is helpful,

Brad

[karen_brooks]

Brad,

 

Thank you.  I am trying to get clarity from the customer and sent that screen capture along to them.  

They have asked to put this specific issue on the back burner, so I will mark it as answered for now. I think there is enough information here for us to get it going when they are ready to resume.