SNMP Collection
Network infrastructure discovery via SNMP polling and LLDP topology mapping
Parascope's SNMP collector discovers network infrastructure devices --- switches, routers, firewalls, and access points --- by polling them over SNMP and mapping their physical interconnections via LLDP. It creates network.device Configuration Items and physical_connection relationships, giving you a live view of your network fabric alongside the compute, storage, and platform infrastructure that Parascope already tracks.
Why SNMP Collection Matters
Network devices are the connective tissue of your infrastructure. Every VM, container, and bare-metal host depends on switches and routers to communicate, yet these devices are often invisible to configuration management tools that focus on compute and storage. SNMP collection closes that gap by:
- Discovering every SNMP-responsive device on your network and classifying it automatically
- Inventorying physical interfaces with speed, status, MAC address, and traffic counters
- Mapping the physical topology through LLDP neighbor discovery, so you can trace cable-level connectivity
- Enriching existing Netbox device CIs with live operational data from SNMP, bridging the gap between source-of-truth records and runtime reality
Architecture
The collector runs four independent pipelines, each handled independently through dedicated processing pipelines. This separation keeps device inventory, topology mapping, subnet discovery, and CI enrichment cleanly isolated.
What Gets Collected
System Information (SNMP System MIB)
Every SNMP-responsive device exposes a standard System MIB that provides its identity. The collector reads these OIDs on every poll cycle to build the device's core profile.
| OID | Field | Description |
|---|---|---|
| sysName | Hostname | The device's configured hostname |
| sysDescr | System description | Firmware version, model string, and OS details |
| sysContact | Contact | Administrative contact for the device |
| sysLocation | Location | Physical location string (rack, room, site) |
| sysObjectID | Object ID | Enterprise OID used for vendor and device classification |
| sysUpTime | Uptime | Time since last reboot, converted to seconds |
Interface Inventory (ifTable / ifXTable)
The collector walks the standard interface tables to build a complete port inventory for each device. The ifXTable extension is preferred where available because it provides 64-bit counters (ifHighSpeed, ifHCInOctets) that avoid wraparound on high-speed links.
| Field | Source | Description |
|---|---|---|
| Interface name | ifDescr / ifName | The interface identifier (e.g., GigabitEthernet0/1) |
| Alias / description | ifAlias | Operator-assigned description |
| Speed | ifHighSpeed (ifXTable) | Link speed in Mbps, using 64-bit counters |
| Admin status | ifAdminStatus | Configured state: up, down, or testing |
| Oper status | ifOperStatus | Actual link state: up, down, dormant, etc. |
| MAC address | ifPhysAddress | The interface hardware address |
| In octets | ifHCInOctets | Bytes received (64-bit counter) |
| Out octets | ifHCOutOctets | Bytes transmitted (64-bit counter) |
| In errors | ifInErrors | Inbound packet errors |
| Out errors | ifOutErrors | Outbound packet errors |
| In discards | ifInDiscards | Inbound packets discarded (queue full, policy) |
| Out discards | ifOutDiscards | Outbound packets discarded |
LLDP Neighbor Discovery
The Link Layer Discovery Protocol (LLDP) is a vendor-neutral protocol that network devices use to announce their identity to directly connected neighbors. The SNMP collector walks the LLDP-MIB remote tables to discover these adjacencies and build a physical topology map.
For each LLDP neighbor discovered, the collector records:
| Field | Description |
|---|---|
| Local port ID | The port on the polled device where the neighbor was seen |
| Local port description | Operator-assigned description of the local port |
| Remote system name | The neighbor device's hostname (sysName) |
| Remote port ID | The port identifier on the neighbor device |
| Remote port description | Description of the remote port |
These neighbor records are used to create physical_connection relationships between network.device CIs. The remote device is matched by hostname, so both sides of a link must be discoverable via SNMP for the relationship to be established. LLDP must be enabled on your network devices for this feature to work.
Config vs Metrics Separation
Parascope separates collected data into configuration (tracked in change history) and metrics (point-in-time values that are not tracked). This distinction is especially important for network devices, where interface counters change constantly but the device's identity and port inventory change rarely.
Configuration (tracked in change history):
| Field | Description |
|---|---|
| Hostname | Device hostname from sysName |
| System description | Firmware and model string from sysDescr |
| Device class | Automatic classification (switch, router, firewall, etc.) |
| Management IP | The IP address used to reach the device |
| Interface count | Total number of interfaces |
| Interfaces array | Per-interface name, speed, admin/oper status, and MAC address |
Metrics (point-in-time, not tracked):
| Metric | Description |
|---|---|
| Uptime seconds | Time since last device reboot |
| In octets | Per-interface bytes received |
| Out octets | Per-interface bytes transmitted |
| In errors | Per-interface inbound error count |
| Out errors | Per-interface outbound error count |
| In discards | Per-interface inbound discard count |
| Out discards | Per-interface outbound discard count |
When a port changes speed, goes down, or a new interface appears, that change is recorded in history. But the continuous flow of traffic counters is stored as metrics only, keeping the change history meaningful and noise-free.
Target Discovery Scopes
The SNMP collector supports three target discovery scopes, each suited to a different operational scenario. You choose a scope when configuring the collector source.
Static Scope
The simplest approach: provide a comma-separated list of IP addresses or hostnames in the snmp_targets configuration field. The collector polls exactly those devices on every cycle.
Static scope is best when you have a small, well-known set of network devices and want deterministic, predictable collection. There is no automatic discovery --- if you add a new switch, you must add its IP to the target list.
Netbox Query Scope
Instead of maintaining a static list, the Netbox Query scope queries the Parascope API for existing CIs (typically netbox.device) and extracts their management IP addresses. This means the SNMP collector automatically picks up new devices as they appear in Netbox, without any manual target list maintenance.
Beyond device discovery, this scope also enables enrichment: the collector publishes SNMP operational data back to the source Netbox CIs, stored in their raw_data under the key snmp_enrichment. This bridges the gap between Netbox's source-of-truth inventory and the live operational state visible through SNMP.
CIDR Discovery Scope
The most automated approach: provide one or more subnet ranges (e.g., 10.0.0.0/24) and the collector scans them for SNMP-responsive devices. Discovered devices are evaluated with a confidence scoring system to determine whether they should be automatically promoted to network.device CIs or held as discovery candidates for manual review.
Confidence scoring:
| Factor | Weight | Description |
|---|---|---|
| Device class identified | 0.50 | sysObjectID maps to a known vendor and class |
| Vendor identified | 0.10 | Enterprise OID matches a known vendor |
| Interfaces present | 0.10 | Device has network interfaces |
| Hostname present | 0.10 | sysName returned a non-empty value |
| Standard SNMP port | 0.05 | Device responds on UDP 161 |
Devices scoring 0.8 or higher are auto-promoted to full network.device CIs. Devices below that threshold are held as discovery candidates, visible in the UI for manual review and promotion. This prevents noisy or ambiguous devices (printers, UPS units with minimal SNMP support) from cluttering your CMDB without explicit approval.
SNMP Protocol Configuration
The collector supports both SNMPv2c and SNMPv3. Choose v2c for simple environments where security is handled at the network level, and v3 for production networks where authentication and encryption are required.
SNMPv2c
SNMPv2c uses a community string for access control. It is simpler to configure but provides no encryption --- community strings are transmitted in cleartext.
| Setting | Description | Default |
|---|---|---|
snmp_community | Community string | public |
SNMPv3
SNMPv3 provides authentication (verifying the identity of the SNMP manager) and privacy (encrypting SNMP traffic). It is the recommended protocol for production environments.
| Setting | Description | Required |
|---|---|---|
snmp_v3_username | USM username | Yes |
snmp_v3_auth_protocol | Authentication algorithm | No |
snmp_v3_auth_key | Authentication passphrase | With auth protocol |
snmp_v3_priv_protocol | Encryption algorithm | No |
snmp_v3_priv_key | Privacy passphrase | With priv protocol |
Supported authentication protocols: SHA, SHA224, SHA256, SHA384, SHA512, MD5
Supported privacy protocols: AES128, AES192, AES256, DES
Connection Settings
These settings apply regardless of which SNMP version you use.
| Setting | Description | Default | Constraints |
|---|---|---|---|
snmp_port | UDP port for SNMP queries | 161 | -- |
snmp_timeout | Seconds to wait for a response | 5.0 | Minimum 1.0 |
snmp_retries | Number of retries on timeout | 2 | -- |
snmp_max_concurrent | Maximum parallel SNMP requests | 50 | -- |
collection_interval | Seconds between collection cycles | 300 | Minimum 60 |
The snmp_max_concurrent setting is important for large networks. Setting it too high can overwhelm older devices; setting it too low extends collection time. The default of 50 is a reasonable starting point for most environments.
Device Classification
The collector automatically classifies devices based on their sysObjectID, which encodes the vendor's IANA enterprise number. This classification determines the device_class field on the resulting network.device CI.
Vendor Mapping
| Enterprise OID | Vendor | Default Class |
|---|---|---|
| 9 | Cisco | switch |
| 2636 | Juniper | router |
| 30065 | Arista | switch |
| 2011 | Huawei | switch |
| 674 | Dell | switch |
| 11 | HP | switch |
| 12356 | Fortinet | firewall |
| 637 | Nokia | router |
| 8072 | net-snmp | server |
| 2021 | ucd-snmp | server |
When the enterprise OID does not match any known vendor, the collector falls back to keyword matching on the sysDescr string. If the description contains "router", "switch", "firewall", "access point", or "wireless", the device is classified accordingly.
Supported device classes: switch, router, firewall, accesspoint, server, unknown
Devices that cannot be classified by either method receive the unknown class. You can still see and manage these devices in Parascope, but they may benefit from manual classification or correlation rule review.
LLDP Topology Discovery
LLDP topology mapping is one of the most valuable capabilities of the SNMP collector. By reading LLDP neighbor tables from every polled device, the collector builds a graph of physical connections that shows exactly how your network devices are cabled together.
Each physical_connection relationship carries properties that describe both ends of the link:
| Property | Description |
|---|---|
local_port | Port identifier on the source device |
local_port_desc | Operator description of the local port |
remote_port | Port identifier on the neighbor device |
remote_port_desc | Operator description of the remote port |
discovery_protocol | Always lldp for LLDP-discovered connections |
Remote devices are matched by hostname (the LLDP-advertised system name compared against the sysName of known network.device CIs). Both devices must be polled by the SNMP collector for the relationship to be created. If only one side is polled, the neighbor data is still recorded on the polled device but no relationship is established.
Netbox Enrichment
When using the Netbox Query scope, the SNMP collector does more than just discover targets. It also publishes enrichment data back to the source CIs (typically netbox.device) that provided the management IP addresses. This enrichment is handled by the SNMP enrichment pipeline and stored in the target CI's raw_data under the key snmp_enrichment.
Enrichment payload:
| Field | Description |
|---|---|
system_description | Full sysDescr string from the device |
hostname_from_snmp | sysName as reported by SNMP (may differ from Netbox name) |
device_class | Automatic classification result |
vendor | Identified vendor name |
uptime_seconds | Device uptime |
interface_count | Total number of interfaces |
interface_summary | Breakdown of total, up, and down interfaces |
snmp_reachable | Boolean flag indicating SNMP connectivity |
This enrichment provides a live operational overlay on top of Netbox's source-of-truth inventory data. You can see at a glance whether a Netbox device is actually reachable via SNMP, what firmware it reports, how long it has been running, and how many of its interfaces are operational --- all without leaving the Netbox device's detail page in Parascope.
Message Flow
The following diagram shows how data flows from target discovery through collection and processing to the database.
Viewing SNMP Data
Once the SNMP collector is running, network device data appears throughout the Parascope UI.
CI List. Network devices appear as the network.device CI type in the main Configuration Items list. You can filter by CI type, device class, vendor, or any other attribute. The list view shows the device hostname, management IP, classification, and lifecycle status.
Device Detail. Clicking into a network device opens its detail page, which shows system information (hostname, description, vendor, device class, management IP), the full interface inventory with per-port status, speed, and MAC address, and traffic counters as point-in-time metrics.
Relationships. The Relationships tab on each device shows LLDP-discovered physical_connection relationships to neighboring devices. Each relationship displays the local and remote port names, making it easy to trace cabling.
Relationships Explorer. For a broader view, use the Relationships Explorer to visualize the network topology as a graph. Starting from any network device, you can expand connections to see the full physical fabric and how it relates to compute infrastructure connected to those switches.
Change History. Configuration changes --- a port going down, a new interface appearing, a firmware update changing the sysDescr --- are tracked in the global change history and on the individual device's change history tab.
Related Documentation
- Architecture --- System design overview
- Managing Collectors --- Collector configuration and monitoring
- Collector Discovery --- Discovery-based collection patterns
- Correlation Engine --- Cross-system relationship discovery
- OS Collection --- Agentless Linux host discovery
- CI Types --- All CI types across sources