ChorusOS 5.0 System Administrator's Guide

IP Forwarding

This section explains IPv4 datagrams, and includes procedural instructions for configuring the gateway, and for configuring the hosts on subnetworks.

One of the ways in which the ChorusOS operating system can act as a gateway between separate subnetworks is through simply forwarding IP datagrams. A ChorusOS host with two or more ethernet adapters can be configured to make a link between different network interfaces, as shown in Figure 12-1 below.

Figure 12-1 ChorusOS as an IP Gateway

Graphic

In Figure 12-1 above, the ChorusOS system is a gateway bridging Subnetwork 1 to Subnetwork 2. In order to make this gateway:

For example, in order to send an IP datagram from Subnetwork 1 to Subnetwork 2, the ethernet interface IP addresses must to be created for ifeth0 and ifeth1 on the ChorusOS host. Then, in order to reach Subnetwork 2, datagrams received on the ifeth0 interface must be redirected through the ifeth1 interface. The default behavior would be for a ChorusOS system to drop silently the datagram after it is received at ifeth0, so a specific configuration is required to forward it between the two ethernet interfaces.

Configuring the Gateway

In order to configure the two ethernet interfaces from Figure 12-1 and to create the routing table to redirect the datagrams between the interfaces, add the following lines to the sysadm.ini file (see sysadm.ini(4CC)) of the ChorusOS gateway.

  1. Create the network interfaces:

    mkdev ifeth 0 
    mkdev ifeth 1
  2. Configure the ifeth0 interface:

    ifconfig ifeth0 129.158.111.111 netmask 0xffff0000 broadcast 129.158.255.255
    ifwait ifeth0
  3. Configure the ifeth1 interface:

    ifconfig ifeth1 129.159.222.222 netmask 0xffff0000 broadcast 129.159.255.255
    ifwait ifeth1
  4. Set up the routes between ifeth0 and ifeth1:

    route add -net 129.158 -iface ifeth0
    route add -net 129.159 -iface ifeth1
  5. Configure the ChorusOS operating system to forward the incoming IP datagrams to the corresponding ethernet interface. You do this by activating the net.inet.ip.forwarding state in the microkernel, by adding the following line to the sysadm.ini file:

    sysctl -w net.inet.ip.forwarding=1
Configuring the Hosts on the Subnetworks

You must now configure the hosts on the different subnetworks so that they will use the gateway to send datagrams to each other. For example, assuming that Host A on Subnetwork 1 in Figure 12-1 is running under a ChorusOS system, define a route for it to send datagrams to Subnetwork 2 via the gateway. To do this, add the following lines to the sysadm.ini file for Host A.

  1. Create the network interface:

    mkdev ifeth 0
  2. Configure this interface:

    ifconfig ifeth0 129.158.333.333 netmask 0xffff0000 broadcast 129.158.255.255
    ifwait ifeth0
  3. Set up the routes. You can set up a simple route, which uses the network interface directly:

    route add -net 129.158 -iface ifeth0

    Or, you can specify a gateway explicitly, for example ifeth0 on the ChorusOS gateway from Figure 12-1, as the route to take:

    route add -net 129.159 129.158.111.111

As you can see, the gateway configuration using simple IP forwarding will only work if the hosts on the different subnetworks are correctly configured to send datagrams via the gateway. Since configuring all the hosts to use a specific machine as a gateway is not always possible, it is sometimes necessary to create a gateway between the subnetworks by configuring the ChorusOS operating system to act as an ARP proxy.

The ChorusOS operating system as an ARP proxy

The Address Resolution Protocol (ARP -- see ARP(7P)) maps IP addresses to specific machine addresses in a network. Where a ChorusOS system is acting as a gateway between two or more subnetworks, configuring it as an ARP proxy allows you to handle all the different physical subnetworks as if they are the same network. In other words, creating an ARP proxy makes a single virtual network composed of several physical subnetworks. Consequently, the different hosts located on these networks can communicate without being aware of the presence of the gateway.

This type of configuration is desirable in the following circumstances:

A ChorusOS host with two or more ethernet adapters can be configured as an ARP proxy linking different network interfaces to create a single, virtual network, as shown in Figure 12-2.

Figure 12-2 The ChorusOS system as an ARP Proxy

Graphic

Configuring the Gateway as an ARP Proxy

To configure the ChorusOS gateway to act as an ARP proxy, create the two network interfaces, set them up and create the routing table. To create the example shown in Figure 12-2, you add the following to the sysadm.ini file of the ChorusOS gateway:

  1. Create the two network interfaces:

    mkdev ifeth 0
    mkdev ifeth 1
  2. Configure interface ifeth0:

    ifconfig ifeth0 129.158.110.111 netmask 0xffffff00 broadcast 129.158.110.255
    ifwait ifeth0
  3. Configure interface ifeth1

    ifconfig ifeth1 129.158.112.222 netmask 0xffffff00 broadcast 129.159.112.255
    ifwait ifeth1
  4. Set up the routes:

    route add -net 129.158.110 -iface ifeth0
    route add -net 129.158.112 -iface ifeth1
  5. Configure the ChorusOS system to forward IP packets:

    sysctl -w net.inet.ip.forwarding=1
  6. Configure the ChorusOS system to forward ARP requests by activating the net.ether.inet.proxyall microkernel state:

    sysctl -w net.ether.inet.proxyall=1
Configuring the Hosts on the Subnetworks

You must now configure the individual hosts on the virtual network so that they use the ARP proxy gateway. To configure Host A in Figure 12-2 you add the following lines to its sysadm.ini file:

  1. Configure the ifeth0 interface:

    ifconfig ifeth0 129.158.110.333 netmask 0xffff0000 broadcast 129.158.255.255
    ifwait ifeth0
  2. Set a default route, since the router simulates a single network:

    route add default -iface ifeth0

As you can see, when configuring the hosts on the network you are required only to specify the IP address of that particular host and the IP address of the virtual network. There is no requirement to specify the exact IP address of the gateway, thus rendering the gateway transparent to all the individual hosts on the network.