All of lore.kernel.org
 help / color / mirror / Atom feed
* [Bridge] RFC: Simple Private VLAN impl.
@ 2009-06-10 13:32 Joakim Tjernlund
  2009-06-10 14:45 ` Stephen Hemminger
  0 siblings, 1 reply; 31+ messages in thread
From: Joakim Tjernlund @ 2009-06-10 13:32 UTC (permalink / raw)
  To: bridge


Even though some folks on this list thinks ebtables should be used
to deploy Private VLAN I find using ebtables a bit clumsy.

So here a first simple(RFC only) Private VLAN impl. for only Promiscuous and Isolated
mode for the linux bridge. Not tested yet.

 Jocke


diff --git a/net/bridge/br_forward.c b/net/bridge/br_forward.c
index d2c27c8..c10362c 100644
--- a/net/bridge/br_forward.c
+++ b/net/bridge/br_forward.c
@@ -18,11 +18,30 @@
 #include <linux/netfilter_bridge.h>
 #include "br_private.h"

-/* Don't forward packets to originating port or forwarding diasabled */
-static inline int should_deliver(const struct net_bridge_port *p,
+/* Don't forward packets to originating port or forwarding disabled.
+ * Don't froward packets between private VLAN's in ISOLATED mode.
+ */
+static inline int should_deliver(const struct net_bridge_port *to,
 				 const struct sk_buff *skb)
 {
-	return (skb->dev != p->dev && p->state == BR_STATE_FORWARDING);
+	struct net_bridge_port *from = rcu_dereference(skb->dev->br_port);
+
+	if (skb->dev == to->dev || to->state != BR_STATE_FORWARDING)
+		return 0;
+	if (to->priv_vlan == PVLAN_ISOLATED &&
+	    from->priv_vlan == PVLAN_ISOLATED)
+		return 0;
+	return 1;
+}
+
+int br_set_private_vlan(struct net_bridge_port *p,
+			unsigned long v)
+{
+	if (!(v == PVLAN_ISOLATED ||
+	      v == PVLAN_PROMISC))
+		return 1;
+	p->priv_vlan = v;
+	return 0;
 }

 static inline unsigned packet_length(const struct sk_buff *skb)
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index b6c3b71..6f63b7f 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -30,6 +30,10 @@
 /* Path to usermode spanning tree program */
 #define BR_STP_PROG	"/sbin/bridge-stp"

+/* Private VLAN defs */
+#define PVLAN_PROMISC 0
+#define PVLAN_ISOLATED 1
+
 typedef struct bridge_id bridge_id;
 typedef struct mac_addr mac_addr;
 typedef __u16 port_id;
@@ -67,6 +71,7 @@ struct net_bridge_port
 	/* STP */
 	u8				priority;
 	u8				state;
+	u8				priv_vlan;
 	u16				port_no;
 	unsigned char			topology_change_ack;
 	unsigned char			config_pending;
@@ -175,6 +180,7 @@ extern void br_forward(const struct net_bridge_port *to,
 extern int br_forward_finish(struct sk_buff *skb);
 extern void br_flood_deliver(struct net_bridge *br, struct sk_buff *skb);
 extern void br_flood_forward(struct net_bridge *br, struct sk_buff *skb);
+extern int br_set_private_vlan(struct net_bridge_port *p, unsigned long v);

 /* br_if.c */
 extern void br_port_carrier_check(struct net_bridge_port *p);
diff --git a/net/bridge/br_sysfs_if.c b/net/bridge/br_sysfs_if.c
index 02b2d50..aaaa085 100644
--- a/net/bridge/br_sysfs_if.c
+++ b/net/bridge/br_sysfs_if.c
@@ -143,6 +143,18 @@ static ssize_t store_flush(struct net_bridge_port *p, unsigned long v)
 }
 static BRPORT_ATTR(flush, S_IWUSR, NULL, store_flush);

+static ssize_t show_private_vlan(struct net_bridge_port *p, char *buf)
+{
+	return sprintf(buf, "%d\n", p->priv_vlan);
+}
+static ssize_t store_private_vlan(struct net_bridge_port *p, unsigned long v)
+{
+	return br_set_private_vlan(p, v);
+}
+static BRPORT_ATTR(private_vlan, S_IRUGO | S_IWUSR,
+		   show_private_vlan, store_private_vlan);
+
+
 static struct brport_attribute *brport_attrs[] = {
 	&brport_attr_path_cost,
 	&brport_attr_priority,
@@ -159,6 +171,7 @@ static struct brport_attribute *brport_attrs[] = {
 	&brport_attr_forward_delay_timer,
 	&brport_attr_hold_timer,
 	&brport_attr_flush,
+	&brport_attr_private_vlan,
 	NULL
 };



^ permalink raw reply related	[flat|nested] 31+ messages in thread

* Re: [Bridge] RFC: Simple Private VLAN impl.
  2009-06-10 13:32 [Bridge] RFC: Simple Private VLAN impl Joakim Tjernlund
@ 2009-06-10 14:45 ` Stephen Hemminger
  2009-06-10 15:32   ` Joakim Tjernlund
  0 siblings, 1 reply; 31+ messages in thread
From: Stephen Hemminger @ 2009-06-10 14:45 UTC (permalink / raw)
  To: Joakim Tjernlund; +Cc: bridge

On Wed, 10 Jun 2009 15:32:06 +0200
Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:

> 
> Even though some folks on this list thinks ebtables should be used
> to deploy Private VLAN I find using ebtables a bit clumsy.
> 

I prefer ebtables be used to "patch" bridge to do these kind
of special case things.  Remember any code that is put in mainline
adds additional API's and long term support burden.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Bridge] RFC: Simple Private VLAN impl.
  2009-06-10 14:45 ` Stephen Hemminger
@ 2009-06-10 15:32   ` Joakim Tjernlund
  2009-06-10 16:27     ` Ross Vandegrift
  2009-06-11 19:51     ` Daniel Robbins
  0 siblings, 2 replies; 31+ messages in thread
From: Joakim Tjernlund @ 2009-06-10 15:32 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: bridge

Stephen Hemminger <shemminger@vyatta.com> wrote on 10/06/2009 16:45:42:
>
> On Wed, 10 Jun 2009 15:32:06 +0200
> Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
>
> >
> > Even though some folks on this list thinks ebtables should be used
> > to deploy Private VLAN I find using ebtables a bit clumsy.
> >
>
> I prefer ebtables be used to "patch" bridge to do these kind
> of special case things.  Remember any code that is put in mainline
> adds additional API's and long term support burden.

I am not sure this is so special anymore. I know that this
adds "support burden" but so does a lot of stuff in the kernel.

Have anybody managed to do Private VLAN with several switches by
just using ebtables? Seems like most people here thinks that
ebtables is the right tool but none has provided any examples
on how to do it so I am starting to think that noone is so the
claim to just use ebtables might be false.

 Jocke


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Bridge] RFC: Simple Private VLAN impl.
  2009-06-10 15:32   ` Joakim Tjernlund
@ 2009-06-10 16:27     ` Ross Vandegrift
  2009-06-10 17:09       ` Joakim Tjernlund
       [not found]       ` <OF4422F49E.33BDAF5C-ONC12575D1.005C802A-C12575D1.005E38A3@LocalDomain>
  2009-06-11 19:51     ` Daniel Robbins
  1 sibling, 2 replies; 31+ messages in thread
From: Ross Vandegrift @ 2009-06-10 16:27 UTC (permalink / raw)
  To: Joakim Tjernlund; +Cc: Stephen Hemminger, bridge

On Wed, Jun 10, 2009 at 05:32:06PM +0200, Joakim Tjernlund wrote:
> I am not sure this is so special anymore. I know that this
> adds "support burden" but so does a lot of stuff in the kernel.

Private VLANs are additional restrictions on a bridge's filtering
database.  No kernel support is required because Linux (via ebtables)
has a much more generic way to affect the filtering of frames.

> Have anybody managed to do Private VLAN with several switches by
> just using ebtables? Seems like most people here thinks that
> ebtables is the right tool but none has provided any examples
> on how to do it so I am starting to think that noone is so the
> claim to just use ebtables might be false.

I don't have a Linux machine with enough interfaces to build a
meaningful private VLAN config, but I can step you though a simple
conceptual explanation.

One very common installation I can think of - a single router
provides service to many clients in the same VLAN which must be
isolated.  Say the router is using eth0 and the clients are on
eth1-ethX.

Then what you want to do looks something like the following:

0) Deny all frames not explicitly permitted:
ebtables -P FORWARD DENY

1) Permit any frames with ingress eth0:
ebtables -A FORWARD -i eth0 -j ACCEPT
	
2) Permit any frames with egress interface eth0.
ebtables -A FORWARD -o eth0 -j ACCEPT


Think about ebtables as a low-level way to specify policy for the
handling of frames, much in the same way that iptables is a low-level
way to specify policy for IP packets.

In both cases, the tools operate only in very small ways, but the
advantage is that they are super-flexible in that they can handle very
complicated or bizarre scenarios.

For example, suppose that you want to permit eth1-ethX to participate
in the multicast group 01:02:03:04:05:06:
ebtables -A FORWARD -i ! eth0 -o ! eth0 -d 01:02:03:04:05:06 -j ACCEPT

Or now you want to permit eth1-ethX to have full access, but only for IPX:
ebtables -A FORWARD -i ! eth0 -o ! eth0 -p 8137 -j ACCEPT

Read the ebtables(8) manpage - you can do many more things than
private VLANs!

-- 
Ross Vandegrift
ross@kallisti.us

