Hi Mike, please follow me inline:
On Thu, Jun 14, 2007 at 07:30:49AM -0500, TCIS List Acct wrote: > We are looking to use pmacct for traffic billing in a Data Center > environment. > A few general questions: > > 1. We plan to use pmacct via libpcap and use SPAN/mirror ports to sniff > traffic. > However, we have multiple "paths" in and out of our network. With this in > mind, is it possible to set up multiple pmacct instances (listening on > different > interfaces) but still have the data inserted/aggregated into the same MySQL > database while avoiding locking/row duplication issues? Yes, this is possible. Tipically you can avoid row duplications by planning what has to be mirrored. Purely as an example you can mirror a) inbound traffic only coming from b) edge interfaces of the aggregation switches (ie. the ones facing directly the customers) and the exit points to your core network. Locking could be limited by using an underlying RDBMS infrastrucure supporting row locks, ie. InnoDB tables while using MySQL or - i mean, alternatively - PostgreSQL. > 2. When specifying the networks to "watch for", if I say "192.168.1.0/24" in > the > .conf file, when it records data into the MySQL database, I assume it is > doing > so on a /32 basis (for each individual IP in that network range?) It depends on the aggregation and pretty much all the typical scenarios are covered: if aggregating over the src_host and/or dst_host primitives, it will watch for those network and write down the /32 hosts. If aggregating over the src_net and/or dst_net primitives it will write down the subnet (without the mask: but there is a plan to include it aswell ...). > 3. We want to _exclude_ traffic generated on the local network from being > recorded. That is, we only care about recording traffic to/from the Internet > to/from the hosts on the network. So, is there a way to say "Ignore traffic > between hosts on x.x.0.0/19 and other hosts on x.x.0.0/19"? Yes, using pmacctd, for example, you can avail of the pcap_filter directive which accepts a libpcap/tcpdump style filter to shortlist specific traffic. > 4. Our goal is to record traffic totals on a per-IP address basis every 5 > minutes into the SQL database. It would also be nice to be able to summarize > the per-IP data that has been collected in the database on a specific subnet > basis (each customer is assigned a distinct subnet, so to get totals on a per > customer basis, this is necessary). Does pmacct have any facility for this, > or > is it left up to me to write something myself? A better idea could be to avoid the summarization (not supported by pmacct but the main point is that it's resource-consuming) and maybe use two SQL tables in parallel, each feeded by a distinct plugin. One aggregating on a host basis, the other on a subnet basis. This way you can also cope with different timeframe requirements. Cheap and easy. You will need some more space on the disk and that's really it. > 5. Is it also possible to record into the database, on a per-IP address > basis, a > running counter of the "top talkers" -- e.g. top src ip -> top dst ip based > on > traffic volume? (e.g. top 10, top 25, etc) SQL and well-indexed tables are your friend for such tasks. An idea could be to pre-arrange a VIEW - get a look to some of the PDFs online, there are some SQL statements that could be of help to start with. > 6. Looking at the default pmacct-create-db_v1.mysql, I see columns for ip_src > and ip_dst. If I'm going to use this for traffic totals per-IP, does each > "conversation" or "flow" from the ip_src get recorded as a separate row in > the > table? (so if ip_src 192.168.1.5 is talking to 100 different hosts, I get 100 > rows, one for each ip_dst host, every 5 minutes inserted into the table for > ip_src 192.168.1.5) It depends. And again the aggregation method is involved: if you aggregate on the src_host/dst_host couple, then yes, each flow will appear in your database - but that's what YOU are asking for. If aggregating only on the src_host, you will get a single entry per host which will include the originated traffic only; if aggregating only on the dst_host primitive, you will get a single entry per host which will include the terminated traffic only; if aggregating only on the sum_host primitive, you will get a single entry per host which will include both the originated and the terminated traffic; same applies for the src_net/dst_net primitives. Cheers, Paolo _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
