Calling LAN QoS experts!

jigsaw2026 · ‎05-28-2008

We're implementing ip phones on our 3750 - the set up is as follows:

PC---ip phone---<l2 trunk>---3750---<l2 trunk>---3750---<routed l3>---3750---<routed l3>---6509---IP office

I had intended to put a service policy on the access-switch interface that the pc/phone connects into, marking VoIP traffic, VoIP signalling, certain critical-data protocols (for us this is ssh, rdp, telnet), BE traffic, and scavenger class (ftp etc). I was planning to do this with access-lists. Unfortunately when I implemented this no traffic was marked - I guess this is because I'm trying to mark layer 3 info on a layer 2 switchport. The QoS commands on my 3750s are extremely limited...therefore I am now thinking that I will:

-trunk dscp markings from the access switch ports (this will basically only be BE (data) and EF (VoIP) traffic - I have been analysis this for a few hours)

-apply egress prority queuing on the L2 trunk ports

-Mark all other interesting traffic on layer 3 interface using ACLs (SSH, etc) in an inbound service policy

-apply outboud priority queueing on L3 interface

What I can't understand is how to apply priority queueing with only 2 queues. On the L2 access switch I am basically going to have EF VoIP traffic, and then everything else as BE. I either need 2 queues (1 priority for EF) or 4 queues with 3 all handling BE traffic. Otherwise queues 2 and 3 will have zero traffic running on them. Not sure if this makes sense or whether I've not understood it properly...really hoping someone can help!

Many thanks,

J

PAUL TRIVINO · ‎05-28-2008

If you haven't seen it (although you seem pretty knowledgeable on QoS), check out the Enterprise QoS Design Guide at http://www.cisco.com/application/pdf/en/us/guest/netsol/ns432/c649/ccmigration_09186a008049b062.pdf, this is an excellent resource.

Paul

jigsaw2026 · ‎05-29-2008

Actually I have been working from this, but many thanks anyway.

michael.leblanc · ‎05-28-2008

Not the LAN QoS expert requested.

However, I suspect that you need to revisit your classification/marking configuration on the switch ports.

I have a c2950T (layer 2) access switch, and you "can" classify/mark packets based on Layer 3 info.

Here is an example:

Note: The "hst-10" portion of my naming convention indicates that a host is attached to the port, and that I am marking the matching traffic with DSCP 10 (i.e.: AF11).

ip access-list extended hst-10-af11-bulk

permit tcp any any eq ftp-data

permit tcp any any eq ftp

permit tcp any any eq pop3

permit tcp any any eq 587

permit tcp any any eq smtp

class-map match-all hst-10-af11-bulk

match access-group name hst-10-af11-bulk

policy-map hst-qos

class hst-10-af11-bulk

set ip dscp 10

interface FastEthernet0/18

service-policy input hst-qos

I am (of course) using other class-maps to mark other traffic with a range of different DSCP values for a complete service-policy. I have just culled it down for a simple example.

I can not tell you that this syntax is supported on your device.

There should be many output queueing options available to you providing more than 2 queues (opinion).

One of the LAN QoS experts can help you further.

Good luck.

PAUL TRIVINO · ‎05-28-2008

Good point too.

Also, don't depend on "sh policy-map int x/y" for whether or not the traffic is marked, the counters don't work on switches at least). But capturing the traffic should show the markings.

Paul

jigsaw2026 · ‎05-29-2008

Thanks a lot guys for your responses.

This is what I'm doing on my access switch to try to mark the packets, which I think is the same as what you have:

class-map match-any critical-data

match access-group 102

class-map match-any vvlan-voice

match access-group 100

class-map match-any vvlan-call-signalling

match access-group 101

class-map match-any scavenger

match access-group 103

policy-map ipphone+pc-basic

class vvlan-voice

set dscp ef

class vvlan-call-signalling

set dscp cs4

class critical-data

set dscp 25

class scavenger

set dscp cs1

class class-default

set dscp default

interface FastEthernet1/0/9

switchport access vlan 322

switchport trunk native vlan 322

switchport mode dynamic desirable

switchport voice vlan 321

no snmp trap link-status

spanning-tree portfast

service-policy input ipphone+pc-basic

