Cisco Support Community
Community Member

network control (111) & Inter network control (110) & Critical (101) code points/traffic




I have a question on MDRR scheduling algorithm. I have three class provider edge model with guaranteed bandwidth: Real time (45% guaranteed bandwidth), Critical Data (30% guaranteed bandwidth), and Best-Effort (25% guaranteed bandwidth). In this model I am worried about the network control (111), Inter network control (110) & Critical (101) code points. These code points at highest levels are to be reserved for critical network control and routing protocols that must pass from device to device to ensure proper inter network functioning. Same degree of preference for Real time traffic such as voice or video streaming.


  1. In which class I should put these 111 (7), 110 (6) & 101 (5) code points.
  2. As I am using MDRR as scheduling algorithm each class (Queue) will inturn wait for transmission of data whether it’s a voice in Real time class, video streaming in Critical Data class or FTP data in Best-Effort class. Say I put 111 & 110 code points in Real time class (Queue). When say Critical Data traffic is being dequeued. The algorithm then has to services the next queue that is Best-Effort. Say, before the very next pass network control (111) & Inter-network control traffic is arrived. So does it mean that this traffic has to wait before Best-Effort traffic is being dequeued? Right/Wrong.
  3. Instead of putting 111 (7), 110 (6) & 101 (5) code points in Real time class.  I put it in strict priority queue. Say network control (111) & Internetwork control traffic & voice traffic starts coming so does it mean that MDRR will keep on dequeuing this traffic type and other queues have to wait for them to over. It means delay-sensitive data, such as voice has to be dequeued first and has to be sent before packets in other queues are dequeued. Right/Wrong. If Right, then whats the solution for other queues?
  4. Is it mandatory to put 101 (5) code point in the priority class.


It will be a great relaxed to me stressed mind, as I wish to learn QoS in depth.




Everyone's tags (1)
Super Bronze

DisclaimerThe Author of this


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 whatsoever (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.


#1 I would suggest 110 and 101 go to your critical class.  111 might also go there or perhaps to real-time.

#2 Yes, if your only using a variant of RR, classes will wait on each other.  (Which is why RT traffic is normally recommended to go to a PQ or LLQ class.)

One thing, often misunderstood, is setting bandwidth ratios to "bandwidth" guarantees rather than using the "bandwidth" setting for proportional dequeuing prioritization.

For example, you could set your RT class to use PQ, set your critical class to use RR at 99% and your default class to use 1% as long as you "know" (or insure) your RT and critical class don't starve the default class.

#3 Any traffic in PQ has absolute priority over your RR classes.  The solution; you can share your PQ with non-RT traffic such as 111.  This insures such traffic is also dequeued first, but does risk your RT traffic not meeting its service needs.

#4 No, it's not mandatory, and if fact, if not RT, you probably don't want it in PQ.  PQ, besides trying to insure minimal latency, also is trying to insure no jitter.  Other "critical" network traffic, service requirements, usually doesn't have jitter requirements, and except perhaps for network errors (111) doesn't require extraordinary low latency either.

CreatePlease to create content