This post was authored by Jason Burns, Technical Marketing Engineer at Nutanix
Previously in this series, we showed how Nutanix implements application policies in the virtual switch to provide security for our application traffic. AHV microsegmentation implements layer 2 through 4 rules based on a given policy definition, converting the definition to addresses, protocol, and ports.
However, some types of traffic require inspection that simple rules can’t provide, and that’s where network function virtualization (NFV) comes into play. To get inside the traffic payload for virus scanning or deep packet inspection, we need to look at higher network layers—which means that we need more resources. With the Nutanix AHV networking stack, we can insert a virtualized network function that collects and analyzes the network traffic flow to perform this inspection.
This blog series highlights the AHV features announced at Nutanix .NEXT DC back in June that can help you build a one-click network.
Currently, AHV administrators can create network function chains that redirect traffic from an entire AHV network (which corresponds with a VLAN on the AHV host). For example, we could redirect all traffic from our Exchange network through a firewall appliance. In a future release, Nutanix plans to improve function chains to operate on a more granular level and to provide a Prism-based UI. We describe some of these planned improvements below.
In our last post, we used application policies to allow communication from our San Jose HR department to the Exchange Edge Transport tier. Let’s expand that example and use the “East West Firewall” service chain during policy creation to redirect this specific traffic through a network function VM. We could then define our policy as “Allow HR in San Jose to reach my Exchange Edge Transport tier after my East West Firewall application inspects it.”
The figure above offers an early view of the management UI for function chains in Prism, which will be available in an upcoming release. By selecting Redirect through service chain, we can route our traffic through a specialized firewall service VM for further processing with just one click. To ensure that our traffic always takes this route, we implement a series of rules inside the virtual switch in the AHV host. The diagram below shows the East West Firewall in the traffic path. All traffic to or from any VM must flow through the rightmost bridge br0 for internal switching, or for switching to the upstream physical network. In this example, the rules inside the br.nf bridge (or network function bridge) redirect the HR VM traffic—on its way right or left—through the network function VM.
Bridge br0.local never allows a VM to talk directly to another VM. Traffic flows either from a VM to the rest of the bridge chain for handling, or from the bridge chain to the VM. All switching is performed via br0 or the physical switches.
Once we have created the rules and routed specific traffic through the network function chain, we can look at how we provision service or agent VMs. Each network function has to run on each AHV host, so we have to create a service chain on the host, provision the function VM, and hook it into the chain. If you had to perform each step manually on every host, this process would involve a lot of error-prone work.
But we don’t have to perform each step manually, because the upcoming release of Nutanix Calm can help us out. Calm can provision a Palo Alto VM-Series firewall on the Nutanix AHV hosts based on a blueprint and can also configure the controller as needed. Then we just need to check the right box in a security policy to start using the new East West Firewall service as shown above.
Any VM that runs on AHV can be used as a network function VM. The Palo Alto Networks VM-Series firewall described above is just one example of an NFV that you can deploy—on Nutanix, you have the freedom to use the products of your choice. In my own lab, I'm running open source tools as a VM in the function chain of every host to provide packet capture and IDS functionality on AHV.
We put together this blog series to illustrate how visualization, automation, and security are key components of a modern datacenter network strategy. Nutanix AHV delivers visualization through both connectivity and flow mapping available in Prism. Automation is provided both by our vendor-agnostic VM life cycle event notification and by Calm for provisioning and configuring complex network services. Multiple phases deliver layered and nuanced network security:
► Visualization of connectivity and flows can help find any anomalies.
► Integration with top-of-rack switches can ensure that you enable only required connectivity and remove connectivity as soon as no longer required.
► Policy-based microsegmentation implemented at the virtual switch level ensures that your network only permits the right flows.
► Integration with advanced security services can provide even deeper inspection of these flows.
► Calm automation can ease administrative burdens, allowing simple deployment of advanced security services or NFV
Together, all of these networking functions help to bring one-click networking closer to reality.
We hope you’ve enjoyed the series. Please comment below or tweet Nutanix to let us know if you’d like technical deep dives on anything covered so far.
Continue the conversation and connect with peers in our online forums.
This blog includes forward-looking statements, including but not limited to statements concerning our plans and expectations relating to product features and technology that are under development or in process and capabilities of such product features and technology and our plans to introduce product features in future releases. These forward-looking statements are not historical facts, and instead are based on our current expectations, estimates, opinions and beliefs. The accuracy of such forward-looking statements depends upon future events, and involves risks, uncertainties and other factors beyond our control that may cause these statements to be inaccurate and cause our actual results, performance or achievements to differ materially and adversely from those anticipated or implied by such statements, including, among others: failure to develop, or unexpected difficulties or delays in developing, new product features or technology on a timely or cost-effective basis; delays in or lack of customer or market acceptance of our new product features or technology; the introduction, or acceleration of adoption of, competing solutions, including public cloud infrastructure; a shift in industry or competitive dynamics or customer demand; and other risks detailed in our Form 10-K for the fiscal year ended July 31, 2017, filed with the Securities and Exchange Commission. These forward-looking statements speak only as of the date of this presentation and, except as required by law, we assume no obligation to update forward-looking statements to reflect actual results or subsequent events or circumstances.