The problem is I just can't see that it's working. I realise that the sh policy map int isn't necessarily indicative, but also the ACLs don't seem to be incrementing (and I think they would??):

gr102#sh access-list

Extended IP access list 100

10 permit udp 10.30.22.0 0.0.0.255 10.30.25.0 0.0.0.255 range 16384 32767

20 permit udp 10.30.22.0 0.0.0.255 10.4.0.0 0.3.255.255 range 16384 32767

Extended IP access list 101

10 permit ip 10.30.22.0 0.0.0.255 host 10.30.25.20

Extended IP access list 102

10 permit tcp any any eq 3389

20 permit tcp any any eq telnet

30 permit tcp any any eq 22

Extended IP access list 103

10 permit tcp any any eq www

20 permit tcp any any eq 443

Continued on next post....

jigsaw2026 · ‎05-29-2008

Also:

gf102#sh mls qos int fa1/0/9 stat

FastEthernet1/0/9

dscp: incoming

-------------------------------

0 - 4 : 25946955 0 0 0 0

5 - 9 : 0 0 0 0 0

10 - 14 : 0 0 0 0 0

15 - 19 : 0 0 0 0 0

20 - 24 : 0 0 0 0 0

25 - 29 : 0 0 0 0 0

30 - 34 : 0 0 0 0 4

35 - 39 : 0 0 0 0 0

40 - 44 : 0 0 0 0 0

45 - 49 : 0 3168 0 0 0

50 - 54 : 0 0 0 0 0

55 - 59 : 0 0 0 0 0

60 - 64 : 0 0 0 0

dscp: outgoing

-------------------------------

0 - 4 : 31653631 0 0 0 22

5 - 9 : 0 16334 0 0 0

10 - 14 : 0 0 0 0 0

15 - 19 : 0 0 0 0 0

20 - 24 : 0 0 0 0 0

25 - 29 : 0 0 0 0 0

30 - 34 : 0 0 0 0 0

35 - 39 : 0 0 0 0 0

40 - 44 : 0 0 0 0 0

45 - 49 : 0 0 0 168431 0

50 - 54 : 0 0 0 0 0

55 - 59 : 0 0 0 0 0

60 - 64 : 0 0 0 0

cos: incoming

-------------------------------

0 - 4 : 27488777 0 0 0 0

5 - 7 : 0 3556 0

cos: outgoing

-------------------------------

0 - 4 : 63565891 0 0 0 0

5 - 7 : 1651 41837 18425

Policer: Inprofile: 0 OutofProfile: 0

Any ideas where I am going wrong, or am I reading the outputs wrong?

Many thanks,

J

michael.leblanc · ‎05-29-2008

Are you sure you don't have a directional issue?

Lets look at ACL 103 as an example.

10 permit tcp any any eq www

For this packet to be matched, the "destination" port would have to be 80.

You have "input" policy applied to interface FastEthernet1/0/9 (a trunk port).

interface FastEthernet1/0/9

service-policy input ipphone+pc-basic

Are you sure that packets "input" on this port would have a "destination" port of 80, vs. a "source" port of 80?

Perhaps your ACLs are directionally reversed, given that you are applying "input" policy on that specific port.

Perhaps this is why your ACLs are not being matched.

Perhaps:

10 permit tcp any any eq www

should be:

10 permit tcp any eq www any

... and others like it.

I don't know your topology, so I can't be sure.

jigsaw2026 · ‎05-29-2008

I thought that might be the case too but it doesn't make a difference when I reverse it. I'm putting this service policy on an interface that has a phone and PC directly attached to it (see output in previous post for sh run int fa1/0/9) so I'm pretty sure it should be destination port 80 if I am trying to access a remote web page, etc.

Many thanks for your suggestion though, much appreciated.

michael.leblanc · ‎05-29-2008

I think you should apply the service-policy to an access port (making sure your ACLs are still appropriate), and retest to prove the policy is healthy (which I believe it is).

The presence of the VLAN headers on fa1/0/9 may be the issue, as they would create an offset, and may be hindering your matching of specific upper-layer fields in the packet.

Perhaps your class-map needs to match VLAN criteria as well to address the offset due to the 802.1Q headers.

I've not used classification/marking on a trunk before, only at the edge.