"If the fight gets hot, the songs get hotter.  If the going gets tough,
the songs get tougher."
	--Woody Guthrie

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Bridge] RFC: Simple Private VLAN impl.
  2009-06-10 16:27     ` Ross Vandegrift
@ 2009-06-10 17:09       ` Joakim Tjernlund
       [not found]       ` <OF4422F49E.33BDAF5C-ONC12575D1.005C802A-C12575D1.005E38A3@LocalDomain>
  1 sibling, 0 replies; 31+ messages in thread
From: Joakim Tjernlund @ 2009-06-10 17:09 UTC (permalink / raw)
  To: Ross Vandegrift; +Cc: Stephen Hemminger, bridge

Ross Vandegrift <ross@kallisti.us> wrote on 10/06/2009 18:27:52:
>
> On Wed, Jun 10, 2009 at 05:32:06PM +0200, Joakim Tjernlund wrote:
> > I am not sure this is so special anymore. I know that this
> > adds "support burden" but so does a lot of stuff in the kernel.
>
> Private VLANs are additional restrictions on a bridge's filtering
> database.  No kernel support is required because Linux (via ebtables)
> has a much more generic way to affect the filtering of frames.

hmm, yes I am starting to get a grip on this now.
>
> > Have anybody managed to do Private VLAN with several switches by
> > just using ebtables? Seems like most people here thinks that
> > ebtables is the right tool but none has provided any examples
> > on how to do it so I am starting to think that noone is so the
> > claim to just use ebtables might be false.
>
> I don't have a Linux machine with enough interfaces to build a
> meaningful private VLAN config, but I can step you though a simple
> conceptual explanation.
>
> One very common installation I can think of - a single router
> provides service to many clients in the same VLAN which must be
> isolated.  Say the router is using eth0 and the clients are on
> eth1-ethX.
>
> Then what you want to do looks something like the following:
>
> 0) Deny all frames not explicitly permitted:
> ebtables -P FORWARD DENY
>
> 1) Permit any frames with ingress eth0:
> ebtables -A FORWARD -i eth0 -j ACCEPT
>
> 2) Permit any frames with egress interface eth0.
> ebtables -A FORWARD -o eth0 -j ACCEPT
>
>
> Think about ebtables as a low-level way to specify policy for the
> handling of frames, much in the same way that iptables is a low-level
> way to specify policy for IP packets.

I have managed to convince myself that I can do Private VLAN with ebtables,
even between bridges :)
I do need some help to figure out how to setup the ebtable rules in an simple
manner that allows me to add/remove ports and also flip between Isolated and
Promiscuous port mode.

Check out http://www.rfc-editor.org/internet-drafts/draft-sanjib-private-vlan-10.txt ,
Table 1 and ignore community ports for now:
   ---------------------------------------------------------------
   |             | isolat-| promis-| commu-| commu-| interswitch |
   |             | ted    | cuous  | nity1 | nity2 | link port   |
   ---------------------------------------------------------------
   | isolated    | deny   | permit | deny  | deny  | permit      |
   ---------------------------------------------------------------
   | promiscuous | permit | permit | permit| permit| permit      |
   ---------------------------------------------------------------
   | community1  | deny   | permit | permit| deny  | permit      |
   ---------------------------------------------------------------
   | community2  | deny   | permit | deny  | permit| permit      |
   ---------------------------------------------------------------
   | interswitch |        |        |       |       |             |
   | link port   | deny(*)| permit | permit| permit| permit      |
   ---------------------------------------------------------------

 (*) Please note that this asymmetric behavior is for traffic
   traversing inter-switch link ports over an isolated VLAN only.
   Traffic from an inter-switch link port to an isolated port will be
   denied if it is in the isolated VLAN.  Traffic from an inter-switch
   link port to an isolated port will be permitted if it is in the
   primary VLAN (see below for the different VLAN characteristics).

   N.B.: An interswitch link port is simply a regular port that
   connects two switches (and that happens to carry two or more VLANs).


BTW, I think a new ebtables release is needed to address the bug mentioned here:
 http://www.spinics.net/lists/netfilter-devel/msg09369.html
I see that the latest release was in 2007 so I wonder if it is still
maintained?


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Bridge] RFC: Simple Private VLAN impl.
       [not found]       ` <OF4422F49E.33BDAF5C-ONC12575D1.005C802A-C12575D1.005E38A3@LocalDomain>
@ 2009-06-11 12:50         ` Joakim Tjernlund
  2009-06-11 14:22           ` Ross Vandegrift
  2009-06-11 21:04           ` Benny Amorsen
  0 siblings, 2 replies; 31+ messages in thread
From: Joakim Tjernlund @ 2009-06-11 12:50 UTC (permalink / raw)
  Cc: Stephen Hemminger, bridge

Joakim Tjernlund/Transmode wrote on 10/06/2009 19:09:09:
>
> Ross Vandegrift <ross@kallisti.us> wrote on 10/06/2009 18:27:52:
> >
> > On Wed, Jun 10, 2009 at 05:32:06PM +0200, Joakim Tjernlund wrote:
> > > I am not sure this is so special anymore. I know that this
> > > adds "support burden" but so does a lot of stuff in the kernel.
> >
> > Private VLANs are additional restrictions on a bridge's filtering
> > database.  No kernel support is required because Linux (via ebtables)
> > has a much more generic way to affect the filtering of frames.
>
> hmm, yes I am starting to get a grip on this now.
> >
> > > Have anybody managed to do Private VLAN with several switches by
> > > just using ebtables? Seems like most people here thinks that
> > > ebtables is the right tool but none has provided any examples
> > > on how to do it so I am starting to think that noone is so the
> > > claim to just use ebtables might be false.
> >
> > I don't have a Linux machine with enough interfaces to build a
> > meaningful private VLAN config, but I can step you though a simple
> > conceptual explanation.
> >
> > One very common installation I can think of - a single router
> > provides service to many clients in the same VLAN which must be
> > isolated.  Say the router is using eth0 and the clients are on
> > eth1-ethX.
> >
> > Then what you want to do looks something like the following:
> >
> > 0) Deny all frames not explicitly permitted:
> > ebtables -P FORWARD DENY
> >
> > 1) Permit any frames with ingress eth0:
> > ebtables -A FORWARD -i eth0 -j ACCEPT
> >
> > 2) Permit any frames with egress interface eth0.
> > ebtables -A FORWARD -o eth0 -j ACCEPT
> >
> >
> > Think about ebtables as a low-level way to specify policy for the
> > handling of frames, much in the same way that iptables is a low-level
> > way to specify policy for IP packets.
>
> I have managed to convince myself that I can do Private VLAN with ebtables,
> even between bridges :)
> I do need some help to figure out how to setup the ebtable rules in an simple
> manner that allows me to add/remove ports and also flip between Isolated and
> Promiscuous port mode.
>
> Check out http://www.rfc-editor.org/internet-drafts/draft-sanjib-private-vlan-10.txt ,
> Table 1 and ignore community ports for now:
>    ---------------------------------------------------------------
>    |             | isolat-| promis-| commu-| commu-| interswitch |
>    |             | ted    | cuous  | nity1 | nity2 | link port   |
>    ---------------------------------------------------------------
>    | isolated    | deny   | permit | deny  | deny  | permit      |
>    ---------------------------------------------------------------
>    | promiscuous | permit | permit | permit| permit| permit      |
>    ---------------------------------------------------------------
>    | community1  | deny   | permit | permit| deny  | permit      |
>    ---------------------------------------------------------------
>    | community2  | deny   | permit | deny  | permit| permit      |
>    ---------------------------------------------------------------
>    | interswitch |        |        |       |       |             |
>    | link port   | deny(*)| permit | permit| permit| permit      |
>    ---------------------------------------------------------------
>
>  (*) Please note that this asymmetric behavior is for traffic
>    traversing inter-switch link ports over an isolated VLAN only.
>    Traffic from an inter-switch link port to an isolated port will be
>    denied if it is in the isolated VLAN.  Traffic from an inter-switch
>    link port to an isolated port will be permitted if it is in the
>    primary VLAN (see below for the different VLAN characteristics).
>
>    N.B.: An interswitch link port is simply a regular port that
>    connects two switches (and that happens to carry two or more VLANs).

These are the rules i come up with when I have a bridge with four
interfaces. Promisc, Isolated, Community and a Interswitch port.

The Interswitch port is modelled with 3 VLANs 4042, 4043 and 4044

#Static rules
#.4042 = Promisc/primary VLAN
#.4043 = Isolated VLAN
#.4042 = Community VLAN
#These VLANs represent the interswitch port

#Do not leak pkgs between the above VLANs
./ebtables -A FORWARD -i eth0.4042 -o eth0.4043 -j DROP
./ebtables -A FORWARD -i eth0.4042 -o eth0.4044 -j DROP
./ebtables -A FORWARD -i eth0.4043 -o eth0.4042 -j DROP
./ebtables -A FORWARD -i eth0.4043 -o eth0.4044 -j DROP
./ebtables -A FORWARD -i eth0.4044 -o eth0.4042 -j DROP
./ebtables -A FORWARD -i eth0.4044 -o eth0.4043 -j DROP

#Port rules

#Promisc Port, eth1.1
./ebtables -A FORWARD -i eth1.1 -o eth0.4043 -j DROP
./ebtables -A FORWARD -i eth1.1 -o eth0.4044 -j DROP

#Isolated Port, eth1.2
./ebtables -A FORWARD -i eth1.2 -o eth0.4043 -j ACCEPT
./ebtables -A FORWARD -i eth1.2 -o eth1.1 -j ACCEPT
./ebtables -A FORWARD -i eth1.2 -j DROP
./ebtables -A FORWARD -o eth1.2 -i eth0.4042 -j ACCEPT
./ebtables -A FORWARD -o eth1.2 -i eth1.1 -j ACCEPT
./ebtables -A FORWARD -o eth1.2 -j DROP

#Community Port, eth1.3
./ebtables -A FORWARD -i eth1.3 -o eth0.4042 -j ACCEPT
./ebtables -A FORWARD -i eth1.3 -o eth0.4044 -j ACCEPT
./ebtables -A FORWARD -i eth1.3 -j DROP
./ebtables -A FORWARD -o eth1.3 -i eth0.4042 -j ACCEPT
./ebtables -A FORWARD -o eth1.3 -i eth0.4044 -j ACCEPT
./ebtables -A FORWARD -o eth1.3 -i eth1.1 -j ACCEPT
./ebtables -A FORWARD -o eth1.3 -j DROP

This is getting out of control. I was hoping there would be a simpler
way to express the above. Adding ports or changing roles won't
be funny.
Anyone?

 Jocke


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Bridge] RFC: Simple Private VLAN impl.
  2009-06-11 12:50         ` Joakim Tjernlund
