Hello Net‑SNMP community,
I’m new to SNMP, and I’ve been investigating a syslog error “tcpListenerTable
insert failed”.
This appears when running snmpwalk on the TCP‑MIB tables (specifically
tcpListenerTable). The agent is running snmpd9.5.3.
Background: container index collisions
The MIB index is built from:
* AFI (InetAddressType)
* address bytes (4 for IPv4, 16 for IPv6)
* local port
Because the container uses only (AFI, address, port) as the key, certain
Linux/SONiC scenarios naturally produce collisions—for example when both the
host and a VRF have wildcard listeners for the same service:
LISTEN 0 512
0.0.0.0%Vrf-1:179 0.0.0.0:*
users:(("bgpd",pid=32190,fd=23))
LISTEN 0 512 0.0.0.0:179
0.0.0.0:*
users:(("bgpd",pid=32190,fd=26))
Since RFC 4022 does not include a VRF/namespace field in the TCP‑MIB indices,
these entries collapse into the same SNMP key. Therefore:
* CONTAINER_INSERT() fails for the duplicate row
* snmpwalk still completes normally, returning one row per distinct MIB
index
This behavior makes sense and aligns with the MFD model.
While studying the code, I noticed that duplicat-sert failures are logged
differently depending on the table:
In tcpConnectionTable_data_access.c, when CONTAINER_INSERT() fails due to a
duplicate, it logs:
NETSNMP_LOGONCE((LOG_DEBUG,
"Error inserting entry to tcpConnectionTable, entry already exists.\n"));
While in tcpListenerTable_data_access.c, for the same scenario (same key,
failed insert), the code logs:
snmp_log(LOG_ERR, "tcpListenerTable insert failed.\n");
Is there a specific reason why tcpConnectionTable uses a one‑time LOG_DEBUG
message for duplicate inserts, while tcpListenerTable logs these cases as
LOG_ERR, even though both failures arise from the same type of duplicate key
condition?
I’m trying to understand whether this difference is intentional or simply
historical—and whether it would make sense to align tcpListenerTable with the
more conservative logging behavior used in tcpConnectionTable.
Thanks for your time.
Best regards,
Bing
Internal Use - Confidential
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
