Date: Thu, 5 Dec 2002 13:20:32 -0500 From: Chuck Swiger <cswiger@mac.com> To: "'freebsd-net@freebsd.org'" <freebsd-net@FreeBSD.ORG> Subject: Re: SO_DONTROUTE, arp's, ipfw fwd, etc Message-ID: <3DDA4578-087E-11D7-A933-000A27D85A7E@mac.com> In-Reply-To: <FE045D4D9F7AED4CBFF1B3B813C85337010230FE@mail.sandvine.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DDA4578-087E-11D7-A933-000A27D85A7E>