>On Fri, Jul 20, 2001 at 12:21:59PM -0500, David Spindler wrote:
>> The sup2 still supports version 1 which should have sour and
>dest ip set.
>
>Version 1 exports should not be used for anything important
>since without
>a sequence number it is not possible to detect lost flows.
>
>The ifIndex (input/output) fields are left 0. v1 exports will not fix
>this. It's either a bug or hardware limitation of the 65xx.
So okay, what it comes down to is if you have a MSFC OR MSFC2 attached to a
MLS switch (Supervisor+PFC), you can deduce everything that passes through
your network, even nexthop/AS data (requires more 'smarts' in the collection
tools). We have an MSFC2 with Sup1 (c6sup12 native ios image), and we get
full data appearing in the flowscan graphs (after being capture by
flow-tools). Note that the application (flowscan) doesn't require AS data
(it can use it, but we're not as we dont run BGP on these boxes).
If you have a PFC2, it appears you only get effectively the 'shortcut'
flows, and you lose src/dst If/AS and nexthop data from every flow (whereas
the non-accelerated flows from the MSFC2 with a Supervisor 1 are seen,
allowing a "reconstruction" to be made by the collector, as Mark suggested a
possible method for).
why? Supervisor 1 is a "MLS" routing switch ala Cat 5505 netflow feature
card + Route Switch module. Supervisor 2 is more like a GSR (and more like
an 8500 series switching router), using CEF (and PXF?) to accelerate packets
through the chassis. This allows for that 'first packet' classification of
a flow to be skipped (these are the flows the MSFC[2] exports on a Cat6500
Supervisor 1).
-afort
-- cflowd mailing list cflowd@caida.org
This archive was generated by hypermail 2b29 : Sun Jul 22 2001 - 16:16:44 PDT