Switching

I have a customer who is evaluating using NSX for control plane for VXLAN traffic or simply use EVPN with their Juniper switches. I can't seem to find good documentation on one versus the other. While EVPN uses BGP (which is a more standard and robust protocol), OVSDB also achieves the purpose. Customer is also planning to have multiple sites and wants to enable communication between them. Can someone help me evaluate which option will be better?

Generally, the question is NSX vs Contrail, not NSX versus EVPN.  I think you are really asking OSVDB vs EVPN.  EVPN is an open standard, which should [eventually] provide interoperability between different vendors.  OSVDB came from VMWare, via Nicira, and I think now is IETF draft standard.  Many switch/router vendors, Juniper being one, support OSVDB (and EVPN as well) to interoperate with VMWare, but this may only be on a limited set of products.

As far as I know, and what little I know, NSX and VMWare are both generally closed systems.  So if you expect NSX to manage other types of VMs (KVM and HyperV come to mind), that is unlikely to happen.  This is a major difference today between NSX camp and Contrail.

Containers may change all of this, . . .

Thanks for your response. I agree that NSX is more of a closed system, and may not have good support for Hyper-V as well.

One thing which i found favorable in NSX is that the configuration is easier.  The VXLAN-VLAN bindings are configured through the NSX controller and also the L3 routes for communicating with the physical network. And this information is sent to the switches over the OVSDB schema. With EVPN, all the bindings and the customer information must be plumbed manually on the switches and this can be cubmersome for large deployments.

On the other hand, BGP is a more robust protocol and the chances of interoperability are much higher in the future. Moreover, there is no dependancy on a controller. 

I think it really boils down to what the customer requirements are i.e. software/hardware VTEPs, scaling requirements etc. I've worked on a couple of scenarios that resulted in an NSX overlay within the virtualised infrastructure with a separate EVPN-VXLAN overlay in the physical network. NSX works well in VMware only environments and is pretty much fully integrated with vCenter.  With regards to multiple sites, do you require L2 stretch between the sites or all L3?  OVSDB with NSX is only used when integrating hardware VTEPs, or L2 bridging. I've never seen this deployed in production and the general feeling is to steer away from mixing hardware/software VTEPS.  With regards to configuration, it's very unlikely that you would manually administer an EVPN overlay. Typically automation techniques and tools  would be used. 

Highlights

EVPN :

Industry standard adopted by all major vendors. 

Provides a clear demarcation between Network and infrastructure

With the use of EVPN as the control plane, hardware VTEP gateways can support different modes of redundancy such as All-Active or Single-Active multihoming.

Hardware VTEP gateways offer high-density, high-performance and better scale.

For larger deployments, if there are a large number of BMSs that need to communicate with the virtualized workloads, or if there is need to handle large traffic volumes, then a high throughput hardware gateway offers a better solution.

Based on the desired deployment requirements, hardware VTEP gateways can be used to provide physical-physical (BMS-BMS), virtual-virtual (VM-VM) or virtual-physical (VM-BMS) connectivity.

Distributed model 

NSX:

Centralised SDN based network overlay

Provides a logical network and security management plane, control plane and data plane functionality

Extends logical switch to support routing in the hypervisor (DLR)

NSX Edge can be for routing and for stateful services such as firewall and load balancing

VXLAN is used for transport networks

NSX controllers maintain and control the distribution of MAC / IP information to hosts

Does NOT natively support multi-tenancy. Requires 1 logical switch per tenant.

I would also suggest you take a look at Contrail as an alternative to NSX, as suggested by rccpgm 

I hope this helps 🙂 

Thanks. This is super helpful.