Greetings! I wanted to submit a feature request to allow 802.1Q VLAN priority tagging on interfaces through the GUI.
For instance, in some parts of the US where Google Fiber is available, they require both a VLAN tag and a priority tag for WAN traffic. It would be much easier to support IPFire in these scenarios if the priority tag were enabled in the GUI. I have access to several of these WAN links and I could be a tester for these GUI additions.
Do you have some more technical documentation about what you need?
Yes, I think these are technically referred to an ingress and egress priority. Here’s an old thread referencing the same issue I am seeing: https://forum.ipfire.org/viewtopic.php?t=7877
If possible, integrating ingress/egress priority config options in the GUI would be very helpful. It could go on the same page where the VLANs are also defined.
And you are using PPPoE with Google Fibre or how did you set up your IPFire box for it?
For Google Fiber they just provide a PON jack with an ethernet port. They do not use PPPoE. As long as the VLAN and egress COS bit are set, the service will function and provide a DHCP address to the WAN interface.
I tried to get IPFire up and running using the vconfig syntax in the link above but I did not have any luck. I went back to testing in a VM to see if I can get the COS bit set but so far, the commands I am running do not seem to have an effect. It’s also possible that the old thread I am referencing is using a deprecated command and maybe I need to be using a newer method?
I know that setting the COS bit is needed because I can use other firewalls that support this and the service fires up immediately. I think it’s just the missing COS bit on IPFire that is preventing it from working. I’m happy to try to test pilot this too and determine a good solution to get IPFire working.
Just to update this a bit. I figured out how to get this working but it is not staying persistent between reboots.
First I have to run these commands to get my egress priority set:
vconfig add red0 2
vconfig set_egress_map red0.2 0 3
Then I can verify these are in place with the following:
This fires up and Google Fiber works correctly with these settings. I have also gone in to IPFire’s Network/Zone Configuration and set my Red interface to VLAN 2.
The Zone Configuration is persistent because it’s done through the IPFire GUI. However, the vconfig settings are not staying between reboots.
This reminds me when I was trying to setup Unbound DNS over TLS with IPFire and various bootup scripts kept running over my settings. Does anyone with more knowledge of IPFire know how I can make the above settings persistent? Is it possible to add these config options to the Zone Configuration page?
I stand corrected, Google Fiber is not giving me full upload speeds because my vconfig parameters do not seem to be changing the egress traffic on IPFire. At first I thought this was successful because I was able to pull a WAN IP address via DHCP, but this is only due to VLAN 2 tagging on the RED interface.
Google requires VLAN tagging and also wants the 802.1p COS set to 3. Once set to 3, Google will allow full download and upload speed. Without setting to 3, Google will temporarily allow full download and a small upload (10mbits).
So unfortunately, I thought I had this resolved but the egress priority is not working. Does anyone else have any thoughts on this? I’d like to use IPFire but I can’t at this point due to these lack of abilities. I have to use pfSense or OPNsense to get the VLAN tagging and CoS bit set.
I am interested in this, but I have no documentation to look at yet and so I do not know what would be the best way to implement it into IPFire.
I’ve got some good news, I was able to finally get this working. My mistake was that I was using red0.2 for VLAN2 tagging. From what I can tell, it looks like the interface is just renamed to red0 at startup, regardless of the VLAN config. Because of this, my syntax was incorrect.
Below is what I had to do to successfully get IPFire working with Google Fiber. It has been stable for the last 72 hours and is working quite well.
- Configure Network Zones to use VLAN 2 on WAN
- at command prompt run: vconfig set_egress_map red0 0 3
- verify egress COS bit set with: cat /proc/net/vlan/red0
- add ‘vconfig set_egress_map red0 0 3’ to file /etc/sysconfig/rc.local
Adding the /etc/sysconfig/rc.local is key to ensure that the setting gets re-applied during patches and reboots. Does this help to provide better details on what needs to be added to the GUI?
That won’t be overwritten in any updates, etc. But how do we integrate this properly into IPFire?
I suppose we cannot enable this by default because it would break things for other users?
Unfortunately this is where I start to fall off because I am not a developer. However, my thought process is that VLAN selection is already integrated in to the IPFire GUI. There is a back end process that is configuring the interface and also ensuring that the selected VLAN stays permanent between reboots.
I agree, egress maps are not something we would want to enable for all users. Ideally I think what we could have the ability to set the egress map from the VLAN GUI page by invoking the same backend that changes the VLAN to also be able to set the egress map if necessary.
And since we know that the ‘vconfig’ command is working on IPFire, I don’t think we would need to add anything by installing extra binaries or packages. I’ve tried to better understand some of the interface configuration scripts but I still get lost looking at them, especially if they reference other scripts. I’m a relative newbie at this still.
Also more information, while I titled this thread 802.1Q I think the feature I am referring to is actually referenced as 802.1p CoS (Class of Service). https://en.wikipedia.org/wiki/IEEE_P802.1p
When invoking the vconfig command: vconfig set_egress_map red0 0 3
The ‘0’ references the SKB buffer priority, which I left default. The ‘3’ references the CoS bit and that is the specific priority that my ISP wants my outbound traffic to have.
Somewhat confusing, this seems to cross reference between 802.1p and 802.1q, for instance here’s the screenshot from the pfSense page for the same configuration, they reference 802.1q.