@ 2009-06-11 14:22           ` Ross Vandegrift
  2009-06-11 14:48             ` Joakim Tjernlund
  2009-06-11 21:04           ` Benny Amorsen
  1 sibling, 1 reply; 31+ messages in thread
From: Ross Vandegrift @ 2009-06-11 14:22 UTC (permalink / raw)
  To: Joakim Tjernlund; +Cc: Stephen Hemminger, bridge

On Thu, Jun 11, 2009 at 02:50:30PM +0200, Joakim Tjernlund wrote:
> These are the rules i come up with when I have a bridge with four
> interfaces. Promisc, Isolated, Community and a Interswitch port.
> 
> The Interswitch port is modelled with 3 VLANs 4042, 4043 and 4044
> 
> #Static rules
> #.4042 = Promisc/primary VLAN
> #.4043 = Isolated VLAN
> #.4042 = Community VLAN
    ^^^^ I assume you mean 4044 here.

> #These VLANs represent the interswitch port
> 
> #Do not leak pkgs between the above VLANs
> ./ebtables -A FORWARD -i eth0.4042 -o eth0.4043 -j DROP
> ./ebtables -A FORWARD -i eth0.4042 -o eth0.4044 -j DROP
> ./ebtables -A FORWARD -i eth0.4043 -o eth0.4042 -j DROP
> ./ebtables -A FORWARD -i eth0.4043 -o eth0.4044 -j DROP
> ./ebtables -A FORWARD -i eth0.4044 -o eth0.4042 -j DROP
> ./ebtables -A FORWARD -i eth0.4044 -o eth0.4043 -j DROP
> 
> #Port rules
> 
> #Promisc Port, eth1.1
> ./ebtables -A FORWARD -i eth1.1 -o eth0.4043 -j DROP
> ./ebtables -A FORWARD -i eth1.1 -o eth0.4044 -j DROP

Makes sense.

> #Isolated Port, eth1.2
> ./ebtables -A FORWARD -i eth1.2 -o eth0.4043 -j ACCEPT

You may or may not mean this - depends on your goal.  You want to
support the case of an isolated port on bridge A talking to a
promiscuous port on bridge B?

> ./ebtables -A FORWARD -i eth1.2 -o eth1.1 -j ACCEPT
> ./ebtables -A FORWARD -i eth1.2 -j DROP
> ./ebtables -A FORWARD -o eth1.2 -i eth0.4042 -j ACCEPT
> ./ebtables -A FORWARD -o eth1.2 -i eth1.1 -j ACCEPT
> ./ebtables -A FORWARD -o eth1.2 -j DROP
> 
> #Community Port, eth1.3
> ./ebtables -A FORWARD -i eth1.3 -o eth0.4042 -j ACCEPT
> ./ebtables -A FORWARD -i eth1.3 -o eth0.4044 -j ACCEPT

You also want the community port to have access to the promiscuous
port locally:
./ebtables -A FORWARD -i eth1.3 -o eth1.1 -j ACCEPT

> ./ebtables -A FORWARD -i eth1.3 -j DROP
> ./ebtables -A FORWARD -o eth1.3 -i eth0.4042 -j ACCEPT
> ./ebtables -A FORWARD -o eth1.3 -i eth0.4044 -j ACCEPT
> ./ebtables -A FORWARD -o eth1.3 -i eth1.1 -j ACCEPT
> ./ebtables -A FORWARD -o eth1.3 -j DROP


> This is getting out of control. I was hoping there would be a simpler
> way to express the above. Adding ports or changing roles won't
> be funny.
> Anyone?

Not sure how you expected it to look.  To change the filtering
attributes of a bridge with n ports, you're going to need to have two
rules for each port-pair (one for each direction).  That's 2n^2 rules
in the worst case, and there isn't a way around that.

This is where the opportunity for some development and abstraction
comes in.  If I were you, I'd write a "port manager" script that let
me define port rules and roles in a much simpler language.  That
script would then output the required ebtables ruleset to acheive
that.

This is a central feature of netfilter stuff, by the way -
conceptually, it's very low-level.  It's kind of like an "assembly
language" for packet handling.  Search google and freahmeat for
iptables software - you'll find thousands of programs designed to make
the writing of large and complicated iptables rulesets easier.

I doubt such software exists for the creation of private VLANs via
ebtables.

-- 
Ross Vandegrift
ross@kallisti.us

"If the fight gets hot, the songs get hotter.  If the going gets tough,
the songs get tougher."
	--Woody Guthrie

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Bridge] RFC: Simple Private VLAN impl.
  2009-06-11 14:22           ` Ross Vandegrift
@ 2009-06-11 14:48             ` Joakim Tjernlund
  2009-06-11 16:12               ` Ross Vandegrift
  0 siblings, 1 reply; 31+ messages in thread
From: Joakim Tjernlund @ 2009-06-11 14:48 UTC (permalink / raw)
  To: Ross Vandegrift; +Cc: Stephen Hemminger, bridge



Ross Vandegrift <ross@kallisti.us> wrote on 11/06/2009 16:22:51:
>
> On Thu, Jun 11, 2009 at 02:50:30PM +0200, Joakim Tjernlund wrote:
> > These are the rules i come up with when I have a bridge with four
> > interfaces. Promisc, Isolated, Community and a Interswitch port.
> >
> > The Interswitch port is modelled with 3 VLANs 4042, 4043 and 4044
> >
> > #Static rules
> > #.4042 = Promisc/primary VLAN
> > #.4043 = Isolated VLAN
> > #.4042 = Community VLAN
>     ^^^^ I assume you mean 4044 here.

yes, cut & past error.

>
> > #These VLANs represent the interswitch port
> >
> > #Do not leak pkgs between the above VLANs
> > ./ebtables -A FORWARD -i eth0.4042 -o eth0.4043 -j DROP
> > ./ebtables -A FORWARD -i eth0.4042 -o eth0.4044 -j DROP
> > ./ebtables -A FORWARD -i eth0.4043 -o eth0.4042 -j DROP
> > ./ebtables -A FORWARD -i eth0.4043 -o eth0.4044 -j DROP
> > ./ebtables -A FORWARD -i eth0.4044 -o eth0.4042 -j DROP
> > ./ebtables -A FORWARD -i eth0.4044 -o eth0.4043 -j DROP
> >
> > #Port rules
> >
> > #Promisc Port, eth1.1
> > ./ebtables -A FORWARD -i eth1.1 -o eth0.4043 -j DROP
> > ./ebtables -A FORWARD -i eth1.1 -o eth0.4044 -j DROP
>
> Makes sense.
>
> > #Isolated Port, eth1.2
> > ./ebtables -A FORWARD -i eth1.2 -o eth0.4043 -j ACCEPT
>
> You may or may not mean this - depends on your goal.  You want to
> support the case of an isolated port on bridge A talking to a
> promiscuous port on bridge B?

Yes!

>
> > ./ebtables -A FORWARD -i eth1.2 -o eth1.1 -j ACCEPT
> > ./ebtables -A FORWARD -i eth1.2 -j DROP
> > ./ebtables -A FORWARD -o eth1.2 -i eth0.4042 -j ACCEPT
> > ./ebtables -A FORWARD -o eth1.2 -i eth1.1 -j ACCEPT
> > ./ebtables -A FORWARD -o eth1.2 -j DROP
> >
> > #Community Port, eth1.3
> > ./ebtables -A FORWARD -i eth1.3 -o eth0.4042 -j ACCEPT
> > ./ebtables -A FORWARD -i eth1.3 -o eth0.4044 -j ACCEPT
>
> You also want the community port to have access to the promiscuous
> port locally:
> ./ebtables -A FORWARD -i eth1.3 -o eth1.1 -j ACCEPT

Yes, forgot that one. Thanks.

>
> > ./ebtables -A FORWARD -i eth1.3 -j DROP
> > ./ebtables -A FORWARD -o eth1.3 -i eth0.4042 -j ACCEPT
> > ./ebtables -A FORWARD -o eth1.3 -i eth0.4044 -j ACCEPT
> > ./ebtables -A FORWARD -o eth1.3 -i eth1.1 -j ACCEPT
> > ./ebtables -A FORWARD -o eth1.3 -j DROP
>
>
> > This is getting out of control. I was hoping there would be a simpler
> > way to express the above. Adding ports or changing roles won't
> > be funny.
> > Anyone?
>
> Not sure how you expected it to look.  To change the filtering
> attributes of a bridge with n ports, you're going to need to have two
> rules for each port-pair (one for each direction).  That's 2n^2 rules
> in the worst case, and there isn't a way around that.

I didn't expect much. This was a first try and this is what I could come up with.
This quickly builds a lot of rules to be processed and I am worried about
manage all those rules and performance of the bridge.

>
> This is where the opportunity for some development and abstraction
> comes in.  If I were you, I'd write a "port manager" script that let
> me define port rules and roles in a much simpler language.  That
> script would then output the required ebtables ruleset to acheive
> that.

Yes, but still. I feel that there is a better way specify this. I was
thinking of adding some new chains, one for Promisc ports one for Isolated ports
and so on and use them to cut down the number of rules to easy management
and increase performance, but I haven't figured out how yet.

Perhaps ebtables isn't really suited for this task and
one would be better off adding this to the bridge code?

>
> This is a central feature of netfilter stuff, by the way -
> conceptually, it's very low-level.  It's kind of like an "assembly
> language" for packet handling.  Search google and freahmeat for
> iptables software - you'll find thousands of programs designed to make
> the writing of large and complicated iptables rulesets easier.
>
> I doubt such software exists for the creation of private VLANs via
> ebtables.

I don't either. I have googled but found nothing.

One thing that hit me is how to manage STP on the above bridge?
How would such ebtables rules look in the above example?

 Jocke


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Bridge] RFC: Simple Private VLAN impl.
  2009-06-11 14:48             ` Joakim Tjernlund
@ 2009-06-11 16:12               ` Ross Vandegrift
  2009-06-11 19:43                 ` Joakim Tjernlund
  0 siblings, 1 reply; 31+ messages in thread
From: Ross Vandegrift @ 2009-06-11 16:12 UTC (permalink / raw)
  To: Joakim Tjernlund; +Cc: Stephen Hemminger, bridge

On Thu, Jun 11, 2009 at 04:48:25PM +0200, Joakim Tjernlund wrote:
> > This is where the opportunity for some development and abstraction
> > comes in.  If I were you, I'd write a "port manager" script that let
> > me define port rules and roles in a much simpler language.  That
> > script would then output the required ebtables ruleset to acheive
> > that.
> 
> Yes, but still. I feel that there is a better way specify this. I was
> thinking of adding some new chains, one for Promisc ports one for Isolated ports
> and so on and use them to cut down the number of rules to easy management
> and increase performance, but I haven't figured out how yet.

This might be a good idea.  I used to do something similar with
ipchains, way back when.  My ruleset was large and complicated, so I
broke it up into many chains based on what was being accomplished.

In your case, it would somewhat depend on the installation profile.
If most of your ports are promiscuous, you probably want to change the
policy to ACCEPT and then write rules that drop frames where you need
isolation.  If most ports are isolated, then you want to keep the
policy as DROP and write rules to permit frames.

I might write a script like this (totally untested):

ebtables -P FORWARD DROP

# This will take care of all communications to/from a promiscuous
# interface, regardless of the role of the "other" interface
for interface in $PROMISC_IFS; do
	ebtables -A FORWARD -i $interface -j ACCEPT
	ebtables -A FORWARD -o $interface -j ACCEPT
done

# Interfaces in a community need a full mesh of connectivity in
# addition to the above.
for comm in $COMM_IFS; do
	for othercomm in $COMM_IFS; do
		if [[ "$comm" != "$othercomm" ]]; then
			ebtables -A COMMUNITY -i $comm -o $othercomm -j ACCEPT
		fi
	done
done

for interface in $COMM_IFS; do
	ebtables -A FORWARD -i $interface -j COMMUNITY
	ebtables -A FORWARD -o $interface -j COMMUNITY



You're only going to learn the best way to do it by playing with it -
I don't actually have any installation like you want, so I can't offer
any long-term advice.

-- 
Ross Vandegrift
ross@kallisti.us

"If the fight gets hot, the songs get hotter.  If the going gets tough,
the songs get tougher."
	--Woody Guthrie

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Bridge] RFC: Simple Private VLAN impl.
  2009-06-11 16:12               ` Ross Vandegrift
