cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
11523
Views
5
Helpful
10
Replies

Avaya Phones, Cisco Switches and QoS (MPLS network in between)

l.mourits
Level 5
Level 5

All,

I am implementing QoS on our MPLS network. Our environment exists of a mix of Cisco 3750 and 3560 switches. The IPT system is Avaya CM with Avaya phones.

The WAN network is a MPLS network.

Ports are configured for access and voice vlan (no trunking), one vlan for voice, one for data (vlan 1 is disabled).

We like to trust dscp settings from the Avaya phone (pretty simple to figure that out, just auto qos voip trust). Testing it I found the Avaya phones leaves any markings on the data vlan untouched.

We are planning on setting the dscp marks for other traffic then Voice on our packetshapers (that are in between the router and te switch uplink to the router). That all works great.

Upon failure of the packetshaper I need all traffic other then voice to be marked as AF21 instead of BE, and I am looking for the easiest way to do this. preferably without using access-lists that hold IP info (as I like to standardize my configs as much as possible).

So, i am looking to trust dscp mapping on the access ports of each switch (autoqos trust dscp, easy) and then have all traffic coming into the data vlan marked with dscp 18 (AF21) before it leaves the switch. All trunks will be configured to trust dscp as well.

With the dat vlan getting dscp marked as AF21, then remarking the traffic on our packetshapers, I would have all marking set correctly before it enters the ploicymap on the CPE of the MPLS provider, and if the Packetshaper fails I would still have the AF21 and Voice markings. that way I try to avoid all data traffic to end up in the BE class upon packetshaper failure.

Can anyone tell me the easiest way to put a default dscp marking on ingress traffic in the data vlan?

Thanks in advance,

Leo

1 Accepted Solution

Accepted Solutions

Leo

Yep, clever bloke Andy, i worked with him on a project in the UK.

I think you're right in what you say. The service-policy should apply all the correct markings and with the "permit ip any any" it is generic enough to be applied throughout your network.

Good luck with the deployment, let me know how it goes.

Jon

View solution in original post

10 Replies 10

Jon Marshall
Hall of Fame
Hall of Fame

Leo

You would normally use class maps and acl's to match the traffic and then set your DSCP value.

However you say you don't want to use this. There is the option to use a DSCP-to-DSCP mutation map. This is done on a per port basis and allows you to change the incoming DSCP value to one of your choosing -

http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_44_se/configuration/guide/swqos.html#wp1031921

Have never used this before but does this sound like what you need ? If so i have a couple of 3550 switches to hand and i could knock up a quick test.

One other thing though. You say you want to keep standard config. Using class-map with acl would be standard though because the acl would be the same on each data port. Or perhaps i am misunderstanding ?

Jon

Jon,

(nice to see one of the best on the forum reply ;-))

What I mean with trying to standardize configs is to standardize configs throughout the globe. My company has many sites, all with their own subnets, which is why I wanted to avoid the ACLs as they would have to include the IP info ;-)

What I am currently testing is to see if I can actually mix trust and service-policy on the interfaces. The Avaya phones are configured to send the correct dscp markings, and by matching and reclassifying the traffic I think it could work.

Let me know what you think of the following:

!

ip access-list extended vlan-data

permit ip any any

!

class-map match-all vlan-voice-rdp

match ip dscp ef

!

class-map match-all vlan-voice-signaling

match ip dscp af31

!

class-map match-all vlan-data

match access-group name vlan-data

!

policy-map ipphone

class vlan-voice-rdp

set ip dscp 46

police 128000 8000 exceed-action drop

class vlan-voice-signaling

set ip dscp 26

police 32000 8000 exceed-action policed-dscp-transmit

class vlan-data

set ip dscp 18

police 800000 8000 exceed-action policed-dscp-transmit

class class-default

set ip dscp 0

police 5000000 8000 exceed-action policed-dscp-transmit

!

interface x/y/z

switchport access vlan

switchport mode access

switchport nonegotiate

switchport voice vlan

