NetStacksNetStacks

SNMP Communities

Store SNMPv2c community strings on a credential profile and use them for network discovery and live interface polling in NetStacks.

Overview

NetStacks supports SNMP version 2c for read-only network discovery and live interface polling. SNMP community strings are stored on a credential profile, encrypted at rest in the same vault that holds the profile's SSH password and key passphrase. A single profile can hold multiple community strings; during discovery they are tried in order until one answers.

SNMP is used for two things in NetStacks: walking a device's LLDP/CDP neighbor tables to build topology during discovery, and reading interface counters for the live SNMP interface quick-look. SNMP is never used to change device configuration — all writes happen over SSH.

  • SNMPv2c community strings only (no SNMPv1 or SNMPv3 user-based security)
  • Multiple communities per profile, tried in order during discovery
  • Stored encrypted in the vault alongside the profile's SSH secrets
  • Used for LLDP/CDP neighbor discovery and live interface counter polling
  • Reaches devices over UDP/161 directly, or runs net-snmp CLI tools on a jump host when the target is only reachable through a bastion
SNMPv2c only

NetStacks does not implement SNMPv1 or SNMPv3. If your security posture requires authenticated/encrypted SNMP, restrict SNMPv2c to a dedicated read-only management VRF or ACL on the device side, and avoid exposing community strings on production data paths.

How It Works

SNMPv2c uses a single community string as a shared secret. The string is sent in plaintext with every request, so anyone who can observe UDP/161 traffic can read it. NetStacks therefore treats community strings as secrets: they are stored encrypted in the vault and decrypted in memory only when a query is sent.

Where community strings live

Community strings are a property of a credential profile, not a standalone credential object. On the profile's SNMP tab you add one or more community strings. They are serialized into the profile's encrypted credential blob (alongside password and key_passphrase) and never returned to the UI in cleartext — the editor only shows how many communities are configured.

Direct vs. via-jump

SNMP is UDP, and SSH port-forwarding only tunnels TCP, so NetStacks has two code paths for reaching a device:

PathHow it worksWhen it is used
DirectPure-Rust UDP socket from the NetStacks agent to host:161Target is reachable directly from the machine running NetStacks
Via jumpOpens an SSH exec channel on the jump host and runs net-snmp's snmpget / snmpwalk there, parsing stdoutTarget is only reachable through a bastion / jump host
Community visibility on the jump host

On the via-jump path the community string is passed as a CLI argument to snmpget/snmpwalk, so it is briefly visible to anyone with ps access on the jump host. Use jump hosts with tight access control for this reason.

What gets queried

To confirm a community works, NetStacks issues a GET for sysName.0 (OID 1.3.6.1.2.1.1.5.0). For discovery it then walks the LLDP-MIB and Cisco CDP-MIB neighbor tables, and reads sysDescr.0 (1.3.6.1.2.1.1.1.0) for the platform string. Interface polling walks the IF-MIB (ifDescr, ifHCInOctets, ifOperStatus, and related counters).

Adding Community Strings

Community strings are added on the SNMP tab of a credential profile. The same profile can also hold SSH credentials — SNMP and SSH coexist on one profile.

  1. Open the profile editor (create a new profile or edit an existing one)
  2. Switch to the SNMP tab
  3. Type a community string in the input (for example net-ro) and press Enter or click the add button
  4. Repeat to add more communities — order matters, since discovery tries them top to bottom
  5. Save the profile; the communities are encrypted into the vault
Avoid default community strings

Never rely on public or private. These are the factory defaults on most devices and the first values an attacker tries. Configure a strong, unique read-only community on your devices and use that.

Replacing existing communities

In edit mode the editor shows a count of how many communities are already stored but cannot display the cleartext values. If you add any new communities and save, the saved list replaces the existing set rather than appending to it.

Configure the matching community on the device

The community string on the profile must match what is configured on the target device. Examples for two common platforms:

cisco-snmpv2c.txttext
! Cisco IOS / IOS-XE: read-only community restricted by an ACL
ip access-list standard SNMP-RO
 permit 10.0.0.0 0.0.0.255
!
snmp-server community net-ro RO SNMP-RO
junos-snmpv2c.txttext
# Juniper Junos: read-only community restricted by client list
set snmp community net-ro authorization read-only
set snmp community net-ro clients 10.0.0.0/24

Discovery & Interface Polling

Neighbor discovery

When a discovery run includes the SNMP method, NetStacks resolves the profile's community list and, for each target, tries every community in order. The first community that returns a value for sysName.0 wins; NetStacks then walks the device's LLDP-MIB and Cisco CDP-MIB neighbor tables to learn adjacent devices and link endpoints. The discovery method is reported as snmp-lldp or snmp-cdp depending on which table produced neighbors. If no community answers, that target is skipped for SNMP and other configured methods (such as CLI) are tried.

Live interface quick-look

Inside a terminal session you can right-click an interface name to open the SNMP interface quick-look. It polls the IF-MIB counters for that interface twice and computes throughput from the two samples, using 64-bit high-capacity counters (ifHCInOctets/ifHCOutOctets) where available. If the session has a jump configured, the quick-look routes through the bastion using net-snmp CLI on the jump host, matching how the session itself reaches the device.

One profile, two uses

Because the communities live on the credential profile, the same set is used both for discovery topology building and for the interface quick-look on sessions that use that profile — you configure them once.

Code Examples

These examples reproduce, from the command line, the same queries NetStacks performs internally. They are useful for confirming a community string and ACL before adding it to a profile.

Confirm a community (the sysName.0 probe)