@ 2009-06-11 19:43                 ` Joakim Tjernlund
  0 siblings, 0 replies; 31+ messages in thread
From: Joakim Tjernlund @ 2009-06-11 19:43 UTC (permalink / raw)
  To: Ross Vandegrift; +Cc: Stephen Hemminger, bridge

Ross Vandegrift <ross@kallisti.us> wrote on 11/06/2009 18:12:27:
>
> On Thu, Jun 11, 2009 at 04:48:25PM +0200, Joakim Tjernlund wrote:
> > > This is where the opportunity for some development and abstraction
> > > comes in.  If I were you, I'd write a "port manager" script that let
> > > me define port rules and roles in a much simpler language.  That
> > > script would then output the required ebtables ruleset to acheive
> > > that.
> >
> > Yes, but still. I feel that there is a better way specify this. I was
> > thinking of adding some new chains, one for Promisc ports one for Isolated ports
> > and so on and use them to cut down the number of rules to easy management
> > and increase performance, but I haven't figured out how yet.
>
> This might be a good idea.  I used to do something similar with
> ipchains, way back when.  My ruleset was large and complicated, so I
> broke it up into many chains based on what was being accomplished.
>
> In your case, it would somewhat depend on the installation profile.
> If most of your ports are promiscuous, you probably want to change the
> policy to ACCEPT and then write rules that drop frames where you need
> isolation.  If most ports are isolated, then you want to keep the
> policy as DROP and write rules to permit frames.
>
> I might write a script like this (totally untested):

Thanks, I have added some crude additions, What do you think?
(I stink a shell programming, will play some more tomorrow)

>
> ebtables -P FORWARD DROP
>
> # This will take care of all communications to/from a promiscuous
> # interface, regardless of the role of the "other" interface
> for interface in $PROMISC_IFS; do
   ebtables -A FORWARD -o eth0.4043 -i $interface -j DROP
   ebtables -A FORWARD -o eth0.4044 -i $interface -j DROP
>    ebtables -A FORWARD -i $interface -j ACCEPT
>    ebtables -A FORWARD -o $interface -j ACCEPT
> done

ebtables -A FORWARD -i eth0.4042 -j ACCEPT

>
> # Interfaces in a community need a full mesh of connectivity in
> # addition to the above.

COMM_IFS += eth0.4044

> for comm in $COMM_IFS; do
>    for othercomm in $COMM_IFS; do
>       if [[ "$comm" != "$othercomm" ]]; then
>          ebtables -A COMMUNITY -i $comm -o $othercomm -j ACCEPT
>       fi
>    done
> done

hmm, may be split into a IN_COMMUNITY and a OUT_COMMUNITY?
for comm in $COMM_IFS; do
   ebtables -A IN_COMMUNITY  -i $comm -j ACCEPT
   ebtables -A OUT_COMMUNITY -o $comm -j ACCEPT
done
for comm in $COMM_IFS; do
 ebtables -A FORWARD -i $interface -j OUT_COMMUNITY
 ebtables -A FORWARD -o $interface -j IN_COMMUNITY

>
> for interface in $COMM_IFS; do
>    ebtables -A FORWARD -i $interface -j COMMUNITY
>    ebtables -A FORWARD -o $interface -j COMMUNITY
>
>

for iso in $ISOLATED_IFS; do
    ebtables -A FORWARD -i $iso -o eth0.4043 -j ACCEPT
 done
>
> You're only going to learn the best way to do it by playing with it -
> I don't actually have any installation like you want, so I can't offer
> any long-term advice.
>
> --
> Ross Vandegrift
> ross@kallisti.us
>
> "If the fight gets hot, the songs get hotter.  If the going gets tough,
> the songs get tougher."
>    --Woody Guthrie
>
>


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Bridge] RFC: Simple Private VLAN impl.
  2009-06-10 15:32   ` Joakim Tjernlund
  2009-06-10 16:27     ` Ross Vandegrift
@ 2009-06-11 19:51     ` Daniel Robbins
  2009-06-11 23:58       ` Ross Vandegrift
  2009-06-12  9:17       ` Benny Amorsen
  1 sibling, 2 replies; 31+ messages in thread
From: Daniel Robbins @ 2009-06-11 19:51 UTC (permalink / raw)
  To: Joakim Tjernlund; +Cc: Stephen Hemminger, bridge

