Schowler Routes on the IBM iSeries

Resolving The Problem

The use of Schowler routes on the IBM iSeries allows the local outbound traffic to be controlled on a system where multiple TCP/IP interfaces are configured on the same subnet. The following are benefits for using Schowler routes:

o	Load balancing for local IP traffic
o	Prioritization of one local route over another
o	Host routes will now take precedence over what were formerly *DIRECT routes

Route selection (how and where the system sends outbound IP traffic) on the iSeries is done by processing or checking routes in a specific order. The destination IP address in the IP packet is used to determine the route that will be selected. The order is as follows:

Direct Routes:	These are routes that have a Next Hop value of *DIRECT (created automatically by the system based on an interface that was previously configured).
Host Routes:	These are routes to one specific host. In this case, the Subnet Mask value will be 255.255.255.255 or *HOST.
Indirect Routes:	These are routes that are created to route traffic to an entire network of hosts. These are sometimes referred to as "Network Routes" or "Subnet Routes".
Default Routes:	These are considered the "catch-all" routes so that if the IP packet in question does not find a match in the previous three types of routes, this route will be chosen.

Examples of each are below:

	Route Destination	Subnet Mask	Next Hop
Direct Route	10.1.1.0	255.255.255.0	*DIRECT
Host Route	172.16.1.41	*HOST	10.1.1.1
Indirect Route	172.18.3.0	255.255.255.0	10.1.1.2
Default Route	*DFTROUTE	*NONE	10.1.1.3

Note: The iSeries routing table is "system-wide" rather than based on a specific interface.

To have the ability to use the benefits of Schowler routes, your existing *DIRECT routes must be converted to Indirect routes (Showler routes). The following demonstrates the ability to perform outbound local load balancing:

For example, there are two TCP/IP interfaces on the system:

Internet Address	Subnet Mask	Line Description	Status
10.1.1.32	255.255.255.0	ETHLIN1	*ACTIVE
10.1.1.33	255.255.255.0	ETHLIN2	*ACTIVE

Based on these two interfaces, you will have two direct routes by default that the system adds automatically to the TCP/IP routing table:

Route Destination	Subnet Mask	Next Hop	Status
10.1.1.0	255.255.255.0	*DIRECT	*AVAILABLE
10.1.1.0	255.255.255.0	*DIRECT	*AVAILABLE

To create Showler routes, these *DIRECT routes must be replaced by adding two new routes to the system using the following commands:

ADDTCPRTE RTEDEST('10.1.1.0') SUBNETMASK('255.255.255.0') NEXTHOP('10.1.1.32') BINDIFC('10.1.1.32') DUPRTEPTY(6)

ADDTCPRTE RTEDEST('10.1.1.0') SUBNETMASK('255.255.255.0') NEXTHOP('10.1.1.33') BINDIFC('10.1.1.33') DUPRTEPTY(6)

Note: A DUPRTEPTY of 6 is used. This is for the load balancing configuration which will be discussed later.

After adding the above routes, the routing table (CFGTCP, Option 2) will look similar to the following:

Route Destination	Subnet Mask	Next Hop	Preferred Interface	Status
10.1.1.0	255.255.255.0	10.1.1.32	10.1.1.32	*AVAILABLE
10.1.1.0	255.255.255.0	10.1.1.33	10.1.1.33	*AVAILABLE

This completes the process of adding Schowler Routes. You can now use the advantages of Schowler routes that were mentioned at the beginning of this document.

In the above examples of running the ADDTCPRTE CL commands, we used a DUPRTEPTY (Duplicate Route Priority) of 6. This is what allows the system to do outbound local load balancing for the above two interfaces. To have the first one of these routes to have a higher precedence than the other, set the first one to have a DUPRTEPTY of 7, and leave the second one with a DUPRTEPTY of 6. This causes the system to select the first route for all local traffic unless that interface (10.1.1.32) goes inactive, rcypnd, rcycnl, or failed for any reason.

Another common use of Schowler routes is to force local traffic out of a specific interface. Without Schowler routes, the system always uses the first *DIRECT route that it reads from the routing table and will use the local interface that is dynamically bound to that route when sending to a local system. Because *DIRECT routes are the highest precedence route, there is no way to configure the system to use a preferred interface. However, by creating Schowler routes, these *DIRECT routes become Indirect routes and, therefore, other routes (for example, host routes) can be configured to have higher precedence than these Schowler routes.

An example follows (based on the above TCP/IP configuration). Another system (10.1.1.241) accepts only IP communications from the iSeries at address 10.1.1.33. Based on the current configuration, even though Schowler routes have been created, the system could use 10.1.1.32 or 10.1.1.33 to communicate to 10.1.1.241. However, because Schowler routes are implemented, a *HOST route can be added on the iSeries to 10.1.1.241 that is bound to the iSeries interface that we want to use (10.1.1.33). Below shows how the routing table (CFGTCP, Option 2) would look after making this change:

Route Destination	Subnet Mask	Next Hop	Preferred Interface	Status
10.1.1.241	*HOST	10.1.1.33	10.1.1.33	*AVAILABLE
10.1.1.0	255.255.255.0	10.1.1.32	10.1.1.32	*AVAILABLE
10.1.1.0	255.255.255.0	10.1.1.33	10.1.1.33	*AVAILABLE

At this time there will not be any question regarding which route will be used when the iSeries is required to communicate with 10.1.1.241. The system will always select the newly added *HOST route and, therefore, will use 10.1.1.33 as its source address.

Schowler routes should never be used to violate IETF Request for Comments (RFC) standards.