I am migrating several Sup720 c65xx platforms to Sup2T.
Our netflow collector (flow-tools) immediately started complaining
about massive numbers of missed flows.
Packet capture reveals that the device will send more than one
series of flowdata with the same "EngineID".
We'll see flows exported from various DFC-enabled linecards,
with the appropriate slot number as the "EngineID" - all
with the first flow's sequence number starting at 0 and
incrementally increasing as more flows are exported.
The Sup2T will do this too, except, after some number of
flows has been exported, it will start sending _another_
series of flowdata with a new sequence number starting
at 0.
This confuses the collector, which for example, has seen
the supervisor's EngineID send flow sequence number 5000,
and the very next packet contains sequence number 0(!).
Now the collector believes it has lost exports with sequence number 5001
up through the rollover value of the counter - so it reports losing about
4 billion flows.
I don't think this is proper behavior, because the collector
needs to rely on the sequence number for an EngineID
increasing (only) - so that it can determine if it has missed flows (due
to packet loss or other problems on the collector). On Sup720 you
could get the MSFC flows as v5 and the PFC flows as v7 which
worked fine. Perhaps both of those flows are being exported from
the same EngineID - but with different sequence number series?
I'm using the "export-protocol netflow-v5" format. Our netflow
collection infrastructure has been in place for a very long
time and is stable.
Any ideas?
Regards,
-Chris