[-- Attachment #1: Type: text/plain, Size: 2463 bytes --]

On Wed, Jun 10, 2009 at 9:32 AM, Joakim Tjernlund <
joakim.tjernlund@transmode.se> wrote:

> Stephen Hemminger <shemminger@vyatta.com> wrote on 10/06/2009 16:45:42:
> >
> > On Wed, 10 Jun 2009 15:32:06 +0200
> > Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> >
> > >
> > > Even though some folks on this list thinks ebtables should be used
> > > to deploy Private VLAN I find using ebtables a bit clumsy.
> > >
> >
> > I prefer ebtables be used to "patch" bridge to do these kind
> > of special case things.  Remember any code that is put in mainline
> > adds additional API's and long term support burden.
>
> I am not sure this is so special anymore. I know that this
> adds "support burden" but so does a lot of stuff in the kernel.
>
> Have anybody managed to do Private VLAN with several switches by
> just using ebtables? Seems like most people here thinks that
> ebtables is the right tool but none has provided any examples
> on how to do it so I am starting to think that noone is so the
> claim to just use ebtables might be false.
>
>  Jocke


Hi Jocke,

I have not yet done this with ebtables but I plan to in the next two weeks.
I am also interested in doing some testing for your patch, do see if it is
better or preferable to the ebtables approach.

I do think that having the bridge code do PVLANs could end up being better.
In particular, I think this could be *very* useful for virtualization, where
you are adding/removing interfaces from the bridge often. Why? Because it
eliminates the need to dynamically create/remove ebtables rules and keep
them in sync with the interfaces on the bridge.

Stephen, I think one needs to consider the complexity of the patch in terms
of maintenance -- but it's important to note that the bridge code in the
kernel is there to serve *us* and be useful to *us*. In other words, the
highest priority of the code is to be useful. While it is important for the
code to be maintainable, this should never be the highest priority. This is
a very small patch so rejecting it on the basis that it increases the
maintenance burden does not seem like a legitimate argument. And if this
approach is much simpler in practice then using ebtables, then I think
something like this should be added.

I do think that if the bridging code can take care of layer 2 PVLANs, and I
only have to worry about locking down layer 3 via iptables, then this could
be a superior solution to using ebtables.

Regards,

Daniel

[-- Attachment #2: Type: text/html, Size: 3158 bytes --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Bridge] RFC: Simple Private VLAN impl.
  2009-06-11 12:50         ` Joakim Tjernlund
  2009-06-11 14:22           ` Ross Vandegrift
@ 2009-06-11 21:04           ` Benny Amorsen
  2009-06-11 23:10             ` Joakim Tjernlund
  1 sibling, 1 reply; 31+ messages in thread
From: Benny Amorsen @ 2009-06-11 21:04 UTC (permalink / raw)
  To: Joakim Tjernlund; +Cc: Stephen Hemminger, bridge

Joakim Tjernlund <joakim.tjernlund@transmode.se> writes:

>    ---------------------------------------------------------------
>    |             | isolat-| promis-| commu-| commu-| interswitch |
>    |             | ted    | cuous  | nity1 | nity2 | link port   |
>    ---------------------------------------------------------------
>    | isolated    | deny   | permit | deny  | deny  | permit      |
>    ---------------------------------------------------------------
>    | promiscuous | permit | permit | permit| permit| permit      |
>    ---------------------------------------------------------------
>    | community1  | deny   | permit | permit| deny  | permit      |
>    ---------------------------------------------------------------
>    | community2  | deny   | permit | deny  | permit| permit      |
>    ---------------------------------------------------------------
>    | interswitch |        |        |       |       |             |
>    | link port   | deny(*)| permit | permit| permit| permit      |
>    ---------------------------------------------------------------

Ok, I thought this would be really easy, but I must admit I don't get
how an interswitch link port works. Apparently the different VLAN's are
allowed to go to the same ports, but you can't send a packet back out
the physical interface it came in on.

I ignored the community rules, exercise for the reader...

Anyway, this is buggy, but it should give you an idea:

ebtables -A FORWARD -i eth0.4042 -j frominterswitchporteth0
ebtables -A FORWARD -i eth0.4043 -j frominterswitchporteth0
ebtables -A FORWARD -i eth0.4044 -j frominterswitchporteth0

ebtables -A FORWARD -i eth1.1 -j frompromiscuous
ebtables -A FORWARD -i eth1.2 -j fromisolated
ebtables -A FORWARD -i eth0.4042 -j frominterswitch
ebtables -A FORWARD -i eth0.4043 -j frominterswitch
ebtables -A FORWARD -i eth0.4044 -j frominterswitch
ebtables -A FORWARD -j DROP

ebtables -A frominterswitchporteth0 -o eth0.4042 -j DROP
ebtables -A frominterswitchporteth0 -o eth0.4043 -j DROP
ebtables -A frominterswitchporteth0 -o eth0.4044 -j DROP
ebtables -A frominterswitchporteth0 -j RETURN

#ebtables -A fromisolated -j denyisolated
ebtables -A fromisolated -j permitpromiscuous
ebtables -A fromisolated -j permitinterswitch
ebtables -A fromisolated -j DROP

ebtables -A frompromiscuous -j permitisolated
ebtables -A frompromiscuous -j permitpromiscuous
ebtables -A frompromiscuous -j permitinterswitch
ebtables -A frompromiscuous -j DROP

#ebtables -A frominterswitch -j denyisolated
ebtables -A frominterswitch -j permitpromiscuous
ebtables -A frominterswitch -j permitinterswitch
ebtables -A frominterswitch -j DROP

ebtables -A permitisolated -o eth1.2 -j ACCEPT
ebtables -A permitisolated -j RETURN

ebtables -A permitpromiscuous -o eth1.1 -j ACCEPT
ebtables -A permitpromiscuous -j RETURN

ebtables -A permitinterswitch -o eth0.4042 -j ACCEPT
ebtables -A permitinterswitch -o eth0.4043 -j ACCEPT
ebtables -A permitinterswitch -o eth0.4044 -j ACCEPT
ebtables -A permitpromiscuous -j RETURN

Now, to implement an extra interface, just add it to FORWARD with -j
from<type> and add it to permit<type>. Just two rules. If it's an
interswitch interface, you need to make a new rule set and add the
appropriate VLAN's in there as well, so 4 rules per VLAN for those.

It would be handy if ebtables supported interface sets, like netfilter
supports ipsets.


/Benny


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Bridge] RFC: Simple Private VLAN impl.
  2009-06-11 21:04           ` Benny Amorsen
@ 2009-06-11 23:10             ` Joakim Tjernlund
  2009-06-11 23:44               ` Ross Vandegrift
  0 siblings, 1 reply; 31+ messages in thread
From: Joakim Tjernlund @ 2009-06-11 23:10 UTC (permalink / raw)
  To: Benny Amorsen; +Cc: Stephen Hemminger, bridge

Benny Amorsen <benny+usenet@amorsen.dk> wrote on 11/06/2009 23:04:48:
> Joakim Tjernlund <joakim.tjernlund@transmode.se> writes:
>
> >    ---------------------------------------------------------------
> >    |             | isolat-| promis-| commu-| commu-| interswitch |
> >    |             | ted    | cuous  | nity1 | nity2 | link port   |
> >    ---------------------------------------------------------------
> >    | isolated    | deny   | permit | deny  | deny  | permit      |
> >    ---------------------------------------------------------------
> >    | promiscuous | permit | permit | permit| permit| permit      |
> >    ---------------------------------------------------------------
> >    | community1  | deny   | permit | permit| deny  | permit      |
> >    ---------------------------------------------------------------
> >    | community2  | deny   | permit | deny  | permit| permit      |
> >    ---------------------------------------------------------------
> >    | interswitch |        |        |       |       |             |
> >    | link port   | deny(*)| permit | permit| permit| permit      |
> >    ---------------------------------------------------------------
>
> Ok, I thought this would be really easy, but I must admit I don't get
> how an interswitch link port works. Apparently the different VLAN's are
> allowed to go to the same ports, but you can't send a packet back out
> the physical interface it came in on.

Yes that took a while to figure out:
#.4042 = Promisc/Primary VLAN (P)
#.4043 = Isolated VLAN (I)
#.4044 = Community VLAN (C)
#These VLANs represent the interswitch port:
# Promisc ports only TX to P, but RX from P, C & I
# Community ports only TX to C VLAN, but RX from C & P
# Isolated ports only TX to I VLAN, but RX only P

>
> I ignored the community rules, exercise for the reader...

See the latest mail from Ross, I thin he is on to something ..

Also, do we need to do anything if STP is running on the bridge?


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Bridge] RFC: Simple Private VLAN impl.
  2009-06-11 23:10             ` Joakim Tjernlund
@ 2009-06-11 23:44               ` Ross Vandegrift
  0 siblings, 0 replies; 31+ messages in thread
From: Ross Vandegrift @ 2009-06-11 23:44 UTC (permalink / raw)
  To: Joakim Tjernlund; +Cc: Stephen Hemminger, bridge, Benny Amorsen

On Fri, Jun 12, 2009 at 01:10:28AM +0200, Joakim Tjernlund wrote:
> Also, do we need to do anything if STP is running on the bridge?

No, you shouldn't.  The FORWARD chain only defines filters for frames
that are passing through the bridge, not frames that are sourced from
or destined to the bridge.

-- 
Ross Vandegrift
ross@kallisti.us

"If the fight gets hot, the songs get hotter.  If the going gets tough,
the songs get tougher."
	--Woody Guthrie

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Bridge] RFC: Simple Private VLAN impl.
  2009-06-11 19:51     ` Daniel Robbins
@ 2009-06-11 23:58       ` Ross Vandegrift
  2009-06-12  0:15         ` Daniel Robbins
  2009-06-12  9:17       ` Benny Amorsen
  1 sibling, 1 reply; 31+ messages in thread
From: Ross Vandegrift @ 2009-06-11 23:58 UTC (permalink / raw)
  To: Daniel Robbins; +Cc: Stephen Hemminger, bridge, Joakim Tjernlund

On Thu, Jun 11, 2009 at 01:51:06PM -0600, Daniel Robbins wrote:
> I do think that having the bridge code do PVLANs could end up being better.
> In particular, I think this could be *very* useful for virtualization, where
> you are adding/removing interfaces from the bridge often. Why? Because it
> eliminates the need to dynamically create/remove ebtables rules and keep
> them in sync with the interfaces on the bridge.

In the virtualization case, I think it's actually easier: do it via
MAC addresses instead of interfaces.  In this case, since you're
creating the virtual environments, you'll know the MAC address that
gets generated for each VE.

1) Set your policy to deny.
2) Permit all frames destined to/from the promiscuous MACs.
3) Permit all broadcast frames to the promiscuous MACs.

That takes care of the "isolated" use case.  If you need to support
the "community" case:
4) Add pairwise bidirectional rules to permit communications between
each MAC in a community. 

Why is this easier?  Since you know the MACs of the VEs, you have a
trivial way of identifying the rules associated with a VE.  This way,
you know what rules to spin up and remove during the turnup or
disabling of a VE.  Moreover, since all of the rules permit specific
traffic, the order doesn't even matter.

There's two obvious cases where this won't scale:

1) Many VEs on a single host where the VEs form a complicated routing
heirarchy.  In this case, you'll have a rat's nest of MAC rules.  But
I'd say in this case a private VLAN solution was a bad design choice.

2) Many VEs in many communities spread across many hosts.  For
example, it might get bad if you had 5 communities across 100 hosts,
with each community having 100 VEs.  This would mean each host needs
a full set of 10000 MAC rules for each community - 50000 ebtables
rules.  In this case, I'd again prefer a routed design (well, any case
actually...) and if a common "community" LAN was a software
requirement, I'd use multipoint GRE or L2TP.

But for one node with a bunch of unrelated VEs, this is very little
work to maintain.

Ross

-- 
Ross Vandegrift
ross@kallisti.us

"If the fight gets hot, the songs get hotter.  If the going gets tough,
the songs get tougher."
	--Woody Guthrie

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Bridge] RFC: Simple Private VLAN impl.
  2009-06-11 23:58       ` Ross Vandegrift
@ 2009-06-12  0:15         ` Daniel Robbins
  2009-06-12  3:56           ` Ross Vandegrift
  0 siblings, 1 reply; 31+ messages in thread
From: Daniel Robbins @ 2009-06-12  0:15 UTC (permalink / raw)
  To: Ross Vandegrift; +Cc: Stephen Hemminger, bridge, Joakim Tjernlund

[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]

On Thu, Jun 11, 2009 at 5:58 PM, Ross Vandegrift <ross@kallisti.us> wrote:

> 2) Many VEs in many communities spread across many hosts.  For
> example, it might get bad if you had 5 communities across 100 hosts,
> with each community having 100 VEs.  This would mean each host needs
> a full set of 10000 MAC rules for each community - 50000 ebtables
> rules.  In this case, I'd again prefer a routed design (well, any case
> actually...) and if a common "community" LAN was a software
> requirement, I'd use multipoint GRE or L2TP.
>
> But for one node with a bunch of unrelated VEs, this is very little
> work to maintain.
>

In my particular configuration, there are no communities - each VE is an
island, and will only be able to communicate with the network gateway (which
is non-local, ie. not on the linux bridge itself.) That should lock down
layer 2. With OpenVZ, each VE's MAC will have a common SWSoft 00:18:51
prefix.

After I get that working, I need to lock down layer 3 with iptables, so the
PVLAN functionality can't be bypassed.

If you have any configuration examples for ebtables, especially simple ones,
I would welcome them :)

Thanks,

Daniel

[-- Attachment #2: Type: text/html, Size: 1637 bytes --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Bridge] RFC: Simple Private VLAN impl.
  2009-06-12  0:15         ` Daniel Robbins
@ 2009-06-12  3:56           ` Ross Vandegrift
  0 siblings, 0 replies; 31+ messages in thread
From: Ross Vandegrift @ 2009-06-12  3:56 UTC (permalink / raw)
  To: Daniel Robbins; +Cc: Stephen Hemminger, bridge, Joakim Tjernlund

On Thu, Jun 11, 2009 at 06:15:46PM -0600, Daniel Robbins wrote:
> In my particular configuration, there are no communities - each VE is an
> island, and will only be able to communicate with the network gateway (which
> is non-local, ie. not on the linux bridge itself.) That should lock down
> layer 2. With OpenVZ, each VE's MAC will have a common SWSoft 00:18:51
> prefix.
> 
> After I get that working, I need to lock down layer 3 with iptables, so the
> PVLAN functionality can't be bypassed.
> 
> If you have any configuration examples for ebtables, especially simple ones,
> I would welcome them :)

Couldn't be simpler in that case.  Say you've bridged veth1.0 through
venet10.0 and venet1.0 is the interface of the gateway.  Then, all you
need is:

ebtables -A FORWARD -i veth1.0 -j ACCEPT
ebtables -A FORWARD -o veth1.0 -j ACCEPT

If you spin up VEID 11, give it a virtual ethernet NIC, and add the
associated veth device on the hardware node to the bridge - you're
good to go.

Of course veth1.0 could just as easily be a physical interface
connected to another device.

-- 
Ross Vandegrift
ross@kallisti.us

"If the fight gets hot, the songs get hotter.  If the going gets tough,
the songs get tougher."
	--Woody Guthrie

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Bridge] RFC: Simple Private VLAN impl.
  2009-06-11 19:51     ` Daniel Robbins
  2009-06-11 23:58       ` Ross Vandegrift
@ 2009-06-12  9:17       ` Benny Amorsen
  2009-06-12  9:41         ` Joakim Tjernlund
  1 sibling, 1 reply; 31+ messages in thread
From: Benny Amorsen @ 2009-06-12  9:17 UTC (permalink / raw)
  To: Daniel Robbins; +Cc: Stephen Hemminger, bridge, Joakim Tjernlund

Daniel Robbins <drobbins@funtoo.org> writes:

> In particular, I think this could be *very* useful for virtualization,
> where you are adding/removing interfaces from the bridge often. Why?
> Because it eliminates the need to dynamically create/remove ebtables
> rules and keep them in sync with the interfaces on the bridge.

If you had sets of interfaces, like you can have sets of ip addresses
today, it would be trivial to keep the sets in sync.

