[RFE] Can not create router gateway without external_fixed_ips

Bug #1748132 reported by Guoshuai Li on 2018-02-08
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Guoshuai Li

Bug Description

In a public cloud environment, the external network may be the public network, Users may want Router Gateway Port without IP, in order to save public IP network. VM access to public network through floating IP only.

Neutron currently does not support this configuration, I hope available through this api:
    "router": {
        "name": "router1",
        "external_gateway_info": {
            "network_id": "xxx",
            "external_fixed_ips": []

Changed in neutron:
assignee: nobody → Guoshuai Li (liguoshuai1990)
status: New → In Progress
Boden R (boden) on 2018-02-08
tags: added: api-ref
Changed in neutron:
importance: Undecided → Low

Why do you want router with external_gateway_info without external_fixed_ips? Is it useful external_gateway_info without external_fixed_ips?

Ah, I see. So you want to get floating IP. However it's new feature not bug.

tags: added: rfe
Guoshuai Li (liguoshuai1990) wrote :

yes, it's new feature...
Brian wants me to describe this.

Akihiro Motoki (amotoki) on 2018-02-09
tags: added: rfe-confirmed
Akihiro Motoki (amotoki) wrote :

This sounds a reasonable request.

We need to clarify what is the expected behavior when an external gateway has no IP address.
Is the expected behavior that no SNAT connection is allowed and a VM behind such router cannot connect to outside unless FIP is associated?

Guoshuai Li (liguoshuai1990) wrote :

Yes, I really think so, because there is no default snat ip, so I can only rely on floating IP.

Miguel Lavalle (minsel) on 2018-02-16
tags: added: rfe-triaged
removed: rfe-confirmed
YAMAMOTO Takashi (yamamoto) wrote :

it sounds reasonable to me.

Akihiro Motoki (amotoki) on 2018-02-16
summary: - Can not create router gateway without external_fixed_ips
+ [RFE] Can not create router gateway without external_fixed_ips
Brian Haley (brian-haley) wrote :

Another way to save public IP addresses is to use subnet service types, https://docs.openstack.org/ocata/networking-guide/config-service-subnets.html - using that you would have multiple subnets on the external network, but some can only be used for certain types of ports. That way a floating IP subnet could use global addresses, but a router gateways could use private addresses. That way it is still possible to verify reachability of each router since it has an IP, which would not be possible with this proposed change.

Have you tried using this existing extension to see if it can meet your needs? If it doesn't then it should be possible to approve this change as long as it doesn't change the default behavior.

Guoshuai Li (liguoshuai1990) wrote :

Thanks Brian.
I did not notice the subnet service types, I think this is a good solution. I will try behind.
The difference between these two solutions lies in the physical network requirements. Multiple subnets may require multiple gateways or static routing or routing protocols. I think my thoughts may seem simpler.

Miguel Lavalle (minsel) wrote :

@Guoshuai Li,

Did you try the the subnet service types approach suggested by Brian? Did it meet your needs?

Guoshuai Li (liguoshuai1990) wrote :

I'm sorry, I haven't tried yet.
I will try next week.

Guoshuai Li (liguoshuai1990) wrote :

@Miguel Lavalle @Brian Haley

Service-subnets can save me public network ip, but I encountered two problems during the experiment (I use netwroking-ovn plugin):

1. I need to configure a static backhaul route on the external forwarding device.
   When I configure multiple routes, I need to configure multiple static routes on on the external switch.
2. When I don't configure floating ip, my traffic defaults to private address as snat,
   Then transparently transmitted to the public network, No other equipment helped me snat again.
   I actually want this traffic not to go out from the gateway node.

The first problem can be solved using direct routes, although I prefer to publish routes similar to ospf.
The second question I did not think of how to do.


Changed in neutron:
importance: Low → Wishlist
Akihiro Motoki (amotoki) wrote :

@Guoshuai Li

I have a question. Your proposal works to save public IP addresses, but the default IP address of a router gateway will be assigned from an external network. So it is up to users. If you save public IP addresses **as an operator**, you cannot save public IP addresses by this proposal (as changing the default value impacts much). What is the thing you would like to achieve in this RFE? I would like to clarify this to move this forward.

Miguel Lavalle (minsel) wrote :

@Guoshuai Li

Would you help us clarifying further the use case you have in mind? Still interested in pursuing this?

YAMAMOTO Takashi (yamamoto) wrote :

maybe a provider can give users an incentive to save ips. eg. make them pay for each ips.
anyway it's better to have a clarification from the submitter.

Guoshuai Li (liguoshuai1990) wrote :

I am sorry, I am not clear about your question.
The default IP address of a router gateway will be assigned from an external network. I just hope that users can economize it.
This is not by modifying the default value, but through a new parameter of the API: {'external_ fixed_ips' :[]}

Miguel Lavalle (minsel) wrote :

After further discussion during today's drivers meeting, we have decided to approve this RFE

tags: added: rfe-approved
removed: rfe rfe-triaged
Miguel Lavalle (minsel) wrote :

We deemed this as a good starter RFE. As such, it will be advertised in the next Neutron weekly meeting so new contributors can implement it

Miguel Lavalle (minsel) wrote :

@Guoshuai Li

Do you plan to implement this RFE?

Guoshuai Li (liguoshuai1990) wrote :

@ Miguel Lavalle (minsel)

I have some previous attempts:


I used to learn about the networking-ovn plugin. I can try to implement it via ovn, but I am not very proficient with neutron drivers.

Thanks, Guoshuai

Change abandoned by Miguel Lavalle (<email address hidden>) on branch: master
Review: https://review.openstack.org/542106
Reason: Given lack of follow up, abandoning this patch. The author can restore it if he wants to continue working on it

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers