Xen xn NICs can't tag VLANs
Interface xn0 is not listed on "Interfaces: VLAN: Edit" for using as parent interface.
On XEN interface xn0 didn't have hardware based tagging. But tagging is possible:
Other Ethernet interfaces can run VLANs using software emulation in the vlan driver.
#ifconfig vlan12 create #ifconfig vlan12 vlan 12 vlandev xn0 #ifconfig xn0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=3<RXCSUM,TXCSUM> ether 02:0a:32:c0:78:04 inet6 fe80::a:32ff:fec0:7804%xn0 prefixlen 64 scopeid 0x5 inet 192.168.180.92 netmask 0xffffff00 broadcast 192.168.180.255 nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL> media: Ethernet manual status: active vlan12: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1496 ether 02:0a:32:c0:78:04 inet 10.32.12.123 netmask 0xffffff00 broadcast 10.32.12.255 inet6 fe80::a:32ff:fec0:7804%vlan12 prefixlen 64 scopeid 0x7 nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL> media: Ethernet manual status: active vlan: 12 vlanpcp: 0 parent interface: xn0 #ping 10.32.12.1 PING 10.32.12.1 (10.32.12.1): 56 data bytes 64 bytes from 10.32.12.1: icmp_seq=0 ttl=64 time=0.469 ms 64 bytes from 10.32.12.1: icmp_seq=1 ttl=64 time=0.214 ms #ssh 10.32.12.1 The authenticity of host '10.32.12.1 (10.32.12.1)' can't be established. RSA key fingerprint is bd:35:80:67:4a:cb:a8:7c:cc:35:fa:4c:1f:e2:10:00. No matching host key fingerprint found in DNS. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '10.32.12.1' (RSA) to the list of known hosts.
#1 Updated by Chris Buechler about 4 years ago
- Subject changed from VLAN tagging always possible to Xen xn NICs can't tag VLANs
- Category set to Operating System
- Status changed from New to Rejected
they don't show up because they report themselves as not being VLAN-capable. Those who have forced their way around the fact that they don't show up have seen major issues. There are problems in xn NICs with VLAN tagging that need to be reported and fixed upstream.
#3 Updated by Grischa Zengel about 4 years ago
That's in the code:
is_jumbo_capable - Test if interface is jumbo frame capable. Useful for determining VLAN capability
But that's not the whole story. Tagging is always possible.
If your interface can't handle jumbo frames you have to reduce MTU and that's what freebsd does.
#5 Updated by Grischa Zengel almost 4 years ago
In XN there couldn't be tagging problems, because it didn't know anything about tagging.
They will tell me that the problems are of the reduced MTU and that some protocols have problems with Path MTU Discovery. Mostly UDP based protocols if fragmentation is disabled.
So what should I report?
I still have the opinion that it should be possible to use tagging on interfaces with smaller MTU.
VLANMTU shows only the fact that an interface can have packet sizes greater than 1512 bytes.
Can you add an switch on Advanced/Interfaces which allows to use tagging with smaller MTU?
Problems with PMTUD Many network security devices block all ICMP messages for perceived security benefits, including the errors that are necessary for the proper operation of PMTUD. This can result in connections that complete the TCP three-way handshake correctly, but then hang when data is transferred. This state is referred to as a black hole connection. Some implementations of PMTUD attempt to prevent this problem by inferring that large payload packets have been dropped due to MTU rather than because of link congestion. However, in order for the Transmission Control Protocol (TCP) to operate most efficiently, ICMP Unreachable messages (type 3) should be permitted. A robust method for PMTUD that relies on TCP or another protocol to probe the path with progressively larger packets has been standardized in RFC 4821. A workaround used by some routers is to change the maximum segment size (MSS) of all TCP connections passing through links with MTU lower than the Ethernet default of 1500. This is known as MSS clamping.
#6 Updated by Grischa Zengel almost 4 years ago
On Interfaces/VLAN is written:
Note: Not all drivers/NICs support 802.1Q VLAN tagging properly. On cards that do not explicitly support it, VLAN tagging will still work, but the reduced MTU may cause problems. See the pfSense handbook for information on supported cards.
So this bug still exists (not only for xn).
It should be my decision if I use vlans for unsupported NICs.
#7 Updated by Eduardo Stelmaszczyk over 3 years ago
I've read many reports about this issue and this one is the best by far. But I still think the problem deservers a bit more clarification. I'm not sure if we're discussing lack of a capability (in this case, VLANMTU) or a bug.
First, could you please provide a link to a report of any kind about the "major issues" encountered by people who "have forced their way around the fact that [the interfaces] don't show up [as VLAN-capable]"? Are these issues related to reduced MTU, as Grischa explained?
Also, you asked us to "please replicate the problem on stock FreeBSD 10.1 and report upstream." What "problem", exactly, are we talking about? VLAN tagging works with stock FreeBSD, unless you're mentioning a not so obvious bug. A FreeBSD developer tested it without problems (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195978) and I tested it too, as did Grischa, without any apparent issues.
In a broader sense, what I don't understand is this: FreeBSD's own vlan creating tool doesn't check if the physical interface reports itself with a VLANMTU capability. Should pfSense do it? As Grischa mentioned, quoting the "vlan" manpage, "other Ethernet interfaces can run VLANs using software emulation in the vlan driver." So, is there really a problem here or is pfSense being too zealous about this?
To sum everything up: are you recommending that we don't use xn NICs with VLANS because of the lack of VLANMTU capability (that's what pfSense checks for, after all) or because of other problems? In the latter case, can you please provide some sources for this?
#8 Updated by Michael Jephcote over 3 years ago
FYI, manually adjusting the select box HTML using an inline edit from the browser allows you to create the VLAN on the correct interface. After doing this VLANs work as expected including DHCP addressing.
I think that pfSense shouldn't be restrictive here and should show all interfaces.