OS/2 Routes - TCP/IP
Written by Tom Brown
This month's column is the first in a multipart tutorial on TCP/IP. As the first OS/2 Routes column to deal with an upper level protocol, TCP/IP seems like the logical choice for an Internet based publication.
The roots of TCP/IP belong to the UNIX world. IBM modeled the OS/2 implementation of TCP/IP very closely after the BSD-UNIX implementation of TCP/IP. Even today, few differences exist between the OS/2 and BSD based implementations of TCP/IP. This makes OS/2 a particularly strong IP platform.
TCP/IP consists of more than one protocol. In fact, TCP/IP is really a suite of many protocols. The real heart of TCP/IP is the Internet Protocol (IP) which is responsible for routing and all lower layer communication. There are three important protocols that sit on top IP: Transmission Control Protocol (TCP), User Datagram Protocol (UDP) and Internet Control Message Protocol (ICMP). ICMP is used almost exclusively by IP itself and not by applications. Due to the close marriage of IP and ICMP, ICMP is implemented as part of the IP code and is sometimes drawn as being part of the same layer as IP. We will get to each of these protocols during the course of this IP tutorial.
As the foundation layer of the TCP/IP suite of protocols, the IP layer is responsible for packet routing as well as delivering packets to the network interfaces.
IP addresses are 32 bit entities which are divided into four distinct bytes. These bytes are called octets (8 bits) in IP speak. By convention, an IP address is written a.b.c.d, where each letter will be replaced by the appropriate octet. While each octet has 256 possible values, there are two values with special meaning leaving 254 possible values for each position. Not surprisingly, the two special values are 0 and 255. In IP speak, 0 means 'any host' and 255 means 'every host'.
There are roughly four billion addresses in the Internet address space. This space is carved up into four main types of sub-spaces, called classes. Class A address spaces are the largest and Class D is the smallest. Here is the breakdown:
Class Definition Size ----- ---------- ------ A a.0.0.0 16M B a.b.0.0 65K C a.c.d.0 254 D a.b.c.d 1Fig. 1: IP address breakdown
The definition column shows letters where the Internic (Internet governing body) provides their part of the address definition and zeros where the network managers can supply their portion of the address. The class A address allows the network managers to supply three bytes (octets) of the address while the class D address is a single host definition providing no user definable portion. A class D address is what is obtained when dialling into an ISP using PPP as a single host. I understand that IBM owns the class A address 220.127.116.11. This means that any IP address with a first octet of 9 is an IBM address.
Given that 255 means 'every host', it makes sense that this can be used as the broadcast address. In order to broadcast a message to 'every host' in a class C subnetwork (subnet), a packet can be sent to the address a.b.c.255. A broadcasting to a class B address would end up looking like a.b.255.255. If you are familiar with the PING utility and you are on a LAN, you may want to try PINGing to every host in your subnet. What you will get in response to this is a roster of running hosts. Routers typically block broadcasts, so don't expect this to work across the Internet.
In the IP world, routers are often called gateways. While they are not technically the same thing, these two terms can be thought of as synonyms. IP routing is implemented as a value added process. It is not necessary for an IP router to know the specific path to the destination, it is only necessary for an IP router to know the next hop for any given packet. Once the packet is sent to the next hop, the next router will perform the same process. Thus, an IP router uses the destination address of a given packet to select a route to its next hop. Address matches are found in the routing table by searching using progressively wider match criteria. The first search will look for a class D match in the routing table and if this is not successful, the search will broaden to a class C and so on until the final search will be for a route which will match any host (0.0.0.0), often called the default route. If a match is found, it will be either a local interface in which the packet will be sent out, or it will be another address which will cause another search the same as the first, only for this new address.
This will be our example network:
Fig. 2: Example network
In the above diagram, boxes A, B and C are IP routers. Boxes X and Y are IP hosts. The top segment (18.104.22.168) is the segment that is used to connect the other three segments and as such, would likely be called the backbone segment. The routing tables might look something like this:
Router A IP Addresses = 22.214.171.124 & 126.96.36.199 Destination Next Hop ----------- ---------- 188.8.131.52 184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52 184.108.40.206 Router B IP Addresses = 220.127.116.11 & 18.104.22.168 Destination Next Hop ----------- ---------- 22.214.171.124 126.96.36.199 188.8.131.52 184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124 126.96.36.199 Router C IP Addresses = 188.8.131.52 & 184.108.40.206 Destination Next Hop ----------- ---------- 220.127.116.11 18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52 184.108.40.206 220.127.116.11 18.104.22.168 Host X IP Address = 22.214.171.124 Destination Next Hop ----------- ---------- 126.96.36.199 188.8.131.52 0.0.0.0 184.108.40.206 Host Y IP Address = 220.127.116.11 Destination Next Hop ----------- ---------- 18.104.22.168 22.214.171.124 0.0.0.0 126.96.36.199Fig. 3: Example routing tables
The first thing you might notice is that the hosts X and Y each have a routing table. Does this mean that they are IP routers? The answer is yes. What makes X and Y different from A, B and C is that X and Y are single homed routers and A, B and C are dual homed routers. This simply means that A, B and C each have two local segments to which they are attached. In fact, each of these boxes could well be an OS/2 machine with the difference being that A, B and C each would contain two network adapters. Not only is this possible, it is particularly smart given that OS/2 routes IP particularly well and makes a decent quality and very low cost router for many applications. It is even Simple Network Management Protocol (SNMP) manageable, for those who know what that means.
Let's say that host X wants to send a packet to host Y. Also, assume that X knows the address of Y (188.8.131.52). X does not know the specific route to Y. X knows only two routes. The class C subnet 184.108.40.206 is routed to address 220.127.116.11 which is the local ethernet address and everything else is routed to 18.104.22.168. Y is not part of the class C subnet to which X is connected, so this is not a match. The second route (the default route, 0.0.0.0 -> 22.214.171.124) will match any address, so this packet will now be sent to address 126.96.36.199. Address 188.8.131.52 is not a local interface however, so this address will need to be searched for as well. This time, address 184.108.40.206 matches the route 220.127.116.11 -> 18.104.22.168 because it is 'any host' in this subnet and the result is the address of the local interface. The packet that will eventually get to Y is sent to the local interface to the address 22.214.171.124 which is actually router A.
Continuing the example, A receives the packet destined to Y and looks up the address of Y (126.96.36.199) in its routing table. A match is found (188.8.131.52 -> 184.108.40.206) but it is not a local interface, so this match is compared to the routing table and is found to match a route which has a next hop which is a local port (220.127.116.11 -> 18.104.22.168). The packet is now sent to 22.214.171.124 which is actually router C.
Router C receives the packet and looks up the destination address (126.96.36.199) in its routing table. A match is found (188.8.131.52 -> 184.108.40.206) and it is a local interface so the packet is sent out this interface where it is picked up by Y.
This may all be a little confusing. Try working through this slowly. It is worth spending a little time and trying to get a good handle on this process. If you are an application developer, a basic knowledge of IP routing will help by allowing you to set up test networks and create configurations that closely match that of your clients. You never really know how your applictaions will perform until you try them on a real network.
The above example is interesting in that it is not too far from the real world. Perhaps you have an ethernet segment and would like to increase bandwidth by breaking it up into multiple segments. Maybe you have two or more offices and would like to join the networks. This could be done using OS/2 (or UNIX) machines, each configured with a PPP interface and a some serial communication hardware such as a modem.
IP Routing Implementation Specifics
OK. Now that we have some IP routing theory, how is this implemented under OS/2? The answer often confuses people due to its simplicity. Suppose we want to configure an OS/2 machine to be X in our above example. We need to configure the network interface, supply the routing table and we need to be able to query this information.
To configure an interface, we would use the interface configuration command IFCONFIG. It has one required parameter and that is the interface name. If the interface is the first ethernet card, the interface name will be lan0. If it is the first PPP interface, the name will be ppp0. Running IFCONFIG with only the interface name will return the current configuration.
Before we look at IFCONFIG, we need to discuss network masks. A network mask is used to indicate the bits of significance in an address. A class C address has 24 bits of significance consisting of the first three octets. A class C subnet mask would be 255.255.255.0. By using this notation, the network manager can create more than just the standard A, B and C subnets. Don't get too involved with wild subnet configurations until you are solid with the three classic classes of subnets.
Configuring an interface with an IP address might look like this: 'ifconfig lan0 220.127.116.11 netmask 255.255.255.0'. This configures the first LAN interface with the address 18.104.22.168 as part of a class C IP subnetwork. What this means is that this IFCONFIG statement will also add the route 22.214.171.124 -> 126.96.36.199 to the routing table.
Adding a route to the routing table is particularly easy. It can be done with the ROUTE command. Before we look at the ROUTE command though, we should discuss routing metrics. A routing metric is defined to be the number of hops to the destination including the current host. This means that if I am routing a packet to another machine attached to the same LAN as this machine, the other machine is one hop away. Perhaps this remote machine is the default gateway for the local subnet (eg: router A). The route could be added like this: 'route add default 188.8.131.52 1'. It really is this simple.
These commands and a few others can be found in a batch file called $(ETC)\setup.cmd. A machine can be reconfigured by editing this file, or the graphical TCPCFG tool can be used.
Extracting the routing table from an OS/2 machine can be done by simply running 'netstat -r'. This tells the NETSTAT application that you want to see the routing table. By running NETSTAT with the '-?' parameter, you will be able to see some of the other information that is available. Give this a try. A machine's MAC address can be obtained by running 'netstat -n'. This can be particularly useful in some environments.
One other point that may be of interest to some readers is the two batch files that the OS/2 IP subsystem calls if they exist. The first one is the file \TCPIP\BIN\B4TCP.CMD. This batch file will be run, if it exists, prior to the boot time setup and configuration of TCP/IP. If you want something to run before IP is configured, create a batch file and call it from here. The other file of note is \TCPIP\BIN\TCPEXIT.CMD. TCPEXIT.CMD is called, if it exists, once the IP stack is fully configured and running and any daemons that have been configured are started. It is not guaranteed that the daemons will be fully initialized, but it is guaranteed that IP will be up and running. TCPEXIT.CMD is a good place to put things that absolutely require IP to be up and configured before running such as the ADSM scheduler (when configured for IP) or any home cooked daemons which should be run at startup. This is also a good place to call an application that sets the PCs time clock from either a local time server or perhaps the NIST atomic clock. Keep in mind that TCPEXIT.CMD will not do a lot of good if your main connection is a serial connection to a service provider. TCPEXIT.CMD will not be called when a serial connection is made.
I would recommend that you back up any files before fiddling with their contents. Other than that, a lot can be learned by playing with configurations and trying things for yourself. It is worthwhile to read the IP documentation that comes with WARP. Between this column and the IP documentation that comes with WARP, it is fairly straight forward to configure a small network using only PCs, null modems and PPP.
Next month I will be continuing with the IP tutorial by covering TCP, UDP, ICMP and the loop back address. My goal is to keep this column as close to the real world as possible. Don't hesitate to drop me a note indicating the type of configurations you are interested in and perhaps I will use some of these requests as examples in future columns. Until then, have a happy and safe holiday season.