Cisco has made it clear that there will be no validated design for a FlexPod with VMware NSX running as the virtual network and there will be no trifecta vendor support for the entire platform. This does not mean you’re completely barred from using it though. To be able to make use of the best of both worlds, I’ve been working to create a design that uses FlexPod as the rock solid foundation and offer the networking flexibility that VMware NSX offers. The goal is to not change the FlexPod design so that it will still be certified for support.
Before getting into the specifics, let’s lay out the design specifications:
- FlexPod components, configuration and support
- VMware NSX for network services (firewall, loadbalancing, vpn, switching, etc) for the virtual machines
- For optimal routing use dynamic routing between the physical and virtual world
- Further optimise routing by using the NSX Distributed Router and optimise east-west VM traffic
When it comes to the relation between a FlexPod and NSX, basically all there really is is the network connectivity between the physical and virtual network. The problem lies in the routing between the two worlds.
Using the Virtual Port-Channel (vPC) technology, FlexPod has layer 2 high availability covered. Using a first-hop redundancy protocol (HSRP or VRRP), layer 3 high availability is also covered.
When using vPC, the connections to your UCS environment looks like this:
vPC has technical limitations when it comes routing; point-to-point static routing is fine, but point-to-point dynamic routing will not work. Brad Hedlund has done an amazing job of explaining the technical details here.
One of the requirements to create the most flexible environment, was the dynamic routing between the NSX components and the physical network, so we need to think of a way around that. This is where we can use an existing exception to the architecture; FCoE.
In the storage world applications usually requires two separate storage paths between the storage controllers and two server HBAs, which is often met by using two completely separated physical networks. In the ethernet world, we like to mesh everything together and let the network figure out the best paths. Now here comes FCoE and we combine the two, while keeping the requirement to have two separate paths. Ciscos recommendation for delivering FCoE to UCS looks like this:
We can use this design to make the same adjustment for NSX data traffic. The transport, storage and management networks can remain on the original FlexPod configuration. Using direct non-vPC connections between the virtual and physical world enables the use of dynamic routing between the two, which satisfies our requirement.
When extending the FlexPod this way, we leave the original foundation of the FlexPod design in place and don’t bother with any of the constraints set by the validated designs. The existing high available vPC connections are used for the storage, management functions and the all the east-west traffic inside the virtual environment.
When using the NSX distributed router (which is our last requirement) inside the virtual network, we minimise the north-south traffic tremendously by not needing the traditional core routers in the center of the datacenter. By leveraging the network services inside NSX (firewalling, loadbalancing, vpn, etc), we move even more traffic from the datacenter core to the virtual network (which turns into east-west traffic).
When it comes down to it, the only north-south traffic you would have left is user access. Server to server, loadbalancer to server, firewall to server, firewall to firewall, all the other traffic will be east-west and therefore not traversing the uplinks.
If you put the logical picture together, we conclude with all the goodness of NSX combined with dynamic conversation between the virtual and physical network for optimal flexibility in deploying virtual networks and everything in it.
Whether Cisco likes it or not, NSX is coming around and fitting in most network virtualisation use cases better then other solutions. VMware used to suggest that you could use “commodity” network hardware, but that also doesn’t fly. You always need a stable foundation to build your services on and the FlexPod proposition fits in that picture perfectly.
I, for one, am very excited about combining the two.
Leave a Reply