There are three kinds of connections between simulated networks and real networks in Simics. The next paragraphs describe how they work, and their advantages and drawbacks.
All connection types except port forwarding require low-level access to the simulation host's Ethernet interfaces, and therefore require administrative privileges to set up. However, administrative privileges are, in most cases, not needed once the low-level access has been set up. See section 3.3 for details.
Port forwarding Port forwarding is the easiest connection type to set up for simple usage. It does not require administrative privileges nor any configuration on the simulation host or on the other hosts.
However, port forwarding is limited to TCP and UDP traffic. Other traffic, for example, ping packets that use the ICMP protocol, will not pass through the connection. Since port forwarding uses ports on the simulation host it is not possible to use incoming ports that are already used by the simulation host, or ports below 1024 without administrative privileges.
Each incoming TCP port, and each incoming or outgoing UDP port require a separate forwarding rule. Therefore, for an application that uses many ports, or random ports, configuration can become cumbersome or nearly impossible without complex communication. Outgoing TCP connections on many or random ports can be handled by NAPT, so that is not a problem.
Port forwarding allows communication between the simulated machines, the simulation host and other hosts on the real network.
Ethernet bridging connection With an Ethernet bridging connection, the simulated machines appears to be directly connected to the real network. The connection allows any kind of Ethernet traffic between the simulated and real networks. Usually IP addresses from the IP subnet of the real network are used by the simulated machines, in which case nothing needs to be configured on the real hosts on the real network. However, the simulation host can not be accessed from the simulated machines using an Ethernet bridging connection.
To use Ethernet bridging, the simulation host needs to be set up for TAP access as described in section 3.3.
Host connection With a host connection, the simulation host is connected to a simulated network, allowing any kind of Ethernet traffic between the simulation host and the simulated machines.
Host connections also supports IP forwarding. When using IP forwarding, the operating system of the host routes IP traffic between the real and simulated networks. As above, routes should be configured between the simulated and real networks to make it work.
To use host connections, the host needs to be set up for TAP access as described in section 3.3.1.
A raw packet with length X bytes sent from the simulation host through the real network device into the simulated target will have 4 Bytes of FCS(frame check sequence) appended. The target machine will actually receive a packet of length X+4 bytes. The NIC model on the target machine usually checks and strips the FCS bytes before it is seen by any software. A raw packet that originates from the target will have an FCS calculated and appended by the NIC model. The real network device will then check the FCS and strip it before sending to the simulation host interface (TAP interface).
| Port Forwarding | Ethernet Bridge | Host Connection | |
|---|---|---|---|
| Need admin rights for config. | no | yes | yes |
| Need admin rights to run | no | no | no |
| Need real IP available | no | yes | no |
| Support UDP/TCP | yes | yes | yes |
| Restrict TCP/UDP ports | yes | no | no |
| Support all IPv4 | no | yes | yes |
| Support all Ethernet | no | yes | yes |
The table 1 recapitulates the advantages and drawbacks of each type of connection. Basically, for simple TCP services like FTP, HTTP or telnet, port forwarding is the way to go. If port forwarding does not suffice and if there are available IP addresses on the IP subnet of the real network, or for network protocols other than IPv4, Ethernet bridging is another possibility. Finally, if access to the simulated machines from the simulation host is required, but port forwarding is not sufficient, host connection might be the solution.
All commands that create a connection to the real network start with the prefix connect-real-network-, with different suffixes depending on the connection type. They come in two variants.
For each connection type there is a global command that assumes that there is at most one Ethernet link object. If there is no Ethernet link object, a default ethernet_switch is created. All Ethernet interfaces of all simulated machines in the Simics process are then automatically connected to the new Ethernet switch, and the Ethernet switch is connected to the real network. This is an easy way to connect all simulated machines in the Simics process to the real network with a single command. For example, to connect all simulated machines to the real network using an Ethernet bridging connection, just type in the global command connect-real-network-bridge.
For a more complex simulated network setup, not all simulated Ethernet interfaces will be connected to the same network. In that case, create first the simulated network setup, and then connect specific Ethernet links to the real network. For each connection type, there is a command with the same name as the global command that can be run on a specific Ethernet link object to connect it to the real network. For example, with an Ethernet link object named ethernet_hub0, use the command ethernet_hub0.connect-real-network-bridge to create an Ethernet bridging connection between that particular link and the real network.
The commands related to port forwarding are an exception to this rule. They do not come in variants that can be run on Ethernet links objects, but instead have an ethernet-link argument that can be used to specify a link.
Port forwarding forwards traffic on TCP and UDP ports between the simulated network and the real network. It also allows forwarding DNS queries from the simulated network to the real network. Port forwarding can be used with any kind of IP network on the host, it is not limited to Ethernet networks.
Port forwarding is probably the easiest way to access the real network for simple TCP or UDP connectivity, for example, telnet or FTP usage. Port forwarding is easy to set up. Simics does not need administrative privileges to run port forwarding, and neither the simulation host nor any other host needs to be configured in any way.
Port forwarding is managed by a service node connected to an Ethernet link. It is the service node that listens for traffic on both the real and simulated networks and forwards it to the other side. All port forwarding commands except connect-real-network therefore take as argument an Ethernet link with a connected service node.
There are really four distinct parts to Simics's port forwarding solution: forwarding of specific ports from the real network to the simulated network, forwarding of specific ports from the simulated network to the real network, NAPT from the simulated network to the real network, and forwarding of DNS queries to the real network.
There is also a convenience command named connect-real-network that automatically sets up NAPT for outgoing traffic, forwarding of DNS queries to the real network, and incoming port forwarding for some common services. If there is no Ethernet link object, one is created and set up.
The list-port-forwarding-setup command describes the current port forwarding setup: it will list all incoming and outgoing ports, as well as the NAPT and DNS forwarding status.
Pinging between the simulated network and the real network will not work when using port forwarding, so ping should not be used to test if the connection is working. Ping uses the ICMP protocol, but only TCP and UDP traffic is supported with port forwarding.
The connect-real-network command is a convenience command that sets up NAPT for outgoing traffic, enables forwarding of DNS queries to the real network, and opens incoming ports for FTP, HTTP and telnet to a simulated machine. This is an easy way to get inbound and outbound access for common services on a simulated machine.
The command requires a target-ip argument that specifies the IP address of the simulated machine that should be targeted by the incoming traffic. If there are multiple simulated machines, connect-real-network can be run once for each machine. Simics will select different ports on the simulation host for the incoming services for each simulated machine, and the selected ports are printed in the Simics console.
The connect-real-network command does not require an Ethernet link as argument, unless there is more than one in the simulation. If there is no Ethernet link or service node, they will be created automatically.
The connect-real-network allows us to set up all connections that are needed for most simple real network uses with one simple command. We can start from the checkpoint prepared in section 3.1, and then run the connect-real-network command with the IP address 10.10.0.40, which is the default address of QSP-x86:
simics> connect-real-network 10.10.0.40
No Ethernet link found, created default_eth_switch0.
Connected board.mb.sb.eth_slot to default_eth_switch0
Created instantiated 'service_node_comp' component 'default_service_node0'
Connecting 'default_service_node0' to 'default_eth_switch0' as 10.10.0.1
NAPT enabled with gateway 10.10.0.1/24 on link default_eth_switch0.link.
NAPT enabled with gateway fe80::2220:20ff:fe20:2000/64 on link default_eth_switch0.link.
Host TCP port 4021 -> 10.10.0.40:21
Host TCP port 4022 -> 10.10.0.40:22
Host TCP port 4023 -> 10.10.0.40:23
Host TCP port 4080 -> 10.10.0.40:80
Real DNS enabled at 10.10.0.1/24 on link default_eth_switch0.link.
Real DNS enabled at fe80::2220:20ff:fe20:2000/64 on link default_eth_switch0.link.
The output shows that an ethernet_switch and a service_node_comp components have been automatically created and connected to the simulated machine. NAPT, DNS forwarding, and incoming port forwarding for FTP, HTTP and telnet have also been enabled.
Now start the simulation. Since we gave the service node the IP address 10.10.0.1, QSP-x86 should be configured with 10.10.0.1 as default gateway:
~# route add default gw 10.10.0.1
It should now be possible to telnet from the simulated machine to hosts on the real network. In this case, we telnet to a machine with IP address 10.0.0.240; replace this address with any host answering to telnet on the network:
~# telnet 10.0.0.240
Trying 10.0.0.240...
Connected to 10.0.0.240.
Escape character is '^]'.
SunOS 5.9
login: joe
Password:
Sun Microsystems Inc. SunOS 5.9 Generic May 2002
$ exit
Connection closed by foreign host.
~#
QSP-x86 can be configured to use the service node as DNS server and use it to look up real DNS names. To do that, add the line nameserver 10.10.0.1 in the file /etc/resolv.conf on the simulated machine:
~# echo nameserver 10.10.0.1 > /etc/resolv.conf
It should now be possible to look up the addresses of real hosts on the simulated machine, for example, https://gnu.org. QSP-x86 does not have the tools to perform DNS lookups. Instead, verify that DNS works by connecting to a real server by name:
~# telnet gnu.org 80
GET /
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<title>Server error!</title>
[...]
Connection closed by foreign host.
~#
FTP, HTTP and telnet servers running on the simulated machine should also be accessible. QSP-x86 runs both a telnet and a HTTP server. Just use port 4023 and 4080 instead of 23 and 80. The exact ports of the host these services are mapped to varies if the default ports are already in use. Look at the output from the connect-real-network above for the port numbers to use.
The connect-real-network-port-in command sets up port forwarding from a port on the host machine to a specific port on a simulated machine. It takes three required arguments: ethernet-link, target-ip and target-port, that specify the Ethernet link, IP address and port the traffic should be forwarded to.
An IP address and preferred port can be selected for incoming traffic on the simulation host using the host-ip and host-port arguments. If these arguments are not provided, Simics will select a port automatically and print it on the Simics console, and receive all IPv4 traffic (i.e., IP 0.0.0.0) from that port. In order to forward multicast traffic, specify that multicast address (e.g., specify 239.255.255.253 to forward IPv4 SLP traffic).
The connect-real-network-port-in command can also take the flags -tcp and -udp, which specify whether forwarding is set up for a TCP or a UDP port. If neither is provided, forwarding will be set up for both the TCP and UDP ports. Also, with the optional -preserve-ip flag, the source IP is preserved through a NAT layer (for TCP only).
The service node acts as a proxy for incoming traffic, so to initiate a connection to a specific port on the simulated machine, the real machine should contact the corresponding open port on the simulation host. The simulation host is not a gateway to the simulated network.
Any UDP packets sent to a port on the simulation host are forwarded to the specified port and IP address on the simulated network. For the simulated machine to be able to return UDP packets to the real network, a separate forwarding rule must be set up using the connect-real-network-port-out command.
Any TCP connections to the port on the simulation host are forwarded to the specified port and IP address on the simulated network. Since TCP connections are two-ways, once a connection has been established, data can be sent in both directions.
You will probably have to manually add the incoming ports to your host based software firewall if you want to access the simulated network from another machine. Tracking down network problems when you forget to update the firewall is annoying as the packets tend to get dropped silently without a log.
The FTP protocol needs to open additional ports when transferring files. Simics handles this by automatically opening outgoing ports for FTP when needed, so FTP will work as long as it is in active mode.
QSP-x86 runs sshd on port 22. We can now set up a port forwarding rule that allows us to access the ssh service from the real network. Start from the checkpoint, create an Ethernet link and service node, connect the simulated machine to the Ethernet link and run the connect-real-network-port-in command like this:
simics> load-module eth-links
simics> new-ethernet-switch switch0
Created instantiated 'ethernet_switch' component 'switch0'
simics> new-service-node-comp sn0
Created instantiated 'service_node_comp' component 'sn0'
simics> sn0.connect-to-link switch0 10.10.0.1
Adding host info for IP 10.10.0.1: simics0.network.sim MAC: 20:20:20:20:20:00
simics> connect board.mb.sb.eth_slot switch0.device1
simics> connect-real-network-port-in ethernet-link = switch0 target-ip = 10.10.0.40 target-port = 22 host-port = 2022 -tcp
Host TCP port 2022 -> 10.10.0.40:22
simics> enable-real-time-mode
QSP-x86 uses the IP address 10.10.0.40 and the ssh service runs on TCP port 22. We use port 2022 on the simulation host, but any free port can be used. The last command slows down QSP-x86 to avoid time-outs.
Start the simulation, then start a ssh from a real host to the ssh service port of the simulated machine by connecting to port 2022 of the simulation host. In our case, we do the ssh on the simulation host itself; replace localhost with the IP address of the simulation host if running ssh from another machine:
host:~$ ssh -p 2022 -l root localhost
The authenticity of host '[localhost]:2022 ([127.0.0.1]:2022)' can't be established.
ECDSA key fingerprint is 62:7e:eb:4d:6d:cb:ae:0f:a0:a9:44:cc:0d:59:ce:52.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[localhost]:2022' (ECDSA) to the list of known hosts.
Last login: Mon Jan 18 10:34:08 2016
~# ls /
bin boot dev disk2 etc home host lib lib64 lost+found media mnt proc run sbin sys tmp usr var www
~# exit
logout
Connection to localhost closed.
Note that if you restart the simulated machine, you need to remove the line starting with '[localhost]:2022' in host file ~/.ssh/known_hosts to login with ssh again.
The connect-real-network-port-out command sets up port forwarding from a port on a service node to a specific port on a host on the real network. It takes four required arguments: service-node-port ethernet-link, target-ip and target-port, that specify the port on the service node that will forward traffic to the target, the Ethernet link the service node is connected to, and the real IP address and port to which the traffic should be forwarded.
The command can optionally take the flags -tcp and -udp, to specify whether the forwarding should be set up for a TCP or UDP port. If neither is provided, forwarding will be set up for both the TCP and UDP port.
The service node acts as a proxy for outgoing traffic, so to initiate a connection to a port on a host on the real network, the simulated machine should connect to the corresponding mapped port on the service node. The service node is not a gateway to the real network.
Any UDP packets sent to a port on the service node are forwarded to the specified port and IP address on the real network. For the real host to be able to return UDP packets to the simulated network, a separate forwarding rule must be set up using the connect-real-network-port-in command.
Any TCP connections to the port on the service node are forwarded to the specified port and IP address on the real network. Since TCP connections are two-ways, once a connection has been established data can be sent in both directions.
By setting up forwarding from a port on a service node to port 22 of a host on the real network, it should be possible to ssh to the real host by connecting to the port on the service node from QSP-x86. We can start from the checkpoint we prepared in section 3.1, and create an Ethernet link and a service node, connect the simulated machine to the Ethernet link and run the connect-real-network-port-out command. Here we use a host on the real network with IP address 10.0.0.240, replace it with the IP address of a real host on the network:
simics> load-module eth-links
simics> new-ethernet-switch switch0
Created instantiated 'ethernet_switch' component 'switch0'
simics> new-service-node-comp sn0
Created instantiated 'service_node_comp' component 'sn0'
simics> sn0.connect-to-link switch0 10.10.0.1
Adding host info for IP 10.10.0.1: simics0.network.sim MAC: 20:20:20:20:20:00
simics> connect board.mb.sb.eth_slot switch0.device1
simics> connect-real-network-port-out service-node-port = 2222 ethernet-link = switch0 target-ip = 10.0.0.240 target-port = 22 -tcp
10.10.0.1 TCP port 2222 on link switch0.link -> host 10.0.0.240:22
ff02::1:2 TCP port 2222 on link switch0.link -> host 10.0.0.240:22
simics> enable-real-time-mode
Now start the simulation. We used the IP address 10.10.0.1 and the port 2222 for the service node, so we should be able to ssh to the real host by connecting to port 2222 of 10.10.0.1 from QSP-x86:
~# ssh 10.10.0.1 -p 2222
The authenticity of host '[10.10.0.1]:2222 ([10.10.0.1]:2222)' can't be established.
ECDSA key fingerprint is 39:a4:cb:1c:54:4b:bd:86:9f:d1:1b:6d:a6:43:e9:f4.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[10.10.0.1]:2222' (ECDSA) to the list of known hosts.
10.10.0.1's password:
Last login: Thu May 19 09:59:33 2016 from 127.0.0.1
host:~$ ls /
bin dev home lib64 media opt root sbin sys usr
boot etc lib lost+found mnt proc run srv tmp var
The connect-real-network-napt command sets up NAPT (network address port translation, also known as just NAT or network address translation) between the simulated network and the real network. With NAPT enabled, the service node will act as a gateway on the simulated network and automatically mediate TCP connections to the real network.
The connect-real-network-napt only has one required argument, ethernet-link, that specifies the Ethernet link that should be connected to the real network.
The simulated machines must be configured to use the service node as gateway for the real network, so that it is able to capture the outgoing traffic. The simulated machines will then be able to access hosts on the real network using their real IP addresses. By combining NAPT with DNS forwarding, described in section 3.2.1.5, the real DNS names of hosts on the real network can be used as well.
The NAPT setup is not specific to a simulated machine, so connect-real-network-napt needs only to run once for each Ethernet link, and all simulated machines on the link get outbound access.
Since NAPT only allows new TCP connections to be opened from the simulated network to the real network, and the FTP protocol need to open new ports when transferring files, passive mode FTP should be used when connecting to an FTP server on a host on the real network from a simulated machine. An alternative is to use the FTP server implemented in the Simics service-node and avoid the need to connect to a real network.
To try NAPT, we can start from the checkpoint we prepared in section 3.1, create an Ethernet link and service node, connect the simulated machine to the Ethernet link and run the connect-real-network-napt command like this:
simics> load-module eth-links
simics> new-ethernet-switch switch0
Created instantiated 'ethernet_switch' component 'switch0'
simics> new-service-node-comp sn0
Created instantiated 'service_node_comp' component 'sn0'
simics> sn0.connect-to-link switch0 10.10.0.1
Adding host info for IP 10.10.0.1: simics0.network.sim MAC: 20:20:20:20:20:00
simics> connect board.mb.sb.eth_slot switch0.device1
simics> connect-real-network-napt ethernet-link = switch0
NAPT enabled with gateway 10.10.0.1 on link switch0.link
NAPT enabled with gateway fe80::2220:20ff:fe20:2000/16 on link switch0.link
simics> enable-real-time-mode
The simulated machine should be configured to use the service node as its default gateway:
~# route add default gw 10.10.0.1
The enable-real-dns and disable-real-dns commands of the service node enable and disable forwarding of DNS requests to the real network by a service node. This allows simulated machines to look up names and IP addresses of hosts on the real network, using the service node as DNS server.
To try DNS forwarding, we can start from the checkpoint we prepared in section 3.1, and create an Ethernet link and a service node, connect the simulated machine to the Ethernet link and run the enable-real-dns command like this:
simics> load-module eth-links
simics> new-ethernet-switch switch0
Created instantiated 'ethernet_switch' component 'switch0'
simics> new-service-node-comp sn0
Created instantiated 'service_node_comp' component 'sn0'
simics> sn0.connect-to-link switch0 10.10.0.1
Adding host info for IP 10.10.0.1: simics0.network.sim MAC: 20:20:20:20:20:00
simics> connect board.mb.sb.eth_slot switch0.device1
simics> sn0.enable-real-dns
Real DNS enabled
simics> enable-real-time-mode
To tell QSP-x86 to use the service node as DNS server, the line nameserver 10.10.0.1 is needed in the file /etc/resolv.conf:
~# echo nameserver 10.10.0.1 > /etc/resolv.conf
Simics can act as a bridge between simulated Ethernet networks and the real Ethernet networks of the host. With this type of connection, the simulated machines will appear as directly connected to the real network, both to the simulated machines and to the hosts on the real network. For that reason, the simulated machines should be configured with IP addresses from the same subnet as the real hosts.
Since the simulated machines appear to be located on the real network, there is no need to configure routes on real hosts that communicate with it. They can find the simulated machines by sending ARP requests, just like they would find other real hosts.
When using a bridged connection, it is recommended to use a dedicated host network interface for the bridge, not the interface that the host uses for general network access. Otherwise, special configuration of the bridge interface is necessary for any kind of network access for the host. The details about this configuration will not be covered in this manual. See section 3.3 for how to set up TAP access.
To create a bridged connection to the real network, use the connect-real-network-bridge command. It takes an interface argument that specifies which host TAP interface that should be used.
This example assumes that the simulation is starting from the checkpoint prepared in section 3.1, and that a TAP bridge has been set up as described in section 3.2.2.2.
To set up an Ethernet bridging connection between the real network and the simulated network, run the connect-real-network-bridge command. This will automatically create an Ethernet link, connect it to the simulated machine and set up bridging to the real network:
simics> connect-real-network-bridge
No Ethernet link found, created default_eth_switch0.
Connected board.mb.sb.eth_slot to default_eth_switch0
[rn0.rn info] Connecting to existing TAP device 'sim_tap0'
'default_eth_switch0' connected to real network.
When using Ethernet bridging, the simulated machine should be configured with an unused IP address and netmask from the real network. In this case we use 10.0.0.241 and 255.255.255.0. Replace it with an unused IP address and netmask from the real network:
~# ifconfig eth0 10.0.0.241 netmask 255.255.255.0
As the target machine will appear as a real machine in the net, its gateway and DNS server should be correctly set according to the host settings, this step can be verified through pinging the gateway and DNS server IP. In some corner conditions, it's worth trying to reset (disable and then enable) the target Ethernet adapter if the gateway or DNS server are unreachable.
The simulated machine is now connected to the real network. Any kind of IP traffic is bridged between the simulated network and the real network. It should be possible to ping any real host from the simulated machine. Replace 10.0.0.240 with the address of a host on the real network:
~# ping 10.0.0.240 -c 3
PING 10.0.0.240 (10.0.0.240): 56 data bytes
64 bytes from 10.0.0.240: seq=0 ttl=64 time=10.285 ms
64 bytes from 10.0.0.240: seq=1 ttl=64 time=0.349 ms
64 bytes from 10.0.0.240: seq=2 ttl=64 time=0.323 ms
--- 10.0.0.240 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.323/3.652/10.285 ms
Of course, it should also be possible to ping the simulated machine from the real host.
Running traceroute on the simulated machine shows that it is connected directly to the real network; there are no routers between it and the real host. Again, replace 10.0.0.240 with a host on the real network:
~# traceroute 10.0.0.240
traceroute to 10.0.0.240 (10.0.0.240), 30 hops max, 38 byte packets
1 10.0.0.240 (10.0.0.240) 10.106 ms 0.371 ms 0.347 ms
If the IP address of the simulated machine itself is printed and !H is printed after the response times, it means the simulated machine can not reach the real host, and the configuration is incorrect.
To use TAP access with the connect-real-network-bridge command, the operating system must be configured to act as a bridge between the virtual interface and the real interface. Follow the steps below to set it up.
When setting up bridging between a TAP interface and a real Ethernet interface, the host will no longer accept traffic on the real interface. All connections the host has open on the interface will be lost. One consequence of this is that if this is being done from a remote console, the connection might be lost before the bridge is fully configured. We therefore strongly recommend that bridging is only set up on dedicated host interfaces.
Create a TAP interface, as described in section 3.3.1
Create a bridge interface and connect the TAP interface and the real interface. Turn off STP (Spanning Tree Protocol) in the bridge as well, otherwise there will be STP traffic from the bridge into both the simulated and the real network. Here the name of the created bridge interface is sim_br0 and the interface used is eth1, but other names and interfaces can be used.
computer# brctl addbr sim_br0
computer# brctl addif sim_br0 sim_tap0
computer# brctl addif sim_br0 eth1
computer# brctl stp sim_br0 off
Bring up the TAP interface and the bridge interface.
computer# ifconfig sim_tap0 promisc up
computer# ifconfig sim_br0 promisc up
Bring up the Ethernet interface.
computer# ifconfig eth1 up
To remove the bridging when finished, do the following:
Bring down the TAP interface and the bridge interface.
computer# ifconfig sim_tap0 down
computer# ifconfig sim_br0 down
Delete the bridge interface.
computer# brctl delbr sim_br0
The brctl utility is usually not present in default Linux installations. It is usually included in the bridge-utils package.
Windows will now set up bridging between the OpenVPN TAP interface and the real interface. If successful both the OpenVPN TAP and real interfaces will seem to disappear as they are now contained in the new bridge interface. To undo the bridging, go to the Network Connections folder, right-click on the bridge and select Delete.
Perhaps you want to disable the spanning tree algorithm (STA). To do that you must add or edit the DisableSTA registry key to 1. Disabling STA will minimize the time to allow packages over the bridge. Rebooting Windows is required.
Windows 7 has the key at
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BridgeMP\DisableSTA while Windows 10 and later has the key at
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MsBridge\DisableSTA.
Simics can connect a simulated network to a virtual Ethernet (TAP) interface on the simulation host. The simulation host and the simulated machines will then be able to communicate as if they were connected to the same Ethernet network. For example, by configuring the simulation host with an IP address on the TAP interface, the simulation host and the simulated machines will be able to send IP traffic to each other.
Enabling IP forwarding on the host will also allow the simulated machines to access other hosts on the real network, using the host operating system's IP routing facilities. Read the instructions after the example below for instructions about how to set it up.
To connect the simulated network to the TAP interface, the TAP interface should be configured on the simulation host, as described in section 3.3.1. Use the connect-real-network-host command, which simply takes the name of the TAP interface as the interface argument. The simulation host will now appear on the simulated network. Configure the TAP interface of the host with an IP address from the same subnet as the simulated machines, and the simulated machines will be able to communicate with the host.
Simulated machine configurations provided with Simics usually use IP addresses from the 10.10.0.x subnet, so the simulation host should typically get an IP address on the form 10.10.0.x with a netmask of 255.255.255.0.
On Linux, this is configured with ifconfig, which requires administrative privileges:
computer# ifconfig sim_tap0 10.10.0.x netmask 255.255.255.0 up
On Windows, use these steps instead:
Open the Network Connections folder of the Control Panel.
Right-click on the OpenVPN TAP interface to bring up a context menu, and select Properties.
A property dialog box will open. Select Internet Protocol (TCP/IP) and click on the Properties button.
A new property dialog box will open. Select Use the following IP address and enter the IP address and Subnet mask the simulation host should use on the simulated network.
Select an IP address on the form 10.10.0.x and the netmask 255.255.255.0. The Default gateway field can typically be left blank.
Click OK in both property dialog boxes.
This example assumes that the simulation is starting from the checkpoint prepared in section 3.1, that there is a correctly set up TAP interface on the simulation host for host connection according to section 3.3.1, and that it has been configured with the IP address 10.10.0.1 as described above. Here the name if the TAP interface is assumed to be sim_tap0: replace it with the name of the TAP interface.
To connect the TAP interface to the simulated network, use the connect-real-network-host command:
simics> connect-real-network-host interface = sim_tap0
No Ethernet link found, created default_eth_switch0.
Connected board.mb.sb.eth_slot to default_eth_switch0
[rn0.rn info] Connecting to TAP device 'sim_tap0'
'default_eth_switch0' connected to real network.
On Windows, the message "Connecting to existing TUN/TAP device 'sim_tap0'" will not appear.
Any kind of Ethernet traffic can now pass between the simulated network and the simulation host. It should be possible, for example, to ping the simulation host from the simulated machine, at the IP address configured on the TAP interface:
~# ping 10.10.0.1 -c 5
PING 10.10.0.1 (10.10.0.1) from 10.10.0.40 : 56(84) bytes of data.
64 bytes from 10.10.0.1: icmp_seq=1 ttl=64 time=1.15 ms
64 bytes from 10.10.0.1: icmp_seq=2 ttl=64 time=1.11 ms
64 bytes from 10.10.0.1: icmp_seq=3 ttl=64 time=10.9 ms
64 bytes from 10.10.0.1: icmp_seq=4 ttl=64 time=1.11 ms
64 bytes from 10.10.0.1: icmp_seq=5 ttl=64 time=1.11 ms
--- 10.10.0.1 ping statistics ---
5 packets transmitted, 5 received, 0% loss, time 4037ms
rtt min/avg/max/mdev = 1.113/3.085/10.932/3.923 ms
Enabling IP forwarding on the simulation host will allow real machines to access the simulated network by routing the traffic through the simulation host. This method is called IP forwarding.
On Linux run the following command to set up ip forwarding:
computer# sysctl -w net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1
And to disable IP forwarding again:
computer# sysctl -w net.ipv4.ip_forward=0
net.ipv4.ip_forward = 0
To set it up on Windows, change the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\IPEnableRouter from 0 to 1 and reboot. If the key does not exist, create it and give it the value 1. To disable IP forwarding, reset the registry key to 0 and reboot.
For the routing to work, both the simulated machines and the machines on the real network must be configured: on the simulated machines, a route must be added to the real network with the IP address of the host's TAP interface as gateway; on the real machines, it is a route to the simulated network with the IP address of the simulation host's Ethernet interface that should be added.