From: Eliezer Croitoru <eliezer@ngtech.co.il>
To: "Humberto Jucá" <betolj@gmail.com>
Cc: netfilter@vger.kernel.org
Subject: Re: A question about routing cache (for load balancing).
Date: Fri, 08 Nov 2013 00:03:06 +0200 [thread overview]
Message-ID: <527C0E1A.6050003@ngtech.co.il> (raw)
In-Reply-To: <CACuyg25xzoDS7wMyc8Ah=ZpoEvRoqbwgMMwA-vtetFFRU0Q9Wg@mail.gmail.com>
First thanks!
It helps to understand what was changed.
(notes in the email)
On 11/07/2013 10:59 PM, Humberto Jucá wrote:
> 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
This is the part when I got confused while trying to understand the
"ipv4 route cache removed".
ip route show cache will show "blank".
but when I run ip route get 201 I see the result with "cache".
>
> If you increase this value, all tests can result the same gateway in
> gc_interval period.
Are you talking about "before" the cache removal or "after"?
> 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
Which is not happens after 3.6 kernel and the cache removal.
try a nice example:
$ watch -d --interval=0.1 ip route get 200
and see what I am talking about.
OK so the next scenario:
Client: 192.168.1.1/24
Lan Router: 192.168.1.254/24
Lan Router wan side:192.168.100.254/24
Wan Router 1:192.168.100.1/24
Wan Router 1-wanip: 3.3.3.3
Wan Router 1:192.168.100.2/24
Wan Router 1-wanip: 4.4.4.4
Simple HTTP\SMTP\SSH\TCP server: 6.6.6.6
Client -> SYN --> Lan ROUTER: --> *WAN-router1*(which does NAT) --> BIG
INTERNET --> TCP server
TCP server SYN-ACK --> BIG INTERNET -> *WAN-router1*(NAT) --> Lan ROUTER
--> Client
Client -> ACK --> Lan ROUTER: --> *WAN-router2*(which does NAT) --> BIG
INTERNET --> TCP server
OK so now stop and feel the TCP server FW:
"Hmm what is this strange packet?? I think it's an invalid packet and
the sentence for this one is *DROP*"
In the application level it will be almost the same:
"Hmm I do not recall any existing connection from this IP so
*DROP*\ignore that"
For a simple router that handles internet traffic simple LoadBalancer
router will not have any effect but in the case of TCP load balancing I
am almost certain that IPTABLES will need do a thing or two about that.
Am I right about the direction of how it goes?
Thank,
Eliezer
>
> 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.
next prev parent reply other threads:[~2013-11-07 22:03 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-05 1:55 A question about routing cache (for load balancing) Eliezer Croitoru
2013-11-07 10:26 ` Humberto Jucá
2013-11-07 16:52 ` Eliezer Croitoru
2013-11-07 20:59 ` Humberto Jucá
2013-11-07 22:03 ` Eliezer Croitoru [this message]
2013-11-07 22:39 ` Neal Murphy
2013-11-07 23:53 ` Humberto Jucá
2013-11-08 0:02 ` Humberto Jucá
2013-11-08 0:39 ` Humberto Jucá
2013-11-08 1:23 ` Eliezer Croitoru
2013-11-08 2:29 ` Humberto Jucá
2013-11-08 2:35 ` Humberto Jucá
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=527C0E1A.6050003@ngtech.co.il \
--to=eliezer@ngtech.co.il \
--cc=betolj@gmail.com \
--cc=netfilter@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.