Which SNMP version for Trap based discovery?

[Skip.Taylor]

Does anyone know what version of SNMP Trap based discovery Spectrum supports?  Is that feature configurable and if so where?

[Jason Meader]

It supports v1, v2 and v3 (for v3 you have to have a v3 profile configured and none of your v3 profiles can have a duplicate username.  It must be unique).

 

Cheers

Jay

[Skip.Taylor]

Thanks Jay,
I'm trying to discover Palo Alto Devices by traps.  Verified via Wireshark on Spectro server that the device is sending traps.  It was not discovering in Spectrum.  Set spectrum to discover Pingables and then I saw it as a pingable device.  I can manually discover the device and it comes in correctly as a Palo Alto device.   Does that make sense?  Thoughts?

[Jason Meader]

Hi Skip,

Were you able to get the discovery to work with the info we provided?

Thanks!

Jay

[Skip.Taylor]

Hi Jay,

unfortunately no, I was not able to get Trap based discovery working on the Palo Altos.  Not sure why.  Via Wireshark I see the version 2c traps coming to the Spectro server.  I added the Palo Alto Mibs.  Not sure why it is not discovering.  I can manually discover it.

[Jason Meader]

In your v3 profiles, do all profiles have a unique username?  Or do you have multiple profiles using the same username?

[Skip.Taylor]

we are not using SNMP v3.  Where do I view SNMP profiles?

[Jason Meader]

Oh, sorry, I just assumed v3 b/c usually v1 and v2 work without any troubles.  The Trap based discovery is on?  Make sure the SS is seeing the trap – open the dynamic debugging on the VNM and turn on the Alert Manager debug.  Also turn on the autodiscovery debug (from the VNM model autodiscovery -> debug -> on).  Send the trap(s). Turn the debug off.  Review the /SS/Adiscdebug* file.

 

Cheers

Jay

[Skip.Taylor]

I'll take a look at the logs.  Trap based discovery is on and has been working for years.  It is not set to discover pingables.  Confirmed Spectrum is seeing the traps.  If I allow to discover pingables it shows up if I don't allow pingables it does not show up.  Seems it does not know what to do with the device.  

[Skip.Taylor]

here's what I'm seeing in the log  (I removed address and replaced with ***.***.***.***)

 

******************************************************
19:00:46 Unmanaged Trap IH: ***.***.***.***
19:00:46 Unmanaged Trap IH: Just tried this trap IP ***.***.***.*** 153 seconds ago. Will not try again.

******************************************************

[ackjo04]

Can you model by ip using the same v2 community string sent with the trap?

 

Joe

[Skip.Taylor]

Hi Joe,

If you mean can I discover manually then yes.

[ackjo04]

Manually meaning discover by ip where you just enter the ip address and community string or manually by model type where you select a specific model type first and then enter the ip and community string?

 

Joe

[Skip.Taylor]

I am putting in the IP and community string in the manual discovery and it works.

[ackjo04]

Skip,

 

Spectrum's Trap Based Continuous Discovery supports SNMP V1, V2C and V3. It is configurable under the AutoDiscovery Control -> Trap Based Continuous Discovery subview. Document reference VNM Attributes in the Information Tab - CA Spectrum - 10.2 and 10.2.1 - CA Technologies Documentation 

 

For SNMP V3, it does require an SNMP V3 Profile exist that contains the V3 credentials (User Security name, auth password and priv password if needed.). If no V3 profile exists with those credentials, it will not create the model.

 

Joe

[Bradley Gray]

Hi Skip,

 

The trap based discoveries should use the same process as a Model by IP, or any other SNMPv1 or v2c discovery. However, we pull the needed information directly from the trap. Make sure the trap is passing the proper SNMP community string. The SNMP standards do not require traps to pass the correct community string, so if your trap is passing the community string of "public", but you are using "private", the discovery will fail.

 

Thank you,

Brad

[Skip.Taylor]

Hi Brad,
It appears to be sending SNMP V2c the correct community string.  I verified in wireshark.

[ackjo04]

Enable AutoDiscovery debug. The next time this occurs, check the ADISC log in the $SPECROOT/SS directory for any errors.

 

Joe

[Skip.Taylor]

same as before.

 

20:09:52 Unmanaged Trap IH: ***.***.***.***
20:09:52 Unmanaged Trap IH: Just tried this trap IP ***.***.***.*** 662 seconds ago. Will not try again

[ackjo04]

Can you start wireshark and check the community string Spectrum is sending out after the trap is received?

 

Joe

[Skip.Taylor]

yep, verified.  Sending correct community string

[ackjo04]

Is the device responding?

 

Joe

[Skip.Taylor]

yes, device is responding .   I even changed the community string on the device to another "known" value and verified it came in via the trap.  Changed it back to our default and watched it update again via the trap using Wireshark.  Very strange behavior.  
Is there anywhere to configure the SNMP types for auto discovery?  Seems it's either on or off.

[ackjo04]

Not much to configure for the trap based discovery. I tested all 3 , V1, V2c and V3 successfully using the sendtrap utility sending the traps to Spectrum 10.2.1 on Linux. The device is a Cisco router.

 

You can tell Spectrum to use other snmp community strings if the community string sent with the trap fails to create a model. For example, it is common to leave the trap community string at public and remove public as an snmp community string. 

 

Under the AutoDiscovery Control -> Modeling and Protocol Options section, there is a SNMP Community Strings field. Adding to this list will cause the Trap Based Continuous Discovery to try these in order if the community string sent with the trap fails to create a model.

 

Joe