Date: Wed, 4 Dec 2002 16:16:44 -0500 From: Chuck Swiger <cswiger@mac.com> To: Don Bowman <don@sandvine.com> Cc: "'freebsd-net@freebsd.org'" <freebsd-net@FreeBSD.ORG> Subject: Re: SO_DONTROUTE, arp's, ipfw fwd, etc Message-ID: <B0A07548-07CD-11D7-A933-000A27D85A7E@mac.com> In-Reply-To: <FE045D4D9F7AED4CBFF1B3B813C85337010230F8@mail.sandvine.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, December 4, 2002, at 03:37 PM, Don Bowman wrote:
[ ... ]
> These are isp-sized routers (complicated networks with different
> peering points to other networks). Static routes don't work since
> they are much too dynamic. Additionally, the widget which is
> picking the traffic to send (like Cisco WCCP) is load-balancing,
> so there's another striping of data going on.
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.
> I'd like to just send it back to the router it came from.
> I won't have a single TCP session come from more than one router,
> but will have the same source or destination IP come from the different
> routers concurrently.
So these routers are multihomed in practice?
> I'm not sure what you mean by policy-based routing. If its the same
> thing as on a router, then its not appropriate since it will be
> based on IP.
Huh? Determining which network interface to send a packet is exactly what
a layer-3 router _does_...it uses the IP address to decide how to route
the packet. Anyway, I meant things like dynamic routing protocols (RIP,
RIPv2, OSPF, BGP, etc) via something like gated.
> In the example diagram above, I might have a case where host 'A'
> sends host 'B' two concurrent TCP sessions. These will both transparently
> arrive @ the BSD box, one via router1, one via router2. Triangulation
> breaks the application, so A->B(session1) needs to always flow via
> the same router it started on.
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....
> I'm thinking this is achieved by just caching the interface & destination
> MAC etc in the PCB for the TCP session. It does this anyway once its
> finished sending the SYN/ACK, its just that it follows routing rules and
> ARP's for the SYN/ACK.
Yes. Pretending machines which are on remote networks are local can be
done by re-writing MAC addresses, but that can be achieved by NAT or VPN
solutions as well. Why are you trying to override normal routing behavior
when you probably can use it to help solve the problem?
-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?B0A07548-07CD-11D7-A933-000A27D85A7E>