Pluribus Netvisor, A Look Under the Hood

At Pluribus, we have long held the vision that the world of networking would be a richer, better place if parts of it looked more like the server. Just as x86 has pretty much come to dominate the world of compute, merchant silicon from the likes of Broadcom and Intel have come to dominate the world of networking. Virtualization has a long history on the server, one that stretches back to at the very least IBMs CP-40 in 1964. On the network side thing haven’t gone as fast or as far as many would hope and thus one of the opportunities we saw at Pluribus was to bring server style virtualization to the network using potent but cost effective merchant silicon and commercial off the shelf components like Intel Xeon CPUs and SSD storage.

Our network OS, Netvisor (NETwork hyperVISOR) is designed to take advantage of some of these opportunities, bringing Type 1, bare metal, distributed virtualization to a more agile, intelligent and programmable network. While we are big proponents of SDN and the concept of separate data and control planes, we also strongly believe that the right way to do this is with a distributed rather than centralized controller. From this comes the ability to create a “fabric-cluster”, presenting the entire network as a single logical unit and allowing VM migration and policy management across L2 and L3 boundaries.

Additionally, this server-like approach provides a server class control plane, allowing deep integration of switching hardware over high speed connections, allowing the switch hardware to be virtualized much like a big NIC (albeit one with an unusually large number of ports). This deep integration unleashes
a new class of services and
functions, enabling them to run directly on the network, such as the ability to
run scalable monitoring and
analytics for both physical and
virtual flows, without the need to deploy taps and other external monitoring gear.

How does this tie in with Data Center requirements?

Data centers in general tend to want to segment networks, manage and host virtual machines and be able to do fine grained analytics all while being able to guarantee bandwidth and meet stringent SLAs. As we will see, Netvisor can help on all these fronts.

Segmentation

Network segmentation, the ability to take a single physical network and slice and dice it into individually manageable parts, is very important for modern networks, particularly in the data center. Netvisor provides this capability through VNETs.

Each VNET has its own set of network services such as DNS, DHCP etc. VNETs are not limited to a single rack, but are a fabric wide feature. Management of the network can be done from any switch. Any vlan can contain any switch (or port) on the network and every VNET has its own set of vlans. Netvisor virtualizes the network and masks the underlying network complexity to the applications.

A typical implementation would be similar to the following diagram:

The above segmentation can be easily achieved using Netvisor architecture. The database servers can run on different machines connected to the switches in the fabric. They will part of VNET “Database”.

Let's create a virtual network (VNET) for database servers and add 5 vlans to it. This VNET needs to be fabric-wide hence scope fabric.

Now, let's add database server facing ports on all switches across the fabric to the vnet “database”.

The VNET named “database” is created fabric wide and can be viewed from the below cli command. We can see that on switches pn-sw1 and pn-sw2 that VLANs 10-14 and ports 41-42 are assigned to VNET database. On pn-sw3, it’s the same VLANs (10-14) but ports 33-36.

A similar VNET can be created for webservers. The switch ports facing webservers are added to VNET “webserver”. The pn-sw2-global is a fabric wide VNET for global VNET and will be used for fabric related stuff.

Now the network is sliced in to two segments, or in this case, VNETs, database and webserver. These segments can have their own DNS and DHCP services installed within the fabric.

Communication between VNETs

Communication between VNETs can be routed over the fabric using vrouters. Netvisor offers hardware vrouters as well as software vrouters. In the following, we will illustrate the creation of some vrouters.

Conclusion

We took a look at some of the fundamental principles behind Netvisor, one of which being that there is considerable advantage to building networks with more server-like attributes. We also took a more pragmatic look at some of the capabilities of Netvisor as exposed by the CLI, including the ability to segment the network with VNETs.