MIMIC^® Online Documentation

When we encounter this question, often the answer is "because other software is hogging the system". All bets are off if MIMIC has to compete on the system with other software.

If you want to run MIMIC with predictable performance, then you have to cut down on interference from other software running on the system. This not only includes the bundled services we have identified for the supported OS platforms, ie. Windows Services and Linux daemons. but also applies to any other third-party programs that run concurrently, including Virus checkers, Automatic Software Updates such as Windows Automatic Updates, or any other background processes.

The first step to check for interference is always a process listing, such as that displayed by Windows Task Manager, and the top utility on Unix.

The tricky part is that interference can be sporadic, short-lived and quite hidden, thus sometimes hard to track down. For that reason, if you care about MIMIC performance, we highly recommend running MIMIC on a dedicated system with minimal other extraneous software.

A. These old versions of Windows are not supported any more.

We recommend running MIMIC on the latest supported Windows version, or Linux platforms as detailed on our "Supported Platforms" page.

A. You can download an unsupported binary distribution of the net-snmp (was UCD SNMP) toolset from our website.

A. The MIMIC installation instructions contain upgrade information:

1. make sure you terminate MIMIC (use File->Terminate) before running the installation program.

2. Do NOT uninstall the older release (this way you can always fallback in case of problems).

3. Install this release in a different directory from the older release. All your MIMIC data files will be fetched out of your existing private area.

4. For minor release upgrades (eg. from 5.00 to 5.10) you only need to supply your existing license keys to the install script and start the new MIMIC.

5. For major release upgrades (eg. from 4.xx to 5.xx) you may need to request new license keys. Send your HOSTID to support@gambitcomm.com .

A. MIMIC is a distributed/client-server application, and you still have the old daemon process running. You need to terminate the old version of the MIMIC Simulator before you run the new version. You have a couple of choices:

1) kill the MIMIC daemon. On Linux do something similar to

# ps ax | grep mimicd

and kill that process. On Windows, kill the mimicd.exe from the task manager.

OR

2) run the old mimicview. Do "File --> Terminate".

When you restart the new mimicview, a log window should appear with the log output of the new MIMIC simulator daemon.

> Also, how is MIMIC programmed?  What programming language?  Tcl?
> Scripts?  What type of development environment?  How customizable is it?

MIMIC is highly customizable. In the basic simulation, you can export any MIB data you want, by adding new MIBs to the already compiled 2500+ MIBs (with MIB Wizard ), recording real device data (with Simulation -> Record or Snapshot Wizard or Discovery Wizard ), or defining simulations (with Simulation Wizard ).

To create advanced simulations, you can use several levels of programming:

1. write MIMICshell scripts, which run externally to the MIMIC Simulator in a MIMICshell client and control the simulation (eg. start/stop agents, change values, generate traps, etc). These scripts are written in a superset of Tcl (with MIMIC command extensions, as documented in Simulator Guide, MIMICShell reference section ).

2. write action scripts which are executed inside the MIMIC daemon on particular events, eg. when an SNMP request is received for a MIB object. The action script is written in a superset of Tcl (with the MIMIC command extensions, as documented in Simulator Guide, Agent -> Actions section ).

3. write timer action scripts, which are executed periodically by the Simulator. Again, timer scripts are written in the same language as 1) and 2). Online help is in the Simulator Guide, Run Menu section .

4. write trap action scripts, which are executed when a trap is generated. Again, trap scripts are written in the same language as 1), 2) and 3). Online help is in the Simulator Guide, Agent -> Generate Traps section.

5. as of MIMIC 4.40, you can use a Java API to control MIMIC in place of/ in addition to 1). This is documented in the Java API Guide .

6. as of MIMIC 5.10, you can use a Perl API to control MIMIC in place of/ in addition to 1). This is documented in the Perl API Guide .

7. as of MIMIC 5.40, you can use a C++ API to control MIMIC in place of/ in addition to 1), 2), 3) and 4). This is documented in the C++ API Guide . In particular, actions can now be written in C++ for best performance.

8. as of MIMIC 9.00, you can use a Python API to control MIMIC in place of/ in addition to 1). This is documented in the Python API Guide . The Python API is an option package installable with the Update Wizard.

9. as of MIMIC 16.10, you can use a PHP API to control MIMIC in place of/ in addition to 1). This is documented in the PHP API Guide . The PHP API is an option package installable with the Update Wizard.

10. as of MIMIC 18.10, you can use a Javascript API to control MIMIC in place of/ in addition to 1). This is documented in the Javascript API Guide .

11. there is a proprietary simulation language (as documented in Compiler Guide, MIMIC Simulation Language Reference section), which you can use to control the simulation. This is needed only in rare cases, where you want the most speed and control.

A commercial TCL development environment is available from ActiveState , called Tcl Dev Kit. It gives you a symbolic debugger environment, etc. You can use it to debug scripts written for 1).

A. There are plenty of book lists and recommendations on Tcl/Tk. See the References section on our Support page.

MIMIC provides a set of simple, illustrative Tcl/Tk-based MIMICshell and action scripts in the scripts/ subdirectory.

A. As detailed above MIMIC can be controlled from various programming languages. Each of them has different performance characteristics (eg. interpreted vs. compiled). This section attempts to show how they stack up to each other.

Oftentimes your choice of language will be determined by factors other than just speed, such as

• knowledge of the language
• efficiency and convenience of other services, eg. graphics, sorting, etc
• policy/politics

but if you have a choice, it could be influenced by speed, specially if controlling MIMIC means issuing many commands (eg. frequently configuring thousands of agents, or millions of MIB values) within time constraints.

The control of MIMIC is a remote procedure call (RPC) mechanism into the MIMIC server. MIMIC commands are performed via RPC calls. The performance of an RPC call is impacted by:

	time(RPC call) = time(language overhead to package and send request) +
		time (transport of request) +
		time (MIMIC server dispatch) +
		time (transport of response) +
		time (language overhead to receive and parse response)

The first thing to realize is that the MIMIC server dispatch time will be the same for all language bindings. For this test, this can be considered a constant for each distinct RPC call.

Second, the transport mechanism for the MIMIC RPC calls is TCP for remote calls (MIMIC client and MIMIC server on distinct machines), and a faster local transport mechanism for local calls (within a machine), such as Unix domain sockets for Unix, and pipes for Windows. Some languages, such as Java on Windows, do not support the local transport mechanism, thus local transport will be slower than on languages that do.

Third, the difference in performance between the language bindings will be reflected primarily in the time(language overhead to package request) and time (language overhead to parse response) numbers, thus our performance tests did focus on calls where the other 3 numbers do not dominate the equation (such as large requests, for which the difference will be much smaller).

Fourth, within a language you may find small fluctuations for different versions of compilers or interpreters. We tested with a recent version for each language.

This matrix contains numbers (calls per second) for some representative RPC calls for the different languages in local and remote mode for a representative Fedora 19 Linux (quad-core Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz) and Windows 8.1 (quad-core Intel(R) Core(TM) i5-2400 @ 3.10GHz) system:

Linux	Windows
Mode C++ Tcl Java (1) Perl Python mimic get max local 69013 19790 55866 15202 18650 remote (4) 40453 14888 33036 12492 14769 mimic agent get host local 91408 19670 64725 24777 21964 remote 50865 16639 40064 18758 16488 mimic value get local 62933 16958 53022 21959 22173 remote 38168 13569 31636 16787 16920	Mode C++ Tcl Java (2) Perl (2) (3) Python (2) mimic get max local 62735 21815 35753 12850 16548 remote 46041 11111 30618 12982 16548 mimic agent get host local 73584 21515 39262 18443 15939 remote 52029 10441 39746 18129 15939 mimic value get local 52882 17373 30479 16038 11305 remote 37864 9916 30331 16160 11305

As expected, the clear winner is C++, in local mode (which is the most common form of control of MIMIC). The other compiled language, Java, is about 20% slower than C++. The interpreted languages are significantly slower than C++ in both modes, less than half that of the compiled languages.

This next matrix shows a more recent test for the different languages in local and remote mode performing 262144 valuespace read operations (65536 iterations, each 1 set, 1 get/eval/mget/meval and comparisons). Numbers show duration in seconds (smaller numbers are better):

Linux	Windows
Mode C++ Tcl Java (1) Perl Python Go (2) Unix-domain 8 32 7 TBD 18 NA TCP localhost 10 34 10 TBD 20 11 TCP remote 128 329 168 TBD 210 262	Mode C++ Tcl Java (2) Perl (2) (3) Python (2) Go (2) Windows pipe 10 33 NA NA NA NA TCP localhost TBD 65 20 TBD 29 TCP remote 124 200 143 TBD 192

This time the winners are C++ and Java, in local mode (which is the most common form of control of MIMIC). The other compiled language, Go, is a little slower than C++. The interpreted languages are significantly slower than C++ in both modes, less than half that of the compiled languages.

A. Tcpdump is a free public domain protocol analyzer. Most Linux distributions include this valuable diagnostic tool.

Wireshark (formerly ethereal) is a great free public domain protocol analyzer. It decodes SNMPv3. Download it for your favorite platform from their website http://www.wireshark.org/.

MIMIC allows you to trace all received PDU requests for any agent instance with the mimic agent set trace command in the MIMICShell. The logged PDUs will be displayed in the MIMIC log window. This way you can see which MIB objects are being accessed. This feature is designed to complement the protocol analyzer output (OIDs, values) by displaying the MIB Object name.

As of MIMIC 9.00, all objects and values are displayed in the log, to enable diagnosis of encrypted SNMPv3 requests.

NOTE: tracing slows down the simulator considerably, and should only be used temporarily to track down a specific problem. To do long-term protocol analysis, one of the external protocol analyzers is recommended, preferably running on a different computer than the MIMIC system.

A. After MIMIC 5.10 the Diagnostic Wizard presents a convenient interface to report problems.

Otherwise, the fastest way of resolving problems is by sending e-mail to support@gambitcomm.com with a brief description of the problem, and supporting information, such as excerpts from the log window that show the problem.

If there is a workaround, we will let you know as soon as possible. If the problem requires a fix, we will open a trouble ticket and schedule it for an upcoming release. All customers are notified of new releases as soon as they become available through the MIMIC User Group mailing list.

If you have a large supporting file from one of the tools (core file, log file, walk file), please don't email it yet since our mail server has limited resources (bandwidth and space). Tell us about the problem first, and we will ask you for the core file.

	If I wanted a 100 node network, I need a 100 agent license. Is this
	correct? How does a router fit in? For example, if I have a router with
	10 interfaces -- is that one agent or 10? I suspect one, but I want
	to ensure my understanding so we know what were buying.

A. Strictly speaking, MIMIC was until 3.33 licensed by number of IP addresses you want to talk to via SNMP (regardless of how many agents the real device implements). Thus, if you want to simulate a device with multiple management interfaces, then you needed to count those towards your license requirements. If the interfaces were not management interfaces (ie. your management application uses a single management interface, read, IP address, to manage the device), then you only needed 1.

After MIMIC 4.00, agents can have IP Aliases, ie. alternate IP addresses that the management application can talk to the agent. These IP aliases do not count toward the number of agents in your license. Thus, you can have many more agents configured with aliases than in earlier releases. There are OS platform limitations of how many IP addresses you can configure. On Windows Vista and later the limit is 20,000; on Linux this is currently 100,000.

After MIMIC 4.00, the answer is: "a 100 agent license supports 100 agents, no matter how many interfaces each has (upto a limit on the OS platform you are running MIMIC on)".

> If I have defined routers with Mib IP interfaces which are not shown
> in the MIMIC map, how would I go about make these IPs available?  That is
> having a simulated router with the IP 192.9.200.180 and the router's MIB
> contains 120 interfaces with addresses ranging from 155.133.1.1 to
> 155.133.1.24 with a mask of 255.255.255.254 each - shouldn't I use
> ifDiag.exe in order to create these IP addresses?  or there another way to
> make these IPs available through mimic TCL programmatically?

A. You can use the IP aliases feature (available after MIMIC 4.00) when you need to associate additional IP Addresses with a simulation that can be pinged and also answer SNMP requests.

The IP aliases can be manipulated using the 'mimic agent ipalias' commands. The list of supported commands are :

Usage:
 mimic agent ipalias list
 mimic agent ipalias add ipaddress,port,[mask],[interface]
 mimic agent ipalias delete ipaddress,port
 mimic agent ipalias start ipaddress,port
 mimic agent ipalias stop ipaddress,port

You can use the 'add' subcommand to add new IP aliases and 'delete' subcommand to remove any existing IP aliases. Also use 'start'/'stop' to actually activate or deactivate the same.

	The problem: the drive that MIMIC is using has become full due
	to MIMIC usage. Is there a way to modify the configuration of
	MIMIC to use another drive for its use?

	This is running on an NT Server with a drive C and D. Mimic
	has been using drive C:

A. You can set the environment variable MIMIC_PRIV_DIR to point to a location on another drive to do this. Determine what directory is being used currently by MIMIC for storing your private data. Copy this over to a different drive and then point MIMIC_PRIV_DIR to this location. Restart MIMIC fresh and all subsequent data should be stored on the new drive.

First, terminate MIMIC (in MIMICView, use File -> Terminate).

• On Unix, in the Cshell do this before invoking MIMICView:
  % setenv MIMIC_PRIV_DIR new-path-to-your-private-area

• On Unix, in the Bourne shell do this before invoking MIMICView:
  # MIMIC_PRIV_DIR=new-path-to-your-private-area; export MIMIC_PRIV_DIR

• On Windows, use the System Control Panel to set MIMIC_PRIV_DIR to the new path.

