The MIMIC Recorder lets you easily create starting simulations of actual devices on your network. The starting simulation of a device has the following characteristics:
This means that the simulated device will look like a copy of the real one: values returned by the MIMIC Simulator of a simulation created by the Recorder will return exactly the values of all MIB objects discovered, and for MIB objects of type Counter, return values that change at the average rate calculated by the recorder.
The MIMIC Recorder can run in either live or file mode. In live mode, the Recorder interacts with one or more running target devices on your network in real time. In the discovery phase, the Recorder walks the entire MIB (or, optionally, a subset of the MIB) of each target device, and stores the retrieved values. In the second simulation phase, the Recorder creates the simulation from the discovered values.
The file mode works by reading a walkfile created previously either with other commercial or public domain MIB browser utilities (SNMP Walk utilities) or from a previous run of the Recorder against a Live target device.
Once data is captured from a device, the MIMIC Agent Simulator can use the simulation generated by the Recorder to simulate the device realistically. Any variation on this basic simulation can later be done for use with the Simulator. This is accomplished by changing:
There are two ways of starting the MIMIC Recorder:
If you haven't done so yet, read the Recording a Device section in the
The recorder can interact with any number of target devices simultaneously. The MIB walk of each target device in the discovery phase is interleaved for maximum performance. Each target is then simulated separately in the simulation phase (there is no performance benefit in handling them together).
The Record Live dialog allows you to start a recording for the specified list of targets.
Figure - Dialog for recording a live device
Specifies the target IPv4 address, either as "dot-value" notation (e.g., 192.9.200.1), or as a hostname (e.g., gambit), or fully qualified domainname (e.g., gambit.gambitcomm.com) provided that they can be resolved to an address (via /etc/hosts, Yellow Pages or DNS).
For IPv6 addresses, the standard notation is used, eg. fe80::a00:20ff:fef5:57c. On Windows, Scope IDs need to be specified, as detailed in the Windows installation section.
The Recorder talks to the standard SNMP port 161 on the target device. If the device is configured to use a non-standard port, you can specify it in this option.
This specifies the version of SNMP to use to access the target device. The possible options are "1", "2c" and "3". The default is SNMPv1.
This specifies the simulation name of the simulation to create. The dialog provides a default simulation name, which you can change. Using an already existing simulation causes the old simulation values to be overwritten with the new.
This specifies a scenario name. The dialog provides a default scenario name which you can change. Using an already existing scenario causes the old simulation values to be overwritten with the new.
Figure - Advanced Tab
In addition, the following advanced options can be supplied for each selected target in the Advanced tab:
The minimum timeout to wait for a reply from the agent (in microseconds). The Recorder uses a binary exponential retransmission scheme to overcome unreliable communications. The default minimum retransmit timeout is 1/2 second (500000 microseconds). This retransmit timeout is doubled on every consecutive retransmit of a PDU.
By default, the Recorder tries at most four times for every SNMP PDU. If no response arrives after the number of retransmits, the PDU times out and the discovery phase is over for the specific target. Use this option for extra slow, distant or erratic devices.
Figure - MIB Tab
The following advanced options control the recording of MIBs for each selected target through parameters in the MIB tab:
By default, the Recorder walks the entire MIB exported by the target device. This option is useful if you want to exclude parts of the MIB from being simulated. For example, some MIB tables (such as RMON history tables) can be extremely dynamic (and large). Other tables implement proprietary retrieval schemes (e.g., getTable). Some devices even crash when you access certain parts of the MIB. This option allows to skip these MIB subtrees.
By default, the Recorder walks the entire MIB exported by the target device. This options lets you specify the starting OID to start recording. This is useful if you want to restart a recording that previously failed for any reason.
By default, the Recorder walks the entire MIB exported by the target device. This options lets you specify the ending OID, ie. the object after which the Recorder stops recording. This option is useful if you are interested in only a small part of the MIB.
By default, the Recorder walks the entire MIB exported by the target device (starting at OID .1.3). This options lets you specify MIB subtrees to record. This option is useful if you are interested in only a small part of the MIB.
Figure - Forced MIB Tab
You can force the inclusion of certain MIBs for the selected target through the list in the Forced MIB tab.
By default, the Recorder will detect only MIBs for which there are discovered MIB objects. If there are certain MIBs, eg. TRAP-only MIBs you want to add to the simulation, you can force them with this option.
This option modifies the simulation for the MIB objects under the specified root to a "static" simulation, which executes much faster (twice as fast) than the basic simulation. It can be used when the basic simulation is not fast enough, and you don't care what values are returned from the simulation. The values assigned to the simulation are hard-coded, rather than through a Value Space lookup.
In terms of simulation language, the SIMULATE clauses are as follows:
This option modifies the simulation for the MIB objects under the specified root to a "fast" simulation, which executes much faster than the static simulation. It can be used when the basic simulation is not fast enough, and you don't care what values are returned from the simulation. The values assigned to the simulation are hard-coded, rather than through a Value Space lookup.
In terms of simulation language, the SIMULATE clauses are as follows:
This options lets you save the walkfile in a directory other than the default (walks/ subdirectory in your private data area).
By default, the Recorder will retrieve all entries for each table. This can take a long time for huge or dynamically increasing tables. Selecting this option limits the size of large tables to the specified number of table entries. It applies both at discovery time, where only the selected number of entries are traversed, and at simulation time, where only the selected number of entries are simulated. This is useful for devices with large tables, such as RMON tables, etc.
This option slows down the retrieval of variables in the discovery phase in order not to overwhelm the target device with SNMP requests. The delay in milliseconds is introduced between the receipt of the response and the sending of the next request. (By default this option is disabled.)
This option allows three choices: random, constant or linear, to specify which of three simulation methods to use for counter simulations. By default, the Recorder simulates every MIB object of type Counter with a rate with a uniformly-distributed "random" variable using the following expression
SIMULATE { uniform_per_tu (lookup ("r"), lookup ("tu")) }
You can use the "constant" option to generate a constant rate simulation with the following expression
SIMULATE { constant_per_tu (lookup ("r"), lookup ("tu")) }
This is equivalent to the function
f(t) = r/tu * t
You can use the "linear" option to generate a linear simulation with the following expression
SIMULATE { lookup ("v") + constant_per_tu (lookup ("r"), lookup ("tu")) }
This is equivalent to the linear function
f(t) = v + r/tu * t
This method is more flexible than the constant method, but will simulate 33% slower, because of the 1 extra lookup.
Selecting this option generates the simulation source file so that you can change the simulation later on. (By default this option is disabled.)
Selecting this option skips the simulation phase and only generates a walk file. This is useful for example if you are at a remote site, and want to generate the simulation later. (By default this option is disabled.)
Use this option to remove the walk file upon completion. This prevents walk files from accumulating in your directory. (By default this option is disabled.)
Enabling this option causes the Recorder to query sysUptime more frequently than every 10 seconds. This provides more accurate extrapolations (based on time) for Counter objects. (By default this option is disabled.)
This options prevents the Recorder from putting symbolic information in the walkfile created during discovery phase of recording. Otherwise, the output walkfile has one commented line of symbolic information for each object exported, e.g.
# sysDescr: read-only OCTET STRING (SIZE (0..255))
(By default this option is disabled.)
This options tells the Recorder how to optimize tablewalk traversal and allows 3 choices: none, row and bulk.
By default, the Recorder will use GETBULK when possible (in versions 2c and 3). In version 1, the Recorder uses a proprietary multi-variable per-PDU row traversal to optimize the number of requests. This behavior can be overridden with the --tablewalk option.
The option none disables any optimizations and will do inefficient single-variable per-PDU GETNEXT traversal.
The option row forces multi-variable per-PDU row traversal.
The option bulk forces GETBULK traversal.
Figure - SNMPv1 Tab
The following options in the SNMPv1 tab apply to each target using the SNMPv1 protocol:
The default community string used is "public" -- if the device uses another read community string, set it in this option.
Figure - SNMPv3 Tab
The following options in the SNMPv3 tab apply to each target using the SNMPv3 protocol:
The authentication and privacy parameters are determined from the user name, context name and the USM and VACM Database files.
The authentication and privacy parameters are determined from the user name, context name and the USM and VACM Database files.
The authentication and privacy parameters are determined from the user name, context name and the USM and VACM Database files. The USM Database file is optional, and will use by default config/v3usm.conf. You can also browse for the file by clicking Browse...
Figure - Record File Dialog
In this off-line simulation method a previously captured data file is fed to the Recorder to simulate a device. As such there is no discovery phase, just a simulation phase. The following options in the General tab are mandatory:
The file contains the previously captured walk of a MIB. This walk can be the output of a third party MIB browsing tool or of a previous live capture from the Recorder. The format of each line in the file needs to be of the form
MIB-object-instance: value
where MIB-object-instance can be in dot-notation or a symbolic name. Since not every browsing tool outputs this format, we provide filters (in the common/ subdirectory) for some of the common tools.
This specifies the simulation name of the simulation to create. The dialog provides a default simulation name that you can change. You can create any number of simulations for a particular device type. Using an already existing simulation causes the old simulation values to be overwritten with the new.
This specifies a scenario name. The dialog provides a default scenario name that you can change. Using an already existing scenario causes the old simulation values to be overwritten with the new.
By default, the Recorder will detect only MIBs for which there are discovered MIB objects. If there are certain MIBs, eg. TRAP-only MIBs you want to add to the simulation, you can force them with this option.
By default, the Recorder will retrieve all entries for each table. This can take a long time for huge or dynamically increasing tables. Selecting this option limits the size of large tables to the specified number of table entries. It applies both at discovery time, where only the selected number of entries are traversed, and at simulation time, where only the selected number of entries are simulated. This is useful for devices with large tables, such as RMON tables, etc.
By default, the Recorder will start at the first line of the walkfile. You can start at a different line with this command line option.
This option allows two choices: random or constant, to specify which of two simulation methods to use for counter simulations. By default, the Recorder simulates every MIB object of type Counter as a uniformly-distributed random variable with the following expression
SIMULATE { uniform_per_tu (lookup ("r"), lookup ("tu")) }
You can use the constant option to generate a constant simulation with the following expression
SIMULATE { constant_per_tu (lookup ("r"), lookup ("tu")) }
See Language Reference.
Selecting this option generates the simulation source file so that you can change the simulation later on. (By default this option is disabled.)
Selecting this option overwrites the entry in the device configuration file (config/dev.cfg), even if the set of MIBs is different. When you record a device, an entry is added to dev.cfg, which you can then select in MIMICView. This option is useful if you are recording a device multiple times, each time with a newly compiled MIB. This is the normal procedure to add a new device to MIMIC, where the set of MIBs supported by the device is unknown. (By default, this option is turned off, causing a new entry to be added to dev.cfg.)
By default, if the Recorder encounters an unknown MIB object, ie. one for which no MIB definition exists in the compiled MIBs, then it will skip creating a simulation for this object, and will print an error message. The count error messages is displayed at the end, providing an overall measure of the correctness of the simulation.
The walkfile saved by the MIMIC Recorder will contain syntax information for unknown objects with a commented line of the form:
# UNKNOWN: read-only syntax
NOTE: any 3rd party walkfile format which does not have type information cannot be processed for unknown objects.
Enabling this option will cause the Recorder to attempt to guess the syntax of the unknown MIB objects, and will try to create a simulation for them. It does this by parsing the syntax information saved for unknown objects and will try to derive correct indexing through proprietary heuristics.
Since no MIB object naming information is known, the Recorder assigns names to the objects of the form unknown-dashed-OID, table-dashed-OID, entry-dashed-OID, where dashed-OID is the dotted OID notation, where the dot is substituted with a dash to conform with SMI rules. These MIB object names will not be used when responding to SNMP requests, but will be displayed when queried through MIMIC clients (MIMICView or MIMICshell).
In addition, a MIB is created containing derived (guessed) definitions for the unknown objects. The MIB has the name UNKNOWN/simulation-scenario-MIB, where simulation and scenario are the simulation and scenario names. It is compiled in, so that future recordings will take this definition.
NOTE: the Simulation Wizard provides a user-friendly front-end to mib2walk.
For example:
mib2walk RFC1213-MIB IF-MIB DIAL-CONTROL-MIB xylan/XYLAN-ATM-MIB > walkfiletemplate
The walkfile template will contain two lines per MIB object: a comment containing object name, type and other information; and a line containing the OID of the object.
You can use this template to create your simulation by
You then feed the modified walkfile to the MIMIC Recorder to create the simulation.
The MIMIC Recorder is designed to aid in this process by allowing you to implement the simulation incrementally. To skip processing the remaining walkfile, just add a line with
exit
in it. Thus you can incrementally implement more and more of your simulation, and just move the exit point forward.
Note that counter objects depend on the notion of time to be able to extrapolate the rate for the rate-based simulation. Thus, if you want to simulate counters, you will need to define a line that sets sysUpTime at the beginning of your walkfile, such as
1.3.6.1.2.1.1.3.0: 100
Note that sysUpTime is counted in TimeTicks (1/100 sec), thus 1 sec is equivalent to 100 TimeTicks.
This section defines the format of the walkfile understood by the MIMIC Recorder. It is similar to most common walkfile formats and there is a conversion utility and conversion scripts in the common/ directory to convert from popular formats to the MIMIC format.
Each variable-value binding is represented by one or more lines with the following single-line or multi-line formats:
[OID]: [value]
or
[OID]: [value]
[value continuation]
For example:
These are sample MIMIC walkfile lines
1.3.6.1.2.1.1.1.0: Cisco Systems WS-C5000
1.3.6.1.2.1.1.2.0: 1.3.6.1.4.1.9.5.7
1.3.6.1.2.1.1.3.0: 107d 10:25:09.99
This shows a mult-line hex value
1.3.6.1.4.1.9.5.1.3.1.1.15.5: \x02 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 01 01 01
Notice that a variable-value binding line starts with a blank character. All other lines (except value continuation lines) are interpreted as comments. Value continuation lines are useful for long hexadecimal values. There is a blank character between the ":" and the value.
The [OID] field can be numeric or symbolic, but numeric OIDs are preferred.
The [value] field has the following formats for the different types:
In addition, each line containing a new MIB object will have a comment with the SYNTAX for that MIB object. This is not only for documentation, but for unknown objects allows better simulation. For details, see above.