Re: Service Provider NetFlow Collectors

[H I Baysal <hibaysal () gmail com>]

Hi Saku,

aggregate [DSTAS]: label, dst_as, peer_dst_as, out_iface

aggregate [SRCAS]: label, src_as, peer_src_as, in_iface

aggregate[IP]: label, dst_as, src_host, out_iface, in_iface


And a script goes over this output to relate ifindex to ifalias from 
also influxdb SNMP counter DB (where the ifalias is stored) ( script has 
to be smart to know which port flows to store, as in edge ports for 
hosters for example cause you wouldnt want ibgp flow info in your DST AS 
database)


I'm attaching only the graph for IP aggregate series. And Cpu never goes 
above 30%.

As i said, per IP, per iface, per dst As information stored, cant get 
more pretties and betetr than this for a capacity manager :D

And if you add another tag adding a price per mbit to a carrier/port, 
you can find out how much a single customer is costing you for network 
usage based on per IP aggregation !!!!!!!!!!!!!!!!!!!!

You have to be "smart" with duration of your retention policy and 
continuous queries though :D


(again, Thanks Paulo for PMACCT!!! )


( and as an addition, we have a telegram bot you send a message to like 
"/dst as#",
and this pulls the graph from grafana, renders it and sends it to 
telegram chat :D
I worked at a few Hosting companies, and I haven't seen anything like 
this :D )


The idea is to put this whole thing on github but i need to make time 
for that...
And "aint nobody got time for that" :P



On 02-01-19 13:59, Saku Ytti wrote:
> Hey,
>
>
> On Wed, 2 Jan 2019 at 14:40, H I Baysal <hibaysal () gmail com> wrote:
>
> > That absolutely depends on the amount of TAGs you use, and how you aggregate, etc.
> > I am collecting DSTAS, SRCAS, en DST AS per IP. And influx is not even sweating a single drop....
> >
> > We have a 4 Tbps of traffic during peak, and as well as pmacct and influxdb or running very very smooth.
> How many series do you have in the DB?
>
> Your explanation makes it unclear to me what labels you have 'per IP'
> is ambiguous to me. If only DST_IP is tag and you have low amount of
> IPs in or behind your network, it seems very feasible indeed.