cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
644
Views
0
Helpful
3
Replies

QoS help! Control traffic still being starved out despite QoS policy

vincehgov
Level 1
Level 1

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

1 Accepted Solution

Accepted Solutions

dominic.caron
Level 5
Level 5

The one dropping the eigrp packets is the provider, not you. QOS will not help if it's applied on your side.

View solution in original post

3 Replies 3

dominic.caron
Level 5
Level 5

The one dropping the eigrp packets is the provider, not you. QOS will not help if it's applied on your side.

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

I lowered my shaping to 3.8 Mbps and now I'm getting more predictible results. 

Thanks.

Review Cisco Networking for a $25 gift card