Solved: LAN QOS (on C3750) strategy

shikamarunara · ‎03-19-2010

I'm working on implementing a classification and marking strategy for my network. I've put together some syntax and have recieved some input from others about configuration but would like to know what you think. These are the requirements;

1 - Class-based marking should happen at the edge

2 - RTP traffic should be classified as EF (codec is G711)

3 - Control traffic (MGCP, SCCP, SIP, H323) should be classified as CS3

4 - All other traffic must be marked as Best Effort

5 - Marking from phones and PCs must not be trusted

6 - Marking from servers is trusted

This is what I have;

ACLs
access-list 101 permit udp any any range 16384 32767
access-list 102 permit tcp any any eq 2000
access-list 102 permit tcp any eq 2000 any
access-list 102 permit tcp any any eq 5060
access-list 102 permit tcp any eq 5060 any
access-list 102 permit tcp any any range 1719 1720
access-list 102 permit tcp any range 1719 1720 any

Policy Maps
policy-map QOS-POLICE-VOIP
    class VOIP-RTP
        set dscp ef
         police 96000 8000 exceed-action policed-dscp-transmit
    class VOIP-CONTROL
        set dscp cs3
        police 32000 8000 exceed-action policed-dscp-transmit

Class Maps
class-map match-all VOIP-RTP
    match access-group 101
class-map match-all VOIP-CONTROL
    match access-group 102

Global Syntax
mls qos
mls qos map policed-dscp 24 26 46 to 0

Phone/PC Interface Syntax
interface fa x/x
    service-policy input QOS-POLICE-VOIP

    srr-queue bandwidth share 10 10 60 20
    priority-queue out

Server Interface Syntax
inteface gig x/x
    mls qos trust dscp

I have questions regarding some of this syntax;

1 - What is the implication of the police statements in the policy map? For the RTP traffic, we are policing each phone's RTP traffic at 96000 bits per second and control traffic is being policed at 32000 bits per second, which I believe corresponds to the bandwidth requirements of g711 after overhead. Does this mean that if the switch port sees anything more traffic than this that the packets are sent for the DSCP rewrite? Why are these bandwidth statements needed? The policy map, which is applied on the interface, refers to a class map that in turn refers to a very specific ACL that looks for traffic based on the protocol ports. We are already telling the switch that if traffic comes in that matches the specifications of the ACL that it be classified as EF or CS3. Is there a way of telling it that if any other communication happens outside of what is found in the ACLs that it be sent for a DSCP rewrite so that we can accomplish the Best Effort classification requirement? What is the best way to do this?

2 - In the context of this configuration, what does the syntax for srr-queue bandwidth share 10 10 60 20 do?

Lei Tian · ‎03-19-2010

Hi,

1 - What is the implication of the police statements in the policy map? For the RTP traffic, we are policing each phone's RTP traffic at 96000 bits per second and control traffic is being policed at 32000 bits per second, which I believe corresponds to the bandwidth requirements of g711 after overhead. Does this mean that if the switch port sees anything more traffic than this that the packets are sent for the DSCP rewrite? Why are these bandwidth statements needed? The policy map, which is applied on the interface, refers to a class map that in turn refers to a very specific ACL that looks for traffic based on the protocol ports. We are already telling the switch that if traffic comes in that matches the specifications of the ACL that it be classified as EF or CS3. Is there a way of telling it that if any other communication happens outside of what is found in the ACLs that it be sent for a DSCP rewrite so that we can accomplish the Best Effort classification requirement? What is the best way to do this?

2 - In the context of this configuration, what does the syntax for srr-queue bandwidth share 10 10 60 20 do?

1, the police will make sure other traffic that match the RTP class will not be traded as RTP traffic; say w/o this command if you have an application using UDP in the port range, then it will be marked as RTP traffic and receive the EF tradement, which it not what you want. So the police statement will say traffic within that CIR will be traded as EF; traffic beyond that CIR most likely is not RTP traffic then it will mark down to other DSCP value. The marked down DSCP value is determined by the policed-DSCP map. You have policy-map applied under the interface level which will mark the EF and CS3 based on the ACL, traffic doesn't match any ACL will be remarked to DSCP 0.

2,

 srr-queue bandwidth share 10 10 60 20

Each interface has 4 queues, each queue will have its own bandwidth, and they are served as round robin fashion. This command tells the interface the bandwidth percentage for each queue, for for case Q1 10%, Q2 10%, Q3 60% and Q4 20%

HTH,

Lei Tian

View solution in original post

