[RESOLVED] videoconferencing traffic falls into the default queue
-
I've been trying to figure out why most of the videoconference traffic falls into the default queue and it seems that I managed to reach a conclusion, see:
pktstat slice:interface: bce1 total: 437.9Mb (3m45s)
cur: 1.9M (98%) min: 1.9M max: 2.0M avg: 1.9M bps
filter: host 192.168.0.240
bps % b desc
869.8k 44% 195.2M udp 172.16.20.10:55082 -> 192.168.0.240:30002
698.9k 35% 157.8M udp 192.168.0.240:30002 -> 172.16.20.10:55082
229.7k 11% 53.8M udp 192.168.0.240:30004 -> 172.16.20.10:55084
69.5k 3% 15.7M udp 192.168.0.240:30000 -> 172.16.20.10:55080
65.7k 3% 14.7M udp 172.16.20.10:55080 -> 192.168.0.240:30000
911.3 0% 192.4k udp 172.16.20.10:55081 -> 192.168.0.240:30001
911.3 0% 189.7k udp 172.16.20.10:55083 -> 192.168.0.240:30003
601.1 0% 155.7k udp 172.16.20.10:55085 -> 192.168.0.240:30005
99.1 0% 60.5k tcp 192.168.0.240:30007 -> 172.16.20.10:4003
86.3 0% 38.5k tcp 172.16.20.10:4003 -> 192.168.0.240:30007the bold line shows that the traffic is being sent from the host 192.168.0.240 on port 30002 to destination.
However, observing the states table, I realized that the packet filter handles traffic on the contrary, as if coming from the host 172.16.20.10 to 192.168.0.240, thus only part of the traffic get into the right queue while most falls in the default queue as you can see below.pfctl -ss | grep 192.168.0.240
all tcp 192.168.0.240:1720 <- 172.16.20.10:4002 ESTABLISHED:ESTABLISHED
all tcp 172.16.20.10:4002 -> 192.168.0.240:1720 ESTABLISHED:ESTABLISHED
all tcp 192.168.0.240:30007 <- 172.16.20.10:4003 ESTABLISHED:ESTABLISHED
all tcp 172.16.20.10:4003 -> 192.168.0.240:30007 ESTABLISHED:ESTABLISHED
all udp 192.168.0.240:30000 <- 172.16.20.10:55080 MULTIPLE:MULTIPLE
all udp 172.16.20.10:55080 -> 192.168.0.240:30000 MULTIPLE:MULTIPLE
all udp 192.168.0.240:30002 <- 172.16.20.10:55082 MULTIPLE:MULTIPLE
all udp 172.16.20.10:55082 -> 192.168.0.240:30002 MULTIPLE:MULTIPLE
all udp 192.168.0.240:30001 <- 172.16.20.10:55081 NO_TRAFFIC:SINGLE
all udp 172.16.20.10:55081 -> 192.168.0.240:30001 SINGLE:NO_TRAFFIC
all udp 192.168.0.240:30003 <- 172.16.20.10:55083 NO_TRAFFIC:SINGLE
all udp 172.16.20.10:55083 -> 192.168.0.240:30003 SINGLE:NO_TRAFFIC
all udp 192.168.0.240:30005 <- 172.16.20.10:55085 NO_TRAFFIC:SINGLE
all udp 172.16.20.10:55085 -> 192.168.0.240:30005 SINGLE:NO_TRAFFIC
all udp 172.16.20.10:55084 <- 192.168.0.240:30004 NO_TRAFFIC:SINGLE
all udp 192.168.0.240:30004 -> 172.16.20.10:55084 SINGLE:NO_TRAFFICqueue qVoIP_ext on ovpns9 bandwidth 400Kb qlimit 100 hfsc( rio realtime(1.29Kb 3000 1.10Mb) )
[ pkts: 78687 bytes: 77168173 dropped pkts: 0 bytes: 0 ]
[ qlength: 0/100 ]
[ measured: 32.6 packets/s, 252.27Kb/s ]
queue qDefault on ovpns9 bandwidth 200Kb qlimit 200 hfsc( default )
[ pkts: 374119 bytes: 246208798 dropped pkts: 0 bytes: 0 ]
[ qlength: 0/200 ]
[ measured: 149.6 packets/s, 784.36Kb/s ]Match rule
pfctl -sr | grep match
match out on ovpns9 inet from 192.168.0.240 to 172.16.20.0/24 label "USER_RULE: Queue VideoConferencia" queue qVoIP_ext
-
match in on ovpns9 inet from 172.16.20.0/24 to 192.168.0.240 label "USER_RULE: Queue VideoConferencia" queue qVoIP_ext
The rule above seems to work, since the queue is applied to the state, so the traffic coming back would fall into the right queue.