If this is the case, you can fix it in MIMICView, by re-configuring each agent again (just use Edit->Configure->All... , click Apply). Or you can edit the config/*.cfg files in your private directory with your favorite text editor, search for lines beginning with priv_dir, and remove them.

	I have recorded agents and have placed the results in my
	"private file space".  How do I move those agents to the
	"shared file space"

A. Any private area can be "shared" with other users of MIMIC. In effect, you can have multiple private areas, and choose among them when using MIMIC. By default, MIMIC looks at the mimic/ subdirectory in your home directory. You can override this with the MIMIC_PRIV_DIR environment variable.

Thus if you setup some simulations in your private area, you can move it anywhere, and tell other users to set their MIMIC_PRIV_DIR to that directory path.

Moving the private data into the MIMIC shared area has these downsides compared to the above solution:

1) you can have only one shared area: the MIMIC installation directory.

2) it's tricky - you need to copy the data/sim/* directories, any lab configuration files (config/agents/*.cfg) and update config/dev.cfg.

3) it's not upgradeable out of the box - when you upgrade to your next version of MIMIC, you'll have to perform the same manual steps.

Thus I recommend the first solution, especially if the other users only want read access to the simulations.

> I have recorded an agent and created a new device. I now want to
> "export" this device to the other Mimics
> They are on different PCs and locations in the company.
> Is it possible?

A. Yes this is possible. From MIMIC version 10.30 on you can use the Update Wizard to install an optional patch to export/import simulations. For earlier versions of MIMIC, read on.

Since a device has been designed to be as self-contained as possible, usually consisting only of a simulation directory and some MIBs, you will be required to copy the following directories from the source computer's MIMIC private area to your destination MIMIC private area. (The private area of your system will be displayed on top title bar of the MIMICView GUI application.)

1) /data/sim/<sim-name>/ (each simulation will have one directory, so copy the desired simulation);

2) if the simulation also requires some additional MIBs that you imported/compiled in your private area, then copy /data/mibs/* ;

3) rarely (and only if you use the most advanced features), the device simulation invokes action scripts located outside of the simulation directory. If so, those also need to be copied.

After successful transfer, use the MIMICView Simulation->Devices dialog on your destination system and verify that the new simulation shows up in the list.

NOTE: if you are copying from Unix to Windows, you need to do CRLF translation for all ASCII files. This can be done in a variety of ways, eg.:

• FTP in ASCII mode
• use the unix2dos utility
  

  find . -type f -exec unix2dos {} \;
  

A. MIMIC uses two different areas to maintain its data.

The first is the shared install area i.e. the directory where the installation is done. This is fresh for each version installed. The only MIMIC component that will change this area after installation is the Update Wizard to install optional components.

The second is the private data area. where the additional simulations and MIBs are stored on a per user basis. You can find the private area by using File->Open, and then hitting the Browse button to bring up the dialog where it is listed above the buttons. So to start fresh, use File->Terminate, rename the private area directory and restart MIMIC.

	Is there a recommended method to save off some of the simulations
	in some kind of source control? Like which files/etc?

A. As the previous topic explains, the MIMIC shared area does not need to be backed up, because all changes are normally saved in the private data area for each MIMIC user. This is normally in a subdirectory called mimic in the user's home directory. If your backup schedule backs up user home directories, your MIMIC data is already backed up. Otherwise, we recommend to just tar/gzip or Winzip the entire private data area of each MIMIC user.

As for source-code control, all data files in MIMIC are ASCII files, thus can easily be source-code controlled (you cannot easily diff binary files). The level of source-code control depends on the amount of changes to the data. For example, if your data rarely changes, you can use a backup schedule to maintain the changes. But, if you are developing and changing a lot of scripts, you want to source-code control those. If you are changing simulation data, the easiest process is to modify (and source-code control) the walkfiles used to generate the simulations (in effect, the walkfile becomes the source-code for the simulations).

A. This version of Linux uses newer libraries by default. If you run MIMIC on the default system, you'll encounter this error:

error while loading shared libraries:
libstdc++-libc6.2-2.so.3:  cannot open shared object file:  No such
file or directory

To fix this, you need to install several optional RPMs to fulfill the dependency on specific versions of the system libraries.

The solution is to select "Legacy Software Development" during install, or run the RPM package manager after installation and select the same option. The individual RPMs that are selected are:

• compat-glibc
• compat-libstdc++
• compat-gcc
• compat-libstdc++-devel
• compat-gcc-c++

A. Try running MIMICview first as is.

If you get the following error:

  ./mimicview: error in loading shared libraries
  libtclx.so: cannot open shared object file: No such file or directory

	1. copy it to /usr/lib
	2. ln -s libtcl8.0.4.so /usr/lib/libtclx.so

You could also get the following error once MIMICView is started:

./mimicd: error in loading shared libraries
libstdc++-libc6.1-1.so.2: cannot open shared object file: No such
file or directory

	1. ln -s libstdc++.so.2.9.0 libstdc++-libc6.1-1.so.2

> Which network ports need to be accessible on the MIMIC system, eg.
> through a firewall.

MIMICD:

tcp/9797
udp/9797

SNMP:

udp/161

trapper:

udp/162

WEBUI:

tcp/8080

OPENAPI:

tcp/8081
tcp/8444

SSH:

tcp/22

TELNET:

tcp/23

WEB:

tcp/80
tcp/443

IPMI:

udp/623
udp/662

VNC:

tcp/5903

A. MIMIC should allow you to do what you want. The snag is that HP/Openview requires an SNMP agent to run on the management station. This agent conflicts with agent instances running on MIMIC. You have 2 choices:

a) run MIMIC on one machine, HP/Openview on another. This would require 2 laptops to do your demos. We have found this to be a better solution than b), because HP/Openview and other management applications put a lot of burden on the machine (memory, CPU utilization).

b) run MIMIC and HP/Openview on same machine, but this only works if you use non-standard port numbers for the MIMIC SNMP agent instances. You will have to configure HP/Openview to probe these non-standard ports.

A. HPOV does not discover foreign networks automatically. I quote from the NNM Runtime manual, section "Maps" --> "Customizing you Network Map View" --> "Expanding Your IP Network Map" --> "Adding a Network":

 >For security purposes, Network Node Manager does not discover networks
 >in your internet, beyond your local gateways. You can add an object for
 >an network that NNM has not discovered to an Internet submap, by placing
 >a network symbol on that submap. If you are adding an object for an IP
 >network, NNM will eventually discover it. For network objects that NNM
 >cannot discover, the network symbol remains on the user plane.

A. MIMIC is a distributed client/server application, which means you can access the MIMIC Simulator daemon both locally (from same machine) and remotely (over the network) from multiple MIMIC clients (MIMICView, MIMICShell, etc). Each MIMIC client normally opens one session and upto 20 sessions are allowed. To use MIMIC remotely, all you have to do is this:

1) install MIMIC on the client system. Use empty license keys while installing.

2) invoke MIMICView from a command prompt with the --host option. Change to the bin/ folder of the MIMIC install area and type

mimicview --host THE-HOST-WHERE-MIMIC-DAEMON-IS-RUNNING

The assumption for the Client/Server function to work 100% is that the private data areas are accessible at the same file path on both client and server machines for the agents in the user's view (if access control is used). This is accomplished on Unix systems with NFS, and on Windows with shared drives. Eg. on Windows, mount a drive containing the private data area on both systems with the same drive name.

All MIMIC APIs (Tcl, Perl, Java, C++) can also work in remote mode by specifying the hostname where the MIMIC simulator daemon is running while opening a MIMIC session.

Even though the MIMIC clients are not licensed on a node-locked basis, the MIMIC Compiler and MIMIC Recorder are, and as such can only run on the machine that they are licensed for.

> Do you see any issues or know of things to watch out if
> we  want to
>   o Run Both MIMIC and Apache web server on a linux machine
>   o Run both MIMIC and IIS web server on an NT machine?

A. MIMIC does not care what other servers run on your system, as long as they are not making use of the same ports as MIMIC (eg. UDP SNMP port 161). Since standard web servers use TCP ports 80 or 8080, there is minimal likelihood of a clash.

A. Before MIMIC 14.00, you had to use a web server with virtual hosting functionality, such as Apache. For Apache, a different virtual web server can easily be setup for each of your simulated agents with the VirtualHost primitive. Each virtual web server can export a customized web site.

With MIMIC 14.00, we added the WEB Services Simulator that simulates complex web services.

A. If you want to apply new license keys to an already installed version of MIMIC (eg. if you want to change the evaluation keys to permanent keys, or upgrade in size), all you have to do is edit the license key files in config/*.lic . There is one file per licensed component (Simulator, Compiler, Recorder). Open each file with your favorite text editor, and copy/paste the corresponding key.

A. In general, there is no need to use environment variables with MIMIC. MIMIC is highly configurable in several ways (configuration files, command line options, etc), and environment variables are a convenient way to override default behavior for highly specialized circumstances. The references below contains details for the user-configurable environment variables:

• MIMIC_DISABLE_ACTION

• MIMIC_ADAPTIVE_VSPACE

• MIMIC_DEFAULT_NETDEV

• MIMIC_DISCARD_RESENDS

• MIMIC_REC_NO_GETNEXT

• MIMIC_REC_NO_TABLEWALK

• MIMIC_EDITOR

• MIMIC_PRIV_DIR

A. For a HOWTO on configuring MOM to receive SYSLOG messages see this article at the Microsoft support site.

For details on how to generate SYSLOG messages from MIMIC see the SYSLOG Protocol Module Guide in the MIMIC documentation.

A. Older versions of Fedora are downloadable from the Fedora download site

A. MIMIC Update Wizard needs access to the MIMIC update server(s) over the internet, either directly or through a proxy server.

MIMIC Update Wizard will work through a SOCKS proxy server with the help of the socat relay utility which is an optional installable on newer versions of Fedora Linux. You can get it running in 3 easy steps:

• First, install socat on a Linux system with

  # yum install socat
  

• Second, run socat to forward through your proxy server. Assuming that your proxy server is running on the machine proxy-server, invoke socat with something like

  socat TCP4-LISTEN:9799,fork SOCKS4:proxy-server:mirror2.gambitcommunications.com:80
  

• Third, set the proxy server and port in the Configuration Wizard to HOST-IPADDR port 9799, ie. HOST-IPADDR is the host IP address where the socat is running. If the socat is running on the same system as MIMIC, then use localhost

We have also verified Update Wizard to work through a SSH proxy like MobaXterm or PuTTY .

• First, install either proxy tool from the URL above on a Windows system.

• In the SSH tool, enable a SSH tunnel from local port 9799 to our update server mirror2.gambitcommunications.com port 80.

• Third, set the proxy server and port in the Configuration Wizard to HOST-IPADDR port 9799, ie. HOST-IPADDR is the host IP address where the SSH tool is running. If the SSH tool is running on the same system as MIMIC, then use localhost

After that, Update Wizard should work.

A. For MIMIC SNMP Simulator the process is detailed in the Process Overview section of the Guide, specially this section. It depends on what you have access to. This matrix tries to quickly present the different cases:

How to create a simulation if you have...

MIB Live device Walkfile Action Yes Yes Yes No Wizard -> MIB to compile MIBs if not already in MIMIC. Even if you have a walkfile, it's best to record the live device. Then File -> Record Live for single device or a small number; see also or Wizard -> Discovery for many devices; see also this FAQ entry and this one or Wizard -> Snapshot to capture changes over time Yes No Yes Wizard -> MIB to compile MIBs if not already in MIMIC. MIMIC handles many third-party walkfiles as detailed here. Then Simulation -> Record File for single walkfile or a small number; or Wizard -> Discovery for large number of walkfiles; or Wizard -> Simulation if you want to change the simulation Yes No No Wizard -> MIB to compile MIBs if not already in MIMIC. Then Wizard -> Simulation and input values for the MIB objects.

The MIMIC CLI Simulator already supports extensive Cisco IOS and Juniper JUNOS simulations. To create additional command-line simulations you need to record an existing CLI (command line interface) with Wizard -> CLI. The wizard can record from a live device, from a transcript, or interactively.

For MIMIC NetFlow Simulator you need to use Wizard -> NetFlow to record either from a packet capture (PCAP) or in live mode from a real exporter.

Web Service simulations for MIMIC WEB Simulator can be created with Wizard -> Web from either a PCAP or in live mode. They require the management application to access the real web server so that we can record the requests and responses.

For MIMIC MQTT Simulator you need to use mqttrec and mqttconv tools to record either from a packet capture (PCAP), or in live mode from a real sensor.

A. Even though our public device library spans hundreds of device models, we get this kind of request all the time. Here is a recent list:

>ECI
> BG20B
> BG20C
> BG30B
> BG40
> BG64B

The first place to check would be our published device library index at this page.

If not there, we might have it in our unpublished library or we can request it from our users, and you can send a request with what model you are looking for.

The problem with the model string is that this is an ambiguous, inefficient way to search for. Even if we grep for the string, there might be no matches, or multiple matches from different vendors.

The authoritative way to search for device models is by "sysObjectID". This OID is universally used, and unique enough to quickly yield good search results.

So, for the quickest results send us the sysObjectID of the devices you are looking for.

A. After MIMIC 4.00, use the MIMIC Discovery Wizard.

For versions earlier than MIMIC 4.00, the most efficient way of recording a large network is with shell scripts. Here is one that records a set of devices at known IP addresses (assuming you run it from the MIMIC shared area top directory):

bin/mimicrec --target [ADDR1] --simulation faq-[ADDR1] --scenario 1
bin/mimicrec --target [ADDR2] --simulation faq-[ADDR2] --scenario 1
...
bin/mimicrec --target [ADDRn] --simulation faq-[ADDRn] --scenario 1

Substitute [ADDR1], etc with the addresses of your devices. This script will work in most scripting languages such as Unix shells and Windows .BAT files. Notice that we are creating a simulation for each device with a name that contains its IP address (you can choose any unique prefix aside from "faq-"; do not use "sim-" since MIMICView uses this by default).

Once you have recorded your devices, you need to create an agent configuration that uses the simulations. Rather than doing this manually in the graphical user interface, you can write another script that does this. Here is an example using Unix text processing tools:

1) Extract your set of simulations from the device configuration file(s) in your private data area:
# MIMIC version 4.10 and earlier
% cd ~/mimic
% grep ^faq- config/dev.cfg > /tmp/devices.lst
or
# MIMIC version 4.20 and later
% cd ~/mimic
% cat data/sim/faq-*/dev.cfg > /tmp/dev.cfg
% grep ^triplets /tmp/dev.cfg | sed 's/triplets = //' > /tmp/devices.lst

You can further sort this file by IP address with the sort utility.

2) Create configuration files with text-processing tools:

% cat > /tmp/awk.prog
BEGIN {print "version = 2.1"}
{print "agent = {"}
{print "hostaddr = FOOBAR" $0 "FOOBAR" }
{print "portno = 161"}
{print "read_str = public"}
{print "write_str = netman"}
{print "delay = 0"}
{print "start_time = 0"}
{print "pdusize = 4500"}
{print "drop_rate = 0"}
{print "triplet = " $0 }
{print "}"}
^D

The ^D means to press CTL and D simultaneously (to generate the EOF character). On Windows, you need to use CTL-Z followed by Return, instead of CTL-D.

% awk -f /tmp/awk.prog /tmp/devices.lst > /tmp/almost.cfg

% cat /tmp/almost.cfg | sed 's/FOOBARfaq-//' | sed 's/,.*FOOBAR//' > \
/tmp/copy.cfg

The file /tmp/copy.cfg will contain the lab configuration necessary to run your simulations. Copy it into the config/ directory with your desired name.

On Windows, you can use the free GNU implementation of the Unix shell and text-processing tools downloadable from http://www.cygnus.com/misc/gnu-win32/ .

A. After MIMIC 4.00, use the MIMIC Discovery Wizard.

For versions earlier than MIMIC 4.00, you can run the following Bourne shell script to discover and record all devices in a subnet (scripts can be easily integrated with MIMIC command-line tools in any of the popular languages, including Perl, Tcl, shells, Windows .BAT files etc.). This script is supplied in common/discover.sh.

# discover.sh network-address
# this little script will discover and record all devices in a subnet
# (class C) that is specified in the first argument
# It needs to be customized to your site, eg.
# the path and syntax of a "SNMPGET" utility needs to be changed.

if [ a$1 = a ]
then
        echo "Usage: discover.sh network-address"
        echo "eg. discover.sh 192.9.200"
        exit 1
fi

net=$1

# loop from 1 to 254
host=0
while [ a = a ]
do
        host=`expr $host + 1`
        if [ $host -gt 254 ]
        then
                break
        fi

        addr=$net.$host
        echo "Querying $addr"

        # this determines if there is an agent at the address
        # any publicly available SNMP GET utility will do. I am using
        # the HP OpenView implementation at my site.
        # could do this with sysDescr and filter out certain device types
        response=`e:/apps/openview/bin/snmpget -p 161 -t 1 -r 0 $addr \
sysObjectID.0 2>NUL`

        if [ "$response" = "" ]
        then
                echo "$addr is down"
                continue
        fi

        echo "$addr is $response"

        # we could do a filter here to only look at certain devices
        # or exclude certain devices

        # now do what you want with discovered node
        ./mimicrec --target $addr --sim faq-$addr --scen 1
done

A. This means that the device did not respond to a query from the MIMIC Recorder. This could be due to congested network, or a busy device. You can use the --rexmits and --timeout options to cause the Recorder to wait longer for responses, although the default settings should already wait long enough.

Another cause could be a faulty agent implementation on the device. The MIMIC Recorder uses efficient, multi-variable per PDU queries (as do most good management applications) to minimize network traffic and to traverse dynamic tables. Some agent implementations do not work correctly with this type of query. You can use the --tablewalk command line option, or set the MIMIC_REC_NO_TABLEWALK environment variable before invoking mimicrec to disable the default behavior of the Recorder.

• In the Cshell do:
  % setenv MIMIC_REC_NO_TABLEWALK 1

• In the Bourne shell do:
  # MIMIC_REC_NO_TABLEWALK=1; export MIMIC_REC_NO_TABLEWALK

• On Windows, use the System Control Panel to set this environment variable.

You will know that this is set correctly if you do not see any messages containing "starting table walk".

A. This is caused by a faulty agent implementation on the device. The MIMIC Recorder ensures that the lexicographical order of retrieved variables is preserved according to the SNMP standard. Otherwise the retrieval could go on forever.

The MIMIC Recorder uses efficient, multi-variable per PDU queries (as do most good management applications) to minimize network traffic and to traverse dynamic tables. Some agent implementations do not work correctly with this type of query. You can use the --tablewalk command line option, or set the MIMIC_REC_NO_TABLEWALK environment variable before invoking mimicrec to disable the default behavior of the Recorder.

• In the C shell do:
  % setenv MIMIC_REC_NO_TABLEWALK 1

• In the Bourne shell do:
  # MIMIC_REC_NO_TABLEWALK=1; export MIMIC_REC_NO_TABLEWALK

• On Windows, use the System Control Panel to set this environment variable.

