Help with Policy-Map Priority command

[ADynes]

Back in the day we had Cisco 1921 routers with some lower bandwidth connections between offices, usually a 10/10 or 20/20.  We have recently installed a couple of Cisco ISR1111 routers and upgraded the EPL lines between branches up to 50/50.  The configs however were mostly brought over from the old routers and I don't think they are correct for our needs.

We are using a Mitel phone system between the branches and there is a ACL setup with the ports Mitel recommends.  Then there is a QoS policy called VoIP with that ACL in it.  My question is about the Priority command below:

policy-map VoIP
  description "Dedicate 3Mb of outbound traffic to voice rules"
  class VoiceTraffic
  priority 3000

Is the priority command actually dedicating 3Mb to this?  Looking at documentation it doesn't look right.  It is "working" and we have 0 issues with voice traffic but I want to make sure this is correct, especially now that we have less phones in some of the branches and larger bandwidth connections.  Also is this the best way?  Looking at the difference between bandwidth and priority (https://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-packet-marking/10100-priorityvsbw.html) I think we do want priority, just dont know if the 3000 is correct.

[balaji.bandi]

I am sure you may be running IOS XE, so you need to refer the IOS XE  QoS config as below :

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/qos_mqc/configuration/xe-16-12/qos-mqc-xe-16-12-book/qos-mrkg.html

You need to provide full QoS config for us to review and suggest.

Since you may have enough bandwidth all working as expected. you only see the effects when your WAN bandwidth fully utilised then make sure prioroty traffic get their own space to get QoS of service like Voice.

other good examples here :

https://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/qos_solutions/QoSVoIP/QoSVoIP.html

[ADynes]

We have tested this and saturated the link and phone traffic works without issues.  Both using real world large file transfers and artificial means like iPref over the link.  As mentioned we are using a ACL with the recommended Mitel ports and assigning that ACL to the QoS policy.  The policy is then applied to the outgoing side of the connection in both directions.   I'm just asking is the priority command 3000 KBps or kbps or what?  We want to make sure we can use up to 3Mb of the connection for voice as we should never need more then that but I'm not sure that's what it's doing.

[Joseph W. Doherty]

To your question, the priority command insures any traffic in the priority queue is dequeued first for transmission.

The 3000 setting sets a limit of how much bandwidth is allowed to used by this priority queue class.  Reason for this, as PQ always dequeues first, it can totally "starve" any other traffic from getting ANY bandwidth.  For just the PQ traffic that exceeds the cap, that excess traffic is dropped.

BTW, VoIP traffic is the "textbook" example for when to use PQ.

