-
Problem report
-
Resolution: Fixed
-
Major
-
5.0.16rc1
-
Sprint 84 (Jan 2022), Sprint 85 (Feb 2022)
-
0.5
1. Create an older version of import. The problem is in 4.4 converter. So even 4.4 export will do.
2. Create multiple items, LLD rules and item prototypes with various SNMP version interfaces. Create them having empty ports, different ports than in host, some of them the same. Total of 9 objects that use one old SNMP interface.
3. Now add SNMP trap item and item prototype that uses the same old SNMP interface. There should be now 11 objects. Feel free to add more and different types of interfaces. An example can be seen in the attached image.
4. When doing upgrade to 5.0 the results are following:
- some items use SNMPv1 interface, however they were created as SNMPv2 type;
- some items use SNMPv2 interface, however they were created as SNMPv1 type;
- some interfaces are left unused;
5. When doing import to 5.0 the results are following:
- SNMP trap item and SNMPv2 items will use default interface having SNMPv2 and "community" set to macros {$SNMP_COMMUNITY}, however that is different what server does in upgrade. Server, creates interface with SNMPv1 and "community" is always set to "public".
- one interface is missing since SNMP trap and SNMPv2 use same interface. They were only compared via port, but the "community" field was different, so it should've made one more interface (again see the image for reference).
The 4.4 converter code is a mess, uses too many nested loops, uses misleading variable names and tries to process the interfaces in almost one go. Preferably this has to be rewritten with a better algorithm. And, of course, frontend and server have to work the same.
- caused by
-
ZBXNEXT-2613 SNMP version/credentials should be set at interface level, not item level
- Closed
- depends on
-
ZBX-20698 Import from 2.0-4.4 to 5.0 and above with SNMP interfaces is not working correctly
- Closed
- mentioned in
-
Page Loading...