Date:	Wed, 6 Jan 2010 23:22:31 +1030
From:	Mark Smith <lk-netdev@...netdev.nosense.org>
To:	hawk@...x.dk
Cc:	Eric Dumazet <eric.dumazet@...il.com>,
	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [net-next PATCH] net: RFC3069, private VLAN proxy arp support

On Wed, 06 Jan 2010 10:49:29 +0100
Jesper Dangaard Brouer <hawk@...x.dk> wrote:

> On Wed, 2010-01-06 at 07:03 +0100, Eric Dumazet wrote:
> > Le 05/01/2010 16:50, Jesper Dangaard Brouer a écrit :
> > > This is to be used together with switch technologies, like RFC3069,
> > > that where the individual ports are not allowed to communicate with
> > > each other, but they are allowed to talk to the upstream router.  As
> > > described in RFC 3069, it is possible to allow these hosts to
> > > communicate through the upstream router by proxy_arp'ing.
> > > 
> > 
> > Reading RFC 3069, I dont understand why it needs support on hosts
> > themselves.
> 
> They don't, this patch does NOT implement support on the hosts (most of
> the "hosts" in our ISP setup is peoples Windows machines).
> This is intended only to be used on the router.
> 
> 
> > > This patch basically allow proxy arp replies back to the same
> > > interface (from which the ARP request/solicitation was received).
> > 
> > Could you give me an example of how it is used ?
> 
> Okay, that first requires an understanding of our setup, then how we use
> it...
> 
> As an ISP we use this stuff on our Linux based Internet routers (these
> boxes are Ethernet Layer 2 connected via VLANs to the Ethernet switches
> in the customers apartment buildings).
> Our primary customers are entire apartment buildings, where we basically
> establish an Ethernet based network, which all apartments are connected
> to.
> 
> One big Ethernet based network gives a lot of problems with people
> misbehaving, viruses, broadcast packets and so on.  Thus, to solve these
> issues we shield every customer/ethernet-port from each other, by using
> RFC 3069 like switch technologies.
> 
> This seemed like a good solution, until customers started to run e.g.
> web-servers on their home PCs.  This meant that the entire Internet
> could browse their homepage, but they could not show it to their
> neighbor...
> 
> This patch solved the issue by doing proxy arp'ing on the router against
> the "local" network, thus making it possible for customers to
> communicate, but via the router.  This also gives the ability to do
> firewalling on the router between customers on an Ethernet. (In our
> solution the Linux router also have a personal firewall configurable per
> customer.)
> 

I can see value in that - you're forcing all traffic through the
upstream router for policy enforcement purposes, without having to have
point-to-point (simulated or otherwise) links between customers and the
router, and avoiding IP address waste by not using /30s. You're pretty
much making the ethernet a Non-broadcast Multi-Access link.



> It is simply enabled on an interface via e.g.:
> 
>  echo 1 > /proc/sys/net/ipv4/conf/eth2.1013/proxy_arp_pvlan
> 
> Hope that helps your understand the idea and usage :-)
> 
> -- 
> Med venlig hilsen / Best regards
>   Jesper Brouer
>   ComX Networks A/S
>   Linux Network Kernel Developer
>   Cand. Scient Datalog / MSc.CS
>   Author of http://adsl-optimizer.dk
>   LinkedIn: http://www.linkedin.com/in/brouer
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists