srr-queue bandiwdth share and shape questions

rakemrakem Member Posts: 800
Just doing some testing and i have sort of forgotten a few points about the srr-queue commands...

I enabled auto qos voip on an interface while doing some testing and the following config was generated;

interface GigabitEthernet0/1
switchport access vlan 13
switchport mode access
switchport voice vlan 25
srr-queue bandwidth share 10 10 60 20
srr-queue bandwidth shape 10 0 0 0
queue-set 2
mls qos trust device cisco-phone
mls qos trust cos
auto qos voip cisco-phone
spanning-tree portfast

So my understanding of the srr-queue bandwidth share 10 10 60 20 command is that; there are four queues per inteface, and the weight values are the frequency in which packets are removed from their queue and sent. Is that an accurate description?

So if the above is correct, a heigher weight would mean packets are dequeued at a higher rate, meaning that queue has higher priority, correct?

Now another question - there are four queues configured, how do you know which queue VoIP traffic will use? And what traffic gets sent over the other three queues?

If the srr-queue bandwidth shape 10 0 0 0 command is applied, it would seem that the VoIP traffic would use queue 1, since you would probably want to shape VoIP traffic to keep it smooth, and shaping is applied on queue 1 in the config I posted above. And i believe that if shapping and sharing is configured shaping is used, not sharing.

So am I on the right track with my assumptions above?

thanks
CCIE# 38186
showroute.net

Comments

  • networker050184networker050184 Mod Posts: 11,962 Mod
    What model is the switch? A lot depends on the model with L2 QoS. I'd check out the QoS config guide for your specific model. I'll try to give a little help though.

    What traffic would go in which queue would depend on your cos map. By default if this is a 3560 it will be cos 5 in queue 1 - cos 0 and 1 in queue 2 - cos 2 and 3 in queue 3 - cos 4, 6 and 7 in queue 4.

    You are correct in your statement about the bandwidth share as far as I know. When you use the shape command you are allocating 10% to queue 0 and by setting the other queues to 0 they will be put in shared mode and share the remaining bandwidth according to your share configuration.

    At least this is my understanding. I do need to brush up on my LAN QoS though so some additional research wouldn't hurt. Hope this helps some though.
    An expert is a man who has made all the mistakes which can be made.
  • CyanicCyanic Member Posts: 289
    You should be able to remove the 'switchport mode access' command from this. The 'switchport voice' command takes over the mode for the port. It does not hurt the configuration; it just is not necessary.
  • GT-RobGT-Rob Member Posts: 1,090
    We use a similar config, but with priority-out as well (which gives the queue 1 full priority until it is empty, so be careful!)


    Voice will be in queue 1 be default correct (if the phone is tagging correctly, usually EF), low drop. There is a page on Cisco somewhere that explains the remaining queues and the CoS/DSCP values in each. It is also configurable (global config), and you can set any markings in any queue.


    Check out some of the mls qos command references on cisco, and it will have lots of examples.
  • rakemrakem Member Posts: 800
    GT-Rob wrote: »
    We use a similar config, but with priority-out as well (which gives the queue 1 full priority until it is empty, so be careful!)

    So the priority-queue out command will only remove packets from queue 1 until it is empty, then it will service the other queues?? is the correct?
    CCIE# 38186
    showroute.net
  • GT-RobGT-Rob Member Posts: 1,090
    correct, meaning it will get 100% of the link until it is empty. Just have to be careful what you put in queue 1, although if its only voice it shouldn't be an issue.
  • rakemrakem Member Posts: 800
    GT-Rob wrote: »
    correct, meaning it will get 100% of the link until it is empty. Just have to be careful what you put in queue 1, although if its only voice it shouldn't be an issue.

    Righto... queue 1 would only be for VoIP in this case, but this could cause data traffic to be delayed when voice calls are in progress i guess.
    CCIE# 38186
    showroute.net
Sign In or Register to comment.