05-28-2008 07:09 AM - edited 03-05-2019 11:16 PM
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
05-28-2008 10:31 AM
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
05-29-2008 02:52 AM
Actually I have been working from this, but many thanks anyway.
05-28-2008 10:41 AM
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.
05-28-2008 10:44 AM
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
05-29-2008 02:50 AM
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....
05-29-2008 02:50 AM
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
05-29-2008 06:38 AM
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.
05-29-2008 07:00 AM
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.
05-29-2008 08:07 AM
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.
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