On Thu, 15 Mar 2001, RoMaN SoFt / LLFB !! wrote: > 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? Right. This is assuming no NAT and a single IP address for the linux balancer. > >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"? ipchains <yourmatchfields> -t 0x01 0x00 This simply sets the TOS to be equal on all packets that match the rest of the rule. > 2) Which services are currently affected with TOS changes? I have no idea. I know OpenSSH does, and is very weird in that, as it changes the TOS field on an *existing* TCP connection. > 3) Any other alternative apart from Multipath? Probably, but none that I have personal experience with. > 4) Anyone who is currently using the Multipath solution I've talked > about? One of X/OS's customers (X/OS, http://www.xos.nl/, is my employer) has a setup like you've described working with 3 ADSL modems and a cable modem. And yes, it seems to work without glitches. > (*) At least FTP is affected! [snip] > 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. This is not a very good example, as a new TCP connection is started. FTP is one of the services that is very tricky to deal with in such situations, precisely because of the separate control and data connections. But yes, the basic problem is the same as with OpenSSH: suddenly an extra entry appears in the route-cache, going out over a different gateway, breaking functionality. > What's the better way to achieve TOS uniformity? Is this a good idea > to use same TOS for *ALL* outgoing packets!???? Clearing the TOS should pose no problems whatsoever. > Moreover, is this possible to make the "TOS translation" with > ipchains?? (remember I'm using 2.2 kernel!). Yes. The -t option to ipchains does it. > Well, enough for today, isn't it? :-)) Quite. Back to coding... Doei, Arthur. -- /\ / | arthurvl@xxxxxxxxxx | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt / \/__ | you can dare to be yourself | Dance like there's nobody watching
