02-24-2009 12:32 PM - edited 03-04-2019 03:42 AM
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
02-24-2009 02:03 PM
Hello.
Can you provide two 'show policy-map interface Serial1/0:0 output' 15 minutes apart?
Simon
02-24-2009 02:41 PM
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
02-24-2009 08:29 PM
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***
02-25-2009 07:16 AM
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.
02-24-2009 04:43 PM
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.
02-25-2009 07:13 AM
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
02-25-2009 07:18 AM
This is a 2800 router running c2800nm-adventerprisek9-mz.124-15.T5.bin. This is a full T1 running hdlc encapulation.
02-25-2009 12:21 AM
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
for more details.
BR,
Milan
02-25-2009 07:06 AM
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.
02-25-2009 09:36 AM
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.
02-25-2009 02:35 PM
Try using some kind of random detect mechanism and drop some traffic. Also, try priority 461 and add random detect to your class default.
02-25-2009 02:56 PM
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.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: