arp-proxy

[Jeremie Le Hen]

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/
-- 
Jeremie Le Hen
< jeremie at le-hen dot org >< ttz at chchile dot org >