As to whether 3000 is the correct value, well that depends on how much concurrent VoIP you might have (remember, exceeding this values drops the excess traffic [bad for VoIP!]) but Cisco also recommends (I recall) not allocating more than one third of all your possible bandwidth to PQ (classes, combined).  (Personally, I've found, up to 40%, sometimes even 50%, is okay too.)

If all the above appears to match what you been doing, implies your QoS setup is "good", well, maybe it is, and may it's not.  It's "good" you've had no VoIP issues, but that might be as much as by luck rather than by design.

"Red flags", in your OP, include "10/10 or 20/20", "EPL" and "50/50"

There are other configuration "options", and topologies that can impact especially sensitive traffic, like VoIP, often not touched upon unless you delve deep into QoS (the latter often arising, when QoS doesn't appear to be working).

PS:

I just read your follow on posting, if you haven't had VoIP issues when you saturate your links, that's very good, can mean you do have an effective QoS design.

[ADynes]

---

"Red flags", in your OP, include "10/10 or 20/20", "EPL" and "50/50"

---

Not sure why these are "red flags". The EPL, Ethernet private line, is a low latency connection between our offices.  Our smallest one is 50Mbps.  Latency ranges from 8ms to 20ms depending on the branch and the physical distance from us. It's logically a long patch cable.

---

As to whether 3000 is the correct value, well that depends on how much concurrent VoIP you might have (remember, exceeding this values drops the excess traffic [bad for VoIP!]) but Cisco also recommends (I recall) not allocating more than one third of all your possible bandwidth to PQ (classes, combined).  (Personally, I've found, up to 40%, sometimes even 50%, is okay too.)

---

As far as bandwidth goes we would never have more then 10 voice calls between branches, most branches don't even have that many phones.  So even on the high side assuming 156 kbs per connection that's 1560 kbs worst case.  Which is why I asked about the value of 3000.  Is that in kbps?  If so we can reduce that down to 2000 and still be more then fine. I can't see giving it a higher range, like a actual 1/3 of the 50Mbp, but I suppose that would also be fine since it would never use it.

[Joseph W. Doherty · Accepted solution]

"Not sure why these are "red flags"."

If your EPL is truly just configured to be ONLY point-to-point, then that's not a red flag.  (What you have to watch for is the Ethernet variants that support multipoint.  [Per you example, think patch cable going to a Ethernet switch, i.e. more than two IPs on same segment.])

As to 10/10, 20/20, 50/50, often these are some from of logical cap imposed on a link whose port speed it some "native" Ethernet speed, e.g. 100 Mbps or gig.  Problem is, QoS, responds to "congestion".  So, if your port is configured to run at 100 Mbps, with a 50 Mbps logical (and actually enforced) bandwidth cap, QoS will not "trigger" until you exceed 100 Mbps, but you really want it to "trigger" when you exceed 50 Mbps.  (BTW, QoS can be configured to deal with this situation, but as you didn't post your full QoS configuration, cannot say whether that's the case, or not, for you.)

BTW, again, your test result may indicate you have a fully effective QoS design, but it's MAY because don't know the details of your large file copies, iPerf tests, and whether your saturation really, and fully, saturated a link.  (A good test for saturation, is use a bandwidth tool that generates UDP, not TCP, packets at about 10% above port speed, sent to a far side IP.)

"Is that in kbps?"

Should be.

"If so we can reduce that down to 2000 and still be more then fine. I can't see giving it a higher range, like a actual 1/3 of the 50Mbp, but I suppose that would also be fine since it would never use it."

Unused priority bandwidth is available to other traffic, so going higher than needed, isn't, generally, an issue.

The converse, though, going lower than needed, is an issue!

I would suggest leaving value at 3 Mbps, at least you don't need to update if someone adds a phone or two, and the 3 Mbps, is 30%, or less, of the bandwidth rates you've noted.

[ADynes]

Thanks, thats helpful.  And as for the EPL in the past when we were running the

10/10 and 20/20

I used the bandwidth command on the Ethernet ports within the router to let them know that.  Now that our slowest is a 50/50 (and fastest is a 500/500) I didn't bother.

I'll also leave the 3000 but change the description from "3 Mb" to "3000 kbps" so I don't confuse myself next time we upgrade.

[Joseph W. Doherty]

BTW, the interface bandwidth command, generally, doesn't actually control interface bandwidth.

[ADynes]

---

@Joseph W. Doherty wrote:

BTW, the interface bandwidth command, generally, doesn't actually control interface bandwidth.

---

I swear on the older 1921s it was recommended to include that on the interface when the connection wasn't a "standard" 10/100/1000 so that's what we did.  We were also using priority as a percentage back then so maybe that's why also

[Joseph W. Doherty]

Yup, QoS policies (and other features) will compute using the interface bandwidth value.  What interface bandwidth, alone, not do is regulate/restrict interface bandwidth consumption.

[ADynes]

Yeah that makes sense.  We were telling it a percentage so it needed to figure out how to calculate bandwidth.  Now we just tell it the bandwidth it can use so no need to specify as long as we have it available.

[Joseph W. Doherty]

"Now we just tell it the bandwidth it can use so no need to specify as long as we have it available."

Again, it's not quite that simple in a situation like yours.  Keep in mind priority only happens when QoS is "triggered" by congestion.

Suppose, for example, you have a 50 Mbps CIR on a 100 Mbps port.  If you send 70 Mbps, QoS "sees" no congestion, but what happens when the 70 Mbps is constrained by your service provider?  Often they will just drop excess traffic, but it's possible they might shape your traffic.  Either, though, may totally ignore you want VoIP to get preferential treatment.

What's the usual QoS solution?

You define a two level policy.  Top level shapes for CIR.  Next level decides how to prioritize your traffic.

E.g.:

policy-map ShapeFor50Mbps
  class class-default
    shape average 42500000 !bps, CIR less about 15% for L2 overhead
    service policy VoIP

policy-map VoIP
  description "Dedicate 3Mb of outbound traffic to voice rules"
  class VoiceTraffic
    priority 3000
  class class-default
    fair-queue

interface g# !port with contracted 50 Mbps
  service-policy out ShapeFor50Mbps