Hello,

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

Giuseppe

Hi,

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?

Thanks,

Antony

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.

Antony

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

Giuseppe

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.