Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Can't get QoS on serial link to function properly

The following configuration is on our WAN routers. The problem is, data traffic stills take up the entire T1 and the voice quality becomes extremely poor when there are file transfers. If I create another policy-map called FILE_XFR and put it under the VOICE-LLQ policy-map, assign FTP, HTTP, and the Microsoft ports to it, and give it a percentage of bandwidth, say 30%, voice quality instantly becomes good. Given the configuration below, it appears the class-default can still take 100% of the bandwidth, but I don't understand how. I've even assigned it a small percent of the bandwidth, configured policing, and the behavior doesn't change. I'd appreciate anyone's ideas on this.

Thank you.

class-map match-any VOIP_RTP

match access-group 180

class-map match-any SIGNALLING_TRAFFIC

match access-group 181

...

policy-map VOICE-LLQ

class _VOIP_RTP

priority percent 30

class SIGNALLING_TRAFFIC

bandwidth percent 5

class class-default

fair-queue

...

interface Serial1/0:0

ip address 10.2.6.14 255.255.255.252

service-policy output VOICE-LLQ

ip rtp header-compression

...

access-list 180 remark this acl is used to classify VOIP and FAX RTP Traffic

access-list 180 permit udp any any range 16384 32767

access-list 180 permit udp any any precedence critical

access-list 180 permit udp any any dscp ef

access-list 181 remark this acl is used to classify all VOIP Signalling from CCM

access-list 181 permit tcp any any eq 2000

access-list 181 permit tcp any any eq 2443

access-list 181 permit tcp any any eq 3804

access-list 181 permit tcp any any eq 1718

access-list 181 permit udp any any eq 1719

access-list 181 permit tcp any any eq 1720

access-list 181 permit udp any any eq 2427

access-list 181 permit tcp any any eq 2428

access-list 181 permit tcp any any eq 5060

access-list 181 permit udp any any eq 5060

12 REPLIES

Re: Can't get QoS on serial link to function properly

Hello.

Can you provide two 'show policy-map interface Serial1/0:0 output' 15 minutes apart?

Simon

New Member

Re: Can't get QoS on serial link to function properly

There won't be much voice traffic at this time of day, so I can repost tomorrow morning after employees get back into the office.

REIX1-R1-01000#show policy-map interface Serial1/0:0 outpu

Serial1/0:0

Service-policy output: VOICE-LLQ

Class-map: _VOIP_RTP (match-any)

490711 packets, 31422541 bytes

30 second offered rate 25000 bps, drop rate 0 bps

Match: access-group 180

490711 packets, 31422541 bytes

30 second rate 25000 bps

Queueing

Strict Priority

Output Queue: Conversation 264

Bandwidth 30 (%)

Bandwidth 460 (kbps) Burst 11500 (Bytes)

(pkts matched/bytes matched) 115/2990

(total drops/bytes drops) 0/0

Class-map: SIGNALLING_TRAFFIC (match-any)

20535 packets, 1116567 bytes

30 second offered rate 2000 bps, drop rate 0 bps

Match: access-group 181

20535 packets, 1116567 bytes

30 second rate 2000 bps

Queueing

Output Queue: Conversation 265

Bandwidth 5 (%)

Bandwidth 76 (kbps)Max Threshold 64 (packets)

(pkts matched/bytes matched) 894/64224

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

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

161548 packets, 58095302 bytes

30 second offered rate 1467000 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/0/0

=== 15 minutes later ===

Serial1/0:0

Service-policy output: VOICE-LLQ

Class-map: _VOIP_RTP (match-any)

491236 packets, 31456141 bytes

30 second offered rate 0 bps, drop rate 0 bps

Match: access-group 180

491236 packets, 31456141 bytes

30 second rate 0 bps

Queueing

Strict Priority

Output Queue: Conversation 264

Bandwidth 30 (%)

Bandwidth 460 (kbps) Burst 11500 (Bytes)

(pkts matched/bytes matched) 127/3302

(total drops/bytes drops) 0/0

Class-map: SIGNALLING_TRAFFIC (match-any)

22340 packets, 1221139 bytes

30 second offered rate 1000 bps, drop rate 0 bps

Match: access-group 181

22340 packets, 1221139 bytes

30 second rate 1000 bps

Queueing

Output Queue: Conversation 265

Bandwidth 5 (%)

Bandwidth 76 (kbps)Max Threshold 64 (packets)

(pkts matched/bytes matched) 982/71120

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

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

240708 packets, 155181187 bytes

30 second offered rate 1493000 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/0/0

New Member

Re: Can't get QoS on serial link to function properly

Do a show class-map and see what traffic you are marking for _VOIP_RTP.

"_VOIP_RTP" vs "VOIP_RTP"

class-map match-any VOIP_RTP

match access-group 180

