Alcatel Unleashed

Hi All,
I am facing problem with SNMPv3 authentication on 6850/9800 with 6.3.1.

SNMP config on 6850:
TestSwitch> user snmpuser password abcd1234 read-write all md5+des
TestSwitch> snmp security authentication all
TestSwitch> snmp authentication trap enable
TestSwitch> snmp station 10.68.88.11 162 "snmpuser" v3 enable

Linux with Net-SNMP 5.3.1.
When I run snmpget from the Linux console (eg. for Nagios) I get the correct response from the switch:
snmpget -v3 -u snmpuser -l authpriv -a md5 -A abcd1234 -x des -X abcd1234 -e 800019560300E0B19BC33F 172.31.21.98 sysName.0
SNMPv2-MIB::sysName.0 = STRING: TestSwitch

But the switch sends a trap to the OmniVista:
authenticationFailure: Authentication failed

I've traced snmp with wireshark:
1. the first snmp request to the switch contained:
msgAuthoritativeEngineID: 800019560300E0B19BC33F
msgAuthoritativeEngineBoots: 0
msgAuthoritativeEngineTime: 0
2. next cames from the switch snmp report with:
msgAuthoritativeEngineID: 800019560300E0B19BC33F
msgAuthoritativeEngineBoots: 1
msgAuthoritativeEngineTime: 72848
3. second ??? snmp request to the switch contained:
msgAuthoritativeEngineID: 800019560300E0B19BC33F
msgAuthoritativeEngineBoots: 1
msgAuthoritativeEngineTime: 72848
4. snmp response from switch - OK

The only difference between 1. and 3 is msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime .
How can I configure net-snmp for snmp v3 with auth. ?

Thanks in advance,
alek

SNMPv3 got some security ties related to time. Please make sure that the time/date is the same on PC and switch.

All is synchronized per NTP!

1. the first snmp request to the switch contained:
msgAuthoritativeEngineBoots: 0
msgAuthoritativeEngineTime: 0
Is that the problem?

I resent that there 2 snmp requests needed by SNMP v3. With snmp v1/2 is only 1 snmp request to get response.

alek

Hi,

seems that you forgot the authentication command:
aaa authentication snmp local

Meanwhile, here is the answer about that.

I understood that this is normal.
SNMPv3 authentication relies on a synchronisation of "engine uptime" information between the two sides.

The first time that the client application tries to query the agent, it has no idea of what the engineBoot/Time values ought to be, so sends a "probe" request to discover them. In this time sends the switch "authenticationFailure" trap.
This probe is actually a copy of the real request (but with 0 values for these two fields), and there is no expectation that the request will succeed.
The purpose is to trigger a failure report message, which will include the current engineBoot/Time values for the agent.

The request can then be sent with these two values inserted, and this should allow the agent to authenticate it successfully.

Any subsequent request from the same management application should succeed, without the need for another probe (unless the agent has restarted in the meantime)

If you are using separate "snmpget" shell commands for each request, then these will indeed be regarded as completely separate, and will probe for the boot/time values every time.
They are designed as "one-shot" requests, so will probe for this information each time.
If you want to avoid these subsequent probes, you are really looking at coding a suitable long-running application.

SNMPv2-MIB::snmpEnableAuthenTraps, can be used to suppress the generation of authenticationFailure notifications.
In AOS there is command "snmp authentication trap disable".

alek