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`
p_w_picpath = /opt/3660-p_w_picpaths/c3660-ik9o3s-mz.122-15.T17.p_w_picpath
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
PIX Emulation
PIX emulation was added with Dynagen 0.11.0, thanks to the PEMU emulator by Milen Svobodnikov, and Pemuwrapper by Thomas Pani. To add a firewall to your lab, first you must launch the Pemu Server. On Windows, use the “Pemu Server” shortcut on the desktop and in the Start menu. On Linux, use the “pemu-start.sh” script.
In your network file, define the connection to the pemu server and the firewall as shown here:
[localhost]
`7200`
p_w_picpath = \Program Files\Dynamips\p_w_picpaths\C7200-jk9s-mz.124-12.bin
ram = 160
npe = npe-400
`router R1`
e1/0 = FW1 e0
[pemu localhost]
`525`
p_w_picpath = \Program Files\Dynamips\p_w_picpaths\pix802.bin
serial = 0x12345678
key = 0x00000000,0x00000000,0x00000000,0x00000000
`fw FW1`
This .net file specifies the Pemuwrapper instance as running on “localhost”. It could be running also on another computer, creating a distributed lab. Then, specify the 525 section (signifying the PIX 525 that PEMU emulates) and set the defaults that will apply to all firewall instances on this PEMU server. Here you can set the “p_w_picpath”, ”key”, ”serial” and “ram” options. The [FW1] line creates the PIX 525 instance; whose Ethernet0 interface is connected to R1’s e1/0 interface (specified in router R1’s config).
This run the lab and you can list PEMU instances using the 'list' command:
=> list
Name Type State Server Console
R1 7200 stopped localhost:7200 2000
FW1 525 stopped localhost:10525 4000
PEMU firewalls can be stopped, started, reloaded, and of course you can attach to the console just like a virtual router. However, the following commands are not supported on PEMU firewalls:
import / export
suspend / resume
capture / filter (on firewall interfaces. You can instead capture on the “dynamips” side of the connection)
cpuinfo
copy / push
The following caveats apply to PEMU:
Currently, PEMU server only runs on Windows and Linux hosts (not OS X,). However Dynagen running on any platform can be used to communicate with a PEMU server running on a Linux or Windows host.
There is no concept of “idlepc” for PEMU; each PEMU device will consume 100% of a core. However the process does run at a low priority. You can choose to limit CPU consumption with a 3rd party tool like BES (on Windows) or cpulimit on Windows.
Dynagen does not currently support connecting PIX interfaces to NIOs (for example “e1 = NIO_gen_eth:eth0”). To get around this, bridge the connection with a virtual Ethernet switch like so:
[localhost]
`ethsw sw1`
1 = access 1
2 = access 1 NIO_gen_eth:eth0
[pemu localhost]
e1 = sw1 1
See the “pix” sample lab (in the sample_labs directory) for a more detailed example of utilizing emulated PIX firewalls in your labs.
Dynamic Configuration Mode
Because Dynagen has merged in Pavel Skovajsa’s confDynagen fork, version 0.11.0 now supports confDynagen’s Dynamic Configuration Mode. This significant enhancement allows you to dynamically change your lab by editing the .net config "on the fly" without needing to exit Dynagen or even stop running devices. You can add/change/remove all lab/router options that are available in the .net files without restarting your lab. You can also add/change/remove hypervisors without restarting your lab.
Dynagen now supports running without specifying a NET file to load This runs Dynagen with empty lab, and you are able to create the new lab with confDynagen's configuration mode. This is rather clumsy when creating a big lab from scratch - however it could be done. The following example uses this option in order to illustrate as many of the options as possible. Instead, you will typically define the network in your NET file, and then use the Dynamic Configuration Mode to “tweak” the lab.
In the following example, input and output of Dynagen is shown in blue, along with comments inline:
=> conf localhost
Hypervisor on localhost:7200 created
This command added the hypervisor running on localhost:7200 to the lab, which will attempt to connect to a Dynamips server running on port 7200 on localhost. Explicitly specifying 7200 here is technically not needed, as it is the default port.
=>(config-localhost:7200)help
Documented commands (type help <topic>):
========================================
2691 3640 3725 7200 help no router
3620 3660 3745 exit hist py workingdir
Use of the “conf” command caused us to enter config mode (which should be familiar to Cisco IOS users). Above, the “help” command shows us a list of the options available in hypervisor config mode.
=>(config-localhost:7200)7200
This enters what would be the `7200` section of the .NET file, where default options for 7200 routers are set. Minimum setting is the IOS p_w_picpath path.
=>(config-localhost:7200-7200)help
Documented commands (type help <topic>):
=======================================
cnfg disk0 exit help idlemax idlesleep midplane npe py slot
confreg disk1 ghostios hist idlepc p_w_picpath no nvram ram
Here the “defaults” configuration mode options are shown, which include all the options that can be set in the device defaults section of a NET file.
=>(config-localhost:7200-7200)p_w_picpath = C:\IOS\C7200-jk9s-mz.124-12.bin
C7200-jk9s-mz.124-12.bin found in user idlepc database
Setting idlepc value to 0x60654b68
Here the IOS p_w_picpath is set, and the idlepc value is automatically plucked from the idlepc database previously configured on this system.
=>(config-localhost:7200-7200)npe
npe = <npe type>
set NPE type. Choose "npe-100", "npe-150", "npe-175", "npe-200", "npe-225", "npe-300" or "npe-400"
=>(config-localhost:7200-7200)npe = npe-400
=>(config-localhost:7200-7200)exit
Exiting...
=>(config-localhost:7200)router R1
Router R1 created
The “router <router_name> <model>” command creates a new router with specified model and name. All options set under model default config get applied to the router. The default model is 7200, so we could use command 'router R1' instead of 'router R1 model 7200' (which will work too). This will drop you into router config mode.
=>(config-localhost:7200-router R1)exit
Exiting...
=>(config-localhost:7200)router R2
Router R2 created
=>(config-localhost:7200-router R2)help
Documented commands (type help <topic>):
========================================
a confreg e f help idlepc midplane nvram py se
at disk0 et fa hist idlesleep no p ram slot
cnfg disk1 exit ghostios idlemax p_w_picpath npe po s
In the router config mode we can set specific options like (midplane, nvram size, disk0 size etc.) for this specific router. The 'a', 'f', 'e' commands are for creating connections between routers.
=>(config-localhost:7200-router R2)f0/0 = R1 f0/0
Here is an example of creating a connection to another router’s interface. The syntax is the same as used in NET files. Syntax for disconnecting this connection would “no f0/0 = R1 f0/0”. Any option that has been previously set can be removed by using the “no” version of the command.
=>(config-localhost:7200-router R2)exit
Exiting...
=>(config-localhost:7200)exit
Exiting...
=> show run
autostart = False
[localhost:7200]
`7200`
npe = npe-400
p_w_picpath = C:\IOS\C7200-jk9s-mz.124-12.bin
idlepc = 0x60654b68
`ROUTER R1`
model = 7200
F0/0 = R2 F0/0
`ROUTER R2`
model = 7200
F0/0 = R1 F0/0
The “show run” command displays the running configuration of current lab in the NET file format.
=> start /all
100-C7200 'R1' started
100-C7200 'R2' started
We start our routers to begin the simulation. At this point you can console to the devices and start configuring.
=> conf localhost
After the devices are started we can still go into config mode and add/change/remove stuff. The changes are reflected on the routers either immediately, or after router reload depends on the type of option changed, and the type of device.
=>(config-localhost:7200)router R1
If router R1 already exists (as it does in this case) we are placed into the router config mode where we can add/change/remove any router option.
=>(config-localhost:7200-router R1)f1/0 = R2 f2/0
Here we add a new connection on the fly. As you can see in the 'show run' output above there is no adapter card in slot 1 in our 7206. This command will virtually insert the card (PA-FE-TX in this example) into slot1 and create the connection between both routers. This will be seen on the router as an OIR (online insertion removal) event:
%OIR-6-INSCARD: Card inserted in slot 1, interfaces administratively shut down
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0, changed state to down
%ENTITY_ALARM-6-INFO: ASSERT INFO Fa1/0 Physical Port Administrative State Down
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0, changed state to down
The only router that Dynamips emulates that supports OIR is the 7206. However you can still create/delete connections between other classes of routers provided that the network modules were inserted before the router was started.
=>(config-localhost:7200-router R1)exit
Exiting...
=>(config-localhost:7200)exit
Exiting...
=> show run
autostart = False
[localhost:7200]
`7200`
npe = npe-400
p_w_picpath = C:\IOS\C7200-jk9s-mz.124-12.bin
idlepc = 0x60654b68
`ROUTER R1`
model = 7200
F0/0 = R2 F0/0
slot1 = PA-FE-TX
F1/0 = R2 F2/0
`ROUTER R2`
model = 7200
F0/0 = R1 F0/0
slot2 = PA-FE-TX
F2/0 = R1 F1/0
The “show run” output reflects the change.
=> copy run start
After making your changes you can save it back into the .NET file. This will also save the NVRAM config into from the routers into the NET file under 'configuration' option, (just as a 'save /all' command does).
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`
p_w_picpath = \PROGRA~1\Dynamips\p_w_picpaths\c7200-ik9o3s-mz.122-15.T17.p_w_picpath
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`
p_w_picpath = /opt/7200-p_w_picpaths/c7200-ik9o3s-mz.122-15.T17.p_w_picpath
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 p_w_picpath. 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 p_w_picpath, and that p_w_picpath 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 p_w_picpath.
When enabled, you will notice additional files in the same directory as you router nvram files with names like “c3660-ik9o3s-mz.124-10.p_w_picpath.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`
p_w_picpath = \Program Files\Dynamips\p_w_picpaths\c3660-ik9o3s-mz.124-10.p_w_picpath
`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`
p_w_picpath = \Program Files\Dynamips\p_w_picpaths\c3660-ik9o3s-mz.124-10.p_w_picpath
`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 p_w_picpaths)
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 &
Then use a multiserver config, but specify that both servers are on “localhost” but with the 2nd one on port 7201:
[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
`7200`
…
`ROUTER R2`
Note that as of 0.11.0 manually changing the UDP port for connections on the 2nd instance is no longer needed. Dynagen now takes care of this automatically.
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
转载于:https://blog.51cto.com/hb12052/392449
扫一扫
271
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
