SNMP Device Connectivity & Discovery Troubleshooting Guide
Use this guide when a device fails to connect or return data during SNMP discovery in Motadata ServiceOps.
SNMP (Simple Network Management Protocol) is how ServiceOps communicates with network devices, servers, and other hardware to collect data during discovery. When discovery fails, the cause is almost always one of three things: a network/firewall issue, a wrong credential, or a misconfiguration on the device itself.
This guide walks you through diagnosing and fixing those issues step by step, no advanced networking knowledge required.
Prerequisites
- Collect the following information:
Having these details upfront will save you time:
| # | What you need | Why |
|---|---|---|
| 1 | Device IP address | Target for all tests |
| 2 | Device vendor and model (e.g. Cisco IOS, Fortinet FortiGate) | Determines which device-side commands to run |
| 3 | SNMP version (v2c or v3) | Determines which test commands to use |
| 4 | Credentials — community string (v2c) OR username/auth password/privacy password (v3) | Required for the connection test |
| 5 | ServiceOps server IP | Needed to check firewall and ACL rules |
| 6 | Whether the device was previously working | Helps narrow down what changed |
- Check the SNMP version you are using:
If you're not sure, check Admin > Discovery and Agents > Credentials in ServiceOps and open the credential profile assigned to the device. The version is listed there.
This matters because SNMPv2c and SNMPv3 have different failure modes and different commands.
| Version | How it authenticates | Typical issues |
|---|---|---|
| SNMPv2c | Community string (a shared password) | Wrong community string, firewall blocking UDP/161 |
| SNMPv3 | Username + auth password + privacy password | Wrong username/password, protocol mismatch, missing device view |
- Install the required test tool
You need snmpwalk available on the Motadata ServiceOps server (or any Linux host that can reach the device).
Linux (run on the ServiceOps server):
# RHEL / CentOS / Rocky
yum install net-snmp-utils
# Debian / Ubuntu
apt-get install snmp
# Confirm it's installed
snmpwalk --version
Windows admins: All commands in this guide run on Linux. If your ServiceOps server is Linux-based, SSH into it and run the commands there. If you do not have SSH access, ask your system administrator to run the commands on your behalf, or use Windows Subsystem for Linux (WSL).
- Know about silent failures:
Many SNMP failures produce no error message at all. The device simply returns nothing. From ServiceOps this looks identical to a network problem, but the cause is usually a misconfigured permission on the device. Always run the snmpwalk test in Step 3 to find out whether the device is actually responding.
Diagnostic Workflow
Follow these steps in order. Each step either identifies the problem or tells you where to go next.
1. Check Network Reachability
Before testing SNMP, confirm the ServiceOps server can actually reach the device.
1.1 Ping the device
Run on: ServiceOps server (Linux shell)
ping -c 4 <device_ip>
1.2 Test UDP port 161
Ping uses ICMP, which can succeed even when SNMP traffic (UDP port 161) is blocked by a firewall. Test port 161 directly:
Run on: ServiceOps server (Linux shell)
# Preferred method — uses nmap
nmap -sU -p 161 <device_ip>
# Alternative — netcat
nc -zuv <device_ip> 161
1.3 What the results mean
| Result | What it means | What to do |
|---|---|---|
Ping OK + nmap shows open or open\|filtered | Device is reachable on UDP/161 | Proceed to Step 2 |
Ping OK + nmap shows closed | Device is up but SNMP agent may not be running, or a local firewall is blocking | Check the SNMP service on the device (Step 2) |
Ping OK + nmap shows filtered | A firewall between ServiceOps and the device is silently dropping SNMP traffic | Open UDP/161 in the firewall for the ServiceOps server IP |
| Ping fails + nmap times out | Network or routing issue, or device is offline | Fix network connectivity first |
open|filtered means nmap could not tell whether the port is open or blocked. Continue to Step 3, if snmpwalk succeeds, then the port is open.
2. Check the SNMP Agent on the Device
If port 161 appears closed or if you want to confirm the device is actively running SNMP, verify the SNMP agent status on the device itself.
For Linux/server devices:
Run on: The device (root shell)
systemctl status snmpd
If the service is not running, start it:
systemctl start snmpd
systemctl enable snmpd
For network devices (Cisco, Juniper, etc.):
Log in to the device and run the appropriate command from Step 5 for your vendor. The show snmp or equivalent command will confirm whether SNMP is active and show request/response counters. Run snmpwalk while watching the counters — if the input packets counter does not increment, the device is not receiving the request at all, which points to a firewall or routing issue rather than a credential problem.
3. Test the SNMP Connection Directly
Running snmpwalk from the ServiceOps server is the most reliable way to determine whether the device is responding to SNMP and whether your credentials are correct.
Always start with the system MIB (1.3.6.1.2.1.1). It is small, fast, and supported by virtually every SNMP-capable device.
For SNMPv2c
Run on: ServiceOps server (Linux shell)
snmpwalk -v 2c -c <community_string> <device_ip> 1.3.6.1.2.1.1
# Example
snmpwalk -v 2c -c public 10.1.1.10 1.3.6.1.2.1.1
Replace public with your actual community string (it is case-sensitive).
For SNMPv3
SNMPv3 uses a username, an authentication password, and (optionally) a privacy/encryption password. Match the security level to what is configured on the device:
Run on: ServiceOps server (Linux shell)
# authPriv — authentication + encryption (most common in production)
snmpwalk -v 3 -l authPriv \
-u <username> \
-a <auth_protocol> -A '<auth_password>' \
-x <priv_protocol> -X '<priv_password>' \
<device_ip> 1.3.6.1.2.1.1
# authNoPriv — authentication only, no encryption
snmpwalk -v 3 -l authNoPriv \
-u <username> \
-a <auth_protocol> -A '<auth_password>' \
<device_ip> 1.3.6.1.2.1.1
# noAuthNoPriv — no authentication, no encryption (not recommended)
snmpwalk -v 3 -l noAuthNoPriv -u <username> <device_ip> 1.3.6.1.2.1.1
Flag reference:
| Flag | What it sets | Accepted values |
|---|---|---|
-l | Security level | noAuthNoPriv, authNoPriv, authPriv |
-u | Username | Case-sensitive string |
-a | Auth protocol | MD5, SHA, SHA-256, SHA-512 |
-A | Auth password | String (min 8 characters) |
-x | Privacy (encryption) protocol | DES, AES (= AES-128), AES192, AES256 |
-X | Privacy password | String (min 8 characters) |
-n | Context name | Leave empty unless the device requires one (must match the Context name field in the ServiceOps credential profile) |
Older Net-SNMP builds may not support AES-192/256 or SHA-256/512. Check with snmpwalk --help | grep -iE 'aes|sha'. If the cipher you need is missing, upgrade Net-SNMP or temporarily test with AES-128/SHA to isolate the issue.
Testing devices on slow or remote links
If your device is across a WAN link or under heavy load, the default timeout may be too short and snmpwalk will time out even when the device would respond. Use these flags to extend the wait:
# -t sets timeout in seconds (default: 5), -r sets retry count (default: 1)
snmpwalk -v 2c -c <community_string> -t 15 -r 3 <device_ip> 1.3.6.1.2.1.1
# Same for SNMPv3
snmpwalk -v 3 -l authPriv -u <username> -a SHA -A '<auth_password>' \
-x AES -X '<priv_password>' -t 15 -r 3 <device_ip> 1.3.6.1.2.1.1
If these succeed but the default timeout fails, increase the SNMP timeout and Retries in the ServiceOps credential profile — see Step 6.4.
What a successful response looks like
SNMPv2-MIB::sysDescr.0 = STRING: Cisco IOS Software ...
SNMPv2-MIB::sysObjectID.0 = OID: ...
SNMPv2-MIB::sysUpTime.0 = Timeticks: (123456789) 14 days ...
SNMPv2-MIB::sysName.0 = STRING: switch-01
SNMPv2-MIB::sysLocation.0 = STRING: Server Room A
✅ If you see output like this, the SNMP connection is working. If ServiceOps still fails to discover the device, the issue is in the ServiceOps credential profile, go to Step 6.
❌ If you get an error or no output, go to Step 4.
Useful test OIDs
| OID | What it returns | When to use |
|---|---|---|
1.3.6.1.2.1.1 | Device name, description, uptime | Always start here |
1.3.6.1.2.1.2.2 | Interface list | To confirm interface polling works |
1.3.6.1.2.1.4.20 | IP address table | To confirm L3 data is accessible |
1.3.6.1.2.1.25.1 | Host/server resources | For server devices |
4. Read the Error Message
Warnings you can safely ignore
Check this table first before investigating an error — these are harmless messages that Net-SNMP outputs regardless of connection success:
| Warning | What it means |
|---|---|
Cannot find module (X-MIB) | A MIB file is not installed locally. OIDs show as numbers. Harmless. |
Sub-id not found | A numeric OID has no local name mapping. Harmless. |
No log handling enabled | Net-SNMP cannot write to its log file. Harmless for command-line use. |
SNMPv2c errors
| Error / output | What it means | What to do |
|---|---|---|
Timeout: No Response from <ip> | Device did not reply — unreachable, port blocked, or SNMP agent not running | Return to Step 1 and Step 2 |
Authentication failure | Wrong community string | Re-check the community string — it is case-sensitive |
snmpwalk: Unknown host | DNS lookup failed for the hostname | Use the IP address directly instead |
End of MIB with no data before it | Community string is valid but the device's access policy excludes this data | Go to Step 5 and check the device's view/ACL config |
| No output, no error — returns immediately | Device responded but returned nothing | This is a silent failure — see the warning below |
SNMPv3 errors
| Error or Output | What it means | What to do |
|---|---|---|
Timeout: No Response from <ip> | Same as v2c — network, firewall, or agent issue | Return to Step 1 |
Authentication failure | Auth password or auth protocol does not match | Verify the -a protocol and -A password exactly match the device config |
Unknown user name | The SNMPv3 username does not exist on the device | Run show snmp user on device; check spelling and case |
Unsupported security level | Device requires a different security level | Try authPriv if you used authNoPriv, or vice versa |
Decryption error | Privacy protocol or privacy password does not match | Verify the -x protocol and -X password exactly match the device config |
Not in time window | Time difference between ServiceOps and the device is too large | Sync the device clock using NTP |
| No output, no error, returns immediately | Silent failure — credentials are valid but device view/group is misconfigured | Go to Step 5 |
An snmpwalk that returns zero output with no error is almost always an SNMPv3 group or view misconfiguration on the device. The credentials are correct, but the device's access policy is blocking the data and it does this silently, with no error. See Worked Example: Cisco Silent Failure for a step-by-step resolution.
5. Fix the Issue on the Device
If snmpwalk shows a credential error or a silent failure, the fix is on the device side. Use the commands below for your device vendor.
Jump to your vendor: Cisco IOS / IOS-XE | Cisco NX-OS | Juniper Junos | HP / Aruba ProCurve | Aruba ArubaOS-CX | Fortinet FortiGate | Palo Alto PAN-OS | Linux
Cisco IOS / IOS-XE
Run on: Cisco device (privileged EXEC mode)
show running-config | include snmp
show snmp community
show snmp user
show snmp group
show snmp view
show snmp
show snmp engineID
In show snmp group, if the group has a readview name assigned, that name must also appear in show snmp view. If it does not, the view is missing and the device will silently return no data. Fix it with:
snmp-server view <readview-name> iso included
Run this in global configuration mode (configure terminal). See Worked Example for the full walkthrough.
Cisco NX-OS
Run on: Cisco NX-OS device (exec)
show snmp
show snmp community
show snmp user
show snmp group
show running-config snmp
Juniper Junos
Run on: Juniper device (operational mode)
show snmp mib walk system
show snmp statistics
show snmp v3
Run on: Juniper device (configuration mode)
show configuration snmp
Junos maps users → groups → views using VACM (View-based Access Control). Check that the user is in a group and that the group has a view defined that includes the OIDs you need.
HP / Aruba ProCurve
Run on: HP/Aruba ProCurve (manager view)
show snmp-server
show snmpv3 user
show snmpv3 group
show running-config | include snmp
Aruba ArubaOS-CX
Run on: ArubaOS-CX (exec)
show snmp community
show snmpv3 users
show snmp trap
show running-config snmp-server
Fortinet FortiGate
Run on: FortiGate (CLI)
get system snmp sysinfo
show system snmp community
show system snmp user
show system interface | grep -A 20 allowaccess
On FortiGate, SNMP must be explicitly allowed on the ingress interface. Even with a valid community string or user, if the interface's allowaccess setting does not include snmp, all requests are silently dropped with no error or log entry.
To fix it, go to Network > Interfaces, edit the interface that receives SNMP traffic, and enable SNMP under Administrative Access.
Palo Alto PAN-OS
Run on: Palo Alto (operational CLI)
show snmp-server configuration
show interface management
show network interface <name> management-profile
PAN-OS requires SNMP to be enabled in the Interface Management Profile assigned to the interface (Network → Network Profiles → Interface Mgmt). Without this, SNMP requests are dropped silently at the interface even if the SNMP server is fully configured.
Linux / Net-SNMP agent
Run on: The Linux device (root shell)
# Is the agent running?
systemctl status snmpd
# Active configuration (without comments)
grep -vE '^(#|$)' /etc/snmp/snmpd.conf
# Real-time log
journalctl -u snmpd -f
# SNMPv3 user state
cat /var/lib/net-snmp/snmpd.conf
Net-SNMP stores SNMPv3 users in two places: /etc/snmp/snmpd.conf (where users are initially created) and /var/lib/net-snmp/snmpd.conf (where localized keys are stored after first startup). If a user was added to one file but not the other, authentication will fail. Always check both files.
6. Check the ServiceOps Credential Profile
If snmpwalk succeeds from the ServiceOps server but ServiceOps discovery still fails, the credential profile in ServiceOps does not match what you used in the test.
6.1 Verify the credential profile settings
Go to Admin > Discovery and Agents > Credentials and open the SNMP credential profile assigned to this device. Check every field against what worked in your snmpwalk test:
- SNMP version: v2c or v3
- Community string (v2c): exact match, case-sensitive
- Username (v3): exact match, case-sensitive
- Auth protocol and password (v3): exact match, case-sensitive
- Privacy protocol and password (v3): exact match, case-sensitive
- Security level (v3): must match device:
authPriv,authNoPriv, ornoAuthNoPriv - Context name (v3): leave empty unless the device explicitly requires one; an accidental value here is a common mistake
- Port: default is
161; only change if the device uses a non-standard port
6.2 Verify the profile is assigned to the right device
- Confirm the correct credential profile is assigned to this device or its discovery range.
- If multiple profiles are assigned, check their priority order. A higher-priority but incorrect profile may be tried first, causing the correct profile never to be used.
6.3 Common ServiceOps log messages and what they mean
Discovery logs are stored on the ServiceOps server at /optflotomate/discovery/logs. Open the relevant log file for the discovery job and search for the device IP to find its specific error entries.
| Log message | What it means | Fix |
|---|---|---|
SNMP timeout for <ip> | No reply within the timeout window | Increase the timeout in discovery settings; verify network |
Authentication failure | Credentials in the profile do not match the device | Re-enter the credentials in the credential profile |
Unknown user name | The SNMPv3 username in the profile does not exist on the device | Create the user on the device or correct the username in the profile |
Empty response / no varbinds | Credentials are valid but device view is blocking the data | Go to Step 5 |
Engine ID mismatch | The stored Engine ID is stale (e.g. device was replaced or reset) | Remove the device from ServiceOps and re-add it |
6.4 Adjust timeouts for slow or remote devices
Devices on WAN links or under high load may need more time to respond:
| Setting | Default | Recommended for WAN / high latency |
|---|---|---|
| SNMP timeout | 5 seconds | 10–15 seconds |
| Retries | 1 | 2–3 |
7. Advanced Packet Capture
Use this only if Steps 1–6 have not identified the root cause. A packet capture confirms exactly what is being sent and received at the network level.
7.1 Capture SNMP traffic on the ServiceOps server
Run on: ServiceOps server (Linux shell, root)
# Save capture to file (open later in Wireshark)
tcpdump -i any -n host <device_ip> and udp port 161 -w /tmp/snmp.pcap
# View in real time (press Ctrl+C to stop)
tcpdump -i any -n -vv host <device_ip> and udp port 161
7.2 What to look for
| What you observe | What it means |
|---|---|
| No outbound packet from ServiceOps | ServiceOps is not sending — check credential profile binding |
| Outbound packet sent, no reply | Firewall or routing issue in the path, or device is dropping silently |
| Reply received with empty data | Credentials valid; device view or ACL is filtering the data — go to Step 5 |
| Reply with an error code | A specific SNMP error was returned — cross-reference with Step 4 |
7.3 Device-side debug commands
Debug commands can generate significant CPU load on production devices. Always disable debugging immediately after your test. Schedule a maintenance window if the device is under heavy load.
Cisco IOS (privileged EXEC):
debug snmp packets
! Reproduce the issue, then:
undebug all
Juniper Junos (operational mode):
monitor traffic interface <mgmt-interface> matching "udp port 161"
Linux Net-SNMP agent (run snmpd in debug mode — stop the service first):
snmpd -f -Le -DALL 2>&1 | tee /tmp/snmpd-debug.log
Post Verification Checklist
Complete all items before closing the issue.
| Check | Where | Expected result |
|---|---|---|
snmpwalk returns expected data | ServiceOps server (Linux shell) | OIDs returned without errors |
| Discovery succeeds in ServiceOps | ServiceOps UI > Technician Portal > Asset Management > Hardware Asset | Device fully discovered (interfaces, CPU, memory) |
| No SNMP errors in device logs | Device syslog | Clean log during the discovery window |
| Configuration saved on device | Device CLI | write memory / commit completed |
| Change documented | Your change management system | Ticket updated with what was changed and why |
Prevention tips
- Always create a view before assigning it to a group.
- Never use passwords, secrets, or sensitive strings as view, group, or community names.
- Use descriptive names — e.g.
MOTA-READ,NMS-READ,APP-READ. - Use a dedicated SNMP user per monitoring tool — this makes it easier to isolate per-tool problems.
- After every SNMP configuration change on a device, run a test discovery from ServiceOps and validate with
show snmpcommands. - Periodically audit device configs to confirm every referenced view is actually defined.
Worked Example: Cisco SNMPv3 Silent Failure
This is one of the most common — and most confusing — SNMP problems. It applies to any Cisco IOS or IOS-XE device. The same root cause — valid credentials, but a missing or misconfigured view — also occurs on Juniper Junos (via VACM), HP/Aruba ProCurve, and other vendors. The diagnostic steps and logic are identical; only the fix commands differ.
The situation
- A Cisco switch is not being discovered in ServiceOps.
- The device is configured for SNMPv3 with SHA authentication and AES-256 encryption.
- The credentials have been double-checked and are confirmed correct.
- The same device is successfully polled by another monitoring tool.
Diagnosis
Step 1: Ping and UDP/161 test both succeed. The device is reachable.
Step 3: Run snmpwalk with the correct SNMPv3 credentials. It completes without any error — but returns zero output.
Step 4: Zero output with no error = silent failure. This pattern means credentials are valid but the device's access policy is blocking the data.
Step 5: Log in to the Cisco device and run:
show snmp group
show snmp view
In show snmp group, the ServiceOps user's group has a readview name assigned — for example MOTA-READ. But that name does not appear anywhere in show snmp view. The view was never created.
Root cause
Cisco IOS silently returns no data when a group's readview does not exist. There is no error message, no SNMP error code, and no syslog entry. The configuration looks complete because the user and group both exist — but without a valid readview, the device has nowhere to look up the data.
Fix
Create the missing view. Run this in global configuration mode (configure terminal):
snmp-server view MOTA-READ iso included
Save the configuration:
write memory
Re-run discovery in ServiceOps. To confirm the fix:
show snmp view
show snmp group
Both commands should now show MOTA-READ consistently.
Security note
If the original readview name was accidentally set to something sensitive (such as a password — a real-world occurrence), it is stored in the device's running config and any backup in plaintext. Replace it with a non-sensitive name:
snmp-server view MOTA-READ iso included
snmp-server group <group-name> v3 priv read MOTA-READ
no snmp-server view <old-sensitive-name>
Root Cause Matrix
Already familiar with the guide? Find your symptom here and jump directly to the fix.
| Symptom | Likely cause | Go to |
|---|---|---|
| Ping fails, no reply on UDP/161 | Network/routing problem or device is offline | Step 1 |
| Ping OK, UDP/161 filtered | Firewall blocking SNMP between ServiceOps and device | Step 1 |
snmpwalk timeout (v2c or v3) | Firewall, device ACL, or SNMP agent not running | Step 1, Step 2 |
| Authentication failure (v2c) | Wrong community string | Step 3, Step 5, Step 6 |
| Authentication failure (v3) | Wrong username, auth protocol, or auth password | Step 3, Step 5, Step 6 |
| Decryption error (v3) | Wrong privacy protocol or privacy password | Step 3, Step 5 |
| Unknown user name (v3) | Username does not exist on the device | Step 5 |
| Not in time window (v3) | Clock drift between ServiceOps server and device | Step 4 — sync device NTP |
snmpwalk OK but ServiceOps discovery fails | Credential profile mismatch or wrong profile assigned | Step 6 |
snmpwalk returns nothing, no error | Silent failure — group readview missing on device | Step 4, Step 5, Worked Example |
| Some OIDs return data, others are empty | Device view restricts part of the MIB tree | Step 5 |
| Intermittent discovery failures | WAN latency + timeout setting too low | Step 6 — increase timeout |
| Engine ID mismatch errors | Device was replaced, reset, or stack changed | Step 6 — re-add device |
| Works in another tool, fails in ServiceOps | Different view used per tool, or wrong ServiceOps profile | Step 5, Step 6 |
| Fortinet — silent drop despite valid credentials | Interface allowaccess missing snmp | Step 5 — Fortinet |
| Palo Alto — silent drop despite valid credentials | Interface Management Profile missing SNMP | Step 5 — Palo Alto |
When to Contact Support
Escalate to Motadata Support if, after completing all steps above:
snmpwalkfrom the ServiceOps server succeeds, but ServiceOps discovery still returns no data.- Discovery succeeds for some OIDs but fails for specific data types.
- The issue affects multiple SNMP devices simultaneously with no apparent common cause.
- Engine ID negotiation repeatedly fails after re-adding the device.
- You suspect a bug or unexpected behavior in ServiceOps itself.
What to include in your support request
- Motadata ServiceOps version and patch level
- Device vendor, model, and OS/firmware version
- SNMP version (v2c or v3) and security level
- Output of the vendor
showcommands from Step 5 — redact all passwords - Output of your
snmpwalktest from Step 3 - ServiceOps discovery logs for the affected device, with timestamps — found on the server at
/optflotomate/discovery/logs - Packet capture file if available (Step 7)
- List of steps already attempted