Solved: Qos on Cisco 2610 with ISO 13.3(26)

eweber1234 · ‎08-26-2009

I have now connected two of our office branches with a bundle of two T1 configured in MLPPP mode. I have data and voice going across and in normal circumstances everything works just fine but when there is a heavy traffic ( like when the backup is running and pulling data across) the voice part start struggling and employees complain about a goggling in the voice. I have come to the conclusion that there must be something wrong with my configuration for prioritizing the voice packets over data. I really appreciate if anyone could give a look at the attached configuration and comment on current configuration or suggest a different solution.

Thank you,

Joseph W. Doherty · ‎08-31-2009

The policy, itself, basically looks alright, although the bandwidth allocation for voice signaling might be too little.

In execution, you didn't match any voice signaling packets, but since you're running FQ in class-default, you probably don't need a defined class for this traffic.

What is of much concern with your policy stats, is the deep queue within class-default and the number of drops (21%).

What you might try, remove both header compression statements from the multilink interface.

View solution in original post

simontibbitts · ‎08-28-2009

Hello,

Your config looks ok so far. You have priority queuing enabled and the only drops are in the normal and low queues. I would like to know the following:

1) Is this the only link that could be causing the congestion? Do you have QoS configured end to end?

2) Are you certain that all traffic is correctly marked with the csX values you are using in your access-list? Normally voice payload traffic is marked with EF. So your ACL that matches only CS5 will not match this. What device is doing the classification?

Kind Regards

Simon

simontibbitts · ‎08-28-2009

Also - please paste a 'show access-list' it might tell us whether you are correctly matching the traffic or not.

Simon

eweber1234 · ‎08-28-2009

Simon,

Thanks for looking into this, very appreciate your help

Question 1) Yes, Yes

Question 2) about being certain for marking all the traffics- No i'm not sure, do you know a way for me to find that out? I'm open to anything. Also, what do you mean by "what device is doing the classification" I'm not sure what you are asking for!!!

Asscess Lists:

Main_to_Ells#show access-lists

Standard IP access list 1

10 permit 10.1.1.0, wildcard bits 0.0.0.255

Extended IP access list 100

10 permit ip any any dscp cs7

Extended IP access list 101

10 permit ip any any dscp cs6 (379992 matches)

Extended IP access list 102

10 permit ip any any dscp cs5 (683 matches)

20 permit udp any any range 16384 32776

Extended IP access list 103

10 permit ip any any dscp cs4

Extended IP access list 104

10 permit ip any any dscp cs3

Extended IP access list 105

10 permit ip any any dscp cs2

Extended IP access list 106

10 permit ip any any dscp cs1 (1 match)

Extended IP access list 107

10 permit ip any any dscp default (30131683 matches)

Main_to_Ells#

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

Ellsworth-R#show access-lists

Extended IP access list 100

10 permit ip any any dscp cs7

Extended IP access list 101

10 permit ip any any dscp cs6 (120381 matches)

Extended IP access list 102

10 permit ip any any dscp cs5 (8 matches)

Extended IP access list 103

10 permit ip any any dscp cs4

Extended IP access list 104

10 permit ip any any dscp cs3

Extended IP access list 105

10 permit ip any any dscp cs2

Extended IP access list 106

10 permit ip any any dscp cs1

Extended IP access list 107

10 permit ip any any dscp default (4911986 matches)

Ellsworth-R#

simontibbitts · ‎08-31-2009

Hello.

I think you might have a problem with your classification. By this I mean that your traffic is not being marked with the correct DSCP value or specifying cs5 for voice is incorrect.

My question 'What is doing the classification' basically means what devices are marking the packets with the DSCP values? Is it the switch that is doing the classification or do you have your IP phones setting the DSCP value? If we can find this out then we can see what DSCP value is being set for voice payload.

In the 'show access-list' you have pasted we can see how many matches each line gets. On the router 'Ellsworth' you can see you only have 8 packet matches for cs5. This indicates our problem as 1 single voice call will be way more than 8 packets alone.

So to continue I would try the following:

1) Try and find out what is classifying the voice traffic and what is it classifying it with?

2) The normal DSCP value for voice payload is EF. You could try the following: i) adding the line 'access-list 102 permit ip any any dscp ef' to both routers ii) Make a voice call across the link iii) Then check the 'show access-list' command again to see if matches are shown against the new line.

Simon

Joseph W. Doherty · ‎08-31-2009

You might want to consider the information I provided in my post to your other (duplicate?) post. See: http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40.2cd4691f/6#selected_message

eweber1234 · ‎08-31-2009

Joseph,

Thank you very much for your persistent to help, I have decided to move on into the new way of managing voice over IP and you recommended. I have attached one router configuration with using LLQ. There is a problem with the configuration because as soon as I put the router in production it works for about a minute or two and then nothing goes through. Could you or any one give a look and comment on it please. I have a feeling that I am very close.

P.S. I'm sure that our phone server ( Toshiba CTX 100)is the voice packets but Is it DSCP or DSCP EF or something else I don't know at this point; may be its better for me to prioritize the packets base on the host IP.

Thank you,

Joseph W. Doherty · ‎08-31-2009

The policy, itself, basically looks alright, although the bandwidth allocation for voice signaling might be too little.

In execution, you didn't match any voice signaling packets, but since you're running FQ in class-default, you probably don't need a defined class for this traffic.

What is of much concern with your policy stats, is the deep queue within class-default and the number of drops (21%).

What you might try, remove both header compression statements from the multilink interface.

eweber1234 · ‎09-01-2009

Thanks for all of you help.

Best regards,

E.