CDRouter SNMP User Guide
Introduction
CDRouter SNMP is an add-on for CDRouter, the industry’s leading CPE and router test platform. CDRouter SNMP adds Simple Network Management Protocol (SNMP) test capabilities to CDRouter.
In a residential or SOHO environment, SNMP functionality is typically integrated directly within the CPE device. CDRouter SNMP supports testing SNMP implementations over a wide range of IPv4 and IPv6 network configurations as well as both UDP and TCP transports. CDRouter SNMP provides an instant regression environment for testing SNMP functionality, and is powerful, easy to use, and fully automated.
CPE Devices with Integrated SNMP Functionality
Many modern CPE devices support integrated SNMP functionality. Such devices typically include management tools for provisioning access to SNMP from managers on the LAN and WAN. In many CPE devices LAN access is allowed while WAN access is restricted.
The test setup for a typical CPE device with integrated SNMP functionality is shown below:
SNMP Versions
CDRouter SNMP includes a number of test modules designed to verify SNMP functionality for SNMP v1/2c/3 clients, access controls and common MIBs in today’s leading CPE devices. CDRouter SNMP allows the following SNMP commands, or PDUs, to be tested:
- GetRequest
- GetNextRequest
- GetBulkRequest
CDRouter SNMP also allows the following MIBs to be tested:
- ifMIB
- IF-MIB::ifTable
- DISMAN-EVENT-MIB::sysUpTimeInstance
- IP-MIB::ipForwarding
- IP-MIB::ipAddrTable
- RFC1213-MIB::ipRouteTable
Separate test modules for both SNMP over IPv4 on the LAN, SNMP over IPv6 on the LAN, SNMP over IPv4 on the WAN and SNMP over IPv6 over the WAN are provided. This level of granularity allows issues or inconsistencies within an SNMP implementation to be quickly identified and isolated.
Test Methodology
Initial Setup
CDRouter SNMP can be used with any CPE or gateway device with integrated SNMP functionality, provided the SNMP users configured in CDRouter match those configured on the device.
Terminology
The CPE or gateway device contains an SNMP agent which responds to requests from an SNMP manager. CDRouter will automatically create an SNMP manager instance on the LAN or WAN during each SNMP test case.
Start-Up
CDRouter SNMP does not modify or impact the normal CDRouter start-up procedure performed at the beginning of every test run. However, at the start of each SNMP related test the SNMP user configuration to be tested is determined. This procedure is discussed in more detail below.
SNMP Users
CDRouter SNMP allows an arbitrary number of SNMP user configurations to be created. Each SNMP user configuration is defined as a unique snmpuser testvar_group in the CDRouter configuration file. A full description of all of the testvars available for each snmpuser testvar_group instance is defined in the Configuration section of this User Guide.
At the start of each SNMP test CDRouter will choose an snmpuser configuration to test. For SNMP tests that do not have restrictions on what type of SNMP user they can run with, CDRouter chooses the snmpuser configuration to test based on the value of the snmpDefaultUser testvar. If this testvar is set to the special value auto, CDRouter will implicitly configure a default user that supports SNMP version 2c and a community string of public, and read-only access. Otherwise, it will test using the SNMP user defined by snmpDefaultUser.
If no snmpuser testvar_group’s are defined in the CDRouter configuration file, snmpDefaultUser must be set to the value auto or all SNMP related test cases will be skipped.
Some test cases require an SNMP user configured to communicate with the CPE’s SNMP implementation using a specific version of SNMP, such as 2c or 3. CDRouter will automatically search the list of defined snmpuser configurations for a user with the appropriate version for each test that is performed.
Running
SNMP support can be enabled within CDRouter by uncommenting the testvar supportsSnmp and setting it to a value of “yes”. If testing SNMP related functionality over IPv6, IPv6 must also be enabled and and properly configured. Please see the CDRouter IPv6 User’s Guide for more information on configuring CDRouter for IPv6.
CDRouter SNMP includes a number of test modules designed to verify a wide variety of SNMP related functionality over both IPv4 and IPv6 from the LAN and WAN interface. The following table summarizes the different test modules included with CDRouter SNMP:
Test Module | Interface | Protocol |
---|---|---|
snmp.tcl | LAN | IPv4 |
snmp-wan.tcl | WAN | IPv4 |
snmp-v6.tcl | LAN | IPv6 |
snmp-wan-v6.tcl | WAN | IPv6 |
To run only the SNMP related test modules from the command-line:
$ cdrouter-cli -addon snmp –trace –pt
For additional test execution options, see the CDRouter CLI Guide.
Source and Destination Addresses
At the start of each test CDRouter will automatically choose a source and destination address. The destination address is the address used by the SNMP agent on the CPE or gateway device. The source address is the address used by CDRouter’s integrated SNMP manager.
The table below summarizes the source and destination addresses used by CDRouter in each SNMP test module:
Test Module | Source Address | Destination Address |
---|---|---|
snmp.tcl | Learned IPv4 address | lanIp |
snmp-wan.tcl | snmpManagerIp | wanIspAssignIp |
snmp-docsis.tcl | docsisDhcpServer | docsisAssignIp |
snmp-v6.tcl | Learned IPv6 address | ipv6LanIp |
snmp-wan-v6.tcl | snmpManagerIpv6 | ipv6WanIspAssignIp |
snmp-docsis-v6.tcl | docsisDhcpIpv6Server | docsisAssignIpv6 |
Licensing
To utilize CDRouter’s SNMP test capabilities, your license file must have the CDRouter SNMP add-on enabled. In addition, if you plan to test SNMP functionality over IPv6 your license file must also have the CDRouter IPv6 add- on enabled.
For information on upgrading your license to support CDRouter SNMP or CDRouter IPv6, please contact sales@qacafe.com. Please follow the instructions from support@qacafe.com when updating your license file to enable CDRouter SNMP or CDRouter IPv6.
CDRouter will report the status of all available add-ons during the installation
process and during startup. To verify that CDRouter SNMP and optionally
CDRouter IPv6 are enabled on your system, execute the command cdrouter-cli -info
as root and look for the lines “SNMP is enabled” and “IPv6 is enabled”,
as shown below. If these lines are present, CDRouter SNMP and CDRouter IPv6,
respectively, are enabled and ready to use.
$ cdrouter-cli -info
Starting cdrouter-cli Fri Mar 25 13:28:42 EDT 2016
Copyright (c) 2001-2016 by QA Cafe
Version 10.0 build 1 (21410 trunk), built 2016-03-24 17:36:47 by nightly@cdr-forge6.lan (x86_64)
Loaded OS distro \S Kernel \r on an \m
Loaded OS version Linux-3.10.0-327.10.1.el7.x86_64 x86_64
Loaded Tcl version 8.6.4
Loaded buddy version 10.0.1
(builder@kbuilder.dev.centos.org) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) )
Trying to load modules from '.'
Trying to load modules from '/usr/cdrouter/tests'
Start command: /usr/cdrouter/bin/cdrouter-cli -info
Test Suite cdrouter 10.0.1
The system ID is 2df9e2a1f8c359183cf0191a20f2cc5a
Using license installed at: /etc/cdrouter.lic
Registered to: qacafe
Maintenance, Support and Upgrades until: 2016-05-11
Licensed to run: cdrouter
Multiport is enabled
IPv6 is enabled
Storage is enabled
IKE is enabled
TR69 is enabled
TR69-EDM is enabled
Nmap is enabled
BBF.069 is enabled
SNMP is enabled
Performance is disabled
CPU is Intel(R) Core(TM) i5-4308U CPU @ 2.80GHz, bogomips 5599.98
Loaded TclXML version 3.1 (libxml2), TclDOM 3.0, xmldefs 3.1
Trying to load modules from '/usr/cdrouter/vendor/IOL/BBF.069/Tests'
BBF.069 version 1.2.075-11 (19093)
Configuration
Global SNMP Configuration
CDRouter SNMP has several configuration options, also known as test variables, or “testvars” for short, that define the DUT and the test environment.
The following tables describe all of the new testvars available with the CDRouter SNMP add-on. The sections below group testvars by the protocol or functionality they define.
To globally enable SNMP support within CDRouter, the testvar supportsSnmp must be set to a value of “yes”.
To change the port used for SNMP traffic on your device, set the value of snmpPort .
To set the default SNMP user configuration used by tests that do not have restrictions on the type of SNMP users that they can run with, set the value of snmpDefaultUser.
To specify additional directories to search for MIB definitions, define snmpMibDirs.
To specify the update delay CDRouter should use when verifying that an OID value has changed, define snmpUpdateDelay.
SNMP User Configuration
The following testvars specify the IP and IPv6 address that CDRouter will use as the source of all SNMP requests from the WAN. If the DUT restricts SNMP access to specific addresses or address ranges, be sure to set these testvars to an address that the DUT will accept.
- snmpManagerIp
- snmpManagerIpv6
- docsisDhcpServer - for DOCSIS SNMP testing
- docsisDhcpIpv6Server - for IPv6 DOCSIS SNMP testing
Each snmpuser testvar_group is independent and defines a unique test configuration. The snmpVersion testvar must be defined and must be set to 1, 2c or 3.
If snmpVersion is set to 1 or 2c, the snmpCommunity testvar must be defined and specifies the user’s membership in the given SNMP community. In SNMP v1/v2c, each SNMP community may have differing access controls such as read-only/read-write access, access to specific OIDs, or access from certain interfaces or IP ranges.
If snmpVersion is set to 3, the snmpSecurityLevel testvar must be defined. SNMP v3 defines an optional set of security features that are designed to address the security deficiencies in SNMP v1/v2c. An SNMP v3 user can be configured with authentication, privacy or both. A user configured with authentication must provide a valid username and password. A user configured with privacy uses a second password along with encryption to communicate confidentially with the SNMP agent.
The snmpSecurityLevel testvar specifies the SNMP v3 security settings for the SNMP user. Three different security levels are supported:
-
noAuthNoPriv: The user will send unauthenticated messages without encryption.
-
authNoPriv: The user will send authenticated messages without encryption.
-
authPriv: The user will send authenticated and encrypted messages.
If this option is set to a value of authNoPriv or authPriv, the testvars snmpAuthProtocol , snmpAuthUsername , and snmpAuthPassword must all be defined.
Likewise, if this option is set to a value of authPriv, the testvars snmpPrivacyProtocol and snmpPrivacyPassword must be defined.
The snmpTransport testvar determines if the user will use UDP or TCP as the transport protocol when sending SNMP traffic.
If defined, the snmpRetries and snmpTimeout testvars specify the number of retries and the delay in seconds between each retry for failed SNMP requests made by the user, respectively.
Configuration Notes - Required User Versions
Certain test cases require SNMP users configured with specific versions of SNMP. CDRouter will automatically skip tests if there does not exist at least one SNMP user configuration that meets its criteria. The table below lists the required criteria for each test case, by test module.
Test Name | SNMP version |
---|---|
ipv6_snmp_301 | v1 or v2c |
ipv6_snmp_wan_301 | v1 or v2c |
snmp_301 | v1 or v2c |
snmp_wan_301 | v1 or v2c |
ipv6_snmp_304 | v2c or v3 |
ipv6_snmp_305 | v2c or v3 |
ipv6_snmp_wan_304 | v2c or v3 |
ipv6_snmp_wan_305 | v2c or v3 |
snmp_304 | v2c or v3 |
snmp_305 | v2c or v3 |
snmp_wan_304 | v2c or v3 |
snmp_wan_305 | v2c or v3 |
ipv6_snmp_302 | v3 |
ipv6_snmp_303 | v3 |
ipv6_snmp_wan_302 | v3 |
ipv6_snmp_wan_303 | v3 |
snmp_302 | v3 |
snmp_303 | v3 |
snmp_wan_302 | v3 |
snmp_wan_303 | v3 |
Example Configurations
There is a wide variety of SNMP configurations and functionality that can be tested with CDRouter SNMP. A few basic example configurations for common SNMP testing environments are provided below.
Example 1: SNMP v2c User
In this example a single SNMP user configuration is defined and set as the default SNMP user. An SNMP version 2c community named mycommunity is configured on the DUT.
NOTE: Since no SNMP v3 users are defined in this configuration, all tests requiring at least one SNMP v3 user will be automatically skipped by CDRouter.
SECTION "CDRouter SNMP: Basic Setup" {
testvar supportsSnmp yes
testvar snmpDefaultUser snmpuser1
SECTION "SNMP Users Setup" {
testvar_group snmpuser1 {
testvar snmpVersion 2c
SECTION "SNMP version 1/2c Configuration" {
testvar snmpCommunity mycommunity
}
}
}
}
Example 2: SNMP v3 User without authentication or privacy
In this example a single SNMP user configuration is defined and set as the default SNMP user. An unauthenticated, unencrypted SNMP version 3 user is configured on the DUT.
NOTE: Since no SNMP v1/v2c users are defined in this configuration, all tests requiring at least one SNMP v1/v2c user will be automatically skipped by CDRouter.
SECTION "CDRouter SNMP: Basic Setup" {
testvar supportsSnmp yes
testvar snmpDefaultUser snmpuser1
SECTION "SNMP Users Setup" {
testvar_group snmpuser1 {
testvar snmpVersion 3
SECTION "SNMP version 3 Configuration" {
testvar snmpSecurityLevel noAuthNoPriv
}
}
}
}
Example 3: SNMP v3 User with authentication, without privacy
In this example a single SNMP user configuration is defined and set as the default SNMP user. An authenticated, unencrypted SNMP version 3 user named myuser is configured on the DUT using the MD5 authentication protocol and username/password qacafe/qacafe123.
NOTE: Since no SNMP v1/v2c users are defined in this configuration, all tests requiring at least one SNMP v1/v2c user will be automatically skipped by CDRouter.
SECTION "CDRouter SNMP: Basic Setup" {
testvar supportsSnmp yes
testvar snmpDefaultUser snmpuser1
SECTION "SNMP Users Setup" {
testvar_group snmpuser1 {
testvar snmpVersion 3
SECTION "SNMP version 3 Configuration" {
testvar snmpSecurityLevel authNoPriv
testvar snmpAuthProtocol MD5
testvar snmpAuthUsername qacafe
testvar snmpAuthPassword qacafe123
}
}
}
}
Example 4: SNMP v3 User with authentication and privacy
In this example a single SNMP user configuration is defined and set as the default SNMP user. An authenticated, encrypted SNMP version 3 user named myuser is configured on the DUT using the MD5 authentication protocol and authentication username/password qacafe/qacafe123. The SNMP user on the DUT is configured with privacy using the privacy protocol DES and privacy password qacafe123.
NOTE: Since no SNMP v1/v2c users are defined in this configuration, all tests requiring at least one SNMP v1/v2c user will be automatically skipped by CDRouter.
SECTION "CDRouter SNMP: Basic Setup" {
testvar supportsSnmp yes
testvar snmpDefaultUser snmpuser1
SECTION "SNMP Users Setup" {
testvar_group snmpuser1 {
testvar snmpVersion 3
SECTION "SNMP version 3 Configuration" {
testvar snmpSecurityLevel authPriv
testvar snmpAuthProtocol MD5
testvar snmpAuthUsername qacafe
testvar snmpAuthPassword qacafe123
testvar snmpPrivacyProtocol DES
testvar snmpPrivacyPassword qacafe123
}
}
}
}
Supported MIBs
CDRouter SNMP ships with support for the following MIBs:
ACCOUNTING-CONTROL-MIB
ADSL2-LINE-MIB
ADSL2-LINE-TC-MIB
ADSL-LINE-EXT-MIB
ADSL-LINE-MIB
ADSL-TC-MIB
AGENTX-MIB
AGGREGATE-MIB
ALARM-MIB
APM-MIB
APPC-MIB
APPLETALK-MIB
APPLICATION-MIB
APPN-DLUR-MIB
APPN-MIB
APPN-TRAP-MIB
APS-MIB
ARC-MIB
ATM2-MIB
ATM-ACCOUNTING-INFORMATION-MIB
ATM-MIB
ATM-TC-MIB
BGP4-MIB
BLDG-HVAC-MIB
BRIDGE-MIB
CHARACTER-MIB
CIRCUIT-IF-MIB
CLNS-MIB
COFFEE-POT-MIB
COPS-CLIENT-MIB
DECNET-PHIV-MIB
DIAL-CONTROL-MIB
DIFFSERV-CONFIG-MIB
DIFFSERV-DSCP-TC
DIFFSERV-MIB
DIRECTORY-SERVER-MIB
DISMAN-EVENT-MIB
DISMAN-EXPRESSION-MIB
DISMAN-NSLOOKUP-MIB
DISMAN-PING-MIB
DISMAN-SCHEDULE-MIB
DISMAN-SCRIPT-MIB
DISMAN-TRACEROUTE-MIB
DLSW-MIB
DNS-RESOLVER-MIB
DNS-SERVER-MIB
DOCS-BPI-MIB
DOCS-CABLE-DEVICE-MIB
DOCS-IETF-BPI2-MIB
DOCS-IETF-CABLE-DEVICE-NOTIFICATION-MIB
DOCS-IETF-QOS-MIB
DOCS-IETF-SUBMGT-MIB
DOCS-IF-MIB
DOT12-IF-MIB
DOT12-RPTR-MIB
DOT3-EPON-MIB
DOT3-OAM-MIB
DS0BUNDLE-MIB
DS0-MIB
DS1-MIB
DS3-MIB
DSA-MIB
DSMON-MIB
EBN-MIB
EFM-CU-MIB
ENTITY-MIB
ENTITY-SENSOR-MIB
ENTITY-STATE-MIB
ENTITY-STATE-TC-MIB
ETHER-CHIPSET-MIB
EtherLike-MIB
ETHER-WIS
FCIP-MGMT-MIB
FC-MGMT-MIB
FDDI-SMT73-MIB
FIBRE-CHANNEL-FE-MIB
Finisher-MIB
FLOW-METER-MIB
FRAME-RELAY-DTE-MIB
FR-ATM-PVC-SERVICE-IWF-MIB
FR-MFR-MIB
FRNETSERV-MIB
FRSLD-MIB
GMPLS-LABEL-STD-MIB
GMPLS-LSR-STD-MIB
GMPLS-TC-STD-MIB
GMPLS-TE-STD-MIB
GSMP-MIB
HC-ALARM-MIB
HCNUM-TC
HC-PerfHist-TC-MIB
HC-RMON-MIB
HDSL2-SHDSL-LINE-MIB
HOST-RESOURCES-MIB
HOST-RESOURCES-TYPES
HPR-IP-MIB
HPR-MIB
IANA-ADDRESS-FAMILY-NUMBERS-MIB
IANA-CHARSET-MIB
IANA-FINISHER-MIB
IANA-GMPLS-TC-MIB
IANAifType-MIB
IANA-IPPM-METRICS-REGISTRY-MIB
IANA-ITU-ALARM-TC-MIB
IANA-LANGUAGE-MIB
IANA-MALLOC-MIB
IANA-MAU-MIB
IANA-PRINTER-MIB
IANA-RTPROTO-MIB
IANATn3270eTC-MIB
IF-CAP-STACK-MIB
IFCP-MGMT-MIB
IF-INVERTED-STACK-MIB
IF-MIB
IGMP-STD-MIB
INET-ADDRESS-MIB
INTEGRATED-SERVICES-GUARANTEED-MIB
INTEGRATED-SERVICES-MIB
INTERFACETOPN-MIB
IPATM-IPMC-MIB
IP-FORWARD-MIB
IPMCAST-MIB
IP-MIB
IPMROUTE-STD-MIB
IPOA-MIB
IPS-AUTH-MIB
IPSEC-SPD-MIB
IPV6-FLOW-LABEL-MIB
IPV6-ICMP-MIB
IPV6-MIB
IPV6-MLD-MIB
IPV6-TC
IPV6-TCP-MIB
IPV6-UDP-MIB
IRTF-NMRG-SMING
IRTF-NMRG-SMING-EXTENSIONS
IRTF-NMRG-SMING-TYPES
ISCSI-MIB
ISDN-MIB
ISIS-MIB
ISNS-MIB
ITU-ALARM-MIB
ITU-ALARM-TC-MIB
Job-Monitoring-MIB
L2TP-MIB
LANGTAG-TC-MIB
LMP-MIB
MALLOC-MIB
MAU-MIB
MIDCOM-MIB
MIOX25-MIB
MIP-MIB
MOBILEIPV6-MIB
Modem-MIB
MPLS-FTN-STD-MIB
MPLS-L3VPN-STD-MIB
MPLS-LC-ATM-STD-MIB
MPLS-LC-FR-STD-MIB
MPLS-LDP-ATM-STD-MIB
MPLS-LDP-FRAME-RELAY-STD-MIB
MPLS-LDP-GENERIC-STD-MIB
MPLS-LDP-STD-MIB
MPLS-LSR-STD-MIB
MPLS-TC-STD-MIB
MPLS-TE-STD-MIB
MSDP-MIB
MTA-MIB
NAT-MIB
NET-SNMP-AGENT-MIB
NET-SNMP-EXAMPLES-MIB
NET-SNMP-EXTEND-MIB
NET-SNMP-MIB
NET-SNMP-PASS-MIB
NET-SNMP-TC
NETWORK-SERVICES-MIB
NHRP-MIB
NOTIFICATION-LOG-MIB
OPT-IF-MIB
OSPF-MIB
OSPF-TRAP-MIB
PARALLEL-MIB
P-BRIDGE-MIB
PerfHist-TC-MIB
PIM-MIB
PIM-STD-MIB
PINT-MIB
PKTC-IETF-MTA-MIB
PKTC-IETF-SIG-MIB
POLICY-BASED-MANAGEMENT-MIB
POLICY-DEVICE-AUX-MIB
POLICY-DEVICE-AUX-MIB-orig
POWER-ETHERNET-MIB
PPP-BRIDGE-NCP-MIB
PPP-IP-NCP-MIB
PPP-LCP-MIB
PPP-SEC-MIB
Printer-MIB
PTOPO-MIB
Q-BRIDGE-MIB
RADIUS-ACC-CLIENT-MIB
RADIUS-ACC-SERVER-MIB
RADIUS-AUTH-CLIENT-MIB
RADIUS-AUTH-SERVER-MIB
RADIUS-DYNAUTH-CLIENT-MIB
RADIUS-DYNAUTH-SERVER-MIB
RAQMON-MIB
RDBMS-MIB
RFC1065-SMI
RFC1155-SMI
RFC1158-MIB
RFC-1212
RFC1213-MIB
RFC-1215
RFC1269-MIB
RFC1271-MIB
RFC1285-MIB
RFC1316-MIB
RFC1381-MIB
RFC1382-MIB
RFC1414-MIB
RIPv2-MIB
RMON2-MIB
RMON-MIB
ROHC-MIB
ROHC-RTP-MIB
ROHC-UNCOMPRESSED-MIB
RS-232-MIB
RSTP-MIB
RSVP-MIB
RTP-MIB
SCSI-MIB
SCTP-MIB
SFLOW-MIB
SIP-COMMON-MIB
SIP-MIB
SIP-SERVER-MIB
SIP-TC-MIB
SIP-UA-MIB
SLAPM-MIB
SMON-MIB
SMUX-MIB
SNA-NAU-MIB
SNA-SDLC-MIB
SNMP-COMMUNITY-MIB
SNMP-FRAMEWORK-MIB
SNMP-MPD-MIB
SNMP-NOTIFICATION-MIB
SNMP-PROXY-MIB
SNMP-REPEATER-MIB
SNMP-TARGET-MIB
SNMP-USER-BASED-SM-MIB
SNMP-USM-AES-MIB
SNMP-USM-DH-OBJECTS-MIB
SNMPv2-CONF
SNMPv2-MIB
SNMPv2-SMI
SNMPv2-TC
SNMPv2-TM
SNMPv2-USEC-MIB
SNMP-VIEW-BASED-ACM-MIB
SONET-MIB
SOURCE-ROUTING-MIB
SSPM-MIB
SYSAPPL-MIB
T11-FC-FABRIC-ADDR-MGR-MIB
T11-FC-FABRIC-CONFIG-SERVER-MIB
T11-FC-FABRIC-LOCK-MIB
T11-FC-FSPF-MIB
T11-FC-NAME-SERVER-MIB
T11-FC-ROUTE-MIB
T11-FC-RSCN-MIB
T11-FC-VIRTUAL-FABRIC-MIB
T11-FC-ZONE-SERVER-MIB
T11-TC-MIB
TCP-ESTATS-MIB
TCPIPX-MIB
TCP-MIB
TE-LINK-STD-MIB
TE-MIB
TIME-AGGREGATE-MIB
TN3270E-MIB
TN3270E-RT-MIB
TOKENRING-MIB
TOKEN-RING-RMON-MIB
TOKENRING-STATION-SR-MIB
TRANSPORT-ADDRESS-MIB
TRIP-MIB
TRIP-TC-MIB
TUBS-IBR-AGENT-CAPABILITIES
TUBS-IBR-LINUX-MIB
TUBS-IBR-LINUX-NETFILTER-MIB
TUBS-IBR-NFS-MIB
TUBS-IBR-PING-MIB
TUBS-IBR-PROC-MIB
TUBS-IBR-TEST-MIB
TUBS-IBR-TNM-MIB
TUBS-IBR-XEN-MIB
TUBS-SMI
TUNNEL-MIB
UCD-DEMO-MIB
UCD-DISKIO-MIB
UCD-DLMOD-MIB
UCD-IPFWACC-MIB
UCD-SNMP-MIB
UDPLITE-MIB
UDP-MIB
UPS-MIB
URI-TC-MIB
VDSL-LINE-EXT-MCM-MIB
VDSL-LINE-EXT-SCM-MIB
VDSL-LINE-MIB
VPN-TC-STD-MIB
VRRP-MIB
WWW-MIB
Custom MIBs
CDRouter SNMP supports loading custom MIB files. This will allow CDRouter SNMP
to display custom MIBs using the appropriate names/display hints and fully
decode SNMP packets containing custom OIDs in CDRouter’s web packet viewer.
Follow the steps below to ensure your custom MIB is fully integrated with
CDRouter SNMP. These commands must be run while logged in as the root
user.
-
Create the directory
/usr/cdrouter/share/mibs/site
if it does not already exist$ mkdir /usr/cdrouter/share/mibs/site
-
Place your custom MIB file in the newly-created directory. Its filename should be the same as the module it is defining
$ cp MY-CUSTOM-MIB.txt /usr/cdrouter/share/mibs/site
-
Create the directory
/root/.wireshark
if it does not already exist. CDRouter is shipped with a version of wireshark to decode and display packet contents. The files in this directory tell wireshark which MIB files to load and how to display them in decoded SNMP packets.$ mkdir /root/.wireshark
-
Make a copy of CDRouter’s
/usr/cdrouter/share/wireshark/smi_modules
file and place it in the/root/.wireshark
directory.$ cp /usr/cdrouter/share/wireshark/smi_modules /root/.wireshark/smi_modules
-
Edit the
/root/.wireshark/smi_modules
file and add the name of your custom MIB in quotation marks to the file on its own line.# Default MIB modules to load "MY-CUSTOM-MIB" "IP-MIB" "IF-MIB" "TCP-MIB" "UDP-MIB" "SNMPv2-MIB" "RFC1213-MIB" "IPV6-ICMP-MIB" "IPV6-MIB" "SNMP-COMMUNITY-MIB" "SNMP-FRAMEWORK-MIB" "SNMP-MPD-MIB" "SNMP-NOTIFICATION-MIB" "SNMP-PROXY-MIB" "SNMP-TARGET-MIB" "SNMP-USER-BASED-SM-MIB" "SNMP-USM-DH-OBJECTS-MIB" "SNMP-VIEW-BASED-ACM-MIB"
Note: This must be the actual name of the custom MIB module and not the name of the file it is defined in. The name of the MIB can be found in the “DEFINITIONS” line of the MIB file.
$ grep "DEFINITIONS" /usr/cdrouter/share/mibs/site/MY-CUSTOM-MIB.txt MY-CUSTOM-MIB DEFINITIONS ::= BEGIN
-
Edit or create the file
/root/.wireshark/preferences
and ensure the following values are setnameres.mac_name: TRUE nameres.transport_name: TRUE nameres.network_name: TRUE nameres.load_smi_modules: TRUE nameres.suppress_smi_errors: FALSE
-
Restart CDRouter
$ service cdrouter restart
SNMP Scenario Testing
Starting in CDRouter 10.1, users may create SNMP scenarios to easily get, set and verify SNMP MIB objects on their device. SNMP scenarios are small text-based scripts that define interactions between CDRouter and the CPE device under test.
The scenario file you create will be executed by the snmp_scenarios.tcl test module, which can be added to your test package to run among all other tests.
To get started with SNMP scenarios, create an SNMP scenario script file on the local disk of your CDRouter system. The scenario script file may contain one or more “scenario” blocks denoted by the “SNMP” keyword. Each “scenario” contains one or more “commands” from the list below, which direct CDRouter to send SNMP requests to the DUT and interpret the response.
Once you have created your scenario script file, update the following testvars in your config file:
-
snmpScenarioPath - This must be set to the full path to the SNMP scenario script file you created. Multiple scenarios can be defined in this file, each with a unique name.
-
snmpScenarioInterface - CDRouter will send requests to the IPv4/IPv6 address of the DUT that corresponds to the interface named by this testvar. The values
'wan'
and'lan'
correspond respectively to CDRouter’s primary WAN and LAN interfaces in the config file. Other interfaces defined in testvar_groups may be specified by name (eg.'lan2'
,'lan3'
,'wan2'
, etc.).If CDRouter DOCSIS is also configured, the special value
'docsis'
may be used to specify that CDRouter send SNMP requests to the Cable Modem of the DUT. -
snmpScenarioIpVersion - This may be set to
'IPv4'
or'IPv6'
to specify which address family should be used for SNMP requests. The DUT must have a reachable address on the interface specified by snmpScenarioInterface .
Scenario Script Format
Each SNMP scenario script file may contain one or more scenario blocks which are executed as a unit. Each scenario block is defined by the SNMP keyword and a unique name for the scenario block, followed by a list of commands to execute, all enclosed in curly braces (’{ }’).
SNMP example_scenario {
<command>
<command>
<command>
:
:
}
Each command is a keyword that may also have a number of arguments enclosed in curly braces. The table below lists all of the available commands that can be used in a scenario block:
Available Commands |
---|
GetRequest |
GetNextRequest |
SNMPWalk |
SNMPTable |
SetRequest |
Delay |
Log |
Simple Example
Here is a simple SNMP scenario to request two OID values with a single GetRequest command. Each scenario must be given a unique name when it is defined. All MIB objects must be specified with their full numeric OID.
This SNMP scenario consists of one command. Some commands correspond directly to SNMP PDUs that can be sent, and may contain additional arguments to verify the response from the DUT
For example, the GetRequset
command sends an SNMP GetRequest PDU to the
DUT. The command contains a list of one or more oid
arguments to
specify which object OIDs to include in the PDU.
SNMP example_scenario {
GetRequest {
# get OID values from the mib-2 system and interfaces groups
# sysDescr.0
# ifOperStatus.1
oid .1.3.6.1.2.1.1.1.0
oid .1.3.6.1.2.1.2.2.1.8.1
}
}
The GetRequest command may also contain verify
arguments to check
whether the response from the DUT matches expected values.
Here is another example:
SNMP example_scenario {
GetRequest {
# get OID values from the mib-2 system and interfaces groups
# sysDescr.0
# ifOperStatus.1
oid .1.3.6.1.2.1.1.1.0
oid .1.3.6.1.2.1.2.2.1.8.1
# verify the response
verify .1.3.6.1.2.1.1.1.0 "OpenWrt"
verify .1.3.6.1.2.1.2.2.1.8.1 "up(1)"
}
}
Scenario Commands
SNMP Scenarios contain commands that map directly to executable
commands in the Net-SNMP package bundled with
CDRouter. For example, to set specific object values, use the SetRequest
command and a valid OID instance. To read the values of objects, use the
GetRequest
, GetNextRequest
, SNMPWalk
, and SNMPTable
commands.
When specifying OID’s in SNMP Scenario commands, they should be specified in numerical format (dotted-decimal) rather than symbolic names. When verifying the DUT’s response, value should exactly match the format presented by the Net-SNMP tools.
GetRequest, GetNextRequest, and SNMPWalk Commands
The GetRequest
command may specify one or more full OID instances with
the oid
argument. The OID specified must match an object instance
that exists on the DUT in order for the request to be successful.
The GetNextRequest
command may specify one or more OIDs, which may
or may not map to real objects defined in the MIB. The DUT will return
the OID instance that comes immediately after the OID contained in the
oid
argument.
The SNMPWalk
command may specify a single OID only, which may or may
not map to a real object defined in the MIB. The result of an SNMPWalk
command will be all of the OID instances that come immediately after the
OID contained in the oid
argument and also share the same OID prefix.
The result of an SNMPWalk
ends when the DUT returns an OID instance
whose prefix does not match the oid
argument or the end of the MIB
database is reached.
GetNextRequest {
# get next OID after mib-2 "system" group
oid .1.3.6.1.2.1.1
}
“verify” argument
The optional verify
argument can be used to verify the value of any
OID instance returned by the DUT in a GetRequest
, GetNextRequest
,
or SNMPWalk
command. Multiple verify
arguments can be specified to verify the values of
different OIDs contained in the same response from the DUT.
Each verify
argument takes the following form:
verify <oid> <value>
-
By default,
verify
will check to ensure that the value of the specified object exactly matches<value>
. Values containing spaces or special characters should be placed in curly braces ({<value>}).GetRequest { ## ifOperStatus oid .1.3.6.1.2.1.2.2.1.8.1 verify .1.3.6.1.2.1.2.2.1.8.1 "up(1)" }
-
[ any ]
The
any
keyword ensures the object exists without regard for its value. This is useful for objects such as packet counters which may be constantly changing. Empty (null) values are also acceptable.verify .1.3.6.1.2.1.2.2.1.8.1 [ any ]
-
[ accept … ]
The
verify
argument can also be configured to accept a list of values using the syntax[ accept value1 value2 ... ]
. The value returned by theGetRequest
,GetNextRequest
, orSNMPWalk
call will then be compared to the list of acceptable values.verify .1.3.6.1.2.1.2.2.1.8.1 [ accept "up(1)" "down(2)" ]
-
[ expr … ]
The
expr
keyword can be used to compare whether numerical OID instance values are less than, greater than, or equal to a specific value. The special keyword'VALUE'
is used to represent the OID value returned by the DUT.verify .1.3.6.1.2.1.2.2.1.10.1 [ expr {VALUE > 0} ]
-
[ regexp … ]
The
verify
argument can compare the value returned by theGetRequest
,GetNextRequest
, orSNMPWalk
GetRequest
call against a TCL regular expression if the exact value is not known. Any valid TCL regular expression string may be used and should be enclosed in curly braces (’{}’).# ifInOctets.1 verify .1.3.6.1.2.1.2.2.1.10.1 [ regexp {[0-9]+} ]
SNMPTable Command
The SNMPTable
command requests all of the OID instances contained within
a specific table of the MIB and displays them in a formatted table.
The oid
argument must specify a single object OID corresponding to a
MIB “table” definition, such as IF-MIB::ifTable
.
SNMPTable {
oid .1.3.6.1.2.1.2.2
}
“verify” argument
The verify
argument is similar to its counterpart described
above with the following exceptions:
-
Due to the way the Net-SNMP
snmptable
command presents its output, theverify
argument must only specify the object name without any leading path or instance (eg. “ifInOctets”). This identifies the “column” of the table being verified. -
The
verify
argument verifies every instance (row) of the named OID that the DUT returns, and it will print a separate PASS or FAIL message instance.SNMPTable { ## IF-MIB::ifTable oid .1.3.6.1.2.1.2.2 verify ifInOctets [ expr {VALUE > 0} ] }
“contains” argument
The contains
argument is only available with the SNMPTable command.
It is identical to verify
, but it only produces a single PASS or
FAIL message to represent all instances returned by the DUT. If all
instances of the OID meet the criteria of the verify
argument, then a
PASS message is printed. Otherwise, if any instance does not meet the
verify
criteria, a FAIL message is printed.
SNMPTable {
## IF-MIB::ifTable
oid .1.3.6.1.2.1.2.2
contains ifInOctets [ expr {VALUE > 0} ]
}
SetRequest command
The SetRequest
command is used to modify the value of a MIB object. The command
must specify a full object OID instance using the oid
argument, along with a value and type specification.
SetRequest {
# sysName.0
oid .1.3.6.1.2.1.1.5.0 {QA Cafe} STRING
}
The following types can be specified:
- INTEGER (eg. `{-2147483648}` )
- UNSIGNED (eg. `{4294967295}` )
- STRING (eg. `{QA Cafe}` )
- HEX_STRING (eg. `{51 41 20 43 61 66 65}` )
- DECIMAL_STRING (eg. `{81 65 32 67 97 102 101}` )
- OBJID (eg. `{.1.3.6.1.2.1.1.1.0}` )
- TIMETICKS (eg. `{14713580}` )
- IPADDRESS (eg. `{192.168.1.1}` )
- BITS (eg. `{0 4 7 8}` )
- FLOAT (eg. `{-3.141592}` )
- DOUBLE (eg. `{-3.141592653589793}` )
- INT64 (eg. `{-9223372036854775808}` )
- UINT64 (eg. `{18446744073709551615}` )
Delay Command
The Delay
command can be used to insert an arbitrary delay, in milliseconds,
anywhere within the scenario file. This can be useful for investigating timing
issues between successive RPCs.
SNMP Delay_example {
# Pause for 60 seconds
Delay 60000
}
Log command
The Log
command can be used to insert a user defined message into the log
file. This command can be used anywhere within a scenario file.
SNMP log_example {
Log "Here is a GetRequest for sysDescr.0"
}
Run a single scenario from the SNMP scenario file
Rather than running all SNMP scenarios defined in the scenario file all at once, it is possible to run the scenarios one at a time by setting the following testvar:
testvar snmpScenarioSingleMode yes
If set to yes, then only a single SNMP scenario will be run for each iteration of the snmp_scenario_1 test. If the CDRouter test package is defined such that the snmp_scenario_1 test is repeated or looped, then each iteration of the snmp_scenario_1 test will run a subsequent scenario.
Testing Exercises
A great way to start testing an SNMP enabled CPE with CDRouter is to simply configure and run each of the applicable test modules included with the CDRouter SNMP add-on individually. Analysis of these initial results will provide valuable insight and may help identify basic functional issues within the DUT that should be addressed.
The following sections describe some of the more common advanced testing exercises that are possible with CDRouter SNMP.
Vary the IPv4/IPv6 Configuration
There are a number of different configuration scenarios that can be created with CDRouter which involve different combinations of IPv4 and IPv6 WAN and LAN modes and various configuration options. One simple yet powerful test exercise is to run the same set of SNMP tests while varying the underlying IPv4 and/or IPv6 configuration of the DUT. The DUT’s SNMP functionality should remain consistent across all of the IPv4 and IPv6 configuration scenarios supported.
Test with Wireless
The DUT’s SNMP related functionality should be consistent over both wired and wireless LAN interfaces. With CDRouter it is very easy to confirm this by adding at least one wireless LAN interface to your configuration file. In addition, SNMP functionality can be verified over all of the wireless modes and security schemes supported by the DUT.
Test with Different Timeout Values
CDRouter Storage includes configuration options for adjusting the SNMP user retries, snmpRetries , and the timeout period in seconds between retries, snmpTimeout . These options are useful for ensuring that the DUT is responsive and capable of performing the desired operations within a practical amount of time. If the DUT takes longer than 10 seconds to complete any operation, CDRouter’s SNMP client will time out and the test will fail.
Verify Service Availability
Another good testing exercise is to verify that SNMP is indeed unavailable when it is disabled within the CPE’s management interface. Some implementations may continue to allow access through SNMP even if it is administratively disabled. With CDRouter this condition can be easily tested. Start by building a baseline configuration and test package for the various SNMP services supported by the DUT. Next, disable SNMP and verify that all applicable tests generate failures. In this scenario test failures represent positive results, indicating that SNMP is indeed disabled.
Test Different Users and Shares
With CDRouter SNMP an arbitrary number of SNMP user configurations can be defined. Including a variety of different user configurations in your CDRouter configuration file is a good way to verify the SNMP functionality of the DUT. Many different scenarios involving different SNMP versions, communities, security levels, and authentication/privacy protocols can be easily tested with CDRouter SNMP. Some simple examples are provided below:
-
Create two different users with different SNMP versions (such as v2c and v3).
-
Create two different SNMP v3 users with different security levels. User1 might be authenticated but not encrypted, whereas User2 may be authenticated and encrypted.
Verify Management Access Restrictions
CDRouter allows you to choose an arbitrary source address for all SNMP requests via the snmpManagerIp and snmpManagerIpv6 testvars. This can be used to indirectly verify that the DUT only responds to SNMP requests from hosts from an authorized address or address range.
Duration Testing
The CDRouter UI allows for editing a package which includes a number of useful run-time options which can be utilized to ensure SNMP functionality over long durations. For example, with CDRouter you can easily repeat the same SNMP test (or tests) 1000 times to ensure robustness and consistent behavior.
Possible Problems
Firewall Preventing Access from WAN
Some devices support SNMP on the WAN but do not automatically create a firewall entry to allow access. If SNMP has been enabled on the WAN but tests are failing, check the firewall configuration. A firewall rule may need to be manually added to allow SNMP traffic.
Source Address Filtering
Some devices implement source address filtering to limit SNMP requests to a specific, known set of IP addresses. CDRouter’s LAN IPv4 and IPv6 addresses and the IPv4 and IPv6 remote host addresses (testvars remoteHostIp and ipv6RemoteHost , respectively) should be added as allowed source addresses.