It is often useful to let the simulated machines use services (e.g. DHCP service) available on the simulated network. Normally these services run on servers connected to the network. To avoid having to set up simulated servers just to provide them, Simics implements a service node instead.
The service_node_comp component class, available after loading the std-comp module, provides a virtual network node that acts as a server for a number of TCP/IP-based protocols, and as an IP router between simulated networks. It handles both IPv4 and IPv6 protocol versions. The supported services are:
ftp-service class description in Simics Reference Manual)There can be any number of service_node_comp components, and each one can be connected to any number of Ethernet links. In most configurations, however, there will be a single service node. A service node can be created using the create/new-service-node-comp commands. An example, starting with the firststeps-multi.simics script:
simics> load-module std-comp
simics> new-service-node-comp sn0
Created instantiated 'service_node_comp' component 'sn0'
This service node can then be connected to an Ethernet link component. Note that the service-node IP address on the link must be specified:
simics> load-module eth-links
simics> new-ethernet-hub
Created instantiated 'ethernet_hub' component 'ethernet_hub0'
simics> sn0.connect-to-link ethernet_hub0 10.10.0.1
Adding host info for IP 10.10.0.1: simics0.network.sim MAC: 20:20:20:20:20:00
Connecting links can be done with non-instantiated components. Some commands are only available after the service node has been instantiated, for example:
simics> sn0.list-host-info
IP name.domain MAC
-------------------------------------------------
10.10.0.1 simics0.network.sim 20:20:20:20:20:00
Simics' service node can provide IP based routing between Ethernet links, allowing machines attached to different networks to communicate with each other.
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.
Each connection of the service-node to an Ethernet link implies a default route to that link. For example, connecting a service node with the address 192.168.0.1/24 to link1 implies that all packets matching this network and mask combination will be routed to link1 automatically. This often solves the most common routing needs.
In addition, 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_comp>.route command:
simics> sn0.route
Destination Netmask Gateway Link
------------------------------------
10.10.0.0 24 link0
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 link field specifies the Ethernet link the packet should be sent to.
New entries can be added to the routing table with the
<service_node_comp>.route-add command. If there is a service node called sn0 connected to two links called link0 and link1, it would for example possible to set up routes like this:
simics> sn0.route-add 192.168.0.0 255.255.0.0 link = link0
simics> sn0.route-add 192.168.1.0/26 link = link1
simics> sn0.route-add 10.10.0.0 255.255.0.0 192.168.0.1 link0
simics> sn0.route-add 0.0.0.0 255.255.255.255 192.168.1.1 link1
simics> sn0.route
Destination Netmask Gateway Link
----------------------------------------
192.168.0.0 16 link0
192.168.1.0 26 link1
10.10.0.0 16 192.168.0.1 link0
default 192.168.1.1 link1
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".
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 is 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 requests.The <service_node_comp>.add-host command can add entries to this table:
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 <service_node_comp>.list-host-info command prints the current contents of the table:
simics> sn0.list-host-info
IP name.domain MAC
-------------------------------------------------
10.10.0.0 simics0.network.sim 20:20:20:20:20:00
10.10.0.1 node1.network.sim 10:10:10:10:10:01
The <service_node_comp>.dhcp-add-pool command adds dynamic DHCP leases, from which new clients will be automatically assigned an address on request. When an entry from the pool is given out, the new mapping is stored in the internal host info table, including a 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.
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 to answer DNS requests, and not for DHCP, the MAC address can be left out. The <service_node_comp>.add-host command can be used to add table entries, and the <service_node_comp>.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
-------------------------------------------------
10.10.0.0 simics0.network.sim 20:20:20:20:20:00
10.10.0.1 donut.network.sim 10:10:10:10:10:01
10.11.0.1 foo.other.domain
For dynamic DHCP addresses, a DNS name will be added for the new IP number, so that any of these addresses 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.
The service node also supports the Trivial File Transfer Protocol (TFTP, see RFC 1350) which allows to transfer files between the host system (running the simulation) and a simulated (target) client. TFTP is often used during network booting, together with the BOOTP facilities, to load OS kernels and images, and it can also be used interactively with the tftp command found on many systems.
Files transferred from the host system to the simulated client should be placed in a directory in the Simics path. This is the standard path used by image objects: list-directories prints its current value, while add-directory adds a directory to the path list. The current working directory is also automatically included.
Files transferred from the simulated client to the host end up in the current working directory. When running Simics from the command line, this is the directory Simics was started from.
TFTP is based on UDP, and each packet 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 uses a lower latency will increase performance.