cfgmaker support for Watchguard devices?
Morten Nilsen <[email protected]> Fri, 5 Jan 2018 15:46:18 +0100
| Newsgroups | gmane.network.mrtg.user |
|---|---|
| Message-ID | <[email protected]> |
Greetings! I've been using MRTG for years, in combination with PHP Weathermap to monitor our infrastructure, and it works great! But I've recently run into a bit of a snag with our firewalls, as I was looking into automating weathermap configuration. When I run cfgmaker on a firewall, it fails to connect the IP information to the proper interface, instead generating configuration like this: ### Interface 16 >> Descr: 'No-Description' | Name: 'No Name' | Ip: '10.61.1.1' | Eth: 'No Ethernet Id' ### ### The following interface is commented out because: ### * got 'No counter exists for 16' from interface when trying to query ### * --ifref=name is not unique for this interface # # Target[wg-jessheim_16]: 16:...@wg-jessheim::60:5::2 # SetEnv[wg-jessheim_16]: MRTG_INT_IP="10.61.1.1" MRTG_INT_DESCR="No-Description" ... ### Interface 131112 >> Descr: 'vlan40' | Name: 'vlan40' | Ip: 'No Ip' | Eth: 'No Ethernet Id' ### Target[wg-jessheim_vlan40]: #vlan40:...@wg-jessheim::60:5::2 noHC[wg-jessheim_vlan40]: yes SetEnv[wg-jessheim_vlan40]: MRTG_INT_IP="No Ip" MRTG_INT_DESCR="vlan40" I reported this to watchguard, but got this response: > In 12.0.1, changes were made to net-snmp to enable fixed OIDs for interfaces. > In previous versions, these values could change on reboot, which had the potential to break SNMP polling of specific interfaces. > After this change, the OIDs of specific interfaces start at 65536. For example, getting link speed on eth0 would use OID 1.3.6.1.2.1.2.2.1.5.65536. > > The cfgmaker script appears to make some assumptions about how these OID values are mapped > and it seems to try using information returned by OID 1.3.6.1.2.1.2.2.1.1 (ifindex) to generate specific queries for each interface. > The problem with this is that these values do not map to the same values used in the fixed OIDs, > and causes cfgmaker to fail when retrieving some of the data for the interfaces. > The only real solutions here would be to either create a custom script to properly parse data returned by snmpwalk > when querying the Firebox and generate an MRTG configuration file based on it or modify the cfgmaker script to do this. I would prefer to not run my own custom version of cfgmaker, so was wondering if this might get fixed upstream somehow? -- Cheers, Morten