02-25-2012 07:43 AM - edited 03-07-2019 05:11 AM
Hello,
I have a situation where I need to setup some kind of qos between two switches that are located between two builings and connected via our own 1G fiber.
We have some video systems setup but we also have a voice system in both buildings. When my co-workers need to reimage a few of the desktops the imaging server is fast enouph that it hogs all of the bandwidth on the fiber link. This is obviously a concern for the voice and video traffic. But what I noticed the most was my snmp traffic was not getting to the switch were the computers were connected to and then my monitoring system thought that the switch was going up and down while the imaging process was going.
My dscp trust commands on my trunk ports are as follows:
priority-queue out
mls qos trust dscp
My though was to set the dscp on the snmp traffic coming from the monitoring server and the switch, as I already have a dscp trust between the switches for the voice traffic.
Is the the correct way of solving this problem?
What would be the best way to set the dscp on the snmp traffic?
Thanks,
Dan.
Solved! Go to Solution.
02-25-2012 12:25 PM
With the 3560/3750 line, you can still do limited output QoS. This document is pretty detailed on how to go about setting up QoS on 3560:
http://www.cisco.com/en/US/products/hw/switches/ps5023/products_tech_note09186a0080883f9e.shtml
You can map DSCP values to output queues via config, like this example below:
mls qos srr-queue output dscp-map queue 1 threshold 3 46
mls qos srr-queue output dscp-map queue 2 threshold 3 54
mls qos srr-queue output dscp-map queue 3 threshold 3 8
mls qos srr-queue output dscp-map queue 4 threshold 1 0
You can define the thresholds and buffers as well, as described in the above document.
For example, if you set up your srr-queue's with queue 1 being voice, then queues 2, 3, 4 being other important traffic... say Q2 is net management and/or video, Q3 is bulk data, Q4 is default, then you can configure your outbound interface towards the 1G fiber with commands like this:
int G1/1
srr-queue bandwidth share 1 40 10 50
priority-queue out
Note with this configuration as we are specifying priority queue, queue 1 becomes priority. The remaining bandwidth not used by the priority queue is split at the ratio of the other 3 queues (Q2 = 100%*40/(40+10+50) = 40%; Q3 = 10%; Q4 = 50%).
Again, this is fairly brief overview but hopefully between cherry-picked examples here and the link attached, you will be able to get a solid config built!
Good luck!
Matt
02-25-2012 10:29 AM
Without knowing more about the platforms on each side of the link in question, I can give you an example of what type of configuration you should look to perform. These are just examples to show you the basic method of applying QoS in IOS -- so please do not just run with this and hope it will meet all of your needs.
I would recommend building a quality of service policy to help allow certain traffic flow uninterrupted by punishing others, in the event of network congestion. Especially if there is voice across this circuit, it is very important to try to identify and prioritize your traffic.
Most platforms support MQC configuration for QoS... the basics to this are as follows:
1. Define class-maps to differentiate your traffic.
e.g:
class-map match-any voip-class
! match on trusted traffic already marked
match ip dscp 46
! if supported, use NBAR to match VoIP traffic
match protocol rtp audio
! match on ACL defining IP addresses and/or UDP ports of voice traffic
match access-group name VoIP-Traffic
!
class-map match-any net-mgmt
! match on trusted traffic already marked
match ip dscp cs6
! match on SNMP traffic via ACL
match access-group name SNMP-Servers-UDP161-UDP162
! match SSH traffic via ACL
match access-group name NetMgmt-Loopbacks-TCP22
!
class-map match-any bulk-data
! match on trusted traffic already marked
match ip dscp cs1
! match on Desktop reimaging traffic via ACL
match access-group name Imaging-Traffic
!
2. Set up policy-map for QoS marking of ingress traffic on untrusted ports
e.g.
policy-map ingress-untrust
class voip-class
set ip dscp 46
class net-mgmt
set ip dscp cs6
class bulk-data
set ip dscp cs1
class class-default
set ip dscp 0
3. Set up policy-map for QoS outbound for prioritization
e.g.
policy-map egress-policy
class voip-class
! Define voice traffic as priority queue
priority percent 33
class net-mgmt
! define rest as class based weighted fair queuing
bandwidth percent 10
class bulk-data
bandwidth percent 7
class class-default
bandwith percent 50
4. Apply policy-maps to interfaces -- marking on input of standard LAN ports, prioritization outbound on 1G fiber.
e.g.
int range fa1/1 - 48
descr $LAN-UNTRUSTED$
service-policy input ingress-untrust
int g2/1
descr $WAN-LINK$
service-policy output egress-policy
end
Again, this is just an example and is not really complete (no matching/prioritization of voice control protocol, video, etc) but I am hoping it gives a good idea as to the basics of QoS in IOS.
Hope this helps,
Matt
02-25-2012 11:06 AM
Thank you very much for the example Matt.
The platforms are 2960's, 3560's and 3560G's. So I do not have the bandwidth command available to me, only the police, set and trust commands. I also cannot assign a policy to the output side of an interface:
Warning: Assigning a policy map to the output side of an interface not supported
This is most limiting.
Dan.
02-25-2012 12:25 PM
With the 3560/3750 line, you can still do limited output QoS. This document is pretty detailed on how to go about setting up QoS on 3560:
http://www.cisco.com/en/US/products/hw/switches/ps5023/products_tech_note09186a0080883f9e.shtml
You can map DSCP values to output queues via config, like this example below:
mls qos srr-queue output dscp-map queue 1 threshold 3 46
mls qos srr-queue output dscp-map queue 2 threshold 3 54
mls qos srr-queue output dscp-map queue 3 threshold 3 8
mls qos srr-queue output dscp-map queue 4 threshold 1 0
You can define the thresholds and buffers as well, as described in the above document.
For example, if you set up your srr-queue's with queue 1 being voice, then queues 2, 3, 4 being other important traffic... say Q2 is net management and/or video, Q3 is bulk data, Q4 is default, then you can configure your outbound interface towards the 1G fiber with commands like this:
int G1/1
srr-queue bandwidth share 1 40 10 50
priority-queue out
Note with this configuration as we are specifying priority queue, queue 1 becomes priority. The remaining bandwidth not used by the priority queue is split at the ratio of the other 3 queues (Q2 = 100%*40/(40+10+50) = 40%; Q3 = 10%; Q4 = 50%).
Again, this is fairly brief overview but hopefully between cherry-picked examples here and the link attached, you will be able to get a solid config built!
Good luck!
Matt
02-25-2012 12:44 PM
This is excellent information. Applying markings to ingress traffic and then queuing them on egress makes more sense now.
Only have one more question:
Will the dscp value of the traffic coming from the snmp server still apply when the return traffic goes back to the snmp server? Or should I set the dscp value of the snmp traffic from the switch going back to the snmp server? If so how would I do that if the switch does not support egress polices?
Thanks,
Dan.
02-25-2012 12:56 PM
Dan,
I am glad this is helpful!
In a typical "untrusted client" model as we have been talking about, the client ports (Servers, PC's etc) are not trusted, so you have to mark traffic as it enters the network. This must be done bidirectionally, as there is no state relationship with marking flows.
It is best practice to mark traffic as close to the source as possible, so you should preferrably mark traffic destined to the SNMP server from the clients on the client access switch, and alternatively traffic from the snmp server to the clients should be marked on the switch with the SNMP server.
Remember you can mark your ingress traffic on a switch and choose not to apply an egress policy too -- so if you are only concerned with bandwidth congestion on the 1 fiber link you spoke of, you could choose to only do the egress policies on each side of that fiber link (assuming it is a 3560 on both sides), and then elsewhere closer to the sources just worry about making sure traffic is properly marked with the right DSCP values on ingress.
Does this make sense, and more importantly does it answer your question?
Thanks,
Matt
02-25-2012 01:00 PM
This was the command I was looking for:
snmp-server ip dscp
So I can mark the snmp traffic that is going directly from the switch not a client back to the snmp server.
Thanks again.
Dan.
02-25-2012 01:02 PM
That makes sense, thanks for sharing Dan!
02-26-2012 03:06 AM
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
If you're new to QoS, just wanted to emphasis, by default QoS features are disabled on the Cisco switches you mentioned. If I remember correctly, you can even add configuration commands, as Matt describes, but they won't be active until QoS is globally enabled on the switch.
To your question, do you need to QoS process return path traffic; actually no, if there's no congestion issue in the return path.
BTW, many switches support auto-QoS which will give you a working QoS policy although you may need to insure you traffic is identified (classified) to be sent to the appropriate queues.
Although Matt is correct, the "book" calls for marking as close to the source as possible, if congestion isn't a problem within the LAN, i.e. it's only a problem across the gig link, besides doing just egress QoS as Matt suggests, you could also only do classification there too. This might avoid the burden of maintaining QoS policies on many other switches.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide