Connecting your OpenStack private cloud to the public internet or other external networks is a fundamental task. OpenStack Neutron manages this through what it calls “external networks.” This guide will walk you through understanding, setting up, and maintaining these connections, covering the creation of networks and subnets, router configuration, and assigning floating IPs.
This video from the OpenInfra Foundation is a great supplementary resource that we’d also recommend checking out as you go through this process:
Understanding the Basics
Before diving into commands, let’s clarify what we’re building:
- External Network: This is a special Neutron network object that maps to a physical network outside your OpenStack cloud, like your organization’s public internet uplink.
- Subnet: Associated with the external network, this defines the IP address range, gateway, and DNS servers for that external connection.
- Router: A Neutron router acts as a gateway, connecting one or more of your private (tenant) networks to the external network, allowing traffic to flow in and out.
- Floating IPs: These are public IP addresses from the external network’s subnet that you can dynamically assign to your instances (VMs). This allows specific instances to be directly reachable from the outside world.
Prerequisites: Getting Ready for Setup
To successfully configure an external network, you’ll need a few things in place.
Physical Network Infrastructure
Your OpenStack environment needs a physical connection to the outside world. This typically involves:
- A dedicated physical network interface card (NIC) on your controller or network nodes, intended for external traffic.
- Network switches that are configured to handle the VLAN (if used) for your external traffic.
- A Linux bridge (often named
br-exby convention, though the name can vary) on the relevant OpenStack nodes (usually network nodes or controllers running the L3 agent). This bridge will connect to the physical NIC dedicated to external traffic.
This physical NIC should be connected to your data center’s border router or firewall to ensure proper routing and security.
Software and Access
You’ll need administrative privileges in your OpenStack environment:
- OpenStack Neutron Server: Ensure the main Neutron service is running.
- L3 Agent Service: This service is crucial as it manages routing functions. Verify it’s active.
- Admin Access: You’ll need administrative credentials for both the OpenStack dashboard (Horizon) and the command-line interface (CLI).
- Verification Tools: Familiarity with tools to check network agent status is helpful.
Key configuration files you might interact with or need to be aware of include:
/etc/neutron/neutron.conf(Main Neutron configuration)/etc/neutron/plugins/ml2/ml2_conf.ini(For ML2 plugin-specifics, like VLAN or flat network mappings)/etc/neutron/l3_agent.ini(L3 agent configuration)/etc/neutron/plugins/ml2/openvswitch_agent.ini(If using Open vSwitch)
Network Planning: The Blueprint
Good planning prevents headaches later. Consider these points:
IP Address Range:
- What is the external IP subnet you’ve been allocated (e.g.,
203.0.113.0/24)? - What is the gateway IP address for this subnet?
- Which DNS servers should instances use for external resolution?
- What portion of this subnet will be used for the floating IP pool?
VLAN Configuration (if applicable):
- If your external network is on a specific VLAN, what is the VLAN ID?
- How will VLAN tagging be handled on your physical switches and OpenStack nodes?
MTU (Maximum Transmission Unit):
- What is the appropriate MTU size? It’s often 1500 bytes for standard Ethernet, but can be larger (jumbo frames) in some environments.
Security Rules:
- What are the baseline firewall rules or network access control lists (ACLs) that should be in place?
Always document your IP ranges, VLAN details, and security policies to avoid conflicts and to aid in troubleshooting.
Configuration Steps: Bringing Your External Network Online
Let’s configure the necessary components using the OpenStack CLI.
1. Create the External Network
First, define the network itself. This command tells Neutron that this network is external and maps it to a specific physical network provider (if applicable).
--external \
--provider-physical-network external \
--provider-network-type flat--external: Flags this network as an external network.--provider-physical-network external: This name (external) should match a configuration in yourml2_conf.inifile (e.g., in[ml2_type_flat]or[ml2_type_vlan]). It maps this Neutron network to a physical network known by the underlying SDN or network plugin. For flat networks, this might be a specific physical interface. For VLANs, it refers to a trunked interface.--provider-network-type flat: Specifies that this network is a flat network (no VLAN tagging managed by Neutron on this segment). Another common type isvlan.
Verify its creation:
openstack network show external-netLook for router:external being True.
2. Configure the External Subnet
Now, create a subnet associated with external-net. This defines the IP addressing.
openstack subnet create external-subnet \
--network external-net \
--subnet-range 203.0.113.0/24 \
--allocation-pool start=203.0.113.100,end=203.0.113.200 \
--gateway 203.0.113.1 \
--dns-nameserver 8.8.8.8 \
--no-dhcp--network external-net: Associates this subnet with the network we just created.--subnet-range 203.0.113.0/24: Your public IP block.--allocation-pool start=203.0.113.100,end=203.0.113.200: The specific range within the subnet from which floating IPs will be assigned. Ensure this doesn’t overlap with your gateway or other statically assigned external IPs.--gateway 203.0.113.1: The gateway IP address for your external network.--dns-nameserver 8.8.8.8: A public DNS server (Google’s, in this example).--no-dhcp: Typically, DHCP is disabled on external subnets used for floating IPs, as IPs are assigned statically or through the floating IP mechanism.
3. Create a Virtual Router
A router is needed to connect your private tenant networks to this new external network.
openstack router create my-routerNow, set the external network as the gateway for this router:
openstack router set my-router --external-gateway external-netNext, connect one of your existing private (tenant) subnets to this router. Let’s assume you have a private subnet named private-subnet:
openstack router add subnet my-router private-subnetThis step allows instances on private-subnet to route traffic through my-router to the external network.
4. Assign Floating IPs
To make an instance reachable from the outside, you assign it a floating IP. First, create (allocate) a floating IP from your external network’s pool:
openstack floating ip create external-netThis will output the allocated floating IP address. Note it down.
Now, associate this floating IP with a specific instance (e.g., my-instance):
openstack server add floating ip my-instance <floating-ip-address>Replace <floating-ip-address> with the IP you just created.
At each stage, you can use tools like ping or traceroute (from within an instance, or from an external machine if a floating IP is assigned) to test connectivity.
Fine-Tuning and Best Practices
With the basics in place, think through these aspects for a well-managed setup.
Securing Your Network
The importance of security can’t be overstated. Use Neutron’s security groups to control traffic to and from your instances. Follow the principle of least privilege – only open the ports that are absolutely necessary.
For example, to create a security group allowing SSH access:
openstack security group create allow-ssh-sg --description "Allow SSH access"
openstack security group rule create allow-ssh-sg \
--protocol tcp \
--dst-port 22:22 \
--remote-ip 0.0.0.0/0Then apply this security group (allow-ssh-sg) to your instances. Also, review port security settings (often enabled by default) on your Neutron networks to prevent IP and MAC spoofing.
Setting up High Availability (HA)
For production environments, you don’t want your external connectivity to be a single point of failure.
Neutron’s L3 agent can be configured for high availability. This typically involves:
Multiple L3 Agents: Run L3 agents on several network nodes.
openstack network agent list --agent-type l3HA Mode for Routers: Enable HA mode when creating routers or update existing ones. This often uses VRRP (Virtual Router Redundancy Protocol) to manage failover between L3 agents.
openstack router create my-ha-router --haNeutron Configuration: In /etc/neutron/neutron.conf, you might configure:
[DEFAULT]
l3_ha = True
max_l3_agents_per_router = 3 # Or a suitable number
min_l3_agents_per_router = 2 # For HA, typically at least 2And in /etc/neutron/l3_agent.ini:
[DEFAULT]
agent_mode = dvr_snat # Or legacy, ha
ha_vrrp_auth_type = PASS
ha_vrrp_auth_password = your_secret_password(Note: dvr_snat also provides HA capabilities for SNAT services.)
Consult the OpenStack Networking Guide for detailed L3 HA configuration steps specific to your OpenStack release and chosen plugins.
Improving Performance
Network performance can be tuned:
MTU Adjustment: If your physical network supports jumbo frames, you can increase the MTU for better throughput for large data transfers.
# Set MTU for the network
openstack network set --mtu 9000 external-net
# You may also need to adjust global_physnet_mtu in neutron.conf
# and ensure instances and physical network gear are configured accordingly.Open vSwitch (OVS) Settings: If you’re using OVS, ensure your bridge_mappings in /etc/neutron/plugins/ml2/openvswitch_agent.ini are correctly pointing your provider network name (e.g., external) to the appropriate OVS bridge (e.g., br-ex):
[ovs]
bridge_mappings = external:br-ex
# Consider datapath_type (e.g., netdev vs system) based on your kernel and OVS version
# datapath_type = netdevDriver Choices: Using PMD (Poll Mode Driver) threads for OVS datapaths or SR-IOV for direct hardware access can significantly boost performance for demanding workloads but requires more complex setup.
Monitoring tools can help you identify bottlenecks:
openstack network agent list --long # Check agent status and health
# Use standard Linux tools like ethtool, ip, iftop on network nodesWrapping Up – Configuring External Networks in OpenStack Neutron
Setting up external network access in OpenStack Neutron involves planning out your physical and logical network topology, followed by a sequence of configuration steps for networks, subnets, routers, and floating IPs. Pay attention to security, build in redundancy, and consider performance aspects to create a reliable and efficient connection between your OpenStack cloud and the outside world.
Remember to consult the official OpenStack documentation for your specific version, as commands and configuration details can evolve. Regular monitoring and maintenance will help ensure your external connectivity continues functioning the way you want it to.
For an alternate method of setting up an external network that uses the OpenStack Horizon interface, check out our guide: Networking in OpenStack.
Schedule a Consultation
Get a deeper assessment and discuss your unique requirements.
Read More on the OpenMetal Blog