Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

3560 QoS SRR bandwidth shape/share

i have the following setup

Core Stack(3750)--- Distribution Stack(3750)----Access switches (3560)--- end devices

i want to implement the srr-queue bandwidth shape/share on the interface

my question is

1- on which interfaces should i implement the command and on which boxes ?

Everyone's tags (3)
3 ACCEPTED SOLUTIONS

Accepted Solutions
VIP Purple

Re: 3560 QoS SRR bandwidth shape/share

Hi Asus,

Here is my recommendation & given you some reference post as well to understand logic behind it.

Switch-Switch : Trust DSCP

Switch-AP : Trust DSCP (if APs are local mode & switch port is configured as Access ports)

Switch-AP : Trust CoS (if your APs are in FlexConnect Local Switching mode & switch port is configured as Trunk Port)

http://mrncciew.com/2013/07/23/qos-for-h-reap/

additionally consider the below as well.

Switch- VoIP : Trust CoS (with trust device cisco-phone)

http://mrncciew.com/2013/07/26/voip-phone-switchport-config/

Switch - WLC : Trust CoS

http://mrncciew.com/2013/02/24/best-practice-qos-config/

srr commands should configure on all interfaces with priority queue if you want to do voice traffic prioratization (DSCP EF traffic).

http://mrncciew.com/2012/11/26/375035602960-wired-qos/

Keep note that QoS commands are hareware specific & always refer the specific product configuration guide when configuring.

HTH

Rasika

**** Pls rate all useful responese ***

VIP Purple

Re: 3560 QoS SRR bandwidth shape/share

Hi Asus,

Yes, you can ask any number of questions & happy to help

1- why trust dscp between access and aggregation switches, i mean if they are L2 switches with only SVI for management why do i need to trust DSCP not COS ?

Typically you would classify your traffic at access layer (most probably DSCP based). Once classified you want to preserve those classification when it goes to rest of your network. That's the reason you would trust DSCP on your inter-switch links interfaces. You could trust CoS here, then receving switch will trust CoS & rewrite the inner DSCP of IP packet, then depend on this CoS-DSCP mapping configuration of your switches, original trusted DSCP (at the access layer) may alter when it goes to destination.

2- the core stack has ip routing enabled and the wan interface is ospf enabled. on the core stack WAN interface, what configs should i add? srr commands , priority queue out , auto qos voip trust, mls qos trust DSCP... am i missing anything else ?

If it is a L3 routed port & connected to a your own device (trusted) then you can simply configure it to trust DSCP & enable queuing. (srr queue values could be different to given value, here is given what I have configured in my access layer & recommended in certain reference guide SRND 4.0)

srr-queue bandwidth share 1 30 35 5

priority-queue out

mls qos trust dscp

3- on the interface to the ip phone, i want this port to be trust only the traffic from the ip phone and treat the traffic from the pc connected to the phone as untrusted. will configuring "mls qos trust voip" without the " mls qos trust cos/dscp" do it ?

Below two lines achieve what you require. It will trust CoS only if it coming from a Cisco Phone, otherwise it will act as a untrusted port & re-write to CoS value of 0

mls qos trust device cisco-phone

mls qos trust cos

On those ports as well you can configure queuing & prioratise voice traffic adding below commands line

srr-queue bandwidth share 1 30 35 5

priority-queue out

Pls let us know if you have any further queries on this.

HTH

Rasika

**** Pls rate all useful responses ******

VIP Purple

Re: 3560 QoS SRR bandwidth shape/share

Hi Asus,

i also need to configure auto qos voip trust on all the interfaces, including the uplin to the wan , right ?

No, this is only required for the switchports you are connecting VoIP handsets. It is not required on the WAN ports.

If you look at previously given reference post "Best Practice QoS config" once you add "auto qos voip  cisco-phone" config line onto a switchport where VoIP phone connected, switch will automatically generating rest of the QoS config for you (classification, queuing, etc for you). You do not want to add any manual QoS config line for those ports.

For the WAN port simply you can manually configure like this. If srr-que bandwidth values are different in my example (compare to auto qos voip cisco-phone added lines to VoIP connected ports) you can stick with the value derived from auto-qos for consistency.


srr-queue bandwidth share 1 30 35 5

priority-queue out

mls qos trust dscp

Keep in mind, if you are using Auto-QoS, then your manual QoS configuration requirement is minimal

