Dropping packets

I have a scenario of dropping packets in my class-default class under a specified policy-map (outbound) and I can't figure out why.  The priority and other defined classes don't get near their assigned "reservations".  I thought when that configured bandwidth went unused, it would be shared with the other classes.  The class-default in this situation is assigned 30% bandwidth and although it does spike above 30% sometimes, its not the norm.  Either way like I said the other classes are not being used to their limit so should be shared. Just makes no sense.

The physical interface is never compelely saturated per the show interface tx/rxloads either. 

Output:

Class-map: A-VOIP (match-all)
      213730 packets, 43472790 bytes
      5 minute offered rate 101000 bps, drop rate 0000 bps
      Match: access-group name VOICE
      Match: ip dscp ef (46)
      Priority: 40% (17684 kbps), burst bytes 442100, b/w exceed drops: 0


    Class-map: B-VIDEO (match-any)
      3328 packets, 2215861 bytes
      5 minute offered rate 2000 bps, drop rate 0000 bps
      Match: access-group name VIDEO
      Match: ip dscp cs4 (32)
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 3328/2215861
      bandwidth 25% (11052 kbps)

    Class-map: SMS (match-all)
      4 packets, 320 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: access-group name SMS
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 4/320
      shape (peak) cir 1024000, bc 4096, be 4096
      target shape rate 2048000

    Class-map: class-default (match-any)
      12065683 packets, 4038396521 bytes
      5 minute offered rate 13498000 bps, drop rate 0000 bps
      Match: any
      Queueing
      queue limit 1024 packets
      (queue depth/total drops/no-buffer drops/flowdrops) 0/1446/0/0   (recently cleared)
      (pkts output/bytes output) 12063937/4037655219

      Fair-queue: per-flow queue limit 128 packets
      bandwidth 30% (13263 kbps)

policy-map WAN
 class A-VOIP
  priority percent 40
 class B-VIDEO
  bandwidth percent 25
 class SMS
  shape peak 1024000
 class class-default
  queue-limit 1024 packets
  fair-queue
  fair-queue queue-limit 128
  bandwidth percent 30

Serial interface:

bandwidth 44210

BW 44210 Kbit/sec, DLY 200 usec,
     reliability 255/255, txload 77/255, rxload 87/255

Comments

  • Tail drop?

  • I suppose that is what is happening although the TxRing is not close to full so didn't think I would see tail drops.  There is no congestion on the DS3.  The output queue shouldn't be holding any packets.  I researched this online a little today.  Its an ASR1K router.  I ended up raising the queue packet limit in class-default to 10000 packets and the per flow limit to 500 packets from the default 64 and 16.  This has resolved the problem although I still dont know why I was dropping packets to begin with.

  • I have some ASR1ks in my environment and I have seen this exact same behavior.  The bandwidth reservations seem to be strict in the sense that once you assign the reservation to the class, that's what you are going to get regardless of whether or not the circuit is congested.

  • I thought about the reservations 'acting' strict too although with my new settings I have seen class-default taking almost half the DS3, and well over it's reservation, without dropping packets, so I know the classes are sharing.  Can't explain it.  Maybe its something hardware related with the platform or some code issue with the queueing.  

    I was going to open a TAC case but this one I might just file this under juice isnt worth a squeeze to figure it out.  The adjusted queue settings have worked good.  Dropped 1091 packets out of 250M over the last 24 hours.  I'm satisfied.

     

  • IME, complaints about tail drop that can be fixed by increasing buffers are usually explained away by cisco as "micro-bursts".  I buy this on higher speed links with very shallow buffers, but find this harder to accept on slower larger buffered links, or links where the agg input is definitely slower than the wan output. Where it's possible, adding buffers (and latency) seems to fix things, and if it doesn't WRED, etc, can help some.  Not sure how that works out when you're trying to protect class-default trafic, though.

    My favorite is incrementing input "ignores" on full speed full duplex links.  I'm totally clueless when it comes to backplane architecture, so I just assume the issue lies there, but on the surface identical interfaces that can send faster than they can recv seems like broken design.

  • Yea backplane is something for TAC as far as I'm concerned. 

    I've never heard the term micro-burst before, but hey if Cisco can use it, I'll use it too.  Still doesn't make sense to have drops on an uncongested link. 

    I did notice that there was dscp based WRED on the interface when I first started on the problem and when I removed it, the drop rate diminished noticably. It seemed to make things worse.  That's when I added the bandwidth command and left on fair-queue. 

    I can still see packets sitting in the queue at a 13.4M rate in the class default like this from time to time but never get drops. Whatever works.

     Class-map: class-default (match-any)
          1276883104 packets, 348784461557 bytes
          5 minute offered rate 13409000 bps, drop rate 0000 bps
          Match: any
          Queueing
          queue limit 10000 packets
          (queue depth/total drops/no-buffer drops/flowdrops) 184/1019/0/0
          (pkts output/bytes output) 1277023818/348838227677
          bandwidth 30% (13263 kbps)
          Fair-queue: per-flow queue limit 500 packets

  • WRED is designed to drop packets *before* tail drop.  This means that you'd be purposely dropping packets intentionally at some threshold before 100% loss due to tail drop.  This can actually lead to *more* pacets being dropped than you'd see with tail drop, but you've got more contol over what's being dropped - it's supposedly not indescriminate.  It works well to protect classes you care about, IME, but again, I've never tired protecting class default.  It may not work as expected in that case.

Sign In or Register to comment.