Bug #7748
closed
VLAN Priority
100%
Description
I have a 2.3 and a 2.4 pfSsense system
On both systems I can create a VLAN 832 with Priority 6 (Attachment 1)
Ifconfig on both 2.3 and 2.4 shows the VLAN prio set as I would expect for the VLAN 832 (Attachment 2 & 3)
However a wireshark trace of the dhcp6c request issued over the VLAN shows that at v2.3 the priority is set to 6 (attachment 4) as expected but v2.4 the PRI is 0 not 6 (attachment 5)
Files
| Screen Shot 2017-08-01 at 23.12.12.png (19.9 KB) Screen Shot 2017-08-01 at 23.12.12.png | VLAN 832 Setting | ||
| Screen Shot 2017-08-01 at 23.08.20.png (29.7 KB) Screen Shot 2017-08-01 at 23.08.20.png | ifconfig 2.3 | ||
| Screen Shot 2017-08-01 at 23.13.20.png (50.9 KB) Screen Shot 2017-08-01 at 23.13.20.png | ifconfig 2.4 | ||
| Screen Shot 2017-08-01 at 22.59.08.png (72.5 KB) Screen Shot 2017-08-01 at 22.59.08.png | wireshark 2.3 | ||
| Screen Shot 2017-08-01 at 23.14.01 (1).png (56.6 KB) Screen Shot 2017-08-01 at 23.14.01 (1).png | wireshark 2.4 | ||
| Screenshot from 2017-10-13 11-04-48.jpg (82.6 KB) Screenshot from 2017-10-13 11-04-48.jpg |
Updated by 
.png){kind=link}
Updated by Jim Pingle about 7 years ago
- Category set to Interfaces
- Target version set to 2.4.1
Apparently this negatively impacts users on Google Fiber
https://forum.pfsense.org/index.php?topic=137916.msg754579#msg754579
Updated by Oliver Palmer about 7 years ago
Hey, I'm one of those users thanks for putting this in the queue for 2.4.1.
I did a real quick tcpdump looking for packets with priority 3 set:
tcpdump -ei igb1 | grep "p 3"
After several minutes nothing had matched. I reran without the grep and most packets were coming through with priority 0, 2 or 7. I've extracted a few examples:
11:12:20.104233 WAN_MAC (oui Unknown) > UPSTREAM_MAC_ADDR (oui Unknown), ethertype 802.1Q (0x8100), length 90: vlan 2, p 0, ethertype IPv6, fe80::208:a2ff:fe0b:b80d > ff02::1:ff8e:b351: ICMP6, neighbor solicitation, who has fe80::12e8:78ff:fe8e:b351, length 32 11:12:20.380221 WAN_MAC (oui Unknown) > UPSTREAM_MAC_ADDR (oui Unknown), ethertype 802.1Q (0x8100), length 46: vlan 2, p 0, ethertype IPv4, PUBLIC_IP > PUBLIC_BROADCAST: ICMP echo request, id 36179, seq 493, length 8 11:12:20.381613 UPSTREAM_MAC_ADDR (oui Unknown) > WAN_MAC (oui Unknown), ethertype 802.1Q (0x8100), length 60: vlan 2, p 2, ethertype IPv4, PUBLIC_BROADCAST > PUBLIC_IP: ICMP echo reply, id 36179, seq 493, length 8 11:12:24.400911 UPSTREAM_MAC_ADDR (oui Unknown) > WAN_MAC (oui Unknown), ethertype 802.1Q (0x8100), length 64: vlan 2, p 7, ethertype ARP, Reply PUBLIC_BROADCAST is-at UPSTREAM_MAC_ADDR (oui Unknown), length 46 11:12:26.195384 UPSTREAM_MAC_ADDR (oui Unknown) > WAN_MAC (oui Unknown), ethertype 802.1Q (0x8100), length 809: vlan 2, p 2, ethertype IPv4, WEB_NODE.https > PUBLIC_IP.37044: Flags [P.], seq 64:803, ack 63, win 1109, options [nop,nop,TS val 965621101 ecr 3420879379], length 739 11:12:26.954267 WAN_MAC (oui Unknown) > UPSTREAM_MAC_ADDR (oui Unknown), ethertype 802.1Q (0x8100), length 46: vlan 2, p 0, ethertype IPv4, PUBLIC_IP > PUBLIC_BROADCAST: ICMP echo request, id 52117, seq 0, length 8 11:12:26.955584 UPSTREAM_MAC_ADDR (oui Unknown) > WAN_MAC (oui Unknown), ethertype 802.1Q (0x8100), length 60: vlan 2, p 2, ethertype IPv4, PUBLIC_BROADCAST > PUBLIC_IP: ICMP echo reply, id 52117, seq 0, length 8
Attached is screenshot of my configuration for the vLAN attached to the wan interface. Unfortunately, I don't have a comparison against pfsense 2.3 right now but I might downgrade this weekend and will post the results if I do. Assuming I have the capacity, I'm also happy to help validate the fix when it lands for 2.4.1.
Updated by Oliver Palmer about 7 years ago
Downgraded last night to 2.3.4, packets are now being properly tagged again. Here are some examples:
08:38:57.394096 WAN_MAC (oui Unknown) > UPSTREAM_MAC_ADDR (oui Unknown), ethertype 802.1Q (0x8100), length 70: vlan 2, p 3, ethertype IPv4, PUBLIC_IP.59211 > EXTERNAL_IP.https: Flags [.], ack 11884, win 566, options [nop,nop,TS val 544831721 ecr 26319626], length 0 08:38:57.419667 WAN_MAC (oui Unknown) > UPSTREAM_MAC_ADDR (oui Unknown), ethertype 802.1Q (0x8100), length 46: vlan 2, p 3, ethertype IPv4, PUBLIC_IP > DNS_SERVER: ICMP echo request, id 27638, seq 681, length 8 08:38:57.469671 WAN_MAC (oui Unknown) > UPSTREAM_MAC_ADDR (oui Unknown), ethertype 802.1Q (0x8100), length 87: vlan 2, p 3, ethertype IPv4, PUBLIC_IP.9958 > DNS_SERVER.domain: 32800+ [1au] AAAA? DOMAIN_NAME (41) 08:38:57.469702 WAN_MAC (oui Unknown) > UPSTREAM_MAC_ADDR (oui Unknown), ethertype 802.1Q (0x8100), length 107: vlan 2, p 3, ethertype IPv6, PUBLIC_IP > DNS_SERVER.domain: 41949+ [1au] A? DOMAIN_NAME. (41)
Looks like packets that were previously priority zero are now properly tagged as priority 3.
Updated by Luiz Souza about 7 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Found the regression. Please test the next snapshot.
Updated by Corey Doss about 7 years ago
Luiz Souza wrote:
Found the regression. Please test the next snapshot.
No luck for me (Google Fiber) on snapshot 2.4.1.a.20171018.1713. Maybe the next available build?
Updated by Jim Pingle about 7 years ago
Corey Doss wrote:
No luck for me (Google Fiber) on snapshot 2.4.1.a.20171018.1713. Maybe the next available build?
The fix was put in after that snapshot timestamp, so yes, the next available build should have it. Should be coming sometime this morning for CE, the latest Factory snapshot has the fix but that's just because of how the build timing worked out yesterday apparently.
So far, so good on the Factory snap. I set a priority in the VLAN instance config (Interfaces > Assignments, VLAN tab) and I can see that flag set in the packets as they egress. Setting the VLAN priority number via pf rule doesn't work but that's a separate issue I have moved to #7973
Once the fix for this issue is in the next full set of snapshots and confirmed working, then we can mark this resolved.
Updated by Corey Doss about 7 years ago
2.4.1.a.20171019.0413 seems to have resolved the issue on my end. Thanks everyone.
Updated by Jim Pingle about 7 years ago
- Status changed from Feedback to Resolved