Understanding Virtual Networks (vNETs)
Pluribus Networks supports various network virtualization capabilities as part of a highly flexible approach to software-defined networking (SDN), called Unified Cloud Fabric.
Pluribus’ fabric addresses all the most common network design requirements, including scalability, redundancy, predictable growth capability, fast convergence in case of a failure event, etc. Such requirements also include multi-tenancy support.
Therefore, in the data center, by leveraging Netvisor ONE’s virtualization features, network designers can implement a variety of multi-tenancy models such as Infrastructure as a Service (IaaS) or Network as a Service (NaaS).
To support multiple tenants, the fabric’s data plane segmentation technologies include standard features (such as VLANs) as well as advanced virtualization features such as VXLAN and distributed VRFs, to be able to deploy an open, interoperable, high-capacity and high-scale multi-tenant network. (Refer to the Configuring VXLAN section for more details on VXLAN and distributed VRFs).
In addition to data plane segmentation, fabric virtualization also comprises the capability of separating tenants into isolated management domains. Pluribus calls this capability Virtual Networks (vNETs in short).
A vNET is an abstract control plane resource that is implemented globally across the fabric to identify a tenant’s domain. By using vNETs, you can segregate a physical fabric into many logical domains, each with separate resources, network services, and Quality of Service (QoS) guarantees. vNETs therefore allow the network administrator to completely separate the provisioning of multiple tenants within the network.
Each vNET has a single point of management. As the fabric administrator, you can create VNETs and assign ownership of each vNET to individuals with responsibility for managing those resources.
You can create separate user names and passwords for each vNET manager. Using the separate vNET administration credentials, the vNET admin can use Secure Shell (SSH) to connect to the vNET manager and access a subset of the Netvisor ONE CLI commands to manage a specific vNET. This way, multiple tenants can share a fabric with each managing a vNET with security, traffic, and resource protection from other vNETs.
Figure 17-1 - Using vNETs with Netvisor ONE
vNETs are very flexible and can be used to create complex network architectures. For example, a Pluribus Networks switch, or a fabric of switches, can be used to create multiple tenant environments. In Figure 16-1 above there are three vNETs, each one with a management interface and a data interface. Each vNET is assigned an IP address pool used for DHCP assignment of IP addresses to each node, server, or OS component.
Underlying each vNET is the vNET manager. Each vNET manager runs in a zone. When services are created for a vNET they occupy the same zone on a switch. This is called a shared service and it is the default when creating services. However, each zone can only support a single instance of a service. If a second service instance is needed for a vNET, then it needs to occupy a separate zone. This is called a dedicated service. In most cases, you can create services as shared resources unless you specifically want to create a dedicated service.
When a fabric is created, a vNET is also automatically created and named fabric-name-global. This vNET initially owns all resources within the fabric. As new vNETs are created, resources are moved from the default vNET to the new vNETs. Global services remain in the default vNET unless assigned to a specific vNET.