Frame-Relay QOS

[kchannels]

I am trying to prioritize voice traffic between 3 sites and everything I try only seems to make things worse for both data and voice, can somebody point me in the right diretion?

Each site has a Full T1 with a 768 CIR.

The main site has two DLCI's one to each remote site. Each remote site only has a single DLCI back to the main site.

On all 3 routers I have added this:

class-map match-all voice-signaling

match dscp af41

class-map match-all voice-traffic

match dscp ef

policy-map voice-policy

class voice-signaling

bandwidth 8

class voice-traffic

priority 128

class class-default

fair queue

Each routers S1/0 interface is:

bandwidth 768

no ip address

encapsulation frame-relay

no ip mroute-cache

no fair-queue

frame-relay traffic-shaping

On both sub interfaces on the main site router and the sub interface on each remote site I have:

bandwidth 768 (not sure if I should be using 384 or not since I physically only have 1 T1 at the main site connected to the 2 remote sites???)

for each frame-relay interface-dlci xx command I have:

class VOIPovFR

finally each router has:

map-class frame-relay VOIPovFR

no frame-relay adaptive-shaping

frame-relay cir 768000

frame-relay bc 640

frame-relay be 0

frame-relay mincir 768000

service-policy output voice-policy

if I do a show policy-map interface command I do show packets in the voice signaling and traffic priority queue so know the data is being put in the correct queue it's just that the time to copy a file from site to site has doubled (assuming that's related to not using any of the burst area of the T1 now by using the 768 CIR instead of teh old 1544) and voice sounds OK one minute and terrible the next...

I got all these commands from the Cisco article "VOIP over Frame-Relay with Quality of Service..."

Finally, this is an Avaya phone system

[paolo bevilacqua]

yes, the doubled copy time is because you have cofigured a CIR that is half of the access speed. How many voice class are you sendi g?Can you take a show policy-map interface on both routers, at the time the voice quality is bad?

[kchannels]

From what I read on Cisco's recommendations even though the access speed is the 1544 I should use the bandwidth and cir settings to restrict the use of the line to the 768 CIR though to ensure reliability, do you agree with that part?

I just called one of the remote offices and talked for awhile, after a few minutes it got bad and then started sounding OK again, at the end of the conversation I had this result on the remote router, during the call as I ran the policy-map I saw the drop rate on the voice-traffic hit 19200 bps.

Class-map: voice-traffic (match-all)

41266 packets, 8410912 bytes

5 minute offered rate 169000 bps, drop rate 0 bps

Match: ip dscp ef

Queueing

Strict Priority

Output Queue: Conversation 72

Bandwidth 128 (kbps) Burst 3200 (Bytes)

(pkts matched/bytes matched) 19706/4016064

(total drops/bytes drops) 2297/468488

Class-map: class-default (match-any)

37529 packets, 45208068 bytes

5 minute offered rate 319000 bps, drop rate 0 bps

Match: any

Queueing

Flow Based Fair Queueing

Maximum Number of Hashed Queues 64

(total queued/total drops/no-buffer drops) 0/0/0

Not sure what you mean when you say, "How many voice class are you sending?" ?

Another thing is Avaya is going to switch us from G.711 to G.729 later today as well. On that note, if were using 711 and two calls happen, that will eat up my 128K PQ correct?

[paolo bevilacqua]

Hi,

the issue with CIR is a double sworded issue. if you set CIR and shaping, you are in theory guaranteed that all you traffic will go through, but you will loose bandwidth. This is why often times, when the FR network is performant and permissive, you can renounce setting CIR and shaping at all.

Now for your issue, the voice traffic was way in excess of the configured 128 Kbps so you got drops from the priority queue and the bad quality. You need need to set enough bandwidth in the PQ for as many simultaneous calls (I mispelled as "class", sorry) you will have, considering the codec used. If they are changing that, wait until they are done then configure accordingly.

One thing you can do to improve the bandwidth usage, is header compression for RTP. Search "configuring crtp on frame-relay" on CCO for examples.

Hope this helps, please rate post if it does!

[kchannels]

That's the way I saw it, I had to give up my ability to burst above the CIR in order to get good voice performance.

The documentation I had from Cisco did have the command to compress the RTP but it also cautioned against using it as it can cause high CPU utilization? I figured I would start without and and add it at the end and see how it worked out.

The good news on giving up the bandwidth is we're now looking to switch from FR to MPLS.

The avaya engineer should be here any minute, will let you know how it works out. Thanks for the help!

[kchannels]

OK, we've now got all 3 locations setup with 256KB priority queues and I see no more drops however voice traffic is still bad at times(but much better than it used to be). Now we need to look at the switches I guess. Even on calls made out a local trunk on a phone attached to the same switch as the Avaya equipment we have issues.

The switches at the main office are WS-C2950T-24's running IOS 12.1(13)EA1. The switches at the remote offices are WS-C2950-24's running IOS 12.1(13)EA1. Only voice equipment and phones are utilizing these switches, the computer data network is seperated via physical nics on router.

The config changes made in an attempt to prioritize the traffic is:

wrr-queue bandwidth 10 20 70 0

wrr-queue cos-map 1 0 1

wrr-queue cos-map 2 2 3

wrr-queue cos-map 3 4

wrr-queue cos-map 4 5 6 7

then on each switch port we added:

mls qos trust cos pass-through dscp

What am I missing?

[paolo bevilacqua]

Hi, be reassured (beers on me if I'm wrong) that switches play no part in voice quality, and no matter how you configure them, there will be no changes in voice quality.

[kchannels]

But if QOS is wrong or not working correctly then wouldn't you have issues? I know that with no traffic but voice on the switches in this case it shouldn't really matter whether it's implemented or not but the Avaya guys are going to point the problem finger at me until I get it setup "correctly". What would be causing the voice issues in my case if it's not the switch?

[paolo bevilacqua]

The WAN circuits are causing the issues.

You need to:

1st, check that any and all packet sent is received on FR PVC. To do this, compare output to input counters of "show frame-relay pvc XX", onte the PVC ends, at intervals. Do clear counters if possible.

2nd, check that any and all voice packet is correctly marked as such, and treated with priority by the QoS configuration. Begin checking "show policy-map interface".

[kchannels]

The WAN is not used on a call in/out a local trunk and those calls are having issues though...

[paolo bevilacqua]

Then I'm not sure of the call flow, would you explain it in detail ?

[kchannels]

See attached...

Exampe: If a call is made to/from a phone connected to one of the switches on the ELK2950-1 or -2 to a local trunk (attached to the G700) the calls sometimes have quality issues. The voip traffic would only be touching the G700, the 2950 switch and the phone, it would never cross the router in this case.

That help?

[paolo bevilacqua]

"sometime" how often ? If quite often or if you can find a way to reproduce it, you can again take some show interface and show controller on the interested ports at the time it happens.

Also check usage on the trunk between switches, I think the 2950 have no gigabit and if someone is doing copies at the time of the calls up to make it congested, here one rare case when you need QoS on the switches.

Also ask the phone vendor if they have statistics like cisco phone have, that tells you explicitly that packets are lost or delayed causing quality issues.

[kchannels]

Not sure on the "sometimes", that's all I've been told, will have to find out more.

The 2950T's do have 2 gig ports at the main office, users doing copies are not an issue as they are on their own switches separated from the voice network via the router.