Product
Search Results

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:

Test Setup for CPE Device with Integrated SNMP Functionality

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.

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.

  1. Create the directory /usr/cdrouter/share/mibs/site if it does not already exist

    $ mkdir /usr/cdrouter/share/mibs/site

  2. 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

  3. 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

  4. 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

  5. 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

  6. Edit or create the file /root/.wireshark/preferences and ensure the following values are set

    nameres.mac_name: TRUE
nameres.transport_name: TRUE
nameres.network_name: TRUE
nameres.load_smi_modules: TRUE
nameres.suppress_smi_errors: FALSE

  7. 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 the GetRequest, GetNextRequest, or SNMPWalk 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 the GetRequest, GetNextRequest, or SNMPWalk 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, the verify 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.