PLUMgrid hosted the San Francisco Bay Area OpenStack meetup this week, and we had a presentation by Gaetano Borgione on OpenStack integrated networks. I think his presentation can be summed up as follows:
Virtual and Physical networks need to be cooperatively integrated from some form of central management ‘controller’, and can get much need performance and improved manageability and performance from hardware accelerated ‘gateway’ to get the best value from the overall fabric.
Virtual and Physical networks need to be co-operatively integrated from some form of central management Click To Tweet
In this particular situation, the point was made with a demonstration of an OpenStack environment (using the PLUMgrid SDN controller and VXLAN overlay virtual network) connected to a physical network attached to a Cisco Nexus switch with embedded VXLAN Layer 2 VTEP termination. The embedded hardware forwarding translator was the star of the show, providing connectivity between the virtual network and virtual machines created and managed by an OpenStack system (using VXLAN as the network topology), and the physical network and a set of machines attached to the Cisco switch via VLAN based networking. The PLUMgrid controller configured the Nexus switch to do VTEP-to-VLAN translation between a VXLAN created by OpenStack, and a VLAN available to devices on the non-OpenStack side of the environment. This demonstration modeled an environment often seen by users of tools like the PLUMgrid SDN solution, where legacy components (in this case a database cluster) is already established and running on the physical environment, and a set of application servers built in the OpenStack environment.
The point in enabling this translation in a physical gateway such as the Nexus 9000 switch (PLUMgrid supports Arista and Cumulus Networks devices as well), was to leverage the hardware encap/de-encap rather than doing this in a software environment, allowing for the potential of wire rate forwarding at 40G aggregate throughput.
One attendee asked about the use of L2 translation rather than just running everything at L3 (e.g. remove the translation all together), and it was pointed out that, while this might be an option in some environments, and can certainly remove the encap/de-encap overhead, that this is not always possible. I.e., the customer dictates the requirements, and in this case, a vendor was providing access to a high-performance and _manageable_ solution.
manage and monitor the infrastructure is a key point that all network services users are looking for Click To Tweet
A second commentary around this overall capability was the fact that the ability to manage and monitor the infrastructure is a key point that all network services users are looking for. While there isn’t currently a fully integrated low-level monitoring solution, the ability to have a central software defined network service that integrates the physical world with the virtual allows for better end-2-end visibility, and can help reduce the overhead of debug by providing a single point of connectivity knowledge.
An interesting evening with the OpenStack community and our hosts at PLUMgrid.
Robert Starmer,
Founder and CTO