Support /
Knowledge Base

Multiple Gateways Configuration

A situation often encountered in practice is a network setup where the enterprise’s gateway is connected to more than one Internet Service Provider. In this case the normal approach of setting a single default gateway on the appliance will make use of a single provider. An ideal approach would be to define a composed default gateway rule which can specify more than one destination. Such a setup is presented here:

Figure 10-1

In the presented network environment, different requests are routed via different gateways but, during a connection’s lifetime – in the case of a connection oriented protocol like TCP, the packets tend to follow the same route. This must be so, otherwise it would be impossible to transfer data using such protocols over a default route with multiple gateways.

The problem that plagues most frequently such setups is unusable gateways. We would like to abide from using the word unreachable because sometimes they can be reached but they cannot be used from a variety of reasons: maybe their software is broken and cannot route the packets, maybe a firewall policy restricts the travel of our packets etc. In this case, the routing system should somehow detect the state of that gateway in a timely fashion, mark it as dead and reroute all the routes that were passing through it to exit through the other, reachable gateways. If this mechanism fails to function properly, all the connections/packets that would take the same path through that gateway would be lost and the end user will perceive a stalling in network connectivity. This would happen because the routes tend to have a certain persistence within the appliance’s routing table and, until the route isn’t flushed (that is, deleted) and a new one reinstated, the packets will be sent towards the dead gateway.

Setting Up a Second Gateway

Using the setup presented in Figure 9-1 that was used to illustrate the concept of multiple gateways, we consider in our scenario that the appliance has only ISP A’s router set as default gateway. Our task is to integrate the gateways of the other two ISPs in a multiple gateway default route. Log into the console and check the default route already defined:

# config gateway show
...
# config gateway add 10.0.0.1
# config gateway add 172.16.0.1 - 

# config gateway show
...

These gateway can be added only if you have networking provisions for them, that is, if they are on a directly connected network; otherwise, adding the gateway will fail. In this respect, the best way to use this feature is to have each default gateway on another physical interface of the appliance.

If you want that one of your gateways to be preferential, that is, most of the routes to go through it, using the other two just as a backup when the main pipe gets clogged, you can use the weight metric. By default, all gateways are added with a metric of 1 but a larger metric will improve that gateway’s position in the routing table, the end result being that that gateway will be solicited more often.

Deleting a gateway can be easily done if you specify it by IP:

# config gateway delete 10.0.0.1
# config gateway show
...

Setting Up Failover

In a hypothetical world none of the gateways will suffer any service disruption – they will be available permanently and will function without error. In the real world, nevertheless, this is not true and when this happens – that is, a disruption in the normal functioning of one or more gateways, we have to be prepared to deal with this. A worst case scenario, one for which we don’t have any solution, is when all gateways cease to work. But in any other scenario, if we have at least one functional gateway, with the help of the failover functionality, we can efficiently reroute all the traffic through it. Explanation: the failover functionality doesn’t start working only when we have a single gateway left; it works to compensate the loss of any number of gateways from your setup: if we have three gateways and we lose one, the traffic will be rerouted by the failover service through the remaining two; if we lose yet another one, the traffic will be automatically redirected through the only one left.

The problem any user will face at this point is to correctly select the way we determine that we lose a gateway. It seems to be a simple problem but in reality we can divide it into three cases:

(1) At the lowest level, we consider that we cannot access the gateway if we lose the connectivity on the network interface.

(2) In another case we can have physical connectivity with the gateway but something is not allowing the packets to travel beyond the gateways: filtering rules, the operating system running on the remote gateway is faulty etc.

(3) The third case appears when the filtering policy on the remote gateway doesn’t allow ALL the packets to travel – blocking the packets that are mandatory for a certain operation, i.e. blocking HTTP traffic.

Each of the three cases presented above need different parameters. All of them require an interval (in seconds) to poll the gateways. Sensible values are between 10 and 60 seconds. Monitoring the link layer (case 1) doesn’t need any other parameters. The second and third cases need a target host as parameter. This target host shouldn’t be any of the defined gateways – the purpose of the multiple gateways with failover system is to ensure that host A reaches host B not that host A can reach any of the gateway – it may be a situation when host A can reach all gateways but it cannot reach host B, which is the real target. This concept is illustrated in the next image:

Figure 10-2

In cases 2 and 3 the system will try to asses the capacity of reaching target B from target A through any of the defined gateways. Case 3 will specify, besides failover check interval and target host (which, by the way, can be a hostname or IP), a port number. Using the same illustration, in case 3 we want to ensure not only that packets travel from A to B but we want to ensure that packets destined for a special port (for TCP or UDP protocols only) will be able to pass.

Setup failover only for link layer (connectivity loss); the poll interval is 30 seconds: # config gateway failover 30:

# config gateway failover 30

Setup failover for layer 3 with a target host specified with an IP address (testing connectivity with ICMP ping packets):

# config gateway failover 10 172.16.8.45

Setup failover for layer 4, port 80 with a target host specified with a hostname (testing connectivity with connect()):

# config gateway failover 20 host.example.com 80 - 

Sourcerouting

Normal routing uses the destination address of an IP packet to make the routing decision. Sourcerouting, among other things, uses the source address of the IP packet to make the routing decision. Sometimes, sourcerouting is called policy routing because it can be used to implement a routing policy: if the source of the packet is A it will be sent through one hop and if the source of the packet is B it will be sent through another hop.

Here are a couple of situations where sourcerouting would be useful:

• You have two connections to the internet, a slow one and a fast one; you want the accounting department to exit through the slow connection while the development department would enjoy the amenities of the fast one. You can put all the accounting department computers in one subnet and, using sourcerouting, you can instruct your Syneto gateway to route all request originating the the accounting department through the slow path. The same thing can be done for the development department, redirecting the traffic through the fast link.
• Again, you have two connections to the internet, a slow one and a fast one; you want to segregate the smtp traffic (port 25) on the slow link while the web traffic, which has to be responsive, has to be routed through the fast link.

Configure Sourcerouting

Sourcerouting can be configured only from Syneto’s console. Access the console and consult the little help available for the sourcerouting functionality:

# config sourcerouting help

The help message shows the parameters accepted to the sourcerouting module and it’s a great as a quick reference. The only mandatory arguments are source address (network or host) and the gateway (which is always an IP).

Sometimes configuring sourcerouting can be confusing and the end result is spoiled because the person doesn’t have a clear image of what goes where. We feel that in this case giving a list of useful examples might help better than writing an exhaustive presentation on all and everything sourcerouting. Here we go with out examples:

# config sourcerouting add from 10.0.0.0/24 1.2.3.4 - 

# config sourcerouting add from 10.0.0.1 to 176.16.1.0/24 1.2.3.4 - 

# config sourcerouting add from 0.0.0.0/0 proto tcp port 80 1.2.3.4 - 

# config sourcerouting show - 

# config sourcerouting delete from 10.0.0.0/24 1.2.3.4 - 

# config sourcerouting edit from 0.0.0.0/24 proto tcp port 8080 1.2.3.4 - 

# config sourcerouting delete all -