You are browsing a read-only backup copy of Wikitech. The live site can be found at wikitech.wikimedia.org

News/CloudVPS NAT change: Difference between revisions

From Wikitech-static
Jump to navigation Jump to search
imported>Arturo Borrero Gonzalez
(draft no longer!)
 
imported>Arturo Borrero Gonzalez
(→‎See also: add reference to the original enhancement proposal)
 
Line 10: Line 10:
== What is changing ? ==
== What is changing ? ==


Previous to this change, all traffic from CloudVPS virtual machine instances heading to the internet appeared to come from this IPv4 address:
Prior to this change, all traffic from CloudVPS virtual machine instances (without their own floating IPs) heading to the internet appeared to come from this IPv4 address:
<pre>
<pre>
185.15.56.1
185.15.56.1
Line 49: Line 49:
Your software in this case might be a Toolforge tool, a Toolforge webservice, or any other software component running inside CloudVPS project virtual machine instance.
Your software in this case might be a Toolforge tool, a Toolforge webservice, or any other software component running inside CloudVPS project virtual machine instance.


== Why are you doing this ? ==
== Why are you doing this? ==


We need to simplify the Neutron setup we have. Previous to this change, we had a couple of changes in the Neutron source code to adapt it to our use case.
We need to simplify the Neutron setup we have. Previous to this change, we had a couple of changes in the Neutron source code to adapt it to our use case.
Line 55: Line 55:


Having less source code customization allows us to improve our ability to upgrade between Openstack versions.
Having less source code customization allows us to improve our ability to upgrade between Openstack versions.
In previous times, our transport network between the neutron virtual router and the production core router was using a private IP address (the 10. range). This was renumbered at some point (see [[phab:T207663 | phabricator ticket T207663]]), and we now use a public range for this. This allows us to use the native neutron virtual router address for the NAT, thus making our old <code>routing_source_ip</code> configuration obsolete.


== See also ==
== See also ==


* [[Portal:Cloud_VPS/Admin/Neutron | Neutron administrator documentation ]]
* [[Portal:Cloud_VPS/Admin/Neutron | Neutron administrator documentation ]]
* [[phab:T247505 | Phabricator T247505 - CloudVPS: neutron: consider dropping routing_source_ip custom hack from the l3 agent]] -- original phabricator ticker where this change was developed
* [[Wikimedia_Cloud_Services_team/EnhancementProposals/Network_refresh#Eliminate_routing_source_ip_address]]
* [[phab:T247505 | Phabricator T247505 - CloudVPS: neutron: consider dropping routing_source_ip custom hack from the l3 agent]] -- original phabricator ticket where this change was developed
* [https://lists.wikimedia.org/pipermail/cloud-announce/2020-April/000273.html Original announcement email]

Latest revision as of 12:53, 7 April 2020

The CloudVPS service is changing the main source NAT IP address.

Each CloudVPS virtual machine instance uses a private IPv4 address that cannot circulate in the internet, is only valid for internal traffic. Therefore, to allow virtual machines to contact endpoints over the internet we need a source NAT mechanism.

However, this NAT address is never used to contact internal Wikimedia servers, a different mechanism is used in such cases.

In CloudVPS, all this setup is implemented by means of Neutron, a complex-to-setup Openstack component that we hope to simplify with this change.

What is changing ?

Prior to this change, all traffic from CloudVPS virtual machine instances (without their own floating IPs) heading to the internet appeared to come from this IPv4 address:

185.15.56.1

When the change is applied, that address will no longer be involved and this one will be used instead:

208.80.155.92

Those addresses can also be associated with DNS names (FQDN), only for identification purposes:

  • 185.15.56.1 --- nat.openstack.eqiad1.wikimediacloud.org
  • 208.80.155.92 --- cloudinstances2b-gw.openstack.eqiad1.wikimediacloud.org

Please note: the DNS name (FQDN) is provided only for identification purposes, the meaningful thing here is the IPv4 address.

Timeline

Timeline this change will follow:

  • 2020-04-06: initial announcement to the community.
  • 2020-04-13: actual change introduction. Collect issues over this week and fix them if possible.
  • 2020-04-17: if the change wasn't rollback or any major issues were found, declare success.

Is there anything not changing?

Yes, a couple of things wont change and will keep working the same as before:

  • CloudVPS virtual machine instances that have floating IP addresses will keep using those. No changes for floating IP addresses.
  • Connections from CloudVPS to internal wikimedia services (such as Wikis, APIs, etc) aren't affected by this NAT, so no changes in this case.

What should I do?

In most cases, you literally don't have to do anything specific. However, some users may want to double check a couple of things.

If your software contacts any internet endpoints (for example, for downloading an external dataset or uploading a computation result) you will now see the connections coming from 208.80.155.92 instead of the old address 185.15.56.1.

Your software in this case might be a Toolforge tool, a Toolforge webservice, or any other software component running inside CloudVPS project virtual machine instance.

Why are you doing this?

We need to simplify the Neutron setup we have. Previous to this change, we had a couple of changes in the Neutron source code to adapt it to our use case. With this change, our customization to Neutron will be reduced by a good chunk.

Having less source code customization allows us to improve our ability to upgrade between Openstack versions.

In previous times, our transport network between the neutron virtual router and the production core router was using a private IP address (the 10. range). This was renumbered at some point (see phabricator ticket T207663), and we now use a public range for this. This allows us to use the native neutron virtual router address for the NAT, thus making our old routing_source_ip configuration obsolete.

See also