On Wednesday, December 4, 2002, at 05:33 PM, Don Bowman wrote: > From: Chuck Swiger [mailto:[EMAIL PROTECTED]] [ ... ]
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.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).
You want your machine (or load-balancer feeding a pool of server machines)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.
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.
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.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.
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?I don't have control of the content switching routers which feeds this. They work the way they do.
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.
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?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.
-Chuck
Chuck Swiger | [EMAIL PROTECTED] | 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
