Seit Jahren zeichne ich minütlich Vitalwerte meiner IT-Infrastruktur auf. Dafür verwende ich das quelloffene cacti, dessen Entwicklung zwar seit mehr als einem Jahr stillsteht, meine Bedürfnisse aber immer noch abdeckt. An der Code-Qualität hege ich meine Zweifel, habe mich bisher aber damit arrangiert, insbesondere weil aus meiner Sicht derzeit keine Alternative zur Verfügung steht. Item!

Seit einigen Monaten habe ich das Netzwerk hier in unserer gemeinsamen Wohnung in Bern mittels OpenVPN mit dem Netzwerk im Elternhaus verbunden. Zum Einsatz kommen zwei Router, welche mit DD-WRT geflasht sind (die Konfiguration von OpenVPN auf diesen Kisten ist eine weitere Pendenz in der Liste der geplanten Blog-Artikel).

Der Linux-Server, auf welchem cacti installiert ist und der Poller läuft, befindet sich im Elternhaus. Meine OpenVPN-Konfiguration hat es nun an sich, dass ich den Router in meiner Wohnung nicht per SNMP abfragen kann, weil dessen interne IP aus dem entfernten Netzwerk nicht ansprechbar ist.

Vor einer Woche hatte ich deshalb die zündende Idee, mich auf die Suche nach einem SNMP-Proxy zu machen, welchen ich auf einem Client im LAN unserer Wohnung aufsetze und mittels cacti via SNMP darüber die SNMP-Werte des Routers abfragen kann. Die Wahl fiel auf meinen Mac mini, auf dem SNMP bereits aktiviert ist und bereits von cacti abgefragt wird.

Nach einigen Recherchen mit Google war rasch klar, dass net-snmp die Funktionalität mit sich bringt, einzelne OIDs oder einen ganzen OID-Baum von einem SNMP-fähigen Drittsystem einzubinden und so als Proxy zu wirken.

Die Anleitungen, die man im Netz findet, sind leider etwas holprig, weshalb ich hier für die Nachwelt festhalten möchte, wie ich das Setup schlussendlich zum Laufen gekriegt habe — im Grunde ist es äusserst simpel:

/etc/snmp/snmpd.conf

(Auf dem Rechner, welcher im selben Subnetz wie der abzufragende Router steht)

...
# Proxy to let remote cacti retrieve local router SNMP information

# Define a simple view 'systemview', which includes everthing under .1.3.6.1
view    systemview     included      .1.3

# Map 'public' community to the 'notConfigUser'
com2sec notConfigUser  default       public

# Map 'notConfigUser' to 'notConfigGroup'
group   notConfigGroup v1            notConfigUser
group   notConfigGroup v2c           notConfigUser

# Give 'notConfigGroup' read access to objects in the view 'systemview'
access  notConfigGroup ""            any       noauth    exact  systemview none none

# v1/v2c community string for each proxied host
com2sec -Cn my_router_int notConfigUser  default       my_router

# Allow the 'notConfigUser' (a member of 'notConfigGroup') access for these contexts
access  notConfigGroup my_router_int        any     noauth  prefix  systemview none none

# Proxy configuration
proxy -Cn my_router_int -v 1 -c public 192.168.168.168 .1.3

Via: [HOWTO] Graph multiple servers using an SNMP proxy

Diese Konfiguration kann problemlos in die eigene Konfiguration eingepflegt werden, anzupassen sind einzig die IP des Routers (hier: 192.168.168.168), der über den Proxy abgefragt werden können soll, sowie dessen Community-Namen (hier fahrlässigerweise public).

Aus ästhetischen und verständlichen Gründen anzupassen sind zudem die Bezeichnungen my_router_int sowie my_router. my_router ist der Community-Name, mit welchem die SNMP-Daten des Drittsystems abgefragt werden können. my_router_int wiederum scheint eine Rolle bei der internen Zugriffsverwaltung zu spielen.

Unter Mac OS X verwende ich das von mir auf Github geteilten Restart-Script, um den SNMP-Server neu zu starten.

Test

Mittels des Tools snmpwalk prüfen wir in einer Shell direkt auf dem Proxy, ob net-snmp den OID-Baum tatsächlich einbindet:

$ snmpwalk -v 1 -c my_router localhost
SNMPv2-MIB::sysDescr.0 = STRING: Linux DD-WRT 3.X.X #110 Sun Mar 24 15:46:47 CET 2013 mips
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (12623972) 1 day, 11:03:59.72
SNMPv2-MIB::sysContact.0 = STRING: user@domain.tld
...

Klappt!

cacti

Schlussendlich muss das neue Gerät noch in cacti erfasst werden. Das stellt den erfahrenen cacti-Benutzer vor keine Probleme, einzig muss darauf geachtet werden, dass man nicht die IP des Routers, sondern diejenige des Proxys und der in snmpd.conf definierte Community-String (im obigen Beispiel -c my_router, also my_router) angibt. Belässt man den Community-Wert auf public frägt man stattdessen die Werte des Proxys selber ab — und nicht diejenigen des zu überwachenden Routers.

Weiterführende Links

Ein ETH-Mitarbeiter hat aufgeschrieben, wie man so etwas via SSH-Tunnel hinkriegt, wenn man keinen VPN-Tunnel hat.