ZABBIX BUGS AND ISSUES
  1. ZABBIX BUGS AND ISSUES
  2. ZBX-7576

Discovery does not correctly process broadcast addresses

    Details

      Description

      For example, if broadcast address not .255 (small size of network), some of devices can answer to ping echo requests. So broadcast address will be added as another device.

        Issue Links

          Activity

          Hide
          Andris Zeila added a comment -

          Fixed in development branch svn://svn.zabbix.com/branches/dev/ZBX-7576

          Show
          Andris Zeila added a comment - Fixed in development branch svn://svn.zabbix.com/branches/dev/ZBX-7576
          Hide
          Aleksandrs Saveljevs added a comment - - edited

          (1) There are differences between fping versions how broadcast addresses for which no answers are received are handled in the summary:

          For instance, version 2.4b2_to does not output ping results for the broadcast address:

          fping 2.4b2_to
          $ sudo fping -v
          fping: Version 2.4b2_to $Date: 2002/01/16 00:33:42 $
          fping: comments to david@remote.net
          $ echo 192.168.1.255 | sudo fping -C3
          
          192.168.1.255 :
          

          However, version 3.8 outputs results. Sometimes it outputs all dashes and sometimes it outputs what seems to be a random value as the first number:

          fping 3.8
          $ sudo fping -v
          fping: Version 3.8
          fping: comments to david@schweikert.ch
          $ echo 192.168.1.255 | sudo fping -C3
          
          192.168.1.255 : - - -
          $ echo 192.168.1.255 | sudo fping -C3
          
          192.168.1.255 : 21140988.88 - -
          

          Do we wish to do something about it? For instance, by parsing lines for each ping result, rather than the summary line? Or parsing the summary line, but checking that there were lines for each ping result, too?

          Andris Zeila We have to parse summary line anyway to get the timeouts. So that leaves the second option.

          Andris Zeila Actually we can parse the individual results and just use the summary line as 'EOF' marker.

          Andris Zeila RESOLVED in r41456

          Aleksandrs Saveljevs It might be better to start parsing the response time one character later. That I changed in r41492, please take a look.

          Aleksandrs Saveljevs Another thing is that individual ping results have less precision (see sprint_tm() function in fping source). For instance:

          ...
          192.168.1.1 : [21], 84 bytes, 1819 ms (260 avg, 69% loss)
          192.168.1.1 : [22], 84 bytes, 818 ms (330 avg, 65% loss)
          192.168.1.1 : [23], 84 bytes, 0.51 ms (293 avg, 62% loss)
          ...
          

          This corresponds to the following numbers in the summary line:

          192.168.1.1 : 0.57 1.05 0.49 0.98 0.26 0.92 - - - - - - - - - - - - - - - 1819.74 818.80 0.51 0.96 0.26 ...
          

          Does not seem to be good from our side to compromise on precision... REOPENED.

          Andris Zeila RESOLVED in r41500

          Aleksandrs Saveljevs CLOSED

          Show
          Aleksandrs Saveljevs added a comment - - edited (1) There are differences between fping versions how broadcast addresses for which no answers are received are handled in the summary: For instance, version 2.4b2_to does not output ping results for the broadcast address: fping 2.4b2_to $ sudo fping -v fping: Version 2.4b2_to $Date: 2002/01/16 00:33:42 $ fping: comments to david@remote.net $ echo 192.168.1.255 | sudo fping -C3 192.168.1.255 : However, version 3.8 outputs results. Sometimes it outputs all dashes and sometimes it outputs what seems to be a random value as the first number: fping 3.8 $ sudo fping -v fping: Version 3.8 fping: comments to david@schweikert.ch $ echo 192.168.1.255 | sudo fping -C3 192.168.1.255 : - - - $ echo 192.168.1.255 | sudo fping -C3 192.168.1.255 : 21140988.88 - - Do we wish to do something about it? For instance, by parsing lines for each ping result, rather than the summary line? Or parsing the summary line, but checking that there were lines for each ping result, too? Andris Zeila We have to parse summary line anyway to get the timeouts. So that leaves the second option. Andris Zeila Actually we can parse the individual results and just use the summary line as 'EOF' marker. Andris Zeila RESOLVED in r41456 Aleksandrs Saveljevs It might be better to start parsing the response time one character later. That I changed in r41492, please take a look. Aleksandrs Saveljevs Another thing is that individual ping results have less precision (see sprint_tm() function in fping source). For instance: ... 192.168.1.1 : [21], 84 bytes, 1819 ms (260 avg, 69% loss) 192.168.1.1 : [22], 84 bytes, 818 ms (330 avg, 65% loss) 192.168.1.1 : [23], 84 bytes, 0.51 ms (293 avg, 62% loss) ... This corresponds to the following numbers in the summary line: 192.168.1.1 : 0.57 1.05 0.49 0.98 0.26 0.92 - - - - - - - - - - - - - - - 1819.74 818.80 0.51 0.96 0.26 ... Does not seem to be good from our side to compromise on precision... REOPENED. Andris Zeila RESOLVED in r41500 Aleksandrs Saveljevs CLOSED
          Hide
          Aleksandrs Saveljevs added a comment -

          We have reported the issue with fping described above at https://github.com/schweikert/fping/issues/56 .

          Show
          Aleksandrs Saveljevs added a comment - We have reported the issue with fping described above at https://github.com/schweikert/fping/issues/56 .
          Hide
          Andris Zeila added a comment -

          Released in:
          pre-2.2.2rc1 r41522
          pre-2.3.0 r41523

          Show
          Andris Zeila added a comment - Released in: pre-2.2.2rc1 r41522 pre-2.3.0 r41523
          Hide
          Aleksandrs Saveljevs added a comment -

          The fping issue at https://github.com/schweikert/fping/issues/56 was fixed and is scheduled to be released in version 3.9.

          Show
          Aleksandrs Saveljevs added a comment - The fping issue at https://github.com/schweikert/fping/issues/56 was fixed and is scheduled to be released in version 3.9.
          Hide
          Aleksandrs Saveljevs added a comment -

          Due to a request in ZBX-8250, we shall port the fix to Zabbix 2.0, too.

          Show
          Aleksandrs Saveljevs added a comment - Due to a request in ZBX-8250 , we shall port the fix to Zabbix 2.0, too.
          Hide
          Aleksandrs Saveljevs added a comment -

          Fixed in development branch svn://svn.zabbix.com/branches/dev/ZBX-7576 .

          Show
          Aleksandrs Saveljevs added a comment - Fixed in development branch svn://svn.zabbix.com/branches/dev/ZBX-7576 .
          Hide
          Andris Zeila added a comment -

          Successfully tested

          Show
          Andris Zeila added a comment - Successfully tested
          Hide
          Aleksandrs Saveljevs added a comment -

          Released in:
          pre-2.0.13rc1 r46000

          Show
          Aleksandrs Saveljevs added a comment - Released in: pre-2.0.13rc1 r46000
          Hide
          richlv added a comment - - edited

          (2) changelog entry does not follow the guidelines (does not start with a verb)

          Aleksandrs Saveljevs Fixed in r50191. RESOLVED.

          Andris Zeila CLOSED

          Show
          richlv added a comment - - edited (2) changelog entry does not follow the guidelines (does not start with a verb) Aleksandrs Saveljevs Fixed in r50191. RESOLVED. Andris Zeila CLOSED
          Hide
          Onno Steenbergen added a comment -

          Hi,

          I'm experiencing this bug as well by using multiple /16 in my discovery. Host are discovered on their main address (10.1.1.1 for example) but also on the .0 and .255. Zabbix creates a single interface for the main address but adds multiple .255 interfaces, but it seems a bit random when Zabbix adds an interface.

          My configuration

          • Discovery rule:
            • IP range:
              • 10.1.0.0/16
              • 10.2.0.0/16
              • ...(total of 10 times a /16)
            • Checks:
              • SNMPv2 agent "1.3.6.1.2.1.47.1.1.1.1.11.1" (Serial)
              • SNMPv2 agent "1.3.6.1.2.1.47.1.1.1.1.13.1" (Device type)
            • Device uniqueness criteria: SNMPv2 agent "1.3.6.1.2.1.47.1.1.1.1.11.1"
          • Discovery Action:
            • Discovery check = Routers: SNMPv2 agent "1.3.6.1.2.1.47.1.1.1.1.13.1"
            • Discovery rule = Routers
            • Received value like CISCO887VA-SEC-K9
            • Discovery status = Up
            • Service type = SNMPv2 agent

          There are multiple ways to currently solve this, although all will result in a lot of rules:

          • Only add 10.1.1.1-254 discovery rules
            • Results in 2550 discovery rules, which is unmanageable.
          • Add a extra condition in the discovery action
            • Impossible as there is only one received value and I need to check if it is the correct device
            • Host.ip only allows for equals and not equals. With a not like you could add 'host.ip not like .255' although that filters out 10.255.1.1

          I "fixed" it by adding 5100 rules to iptables with: iptables -A OUTPUT -d 10.1.1.255 -j DROP

          Show
          Onno Steenbergen added a comment - Hi, I'm experiencing this bug as well by using multiple /16 in my discovery. Host are discovered on their main address (10.1.1.1 for example) but also on the .0 and .255. Zabbix creates a single interface for the main address but adds multiple .255 interfaces, but it seems a bit random when Zabbix adds an interface. My configuration Discovery rule: IP range: 10.1.0.0/16 10.2.0.0/16 ...(total of 10 times a /16) Checks: SNMPv2 agent "1.3.6.1.2.1.47.1.1.1.1.11.1" (Serial) SNMPv2 agent "1.3.6.1.2.1.47.1.1.1.1.13.1" (Device type) Device uniqueness criteria: SNMPv2 agent "1.3.6.1.2.1.47.1.1.1.1.11.1" Discovery Action: Discovery check = Routers: SNMPv2 agent "1.3.6.1.2.1.47.1.1.1.1.13.1" Discovery rule = Routers Received value like CISCO887VA-SEC-K9 Discovery status = Up Service type = SNMPv2 agent There are multiple ways to currently solve this, although all will result in a lot of rules: Only add 10.1.1.1-254 discovery rules Results in 2550 discovery rules, which is unmanageable. Add a extra condition in the discovery action Impossible as there is only one received value and I need to check if it is the correct device Host.ip only allows for equals and not equals. With a not like you could add 'host.ip not like .255' although that filters out 10.255.1.1 I "fixed" it by adding 5100 rules to iptables with: iptables -A OUTPUT -d 10.1.1.255 -j DROP

            People

            • Assignee:
              Unassigned
              Reporter:
              Alexey Pustovalov
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: