Traffic accounting with iptables - Revision history

Kir: Reverted edits by TermPaperServices (talk) to last revision by Kir

2011-12-15T09:28:12Z

Reverted edits by TermPaperServices (talk) to last revision by Kir

Kir: Reverted edits by 109.73.68.18 (Talk) to last revision by Kir

2011-09-28T09:35:14Z

Reverted edits by 109.73.68.18 (Talk) to last revision by Kir

109.73.68.18: yrkJGg web20power.txt;1;1

2011-09-28T09:34:15Z

yrkJGg web20power.txt;1;1

Kir: Reverted edits by 116.71.15.55 (Talk) to last revision by 217.225.194.26

2011-08-16T06:55:36Z

Reverted edits by 116.71.15.55 (Talk) to last revision by 217.225.194.26

116.71.15.55: /* Solution */

2011-08-16T06:13:09Z

‎Solution

217.225.194.26: /* Sample php script to store the trafficlog in a database */

2011-07-04T16:13:35Z

‎Sample php script to store the trafficlog in a database

Robferrer: /* Generate a traffic.log */

2008-05-14T11:05:34Z

‎Generate a traffic.log

Robferrer: /* Generate a traffic.log */ - cron interval warning

2008-05-14T11:05:20Z

‎Generate a traffic.log: - cron interval warning

Botinki Kira: Robot: Automated text replacement (-VE +container)

2008-03-11T11:36:54Z

Robot: Automated text replacement (-VE +container)

Botinki Kira: Robot: Automated text replacement (-VEs +containers)

2008-03-11T09:49:47Z

Robot: Automated text replacement (-VEs +containers)

@@ Line 2: / Line 2: @@
 using iptables.
-yrkJGg web20power.txt;1;1
+== Situation description ==
 == Solution ==

@@ Line 2: / Line 2: @@
 using iptables.
-== Situation description ==
+yrkJGg web20power.txt;1;1
 == Solution ==

@@ Line 29: / Line 29: @@
 it remains right. But if you restart your [[hardware node]], all the rules and consequently statistics are dropped.
 So it is recommended to
 * run some cron job that dumps statistics to some file
 * add init script that creates iptables rules on [[HN]] start.

@@ Line 29: / Line 29: @@
 it remains right. But if you restart your [[hardware node]], all the rules and consequently statistics are dropped.
 So it is recommended to
 * run some cron job that dumps statistics to some file
 * add init script that creates iptables rules on [[HN]] start.

@@ Line 162: / Line 162: @@
   $MySQL_Passw="INSERT-YOUR-MYSQL-PASSWORD-HERE";
-  mysql_connect("$MySQL_Host","$MySQL_User","$MySQL_Passw");
+  mysql_connect($MySQL_Host,$MySQL_User,$MySQL_Passw);
   $HN=trim(addslashes($_GET["HN"])); // Hardware Node
-  $handle = fopen ("tmp/$HN-traffic","r");
+  $handle = fopen ("tmp/{$HN}-traffic","r");
   while (!feof($handle)) {
     $line = fgets($handle, 4096);
     list($date,$time,$ip,$traffic)=explode(" ",$line);
-    if($traffic>0) {mysql($db,"insert into Traffic (ip,measuringtime,bytes) values('$ip','$date $time','$traffic')");}
+    if($traffic>0) {mysql($db,"insert into Traffic (ip,measuringtime,bytes) values('{$ip}','{$date} {$time}','{$traffic}')");}
+  }
   fclose($handle);

← Older revision	Revision as of 09:28, 15 December 2011
(No difference)

@@ Line 116: / Line 116: @@
 === Generate a traffic.log ===
 Please use crontab to run this script once per hour or day to collect your traffic statistics.
 (Warning, the counters can overflow if there is too much traffic within that period. Would recommend 15 minute intervals if you expect a lot of traffic)
 <pre>

@@ Line 1: / Line 1: @@
-Suppose you need to know how much traffic your [[VE]]s eat. It can be easily done
+Suppose you need to know how much traffic your [[container]]s eat. It can be easily done
 using iptables.
 == Situation description ==