no logging event link-status

srr-queue bandwidth share 10 10 60 20

srr-queue bandwidth shape 10 0 0 0

priority-queue out

no snmp trap link-status

auto qos voip trust

storm-control broadcast level 50.00

storm-control multicast level 50.00

storm-control unicast level 99.00

storm-control action trap

spanning-tree portfast

service-policy input ipphone

exit

I get the impression while testing that it actually works, allthough there seem to be a cosmetic issue, where the access-list and policy-maps show no matches. But if that is the only downside, I'm okay with it. I did see traffic ending up in AF21 now, which was not the case before I entered this.

Thanks in advance,

Leo

Leo

"(nice to see one of the best on the forum reply ;-))" - appreciate the compliment altho you may want to wait until we have finished this thread :-)

Funnily enough i was thinking of using "permit ip any any" for data when i was talking about standardising to "mop" up the non VOIP traffic which is exactly what you have done. As long as it is in the right order in your policy-map then it will be fine altho you realise nothing will match class-default unless you have non-IP traffic on the port.

You need to have a read of this thread as it was one i was involved in recently about mixing trust state and service-policy on the same interface. Andy Butterworth seems to be suggesting they cannot be used together and the documentation backs this up altho i'm not sure how the "auto qos voip trust" affects this. If you are sure packets are getting marked properly then perhaps the auto qos setting behaves differently.

Also there is an issue with 3560/3750 in that they do not keep counters for QOS/ACL's switched in hardware. Next best command is

sh mls qos interface statistics.

Jon

Jon,

Can you send the link to the thread you mentioned?

Thanks,

Leo

I am implementing QoS on our MPLS network. Our environment exists of a  mix of Cisco 3750 and 3560 switches. The IPT system is Avaya CM with  Avaya phones.

The WAN network is a MPLS network.

Ports are configured for access and voice vlan (no trunking), one vlan for voice, one for data (vlan 1 is disabled).

Please can you advise how you are using voice vlan with avaya phones without using trunking and native vlans like we have setup. Do you need to make adjustments to the 46xxxsettings.txt file or are you using LLDP?

Thanks

Hi Jon,

I think the link says it all, one can not use autoqos trust and service-policy at the same time. I think Andy Butterworth is correct in his assumption it has never worked but still showed in previous version. I am running a previous version and saw the trust stayed in but as soon as I tried to configure it to trust dscp instead of the default cos, it removed the service-policy.

That said, I think the service-policy I listed out should do the trick, right? I agree the default-class should not be hit unless for layer2 traffic. Other then that comment, do you agree the service-policy is correct?

Thanks for your replies so far :-)

Leo

Leo

Yep, clever bloke Andy, i worked with him on a project in the UK.

I think you're right in what you say. The service-policy should apply all the correct markings and with the "permit ip any any" it is generic enough to be applied throughout your network.

Good luck with the deployment, let me know how it goes.

Jon

Ok then Jon, I woud have to say thank you and Andy. Gave you guys both proper credit ;-)

Only thing I want to look at in addition is to see if I can match on voice vlan for the voice classes, next to the match on the dscp markings, as that would ensure data vlan would not respect any markings.

I'll play with it, I marked the thread as resolved as I believe the thread contains good answers and a resolution. Once I completed my config, I'll post it back to this thread to share with the community.

Thanks again,

Leo

Jon,

I have tested the service-policy in the test environment and it does exactly what it needs to do. I ended up with the following config.

ip access-list extended vlan-data

permit ip any any

ip access-list extended vlan-voice

permit ip

!

class-map match-all vlan-voice-rdp

match ip dscp ef

class-map match-all vlan-voice-signaling

match access-group name vlan-voice

class-map match-all vlan-data

match access-group name vlan-data

!

policy-map ipphone

class vlan-voice-rdp

set dscp ef

class vlan-voice-signaling

set dscp af31

class vlan-data

set dscp af21

interface for PBX system and WAN routers

mls qos trust dscp

auto qos voip trust

