Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Community Member

Catalyst 3560 Extended ACLs

I have a VoIP / QoS situation I just discovered on the Cat 3560's. In this case, a particular manufacturer's IP Phones do not tag CoS or DSCP. As such, I have defined extended ACL's/Policies on the Cat 3560 switches to detect and mark traffic from the IP Phones. My policies are designed to identify and mark Call Bearer with DSCP 46 and Call Control traffic with DSCP 26 based upon source address and UDP port. What I see however, is that all VoIP traffic is marked at DSCP 46, and nothing is marked at 26. (It's not so bad having control and bearer marked with DSCP EF, but I like to put call control in a different queue when possible.)

I am looking for confirmaton of the following theory. I suspect that the 3560's ((C3560-IPBASEK9-M), Version 12.2(25)SED) are not layer 4 aware, thus extended access lists function only as standard access lists - (even though the switch allows me to create an extended ACL). As such, my attempt to identify call bearer and call signalling based upon UDP port will not work.

Below is the ACL / Policy config. Note that on downstream routers, I only see DSCP 46 and never match DSCP 26 (af31). From the switch, using "sh mls qos interface statistics", I see no traffic with DSCP 26 at all (output attached).

I believe this is because the switch is only reading the layer 3 portion of the ACL. Since both ACL 101 and ACL 102 have the same layer 3 source adress, then all classified traffic will match class "IngressVoiceBearer" and get marked with 46.

access-list 101 remark Voice Bearer Signalling

access-list 101 permit udp 192.168.100.0 0.0.0.255 any eq 5004

access-list 102 remark Call Control Signalling (udp 5440-5445)

access-list 102 permit udp 192.168.100.0 0.0.0.255 any eq 5440

access-list 102 permit udp 192.168.100.0 0.0.0.255 any eq 5441

access-list 102 permit udp 192.168.100.0 0.0.0.255 any eq 5442

access-list 102 permit udp 192.168.100.0 0.0.0.255 any eq 5443

access-list 102 permit udp 192.168.100.0 0.0.0.255 any eq 5444

access-list 102 permit udp 192.168.100.0 0.0.0.255 any eq 5445

class-map match-any IngressCallControlSignalling

match access-group 102

class-map match-any IngressVoiceBearer

description All Inbound Voice Bearer traffic on UDP 5004

match access-group 101

policy-map IngressVoIP

class IngressVoiceBearer

set dscp ef

class IngressCallControlSignalling

set dscp af31

class class-default

set dscp default

Switch Output:

switch#sh mls qos int g0/1 statistics

GigabitEthernet0/1

dscp: outgoing

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

0 - 4 : 12359302 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 0

35 - 39 : 0 0 0 0 0

40 - 44 : 0 0 0 0 0

45 - 49 : 0 1837749 0 9716 0

50 - 54 : 0 0 0 0 0

55 - 59 : 0 0 0 0 0

60 - 64 : 0 0 0 0

3 REPLIES
Community Member

Re: Catalyst 3560 Extended ACLs

Are the ports correct for the call control ACL? In the Cisco VoIP world we use an ACL like this for call control:

ip access-list extended VOICE-CONTROL

permit tcp any any range 2000 2002

permit tcp any range 2000 2002 any

permit tcp any any range 11000 11999

permit tcp any any range 1718 1720

permit udp any any range 1718 1719

permit udp any any range 2427 2428

permit tcp any any range 2443 2445

permit tcp any any range 5555 5599

But Cisco uses different protocols. Your ACL is configured correctly and the 3560 is supposed to support extended ACLs. Does your 3560 have an enhanced image or a standard image?

Are these Avaya phones? I have had to do software updates on Avaya phones to get them to behave correctly.

-Mark

Community Member

Re: Catalyst 3560 Extended ACLs

This is a Shoretel phone system. The ports are correct. I match all of these same ports perfectly on the routers in this LAN/WAN.

I included the image version in my previous post, but this is a standard image.

Every system is different. Mitel, Intertel, Avaya, Shoretel, NEC, Cisco. I've worked with them all - however Shoretel is the only one I have encountered where the phones do not mark CoS/DSCP. Bugger that!

As I said initially, I don't mind that everything is marked DSCP 46 - there is not a ton of VoIP traffic. Regardless, I would like to know why the 3560 is doing what it is doing for future design/config.

Thank you.

Jamison

Community Member

Re: Catalyst 3560 Extended ACLs

I'm going to be doing a similiar set-up with a 4500 Catalyst plugging Shoretel phones in. I'm trying to figure out the best route to go as far as QOS. I like your configuration but it does seem weird that the AF31 was not getting sent to its own queue.

Do we need to do anything with COS. Are the Shoretel phones capable of trunking? My understanding is that COS is only visible on a trunk.

My scenario is a flat network. Is there anything I need to do to have the 4500 switch look at layer 3 markings? Will it look at layer three markings and act on them by default?

Thanks,

Jason

465
Views
0
Helpful
3
Replies
CreatePlease to create content