On Thu, 15 Mar 2001 12:48:54 +0100 (MET), you wrote:
>> and activated the "CONFIG_IP_ROUTE_MULTIPATH". Then I've set up two
>
>interfaces, for as long as packets are exchanged over it. Note that the
>route-cache is keyed on the triple (src-address,dst-address,type-of-service).
Yes, I knew that. That was the reason I decided to test it. Note that
there is also a kernel patch to avoid this route cache (supposed to be
valid for "non-session handling" balancing) which is NOT valid for my
purposes.
But when I tested it (some time ago) I got some troubles. I'm
re-testing it.
These are the lines I added to my /etc/rc.d/route script:
/sbin/route del default 2> /dev/null
/usr/sbin/ip route add default equalize \
nexthop dev eth0 via 192.168.0.229 onlink \
nexthop dev eth0 via 192.168.0.230 onlink
My routing table stays as follow:
goliat:~ # ip route
192.168.3.0/24 via 192.168.0.230 dev eth0
192.168.2.0/24 via 192.168.0.230 dev eth0
192.168.1.0/24 via 192.168.0.230 dev eth0
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.200
127.0.0.0/8 dev lo scope link
default equalize
nexthop via 192.168.0.229 dev eth0 weight 1 onlink
nexthop via 192.168.0.230 dev eth0 weight 1 onlink
Let's suppose:
- 192.168.0.230 = Router 1
- 192.168.0.229 = Router 2
- 192.168.0.200 = the Linux Balancer machine (the one these logs
belong to)
If I understood all correctly with the above lines:
- machines at 192.168.x.0/24 -where x:=1,2,3- are reached using router
1 (I've done so because the above machines are only reachable via
router 1; router 2 is not valid here).
- machines at 192.168.0.0/24 (my local subnet) are reachable directly
via eth0.
- default gateways (the ones that will carry internet traffic) are
equally balanced between router 1 and router 2.
- it should maintain "sessions" (except the ones with changing TOS in
its IP packets).
Right?
>The last part of that key may bite you with your 'session handling', as at
>least one notable piece of client software, OpenSSH, changes the
>type-of-service somewhere during the session. Fortunately, the TOS field
>can be thwacked using ipchains or iptables so you can work around that...
1) Could you exemplify this TOS field "hacking"?
2) Which services are currently affected with TOS changes?
See (*)
3) Any other alternative apart from Multipath?
4) Anyone who is currently using the Multipath solution I've talked
about?
(*) At least FTP is affected!
goliat:~ # ftp 62.22.78.68
Connected to sniff.batmap.com.
220 Sniff FTP-Server ready
Name (62.22.78.68:roman):
421 Service not available, remote server has closed connection.
ftp: Login failed.
ftp: No control connection for command.
ftp>
If I sniff at 62.22.78.68 (ftp server):
16:31:57.564330 62.174.129.161.5665 > 62.22.78.68.ftp: S
2788746458:2788746458(0) win 32767 <mss 1460,sackOK,timestamp 343505
0,nop,wscale 0> (DF)
16:31:57.564363 62.22.78.68.ftp > 62.174.129.161.5665: S
2785652370:2785652370(0) ack 2788746459 win 32120 <mss
1460,sackOK,timestamp 805012719 343505,nop,wscale 0> (DF)
16:31:58.153962 62.174.129.161.5665 > 62.22.78.68.ftp: . 1:1(0) ack 1
win 65160 <nop,nop,timestamp 343564 805012719> (DF)
16:31:58.157026 62.22.78.68.dbreporter > 62.174.129.161.ident: S
2786506672:2786506672(0) win 32120 <mss 1460,sackOK,timestamp
805012778 0,nop,wscale 0> (DF)
16:31:58.572871 62.174.129.161.ident > 62.22.78.68.dbreporter: R
0:0(0) ack 2786506673 win 0
16:31:58.579242 62.22.78.68.neod2 > 194.98.65.65.domain: 15249+ PTR?
161.129.174.62.in-addr.arpa. (45)
16:31:58.613088 194.98.65.65.domain > 62.22.78.68.neod2: 15249 1/2/2
PTR 161-MAD2-X2.red.retevision.es. (185) (DF)
16:31:58.613986 62.22.78.68.telesis-licman > 62.174.129.161.ident: S
2784376363:2784376363(0) win 32120 <mss 1460,sackOK,timestamp
805012824 0,nop,wscale 0> (DF)
16:31:58.739687 0:2:b9:7a:87:4a > 1:0:0:0:0:0 sap aa ui/C
16:31:59.092067 62.174.129.161.ident > 62.22.78.68.telesis-licman: R
0:0(0) ack 2784376364 win 0
16:31:59.092245 62.22.78.68.ftp > 62.174.129.161.5665: P 1:29(28) ack
1 win 32120 <nop,nop,timestamp 805012872 343564> (DF)
16:31:59.133590 62.83.23.69.7167 > 62.22.78.68.ftp: .
2788746459:2788746459(0) ack 2785652399 win 65160 <nop,nop,timestamp
343662 805012872> (DF) [tos 0x10]
16:31:59.133617 62.22.78.68.ftp > 62.83.23.69.7167: R
2785652399:2785652399(0) win 0 [tos 0x10]
16:31:59.297491 0:2:b9:7a:87:4a > 1:0:0:0:0:0 802.1d ui/C
16:31:59.552596 62.83.23.69.7167 > 62.22.78.68.ftp: P 0:12(12) ack 1
win 65160 <nop,nop,timestamp 343704 805012872> (DF) [tos 0x10]
16:31:59.552613 62.22.78.68.ftp > 62.83.23.69.7167: R
2785652399:2785652399(0) win 0 [tos 0x10]
16:32:01.297944 0:2:b9:7a:87:4a > 1:0:0:0:0:0 802.1d ui/C
16:32:02.090026 62.22.78.68.ftp > 62.174.129.161.5665: P 1:29(28) ack
1 win 32120 <nop,nop,timestamp 805013172 343564> (DF)
16:32:02.126023 62.174.129.161.5665 > 62.22.78.68.ftp: R
2788746459:2788746459(0) win 0
16:32:02.560028 arp who-has 62.22.78.65 tell 62.22.78.68
(0:c0:26:a0:a4:63)
16:32:02.560946 arp reply 62.22.78.65 is-at 0:2:fd:8a:c7:e0
(0:c0:26:a0:a4:63)
16:32:03.300793 0:2:b9:7a:87:4a > 1:0:0:0:0:0 802.1d ui/C
Having a look at tcpdump's log, you can easily notice that:
1) 62.174.129.161 starts ftp session (control connection) (client
port: 5665)
2) 62.83.23.69 starts the ftp data session (because linux ftp client
starts with passive mode enable by default). Note the "[tos 0x10]"
mark. Effectively this connection has a different TOS!
These IP's belong to my two different outgoing routers. This is an
example of TOS problem.
What's the better way to achieve TOS uniformity? Is this a good idea
to use same TOS for *ALL* outgoing packets!????
Moreover, is this possible to make the "TOS translation" with
ipchains?? (remember I'm using 2.2 kernel!).
Well, enough for today, isn't it? :-))
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
** RoMaN SoFt / LLFB **
roman@xxxxxxxxxx
http://pagina.de/romansoft
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
