01-31-2007 12:02 AM - edited 03-03-2019 03:34 PM
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
01-31-2007 12:15 AM
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
01-31-2007 12:27 AM
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,
01-31-2007 12:34 AM
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
01-31-2007 12:55 AM
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
01-31-2007 12:57 AM
And there are no other points in the network, having jam. it is a point to point test.
01-31-2007 03:51 AM
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.
01-31-2007 03:15 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide