This is the fourth and final post by speakers at the Hong Kong OpenStack Summit. Today we feature a preview of the talk by Damian Igbe about OpenStack Neutron Namespaces and IPtables, scheduled for November 8, from 4:10 pm to 4:50 pm. To see the full list and descriptions of Mirantis talks, please check out the schedule.
Namespaces enable multiple instances of a routing table to co-exist within the same Linux box (like virtual routing and forwarding [vrf] in routers), within the network and subnets spaces, per tenant. They introduce a whole realm of networking flexibility, which can be critical in production Openstack deployments–but can also contradict the logic applied by experienced IP network admins and lead troubleshooting off a cliff.
This technical deep dive into OpenStack Neutron Namespaces and IPtables will give a clear understanding of these building blocks of OpenStack L3 and DHCP agents. We’ll show how to go about troubleshooting L3 issues, and how to apply this more robust networking abstraction in distributed OpenStack environments.
Fancy privacy? Well, even computer networks do fancy privacy mostly from security point of view. A feature widely used in Linux to achieve network privacy is network namespaces. Network namespaces make it possible to separate network domains (network interfaces, routing tables, iptables) into completely separate and independent domains. One network namespace traffic is completely different and isolated from the other and still completely different from the main Linux IP network stack.
A kernel feature being supported form version 2.6.29, some Linux distribution versions still do not support network namespaces and so it’s important to check that the Linux kernel of choice supports the intended use.
To check if your kernel supports namespaces, run the following commands:
root@vmcon-mn:~# ip netns add net-ns1 root@vmcon-mn:~ip netns exec net-ns1 ifconfig
If the above two commands do not produce errors, your kernel supports namespaces.
The tutorial I’m going to discuss in Hong Kong is primarily about the application of network namespaces in Openstack and, therefore, will not explore network namespaces at the Linux kernel. A Linux kernel that supports namespaces is the only requirement for the tutorial. Ubuntu 12.04 or later support namespaces as does Fedora 17 and new, but some older RHEL platforms do not by default. It may be possible to upgrade the iproute2 package on a platform that does not support namespaces by default.
Namespaces in OpenStack
Network namespaces are widely used in OpenStack Networking-as-a-Service (NaaS), codenamed Neutron. In a multi-tenancy environment where network security of each tenant is of highest priority, network namespaces make this goal a reality. With namespaces, every tenant network traffic and network interfaces is completely isolated from each other as illustrated in Figure 1.
Figure 1 Illustration of Tenant namespaces implementation in Neutron
A big advantage of namespaces implementation in neutron is that tenants can create overlapping IP addresses, a situation that gives freedom to cloud users because they are free to create any subnet of choice without fear of conflicting with that of another tenant. A Linux network namespace is required on nodes running neutron-l3-agent or neutron-dhcp-agent if overlapping IPs is in use. Hence, the hosts running these processes must support network namespaces.
Also, namespaces enables Neutron to operate Use Case: Per-tenant Routers with Private Networks. In this use case the neutron-l3-agent uses the compute node’s IP stack’s routing functionality to implement virtual routers that route between different neutron subnets and, in conjunction with iptables, NAT route between these and external networks. The neutron-l3-agent is designed to use network namespaces to provide multiple independent virtual routers per node, that do not interfere with each other or with routing of the compute node on which they are hosted.
If the kernel does not support namespaces, the following limitations should be noted with Neutron:
- Neutron-l3-agent is limited to providing a single virtual router per compute node. If namespaces is supported, a single deployed neutron-l3-agent should be able to host multiple virtual routers.
- It is necessary to configure each neutron-l3-agent with the Universally Unique ID (UUID) identifying the router instance that it hosts. This complicates deployment, makes self-service provisioning of routers by tenants impractical. If namespaces is supported, the configuration with the UUID(s) of the router(s) it hosts is not required.
- If the host does not support namespaces then the neutron-l3-agent and neutron-dhcp-agent should be run on different hosts. This is due to the fact that there is no isolation between the IP addresses created by the L3 agent and by the DHCP agent. A downside to this is that by manipulating the routing tables the user can ensure that these networks have access to one another.
Join me in Hong Kong, where I will discuss how to:
- Identify the correct namespace.
- Perform general troubleshooting around the identified namespace.
I hope to see you there!
Dr. Damian Igbe has nearly a decade of experience in technical roles at Internet Service Providers (ISPs), Consultancy, Education and Government organizations. Concentrating primarily on Redhat & Debian Linux, MS-Windows, Open source IT automation tools (Spacewalk (Satellite), Puppet, Cobbler, Bash, Perl), Cloud (Amazon AWS, EC2, NOVA, Glance, Swift), Virtualization technologies (ESXi, VMware, Virtualbox, XEN, KVM) and monitoring (Nagios, Cacti). He holds a PhD in Computer Science from the University of Westminster, with research in Dynamic Load Balancing of Parallel Road traffic simulations. Dr. Igbe lives in Northern California with his family, having recently relocated from London.