03-01-2011 09:33 AM - edited 03-06-2019 03:49 PM
Hi, I've configured a CBWFQ policy with Priority queue for voice traffic. The problem I'm having is that when a user downloads a giant file over the link via HTTP or Cifs, EIGRP appears to be starved out and that effectively brings the link down.
Could you all look at my config to tell me where the problem might be?
This is a 4 meg ethernet handoff from the provider (Cox) between Irvine and London.
Class-maps to classify incoming traffic:
Extended IP access list CUVAVideo
10 permit udp any eq 5445 any (9245939 matches)
20 permit udp any any eq 5445 (4504 matches)
Extended IP access list FromCitrixServers
10 permit ip host 10.40.112.107 any (43886238 matches)
20 permit ip host 10.40.112.108 any (108997111 matches)
30 permit ip host 10.40.112.43 any (4165954 matches)
40 permit ip host 10.40.112.46 any (4090879 matches)
50 deny ip any any (555133236 matches)
Class Map match-any class-default (id 0)
Match any
Class Map match-any RTP-Video (id 5)
Match protocol rtp video
Match access-group name CUVAVideo
Class Map match-any Priority (id 6)
Match protocol rtp audio
Class Map match-any Control (id 7)
Match protocol mgcp
Match protocol skinny
Match protocol h323
Match protocol sip
Match protocol icmp
Match protocol eigrp
Match protocol ospf
Match protocol snmp
Class Map match-any Interactive (id 8)
Match protocol citrix
Match protocol telnet
Match protocol ssh
Match access-group name FromCitrixServers
Policy-map to classify incoming traffic:
Policy Map To_WAN
Class Priority
set dscp ef
Class Control
set dscp af41
Class RTP-Video
set dscp af31
Class Interactive
set dscp af21
Class class-default
set dscp default
Class-maps to enforce policy on outgoing traffic:
Extended IP access list WAN-Control
10 permit udp any any eq ntp (18848 matches)
20 permit udp any eq ntp any
30 permit eigrp any any (1174234 matches)
Class Map match-any AF41 (id 1)
Match dscp af41 (34)
Match access-group name WAN-Control
Class Map match-any EF (id 2)
Match dscp ef (46)
Class Map match-any AF21 (id 3)
Match dscp af21 (18)
Class Map match-any AF31 (id 4)
Match dscp af31 (26)
Class Map match-any class-default (id 0)
Match any
Policy-map to enforce policy on outgoing traffic (with shaping):
Policy Map To_UK_Shaper
Class class-default
Average Rate Traffic Shaping
cir 4000000 (bps)
service-policy To_UK
Policy Map To_UK
Class EF
priority 512 (kbps)
Class AF41
bandwidth 256 (kbps)
Class AF31
bandwidth 768 (kbps)
Class AF21
bandwidth 1024 (kbps)
Class class-default
bandwidth 256 (kbps)
Applied on outgoing interface:
interface FastEthernet0/0/0
description to UK via Cox TLC
bandwidth 4000
ip address 192.168.41.40 255.255.255.0
duplex full
speed 10
service-policy output To_UK_Shaper
end
Here is the sh policy-map for the interface:
I don't know why there are so many drops for AF21. I don't see any drops for AF41. Would anyone go about a different way of doing this? I'd like to see some examples from you experts.
#sh policy-map int fa 0/0/0
FastEthernet0/0/0
Service-policy output: To_UK_Shaper
Class-map: class-default (match-any)
31135173 packets, 8815650918 bytes
5 minute offered rate 3446000 bps, drop rate 27000 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/33765/0
(pkts output/bytes output) 31101409/8809555924
shape (average) cir 4000000, bc 16000, be 16000
target shape rate 4000000
Service-policy : To_UK
queue stats for all priority classes:
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/17/0
(pkts output/bytes output) 5694740/1295714435
Class-map: EF (match-any)
5694757 packets, 1295732084 bytes
5 minute offered rate 87000 bps, drop rate 0 bps
Match: dscp ef (46)
5694757 packets, 1295732084 bytes
5 minute rate 87000 bps
Priority: 512 kbps, burst bytes 12800, b/w exceed drops: 17
Class-map: AF41 (match-any)
2039678 packets, 171167811 bytes
5 minute offered rate 2000 bps, drop rate 0 bps
Match: dscp af41 (34)
1928499 packets, 166099509 bytes
5 minute rate 2000 bps
Match: access-group name WAN-Control
111179 packets, 5068302 bytes
5 minute rate 0 bps
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 2039678/174463657
bandwidth 256 kbps
Class-map: AF31 (match-any)
2438468 packets, 1514221844 bytes
5 minute offered rate 180000 bps, drop rate 0 bps
Match: dscp af31 (26)
2438468 packets, 1514221844 bytes
5 minute rate 180000 bps
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 2438468/1514219989
bandwidth 768 kbps
Class-map: AF21 (match-any)
11029034 packets, 2904495680 bytes
5 minute offered rate 150000 bps, drop rate 0 bps
Match: dscp af21 (18)
11029033 packets, 2904495680 bytes
5 minute rate 150000 bps
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/1565/0
(pkts output/bytes output) 11027469/2903202927
bandwidth 1024 kbps
Class-map: class-default (match-any)
9933237 packets, 2930033884 bytes
5 minute offered rate 3060000 bps, drop rate 27000 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/32183/0
(pkts output/bytes output) 9901054/2921954916
bandwidth 256 kbps
Solved! Go to Solution.
03-01-2011 10:00 AM
The one dropping the eigrp packets is the provider, not you. QOS will not help if it's applied on your side.
03-01-2011 10:00 AM
The one dropping the eigrp packets is the provider, not you. QOS will not help if it's applied on your side.
03-01-2011 10:26 AM
Hi Dominic,
Thank you for your response. How did you come to that conclusion? So you're saying that despite the policing policy, the provider still might be dropping our packets? We have a 4 meg line from them. Should I calculate for something lower to minimize the risk that they'll drop our packets?
Vince
03-02-2011 11:15 AM
I lowered my shaping to 3.8 Mbps and now I'm getting more predictible results.
Thanks.
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