[nsp] netflow on cat6k native?

[Ian Cox]

At 01:21 AM 3/1/2003 +0000, Stephen J. Wilcox wrote:

>OK so I have now hacked up a collector and am getting pretty good data.
>
>The trouble is the analysis produces bad results
>
>I am getting 80% of flows from one particular cat6k, any ideas where the 
>other
>20% are going, they dont seem to be overflowing any udp buffers on the server.

No.

>When I calculate bit rates per interface they are too low by about a 
>factor of
>2 +/- 1
>
>
>So the questions are where do the missing 20% go and do those particular 20%
>really contain the missing 50% of the flow bitrates or is it just 
>calculating it
>wrong to begin with on the pfc before export?

If you compare the SNMP counters to the netflow counters your results can 
be off by up to 30%. Why? Netflow only accounts for the L3 packet length, 
and not the L2 headers on the packet like the SNMP counters. Take the case 
of a 40 Byte IP packet in ethernet, L2 headers 6+6+2+4 = 18 bytes of L2 
that netflow does not account for.


Ian

>Steve
>
>
>On Wed, 19 Feb 2003, Ian Cox wrote:
>
> >
> > The ability to distinguish between v5 NDE from the RP and SP/DFCs was 
> fixed
> > in 12.1(13)E3
> >
> > CSCdz27636 NDE: Add unique engine ID for PFC2 exported traffic
> >
> >
> > The fix for this caveat changes the engine ID to reflect the slot of the
> > forwarding engine and the engine type to be the value "2," indicating that
> > the records were created by the hardware forwarding engine.
> >
> >
> > Ian
> >
> >
> >
> > At 09:45 PM 2/19/2003 +0100, Simon Leinen wrote:
> > >Stephen,
> > >
> > > > K folks I'm on 12.1.13E4 now..
> > >
> > >good.
> > >
> > > > So I get the sp flows now too, but its not good:
> > >
> > > > AS src/dst fields are zero
> > >
> > >Did you say
> > >   ip flow-export version 5 peer-as
> > >or
> > >   ip flow-export version 5 origin-as
> > >?
> > >
> > > > Src interface seems not to be the source, in fact the one I'm
> > > > looking at right now corresponds to an admin down interface.
> > >
> > >Try the following configuration commands:
> > >
> > >   mls flow ip interface-full
> > >
> > >This includes the source VLAN (L3 interface) in the flow mask, and
> > >will make sure that the actual ingress interface is noted for each
> > >flow.
> > >
> > >   mls nde interface
> > >
> > >This causes the NDE process to fill in the input/output interface
> > >fields - but if you have non-zero interface fields you know that
> > >already.
> > >
> > > > RP and SP flows are indistinguishable (no unique src/dst port/ips)
> > >
> > >That's a bug - for this reason I still use NetFlow v7 from the SP,
> > >just so that I can distinguish the SP (PFC) flow stream from the RP
> > >(MSFC) one.
> > >
> > >NetFlow v5 (and also v7 I think) includes engine-type and engine-id
> > >fields that should be used to disambiguate exported flows from
> > >different "engines" within a box.  This is used with Distributed
> > >NetFlow on the 7500/VIP2 and 12000 platforms.  Somehow it seems to
> > >have been forgotten on the Catalyst 6500/7600 OSR when NetFlow v5
> > >support was introduced on the SP (PFC) - the engine-type and engine-id
> > >are zero, whether the flows come from the PFC or from the MSFC.
> > >Hopefully this will be fixed in a future release.
> > >
> > > > Is this right or am I doing something wrong? This is useless!
> > >
> > >Well, for me it has been extremely useful (and the numbers look
> > >correct too :-)
> > >
> > >Regards,
> > >--
> > >Simon.
> > >_______________________________________________
> > >cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > >http://puck.nether.net/mailman/listinfo/cisco-nsp
> > >archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > http://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> >