SNMP TCP / UDP / IP OIDs: Stack Counter Reference

By the SNMP Monitoring team · Reviewed July 2026

Below the interface counters sits another layer of standard telemetry: the protocol stack itself. The TCP-MIB, UDP-MIB, and IP-MIB expose how many connections are open, how many segments are being retransmitted, how many datagrams hit closed ports, and how many packets the IP layer is discarding. These are the counters that diagnose the problems interface stats can't see — a host drowning in retransmits, a service hammered with UDP to nowhere, an IP layer quietly dropping traffic. This page is the paste-ready reference for all three.

For the interface layer, see interface OIDs and the network monitoring how-tos. Hubs: sensors, all OIDs.

TCP-MIB objects

The TCP-MIB (RFC 4022) sits at 1.3.6.1.2.1.6. The scalars you'll reach for:

tcpCurrEstab is a gauge — the live count of established connections, read directly. The rest are counters you diff. tcpRetransSegs is the diagnostic gem: a rising retransmit rate points at packet loss or congestion between this host and its peers.

UDP-MIB objects

The UDP-MIB (RFC 4113) sits at 1.3.6.1.2.1.7:

• udpInDatagrams — 1.3.6.1.2.1.7.1.0 — datagrams delivered to UDP users (Counter32).
• udpNoPorts — 1.3.6.1.2.1.7.2.0 — datagrams received for a port with no listener (Counter32).
• udpInErrors — 1.3.6.1.2.1.7.3.0 — datagrams that couldn't be delivered for other reasons (Counter32).

udpNoPorts climbing is a useful signal — it means traffic is arriving for ports nothing is listening on, which can indicate a misconfigured client, a dead service, or scanning. udpInErrors rising suggests buffer or checksum problems on inbound UDP.

IP-MIB objects

The IP-MIB (RFC 4293) at 1.3.6.1.2.1.4 carries the network-layer totals — packets in, discarded, and forwarded:

• ipInReceives — total inbound packets the IP layer received.
• ipInDiscards — inbound packets discarded despite no error (e.g. buffer full).
• ipForwDatagrams — packets forwarded (relevant on routers and hosts doing forwarding).

These are cumulative scalar counters. ipInDiscards climbing is the one to watch — like interface discards, it means valid packets are being dropped for lack of resources, which points at a capacity or tuning problem rather than a wire fault.

What to alert on

The theme across all three MIBs: these are cumulative Counter32 objects (except the tcpCurrEstab gauge), so you alert on rates and ratios, never lifetime totals. Practical signals:

• TCP retransmit ratio — tcpRetransSegs rate against total segments sent; a rising ratio flags loss/congestion.
• UDP no-ports rate — udpNoPorts climbing means traffic to dead ports; investigate the source or the missing listener.
• UDP/IP error and discard rates — udpInErrors, ipInDiscards rising means the stack is dropping traffic under load.
• Established-connection trend — tcpCurrEstab far above baseline can mean a connection leak or a flood; far below can mean a service down.

A lifetime tcpRetransSegs of two million means nothing on its own — a box up for a year will accumulate that harmlessly. What matters is how fast it's climbing now relative to traffic.

It's worth being clear about what these stack counters give you that interface counters can't, because that's the whole reason to poll them. The IF-MIB tells you a link is passing bytes and whether the wire is clean; it says nothing about whether the conversations riding that link are healthy. A gigabit uplink can show zero interface errors while the host on the end is retransmitting a tenth of its TCP segments because of loss somewhere upstream, a congested peer, or an overloaded application. That mismatch — clean interfaces, unhappy sessions — is exactly the blind spot the transport counters fill. tcpRetransSegs climbing against a flat ifInErrors points you past the local wire toward path loss or a remote problem. ipInDiscards rising while interfaces look fine points at the host's own buffers or tuning, not the network. And udpNoPorts climbing tells you something is talking to this box on ports nothing answers — a story no interface counter will ever tell. Reaching for these when the interface layer looks innocent is what turns "the network seems fine but the app is slow" from a shrug into a diagnosis.

Worked snmpwalk example

A sensible reading order when a host looks slow but its interfaces are clean:

1. Read tcpCurrEstab for the live connection count against baseline.
2. Diff tcpRetransSegs across two polls for the retransmit rate.
3. Diff ipInDiscards for network-layer drops under load.
4. Diff udpNoPorts / udpInErrors if UDP services are involved.

Grab the TCP scalars:

snmpget -v2c -c <RO_string> <host> 1.3.6.1.2.1.6.9.0 1.3.6.1.2.1.6.12.0

TCP-MIB::tcpCurrEstab.0 = Gauge32: 148
TCP-MIB::tcpRetransSegs.0 = Counter32: 20514

148 connections established now; retransmits are a counter, so poll again and diff:

snmpget -v2c -c <RO_string> <host> 1.3.6.1.2.1.7.2.0

UDP-MIB::udpNoPorts.0 = Counter32: 88342

<RO_string> is a placeholder; keep live communities out of committed scripts.

Related

Stack counters complement the interface layer: interface octets and errors are on interface OIDs, and the traffic how-tos are under network monitoring. When an interface looks clean but an app is slow, the TCP retransmit and IP discard counters here are often where the answer is. The full index: all sensors; the standards behind these MIBs: standard MIBs; definitions: glossary.

Frequently asked questions

What OID is the TCP connection count?

tcpCurrEstab at 1.3.6.1.2.1.6.9.0 from the TCP-MIB — a Gauge32 with the number of TCP connections currently in the ESTABLISHED state. Because it's a gauge, you read it directly rather than diffing; watch it against a baseline for connection leaks or floods.

What OID shows UDP errors?

udpInErrors at 1.3.6.1.2.1.7.3.0 counts inbound UDP datagrams that couldn't be delivered for reasons other than a missing port. For traffic to ports with no listener, use udpNoPorts (1.3.6.1.2.1.7.2.0). Both are cumulative counters, so alert on the rate of change.

What MIB has IP statistics?

The IP-MIB (RFC 4293) at 1.3.6.1.2.1.4, with scalar counters like ipInReceives, ipInDiscards, and ipForwDatagrams. It reports the network layer's packet totals — received, discarded, and forwarded — which complement the interface-level counters in the IF-MIB.

Should I alert on TCP retransmits?

Yes, but on the rate or ratio, not the total. tcpRetransSegs (1.3.6.1.2.1.6.12.0) only ever climbs, so a big lifetime number is meaningless. Diff it between polls and compare to segments sent — a rising retransmit ratio is a strong early sign of packet loss or congestion.

Key takeaways

• Stack counters live in TCP-MIB (…6), UDP-MIB (…7), IP-MIB (…4) — all standard.
• tcpCurrEstab (…6.9.0) is a gauge (read directly); most others are Counter32 (diff them).
• Key diagnostics: tcpRetransSegs (loss/congestion), udpNoPorts (dead-port traffic), ipInDiscards (drops under load).
• Alert on rates/ratios, never lifetime totals.
• Use these when interfaces look clean but an app is slow — see interface OIDs.
• Catalog: sensors/all; network how-tos: network monitoring.