Project

General

Profile

Bug #4669

QinQ virtual interfaces available for assignment where they shouldn't be

Added by Chris Buechler about 2 years ago. Updated 27 days ago.

Status:
Resolved
Priority:
Normal
Category:
Interfaces
Target version:
Start date:
05/01/2015
Due date:
% Done:

0%

Affected version:
2.3.x
Affected Architecture:
All

Description

Creating a QinQ VLAN adds 3 interfaces to the assign interfaces tab. For instance, add a QinQ on em1 with tag 5, QinQ 6. You end up with 3 new interfaces for assignment, em1_5, em1_5_6, and "QinQ 6". Assigning either em1_5 or em1_5_6 results in an interface mismatch upon reboot. The assignment screen needs to hide the em1_5 and em1_5_6 interfaces.

Associated revisions

Revision 5ec2eb9b
Added by Doktor Notor 3 months ago

Add QinQ interfaces to the list of interfaces not to check (Bug #4669)

Revision 44fc37ee
Added by Doktor Notor about 2 months ago

Add QinQ interfaces to the list of interfaces not to check (Bug #4669)

Revision 0f29b3a0
Added by Doktor Notor about 2 months ago

Add QinQ interfaces to the list of interfaces not to check (Bug #4669)

History

#1 Updated by Steve Wheeler about 2 years ago

Having run some tests this appears to be broken beyond just exposing the raw interface names.
Choosing the QinQ name in interface assignments results in the interface appearing to be disabled.
Choosing the raw name shows the interface as up but I'm unable to pass any traffic across the resulting QinQ link. Though the first level VLAN is able to pass traffic if the raw name is selected. It prevent a clean boot though as described above.
With a QinQ interface assigned the following error is shown at boot: ngctl: send msg: No such file or directory.

#2 Updated by Steve Wheeler about 2 years ago

There appear to be three distinct issues here. Documenting it before I forget.
1. The generated netgraphcmd file seems incorrect, it's using the parent interface instead of the VLAN interface.
This can be corrected by changing 'qinqif' to 'vlanif' where the first half of the file is generated in interface_qinq_configure() in /etc/inc/interfaces.inc.
Doing just that allows traffic to flow and captures show both tags.
2. The interface assigned when 'QinQ 100', for example, is chosen is incorrect. It assigns 'vlan21_100' (for example) but that does not exist it should be assigning em1_21_100.
That can be corrected in the 'add qinq interfaces section' of /usr/local/www/interfaces_assign.php. That then allows you to choose 'QinQ 100'rather than the raw interface name. That name should be better though IMHO. Somthing like 'QinQ 100 in VLAN 21 on em1'.
3. QinQ interfaces need to be excluded from the interfaces mismatch check in 'is_interface_mismatch()' in /etc/inc/util.inc. They don't exist when it's run. It might be easier to just include 'vlan' in the name somehow.

#3 Updated by Steve Wheeler almost 2 years ago

I have a set if patches that attempt to address the three points above. They seem to allow QinQ to work in my testing but could probably use some refinement.
1. Allow the QinQ interfaces to pass the interface mismatch check:
https://github.com/stephenw10/pfsense/commit/6a03a8ca8d528449a59f1ac1fed24cc3cfd8d024
2. Create the netgraphcmd file to use the vlan interface not it's parent:
https://github.com/stephenw10/pfsense/commit/c821a915b1228ed734a6439d816d4ab04590e8cb
3. Allow sellecting the QinQ interface in interface assingment, alsop removing the underlying VLAN:
https://github.com/stephenw10/pfsense/commit/b3b59037bcd268337ae907a7d4969e987bf72d83

That last one is more of a suggestion because it doesn't remove the actual interface.

#4 Updated by Steve Wheeler almost 2 years ago

This commit is also required to get the QinQ interface selection correct:
https://github.com/stephenw10/pfsense/commit/643cf3e805714bce2ce432fb09bd6e012259ff9f

#5 Updated by Steve Wheeler about 1 year ago

This is still broken in 2.3 though the exact form of the problem seems to have changed slightly.
See: https://forum.pfsense.org/index.php?topic=110459.0

#6 Updated by Luiz Otavio O Souza 12 months ago

  • Assignee set to Luiz Otavio O Souza

#7 Updated by Timo Nieminen 8 months ago

The patch 1. is missing on 2.3.2-RELEASE-p1. Booting system with QinQ interfaces assigned will only trigger vlan assignment tool because of missing interfaces.

Manually patching /etc/inc/util.inc to ignore vman interfaces identified by "_\d{0,4}_\d{0,4}" fixed the issue. Now I have working QinQ interfaces.

Would be nice to have this fixed in future releases, any manual patching is very bad for upgrades.

Steve Wheeler wrote:

I have a set if patches that attempt to address the three points above. They seem to allow QinQ to work in my testing but could probably use some refinement.
1. Allow the QinQ interfaces to pass the interface mismatch check:

#8 Updated by Kill Bill 3 months ago

Timo Nieminen wrote:

The patch 1. is missing on 2.3.2-RELEASE-p1. Booting system with QinQ interfaces assigned will only trigger vlan assignment tool because of missing interfaces.
Manually patching /etc/inc/util.inc to ignore vman interfaces identified by "_\d{0,4}_\d{0,4}" fixed the issue. Now I have working QinQ interfaces.

https://github.com/pfsense/pfsense/pull/3635

#9 Updated by Kill Bill about 2 months ago

Merged, please test with latest 2.3.4/2.4 snapshot.

#10 Updated by Jim Pingle about 2 months ago

  • Target version set to 2.3.4
  • Affected version changed from All to 2.3.x
  • Affected Architecture set to All

#11 Updated by Jim Pingle about 2 months ago

  • Status changed from Confirmed to Feedback

#12 Updated by Jim Pingle 27 days ago

  • Status changed from Feedback to Resolved

I only see one QinQ interface available to assign for each tag now, and it does not cause a mismatch at boot when selected.

Also available in: Atom PDF