Qos on lan with network imaging

[dan.letkeman]

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.

[mgalazka]

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

[dan.letkeman]

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.

[mgalazka · Accepted solution]

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

[dan.letkeman]

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.

[mgalazka]

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

[dan.letkeman]

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.

[mgalazka]

That makes sense, thanks for sharing Dan!

[Joseph W. Doherty]

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.