frame-relay LLQ configuration doesn't work for Voip

Unanswered Question
Jan 31st, 2007

Dear all,

I am trying to implement QoS in a frame relay connection, i am configuring on the side where the jam occurs. But i could not see any improvement in the quality. what may be wrong ? Below there is my configuration:

class-map match-all voice-traffic

match access-group 106

class-map match-all voice-signalling

match access-group 107

policy-map VOIPLLQ

class voice-traffic

priority 100

class voice-signalling

bandwidth 32

class class-default

fair-queue

interface Serial0/0

bandwidth 512

no ip address

no ip unreachables

service-policy output VOIPLLQ

encapsulation frame-relay

no ip mroute-cache

load-interval 30

frame-relay class VOIPCLASS

frame-relay lmi-type ansi

!

interface Serial0/0.1 point-to-point

description connected to Internet

bandwidth 512

ip address xxx.xxx.xxx.xxx

ip accounting output-packets

ip nat outside

no ip mroute-cache

frame-relay interface-dlci 206

class VOIPCLASS

!

map-class frame-relay VOIPCLASS

frame-relay cir 512000

frame-relay bc 5120

frame-relay mincir 512000

frame-relay fragment 50

service-policy output VOIPLLQ

!

access-list 106 permit udp any any eq 16384

access-list 107 permit tcp any any eq 5060

access-list 107 permit udp any any eq 5060

Best

Regards,

Deniz

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
mheusinger Wed, 01/31/2007 - 00:15

Hello Deniz,

your classification seems not complete. VoIP uses dynamically assigned UDP port numbers, which MIGHT be the port 16384, which your ACL matches. If this port is not chosen, then your VoIP traffic will be treated with best effort.

My first suggestion is to change the voip classification

ip cef

class-map match-all voice-traffic

match protocol rtp audio

This will use NBAR to classify the VoIP traffic, which usually works best.

Second, your Serial interface does not have to use the service policy, so second suggestion:

interface Serial0/0

bandwidth 512

no ip address

no ip unreachables

encapsulation frame-relay

no ip mroute-cache

load-interval 30

frame-relay lmi-type ansi

Last, your "signaling ACL" describes SIP only. Make sure this is, what you have in use or modify it to reflect your signaling protocol.

You can check the operational policy with "show policy-map interface". You should see matches in the VoIP class, IF an overload situation occurs.

Hope this helps! Please use the rating system.

Regards, Martin

denizpecel Wed, 01/31/2007 - 00:27

Dear Martin

Thanks for your fast response!! I have configured "match protocol rtp audio " but no change in the voice quality. Actually i am using Cisco ATA behind the router so i am sure about that cisco uses 16384 udp as voice port. Also i get the sh policy int output below:

Router#sh policy-map interface

Serial0/0

Service-policy output: VOIPLLQ

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

6133 packets, 711428 bytes

30 second offered rate 5000 bps, drop rate 0 bps

Match: protocol rtp audio

Queueing

Strict Priority

Output Queue: Conversation 136

Bandwidth 100 (kbps) Burst 2500 (Bytes)

(pkts matched/bytes matched) 1014/117624

(total drops/bytes drops) 0/0

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

1999 packets, 838653 bytes

30 second offered rate 0 bps, drop rate 0 bps

Match: access-group 107

Queueing

Output Queue: Conversation 137

Bandwidth 32 (kbps) Max Threshold 64 (packets)

(pkts matched/bytes matched) 270/121000

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

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

4631510 packets, 2266370452 bytes

30 second offered rate 666000 bps, drop rate 0 bps

Match: any

Queueing

Flow Based Fair Queueing

Maximum Number of Hashed Queues 128

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

Any other suggestions?

Best Regards,

mheusinger Wed, 01/31/2007 - 00:34

Hello,

the show output prooves, that VoIP is treated properly on this interface. So the question is, which other possible choke points are present in the network. This includes the LAN access ports and trunk ports in your network. The quickest approach would be "auto qos voip" on all ports VoIp traffic is crossing.

Second, Poor Voice quality does not always result from the network. So the choice of codec, handset and so on might also influence voice quality. What exactly do you mean by poor voice quality? Is it the same on both ends or unidirectional?

Regards, Martin

denizpecel Wed, 01/31/2007 - 00:55

I do not have Auto Qos in my ioses they are 12.3 and 12.2. The quality is poor in the sense that packets are lost or like orders changed. It appears on the remote end, unidirectional. That is to say; there are two sides, my side and customer side. customer hears well but i didn't so i am configuring customers router for upload traffic, actually as i see from mrtg graphs they are uploading by using all of the bandwitdh, i think they may be infected by virus etc. But i think still QoS must work under this circumstances, doesn't it?

Best Regards,

Deniz

denizpecel Wed, 01/31/2007 - 00:57

And there are no other points in the network, having jam. it is a point to point test.

VPMaharaj Wed, 01/31/2007 - 03:51

Hi Deniz,

You have to first classify voice traffic which you have done. VOIP uses udp ports 16384 - 32767 or preferably classify via NBAR as Martin has suggested. Then identify what signalling you are using. There is no harm in classifying and prioritising voip signalling ports - 1718, 1720, 1719 just incase your system is using this. Your FR bc of 5120 appears to be correct as this would give you an FR tc period of 10 ms which is the recommended value by Cisco and so is the mincir setting. The other thing that you can do is mark the traffic if there are any intervening devices that are dscp aware. Voice is marked as EF and voice signalling is marked as AF31 if I remember correctly and this has to agree with the provider marking scheme. This is so that intervening DSCP aware devices can prioritise your traffic properly however it depends on how your wan is and prioritisation/qos kicks in if the link is congested. Also do a sh frame-relay pvc and see if you see any drops etc plus enable frame-relay traffic shaping under the serial0/0 interface to 512k and check with the cust if they are classifying, prioritising properly. If you cannot hear them then maybe they are not classifying/marking properly and lastly disable VAD at all ends.

mheusinger Wed, 01/31/2007 - 03:15

The problem might be in the customer LAN. If a LAN switch is not configured for QoS then packets could be dropped there. Once a packet is dropped, from a voip perspective it is absolutely irrelevant, where a packet is dropped or delayed.

You cannot solve this problem without looking at the complete picture.

If they are infected with a virus/worm, then even LAN access ports might be overloaded and are causing the poor voice quality.

Your WAN config looks good to me and there are no evident problems on this side.

Eventually also check with the frame-relay provider, who might overbook his network and eventually drop your traffic.

Regards, Martin

Actions

This Discussion