You will know that this is set correctly if you do not see any messages containing "starting table walk". If you still see the GETNEXT violation message, then you can use the MIMIC_REC_NO_GETNEXT environment variable to disable GETNEXT checking. This will only work if the agent (e.g., a Windows NT agent) incorrectly orders entries in a table, but otherwise proceeds with the walk.

If you are now hung in an infinite loop (if it takes forever and a tail of the walkfile shows repeating objects), kill the recording, and use the --start or --root options to bypass the faulty objects.

A. With MIMIC, you don't need the live device to be able to re-record it. When you record it the first time, the MIMIC Recorder creates a walkfile in the walkfile directory (before MIMIC version 8.10 this was by default /tmp, after that the walks/ subdirectory in your private data area). You can use the Recorder's --file command to instruct it to get its data from this walkfile, or you can use Simulation->Record File... in MIMICView.

> Would it be possible to edit the retrieved data to include
> our missing interface, etc info?

A. While recording a live device, the Recorder creates a walkfile in the walkfile directory. Before MIMIC 8.10 this was a file named walkfile-[IP-ADDRESS].wlk, stored on Unix in the /tmp directory, or on Windows in a folder DRIVE:\tmp\ (where DRIVE is the drive letter on which you installed MIMIC), where IP-ADDRESS is the IP-address of the device. In MIMIC 8.10 or later, the walkfiles are stored in the walks/ subdirectory in your private data area.

You can edit the walkfile, and rerecord from this file with Simulation->Record File... What I would do first, though, is to recompile the MIBs, then rerecord the live device. The MIMIC Recorder then should pick up the missing variables. The Simulation Wizard presents a user-friendly interface for doing this.

> Is there any way to change the name of the agent.  It now appears
> as unknown - first - first where first-first is the name of simulation
> and scenario.  How can I change the unknown?

A. As a convenience to the user, the Recorder names the agent by default with the contents of the sysDescr.0 object. Otherwise it calls it "Unknown...". You can add sysDescr.0 to your walkfile, and it will pick up that name in subsequent runs of the Recorder (recommended), or you can change the name of any simulated device with Simulation->Devices... dialog in MIMICView. The third option is to edit the config/dev.cfg file.

Note: the device name is only used to display a user-friendly string in MIMICView. It is not actually used for simulation. The simulation and scenario name of a device are used to drive the simulation.

> I performed Record Live from Simulation menu on a real switch. The
> process ended with 0 errors, but when I looked into list of simulated
> devices it shows that my simulation includes only 3 standard (I mean not
> enterprise) mibs. So I added the enterprise mibs from the list of mibs but
> now I had to init all the mib variables by myself, which is very long and
> arduous process. My question is: How to add the enterprise mibs at the
> beginning of the recording process, so that I should receive starting
> complete simulation of the real device as a result of recording process.

A. After compiling the enterprise MIBs, you can re-record from the walkfile generated by the Live Record. This should simulate the earlier missing MIBs.

Otherwise, it is likely that you did not traverse the enterprise MIBs when you recorded the switch. You can verify this by looking at the walkfile generated by the MIMIC Recorder.

The file is called walkfile-[switch-address].wlk and resides in the walkfile directory (see previous article above).

Look at the end of the walkfile, if there are OIDs starting with 1.3.6.1.4.1, that would be in the enterprise MIB (likely your enterprise MIB). If so, please e-mail us the walkfile for us to diagnose any further problems.

If not, you did not record the enterprise MIB. This can be due to a number of reasons, as we have encountered in the past with a variety of equipment from other manufacturers:

1) your enterprise MIB is accessible only with a different community string. You need to record your switch with the different community string.

2) your enterprise MIB is accessible only at a different port number. You need to record your switch with the different port number.

3) the agent on your switch has a problem traversing from the standard MIBs to the enterprise MIB. You need to start recording your switch with --start 1.3.6.1.4.1 or somesuch.

For all these cases, you will end up with 2 walkfiles, the first containing the standard MIBs, the second containing the enterprise MIB. You can combine the 2 walkfiles into one (append the enterprise walk to the standard walk). Then record the combined file with "Simulation->Record File". The Simulation Wizard presents a user-friendly interface for doing this.

> Why am I seeing error messages with "unknown objects" in the recorder log?

A. The MIMIC Recorder is used to create a simulation by taking a snapshot of a real device. By default, it accomplishes this with a "snmp walk": a complete traversal of the MIB. It relies on the MIB definitions to create a default basic simulation, one that is useful to most users.

One side effect of every live MIMIC Recorder session is a "walkfile" with the contents of that "snmp walk". The second phase is to create the simulation from that walkfile, where it uses the MIB definitions that are compiled into MIMIC to create a default simulation.

MIMIC does this by default because if you are interested in a MIB simulation, you will have the MIB definition, since your management app uses this MIB definition as a contract between it and the agent.

Of course, there are a miriad of options to override the defaults, and the best combination depends on your exact requirements. For example, if you don't have the MIB definitions, but still want to create a simulation, the recorder can record "unknown" MIBs. The accuracy is decreased, because guesses will only go so far, maybe 90%. But if they go wrong, they really go wrong. That is why that is not the default.

So, your recording generated a walkfile with a lot of unknown objects, and that is what the log is telling you. You can now choose to either import the MIB into MIMIC, then re-record from the walkfile to create the best simulation, or to create an approximation with the --unknown option to mimicrec.

	The manual states that if there are too many errors, you might
	have to obtain the MIB from the equipment vendor and compile it.
	In general, how many errors would be too many as a percentage?

A. Generally, less than 10% is ok, unless you are interested in the MIB objects in the missing 10%. The simulation only really needs to export the MIB objects that your management application retrieves. Even if you record the entire device, and you are only interested in MIB-II, then you can instruct MIMIC to only simulate MIB-II (eg. to conserve memory if you are running lots of agents).

 > 2.  When I do simulation, sometimes I also want to remove some
 > unnecessary simulation and scenario.  Besides modify the simulation file
 > in /mimic/data/sim, is there a GUI function allow me to remove these
 > unwanted simulations ?

A. For removing unwanted simulations use the Simulation->Devices... menu option. Select the simulations that you want to get rid of and press the Delete button. After you have completed cleanup press Save to commit these changes to the disk.

Once you have done the above you can delete the simulation directory from under data/sim to complete the cleanup.

> Can you tell me whether it's possible to use an external SNMP walk tool
> to get information from a device, and then import that data into MIMIC ?
>
> If so, what format would the data need to be in ?
>
> One of our clients has devices that respond to SNMP requests only from
> given IP addresses, and we would like to try and avoid having to get
> them to reconfigure the network just so we can run a MIMIC trace.

A. Yes, you can create a simulation from any walkfile format, but you need to convert it to MIMIC walkfile format first. This walkfile can then be fed to the MIMIC Recorder, eg. in MIMICView use Simulation->Record File.

There are problems with walkfile conversion, specially from formats with ambiguous and incomplete output. Eg. if the output is

someObject.0: 00:11:22:33:44:55

is that an OCTET STRING with hexadecimal or ASCII values? 99% of the time it is hexadecimal, so the conversion filters will blindly convert them to hex. But, for the 1% of the cases where it is indeed ASCII, the conversion will return incorrect values.

If you must resort to third-party tool to record walkfiles, we recommend the net-snmp toolset with the -One -Ih command line options.

After MIMIC 5.10, anytime you manipulate walkfiles in MIMICView, the MIMIC walkfile converter is automatically invoked.

Otherwise, MIMIC ships with conversion scripts for these common walkfile formats:

• HP/Openview
• NetMetrix
• UCD snmpwalk
• Concord Network Health

See the walkfile converters section in the Utilities Guide for more details.

A. There can be many reasons for this problem, but it is most likely caused by the existence of another SNMP agent running on this system. The solution is explained in detail in Appendix C, for Windows.

A. When you start agent instances with IP (IPv4) addresses on a subnet different from the one that your management station is on, you need to tell the management station how to get to the subnet.

This can be done in most operating systems via a static route with the route command. Assuming that your management station and MIMIC system are on the same LAN, your agent instances are on the 192.9.200.0 subnet and that the address of your management station machine is IPADDR, here are the route commands for some common operating systems:

• Windows 7/8/10

  From the DOS command prompt:
  C> route add 192.9.200.0 mask 255.255.255.0 IPADDR

• Solaris 2.6, 7

  From any shell as root:

  To add a route:
  # route add -net 192.9.200.0 IPADDR 0

  To delete a route:
  # route delete -net 192.9.200.0 IPADDR

• Solaris 2.5

  From any shell as root:
  # route add 192.9.200.0 IPADDR 0

• Red Hat Linux 5.x

  From any shell as root:
  # route add -net 192.9.200.0 gw IPADDR

• Ubuntu Linux 20 and later

  From any shell as root:

  To add a route:
  #ip route add 192.9.200.0/24 via IPADDR

• Red Hat Linux 6.x and later

  From any shell as root:

  To add a route:
  # route add -net 192.9.200.0 netmask 255.255.255.0 INTERFACE
  

  To delete a route:
  # route del -net 192.9.200.0 netmask 255.255.255.0
  

• HP/UX

  From any shell as root:
  # route add 192.9.200.0 IPADDR 0

If there is a gateway between the 2 LANs, then you change the above commands to supply IPADDR with the gateway IP address. You'll also need to configure routes on the gateway to route between the subnets, just as you would on any regular network.

If you have setup the routes, and you still cannot ping the agents, then a firewall could be the culprit. See also this section.

IPv6 addresses of agents can be reachable from remote IPv6 management systems on the same LAN by adding a default route, if it doesn't already exist, via the main network adapter of the management system as below:

• Windows

  netsh interface ipv6 add route ::/0 INTERFACE-NAME-OR-INDEX

  INTERFACE-NAME-OR-INDEX can be found using:
  netsh interface ipv6 show interface

  Example:

  C:\> netsh interface ipv6 show interface
  Querying active state...
  
  Idx  Met   MTU    State         Name
  ---  ----  -----  ------------  -----
     6     2   1280  Disconnected  Teredo Tunneling Pseudo-Interface
     5     0   1500  Connected     main-192.9.200.64
     4     0   1500  Connected     second-192.9.200.66
     3     1   1280  Connected     6to4 Tunneling Pseudo-Interface
     2     1   1280  Connected     Automatic Tunneling Pseudo-Interface
     1     0   1500  Connected     Loopback Pseudo-Interface
  
  C:\> netsh interface ipv6 add route ::/0 5
  Ok.
  

• Linux

  Check whether the default route exists:
  $ip -6 route show | grep ^default

  Add route if does not exist:
  route -A inet6 add ::/0 dev eth0

• Solaris:

  Check whether the default route exists:
  netstat -f inet6 -rn | grep ^default

  Add route as root:
  route -f inet6 add ::/0 IPv6-ADDRESS-OF-MAIN-ADAPTER 0

  Example:

  route -f inet6 add ::/0 fe80::209:3dff:fe00:c69e 0

A. Once you have determined reachability via ping, an agent can fail to respond (your application times out even after a number of retransmits) due to numerous reasons. You can determine each of them as follows:

• community string mismatch (you are sending the wrong community string or other authentication information): an error appears in the Error Log. See also this video .

• protocol mismatch (the agent does not support the SNMP version you are using): an error appears in the Error Log.

• port number mismatch: a protocol analyzer trace would show an ICMP response with "port unreachable".

• IP address conflict: this will ALWAYS result in indeterminate behavior. If you are re-using an IP address of another system which does not run an SNMP agent, the symptoms will be the same as "port number mismatch". If the other system does run an SNMP agent, it may respond instead of the MIMIC agent.

• incorrect routing entries on MIMIC system: if there are routing entries setup on the system that is running MIMIC, they can interfere with the proper behavior of MIMIC. This is easily determined by examining the routing table as returned with the netstat -r -n or route print command.

• firewalls: a firewall (eg. BlackICE) may limit interactions with MIMIC, specially it it determines that a "denial of service" attack on SNMP agents is occurring. The first thing to determine is whether firewall software is running on the MIMIC PC. If so, the only solution is to re-configure or even disable the firewall software. Problems with external firewalls are tough to diagnose, but a protocol analyzer running on the MIMIC PC and on the NMS station should determine where packets are being dropped.

• retransmits: MIMIC discards retransmits for efficiency reasons (servicing unnecessary retransmits uses up CPU bandwidth). To disable this behavior, set the environment variable MIMIC_DISCARD_RESENDS to 0 as follows:
  • In the C shell do:
    % setenv MIMIC_DISCARD_RESENDS 0

  • In the Bourne shell do:
    # MIMIC_DISCARD_RESENDS=0; export MIMIC_DISCARD_RESENDS

  • On Windows, use the System Control Panel to set this environment variable.

In any of the cases, the first action would be to consult the Error Log and the agent statistics with the Agent->Statistics dialog. Use of a protocol analyzer such as tcpdump, wireshark or etherfind can reveal further causes of the problem.

A. By default, MIMIC runs the most useful basic simulation clause for a wide variety of applications: a close snapshot of a device SNMP agent, with static objects taking on the values that were observed, and Counter objects taking on a rate that was interpolated from observed values, both entirely configurable at run-time. For details, see the QuickStart tutorial.

This default basic simulation is more expensive than faster, simpler simulations. The simplest simulation is to just return a constant value for all object instances. If the management application does not care about values retrieved, then you can use this simulation.

The sample simulation clauses that were compared in a performance experiment were (for more details, see the SIMULATE clause section in the Compiler Guide):

• INDEX
• SIMULATE{ 1 }
• SIMULATE{ constant(1) }
• SIMULATE{ uniform(1) }
• SIMULATE{ constant_per_tu(1, 60) }
• SIMULATE{ uniform_per_tu(1, 60) }
• SIMULATE{ constant(lookup("r")) }
• SIMULATE{ uniform(lookup("r")) }
• SIMULATE{ constant_per_tu(lookup("r"), lookup("tu")) }
• SIMULATE{ uniform_per_tu(lookup("r"), lookup("tu")) }
• SIMULATE{ uniform_per_tu ( (lookup ("r") == 0 ? 1 : lookup ("r")), lookup ("tu")) }

Here is a chart comparing the performance of different simulation clauses for objects. When requests are performed with only one variable per PDU, the difference in performance between the fastest and default simulations is approximately 50%. But, the more variables that are packed into a PDU, the larger the computation part becomes (compared to network overhead, etc), and for 100 variables per PDU, the difference between the fastest and default simulations is a factor of more than 5.

You can easily create the fastest simulation with the --fast command line option to the MIMIC Recorder.

A. MIMIC does extensive error logging to justify its actions. If something is not going the way you want it, you can find out why from the error log. The error log is normally displayed in a log window, as well as dumped into a file mimiclog.date.time in your temporary directory (/tmp in Unix, \TMP in Windows).

The most common error messages are described in Appendix C of the online documentation.

A. The MIMICView GUI application automatically changes the log every night at midnight, if so configured (for details see Configuration Wizard). You can also change the log manually with the File->Log->Save menu item.

If you are not running MIMICView, or want to have more control over the log size, then you can truncate it with the timer+truncatelog.mtcl timer script. See the Run->Timer Scripts menu item in MIMICView for more details.

This script runs periodically (by default every minute), and changes the active log when it exceeds a maximum size (by default 10 MB).

Old inactive log files can automatically be removed from the system with periodic batch files (eg. through crontab).

A. The rate-based simulation of counter objects in MIMIC is governed by 2 variables: rate ("r") and time-unit ("tu"). Both together determine the actual rate of the counter, eg. r=10, tu=60 would increment a counter at a rate of 10 per minute.

When you configure a counter object rate, make sure you set the desired time-unit ("tu") variable for that object.

> Using MIMIC, I want to test how my management station handles 64-bit
> counter wrap.  I want to be able to send SNMP queries to the agent and have
> the agent return the data that follows
>
> Query          ifHCInOctets Value
> --------       ---------------------------
> 1         18446744073707551614
> 2         18446744073708551614
> 3         100
>
> This sequence would enable me to test the handling of huge 64-bit values
> AND handling of the 64-bit counter wrap.  How can I get MIMIC to behave
> this way?

A. After MIMIC version 12.00, you can use the Agent->Change Simulation dialog. Else, follow these instructions.

You have a couple of choices, depending on your exact requirements. All of the choices have the basic rate-based simulation of Counter* objects as a starting point, and here is probably the quickest way to achieve what you want:

