I think you have to take a hit on MTU, so this is probably better
on gigabit interfaces that are configured for jumbo frames (using
ifconfig to increase MTU configures them for jumbos).

Cisco does something similar (qinq) but iirc they use a different

You could really use another machine for testing ...

[ message continues ]

On Thu, Aug 21, 2008 at 09:50:35AM +0000, Stuart Henderson wrote:
| > you can stack vlans. aka
| >
| > ifconfig vlan2 vlan 2 vlandev em0
| > ifconfig vlan4 vlan 4 vlandev vlan2
| >
| 
| I think you have to take a hit on MTU, so this is probably better
| on gigabit interfaces that are configured for jumbo frames (using
| ifconfig to increase MTU configures them for jumbos).
| 
| Cisco does something similar (qinq) but iirc they use a different
| ethertype, so it may not be directly compatible.

The standard specifies 0x88a8 for 'qinq' or 'stacked vlans' or
802.1ad (Provider Bridges). OpenBSD uses 0x8100 for both the outer and
the inner ethertype (which may give interoperability issues with other
vendors, don't know, don't have gear that supports it).

Attached is a patch that adds ETHERTYPE_8021AD to ethertypes.h.

Cheers,

Paul 'WEiRD' de Weerd

+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
                 http://www.weirdnet.nl/                 
Index: ethertypes.h
===================================================================
RCS file: /cvs/src/sys/net/ethertypes.h,v
retrieving revision 1.9
diff -u -r1.9 ethertypes.h
--- ethertypes.h	5 May 2008 13:40:17 -0000	1.9
+++ ethertypes.h	21 Aug 2008 11:22:02 -0000
@@ -300,6 +300,7 @@
 #define	ETHERTYPE_LANPROBE	0x8888	/* HP LanProbe test? */
 #define	ETHERTYPE_PAE		0x888E	/* 802.1X Port Access Entity */
 #define	ETHERTYPE_AOE		0x88A2	/* ATA over Ethernet */
+#define	ETHERTYPE_8021AD	0x88A8	/* 802.1ad VLAN stacking */
 #define	ETHERTYPE_LLDP		0x88CC	/* Link Layer Discovery Protocol */
 #define	ETHERTYPE_LOOPBACK	0x9000	/* Loopback */
 #define	ETHERTYPE_LBACK		ETHERTYPE_LOOPBACK	/* DEC MOP loopback */

[ message continues ]

no point in just doing that.

a button to change the ether type would make sense.

-- 
Henning Brauer, hb@bsws.de, henning@openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam

[ message continues ]

If we stack vlan interfaces I don't see a real need for such a button.
This could be figured out either at configuration time or on runtime.
E.g. just check if the ethertype is 0x8100 and add the next vlan tag as
0x88a8. This would also allow to use a bridge for qinq setups. Because of
this I think doing it on runtime is the best.


[ message continues ]

switch vendors don't agree on the ethertype. it is configurable on all
of them, and the defaults are different between vendors.
as in: button needed.

-- 
Henning Brauer, hb@bsws.de, henning@openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam

[ message continues ]

hi,


for example, you can easilly change the default tag-type from 0x88a8
to old-style 0x8100 on hp switches, but it is a global setting:

- on the switch:
ProCurve Switch 5406zl(config)# qinq mixedvlan tag-type 0x8100
- or - 
ProCurve Switch 5406zl(config)# qinq svlan tag-type 0x8100
...

ProCurve Switch 5406zl(config)# interface a1-a2 unknown-vlans disable 
ProCurve Switch 5406zl(config)# svlan 100 tagged a1,a2

- on the OpenBSD hosts:
a# ifconfig em0 up
a# ifconfig vlan100 vlandev em0
a# ifconfig vlan200 vlandev vlan100 192.168.200.1

b# ifconfig em0 up
b# ifconfig vlan100 vlandev em0
b# ifconfig vlan200 vlandev vlan100 192.168.200.2
b# ping 192.168.200.1

reyk

[ message continues ]

Geez Guys,
This is beyond expectation, as an openbsd user, I'am blown over since now,  
my so called router/switch is a metro switch.. geez.. I patching now, and  
let's see what happens.
Thanks,



Insan
-- 
insandotpraja(at)gmaildotcom

[ message continues ]

OT, but what makes a metro switch "metro"?

[ message continues ]

Metro is a model name for cisco.

