1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

QoS: LLQ with CBWFQ

Discussion in 'Routing & Switching' started by BosonMichael, Dec 19, 2008.

  1. BosonMichael
    Highly Decorated Member Award

    BosonMichael Yottabyte Poster

    19,136
    462
    374
    Okay... consider a QoS setup with a priority queue and several bandwidth remaining queues. The priority queue is assigned 40% of the bandwidth. When priority traffic is being sent, the bandwidth remaining queues obviously get what's left - can find tons of links that back that up. But when no priority traffic is being sent, can the bandwidth remaining queues consume that interface bandwidth until priority traffic is received (and is prioritized over those queues)? I think so... just need verification... and a link to a statement or an example would be great so I can show our editing staff. :)
     
    Certifications: CISSP, MCSE+I, MCSE: Security, MCSE: Messaging, MCDST, MCDBA, MCTS, OCP, CCNP, CCDP, CCNA Security, CCNA Voice, CNE, SCSA, Security+, Linux+, Server+, Network+, A+
    WIP: Just about everything!
  2. BosonMichael
    Highly Decorated Member Award

    BosonMichael Yottabyte Poster

    19,136
    462
    374
    I guess when I post a question, it's a doozy... :D

    Anyone? Bueller?
     
    Certifications: CISSP, MCSE+I, MCSE: Security, MCSE: Messaging, MCDST, MCDBA, MCTS, OCP, CCNP, CCDP, CCNA Security, CCNA Voice, CNE, SCSA, Security+, Linux+, Server+, Network+, A+
    WIP: Just about everything!
  3. Spice_Weasel

    Spice_Weasel Kilobyte Poster

    254
    45
    45
    I usually only login to CF from work - hence no reply on the weekend ;)

    You are correct, other queues can use the bandwidth reserved for the priority que, when there is no priority traffic. Consider the following example:

    policy-map QoS
    class voice
    priority percent 30
    class signaling
    bandwidth percent 5
    class important
    bandwidth percent 20
    class class-default
    fair-queue
    random-detect

    For the above configuration, if the interface is not congested, traffic is sent fifo - no priority is given to voice, because qos only effects traffic flow during congestion. If there is congestion, voice can use up to 30 percent of the bandwidth, and no more - excess voice traffic is dropped, because the priority que is policed. To summarize, if the interface is not congested, voice traffic can exceed 30 percent - but if the interface is congested, voice traffic exceeding the allocated bandwidth is dropped.

    For the signaling and important classes, above, it is a bit different. Again, if the interface is not congested, traffic can exceed bandwidth percentages for the class. If the interface is congested, then the bandwidth classes are guaranteed bandwidth - 5% for signaling, 20% for important. They may exceed the guaranteed allocation (unlike the priority que, which is policed) if bandwidth is available. Unused bandwidth would be divided proportionally between signaling, important and class-default.

    So if the interface is congested, the voice has priority (dequeued first) and is policed to 30%, signaling is quaranteed 5%, important is quaranteed 20%. Remaining bandwidth is proportionally divided between signaling, important and class-default.

    If the interface is not congested, then traffic is fifo, and any traffic flow can use any amount of bandwidth.


    Spice_Weasel
     
    Certifications: CCNA, CCNP, CCIP, JNCIA-ER, JNCIS-ER,MCP
    WIP: CCIE
  4. Spice_Weasel

    Spice_Weasel Kilobyte Poster

    254
    45
    45
    Certifications: CCNA, CCNP, CCIP, JNCIA-ER, JNCIS-ER,MCP
    WIP: CCIE
  5. BosonMichael
    Highly Decorated Member Award

    BosonMichael Yottabyte Poster

    19,136
    462
    374
    Yeah, I looked at the command ref, as always... and it lays out clearly what happens when congestion occurs with regard to priority traffic... but it was not as clear as to what happens when there's a buttload of CBWFQ traffic but no priority traffic. And, the behavior you explained is as I had suspected.

    That link hits the spot, Spicey... I will forward the link to the tech editor who is reviewing my work! :)

    Rep given - thanks a lot for the confirmation! :thumbleft
     
    Certifications: CISSP, MCSE+I, MCSE: Security, MCSE: Messaging, MCDST, MCDBA, MCTS, OCP, CCNP, CCDP, CCNA Security, CCNA Voice, CNE, SCSA, Security+, Linux+, Server+, Network+, A+
    WIP: Just about everything!

Share This Page

Loading...