qos migration from 3750 v12.2 to 3650 x3.6.4

[Ray Lau]

i am trying to do a migration for a customer.
the following commands has changed on the interface level, can anyhow help me with the conversion?

srr-queue bandwidth share 1 30 1 70
priority-queue out
mls qos vlan-based

seems like it has changed the commands using policy-map
these are the current class and policy map, how can i integrated the above to the existing policy map?

class-map ABC
match access-group name ABC
class-map DEF
match access-group name DEF
class-map GHI
match access-group name GHI
!
policy-map XXX
class ABC
set dscp cs5
class DEF
set dscp cs4
class GHI
set dscp cs4
class class-default
set dscp cs2

any help is greatly appreciated. thanks!

[Furose M]

example for srr-queue command:

http://www.cisco.com/c/en/us/support/docs/switches/catalyst-3850-series-switches/118629-technote-qos-00.html#anc47

[Ray Lau]

thanks for the reply. I saw this conversion the too but it's not very detail and I am not very familiar with qos. can you or anyone help me with the direct conversion for my case? 

[Furose M]

i am giving the conversion "as it is" as per your config. please use it cautiously.

3750:

srr-queue bandwidth share 1 30 1 70
priority-queue out

3850:

class-map ABC
match access-group name ABC
class-map DEF
match access-group name DEF
class-map GHI
match access-group name GHI
!
policy-map XXX
priority level 1 percent 1
class DEF
bandwidth percent 30
class GHI
bandwidth percent 1
class class-default
bandwidth percent 70

[Ray Lau]

thanks for the conversion. 

base on my understanding, the existing config means that the first traffic on the queue that matches the policy map will be given priority (priority queue out) and the next on queue will be given 30/100 bandwidth. 

I don't think the converted commands works the same way right? the converted commands are base on specify traffic base on class-map. 

please correct me if I am wrong. 

how about mls qos vlan based? any conversion for this? 

thanks 

[Furose M]

base on my understanding, the existing config means that the first traffic on the queue that matches the policy map will be given priority (priority queue out) and the next on queue will be given 30/100 bandwidth. 

<Furose>: yes. The first queue will be used as priority-queue.

I don't think the converted commands works the same way right? the converted commands are base on specify traffic base on class-map. 

<Furose>: it depends on what you are matching in the queues 1-4 in your actual QOS config.

please correct me if I am wrong. 

how about mls qos vlan based? any conversion for this? 

<Furose>:  that indicates there is a service-policy applied in Vlan's SVI and instructs the switch to use that service-policy for classification and marking.

[Ray Lau]

thanks for the reply again. 

I am a bit confused here, I read the existing config as, all traffics on queue 2 will given 30/100 bandwidth. but base on the new converted config, only traffic class def will be given 30/100 bandwidth. 

please correct if I am wrong. and I don't see class abc in the converted config. 

[Furose M · Accepted solution]

i missed the "class ABC" line. typo.

class-map ABC
match access-group name ABC
class-map DEF
match access-group name DEF
class-map GHI
match access-group name GHI
!
policy-map XXX

class ABC
priority level 1 percent 1
class DEF
bandwidth percent 30
class GHI
bandwidth percent 1
class class-default
bandwidth percent 68

here, queue-2 gets 30% and class-default gets 68% which is remaining of whatever is left.

you have to keep in mind that its not a 1-1 conversion and it cant be. you simply have to redesign your QOS parameters with MQC.

[Ray Lau]

please bare with me.

am i right to conclude the following:

1) in the old config "srr-queue bandwidth share 1 30 1 70", when priority-queue out is configured, queue 1 will turn into priority ignoring the 1st weight'.

2) in the converted config, isn't class DEF has 30% but not queue-2 has 30%?

3) if there are 6 queues ahead and class ABC comes in, it will be given priority and straight away to queue 1 but with only 1% bandwidth?

4) there are 2 queues, class GHI on first and ABC on the second. ABC will be given the priority and exit with 1% bandwidth and then GHI will exit next with 1% bandwidth.

I hope I get it right. which means they are really 2 different thing.

[Furose M]

1) in the old config "srr-queue bandwidth share 1 30 1 70", when priority-queue out is configured, queue 1 will turn into priority ignoring the 1st weight'.

<Furose>: yes. when using "share", it means you are guaranteeing the % of bandwidth to that queue but that queue is not limited to that value. it can go beyond when other queues are not using them. when "priority-queue out" is applied on that interface, queue-1 is the priority queue and the "Share" value configured for it will be ignored.

The bandwidth value configured for queue-1 is not used in ratio calculation. so, the ratio for other queues are, 30/101, 1/101 and 70/101 for queue 2, 3 and 4 respectively.

1 good thing in 3850 is, you can limit the priority queue to a particular percentage. in 3750, there was no limit for priority queue and it can take up the whole bandwidth of a link.

2) in the converted config, isn't class DEF has 30% but not queue-2 has 30%?

<Furose>: each class is a queue. so, class DEF is essentially queue-2. similarly, class ABC is queue-1.

3) if there are 6 queues ahead and class ABC comes in, it will be given priority and straight away to queue 1 but with only 1% bandwidth?