confirm-community.shbash
# NetStacks confirms a community by GETting sysName.0 (1.3.6.1.2.1.1.5.0).
# Reproduce it with net-snmp:
snmpget -v2c -c net-ro -On 10.0.1.1 1.3.6.1.2.1.1.5.0
# .1.3.6.1.2.1.1.5.0 = STRING: core-rtr-01

# Read the platform string (sysDescr.0) the same way:
snmpget -v2c -c net-ro 10.0.1.1 1.3.6.1.2.1.1.1.0
# SNMPv2-MIB::sysDescr.0 = STRING: Cisco IOS XE Software, Version 17.x

Walk neighbor and interface tables

walk-tables.shbash
# LLDP remote system names (LLDP-MIB) — used for neighbor discovery
snmpwalk -v2c -c net-ro 10.0.1.1 1.0.8802.1.1.2.1.4.1.1.9

# Cisco CDP cache device IDs (CDP-MIB) — fallback neighbor source
snmpwalk -v2c -c net-ro 10.0.1.1 1.3.6.1.4.1.9.9.23.1.2.1.1.6

# Interface descriptions (IF-MIB ifDescr) — used by the interface quick-look
snmpwalk -v2c -c net-ro 10.0.1.1 1.3.6.1.2.1.2.2.1.2
# IF-MIB::ifDescr.1 = STRING: GigabitEthernet0/0/0
# IF-MIB::ifDescr.2 = STRING: GigabitEthernet0/0/1

# 64-bit interface counters (IF-MIB ifHCInOctets / ifHCOutOctets)
snmpwalk -v2c -c net-ro 10.0.1.1 1.3.6.1.2.1.31.1.1.1.6
snmpwalk -v2c -c net-ro 10.0.1.1 1.3.6.1.2.1.31.1.1.1.10

Reproduce the via-jump path

via-jump.shbash
# When a device is reachable only through a bastion, NetStacks runs
# net-snmp on the jump host. You can reproduce that manually:
ssh bastion.example.net "snmpget -v2c -c net-ro -On -t 5 -r 1 10.0.1.1:161 1.3.6.1.2.1.1.5.0"
# .1.3.6.1.2.1.1.5.0 = STRING: core-rtr-01

Questions & Answers

Q: What SNMP versions does NetStacks support?
A: SNMP version 2c only. NetStacks does not implement SNMPv1 or SNMPv3 (no user-based security, no auth/priv keys). Community strings are the only SNMP credential.
Q: Where do I configure SNMP community strings?
A: On the SNMP tab of a credential profile. Add one or more community strings, then save — they are encrypted into the vault alongside the profile's SSH secrets. There is no separate "SNMP credential" object.
Q: Why can I add more than one community string?
A: During discovery NetStacks tries each community in order until one answers a sysName.0 probe. This lets one profile cover a fleet with mixed communities (for example a legacy and a current read-only string) without creating separate profiles.
Q: What is SNMP used for in NetStacks?
A: Read-only operations: walking LLDP-MIB and Cisco CDP-MIB neighbor tables during discovery to build topology, reading sysName/sysDescr, and polling IF-MIB interface counters for the live interface quick-look. Configuration changes always go over SSH, never SNMP.
Q: How does NetStacks poll a device that is behind a jump host?
A: SNMP is UDP and SSH only forwards TCP, so for via-jump targets NetStacks opens an SSH exec channel on the bastion and runs net-snmp's snmpget/snmpwalk there, then parses stdout. The community is passed as a CLI argument on the jump, so use bastions with tight access control.
Q: Can I see the stored community strings later?
A: No. The profile editor shows only a count of configured communities, never the cleartext. If you add new communities and save in edit mode, the new list replaces the existing one rather than appending.
Q: Why should I avoid public and private?
A: They are factory defaults on most devices and the first values attackers try when scanning. Configure a unique read-only community on your devices and restrict it with an ACL/client list, then store that on the profile.

Troubleshooting

No SNMP response (timeout)

  • Confirm reachability: ping 10.0.1.1, and that UDP/161 is open (nc -zuv 10.0.1.1 161)
  • Verify SNMP is enabled on the device: show snmp on Cisco, show snmp community on Juniper
  • Check device-side ACLs / client lists — the source IP doing the polling (the NetStacks host, or the jump host on the via-jump path) must be permitted
  • Community strings are case-sensitive — verify an exact match
probe-timeout.shbash
# Reproduce the exact probe NetStacks uses, with verbose output:
snmpget -v2c -c net-ro -On -t 5 -r 1 10.0.1.1 1.3.6.1.2.1.1.5.0
# "Timeout: No Response from 10.0.1.1" => unreachable, blocked, or wrong community/ACL

Discovery skips SNMP for a target

If discovery logs that SNMP is being skipped, the profile likely has no community strings configured. Open the profile's SNMP tab and confirm at least one community is present and saved. If communities are present but none answer the sysName.0 probe, NetStacks moves on to other configured methods (such as CLI) for that target.

Via-jump SNMP fails but direct works (or vice-versa)

  • The via-jump path requires net-snmp (snmpget/snmpwalk) installed on the jump host — confirm with ssh bastion which snmpget
  • ACLs differ by source: a direct poll comes from the NetStacks host, a via-jump poll comes from the bastion. Permit whichever source applies
  • UDP/161 must be reachable from the jump host to the target on the via-jump path

A device stopped responding

  • Verify SNMP config survived a reboot: show running-config | include snmp
  • Check for a newly added ACL restricting SNMP to specific source IPs
  • Confirm the community on the profile still matches the device

Explore related credential, discovery, and topology features: