Discrepancy between flow-packets and interface counter

In article , Garry Glendown wrote: :I'm currently trying to locate some high troughput on a line - anyway, :after enabling flow accounting on the PE router, I get some of the :flows, but there's a pretty big discrepancy between the octet count of :the flows, and what the SNMP-counters resulted in - something like 6gig :on SNMP, and 106MB on the flows

I do not know the extent to which it applies to the various different counters, but in IOS, if you have flow caching enabled then some of the counters only reflect the initial packets of the flows -- because the other packets go directly into processing rather than having to go through the decision-making step that has the meter.

Well, doesn't that contradict the (AFAIK) usual use of flows for traffic analysis and accounting??? Plus, if the flow is identified (for the route caching), isn't increasing the counter of that flow by the number of bytes more or less the easiest thing to do??

:> I do not know the extent to which it applies to the various different :> counters, but in IOS, if you have flow caching enabled then some :> of the counters only reflect the initial packets of the flows --

:Well, doesn't that contradict the (AFAIK) usual use of flows for traffic :analysis and accounting???

If I understand correctly, "netflow accounting" is supposed to be accurate. When you wrote "flow accounting" it did not match "netflow" in my mind, partly because you were talking about "counters", but netflow is a way of outputting accounting -records- to an outside location for later analysis.

OK, just to clarify/confirm what I'm doing:

- our regular accounting uses the SNMP counters of a port

- I set up flow export to get detailed flow infos to track down the cause of unexprected traffic:

int ser5/0:0 ip route-cache flow [..] ip flow-export source fa0/0 ip flow-export version 5 ip flow-export dest LOGGINGHOST

One interesing thing I have noticed that I only seem to get flow data originating from the CPE/customer net, not any going TO the CPE/customer net ... !?

On 17.04.2005 16:21 Garry Glendown wrote

You have to enable netflow on every port traffic for customer X may come in. Not only the interface the customer X sends traffic to. See

Arnold

The link to the backbone was netflow enabled, too ... when not limiting flow data to the customer interface, I still don't see "enough" flow traffic ... !?

Is the traffic actually being fast switched? In this case you are using

Netflow Switching as the fast switching method.

I would suppose that process switched traffic would not be accounted for in netflow switching.

Also on a broadcast (or non-broadcast) medium the router can receive traffic that is not forwarded by it. This will be recorded by the interface counters but not by the netflow accounting.

In a 5 days by 8 hours environment the 24 x 7 broadcasts can amount to a surprising proportion of the total traffic.

What would I have to do to check into this? Up till now I thought by enabling route-cache flow, the netflow switching were enabled and thus all data traffic would be visible through the flow export ... worked before on other customer links that had unexplainable traffic ...

The router I'm running the flow accounting on is the sending side ... so I recon this does not apply ...

Tnx, -gg

sh interface switching

sh interface stat

Show various confusing numbers but I usually just look to make sure that the process switched numbers are a smallish proportion of the traffic. I have never wanted to worry more.

Remember that the first packet in each flow is process switched. Maybe you have a high proportion of flows with few packets (one?). For example a port scan would likely result in this behaviour.

I have NO IDEA if process switched packets are accounted for in netflow accounting. It does seem reasonable that they might be since the extra overhead would be quite small.

Should be easy enough to test with above mentioned port scanning technique.