Ask Your Question

Neutron metering agent: excluding traffic based on target IP?

asked 2016-02-01 03:58:45 -0500

sxc731 gravatar image

updated 2016-02-19 02:36:34 -0500

I'm trying to measure outbound traffic from a tenant's private network towards the public network, yet exclude that bound for a specific target on the public network (which happens to host an object storage gateway). Let:

  • source IP (on private net) =
  • target address to exclude = (on public network

Here are rules (I realize the exclude rules may not make sense but I wanted to cover all bases):

neutron meter-label-create testvm_outbound
neutron meter-label-rule-create --direction egress testvm_outbound
neutron meter-label-rule-create --direction egress testvm_outbound --excluded
neutron meter-label-rule-create --direction ingress testvm_outbound --excluded

This correctly catches all traffic egressing from onto the public network but there seems to be no way to exclude traffic bound for Is there a way to achieve this?

I'm running Kilo with Neutron VLAN-segregation. The doc (I could find) is here: and here

edit retag flag offensive close merge delete

1 answer

Sort by ยป oldest newest most voted

answered 2016-02-05 06:54:55 -0500

sxc731 gravatar image

I couldn't find any way to achieve the above by means of neutron meter-label-rule which is a shame. If you find anything, please do contribute so others can benefit...

So I had to resort to configuring the guest to egress the traffic I need excluding via a separate source IP (here the intention is to use but read below on IP assignment) so this traffic doesn't get metered. Here's how I did it:

$ neutron port-list
# figure out the right port then add an IP address (on the same subnet) as follows:
$ neutron port-update --fixed-ip subnet_id=<subnet_id>,ip_address=\
   --fixed-ip subnet_id=<subnet_id>,ip_address= <port_id>

Now this gets a little tricky: the port has both IPs (check with neutron port-show <port_id>) but I haven't found a way to control how they get assigned to the VM (seems a "collaboration" between cloud-init and DHCP). In any case, what happened here is that the instance's eth0 got its IP address swapped pretty much instantly to the one I wanted to use for the separate traffic. It's a bit annoying because I had to reconfigure things (including the above metering-label-rule) but at least the behaviour appears deterministic, even after a number of reboots.

So once you've worked out which IP your guest now has for its primary NIC, it's a matter of configuring a sub-interface to use for the secondary IP, and an appropriate route. Here's how I did it (this is a Ubuntu 14.04.3 guest):

$ cat << EOF | sudo tee /etc/network/interfaces.d/eth0:1.cfg
auto eth0:1
    iface eth0:1 inet static
    up ip route add via dev eth0:1 src
$ sudo ifup eth0:1

Check with ip route list that the routing is as intended. A final check that the metering is working as expected is also highly recommended (if things don't behave, tcpdump is your friend, as ever...). Finally reboot the box a couple of times to ensure the IP assignment works across.

edit flag offensive delete link more


Word of caution: in the above workaround it appears the added IP address doesn't fully inherit all the security groups from its sibling IP, despite sharing the same port (and sec-groups being assigned at port-level). We had to add some explicit INGRESS rules with the new IP on a sibling box. Bug?

sxc731 gravatar imagesxc731 ( 2016-03-09 02:08:36 -0500 )edit

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower


Asked: 2016-02-01 03:58:45 -0500

Seen: 575 times

Last updated: Feb 19 '16