Re: arp-proxy
From: Jon Otterholm (jon.otterholm_at_ide.resurscentrum.se)
Date: 11/17/05
- Previous message: Volker: "Re: IPSEC, Watchguard SOHO 6tc and racoon"
- In reply to: Jeremie Le Hen: "Re: arp-proxy"
- Next in thread: Brian Candler: "Re: arp-proxy"
- Reply: Brian Candler: "Re: arp-proxy"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To: Jeremie Le Hen <jeremie@le-hen.org> Date: Thu, 17 Nov 2005 16:06:03 +0100
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/
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
- Previous message: Volker: "Re: IPSEC, Watchguard SOHO 6tc and racoon"
- In reply to: Jeremie Le Hen: "Re: arp-proxy"
- Next in thread: Brian Candler: "Re: arp-proxy"
- Reply: Brian Candler: "Re: arp-proxy"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
