Traffic appearing in multiple queues when using VLANs
-
Hi! I have the following interfaces and queues set up:
-
vtnet0_vlan2 (WAN - DHCP)
-
qInternet
-
qACK
-
qDefault
-
qVoip
-
qOthersHigh
-
qOthersLow
-
-
-
vtnet0 (LAN - 10.0.1.0/24)
-
qLink
-
qInternet
-
qACK
-
qDefault
-
qVoip
-
qOthersHigh
-
qOthersLow
-
-
-
vtnet0_vlan3 (Private - 10.0.3.0/24)
-
qLink
-
qInternet
-
qACK
-
qDefault
-
qVoip
-
qOthersHigh
-
qOthersLow
-
-
-
vtnet0_vlan4 (Public - 10.0.4.0/24)
-
qLink
-
qInternet
-
qACK
-
qDefault
-
qVoip
-
qOthersHigh
-
qOthersLow
-
-
-
vtnet0_vlan5 (VOIP - 10.0.5.0/24)
-
qLink
-
qInternet
-
qACK
-
qDefault
-
qVoip
-
qOthersHigh
-
qOthersLow
-
-
I have created firewall match rules for traffic from the 10.0.5.0/24 network and put this in to the qVoip queue. This is the only rule that assigns anything to qVoip.
When I make a voip call I see (via Status > Queues) traffic in qVoip on the VOIP interface and the WAN interface (as expected), but I also see exactly the same traffic (same pps and bandwidth) on qVoip which falls under LAN.
Why is this traffic appearing here as well as on the correct (VOIP) interface?
What are the implications of the traffic appearing here? For example, will pfSense be trying to allow for this VOIP traffic on both the LAN and VOIP interface and therefore allocating too much of the available bandwidth to qVOIP (since it thinks there is traffic on both interfaces)?
I also see a similar situation when I apply rules to put PUBLIC (10.0.4.0/24) traffic in to qOthersLow.
As you can see, all my interfaces are based on 1 physical interface card. I know this is not going to give absolutely the best performance, but it is adequate for the amount of traffic we are using.
-
-
I had a similar setup and experienced the same behavior.
I think this is what is going on with the traffic flow when using one physical interface for one or multiple VLANs and would explain why the traffic shows up in multiple queues. I am just guessing here and would be happy if someone can confirm my theory or provide a correct answer.
Traffic flow by interface
Inbound: WAN->LAN->VLAN->HOST
Outbound: HOST->VLAN->LAN->WAN
*note that I do not mean the VLAN traffic passes through the LAN network, just the interfaceIn my theory you can see that the traffic passes through both the LAN and the VLAN which would explain why the traffic ends up in both the VLAN queues and the LAN queues. This might be because the traffic shaper runs in promiscuous mode on the LAN or could be just the way the traffic flows through the system. Or I could be entirely wrong.
What I ended up doing was just creating traffic shaping rules on the LAN and WAN and used a combination of alias and firewall rules to place the traffic into the correct queues.
-
Do you have an example of how you did that? I haven't applied any of my rules to any specific interface, I've just left them on the "floating" tab and applied them where the traffic is for an IP an a particular subnet (that subnet happens to me on of the VLANs).
On a perhaps related note, I have noticed that the bandwidth graph on the home status screen shows by currently used bandwidth on the WAN interface to be exactly double what is in use. Could this be related in some way?
-
Before changing anything with your setup I would suggest to wait until someone can confirm my assumptions. I could be totally wrong.
I have two shapers running, one on my LAN and the other on my WAN.
LAN
ACK
High
Medium
Low
DefaultWAN
ACK
High
Medium
Low
DefaultI have floating rules that match on specific traffic that places the traffic into whichever queue I want. I would be willing to bet my setup is pretty similar to yours, just simpler because I am only running two shapers (LAN and WAN).
In my theory all your inbound traffic is going to pass through the LAN interface so shaping the inbound traffic there should work and it will not be necessary to shape on your VLANs. All your outbound traffic should be shaped on the WAN.
Please note that when I say "pass through the LAN interface", I mean the interface itself, not the LAN network.
Again, could be totally wrong. I am just making assumptions from the behavior I have seen in my own setup.
-
Thanks for your reply.
I had another look at my setup and realised that I am kind of in a fortunately situation in that I have pfSense running in a Proxmox VM. Again, I know this is not an idea situation, but in this case I think it will actually help me.
Instead of giving the VM one network card and using VLANs within pfSense, I have now changed my VM network configuration to give the VM 5 virtual network cards (each of them assigned to different VLANs within Proxmox. This way pfSense see these as completely distinct interfaces, rather than having to VLAN the one interface within pfSense.
So far, it looks as if this has solved my double traffic issue within the queues, although I am still seeing double the traffic on the WAN interface when I look at the bandwidth section on the home status screen (but that is something I can fight with on another day).
-
The shaper is messed up in many ways, this is one of them.
This "bug" could easily become a "feature" if you have two physical interfaces and you run your WAN VLANs on one of the them and your LAN VLANs on the other. This "traffic grouping" you see is the only practical way to achieve proper multi-LAN shaping (when you have multiple internal networks, you actually want all the traffic on the same parent queue, from a shaper standpoint)