SNMP-management software usually has little impact on network performance. The software might make changes to performance reports or monitor a particular network device in real time--both low-risk activities that don't affect network stability. But that doesn't mean you want to let newbies take a whack at SNMP's bells and whistles while they learn the ropes. When it comes time to train new operators or helpdesk personnel on the features and functionality of production network-management tools, products that simulate SNMP are ideal. They shield your network while providing a useful test bed.

To SNMP network-management tools, the SNMP simulation appears to be a real network. No switches or routers are required. The SNMP agents for those devices modeled in software can operate on a PC or Unix desktop, appear as devices available off a routed segment and populate network topology maps. Link utilization, error rates, MAC-to-IP mapping, traps and anything else that an SNMP agent on an actual device does can be simulated. When a simulated device, such as a router or switch, is started, it presents the MIB structure and data via SNMP at a specific IP address. A network-management application perceives no difference between the simulated device and a real one.

Unlike network simulators, which create "what-if" scenarios to show the effect of network design on traffic and of load on network services, SNMP simulators run actual addressable MIBs. Entire MIB structures, a portion of a MIB or multiple combined MIBs can be simulated. The MIBs can be any standard or private MIB of SNMP version 1, 2C or 3 (not all simulation products support version 3, so if such functionality is important to you, make sure you choose one that does).

In addition, MIB-instance values can be loaded manually or learned automatically. Learning a device is a series of SNMP GetNext operations that determine the MIB structure. The values are then monitored for a short time to determine the rate of change. TCL scripting is used to increment or decrement the MIB values in the simulated devices. These changing values make the simulated network come alive. The downside is that you'll have to make the time to learn TCL if you don't already know it.

Addressing Topology

In a real network, the values collected by SNMP agents represent actual traffic that has a direct relationship to how the devices are connected. The InOctets values on one port are going to match the OutOctets on the port connected to it. Just as managing a network using SNMP is a complex task in part because of the diversity of SNMP, using and setting up a simulated network take some work.

The number of SNMP MIBs supported can be overwhelming when trying to simulate a device. During the GetNext process, known and unknown MIB OIDs (Object Identifiers) are logged. This process helps identify the MIBs a device supports. You can get a lot of mileage out of RFC 1213 (MIB2) and RFC 1493 (the dot1Bridge MIB). If you need to simulate other standard MIBs or private MIBs see "SNMP Resources" for some starting points.

Being specific about which MIBs to simulate may be a case of less is more, because the more MIB instances are simulated, the more memory is consumed. Eventually this will limit the number of devices you can simulate. Most SNMP-simulation products can support 1,000 devices using standard desktops. The general rule of thumb is to allocate 1 MB of memory per device. However, some products consume less by sharing definitions. If you are simulating many similar devices, the additional memory required for subsequent devices may be greatly reduced, making it possible to increase the number of devices supported on the same hardware.

SNMP simulation (screen view) Click here to enlarge

Copying device information from real devices may be problematic. The copying process is as easy as specifying a starting IP address and the number of devices to be cloned. However, all the IP and MAC addresses referenced in the original MIBs are copied without change.

One workaround in some simulators is to create a variable out of the device IP address. When a device is being created, a variable like $$MYIPADDRESS$$ can be substituted for the simulated device's IP address. This solves the problem only for the simulated devices' IP addresses referenced in the MIB. However, the MIB values are stored in text files, making it easy to search for and replace the network portion of the address.

To get the right relationships between devices without concerning itself with what address is attached where, the SNMP simulation product needs to support autodiscovery of a range of network addresses. This is the same process network-management tools use to find devices. The SNMP simulation software queries the device using a list of SNMP community strings. To ensure accuracy, you should audit the devices and the MIBs they support.

New Features

As SNMP simulation suites grow more popular, vendors are adding new features. Some suites now support telnet, TFTP and FTP simulation. Telnet simulation is a great teaching tool: It lets newbies practice actual router and switch commands and learn about management software--without a dedicated infrastructure for training or risking a production network.

TFTP and FTP simulations are straightforward for the sim vendors. Both are mature, well-defined protocols. As with SNMP simulation, a set of TCL commands controls the FTP and TFTP behaviors. TFTP is the easiest--it's a simple matter of getting and sending files. FTP has a few more interactions, such as supporting PWD, CD and BIN commands. But these, too, are a short set with little variation.

Telnet, however, is a different story. Telnet is just about access; it doesn't define the infrastructure hardware's configuration application. In addition, the CLI (command-line interface) interaction via telnet is not standardized in any way--it varies from vendor to vendor, version to version, model to model, and feature set to feature set. It can get hairy fast. While you'd expect the telnet interaction between devices from Cisco Systems and Extreme Networks, for example, to be different, you'll also find the interaction between Cisco 2600 devices running different versions of IOS is different. This makes for a ton of work in setting up a realistic simulation.

To this end, it's important to have a simulation that learns a CLI flow by recording keyboard input and video response. For the most part TCL is used as the scripting language for these products, and the macro-like CLI recorders create editable TCL. Fortunately, the format for this is self-documenting. This also means that if you have network-management applications that telnet into routers and switches to retrieve and set configuration, those functions can be taught and tested offline.

Telnet-CLI response and the combination of SNMP gets and sets and behind-the-scenes TCL-scripted manipulation of SNMP values make the simulated network seem very real. What is lacking is a bridge between the setting of the CLI configuration and having it show up in a new response by the network infrastructure in reaction to a traffic load.

This is not to say that certain static scenarios couldn't be set up via TCL. If your TCL chops are really good, you could set it up so a configuration change in the network would make a difference in the way the network handles a given load. But remember, there isn't any real traffic and there isn't any real infrastructure handling that traffic. No matter how talented you are with TCL, the only response the TCL simulation will garner is static.

Given the accuracy of SNMP simulation, the administrative, operational and training flexibility makes it a useful tool. Having a replication of a real network with all its performance variations is worth the setup headaches.