Technical Blog Post
Abstract
IBM DataPower Gateways - Understanding Network Routing
Body
Note: Overall this discussion will assume default network settings on your DataPower Gateway. There are some settings which can be altered which affect routing decisions, but they are typically not recommended to be used.
How is the routing table formed?
The routing table is created by taking all static routes and any default gateways configured on your interfaces, regardless of the link state. For each interface you configure there is also an implicit route for the subnet that interface resides in. The below use case walks through example interface configuration and the resulting routing table.
Interface eth10:
primary IP: 9.0.0.100/24
default gateway: 9.0.0.1
Interface eth11:
primary IP: 10.0.0.100/24
default gateway: none
static route: 10.0.5.0/24 via 10.0.0.1
static route: 10.1.1.12/32 via 10.0.0.1
Resulting routing table:
idg(config)# show route
IP version Destination Prefix length Interface type Interface Next hop version Next hop Metric
-------------------------------------------------------------------------------------------
ipv4 0.0.0.0 0 Ethernet eth10 ipv4 9.0.0.1 200 // Created based on the default gateway of 9.0.0.1 on eth10
ipv4 9.0.0.0 24 Ethernet eth10 ipv4 0.0.0.0 0 // Implicit local route for subnet 9.0.0.0/24 which eth10 resides in
ipv4 10.0.0.0 24 Ethernet eth11 ipv4 0.0.0.0 0 // Implicit local route for subnet 10.0.0.0/24 which eth11 resides in
ipv4 10.0.5.0 24 Ethernet eth11 ipv4 10.0.0.1 0 // Static route for 10.0.5.0/24 via 10.0.0.1 over eth11
ipv4 10.1.1.12 32 Ethernet eth11 ipv4 10.0.0.1 0 // Static route for 10.1.1.12/32 via 10.0.0.1 over eth11
How does DataPower determine which route to use for backend connections?
Now that we have our routing table, we will explore how this is used to make routing decisions.
The first case we will discuss is when DataPower is acting as a client and is looking to establish a connection to another system. This could be DNS server, a syslog server, a backend web service which serves traffic over HTTPS, or any other number of cases. In all situations, DataPower will have a specific IP and port we are trying to open a connection to.
To determine which network interface should be used to establish this connection DataPower will use the routing table. The general logic for resolving the appropriate route is the following:
1) Find a route which when considering the destination and prefix length, matches the desired destination.
2) If multiple routes exist, the route with the stricter(higher) subnet mask is used.
3) If multiple routes exist with the same subnet mask, the lower metric is used.
4) If multiple routes exist with the same subnet mask and metric, the routing table is non-deterministic. There is no way to predict which route will be used, and either can be used by DataPower.
Note: The two most common ways to create a non-deterministic routing table are to configure multiple default gateways, or to configure multiple interfaces in the same subnet. These cases should both be avoided in almost all circumstances.
To illustrate this, we will walk through 3 scenarios using the above routing table.
Case 1: DataPower needs to connect to a DNS server which has the IP 10.0.5.25.
Route 10.1.1.12/32 does not match.
Route 10.0.5.0/24 does match (subnet: 24, metric 0).
Route 10.0.0.0/24 does not match.
Route 9.0.0.0/24 does not match.
Route 0.0.0.0/0 does match [this is the "default route" and will match in every case] (subnet: 0, metric: 200).
In this case, traffic to 10.0.5.25 will be routed through eth11 via the next hop router 10.0.0.1. Although 2 matches exist, the subnet mask of 24 takes precedence over the subnet mask of 0.
Case 2: DataPower needs to connect to a backend web server which has an IP of 9.0.0.50.
Route 10.1.1.12/32 does not match.
Route 10.0.5.0/24 does not match.
Route 10.0.0.0/24 does not match.
Route 9.0.0.0/24 does match (subnet: 24, metric: 0).
Route 0.0.0.0/0 does match [this is the "default route" and will match in every case] (subnet: 0, metric: 200).
In this case, traffic to 9.0.0.50 will be routed through eth10 directly without any next hop router, since these both reside in the same subnet.
Case 3: DataPower needs to connect to an NTP server which has an IP of 10.1.1.12.
Route 10.1.1.12/32 does match(subnet: 32, metric: 0).
Route 10.0.5.0/24 does not match.
Route 10.0.0.0/24 does not match.
Route 9.0.0.0/24 does not match.
Route 0.0.0.0/0 does match [this is the "default route" and will match in every case] (subnet: 0, metric: 200).
In this case, traffic to 10.1.1.12 will be routed through eth11 via the next hop router 10.0.0.1. Providing the subnet mask of 32 in this case only includes this 1 ip, rather than a range, and effectively ensures that eth11 will always be used for this destination.
How does DataPower determine which route to use to respond to incoming client connections?
When DataPower receives incoming connections from a client, the routing table is still used to determine how to route the response packets. The same general rules of routing apply in this case as they do in the case of outbound connections.
However, by default, DataPower will ONLY respond to the client via the same interface the packet was received. This means if traffic is sent to DataPower on eth11, it will only respond on eth11.
Please keep in mind that routing is still needed. If eth11 does not have any configured route which can be used to reach the client IP which sent the request, DataPower will have no way to route response packets, and will not be able to respond to the client connection request.
UID
ibm11285672