-----Original Message-----
From: owner-misc@openbsd.org [mailto:owner-misc@openbsd.org] On Behalf Of
Steve Shockley
Sent: Friday, August 22, 2008 12:08 PM
To: misc@openbsd.org
Subject: Re: Vlan Tag on Vlan Tag (l2tunneling)


OT, but what makes a metro switch "metro"?

[ message continues ]

Normaly next to qinq mostly even bigger cams plus I nicer frontplate.
Qinq while making it possible to push differnet L2 lans over a common
network in a VPN like (the unencrypted form) fashion needs a lot more
storage for all the MAC addrs seen on the core switches. In the end the
core switches need to know all MAC addrs of all clients in all networks.
The 16k entries of most basic manageable switches are way to little for
larger networks.
Oh and just to make stuff even more crazy on L2 there is MAC-in-MAC which
adds to the qinq header an additional ethernet header to keep the MAC
address tables separated per network.

All this was invented because Windows likes to broadcast/multicast
information around and the admins are unable to figure out how routing
works.

[ message continues ]

this is not trivial because it would require a change in the Rx path
where it is currently matching the ethertype in ether_input() before
calling vlan_input().  do you want to call vlan_input() for every
other packet or do a configured type lookup all the time?  and what if
the user specifies an ethernet type that is conflicting with something

here is another approach defining QinQ-compliant interfaces as a new
cloner type; so you can stack 0x88a8 devices as you wish and it
doesn't need a new button in ifconfig.  it also uses a dedicated vlan
tag hash for "Service VLANs" to avoid tag/Id conflicts.

# ifconfig em0 up
# ifconfig svlan100 vlandev em0
# ifconfig vlan200 vlandev svlan100 192.168.2.100

reyk

Index: share/man/man4/vlan.4
===================================================================
RCS file: /cvs/src/share/man/man4/vlan.4,v
retrieving revision 1.31
diff -u -p -r1.31 vlan.4
--- share/man/man4/vlan.4	26 Jun 2008 05:42:07 -0000	1.31
+++ share/man/man4/vlan.4	21 Aug 2008 19:18:42 -0000
@@ -31,8 +31,9 @@
 .Dt VLAN 4
 .Os
 .Sh NAME
-.Nm vlan
-.Nd "IEEE 802.1Q encapsulation/decapsulation pseudo-device"
+.Nm vlan ,
+.Nm svlan
+.Nd "IEEE 802.1Q/1AD encapsulation/decapsulation pseudo-devices"
 .Sh SYNOPSIS
 .Cd "pseudo-device vlan"
 .Sh DESCRIPTION
@@ -40,6 +41,10 @@ The
 .Nm
 Ethernet interface allows construction of virtual LANs when used in
 conjunction with IEEE 802.1Q-compliant Ethernet devices.
+The
+.Ic svlan
+Ethernet interface allows contruction of IEEE 802.1AD-compliant
+provider bridges.
 .Pp
 A
 .Nm
@@ -83,6 +88,24 @@ option for more information.
 Following the vlan header is the actual ether type for the frame and length
 information.
 .Pp
+An
+.Ic svlan
+interface is normally used for QinQ in 802.1AD-compliant provider bridges to
+stack other
+.Nm
+interfaces on top of it.
+It can be created using the
+.Ic ifconfig svlan Ns Ar N Ic create
+command or by setting up a
+.Xr hostname.if 5
+configuration file for
+.Xr netstart 8 ...
[ message continues ]

Works for me.

(haven't tested this very extensively yet, and only OpenBSD <->
OpenBSD ... nor did I try the tcpdump patches .. will do so later)

Thanks Reyk, cool stuff ;)

Paul 'WEiRD' de Weerd

