Re: passing vlan priority tag through bridge
On 2011-08-28 02:16, Christiano F. Haesbaert wrote: > Heya, > > So here is a crude diff, the shiffting can be improved and if we wan't > this in the future we'll need a knob to enable "don't touch the > vlanprio thingy". > > Please it would be great if you can give this a spin Peter. I did some > basic tests with a re(4) (hw tagging) and a rl(4) (no hw tagging). Thanks, tested and works like a charm: Before patch: em1: 15:13:55.762101 00:04:96:51:71:80 01:04:96:51:71:80 8100 66: 802.1Q vid 500 pri 7 snap 0:e0:2b:0:bb sap aa ui/C len=37 15:13:55.762400 00:04:96:51:71:80 01:04:96:51:71:80 8100 66: 802.1Q vid 500 pri 0 snap 0:e0:2b:0:bb sap aa ui/C len=37 15:13:56.201398 00:1e:0b:2b:eb:ed 88:ae:1d:b5:94:e1 8100 102: 802.1Q vid 500 pri 2 192.168.0.1 > 192.168.0.2: icmp: echo request (id:21e1 seq:623) (DF) (ttl 64, id 0, len 84) 15:13:56.201553 88:ae:1d:b5:94:e1 00:1e:0b:2b:eb:ed 8100 102: 802.1Q vid 500 pri 0 192.168.0.2 > 192.168.0.1: icmp: echo reply (id:21e1 seq:623) (ttl 64, id 42697, len 84) em0: 15:13:55.762116 00:04:96:51:71:80 01:04:96:51:71:80 8100 66: 802.1Q vid 1500 pri 0 snap 0:e0:2b:0:bb sap aa ui/C len=37 15:13:55.762388 00:04:96:51:71:80 01:04:96:51:71:80 8100 66: 802.1Q vid 1500 pri 7 snap 0:e0:2b:0:bb sap aa ui/C len=37 15:13:56.201412 00:1e:0b:2b:eb:ed 88:ae:1d:b5:94:e1 8100 102: 802.1Q vid 1500 pri 0 192.168.0.1 > 192.168.0.2: icmp: echo request (id:21e1 seq:623) (DF) (ttl 64, id 0, len 84) 15:13:56.201547 88:ae:1d:b5:94:e1 00:1e:0b:2b:eb:ed 8100 102: 802.1Q vid 1500 pri 2 192.168.0.2 > 192.168.0.1: icmp: echo reply (id:21e1 seq:623) (ttl 64, id 42697, len 84) After patch: em1: 15:07:07.277884 00:04:96:51:71:80 01:04:96:51:71:80 8100 66: 802.1Q vid 500 pri 7 snap 0:e0:2b:0:bb sap aa ui/C len=37 15:07:07.278039 00:04:96:51:71:80 01:04:96:51:71:80 8100 66: 802.1Q vid 500 pri 7 snap 0:e0:2b:0:bb sap aa ui/C len=37 15:07:07.576643 00:1e:0b:2b:eb:ed 88:ae:1d:b5:94:e1 8100 102: 802.1Q vid 500 pri 2 192.168.0.1 > 192.168.0.2: icmp: echo request (id:21e1 seq:214) (DF) (ttl 64, id 0, len 84) 15:07:07.576794 88:ae:1d:b5:94:e1 00:1e:0b:2b:eb:ed 8100 102: 802.1Q vid 500 pri 2 192.168.0.2 > 192.168.0.1: icmp: echo reply (id:21e1 seq:214) (ttl 64, id 42409, len 84) em0: 15:07:07.277901 00:04:96:51:71:80 01:04:96:51:71:80 8100 66: 802.1Q vid 1500 pri 7 snap 0:e0:2b:0:bb sap aa ui/C len=37 15:07:07.278029 00:04:96:51:71:80 01:04:96:51:71:80 8100 66: 802.1Q vid 1500 pri 7 snap 0:e0:2b:0:bb sap aa ui/C len=37 15:07:07.576658 00:1e:0b:2b:eb:ed 88:ae:1d:b5:94:e1 8100 102: 802.1Q vid 1500 pri 2 192.168.0.1 > 192.168.0.2: icmp: echo request (id:21e1 seq:214) (DF) (ttl 64, id 0, len 84) 15:07:07.576788 88:ae:1d:b5:94:e1 00:1e:0b:2b:eb:ed 8100 102: 802.1Q vid 1500 pri 2 192.168.0.2 > 192.168.0.1: icmp: echo reply (id:21e1 seq:214) (ttl 64, id 42409, len 84) This was tested with an extreme networks summit 450 switch with prio tagging on the ports going into the fw on both sides and clients on untagged ports on both sides. Again, many thanks and I hope this could be implemented with or without a knob. //Peter
Re: passing vlan priority tag through bridge
Heya,
So here is a crude diff, the shiffting can be improved and if we wan't
this in the future we'll need a knob to enable "don't touch the
vlanprio thingy".
Please it would be great if you can give this a spin Peter. I did some
basic tests with a re(4) (hw tagging) and a rl(4) (no hw tagging).
Index: sys/net/if_vlan.c
===
RCS file: /cvs/src/sys/net/if_vlan.c,v
retrieving revision 1.88
diff -d -u -p -w -r1.88 if_vlan.c
--- sys/net/if_vlan.c 20 Aug 2011 06:21:32 - 1.88
+++ sys/net/if_vlan.c 28 Aug 2011 05:15:37 -
@@ -225,6 +225,11 @@ vlan_start(struct ifnet *ifp)
*/
if ((p->if_capabilities & IFCAP_VLAN_HWTAGGING) &&
(ifv->ifv_type == ETHERTYPE_VLAN)) {
+ /* Don't touch the priority */
+ if (m->m_flags & M_VLANPRIO) {
+ m->m_pkthdr.ether_vtag &= ~EVL_VLID_MASK;
+ m->m_pkthdr.ether_vtag |= ifv->ifv_tag;
+ } else
m->m_pkthdr.ether_vtag = ifv->ifv_tag +
(ifv->ifv_prio << EVL_PRIO_BITS);
m->m_flags |= M_VLANTAG;
@@ -234,6 +239,12 @@ vlan_start(struct ifnet *ifp)
m_copydata(m, 0, ETHER_HDR_LEN, (caddr_t)&evh);
evh.evl_proto = evh.evl_encap_proto;
evh.evl_encap_proto = htons(ifv->ifv_type);
+ if (m->m_flags & M_VLANPRIO)
+ /* XXX can be simpler */
+ evh.evl_tag = htons(ifv->ifv_tag +
+ (EVL_PRIOFTAG(m->m_pkthdr.ether_vtag)
+ << EVL_PRIO_BITS));
+ else
evh.evl_tag = htons(ifv->ifv_tag +
(ifv->ifv_prio << EVL_PRIO_BITS));
@@ -319,9 +330,13 @@ vlan_input(struct ether_header *eh, stru
* reentrant!).
*/
m->m_pkthdr.rcvif = &ifv->ifv_if;
+ m->m_flags |= M_VLANPRIO; /* XXX test only remove me */
if (m->m_flags & M_VLANTAG) {
m->m_flags &= ~M_VLANTAG;
} else {
+ if (m->m_flags & M_VLANPRIO)
+ m->m_pkthdr.ether_vtag =
+ ntohs(*mtod(m, u_int16_t *));
eh->ether_type = mtod(m, u_int16_t *)[1];
m->m_len -= EVL_ENCAPLEN;
m->m_data += EVL_ENCAPLEN;
Index: sys/sys/mbuf.h
===
RCS file: /cvs/src/sys/sys/mbuf.h,v
retrieving revision 1.155
diff -d -u -p -w -r1.155 mbuf.h
--- sys/sys/mbuf.h 8 Jul 2011 18:48:51 - 1.155
+++ sys/sys/mbuf.h 28 Aug 2011 03:58:05 -
@@ -71,7 +71,7 @@ struct m_hdr {
caddr_t mh_data;/* location of data */
u_int mh_len; /* amount of data in this mbuf */
short mh_type;/* type of data in this mbuf */
- u_short mh_flags; /* flags; see below */
+ u_int32_t mh_flags; /* flags; see below */
};
/* pf stuff */
@@ -171,10 +171,12 @@ struct mbuf {
#define M_AUTH_AH 0x2000 /* header was authenticated (AH) */
#define M_COMP 0x4000 /* header was decompressed */
#define M_LINK00x8000 /* link layer specific flag */
+#define M_VLANPRIO 0x1 /* vlanprio bits are valid */
/* flags copied when copying m_pkthdr */
#defineM_COPYFLAGS
(M_PKTHDR|M_EOR|M_PROTO1|M_BCAST|M_MCAST|M_CONF|M_COMP|\
-M_AUTH|M_LOOP|M_TUNNEL|M_LINK0|M_VLANTAG|M_FILDROP)
+M_AUTH|M_LOOP|M_TUNNEL|M_LINK0|M_VLANTAG|M_FILDROP|\
+M_VLANPRIO)
/* Checksumming flags */
#defineM_IPV4_CSUM_OUT 0x0001 /* IPv4 checksum needed */
Re: passing vlan priority tag through bridge
On 2011-08-21 23:33, Christiano F. Haesbaert wrote: > > I have a partial diff for this. > > Unfortunately I couldn't test so I'll need more time. > > The idea is to flag the incoming packet with a new flag M_VLANPRIO > which signals vlan(4) to not touch the vlanprio in vlan_start(). > > It's a proof-of-concept only, having something like this will probably > involve a lot of talk. > > Sorry my diff is not showable at this time. Wonderful. No stress. Thx, Peter
Re: passing vlan priority tag through bridge
On Fri, Aug 19, 2011 at 09:07:42AM +0200, Peter Hallin wrote: > Hello, > > I have a question. > > We use bridging firewalls at Lund University with different vlan tags on > respective sides of the bridges. The frames are therefore "retagged" > when passing through the bridge and unforunatley the priority flag gets > reset and always ends up as 0 on the other side. > > We would love to be able to let the priority flag pass the bridge and I > wonder if this could be possible in a not so distant future. > > In if_vlan.c, there is a comment regarding the prio flag: > > /* > * if_vlan.c - pseudo-device driver for IEEE 802.1Q virtual LANs. > * Might be extended some day to also handle IEEE 802.1p priority > * tagging. This is sort of sneaky in the implementation, since > * we need to pretend to be enough of an Ethernet implementation > * to make arp work. The way we do this is by telling everyone > * that we are an Ethernet, and then catch the packets that > * ether_output() left on our output queue when it calls > * if_start(), rewrite them for use by the real outgoing > * interface, > * and ask it to send them. > * > * Some devices support 802.1Q tag insertion in firmware. The > * vlan interface behavior changes when the > * IFCAP_VLAN_HWTAGGING > * capability is set on the parent. In this case, > * vlan_start() > * will not modify the ethernet header. > */ > I have a partial diff for this. Unfortunately I couldn't test so I'll need more time. The idea is to flag the incoming packet with a new flag M_VLANPRIO which signals vlan(4) to not touch the vlanprio in vlan_start(). It's a proof-of-concept only, having something like this will probably involve a lot of talk. Sorry my diff is not showable at this time.
passing vlan priority tag through bridge
Hello, I have a question. We use bridging firewalls at Lund University with different vlan tags on respective sides of the bridges. The frames are therefore "retagged" when passing through the bridge and unforunatley the priority flag gets reset and always ends up as 0 on the other side. We would love to be able to let the priority flag pass the bridge and I wonder if this could be possible in a not so distant future. In if_vlan.c, there is a comment regarding the prio flag: /* * if_vlan.c - pseudo-device driver for IEEE 802.1Q virtual LANs. * Might be extended some day to also handle IEEE 802.1p priority * tagging. This is sort of sneaky in the implementation, since * we need to pretend to be enough of an Ethernet implementation * to make arp work. The way we do this is by telling everyone * that we are an Ethernet, and then catch the packets that * ether_output() left on our output queue when it calls * if_start(), rewrite them for use by the real outgoing * interface, * and ask it to send them. * * Some devices support 802.1Q tag insertion in firmware. The * vlan interface behavior changes when the * IFCAP_VLAN_HWTAGGING * capability is set on the parent. In this case, * vlan_start() * will not modify the ethernet header. */ Sounds tricky, but can it be done? Any feedback highly appreciated. Brgds, Peter -- -- Peter Hallin IT-Security and firewalls LDC, Lunds Universitet Margaretav. 1A, 222 40, LUND http://www.ldc.lu.se
