On Wed, 4 Dec 2002, Don Bowman wrote:
> > From: Julian Elischer [mailto:[EMAIL PROTECTED]] > > On Wed, 4 Dec 2002, Don Bowman wrote: > > > > Why does it think the source is local? are the routers below > > > > doing proxy > > > > arp? Did you give your interface a netmask of 0,0.0.0? > > > > > > > > Who responds to the arp? > > > > > > Its a layer-2 MAC rewrite, so it arrives on a local segment, but > > > subnetting rules don't apply. > > > No-one responds to the ARP, hence my problem :) > > > > Someone must be responding, because the SYN is eventually sent. > > Ah, its working currently with a single router. Adding the 2nd router > is breaking it. I currently have a default route back to the first > router. Adding the 2nd router, the back-path always goes through > the first router, which gets confused. (I'm using the term router, > but its actually a content switching device operating @ layer 4, > like cisco WCCP or Cisco CSM or nortel Alteon). > > > Here's my suggestion: > > > > write a netgraph node that does all the MAC rewriting. > > Code from the ng_bridge node would be useful. > > attach it to a ng_iface node. > > make the netgraph iface the default route. > > (route add default -iface ng0) > > Let me chew on that for a bit. I'm not sure where it would get the > destination mac from, wouldn't it have to cache the information > the PCB is holding? It gets the destination MAC address from the SRC AMC field of the preceding incoming packets with that IP src, dst and port combination.... i.e. the node would look within the IP header. > Wouldn't it be more efficient for me to > just create the ether-header when the SYN comes in, store it > in the PCB, and use that on each outgoing packet for that tcp > connection, add a sockopt (or use SO_DONTROUTE for this on the > listen socket)? yes and no... you would be breaking the layering in the standard code and you'd get crucified for it. start with the ng_bridge node and make it look within the IP header and use that information in it's hash tables instead of MAC addresses. It'll need some hosekeeping code too. (to flush old info, though you could reduce this by removing entries when you see the FIN packets go past.) > > Thanks for the great suggestions, keep them coming :) > > --don ([EMAIL PROTECTED] www.sandvine.com) > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
