Previous - Up - Next

9.3   IP Services

It is often useful to be able to let the simulated machines use services available on the simulated network, especially for boot-time configuration. Instead of adding a full system simulation of servers running these services, a more efficient implementation is provided as a Simics service node.

The service-node class provides a virtual network node that acts as a server for a number of protocols, and it can act as a IP router between networks. The services supported are:

There can be any number of service-node objects, and each object can be connected to any number of Ethernet links. In most configurations, however, there will usually be a single service node object. The links themselves do not provide any services, so a service node is needed to make the services available to target machines connected to the link.

A service node can be created using the new-service-node command:

simics> new-service-node
Created service-node sn0

This service node can then be connected to an Ethernet link object. For example, if you already have an ethernet-link called ethlink0 and want the service-node to use the IP address 10.10.0.1 on it:

simics> sn0.connect ethlink0 10.10.0.1
Connecting sn0 to ethlink0
Setting IP address of sn0 on network ethlink0 to 10.10.0.1


Note: The service node needs to have an IP address on each link it is connected to.

The link to attach the service node to can also be specified when creating the service node. This will make the default name given to the service reflect which link object it is connected to. For example, if you already have an ethernet-link called ethlink0 and want the service-node to use the IP address 10.10.0.1 on it:

simics> new-service-node link = ethlink0 ip = 10.10.0.1
Created service-node ethlink0_sn0
Connecting ethlink0_sn0 to ethlink0
Setting IP address of ethlink0_sn0 on network ethlink0 to 10.10.0.1

For each link that the service node connects to, a service-node-device will be automatically created to act as an Ethernet interface. The name of these device objects are a combination of the service node name and the link object name.

9.3.1   IP Based Routing

A service-node object can provide IP based routing between Ethernet links, allowing machines attached to different networks to communicate with each other.


Note: To use the routing mechanisms, simulated machines must use the IP address of the service node as a gateway for IP based traffic. Configuring a gateway requires system administration skills, and the exact procedure depends on the target operating system.

The service node contains an internal IP routing table that is used for packet routing between connected links. The routing table can be viewed using the <service-node>.route command:

simics> sn0.route
Destination  Netmask        Gateway  Port
-----------------------------------------------------
10.10.0.0    255.255.255.0           sn0_ethlink0_dev

The output is quite similar to route command available on many systems. The destination and netmask fields specify a target that can be either a network (i.e., a range of addresses) or a single host (with netmask 255.255.255.255). For packets with this target as their destination, the port field specifies the service node network device on which link the packet should be sent.

New entries can be added to the routing table with the <service-node>.route-add command. If you have a service-node called sn0 connected to two links called ethlink0 and ethlink1, you could, for example, set up routes like this:

simics> sn0.route-add 192.168.0.0 255.255.0.0 link = ethlink0
simics> sn0.route-add 192.168.1.0/26 link = ethlink1
simics> sn0.route-add 10.10.0.0 255.255.0.0 192.168.0.1 ethlink0
simics> sn0.route-add 0.0.0.0 255.255.255.255 192.168.1.1 ethlink1
simics> sn0.route
Destination  Netmask          Gateway      Port
-----------------------------------------------------------
192.168.0.0  255.255.255.0                 sn0_ethlink0_dev
192.168.1.0  255.255.255.192               sn0_ethlink1_dev
10.10.0.0    255.255.0.0      192.168.0.1  sn0_ethlink0_dev
default                       192.168.1.1  sn0_ethlink1_dev

The destination address and the netmask identify the target, and should be given as strings in dotted decimal form. If the target is a single host, the netmask should be given as "255.255.255.255".

9.3.2   DHCP and BOOTP

A service node can act as a Dynamic Host Configuration Protocol (DHCP) or Bootstrap Protocol (BOOTP) server, responding to requests from clients that can read their network configuration from such a server. The DHCP protocol is an extension of the BOOTP protocol, and for many uses the feature set used are more or less the same. The Simics implementation uses the same configuration for both services.

The service node has a table that maps MAC addresses to IP addresses and domain name. This is used to answer DHCP or BOOTP request. An entry to this table can be added with the <service-node>.add-host command:

simics> sn0.add-host 10.10.0.1 node1 mac="10:10:10:10:10:01"
Adding host info for IP 10.10.0.1: node1.network.sim  MAC: 10:10:10:10:10:01

The current contents of the table can be viewed with the <service-node>.list-host-info command:

simics> sn0.list-host-info
IP         name.domain        MAC
-----------------------------------------------
10.10.0.1  node1.network.sim  10:10:10:10:10:01

A pool of IP addresses for dynamic DHCP leases can be added with the <service-node>.dhcp-add-pool command. This is used for dynamically assigning IP addresses to new clients. When an entry from the pool is used, the new mapping is stored in the internal host info table, including an automatically generated name that can be found through DNS queries.

If a DHCP client's MAC address matches an entry in the table, it is assigned the corresponding IP address. If there is no matching MAC address, the dynamic address pools will be searched for an available IP address.

The DHCP implementation in service-node is simple, and might not work with all DHCP clients.

9.3.3   DNS

The service node includes the functionality of a simple Domain Name Server (DNS), that a simulated client can use to translate a host/domain name into an IP address and vice versa. The DNS service is based on the same host table as the DHCP service, and only answers requests for A and PTR records.

For entries in the table that will only be used for DNS requests, and not for assigning IP address by means of DHCP, the MAC address can be left out. The <service-node>.add-host command can be used to add table entries, and the <service-node>.list-host-info command prints the current table. By default, all host entries will use the network.sim domain.

simics> sn0.add-host 10.10.0.1 donut
Adding host info for IP 10.10.0.1: donut.network.sim
simics> sn0.add-host 10.11.0.1 foo other.domain
Adding host info for IP 10.11.0.1: foo.other.domain
simics> sn0.list-host-info
IP         name.domain        MAC | IP         name.domain        MAC
----------------------------------+----------------------------------
10.10.0.1  donut.network.sim      | 10.11.0.1  foo.other.domain

For dynamically added DHCP addresses, a DNS name will be added for the new IP number, so that any address handed out by a DHCP server can be found by the DNS service.

When connected to a real network, the DNS service can do external lookups for names it does not recognize.

9.3.4   TFTP

The service node also supports the Trivial File Transfer Protocol (TFTP, see RFC 1350) and can be used to transfer files between the host system (running the simulation) and a simulated (target) client. The TFTP functionality is often used in network booting, together with the BOOTP facilities, to load OS kernels and images, and can also be used interactively from the tftp command found on many systems.

Files that should be transferred from the host system to the simulated client should be located in a directory on the Simics path.


Note: This is the same path as used by image objects and can be viewed with list-directory command and modified with the add-directory command.

Files transferred from the simulated client to the host, will also end up in the same directory.


Note: TFTP is based on UDP, and each package is acknowledged individually before the transfer is allowed to continue. Depending on the latency of the link, the transfer of large files can be slow. In that case, ensuring that the link can use a lower latency will increase performance.

Previous - Up - Next