Detail of Packet Drops for CAR or MQC (Police)

Unanswered Question
Jul 9th, 2008
User Badges:


We have a customer that is looking for detail of the actual traffic that gets dropped within a queueing policy. They would like source / destination / port numbers if possible.

Is there any type of policing that would allow us to see this information?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
lee.reade Wed, 07/09/2008 - 07:03
User Badges:
  • Silver, 250 points or more


You could try have the class-map match an access-list with the log keyword at the end, and the view the hits for the access-list via the show access-list and show logging command.

Make sure to turn logging buffered on.



Giuseppe Larosa Wed, 07/09/2008 - 08:32
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member


I would add the sending of the log messages to a syslog server because the local buffer is easily overwritten with this configuration.

Hope to help


TECH SUPPORT Wed, 07/09/2008 - 08:42
User Badges:


Are you saying we can debug the queueing policy and therefore get some output of the destination address / source address / destination port / source port of the packet that gets dropped by the queueing policy?

Then send this to syslog?

Which queueing policy would you advise?

Which debugs (if any) would you run?



TECH SUPPORT Wed, 07/09/2008 - 08:47
User Badges:

Thanks but it is not class matches that our customer wishes to track but class matches that exceed the given rate for that class.

He has chosen rate-limit (CAR) but I suspect that neither CAR or MQC will give detail of the information we require.

Please correct me if I am wrong or if you can definitely say there is no way we can do this.


Giuseppe Larosa Fri, 07/11/2008 - 08:58
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Antony,

now it is more clear what you customer would like to see.

I agree I don't think is possible to have this level of detail only for exceeding packets.

However, TCP flows have built-in flow control so if one packet in a TCP session is dropped it will produce a reduction of the TCP window for that session.

If the majority of traffic is TCP it will adapt to the CAR BW limit.

I would try to make this explanation to the customer.

For implementation reasons the network device cannot provide this type of info, however it is possible to have statistical information about how much traffic is dropped without going to the single microflow detail. The dropping rate can be seen as the retransmission probability for a TCP segment

Modular QoS provides also specific MIBs that allow to red per class counters.

This could be a reason to move to service-policy with the police command instead of CAR.

hope to help


tdrais Fri, 07/11/2008 - 10:05
User Badges:
  • Blue, 1500 points or more

Hmm I though I had posted on this but maybe I forgot to click post.

As pointed out you basically can't do this.

Will post a short version of what I though I had put up.

Put a car/police on the input interface but change the exceed action to SET_DSCP TRANMIT and select a unique value for the DSCP.

Put a access list on the output that matches this dscp and deny it with log if you wish.

Put IP ACCOUNTING access-violations on the output interface

You can now get a report that show the source and destination ips and how many packets/bytes. It does not include the port but since the packets are now passing the router you may get something from cache flow.


This Discussion