Ha, Yea I did that once before! ;)
Had a match with a 'set-tos lowdelay' for a four-tuple etc, and then
later defined a rule with (normal,high), and of course the entire
connection went into 'high', and not just the control side-band..
Think it was scp that killed me if I remember..
Thanks, Andy.
On Tue 16 Jul 2013 16:43:44 BST, Stuart Henderson wrote:
On 2013-07-16, Peter N. M. Hansteen <pe...@bsdly.net> wrote:
Andy <a...@brandwatch.com> writes:
I have an issue where one of my 'real-time' queues is much busier than
it should be. I suspect that someone is running something on the
network and setting the diffserv bits (or something else funky..) and
so the firewall is placing the traffic into the higher priority queue
which is screwing with our VoIP traffic :(
Does anyone know of how I can view the pflow or even just the states
for /all/ traffic in just one queue?
If you're only interested in the traffic that hits one queue, my
suggestion would be that you temporarily alter your rule set so only
the rule that assigns traffic to that queue exports pflow data. Then
set up collection (I like nfsen/nfdump, but there are others) and mine
the data.
Don't forget it may be due to tos lowdelay traffic hitting the
secondary "fast" queue in e.g. "queue (normal fast)"...
