🔬PDU-Debugger

Wähle eine Operation, schicke sie an den simulierten Agenten gw1.example.org und verfolge jeden Schritt – von der PDU über die Bytes auf der Leitung bis zur Ausgabe. Alles wird im Browser berechnet.

Version

OIDs (eine pro Zeile)

Schritt 1 / 6

1 · Manager baut die GetRequest-PDU

$ snmpget -v2c -c public 192.0.2.10 SNMPv2-MIB::sysUpTime.0 SNMPv2-MIB::sysName.0 SNMPv2-MIB::sysName

request-id

4711

error-status

0 (noError)

error-index

#	name (OID)	value
1	SNMPv2-MIB::sysUpTime.0 .1.3.6.1.2.1.1.3.0	NULL
2	SNMPv2-MIB::sysName.0 .1.3.6.1.2.1.1.5.0	NULL
3	SNMPv2-MIB::sysName .1.3.6.1.2.1.1.5	NULL

🧬 BER-Explorer

GetRequest68 Bytes17 TLV-Elemente

0000

0010

0020

0030

0040

TagLängeWert

30SEQUENCE· Message

Länge: 42 = 66 Byte

Position: Byte 0–67 · enthält 3 Element(e)

📐Aufbau einer SNMPv1/v2c-Nachricht

30 LL                 SEQUENCE  Message
   02 01 01           INTEGER   version  (0 = v1, 1 = v2c)
   04 06 70 75 …      OCTET STR community „public“
   A0 LL              GetRequest-PDU  (A1 GetNext, A2 Response, A3 Set,
                                       A5 GetBulk, A6 Inform, A7 Trap)
      02 01 01        INTEGER   request-id
      02 01 00        INTEGER   error-status   | non-repeaters
      02 01 00        INTEGER   error-index    | max-repetitions
      30 LL           SEQUENCE  variable-bindings
         30 LL        SEQUENCE  VarBind
            06 08 2B 06 01 02 01 01 01 00    OID  1.3.6.1.2.1.1.1.0
            05 00     NULL  (in Anfragen ist der Wert leer)

📎 Quellen: RFC 1157 – SNMPv1 · RFC 1901 – Community-based SNMPv2 (v2c) · RFC 3416 – Protokolloperationen (PDUs) · RFC 3417 – Transport-Mappings

🔢OID-Kodierung: 40·x + y und Base-128

Die ersten beiden Bögen werden zu einem Byte zusammengefasst: 1.3 → 40 · 1 + 3 = 43 = 0x2B. Deshalb beginnt fast jede SNMP-OID im Paket mit 2B.
Jeder weitere Bogen wird in 7-Bit-Gruppen zerlegt. Bit 8 = 1 heißt „es folgt noch ein Byte“: 8072 = 63 · 128 + 8 → BF 08, 2021 = 15 · 128 + 101 → 8F 65.
INTEGER ist vorzeichenbehaftet: Ein Counter32 mit gesetztem Höchstbit braucht ein führendes 00 – 3 984 523 411 wird zu 41 05 00 ED 7F 00 93.
Längen unter 128 passen in ein Byte. Darüber kommt die lange Form: 81 9B = 155 Bytes, 82 05 DC = 1500 Bytes.

📎 Quellen: RFC 3417 – Transport-Mappings · RFC 2578 – SMIv2

🚶Walk-Simulation: GetNext-Kette vs. GetBulk

snmpwalk schickt so lange GetNext-Anfragen, bis eine Antwort außerhalb des Start-Teilbaums liegt oder der Agent endOfMibView meldet. snmpbulkwalk holt mit GetBulk bis zu max-repetitions Nachfolger pro Anfrage. Durchgestrichen: Werte, die schon hinter dem Teilbaum liegen und verworfen werden.

Start-OID

Verfahren

Anfragen (Round Trips)

mit GetBulk: 4

Werte im Teilbaum

Bytes gesamt (Anfragen + Antworten)

3.270

$ snmpwalk -v2c -c public 192.0.2.10 IF-MIB::ifTable

#1GetNextRequest IF-MIB::ifTable→ 1 Varbind(s)

IF-MIB::ifIndex.1 = INTEGER: 1

Zu großes max-repetitions

Passt die Antwort nicht in die maximale Nachrichtengröße, kürzt der Agent die Varbind-Liste der GetBulk-Antwort (RFC 3416, 4.2.3) – manche Geräte antworten aber auch mit tooBig oder gar nicht. Werte zwischen 10 und 50 sind ein üblicher Kompromiss.

📎 Quellen: RFC 3416 – Protokolloperationen (PDUs) · snmpwalk(1) / snmpbulkwalk(1)