When that new route's interface limits are also exceeded then the route with the next highest
metric is taken and so on. As soon as any route with a lower metric falls below its interface limit
for its Hold Timer number of seconds, then it reverts to being the chosen route.
•
If there is no alternative route, the route does not change.
If the spillover limit is reached but all alternative routes have also reached their limit then the
route will not change.
The Requirement for Matching IP Ranges
As explained above, when RLB is assembling a list of matching routes from a routing table, the
routes it selects must have the same range. Balancing between routes will not take place if their
ranges are not exactly the same.
For instance, if one matching route has an IP address range of 10.4.16.0/24 and there is a second
matching route with an address range 10.4.16.0/16 (which is a range that includes 10.4.16.0/24) then
RLB will not take place between these routes. The ranges are not exactly the same so RLB will treat
the routes as being different.
It should also be remembered that route lookup will select the route that has the narrowest range that
matches the destination IP address used in the lookup. In the above example, 10.4.16.0/24 may be
chosen over 10.4.16.0/16 because the range is narrower with 10.4.16.0/24 for an IP address they
both contain.
RLB Resets
There are two occasions when all RLB algorithms will reset to their initial state:
•
After NetDefendOS reconfiguration.
•
After a high availability failover.
In both these cases, the chosen route will revert to the one selected when the algorithms began
operation.
RLB Limitations
It should be noted that the selection of different alternate routes occurs only when the route lookup
is done and it is based on the algorithm being used with the routing table used for the lookup and the
algorithm's state.
RLB cannot know how much data traffic will be related to each lookup. The purpose of RLB is to
be able to spread route lookups across alternatives on the assumption that each lookup will relate to
a connection carrying some assumed amount of traffic.
An RLB Scenario
Below is an illustration which shows a typical scenario where RLB might be used. Here, there is a
group of clients on a network connected via the LAN interface of the NetDefend Firewall and these
will access the internet.
Internet access is available from either one of two ISPs, whose gateways GW1 GW2 are connected
to the firewall interfaces WAN1 and WAN2. RLB will be used to balance the connections between
the two ISPs.
4.4. Route Load Balancing
Chapter 4. Routing
173
Summary of Contents for NetDefend DFL-260E
Page 27: ...1 3 NetDefendOS State Engine Packet Flow Chapter 1 NetDefendOS Overview 27...
Page 79: ...2 7 3 Restore to Factory Defaults Chapter 2 Management and Maintenance 79...
Page 146: ...3 9 DNS Chapter 3 Fundamentals 146...
Page 227: ...4 7 5 Advanced Settings for Transparent Mode Chapter 4 Routing 227...
Page 241: ...5 4 IP Pools Chapter 5 DHCP Services 241...
Page 339: ...6 7 Blacklisting Hosts and Networks Chapter 6 Security Mechanisms 339...
Page 360: ...7 4 7 SAT and FwdFast Rules Chapter 7 Address Translation 360...
Page 382: ...8 3 Customizing HTML Pages Chapter 8 User Authentication 382...
Page 386: ...The TLS ALG 9 1 5 The TLS Alternative for VPN Chapter 9 VPN 386...
Page 439: ...Figure 9 3 PPTP Client Usage 9 5 4 PPTP L2TP Clients Chapter 9 VPN 439...
Page 450: ...9 7 6 Specific Symptoms Chapter 9 VPN 450...
Page 488: ...10 4 6 Setting Up SLB_SAT Rules Chapter 10 Traffic Management 488...
Page 503: ...11 6 HA Advanced Settings Chapter 11 High Availability 503...
Page 510: ...12 3 5 Limitations Chapter 12 ZoneDefense 510...
Page 533: ...13 9 Miscellaneous Settings Chapter 13 Advanced Settings 533...
