I’ve been around IT long enough to remember when Data Center Network designs resembled those of Campus Networks. The two design methodologies started to diverge when it became apparent that, given the same outage duration, negative impact to the business was greater at the Data Center than at the Campus. A Campus user had to wait 50 seconds for a page to load? The user probably didn’t even notice. That a Data Center web server couldn’t serve webpages for 50 seconds? Somebody’s job might be in the chopping block.
Today’s rule of thumb is that unplanned Data Center Network disruption must be kept to a minimum. With that goal in mind, many of the Network protocols have been tweaked to provide fast Network re-convergence in the event Network components fail. For example, Spanning Tree (STP) gave way to Rapid Spanning Tree (RSTP) and recovery time when from about 45 seconds to a few seconds.
So where am I going with this? Well, NSX has a component called the NSX Edge. The NSX Edge is a Virtual Appliance that does NetworkFunction Virtualization (NFV). One of the nice features of the NSX Edge is that you can deploy it in pairs of Active/Passive. The two NSX Edges will have identical configuration, with the passive NSX Edge monitoring the up-state of the Active NSX Edge, and the Active NSX Edge feeding state tables and session information back to the Passive. If the Active NSX Edge goes down, the Passive NSX Edge takes over the role of Active. This feature of the NSX Edge is called Edge High Availability, or HA (not to be confused with vSphere HA, that is a different concept).
Edge HA supports a dead-timer (Declare Dead Time) as small as 6 seconds (although VMware’s latest version, V3, of the NSX Reference Design Guide encourages you to not go below 9 seconds). Assuming a HA dead-timer of 6 seconds, plus a second or two for the Passive to be fully functional as the Active, you can expect to have the NFV service unavailable, during unplanned outages, for less than 10 seconds.
Some of the NFV services the NSX Edge supports are routing protocols (OSFP, BGP, IS-IS), NAT, Load Balancer and stateful L3/4 Firewall. I like to think of these services as asymmetrical and symmetrical. An asymmetrical service would be routing. Traffic can come in one NSX Edge and return via a different path. Symmetrical services, such as NAT or Load Balancer, require that traffic return via the same NSX Edge, as there is some mapping table or session state that needs to be consulted for the traffic to go on its way.
For example, NSX Edge Cabaña performs a destination NAT to traffic from Brugal destined for Virtual Machine Piña Colada. If Piña Colada’s return traffic goes up it’s default gateway, NSX Edge Hamaca, then there will be no one to reverse the destination NAT that Cabaña did. When Brugal receives the traffic, it will drop the traffic as it won’t recognize the source IP as one it is communicating with.
By the way, I strongly discourage you from using the design in the above image.
Let’s talk a bit about routing. The NSX Edge supports low keepalive and dead timers for its routing protocols (keeping in line with low recovery time for Data Centers). In the case of OSPF, you can go with 1 and 3. So after 3 seconds, the OSPF neighbor adjacency gets removed and its entries get flushed from the routing table. The NSX Edge also supports having up to 8 different paths in the routing table for the same network. This is called Equal Cost Multipathing (ECMP). This ECMP support works for OSPF, BGP and IS-IS. In the case of BGP, the NSX Edge kind of disregards the BGP standard and adds multiple paths based on the number of BGP Peers it has advertising the same network.
So a question that I’ve been asked a few times is this one: Should I deploy two NSX Edges running a routing protocol and use ECMP or should I deploy a single NSX Edge with Edge HA?
Well, the answer depends on what other NFV service is that NSX Edge providing. If the NSX Edge is providing a symmetrical service, my advice is to go with HA. If the NSX Edge is only providing an asymmetrical service (routing), then go with multiple NSX Edges and turn on ECMP in the upstream and downstream NSX Edges or routers.
To explain the logic behind it, have a look at the diagram below. NSX Edges Cabaña and Hamaca are running OSPF with timers of 1 and 3 in the internal side. The NSX Edge Barcelo is doing L3/4 stateful firewalling as well as running OSPF with ECMP enabled.
Traffic coming from Piña Colada will be load shared (ECMP) by Barcelo between Cabaña and Hamaca. If either Cabaña or Hamaca goes down, Barcelo will detect the event in about 3 seconds, remove all routes from the downed NSX Edge in its routing table, and send all traffic via the other NSX Edge. And by the way, when the NSX Edge goes down, only about half the traffic gets affected.
Alternatively, if instead of two NSX Edges, Cabaña and Hamaca, you had just one with Edge HA, when that NSX Edge goes down all traffic will be affected. Assuming an Edge HA dead timer of 6 seconds and OSPF dead timer of 3 seconds it would be just under 10 seconds before traffic flow is restored.