we started updating all 16Gbit / Gen5 switches from v7.4.2a > v8.0.2f > v8.1.2f.
We recognised that our nagios monitoring via SNMP (default unsing v2) failed after both updates on a DCX8510-8 (not sure if it stopped on v8.0.2f or v8.1.2f).
Troubleshooting lead to a change in the date / timestamp format for connUnitREventTime (22.214.171.124.126.96.36.199.1.4) from MMDDYYYY (v7.4.x) to DDMMYYYY in the answer from the switch.
I've cheked the FOS MIB references and it seems that the now active format DDMMYYYY is the correct one since ever.
MIB references 6.4, 7.4, 8.1 and 8.2 are showing "DDMMYYYY HHMMSS" as only possible option. It seems to be the default format as well.
It is the same behavior for SNMP v2 and v3:
FOS v7.4.2a# snmpwalk -v 2c -c public tsfcs04 188.8.131.52.184.108.40.206.1.4iso.220.127.116.11.18.104.22.168.22.214.171.124.126.96.36.199.188.8.131.52.0.0.0.0.0.5374 = STRING: "12132018 131710"
# snmpwalk -v 3 -u snmpuser1 tsfcs04 184.108.40.206.220.127.116.11.1.4iso.18.104.22.168.22.214.171.124.126.96.36.199.188.8.131.52.184.108.40.206.0.0.0.0.0.5376 = STRING: "12132018 212143"iso.220.127.116.11.18.104.22.168.22.214.171.124.126.96.36.199.188.8.131.52.0.0.0.0.0.5377 = STRING: "12142018 063731"
FOS v8.1.2f# snmpwalk -v 2c -c public tsfcs01 184.108.40.206.220.127.116.11.1.4iso.18.104.22.168.22.214.171.124.126.96.36.199.188.8.131.52.184.108.40.206.0.0.0.0.0.28287 = STRING: "13122018 131449"
# snmpwalk -v 3 -u snmpuser1 tsfcs01 220.127.116.11.18.104.22.168.1.4iso.22.214.171.124.126.96.36.199.188.8.131.52.184.108.40.206.220.127.116.11.0.0.0.0.0.28287 = STRING: "13122018 131449"itcsec02:~#
Is this "working as designed" and why?
Can we change the output format?We have a mix of Gen4 and Gen5 switches and can't update all to FOS v8.1.x and don't want to hack the Nagios monitoring for every switch.
Thanks in advance!
Reformatted by @Jason McClellan removed HTML which caused SPAM trap
FYI - Feedback from support:
"The change to DDMMYYYY HHMMSS to match the user guide is due to an internal defect, this was implemented in FOS 8.0.1."
We requested a CVR for v7.4.2x.