From owner-freebsd-net Thu Dec 5 10:20:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9241837B401 for ; Thu, 5 Dec 2002 10:20:34 -0800 (PST) Received: from smtpout.mac.com (A17-250-248-89.apple.com [17.250.248.89]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2646943E9C for ; Thu, 5 Dec 2002 10:20:34 -0800 (PST) (envelope-from cswiger@mac.com) Received: from asmtp02.mac.com (asmtp02-qfe3 [10.13.10.66]) by smtpout.mac.com (8.12.2/MantshX 2.0) with ESMTP id gB5IKX80004377 for ; Thu, 5 Dec 2002 10:20:34 -0800 (PST) Received: from bust ([12.38.161.88]) by asmtp02.mac.com (Netscape Messaging Server 4.15) with ESMTP id H6NSA900.KOI for ; Thu, 5 Dec 2002 10:20:33 -0800 Date: Thu, 5 Dec 2002 13:20:32 -0500 Subject: Re: SO_DONTROUTE, arp's, ipfw fwd, etc Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) From: Chuck Swiger To: "'freebsd-net@freebsd.org'" Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <3DDA4578-087E-11D7-A933-000A27D85A7E@mac.com> X-Mailer: Apple Mail (2.482) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wednesday, December 4, 2002, at 05:33 PM, Don Bowman wrote: > From: Chuck Swiger [mailto:cswiger@mac.com] [ ... ] >> Yes, but the complicated internal routes maintained within >> those networks isn't your problem if your machine or network isn't BGP >> peering with them. > > It is in the sense that I have to figure out which one to send > data back to. More than one of them may 'own' a source address > at a given time (for a TCP session). If that is the case, then you either need to have a central point which knows which interface the original request came from, or you need to be able to send replies to a valid IP address back via any route which is up and offers reachability to the IP addr. >> Why? This sounds like a pretty classic example of A being on >> a multihomed network, and you should let IP-level routing deal with the >> problem. But there are alternatives, I guess-- maybe try putting a >> buncha >> interfaces on the BSD box, one for each router being connected to it, and >> put each pair on their own /30. That way, the BSD box can quite easily >> return the >> traffic back to the originating router.... > > Only if its routing, not for L2 redirection. You want your machine (or load-balancer feeding a pool of server machines) to send replies back via the "router it came from", right? If you're NAT'ing a bunch of traffic to a particular IP address on the router via the interface you connect to, why are you doing L2 rewriting? If you simply want your machine to "see" traffic not addressed to it, set the ethernet interface to promiscuous. > This is a transparent proxy. The proxy needs to know where the > real destination was (in case it needs to open a connection there). > The HTTP protocol solved this by putting the real-ip address in the > header, but most other protocols didn't. Sure; but the "real destination" isn't changed. (Unless you're re-writing that, too.) Your transparent proxy should be able to fetch the content from that location. > I don't have control of the content switching routers which feeds > this. They work the way they do. Fine. That means you don't have control over how the "content switching routers" route, NAT, rewrite, fold, spindle, or otherwise mutilate packets from "client", correct? They just send input packets to your part of the system, and you just need to feed replies back the same way. It's the "content switching routers" job to route (un-re-write, un-NAT, whatever) your replies. > Say for the sake of example you wished to load balance 2 farms > of telnet servers. You had a device which picked off port 23, > and sent it to you without alterations. You would then look @ the > intended destination address, and pick the right group of telnet > servers, and send the data there. Now say that those devices themselves > where load-balanced. So if a user telneted twice to the same destination, > one path might go through the first redirector, and one through the > 2nd. The path back is based on the path it came in. All of this can be handled by multihoming your redirector connections and using a dynamic link state protocol to detect failures, be it OSPF at layer 3 or spanning tree or whatever at layer 2. The redirectors *have* to communicate amongst themselves in order to distribute transactions around a downed redirector, right? -Chuck Chuck Swiger | chuck@codefab.com | All your packets are belong to us. -------------+-------------------+----------------------------------- "The human race's favorite method for being in control of the facts is to ignore them." -Celia Green To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message