class-map match-any SIGNALLING_TRAFFIC

match access-group 181

...

policy-map VOICE-LLQ

class _VOIP_RTP

--------------

Class-map: _VOIP_RTP (match-any)

491236 packets, 31456141 bytes

30 second offered rate 0 bps, drop rate 0 bps

*** 30 second offered rate 0 bps***

New Member

Re: Can't get QoS on serial link to function properly

I didn't strip out the leading underscore. This is for one of my clients, and they don't want me to post client information. The client's name was before the underscore, and I accidentally didn't remove it.

Super Bronze

Re: Can't get QoS on serial link to function properly

What kind of WAN technology is interface Serial1/0:0 attached too? What type of device and IOS is this?

As to your question about another policy map, FILE_XFR, "under" VOICE-LLQ policy-map, it unclear exactly what you're doing. If you would post actual config, might be able to explain realized performance differences.

New Member

Re: Can't get QoS on serial link to function properly

I put in the FILE_XFR to match various file transfers, but I have since taken this out and replaced it with policing on the default class. I didn't mean to create confusion, when with the XFR_TRAFFIC class configured, the voice quality is good.

class-map match-any XFR_TRAFFIC

match access-group 182

policy-map VOICE-LLQ

class VOIP_RTP

priority percent 30

class SIGNALLING_TRAFFIC

bandwidth percent 5

class XFR_TRAFFIC

bandwidth percent 30

class class-default

fair-queue

access-list 182 permit tcp any any eq www

access-list 182 permit tcp any any eq 443

access-list 182 permit tcp any any eq 445

access-list 182 permit tcp any any eq ftp

access-list 182 permit tcp any any eq ftp-data

access-list 182 permit tcp any eq www any

access-list 182 permit tcp any eq 443 any

access-list 182 permit tcp any eq 445 any

access-list 182 permit tcp any eq ftp any

access-list 182 permit tcp any eq ftp-data any

New Member

Re: Can't get QoS on serial link to function properly

This is a 2800 router running c2800nm-adventerprisek9-mz.124-15.T5.bin. This is a full T1 running hdlc encapulation.

Re: Can't get QoS on serial link to function properly

Hi,

so far I can see two possible reasons of your trouble:

a) there might be some non-voice traffic using udp with precedence critical or dscp ef and consuming your class VOIP_RTP bandwidth

b) some non-voice traffic using TCP with high TOS values. As you are running fair-queue within your class-default, it can consume a lot of bandwidth.

If you simply reserve some bandwidth (30%, e.g.) to your class-default and configure no fair-queue for that, it could make it to behave more friendly to your voice traffic.

Look at this thread

http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Network%20Infrastructure&topic=WAN%2C%20Routing%20and%20Switching&topicID=.ee71a06&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40%40.2cc2d915/27#selected_message

for more details.

BR,

Milan

New Member

Re: Can't get QoS on serial link to function properly

I did reserve bandwidth yesterday (40%) and removed the fair queue, and it didn't impact the behavior. I even set it down to 5% (I know the default class gets an addition 25%, so I presume this actually made it 30%) and nothing changed.

Regarding a), I thought about that yesterday, but when I created a separate class for just file transfers, the voice immediately became acceptable. I'm not sure which order the matching occurs, but given queuing controls the traffic when I create a separate class for the file transfers, I'd presume the same traffic matches the default class when a file transfer class is not used.

Last night I set policing to transmit if traffic conforms and to drop when it exceeds in the default class, and this has solved the problem. I wouldn't think this would be required, but as soon as I remove service-policy statement from the serial link, the voice quality instantly degrades.

Super Bronze

Re: Can't get QoS on serial link to function properly

The results you're describing don't make much sense. If I understand correctly, the VoIP problem is only seen when file transfers are in a non-policed class-default class. I can think of reasons moving file transfers to their own defined class would make a difference, but this along with policing class-default works is stange. I can also think of reason why policing class-default alone would make a difference. It's both being cures what's strange.

This T-1 is p-2-p? Similar router other side? Same QoS both sides?

[edit]

Of course running a "T" train muddies the waters. You might consider moving to 12.4 mainline or upgrading to the (15)T8.

Re: Can't get QoS on serial link to function properly

Try using some kind of random detect mechanism and drop some traffic. Also, try priority 461 and add random detect to your class default.

New Member

Re: Can't get QoS on serial link to function properly

This T1 is p-2-p. There is the same QoS on both sides. I know this sounds strange, and quite honestly, I'm more convinced that there is a bug. I've changed the configuration back and forth enough to see the impact on the voice traffic to know that what I stated is correct. I've inherited this project with the router running this version of code, but I agree that upgrading would be worth a shot.

Thanks for the input.

198
Views
0
Helpful
12
Replies
CreatePlease to create content