I'm having some problems with queueing using pf on a bridge (3.3 i386 GENERIC).
I'm using priority queuing with 10 queues, the default queue being the lowest priority one. It appears as though arp request frames going through the bridge are being put into the default queue, and that it is not possible to change this behavior. Often, while arp request frames are being sent, all available bandwidth is consumed by the higher priority queues, so the arp frames are queued. When the bandwidth spike subsides, all of these arp packets are sent at once, which results in a large batch of arp replies. For example, a client will send out an arp request frame every second or two. After 10-20 seconds or so, it will stop. A few seconds after that (sometimes quite a bit longer, depending on traffic), it will get sent 10-20 arp reply frames within a tenth of a second. I watched tcpdumps of this happening in real time with the following commands (running on different TTYs on the bridge): tcpdump -ni rl0 arp #external NIC tcpdump -ni rl1 arp #internal NIC tcpdump -ni bridge0 arp tcpdump -ni pflog0 The arp request frames would show up right away on rl1 and bridge0, but they wouldn't show up on rl0 or pflog0 (all pf rules are on rl0). After traffic subsided, all of the arp request frames would show up on rl0, quickly followed by a bunch of arp reply frames, which would immediately show up on rl0, bridge0, and rl1 (in that order). From monitoring pflog0, I can see that no arp frames are getting blocked. I conclude from this behavior that pf is queuing the arp request frames outbound (there is no queuing on the inbound NIC). Since they are layer 2 frames and not layer 3/4 packets, there doesn't seem to be anyway to change which in queue they are placed. Is there any way to assign arp frames to a different queue?
