2013/11/7 Eliezer Croitoru <eliezer@xxxxxxxxxxxx>:
> On 11/07/2013 12:26 PM, Humberto Jucá wrote:
> By load balance I am talking about Route load balance.
Yes, i understand it too. I think! rs
> OK so every 60 secs remove the old entries?
Yes, but...
This also depends of gc_timeout value.
The route system will check/flush the route cache every 60 secs
(gc_interval) and "update" into lb algorithm (round robin, by
default), so:
ip route add default \
nexthop via 10.1.1.1
nexthop via 10.1.2.1
echo 1 > /proc/sys/net/ipv4/route/gc_interval
This is the same as (every 1s):
echo 1 > /proc/sys/net/ipv4/route/flush
ip route get 200
# This probe result in 10.1.1.1
# wait 1s and
ip route get 201
# This probe result in 10.1.2.1
# wait 1s and
ip route get 202
# This probe result 10.1.1.1
If you increase this value, all tests can result the same gateway in
gc_interval period.
Each learned path will be maintained by gc_timeout.
But this path will be *checked* only every gc_interval.
The result for 200 will be the same until gc_timeout.
This time expire after *300s of inactivity*.
ip route get 200
ip route get 200
ip route get 200
This probe will return the same path: only 10.1.1.1
But, if you change gc_timeout to 1
echo 1 > /proc/sys/net/ipv4/route/gc_timeout
ip route get 200 # wait 1 or 2s
ip route get 200 # wait 1 or 2s
ip route get 200 # wait 1 or 2s
The result will be balanced - i consider this a aggressive load balance.
This is not so complicated in TCP (because the protocol is
connection-oriented), but is very much in UDP.
I refer to the persistence of connection, not the application. You
will certainly have problems with https and email sessions.
So, a larger value for gc_timeout will allow you a greater connection
persistence.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
