Ad Widget

Collapse

SNMP traps: sent to server = unmatched, sent to proxy = ok

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • d0d0
    Member
    • May 2023
    • 41

    #1

    SNMP traps: sent to server = unmatched, sent to proxy = ok

    I have the following setup:

    zabbix server container in LAN, has snmptraps container, cannot talkt to snmp device
    zabbix proxy container in protected Admin VLAN, has snmptraps container, can talk to snmp device
    snmp device in protected Admin VLAN, has ip1, can talk to zabbix proxy and can also talk to zabbix server

    in zabbix server I have a host object for snmp device at ip1, set to be reached via zabbix proxy

    if I set snmp device to send SNMPv1/2c traps from ip1 to zabbix proxy, the traps are received by zabbix proxy and forwarded to zabbix server, and there correctly assigned to the snmp traps (fallback) item. so far so good.

    if I set snmp device to send SNMPv1/2c traps from ip1 directly to zabbix server (not through zabbix proxy), the traps are received by zabbix server and in the log it says:

    unmatched trap received from "ip1": 20230523.194919 UDP: [ip1]:63668->[172.17.0.5]:1162
    DISMAN-EVENT-MIB::sysUpTimeInstance = 1073850
    SNMPv2-MIB::snmpTrapOID.0 = SNMPv2-SMI::enterprises.318.0.636
    DISMAN-EVENT-MIB::sysUpTimeInstance = 1073850
    SNMPv2-MIB::snmpTrapOID.0 = SNMPv2-SMI::enterprises.318.0.636
    SNMP-COMMUNITY-MIB::snmpTrapAddress.0 = ip1
    SNMP-COMMUNITY-MIB::snmpTrapCommunity.0 = "public"
    SNMPv2-MIB::snmpTrapEnterprise.0 = SNMPv2-SMI::enterprises.318​

    which is exactly the same data assigned to snmp traps (fallback) if the trap is sent to the proxy instead of the server.

    The ip1 address is the same in the log, in the SNMP interface definition of the host object, and works fine when sent through the proxy.
    So i thought the problem might be something else, e.g. the community string, or that the host object has zabbix proxy selected.
    I tried different community strings for the sending snmp device and playing with setting proxy or no proxy in host object for both destinations, server and proxy.
    The outcome was exactly the same!

    Another wild details is, that SNMP communication initiated through the proxy is actually using SNMPv3, but I made the device use SNMPv1 traps.
    Still, when going through the proxy the traps are received and accepted, no matter if there is another SNMPv1 interface with the correct community string.

    So to me it seems, that the SNMP interface settings (apart from the IP address) are not at all used for anything when receiving traps. Is that correct?

    The big question here to me is:
    What could be the reason why zabbix server rejects the exact same snmp traps as unmatched when they are sent directly to the server instead of to the proxy?


    (final notes: I think it is no good that one has to configure details in snmptrapd.conf which should be already known from the UI SNMP interface definition, and also its not good, that information that is available in the UI SNMP interface definition is disregarded, and also no good that SNMPv1 traps are received, even if no SNMPv1 interface is defined, but only an SNMPv3 interface)








  • ISiroshtan
    Senior Member
    • Nov 2019
    • 324

    #2
    Howdy

    Firstly you need to understand distinction between SNMP Trap and SNMP Query processing from Zabbix standpoint.

    SNMP Query would be perfomred by Zabbix process itself and it would take data from whatever you define on SNMP interface settings. In this case it would matter if you set SNMPv1,2 or SNMPv3, if you set community string and/or authentication data, if you set them wrong, etc.

    SNMP traps, on other hand, are not actually processed by Zabbix services directly. Instead processing will be done by snmptrapd and decryption/authentication of messages will be done based on snmtrapd.conf and it does not matter what supplimentary information you will set in Zabbix UI on SNMP interface.
    After snmptrapd processed the trap it logs it to special log file in special format. Here Zabbix services start to work by parsing said log file. As the traps already decoded and written as plain text, Zabbbix does not need any of SNMP information to prcoess them, hence it does not matter what version or authentication data you set in Zabbix UI. The only thing Zabbix service needs is that SNMP interface is set with proper IP/DNS to match "from" field of decoded SNMP trap to proper host.



    Now in regards to actual problem:

    It might be obvious to do hence you not mentioned it, but did you switch the host in Zabbix UI from 'Monitored by proxy" to "No proxy" when you try sending trap directly to server?
    Last edited by ISiroshtan; 24-05-2023, 04:49.

    Comment

    • cyber
      Senior Member
      Zabbix Certified SpecialistZabbix Certified Professional
      • Dec 2006
      • 4807

      #3
      Originally posted by d0d0
      The big question here to me is:
      What could be the reason why zabbix server rejects the exact same snmp traps as unmatched when they are sent directly to the server instead of to the proxy?
      That's pretty obvious... from "monitoring perspective" that host is "given to proxy", so any trap data association to host is done there... Your "server" does not know about that host (yea sound weird, but you need to separate the functions here), thus defining it as "unknown trap"...
      Just as ISiroshtan said, switch that host to "no proxy" and your server will accept traps.. But then it also starts to poll the rest of items for that host, which might not be possible as you say "cannot talkt to snmp device"

      And I said many other things about that snmpv3 in other topic, will not repeat it here..

      Comment

      • d0d0
        Member
        • May 2023
        • 41

        #4
        What I wrote in my initial posting:
        "I tried [...] playing with setting proxy or no proxy in host object for both destinations, server and proxy.
        The outcome was exactly the same!"

        So what you propose sounds logically sound, but it did not work for me that day for the device I tested.

        However, I tried it again today with two nearly identical devices (the same device as used last time and another device):


        device1: behavior as last time:

        -when host object set to use proxy, and device1 sends trap to proxy: works OK

        -when host object set to use NO proxy, and device1 sends trap to proxy: proxy says "unmatched trap received from IP1" - this should be OK, as trap must now be sent directly to the server
        ​​
        -when host object set to use NO proxy, and device1 sends trap directly to server: server says "unmatched trap received from IP1", but IP1 is the same as in the SNMP interface of the host object - this should be an error, something must be wrong but I don't find the problem.


        device2: behavior as you describe, everything OK

        -when host object set to use proxy, and device2 sends trap to proxy: works OK

        -when host object set to use NO proxy, and device2 sends trap to proxy: proxy says "unmatched trap received from IP2" - this should be OK, as trap must now be sent directly to the server
        ​​
        -when host object set to use NO proxy, and device2 sends trap directly to server: works OK


        As another test I removed the host object for device1 and created a new host object for device1 and ran the same tests. The result was the same.

        So for device2 the whole SNMP traps thing works as expected, but for device1 it does not. Both are APC NMC network mangement cards for UPS.



        ​Any ideas why there is a different behavior on the server for device1 and device2?
        Last edited by d0d0; 25-05-2023, 16:28.

        Comment

        Working...