OverviewUsers generally see that the traffic they have discarded shows up in the Monitor > Real time/Application/Host (with respect to host) giving the impression that it is not discarded. This generally happens with traffic which is Web based, like Windows Updates, but also for websites that are being discarded.
CauseWeb traffic will be classified under the Web policy initially. That is because the first packets are HTTP and the Exinda needs to examine the packets at a deeper level in order to perform a higher level of classification. These initial packets are what is used in order to determine the classification. After the classification happens, the appliance also realizes the policy that the traffic needs to be sent to is a discarding one. So the Exinda summarizes all those packets within the last 10 seconds as the new classification falling under the old policy when actually the packets are being discarded.
The device reports in real-time and send to the database every 10 seconds, As a metric it sometime stores reporting data under Monitor > Application or Host which indicates data being used even though discarded although it shows data for initial flows only until it is being recognized for discarded policy.
So if a flow starts out in a different policy and is then re-classified then there is a time where the packets are in some other policy before they start getting put in the policy that the flow reported against.
A flow may have been going at 20kbps for 5 seconds, then got re-classified to a policy that has a 3kbps limit, so then for the next 5s it will go at 3kps. But real-time will show around 11.5kbps for that flow - because that was the average for the past 10s. It will account all this traffic to the 3kbps policy even though some of it fell in a different policy initially. So all the reporting is based on what the policy is each 10s, not what policies it may have had during the 10s.
When a L7 re-classification happens to flow the new classification doesn't apply to any packets already in QoS - only new packets, so there could already be a lot of packets queued up against the old policy. And it in fact can take a while from when the packet is passed through to get back to collectord and to get back to the kernel to start reclassifying new packets.
At very low speeds (less than 32k is starting to get pretty low) due to the way we select QoS queues - the rate can be a bit erratic (over for a bit, below for a bit) although over the long term it should average out (but again only the control graph shows the actual QoS of packets, real-time and the database are based in flows at what policy that had at the end of each 10s.)
So if the flows falling into the policy are doing so because of a L7 reclassification then you can expect to see a rate higher than that configured. If there are a lot of flows, that can be significantly higher - depending on how many and what policy the flows are starting out in before being re-classified and how busy collectord is (how long it takes to get around to doing the reclassification.)