vlans over lagg

Huh, funny...

Thanks for your info Knarf.

By the way. I've found that Intel placed new version of em drivers.

em-6.9.21.tar.gz Ver:6.9.21 Date:11/23/2009 Size:199 (KB)

Will try them in a short time...
 
Nope, it doesn't help.
I guess that I will take one more NIC for vlans. :)
Welcome Realtek, because Intel can't make a proper driver? :D
 
To anyone who is having non-panic trouble with em+lagg+vlan: I think I've identified the problem, as I ran into it myself. tcpdumping on the FreeBSD box didn't really show it off, but once I put something on the other end of the active cable to catch frames, I saw that the FreeBSD box is transmitting what wireshark identifies as ISL-tagged frames instead of 802.1q-tagged frames. I've filed PR kern/141646 in the hopes it can get addressed before I need to upgrade my fleet of 7.1 PowerEdge 2850s to 8.x.
 
A workaround

Hello!

The is a workaround for the problem.

Code:
ifconfig_em0="-vlanhwtag up"
ifconfig_em1="-vlanhwtag up"
ifconfig_em2="-vlanhwtag up"
ifconfig_em3="-vlanhwtag up"
cloned_interfaces="lagg0 vlan10"
ifconfig_lagg0="laggproto lacp laggport em0 laggport em1 laggport em2 laggport em3 up"
ifconfig_vlan10="vlan 10 vlandev lagg0 192.168.10.2/24"

Cheers!
 
@vbelousov

I remember that people reported, that em driver has a bug that prevents this (vlan over lagg) because if they moved to Realtek cards (with re driver), vlan over lagg worked like a charm, check mailing lists/ask developers/submit a bug.
 
It is in fact working very well

Ok, let me add more information.

Stock kernel of 8.0-STABLE-201001 (snapshot) had the problem in question. The latest available Intel driver (6.9.21) has the problem also.

In my case, removal of hardware assisted VLAN tagging and hardware assisted VLAN filtering made it working. I tog ~10 perfectly working VLANS at the moment, right how it was in 7.2-STABLE. I discovered that switching off VLAN tagging alone is enough. However, in addition to that I keep TCP Segmentation Offload switched off (and my complete configuration for an interface is:
Code:
ifconfig_em0="rxcsum txcsum -tso -lro promisc polling -vlanhwtag up"   # Keep TSO disabled!!!
and I do not remember why I have the commentary like that, but I had very strong reasons back then to do so).


I will spend some time going through the source code. It really feels like the packets are tagged twice when they go out of the card...

Cheers!
 
vermaden said:
@vbelousov

I remember that people reported, that em driver has a bug that prevents this (vlan over lagg) because if they moved to Realtek cards (with re driver), vlan over lagg worked like a charm, check mailing lists/ask developers/submit a bug.

Yeah, I do remember that too. But I decided to stay on Intel. At lease for a while. Basicly because of multy port configuragtion. I have one quaded and one dual PT and MT controllers. So it's definetely not an option for me. But I have to thank you for your participation pal. :)
 
m1m1n0 said:
Code:
ifconfig_em0="rxcsum txcsum -tso -lro promisc polling -vlanhwtag up"   # Keep TSO disabled!!!


Works just fine here, thanks a lot for sharing the workaround.
This is saving me the troublesome and very dirty solution of not tagging VLANs anymore and splitting my interfaces, 1 per access vlan on the switch, without redundancy.
 
dam23 said:
Works just fine here, thanks a lot for sharing the workaround.
This is saving me the troublesome and very dirty solution of not tagging VLANs anymore and splitting my interfaces, 1 per access vlan on the switch, without redundancy.

Dear dam23, what NICs do you have exactly? And what FreeDSB version?
 
I won't say for dam23, my system is:

[CMD="FreeBSD xx.yyyy.com 8.0-STABLE FreeBSD 8.0-STABLE #3: Tue Jan 26 23:30:00 EET 2010 [email]igor@xx.yyyy.com[/email]:/usr/obj/usr/src/sys/FSFWCLUSTER amd64"][/CMD]
and the em driver is loaded as a module compiled from the source code on the Intel web site.

