On Wednesday, December 4, 2002, at 03:37 PM, Don Bowman wrote: [ ... ] > These are isp-sized routers (complicated networks with different
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.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.
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?
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.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.
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....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.
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?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.
-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
