Previous - Up - Next

10.6   Troubleshooting

A network monitoring tool such as Ethereal is invaluable when debugging problems with the real network connections. It is a graphical traffic analyzer that can analyze most common network protocols. Ethereal is available from http://www.ethereal.com.

There are some pitfalls one might encounter when trying to connect a simulated network to a real one:

Trying to access the simulation host

Accessing the simulation host from the simulated network, or the other way around, is only supported with port forwarding and host connection. You will not be able to access the simulation host from the simulated network if you set up an IP routing connection or an Ethernet bridging connection.

Real host has no route

If you are using an IP routing connection and trying to communicate with the simulated network from a real host that does not have a route to the simulated network, the real host will drop the packets intended for the simulated network or send them to the wrong router. Running Ethereal on the Ethernet interface of the real host will show you if, and in that case where, the packets are sent. They should be sent to the simulation host, but if a route is missing they will usually be sent to the real host's default gateway, which will probably ignore them.

Simulated OS has no route

If you are using a NAPT connection or an IP routing connection and the operating system of the simulated machine does not have a correct route to the real network, the simulated machine will drop the packets or send them to the wrong address. To view the routing setup on the simulated machine, use the command netstat -r on Linux and Solaris, or route print on Windows. Note that these commands should be executed on the simulated machines. The simulated OS should have a default route to the service node in the case NAPT connections, or the real network router in the case of IP routing connections.

Real host and simulation host not on the same subnet

If you are using an IP routing connection, all real hosts that should be communicating with the simulated network need to be on the same IP subnet as the simulation host. Otherwise, the real routers between the real host and the simulation host will not be aware of the simulated network and will drop any packets to it, or confuse it with a real subnet with the same address and route the packets there.

Of course, you can configure the real routers to be aware of the simulated network if you really have to communicate with the simulated network from other subnets.

This restriction does not apply to port forwarding connections and Ethernet bridging connections where the simulated machines use IP addresses from the real subnet.

Simics uses the wrong host network interface

On a host with multiple network interfaces installed, Simics will only use one of them for a real network connection. If the default selection is incorrect, use the interface argument of the connect command to select the desired network interface. See the Selecting Host Interface part of section 10.2.

Previous - Up - Next