1) this assumes an agent instance with IF-MIB configured. Start the agent, set the rate of ifHCInOctets to something large, eg. 1,000,000,000 (1 billion) / sec. You can do this with the Agent->Value Space... dialog by adding a variable r with value 1000000000 for the instance you are interested in.

2) your object is now advancing at a rate of 1 billion per second, so you should be getting values larger than 2^32 after 4 seconds of running.

3) if you need larger values, you can pause the agent at a later time, eg. use Agent->Pause, set to 5 days, then use Agent->Resume.

Here are the values returned when I tried it:

% snmpget 192.9.201.133 public .1.3.6.1.2.1.1.3.0 .1.3.6.1.2.1.31.1.1.1.6.1
system.sysUpTime.0 = Timeticks: (43202330) 5 days, 0:00:23.30
ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifHCInOctets.1 = Counter64: 431983340054944

% snmpget 192.9.201.133 public .1.3.6.1.2.1.1.3.0 .1.3.6.1.2.1.31.1.1.1.6.1
system.sysUpTime.0 = Timeticks: (43202698) 5 days, 0:00:26.98
ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifHCInOctets.1 = Counter64: 431987020076191

4) using only this method, it's going to be hard to make it wrap on demand, ie. you would have to calculate the time to set for the agent, then pause it at exactly the right time.

One alternative to force the wrap would be to advance the time on the agent (Agent->Pause), but this only works if your management app is not looking at sysUpTime.

So, we are going to use action scripts to force the value down to 100 after 2 accesses. Use the Agent -> Actions -> On GET/SET... dialog, type ifHCInOctets into the Object text field, press the Browse... button for the Get Scripts field, click New..., call the action script ifHCInOctets.mtcl. Select the script in the list, press Edit..., and paste this into the editor window:

# this action returns a special value after 2 GET* accesses to this object
# instance
set count [mimic value get ifHCInOctets $gCurrentInstance count]
if { $count > 1 } {
        puts stderr "ifHCInOctets: special case"
        set gCurrentValue 100
}

incr count
mimic value set ifHCInOctets $gCurrentInstance count $count

Press Save, then Exit in the editor, press OK in the File Browser window, press OK in the Action dialog, and you have set the action script for the ifHCInOctets object.

Now when you access the object, you will get 2 large values, then the small value thereafter until you restart the agent.

% snmpget 192.9.201.133 public .1.3.6.1.2.1.1.3.0 .1.3.6.1.2.1.31.1.1.1.6.1
system.sysUpTime.0 = Timeticks: (43204776) 5 days, 0:00:47.76
ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifHCInOctets.1 = Counter64: 432007800089978

% snmpget 192.9.201.133 public .1.3.6.1.2.1.1.3.0 .1.3.6.1.2.1.31.1.1.1.6.1
system.sysUpTime.0 = Timeticks: (43204919) 5 days, 0:00:49.19
ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifHCInOctets.1 = Counter64: 432009230047969

% snmpget 192.9.201.133 public .1.3.6.1.2.1.1.3.0 .1.3.6.1.2.1.31.1.1.1.6.1
system.sysUpTime.0 = Timeticks: (43205110) 5 days, 0:00:51.10
ifMIB.ifMIBObjects.ifXTable.ifXEntry.ifHCInOctets.1 = Counter64: 100

Another alternative for exactly predictable values is to use a GET Action Script for the desired object that returns hard-coded values in the script itself or retrieved from the Agent Store.

A. After MIMIC version 12.00, you can use the Agent->Change Simulation dialog. Else, follow these instructions.

In SNMP, the definition of a Counter object implies a non-monotonically increasing value, and the default simulation in MIMIC implements this. But, as a side effect of resetting state on a device (eg. an interface), some counters may have to be reset. This sequence of MIMICShell commands will reset a counter object instance (eg. for instance 1 of ifInOctets) to 0, and apply a new rate of increase NEWRATE:

    mimicsh> mimic value set ifInOctets 1 r 0
    mimicsh> mimic value set ifInOctets 1 _t0v0  [mimic value eval sysUpTime 0],0
    mimicsh> mimic value set ifInOctets 1 r $NEWRATE

A. The details for this error message are described in Appendix C of the online documentation.

    mimicsh>mimic value set saSysNvCfgCntrl 0 v 2
    0
    mimicsh>mimic value get saSysNvCfgCntrl 0 v
    2

    whereas it fails, as expected when tried through snmpget/set

    snmpget 152.148.26.56 saSysNvCfgCntrlEntry.1.0
    snmpget: Agent reported error with variable #1.

A. Through the MIMIC interface, you can do whatever you want. Remember, all you are doing is setting variables in the "value space". Whether those variables are used or not is another matter, and is governed by the simulation expression. Hypothetically, we could have a simulation expression which uses variables of illegal instances.

The SNMP semantics are enforced in the SNMP PDU processing code, and in the simulation expression engine.

BTW, having 0-valued subids in table instances is allowed, eg. in MAC or IP address instances, you can have a 0, eg. 192.9.0.50 . RFC1212 says that the index cannot be 0 for INTEGER-valued subids. For error-testing, MIMIC allows you to have 0-valued indices, ie. in the example above the snmpget would succeed if you did

mimicsh> mimic value add saSys...Entry 0

	Generating a trap from a simulated Cisco router arrives to 
	Netview.  But from a simulated IBM-2210 it does not arrive
	there. Is there a tool or a Unix command I can use to see
	what is wrong. The destination address for the trap is correct
	(same as the Cisco one) and I can ping the Netview from
	the Sun station too. What should I do to investigate this
	problem ?

A. You can look at the statistics for that agent instance, in MIMICView with Agent->Statistics . If "Trap PDUs" shows a positive number, then the traps are sent out. If not, you may have to define any variables that are to be sent with the trap in the "Advanced" tab in the "Generate Traps" dialog.

	1. About dynamic rows. Let me clarify my question. I want
	to add entries in the tables thru snmp-set's from the manager
	and not by running scripts. Taking ur eg :  I would like to
	add ifTable.101 when an snmp-set for this table is sent from
	the manager.

A. Yes. MIMIC does correctly simulate row creation. Below is a sample exchange with a MIMIC simulated agent. Notice that the ifTable only has 2 entries (1 and 2). Then we do a SET on row 5. Then row 5 is created. You need to make sure that you use the correct write-community string.

% snmpwalk 192.9.201.150 hp_admin interfaces.ifTable.ifEntry.ifType
interfaces.ifTable.ifEntry.ifType.1 = ethernet-csmacd(6)
interfaces.ifTable.ifEntry.ifType.2 = 28

% snmpwalk 192.9.201.150 hp_admin interfaces.ifTable.ifEntry.ifAdminStatus
interfaces.ifTable.ifEntry.ifAdminStatus.1 = up(1)
interfaces.ifTable.ifEntry.ifAdminStatus.2 = up(1)

% snmpset 192.9.201.150 netman interfaces.ifTable.ifEntry.ifAdminStatus.5 i 2
interfaces.ifTable.ifEntry.ifAdminStatus.5 = down(2)
interfaces.ifTable.ifEntry.ifAdminStatus.5 = down(2)

% snmpwalk 192.9.201.150 hp_admin interfaces.ifTable.ifEntry.ifType
interfaces.ifTable.ifEntry.ifType.1 = ethernet-csmacd(6)
interfaces.ifTable.ifEntry.ifType.2 = 28
interfaces.ifTable.ifEntry.ifType.5 = 0

% snmpwalk 192.9.201.150 hp_admin interfaces.ifTable.ifEntry.ifAdminStatus
interfaces.ifTable.ifEntry.ifAdminStatus.1 = up(1)
interfaces.ifTable.ifEntry.ifAdminStatus.2 = up(1)
interfaces.ifTable.ifEntry.ifAdminStatus.5 = down(2)

> I checked it for creation and deletion of rows with the RowStatus oid
> without any success.
> What I did was compiling a mib that has a mibtable and then I tried
> setting the RowStatus oid of that table to 4 (createAndGo) and
> then to 6 (destroy).
> What I found out is that every initial value including 6 creates a new
> row full with default values,
> and the value 6 (destroy) doesn't destroy the row.

A. You can simulate a RowStatus object (as defined in RFC 2579) with a SET action script. For a discussion on action scripts see the QuickStart Tutorial.

As of MIMIC 12.00, you can use the Agent->Change Simulation... dialog to deploy this simulation for RowStatus objects.

To set this up manually, copy the scripts/rowStatus.mtcl to your simulation directory and associate to the RowStatus object in your table as a SET action with the Agent -> Actions -> On GET/SET... dialog. Now when you send the SNMP SET request with RowStatus values it will trigger the action script and will create or destroy the row as per the value specified. Other custom side-effects will have to be programmed into the action script.

You can use the supplied scripts/setup-rowStatus.mtcl script to assign the default rowStatus action script to all RowStatus typed objects for an agent. This script will start the agent, run through its MIB tree looking for RowStatus objects, and assign to each the default action script. Furthermore, this script assigns the fast C++-based action scripts, rather than the slower Tcl-based scripts.

> We are trying to simulate a Core Builder 9000 from 3com but we have
> some difficulty.
> Indeed the CB9000 is a chassis which have several communication cards.
> Only the chassis have an IP address.
> The chassis have a community name : public, but all the other card
> have different SNMP name like public@slot-1.1 for the first card,
> public@slot-2.2 for the second card...
> How can we simulate this agent ?

A. This is called "community-string-indexing", and is supported by MIMIC 3.30 and later. You need to create an agent instance for each community string. They all have the same IP address and port, but different community string.

Then you need to setup the correct simulation for each agent instance. For example, you can record an existing CB9000 at the different community strings (eg. public, public@slot-1.1) and assign the generated simulations to different agent instances.

At MIMIC v7.10 we have introduced the same concept for SNMPv3 with "engine-id indexing". Multiple agents with the same IP address but different engine-id can be configured. Thus, you can simulate the same IP address with different user and context names, and return different information. In the following example the system description is different for different context names to the same IP address:

% snmpget -v 3 -e 800000020109840302 -u user11 -n context11 10.0.0.1 sysDescr.0
SNMPv2-MIB::sysDescr.0 = STRING: Cisco Internetwork Operating System Software ..
IOS (tm) 3000 Software (IGS-D-L), Version 11.0(14a), RELEASE SOFTWARE (fc1)...

% snmpget -v 3 -e 800000020109840301 -u user11 -n context21 10.0.0.1 sysDescr.0
SNMPv2-MIB::sysDescr.0 = STRING: HP ETHERNET MULTI-ENVIRONMENT,ROM A.03.00,
JETDIRECT,JD24,EEPROM A.03.06

A. Source-address indexing is an extension of MIMIC's multi-user capabilities. Not only does MIMIC allow multiple users to create their own simulations, but it also allows these users to have their own virtual networks, even with overlapping IP addresses.

Suppose one user needs IP address 192.168.100.1 for simulating a Cisco device, but so does another user to simulate a Juniper. Traditionally, the only way to resolve this issue has been to each run their own simulator, adding to cost. In MIMIC, you can configure 2 different agents, with all the same addressing parameters (IP address, port, community string), but with an additional discriminator of source-address, ie. the address of the management station of each of the users.

This diagram illustrates the capability:

+---------------------------------------------+
|  MIMIC Server      Source       IP          |
|                    Address      Aliases     |           +------------+
|  +---------------+                          |           | management |
|  | agent M       |           +--------------+         / | station 1  |
|  | Cisco         | <------+  |  ...         |  SNMP  /  | IPADDR1    |
|  | 192.168.100.1 | IPADDR1 \ +--------------+ <-----+   +------------+
|  +---------------+          \| 192.168.100.1|
|                             /+--------------+ <-----+   +------------+
|  +---------------+         / |  ...         |  SNMP  \  | management |
|  | agent N       | IPADDR2/  +--------------+         \ | station 2  |
|  | Juniper       | <-----+                  |           | IPADDR2    |
|  | 192.168.100.1 |                          |           +------------+
|  +---------------+                          |
+---------------------------------------------+

> Is it possible to quickly create many interfaces on a host?

A. As of MIMIC 12.00, you can use the Agent->Change Simulation... dialog to invoke the Populate table advanced simulation for the ifEntry object.

Otherwise, you can use MIMICShell scripting to populate the desired table. For example

for {set i 1} {$i <= 100} {incr i} {
	mimic value add ifEntry $i
	# set the values for the interface, eg. set to Ethernet type
	mimic value set ifType $i v 6
}

	When I set the multicast, broadcast ethernet counters, this
	won't affect the traffic, right?

	Yesterday our site got a broadcast storm. I hope it wasn't
	because of the broadcast counters I set on a mimic device.

A. MIMIC manipulates MIB data only. It does not generate any traffic other than trap PDUs only (that too only if the user has programmed it to do that). Setting the counter rates to any value on the simulation will not cause any of the side effects you mentioned.

> I want to generate the portLinkDownEvent9 trap for Xylan switch, as defined
> in the XYLANTRAP-9-MIB; but this mib is not associated (if that's the right
> word) with the agent I have running.
> My question, what do I have to do so that I can begin generating this trap.

TRAP objects are non-accessible, and thus cannot be recorded with MIMIC Recorder. If those objects are in a MIB together with accessible MIB objects that are recorded, they end up in the resulting simulation. But, if they are in a separate MIB, it is not added from a recording session of a real device. The MIB needs to be added manually to the simulation.

You can add a MIB to the simulation in the Simulation --> Devices dialog. Remember to click Ok or Apply to commit the changes. After 4.00, it also creates the simulation files. You need to reconfigure the agent instance with this new simulation, with Edit->Configure->All... . Restart the agent, and the trap MIB should be loaded, allowing you to send the desired trap.

	One thing I just noticed while reviewing the wftraps.asn file is that
	wfFakeEventString is defined as OBJECT-TYPE instead of TRAP-TYPE.  Could
	this be the reason we can't seem to generate this trap from within MIMIC?

A. The object that you pointed out is a DisplayString and hence cannot be used as a Trap object name in MIMIC. Only objects that are defined using the macro TRAP-TYPE can be used.

 > The question I have for the sysUpTime is that: for every notification
 > being generated, there is an unique sysUpTime attached to the
 > notification.  How do I get the sysUpTime for the specific notification
 > that I generate?  I tried agent=>get value, it keeps return default
 > value 0.

A. The sysUpTime object is simulated in real-time by default. It does not have a variable in the MIMIC value space, because it's simulation does not need one.

In order to send the value of sysUpTime in a trap you can do this in the MIMICshell:

 # this evaluates sysUpTime to the current value
 mimicsh> set cur_uptime [mimic value eval sysUpTime 0]

 # this tells MIMIC to generate a trap once with the sysUptime value
 # change the value of myTrap to your trap object
 mimicsh> set mytrap "coldStart"
 mimicsh> mimic value set $mytrap 0 r 1
 mimicsh> mimic value set $mytrap 0 tu 1
 mimicsh> mimic value set $mytrap 0 sysUpTime $cur_uptime
 mimicsh> mimic value set $mytrap 0 c 1

After MIMIC 4.10, you can have an action script associated with a trap, which will by executed every time the trap is generated. The dynamic assignment of the sysUpTime variable binding can be accomplished there. See the QuickStart Tutorial for more details.

> I am wondering how mimic determines which version to use when sending a
> trap. I noticed that there is no way to specify the version (v1, v2c, etc)
> when in the Generate Traps dialog. I know you can set the versions support
> by a simulated agent when you Add or Configure an agent. Is it determined by
> the trap definition in the mib?

A. This depends on the trap definition primarily. If the trap is defined using the SMI-V1 TRAP-TYPE definition, then a v1 trap will be generated. If the trap is defined as a NOTIFICATION-TYPE object, and if the agent is configured to support v3 only, then a v3 notification is generated. If it is configured as v2p but not v2c, then a v2p notification is generated, otherwise a v2c trap is generated.

	Is there any way of setting up more than one agent to send
	traps at any one time, i.e. something similar to selecting
	10 agents and Agent -->Generate Traps, then putting the 10
	agent ID's in and each one will generate the trap.?