I don't find it particularly as it is, but with interface-sets you
wouldn't even have to change any rules.


/Benny


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Bridge] RFC: Simple Private VLAN impl.
  2009-06-12  9:17       ` Benny Amorsen
@ 2009-06-12  9:41         ` Joakim Tjernlund
  2009-06-12  9:48           ` Benny Amorsen
  2009-06-12 12:52           ` Ross Vandegrift
  0 siblings, 2 replies; 31+ messages in thread
From: Joakim Tjernlund @ 2009-06-12  9:41 UTC (permalink / raw)
  To: Benny Amorsen; +Cc: Stephen Hemminger, bridge

Benny Amorsen <benny+usenet@amorsen.dk> wrote on 12/06/2009 11:17:45:
>
> Daniel Robbins <drobbins@funtoo.org> writes:
>
> > In particular, I think this could be *very* useful for virtualization,
> > where you are adding/removing interfaces from the bridge often. Why?
> > Because it eliminates the need to dynamically create/remove ebtables
> > rules and keep them in sync with the interfaces on the bridge.
>
> If you had sets of interfaces, like you can have sets of ip addresses
> today, it would be trivial to keep the sets in sync.
>
> I don't find it particularly as it is, but with interface-sets you
> wouldn't even have to change any rules.

Yes, sets would be nice. However I wonder if this case isn't a bug
in any case:
Consider these VLANS:
 eth0.4042
 eth0.4043
 eth0.4044

Add them to a bridge and the bridge will pass pkgs between them, right?
However no real switch I know would do that because they are on
the same physical interface.
I think the bridge needs to check the physical interface too and don't
forward pkgs back on the same physical interface.

 Jocke


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Bridge] RFC: Simple Private VLAN impl.
  2009-06-12  9:41         ` Joakim Tjernlund
@ 2009-06-12  9:48           ` Benny Amorsen
  2009-06-12 11:03             ` Marek Kierdelewicz
  2009-06-12 11:45             ` Joakim Tjernlund
  2009-06-12 12:52           ` Ross Vandegrift
  1 sibling, 2 replies; 31+ messages in thread
From: Benny Amorsen @ 2009-06-12  9:48 UTC (permalink / raw)
  To: Joakim Tjernlund; +Cc: Stephen Hemminger, bridge

Joakim Tjernlund <joakim.tjernlund@transmode.se> writes:

> Add them to a bridge and the bridge will pass pkgs between them, right?

Of course.

> However no real switch I know would do that because they are on
> the same physical interface.

True, and this is very problematic.

> I think the bridge needs to check the physical interface too and don't
> forward pkgs back on the same physical interface.

Certainly not. Real-world configurations are made impossible by doing
that.

Linux doesn't need to limit itself to the myopic views of traditional
switch designers. Their hardware is broken, ours isn't.


/Benny


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Bridge] RFC: Simple Private VLAN impl.
  2009-06-12  9:48           ` Benny Amorsen
@ 2009-06-12 11:03             ` Marek Kierdelewicz
  2009-06-12 11:45             ` Joakim Tjernlund
  1 sibling, 0 replies; 31+ messages in thread
From: Marek Kierdelewicz @ 2009-06-12 11:03 UTC (permalink / raw)
  To: bridge

Hello,

>> I think the bridge needs to check the physical interface too and
>> don't
>> forward pkgs back on the same physical interface.

>Certainly not. Real-world configurations are made impossible by doing
>that.
>Linux doesn't need to limit itself to the myopic views of traditional
>switch designers. Their hardware is broken, ours isn't.

I second Benny Amorsen's opinion. Such scenario is in production use in
my network. You may call it "bridge on the stick" (analogy to "router on
the stick").

Cheers,
Marek Kierdelewicz

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Bridge] RFC: Simple Private VLAN impl.
  2009-06-12  9:48           ` Benny Amorsen
  2009-06-12 11:03             ` Marek Kierdelewicz
@ 2009-06-12 11:45             ` Joakim Tjernlund
  1 sibling, 0 replies; 31+ messages in thread
From: Joakim Tjernlund @ 2009-06-12 11:45 UTC (permalink / raw)
  To: Benny Amorsen; +Cc: Stephen Hemminger, bridge

Benny Amorsen <benny+usenet@amorsen.dk> wrote on 12/06/2009 11:48:09:
>
> Joakim Tjernlund <joakim.tjernlund@transmode.se> writes:
>
> > Add them to a bridge and the bridge will pass pkgs between them, right?
>
> Of course.
>
> > However no real switch I know would do that because they are on
> > the same physical interface.
>
> True, and this is very problematic.

why? I can't think of any usage pattern.

>
> > I think the bridge needs to check the physical interface too and don't
> > forward pkgs back on the same physical interface.
>
> Certainly not. Real-world configurations are made impossible by doing
> that.
>
> Linux doesn't need to limit itself to the myopic views of traditional
> switch designers. Their hardware is broken, ours isn't.

Broken? If only Linux does this, perhaps it is Linux that is broken.
New users could be very surprised by this so perhaps it could default to
off?

 Jocke


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Bridge] RFC: Simple Private VLAN impl.
  2009-06-12  9:41         ` Joakim Tjernlund
  2009-06-12  9:48           ` Benny Amorsen
@ 2009-06-12 12:52           ` Ross Vandegrift
  2009-06-12 13:09             ` Joakim Tjernlund
  1 sibling, 1 reply; 31+ messages in thread
From: Ross Vandegrift @ 2009-06-12 12:52 UTC (permalink / raw)
  To: Joakim Tjernlund; +Cc: Stephen Hemminger, bridge, Benny Amorsen

On Fri, Jun 12, 2009 at 11:41:55AM +0200, Joakim Tjernlund wrote:
> Yes, sets would be nice. However I wonder if this case isn't a bug
> in any case:
> Consider these VLANS:
>  eth0.4042
>  eth0.4043
>  eth0.4044
> 
> Add them to a bridge and the bridge will pass pkgs between them, right?
> However no real switch I know would do that because they are on
> the same physical interface.

No, that's not a problem at all.  Any dot1q bridge would behave
exactly as Linux does if it supports VLAN bridging (which at least
Cisco, Nortel, and Juniper do in varying capcities).

Moreover, any dot1q bridge that doesn't support VLAN bridging can
(be careful!) have the feature added by adding one untagged port into
each VLAN and cabling them to a dot1d bridge.  Linux just saves you
cables.

The split-horizon rule is for flooding into a broadcast domain.  For
purposes of split-horizon flooding, each of your VLAN interfaces are
physical interfaces - a broadcast frame arrived on one of the ports
and needs to be flooded out all of the others.

Ross

-- 
Ross Vandegrift
ross@kallisti.us

"If the fight gets hot, the songs get hotter.  If the going gets tough,
the songs get tougher."
	--Woody Guthrie

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Bridge] RFC: Simple Private VLAN impl.
  2009-06-12 12:52           ` Ross Vandegrift
@ 2009-06-12 13:09             ` Joakim Tjernlund
  2009-06-12 13:19               ` richardvoigt
  0 siblings, 1 reply; 31+ messages in thread
From: Joakim Tjernlund @ 2009-06-12 13:09 UTC (permalink / raw)
  To: Ross Vandegrift; +Cc: Stephen Hemminger, bridge, Benny Amorsen

Ross Vandegrift <ross@kallisti.us> wrote on 12/06/2009 14:52:14:
>
> On Fri, Jun 12, 2009 at 11:41:55AM +0200, Joakim Tjernlund wrote:
> > Yes, sets would be nice. However I wonder if this case isn't a bug
> > in any case:
> > Consider these VLANS:
> >  eth0.4042
> >  eth0.4043
> >  eth0.4044
> >
> > Add them to a bridge and the bridge will pass pkgs between them, right?
> > However no real switch I know would do that because they are on
> > the same physical interface.
>
> No, that's not a problem at all.  Any dot1q bridge would behave
> exactly as Linux does if it supports VLAN bridging (which at least
> Cisco, Nortel, and Juniper do in varying capcities).
>
> Moreover, any dot1q bridge that doesn't support VLAN bridging can
> (be careful!) have the feature added by adding one untagged port into
> each VLAN and cabling them to a dot1d bridge.  Linux just saves you
> cables.
>
> The split-horizon rule is for flooding into a broadcast domain.  For
> purposes of split-horizon flooding, each of your VLAN interfaces are
> physical interfaces - a broadcast frame arrived on one of the ports
> and needs to be flooded out all of the others.

hmm, then I don't understand how Private VLAN is supposed to work over
the interswitch port. If I understand you correctly, a Bcast pkg arriving
on VLAN 4042 will be forwarded back over 4043 and 4044 VLANs, then the
receiving switch will forward back these to pkgs once again and
it never stops?

I have updated the script you sent me, what do you think?

#.4042 = Promisc/Primary VLAN (P)
#.4043 = Isolated VLAN (I)
#.4044 = Community VLAN (C)
#These VLANs represent the interswitch port:
# Promisc ports only TX to P, but RX from P, C & I
# Community ports only TX to C VLAN, but RX from C & P
# Isolated ports only TX to I VLAN, but RX only P

#Note that pkgs must not be forwarded between the different uplinks.

P_UPLINK=eth0.4042
I_UPLINK=eth0.4043
C_UPLINK=eth0.4044

#PROMISC_IFS="eth1.1"
PROMISC_IFS=
ISOLATED_IFS="eth1.2"
COMM_IFS="eth1.3 eth1.4 eth1.5 eth1.6"

EB=/root/ebtables

"$EB" --init-table
#"$EB" --flush
"$EB" -P FORWARD DROP

# This will take care of all communications to/from a promiscuous
# interface, regardless of the role of the "other" interface
for interface in $PROMISC_IFS; do
  "$EB" -A FORWARD -o $I_UPLINK -i $interface -j DROP
  "$EB" -A FORWARD -o $C_UPLINK -i $interface -j DROP
  "$EB" -A FORWARD -i $interface -j ACCEPT
  "$EB" -A FORWARD -o $interface -j ACCEPT
done
"$EB" -A FORWARD -i $P_UPLINK -j ACCEPT

for iso in $ISOLATED_IFS; do
    "$EB" -A FORWARD -i $iso -o $I_UPLINK -j ACCEPT
done


# Interfaces in a community need a full mesh of connectivity in
# addition to the above.

"$EB" -N IN_COMMUNITY
"$EB" -P IN_COMMUNITY DROP

"$EB" -N OUT_COMMUNITY
"$EB" -P OUT_COMMUNITY DROP

for comm in $COMM_IFS; do
   "$EB" -A IN_COMMUNITY  -i $comm -j ACCEPT
   "$EB" -A OUT_COMMUNITY -o $comm -j ACCEPT
