VR replaces connected routes

Bug #1755414 reported by Volodymyr Litovka
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Opinion
Wishlist
Unassigned

Bug Description

Hi colleagues,

The idea behind this design is to easily switch VM between different address scopes (e.g. "grey" addresses in Subnet-1 and "white" in Subnet-2), using same port/MAC (which always is in E-Network).

If VR connected to subnets belonging to same network (preformatted scheme also is at https://pastebin.com/AesqkcXa) :

                   E-Network
  +------------------------------------------+
    Subnet-1 Subnet-2
  +---+----+--+ +----+------+
      | | +----+ |
   VM-+ | | | |
           +--------+ VR +------------+
                   /| |\
         qr-64.. -/ 0----+ \- qg-16..

using Subnet-1 as LAN connection and Subnet-2 as external gateway connection, then Neutron swaps connected route to Subnet-1 with same route but through Subnet-2 interface (3rd entry in the following sequence):

14:45:18.043 Running command: ['ip', 'netns', 'exec', 'qrouter-UUID', 'ip', '-4', 'addr', 'add', '25.0.0.1/8', 'scope', 'global', 'dev', 'qr-64c53cf8-d9', 'brd', '25.255.255.255']
14:45:19.815 Running command: ['ip', 'netns', 'exec', 'qrouter-UUID', 'ip', '-4', 'addr', 'add', '51.x.x.x/24', 'scope', 'global', 'dev', 'qg-16bdddb1-d5', 'brd', '51.x.x.255']
14:45:20.283 Running command: ['ip', 'netns', 'exec', 'qrouter-UUID', 'ip', '-4', 'route', 'replace', '25.0.0.0/8', 'dev', 'qg-16bdddb1-d5', 'scope', 'link']
14:45:20.919 Running command: ['ip', 'netns', 'exec', 'qrouter-UUID', 'ip', '-4', 'route', 'replace', 'default', 'via', '51.x.x.254', 'dev', 'qg-16bdddb1-d5']

which makes it impossible to communicate between VMs in Subnet-1 with the VR.

Proposed solution:

When creating VR, use "ip route add ... metric <LOWER>" for extra subnets of the interfaces. To achieve this:
- function add_route() in ip_lib.py contain unconditional arg "replace" and add other args from function's parameters. If, finally, var "args" contains keyword "metric", then change keyword "replace" with "add".
- when creating VR, add keyword "metric 20" (can be anything lower than connected metric) to all extra subnets.

This will fix routing in case of conflict, will preserve routing model if there is no conflict and will preserve compatibility with other functions calling add_route (no keyword "metric" - no changes in behavior).

Openstack: Pike
Neutron: 11.0.2
Ubuntu: 16.04

Thank you.

Tags: rfe neutron
description: updated
description: updated
description: updated
description: updated
description: updated
description: updated
description: updated
description: updated
description: updated
description: updated
description: updated
Revision history for this message
zhaobo (zhaobo6) wrote :

Thanks for raise this. It sounds like a new enhance for neutron. I will tag it as rfe and discuss during the driver meetings.

tags: added: rfe
Miguel Lavalle (minsel)
Changed in neutron:
importance: Undecided → Wishlist
Revision history for this message
Miguel Lavalle (minsel) wrote :

I don't think I understand the use case behind this proposal. From a user point of view, what is it that you are trying to accomplish? Would you provide more details?

Revision history for this message
Volodymyr Litovka (doka.ua) wrote : Re: [Bug 1755414] Re: VR replaces connected routes

Hi Miguel,

thanks for the responce.

Use case is the ability to easily switch VM between two subnets with
different address spaces, using same port on VM.

In the diagram, at different times VM can be connected:
- EITHER to Subnet1 (e.g. RFC1918 address space) and, thus, be NATed
using VR
- OR to Subnet2, and, thus, be globally accessible without VR

using single port, thus, having at the every one moment of time, just
one address on the port (either Subnet1's or Subnet2's), not two
addresses simultaneously.

This simplifies configuration on the VM (simple MAC-port binding (as
there is always one port), clear configuration as one port is, e.g.
single point of firewall rules), simplifies management and operations of
Openstack (one port per VM instead two ones per VM for such topologies)
and makes overall configuration is more clear.

Thank you.

On 6/15/18 4:43 PM, Miguel Lavalle wrote:
> I don't think I understand the use case behind this proposal. From a
> user point of view, what is it that you are trying to accomplish? Would
> you provide more details?
>

--
Volodymyr Litovka
   "Vision without Execution is Hallucination." -- Thomas Edison

Revision history for this message
Slawek Kaplonski (slaweq) wrote :

Due to lack of any activity in this RFE since more than 1 year, I'm going to close it for now. If You would be still interested in implementing this and would like to continue discussion on that, feel free to reopen it and ping me (slaweq) on irc.

Changed in neutron:
status: New → Opinion
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.