Blogposts tagged snmpf.zz.dehttps://f.zz.de/tags/snmp/f.zz.deikiwiki2017-03-07T14:28:56ZRandom number generatorhttps://f.zz.de/posts/201703071316.random_number_generator/Florian Lohoff2017-03-07T14:28:56Z2017-03-07T12:16:14Z
<p>Es ist schon spannend wie man sich so die Karten legen kann und das
monatelang nicht findet. Ich habe für das Monitoring mit Icinga2
einen interface check in c++ geschrieben der alle möglichen Dinge
pollt. D.h. nicht nur die Standard ifAdminStatus oder ifOperStatus
sondern auch ifIn/OutPackets, Bytes, Errors, Discards etc. Dann
gibt es Schwellwerte die überwacht werden. Zusätzlich polle ich noch
die optischen Pegel der SFPs d.h. rxPower, txPower, Current und
Temperature.</p>
<p>Das ganze fliesst dann über eine Influxdb in ein Grafana um es sich
ansprechend ansehen zu können.</p>
<p>Leider hatte ich seit dem Umzug von einer VM auf richtige Hardware
das Problem das immer wieder sporadisch Messwerte fehlten oder auch
auch mal kaputt waren d.h. eindeutig falsche Messwerte.
Die Fehlermeldungen die ich jedoch sah war "SNMP Timeout" als
wenn das Gerät nicht antworten würde.</p>
<p>Also mit tcpdump mal nachgesehen und nein - Es werden alle
requests beantwortet. Nach einer Schleife mit der SNMP library
snmp++, in der das timeout handling auch noch kaputt war, war ich
noch ratloser als vorher.</p>
<p>Bis ich heute mal debug logging eingebaut habe und feststellte das zu dem
Zeitpunkt wenn die SNMP Timeouts auftreten alle Requests für das Device
eine identische RequestID haben.</p>
<p>Die RequestID wird typischerweise dafür verwendet, das das Target
retransmits erkennen kann. D.h. sollte es einen SNMP Request bekommen
wird die Antwort erzeugt und diese Antwort zusammen mit der RequestID
in einen cache gepackt. Sollte dann ein transmit kommen wird der
request mit der Antwort aus dem cache beantwortet um ein
paar CPU cycles zu sparen.</p>
<p>Wenn jetzt natürlich unterschiedliche Interfaces und EntitySensors
gepollt werden, und alle mit einer identischen RequestID, dann kommen
natürlich willkürliche Antworten zurück, je nachdem welcher Request
zuerst bearbeitet wurde.</p>
<p>Wenn die Anzahl der Variable bindings aber nicht passt wird jedoch
natürlich die Antwort verworfen.
Wenn jedoch die Antwort passt d.h. es ist auch Interface oder auch
ein EntitySensor werden die Daten durcheinandergewürfelt.
TengigabitEthernet0/0/1/0 daten tauchen dann auf
TengigabitEthernet0/2/3/2 auf ... Das alles absolut unvorhersagbar
und willkürlich.</p>
<p>Des Rätsels Lösung war, das der random number generator initialisiert
werden muss. In Wirklichkeit ist das ja nur ein "Pseudo Random Number
Generator" PRNG. Dieser erzeugt für ein Seed immer dieselbe Reihe an
Zufallszahlen.</p>
<p>Wenn man den Random Number Generator jetzt mit "time(0)" initialisiert,
kommt natürlich für alle Prozesse die in derselben Sekunde gestartet
werden identische Zufallszahlen bei raus. Es fehlt an Entropie.</p>
<p>Der schnelle fix ist ein</p>
<pre><code>std::srand(std::time(0)^getpid());
</code></pre>
<p>gewesen. Der nimmt dann nicht nur die Zeit sondern ein XOR zwischen Zeit
und Process ID. Immer noch nicht optimal, aber zumindest fixed es das
Problem das zeitgleich gestartete Prozesse identische Zufallszahlen
verwenden.</p>
Printer discovery in 2016https://f.zz.de/posts/201609201445.printer_discovery_in_2016/Florian Lohoff2016-09-20T13:03:06Z2016-09-20T12:45:23Z
<p>Ist das echt euer ernst? Printer Autodiscovery durch SNMP get
request an die Broadcast Adresse? Ich dachte dafür gibt
es SSDP über Port 1900 UDP oder IPP UDP Port 631:</p>
<pre><code>14:42:15.866096 IP (tos 0x0, ttl 64, id 8379, offset 0,
flags [DF], proto UDP (17), length 71)
192.168.1.198.44285 > 192.168.1.255.161:
{ SNMPv1 { GetRequest(28) R=1 .1.3.6.1.2.1.25.3.2.1.2.1 } }
14:42:15.867962 IP (tos 0x0, ttl 64, id 43867, offset 0,
flags [none], proto UDP (17), length 80)
192.168.1.3.161 > 192.168.1.198.44285:
{ SNMPv1 { GetResponse(37) R=1 .1.3.6.1.2.1.25.3.2.1.2.1=
.1.3.6.1.2.1.25.3.1.5 } }
</code></pre>
Juniper SSG aka Netscreenhttps://f.zz.de/posts/201606161451.juniper_ssg_aka_netscreen/Florian Lohoff2016-06-16T13:14:54Z2016-06-16T12:51:01Z
<p>Auch nach Jahren des Netzwerkmanagements finden sich doch immer
mal wieder neue spannende Dinge. Da fällt mir so ein antiquarisches
Pärchen SSG550M auf die Füße. Na gut - Config Backup war in 3 Minuten
gegessen. Dann noch schnell den export ins Icinga2 und plumps - Da sind
doch interfaces rot - Was ist denn das? Scheinbar gehen beim Standby Peer
des SSG Clusters die ifOperStatus values von up(1) auf testing(3).</p>
<p>Testing ist nicht up - also schmeisst mein Icinga check ein CRITICAL...</p>
<pre><code>~# snmpwalk -v2c -c public ssg-host.dom.ain ifOperStatus
IF-MIB::ifOperStatus.1 = INTEGER: testing(3)
IF-MIB::ifOperStatus.2 = INTEGER: testing(3)
IF-MIB::ifOperStatus.3 = INTEGER: testing(3)
IF-MIB::ifOperStatus.4 = INTEGER: testing(3)
[ ... ]
</code></pre>
ifHCInMulticastPkts & Cohttps://f.zz.de/posts/201602011159.ifhcinmulticastpkts__co/Florian Lohoff2016-02-01T11:04:08Z2016-02-01T10:59:36Z
<p>Es ist erstaunlich wieviele Interfaces zwar HC Counter haben d.h.
<code>ifHCInOctets</code> und Co - aber die entsprechenden Counter
für Broad und Multicast traffic nicht:</p>
<pre><code>Feb 1 11:18:55 nagios checkif[6238]: 172.55.63.1 TenGigE0/0/1/2.343 Invalid value: ifHCInMulticastPkts.20567 =
Feb 1 11:18:55 nagios checkif[6238]: 172.55.63.1 TenGigE0/0/1/2.343 Invalid value: ifHCInBroadcastPkts.20567 =
Feb 1 11:18:55 nagios checkif[6238]: 172.55.63.1 TenGigE0/0/1/2.343 Invalid value: ifHCOutMulticastPkts.20567 =
Feb 1 11:18:55 nagios checkif[6238]: 172.55.63.1 TenGigE0/0/1/2.343 Invalid value: ifHCOutBroadcastPkts.20567 =
</code></pre>
<p>Ich habe die immer wie selbstverständlich mit gepollt
wenn entsprechenden HC Counter supported waren. Das war wohl ein
trugschluss. Auch verstehe ich nicht warum gerade auf den modernen
Plattformen wie ASR9k/IOS-XR <code>ifInUnknownProtos</code> scheinbar
unsupported ist - Selbst im <code>show interface</code> wird das angezeigt.</p>
Neulich in einer SNMP MIBhttps://f.zz.de/posts/201502051117.neulich_in_einer_snmp_mib/2015-02-05T10:57:55Z2015-02-05T10:17:18Z
<p>Neulich in einer MIB von Alcatel-Lucent für deren Switche:</p>
<blockquote><p>The current temperature reading in degrees celsius from this hardware
component's temperature sensor. If this component does not contain
a temperature sensor, then the value -1 is returned.</p></blockquote>
<p>Als hätten die noch nie von "noSuchOid" gehört. Somit sind bei uns in einer
Outdoorlokation die Temperaturen um den Gefrierpunkt nicht mehr von einem nicht
existierenden Temperatursensor zu unterscheiden.</p>
<p>Un-glaub-lich</p>
IOS-XR SNMP Bugshttps://f.zz.de/posts/201412160547.ios-xr_snmp_bugs/2014-12-16T04:53:07Z2014-12-16T04:47:31Z
<p>Bei einem change finden sich ja immer mal wieder nette Bugs.
Heute - SNMP Antwort auf etwas was ich gar nicht gefragt habe.</p>
<pre><code>$ snmpget -c public -v 2c asr9k-corerouter ipv6IfAdminStatus.77
IPV6-MIB::ipv6IfAdminStatus.79 = INTEGER: up(1)
</code></pre>
<p>Ich habe nach dem interface instance .77 gefragt und bekomme
für das interface .79 die Antwort. Das ist eigentlich absolut
unüblich. Wenn nach einer oid gefragt wird die nicht existiert wird
das exact so signalisiert.</p>
<pre><code>$ snmpget -c public -v 2c asr9k-corerouter ifName.1
IF-MIB::ifName.1 = No Such Instance currently exists at this OID
</code></pre>
<p>Das führt dazu das wir im moment im IPv6 teilweise murks überwachen,
vor allem auf interfaces die KEIN IPv6 enabled haben überwachen
wir das "nächste" interface. Damit kriegen wir potentiell 2 Alarme
wenn auf einem interface das v6 wegfällt.</p>
<p>Das ganze ist IOS XR Version 4.3.2 - Danke Cisco.</p>
Alcatel und Bugshttps://f.zz.de/posts/201309191354.alcatel_und_bugs/2013-09-19T11:58:19Z2013-09-19T11:54:43Z
<p>Auslesen von DSL Parametern über SNMP hätte ich jetzt fuer pflicht
gehalten. Scheinbar ist das Kür. Der DSLAM möchte nicht immer
sowas wie "AttainableRate" oder "AttenuationDownstream" rausgeben.
Das kommt auf Mondstand oder Windrichtung an. Wenn aber was schief
geht dann kann man in der AttenuationDownstream schön eine value
von 1270 auslesen - Na ? Kommt euch bekannt vor? 127 ? -1 im char ?</p>
<p>Bug ist seit ende July offen - Heute die Antwort - Ich soll doch
was anderes auslesen und die andere Tabelle hätte aber andere
instances. Häh?</p>
<p>Leute - Ihr habt ein Problem die Daten von eurer Linecard auf die
Controlengine zu bekommen - bzw in den SNMP Stack - Auf der command
line sieht man die werte alle Richtig - Warum nicht im SNMP?</p>
<p>Von exemplarischen 36 Ports liefern 9 keine Werte - Schlechter schnitt.</p>
libsnmp-session-perl hang on walkhttps://f.zz.de/posts/201304151324.libsnmp-session-perlhangonwalk/2013-04-15T11:26:22Z2013-04-15T11:24:59Z
<p>Auf einem der Eltek Netzteile die wir jetzt leider bekommen haben einen walk mit
libsnmp-session-perl auf die ifName table gemacht und gleich gehangen.</p>
<p><a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705461">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705461</a></p>