difference with QoS

[luis.veraza]

HI,

I have configured QoS over serial port with a policy-map and it has a class-map for a ACL with precedence critical, do i need it ? is it good ?

I have configured IP TCP and RTP header-compresion over the ports.

The problem is that one link has a good sound and other has a sound lower,

could you please help me ?

best regards

[robert.hyde]

Luis,

If you are running real-time traffic over your links such as voice, QoS is definitely a good idea. Go ahead and paste in your class-maps, policy-maps, "show interface" for the interfaces where you will apply QoS, and a general description of what you are trying to achieve. We would be happy to look at that.

Thanks!

[luis.veraza]

Ok, we are working with IP Telephony, but first we test the WAN links, PBX to PBX, but in two points we listen the voice lower, we can´t hear very well, both out and in.

Site B --- Site A(Core) ---- Site C

Config in Site B

class-map match-all voice

match access-group 120

!

policy-map traffic

class voice

priority 240

class class-default

fair-queue

queue-limit 20

interface Serial1/0

bandwidth 1024

ip address 10.0.0.2 255.255.255.0

service-policy output traffic

ip tcp header-compression iphc-format

no ip mroute-cache

ip rtp header-compression iphc-format

ACL: Does not exist.

Site A:

class-map match-all voice

match access-group 110

!

policy-map traffic

class voice

priority 240

class class-default

fair-queue

queue-limit 20

interface Serial3/0

bandwidth 1024

ip address 10.0.0.1 255.255.255.0

service-policy output traffic

ip summary-address eigrp 100 198.100.0.0 255.255.0.0 5

ip summary-address eigrp 100 194.43.70.0 255.255.255.0 5

ip summary-address eigrp 100 192.168.120.0 255.255.255.0 5

ip summary-address eigrp 100 192.1.12.0 255.255.255.0 5

ip summary-address eigrp 100 192.1.10.0 255.255.255.0 5

ip summary-address eigrp 100 10.44.8.0 255.255.255.0 5

ip tcp header-compression iphc-format

no ip mroute-cache

serial restart-delay 0

ip rtp header-compression iphc-format

ACL 110:

Extended IP access list 110

10 permit udp any any range 16384 32767 (60937456 matches)

20 permit tcp any eq 1720 any (64639 matches)

30 permit tcp any any eq 1720 (47045 matches)

40 permit ip any any precedence critical (2050742 matches)

Yo need something else ?

Best regards, Luis.

[robert.hyde]

Luis,

That is good info, though I do have two more questions for you:

1) In the config for device B, your "voice" class map matches access-group 120. Is access-list 120 on device B the same as access-list 110 on device A? If access-list 120 does not exist on device B that would cause a problem.

2) When you experience low voice quality, how many calls are you sending through at once and what codec are you using?

If you can paste in a "show policy-map interface" from each device that would be helpful. Also if you could let me know what each platform and IOS version is.

Thanks!

[luis.veraza]

Ok, Robert thanks..

- The ACL 120 does not exist.

- When we did the test was time out of work. None else.

- How can i see the codec used ?

Router A:

Service-policy output: traffic

Class-map: voice (match-all)

46729 packets, 3046251 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: access-group 110

Queueing

Strict Priority

Output Queue: Conversation 264

Bandwidth 240 (kbps) Burst 6000 (Bytes)

(pkts matched/bytes matched) 3931/139821

(total drops/bytes drops) 0/0

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

4682424 packets, 2589211678 bytes

5 minute offered rate 113000 bps, drop rate 0 bps

Match: any

Queueing

Flow Based Fair Queueing

Maximum Number of Hashed Queues 256

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

Router B:

Service-policy output: traffic

Class-map: voice (match-all)

43536133 packets, 2806387741 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: access-group 120

Queueing

Strict Priority

Output Queue: Conversation 264

Bandwidth 240 (kbps) Burst 6000 (Bytes)

(pkts matched/bytes matched) 4050907/135164826

(total drops/bytes drops) 0/0

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

779186975 packets, 81289942193 bytes

5 minute offered rate 175000 bps, drop rate 0 bps

Match: any

Queueing

Flow Based Fair Queueing

Maximum Number of Hashed Queues 256

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

Router A: 3660 c3660-js-mz.123-3.bin

Router B: 3640 c3640-js-mz.122-8.T10.bin

do you see something wrong ?

[robert.hyde]

Luis,

Thank you for that information. Your QoS configs look right - you are classifying voice traffic using the traditional voice ports in an access-list, which feed into a voice class that receives 240k priority bandwidth over everything else.

