[flow-tools] Re: cat6500 v6+v7 export deinterlaving (was Re: [flow-tools] flow-tools-0.55) Andrew Fort

[Andrew Fort]

On Tue, 4 Sep 2001, Nicolai Maquiavel wrote:

[I have BCC'd Nicolai as this arrived in my personal mailbox and is
something that perhaps others on the list can benefit from, also]

> Hi Andrew,
>     I´m using cflowd + flowscan, but I have problem
> with netflow of Catalyst 6500, only MSFC export
> netflow version 5.
>
>     Do you fix this problem with Flow Tools?
>
>     Thanks for advance and excuse-me send mail
> directly for you
>
> Nicolas
>
> >Are others using this particular functionality?
> i.e., Catalyst 6500
> >Native IOS exporting v6 (msfc) flows and v7 (pfc)
> flows at the same time.
> >flow-tools 0.55 supports de-interleaving the combined
> udp stream of v6/v7
> >flows that arrive from such a chassis.

I've gotten a few questions about this via private mail, so I'll explain
the reason this feature exists, and a little history and architecture of
the platform we're talking about.

Yes, flow-tools can work with your Catalyst 6500 to capture all the data
it exports.

flow-tools 0.55 includes functionality that allows it to seperate two PDU
types (say, version 6 and version 7 netflow PDUs) arriving at the same
collector (i use flow-capture).

This is necessary due to a limitation in Cisco's _Native IOS_ software for
the Catalyst 6000/6500 with PFC+MSFC.

The Cat6500's legacy design, that of a seperated architecture, one part
primarily handling L2 functions (this being the Switch Processor [SP],
which includes the PFC and 'Supervisor' bits of the switch, but not the
MSFC (which is connected to the supervisor)); the other part handling
primarily L3 functions (the Route Processor [RP], i.e., the MSFC or
MSFC2).

Of course the PFC can use L4 information for flow classification, QoS and
such, but the SP's major role is L2 forwarding.

So given this architecture (for the Supervisor1, it's quite similar in
concept to the Catalyst 5500+RSM architecture), we have two places that
flows can be exported from.  The SP can export flows (type 7 PDUs, which
include the encapsulation type) and the RP can export flows (type 1, 5 or
6 PDUs -- just like a router (which the MSFC is, it's similar to the NPE
on a 7200, with a different backplane interface).

Nicolas, you didn't mention if you're using Native IOS or the
'traditional' software for your Cat 6000 series; i.e., Catalyst OS runs on
the SP (Supervisor code) and the IOS runs only on the RP (MSFC), providing
the routing protocols and L3 addressing functions.

This new feature (deinterleave) is required for the Native IOS software,
because one cannot configure the destination of the flows from the SP with
Native IOS (note: this is fixed in the latest released code, but I'm not
installing that just yet :).  The destination you configure on the RP is
used for the SP flows also.

Cisco identified that this may cause problems (for their collector),
because of the differing flow versions.  So, they allow you to configure
the source address differently for the SP (it's UDP, so you can pick any
address you like, but treat this address as if it were a loopback
interface or whatever - i.e., make it unique).

So, one can presumably get around this problem by using a seperate
flow-capture process for the SP and RP, on each switch (2 processes per
device).  So for our IDC we have 4 flow-capture processes running.

As an alternative, to allow the "//port" type of operation for the binding
of flow-capture (i.e., have one process capturing all the data of a
particular type), maf added deinterleave support to the code.

This means that one can run a flow-capture like this;

/usr/local/netflow/bin/flow-capture -V7 -N0 -w/opt/flow/v6 -n287
//9991

and configure their Cat6500 (native IOS config) as such:

ip flow-export source Vlan999
ip flow-export version 6
ip flow-export destination x.y.a.b 9991
mls nde src_address 10.1.2.201 version 7

On a Catalyst OS+MSFC IOS (officially known as 'Hybrid mode'), you would
cofnigure the first three lines on the MSFC (router), and the last line
may or may not be required (syntax is different for CatOS anyhow, you'll
require 'set' at the beginning of the line, obviously).

What this means is that you now can get both the router flows, which are
software routed flows only (like the classifier packet (first packet) of
each flow), as well as the flows from the SP, aka the 'shortcuts', which
make up the bulk of your data in most IP routed networks.

The -V7 option you give to flow-capture now sets the 'output' PDU version,
i.e. the raw flows will all be in version 7, no matter what arrives at the
collector.  You could specify -V6 in the above example, and you'd lose the
encapsulation type data that -V7 adds to the mix (this is no great loss).

I haven't tested this new feature with Catalyst OS (is it required for
hybrid mode?), only with the Native IOS (aka Supervisor IOS, aka
Cosmos...)

So, the short of it is that to get all the necessary data out of a
Catalyst, you need to configure flow-export on both the SP and the RP,
whatever your software.

-- 
andrew fort