Open Stack

Hi Brian,

For iptables rules, see below

Yes the only way to setup metering labels/rules is the neutronclient. I agree with you about the future
enhancement.

Regards,

Sylvain

----- Original Message -----
From: "Brian Haley" <brian.haley at hp.com>
To: "Sylvain Afchain" <sylvain.afchain at enovance.com>
Cc: openstack-dev at lists.openstack.org
Sent: Thursday, July 18, 2013 4:58:26 AM
Subject: Re: Change in openstack/neutron[master]: Add method to get iptables traffic counters

> Hi Sylvain,
>
> I think I've caught-up with all your reviews, but I still did have some
> questions on the iptables rules, below.
> 
> One other question, and maybe it's simply a future enhancement, but is the only
> way to setup these meters using neutronclient?  I think being able to specify
> these in an .ini file would be good as well, which is something I'd want to do
> as a provider, such that they're always there, and actually not visible to the
> tenant.
> 
> On 07/11/2013 10:04 AM, Sylvain Afchain wrote:
>> Hi Brian,
>> 
>> You're right It could be easier with your approach to get and keep the traffic counters.
>> 
>> I will add a new method to get the details of traffic counters of a chain.
>> https://review.openstack.org/35624
>> 
>> Thoughts?
>> 
>> Regards,
>> 
>> Sylvain.
>> 
>> ----- Original Message -----
>> From: "Sylvain Afchain" <sylvain.afchain at enovance.com>
>> To: "Brian Haley" <brian.haley at hp.com>
>> Cc: openstack-dev at lists.openstack.org
>> Sent: Thursday, July 11, 2013 11:19:39 AM
>> Subject: Re: Change in openstack/neutron[master]: Add method to get iptables traffic counters
>> 
>> 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           

> So are these two used to separate out what you don't want to count from what you
> want to count?  Seems the jump to the r-aef1456343 will filter, then the
> r-badf566782 will count per-subnet?  I'm just trying to understand why you're
> splitting the two up.

No here, there are two rules only because there are two labels. In the chain of each 
label you will find the label's rules. 

>> 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      

> These two chains aren't really doing anything, and I believe their packet/byte
> counts would be duplicated in the calling rules, correct?  If that's the case I
> don't see the reason to jump to them.  Our performance person always reminds me
> when I increase path length by doing things like this, so removing unnecessary
> things is one of my goals.  Of course we're doing more work here to count
> things, but that needs to be done.

I recently change this(according to your remarks on iptables accounting), so now there is a 
rule which is used to count the traffic for a label. A mark is added one this rule to be 
sure to not count it twice. You can check the metering iptables drivers.
https://review.openstack.org/#/c/36813/

>> 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 */     

> This has excluded (!) certain subnets, then allowed anything else to pass through.

Correct, I don't want to count the traffic in/out for these network and I want to count anything else.

>> 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 */

> This is only counting packets going to a certain subnet.

Correct.

> I'm still trying to get all these changes running in devstack, so sorry for all
> the questions.

No problem, and thanks for your reviews.

Sylvain.

> Thanks,

> -Brian

> 
> 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.haley at hp.com>
> To: "sylvain afchain" <sylvain.afchain at enovance.com>
> Cc: openstack-dev at 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
>