4.2 Connection Types

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 4.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 4.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 4.3.1.

Note: 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).

Figure 2. Comparison of real-network connections

	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 2 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.