Websphere DataPower SOA

Appliances - Routing Resolution

Models and Fundamentals
Introduction
This document discusses the fundamentals of network level routing at Layer 4 and
below of the OSI Basic Reference Model (http://en.wikipedia.org/wiki/OSI_model) as it
applies to IBMs Websphere DataPower SOA Appliance products. SOA Appliances are
a purpose built hardware/software solution that address many aspects of high speed
data processing, security and integration.
This document also makes use of the Classless Inter-Domain Routing notation (CIDR).
For more information on CIDR please visit http://en.wikipedia.org/wiki/CIDR.

ra

ft

For reliable network operation, Websphere DataPower SOA Appliances must be set up
with a deterministic routing configuration. A configuration which results in nondeterministic routing (equal weigh routes) will result in unpredictable network operation.
The remainder of this document focuses on the principles and techniques required to
ensure a deterministic routing configuration on the SOA Appliance platform.

Fundamental Device Principles

Websphere DataPower SOA Appliances operate almost exclusively as a nontransparent Layer 7 protocol proxy, handling only an explicit number of protocols such
as HTTP (HTTPS) and FTP (FTPS). Although they appear to pass data or messages
from one network segment to another, they accomplish this by terminating an inbound
TCP connection, introspecting message based data, and creating a separate and
distinct TCP connection from the device to a destination host.
SOA Appliance devices DO NOT route IP packets directly. They employ a high degree
of interface isolation which is controlled by configuration, but they will not connect two
network segments for random protocols. A protocol specific proxy service must be
configured on the device in order to pass any data through the device to a destination
host.
For some supported protocol types - namely asynchronous messaging protocols such
as IBM MQ Series, IBMs Websphere Messaging Engine, or Tibcos EMS protocol
- the device does not act as a protocol proxy at all but instead is responsible for
establishing TCP level connections to support both the ingress and egress message
path associated with an integration service.

Routing Models
SOA Appliances operate on one of two models with respect to network packet routing.
These models are Source Based Routing and Destination Based Routing. SOA
Copyright IBM Corp. 2008

Appliance configuration specifies a Source Based Routing model by default but either
model can be selected by changing the Destination Based Routing configuration option
found in the Network > Network Settings menu of the SOA Appliance WebGUI interface.
This option is set to OFF by default (indicating a Source Based Routing model) but can
be changed to ON to invoke the Destination Based Routing behavior.
As an alternative you can execute the destination-routing command from the configure
terminal > network menu context in the CLI interface on your appliance.
Source Based Routing vs. Destination Based Routing: these models refer exclusively to
the behavior of response TCP packets as part of a TCP session that is initiated by an
external host. This parameter only effects the determination of how the device should
respond to INBOUND connections. Take the following example:
ETH0 - 192.168.1.1/24; Default Gateway 192.168.1.254
ETH1 - 10.1.1.1/24; Default Gateway 10.1.1.254
A host at 10.1.1.2 sends a TCP SYN packet to 192.168.1.1 (ETH0).
(ETH0)
(ETH1)
(ETH0)
(ETH1)

ra

ft

The devices routing table contains:

0.0.0.0/0 through 192.168.1.254
0.0.0.0/0 through 10.1.1.254

192.168.1.0/24 through 192.168.1.1
10.1.1.0/24 through 10.1.1.1

Source Based Routing (Destination Based Routing OFF) - The devices routing table
will still be referenced but limited only to routing table entries associated with ETH0
because that is the interface of the ingress packet. The device will send a SYN/ACK
packet out 192.168.1.1 and that packet will be routed through 192.168.1.254 as per the
default route on ETH0. Packets for this TCP session are guaranteed to be sent using
ETH0 because this is the interface of the session initiation.
Destination Based Routing (Destination Based Routing ON) - The devices entire
routing table will be referenced to determine the best interface/route for packets
associated with this TCP session. The device will send a SYN/ACK packet out 10.1.1.1
using ETH1 based on the entire routing table contents of the device. No preference is
given to ETH0 even though that is the interface that the connection attempt was initiated
on.

Outbound Connection Routing

This section applies to all new TCP sessions established from the device to an external
host on the network. All ethernet interfaces (ETH0, ETH1, ETH2, MGT0/ETH4) abide by
these global rules for outbound routing.
Implicit routes - all interfaces configured with an IP address on the SOA Appliance will
create an implicit route to that local subnet through the IP address of the interface itself.
When ETH0 is configured with 192.168.1.1/24 there is implicitly a route to the entire
Copyright IBM Corp. 2008

192.168.1.0/24 subnet (192.168.1.1-192.168.1.254) through the IP address defined on

the interface. The gateway for this subnet is going to be the local IP address itself
because the assumption is that all hosts in this subnet are reachable within 1 network
hop.
The implicit route in this example is: 192.168.1.0/24 through 192.168.1.1
Whenever a default gateway is added to any of the interface configurations on the
device, this will add an implicit route of 0.0.0./0 to the devices routing table. The
destination for this route will be the IP address of the default gateway specified.
The default route in this example is: 0.0.0.0/0 through 192.168.1.254
All new outbound connections initiated by the device will use the device's complete
routing table (no interface preference) and determine the route based on the most
specific match it finds in the routing table. Consider the following:

ra

The devices routing table contains:

0.0.0.0/0 through 192.168.1.254
0.0.0.0/0 through 10.1.1.254
192.168.1.0/24 through 192.168.1.1
10.1.1.0/24 through 10.1.1.1

ft

ETH0 - 192.168.1.1/24; Default Gateway 192.168.1.254

ETH1 - 10.1.1.1/24; Default Gateway 10.1.1.254
The device receives an HTTP request on 192.168.1.1. The back side of the receiving
service is set to proxy it's requests to 10.7.7.7.

In this configuration, with no static routes the device has two equal weight routing paths
to the 10.7.7.x network. One on ETH0 through its 192.168.1.254 gateway, and one
through ETH1 through its 10.1.1.254 gateway. The device will randomly choose one of
these two routes because they are equally specific (or in this case non-specific).
However, if we add a static route to the configuration we can force it to choose a
specific interface. Now consider this:
ETH0 - 192.168.1.1/24; Default Gateway 192.168.1.254
ETH1 - 10.1.1.1/24; Default Gateway 10.1.1.254; Static route to 10.7.7.0/24
The devices routing table now contains:
0.0.0.0/0 through 192.168.1.254
0.0.0.0/0 through 10.1.1.254
192.168.1.0/24 through 192.168.1.1
10.1.1.0/24 through 10.1.1.1
10.7.7.0/24 through 10.1.1.254

Copyright IBM Corp. 2008

With this addition, the device will choose to make it's outbound connection from the
10.1.1.1 interface because the static route attached to that interface is more specific
than the default gateway route (0.0.0.0/0) attached to ETH0.
What is the "most specific route"? Basically the one with the smallest mask where a
destination IP address falls in it's range. For example:
10.0.0.0/8
10.7.0.0/16
10.7.7.0/24
10.7.7.7/32
These are all examples of static route addresses/masks that are increasingly specific.
They all represent subnets that 10.7.7.7 can be found in, but the last one would be
chosen first because it is the most specific mask (/32 is equal to 255.255.255.255 or
JUST the IP address 10.7.7.7).

ra

The routing table would contain:

0.0.0.0/0 through 192.168.1.254
0.0.0.0/0 through 10.1.1.254
192.168.1.0/24 through 192.168.1.1
10.1.1.0/24 through 10.1.1.1
10.7.7.0/24 through 10.1.1.254
10.7.7.7/32 through 192.168.1.254

ft

If we were to add a static route to 10.7.7.7/32 to ETH0 in the previous example, that
would be more specific than the 10.7.7.0/24 route entry on ETH1 and subsequently
ETH0 (192.1.1.1) would be chosen as the interface for the outbound connection to
10.7.7.7.

Summary

Summary concepts from this document include:

Websphere DataPower SOA Appliances are not general purpose IP routers and only
explicitly proxy configured protocols.
Websphere DataPower SOA Appliances support both Source Based Routing and
Destination Based Routing models.
Outbound TCP routing resolution is based on a deterministic routing table. Nondeterministic routes (ties) result in unpredictable packet paths.
When it comes to deterministic routing - the most specific route always wins.
For more information on Websphere DataPower SOA Appliance operation please visit
the product support site at:
http://www-01.ibm.com/software/integration/datapower/support/

Copyright IBM Corp. 2008