Project

General

Profile

Bug #4103

Xen xn NICs can't tag VLANs

Added by Grischa Zengel about 4 years ago. Updated over 3 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
Operating System
Target version:
-
Start date:
12/12/2014
Due date:
% Done:

0%

Estimated time:
Affected Version:
2.2
Affected Architecture:
amd64

Description

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:

https://www.freebsd.org/cgi/man.cgi?query=vlan

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.

History

#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.

#2 Updated by Grischa Zengel about 4 years ago

That's to lapidary.
Tagging is something which is handled by software and could be in hardware.
Without anything written I didn't believe.

#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.

#4 Updated by Chris Buechler about 4 years ago

There are problems in VLAN tagging in that driver. That's outside of our control. Please replicate the problem on stock FreeBSD 10.1 and report upstream.

#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?

http://en.wikipedia.org/wiki/Path_MTU_Discovery:

Problems with PMTUD

Many network security devices block all ICMP messages for perceived security benefits,[6] 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.[7]

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.[8]

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.[9]

#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

Hello Chris,

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?

Thank you,

Eduardo

#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.

Also available in: Atom PDF