HTH

Rasika

**** Pls rate all useful responses ****

19 REPLIES
New Member

3560 QoS SRR bandwidth shape/share

another question for the same setup

on trusted ports between switches and trusted ports between the switch and the AP. what should i trust ? dscp or cos ?

VIP Purple

Re: 3560 QoS SRR bandwidth shape/share

Hi Asus,

Here is my recommendation & given you some reference post as well to understand logic behind it.

Switch-Switch : Trust DSCP

Switch-AP : Trust DSCP (if APs are local mode & switch port is configured as Access ports)

Switch-AP : Trust CoS (if your APs are in FlexConnect Local Switching mode & switch port is configured as Trunk Port)

http://mrncciew.com/2013/07/23/qos-for-h-reap/

additionally consider the below as well.

Switch- VoIP : Trust CoS (with trust device cisco-phone)

http://mrncciew.com/2013/07/26/voip-phone-switchport-config/

Switch - WLC : Trust CoS

http://mrncciew.com/2013/02/24/best-practice-qos-config/

srr commands should configure on all interfaces with priority queue if you want to do voice traffic prioratization (DSCP EF traffic).

http://mrncciew.com/2012/11/26/375035602960-wired-qos/

Keep note that QoS commands are hareware specific & always refer the specific product configuration guide when configuring.

HTH

Rasika

**** Pls rate all useful responese ***

New Member

3560 QoS SRR bandwidth shape/share

First of all, thank you so much for the helpful post

i have few more questions if you don't mind

1- why trust dscp between access and aggregation switches, i mean if they are L2 switches with only SVI for management why do i need to trust DSCP not COS ?

2- the core stack has ip routing enabled and the wan interface is ospf enabled. on the core stack WAN interface, what configs should i add? srr commands , priority queue out , auto qos voip trust, mls qos trust DSCP... am i missing anything else ?

3- on the interface to the ip phone, i want this port to be trust only the traffic from the ip phone and treat the traffic from the pc connected to the phone as untrusted. will configuring "mls qos trust voip" without the " mls qos trust cos/dscp" do it ?

VIP Purple

Re: 3560 QoS SRR bandwidth shape/share

Hi Asus,

Yes, you can ask any number of questions & happy to help

1- why trust dscp between access and aggregation switches, i mean if they are L2 switches with only SVI for management why do i need to trust DSCP not COS ?

Typically you would classify your traffic at access layer (most probably DSCP based). Once classified you want to preserve those classification when it goes to rest of your network. That's the reason you would trust DSCP on your inter-switch links interfaces. You could trust CoS here, then receving switch will trust CoS & rewrite the inner DSCP of IP packet, then depend on this CoS-DSCP mapping configuration of your switches, original trusted DSCP (at the access layer) may alter when it goes to destination.

2- the core stack has ip routing enabled and the wan interface is ospf enabled. on the core stack WAN interface, what configs should i add? srr commands , priority queue out , auto qos voip trust, mls qos trust DSCP... am i missing anything else ?

If it is a L3 routed port & connected to a your own device (trusted) then you can simply configure it to trust DSCP & enable queuing. (srr queue values could be different to given value, here is given what I have configured in my access layer & recommended in certain reference guide SRND 4.0)

srr-queue bandwidth share 1 30 35 5

priority-queue out

mls qos trust dscp

3- on the interface to the ip phone, i want this port to be trust only the traffic from the ip phone and treat the traffic from the pc connected to the phone as untrusted. will configuring "mls qos trust voip" without the " mls qos trust cos/dscp" do it ?

Below two lines achieve what you require. It will trust CoS only if it coming from a Cisco Phone, otherwise it will act as a untrusted port & re-write to CoS value of 0

mls qos trust device cisco-phone

mls qos trust cos

On those ports as well you can configure queuing & prioratise voice traffic adding below commands line

srr-queue bandwidth share 1 30 35 5

priority-queue out

Pls let us know if you have any further queries on this.

HTH

Rasika

**** Pls rate all useful responses ******

Re: 3560 QoS SRR bandwidth shape/share

Raisik,

I got a quick question if you don't mind. I undersatnd that a L2 port can trust DSCP markings, but how does a L2 port understand DSCP values, if no DSCP information is within a L2 frame and or a 802.1q frame?

