On Sun, 28 Oct 2001 16:56:43 +0000 (GMT) Julian Anastasov <ja@xxxxxx> wrote: > On Sun, 28 Oct 2001, Christoph Simon wrote: > > > On Sun, 28 Oct 2001 07:28:53 -0600 > > "David" <maniacdavid@xxxxxxxxxxxx> wrote: > > > > > I'm trying to get my AOL IM'r to work consistenly with 2 cable modems. It > > > seems like it says it can't connect (90% of the time, 10% it works, just > > > pure luck) when I have both of the cable modems working together with this > > > iproute command > > This is a problem for the routing and the way it is used from NAT. > > > > ip route default equalize nexthop via ***.***.***.*** dev eth0 nexthop via > > > ***.***.***.*** dev eth2 > > > iptables -A POSTROUTING -t nat -j MASQUERADE -o eth2 > > > iptables -A POSTROUTING -t nat -j MASQUERADE -o eth0 > > I'm not sure Netfilter can work with multipath routes correctly. > Only TCP can work correctly: rerouting after cache entry expiration, etc. > > OTOH, every usage of multipart routes should take care whether > the different gateways allow traffic with the used source addresses > to pass through all paths. The key in using multipath routes is teaching > the NAT code to correctly use the right source addresses when sending > to each path from the multipath routes, especially when they provide > you with distinct public IP ranges. If someone thinks that this should > work by magic, without coding such feature, he is in wrong direction. When I saw David's message, I didn't even think about this (as in my case it brakes much earlier). But as AIM is usually very low traffic, I guess my suggestion to direct it only to one interface was not that wrong. Unless this is a major AIM gateway, I don't think any coding (and getting incompatible with the rest of linux kernels) would not be worth the efford. > Chris, did you asked the Netfilter gurus for such features? [I > hope you received my email from October 20] No, unfortunately, I didn't receive any answer. This is odd, as I'm using email quite frequently, also receiving answers, which makes my think that my return address should be correct. But knowing my ISP and Mr. Murphies Law, anything specially interesting has a great probability to fail. > > if I did understand it well, the usage of the `equalize' argument to > > ip makes the selection of a particular interface packet based, while > > the omission should make it session base. I have tried all > > I'm not sure the equalize patch is into the mainstream kernel. I'm using only standard kernels, currently 2.4.9 and 2.4.12-acX. As I've tried to use equalize and didn't get an error message, so it should be working. But I have done hundrets of tests, so it is easy that I oversaw or don't recall something. > > combinations I'm aware of, including weight'ing of the nexthops, and > > it did not work. HTTP based Internet access will fail with any more or > > less elaborated site, as requests will come from more than one > > IP. This doesn't mean that session oriented interface selection > > doesn't work (which I can't tell for sure); it just means that certain > > subsequent complete user sessions need to use the same IP. This might > > be the reason why AIM isn't working, as it seems to expect always the > > same IP from you. > > IMO, Netfilter should be teached to use destination cache and > multipath routes. I already have it completely working for Linux 2.2 > masquerade (5 patches) but for 2.4 I'm at 60% (3 of 5 patches): I'm forced to use 2.4 kernels for not networking, hardware dependant reasons. So it's a pitty that the 2.4 patch isn't finished yet as i'd loved to try it, but if you want, I would be gladly willing to help testing. What are the chances that this will be introduced to the main stream kernel sources? > http://www.linuxvirtualserver.org/~julian/ > Under the already incorrect title "Dead Gateway Detection" I do have a problem understanding this: Let me take a concrete situation as an example: I have a firewall with three interfaces, one to the LAN and two to the DSL modems. There is a server behind running squid. All clients on the LAN are configured to use squid for Internet access; no forwarding is done beside for the server itself. If there is a destination cache, all connections to the same server would go through the same interface. Is this right? There ares some very important sites which are visited (according to squid reports) by up to 80% of clients and time (not every day and not always the same, but it happens frequently). Those sites also use load balancing (the same address resolves to many IPs). If I understood right, one session is the set of packets which are exchanged between a connect and a close statement. From the HTTP point of view (including cookies and IP tracking) however, a session can be from the first access until the user explicitly closing of the session, or a timeout of inactivity happens. I have observed that within an HTTP session to that site, the destination IP does change (but not within a session in the sense of connect-close). In this very situation, how can the destination cache tell that the following connect (i.e., a new tcp session) is part of an already existing HTTP session or that the proxy is doing this in name of a different user or workstation on the LAN? Unless I missed something really important, I would suppose that those 80% would have to go through the same interface, and that HTTP sessions will break each time a session is opened on a different destination IP for the same DNS name. I also can't imagine that it would help to store in the destination cache the network addresses rather than destination addresses, as the IPs corresponding to those sites are not continuous, and there are others in the middle which exist and would go to different services and/or sites. OTOH, even if not `load balancing', at least it would avoid breaking complex HTTP sessions. For my understanding, the solution would be an extension to the RELATED attribute of a packet, similar as for FTP where a secondary connection is built, although it must be much more difficult. -- Christoph Simon datageo@xxxxxxxxxxxx --- ^X^C q quit :q ^C end x exit ZZ ^D ? help NO CARRIER .