<Furose> queues are defined as per the number of classes and you cant go beyond more than 8 (including the default "class-default" all catch queue).

4) there are 2 queues, class GHI on first and ABC on the second. ABC will be given the priority and exit with 1% bandwidth and then GHI will exit next with 1% bandwidth.

<Furose>: ABC will strictly exit at 1% however, GHI can go beyond if needed. but yes, ABC will be serviced first ahead of GHI as long as packets are in class (queue) ABC and it doesnt exceed 1%.

[Ray Lau]

thanks for your reply once again.

2) in the converted config, isn't class DEF has 30% but not queue-2 has 30%?

<Furose>: each class is a queue. so, class DEF is essentially queue-2. similarly, class ABC is queue-1.

<Ray>: so you mean that only DEF can be in queue 2? then for example GHI that comes in and there are 6 queues ahead will fall under queue 3? doesn't really make sense to me. i don't think the old config works this well right?

3) if there are 6 queues ahead and class ABC comes in, it will be given priority and straight away to queue 1 but with only 1% bandwidth?

<Furose> queues are defined as per the number of classes and you cant go beyond more than 8 (including the default "class-default" all catch queue).

<Ray> as per my question no 2. so queue 1 equals to the first class on the policy map? so on and so for? 

4) there are 2 queues, class GHI on first and ABC on the second. ABC will be given the priority and exit with 1% bandwidth and then GHI will exit next with 1% bandwidth.

<Furose>: ABC will strictly exit at 1% however, GHI can go beyond if needed. but yes, ABC will be serviced first ahead of GHI as long as packets are in class (queue) ABC and it doesnt exceed 1%.

<Ray>: however base on old config it shouldn't work this way right? by issue priority-queue out means that it will be given priority with no bandwidth restriction. this new converted commands since that it will be given priority but only at 1% which is not correct.

[Furose M]

<Ray>: so you mean that only DEF can be in queue 2? then for example GHI that comes in and there are 6 queues ahead will fall under queue 3? doesn't really make sense to me. i don't think the old config works this well right?

<furose>: when you say 6 other queues, are you creating 6 other class-maps? there are actually 8 built-in queues in 3850 for every port but they get activated when you create a class-map for them. if you assign a service-policy to a port which only has 2 clas-maps (including class-default), you are only using 2 queues and the remaining queues are unused.

<Ray> as per my question no 2. so queue 1 equals to the first class on the policy map? so on and so for? 

<Furose> yes, but i can even put the priority command in queue-2 instead of queue-1. its totally fine. MQC gonna do what we are gonna tell it to do and we have full control over it.

<Ray>: however base on old config it shouldn't work this way right? by issue priority-queue out means that it will be given priority with no bandwidth restriction. this new converted commands since that it will be given priority but only at 1% which is not correct.

<furose> you really want to rate-limit priority queue. its a bad practice not to limit the priority queue. if you consider a compressed voip call, its only 8 kbps per call. if you have 50 phones in a switch and if all the 50 phones are being in used, you only need a max of 4mbps for priority queue. 50 is a large value but giving it just as an example. so, you dont want priority queue to be, say 5% of a gig interface. its a lot. even 1 % should be fine in the context of 50 simultaneous calls. what if someone creates a loop in voip vlan, resulting in storm in voice vlan, which chokes down the entire interfaces? you dont want priority queue to choke down ur network and you should precisely know whats the max you want for priority queue.

[Ray Lau]

thanks for your prompt reply once again. I am beginning to understand. 

Can I conclude the following.. 

1) class abc (top in the policy map) will always be in queue 1 even though def comes in first? so def comes in first, it will be put in queue 2 even thought queue 1 is empty? 

2) in the event if I put priorioty on class def, and there are both class abc and def in the queue, def will be processed first. 

[Furose M]

1) class abc (top in the policy map) will always be in queue 1 even though def comes in first? so def comes in first, it will be put in queue 2 even thought queue 1 is empty? 

<Furose> in MQC based, the queue number, 1 or 2, doesnt define the queue order. the number is just for identification. in 3750, its a different scenario as queue 1 is the priority queue.

2) in the event if I put priorioty on class def, and there are both class abc and def in the queue, def will be processed first. 

<Furose> yes, but you have to put 1 as "priority level 1" and the 2nd as "level 2". level 1 will be serviced first upto the configured % of interface bandwidth, followed by level-2 queue and then the rest of the queues.

[Ray Lau]

thanks for the reply again. 

1) class abc (top in the policy map) will always be in queue 1 even though def comes in first? so def comes in first, it will be put in queue 2 even thought queue 1 is empty? 

<Furose> in MQC based, the queue number, 1 or 2, doesnt define the queue order. the number is just for identification. in 3750, its a different scenario as queue 1 is the priority queue

<Ray> that's what I am trying to say. but seems like either or both of my understanding is wrong. 

1) Base on the existing mls qos config, the 2nd in queue is given 30% right? or am I wrong? its actually matching the class map order where the 2nd weight matches the 2nd class map in the policy map? 

2) The converted config give 30% only on class DEF right but no the 2nd in queue right?