There are a four different types of connections between simulated networks and real networks in Simics. Each connection type has its advantages and drawbacks, and which one you should use depends on what you want to do.
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. In most cases, however, you no longer need administrative privileges to access the real network from Simics once low-level access has been set up. See section 10.1 for details.
To help you select what type of connection to use, here is a short description of each connection type:
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 the port forwarding uses ports on the simulation host you will also not be able to use incoming ports that are already used by the simulation host, or ports below 1024 unless you have administrative privileges.
You need to set up a separate forwarding rule for each incoming TCP port and each incoming or outgoing UDP port. This means that if you are using an application that uses many ports, or random ports, the configuration will become cumbersome or impossible.
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 and both the simulations host and other hosts on the real network.
Usually IP addresses from the IP subnet of the real network are used by the simulated machines. In that case you do not have to configure the hosts on the real network in any way.
You can not access the simulation host from the simulated machines using an Ethernet bridging connection.
Since the simulated machines and real hosts will be on different subnets, you need to configure routes to the simulated network on real hosts that need to access it.
You can not access the simulation host from the simulated machines using an IP routing connection.
Host connections do not enable the simulated machines to access other hosts on the real network, unless you enable IP routing on the simulation host. In that case you need to configure routes to the simulated network on real hosts that need to access it.
Basically, if you are only going to use simple TCP services like FTP, HTTP or telnet, you should probably use port forwarding. If you can not use port forwarding but have available IP addresses on the IP subnet of the real network, or if you use other network protocols than IPv4, you should probably use an Ethernet bridging connection. If you do not have available IP addresses on the IP subnet of the real network, but can configure routes on the other hosts on the real network, you should probably use an IP routing connection. Finally, if you want to access the simulated machines from the simulation host but can not use port forwarding, you have to use a host connection.
The commands to create a connection to the real network start with 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 one is created. All Ethernet interfaces of all simulated machines in the Simics process are then automatically connected to the ethernet-link, and the ethernet-link 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, you would use the global command connect-real-network-bridge.
If you have a more complex simulated network setup, you probably do not want to connect all simulated Ethernet interfaces to the same network. In that case, you first create your 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 you can run on an ethernet-link object to connect it to the real network. For example, if you have an ethernet-link object named ethlink0, you would use the command ethlink0.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-link 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. There is also support for 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 if you only need simple TCP or UDP connectivity, for example, for telnet or FTP. Port forwarding is easy to set up. Simics does not need administrative privileges to run port forwarding, and you do not need to configure the simulation host or other hosts on the real network in any way.
The port forwarding is managed by a service-node on the ethernet-link. It is the service-node that listens for traffic both on the real and simulated networks and forwards it to the other side. All port forwarding commands except connect-real-network therefore require an ethernet-link with a service-node as argument.
There are really four distinct parts to Simics's port forwarding solution. There is forwarding of specific ports from the real network to the simulated network, there is forwarding of specific ports from the simulated network to the real network network, there is NAPT from the simulated network to the real network, and there is 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 you want to view the current port forwarding setup, you can use the list-port-forwarding-setup command. It will list all incoming and outgoing ports, NAPT and DNS 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 you have multiple simulated machines you can run connect-real-network 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 you to specify an ethernet-link, unless there is more than one. If there is no ethernet-link or service-node, they will be created automatically.
The connect-real-network lets us 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 10.3, and then run the connect-real-network command with the IP address 10.10.0.15, which is the default address of the enterprise machine:
simics> connect-real-network 10.10.0.15 No ethernet-link found, creating 'ethlink0'. No service-node found, creating 'ethlink0_sn0' with IP '10.10.0.1'. Connecting device 'lance0' to 'ethlink0' NAPT enabled with gateway 10.10.0.1 on link ethlink0. Host TCP port 4021 -> 10.10.0.15:21 on link ethlink0 Host TCP port 4023 -> 10.10.0.15:23 on link ethlink0 Host TCP port 4080 -> 10.10.0.15:80 on link ethlink0 Real DNS enabled at 10.10.0.1 on link ethlink0.
From the output you can see that an ethernet-link and a service-node have been automatically created and connected to the simulated machine. NAPT, DNS forwarding, and incoming port forwarding for FTP, HTTP and telnet have been also enabled.
You should now be able configure the service node as default gateway on the enterprise machine and to telnet to a host on the real network as described in the example of section 10.4.1.4, and to configure the service node as DNS server on the enterprise machine and use it to look up real DNS names as described in the example of section 10.4.1.5.
If you have FTP, HTTP or telnet servers on your simulated machine, which the enterprise machine does not have by default, you should also be able to access these servers from the real network through the ports they have been assigned on the simulation host.
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 machines. It takes required three arguments ethernet-link, target-ip and target-port, that specify the ethernet-link, IP address and port the traffic should be forwarded to.
You can also specify what port on the simulation host should be used to receive the incoming traffic by specifying the host-port argument. If you do not, Simics will automatically select a port and print it on the Simics console.
The command can also take the flags -tcp and -udp, that let you specify whether you want to set up forwarding for a TCP or UDP port. If neither is specified forwarding will be set up for both the TCP and UDP port.
The service-node acts as a proxy for incoming traffic, so when you want to connect to a port on the simulated machine from the real network, you should connect to the corresponding port on the simulation host. You should not use the simulation host as gateway for the simulated network.
Any UDP packets sent to 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-way, once a connection has been established, data can be sent in both directions.
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 you use active mode FTP.
In the checkpoint we prepared in section 10.3 we started the echo service on port 7 of the simulated machine. We can now set up a port forwarding rule that lets us access the echo 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> new-ethernet-link Created ethernet-link ethlink0 simics> new-service-node link = ethlink0 ip = 10.10.0.1netmask = 255.255.255.0 Created service-node ethlink0_sn0 Connecting ethlink0_sn0 to ethlink0 Setting IP address of ethlink0_sn0 on network ethlink0 to 10.10.0.1 simics> lance0.connect ethlink0 simics> connect-real-network-port-in ethernet-link = ethlink0
The enterprise machine uses the IP address 10.10.0.15 and the echo service runs on TCP port 7. We use port 2007 on the simulation host, but you can use any free port.
Start the simulation. You should now be able to telnet from a real host to the echo port of the simulated machine by telnetting to port 2007 of the simulation host. In our case the simulation host has the IP address 10.0.0.129, replace it with the IP address of your simulation host:
bash-2.05# telnet 10.0.0.129 2007 Trying 10.0.0.129... Connected to 10.0.0.129. Escape character is '^]'. Echo this! Echo this! Press Ctrl and 5. ^] telnet> q Connection to 10.0.0.129 closed. bash-2.05#
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 three required arguments ethernet-link, target-ip and target-port, that specify the ethernet-link the service-node is connected to, and the IP address and port on the real network the traffic should be forwarded.
You can also specify what port on the service-node should be used to receive the outgoing traffic by specifying the service-node-port argument. If you do not, Simics will automatically select a port and print it on the Simics console.
The command can also take the flags -tcp and -udp, that let you specify whether you want to set up forwarding for a TCP or UDP port. If neither is specified forwarding will be set up for both the TCP and UDP port.
The service-node acts as a proxy for outgoing traffic, so when you want to connect to a port on the host on the real network from a simulated machine, you should connect to the corresponding port on the service-node. You should not use the service-node as gateway for the real network.
Any UDP packets sent to 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-way, 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 23 of a host on the real network, we should be able to telnet to the real host by telnetting to the port on the service-node from the enterprise machine. We can start from the checkpoint we prepared in section 10.3, and create an ethernet-link and 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 your network:
simics> new-ethernet-link Created ethernet-link ethlink0 simics> new-service-node link = ethlink0 ip = 10.10.0.1
Now start the simulation. We used the IP address 10.10.0.1 and the port 2323 for the service-node, so we should be able to telnet to the real host by telnetting to port 2323 of 10.10.0.1 from the enterprise machine:
[root@enterprise root]# telnet 10.10.0.1 2323 Trying 10.10.0.1... Connected to 10.10.0.1. Escape character is '^]'. SunOS 5.9 login: joe Password: No directory! Logging in with home=/ Last login: Sun Jun 2 07:45:58 from 10.0.0.211 Sun Microsystems Inc. SunOS 5.9 Generic May 2002 $ exit [root@enterprise root]#
The connect-real-network-napt command sets up NAPT (network address port translation, also known as just NAT or network address translation) from the simulated network to the real network. With NAPT enabled, the service-node will act as a gateway on the simulated network and automatically forward 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.
You must configure the simulated machines 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. If you combine NAPT with DNS forwarding, described in section 10.4.1.5, you will be able to use the real DNS names of hosts on the real network too.
The NAPT setup is not specific to a simulated machine, so you only need to run connect-real-network-napt 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, you should use passive mode FTP if you connect to an FTP server on a host on the real network from a simulated machine.
To try NAPT, we can start from the checkpoint we prepared in section 10.3, 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> new-ethernet-link Created ethernet-link ethlink0 simics> new-service-node link = ethlink0 ip = 10.10.0.1
Now start the simulation. Since we gave the service-node the IP address 10.10.0.1, the enterprise machine should be configured with 10.10.0.1 as default gateway. This is already the default, which you can see by running route in the the simulated console:
[root@enterprise root]# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.10.0.0 * 255.255.255.0 U 0 0 0 eth0 127.0.0.0 * 255.0.0.0 U 0 0 0 lo default 10.10.0.1 0.0.0.0 UG 0 0 0 eth0
If this had not been the case, we could have added 10.10.0.1 as default gateway with the command route add default gw 10.10.0.1.
You should now be able to telnet from the simulated machine to hosts on the real network. In this case we telnet to a Solaris machine with IP address 10.0.0.240, replace this with the address of another host on your real network:
[root@enterprise root]# 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. [root@enterprise root]#
The enable-real-dns and disable-real-dns commands of the service-node class 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 10.3, and create an ethernet-link and service-node, connect the simulated machine to the ethernet-link and run the enable-real-dns command like this:
simics> new-ethernet-link Created ethernet-link ethlink0 simics> new-service-node link = ethlink0 ip = 10.10.0.1
Now start the simulation. To tell the simulated machine to use the service-node as DNS server, the line nameserver 10.10.0.1 is needed in the file /etc/resolv.conf on the simulated machine. However, this is already the default, so nothing needs to be done.
You should now be able to look up the addresses of real hosts on the simulated machine, for example, www.google.com:
[root@enterprise root]# nslookup www.google.com Note: nslookup is deprecated and may be removed from future releases. Consider using the `dig' or `host' programs instead. Run nslookup with the `-sil[ent]' option to prevent this message from appearing. Server: 10.10.0.1 Address: 10.10.0.1#53 Name: www.google.com Address: 216.239.59.104
Simics can act as a bridge between simulated Ethernet networks and the real Ethernet networks of the host. With this type of connection it will appear that the simulated machines are directly connected to the real network, both to the simulated machines and to the hosts on the real network. Because of this you should configure your simulated machines 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. You will not be able to access the simulated network from the simulation host.
To create a bridged connection to the real network, use the connect-real-network-bridge command. It takes an argument interface that specifies what Ethernet interface on the host should be used. It also takes an argument host-access that specifies how Simics should access the host's Ethernet interface, see section 10.1. If you omit the arguments, Simics will use raw access to the first interface it finds.
By default Simics will translate MAC addresses between the simulated network and the real network, so that the host's MAC address is used for all packets sent on the real network. This has two advantages. First of all, the simulation host does not have to listen on the real network in promiscuous mode, reducing the load on it. It also avoids problems with MAC address collisions between multiple simulations connected to the same real network. Each simulated machine communicating with the real network must still be configured with a unique IP address, though.
There are a couple of drawbacks with MAC address translation. One is that it is limited to ARP and IPv4 packets; other kinds of packets will not be bridged. There may also be problems with setting up routing on simulated machines. Since the destination MAC addresses are translated, the packets may not go where you expect them.
To be able to bridge other kinds of traffic than ARP and IPv4, for example, DHCP, IPv6, or IPX, you can turn off MAC address translation by specifying the -no-mac-xlate flag to connect-real-network-bridge. This enables all kinds Ethernet traffic to be bridged between the simulated network and the real network. You must then make sure that each simulated machine connected to the real network is configured with a unique MAC address, to avoid MAC address collisions on the real network.
A big drawback with disabling MAC address translation is that the host must listen on the real network in promiscuous mode. This increases the risk of dropping packets from the real network that were intended for the simulated network, because unrelated traffic will be bridged to the simulated network. It is therefore recommended that bridging without MAC address translation only be used on dedicated networks, or on network interfaces with very little unrelated traffic.
When you run the connect-real-network-bridge command with TAP access, the operating system must be configured to act as a bridge between the virtual interface and the real interface. That is done by the following steps:
computer# brctl addbr sim_br0 computer# brctl addif sim_br0 sim_tap0 computer# brctl addif sim_br0 eth1 computer# brctl stp sim_br0 off
computer# ifconfig sim_tap0 promisc up computer# ifconfig sim_br0 promisc up
To remove the bridging when you are done, do the following:
computer# ifconfig sim_tap0 down computer# ifconfig sim_br0 down
computer# brctl delbr sim_br0
This example assumes that you are starting from the checkpoint prepared in section 10.3, and that you have installed the openif helper program according to the instructions in Simics Installation Guide.
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 host-access = raw Created ethernet-link ethlink0 Connecting lance0 to ethlink0 [real_net0 info] Receive buffer size 262142 bytes. [real_net0 info] Using mmap packet capture. Ethernet-link 'ethlink0' 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 your real network:
[root@enterprise root]# ifconfig eth0 10.0.0.241 netmask 255.255.255.0
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. You should be able to ping any real host from the simulated machine. Replace 10.0.0.240 with the address of a host on your real network.
[root@enterprise root]# ping 10.0.0.240 -c 5 PING 10.0.0.240 (10.0.0.240) from 10.0.0.241 : 56(84) bytes of data. 64 bytes from 10.0.0.240: icmp_seq=1 ttl=255 time=28.0 ms 64 bytes from 10.0.0.240: icmp_seq=2 ttl=255 time=60.9 ms 64 bytes from 10.0.0.240: icmp_seq=3 ttl=255 time=40.9 ms 64 bytes from 10.0.0.240: icmp_seq=4 ttl=255 time=50.9 ms 64 bytes from 10.0.0.240: icmp_seq=5 ttl=255 time=1.10 ms --- 10.0.0.240 ping statistics --- 5 packets transmitted, 5 received, 0% loss, time 4047ms rtt min/avg/max/mdev = 1.106/36.409/60.950/20.734 ms
Of course, it should also be possible to ping from the real host to the simulated machine. Running traceroute shows that the simulated machine is connected directly to the real network; there are no routers between it and the real host. Again, replace 10.0.0.240 with another host on your real network.
[root@enterprise root]# 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) 2.568 ms 1.291 ms 1.292 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 you need to check your configuration.
You should also, for example, be able to telnet from the simulated machine to a real host. Again, replace 10.0.0.240 with another host on your real network.
[root@enterprise root]# 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: Last login: Sun Jun 2 07:21:44 from 10.0.0.129 Sun Microsystems Inc. SunOS 5.9 Generic May 2002 $ exit Connection closed by foreign host.
Simics can act as an IP router between simulated Ethernet networks and the real Ethernet networks of the host. This allows any kind of IPv4 traffic between the simulated machines and hosts on the real network. It will appear to both the simulated machine and the real hosts that there is an ordinary IP router between them.
To create a routed connection to the real network, use the connect-real-network-router command. The arguments ip and netmask specify what IP address and netmask the real network router should use on the simulated network. It will always use the simulation host's IP address on the real network. The gateway argument tells the real network router what machine on the simulated network should be used as gateway to other simulated networks, in case there are multiple simulated networks with routers between them. The interface argument specifies what Ethernet interface on the host should be used, if there are more than one.
Simics creates a new real network router object, typically named real_net0, that performs the routing. It is independent of any service-node on the ethernet-link, and should use a unique IP address.
When acting as an IP router, Simics will always use raw access to the host's Ethernet interface; see section 10.1 for more information.
For the routing to work, you have to configure the simulated machine with a route to the real network with the real network router's IP address as gateway. You will also have to set up a route to the simulated network with the simulation host as gateway on all real hosts that are going to communicate with the simulated machines. Also, you will probably not be able to access the simulated network from the simulation host unless you set up fairly complicated routing rules.
This example assumes that you are starting from the checkpoint prepared in section 10.3, and that you have installed the openif helper program according to the instructions in Simics Installation Guide.
To set up an IP routing connection between simulated network to the real network, run the connect-real-network-router command. This will automatically create an ethernet-link and real network router, and connect the simulated machine and real network router to the ethernet-link. Here the IP address 10.10.0.1 is used for the real network router.
simics> connect-real-network-router ip = 10.10.0.1 Created ethernet-link ethlink0 Connecting lance0 to ethlink0 [real_net0 info] Receive buffer size 262142 bytes. [real_net0 info] Using mmap packet capture. Ethernet-link 'ethlink0' connected to real network.
The simulated machine must have a route to the real network with the real network router as gateway, so add one using the route command:
[root@enterprise root]# route add -net 10.0.0.0 netmask 255.255.255.0
We also need to create a route to the simulated network with the simulation host as gateway on the real hosts that are going to communicate with the simulated network. The command to do this is different depending on the operating system of the real host. In this case 10.10.0.0 and 255.255.255.0 are the IP address and the netmask of the simulated network, and 10.0.0.129 is the IP address of the simulation host. Replace these with the correct addresses and netmask for your setup. Note that you must have administrative privileges to run these commands.
/sbin/route add -net 10.10.0.0 netmask 255.255.255.0 gw 10.0.0.129
/sbin/route add -net 10.10.0 10.0.0.129
route add 10.10.0.0 mask 255.255.255.0 10.0.0.129
Once this is done, you should be able to ping the real host from the simulated machine. Replace 10.0.0.240 with the address of another host on your real network:
[root@enterprise root]# ping 10.0.0.240 -c 5 PING 10.0.0.240 (10.0.0.240) from 10.10.0.15 : 56(84) bytes of data. 64 bytes from 10.0.0.240: icmp_seq=1 ttl=255 time=158 ms 64 bytes from 10.0.0.240: icmp_seq=2 ttl=255 time=10.9 ms 64 bytes from 10.0.0.240: icmp_seq=3 ttl=255 time=1.10 ms 64 bytes from 10.0.0.240: icmp_seq=4 ttl=255 time=1.10 ms 64 bytes from 10.0.0.240: icmp_seq=5 ttl=255 time=1.10 ms --- 10.0.0.240 ping statistics --- 5 packets transmitted, 5 received, 0% loss, time 4047ms rtt min/avg/max/mdev = 1.106/34.582/158.650/62.150 ms
Of course it should also be possible to ping from the real host to the simulated machine too. By running traceroute from the simulated machine to the real host, we can see the real network router. It shows up as an unknown router (1 * * *), since it does not implement the ICMP protocol. Again, replace 10.0.0.240 with the address of another host on your real network:
[root@enterprise root]# traceroute 10.0.0.240 traceroute to 10.0.0.240 (10.0.0.240), 30 hops max, 38 byte packets 1 * * * 2 10.0.0.240 (10.0.0.240) 100.883 ms 939.796 ms 1.288 ms
If this works, the IP routing between the real and simulated network is working, so any kind of IP traffic can pass between them. You should, for example, be a able to telnet from the real host to the echo port on the simulated machine, using the simulated machine's IP address:
bash-2.05# telnet 10.10.0.15 7 Trying 10.10.0.15... Connected to 10.10.0.15. Escape character is '^]'. Echo echo echo echo! Echo echo echo echo! Press Ctrl and 5. ^] telnet> q Connection to 10.10.0.15 closed.
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.
Host connection is not supported on Solaris host, since it can only use TAP access, and TAP access is not supported on Solaris.
To connect the simulated network to the TAP interface, you first have to configure the TAP interface on the simulation host, as described in section 10.1.2. You then 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. It should be configured with an IP addresses from the same subnet as the simulated machines. The simulated machines will then be able to communicate with it without any further configuration.
If you enable IP routing on the simulation host you will also be able to access other hosts on the real network, very similar to using an IP routing connection as described above. You must then configure the simulated machines to use the simulation host's IP address on the TAP interface as gateway for the real network, and real hosts to use the simulation host's IP address on the real network as gateway for the simulated network.
To enable IP traffic between the simulation host and the simulated machines, you have to set up an IP address on the TAP interface. The simulation host will use this address on the simulated network. Here the IP address 10.10.0.1 and the netmask 255.255.255.0 are used, replace them with an IP address from the subnet used by the simulated machines and the corresponding netmask. This requires administrative privileges:
computer# ifconfig sim_tap0 10.10.0.1 netmask 255.255.255.0 up
Simulated machine configurations provided with Simics usually use IP addresses from the 10.10.0.x subnet, so you should typically select an IP address on the form 10.10.0.x and the netmask 255.255.255.0.
If you enable IP forwarding on the simulation host, you will also be able to access the simulated network from other hosts on the real network by routing the traffic through the simulation host:
computer# sysctl -w net.ipv4.ip_forward=1 net.ipv4.ip_forward = 1
To disable IP forwarding again:
computer# sysctl -w net.ipv4.ip_forward=0 net.ipv4.ip_forward = 0
This example assumes that you are starting from the checkpoint prepared in section 10.3, that you have set up a TAP interface on the simulation host for host connection according to section 10.1.2, and that you have configured it with the 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 your TAP interface.
Since host connection is not supported supported on Solaris host, this example will not work if your simulation host is running Solaris.
To connect the TAP interface to the simulated network, use the connect-real-network-host command:
simics> connect-real-network-host interface = sim_tap0 Created ethernet-link ethlink0 Connecting lance0 to ethlink0 [real_net0 info] Connecting to existing TUN/TAP device 'sim_tap0' Ethernet-link 'ethlink0' connected to real network.
Any kind of Ethernet traffic can now pass between the simulated network and the simulation host. You should, for example, be able to ping the simulation host from the simulated machine, at the IP address you configured on the TAP interface:
[root@enterprise root]# ping 10.10.0.1 -c 5 PING 10.10.0.1 (10.10.0.1) from 10.10.0.15 : 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