arp-proxy

[Jon Otterholm]

The linux-soloution you are describeing is exactly what I want to do. 

Not a big fan of Linux though. I will have to wait for this to be ported
to BSD. Anyone with info if this is being done?

/Jon

On Thu, 2005-11-17 at 14:57 +0100, Jeremie Le Hen wrote:
> Hi, Jon, Brian,
> 
> > That depends...
> > 
> > In all this - our role is similar to an ISP, but we are buying access to
> > our customers from an external part. Every customer is delivered on a
> > separate vlan trunked. 
> > 
> > - Our DSL customers cannot be set on the same VLAN i a single DSLAM
> > (don't ask me why - ask Alcatel).
> > - We cannot build a simple bridge because the Network service provider
> > can't handle when a MAC-address shows up on 2 different VLAN's.
> > 
> > The arp-proxy should do the following:
> > - Forward any broadcast packets but rewrite src to its own mac.
> > - Forward unicast packets according to FDB but rewrite src to its own
> > mac.
> 
> IIUC, you want to do some kind of NAT of MAC addresses, this is not
> an easy task, because you can't keep connection states only based on
> the (src MAC, dst MAC) tuple.  You have to use at least IP addresses
> from the network layer or even TCP/UDP ports from the transport layer :
> 
> Let's take B your bridge and I, J, K three customers.
> When I wants to talk to J, once the packets emitted from I are on
> J's VLAN, the tuple based only on MAC address would be
> (src: B, dst: J).  If K also wants to talk to J, they would have
> the same tuple on J's VLAN.  Therefore we won't know where to send
> back replies from J.  This is the reason that requires upper layers
> to be taken into account.
> 
> Anyway FreeBSD, as weel as other BSD flavors, can't do this.  This is
> not implemented, and I'm not sure this is something we really want...
> 
> A more elegant solution to this kind of problem is what Linux calls
> "pseudo bridge" [1].  The idea is to configure all your customers to
> let them believe they all live in the same physical network (IOW as if
> their trunks were bridged).  The magic stands on the box linking
> them all together : you do not configure it as a bridge, but as a
> simple router which has one route for each customer pointing to the
> relevant VLAN.
> Then you set a sysctl named "proxy_arp" for each VLAN interface : this
> will ask the Linux kernel to check its routing table when it receives
> an ARP request.  If the requested IP address doesn't live on the same
> VLAN as the request came from, the kernel will send an ARP reply
> claiming it owns the requested IP address.
> 
> Therefore, the customer will believe he is talking directly to the
> computer whereas the packets will be routed, as if he was explicitely
> using a route.
> 
> I hope I have been clear enough.  IIRC the routing code and ARP code
> are currently rewritten in order to be splitted, it would maybe be
> worth to include this kind of functionnality at the same time.  It
> seems to have useful and concrete applications for providers.
> 
> Best regards,
> [1] http://www.sjdjweis.com/linux/proxyarp/