SNMP Polling for Network Device Inventory - Automated Property Collection
SNMP Polling for Network Device Inventory - Automated Property Collection
Section titled “SNMP Polling for Network Device Inventory - Automated Property Collection”SNMP Polling transforms rConfig from a configuration backup tool into an intelligent data collection platform. By leveraging the Simple Network Management Protocol, rConfig can automatically extract device properties—serial numbers, software versions, interface details, uptime statistics—without parsing configuration files or running custom scripts.
SNMP Polling: Automated Device Property Collection
Section titled “SNMP Polling: Automated Device Property Collection”What SNMP Polling Does
Section titled “What SNMP Polling Does”SNMP Polling queries network devices using standardized Object Identifiers (OIDs) to retrieve specific data points. Every time rConfig backs up a device configuration, it simultaneously polls any configured SNMP OIDs and stores the results as dynamic device properties.
The result: You get configuration backups and rich device metadata in a single operation.
How It Works
Section titled “How It Works”The Architecture
Section titled “The Architecture”SNMP Polling in rConfig uses three components:
- SNMP Connection Profiles - Store SNMP credentials (community strings for v2c, or auth/priv credentials for v3)
- SNMP OID Definitions - Specify which data points to collect (e.g., sysDescr, ifName, serial numbers)
- SNMP Polling Groups - Link devices, OIDs, and connection profiles together
The Workflow
Section titled “The Workflow”- Device backup triggered (manual, scheduled, or CLI)
- rConfig checks if the device belongs to an SNMP Polling Group
- If yes, SNMP poll executes alongside the configuration download
- Each OID in the group is queried using the associated connection profile
- Results stored as device properties in the database
- Properties displayed in device details and inventory reports
Key insight: SNMP polling happens automatically during backups. You don’t run separate polling operations—it’s integrated into your existing workflow.
Data Storage
Section titled “Data Storage”- Latest values only are displayed in the UI and reports
- Historical values can be tracked through activity logs
- All polling events are logged for troubleshooting
Why Use SNMP Polling
Section titled “Why Use SNMP Polling”Use Cases That Make Sense
Section titled “Use Cases That Make Sense”Hardware Inventory: Extract serial numbers, chassis IDs, and model information from hundreds of devices without manual data entry.
Software Auditing: Track IOS/NX-OS/JunOS versions across your infrastructure to identify devices needing upgrades.
Interface Discovery: Inventory interface names, descriptions, and MAC addresses without parsing show commands.
Compliance Validation: Verify system contact, location, and other SNMP system fields match organizational standards.
Capacity Planning: Collect uptime, CPU/memory stats, or other operational metrics alongside configuration data.
When SNMP Polling Shines
Section titled “When SNMP Polling Shines”- Standardized data: When the information you need is available via standard SNMP MIBs
- Large scale: Polling 500 devices for serial numbers is faster and more reliable than parsing configs
- Non-config data: Hardware details, environmental sensors, operational stats that don’t appear in configurations
- Consistent format: SNMP returns structured data, eliminating regex complexity
- Extract more specific data with Regex: If you need to extract a specific part of an SNMP response, you can apply regex patterns to the polled data. This allows for more granular control over the information you collect.
When to Use Configuration Parsing Instead
Section titled “When to Use Configuration Parsing Instead”- SNMP disabled: Many security-focused environments disable SNMP entirely
- Configuration-specific data: VLANs, routing protocols, ACL counts—things that live in configs, not MIBs
- Vendor-specific details: Custom config sections without corresponding SNMP OIDs
- Already backing up: If configs already contain the data, parsing might be simpler
- No SNMP support: Some legacy or specialized devices may not support SNMP at all
- Vendor Bugs: Some devices have buggy SNMP implementations that return incorrect data
You can use both methods simultaneously—SNMP for standardized hardware/software details, config parsing for configuration-specific properties.
SNMP Versions: Choosing the Right Protocol
Section titled “SNMP Versions: Choosing the Right Protocol”SNMPv2c (Community-Based)
Section titled “SNMPv2c (Community-Based)”- Security: Plaintext community strings (read-only or read-write)
- Use case: Internal networks, lab environments, legacy devices
- Pros: Simple, widely supported, minimal overhead
- Cons: No encryption, credentials sent in clear text
SNMPv3 (User-Based Security)
Section titled “SNMPv3 (User-Based Security)”- Security: Authentication (MD5/SHA) and encryption (DES/AES)
- Use case: Production environments, compliance requirements, internet-facing devices
- Pros: Encrypted, authenticated, granular access control
- Cons: More complex setup, some older devices lack support
Recommendation: Use SNMPv3 whenever possible. If you must use v2c, restrict it to trusted management VLANs.
Polling Groups: Organizing Your Data Collection
Section titled “Polling Groups: Organizing Your Data Collection”Polling Groups let you organize SNMP polling by device type, location, or data requirements.
Example structure:
- Cisco Routers - Poll for Cisco-specific OIDs (IOS version, serial numbers)
- HP/Aruba Switches - Poll for ProCurve/ArubaOS-specific data
- Core Infrastructure - Poll all critical devices for uptime and system info
- Branch Offices - Poll only essential OIDs to reduce overhead
Each device can belong to one polling group. Choose OIDs that make sense for that device category.
What Gets Collected
Section titled “What Gets Collected”Common OID categories:
System Information
- sysDescr (device description)
- sysUpTime (device uptime)
- sysContact (contact information)
- sysLocation (physical location)
- sysName (hostname)
Hardware Details
- Serial numbers
- Model numbers
- Chassis IDs
- Module inventory
Software/Firmware
- OS version
- Firmware revision
- Software features enabled
Interface Data
- Interface names and descriptions
- MAC addresses
- Administrative and operational status
- Speed and duplex settings
Vendor-Specific
- Cisco: IOS version, platform details
- Juniper: JunOS version, routing engine info
- Aruba: Controller role, AP counts
- Dell: PowerConnect firmware
Performance Considerations
Section titled “Performance Considerations”Polling Overhead
Section titled “Polling Overhead”SNMP polling adds minimal time to backup operations:
- Each OID query: 10-50ms (LAN)
- 10 OIDs per device: 100-500ms additional time
- For most deployments, this is negligible
Scaling
Section titled “Scaling”SNMP polling scales linearly with device count:
- 100 devices, 10 OIDs each = ~1000 SNMP queries
- Even at 100ms per query, that’s ~2 minutes total
- Queries run in parallel during backup jobs
Network Impact
Section titled “Network Impact”SNMP traffic is minimal:
- Average query/response: < 1KB
- 1000 queries = ~1MB of traffic
- Negligible compared to configuration file transfers
Integration with Device Inventory
Section titled “Integration with Device Inventory”SNMP-polled properties become dynamic device attributes in Device Inventory. This means:
- Inventory reports include SNMP data alongside configuration-parsed properties
- Properties are searchable (in future V8+ releases)
- Historical tracking via activity logs
- Export to external systems via API or CSV
The combination of SNMP polling and configuration parsing gives you comprehensive device intelligence without manual data entry.
Comparison: SNMP vs Configuration Parsing
Section titled “Comparison: SNMP vs Configuration Parsing”| Aspect | SNMP Polling | Config Parsing |
|---|---|---|
| Data Source | Live device query | Backed-up config file |
| Setup Complexity | Moderate (OIDs, credentials) | Moderate (regex patterns) |
| Data Types | Hardware, software, runtime stats | Configuration-specific details |
| Accuracy | Real-time, current values | Reflects last backup |
| SNMP Required | Yes | No |
| Parsing Skills | None | Regex knowledge helpful |
| Vendor Variability | Standardized MIBs | Config syntax varies widely |
Security Best Practices
Section titled “Security Best Practices”- Use SNMPv3 whenever possible
- Restrict SNMP to management VLANs - Don’t expose SNMP to untrusted networks
- Use read-only community strings - rConfig only needs read access
- Rotate credentials regularly - Update community strings/SNMPv3 credentials periodically
- Monitor SNMP logs - Watch for failed authentication attempts
- Disable SNMP on devices that don’t need it - Reduce attack surface
The Bottom Line
Section titled “The Bottom Line”SNMP Polling automates the collection of device properties that would otherwise require manual inventory work or complex configuration parsing. It’s most valuable when:
- You need standardized hardware/software details at scale
- SNMP is already enabled and secured on your devices
- You want operational data (uptime, versions) alongside configurations
- You’re building comprehensive device inventory for reporting or integration
Combined with configuration parsing, SNMP Polling gives you a complete picture of your network infrastructure—captured automatically with every backup.
Related Documentation
Section titled “Related Documentation”- Device Inventory Overview - How SNMP data integrates with inventory
- Configuration Property Parsing - The alternative method for property extraction
- CLI Commands - Manual SNMP polling commands
- Device Import Methods - Getting devices into rConfig
- SNMP Trap Handler - Event-driven SNMP automation