Configuring Virtual Networks


Informational Note:

This feature is not supported on Dell platforms.

Implementing Virtual Networks

A Virtual Network (VNET) is 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 its own 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 1:Using VNETs with Netvisor


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 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, 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.  

Specifying the Type of VNET Interface

The mgmt, data, and span keywords used in different commands specify the path used to connect to the network service. For example, to specify an out-of-band connection to a management interface of a VNET, the interface is specified using the mgmt keyword. If in-band access to that management interface of the VNET is required, then the data or span keywords are used in the specific command. The keywords, data and span, are essentially equivalent but apply to two separate paths. To maximize throughput between the server and the switch components, it is recommended to use both. The data keyword applies to port 65, and the span keyword applies to port 66.

Each VNET can have one or more isolating zones and network services are applied to each zone. Network services have their own zone or share the zone with the VNET manager which is the zone that the VNET user logs into to manage the VNET. In shared zones, the network interfaces are available to all network services in the shared zones, regardless of the service that created the network interface.



This is an important concept as you can use service commands such as vnet-manager-interface-add to add interfaces to a VNET. If you want the service to be specific to a VNET as a dedicated service, then add the interfaces using the service-interface-add commands.

Creating a Virtual Network (VNET)

To separate resources, including switch ports, IP addresses, VLANs, and VXLANs, into separate management spaces, create a VNET and place the resources in the VNET. Then configure a separate VNET admin to manage the network.


Informational Note:

You cannot create another VNET inside of a VNET.

There is no performance impact when you send network traffic through a VNET. Packets are switched in the hardware with full line-rate bandwidth and the same latency even if the packets are on a VNET or not. But, the VNET allows you to provide different Service Level Agreements (SLAs) to each VNET when there are multiple VNETs on a physical switch and there is resource contention based on traffic loads. See also:


VNET High Availability (HA)

VNET HA provides high availability for switch access through a VNET manager. The VNET manager is a zone, typically with one IP interface, allows a VNET administrator to log into and administer a VNET using the CLI or a REST API.

HA functionality is provided by allowing you to create multiple VNET managers. Access to the VNET managers is enabled when you add either standard or VRRP VIP interfaces to the VNET managers.

Without VNET HA, VNET administrators have only a single point of access where the VNET manager zone is running on a particular switch. If that switch fails, the administrator cannot log into the fabric and administer the VNET.

This feature now provides the following:

Creating a VNET Manager Zone

To create additional VNET manager zones, use the vnet-manager-create command.

CLI network-admin@switch > vnet-manager-create name name-string vnet vnet-name [disable|enable][location fabric-node name][storage-pool storage-pool name]


Creates a VNET manager

name name-string

Specify the name of service configuration.

vnet vnet-name

Specify the VNET assigned to the service.

any of the following options:



Specify to enable or disable the service.

location fabric-node name

Specify the location of the service.

storage-pool storage-pool name

Specify the storage pool assigned to the service.

Deleting a VNET Manager Zone

To delete a VNET manager zone, use the vnet-manager-delete command.



Deletes a VNET manager.

name name-string

Specify the name of service configuration.

Copying and Pasting SSH Keys

To output SSH host keys to copy and paste to ~/.ssh/known_hosts file of the client host, use the vnet-manager-ssh-host-key-show command. This allows you to SSH to any VNET manager zone and avoid issues with invalid key hosts.

CLI network-admin@switch > vnet-manager-ssh-host-key-show [vnet vnet name]


Displays the VNET Manager host keys to copy and past to ~/.ssh/known_hosts.

name name-string

Displays the name of service configuration.

VNET Manager Command Options

This feature uses a new option[no-]create-vnet-mgr which controls whether or not to create a VNET manager. By default, Netvisor creates a VNET manager as the current behavior of creating a VNET manager as part of vnet-create.

CLI network-admin@switch > vnet- create name name-string no-create-vnet-mgr


Creates a virtual network (VNET)

 name name-string

Specify the VNET name.

scope local|cluster|fabric

Specify the VNET scope as local, cluster, or fabric.


Create or not create a VNET manager service.

VRRP Interfaces Option

This feature now accepts options for VRRP interfaces. This allows you to create VRRP interfaces on VNET manager zones.

CLI network-admin@switch > vnet-manager-interface-add vnet-manager-name name-string [vrrp-id 0...255][vrrp-primary vrrp-primary-string][vrrp-priorty 0..254][vrrp-ad-int 10..40950]


Adds an interface to a VNET manager.

 vnet-manager-name name-string

Specify the name of service configuration.

vrrp-id 0..255

Specify the ID assigned to VRRP.

vrrp-primary vrrp-primary-string

Specify the VRRP primary interface.

vrrp-priority 0..254

Specify the VRRP priority for the interface.

vrrp-adv-int 10..40950

Specify the VRRP Advertisement Interval in mseconds. The minimum interval is 10ms and the maximum interval is 40950ms. The default interval is 1000ms.

shared-vnet-mgr Option

There is a new option for service create commands: shared-vnet-mgr vnet-manager-name

This option allows you to specify the VNET manager if the option shared-vnet-service is specified and more than one VNET manager exists. The VNET manager specified is where the new service is created. The command, vrouter-create, also supports this new option:


Informational Note:

To support backwards compatibility, the vnet-manager-name argument is optional if only one VNET manager exists. If you do not specify the name and more than one VNET manager exists, the command fails.

Topic Feedback

Was this topic useful to you? Please provide feedback to improve the content.