[nsp] netflow on cat6k native?

[Stephen J. Wilcox]

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.

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?

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/
>