neutron

Bug #1045617
Comment #3

Comment 3 for bug 1045617

Revision history for this message

dan wendlandt (danwent) wrote on 2012-09-05:

This patch looks like a good fix for the issue described above, but I'm concerned we have a more general issue around the implementation not being consistent with what we at least originally envisioned for the spec (see host_routes attribute of a subnet: http://wiki.openstack.org/QuantumV2APIIntro).

At issue are scenarios where a subnet has a gateway, but this gateway is not the default gateway. This about a scenario where all VMs have two NICs. The first NIC is plugged into network public, which has a gateway IP of 9.9.9.1, and acts as the default gateway for VM traffic. The second VM NIC is plugging into network private, which is specific to the tenant. This network has a gateway IP as well of 17.16.20.1. This gateway IP is not the default gateway for VMs (otherwise the VMs would get two default gateways), it is simply a gateway that provides access to the a particular IP prefix (e.g., 172.16.19.0/24). For example, this might be a remote network in the customer premises.

The original design for host_routes handled this by saying that a subnet's host_routes would default to [ { 'destination': 0.0.0.0/0, nexthop: <gateway-ip>}], but someone who wanted a gateway that was not a default gateway could specify host routes that did include a default route, and instead just had a more specific route, for example: [ {'destination': '172.16.19.0./24', 'nexthop': <gateway-ip>}]

It seems like the current logic in db_base_plugin_v2.py doesn't create any route by default, and so as a result, dnsmasq generates one every time, putting us in the situation we see here.

Thinking a bit more, I think there's even a single VIF case where this applies. What if you wanted a private network that was just uplinked to a remote subnet in another data center, but was not supposed to have a default gateway at all. Even with the current change, I think its impossible to have a gateway-ip and not have it be the default gateway.

Does this issue make sense to people? Are there other suggestions on how we should handle it?

At issue are scenarios where a subnet has a gateway, but this gateway is not the default gateway.  This about a scenario where all VMs have two NICs.  The first NIC is plugged into network public, which has a gateway IP of 9.9.9.1, and acts as the default gateway for VM traffic.  The second VM NIC is plugging into network private, which is specific to the tenant.  This network has a gateway IP as well of 17.16.20.1.  This gateway IP is not the default gateway for VMs (otherwise the VMs would get two default gateways), it is simply a gateway that provides access to the a particular IP prefix (e.g., 172.16.19.0/24).  For example, this might be a remote network in the customer premises.

It seems like the current logic in db_base_plugin_v2.py doesn't create any route by default, and so as a result, dnsmasq generates one every time, putting us in the situation we see here.

Thinking a bit more, I think there's even a single VIF case where this applies.  What if you wanted a private network that was just uplinked to a remote subnet in another data center, but was not supposed to have a default gateway at all.  Even with the current change, I think its impossible to have a gateway-ip and not have it be the default gateway.

Does this issue make sense to people?  Are there other suggestions on how we should handle it?