IBM DataPower Gateways - Understanding Network Routing
Chris Sloan 27000763MF Visits (18185)
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. 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.
Resulting routing table:
(Click table above to enlarge)
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:
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.
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 188.8.131.52.
Route 10.1.1.12/32 does not match.
In this case, traffic to 184.108.40.206 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).
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.
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.