[nsp] From the baby to the beast

[Stephen J. Wilcox]

> > dont forget its only one packet for each flow.. i dont know for sure but
> i'd imagine a single gaming session altho udp is continous and therefore
> only one
> > flow and if you make your cache timeout a little larger than usual (most
> ppl use 1min i believe) that will reduce the amount of accounting also.
> 
> Yes it will be, so i'd have to expire active flows in order to maintain
> near-realtime.

how near do you need? even with say a 3 min expiry thats not -that- many flow
accounting packets.. on 5 min your still only the same as the usual period for
averaging bandwidth tho you may have to watch the number of cache entries in
ram!

> > i dont see why the routers cant hack it, guess you can always try it - you
> can turn on the netflow accounting even if your not collecting the data and
> see what
> > the load looks like, be prepared for a quick backout ;)
> 
> With the packets from one of the Ethernets on a Transit supplier (i've hit
> well over 100kpps) I maxed out my transit router in terms of cpu \o/

yeah but in how many unique flows, or in easier to estimate terms - how many
distinct users in each expiration interval, somewhat less than 100000 per
minute...

Steve


> So i ended up having to use switches in Telehouse to DOT1Q the Transit
> Traffic and terminate them directly on the 6509's :-)
> 
> > a final thought is if all you want to do is analyse bandwidth on a per
> host basis can you not achieve this with mac accounting and snmp?
> 
> I need to analyise on a per end-user basis.
> 
> i.e
> 
> 215.32.7.14:3827 --------------> 213.221.175.1:27500
> 215.32.7.14:3829 --------------> 213.221.175.1:27500
> 215.32.7.14:3826 --------------> 213.221.176.2:27650
> 
> Would be 3 flows from one endpoint to two destinations in our lan, therefore
> needs to be flagged up.
> 
> Regards
> 
> Darren.
> 
> 
> > Steve
> >
> >
> > On Tue, 10 Dec 2002, Darren Smith wrote:
> >
> > > Hi folks
> > >
> > > After a bit of advice here :-)
> > >
> > > We currently have Cisco 7401's as our edge routers, backhauling traffic
> back
> > > to a pair of Cat6509's & SUP2's.
> > >
> > > One of the projects this year will involve accounting, i'm assuming via
> > > NETFLOW (unless theres a better way to do it?)
> > >
> > > Basically I need to analyse traffic from thousands of endpoints to the
> few
> > > hundred servers connected the the 6509's.
> > >
> > > In a near-to-realtime basis if possible :-(
> > >
> > > It works fine with small traffic volumes (200mb peak between all edges)
> but
> > > they're looking at expanding this to over 800Mb/sec, at which point my
> ickle
> > > 7401's will surely die ;-)
> > >
> > > To make matters worse it's gaming type traffic, so small packet sizes
> and
> > > high pps counts.
> > >
> > > So two questions (well three really i suppose) :-)
> > >
> > > 1. Has anyone actually got netflow accounting working on Cisco 6509's?
> > > reliably?
> > >
> > > 2. If I went down the GSR route, how does that handle netflow? (It's
> sampled
> > > isn't it?) and how much different is a GSR to traditional Cisco routers
> (i.e
> > > much to learn? - I've used 7xxx/65xx/58xx equipment so far).
> > >
> > > The last question is one that might be better suited to offlist, so I
> don't
> > > cause a riot :-) (i.e Would you even look at Cisco? What about Juniper?)
> > >
> > > Any thoughts?
> > >
> > > Regards
> > >
> > > Darren Smith
> > > Game Digital Ltd
> > >
> > > _______________________________________________
> > > cisco-nsp mailing list  cisco-nsp@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@puck.nether.net
> http://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>