-Let's consider the very simple situation: one VE with one IP address on the [[Hardware Node]]
+Let's consider the very simple situation: one container with one IP address on the [[Hardware Node]]
-with only one network interface. To be more exact, assume that [[VE]] ID is <tt>200</tt>, the IP address of the [[HN]]
+with only one network interface. To be more exact, assume that [[container]] ID is <tt>200</tt>, the IP address of the [[HN]]
-is <tt>192.168.0.56</tt>, the network interface name is <tt>eth0</tt>, and the IP address of the [[VE]] is <tt>192.168.0.117</tt>.
+is <tt>192.168.0.56</tt>, the network interface name is <tt>eth0</tt>, and the IP address of the [[container]] is <tt>192.168.0.117</tt>.
-You wish to know how many bytes VE 200 eats. One more assumption is that there are no iptables rules
+You wish to know how many bytes container 200 eats. One more assumption is that there are no iptables rules
 on HN now. All these assumption are only for clarity!
 == Solution ==
-Almost any traffic that goes to and from a VE can be catched by FORWARD chain of iptables module in [[VE0]],
+Almost any traffic that goes to and from a container can be catched by FORWARD chain of iptables module in [[container0]],
 thus we add such rules:
 <pre>
@@ Line 18: / Line 18: @@
 </pre>
 It means that all traffic forwarded to IP 192.168.0.117 and from IP 192.168.0.117 will be accounted.
-To obtain current traffic usage of VE you can issue the command:
+To obtain current traffic usage of container you can issue the command:
 <pre>
 # iptables -nv -L FORWARD
@@ Line 26: / Line 26: @@
   1052            all  --  *      *       0.0.0.0/0            192.168.0.117
 </pre>
-'''Bytes''' column is the column we need. It's worth saying, that restarting a VE doesn't affect accounting,
+'''Bytes''' column is the column we need. It's worth saying, that restarting a container doesn't affect accounting,
 it remains right. But if you restart your [[hardware node]], all the rules and consequently statistics are dropped.
 So it is recommended to
@@ Line 38: / Line 38: @@
 You will get the exact value of the packet and byte counters, instead of only the rounded number in K’s (multiples of 1000) M’s (multiples of 1000K) or G’s (multiples  of  1000M).
-As is easy to see, it's not per-VE statistic, but rather per-IP statistic. Thus you must be careful
+As is easy to see, it's not per-container statistic, but rather per-IP statistic. Thus you must be careful
-then changing VE IP addresses, otherwise you'll get mess of results.
+then changing container IP addresses, otherwise you'll get mess of results.
-By saying ''almost any traffic'' I mean that traffic between a [[VE]] and [[VE0]] is not accounted by rules above.
+By saying ''almost any traffic'' I mean that traffic between a [[container]] and [[container0]] is not accounted by rules above.
 Not sure if it can be useful for anybody, but to account such traffic these rules are needed:
 <pre>
@@ Line 83: / Line 83: @@
 more complicated situations.
-; More than one VE on the node
+; More than one container on the node
-: Just add the rules like above for each VE IP.
+: Just add the rules like above for each container IP.
-; More than one IP per VE.
+; More than one IP per container.
-: For each IP add the rules like above. When counting the complete traffic of a VE you have to summarize over all IPs that this VE owns.
+: For each IP add the rules like above. When counting the complete traffic of a container you have to summarize over all IPs that this container owns.
 ; More interfaces on the HN.

@@ Line 95: / Line 95: @@
 Here are some scripting ideas
-=== Get CTIDs of all running VEs ===
+=== Get CTIDs of all running containers ===
 <pre>
 host2:~/bin# cat vz-all-running
@@ Line 101: / Line 101: @@
 </pre>
-=== Get all IPs of running VEs ===
+=== Get all IPs of running containers ===
 <pre>
 host2:~/bin# cat vz-all-running-ip
@@ Line 127: / Line 127: @@
   # reset the counter
   iptables -Z
-  # update the iptables rules if there is a any change in VEs
+  # update the iptables rules if there is a any change in containers
   ./vz-iptables-create-rules
@@ Line 185: / Line 185: @@
 === Notes ===
-As you see this way can be time-consuming in case of a big number of VEs.
+As you see this way can be time-consuming in case of a big number of containers.
 So if anybody has scripts that automate all the process — you are welcome!