Qos Question - I'm stumped.

[heathersuzanne]

Hi Everyone,

This might be a new one for you all...

We want to enable QoS on our MPLS network in a different way than Ive seen in all the Avaya docs. All the Avaya docs I see clearly state that we need to put specific configurations (markings) on certain devices (MedPro's, IpsI's, Nettwork Regions....etc). so that when voice packets are tagges with the right information, the Data network recognizes that its a voice packet and puts it to the 'front of the line' and prioritizes it right for transmission.

Is there a way to do this differently - without trusting the markings on the packets as the identifier that its a priority packet? If we wanted to do this in a giant access list, via IP address recognition only, can we do that? If so, how do I know which IP addresses we need to map? Lets say a IP phone goes off hook in one country and tries to call another IP phone in another country, but both phones are connected to the same processor. What IP addresses would we be seeing traverse the network and would therefore require inclusion in the Access list? Any clues? I'm stumped on how to ensure that I'm including the correct IP's (since there's a million IP addressed components)so that the call is prioritized correctly - withouut trusting any markings. I have no tools to help me do this. Thanks.

Other background: regional S8700 instances serving all countries in the region (hub and spoke, FCE, however you like to classify it). Mix of Gateway types including G650's. Regionalized Mod Mess (MSS/MAS) and CMS as well.

 

[Tolson]

If you are not going to trust the markings, they you are going to need to include all of the IP addresses that can send the voice portion of the call. the would include any IP telephone set, the medpros, G450 addresses.

 

[latitude12]

From a general perspective you'll need two lists - one for voice traffic (phones, medpros, H248 gateways) and one for signalling traffic (servers, IPSIs, CLANs, phones, H248 gateways). This will allow you to use different priorities for the different traffic types. The problem for you is that some devices (e.g. phones) will be on both lists, so you'll need to discriminate based on the port used. So your starting point is to define all the device IP ranges and the ports used in your environment.

 

[heathersuzanne]

Thank you both for the replies!!!!

So let me ask this - is it safe to say that if I have an ip addressed component, it neds to be set up for Qos and the IP address needs to be reflected in an access list?

I have a list of all IPSIS, Gateways, Default Gateways, Medpro's, Phone IP ranges, CLAN's and Processor interfaces. Do ALL of these components talk over the WAN and therefore need QOS, or just some of them?

What about adjuncts like AES, Session Manager, Call recorders etc? Those are all IP addressed -- to they also need to be included?

Thanks everyone!!

 

[rejackson]

This is how we do it. we do not trust the device markings as they go through a router. the layer 2 COS settings inside an IP subnet are left alone but the layer 3 QOS are all reset as they exit the WAN routers toward the WAN based on an access lists. Your voice traffic should be in separate vlans with unique IP scopes from data so it isnt hard.

This is typical of one site

make your access lists

access-list 101 remark traffic from this sites voice subnet
access-list 101 permit ip 10.n.31.0 0.0.0.255 any
access-list 102 remark Video and routing protocol traffic
access-list 102 permit ip host 10.1.226.236 any
access-list 102 permit eigrp any any
access-list 103 remark interactive traffic to central services
access-list 103 permit ip host 10.1.1.20 any

set up class maps that match packets using the access-lists

class-map match-all video-class
match access-group 102
class-map match-all voice-class
match access-group 121
class-map match-all user-class
match access-group 103

set up policy maps that use the classes to assign priority and bandwidth to the different types of traffic. There are three classes widththe assign vlaues and a fourth default class. The percentages shold match what the provider is using and can change with wach site if the bandwidth is different. Our interface if just serial IP but the provider uses MPLS in their network and only wants 4 classes.

policy-map profile1
class class1
priority percent 7
set ip precedence 5
class class2
bandwidth percent 30
set ip precedence 3
class class3
bandwidth percent 38
set ip precedence 2
class class-default
set ip precedence 0

assign the service policy to the WAN interface outbound.