A. Here is a MIMICShell script that does what you would like :

	# Sample MIMICShell script
	# This assumes that agents 1-10 are configured and running
	# Generate linkUp traps from 10 agents 10/sec for 100 secs)

	for { set i 1 } { $i <= 10 } { incr i } {
	        mimic agent assign $i                   ;# select agent
	        mimic value set linkUp 0 ifIndex 1      ;# var-bind ifIndex=1
	        mimic value set linkUp 0 r 10           ;# rate
	        mimic value set linkUp 0 tu 1           ;# timeunit (sec)
	        mimic value set linkUp 0 c 100          ;# duration (sec)
	}

This should do what you want. You might have to customize for different traps/agents etc but the methodology should be clear.

A. If you would like to generate this trap from MIMICView then select the Agent->Generate Traps menu item, select the desired trap object in the MIB browser, and click the IP Aliases tab where you will find a list of all IP aliases including the main agent IP address. Select the IP alias for which you would like to generate trap and press OK. This will generate the trap for the selected IP alias.

If you would like to automate the process, then you can use a MIMICshell script such as:

# this procedure generates a trap on all aliases of specified agents
# numbered start to end (inclusive)
# this uses synchronous trap generation since we cannot have more than one
# outstanding asynchronous trap of the same name per agent
proc syncr_trap_all_ipaliases {start end trapname} {
	for {set agent $start} {$agent <= $end} {incr agent} {
		mimic agent assign $agent
		mimic value set $trapname 0 r 1
		mimic value set $trapname 0 tu 1

		# generate a trap for each of the IP aliases (the 0-th IP
		# alias being the main address of the agent)
		set max [llength [mimic agent ipalias list]]
		for {set i 0} {$i<=$max} {incr i} {
			mimic value set $trapname 0 ip $i
			# synchronous trap
			mimic value set $trapname 0 c "s"

			# wait until the trap is actually sent
			while { 1 } {
				if { [mimic value get $trapname 0 c] == "0" } {
					break
				}
				after 100
			}
		}
	}
}


# for example generate the coldStart trap for the first agent
syncr_trap_all_ipaliases 1 1 coldStart
exit

> Many agents in the field source every trap from a
> different UDP port, which means these traps are treated differently by
> firewalls evaluating whether every trap is part of the same session or
> whether every trap opens a new session. The firewall considers whether
> all 4 fields match in the sourceIP:port -> destinationIP:port
> connection. We would like to use MIMIC to simulate both types of agent:
> those that source all traps from the same UDP port and those that source
> each trap from a different UDP port.

A. You can use the IP Alias feature detailed in the previous section to send traps from different source ports for your agent. For each desired port, add an alias, then send desired traps for that alias.

A. Generating an immediate single trap upon processing a SET PDU is simple in MIMIC: you create an action script which contains the mimic value commands necessary to generate the single trap.

The next complication is to delay the trap: you achieve this by scheduling a timer script in your SET action script, which when executed in the future will issue the same mimic value commands.

But what if you want to generate a sequence of traps, possibly at varying time intervals?

The solution is to combine the output of the Trap Wizard with the mechanisms explained above. The output of the Trap Wizard is a sequence of trap generation scripts, which schedule the generation of different traps successively at the intervals they were observed when they were captured by the wizard. This sequence is by default started for the configured simulation when the agent is started up. Applying this to a SET action script involves these modifications:

1. turn off the automatic generation of the traps at agent startup in the Edit->Configure->All... dialog.

2. associate a SET action script with the desired MIB object. This script will merely schedule the initial trap generation script, usually with the statement:

   catch { mimic agent timer script add sequence.1/begin.mtcl 0 } msg
   

   This will invoke the first sequence of traps that were captured.

3. any sub-sequence of traps can be invoked separately by changing which trap generation script is scheduled in the SET action script.

> Do you happen to know how SUN Solaris assigns IP addresses across the
> network interface cards that it has available?  That is, in our case we have
> one quad NIC and one single NIC.  Will Solaris assign IP Address #1 to NIC
> #1, IP Address #2 to NIC #2, etc., or will it assign the first 8000 IP
> addresses to NIC #1 and then move on the the second card?
>
> If Solaris handles the IP address assignment in the second way, is there any
> way we can configure it to assign addresses across all NICs available?

A. By default, MIMIC does not interleave IP addresses among network interface cards on any of the OS platforms. The assignment of IP addresses to NICs has to be done explicitly (otherwise the address is configured on the default network device, usually the first available NIC), either in the Interface field of the Advanced tab of the agent configuration dialog in MIMICView, or with the mimic agent set interface command in MIMICShell.

You can do this by first configuring all agents with the default interface, eg. in MIMICView with the Edit->Add->Agent... menu item, and leave the Interface field blank. Then run a MIMICShell script that interleaves each agent on the desired NIC. After that, save the configuration ( File->Save As menu item in MIMICView, or mimic saveas in MIMICShell) to make this persistent.

Here is a script fragment which does strict interleaving of agents on all configured network interfaces:

        set ifs [mimic get interfaces]
        set curif 0
        for {set i 1} {$i <= [mimic get last] } {incr i} {
                mimic agent assign $i
                # this assumes that all agents are configured, otherwise
                # check for state == 5
                mimic agent set interface [lindex $ifs $curif]
                incr curif
                if { $curif >= [llength $ifs] } {
                        set curif 0
                }
        }

A. If your Linux MIMIC system has multiple active network interfaces connected to the same LAN, and you are experiencing drops in PDU throughput while polling MIMIC agents, it may be due to one network interface running slower than the other. Linux will route traffic through the NIC according to the arp tables regardless of the interface an agent IP address is assigned to. The command ethtool run as root can be used to discover the current speed and duplex settings of each NIC.

# ethtool eth0
Settings for eth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
        Advertised auto-negotiation: Yes
        Speed: 100Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: umbg
        Wake-on: g
        Current message level: 0x00000001 (1)
        Link detected: yes

Any protocol analyzer can be used to capture packets between the walkhost and the agent to determine the MAC address of the NIC handling the traffic.

A. MIMIC version 16.20 and later adds SHA-2 Authentication as specified in RFC 7860.

MIMIC version 9.20 and later adds AES-192 and AES-256 Privacy.

MIMIC version 7.30 and later adds AES Privacy as specified in RFC 3826.

MIMIC version 7.20 and later adds user management support.

MIMIC version 7.10 and later adds engine-id indexing.

MIMIC version 5.00 and later adds INFORM PDUs, and SNMPv3 in Recorder (see Release Notes).

MIMIC version 4.40 and later adds AUGMENTed tables, and ContextName based indexing.

MIMIC version 4.20 and later adds DES Privacy.

MIMIC version 4.10 and later adds SHA Authentication.

MIMIC version 4.00 and later supports full SNMPv3 with USM, VACM and MD5 Authentication.

MIMIC 3.30 onwards supports a partial SNMPv3 implementation. This includes the noAuthNoPriv, AuthNoPriv implementation where the authentication is done using the MD5 protocol. USM is supported with the user database allowed to be configured as required. All the relevant report PDUs are supported. VACM, SHA and DES support will be added in later releases.

For example, all of the following net-snmp commands using different combinations of authentication and privacy protocols will work against an SNMPv3 agent with default MIMIC SNMPv3 configuration files at address 10.0.201.1:

% snmpget -v3 -uuser1 -lnoAuthNoPriv 10.0.201.1 sysDescr.0
% snmpget -v3 -uuser2 -lauthNoPriv -aMD5 -A1234567890abcdef 10.0.201.1 sysDescr.0
% snmpget -v3 -uuser3 -lauthNoPriv -aSHA -A1234567890abcdef 10.0.201.1 sysDescr.0
% snmpget -v3 -uuser4 -lauthPriv -aMD5 -A1234567890abcdef -xDES \
-X 1234567890abcdef 10.0.201.1 sysDescr.0
% snmpget -v3 -uuser5 -lauthPriv -aSHA -A1234567890abcdef -xDES \
-X 1234567890abcdef 10.0.201.1 sysDescr.0
% snmpget -v3 -uuser6 -lauthPriv -aMD5 -A1234567890abcdef -xAES \
-X 1234567890abcdef 10.0.201.1 sysDescr.0
% snmpget -v3 -uuser7 -lauthPriv -aSHA -A1234567890abcdef -xAES \
-X 1234567890abcdef 10.0.201.1 sysDescr.0
% snmpget -v3 -ncontext11 -uuser11 -lnoAuthNoPriv 10.0.201.1 sysDescr.0
% snmpget -v3 -ncontext12 -uuser12 -lauthNoPriv -aMD5 -A1234567890abcdef \
10.0.201.1 sysDescr.0
% snmpget -v3 -ncontext13 -uuser13 -lauthNoPriv -aSHA -A1234567890abcdef \
10.0.201.1  sysDescr.0
% snmpget -v3 -ncontext14 -uuser14 -lauthPriv -aMD5 -A1234567890abcdef -xDES \
-X 1234567890abcdef 10.0.201.1 sysDescr.0
% snmpget -v3 -ncontext15 -uuser15 -lauthPriv -aSHA -A1234567890abcdef -xDES \
-X 1234567890abcdef 10.0.201.1 sysDescr.0

Using Extended Security requires extra configuration in MIMIC. You need to uncomment the appropriate users from the v3usm.conf configuration file. NET-SNMP prior to version 5.8 did not support these privacy options, but with NET-SNMP 5.8 we interoperate with all supported authentication/privacy combinations, and we have tested interoperability of AES-192 and AES-256 privacy with at least these packages:

• SNMP++
• SNMP4J
• SnmpSoft
• PySNMP

SHA-2 interoperability has been tested with at least these

• NET-SNMP
• SNMP Research

This is a recommendation from SNMP Research:

"When using AES-256 with authentication protocols with key lengths less
than 256 bits (such as md5 and sha1), there needs to be a standard
mechanism to produce the localized keys. Since SNMPv3 does not currently
provide such a standard, there needs to be an agreed upon way to do key
localization. The most common approach is the one used by Cisco which
is based on a variation of the Reeder 3DES draft. This is not an issue
when using SHA-2 with 256 or more bits for authentication; therefore,
it is recommended to use SHA-2 for authentication when using AES-256
for encryption because no key extension is needed.
"

so we support the Reeder key extension by default.

For example, with NET-SNMP 5.8 these work:

% snmpgetnext -v 3 -l authPriv -u user21 -a md5 -A 1234567890abcdef -x AES-192-C -X 1234567890abcdef \
-m "" -One 10.48.0.1 .1.3
% snmpgetnext -v 3 -l authPriv -u user22 -a sha -A 1234567890abcdef -x AES-192-C -X 1234567890abcdef \
-m "" -One 10.48.0.1 .1.3
% snmpgetnext -v 3 -l authPriv -u user23 -a md5 -A 1234567890abcdef -x AES-256-C -X 1234567890abcdef \
-m "" -One 10.48.0.1 .1.3
% snmpgetnext -v 3 -l authPriv -u user24 -a sha -A 1234567890abcdef -x AES-256-C -X 1234567890abcdef \
-m "" -One 10.48.0.1 .1.3
% snmpgetnext -v 3 -l authPriv -u user31 -a SHA-224 -A 1234567890abcdef -x AES -X 1234567890abcdef \
-m "" -One 10.48.0.1 .1.3
% snmpgetnext -v 3 -l authPriv -u user32 -a SHA-256 -A 1234567890abcdef -x AES -X 1234567890abcdef \
-m "" -One 10.48.0.1 .1.3
% snmpgetnext -v 3 -l authPriv -u user33 -a SHA-384 -A 1234567890abcdef -x AES -X 1234567890abcdef \
-m "" -One 10.48.0.1 .1.3
% snmpgetnext -v 3 -l authPriv -u user34 -a SHA-512 -A 1234567890abcdef -x AES -X 1234567890abcdef \
-m "" -One 10.48.0.1 .1.3
% snmpgetnext -v 3 -l authPriv -u user35 -a SHA-224 -A 1234567890abcdef -x AES-192 -X 1234567890abcdef \
-m "" -One 10.48.0.1 .1.3
% snmpgetnext -v 3 -l authPriv -u user36 -a SHA-224 -A 1234567890abcdef -x AES-256-C -X 1234567890abcdef \
-m "" -One 10.48.0.1 .1.3
% snmpgetnext -v 3 -l authPriv -u user37 -a SHA-256 -A 1234567890abcdef -x AES-192 -X 1234567890abcdef \
-m "" -One 10.48.0.1 .1.3
% snmpgetnext -v 3 -l authPriv -u user38 -a SHA-256 -A 1234567890abcdef -x AES-256 -X 1234567890abcdef \
-m "" -One 10.48.0.1 .1.3
% snmpgetnext -v 3 -l authPriv -u user39 -a SHA-384 -A 1234567890abcdef -x AES-192 -X 1234567890abcdef \
-m "" -One 10.48.0.1 .1.3
% snmpgetnext -v 3 -l authPriv -u user40 -a SHA-384 -A 1234567890abcdef -x AES-256 -X 1234567890abcdef \
-m "" -One 10.48.0.1 .1.3
% snmpgetnext -v 3 -l authPriv -u user41 -a SHA-512 -A 1234567890abcdef -x AES-192 -X 1234567890abcdef \
-m "" -One 10.48.0.1 .1.3
% snmpgetnext -v 3 -l authPriv -u user42 -a SHA-512 -A 1234567890abcdef -x AES-256 -X 1234567890abcdef \
-m "" -One 10.48.0.1 .1.3

A. Prior to version 8.31, starting SNMPv3 agents took a lot longer than SNMPv1 and/or SNMPv2c agents, because SNMPv3 authentication and security info needed to be loaded for each SNMPv3 agent. After 8.31, for most cases, starting SNMPv3 agents takes approximately the same amount of time as agents without SNMPv3. This is because the authentication info is the same for all agents in most cases, and in those cases we use a cache.

The following information is only relevant if you cannot upgrade MIMIC to version 8.31 or later.

In a simple experiment, on a representative Linux system, starting 1000 SNMPv3 agents took 30 times longer than non-SNMPv3 agents (450 seconds vs. 13 seconds), whereas on Windows it took 10 times longer (180 seconds vs. 18 seconds).

Thus, if you do not need SNMPv3 simulation, and start many agents, it is better to disable the SNMPv3 protocol for all relevant agents.

> But is there a way for mimicsh to exit automatically after having
> executed the script ?

A. You need to explicitly end your script with "exit".

> Do you know how to find out if an agent exists or not? I'm trying to build a
> loop that manipulates each agent without failing if the agent numbering is
> not contiguous from 1.

A. Unconfigured agents have state 5 (see Simulator Guide). So, to manipulate all configured agents, you can use a for-loop like

	for {set i 1} {$i <= [mimic get last]} {incr i} {
		mimic agent assign $i
		set state [mimic agent get state]

		# ignore unconfigured agents
		if { $state == 5 } {
			continue
		}
		# do something interesting with configured agents...
	}

An equivalent, more efficient way of achieving this loop is

	set list_of_agents [mimic get configured_list]
	foreach i $list_of_agents {
		mimic agent assign $i
		# do something interesting with configured agents...
	}

> I was trying to run a script by right clicking on the agent icon and
> selecting Script... and I get this error:
>
>     Error connecting to MIMIC server
>     localhost on port 9797 as limit
>     of total connections exceeded.
>
> The scripts (which are basically just puts statements) work fine when I use
> the Action... method and a remote MIB browser to invoke them.
>
> Is this due to the fact that I am not logged in with Administrator access on
> my WinNT machine or could it be something else?
> (I know in the manual it said that you need to have Administrator
> privileges, but since everything seemed to install and work fine without it,
> I never bothered!)
>
> How does this method of running scripts differ from using the Action...
> method?

A. The reason for the error you are seeing is that there is a limit of 5 client connections to the MIMIC daemon at a time (after version 5.00 the limit is 20 connections).

The reason that one method works and the other does not is due to the fact that Action method is run within the mimicd process and so does not count as a new client connection, whereas the Script method essentially forks of a mimicsh which has to make a connection with the MIMIC daemon to run and so counts as one more client connection.

A. You can use "puts stderr" to print debugging info to the Log Window.

> I have a small problem to obtain a value increase at each polling of the
> value.

A. To maintain state between 2 invocations of the action script, you need to keep another global variable which you increment. Also, you need to return the value from the script. For example, this fragment returns increasing values until 90, after which it starts from 0 again:

global myglobal
if { ![info exists myglobal] } {
        set myglobal 0
}

if {$myglobal > 90} then {
        set myglobal 0
} else {
        incr myglobal 10
}