Code:
em0: <Intel(R) PRO/1000 Network Connection 6.9.21> port 0xdce0-0xdcff mem 0xfd9e0000-0xfd9fffff,0xfd9c0000-0xfd9dffff irq 16 at device 0.0 on pci10
em0: Using MSI interrupt
em0: [FILTER]
em0: Ethernet address: 00:15:17:ff:d8:1e

---------------

em0@pci0:10:0:0:        class=0x020000 card=0x135e8086 chip=0x105e8086 rev=0x06 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'HP NC360T PCIe DP Gigabit Server Adapter (n1e5132)'
    class      = network
    subclass   = ethernet

---------------

Intel PRO/1000 PT Dual Port Server Adapter (82571)

funny that it shows HP NC360T - the card came with a Dell server. :)
 
Code:
FreeBSD xx.yyyy.com 8.0-STABLE FreeBSD 8.0-STABLE #3: Tue Jan 26 23:30:00 EET 2010     igor@xx.yyyy.com:/usr/obj/usr/src/sys/FSFWCLUSTER  amd64
 
Kinda strange that I had no effect by switching off hardware VLAN tagging. Does anyone also has not a positive result?
In any way I'll try it again tonight. May be I did something wrong.
And thank you guys. :)
 
@vbelousov: for some reason and apparently independently of "spanning-tree portfast trunk" on the switch, it takes the box around 30 seconds after becoming fully up (daemons started + console login available) for it to get network connectivity.

Might have to do with us using aggregation, I don't know.

Perhaps you've got the same issue ?
Try giving the box a little time after booting, see how that works out.


The configuration we're running here is:
Code:
FreeBSD 8.0-RELEASE-p2 #0: Tue Jan  5 21:11:58 UTC 2010
Upgraded from 7.2 via freebsd-update
GENERIC kernel for now
amd64

Code:
em0: <Intel(R) PRO/1000 Network Connection 6.9.14> port 0xdce0-0xdcff mem 0xfc3e0000-0xfc3fffff,0xfc3c0000-0xfc3dffff irq 16 at device 0.0 on pci12

em1: <Intel(R) PRO/1000 Network Connection 6.9.14> port 0xdcc0-0xdcdf mem 0xfc3a0000-0xfc3bffff,0xfc380000-0xfc39ffff irq 17 at device 0.1 on pci12

em0@pci0:12:0:0:	class=0x020000 card=0x135e8086 chip=0x105e8086 rev=0x06 hdr=0x00

em1@pci0:12:0:1:	class=0x020000 card=0x135e8086 chip=0x105e8086 rev=0x06 hdr=0x00

Intel cards aggregated as a lagg0 device:
Code:
ifconfig_em0="-vlanhwtag -lro -tso up"
ifconfig_em1="-vlanhwtag -lro -tso up"
ifconfig_lagg0="laggproto failover laggport em0 laggport em1"
ifconfig_vlan16="inet [snip] vlan 16 vlandev lagg0"
 
dam23

You have not created interfaces by cloned_interface command. Your config shouldn't work.

To all.
Thank you all guys, I've tried these keys again and for now it works fine. As dam23 said I just took a little break and it got up.
 
Actually, I do have the following cloned interfaces:
Code:
cloned_interfaces="lagg0 lagg1 vlan666 vlan16 vlan26 vlan36 carp0 carp1 carp2"

I didn't think they were all that relevant so I omitted this line.


Glad it works for you too now.
This solution should be put somewhere in the release notes or wherever.
 
jbhappy said:
A patch for this issue has been developed by Ermal Luçi so that disabling hardware VLAN tagging should no longer be necessary. It's in HEAD now and will be in 8-STABLE in a couple weeks and then in 8.1-RELEASE. See http://lists.freebsd.org/pipermail/freebsd-net/2010-February/024477.html.

The problem still exists in 8.1-RELEASE.

The patch is only in HEAD (r203548) but not in stable. :(

http://redmine.pfsense.org/reposito...?rev=64fd5b02c883db52511a333d8b879eaad2038d11

I've tried it right now and it works (vlan->lagg->em).
 
Contacting the author of the patch may give some insight. Not many devs frequent the forums.

Or, maybe sending an e-mail to the freebsd-current and/or freebsd-stable mailing lists.
 
Back
Top