Is this done, by the CoS-to-DSCP mapping table?

Also, I would assume a Cisco VoIP phon would mark these are CoS 5?

VIP Purple

Re: 3560 QoS SRR bandwidth shape/share

Hi John,

I undersatnd that a L2 port can trust DSCP markings, but how does a L2 port understand DSCP values, if no DSCP information is within a L2 frame and or a 802.1q frame?

Yes, in L2 frame there is no DSCP information. If "trust DSCP" is in use, then switch will simply ignore the CoS value of a incoming L2 frame & pass it (IP packet) on if is going via Access port or L3 routed port. If it is going via trunk port, then it will derive the CoS value based on the DSCP (dscp-cos mapping) and add the CoS value onto L2 frame.

If you trust CoS in these scenario, then switch will trust that & re-write the original packet DSCP based on the cos-dscp mapping table of the switch.

I would assume a Cisco VoIP phon would mark these are CoS 5?

Yes, Cisco phone will mark voice traffic to CoS5 when it is coming from the Phone.

HTH

Rasika

**** Pls rate all useful responses ****

Re: 3560 QoS SRR bandwidth shape/share

Raisik,

So let's say, I have a frame coming in, that has an IP packet encapsualted within with DSCP 46 in the ToS byte of the IP Header. If I have 'mls qos trust dscp' on the trunk port, it will simply ignore the CoS value, and if it's going to a trunk, it will check the dscp-to-cos mapping table, and whatever cos value it maps to, we'll say CoS5, it will go across the trunk, and hit the other switch, with a marking of CoS 5 and the IP header that is still encapsulated from within will have DSCP EF.

Which I would assume you would add 'mls qos trust dscp' although, in theory, you coudl just have 'mls qos trust cos' and as long as the cos-to-dscp mapping table goes CoS5 > DSCP EF, you will be ok.

Sorry for all the questions

VIP Purple

Re: 3560 QoS SRR bandwidth shape/share

 I have a frame coming in, that has an IP packet encapsualted within with DSCP 46 in the ToS byte of the IP Header. If I have 'mls qos trust dscp' on the trunk port, it will simply ignore the CoS value, and if it's going to a trunk, it will check the dscp-to-cos mapping table, and whatever cos value it maps to, we'll say CoS5, it will go across the trunk, and hit the other switch, with a marking of CoS 5 and the IP header that is still encapsulated from within will have DSCP EF.

Yes, your understanding is correct here.

Which I would assume you would add 'mls qos trust dscp' although, in theory, you coudl just have 'mls qos trust cos' and as long as the cos-to-dscp mapping table goes CoS5 > DSCP EF, you will be ok

Yes,If CoS 5 <-> EF mapping is correct then you would get the same outcome. If you are having DSCP based classification rules for other traffic (for example video AF41, signalinng CS3, etc) then it is important ro have your cos-dscp mapping table correct across the network as you will re-write it at every trunk port interfaces. If you use "trust dscp" then it will not require to do those re-write every time it goes through a trunk.

Sorry for all the questions

No problem at all.. as long as it helps you

HTH

Rasika

**** Pls rate all useful responses

Hall of Fame Super Blue

Re: 3560 QoS SRR bandwidth shape/share

John / Rasika

Just wanted to add something to this.

When you say a CoS value is derived from the internal DSCP value and is written into the vlan tag on an egress trunk link i totally agree.

However if you trust DSCP and the egress interface is not a trunk link this does not necessarily mean that a CoS value isn't needed ie. it is not just trunk links where the switch needs to derive a CoS value.

The reason for this is that some switches and some linecards for modular switches only support CoS based egress queueing. So even if you trust DSCP you stiill need to derive a CoS value from the internal DCSP value so the packet can be placed into the correct egress queue. The difference is, if it is not a trunk link, the CoS value is not written into a vlan tag as there obviously isn't one present.

Jon

VIP Purple

Re: 3560 QoS SRR bandwidth shape/share

Hi Jon,

Thanks for that correction. Yes you are right with respect to modular switches line cards

Rasika

New Member

Re: 3560 QoS SRR bandwidth shape/share

i also need to configure auto qos voip trust on all the interfaces, including the uplin to the wan , right ?

VIP Purple

Re: 3560 QoS SRR bandwidth shape/share

Hi Asus,

i also need to configure auto qos voip trust on all the interfaces, including the uplin to the wan , right ?