return $myglobal

The global Tcl variable (defined above with the global statement) is accessible only by the same Tcl interpreter. All PDU action scripts for the same agent will run in the same Tcl interpreter, but other action scripts (startup, timer, etc) will run in different interpreters. Thus if you want to share variables the safest method is to use the MIMIC Variable Store. This will let you share global variables across action scripts, agents, even across different MIMIC daemons and API languages.

>Is there a way to assign action scripts via another script?  I have some
>action scripts written, but I will want to apply them to a large number of
>agents.  Assigning action scripts in the GUI for a large number of agents
>is very tedious.  

A. Anything that can be done in the GUI can be done in the script. You can assign action scripts using the mimic value set command. The following command sequence sets the action script foo-get.mtcl for the GET action and foo-set.mtcl for the SET action on the object ifStatus.

This assumes that the files foo-get.mtcl and foo-set.mtcl exist in the simulation directory for the agent.

    mimic value set ifStatus 0 g foo-get.mtcl
    mimic value set ifStatus 0 s foo-set.mtcl

NOTE: The instance used is always 0 for assigning the action scripts even for tables.

> If I want do I/O in this "GET action" script what should I do?
> 
> e.g.
> #this is GET action script,
> puts "please input 0:right return 1: error return  "
> gets stdin line
> set gError $line
> return

A. Direct user interaction is not possible, since an action script is invoked in response to a SNMP request, and if it were to wait for user input then this would cause timeouts and retransmits from the manager. Also, the agent would be blocked and would not be able to process any other request.

The way to allow user-controllable decision points in action scripts is to use a variable in the Value Space, which you control from the MIMICShell or MIMICView. Eg. if you wanted a decision point for the sysDescr object, use a variable, eg. "decision", so your action script could contain:

        set decision [mimic value get sysDescr 0 decision]
        switch $decision {
        choice1 {
                # do first choice
                break
        } 
        # other choices...
        }

You can then cause the action to behave differently by interactively doing (or the equivalent in the Value Browser of MIMICView)

mimic value set sysDescr 0 decision some-value

>I have a question about timer scripts.  It mentions in the documentation
>how to set up timer scripts, and further mentions that they are "global"
>timer scripts.  Is there any way to start up a timer script for each
>agent?

A. Timer scripts are designed to be executed globally. However from a given script you can address any particular agent by using the 'mimic agent assign' command to select that agent. Typically you can write a loop that runs through the list of agents, selecting them one after the other and doing whatever stuff is required.

# Example script

set num_agents [mimic get last]
for { set i 1 } { $i <= $num_agents } { incr i } {

    # select an agent
    mimic agent assign $i

    # Do stuff here

}

Another approach would be to schedule an agent timer script for each of the agents with mimic agent timer add. Each script invocation will select a different agent right at the start. The problem with this approach is that performance will be affected by the large number of timer scripts.

In general, you should use global timer scripts if you need to iterate over a large number of agents (less "context switching", ie. less overhead of switching between different timer scripts). Use agent timer scripts only to iterate over a small number of agents or as a side effect from action scripts.

> It looks like MIMIC doesn't start the agents in any specific order,

A. By default, MIMIC does an efficient "asynchronous" start of agents, eg. if you do:

       foreach agent $list_of_agents {
               mimic agent assign $agent
               mimic agent start
       }

       mimic start

If you require the starting of agents to proceed in a particular order, you can script it through a "synchronous loop", by waiting for each agent to actually be in a "running" state, before continuing to the next agent. For example, this loop

       foreach agent $list_of_agents {
               mimic agent assign $agent
               mimic agent start
               # wait for the agent to be running
               while { 1 } {
                       if { [mimic agent get state] == "1" } {
                               break
                       }
                       after 1000
               }
       }

A. The MIMICView Get Value and Set Value dialogs (as well as the MIMICShell mimic value get and mimic value set commands) do not use SNMP to interact with the agent. They use a proprietary command protocol to accomplish their function.

Since the statistics only increment on SNMP activity, you will not see any change. Also, PDU actions are only executed upon receiving SNMP requests.

> The message I got, when I tried to get the value with a "v" , which I know
> you said wouldn't work, is
>
> ERROR 01/28.14:04:26 - management operation failed
>       01/28.14:04:26 - command: value get
>       01/28.14:04:26 - 10 36 ospfNbrAddressLessIndex 1 32.81.243.85.0 v
>       01/28.14:04:26 - value space lookup failed
>       01/28.14:04:26 - no such index

A. The simulation for INDEX objects does not look at the value space, since their value is implicit in the index part of the OID. Thus it is normal that you cannot find anything for this MIB object with Value Get.

Instead of a "mimic value get" you can use "mimic value eval", such as

mimicsh> mimic value eval ospfNbrAddressLessIndex 32.81.243.85.0
32.81.243.85.0

> We are trying to set hrSystemDate to the correct value. How do we do this?

A. The object you are trying to set (hrSystemDate from HOST-RESOURCE-MIB) is defined as type DateAndTime with size 8 OR 11, as follows

     DateAndTime ::= OCTET STRING (SIZE (8 | 11))
     --        A date-time specification for the local time of day.
     --        This data type is intended to provide a consistent
     --        method of reporting date information.
     --
     --            field  octets  contents                  range
     --            _____  ______  ________                  _____
     --              1      1-2   year                      0..65536
     --                           (in network byte order)
     --              2       3    month                     1..12
     --              3       4    day                       1..31
     --              4       5    hour                      0..23
     --              5       6    minutes                   0..59
     --              6       7    seconds                   0..60
     --                           (use 60 for leap-second)
     --              7       8    deci-seconds              0..9
     --              8       9    direction from UTC        "+" / "-"
     --                           (in ascii notation)
     --              9      10    hours from UTC            0..11
     --             10      11    minutes from UTC          0..59
     --
     --            Note that if only local time is known, then
     --            timezone information (fields 8-10) is not present.

To set its value in MIMIC, you will need to set it as a hexadecimal value, eg. to convert 2003-12-22 18:25:40:05

Year 2003 = 07 d3
Month 12 = 0c
Day 22 = 16
Hour 18 = 12
Min. 25 = 19
Sec. 40 = 28
Deci-sec. 05 = 05

In MIMICshell you would do

mimicsh> mimic value set hrSystemDate 0 v "\\x07 d3 0c 16 12 19 28 05"

This is the canonical representation of a binary octet string, but MIMIC is flexible to accept other formats. Eg. these are all equivalent:

\xaa bb cc
\xAA BB CC
\xAA      BB      CC
\xAABBCC
\xAA:BB:CC
\xAA-BB-CC

A. According to RFC 3417 "Transport Mappings for the Simple Network Management Protocol (SNMP)", section 8. 3):

   (3)   When encoding an object whose syntax is described using the
         BITS construct, the value is encoded as an OCTET STRING, in
         which all the named bits in (the definition of) the bitstring,
         commencing with the first bit and proceeding to the last bit,
         are placed in bits 8 (high order bit) to 1 (low order bit) of
         the first octet, followed by bits 8 to 1 of each subsequent
         octet in turn, followed by as many bits as are needed of the
         final subsequent octet, commencing with bit 8.  Remaining bits,
         if any, of the final octet are set to zero on generation and
         ignored on receipt.

For example, in RMON2-MIB there is a BITS type object called probeCapabilities with this definition

probeCapabilities OBJECT-TYPE
     SYNTAX BITS {
        etherStats(0),
        historyControl(1),
        etherHistory(2),
        alarm(3),
        hosts(4),
        hostTopN(5),
        matrix(6),
        filter(7),
        capture(8),
        event(9),
        tokenRingMLStats(10),
        tokenRingPStats(11),
        tokenRingMLHistory(12),
        tokenRingPHistory(13),
        ringStation(14),
        ringStationOrder(15),
        ringStationConfig(16),
        sourceRouting(17),
        protocolDirectory(18),
        protocolDistribution(19),
        addressMapping(20),
        nlHost(21),
        nlMatrix(22),
        alHost(23),
        alMatrix(24),
        usrHistory(25),
        probeConfig(26)
     }

To set the etherStats(0) bit from the MIMICView Value Space browser, you will set the value in hexadecimal format as \x8000 (from the MIMICShell set the value as \\x8000).

To set the historyControl(1) bit, you will set the value as \x4000 (\\x4000 from MIMICShell).

A. These scripts will let you set/clear bits in a BITSTRING object. Save the following in scripts/set-bit.tcl under your private MIMIC directory, and invoke as documented, then customize to your need:

# Copyright (c) 2001-2014 by Gambit Communications, Inc.
#
# script to calculate BIT string in hex by setting desired bits
# This is my sample run trying scenario of setting bits 3,7 and 11:
#
# $./mimicsh --nosession --script ~/mimic/scripts/set-bit.tcl
# org hexbit 00 00 00 00 00 00 00 00
# org bitstring 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
# set bits 3, 7, 11
# new hexbit  11 10 00 00 00 00 00 00
# new bitstring 00010001 00010000 00000000 00000000 00000000 00000000 00000000 00000000
# clear bits 3, 7, 11
# new hexbit  00 00 00 00 00 00 00 00
# new bitstring 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
#
#
#
#

proc bit {varName pos {bitval {}}} {
   upvar 1 $varName var
   if {![info exist var]} {set var 0}
   set element [expr {$pos/8}]
   while {$element >= [llength $var]} {lappend var 0}
   set bitpos [expr {1 << $pos%8}]
   set word [lindex $var $element]
   if {$bitval != ""} {
       if {$bitval} {
           set word [expr {$word | $bitpos}]
       } else {
           set word [expr {$word & ~$bitpos}]
       }
       lset var $element $word
   }
   expr {($word & $bitpos) != 0}
}

proc bits bitvec {
   set res {}
   set pos 0
   foreach word $bitvec {
       for {set i 0} {$i<8} {incr i} {
           if {$word & 1<<$i} {lappend res $pos}
           incr pos
       }
   }
   set res
}

proc hex2bin hex {
    set t [list 0 0000 1 0001 2 0010 3 0011 4 0100 \
            5 0101 6 0110 7 0111 8 1000 9 1001 \
            a 1010 b 1011 c 1100 d 1101 e 1110 f 1111 \
            A 1010 B 1011 C 1100 D 1101 E 1110 F 1111]
    regsub {^0[xX]} $hex {} hex
    return [string map -nocase $t $hex]
}

proc set_rbit {varName nth bit_val} {
        upvar 1 $varName var
        bit var [expr 7 - $nth % 8] $bit_val
}


# this procedure sets the "nth" bit in the BITSTRING "hex_val"
# to the bit value "bval"
proc set_bit {hex_val nth bval} {
        upvar 1 $hex_val hex
        set idx [expr $nth/8]
        set rem [expr $nth%8]
        set curr_byte [lindex $hex $idx]
        #puts "curr_byte $curr_byte"
        scan $curr_byte %x val
        set_rbit val $rem $bval
        set hex [lreplace $hex $idx $idx [format %02X $val]]
        #puts "int val $val"
        #puts "hex val [format %02X $val]"
}

# Example
# setting bit 3,7,11
set hexbit "00 00 00 00 00 00 00 00"
set org_hexbit $hexbit

puts "org hexbit $org_hexbit"
puts "org bitstring [hex2bin [join [split $org_hexbit]]]"

set_bit hexbit 3 1
set_bit hexbit 7 1
set_bit hexbit 11 1

puts "set bits 3, 7, 11"
puts "new hexbit  $hexbit"
puts "new bitstring [hex2bin [join [split $hexbit]]]"

# clear bit 3,7,11 to get back to original
puts "clear bits 3, 7, 11"
set_bit hexbit 3 0
set_bit hexbit 7 0
set_bit hexbit 11 0

puts "new hexbit  $hexbit"
puts "new bitstring [hex2bin [join [split $hexbit]]]"
puts ""
exit

> My script is filling up the vacmAccessTable (in the vacmMIBObjects)
> with values (that works fine). But when the script deletes the
> table rows, an error occurs.
> 
> Here is the error that is printed as output from the script:
> {Failed INDEX simulation for table}
>     while executing
> "mimic value instances 1.3.6.1.6.3.16.1.4.1.9"
>... 

A. In your script, adding a new instance to the vacmAccessTable is not working correctly i.e. in the "mimic value add" command, the length of the OCTET STRING is missing. If you look in the Log window, you will see errors of the type:

ERROR DATE - management operation failed
      DATE - command: value add
      DATE - 26 6 1.3.6.1.6.3.16.1.4.1 1 99.99.0.3.1 v
      DATE - table add entry failed
      DATE - cannot add entry 99.99.0.3.1
      DATE - index length (5) less than required (102)

According to the vacmAccessTable table definition it has four INDEX objects viz. vacmGroupName, vacmAccessContextPrefix, vacmAccessSecurityModel and vacmAccessSecurityLevel. The first object vacmGroupName is defined as SnmpAdminString(SIZE(1..32)), i.e. a variable length OCTET STRING. To instantiate an OCTET STRING object in the INDEX clause, the first octet should be preceded by the size of the string and then the actual octets.

This is explained in RFC2578 "Structure of Management Information Version2 SMIv2)":

(3) string-valued, variable-length strings (not preceded by the IMPLIED keyword): `n+1' sub-identifiers, where `n' is the length of the string (the first sub-identifier is `n' itself, following this, each octet of the string is encoded in a separate sub-identifier);

The following code snippet accomplishes this

#
# this proc converts an ASCII string to an OID.
# This is useful for OCTET STRING indices.
#
proc convert_ASCII_to_OID {str} {
	set i 0
	set tmp ""
	foreach c [split $str {}] {
		if {$i > 0} {
			append tmp .
		}
		append tmp [scan $c %c]
		incr i
	}
	return $tmp
}

# here is a sample usage
set controlGroup [convert_ASCII_to_OID "controlGroup"]
set strlen [llength [split $controlGroup .]]
mimic value add 1.3.6.1.6.3.16.1.4.1  $strlen.$controlGroup.0.3.1

> Is there a way to have Mimic skip over missing entries in a sparse table?
> By sparse table I mean that for some rows of a column in a table, there was
> no value supplied by the recorded device and so there is a blank value in
> the MIB walk file.

A. There is a difference between the case where an empty value is returned, or no value is returned at all. In the former, an empty value is a normal occurrence for OCTET STRING objects. The normal behavior for tables is that a row in the table exists or it does not exist, ie. either all columnar object instances are returned for a particular row index or none at all. There are some device agents which will have gaps in tables, ie. not all columnar objects for a row will be returned in a table traversal. This is highly irregular and frowned upon, since it unnecessarily complicates data retrieval for management applications, which is the reason why most standard MIBs explicitly prohibit table gaps. Nevertheless there are exceptions, and MIMIC can simulate this behavior by turning off the adaptive nature of the MIMIC Value Space.

By default, the MIMIC Value Space is forgiving about missing information for MIMIC simulations. Eg. if the simulation of an object requires the value of a variable in the Value Space, if that value is missing, the Value Space will return some default value, rather than failing the simulation. This event is logged with a warning in the error log. This causes MIMIC to function even when there is missing information. You can turn off the adaptive Value Space, by setting the environment variable MIMIC_ADAPTIVE_VSPACE to 0 prior to running MIMIC. Doing so will not return object instances for which there is missing information in the Value Space.

• In the C shell do:
  % setenv MIMIC_ADAPTIVE_VSPACE 0

• In the Bourne shell do:
  # MIMIC_ADAPTIVE_VSPACE=0; export MIMIC_ADAPTIVE_VSPACE

• On Windows, use the System Control Panel to set this environment variable.

The Simulator will show a confirmation in its initial startup messages in the log

adaptive vspace = 0

A. By default, the basic simulation of numeric objects in MIMIC returns "static" values, by using the value space lookup("v") MIMIC simulation language function. This function will return the same value for successive queries of a MIB object instance. You can change this value by changing the variable v in the MIMIC Value Space at any point in time.

One way of making this default simulation "random" would be to periodically change the MIMIC Value Space, either through the MIMIC scripting interface, action scripts or timer scripts.

A simpler way would be to use the random (low, high) MIMIC simulation language function. This function will return successively random values between a low and high limit. To apply this function to an object, use Simulation->Edit menu item to edit the simulation expression for the desired object and change it to

	SIMULATE { random ( lookup ("lo"), lookup ("hi")) }