interface Serial1/0
ip address n.n.n.n 255.255.255.252
service-policy output profile1

 

[mattKnight]

To be honest, you would be much better trusting the edge devices as unless you push QoS to the host edge you will be able to prioritise traffic on internal devices.

But I'd suggest that you classify by traffic type rather than source address - perfectly possible in a Cisco network environment (can't be 100% sure about other technologies, but I'd strongly expect so)

i.e. TCP 1720, UDP 1718, UDP/TCP 5060, TCP 5061 --> call control --> DSCP 24 / CS3

UDP port range x to y --> Media streams --> DSCP 46 (not idea; as you might get some UDP streams promoted when they shouldn't be)

Again, while it seems like a mountain to climb, having the IP phones and other infrastructure mark their traffic appropriately is not difficult and quick, ensuring those marks are preserved across the L3 boundaries is easy too (time consuming though)

Which MPLS carrier are you using? I'd also make sure you understand how the policing of the EF works across the MPLS. We have to purchase an EF CAR from our carriers that is policed on the carriers' PE - so if we go over that amount EF gets dropped and it all turns very horrid very quickly! Police our outbound EF at very slightly below the EF CAR so that we can track if our device drops the traffic as we have no visibility of the carrier dropping traffic...

Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

 

[heathersuzanne]

Thanks Everyone!

Hi Matt,

Im not sure what you meant about trusting the edge devices... I would like for the the network team to trust the marks they are receiving from our gear(All of our Avaya gear is already set up for QoS and sending the markings), but they don't what to do this.

But what about the suggestion you had about traffic type? That sounds interesting - my question would be though if the traffic types (such as the ones you listed) are used by anything other than Avaya? For example - would a polycom video unit use those, or Microsoft Office Communicator voice calls, or any other device/application that carries voice? Because then in theory I think a video call could use up the Gold CAR, when we dont want it to use the BW we are trying to reserve for Avaya voice...

The way that they would like to do this is to have a list of all of our Source and Destination IP's and Ports and Devices that require EF for its communications. That makes me think that I need to just send them a list of every IP address on every peice of Avaya gear I have (ie, Medpro's, CLAN's, Gatweway IP's, Procr, IPSI's, Phones, Call recorders, and so on...) since I think that all voice needs to be prioritized. I can send a list of IP's (a daunting task and it will be one heck of an access list) but I dont think getting the specific ports will be that easy.

Thoughts? Have you ever heard of doing it this way?
Thanks!
HeatherSue

 

[mattKnight]

Hi,

>Im not sure what you meant about trusting the edge devices... I would like for the the network team to trust the marks they are receiving from our gear(All of our Avaya gear is already set up for QoS and sending the markings), but they don't what to do this.
I think we mean the same thing!

Do your network team have a reason for not trusting the phones or infrastructure devices' markings? We run all of our voice & video in this way and it allows us to put media traffic in the priority queues at the switching layers (admittedly, we do use the inbuilt switch in out handsets so that both laptop and handset share a switch port). It seems to me that that network team are trying to only implement QoS over the MPLS cloud rather than end to end.

Using traffic type ACL to mark traffic is possible, but it will mean that any traffic using, for example, UDP 2048 to 3338 would be marked as EF regardless of source/destination IP address and use your Gold CAR. If you have an extensive set of non-Avaya infrastructure, this may not be best , as you've already identified.

I'm not a fan of marking traffic according to IP address (either source or destination) as you can and will end up with undesired results. For example, management traffic to and from your avaya devices (CMS, AES, ACM web screens, SAT etc) will probably be marked as EF because they target or are sourced from something that matches the ACL! - if you have an EF congestion issue - you will find management of remote devices very hard (all your management traffic being dropped!). The other issue that you will need to address is softphones, which will inevitable occupy the same IP range as your LAN (and RAS) hosts. The whole point of trusting the voice devices' markings is that these markings a clear and unambiguous against using either the "what IP address does it come from" or "what TCP/UDP ports does it use"

>Have you ever heard of doing it this way?

The US arm of my employer use this strategy for traffic marking - so it does work (but I'd rather not say more).
In reality we (EMEA) use a mix of these strategies - *all* voice and video traffic is marked by the Phone / VC unit / Infrastructure device and this is trusted from the LAN edge to the remote LAN wedge. All our LAN traffic traversing sites (that is unmarked) is then categorised by traffic type (i.e. which TCP/UDP port) and appropriately marked at egress to the WAN. We do also uses IP address ranges for some marking for some special applications that are core to our operation - but these ranges are well known and tightly defined

I'd push back on the network team and ask them to justify why trusting host markings at L2 or L3 (COS or DSCP). I suspect that there is some reason (IOS images or core s devices that don't QoS trust or maybe too many ports to reconfigure for example) that means they can't do it and don't want to admit to it However, I'd argue that maintaining the marking ACLs on multiple devices is much more time consuming in the longer term, from a BAU perspective) than applying the correct config across the devices now.

As you can tell, I'm quite an advocate of edge marking...

However, you don't need to give them individual IP addresses - just the network ranges (hopefully all your handsets will be in 1 range per site and all adjuncts in a range of their own)



Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

 

[rejackson]

Our attitude was that is wasnt a problem of trusting the avaya equipment but controlling other devices from using the bandwidth we wanted the avaya equipment to have.

The ip address thing is not that hard. Your voice networks should be unique from your data networks or you already have a problem. The access lists should match on IP network not host. I would guess that the network department assigned those networks so tell them to look at their documentation.

 

[heathersuzanne]

Hi mattknight and rejackson, thank you both for the replies,

rejackson, you are right - they want to make sure our Avaya equipment gets the BW. Our voice network is seperate from our data network, except for one item I can think of - One-X Communicator. That voice application is a true voice/avaya application so we'd want to prioritize it, but the IP address it uses is my PC's IP address. I'm not sure how to deal with this situation. Any ideas?

I'm also thinking that doing it this way creates a mainteance issue, since the ACL would need to keep being modified as we grow and add Avaya equipment, but I guess that's for the datcom team to worry about...

mattknight, I completely agree with you on the undesired results of doing it this way. This is a manual process for me to list out all of the IP's on all of my Avaya equipment since I have no tools handy to collect this info. If I miss an IP address, I dont get the gold car that I need. If I do add an ip address, I may still get unnecessary gold car for things that I dont need to use it for - like managemnt traffic as you mentioned. I know this is not the best way to do it and I would much prefer to go by the Avaya recommendations and use the markings, but its not an option. The concern is that other gear uses the markings (like Cisco voice) and its BW that is set aside only for Avaya. So they want the IP's...

Thanks for all the advice! Its so helpful to bounce ideas and concerns off other people and see what feedback you get Much appreciated!
HeatherSue

 

[mattKnight]

Our voice network is seperate from our data network, except for one item I can think of - One-X Communicator. That voice application is a true voice/avaya application so we'd want to prioritize it, but the IP address it uses is my PC's IP address. I'm not sure how to deal with this situation. Any ideas?

You are knackered here... You can't trust the markings because other things mark similarly, you can't re-mark according to IP because not all IP addresses in that range generate voice traffic and you can't re-mark on traffic type because the traffic types are shared!

May I ask some more questions?

How much of non-avaya voice traffic traverses your MPLS cloud? Is there a reason why the non-avaya traffic is less important than the avaya. In my world, any voice traffic is more important than non-voice traffic (i.e. I don't care about vendor!) Is there a reason why it must not use your gold CAR?
Where I'm going is; - can you simplify the configuration by "adjusting" the specification?

Do you have many non-avaya devices? For example, you could use IP range to demote other voice ranges - if there are fewer....

I would also specify what are your voice device ranges, itemising each device is a route to madness!

I'm intrigued now!

Please don't misunderstand me, what you are doing will work, but I suspect that in time it will become difficult to manage!



Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.