Implementing Virtual Networks
Netvisor ONE uses Virtual Networks (vNETs), an abstract network resource realized across a fabric of Pluribus Networks switches. Using vNETs, you can segregate a physical fabric into many logical networks, each with separate resources, network services, and Quality of Service (QoS) guarantees. A vNET allows you to completely separate all traffic in one vNET from the traffic of other vNETs.
Figure 13-1 - Using VNETs with Netvisor One
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 that vNET. This way, multiple tenants can share a fabric with each managing a vNET with security, traffic, and resource protection from other VNETs.
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 an OpenStack deployment. In Figure 1 Using VNETs with Netvisor One, there are three VNETs, each 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 unless you specifically want to create a dedicated service.
When a fabric is created, a vNET is automatically created and named fabric-name-global. This vNET owns all resources within the fabric, and 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 specifically to a vNET.