As a short-cut, you can copy the random.sdb file from the template/ directory of your installation to the data/sim/YOUR-SIMULATION/MIB-OF-OBJECT/OBJECT.sdb file. For example, if your simulation is called mysim, and the object is ifOutQLen in the IF-MIB, you would copy template/random.sdb to data/sim/mysim/IF-MIB/ifOutQLen.sdb.

To control the random values for this object, create variables lo and hi in the Value Space and assign required values. Once you evaluate this object, or retrieve it's values via SNMP GET* requests, the values should be randomly returned in the specified range.

A. Given a Counter value which increases according to the linear function

        f(t) = t * r / tu

The graph of this function looks like this:

        ^
        |                       *
        |                     *
        |                   *
        |                 *
        |               *
        |             *  |
   f(t) |           *    | r
        |         *------+
        |       *    tu
        |     *
        |   *
        | *
        +----------------------------->
                    t

This constant linear function is simulated in MIMIC with the basic constant_per_tu simulation expression using the r and tu variables.

We can define a step function based on this linear function, so that every dt timeunits the value increases, like this:

        ^
        | 
        |                     ****
        |
        |                 ****
        |
        |             ****
   f(t) |              
        |         ****
        |
        |     ****
        | 
        | ****
        +-------------+--+------------->
                t      dt

This function is simulated in the MIMIC Simulation language with the simulation expression using the "r", "tu" and "dt" variables:

SIMULATE { ( lookup ("dt") == 0 ) ? 0 : constant_per_tu (lookup ("r"),
lookup ("tu")) - ( ( ( sysuptime() - ( ( sysuptime() / lookup ("dt") ) *
lookup ("dt") ) ) * lookup ("r") ) / ( 100 * ( ( lookup ("tu") == 0 ) ? 1 :
lookup ("tu") ) ) ) }

where "dt" is in TimeTicks (10 milliseconds). Eg. if you wanted the step to take every 5 seconds, dt would be 500. With this simulation expression, you can change any of the variables at any time with correct results.

As a short-cut, you can copy the step.sdb file from the template/ directory of your installation to the data/sim/YOUR-SIMULATION/MIB-OF-OBJECT/OBJECT.sdb file. For example, if your simulation is called mysim, and the object is ifInMulticastPkts in the IF-MIB, you would copy template/step.sdb to data/sim/mysim/IF-MIB/ifInMulticastPkts.sdb.

> In my MIB I have the following definition:
> 
> myAddressEntry  ::=  SEQUENCE {
>                  myIndex  Integer32,
>                  myAddress  SnmpUDPAddress
>                  }
> 
> and in my work scenario, my manager need set myAddress to "". But when I
> get this SET request, MIMIC warns me that
> 
> WARN  03/21.09:01:19 snmpv2c.cc:841 - agent 73 SNMP SET failed.
>       03/21.09:01:19 mimic.cc:1314 - object myAddress : illegal size.
> 
> I don't know how to set this object to empty.

A. By default MIMIC will do syntax validation check on a SET request for the set value. If it does not match according to the object definition (assuming SnmpUDPAddress is a fixed-size OCTET STRING), the MIMIC agent will return an error. You can disable this default behavior of validation using the command mimic agent set validate as detailed in the Simulator Guide, MIMICShell commands section. The validation policy is a bitmask in which with the following bits (from LSB) check for

• type
• length (size)
• range
• access

For example, if you would like to disable size and range validation, you would unset bits 1 and 2, i.e. hex FFF9, or decimal 65529 with

mimicsh> mimic agent set validate 65529

One use case we have seen is if you want to set OPAQUE objects with a value, by default this will fail, since OPAQUE values have no length. By disabling size validation as above you can workaround this feature.

If you would like to disable all syntax validation, use

mimicsh> mimic agent set validate 0

A. Accessing a MIB object by name through the MIMIC APIs or GUI is a convenience (it is easier to remember a name, than a sequence of numbers). But, this convenience has a price in terms of efficiency: whenever a name is used, that name has to be converted to an OID using some sort of search.

MIMIC has optimized this search to take advantage of localization of reference: when referring to names, one usually refers to localized names, eg. within a table. For this reason, when you use a name, MIMIC will search first among the siblings of the last referenced MIB object. Only if the name is not found then will the search be from the beginning of the MIB.

Even with this optimization, the linear searches involved are much less efficient than referring to a MIB object by OID. This access is extremely fast in MIMIC.

Thus, while accessing MIB objects by name is a handy convenience specially for beginners, if you want to write efficient MIMIC scripts, we recommend to use OIDs. Even for this you can use mnemonics, eg. in Tcl

	set sysName 1.3.6.1.2.1.1.5
	mimic value eval $sysName 0

A. The first performance improvement to implement is the access by OID instead of name, as detailed in the previous section.

The MIMIC API features "multiple-variable" get and set operations on the MIMIC value space, which get and set multiple variables in one operation. The Tcl mimic value mget (and analogous calls in the other supported languages) is the equivalent to mimic value get for multiple variables. The same applies for the mimic value mset operation. These calls are specially efficient if you need to get/set many variables in your simulation.

We ran a performance test to access a large number of variables (on the order of 100,000), first with mimic value get, then with mimic value mget with 1, then 10, and finally 100 variables per call. We repeated the experiment for mimic value mset.

This matrix compares the performance of the operations (in variables per second):

Linux (1)

Windows (2)

Command Tcl C++ Java (3) Perl Python mimic value get 17596 64641 51975 23196 21978 mimic value mget 1 13992 45228 37879 14116 16075 mimic value mget 10 65790 228310 120480 56950 49800 mimic value mget 100 117600 400000 123300 80000 64500 Command Tcl C++ Java (3) Perl Python mimic value set 18106 59916 43554 24820 23223 mimic value mset 1 13753 44287 38447 17715 19474 mimic value mset 10 56430 208330 125160 76750 67930 mimic value mset 100 94300 344800 111400 113800 91200

Command Tcl C++ Java (4) Perl (4) (5) Python (4) mimic value get 18345 54230 30479 15094 11106 mimic value mget 1 14461 43253 24618 10158 7854 mimic value mget 10 70180 188320 92760 26670 13140 mimic value mget 100 111500 266700 116400 34200 15400 Command Tcl C++ Java (4) Perl (4) (5) Python (4) mimic value set 16656 34602 22936 14447 13523 mimic value mset 1 13635 29360 18879 12121 12666 mimic value mset 10 35110 66670 49630 29360 29340 mimic value mset 100 50300 72700 52900 41800 41300

As can be seen, packing more variables per operation can result in orders of magnitude faster access to the MIMIC value space.

Notes:

1. Linux was tested on Fedora Core 19 running on a quad-core Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz

2. Windows was tested on Windows 8.1 on a quad-core Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz

3. Java has Unix domain transport support on Unix.

4. Java, Perl and Python have no local mode transport on Windows. See also above.

5. On Windows, the numbers are for ActivePerl. See also above.

A. Since MIMIC is multi-threaded, and since on older versions of Linux each thread shows up in process listings by the ps and top utilities, you will see multiple mimicd entries. This is normal behaviour on older versions of Linux. With newer versions of top, use the -H command line option to see CPU usage by thread.

In combination with the MIMIC thread information that the Diagnostic Wizard prints, you can examine MIMIC thread CPU usage.

A. You can use the nsupdate dynamic DNS client program to send dynamic DNS updates to your DNS server. The nsupdate program is provided with Solaris and Linux

Before you start, make sure your DNS server allows dynamic updates. For the ISC BIND server which is shipped on Solaris and Linux, you need to use the allow-update primitive in named.conf, eg. to allow all updates:

zone "yourzone.com" {
	// other configs here...
	allow-update {
		any;
	};
};

Test that nsupdate will work, eg. if a MIMIC agent with address 10.1.120.142 is running, from the shell do

% nsupdate -d
> local 10.1.120.142
> update add yoursystem.yourzone.com 86400 A 10.1.120.142
> send
Reply from SOA query:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id:  51587
;; flags: qr aa rd ra ; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;yoursystem.yourzone.com.	IN SOA

;; AUTHORITY SECTION:
yourzone.com.	         86400	IN SOA ns.yourzone.com. hostmaster.yourzone.com.
2002092502 28800 7200 3600000 86400


Found zone name: yourzone.com
The master is: ns.yourzone.com

Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  55048
;; flags: qr ra ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0

> Destroy DST lib
Detach from entropy

% dig yoursystem.yourzone.com

; <<>> DiG 9.1.3 <<>> yoursystem.yourzone.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26804
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;yoursystem.yourzone.com.		IN	A

;; ANSWER SECTION:
yoursystem.yourzone.com.	86400	IN	A	10.1.120.142

;; AUTHORITY SECTION:
yourzone.com.		86400	IN	NS	nameserver.yourzone.com.

;; ADDITIONAL SECTION:
nameserver.yourzone.com. 86400 IN	A	192.9.200.70

;; Query time: 41 msec
;; SERVER: 192.9.200.70#53(192.9.200.70)
;; WHEN: Thu May 22 12:59:06 2003
;; MSG SIZE  rcvd: 107

Then you can use nsupdate in an agent startup action script.

... We will be having a
power work done on our building this weekend. I want to setup our Linux
MIMIC machine to automatically startup upon power up. Currently we have to
start it manually with the mimicadmin id. What is the preferred method?
Would the following entry in /etc/inittab suffice?

mimicadmin:3::/mimic/7.11/bin/mimicd

A. Here are the answers for the different supported platforms:

On Linux

After MIMIC 21.00, use the install-service script that ships in the bin/ folder, to install MIMIC as a systemd service.

Else, we recommend to start mimicd from /etc/rc.local. Anything in this file is executed after all other sysinit. For example, add the following lines towards the end of /etc/rc.local:

# start mimicd
# this code fragment assumes that MIMIC is installed in /usr/local/mimic
MIMIC_DIR=/usr/local/mimic
export $MIMIC_DIR
mimicd_args=""
mimicd_log=/tmp/mimic.`date '+%y%m%d%H%M%S'`.log
prog="./mimicd"
echo "Starting $prog >& $mimicd_log &"
cd $MIMIC_DIR/bin
$prog >& $mimicd_log &

Please make sure to replace the MIMIC_DIR variable with your MIMIC installation area absolute path.

Instructions to start MimicD.exe as a user-defined Windows service

This section applies to Windows Server 2008 and later, and Windows 7 and later. It has been tested on those versions, and Windows Server 2012, Windows 8.1 as well as Windows 10 and 11.

1. Create a batch file in the MIMIC\bin folder with this content:

   @echo off
   
   REM MIMIC daemon startup script
   REM useful when running as a service
   
   REM ********CUSTOMIZATION BEGIN********
   REM ********PLEASE DO YOUR CUSTOMIZATIONS HERE*******
   
   REM set proper MIMIC installation directory path
   set MIMIC_DIR=C:\Apps\Mimic.1130
   
   REM set proper MIMIC user's private directory
   set MIMIC_PRIV_DIR=C:\mimic
   
   REM set proper MIMIC LOG path
   REM timestamp for the log
   set hh=%time:~0,2%
   if "%time:~0,1%"==" " set hh=0%hh:~1,1%
   set yymmddhhmmss=%date:~12,2%%date:~4,2%%date:~7,2%%hh%%time:~3,2%%time:~6,2%
   
   set MIMIC_LOG=C:\tmp\mimic.%yymmddhhmmss%.log
   REM ********CUSTOMIZATION END********
   
   cd %~dp0
   
   set MIMIC_ARGV=
   :loop0
   if %1!==! goto done0
   set MIMIC_ARGV=%MIMIC_ARGV% %1
   shift
   goto loop0
   :done0
   
   REM execute MIMIC daemon
   .\MimicD.exe %MIMIC_ARGV%
   

2. Run below command in COMMAND prompt to register MIMIC as a service:

   C:\>sc create MIMIC binPath="c:\Apps\Mimic.11.30\bin\MimicStart.bat -f agent.cfg -s"
   DisplayName="MIMIC Simulator" start=auto obj=YOURMACHINE\YOURACCOUNT password=YOURPASSWORD
   [SC] CreateService SUCCESS
   

   
   

   NOTE: you may have to change these in the command line above:

   • the path to the MimicStart.bat may be different in your installation.

   • there are optional MimicD.exe arguments to the batch file above, e.g., -f agent.cfg -s. If you don't want to pass any arguments then remove those extra options.

   • YOURMACHINE, YOURACCOUNT and YOURPASSWORD will be unique to your site

3. Optionally, run below command in COMMAND prompt to add a description to the MIMIC service:

   C:\>sc description MIMIC "Simulates IP networks"
   [SC] ChangeServiceConfig2 SUCCESS
   

4. Now if you reboot the system, MIMIC will start automatically. There will be MimicD.exe in the process list. Just invoke MIMICView to connect to it.

   You can also run the MIMIC service manually going into Services window. It will complain that the service start fails with
   

   Error 1053: The service did not respond to the start or control request in a timely fashion
   

   
   but MimicD.exe starts successfully and can be seen in the process list. To solve this problem you need to use INSTSRV and SRVANY as documented below (contact us for detailed instructions - mention bug 4604).

5. If you want to remove the service, run this command:

   C:\>sc delete MIMIC
   [SC] DeleteService SUCCESS
   

• The mimiclog will be appended to the file provided in MIMIC_LOG for every mimicd session.
• Please be aware that this procedure requires changes in Windows Registry and we are not responsible for any mis-configuration that might occur on your system after the changes.

>> Got a question that how to let MIMIC simulate an infinite loop when
>> walking snmp mib ?
>>
>> For example, I snmp recorded a cisco device, then I want to make an
>> infinite loop on one of its oid, in order that when my application to
>> snmpwalk this oid, MIMIC simulator will return data in an infinite loop.

A. We can interpret this problem in 2 different ways:

1. lexicographic ordering

   By default, MIMIC simulates correct lexicographic ordering as most real-world agents do.. In order to simulate incorrect lexicographic ordering of OIDs, you can use the mimic action jump command in a GET action script.

   For example, if you want incorrect ordering in the ifTable eg. by looping on the ifIndex column, you can assign this GET action script

   mimic action jump 1.3.6.1.2.1.2.2.1.1
   set gError -2
   return
   

   
   

   to the ifDescr object, and you will get a traversal such as:

   $snmpwalk -v1 -cpublic 10.11.1.1 ifEntry
   IF-MIB::ifIndex.1 = INTEGER: 1
   IF-MIB::ifIndex.2 = INTEGER: 2
   IF-MIB::ifIndex.3 = INTEGER: 3
   ...
   IF-MIB::ifIndex.35 = INTEGER: 35
   IF-MIB::ifIndex.36 = INTEGER: 36
   IF-MIB::ifIndex.1 = INTEGER: 1
   Error: OID not increasing: IF-MIB::ifIndex.36 >= IF-MIB::ifIndex.1
   

   
   

   Notice that the SNMP tool snmpwalk detects such OIDs out of lexicographic order and stops. Other buggy/faulty applications do not detect this and will loop indefinitely.

2. dynamic tables

   One problem with some applications is that they inefficiently traverse dynamic tables, ie. tables whose indices change all the time. This condition can be simulated by growing the simulated table in a timer script that is invoked frequently. For example, invoking this timer script every millisecond:

   catch {mimic value add ifEntry [clock clicks]}
   

   
   

   will make the ifTable grow rapidly (which it normally does not in the real world). You need to worry about memory usage by the simulator with growing tables, so you should also purge old entries, as happens with many dynamic tables in the real world, eg. RMON-MIB tables. This sample script does that:

   set instances [mimic value instances ifDescr]
   set first [lindex $instances 0]
   set next [expr [lindex $instances end] + 1]
   catch {mimic value add ifEntry $next}
   # assign desired values to object instances in the new row
   catch {mimic value remove ifEntry $first}
   

A. Many parameters of the graphical user interface are configurable through the Configuration Wizard or with the MimicView resource file in the bin/ directory. The file uses the format for the X Window System Resource Configuration.

For example, this line configures the font used to display the information for each of the agent instances:

*subnet_fr*Canvas.font: -adobe-courier-medium-r-normal--10-*-*-*-*-*-iso 8859-1

and these define the foreground and background colors of dialog fields:

*Dialog*Entry.background: yellow
*Dialog*Entry.foreground: red