done

"$EB" -A OUT_COMMUNITY -o $C_UPLINK -j ACCEPT

for comm in $COMM_IFS; do
   "$EB" -A FORWARD -i $comm -j OUT_COMMUNITY
   "$EB" -A FORWARD -o $comm -j IN_COMMUNITY
done


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Bridge] RFC: Simple Private VLAN impl.
  2009-06-12 13:09             ` Joakim Tjernlund
@ 2009-06-12 13:19               ` richardvoigt
  2009-06-12 13:47                 ` Joakim Tjernlund
  0 siblings, 1 reply; 31+ messages in thread
From: richardvoigt @ 2009-06-12 13:19 UTC (permalink / raw)
  To: Joakim Tjernlund; +Cc: Stephen Hemminger, bridge, Benny Amorsen

On Fri, Jun 12, 2009 at 8:09 AM, Joakim
Tjernlund<joakim.tjernlund@transmode.se> wrote:
> Ross Vandegrift <ross@kallisti.us> wrote on 12/06/2009 14:52:14:
>>
>> On Fri, Jun 12, 2009 at 11:41:55AM +0200, Joakim Tjernlund wrote:
>> > Yes, sets would be nice. However I wonder if this case isn't a bug
>> > in any case:
>> > Consider these VLANS:
>> >  eth0.4042
>> >  eth0.4043
>> >  eth0.4044
>> >
>> > Add them to a bridge and the bridge will pass pkgs between them, right?
>> > However no real switch I know would do that because they are on
>> > the same physical interface.
>>
>> No, that's not a problem at all.  Any dot1q bridge would behave
>> exactly as Linux does if it supports VLAN bridging (which at least
>> Cisco, Nortel, and Juniper do in varying capcities).
>>
>> Moreover, any dot1q bridge that doesn't support VLAN bridging can
>> (be careful!) have the feature added by adding one untagged port into
>> each VLAN and cabling them to a dot1d bridge.  Linux just saves you
>> cables.
>>
>> The split-horizon rule is for flooding into a broadcast domain.  For
>> purposes of split-horizon flooding, each of your VLAN interfaces are
>> physical interfaces - a broadcast frame arrived on one of the ports
>> and needs to be flooded out all of the others.
>
> hmm, then I don't understand how Private VLAN is supposed to work over
> the interswitch port. If I understand you correctly, a Bcast pkg arriving
> on VLAN 4042 will be forwarded back over 4043 and 4044 VLANs, then the
> receiving switch will forward back these to pkgs once again and
> it never stops?

Only one switch would be configured to bridge between VLANs.

VLANs are by default (in the absence of enabling bridging) isolation barriers.

Most entry-level physical switches (basic VLAN support only) consider
all VLANs with the same ID to be members of the same bridge, there is
one such bridge for each configured VLAN.  Linux allows you to have
this operation trivially, but allows far more powerful combinations.

All this "promiscuous VLAN" stuff is just an attempt to bring some of
the features of software bridging (e.g. Linux) to hardware switches in
a standard way.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Bridge] RFC: Simple Private VLAN impl.
  2009-06-12 13:19               ` richardvoigt
@ 2009-06-12 13:47                 ` Joakim Tjernlund
  2009-06-12 19:31                   ` richardvoigt
  0 siblings, 1 reply; 31+ messages in thread
From: Joakim Tjernlund @ 2009-06-12 13:47 UTC (permalink / raw)
  To: richardvoigt; +Cc: Stephen Hemminger, bridge, Benny Amorsen

"richardvoigt@gmail.com" <richardvoigt@gmail.com> wrote on 12/06/2009 15:19:22:
>
> On Fri, Jun 12, 2009 at 8:09 AM, Joakim
> Tjernlund<joakim.tjernlund@transmode.se> wrote:
> > Ross Vandegrift <ross@kallisti.us> wrote on 12/06/2009 14:52:14:
> >>
> >> On Fri, Jun 12, 2009 at 11:41:55AM +0200, Joakim Tjernlund wrote:
> >> > Yes, sets would be nice. However I wonder if this case isn't a bug
> >> > in any case:
> >> > Consider these VLANS:
> >> >  eth0.4042
> >> >  eth0.4043
> >> >  eth0.4044
> >> >
> >> > Add them to a bridge and the bridge will pass pkgs between them, right?
> >> > However no real switch I know would do that because they are on
> >> > the same physical interface.
> >>
> >> No, that's not a problem at all.  Any dot1q bridge would behave
> >> exactly as Linux does if it supports VLAN bridging (which at least
> >> Cisco, Nortel, and Juniper do in varying capcities).
> >>
> >> Moreover, any dot1q bridge that doesn't support VLAN bridging can
> >> (be careful!) have the feature added by adding one untagged port into
> >> each VLAN and cabling them to a dot1d bridge.  Linux just saves you
> >> cables.
> >>
> >> The split-horizon rule is for flooding into a broadcast domain.  For
> >> purposes of split-horizon flooding, each of your VLAN interfaces are
> >> physical interfaces - a broadcast frame arrived on one of the ports
> >> and needs to be flooded out all of the others.
> >
> > hmm, then I don't understand how Private VLAN is supposed to work over
> > the interswitch port. If I understand you correctly, a Bcast pkg arriving
> > on VLAN 4042 will be forwarded back over 4043 and 4044 VLANs, then the
> > receiving switch will forward back these to pkgs once again and
> > it never stops?
>
> Only one switch would be configured to bridge between VLANs.
>
> VLANs are by default (in the absence of enabling bridging) isolation barriers.
>
> Most entry-level physical switches (basic VLAN support only) consider
> all VLANs with the same ID to be members of the same bridge, there is
> one such bridge for each configured VLAN.  Linux allows you to have
> this operation trivially, but allows far more powerful combinations.
>
> All this "promiscuous VLAN" stuff is just an attempt to bring some of
> the features of software bridging (e.g. Linux) to hardware switches in
> a standard way.

OK, this would suggest that the default mode of the linux bridge is wrong
and can cause loops and other ill effects. A user should not have
to resort to ebtables just to turn off this behaviour.

 Jocke


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Bridge] RFC: Simple Private VLAN impl.
  2009-06-12 13:47                 ` Joakim Tjernlund
@ 2009-06-12 19:31                   ` richardvoigt
  2009-06-12 21:32                     ` Joakim Tjernlund
  0 siblings, 1 reply; 31+ messages in thread
From: richardvoigt @ 2009-06-12 19:31 UTC (permalink / raw)
  To: Joakim Tjernlund; +Cc: Stephen Hemminger, bridge, Benny Amorsen

On Fri, Jun 12, 2009 at 8:47 AM, Joakim
Tjernlund<joakim.tjernlund@transmode.se> wrote:
> "richardvoigt@gmail.com" <richardvoigt@gmail.com> wrote on 12/06/2009 15:19:22:
>>
>> On Fri, Jun 12, 2009 at 8:09 AM, Joakim
>> Tjernlund<joakim.tjernlund@transmode.se> wrote:
>> > Ross Vandegrift <ross@kallisti.us> wrote on 12/06/2009 14:52:14:
>> >>
>> >> On Fri, Jun 12, 2009 at 11:41:55AM +0200, Joakim Tjernlund wrote:
>> >> > Yes, sets would be nice. However I wonder if this case isn't a bug
>> >> > in any case:
>> >> > Consider these VLANS:
>> >> >  eth0.4042
>> >> >  eth0.4043
>> >> >  eth0.4044
>> >> >
>> >> > Add them to a bridge and the bridge will pass pkgs between them, right?
>> >> > However no real switch I know would do that because they are on
>> >> > the same physical interface.
>> >>
>> >> No, that's not a problem at all.  Any dot1q bridge would behave
>> >> exactly as Linux does if it supports VLAN bridging (which at least
>> >> Cisco, Nortel, and Juniper do in varying capcities).
>> >>
>> >> Moreover, any dot1q bridge that doesn't support VLAN bridging can
>> >> (be careful!) have the feature added by adding one untagged port into
>> >> each VLAN and cabling them to a dot1d bridge.  Linux just saves you
>> >> cables.
>> >>
>> >> The split-horizon rule is for flooding into a broadcast domain.  For
>> >> purposes of split-horizon flooding, each of your VLAN interfaces are
>> >> physical interfaces - a broadcast frame arrived on one of the ports
>> >> and needs to be flooded out all of the others.
>> >
>> > hmm, then I don't understand how Private VLAN is supposed to work over
>> > the interswitch port. If I understand you correctly, a Bcast pkg arriving
>> > on VLAN 4042 will be forwarded back over 4043 and 4044 VLANs, then the
>> > receiving switch will forward back these to pkgs once again and
>> > it never stops?
>>
>> Only one switch would be configured to bridge between VLANs.
>>
>> VLANs are by default (in the absence of enabling bridging) isolation barriers.
>>
>> Most entry-level physical switches (basic VLAN support only) consider
>> all VLANs with the same ID to be members of the same bridge, there is
>> one such bridge for each configured VLAN.  Linux allows you to have
>> this operation trivially, but allows far more powerful combinations.
>>
>> All this "promiscuous VLAN" stuff is just an attempt to bring some of
>> the features of software bridging (e.g. Linux) to hardware switches in
>> a standard way.
>
> OK, this would suggest that the default mode of the linux bridge is wrong
> and can cause loops and other ill effects. A user should not have
> to resort to ebtables just to turn off this behaviour.
>
>  Jocke

The default mode of linux bridging is just fine.  I'm suspecting you
have followed some complicated example setup which wasn't appropriate
for your environment and broke things.

If you want linux to act like a physical switch:

add ethN.0 to br0
add ethN.1 to br1
add ethN.j to brj

all VLANs will be isolated from each other just like a simple
VLAN-capable switch.

If you don't want traffic from VLAN 4042 to go out over VLAN 4043,
don't add them to the same bridge instance.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Bridge] RFC: Simple Private VLAN impl.
  2009-06-12 19:31                   ` richardvoigt