On Thu, Aug 21, 2008 at 09:34:12PM +0200, Reyk Floeter wrote:
| On Thu, Aug 21, 2008 at 04:05:50PM +0200, Claudio Jeker wrote:
| > > no point in just doing that.
| > > 
| > > a button to change the ether type would make sense.
| > > 
| > 
| 
| this is not trivial because it would require a change in the Rx path
| where it is currently matching the ethertype in ether_input() before
| calling vlan_input().  do you want to call vlan_input() for every
| other packet or do a configured type lookup all the time?  and what if
| the user specifies an ethernet type that is conflicting with something
| else?  i think it should really only be 0x8100 or 0x88a8.
| 
| > If we stack vlan interfaces I don't see a real need for such a button.
| > This could be figured out either at configuration time or on runtime.
| > E.g. just check if the ethertype is 0x8100 and add the next vlan tag as
| > 0x88a8. This would also allow to use a bridge for qinq setups. Because of
| > this I think doing it on runtime is the best.
| > 
| 
| here is another approach defining QinQ-compliant interfaces as a new
| cloner type; so you can stack 0x88a8 devices as you wish and it
| doesn't need a new button in ifconfig.  it also uses a dedicated vlan
| tag hash for "Service VLANs" to avoid tag/Id conflicts.
| 
| # ifconfig em0 up
| # ifconfig svlan100 vlandev em0
| # ifconfig vlan200 vlandev svlan100 192.168.2.100
| 
| reyk
| 
| Index: share/man/man4/vlan.4
| ===================================================================
| RCS file: /cvs/src/share/man/man4/vlan.4,v
| retrieving revision 1.31
| diff -u -p -r1.31 vlan.4
| --- share/man/man4/vlan.4	26 Jun 2008 05:42:07 -0000	1.31
| +++ share/man/man4/vlan.4	21 Aug 2008 19:18:42 -0000
| @@ -31,8 +31,9 @@
|  .Dt VLAN 4
|  .Os
|  .Sh NAME
| -.Nm vlan
| ...
[ message continues ]

I have a need for this patch and I would like to test it on OpenBSD 4.5.
the patch no longer applies in part because of changes to if_bridge.c
in Revision 1.173

I was wondering if someone had a updated patch laying around, also
what is the likelihood of this patch ever getting committed?

Sam Fourman Jr.
Fourman Networks

[ message continues ]

we might want to settle for that..

[ message continues ]

Hi Misc@ and Reyk@,
I'd been watching the src at cvs for a while, I can't see that Reyk@ patch  
is submitted to cvs. Is there some issues? I'd like to know if there is.
So far the our machines is not complaining or anything right now.
Thanks,


Insan

-- 
insandotpraja(at)gmaildotcom

[ message continues ]

On Fri, 22 Aug 2008 02:34:12 +0700, Reyk Floeter <reyk@openbsd.org> wrote:
Hi Reyk,
I just update my source from anoncvs1.ca.openbsd.org and I got conflict on  
"sys/net/if_vlan.c", "sys/net/if_bridge.c" and "sys/net/if_ethersubr.c"  
and yes, a couple months ago I use your QinQ patch on my machines. I  
really like to try to solve this on my own, but currently there is no  
software engineer around to help me.
I understand if you suggested me to follow the original code, and I really  
appreciate if you can help me to adjust the source code. from cvsweb, the  
later changes due to;

* Allow ether_input() and vlan_input() to handle incoming packets
   where the tag is stored in the mbuf header.
* Make bridge(4) handle interfaces with and without hardware tag
   support and forward packets inbetween.

by Claudio Jeker.

Below are the conflicted lines;

/usr/src/sys/net/if_vlan.c


<<<<<<< if_vlan.c
                 if ((p->if_capabilities & IFCAP_VLAN_HWTAGGING) &&
                     (ifv->ifv_type == ETHERTYPE_VLAN)) {
                         m->m_pkthdr.rcvif = ifp;
                         m->m_flags |= M_PROTO1;
=======
                 if (p->if_capabilities & IFCAP_VLAN_HWTAGGING) {
                         m->m_pkthdr.ether_vtag = ifv->ifv_tag;



<<<<<<< if_vlan.c
         tagh = etype == ETHERTYPE_QINQ ? svlan_tagh : vlan_tagh;
         tag = EVL_VLANOFTAG(ntohs(*mtod(m, u_int16_t *)));

         LIST_FOREACH(ifv, &tagh[TAG_HASH(tag)], ifv_list) {
                 if (m->m_pkthdr.rcvif == ifv->ifv_p && tag == ifv->ifv_tag  
&&
                     etype == ifv->ifv_type)
=======
         LIST_FOREACH(ifv, &vlan_tagh[TAG_HASH(tag)], ifv_list) {

/usr/src/sys/net/if_bridge.c

<<<<<<< if_bridge.c
         if ((etype == ETHERTYPE_VLAN || etype == ETHERTYPE_QINQ) &&
             (ifp->if_capabilities & IFCAP_VLAN_MTU) &&
             ((m->m_pkthdr.len - sizeof(struct ether_vlan_header)) <=
             ifp->if_mtu)) {
                 s = splnet();
   ...
[ message continues ]

I have looked in the cvs commit logs, and I am unable to determine if
this patch was ever committed?
can anyone confirm if QinQ support is in OpenBSD?

Sam Fourman Jr.
Fourman Networks

[ message continues ]