If you want to change any predefined parameter, just edit the MimicView resource file and restart mimicview. We recommend preserving the old setting by commenting it out with a '!' at the beginning of the line.

If you need assistance with any of the parameters, contact Gambit Communications Technical Support (support@gambitcomm.com).

A. At MIMIC 7.20, the MIMICView GUI provides tooltip balloon popups when you mouse over buttons and dialog fields. You can disable these balloon popups with the Help tab in the Configuration Wizard. Uncheck the Tooltips Balloon checkbox and press Apply.

Check out this video on .

A. MIMIC is a client/server application, i.e., it consists of two complementary sets of programs. The server program mimicd needs to run before the client programs mimicview and mimicsh can do their work.

When you start mimicview, the GUI client, it starts the server program mimicd automatically, if it is not already running. If so, it also starts a logging window to dump the diagnostic output of the server program.

If mimicd is already running, mimicview just attaches to it. This could be the case if you stopped mimicview before and closed the log window before, without terminating the server program with File->Terminate.

You can look at the diagnostic output of the running mimicd by selecting File->View Log from mimicview.

A. As explained in the previous section, MIMIC is a client/server application. The server program mimicd needs to run before the client programs mimicview and mimicsh can do their work.

When you start mimicview, the GUI client, it starts the server program mimicd automatically, if it is not already running. If so, it also starts a logging window to dump the diagnostic output of the server program.

After starting the mimicd daemon, mimicview waits for a little while for the daemon to initialize. Occasionally the daemon takes too long, and mimicview times out with the error message:

Cannot connect to the
MIMIC daemon.
Please check the log window.
Retry connecting?

Inspect the log window, and if there are no errors, simply choose Yes. It will reconnect to the already-started daemon.

A. This is a known issue. On Windows, if you kill the MIMICShell using the 'x' the wish80 still hangs on ... but if you used 'File->Exit' or just type 'exit' on the command prompt then you won't find the wish80 in the process list.

You can just "End Process" any lingering wish80 processes from the Windows Task Manager.

A.

	I am looking at a MIB object in the Value Browser, and see
	their type information in the icon. Can I see more details
	somehow?

The MIMICView MIB Browser that is displayed in the dialogs invoked by the Agent->Value Space..., Agent->Evaluate..., and Agent->Browse MIB... menu items shows the type, access, and enumeration values for the selected MIB object. In addition, when you click the Details... button, it will display the context sensitive portion of the MIB source code for the selected MIB object. The requirement for the Details... button to be enabled, is that the MIB source be imported and compiled into MIMIC, eg. for the MIBs that ship with MIMIC, by downloading the "MIB sources" update package from Update Wizard, or for new MIBs with the MIB Wizard.

A.

	When I generate traps the mib which is listed shows only
	generic traps and no specific traps either for a Cisco router or a
	IBM one.

The SNMPv1 traps are listed in the Generate Traps dialog in a (initially hidden) tree starting at the root, named "traps". You can open it by clicking on the '+' in the top left corner, then clicking again. A 'traps' tree will show, from which you can browse the SNMPv1 traps.

At SNMPv2, NOTIFICATIONS have been correctly defined in the OID name-space, and will appear in the MIB Browser under their defined branch in the .iso.org tree. (Also see next entry in this FAQ.)

	Why are you using different syntax for trap-OIDs and variable-OIDs ?

	like:
	.traps._iso._org._dod._internet._mgmt._mib-2._snmp

	compared to:
	.iso.org.dod.internet.mgmt.mib-2.snmp

	That is not an SMI syntax standard, is it?

A. SNMPv1 traps do not fit into the OID hierarchy. Eg. there is no OID for the linkDown trap (it is sent with an Enterprise OID and a trap number). They fixed this for traps defined with the SNMPv2 NOTIFICATION construct.

In order to display SNMPv1 traps in the MIB Browser OID hierarchy, we artificially give an OID for the SNMPv1 traps that is the concatenation of 0., their Enterprise OID, and the trap number. We also decided to show SNMPv1 traps in their own OID tree and artificially labelled that tree with "traps".

All of this is only visible in the MIB Browser. Everything else behaves strictly to SNMPv1 and SNMPv2 standards, eg. the MIMIC daemon translates OIDs to correctly send SNMPv1 traps.

	Is there a way to assign icons to my devices?
	I have created 4 device types which MIMIC view assigns
	the icon of a terminal, and I would like to distinguish
	each type of device with an icon.

A. Icons bitmaps are picked up from the bitmaps/ directory in the MIMIC installation or private area. The bitmap is associated with an agent by matching the first word in the string describing the device (as seen in the icon legend). So if your device is described on the screen as "Foo device blah blah ..." then you need a file called "Foo" in the bitmaps/ directory.

We use the XBM format for defining the bitmaps. The size needs to be 40x40.

A. As for performance ... multiple scripts running in a loop will lead to sluggishness. The way to optimize this can be using a single script to do the job of 3 if possible. Also use as large an interval with the 'after' command as possible so that CPU is not hogged by a particular script.

A. The scripts run in a separate Tcl shell (shows up on Windows as wish80.exe in the task list). So just terminating MIMIC still does not stop the script execution. You can instead use the Task Manager on Windows to select the 'Console' task and terminate it to get rid of the script.

Another way of stopping a MIMICshell script is to select "File->Exit" from the "Tk Console" window menu bar.

A. You need to stop the agent and then click configure. The device button is disabled if the agent is already running.

A. This can be fixed by simply commenting out those 'adobe' related font in jre_install_path/lib/font.properties:

vi /home/shared/jre1.3.1_01/lib/font.properties

# Serif font definition
#
serif.0=-b&h-lucidabright-medium-r-normal--*-%d-*-*-p-*-iso8859-1
#serif.1=--symbol-medium-r-normal--*-%d-*-*-p-*-adobe-fontspecific

serif.italic.0=-b&h-lucidabright-medium-i-normal--*-%d-*-*-p-*-iso8859-1

#serif.italic.1=--symbol-medium-r-normal--*-%d-*-*-p-*-adobe-fontspecific

serif.bold.0=-b&h-lucidabright-demibold-r-normal--*-%d-*-*-p-*-iso8859-1

#serif.bold.1=--symbol-medium-r-normal--*-%d-*-*-p-*-adobe-fontspecific

serif.bolditalic.0=-b&h-lucidabright-demibold-i-normal--*-%d-*-*-p-*-iso8859-1

#serif.bolditalic.1=--symbol-medium-r-normal--*-%d-*-*-p-*-adobe-fontspecific

# SansSerif font definition
#
sansserif.0=-b&h-lucidasans-medium-r-normal-sans-*-%d-*-*-p-*-iso8859-1
#sansserif.1=--symbol-medium-r-normal--*-%d-*-*-p-*-adobe-fontspecific

sansserif.italic.0=-b&h-lucidasans-medium-i-normal-sans-*-%d-*-*-p-*-iso8859-1

#sansserif.italic.1=--symbol-medium-r-normal--*-%d-*-*-p-*-adobe-fontspecific

A. You have 2 alternatives to display a MIMICview running on Linux on a display monitor on a Windows system.

The MIMICview GUI running on Linux can display locally on a X Window System server (henceforth called X server) to display on a monitor connected to the system, or remotely to a X server running on another system.

For alternative 1, you would run the MIMICview GUI X client on Linux and display on a X server running on the Windows system. There are many X server implementations for Windows, but we prefer MobaXterm or Cygwin/X . Your DISPLAY environment variable on Linux would have to be set to the remote system X display, eg. in bash export DISPLAY=IPADDR:0.0 where IPADDR is the IP address of the remote system.

The second alternative is to access the Linux system with the Windows Remote Desktop Protocol, which requires installing an RDP server on the Linux system. We have tried it according to these instructions for xrdp and it works well.

A. When the Recorder creates a simulation, it only deals with the actual objects and tables it finds on the device. For any missing objects, an error message such as:

WARN 03/03.10:50:05 oiddb.cc:1119 - index simulation load failed ifStackEntry, continuing...
03/03.10:50:05 simdb_load.cc:305 - cannot find index file for ifStackEntry.
03/03.10:50:05 searchpath.cc:348 - data/sim/hp-lanprobe.random/IF-MIB/ifStackEntry.idb not in search path

will be generated, and no values will be returned by MIMIC.

If you have a walkfile, you can use the Simulation Wizard to add entries to a table.

If you don't have the walkfile, to add a table, the first thing to do is to change the simulation file (e.g., in MIMICView with Simulation->Edit) to add simulation expressions for the table objects.

For the ifStackEntry table, you would cut and paste the following objects from the MIB file rfc2863.mib (you can get the MIB source file name from Appendix B: Pre-compiled MIBs), and then reduce to the minimal format with simulation expressions:

   ifStackEntry  OBJECT-TYPE
   SIMULATE { table.static }

   ifStackHigherLayer  OBJECT-TYPE
   SIMULATE { table.index }

   ifStackLowerLayer  OBJECT-TYPE
   SIMULATE { table.index }

   ifStackStatus  OBJECT-TYPE
   SIMULATE { lookup ("v") }

Once you compile this simulation (eg. in MIMICView with Simulation->Compile), you are able to simulate this table.

The next step is to add entries to the table (eg. in MIMICView with Agent->Value Space...) and assign values to objects.

	> We have a problem with a linkDown trap. We have managed to successfully
	> send a standard linkDown trap (i.e. a generic value of 2) to our
	> management station. This trap is sent with the variable ifIndex.

	> However, our problem is that our management station is configured to
	> accept the linkDown trap with extra variables - namely ifName and
	> ifDescr. As a result, our management station returns an error stating
	> that variables are missing when it receives the standard linkDown trap.

	> We were wondering if it would be possible to send the linkDown trap with
	> extra variables? We tried to re-define the trap with extra variables but
	> MIMIC seemed to persist with only sending ifIndex. Is MIMIC "hard-coded"
	> to only send ifIndex for traps of generic value 2 (ie. linkDown trap)?
	> Is it possible to add an Enterprise ID (similar to a specific trap) with
	> linkDown.

	> Does MIMIC store information on the traps that an agent instance can
	> send? If so, where does it store this information?

A. The syntax information about traps comes from the MIB definition, in particular the TRAP-TYPE and NOTIFICATION-TYPE clauses. These clauses define the version of the trap to be sent (for details see above) and the variables to be sent with the trap.

If you wanted to temporarily send extra variable bindings with the trap, you could define them at trap generation time. In the MIMICView Generate Traps dialog use the Advanced tab to add extra variables. In MIMICShell, use mimic value set to control trap generation with the o variable in the Value Space.

If you want to change a trap definition permanently, you would edit the MIB source file, compile it into MIMIC, from then on the new trap syntax is used.

Eg. if you wanted to change the trap definition of linkDown, you would need to change the IF-MIB definition as follows:

1) Use MIB --> Import to import the mibs/rfc1573.mib file from the MIMIC distribution. Please save it as the same filename and enterprise (no name). This file is saved in your private area and will effectively override the MIB supplied with MIMIC.

2) Use MIB --> Edit to edit the file, or edit with your favorite editor.

3) Use MIB --> Compile to compile this new MIB file.

You cannot redefine this trap in a different MIB, because your device configuration specifies a list of MIBs, and the definition in the original IF-MIB will have precedence (since it likely comes earlier in the device configuration as shown in the Simulation --> Devices dialog). Only by redefining it in the same MIB will you override the original definition.

 > 1. When I import MIB files, it will create a MIB directory for me in
 > the MIB browser.  Question 1: How to remove unwanted MIB directories?
 > I tried to modify the /mimic/data/mimic.dir file.  Because I dont know
 > the format of the file, with the modified mimic.dir actually caused the
 > MIMIC can't be started.  Is there  a easy way to remove the unwanted MIB
 > directory through GUI?

A. If your MIMICView has a MIB->Manage MIBs... menu item, you can use it. Else use the following instructions:

MIMIC accesses the compiled MIBs using the file mimic.dir as the directory listing of the MIBs which are compiled into MIMIC. The general format of data/mibs/mimic.dir is as follows :

 <version>
 "<name-of-mib-1>
 "<data/mibs/<db-file-path>
 <number-of-top-oids>
 <top-oid-1>
 <top-oid-2>
 ...
 <top-oid-n>
 "<name-of-mib-2>
 "<data/mibs/<db-file-path>
 <number-of-top-oids>
 <top-oid-1>
 <top-oid-2>
 ...
 <top-oid-n>

To remove the entries you don't want you need to remove the block corresponding to those MIBs and also decrement the topmost number by the same amount. PLEASE backup mimic.dir before starting any changes.

Once you have done the above you can delete the .db files in the data/mibs directory to complete the cleanup.

The MIMIC compiler will alert the user to problems with SMI syntax in their MIB, rather than silently ignoring them. Wouldn't you rather fix your MIB to follow proper SMI syntax, rather than finding errors later, which are invariably more expensive to fix?

For a list of frequent problems in MIBs, see this white-paper at InterWorking Labs or this Muonics page.

A. After MIMIC 5.10, you can use Update Wizard to install the Extreme MIB update. Otherwise, you can download the MIBs from http://www.extremenetworks.com/support/documentation.asp Then use the MIB Wizard to import them into MIMIC.

A. The Foundry Networks MIBs are available as an update to MIMIC which you can install with the Update Wizard.

A. The Alteon MIBs are available as an update to MIMIC which you can install with the Update Wizard.

A. After MIMIC 5.10, you can use Update Wizard to install the Juniper MIB update. Otherwise, you can download the latest MIBs from http://www.juniper.net/techpubs/software/index_mibs.html Then use the MIB Wizard to import them into MIMIC.

The MIBs containing TRAP definitions (v1_traps*.txt) need minor modifications in order to compile with MIMIC:

• v1_traps_bgp.txt

  Add this to the IMPORTS clause (eg. before TRAP-TYPE line):

  -- GAMBIT: added imports for compile purposes
  bgpPeerLastError, bgpPeerState      FROM RFC1269-MIB
  
  

• v1_traps_chassis.txt

  Add this to the IMPORTS clause (eg. before TRAP-TYPE line):

  -- GAMBIT: added import for compile purposes
  jnxContentsContainerIndex,jnxContentsL1Index,
  jnxContentsL2Index,jnxContentsL3Index,jnxContentsDescr
            FROM JUNIPER-MIB
  
  

• v1_traps_mpls.txt

  Add this to the IMPORTS clause (eg. before TRAP-TYPE line):

  -- GAMBIT: added imports for compile purposes
  mplsLspName, mplsPathName FROM MPLS-MIB
  
  

• v1_traps_ospf.txt

  Add this to the IMPORTS clause (eg. before TRAP-TYPE line):

  -- GAMBIT: added imports for compile purposes
  ospfRouterId, ospfExtLsdbLimit,     
  ospfLsdbAreaId, ospfLsdbType,
  ospfLsdbLsid, ospfLsdbRouterId,    
  ospfIfIpAddress,ospfAddressLessIf,
  ospfIfState, ospfVirtIfAreaId,    
  ospfVirtIfNeighbor, ospfVirtIfState,
  ospfNbrIpAddr, ospfNbrAddressLessIndex,
  ospfNbrRtrId, ospfNbrState,
  ospfVirtNbrArea, ospfVirtNbrRtrId,
  ospfVirtNbrState, ospfConfigErrorType,
  ospfPacketType, ospfPacketSrc
  	FROM OSPF-MIB
  
  

A. After MIMIC 5.30, you can use Update Wizard to install the Avaya MIB update. Otherwise, you can search for the latest MIBs on Google. Then use the MIB Wizard to import them into MIMIC.

A. After MIMIC 5.30, you can use Update Wizard to install the Siemens MIB update. Otherwise, you can search for the latest MIBs on Google. Then use the MIB Wizard to import them into MIMIC.

A. After MIMIC 5.30, you can use Update Wizard to install the Brocade MIB update. Otherwise, you can search for the latest MIBs on Google. Then use the MIB Wizard to import them into MIMIC.

A. After MIMIC 5.30, you can use Update Wizard to install the Netopia MIB update. Otherwise, you can search for the latest MIBs on Google. Then use the MIB Wizard to import them into MIMIC. You'll have to do a minor fix to change "DdpAddress" to "DdpNodeAddress", as standardized in the AppleTalk MIB (RFC 1742).

A. You can download the 802.16f and 802.16i MIBs from IEEE directly. We cannot distribute them due to copyright restrictions.