Hi Brian,
First thanks for the reviews and your detailed email.
Second I will update the blueprint specs. as soon as possible, but for example
it will look like that:
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
55 245 metering-r-aef1456343 all -- * * 0.0.0.0/0
0.0.0.0/0 /* jump to rules the label aef1456343 */
55 245 metering-r-badf566782 all -- * * 0.0.0.0/0
0.0.0.0/0
Chain metering-l-aef1456343 (1 references) /* the chain for the label
aef1456343 */
pkts bytes target prot opt in out source
destination
Chain metering-l-badf566782 (1 references) /* the chain for the label
badf566782 */
pkts bytes target prot opt in out source
destination
Chain metering-r-aef1456343 (1 references)
pkts bytes target prot opt in out source
destination
20 100 RETURN all -- * * 0.0.0.0/0
!10.0.0.0/24 /* don't want to count this traffic */
0 0 RETURN all -- * * 0.0.0.0/0
!20.0.0.0/24 /* don't want to count this traffic */
25 145 metering-l-aef1456343 all -- * * 0.0.0.0/0
0.0.0.0/0 /* count the remaining traffic */
Chain metering-r-badf566782 (1 references)
pkts bytes target prot opt in out source
destination
0 0 metering-l-badf56678 all -- * * 0.0.0.0/0
30.0.0.0/24 /* want to count only this */
Of course the in/out interfaces will be set in order to get the ingress or the
egress traffic.
I agree with you I could add a single rule to the chain of the label and get
the traffic of the first entry, though I found this approach less generic.
I mean, to be forced to add a rule at the top of a chain to get its traffic. My
approach is I don't want the counters of a specific rule but I want to count
the traffic going through the chain.
Thoughts?
Regards,
Sylvain.
----- Original Message -----
From: "Brian Haley" <brian.ha...@hp.com>
To: "sylvain afchain" <sylvain.afch...@enovance.com>
Cc: openstack-dev@lists.openstack.org
Sent: Thursday, July 11, 2013 2:30:24 AM
Subject: Re: Change in openstack/neutron[master]: Add method to get iptables
traffic counters
On 07/08/2013 01:10 PM, Sylvain Afchain (Code Review) wrote:
> Sylvain Afchain has posted comments on this change.
>
> Change subject: Add method to get iptables traffic counters
<snip>
> --
> To view, visit https://review.openstack.org/35624
Hi Sylvain,
Instead of trying to ask questions directly in the review itself (since it will
mess-up formatting) I'll just send this to you and the list since I had some
questions on the traffic counter changes you've been doing.
First, thanks for working on this, it's definitely something I'm interested in,
and I'm trying to review all your changes.
Second, do you have more than just the short description from the blueprint for
how the iptables chains/rules will look like when created? I'm still a little
confused with this change (above) and how it's matching chains to get
packet/byte statistics. I'm thinking it can be done within a single chain so
that you can do an 'iptables -L $chain' call to get just what you need, instead
of parsing the entire table.
For example, I did something similar in Nova (out of tree), and it used a
single chain per-VM, such that you could get it's statistics with a single
iptables call like:
(sorry if this wraps)
$ sudo iptables -t mangle -L nova-meter-output-91 -n -v -x [-Z]
Chain nova-meter-output-91 (1 references)
pkts bytes target prot opt in out source
destination
805210 247931149 all -- * * 0.0.0.0/0
0.0.0.0/0 /* inst-91 packets transmitted total */
15510 964648 all -- * * 0.0.0.0/0
x.y.0.0/16
21282 3075403 all -- * * 0.0.0.0/0
x.z.0.0/16
[...]
None of the rules in the chain has a jump target, so they simply count
packets/bytes as they pass through, and the chain is called from a single
location based on IP address, so in iptables-save format it looks like this:
-A nova-meter-output -s $my_ip/32 -i bridge1 -j nova-meter-output-91
-A nova-meter-output-91 -m comment --comment "inst-91 packets transmitted total"
-A nova-meter-output-91 -d x.y.0.0/16
-A nova-meter-output-91 -d x.z.0.0/16
[...]
Obviously with Neutron, and doing this at the router egress, things change, but
I think it could still be done in a single OUTPUT chain in the filter table.
Thoughts?
-Brian
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