interface for IPphone+PC

service-policy input ipphone

Current config on those switches.

!

mls qos map policed-dscp 0 24 to 8

mls qos map cos-dscp 0 8 16 24 34 46 48 56

mls qos srr-queue input bandwidth 90 10

mls qos srr-queue input threshold 1 8 16

mls qos srr-queue input threshold 2 34 66

mls qos srr-queue input buffers 67 33

mls qos srr-queue input cos-map queue 1 threshold 2 1

mls qos srr-queue input cos-map queue 1 threshold 3 0

mls qos srr-queue input cos-map queue 2 threshold 1 2

mls qos srr-queue input cos-map queue 2 threshold 2 4 6 7

mls qos srr-queue input cos-map queue 2 threshold 3 3 5

mls qos srr-queue input dscp-map queue 1 threshold 2 9 10 11 12 13 14 15

mls qos srr-queue input dscp-map queue 1 threshold 3 0 1 2 3 4 5 6 7

mls qos srr-queue input dscp-map queue 1 threshold 3 32

mls qos srr-queue input dscp-map queue 2 threshold 1 16 17 18 19 20 21 22 23

mls qos srr-queue input dscp-map queue 2 threshold 2 33 34 35 36 37 38 39 48

mls qos srr-queue input dscp-map queue 2 threshold 2 49 50 51 52 53 54 55 56

mls qos srr-queue input dscp-map queue 2 threshold 2 57 58 59 60 61 62 63

mls qos srr-queue input dscp-map queue 2 threshold 3 24 25 26 27 28 29 30 31

mls qos srr-queue input dscp-map queue 2 threshold 3 40 41 42 43 44 45 46 47

mls qos srr-queue output cos-map queue 1 threshold 3 5

mls qos srr-queue output cos-map queue 2 threshold 3 3 6 7

mls qos srr-queue output cos-map queue 3 threshold 3 2 4

mls qos srr-queue output cos-map queue 4 threshold 2 1

mls qos srr-queue output cos-map queue 4 threshold 3 0

mls qos srr-queue output dscp-map queue 1 threshold 3 40 41 42 43 44 45 46 47

mls qos srr-queue output dscp-map queue 2 threshold 3 24 25 26 27 28 29 30 31

mls qos srr-queue output dscp-map queue 2 threshold 3 48 49 50 51 52 53 54 55

mls qos srr-queue output dscp-map queue 2 threshold 3 56 57 58 59 60 61 62 63

mls qos srr-queue output dscp-map queue 3 threshold 3 16 17 18 19 20 21 22 23

mls qos srr-queue output dscp-map queue 3 threshold 3 32 33 34 35 36 37 38 39

mls qos srr-queue output dscp-map queue 4 threshold 1 8

mls qos srr-queue output dscp-map queue 4 threshold 2 9 10 11 12 13 14 15

mls qos srr-queue output dscp-map queue 4 threshold 3 0 1 2 3 4 5 6 7

mls qos queue-set output 1 threshold 1 138 138 92 138

mls qos queue-set output 1 threshold 2 138 138 92 400

mls qos queue-set output 1 threshold 3 36 77 100 318

mls qos queue-set output 1 threshold 4 20 50 67 400

mls qos queue-set output 2 threshold 1 149 149 100 149

mls qos queue-set output 2 threshold 2 118 118 100 235

mls qos queue-set output 2 threshold 3 41 68 100 272

mls qos queue-set output 2 threshold 4 42 72 100 242

mls qos queue-set output 1 buffers 10 10 26 54

mls qos queue-set output 2 buffers 16 6 17 61

mls qos

IPphone+PC interfaces

switchport access vlan

switchport voice vlan

srr-queue bandwidth share 10 10 60 20

srr-queue bandwidth shape 10 0 0 0

priority-queue out

mls qos trust dscp

auto qos voip trust

!

What would be the recommended steps for changing this into the dscp markings?

Thanks in advance.

Leo

Review Cisco Networking for a $25 gift card