No, this is only required for the switchports you are connecting VoIP handsets. It is not required on the WAN ports.

If you look at previously given reference post "Best Practice QoS config" once you add "auto qos voip  cisco-phone" config line onto a switchport where VoIP phone connected, switch will automatically generating rest of the QoS config for you (classification, queuing, etc for you). You do not want to add any manual QoS config line for those ports.

For the WAN port simply you can manually configure like this. If srr-que bandwidth values are different in my example (compare to auto qos voip cisco-phone added lines to VoIP connected ports) you can stick with the value derived from auto-qos for consistency.


srr-queue bandwidth share 1 30 35 5

priority-queue out

mls qos trust dscp

Keep in mind, if you are using Auto-QoS, then your manual QoS configuration requirement is minimal

HTH

Rasika

**** Pls rate all useful responses ****

New Member

3560 QoS SRR bandwidth shape/share

Ok so i dont need to configure auto qos voip trust on any interfaces other than the one connected to the i phone ? Because i was told i need to configure that on all interfaces to preserve the voip trust

One more question, i was told that if the port is switchport mode then you trust cos if not you trust dscp. How true is that statement?

New Member

3560 QoS SRR bandwidth shape/share

Also, what if i want toconfigure a port between a router and a switch to be trust for ip phones only but remark other services. How is that done ?

VIP Purple

Re: 3560 QoS SRR bandwidth shape/share

Hi Asus,

Also, what if i want toconfigure a port between a router and a switch to be trust for ip phones only but remark other services. How is that done ?

This can be done by a service policy apply to the switchport where it connect to the router. Here is an example for that where only voice traffic will go with the given DSCP value & all other traffic go as "class-default which is DSCP 0". First you need classify voice traffic (RTP media & Signalling) & then you can mark them appropriately. If you want to remark other traffic then you need to define those ACLs & give required DSCP marking under policy map. Then you can apply this to switchport connected to the router in ingress direction.

ip access-list extended VOIP-RTP

remark VoIP traffic

permit udp any any range 16384 32767

!

ip access-list extended VOIP-SIGNALLING

remark VOIP-SCCP Traffic

permit tcp any any range 2000 2002

permit tcp any range 2000 2002 any

remark VOIP-SIP Control Traffic

permit udp any any range 5060 5061

permit udp any range 5060 5061 any

permit tcp any any range 5060 5061

permit tcp any range 5060 5061 any

!

class-map match-all VOIP-TRAFFIC

match access-group name VOIP-TRAFFIC

!

class-map match-all VOIP-SIGNALLING

match access-group name VOIP-SIGNALLING

!

policy-map INGRESS-POLICY

class VOIP-TRAFFIC

set ip dscp ef

class VOIP-SIGNALLING

set ip dscp cs3

!

Interface Gig x/x

service-policy input INGRESS-POLICY

HTH

Rasika

*** Pls rate all useful responses ****

New Member

Re: 3560 QoS SRR bandwidth shape/share

i can't thank you enough

Hall of Fame Super Blue

3560 QoS SRR bandwidth shape/share

Rasika

Thanks for that. Wasn't trying to pick fault because you are spot on with your answers just wanted to give the full picture in terms of some switches/linecards.

Jon

VIP Purple

Re: 3560 QoS SRR bandwidth shape/share

Hi Jon,

I perfectly understand that  & it is great that you pointed out that. So it helps someone to understand topic in detail.

Regards

Rasika

Super Bronze

Re: 3560 QoS SRR bandwidth shape/share

Disclaimer

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.

Posting

I just wanted to mention, when you enable QoS on the 3560/3750 series switches, their smallish buffer resources often cause drops not seen before QoS was enabled.  Buffer tuning, i.e. changing from the defaults, can sometimes mitigate this; sometimes not too.

Cisco has (finally) documented that 3750-X series has 2 MB per 24 downlink ports, and 2 MB per uplink ports.  So, for really busy ports, uplinks ports allow for more physical buffers per port.  Cisco hasn't, to my knowledge, documented buffer memory for other models in the series, but I would suspect uplink ports might have more physical buffers on other models too.

BTW, at LAN bandwidths, often prioritization isn't as important as drop management.  So, often on these switches you might just leave QoS disabled.

1123
Views
14
Helpful
19
Replies
CreatePlease to create content