In this post we’ll explore how DVR is implemented in OpenStack Neutron and what are some of its benefits and shortcomings.
To be honest I was a little hesitant to write this post because the topic of Neutron’s DVR has already been exhaustively covered by many, including Assaf Muller, Eran Gampel and in the official OpenStack networking guide. The coverage of the topic was so thorough that I barely had anything to add. However I still decided to write a DVR post of my own for the following two reasons:
- I often use my own posts as references and it’s always easier for me to find information in my own writings.
- I wanted to use this post as a reference platform for subsequent posts about dynamic routing and OVN project.
The topic of Neutron’s DVR is quite vast so I had to compromise between the length of this post and the level of details. In the end, I edited out most of the repeated content and replaced it with references to my older posts. I think I left everything that should be needed to follow along the narrative so hopefully it won’t seem too patchy.
Virtual topology overview
Let’s see what we’re going to be dealing with in this post. This is a simple virtual topology with two VMs sitting in two different subnets. VM1 has a floating IP assigned that is used for external access.
Before we get to the packet walk details, let me briefly describe how to build the above topology using Neutron CLI. I’ll assume that OpenStack has just been installed and nothing has been configured yet, effectively we’ll pick up from where we left our lab in the previous post.
Virtual topology setup
- Upload Cirros Linux image to OpenStack's image repository
1 2 3 4 5
curl http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img | glance \ image-create --name='IMG-CIRROS' \ --visibility=public \ --container-format=bare \ --disk-format=qcow2
- Create 2 virtual subnets - RED and BLUE
1 2 3 4 5 6 7
neutron net-create NET-BLUE neutron subnet-create --name SUB-BLUE NET-BLUE 10.0.0.0/24 \ --dns-nameserver 184.108.40.206 neutron net-create NET-RED neutron subnet-create --name SUB-RED NET-RED 10.0.1.0/24 \ --dns-nameserver 220.127.116.11
- Create external network
1 2 3 4 5 6 7 8 9
neutron net-create EXT-NET --provider:network_type flat \ --provider:physical_network extnet \ --router:external \ --shared neutron subnet-create --name EXT-SUB \ --enable_dhcp=False \ --allocation-pool=start=169.254.0.50,end=169.254.0.99 \ --gateway=169.254.0.1 EXT-NET 169.254.0.0/24
- Create a router and attach it to all three networks created above
1 2 3 4
neutron router-create R1 neutron router-interface-add R1 SUB-RED neutron router-interface-add R1 SUB-BLUE neutron router-gateway-set R1 EXT-NET
- Create two host aggregates to spread the VMs across two different hosts
1 2 3 4
nova aggregate-create AGG-RED AZ-RED nova aggregate-create AGG-BLUE AZ-BLUE nova aggregate-add-host AGG-BLUE compute-2 nova aggregate-add-host AGG-RED compute-3
- Boot VMs on two different hypervisors
1 2 3 4 5 6 7 8 9
nova boot --flavor m1.tiny --image 'IMG-CIRROS' \ --nic net-name=NET-BLUE \ --availability-zone AZ-BLUE \ VM1 nova boot --flavor m1.tiny --image 'IMG-CIRROS' \ --nic net-name=NET-RED \ --availability-zone AZ-RED \ VM2
- Assign a floating IP (Static NAT) to VM1
nova floating-ip-create EXT-NET nova floating-ip-associate VM1 169.254.0.55
- Enable ingress ICMP and SSH access
nova secgroup-add-rule default tcp 22 22 0.0.0.0/0 nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0
- Make sure that both VMs are up and running.
1 2 3 4 5 6
+--------------------------------------+------+--------+------------+-------------+----------------------------------+ | ID | Name | Status | Task State | Power State | Networks | +--------------------------------------+------+--------+------------+-------------+----------------------------------+ | 92263ae8-43d1-4cd0-b271-2b11f0efbe7f | VM1 | ACTIVE | - | Running | NET-BLUE=10.0.0.12, 169.254.0.55 | | b4562f24-2461-49fb-875b-fa1bf869dc4a | VM2 | ACTIVE | - | Running | NET-RED=10.0.1.4 | +--------------------------------------+------+--------+------------+-------------+----------------------------------+
non-DVR traffic flow
Using the technique described in my earlier post I’ve collected the dynamically allocated port numbers and created a physical representation of our virtual network.
For the sake of brevity I will omit the verification commands. The traffic flow between VM1 and VM2 will follow the standard path that I’ve explored in my native Neutron SDN post.
It is obvious that in this case traffic flows are suboptimal. Instead of going directly between the peer compute nodes, the packet has to hairpin through a Neutron router. This adds to the end-to-end latency and creates unnecessary load on the Network node. These are one of the main reasons why Distributed Virtual Routing was introduced in OpenStack Juno.
Enabling DVR requires configuration changes of multiple files on all OpenStack nodes. At a high level, all compute nodes will now run Neutron’s L3-agent service which will be responsible for provisioning of DVR and other auxiliary namespaces. The details of specific configuration options that need to be enabled can be found in the official OpenStack Networking guide. As usual, I’ve incorporated all the necessary changes into a single Chef cookbook, so in order to enable DVR in our lab all what you need to do is run the following commands from the UNetLab VM:
Once all changes has been made, we need to either create a new router or update the existing one to enable the DVR functionality:
DVR East-West traffic flow
Now let’s see how the traffic flows have changed with the introduction of DVR.
We’re going to be examining the following traffic flow:
- From VM1 (10.0.0.12/fa:16:3e:83:92:96)
- Via router R1 (10.0.0.1/fa:16:3e:72:7a:50; 10.0.1.1/fa:16:3e:6a:2c:8b)
- To VM2 (10.0.1.4/fa:16:3e:76:31:68)
R1 now has an instance on all compute nodes that have VMs in the BLUE or RED networks. That means that VM1 will send a packet directly to the R1’s BLUE interface via the integration bridge.
1 2 3 4
This is dynamically populated MAC address table of the integration bridge. You can see that the MAC address of VM1 and both interfaces of R1 have been learned. That means that when VM1 sends a packet to its default gateway’s MAC address, it will go directly to R1’s BLUE interface on port 4.
In this post I will omit the details of ARP resolution process which remains the same as before, however there’s one interesting detail that is worth mentioning before we move on. During the initial flood-and-learn phase on the br-int, the ARP request will get flooded down to the tunnel bridge. As per the standard behaviour, the packet should get replicated to all nodes. However, in this case we don’t want to hear responses from other nodes, since the router is hosted locally. In order to help that, tunnel bridges explicitly drop all packets coming from integration bridges and destined for MAC addresses of locally hosted routers:
1 2 3 4
Getting back to our traffic flow, once the IP packet has reached the DVR instance of R1 on compute node #2, the routing lookup occurs and the packet is sent back to the integration bridge with a new source MAC of R1’s RED interface.
Tunnel bridge will do its usual work by locating the target compute node based on the destination MAC address of VM2 (DVR requires L2 population to be enabled) and will send the packet directly to the compute node #3.
1 2 3 4 5 6 7 8
Since all instances of R1 have the same set of IP/MAC addresses, the MAC address of a local router can be learned by the remote integration bridge hosting the same instance of DVR. In order to prevent that from happening, the sending br-tun replaces the source MAC address of the frame with the
set_field:fa:16:3f:d3:10:60->eth_src action. This way the real R1’s MAC address gets masked as the frame leaves the node. These “mask” MACs are generated by and learned from the Neutron server, which ensures that each node gets a unique address.
The receiving node’s br-tun will swap the VXLAN header with a VLAN ID and forward the frame up to the integration bridge.
1 2 3 4 5 6 7 8 9 10
Integration bridge of compute node #3 will lookup the destination MAC address and send the packet out port 2.
1 2 3 4 5
The reverse packet flow is similar - the packet will get routed on the compute node #3 and sent in a BLUE network to the compute node #2.
External connectivity will be very different for VMs with and without a floating IP. We will examine each case individually.
Case 1 - Overload NAT (VM2 with no FIP)
External connectivity for VMs with no floating IP is still performed by the Network node. This time however, NATing is performed by a new element - SNAT namespace. As per the normal behaviour, VM2 will send a packet to its default gateway first. Let’s have a closer look at the routing table of the DVR:
There’s no default route in the main routing table, so how would it get routed out? DVRs extensively use Linux routing policy database (RPDB), a feature that has a lot in common with OpenFlow tables. The principle of RPDB is that every packet gets matched against a set of routing tables until there’s a hit. The tables are checked in the order of their priority (lowest to highest). One of the main features of RPDB is the ability to perform matches based on something other than the destination IP address, which is why it’s often referred to as policy-based routing. To view the contents of RPDB use the
ip rule command under the DVR namespace:
1 2 3 4 5
In our case table 167772161 matches all packets sourced from the BLUE subnet and if we examine the corresponding routing table we’ll find the missing default route there.
The next hop of this default route points to the SNAT’s interface in the BLUE network. MAC address is statically programmed by the local L3-agent.
Integration bridge sends the packet out port 1 to the tunnel bridge.
Tunnel bridge finds the corresponding match and sends the VXLAN-encapsulated packet to the Network node.
Tunnel bridge of the Network node forwards the frame up to the integration bridge.
Integration bridge sends the frame to port 10, which is where SNAT namespace is attached
SNAT is a namespace with an interface in each of the subnets - BLUE, RED and External subnet
1 2 3 4 5 6 7 8 9
SNAT has a single default route pointing to the External network’s gateway.
Before sending the packet out, iptables will NAT the packet to hide it behind SNAT’s qg external interface IP.
Case 2 - Static NAT (VM1 with FIP)
The first step in this scenario is the same - VM1 sends a packet to the MAC address of its default gateway. As before, the default route is missing in the main routing table.
1 2 3
Looking at the ip rule configuration we can find that table 16 matches all packets from that particular VM (10.0.0.12).
1 2 3 4 5 6
Routing table 16 sends the packet via a point-to-point veth pair link to the FIP namespace.
Before sending the packet out, DVR translates the source IP of the packet to the FIP assigned to that VM.
A FIP namespace is a simple router designed to connect multiple DVRs to external network. This way all routers can share the same “uplink” namespace and don’t have to consume valuable addresses from external subnet.
1 2 3 4
Default route inside the FIP namespace points to the External subnet’s gateway IP.
The MAC address of the gateway is statically configured by the L3 agent.
The packet is sent to the br-int with the destination MAC address of the default gateway, which is learned on port 3.
External bridge strips the VLAN ID of the packet coming from the br-int and does the lookup in the dynamic MAC address table.
The frame is forwarded out the physical interface.
Reverse packet flow will be quite similar, however in this case FIP namespace must be able to respond to ARP requests for the IPs that only exist on DVRs. In order to do that, it uses a proxy-ARP feature. First, L3 agent installs a static route for the FIP pointing back to the correct DVR over the veth pair interface:
Now that the FIP namespace knows the route to the floating IP, it can respond to ARPs on behalf of DVR as long as proxy-ARP is enabled on the external fg interface:
Finally, the DVR NATs the packet back to its internal IP in the BLUE subnet and forwards it straight to VM1.
DVR Pros and Cons
Without a doubt DVR has introduced a number of much needed improvements to OpenStack networking:
- East-West traffic now follows the most optimal path thereby reducing the load on the Network node.
- External connectivity to floating IPs now also follows the most optimal path directly to the compute node hosting the VM.
However, there’s a number of issues that either remain unaddressed or result directly from the current DVR architecture:
- DHCP and SNAT are still hosted on the Network node.
- Asymmetric routing means that every DVR needs to have an interface in every configured subnet, even when there are no VMs that belong to those subnets on the current compute node.
- Direct connectivity to FIP means that all compute nodes now need to have direct L2 adjacency to external subnets.
- FIP namespace on compute nodes consumes IP addresses from external subnets which can be a problem if external subnet is in a public IPv4 address range.
- DVR implementation as a network namespace creates additional overhead in packet processing.
Some of the above issues are not critical and can be fixed with a little effort:
- In order to reduce the scope of a External network VLAN span inside the DC, dedicate a subset of hosts that will have a direct L2 adjacency to external networks and only deploy external-facing VMs on those hosts.
- Since FIP namespace only requires an external IP address for debugging purposes, we can create an additional, secondary, subnet in RFC1918 space for FIP connectivity. This is enabled by a feature called subnet “Service types” and is available in the latest Newton release.
However the main issue still remains unresolved. Every North-South packet has to hop several times between the global and DVR/FIP/NAT namespaces. These kind of operations are very expensive in terms of consumed CPU and memory resources and can be very detrimental to network performance. Using namespaces may be the most straight-forward and non-disruptive way of implementing DVR, however it’s definitely not the most optimal. Ideally we’d like to see both L2 and L3 pipelines implemented in OpenvSwitch tables. This way all packets can benefit from OVS fast-path flow caching. But fear not, the solution to this already exists in a shape of Open Virtual Network. OVN is a project spawned from the OVS and aims to address a number of shortcomings existing in current implementations of virtual networks.