> For the complete documentation index, see [llms.txt](https://docs.platform9.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.platform9.com/private-cloud-director/virtualized-networking/networks-and-ports.md). # Virtual Network A Virtual Network is a software defined network that is generally created by a tenant user. By default, the Virtual Networks are isolated from each other, so that the virtual machines created within these networks can not route traffic outside of the network. Virtual Networks use IP encapsulation techniques, i.e. they use an "underlay network" as the underlying physical transport, but present themselves as an entirely new network to VMs and workloads within the hypervisor cluster. ## Types & Setup You can choose to enable virtual networking for your virtual cluster as part of cluster blueprint configuration. Virtual Networks in space.vars.product\_name support following types: * VLAN * VXLAN * GENEVE You choose your preferred method for creating virtual networks **once,** as part of the initial [**cluster blueprint configuration**](/private-cloud-director/virtualized-clusters/virtualized-cluster-blueprint.md). Then, when you or your tenant users create new virtual networks, this underlying configuration will be used behind the scenes to provision the networks. ### VLAN Network A VLAN virtual network is a virtual network that isolates traffic using VLAN tagging (802.1Q). When you choose VLAN as the technology for virtual networks during cluster blueprint creation, you specify a range of VLAN IDs that Private Cloud Director draws from each time a new virtual network is created. It is important that you select a VLAN range **not being used** by your current physical network infrastructure.\ \ **How it maps to your physical network** When a new virtual network is created, Private Cloud Director assigns it one VLAN ID from the configured range. Every VM attached to that network has its traffic tagged with that VLAN ID as it leaves the hypervisor and crosses the physical network. Your physical switches use the tag to keep each virtual network in its own isolated broadcast domain, so VMs on the same virtual network can communicate, even when they run on different hosts, while staying separated from VMs on other networks. Because this tagging happens on your real physical network, a VLAN virtual network is only as reachable as your physical fabric allows. For VMs on the same network but different hosts to reach each other, the switch ports connecting your hypervisor hosts must be configured as trunk ports that carry the full VLAN range you assigned to Private Cloud Director.\ \ Each VLAN virtual network consumes one VLAN ID, so the number of IDs in your range is the maximum number of VLAN virtual networks you can run at once. The 802.1Q standard allows VLAN IDs 1 through 4094, so a VLAN-based deployment supports at most a few thousand concurrent virtual networks. If you expect to exceed that, an overlay technology such as VXLAN is not bound by the VLAN ID limit.\ \ **Example -**\ \ ![](/files/w4fdkb3wWY1KFiHHQuaP)\ \ Two hypervisor hosts each run VMs on different VLAN virtual networks, color-coded by VLAN ID. Each host tags a VM's traffic with its VLAN ID on the way out. Those tagged frames ride trunk ports down to the physical switch, which carries all the VLANs over one link. The green callout states the payoff: same VLAN ID means the same virtual network even across hosts (VM A and VM C on VLAN 100), while different VLANs stay isolated. {% hint style="danger" %} **Important** It is important that you **select a VLAN range** **not being used** by your current physical network infrastructure. Not doing this may result in networking connectivity problems with your virtual networks. {% endhint %} ### VXLAN / GENEVE Network A VXLAN or GENEVE virtual network uses VXLAN or GENEVE as an overlay (encapsulation) technology running on top of an IP underlay. When you choose VXLAN or GENEVE as the technology for virtual networks, you specify the VXLAN VNID Range or the Geneve Tunnel ID Range that Private Cloud Director draws from when new virtual networks are created.\ \ **How it maps to your physical network**\ \ Each hypervisor host acts as a tunnel endpoint. When a VM sends traffic, its host wraps that traffic in a VXLAN or GENEVE header, which carries the virtual network's identifier (VNID or Tunnel ID), and then in a standard UDP/IP packet. The packet travels across your physical IP network to the destination host, which strips the encapsulation and delivers the original traffic to the target VM. \ \ Your physical switches only need to route IP traffic between hosts. They do not need to be aware of individual virtual networks, and they do not require the per-network trunk configuration that a VLAN deployment needs. Because the virtual networks ride on IP, VMs on the same virtual network can run on any hosts that can reach each other over the underlay, independent of how the physical network is laid out.\ \ **Choosing VNID or Tunnel ID range**\ \ The range you configure is the pool of identifiers assigned to new virtual networks behind the scenes. VXLAN and GENEVE identifiers are 24 bits, which allows up to roughly 16 million virtual networks so scale is effectively not a constraint for most deployments. \ \ Unlike VLAN IDs, these identifiers travel inside the encapsulation and are never exposed as tags on your physical switches, so they do not collide with the VLANs already in use on your physical infrastructure. This is the main advantage of overlay networks: large scale and decoupling from the physical fabric, in exchange for some encapsulation overhead and slightly more abstract troubleshooting.\ \ **How Overlay Networks Ride on the IP Underlay**\ \ ![](/files/p7SOceil21dEooLoipau) ## Sharing By default, a Virtual Network is created in the context of a `tenant` that will be the default owner of that Network. A Network can be explicitly marked as `shared`, which will make it accessible to all tenants. Only the tenant that owns a network can change its sharing settings; tenants that the network has been shared with can use it but cannot modify how it is shared. ## Network Interface A Network Interface is an interface inside a Virtual Machine. Each Virtual Machine will typically have one or more pairs of **(Network Interface and Port)** associated with it. ## Subnet A Virtual Network is not really usable without having at least one Subnet as part of it. A Subnet provides a usable IP address range within a layer 2 broadcast domain. Any Virtual Machines belonging to the same subnet can communicate with one another directly without the need for a router. When you deploy a new Subnet for a Virtual Network using space.vars.product\_name UI, the option to deploy a **DHCP server** for that subnet is selected by default. When selected, a new DHCP server will be deployed for this subnet when it's provisioned. This is the **most commonly used** scenario for Virtual Network Subnets. But, you may choose to not use a DHCP server for a Subnet if you plan to: * Assign static IPs to VMs using this Subnet, using `cloud-init` * Use an external DHCP server to assign IPs. Uncheck the box to disable DHCP server for the Subnet in that case. ## IP Version Support You can create a physical (or provider) network with either ipv4 or ipv6 protocol. Choose the right protocol depending on what your underlying physical network infrastructure support. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.platform9.com/private-cloud-director/virtualized-networking/networks-and-ports.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.