cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
718
Views
5
Helpful
7
Replies

Voice QoS on Cisco

paddy.ofarrell1
Level 1
Level 1

Hi,

I have a Cisco 1921, with 2 x Gig Eth ports (config elements below)

I'm seeing some call quality issues to our VOIP provider and one of the requirements is to implement Voice QoS on the router. I think I have it setup below, but it may not be complete. Is SIP alone in the policy sufficient or should I add RTP?

The uplink is gig eth into a bridge mode router from the ISP (400Mbps fibre connection). 

Internal distribution is through a TP-Link 24 port gig eth switch, running at about 2% utilisation. 

There no heavy graphics/video on the LAN, so traffic levels are quite low, I don't believe the issue is going to be resolved with QoS on the router. But as its on the ticklist of items to check off, then I need to implement it (if even just to rule it out). 

Incidentally, I'm in Ireland, and the VOIP provider is in the UK (VOIP host is 31.221.75.70), I suspect the bottleneck is the UK<->Ireland interconnection(s). 

interface GigabitEthernet0/0.100

description General vLAN
encapsulation dot1Q 100
ip address 192.168.100.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
!
interface GigabitEthernet0/0.105
description Phones vLAN
encapsulation dot1Q 105
ip address 192.168.105.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
!
interface GigabitEthernet0/1
description INTERNET UPLINK
ip address 89.101.97.206 255.255.255.252
ip nat outside
ip virtual-reassembly in
duplex auto
speed auto
service-policy output POLICY-VoiceFirst

and the Policy is defined as:

class-map match-any SIP
match protocol sip
!
policy-map POLICY-VoiceFirst
class SIP
priority percent 25
!

1 Accepted Solution

Accepted Solutions

Hello,

sorry for the delay. Traffic load is low, you have a few input errors and overruns, but since you don't know how long they have been on there, clear the counters on that interface (clear counters interface GigabitEthernet0/1) and check if those counters increase.

As stated before, you are probably right and the bottleneck is somewhere upstream.

View solution in original post

7 Replies 7

Mark Malone
VIP Alumni
VIP Alumni

Hi

You should match EF traffic too for the actual rtp stream , you need to make sure the EF is prioritised , you could  match it by ACL too just example below , both routers should be hit at the very minimum

                                       

class-map match-any PREMIUM_CLASS
 match access-group name PREMIUM_ACL#

ip access-list extended PREMIUM_ACL
 permit ip any any dscp ef

Hello,

'match protocol rtp' should be added as well. That said, with traffic levels being low, as you stated, it is probably not going to help much, since your interface has plenty of bandwidth.

To verify that nothing is dropped on your interface, can you post the output of:

show policy-map interface GigabitEthernet0/1

Thanks Georg,

This is the output of "show policy-map interface GigabitEthernet0/1"

(I'll add the match protocol rtp later this evening)

INTERNET_ROUTER#show policy-map interface GigabitEthernet0/1
GigabitEthernet0/1

Service-policy output: POLICY-VoiceFirst

queue stats for all priority classes:
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 692784/530581758

Class-map: SIP (match-any)
692784 packets, 530581758 bytes
5 minute offered rate 7000 bps, drop rate 0000 bps
Match: protocol sip
692784 packets, 530581758 bytes
5 minute rate 7000 bps
Priority: 25% (250000 kbps), burst bytes 6250000, b/w exceed drops: 0


Class-map: class-default (match-any)
86471948 packets, 21472506885 bytes
5 minute offered rate 867000 bps, drop rate 0000 bps
Match: any

queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 86471951/21472507527

There is hardly any traffic, so what you suspected yourself, that your router is not the bottleneck, is probably true.

Can you also post the output of 'show interfaces GigabitEthernet0/1', just to be sure that there are no errors on the interface itself...

Thanks Georg, here's the sh int g0/1

INTERNET_ROUTER#show interfaces GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
Hardware is CN Gigabit Ethernet, address is 84b8.0238.e8e1 (bia 84b8.0238.e8e1)
Description: INTERNET
Internet address is 89.101.97.206/30
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full Duplex, 1Gbps, media type is RJ45
output flow-control is XON, input flow-control is XON
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/835 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: Class-based queueing
Output queue: 0/1000/0 (size/max total/drops)
5 minute input rate 1313000 bits/sec, 172 packets/sec
5 minute output rate 263000 bits/sec, 129 packets/sec
924110621 packets input, 4149288868 bytes, 72 no buffer
Received 360 broadcasts (0 IP multicasts)
0 runts, 0 giants, 6 throttles
130 input errors, 0 CRC, 0 frame, 65 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
669107853 packets output, 3817544846 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 14713751 pause output
0 output buffer failures, 0 output buffers swapped out

Hello,

sorry for the delay. Traffic load is low, you have a few input errors and overruns, but since you don't know how long they have been on there, clear the counters on that interface (clear counters interface GigabitEthernet0/1) and check if those counters increase.

As stated before, you are probably right and the bottleneck is somewhere upstream.

Joseph W. Doherty
Hall of Fame
Hall of Fame

The physical hand-off gig but you have a 400 Mbps CIR?  If so, you should shape.

Georg in his posts suggests QoS wouldn't help much as your router interface appear to have plenty of bandwidth, and the bottleneck is likely not your router.

Well, on the face of it, that's all true, but I did want to add a note QoS is often a "good idea" (i.e. more than just a ticklist item) even when it appears there's no need for it, because it provides guarantees of service that you don't otherwise obtain.  Additionally, often appearances of sufficient bandwidth can be just that, an appearance, because often bandwidth monitoring isn't detailed/granular enough to "see" what happening at the level that impacts something like VoIP quality.

Review Cisco Networking for a $25 gift card