Aaron Harrison · ‎03-19-2010

Hi

1) The police statement is there to stop your endpoints doing things like (for example) streaming 100Mb of traffic onto the LAN marked as EF. The first 96k would get through as EF, the rest map to 0 as defined by your DSCP policing map.

In order to ensure that all other traffic (aside from your defined classes) is marked as 0, you should create a class-default like so in your input policy (this must be named as class-default, it's a special/built in catch-all default class)

class class-default

set dscp 0

One other comment - you say 'very specific' in relation to your ACL. This could be considered true for the signalling ACL, but the RTP ACL covers a very large range of ports. You will likely find that other things use this range of ports, including PC-based VoIP/video applications. This is a drawback of using ACLs to classify voice, it's tricky. You may be able to incorporate addressing into your ACL if you just want to trust phones, and have those phones in a dedicated VVLAN - though if you are IP Communicator, then they would not get classified.

2) srr-queue bandwidth share 10 10 60 20 - this is a ratio of bandwidth allocation. As your values add up to 100, it's easy to work out - 10% q1, 10% q1, 60% q3, 20% q4.

You have priority queue enabled, so (assuming you have a 3560 or 3750), the queue 1 allocation of bandwidth is ignored (as that queue is always serviced if there is data in it), so the actual queue time (in the absence of anything in queue 1) would be slightly higher than I indicated above...

Regards

Aaron

Please rate helpful posts....

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

View solution in original post

Lei Tian · ‎03-19-2010

Hi,

1 - What is the implication of the police statements in the policy map? For the RTP traffic, we are policing each phone's RTP traffic at 96000 bits per second and control traffic is being policed at 32000 bits per second, which I believe corresponds to the bandwidth requirements of g711 after overhead. Does this mean that if the switch port sees anything more traffic than this that the packets are sent for the DSCP rewrite? Why are these bandwidth statements needed? The policy map, which is applied on the interface, refers to a class map that in turn refers to a very specific ACL that looks for traffic based on the protocol ports. We are already telling the switch that if traffic comes in that matches the specifications of the ACL that it be classified as EF or CS3. Is there a way of telling it that if any other communication happens outside of what is found in the ACLs that it be sent for a DSCP rewrite so that we can accomplish the Best Effort classification requirement? What is the best way to do this?

2 - In the context of this configuration, what does the syntax for srr-queue bandwidth share 10 10 60 20 do?

1, the police will make sure other traffic that match the RTP class will not be traded as RTP traffic; say w/o this command if you have an application using UDP in the port range, then it will be marked as RTP traffic and receive the EF tradement, which it not what you want. So the police statement will say traffic within that CIR will be traded as EF; traffic beyond that CIR most likely is not RTP traffic then it will mark down to other DSCP value. The marked down DSCP value is determined by the policed-DSCP map. You have policy-map applied under the interface level which will mark the EF and CS3 based on the ACL, traffic doesn't match any ACL will be remarked to DSCP 0.

2,

 srr-queue bandwidth share 10 10 60 20

Each interface has 4 queues, each queue will have its own bandwidth, and they are served as round robin fashion. This command tells the interface the bandwidth percentage for each queue, for for case Q1 10%, Q2 10%, Q3 60% and Q4 20%

HTH,

Lei Tian

shikamarunara · ‎03-19-2010

Lei (or anyone),

One question - in the policy map, isn't there a risk that traffic that uses the port range 16384 to 32767 can still be classified as EF by mistake? Isn't the implication that if traffic comes through the interface and it happens to use a port in this range and the traffic happens to not exceed 96000 bytes per second that it will be mistakenly marked as RTP? What is the implication of the statement police 96000 8000 exceed-action policed-dscp-transmit ? This means that any traffic that is under 96000 bytes per second that uses the referenced ranges gets marked ef? Is it possible that RTP traffic can be mistakenly marked Best Effort?

Aaron Harrison · ‎03-19-2010

Hi

Yes, that's correct as I put in my earlier post.

The only way around this really is to use endpoint marking; you can do this in conjunction with a police statement to discourage misuse of the classes. That way random streams that use the same ports as RTP that aren't coming in marked as EF (as all packets from CIPC, IP Phones, VC units etc should) it won't get classified incorrectly.

In a corporate environment the desktop PCs should be reasonably controlled, so it's unlikely that someone is going to be able to remark other traffic as EF. If they do, they are then limited to whatever bandwidth you have in your police statement.

Regards

Aaron

Please rate helpful posts..

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

shikamarunara · ‎03-19-2010

Okay, so there are a couple of problems;

1 - Personally, I can't really afford to trust the possibility of marking by endpoint devices - which complicates the issue since I have to decide how the traffic is discerned by the switch.

2 - In a corporate environment, I'm still worried about guest PCs and no clean-access technology (and these are still common issues.)

So, in other words, I don't want to trust the phones and PCs.

Aaron, does the policing statement mean that the first 96000 bytes per second that conform to the access list requirement get marked as EF? If so, that means that a condition can occur where virus traffic is being generated by a PC connected through a phone to a switch that sends packets meeting the port-range criteria. Then, when someone picks up the phone to make a call, the RTP packets will be marked as Best Effort. Now, granted, that's just one phone and PC, but the point is that my configuration won't work as intended in the way that it is configured and I could have a problem if enough PCs connected to a switch(es) have the same virus, no?

Aaron Harrison · ‎03-19-2010

That the choice you have.

There is no perfect solution; I find trusting the attached devices to mark the traffic themselves, and then policing that to a suitable per-endpoint bandwidth amount is the best balance.

At least that way the random virus traffic on a coincidental port in your example would also have to be marking the traffic as EF.

Aaron

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

shikamarunara · ‎03-19-2010

Okay, well, that gives me something to think about and work on. I might trust markings on the phone but not on the

PC. That might be the best comprimise.

Lei Tian · ‎03-20-2010

Hi,

Sorry for the late reply.

  One question - in the policy map, isn't there a risk that traffic that uses the port range 16384 to 32767 can still be classified as EF by mistake?  Isn't the implication that if traffic comes through the interface and it happens to use a port in this range and the traffic happens to not exceed 96000 bytes per second that it will be mistakenly marked as RTP?  What is the implication of the statement police 96000 8000 exceed-action policed-dscp-transmit ?  This means that any traffic that is under 96000 bytes per second that uses the referenced ranges gets marked ef?

Yes, none RTP traffic in that port range and within the policer profile will be traded as EF.

  Is it possible that RTP traffic can be mistakenly marked Best Effort?

As long as the RTP traffic doesn't exceed the policer profile, it will be marked as EF. Individual policer rate limit to certain CIR for each traffic flow; it is unlikely your PC and phone have same source IP, so it will be police separately.

HTH,

Lei Tian

shikamarunara · ‎03-20-2010

As long as the RTP traffic doesn't exceed the policer profile, it will be marked as EF. Individual policer rate limit to certain CIR for each traffic flow; it is unlikely your PC and phone have same source IP, so it will be police separately.

Well, this can be a problem if a different codec with higher bandwidth requirements used? I'd have to change the policer, correct?

I think I'm going to change the strategy to trust markings from the phone and untrust from anything else (and treat as Best Effort). It sounds like that will be less trouble.

Lei Tian · ‎03-20-2010

Yes, you can put your trust boundary to the phones, and you can still keep your policer, they are not mutual exclusive. If you have application like soft phone, then it will be remarked.

Aaron Harrison · ‎03-19-2010

Hi

1) The police statement is there to stop your endpoints doing things like (for example) streaming 100Mb of traffic onto the LAN marked as EF. The first 96k would get through as EF, the rest map to 0 as defined by your DSCP policing map.

In order to ensure that all other traffic (aside from your defined classes) is marked as 0, you should create a class-default like so in your input policy (this must be named as class-default, it's a special/built in catch-all default class)

class class-default

set dscp 0

One other comment - you say 'very specific' in relation to your ACL. This could be considered true for the signalling ACL, but the RTP ACL covers a very large range of ports. You will likely find that other things use this range of ports, including PC-based VoIP/video applications. This is a drawback of using ACLs to classify voice, it's tricky. You may be able to incorporate addressing into your ACL if you just want to trust phones, and have those phones in a dedicated VVLAN - though if you are IP Communicator, then they would not get classified.

2) srr-queue bandwidth share 10 10 60 20 - this is a ratio of bandwidth allocation. As your values add up to 100, it's easy to work out - 10% q1, 10% q1, 60% q3, 20% q4.

You have priority queue enabled, so (assuming you have a 3560 or 3750), the queue 1 allocation of bandwidth is ignored (as that queue is always serviced if there is data in it), so the actual queue time (in the absence of anything in queue 1) would be slightly higher than I indicated above...

Regards

Aaron

Please rate helpful posts....

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

shikamarunara · ‎03-19-2010

Thank you, guys. This helps a lot. I appreiciate the feedback.