[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:30007

    the 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_TRAFFIC

    queue  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.


Log in to reply