Details
-
Vendor Bug
-
Resolution: Won't Fix
-
Major
-
None
-
CE-22.5
-
Basic environment, nothing special
Description
There is an issue with the FORTIGATE poller.
"IPv4 addresses" are completely wrong.
IP addresses are changed, ommitting the 1st octet and adding ".1" at the end (see capture).
If you have an interface "192.168.1.1/24" configured, it will show as "168.1.1.1/24", which is completely weird!
Could you help me on this?
Thanks!
Attachments
1.
|
SNMP parse issue |
|
Closed | Mike Stupalov |
Activity
Hi Christian,
Thanks for all that precisions!
I just created a new sub-task to try to get Observium team to investigate a bit more by their side.
Hope they will! 
Kind Regards,
David
The weird part is that some interfaces work and others don't. Even the ones that work the extra 1 is present. Doing a snmpwalk shows that the fortigates handles the correct IPs. So, I'm confused wether is a Vendor issue or simple a parse issue when loading the data into the database.
I'm not an expert so please take this with a grain of salt and I'm willing to hep in order to solve this issue.
Thank you in advance and best regards.
/opt/observium$ snmpwalk -v3 -l authPriv -u obssnmpread -a SHA -A "asdasffsdfsdfs" -x AES -X "asdasffsdfsdfs" fw01 -m IP-MIB | grep -i ipaddressifindex
IP-MIB::ipAddressIfIndex.ipv4."10.10.10.1".6 = INTEGER: 6
IP-MIB::ipAddressIfIndex.ipv4."10.10.200.1".15 = INTEGER: 15
IP-MIB::ipAddressIfIndex.ipv4."10.10.250.1".13 = INTEGER: 13
IP-MIB::ipAddressIfIndex.ipv4."10.10.254.1".43 = INTEGER: 43
IP-MIB::ipAddressIfIndex.ipv4."10.10.255.1".23 = INTEGER: 23
IP-MIB::ipAddressIfIndex.ipv4."10.100.0.1".34 = INTEGER: 34
IP-MIB::ipAddressIfIndex.ipv4."10.128.4.1".9 = INTEGER: 9
IP-MIB::ipAddressIfIndex.ipv4."10.130.0.1".35 = INTEGER: 35
IP-MIB::ipAddressIfIndex.ipv4."10.130.1.1".37 = INTEGER: 37
IP-MIB::ipAddressIfIndex.ipv4."10.130.255.1".39 = INTEGER: 39
IP-MIB::ipAddressIfIndex.ipv4."10.150.2.1".7 = INTEGER: 7
IP-MIB::ipAddressIfIndex.ipv4."10.253.255.254".36 = INTEGER: 36
IP-MIB::ipAddressIfIndex.ipv4."10.255.11.1".12 = INTEGER: 12
IP-MIB::ipAddressIfIndex.ipv4."10.255.18.1".61 = INTEGER: 61
IP-MIB::ipAddressIfIndex.ipv4."10.255.19.1".63 = INTEGER: 63
IP-MIB::ipAddressIfIndex.ipv4."100.100.99.1".18 = INTEGER: 18
IP-MIB::ipAddressIfIndex.ipv4."100.100.99.5".21 = INTEGER: 21
IP-MIB::ipAddressIfIndex.ipv4."100.100.99.9".16 = INTEGER: 16
IP-MIB::ipAddressIfIndex.ipv4."100.100.99.13".17 = INTEGER: 17
IP-MIB::ipAddressIfIndex.ipv4."100.100.100.2".2 = INTEGER: 2
IP-MIB::ipAddressIfIndex.ipv4."100.100.100.100".14 = INTEGER: 14
IP-MIB::ipAddressIfIndex.ipv4."100.102.5.154".10 = INTEGER: 10
IP-MIB::ipAddressIfIndex.ipv4."127.0.0.1".14 = INTEGER: 14
IP-MIB::ipAddressIfIndex.ipv4."184.161.64.220".1 = INTEGER: 1
IP-MIB::ipAddressIfIndex.ipv4."192.168.1.1".11 = INTEGER: 11
snmpwalk -v3 -l authPriv -u obssnmpread -a SHA -A "asdasffsdfsdfs" -x AES -X "asdasffsdfsdfs" fw01 1.3.6.1.2.1.4.34.1.3
iso.3.6.1.2.1.4.34.1.3.1.4.10.10.10.1.6 = INTEGER: 6
iso.3.6.1.2.1.4.34.1.3.1.4.10.10.200.1.15 = INTEGER: 15
iso.3.6.1.2.1.4.34.1.3.1.4.10.10.250.1.13 = INTEGER: 13
iso.3.6.1.2.1.4.34.1.3.1.4.10.10.254.1.43 = INTEGER: 43
iso.3.6.1.2.1.4.34.1.3.1.4.10.10.255.1.23 = INTEGER: 23
iso.3.6.1.2.1.4.34.1.3.1.4.10.100.0.1.34 = INTEGER: 34
iso.3.6.1.2.1.4.34.1.3.1.4.10.128.4.1.9 = INTEGER: 9
iso.3.6.1.2.1.4.34.1.3.1.4.10.130.0.1.35 = INTEGER: 35
iso.3.6.1.2.1.4.34.1.3.1.4.10.130.1.1.37 = INTEGER: 37
iso.3.6.1.2.1.4.34.1.3.1.4.10.130.255.1.39 = INTEGER: 39
iso.3.6.1.2.1.4.34.1.3.1.4.10.150.2.1.7 = INTEGER: 7
iso.3.6.1.2.1.4.34.1.3.1.4.10.253.255.254.36 = INTEGER: 36
iso.3.6.1.2.1.4.34.1.3.1.4.10.255.11.1.12 = INTEGER: 12
iso.3.6.1.2.1.4.34.1.3.1.4.10.255.18.1.61 = INTEGER: 61
iso.3.6.1.2.1.4.34.1.3.1.4.10.255.19.1.63 = INTEGER: 63
iso.3.6.1.2.1.4.34.1.3.1.4.100.100.99.1.18 = INTEGER: 18
iso.3.6.1.2.1.4.34.1.3.1.4.100.100.99.5.21 = INTEGER: 21
iso.3.6.1.2.1.4.34.1.3.1.4.100.100.99.9.16 = INTEGER: 16
iso.3.6.1.2.1.4.34.1.3.1.4.100.100.99.13.17 = INTEGER: 17
iso.3.6.1.2.1.4.34.1.3.1.4.100.100.100.2.2 = INTEGER: 2
iso.3.6.1.2.1.4.34.1.3.1.4.100.100.100.100.14 = INTEGER: 14
iso.3.6.1.2.1.4.34.1.3.1.4.100.102.5.154.10 = INTEGER: 10
iso.3.6.1.2.1.4.34.1.3.1.4.127.0.0.1.14 = INTEGER: 14
iso.3.6.1.2.1.4.34.1.3.1.4.184.161.64.220.1 = INTEGER: 1
iso.3.6.1.2.1.4.34.1.3.1.4.192.168.1.1.11 = INTEGER: 11
But then the mapping done by Observium works for some interfaces, but for other does not and then grabs the wrong information.
SQL[SELECT * FROM `ipv4_addresses` WHERE `device_id` = '44']
SQL RUNTIME[0.00013590s]
SQL[SELECT * FROM `ipv6_addresses` WHERE `device_id` = '44']
SQL RUNTIME[0.00014615s]
---------------------------------------------------------------------------------------
| ifIndex | ifDescr | IP: Version | Address | Network | Type | Origin |
---------------------------------------------------------------------------------------
| 6 | ... | IPv4 | 10.10.1.1/24 | 10.10.1.0/24 | private | |
| 15 | ... | IPv4 | 10.200.1.1/24 | 10.200.1.0/24 | private | |
| 13 | ... | IPv4 | 10.250.1.1/24 | 10.250.1.0/24 | private | |
| 43 | ... | IPv4 | 10.254.1.1/24 | 10.254.1.0/24 | private | |
| 23 | Network-MGMT | IPv4 | 10.255.1.1/24 | 10.255.1.0/24 | private | |
| 34 | ... | IPv4 | 100.0.1.1/24 | 100.0.1.0/24 | unicast | |
| 9 | ... | IPv4 | 128.4.1.1/24 | 128.4.1.0/24 | unicast | |
| 35 | IoT SSID | IPv4 | 130.0.1.1/24 | 130.0.1.0/24 | unicast | |
| 37 | ... | IPv4 | 130.1.1.1/24 | 130.1.1.0/24 | unicast | |
| 39 | ... | IPv4 | 130.255.1.1/24 | 130.255.1.0/24 | unicast | |
| 7 | Network-Service | IPv4 | 150.2.1.1/23 | 150.2.0.0/23 | unicast | |
| 36 | Quarantine Soft Switch | IPv4 | 253.255.254.1/20 | 253.255.240.0/20 | unicast | |
| 12 | Quarantine VLAN | IPv4 | 255.11.1.1/24 | 255.11.1.0/24 | unicast | |
| 61 | Sniffer VLAN | IPv4 | 255.18.1.1/24 | 255.18.1.0/24 | unicast | |
| 63 | NAC Segment VLAN | IPv4 | 255.19.1.1/24 | 255.19.1.0/24 | unicast | |
| 18 | ... | IPv4 | 100.99.1.1/32 | 100.99.1.1/32 | unicast | |
| 21 | ... | IPv4 | 100.99.5.1/32 | 100.99.5.1/32 | unicast | |
| 16 | ... | IPv4 | 100.99.9.1/32 | 100.99.9.1/32 | unicast | |
| 17 | ... | IPv4 | 100.99.13.1/32 | 100.99.13.1/32 | unicast | |
| 2 | ... | IPv4 | 100.100.2.1/30 | 100.100.2.0/30 | unicast | |
| 14 | ... | IPv4 | 100.100.100.1/32 | 100.100.100.1/32 | unicast | |
| 14 | ... | IPv4 | 0.0.1.1/8 | 0.0.0.0/8 | unicast | |
| 10 | ... | IPv4 | 102.5.154.1/30 | 102.5.154.0/30 | unicast | |
| 1 | ... | IPv4 | 161.64.220.1/24 | 161.64.220.0/24 | unicast | |
| 11 | ... | IPv4 | 168.1.1.1/24 | 168.1.1.0/24 | unicast |
---------------------------------------------------------------------------------------
This is complete impossible fix on Observium discovery.
Firmware bug.
They lose the first number of the address and add .1 at end.
Make sure that you use latest firmware for device, because this is seems as firmware bug.
This data come from common IP-MIB and standardized across vendors.
Make and attach discovery debug (as Bot written).
And snmpdump for check if there exist other place(s) with correct IPs.
If this is already latest firmware, than you should write to vendor support about issue.
General questions and device support can be discussed in our Discord channel, click here to join.
Please make and attach additional information about the device:
- full snmp dump from device:
snmpwalk -v2c -c <community> -t 3 -Cc --hexOutputLength=0 -ObentxU <hostname> .1 > myagent.snmpwalksnmpwalk -v2c -c <community> -t 3 -Cc --hexOutputLength=0 -ObentxU <hostname> .1.3.6.1.4.1 >> myagent.snmpwalkIf device not support SNMP version 2c, replace -v2c with -v1.
- If you have problems with discovery or poller processes, please do and attach these debugs:
./discovery.php -d -h <device>./poller.php -d -h <device>
- additionally attach device and/or vendor specific MIB files
This comment is added automatically.
This is a Fortinet bug. They're appending the ifIndex to the end of the IP address for some unfathomable reason. This is not valid for this OID.
You need to contact Fortinet and get them to fix their firmware.
Making duplicate tickets here won't fix Fortinet's firmware.