Mirantis OpenStack

  • Download

    Mirantis OpenStack is the zero lock-in distro that makes deploying your cloud easier, and more flexible, and more reliable.

  • On-Demand

    Mirantis OpenStack Express is on demand Private-Cloud-as-a-Service. Fire up your own cloud and deploy your workloads immediately.

Solutions Engineering

Services offerings for all phases of the OpenStack lifecycle, from green-field to migration to scale-out optimization, including Migration, Self-service IT as a Service (ITaaS), CI/CD. Learn More

Deployment and Operations

The deep bench of OpenStack infrrastructure experts has the proven experience across scores of deployments and uses cases, to ensure you get OpenStack running fast and delivering continuous ROI.

Driver Testing and Certification

Mirantis provides coding, testing and maintenance for OpenStack drivers to help infrastructure companies integrate with OpenStack and deliver innovation to cloud customers and operators. Learn More

Certification Exam

Know OpenStack? Prove it. An IT professional who has earned the Mirantis® Certificate of Expertise in OpenStack has demonstrated the skills, knowledge, and abilities needed to create, configure, and manage OpenStack environments.

OpenStack Bootcamp

New to OpenStack and need the skills to run an OpenStack cluster yourself? Our bestselling 3 day course gives you the hands-on knowledge you need.

The #1 Pure Play OpenStack Company

Some vendors choose to “improve” OpenStack by salting it with their own exclusive technology. At Mirantis, we’re totally committed to keeping production open source clouds free of proprietary hooks or opaque packaging. When you choose to work with us, you stay in full control of your infrastructure roadmap.

Learn about Our Philosophy

The Road to Hong Kong—OpenStack Summit Speakers #4: Neutron Network Namespaces and IPtables

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:

  1. Identify the correct namespace.
  2. 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.

9 comments

9 Responses

  1. Unfortunately, figure 1 is missing

    November 5, 2013
  2. It might be better to verify whether network namespaces are compiled in kernel. In my case:
    $ grep CONFIG_NET_NS /boot/config-$(uname -r)
    CONFIG_NET_NS=y

    RHEL 5.x do not have NET_NS.
    On the other hand recent RHEL 6.x have it compiled.

    Can’t stand attending your presentation!

    November 7, 2013
  3. The youtube video for this presentation the projector is too bright. Any way the slides could be posted?
    http://www.youtube.com/watch?v=LHKQ514HLAo
    Thanks, Joe

    November 14, 2013
  4. This page and also the video recording of the talk are polluting Google. I’m looking for info on how Neutron configures iptables but neither this page nor the video mention iptables at all despite featuring it in the title. This is only about network namespaces. The title should be changed to not claim that it covers iptables.

    January 20, 2014
    • I’m sorry you feel that way, Paul. I can tell you’re pretty frustrated. I haven’t seen the video in some time so I don’t remember what’s in it; is there something in particular you’re trying to find out about? Maybe we can get Damian or someone else to help you out.

      January 20, 2014

Continuing the Discussion

  1. Linux network namespaces | squarey's blog

    […] More: Neutron Network Namespaces and IPtables […]

    March 15, 201407:49

Some HTML is OK


or, reply to this post via trackback.