QOS Trouble and questions

[bhatti.imran]

Hi All,

I have some trouble regarding the QOS implementation for the VOICE communication.

I tried to setup the low latency queuing but it showed that it is weighted fair

queuing.

I want to apply the strict policy ( reserved the bandwidth) of 128 k for voice.

After this configuration my voice is still not good ( choppy).

Attached below is my configuration file.

Tunnel0 is the outgoing interface and i applied the service policy on ethernet interface. ( e0/0)

Below is the output of show policy-map interface

Ethernet0/0

Service-policy output: LL_QOS

Class-map: VOICE_CONTROL (match-all)

34 packets, 3666 bytes

30 second offered rate 0 bps, drop rate 0 bps

Match: access-group name VOICE-CTL_ACL

Weighted Fair Queueing

Output Queue: Conversation 265

Bandwidth 64 (kbps) Max Threshold 64 (packets)

(pkts matched/bytes matched) 3/534

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

QoS Set

ip precedence 5

Packets marked 34

Class-map: VOICE_RTP (match-all)

1257257 packets, 160414006 bytes

30 second offered rate 0 bps, drop rate 0 bps

Match: access-group name VOICE-RTP_ACL

Weighted Fair Queueing

Strict Priority

Output Queue: Conversation 264

Bandwidth 128 (kbps) Burst 4800 (Bytes)

(pkts matched/bytes matched) 773/110734

(total drops/bytes drops) 0/0

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

4356827 packets, 3116756548 bytes

30 second offered rate 63000 bps, drop rate 0 bps

Match: any

Weighted Fair Queueing

Flow Based Fair Queueing

Maximum Number of Hashed Queues 256

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

It shows that Queuing strategy is still weighted fair , whereas it should be CBWFQ or LLQ.

Can some body help me that where i am doing mistake.

Similar type of configuration is on remote side router.

[Joseph W. Doherty]

Your stats also note "Strict Priority" for your VOICE_RTP class. Don't believe the "Weighted Fair Queueing" indicates just FQ, believe it indicates LLQ within CBWFQ.

However, notice only 773 voice packets matched out of a total of 1,257,257. This should indicate very little congestion on the Ethernet0/0 interface.

Do all other network devices, if any, along the tunnel's path expedite your voice packets based on their precedence marking?

[bhatti.imran]

Mr. Joseph,

Thanks for your reply

I am feeling that line quality is not so good also as some icmp drops observed.

may be this is the reason that we are not getting the good voice quality , please suggest.

Yes i am trying to enhance VOice quality by marking the precedence .

could you suggest me the better method for the good voice quality.

Thanks

[Joseph W. Doherty]

Could you explain further "ICMP drops".

What you're doing, marking your VoIP packets so they can be expedited first is correct procedure. Using LLQ within CBWFQ is one of three ways that comes to my mind to accomplish this. Also marking the control traffic to insure it's guaranteed bandwidth is proper too. (Note, since you're using GRE, the FQ within the default class would see all GRE traffic as one flow except where you mark the GRE packets differently.)

Why are you using a GRE tunnel? I wonder if the overhead of using GRE is impacting your voice performance. (I've never tried voice across a tunnel.) I see you're adjusting MSS, which helps avoid GRE fragmentation for TCP packets. Do you have any max size non-TCP packets using the tunnel?

You do have to insure that similar treatment, the prioritization, is given all along the path; both directions. Just doing it once, unless there are no intermediate hops, doesn't insure quality. If this is the purpose of the tunnel, to avoid intermediate hops having QoS, isn't enough.

[pranabgaya]

u didnt mention about the codec and payload size .

take the following logs and post.

"sh call act voi brief "

"sh voide dsp " when u place a call.

its important to note the delay and jitter , may be u require to adjust the de-jitter buffer.

[bhatti.imran]

Hi all,

Thanks every body for reply.

Purpose of GRE tunnel is to avoid the intermediate hops.

Below are the out put of some voice related commands for codec and payload etc.

sh call act voi brief

Telephony call-legs: 1

SIP call-legs: 0

H323 call-legs: 1

Total call-legs: 2

12CB : 692504155hs.1 +1336 pid:20001 Answer 21002 active

dur 00:14:26 tx:44010/880200 rx:43301/866020

IP 172.2.2.6:19080 rtt:216ms pl:785620/40390ms lost:24/1290/1898 delay:210/69/2

10ms g729r8

12CB : 692504156hs.1 +1335 pid:10001 Originate 42001 active

dur 00:14:26 tx:43301/866020 rx:44010/880200

Tele 1/0/0 (6031): tx:880210/88021/0ms g729r8 noise:0 acom:45 i/0:-11/-59 dBm

Telephony call-legs: 1

SIP call-legs: 0

H323 call-legs: 1

Total call-legs: 2

sh voice dsp

DSP DSP DSPWARE CURR BOOT PAK TX/RX

TYPE NUM CH CODEC VERSION STATE STATE RST AI VOICEPORT TS ABORT PACK COUNT

==== === == ======== ======= ===== ======= === == ========= == ===== ===========

=

C5423 001 01 g729r8 3.6.15 busy idle 0 0 1/0/0 NA 0 1949079/191267

C5428 002 01 g729r8 3.6.15 IDLE idle 0 0 1/0/1 NA 0 1307457/129 438

Thanks and waiting for help.

[Joseph W. Doherty]

The GRE tunnel makes it logically look like there are no intermediate hops, but if there are any physically, you still need to do QoS at each hop.