For certain you will want to make sure that the proper access-list exists on both devices, if either device has a "voice" class referring to an access-list that doesn't exist, you won't get your desired results. And a class-map will in fact let you point to an access-list that doesn't exist - it will take the command, it just won't work.

The "show service policy interface" info shows that on both device A and B, there were matches to the "voice" class, so that proves that it is recognizing the voice traffic. Though site A has matched 10 times the amount of voice traffic as site B, which seems odd. Neither site had to drop voice traffic that exceeded the 240k which you allotted to voice, so it is not a matter of too much voice traffic. Especially since there was no one else running voice over that link when you were testing.

Regarding the circuit between router A and router B, is it a standard point to point Serial circuit running HDLC?

And it is probably time to look at the telephony equipment. Can you explain end-to-end what your telephony setup is? Is the voice just running between site A and site B for now?

Thanks!

[luis.veraza]

Robert,

Thanks a lot, we are running HDLC over it link, other is working with MultilinkPPP, the link with HDLC is working better.

We use VoIP actually over WAN link, but we have IP Telephony with only IT user, we want to expand it to all users, but we believe that need to optimize it first.

Exactly, what do you need to know ?

thanks, a lot. Luis,

[robert.hyde]

Luis,

A few more questions... You said that your network diagram was like this:

Site B --- Site A(Core) ---- Site C

And I believe so far we have just been looking at information on sites B and A, which per the configs use an HDLC link. That would mean that the link between sites A and C is multilink PPP. When you are experiencing low quality voice, is it between site B and A, or between C and A, or between B and C? If the low quality voice is with site C, I would like to see a "show class-map", "show policy-map", and "show policy-map interface" from device C.

Thanks!

[luis.veraza]

Robert, thanks a lot.

Ok. The link with low quality is C, it´s working with Multilink PPP, the link with better quality is A, working with HDLC.

I send you the results from commands.

show class-map

mtcis1#sh class-map

Class Map match-any class-default (id 0)

Match any

Class Map match-all trafico-voz (id 2)

Match access-group 115

Class Map match-all senalizacion-voz (id 3)

Match access-group 116

sh policy-map

mtcis1#sh policy-map

Policy Map VOZ-1

Class senalizacion-voz

Weighted Fair Queueing

Bandwidth 8 (kbps) Max Threshold 64 (packets)

Class trafico-voz

Weighted Fair Queueing

Strict Priority

Bandwidth 96 (kbps) Burst 2400 (Bytes)

Class class-default

Weighted Fair Queueing

Flow based Fair Queueing

Bandwidth 0 (kbps) Max Threshold 64 (packets)

sh policy-map int

Multilink1

Service-policy output: VOZ-1

Class-map: senalizacion-voz (match-all)

5920 packets, 380885 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: access-group 116

Weighted Fair Queueing

Output Queue: Conversation 137

Bandwidth 8 (kbps) Max Threshold 64 (packets)

(pkts matched/bytes matched) 5920/380885

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

Class-map: trafico-voz (match-all)

1739515 packets, 112322731 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: access-group 115

Weighted Fair Queueing

Strict Priority

Output Queue: Conversation 136

Bandwidth 96 (kbps) Burst 2400 (Bytes)

(pkts matched/bytes matched) 1739515/48302952

(total drops/bytes drops) 0/0

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

1749751 packets, 289331030 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: any

Weighted Fair Queueing

Flow Based Fair Queueing

Maximum Number of Hashed Queues 128

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

How can i know the codec used ?

Thank !, best regards Luis.

[robert.hyde]

Luis,

That is good info, and that makes more sense that the link to site C is the one with the problem. From the "show policy-map interface" we can see that link is pretty congested, though the router did not drop any packets from the two class-maps that you defined. But the router did drop some packets from the default class, so your prioritization is working.

If the link between sites A and C is less than 768k, you will want to make sure you have link fragmentation and interleaving (LFI). Since your trafico-voz class gets priority 96k, even if you are using the G.711 codec at 64k, that should be enough to get one call through clean.

So now that we are focussing on sites A and C, I would like to see the following items from the running config of router A and router C: class-maps, policy-maps, access-lists used by class-maps, and interface configs.

Thanks!

[luis.veraza]

Robert,

Thanks a lot by your help,

We solve the problem with the command input gain 12, we have a better sound, now i´m making a standar of QoS, L2 Protocols, etc, because each router or link has a different configuration, later we´ll work with QoS

Best Regards.Luis