Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
If there is congestion, wouldn't all the non-priority queues be impacted, including the call signals?
Yes, they would likely all be impacted, but if signally is in its own queue, you can priorize it such that you manage the impact.
The call signals are pretty lightweight, are they not?
That's my experience, they are often more "robust" as they often use TCP too.
Are there any drawbacks if I were to put them in the LLQ/priority queue?
Well, you expose your other LLQ traffic to additional jitter and latency, as the signally packets interleave with what's already in the LLQ. That said, I've done it, and usually without adverse impact.
I've also placed signally with my other BE traffic when using FQ. I've also placed signally into a HiPrioity queue that's not LLQ, which I believe is also ideal when that queue also supports FQ.
PS:
My general router policy:
policy-map GeneralExample
class LLQ
priority percent 33
class Foreground
bandwidth remaining percent 89
fair-queue
class Background
bandwidth remaining percent 1
fair-queue
class class-default
bandwidth remaining percent 9
fair-queue
(In the above, I would drop signalling into the Foreground class.)
