http://linux-cisco.blogspot.com/
Cisco 7200 Simulator
From IPFlow Netflow Collector
Table of contents [showhide]
1 Introduction
2 Current status
3 Lab simulation / "Hypervisor" mode
4 Contributors are welcome ! :)
5 Download
6 How to use it ?
7 Questions & Answers
[edit]
Introduction
I started in August 2005 a project to emulate a Cisco 7200 on a traditionnal PC. Now, it also supports Cisco 3600 series (3620, 3640 and 3660), 3700 series (3725, 3745) and 2600 series (2610 to 2650XM, 2691).
The goals of this emulator are mainly:
* To be used as a training platform, with software used in real world. It would allow people to become more familiar with Cisco devices, Cisco being the world leader in networking technologies ;
* Test and experiment the numerous and powerful features of Cisco IOS ;
* Check quickly configurations to be deployed later on real routers.
Of course, this emulator cannot replace a real router: you should be able to get a performance of about 1 kpps (depending on your host machine), to be compared to the 100 kpps delivered by a NPE-100 (the oldest NPE model). So, it is simply a complementary tool to real labs for administrators of Cisco networks or people wanting to pass their CCNA/CCNP/CCIE exams.
[edit]
Current status
At this time, the emulator I have programmed is able to boot a large number of Cisco IOS releases available for the 7200, 3600, 3700 and 2600 platforms, including the latest 12.2S and 12.4T.
The following devices are emulated in the current release (0.2.7):
* MIPS64 and PowerPC CPU processors. The instruction sets are not completely emulated now (MIPS FPU support is lacking, TLB support is not finished and other minor things), but it is sufficient for IOS ;
* DRAM and Packet SRAM memory ;
* Non-Volatile Memory (NVRAM) ;
* Signetics SCN 2681 DUART (C7200 Console and AUX ports) ;
* National Semiconductors NS16552 DUART (C3600/C3700/C2600 Console and AUX ports) ;
* Dallas DS1620 Temperature Sensors and Voltage Sensors, allowing the C7200 Environmental Monitor to work properly ;
* NMC93C46 Serial EEPROM ;
* Bootflash of 8 Mb (Intel 28F016SA) ;
* Galileo GT64010/GT64120/GT96100 PCI controllers, DEC 21x50 PCI bridges and so ;
* PCMCIA ATA disk emulation (C7200 only at this time).
* ...
The following Cisco 7200 Port Adapters (PA) are currently supported:
* FastEthernet cards "C7200-IO-FE" and "PA-FE-TX" based on DEC21140 chip
* FastEthernet cards "C7200-IO-2FE" and "PA-2FE-TX" based on Intel i8254x chips
* GigabitEthernet cards "C7200-IO-GE-E" and "PA-GE" based on Intel i8254x chips
* Ethernet cards "PA-4E" and "PA-8E" based on AMD Am79c97x chips
* ATM card "PA-A1" based on Texas Instruments Tneta1570 chip
* Serial cards "PA-4T+" and "PA-8T"
* POS (Packet over Sonet) card "PA-POS-OC3" (experimental, only works with recent IOS images)
The following Cisco 3600 (3620,3640,3660) Network Modules (NM) are currently supported:
* Ethernet cards: "NM-1E", "NM-4E" and "NM-1FE-TX", all based on AMD Am79c97x chips
* Ethernet switching module: "NM-16ESW"
* Serial card "NM-4T"
The following Cisco 2691/3725/3745 Network Modules (NM) are currently supported:
* FastEthernet cards: "NM-1FE-TX"
* Ethernet switching module: "NM-16ESW"
* Serial card "NM-4T"
The following Cisco 2600 Network Modules (NM) are currently supported:
* Ethernet cards: "NM-1E", "NM-4E" and "NM-1FE-TX"
* Ethernet switching module: "NM-16ESW"
You can also get development info and beta versions on my technical blog (http://www.ipflow.utc.fr/blog).
To run at a decent speed, the emulator uses a JIT (Just In Time) compiler, which is working on x86 CPU (like Pentium) and x86_64 CPU (AMD64/Intel EM64T). It is also possible to run the emulator without the JIT support on non-x86 machines, but it is slower.
You can find some information about the C7200 hardware on the Cisco Web site (http://www.cisco.com/en/US/products/hw/routers/ps341/products_tech_note09186a00800942e0.shtml)
[edit]
Lab simulation / "Hypervisor" mode
With the introduction of the 0.2.5 release, it is now possible to run the emulator as an "hypervisor" to start and control many virtual router instances simultaneously.
Dynagen (http://dyna-gen.sourceforge.net/), by Greg Anuzelli, is a front-end (written in Python) that makes lab simulation with the hypervisor very easy: it uses an INI-like configuration file to provision Dynamips emulator networks. It takes care of specifying the right port adapters, generating and matching up those pesky NIO descriptors, specifying bridges, frame-relay, ATM switches, etc. It also provides a management CLI for listing devices, suspending and reloading instances, etc. You can also distribute virtual instances across different servers to set up complex labs. To begin with Dynagen, you can consult this very complete tutorial (http://dyna-gen.sourceforge.net/tutorial.htm).
Dynagui (http://dynagui.sourceforge.net/) is a graphical front-end written by Yannick Le Teigner. It uses Dynagen to communicate with the hypervisor.
[edit]
Contributors are welcome ! :)
For people interested to contribute there is a TODO List.
There are many things to do: a more efficient JIT, network device emulation, new platforms...
[edit]
Download
The current release is 0.2.7, published May 26, 2007 (you can consult the README file (http://www.ipflow.utc.fr/dynamips/README-0.2.7.txt)).
You have to download only one binary file corresponding to your architecture:
* Executable for Linux/x86 (http://www.ipflow.utc.fr/dynamips/dynamips-0.2.7-x86.bin)
* Executable for Linux/x86_64 (AMD64 and EM64T) (http://www.ipflow.utc.fr/dynamips/dynamips-0.2.7-amd64.bin)
* Executable for Windows (with Cygwin DLL) (http://www.ipflow.utc.fr/dynamips/dynamips-0.2.7-cygwin.zip)
If you are using the Windows version, you have to download and install the WinPcap library (http://www.winpcap.org/). The minimum required version is 0.4. Thanks to WinPCAP, it is possible to access the Ethernet card of host machine to send/receive packets on the LAN.
You can also download the source code, published under the GNU General Public Licence (GPL):
* The source code of release v0.2.7 (http://www.ipflow.utc.fr/dynamips/dynamips-0.2.7.tar.gz)
Remark: the sources include 3 files which are not written by me: amd64-codegen.h and x86-codegen.h from the Mono project (http://www.mono-project.com), and base64.c from Fetchmail, all under GPL licence. Of course these files keep their licences and their copyrights.
[edit]
How to use it ?
Very important remark: by default, an instance will take 100% of the host CPU. To avoid this, please read the "idle-pc" section in the README file (http://www.ipflow.utc.fr/dynamips/README-0.2.7.txt).
To boot quickly, the preferred method is to decompress the IOS image with the "unzip" utility. It avoids to run the self-decompressing process in the emulator.
chris@portchris2:~/dynamips-0.2.5$ unzip -p c7200-advipservicesk9-mz.124-9.T.bin > image.bin
warning [c7200-advipservicesk9-mz.124-9.T.bin]: 27904 extra bytes at beginning or within zipfile
(attempting to process anyway)
chris@portchris2:~/dynamips-0.2.5$ file image.bin
image.bin: ELF 32-bit MSB executable, cisco 7200, version 1 (SYSV), statically linked, stripped
You can ignore the warning, unzip has just skipped the self-decompressing code at the beginning of the image.
Now, you can boot the image (in this example, no network connections are defined):
chris@portchris2:~/dynamips-0.2.5$ ./dynamips image.bin -t npe-400 -p 1:PA-A1 -p 2:PA-8T -p 3:PA-4E -p 4:PA-POS-OC3 -p 6:PA-FE-TX
Cisco 7200 Simulation Platform (version 0.2.5-x86)
Copyright (c) 2005,2006 Christophe Fillot.
IOS image file: image.bin
CPU0: carved JIT exec zone of 64 Mb into 2048 pages of 32 Kb.
NVRAM is empty, setting config register to 0x2142
C7200 instance 'default' (id 0):
VM Status : 0
RAM size : 256 Mb
IOMEM size : 0 Mb
NVRAM size : 128 Kb
NPE model : npe-400
Midplane : vxr
IOS image : image.bin
Loading ELF file 'image.bin'...
ELF entry point: 0x80008000
C7200 'default': starting simulation (CPU0 PC=0xffffffffbfc00000), JIT enabled.
ROMMON emulation microcode.
Launching IOS image at 0x80008000...
Restricted Rights Legend
Use, duplication, or disclosure by the Government is
subject to restrictions as set forth in subparagraph
(c) of the Commercial Computer Software - Restricted
Rights clause at FAR sec. 52.227-19 and subparagraph
(c) (1) (ii) of the Rights in Technical Data and Computer
Software clause at DFARS sec. 252.227-7013.
cisco Systems, Inc.
170 West Tasman Drive
San Jose, California 95134-1706
Cisco IOS Software, 7200 Software (C7200-ADVIPSERVICESK9-M), Version 12.4(9)T, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2006 by Cisco Systems, Inc.
Compiled Fri 16-Jun-06 17:27 by prod_rel_team
Image text-base: 0x60009084, data-base: 0x6308C000
This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.
A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
If you require further assistance please contact us by sending email to
export@cisco.com.
Cisco 7206VXR (NPE400) processor (revision A) with 245760K/16384K bytes of memory.
Processor board ID 4294967295
R7000 CPU at 150MHz, Implementation 39, Rev 2.1, 256KB L2, 512KB L3 Cache
6 slot VXR midplane, Version 2.1
Last reset from power-on
PCI bus mb0_mb1 (Slots 0, 1, 3 and 5) has a capacity of 600 bandwidth points.
Current configuration on bus mb0_mb1 has a total of 540 bandwidth points.
This configuration is within the PCI bus capacity and is supported.
PCI bus mb2 (Slots 2, 4, 6) has a capacity of 600 bandwidth points.
Current configuration on bus mb2 has a total of 500 bandwidth points
This configuration is within the PCI bus capacity and is supported.
Please refer to the following document "Cisco 7200 Series Port Adaptor
Hardware Configuration Guidelines" on Cisco.com
for c7200 bandwidth points oversubscription and usage guidelines.
4 Ethernet interfaces
2 FastEthernet interfaces
8 Serial interfaces
1 ATM interface
1 Packet over SONET interface
125K bytes of NVRAM.
Installed image archive
65536K bytes of ATA PCMCIA card at slot 0 (Sector size 512 bytes).
8192K bytes of Flash internal SIMM (Sector size 256K).
--- System Configuration Dialog ---
Would you like to enter the initial configuration dialog? [yes/no]:
[edit]
Questions & Answers
There is a "Frequently Asked Questions" page.
It is also recommended to consult the Hacki's forum (http://7200emu.hacki.at/). Many tips, lab examples, ... are published on it.
Help for Cisco router simulator (dynamips-0.2.7)
================================================
Authors of this document: Fabien Devaux, Christophe Fillot, MtvE
Emulated hardware
*****************
The emulator currently supports the following platforms:
- Cisco 7200 (NPE-100 to NPE-400)
- Cisco 3600 (3620, 3640 and 3660)
- Cisco 2691
- Cisco 3725
- Cisco 3745
By default, a Cisco 7206VXR with NPE-200 (256 Mb of DRAM) is emulated.
To emulate another platform, use the "-P" command line option (for example,
"-P 3725" or "-P 3600").
For the 7200, you can change the NPE type with the "-t" option.
It is possible to select "npe-100", "npe-150", "npe-175", "npe-200",
"npe-225", "npe-300" and "npe-400". The "npe-g1" is not working.
For the 3600, a 3640 with 128 Mb is emulated by default. You can change this
with the "-t" option and by specifying "3620" or "3660".
Don't forget to set the chassis type depending on your IOS image,
a c3660 image will not run on c3640 hardware and vice-versa.
Remark: PCMCIA card emulation is not supported yet with Cisco 3600.
Command Line Options overview
*****************************
-l
-j : Disable the JIT compiler, very slow
--exec-area
--idle-pc
--timer-itv
-i
-r
-o
-n
-c
-m
(default: automatically generated)
-C
-X : Do not use a file to simulate RAM (faster)
-R
-k
-T
-U
(default is on the terminal)
-A
-B
(default is no AUX port)
--disk0
--disk1
-a
-f
-E
-b
-e : Show network device list of the host machine
Options specific to the Cisco 7200 series:
-t
-M
-p
-s
Options specific to the Cisco 3600 series ("dynamips -P 3600 --help"):
-t
--iomem-size
-p
-s
Options specific to the Cisco 2691 series ("dynamips -P 2691 --help"):
--iomem-size
-p
-s
Options specific to the Cisco 3725 series ("dynamips -P 3725 --help"):
--iomem-size
-p
-s
Options specific to the Cisco 3745 series ("dynamips -P 3745 --help"):
--iomem-size
-p
-s
Command Line Options details
****************************
-k
Specify the clock divider (integer) based on the host clock.
Alter the value to match the CISCO clock with the real time.
The command "show clock" at the IOS' CLI will help you set this value.
--idle-pc
The "idle PC" feature allows you to run a router instance without having
a 100% CPU load. This implies that you can run a larger number of instances
per real machine.
To determine the "idle PC", start normally the emulator with your Cisco IOS
image, and a totally IOS empty configuration (although not mandatory, this
will give better results). When the image is fully booted, wait for the
"Press RETURN to get started!" message prompt, but do not press Enter key.
Wait about 5 seconds, then press "Ctrl-] + i". Some statistics will be
gathered during 10 seconds. At the end, the emulator will display a list of
possible values to pass to the "--idle-pc" option. You may have to try some
values before finding the good one. To check if the idle PC value is good,
just boot the Cisco IOS image, and check your CPU load when the console
prompt is available. If it is low, you have found a good value, keep it
preciously.
Important remarks:
==================
* An "idle PC" value is *specific* to a Cisco IOS image. You cannot
boot a different IOS image without proceeding as described above.
* Do not run the process while having the "autoconfiguration" prompt.
--exec_area
The exec area is a pool of host memory used to store pages translated by
the JIT (they contain the native code corresponding to MIPS code pages).
Cisco 7200 Port Adapter Description "
------------------------------------------------
Format: slot:pa_driver
slot: the number of the physical slot (starts from 0)
pa_driver: the name of a Port Adapter driver in:
- C7200-IO-FE (FastEthernet, slot 0 only)
- PA-FE-TX (FastEthernet, slots 1 to 6)
- PA-4E (Ethernet, 4 ports)
- PA-8E (Ethernet, 8 ports)
- PA-4T+ (Serial, 4 ports)
- PA-8T (Serial, 8 ports)
- PA-A1 (ATM)
Cisco 3600 Network Module Description "
--------------------------------------------------
Format: slot:nm_driver
slot: the number of the physical slot (starts from 0)
nm_driver: the name of a Network Module driver in:
- NM-1E (Ethernet, 1 port)
- NM-4E (Ethernet, 4 ports)
- NM-1FE-TX (FastEthernet, 1 port)
- NM-4T (Serial, 4 ports)
- NM-16ESW (Ethernet switch module, 16 ports)
- Leopard-2FE (Cisco 3660 FastEthernet in slot 0, automatically used)
Cisco 2691/3725/3745 Network Module Description "
------------------------------------------------------------
Format: slot:nm_driver
slot: the number of the physical slot (starts from 0)
nm_driver: the name of a Network Module driver in:
- NM-1FE-TX (FastEthernet, 1 port)
- NM-4T (Serial, 4 ports)
- NM-16ESW (Ethernet switch module, 16 ports)
- GT96100-FE (2 integrated ports, automatically used)
NIO binding to Port Adapter "
----------------------------------------------------------------------
Format: slot:port:netio_type[:netio_parameters]
slot : the number of the physical slot (starts from 0)
port : the port in the specified slot (starts from 0)
netio_type : host interface for communication
unix:
Use unix sockets for local communication.
(ex. "/tmp/local:/tmp/remote")
vde:
For use with UML (User-Mode-Linux) or VDE switches.
VDE stands for "Virtual Distributed Ethernet".
Please refer to : http://sourceforge.net/projects/vde/
tap:
Use a virtual ethernet device for communication.
gen_eth:
Use a real ethernet device for communication, using libpcap 0.9
or WinPcap. Works on Windows and Unix systems.
The device list can be found using the "-e" option.
linux_eth:
Use a real ethernet device for communication (Linux specific).
udp:
Use an UDP socket for connection between remote instances.
(ex. "1000:somehost:2000" and "2000:otherhost:1000" on the other
side)
tcp_cli:
Client side of a tcp connection.
tcp_ser:
Server side of a tcp connection.
null
Dummy netio (used for testing/debugging), no parameters needed.
VTTY binding to real serial port device "
----------------------------------------------------
Format:
device: character device name, e.g. /dev/ttyS0
baudrate: baudrate
databits: number of databits.
parity: data parity: N=none, O=odd, E=even,
stopbits: number of stop bits
hwflow: hardware flow control (0=disable, 1=enable)
Note that the device field is mandatory, however other fields are optional.
(dynamips will default to 9600, 8, N, 1, no hardware flow control)
Note that access to the escape commands (described below) through a serial
port are deliberately prevented, as the escape commands interfere with
serial encapsulation protocols.
Escape commands
***************
You can press ^] (Ctrl + ]) at any time, followed by one of these characters:
o : Show the VM object list
d : Show the device list
r : Dump MIPS CPU registers
t : Dump MIPS TLB entries
m : Dump the latest memory accesses
s : Suspend CPU emulation
u : Resume CPU emulation
q : Quit the emulator
b : Dump the instruction block tree
h : JIT hash table statistics
l : MTS64 cache statistics
c : Write IOS configuration to disk (ios_cfg.txt)
j : Non-JIT mode statistics
i : Determine an idling pointer counter
x : Experimentations (can crash the box!)
^]: Send ^]
If you press an unrecognized key, help will be shown.
Note: on Windows, it may be the "Ctrl + $" sequence.
Virtual Bridge
**************
The virtual bridge is used to emulate a shared network between emulator
instances.
Any emulator instance can act as a virtual bridge.
The configuration file (specified by the "-b" option) contains a list of
NetIO descriptors, with the following syntax:
interface_name:netio_type[:netio_parameters]
Example:
# Connection to instance "I0"
I0:udp:10000:127.0.0.1:10001
# Connection to instance "I1"
I1:udp:10002:127.0.0.1:10003
# Connection to instance "I2"
I2:udp:10004:127.0.0.1:10005
The "I0" instance would be launched with the following parameters:
dynamips ios.bin -p 1:PA-FE-TX -s 1:0:udp:10001:127.0.0.1:10000
Virtual Ethernet switch
***********************
The virtual ethernet switch is used to emulate an Ethernet network between
emulator instances. This switch supports access and trunk ports (802.1Q).
ISL will be available in a future release.
Any emulator instance can act as a virtual ethernet switch.
The configuration file (specified by the "-E" option) contains a list of
NetIO descriptors (representing interfaces) and a list of interface properties
(access/trunk port, VLAN info...)
The interface definition is similar to Port Adapters:
IF:interface_name:netio_type[:netio_parameters]
1) Configuring an Access Port
syntax: ACCESS:interface_name:vlan_id
2) Configuration a 802.1Q Trunk Port
syntax: DOT1Q:interface_name:native_vlan
The native VLAN is not tagged. On Cisco devices, by default the native VLAN
is VLAN 1.
Example of configuration file:
IF:E0:udp:10000:127.0.0.1:10001
IF:E1:udp:10002:127.0.0.1:10003
IF:E2:gen_eth:eth0
DOT1Q:E0:1
ACCESS:E1:4
DOT1Q:E2:1
Virtual ATM switch
******************
The virtual ATM switch fabric is used to emulate an ATM backbone between
emulator instances. The use of this virtual switch is not mandatory, you
can directly connect emulator instances for point-to-point ATM connections.
Please note that only basic VP/VC switching is supported, there is no
support for ILMI/QSAAL/... or other specific ATM protocols.
Any emulator instance can act as a virtual ATM switch.
Example of configuration file (specified by the "-a" option):
# Virtual Interface List
IF:A0:udp:10001:127.0.0.1:10000
IF:A1:udp:10002:127.0.0.1:10003
IF:A2:udp:10004:127.0.0.1:10005
# VP connection between I0 and I1
VP:A0:10:A1:20
VP:A1:20:A0:10
# VP connection between I0 and I2
VP:A0:11:A2:30
VP:A2:30:A0:11
# VC connection between I1 and I2
VC:A1:5:2:A2:7:3
VC:A2:7:3:A1:5:2
In this example, we have 3 virtual interfaces, A0, A1 and A2. The syntax
for interface definition is similar to Port Adapters:
IF:interface_name:netio_type[:netio_parameters]
You can do VP switching or VC switching:
1) VP switching
syntax: VP:input_if:input_vpi:output_if:output_vpi
2) VC switching
syntax: VC:input_if:input_vpi:input_vci:output_if:output_vpi:output_vci
Testing the Virtual ATM switch with one dynamips instance
*********************************************************
(Contribution of Mtv Europe)
Virtual ATM switch configuration file ("atm.cfg"):
IF:A0:udp:10003:127.0.0.1:10001
IF:A1:udp:10004:127.0.0.1:10002
# a0/vpi=1/vci=100 connects to a1/vpi=2/vci=200
VC:A0:1:100:A1:2:200
VC:A1:2:200:A0:1:100
Invoking dynamips:
./dynamips -p 1:PA-A1 -s 1:0:udp:10001:127.0.0.1:10003 \
-p 2:PA-A1 -s 2:0:udp:10002:127.0.0.1:10004 \
-a atm.cfg IOS.BIN
(note input ports of IOS interfaces are output ports of ATM switch
interfaces, and vice versa).
IOS configuration:
ip cef
ip vrf test
rd 1:1
route-target both 1:1
int a1/0
no shut
int a1/0.2 p
ip addr 1.1.1.1 255.255.255.0
pvc 1/100
interface a2/0
no shut
interface a2/0.2 p
ip vrf forwarding test
ip addr 1.1.1.2 255.255.255.0
pvc 2/200
!
# ping 1.1.1.2
!!!!!
Virtual Frame-Relay switch
**************************
The virtual Frame-Relay switch fabric is used to emulate a Frame-Relay
backbone between emulator instances. The use of this virtual switch is not
mandatory, you can directly connect emulator instances with appropriate IOS
configuration.
Any emulator instance can act as a virtual Frame-Relay switch.
There is only a basic implementation of the LMI protocol (ANSI Annex D), which
is probably not conforming but works with Cisco IOS. Fortunately, Cisco IOS
is able to detect automatically the LMI protocol.
Example of configuration file (specified by the "-f" option):
# Virtual Interface List
IF:S0:udp:10001:127.0.0.1:10000
IF:S1:udp:10002:127.0.0.1:10003
# DLCI switching between S0 and S1
VC:S0:200:S1:100
VC:S1:100:S0:200
In this example, we have 2 virtual interfaces, S0 and S1. The syntax
for interface definition is similar to Port Adapters:
IF:interface_name:netio_type[:netio_parameters]
DLCI switching syntax:
VC:input_if:input_dlci:output_if:output_dlci
In the example above, the switch is configured to switch packets
received on interface S0 with DLCI 200 to interface S1 with DLCI 100,
and vice-versa.
== EOF ==
Dynamips / Dynagen Tutorial
Documentation Revision 1.11.2
Greg Anuzelli
Introduction
Installing
IOS Images
Resource Utilization
Configuring your Telnet Client
Network Files
Running Simple Lab #1
Working with the Management Console
Calculating Idle-PC values
Simple Lab #2
Frame Relay Lab
Communicating with Real Networks
Ethernet Switch Lab
1700/2600/3600/3700 Routers
WIC Modules
Client / Server and Multi-server Operation
Memory Usage Optimizations
Packet Capture
Other Commands / Features
Hardware Currently Emulated
FAQs
· How do I determine idle pc values from Dynagen?
· When I try to run more than 4 router instances @ 256 MB each (or 6 instances @ 160 MB each) on Windows, or more than 7 instances @ 256 MB each (or 11 instances @ 160 MB each) on 32-bit Linux Dynamips crashes.
· I have a complex lab with several routers, and my serial interfaces are flapping, eigrp neighbor adjacencies are failing, show run and write mem takes forever.
· There is a newer version of Dynamips available than the one bundled with the Dynagen Windows installer. How do I use it with Dynagen? / How do I use Dynagen with Windows 2000 or Windows XP SP1?
· On Linux / Unix / OS X, when I bridge a router or switch interface to my local host I can’t ping it from my host. But this works on Windows? What gives?
· I have a question / I’m having a problem / I think I’ve found a bug. How do I submit a quality post on the forum or the bug tracking system thereby increasing the likelihood that someone will be able to help me out?
Introduction
Dynamips is a Cisco router emulator written by Christophe Fillot. It emulates 1700, 2600, 3600, 3700, and 7200 hardware platforms, and runs standard IOS images. In Chris’ own words:
This kind of emulator would be useful to:
· Be used as a training platform, with software used in real world. It would allow people to become more familiar with Cisco devices, Cisco being the world leader in networking technologies ;
· Test and experiment features of Cisco IOS ;
· Check quickly configurations to be deployed later on real routers.
Of course, this emulator cannot replace a real router, it is simply a complementary tool to real labs for administrators of Cisco networks or people wanting to pass their CCNA/CCNP/CCIE exams.
Although Dynamips provides a simple virtual switch, it does not emulate Catalyst switches (although it does emulate the NM-16ESW).
Dynagen is a text-based front end for Dynamips, which uses the “Hypervisor” mode for communication with Dynamips. Dynagen simplifies building and working with virtual networks:
* Uses a simple, easy to understand configuration file for specifying virtual router hardware configurations
* Simple syntax for interconnecting routers, bridges, frame-relay and ATM, and Ethernet switches. No need to deal with NetIOs
* Can work in a client / server mode, with Dynagen running on your workstation communicating with Dynamips running on a back-end server. Dynagen can also control multiple Dynamips servers simultaneously for distributing large virtual networks across several machines. Or you can run Dynamips and Dyngen on the same system
* Provides a management CLI for listing devices, starting, stopping, reloading, suspending, resuming, and connecting to the consoles of virtual routers.
Dynagen is written in Python, and is therefore compatible with any platform for which there is a Python interpreter (which is to say, many). The design is modular, with a separate OOP API for interfacing with Dynamips. Other Python applications could be written that use this API for programmatically provisioning virtual networks, or to provide other front-ends. For example, a team is working on GNS-3; a GUI front-end using this library.
If somehow you have stumbled upon this tutorial without first finding the Dynamips or Dynagen web sites, here they are along with some other important links:
Dynamips (the actual emulator): http://www.ipflow.utc.fr/index.php/Cisco_7200_Simulator
Dynamips Blog (where most of the action is): http://www.ipflow.utc.fr/blog/
Dynagen (a front-end to the emulator): http://dyna-gen.sourceforge.net/
GNS-3 (a graphical network simulator that uses Dynagen’s libraries): http://www.gns3.net/
Dynamips / Dynagen Bug tracking: http://www.ipflow.utc.fr/bts/
Hacki’s Dynamips / Dynagen / Dynagui Forum: http://7200emu.hacki.at/index.php
Special thanks to the creators of the ConfigObj library at http://www.voidspace.org.uk/python/modules.shtml#configobj. This library is used by Dynagen for reading its configuration files.
Installing
Dynagen runs on any platform that supports Python, which is to say nearly any platform. I have also put together a Windows installer package that includes Dynamips and provides a compiled version of Dynagen, eliminating the need to install Python. It also provides Explorer “integration” so you can double-click on network files in order to run them.
First, install libpcap, or winpcap depending on your platform on the machine on which you intend to run Dynamips. This is used to provide bridging router interfaces to physical network cards. Windows users will need to install Winpcap 4.0 or later, which is current in beta.
Then, Windows users should install the Windows installer package. This provides everything you need to run Dynamips / Dynagen on local or remote machines.
Linux users should download the Dynamips / Dynagen tarball, and extract it to a suitable location (e.g. /opt/dynagen). Then create symlinks to the Dynagen and Dynamips executables in /usr/local/bin, or somewhere else in your PATH.
Note: If you are running Dynamips on a RedHat or Fedora system, take a look at Dynamips FAQ item #2 if you are experiencing segfaults when you try to run Dynamips.
IOS Images
Dynamips runs real Cisco IOS images. From the Dynamips FAQ:
Can you provide a Cisco IOS image for a 7200 to me?
No, I am not allowed to distribute any IOS image. You will have to find one by yourself, this should not be a problem if you are a Cisco customer.
On Windows, drop the image in C:\Program Files\Dynamips\images. You can actually drop the images anywhere you want, but the sample labs are configured to look here. On Linux/Unix systems, designate a location to store your images and drop them there (I like to use /opt/images, but it’s your system.)
Cisco IOS images are compressed. These compressed images will work just fine with Dynamips*, however the boot process is slowed significantly by this decompression process (just like on real routers). It is recommended that you decompress the images beforehand, so the emulator doesn’t have to. You can do this with the “unzip” utility on Linux/Unix/Cygwin as follows:
unzip -p c7200-g6ik8s-mz.124-2.T1.bin > c7200-g6ik8s-mz.124-2.T1.image
You will receive a warning from unzip, which you can safely ignore. On Windows you can use WinRAR to uncompress images.
* Note that currently images for 2600 routers must be uncompressed to work with Dynamips.
Resource Utilization
Dynamips uses a fair amount of RAM and CPU in order to accomplish its emulation magic. If you intend to run an IOS image that requires 256 MB of RAM on a real 7200 router, and you devote 256 MB of RAM to your virtual router instance, it will allocate 256 MB of working set memory. Dynamips also allocates (by default) 64 MB of RAM / instance on Unix systems (16 MB on Windows systems) to cache JIT translations. This will be the total working set size; by default the amount of your system’s actual RAM used will typically be significantly less. This is because by default Dynamips uses memory mapped files for the routers’ virtual memory. In the working directory you will see temporary “ram” files equal to the size of the virtual routers’ RAM size. Your OS will naturally cache in RAM the sections of the mmap files that are being used. (See the Memory Usage Optimizations section for configuration options that can signficanly reduce memory utilization).
If you have plenty RAM, and you know what you are doing, set “mmap = false” in the device default or router sections of your labs to disable mmap for those instances.
Dynamips also uses a lot of CPU, because it is emulating a router’s CPU instruction-by-instruction. it initially has no way of knowing when the virtual router’s CPU is idle so it dutifully executes all the instructions that make up IOS’s idle routines just as it would execute the instructions that perform “real” work. But once you have run through the “Idle-PC” process for a given IOS image, CPU utilization decreases drastically. More on this later.
Configuring your Telnet Client
Dynagen includes a console command that allows you to connect to the virtual router consoles directly from the CLI. But you must first configure the dynagen.ini file (located in C:\Program Files\Dynagen on Windows systems, or wherever you extracted the tarball on Unix systems) to tell it which telnet client to use. Uncomment the line appropriate for your system, or craft your own to use your favorite telnet client. See the comments in the ini file for instructions.
Network Files
Dynagen uses a single “network file” to store the configuration of all the routers, switches, and interconnections that make up a virtual lab. This file uses a simple INI file-like syntax. Open up the simple1.net file in a text editor (on Windows there is a shortcut to the “Dynagen Sample Labs” directory on the desktop).
# Simple lab
Any line prefaced with a # is a comment, and is ignored
[localhost]
The first section specifies the host that is running Dynamips. In this case, we intend to run Dynamips on the same machine as Dynagen, so we specify localhost. If Dynamips were running on a different machine, you would put the hostname or IP address of that machine here instead (we’ll see an example of that a bit later on.)
[[7200]]
The next section is indented, and double bracketed. This means that what follows is configuration that applies to the Dynamips server specified in the section above (in this case, localhost). All whitespace is actually ignored, so the indentation is just for looks. The double-bracket is what really means that this section is nested under the [localhost] section.
This [[7200]] section defines all the defaults that will be applied to any 7200 router instance we create. This makes things easy, by allowing us to specify common things like RAM size and IOS image only once. Note that you can specify defaults, and later override them in specific router instance definitions.
image = \Program Files\Dynamips\images\c7200-jk9o3s-mz.124-7a.image
# On Linux / Unix use forward slashes:
# image = /opt/7200-images/c7200-jk9o3s-mz.124-7a.image
The image keyword specifies the location on the system running Dynamips (in this example our local machine) of the image we want to use by default for all router instances. Here we are pointing to a 12.4 image on a Windows system. For Linux/Unix systems, use forward slashes instead, as shown in the comment.
npe = npe-400
ram = 160
Each of our router instances is going use an NPE-400, and be allocated 160 MB of RAM .
[[ROUTER R1]]
Now, we are defining a virtual router instance with the ROUTER keyword. The string following this keyword is the name we are assigning to this router, in this case “R1”. This name is just the name that is used by Dynamips / Dynagen. It has nothing to do with the hostname that you assign in IOS to the router (although it will probably be less confusing if you just keep them the same.)
s1/0 = R2 s1/0
This line states that we are going to take R1’s Serial 1/0 interface, and connect it to R2’s Serial 1/0 interface (via virtual back-to-back serial cable). Dynagen automatically “installs” a PA-8T adapter in Port 1 to accommodate this connection on both R1 and R2 (note there is a way to override this behavior if, for example, you wanted to use a PA-4T+ instead for some reason).
[[router R2]]
Now we create a 2nd router, creatively name R2. This is the same R2 that is referenced in the line above that connects R1 and R2’s serial interfaces. As you can see, the ROUTER keyword is not case significant. (None of the keywords are.)
# No need to specify an adapter here, it is taken care of
# by the interface specification under Router R1
Although we have to create the R2 router, we do not need to specify any adapters here. R2’s Serial 1/0 interface was already created back when we connected it to R1’s Serial 1/0 above.
Running Simple Lab #1
In order to run this virtual lab, first start up the Dynamips server on your local machine. If you used the Windows installer, you will find a shortcut on the desktop titled “Dynamips Server”. Running this starts up the server (listening on port 7200 by default) in a window like this:
On Linux / Mac / Unix, start up the server in the background. For example:
dynamips –H 7200 &
On Windows, open the simple1.net file in explorer and Dynagen is automatically launched and the network started:
On Linux / Unix, either associate “.net” files with dyangen in whatever file manager you use, or run it from the command line:
dynagen simple1.net
For now, ignore the “no idle-pc value” warning; we’ll get to this a bit later. To see all the devices in this virtual lab, use the list command:
This tells us that there are two routers, R1 & R2. They are both currently running on the local host. R1’s console port is tied to TCP port 2000, and R2’s to port 2001. Telnet to these ports to connect to the virtual router instances. Or, if you configured the dynagen.ini file to specify your telnet client, just type “console R1” to connect to R1’s console.
Even better, you can type “console /all” and a console window will appear for each of your virtual routers. If you use Linux, OS X, or Tera Term SSH on Windows “console /all” works well because the title bar include the name of the router. However the Windows telnet command included with the OS does not seem to allow this. (If anyone can come up with a work-around for this please let me know. I’ve tried setting the title using the “start” command, and it is overwritten as soon as telnet is launched.). But Dynamips lets you know which router you are connecting to as its first line of output inside the telnet window, so you can identify it that way. By the way, the “console” command can be abbreviated as “con” – e.g. “con /all”.
Assign appropriate IP addresses to the Serial 1/0 interfaces on both routers, and “no shut” them, and you should find that they are indeed connected.
Working with the Management Console
From the Management Console, use the help command to see a list of valid commands:
To get help on a particular command, either type help command or command ?. For example:
On platforms that provide the Readline library (Linux/Unix) the console will have tab completion. (I have not yet found a suitable Python Readline library for Windows to provide this functionality. If anyone can find one that *they have tested with Dynagen and works* please let me know.)
To “power off” a virtual router, use the stop command. Help shows the syntax as:
stop {/all | router1 [router2] ...}
To shut down a single router, type use stop routername:
And sure enough, the router is now stopped:
You can also provide a list of routers to stop, or issue as stop /all to shut down all router instances.
To restart R1, use start command:
start {/all | router1 [router2] ...}
The IOS reload command is not suppored by dynamips in virtual routers. So you can use the Dynagen reload command. It performs a stop, followed by a start. To reload all routers in the entire lab, issue a reload /all:
The suspend and resume commands have a similar syntax as stop and start, but they temporarily pause the specified routers:
The exit command stops and deletes all devices from the network, and exits dynagen. If you exit the Management Console, your simulation will no longer be running.
Calculating Idle-PC values
You may have noticed that the previous lab caused your system’s CPU to peg at 100% and stay there. This is because Dynamips does not know when the virtual router is idle and when it is performing useful work. The “idlepc” command performs analysis on a running image to determine the most likely points in the code that represent an idle loop in IOS. Once applied, Dynamips “sleeps” the virtual router occasionally when this idle loop is executed significantly reducing CPU consumption on the host without reducing the virtual router’s capacity to perform real work.
Here is how the process is performed. First, open a lab and make sure only one router instance is running (stop any others in the lab if need be):
Then, telnet to the running router instance. If you are presented with IOS autoconfig prompt, respond with “no”. Otherwise, do not press anything:
Wait for all the interfaces to initialize, then wait a bit to ensure that the router is no longer booting and is idle. Your session should look something like this:
Now, switch back to the Dynagen management console, and issue an “idlepc get routername”. You will see a message that statistics are being gathered, and about 10 seconds later you should see a list of potential idlepc values:
Values that will most likely provide better results are marked with an asterisk. Select one of the values to try from the menu and press Enter. You should notice your host (the one running the dynamips process) CPU utilization drop dramatically. If so, you’ve found a good idlepc value for this particular IOS image.
If your CPU usage did not drop, it’s time to try a different value. Type “idlepc show routername” to show the list of values determined earlier again, and this time select a different one.
The new idlepc value will take effect dynamically. Once you’ve found a value that works, you can save it to your local idlepc database with “idlepc save routername db”. This stores the idlepc value for this IOS image in the file specified in dynagen.ini with the “idledb” option. The default is a file name “dynagenidledb.ini” in your $HOME or “Documents and Settings” folder (depending on your platform).
Once an idlepc value is in the database, it will be automatically applied whenever a router in one of your labs uses this image. If Dynagen starts a router without being able to find an idlepc value, it gives the “Warning: Starting xxx with no idle-pc value” message. If you would prefer to store the idlepc value directly in your network file, use “idlepc save routername” to add an “idlepc = xxxx” line to the router definition section (e.g. “[[ROUTER R1]]”) or use “idlepc save rotuername default” to store it in the default section of your network file for that router platform (e.g. “[[7200]]”).
Idle-PC values are are particular to an IOS image. They will be different for different IOS versions, and even for different feature sets of the same IOS version. However Idle-PC values are not particular to your host PC, operating system, or to the version of dynamips. So “dynagenidledb.ini” files from one system can be freely copied, merged, shared with others, etc.
The idlepc database is indexed by the name of your IOS image as specified in the “image =” line of your network file (minus the directories), so all your images must have unique names for this to work. I strongly recommend using the convention of keeping the same filename as the downloaded bin file, but replacing “bin” with “image” to indicate that the bin file has been unzipped (e.g. “c7200-jk9o3s-mz.124-7a.image”.) If everyone uses this same convention, it will make sharing databases transparent.
It is possible that dynamips will not be able to find and idlepc value for an image, or that the values it does find do not work. If this happens, try repeating the process again. Or you just might be out of luck with that particular image (however running into this situation is rare.)
Simple Lab #2
The lab “simple2.net” (located in the sample_labs directory) shows the use of the “LAN” keyword to specify bridged networks.
[[ROUTER Zapp]]
console = 2001
f0/0 = LAN 1
f1/0 = LAN 2
First, we are manually specifying the console port for Zapp (port 2001). This is usually never required, but is here to show that you can control most all of the defaults that are chosen by Dynagen by overriding them with specific values. FastEthernet0/0 is connected to LAN 1. “1” is an identifier that can be any alphanumeric sequence. All Ethernet interfaces that are connected to the same LAN are bridged together (like connecting them to a virtual hub). Also, just like in the previous lab with the Serial port adapter, Dynagen automatically installs a PA-C7200-IO-FE adapter in port 0, and a PA-FE-TX adapter in port 1 just by referencing f0/0 and f1/0.
In this lab all of the f0/0 interfaces are on one Ethernet segment, and all the f1/0 interfaces are on another segment:
[[ROUTER Leela]]
console = 2002
f0/0 = LAN 1
f1/0 = LAN 2
[[ROUTER Kif]]
console = 2003
f0/0 = LAN 1
f1/0 = LAN 2
Loading in this lab shows that LANs are second-class citizens, so to speak, in that they are not shown in the device list:
Also note that because you now have an idlepc value in your database for this IOS image, you no longer get the “Warning:starting xxx with no idle-pc value” message.
Frame Relay Lab
Dynamips (and accordingly Dynagen) provides support for an integrated frame relay switch. Looking at the “frame_relay1.net” lab, connectivity to the switch is specified like so:
[[ROUTER R1]]
s1/0 = F1 1
[[ROUTER R2]]
s1/0 = F1 2
[[ROUTER R3]]
s1/0 = F1 3
We are connecting the routers’ serial interfaces to ports 1, 2, and 3 respectively on a Frame Relay switch named “F1”.
[[FRSW F1]]
1:102 = 2:201
1:103 = 3:301
2:203 = 3:302
Here we define the switch using the FRSW keyword, and name the switch F1. The format of each Frame Relay switch entry is:
Port:dlci = port:dlci
The first line is assigning a local DLCI of 102 on port 1, which maps to a DLCI of 201 on port 2. The other two lines are configured similarly, creating a full mesh of PVCs between the three routers. (103 <-> 301, and 201 <-> 302).
Note: The Frame Relay switch emulated by Dynamips uses an LMI type of ANSI Annex D, not Cisco.
Launching the lab shows the following:
There are several things to note here. First, all the routers are stopped. This is because of the “autostart = false” line at the beginning of the network file. By default, all routers are automatically started when a lab is launched. The autostart keyword overrides this behavior, and the lab must manually be started (start /all). Also, the Frame Relay switch F1 is listed, but you can’t stop, start, suspend, or resume it like you can with virtual routers.
You can configure multiple Frame Relay switches in a single lab. Dynamips also provides virtual ATM switches. See the “all_config_options.txt” file for an ATM example.
Communicating with Real Networks
Dynamips can bridge virtual router interfaces real host interfaces, allowing your virtual network to communicate with the real world. On Linux systems, this is done with the NIO_linux_eth NIO descriptor. For example:
f0/0 = NIO_linux_eth:eth0
this bridges this router’s F0/0 interface to the eth0 interface on the host. Packets that exit f0/0 are dumped out on to the real network through eth0, and return packets are forwarded back to the virtual router instance accordingly.
On Windows systems, the Winpcap library is used to accomplish this bridging. Interface specification is a little more complex on Windows systems, so Dynamips provides a command line switch to list the available interfaces on Windows hosts. The Dynamips/Dynagen Windows installer includes a shortcut to this utility. On the desktop, open the “Network Device List” shortcut:
So on my Windows system, I would use:
F0/0 = NIO_gen_eth:\Device\NPF_{B00A38DD-F10B-43B4-99F4-B4A078484487}
to bridge to my local Ethernet adapter.
Ethernet Switch Lab
New to Dynamips as of version 0.2.5-pre22 is an integrated virtual Ethernet switch that supports VLANs with 802.1q encapsulation.
Open the Ethernet Switch lab and you will see that connecting Ethernet interfaces to the virtual switch is similar to working with the Frame Relay switch:
[[ROUTER R1]]
F1/0 = S1 1
[[ROUTER R2]]
F1/0 = S1 2
[[ROUTER R3]]
F1/0 = S1 3
Then, to configure these ports on the switch:
[[ETHSW S1]]
1 = access 1
2 = access 20
3 = dot1q 1
#4 = dot1q 1 NIO_gen_eth:eth0
4 = dot1q 1 NIO_gen_eth:\Device\NPF_{B00A38DD-F10B-43B4-99F4- B4A078484487}
Port 1 of the switch (connected to R1 F1/0) is an access port in VLAN 1. Port 2 is also an access port, but in vlan 20. Port 3 is a trunk port (specified with the dot1q keyword) with a native VLAN of 1. Trunk ports trunk all the VLANs known to the switch.
The switchport 4 config shows how to connect a switchport to the “real world”. Here we are connecting a trunk port with a native vlan of 1 to the host’s eth0 or Windows network device using the NIO_gen_eth Winpcap NIO. If this host interface is connected to a real switch that is configured for trunking, you can now easily connect any router instance to any VLAN you wish.
Dynagen includes CLI commands to show and clear the MAC address tables of virtual Ethernet switches. Those commands are “show mac Ethernet_switch_name’ and “clear mac ethenet_switch_name”.
1700/2600/3600/3700 Routers
As of Dynamips 0.2.8-RC1 and Dynagen 0.10.0 1700, 2600, 3600, 3700, and 7200 routers are emulated. Working with these models of routers is much like working with 7200s. You can specify default options that apply to (for example) all 2691, 3620, 3640, 3660, 3725, or 3745s in your lab with [[2691]], [[3620]], [[3640]], [[3660]], [[3725]], and [[3745]] sections. For example:
[[3660]]
image = /opt/3660-images/c3660-ik9o3s-mz.122-15.T17.image
ram = 96
When defining routers, the default is to emulate a 7200. Use the “model” option to specify a different model. E.g.:
[[ROUTER r1]]
model = 3660
f0/0 = R2 e1/1
You can mix and match router models in the same lab. If the majority of the routers in your lab are going to be a particular model other than 7200s, you can set the default for the lab by putting the “model” option at the top level. See all_config_options.txt for more info.
On the 1710, 1720, 1721, and 1750 platforms interfaces show in IOS without a slot designation. (e.g. “f0” for FastEthernet 0). Dynagen supports the use of this format for these routers as shown below:
[[ROUTER R1]]
model = 1720
f0 = R2 f0
[[ROUTER r2]]
model = 1720
Refer to the Hardware Currently Emulated section for an up to date list of which network modules are supported. As with 7200s, Dynagen automatically “installs” an appropriate adapter when you reference an interface such as f0/0, e1/2, s1/0, etc. (Or you can manually specify the adapter if you desire; again see all_config_options.txt for an example.)
WIC Modules
Dynamips 0.2.8-RC1 and Dynagen 0.10.0 also added support for several WIC modules. Currently, these are the WIC-1T and WIC-2T on the 1700, 2600, 2691 and 3700 platforms, and the WIC-1ENET on the 1700. See the Hardware Currently Emulated section for specific model info and how many WIC slots are provided on each platform.
Dynagen will automatically pick and “insert” a WIC module when you reference an interface that corresponds to a WIC module. For example, the config below results in a WIC-2T being inserted in WIC slot 0 on the motherboard on r1:
[[ROUTER r1]]
model = 2621XM
S0/0 = r2 s0/0
On 1720s, 1721s, and 1750s the interfaces provided by WIC modules are “slotless” just like the other interfaces (e.g. “e0” or “s0”). So use that format when specifying adapters in your NET file on those platforms.
You can also manually specific WIC modules much like manually specifying adapters. Use the WIC option like this:
[[ROUTER r1]]
model = 2621XM
WIC0/0 = WIC-2T
S0/0 = r2 s0/0
This configuration specifies a WIC-2T in WIC slot 0 on the motherboard (slot 0). To reference the 2nd WIC slot on the 2621XM, use “WIC0/1”. The 3700 series provides a 3rd wic slot, which is referenced with “WIC0/3”.
Keep in mind that IOS on different platforms present the interfaces provided by WIC modules in different ways. On 1720 – 1750, the first interface of a given type provided by a WIC presents itself as “interface 0” no matter which WIC slot it is in. On 1751 & 1760, modules in WIC slot 0 present as “interface 0/x” and modules in WIC slot 1 as “interface 1/x”. On other platforms the first interface of a given type presents itself as “interface 0/0”, the next as “interface 0/1” and so forth. This is the way real routers would present these interfaces; this is not specific to Dynamips.
Here are a few examples:
# Example 1
model = 1720
WIC0/0 = WIC-2T
WIC0/1 = WIC-1ENET
# This creates s0, s1, and e0
# Example 2
model = 1760
WIC0/0 = WIC-2T
WIC0/1 = WIC-1ENET
# This creates s0/0, s0/1, and e1/0
# Example 3
model = 3725
WIC0/0 = WIC-2T
WIC0/1 = WIC-1T
WIC0/2 = WIC-1T
# This creates s0/0, s0/1, s0/2, & s0/3
Client / Server and Multi-server Operation
The Dynamips “Hypervisor” mode that is used by Dynagen is a TCP/IP communications channel, so the Dynagen client can run on a different machine than the Dynamips emulator. This is done by specifying a host other than “localhost” in the network file. Take a look at the “multiserver.net” lab. First we specify the devices to run the local system (a Windows XP host):
# A windows server (the local machine)
[xplt]
[[7200]]
image = \PROGRA~1\Dynamips\images\c7200-ik9o3s-mz.122-15.T17.image
ram = 96
[[ROUTER R1]]
# Connect to s1/0 on R2 running on a different server
s1/0 = R2 s1/0
A few things to note: First, we must use the DNS name or the IP address of our local host, and not “localhost” when identifying the system. This is because the other server defined below will use this name when talking to our local system. Second, connecting to a device on another system is as simple as specifying it the same way you would if it was on the local system. You can use any connectivity method or device supported by Dynamips (Ethernet, Serial, ATM, Bridges, Ethernet switches, Frame Relay Switches, etc.) This “transparent” connectivity is new to Dynagen starting with version 0.4.
Next we define the other Dynamips server, and the router instance running on it:
# A linux server
[bender:7200]
workingdir = /home/greg/labs/dist1
[[7200]]
image = /opt/7200-images/c7200-ik9o3s-mz.122-15.T17.image
ram = 96
[[ROUTER R2]]
Here, we are talking to a server named “bender” (you can also specify and IP address here rather than a DNS name). We are specifying the TCP port that the Dynamips process is listening on as 7200. This is the default so isn’t actually necessary in this instance. But if you set up Dynamips to listen on a different port you would specify it here.
When talking to a remote server, you need to specify the working directory for this lab. As you may have noticed in the previous labs, Dynamips stores several files in the working directory. These include the NVRAM for the virtual router, as well as the bootflash, logfiles, and some other working files. When running Dynamips and Dynagen on the same machine, you do not need to specify the working directory, because Dynagen defaults to using the same directory as the network file. But in a distributed setup the network file is on the client and the working files are on the host. So specify the fully qualified path to the working directory on the Dynamips host. Be sure to use the correct directory separation character for the platform (here forward slashes for a Linux system).
Be sure that any host based firewalls running on all your Dynamips servers (for example, XP SP2’s firewall) are permitting the necessary traffic. This includes the Dynamips server port (defaults to TCP 7200), the console ports (e.g. TCP 2000, 2001, …) and the ports used by the NIO connections between interfaces, which start at UDP 10000 and work up from there.
Memory Usage Optimizations
As described in the Resource Utilization section your labs can consume a large amount of real and virtual memory. The “ghostios” and “sparemem” options were added to address both of these issues, respectively.
The Ghostios option can significantly reduce the amount of real host RAM needed for labs with multiple routers running the same IOS image. With this feature, instead of each virtual router storing an identical copy of IOS in its virtual RAM the host will allocate one shared region of memory that they will all utilize. So for example, if you are running 10 routers all with the same IOS image, and that image is 60 MB in size you will save 9*60 = 540 MB of real RAM when running your lab. Enabling ghostios is as simple as specifying “ghostios = true” in your network file. This option can be used in several places:
* If used at the top level, ghostios is applied to all router instances in the lab
* If used at the defaults section (e.g. “[[7200]]”) it applies only to that model of router on that dynamips server
* Note that ghostios (and all other top level parameters for that matter) cannot be specified at the server level. They will be ignored. ghostios also cannot be specified at the router level
Typical usage is to specify “ghostios = true” at the top level. Dynagen is smart enough only to use ghostios if there is more than one router using the same IOS image.
When enabled, you will notice additional files in the same directory as you router nvram files with names like “c3660-ik9o3s-mz.124-10.image.ghost”. This is the mmap’ed file that contains the shared memory region. The other files typically created with a router instance are created as well (log, nvram, and possibly bootflash files).
Measuring the amount of host memory saved with ghostios can be a little tricky due to the complexities of memory management in modern OSs. See this sticky post in the General section of Hacki’s Forum titled “Understanding memory usage and RAM Ghosting: for the gory details.
The “sparsemem” feature does not conserve real memory, but instead reduces the amount of virtual memory used by your router instances. This can be important, because OS limits a single process to 2 GB of virtual memory on 32-bit Windows, and 3 GB on 32-bit Linux. For example, on Windows, after the VM space used by cygwin and other libraries dynamips depends on, this only leaves room for 4 router instances @ 256 MB each! Enabling sparsemem only allocates virtual memory on the host that is actually used by IOS in that router instance, rather than the entire amount of RAM configured. This can allow you to run more instances per dynamips process before you have to resort to running multiple dynamips processes. See this FAQ item for more info on this issue.
Neither ghostios nor sparemem are enabled by default, so you must turn them on with:
ghostios = true
sparsemem = true
in your network file. If you use ghostios, the shared memory will be memory-mapped no matter what your mmap setting is. If you enable sparse-mem, no memory mapping will occur for router memory. You can choose to use ghostios or sparsemem separately or together.
Here is an example network file with typical ghostios and sparsemem usage – configured at the top level so that they are applied to all router instances in the lab:
model = 3660
ghostios = true
sparsemem = true
[localhost]
[[3660]]
image = \Program Files\Dynamips\images\c3660-ik9o3s-mz.124-10.image
[[router r1]]
fa0/0 = sw 1 # Note that you can use two letter interfaces names
# for increased clarity if you wish
[[router r2]]
fa1/0 = sw 2
[[router r3]]
fa1/0 = sw 3
[[ETHSW sw1]]
1 = access 5
2 = access 25
3 = access 35
4 = dot1q 1 NIO_gen_eth: NIO_gen_eth:\Device\NPF_{B00A38DD-F10B-43B4-99F4-B4A078484487}
Packet Capture
Dynamips / Dynagen can capture packets on virtual Ethernet or Serial interfaces and write the output to a capture file for use with applications like tcpdump, Wireshark, or any other application that can read the libpcap capture file format.
Consider three routers in series, “r1” and “r2” are connected via an Ethernet cable, and r2 connects to r3 via a point-to-point serial connection with HDLC encapsulation. The network file would look something like this:
model = 3660
[localhost]
[[3660]]
image = \Program Files\Dynamips\images\c3660-ik9o3s-mz.124-10.image
[[router r1]]
f0/0 = r2 f0/0
[[router r2]]
s1/0 = r3 s1/0
[[router r3]]
To begin capturing traffic at r1’s f0/0 interface and to write it to the file “r1.cap”, enter the following in the Dynagen Management window:
capture r1 f0/0 r1.cap
To view the traffic in real-time, open the file with Wireshark.:
The capture is continuing to write packets to the output file. If we ping r2 from r1, then hit the “reload this capture file” icon we see:
To stop capturing packets, enter:
no capture r1 f0/0
Dynamips / Dynagen can capture packets at serial interfaces too. In this case we must also specify the encapsulation we are using on our routers, so Wireshark will know how to decode the packets. Our encapsulation options are FR (Frame-Relay), HDLC, or PPP. To capture some traffic on our HDLC encapluated r2 to r3 link use:
capture r2 s1/0 r2.cap HDLC
Now we can open r2.cap, and the decode looks like this:
Now end the capture with “no capture r2 s1/0”. Note that you can have multiple captures running simultaneously against different interfaces on different routers.
Other Commands / Features
Dynamips and Dynagen provide more options and interface types than shown in this tutorial. Take a look at the “all_config_options.txt” file for list of all these options. For example, specifying an Ethernet adapter such as “e1/0” installs a PA-8E, “p1/0” installs a PA-POS-OC3, etc.
Here are some additional commands that can be used in the Dynagen management console that are not explained in this tutorial. Refer to the online help (command /? or help command) for usage:
* import / export – Imports and exports router configs from nvram to text files on your host. Can be used to get a copy of your current configs, or as a “snapshotting” feature to save your router configs before you make changes.
* push / save – Much like import and export, but the configs are stored as base64 encoded “blobs” right in your network file (specified with the “configuration” option). This allows you to distribute an entire lab with the network topology and IOS configs all in a single .net file
* filter – Applies a connection filter to an interface. Currently the only filter supported by dynamips is “freq_drop”, which drops x out of every y packets across a link (simulating intermittent packet loss).
* send – Used to send raw hypervisor commands to dynamips (see README.hypervisor included with the dynamips source for documentation on hypervisor commands). These hypervisor commands are how Dynagen communicates with Dynamips. This command would typically only be used uf developing new features in dynamips, experimenting, or simply curious.
* ver – outputs the version of Dynagen being used, as well as the versions of each dynamips instance Dynagen is connected to.
* hist – Dynagen management console command history (like “history” in bash)
* py – execute arbitrary python commands within the current dynagen namespace (for example, try “py print namespace.devices”)
* shell (or !) – pass commands to the DOS or Unix shell (e.g. “! dir” or “! ls”)
Also be sure to keep up on Dynamips development by following the technical blog at http://www.ipflow.utc.fr/blog/ for the latest developments.
Hardware Currently Emulated
Stolen Borrowed from ggee’s excellent post on Hacki’s forum:
===========1700s===========
1710
Slots: 0 (available)
WIC slots: 0
CISCO1710-MB-1FE-1E (1 FastEthernet port and 1 Ethernet port, automatically used)
Note, interfaces do not use a slot designation (e.g. “f0”)
1720
Note, interfaces do not use a slot designation (e.g. “f0”)
1721
Note, interfaces do not use a slot designation (e.g. “f0”)
1750
Note, interfaces do not use a slot designation (e.g. “f0”)
1751
1760
Slots: 0 (available)
WIC slots: 2
C1700-MB-1ETH (1 FastEthernet port, automatically used)
Cards:
- WIC-1T (1 Serial port)
- WIC-2T (2 Serial ports)
- WIC-1ENET (1 Ethernet ports)
===========2600s===========
2610
Slots: 1 (available)
WIC slots: 3
CISCO2600-MB-1E (1 Ethernet port, automatically used)
2611
Slots: 1 (available)
WIC slots: 3
CISCO2600-MB-2E (2 Ethernet ports, automatically used)
2620
Slots: 1 (available)
WIC slots: 3
CISCO2600-MB-1FE (1 FastEthernet port, automatically used)
2621
Slots: 1 (available)
WIC slots: 3
CISCO2600-MB-2FE (2 FastEthernet ports, automatically used)
2610XM
Slots: 1 (available)
WIC slots: 3
CISCO2600-MB-1FE (1 FastEthernet port, automatically used)
2611XM
Slots: 1 (available)
WIC slots: 3
CISCO2600-MB-2FE (2 FastEthernet ports, automatically used)
2620XM
Slots: 1 (available)
WIC slots: 3
CISCO2600-MB-1FE (1 FastEthernet port, automatically used)
2621XM
Slots: 1 (available)
WIC slots: 3
CISCO2600-MB-2FE (2 FastEthernet ports, automatically used)
2650XM
Slots: 1 (available)
WIC slots: 3
CISCO2600-MB-1FE (1 FastEthernet port, automatically used)
2651XM
Slots: 1 (available)
WIC slots: 3
CISCO2600-MB-2FE (2 FastEthernet ports, automatically used)
Cards:
- NM-1E (Ethernet, 1 port)
- NM-4E (Ethernet, 4 ports)
- NM-1FE-TX (FastEthernet, 1 port)
- NM-16ESW (Ethernet switch module, 16 ports)
- NM-NAM
- NM-IDS
- WIC-1T (1 Serial port)
- WIC-2T (2 Serial ports)
===========3600s===========
3660
Slots: 6 (available)
3640
Slots: 4
3620
Slots: 2
Cards:
- NM-1E (Ethernet, 1 port)
- NM-4E (Ethernet, 4 ports)
- NM-1FE-TX (FastEthernet, 1 port)
- NM-16ESW (Ethernet switch module, 16 ports)
- NM-4T (Serial, 4 ports)
- Leopard-2FE (Cisco 3660 FastEthernet in slot 0, automatically used)
===========3700s===========
2691 (The 2691 is essentially a 3700 with 1 slot)
Slots: 1 (available)
WIC slots: 3
3725
Slots: 2 (available)
WIC slots: 3
3745
Slots: 4 (available)
WIC slots: 3
Cards:
- NM-1FE-TX (FastEthernet, 1 port)
- NM-4T (Serial, 4 ports)
- NM-16ESW (Ethernet switch module, 16 ports)
- GT96100-FE (2 integrated ports, automatically used)
- NM-NAM
- NM-IDS
- WIC-1T (1 Serial port)
- WIC-2T (2 Serial ports)
===========7200s===========
7206
Slots: 6 (available)
Chassis types:
- STD
- VXR
NPEs:
- NPE-100
- NPE-150
- NPE-175
- NPE-200
- NPE-225
- NPE-300
- NPE-400
- NPE-G2 (Requires the use of NPE-G2 IOS images)
Cards:
- C7200-IO-FE (FastEthernet, slot 0 only)
- C7200-IO-2FE (FastEthernet, 2 ports, slot 0 only)
- C7200-IO-GE-E (GigabitEthernet interface only, Ethernet not currently functional, slot 0 only)
- PA-FE-TX (FastEthernet)
- PA-2FE-TX (FastEthernet, 2 ports)
- PA-4E (Ethernet, 4 ports)
- PA-8E (Ethernet, 8 ports)
- PA-4T+ (Serial, 4 ports)
- PA-8T (Serial, 8 ports)
- PA-A1 (ATM)
- PA-POS-OC3 (POS)
- PA-GE (GigabitEthernet)
FAQs
How do I determine idle pc values from Dynagen?
Currently, you don’t. Now you can! See the “Calculating Idle-PC” values section in this tutorial.
When I try to run more than 4 router instances @ 256 MB each (or 6 instances @ 160 MB each) on Windows, or more than 7 instances @ 256 MB each (or 11 instances @ 160 MB each) on 32-bit Linux Dynamips crashes.
By default, Windows has a 2 GB per process limit that (after including the memory used by the virtual router RAM, cygwin, libraries, and ‘scratch space”) you are bumping up against. 32-bit Linux has a 3 GB per process limit by default.
One workaround for this problem is to use the sparsemem option.
Another is to run multiple instances of Dynamips on the same system listening on different control ports like so:
On Windows:
start /belownormal /min "Dynamips" "dynamips.exe" -H 7200
start /belownormal /min "Dynamips" "dynamips.exe" -H 7201
On Linux/Unix:
nice dynamips –H 7200 &
nice dynamips –H 7201 &
The only issue is that the UDP NIOs that Dynagen picks to make the various connections will “collide” because Dynagen thinks they are different servers and therefore those UDP ports safe to re-use. The workaround is to use the new “udp” option to change the starting UDP port for NIOs on one of the servers. So the relevant sections would look something like this:
[localhost] # Talk to the 1st dynamips process on the default port 7200
[[7200]]
…
[[ROUTER R1]]
f0/0 = R2 f0/0
[localhost:7201] # Talk to the 2nd dynamips process on port 7201
udp = 11000 # Change the base udp port to 11000 (the default is 10000)
[[7200]]
…
[[ROUTER R2]]
I have a complex lab with several routers, and my serial interfaces are flapping, eigrp neighbor adjacencies are failing, show run and write mem takes forever.
This is most likely a performance issue with the host PC. Large labs consume lots of RAM and CPU. By default, the router’s DRAM is simulated as a disk file of the same size as the allocated RAM. The host OS’s caching features will naturally try to keep the most commonly access pages in RAM. But as your RAM runs low, disk thrashing will begin. The virtual routers then become “starved” for CPU and start missing various hellos and such. There are several options for resolving this:
* Use a more powerful host (more RAM and / or a faster CPU)
* Distribute your lab across several hosts
* Use lower-end virtual routers where possible. For example, a 3620 running 12.2 IP base only needs 32 MB of RAM and could be used when you need to simulate a simple LAN router, or “the Internet”.
There is a newer version of Dynamips available than the one bundled with the Dynagen Windows installer. How do I use it with Dynagen? / How do I use Dynagen with Windows 2000 or Windows XP SP1?
The version of Dynamips included with the Windows Dynagen installer requires Windows XP SP2. In either of the above cases, download the Windows binaries from the Dynamips site (http://www.ipflow.utc.fr/blog/). For Windows XP / 2003 rename the file “dynamips-wxp.exe” to “dynamips.exe”. For Windows 2000, use the file “dynamips-w2000.exe” instead. Then copy both “dynamips.exe” and “cygwin1.dll” to “C:\Program Files\Dynamips”, replacing the existing files.
On Linux / Unix / OS X, when I bridge a router or switch interface to my local host I can’t ping it from my host. But this works on Windows? What gives?
This does generally work on Windows (depending on your network card) but not on Linux / Unix. Most likely this is due to differences between libpcap and Winpcap, and the differences in the network stacks on Unix / Windows (e.g. NDIS). However you should be able to ping your bridged interfaces from other systems on the bridged network. If this does not work on Windows for your particular NIC, try creating a Windows loopback adapter and bridging to that. See this thread for more info. On Linux you can use a tap interface and the NIO_tap NIO type. OS X you can install tun/tap drivers as detailed in this thread.
I have a question / I’m having a problem / I think I’ve found a bug. How do I submit a quality post on the forum or the bug tracking system thereby increasing the likelihood that someone will be able to help me out?
Be sure to note all the following in your post:
* The specific details of your issue
* Try to provide the simplest lab you can that recreates the issue
* Add “debug = 1” to your lab, and capture all output if you think debug output would be helpfull
* Dynagen crash traceback (if any)
* Any output from Dynamips