@ 2009-06-12 21:32                     ` Joakim Tjernlund
  2009-06-12 23:54                       ` Benny Amorsen
  2009-06-13  4:29                       ` richardvoigt
  0 siblings, 2 replies; 31+ messages in thread
From: Joakim Tjernlund @ 2009-06-12 21:32 UTC (permalink / raw)
  To: richardvoigt; +Cc: Stephen Hemminger, bridge, Benny Amorsen

"richardvoigt@gmail.com" <richardvoigt@gmail.com> wrote on 12/06/2009 21:31:08:

>
> On Fri, Jun 12, 2009 at 8:47 AM, Joakim
> Tjernlund<joakim.tjernlund@transmode.se> wrote:
> > "richardvoigt@gmail.com" <richardvoigt@gmail.com> wrote on 12/06/2009 15:19:22:
> >>
> >> On Fri, Jun 12, 2009 at 8:09 AM, Joakim
> >> Tjernlund<joakim.tjernlund@transmode.se> wrote:
> >> > Ross Vandegrift <ross@kallisti.us> wrote on 12/06/2009 14:52:14:
> >> >>
> >> >> On Fri, Jun 12, 2009 at 11:41:55AM +0200, Joakim Tjernlund wrote:
> >> >> > Yes, sets would be nice. However I wonder if this case isn't a bug
> >> >> > in any case:
> >> >> > Consider these VLANS:
> >> >> >  eth0.4042
> >> >> >  eth0.4043
> >> >> >  eth0.4044
> >> >> >
> >> >> > Add them to a bridge and the bridge will pass pkgs between them, right?
> >> >> > However no real switch I know would do that because they are on
> >> >> > the same physical interface.
> >> >>
> >> >> No, that's not a problem at all.  Any dot1q bridge would behave
> >> >> exactly as Linux does if it supports VLAN bridging (which at least
> >> >> Cisco, Nortel, and Juniper do in varying capcities).
> >> >>
> >> >> Moreover, any dot1q bridge that doesn't support VLAN bridging can
> >> >> (be careful!) have the feature added by adding one untagged port into
> >> >> each VLAN and cabling them to a dot1d bridge.  Linux just saves you
> >> >> cables.
> >> >>
> >> >> The split-horizon rule is for flooding into a broadcast domain.  For
> >> >> purposes of split-horizon flooding, each of your VLAN interfaces are
> >> >> physical interfaces - a broadcast frame arrived on one of the ports
> >> >> and needs to be flooded out all of the others.
> >> >
> >> > hmm, then I don't understand how Private VLAN is supposed to work over
> >> > the interswitch port. If I understand you correctly, a Bcast pkg arriving
> >> > on VLAN 4042 will be forwarded back over 4043 and 4044 VLANs, then the
> >> > receiving switch will forward back these to pkgs once again and
> >> > it never stops?
> >>
> >> Only one switch would be configured to bridge between VLANs.
> >>
> >> VLANs are by default (in the absence of enabling bridging) isolation barriers.
> >>
> >> Most entry-level physical switches (basic VLAN support only) consider
> >> all VLANs with the same ID to be members of the same bridge, there is
> >> one such bridge for each configured VLAN.  Linux allows you to have
> >> this operation trivially, but allows far more powerful combinations.
> >>
> >> All this "promiscuous VLAN" stuff is just an attempt to bring some of
> >> the features of software bridging (e.g. Linux) to hardware switches in
> >> a standard way.
> >
> > OK, this would suggest that the default mode of the linux bridge is wrong
> > and can cause loops and other ill effects. A user should not have
> > to resort to ebtables just to turn off this behaviour.
> >
> >  Jocke
>
> The default mode of linux bridging is just fine.  I'm suspecting you
> have followed some complicated example setup which wasn't appropriate
> for your environment and broke things.
>
> If you want linux to act like a physical switch:
>
> add ethN.0 to br0
> add ethN.1 to br1
> add ethN.j to brj
>
> all VLANs will be isolated from each other just like a simple
> VLAN-capable switch.
>
> If you don't want traffic from VLAN 4042 to go out over VLAN 4043,
> don't add them to the same bridge instance.

But why should I not be able to add both 4043 and 4044 to the same bridge?

I just sent a patch to add split horizon support to the linux bridge. Have
a look. More power to the linux bridge that way.

   Jocke


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Bridge] RFC: Simple Private VLAN impl.
  2009-06-12 21:32                     ` Joakim Tjernlund
@ 2009-06-12 23:54                       ` Benny Amorsen
  2009-06-13 14:58                         ` Joakim Tjernlund
  2009-06-13  4:29                       ` richardvoigt
  1 sibling, 1 reply; 31+ messages in thread
From: Benny Amorsen @ 2009-06-12 23:54 UTC (permalink / raw)
  To: Joakim Tjernlund; +Cc: Stephen Hemminger, bridge

Joakim Tjernlund <joakim.tjernlund@transmode.se> writes:

> But why should I not be able to add both 4043 and 4044 to the same bridge?

Of course you should. And they should behave as a proper bridge, letting
packets flow as they were meant to. Unless you decide that local policy
does not permit packets to flow freely, and then you use ebtables to
apply that local policy.

> I just sent a patch to add split horizon support to the linux bridge. Have
> a look. More power to the linux bridge that way.

You have already been shown that you can achieve what you want with the
existing kernel code, at the cost of a somewhat complicated rule setup.
You have also been shown ways to simplify this rule setup.

I really hope that your patches are not accepted. Sorry if this is
harsh, but the company I work for has in the past depended on the
flexibility of the existing code. While that company is currently
migrating to proprietary solutions because PC's don't get faster at the
rate which traffic grows, it seems ridiculous that Linux should copy the
limitations of less capable platforms.


/Benny


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Bridge] RFC: Simple Private VLAN impl.
  2009-06-12 21:32                     ` Joakim Tjernlund
  2009-06-12 23:54                       ` Benny Amorsen
@ 2009-06-13  4:29                       ` richardvoigt
  1 sibling, 0 replies; 31+ messages in thread
From: richardvoigt @ 2009-06-13  4:29 UTC (permalink / raw)
  To: Joakim Tjernlund; +Cc: Stephen Hemminger, bridge, Benny Amorsen

>> If you want linux to act like a physical switch:
>>
>> add ethN.0 to br0
>> add ethN.1 to br1
>> add ethN.j to brj
>>
>> all VLANs will be isolated from each other just like a simple
>> VLAN-capable switch.
>>
>> If you don't want traffic from VLAN 4042 to go out over VLAN 4043,
>> don't add them to the same bridge instance.
>
> But why should I not be able to add both 4043 and 4044 to the same bridge?

You are able to add them to the same bridge.  Doing so will pass
traffic between them.  That's what a bridge does.  If you don't want
traffic bridged, don't put them in the same bridge.  But you
experienced the expected and desirable behavior corresponding to
adding multiple interfaces to a bridge, and then you come to the list
saying "Doctor, it hurts when I do this."

Linux supports multiple bridge interfaces.  If you want multiple
private networks isolated from each other, use a new bridge instance
for each.  That's what multiple bridge instances are for.  If you want
a server to serve clients in multiple VLANs, make the server listen on
multiple interfaces (these can be VLANs on a single physical link).
That simplifies the MAC address table and cuts down on broadcast
traffic as well.  Then you don't have the complexity of ebtables to
block traffic between ports, every VLAN is fully connected using its
own bridge instance and no traffic crosses to a different VLAN at all.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Bridge] RFC: Simple Private VLAN impl.
  2009-06-12 23:54                       ` Benny Amorsen
@ 2009-06-13 14:58                         ` Joakim Tjernlund
  0 siblings, 0 replies; 31+ messages in thread
From: Joakim Tjernlund @ 2009-06-13 14:58 UTC (permalink / raw)
  To: Benny Amorsen; +Cc: Stephen Hemminger, bridge

Benny Amorsen <benny+usenet@amorsen.dk> wrote on 13/06/2009 01:54:30:
>
> Joakim Tjernlund <joakim.tjernlund@transmode.se> writes:
>
> > But why should I not be able to add both 4043 and 4044 to the same bridge?
>
> Of course you should. And they should behave as a proper bridge, letting
> packets flow as they were meant to.

You have some other definition of a "proper bridge". A common bridge would not
care about the VLANs and never return a pkg on the same interface.

> Unless you decide that local policy
> does not permit packets to flow freely, and then you use ebtables to
> apply that local policy.
>
> > I just sent a patch to add split horizon support to the linux bridge. Have
> > a look. More power to the linux bridge that way.
>
> You have already been shown that you can achieve what you want with the
> existing kernel code, at the cost of a somewhat complicated rule setup.
> You have also been shown ways to simplify this rule setup.

Yes, I have already worked around this, but it doesn't make it right.
I just want the bridge to do the right thing and I think the current behavior
isn't it.

>
> I really hope that your patches are not accepted. Sorry if this is
> harsh, but the company I work for has in the past depended on the
> flexibility of the existing code. While that company is currently
> migrating to proprietary solutions because PC's don't get faster at the
> rate which traffic grows, it seems ridiculous that Linux should copy the
> limitations of less capable platforms.

You still have that flexibility. Turn it off and you are free to shoot yourself
in the foot.


^ permalink raw reply	[flat|nested] 31+ messages in thread

end of thread, other threads:[~2009-06-13 14:58 UTC | newest]

Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-06-10 13:32 [Bridge] RFC: Simple Private VLAN impl Joakim Tjernlund
2009-06-10 14:45 ` Stephen Hemminger
2009-06-10 15:32   ` Joakim Tjernlund
2009-06-10 16:27     ` Ross Vandegrift
2009-06-10 17:09       ` Joakim Tjernlund
     [not found]       ` <OF4422F49E.33BDAF5C-ONC12575D1.005C802A-C12575D1.005E38A3@LocalDomain>
2009-06-11 12:50         ` Joakim Tjernlund
2009-06-11 14:22           ` Ross Vandegrift
2009-06-11 14:48             ` Joakim Tjernlund
2009-06-11 16:12               ` Ross Vandegrift
2009-06-11 19:43                 ` Joakim Tjernlund
2009-06-11 21:04           ` Benny Amorsen
2009-06-11 23:10             ` Joakim Tjernlund
2009-06-11 23:44               ` Ross Vandegrift
2009-06-11 19:51     ` Daniel Robbins
2009-06-11 23:58       ` Ross Vandegrift
2009-06-12  0:15         ` Daniel Robbins
2009-06-12  3:56           ` Ross Vandegrift
2009-06-12  9:17       ` Benny Amorsen
2009-06-12  9:41         ` Joakim Tjernlund
2009-06-12  9:48           ` Benny Amorsen
2009-06-12 11:03             ` Marek Kierdelewicz
2009-06-12 11:45             ` Joakim Tjernlund
2009-06-12 12:52           ` Ross Vandegrift
2009-06-12 13:09             ` Joakim Tjernlund
2009-06-12 13:19               ` richardvoigt
2009-06-12 13:47                 ` Joakim Tjernlund
2009-06-12 19:31                   ` richardvoigt
2009-06-12 21:32                     ` Joakim Tjernlund
2009-06-12 23:54                       ` Benny Amorsen
2009-06-13 14:58                         ` Joakim Tjernlund
2009-06-13  4:29                       ` richardvoigt

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.