A candidate on a coaching call three weeks ago asked me why his lab would not let him tick Override cluster network settings when he created a namespace. He had rebuilt the Supervisor twice chasing it. Nothing was broken. His Supervisor was enabled on the vSphere networking stack, and on that stack there is no per namespace network to override, because there is no NSX tier-1 gateway to give the namespace. That single checkbox is the cleanest illustration of what Objective 3.2 is really asking: a namespace does not choose its network model, it inherits one, and the choice was made when somebody enabled the Supervisor.

Last Part we sized the load balancer sitting in front of the Supervisor and found that object count, not throughput, is what runs it out of room. This Part stays one layer down. Everything a namespace can do with a packet was decided upstream, and your job in the exam and on a real estate is to read the Supervisor and predict what each namespace will and will not be able to do.

Three network models a namespace can inherit

VCF 9.0 gives a Supervisor three workload networking stacks, and a vSphere Namespace lands in whichever one it was born into. Understanding what each one withholds matters more than understanding what each one provides, because the exam asks you to evaluate implications, not to recite features.

vSphere Distributed Switch with a load balancer. Workload traffic rides a distributed portgroup. Broadcom is explicit that namespaces on this stack support only VKS clusters and standalone VMs. vSphere Pods, which are containers the Supervisor schedules directly onto ESXi hosts, are unavailable, and so is the Harbor Registry as a Supervisor Service. There is no namespace level network object, so the override checkbox never appears.

NSX Segment networking. Each namespace gets a tier-1 gateway and one or more segments carved from a Namespace Network CIDR, with a Subnet Prefix deciding how big each carve is. Ingress virtual IPs come from an Ingress CIDR, and outbound source NAT addresses come from an Egress CIDR. This is the model most people learned on, and it is the only one where the override workflow applies.

NSX VPC networking. New in VCF 9.0 and the recommended stack going forward. A vSphere Namespace maps to an NSX Virtual Private Cloud, a self contained network tenancy with its own gateway, its own IP address management and its own subnets. If you do not name a VPC when you create the namespace, one is created for you inside the default NSX Project. Subnets carry an access mode of Public, Private-VPC or Private-TGW, and that access mode, not a NAT checkbox, is what decides reachability. Every VPC belongs to an NSX Project, and each Project has its own Transit Gateway.

Read the bottom two rows together and the design pressure becomes obvious. On the Segment model you can keep adding CIDRs forever but you can never resize the carve; on the VPC model you add subnets and the sizing conversation moves inside the VPC. That difference is the whole of Objective 3.2 in one sentence.

Namespace density arithmetic on a shared CIDR

Namespace Subnet Prefix is the field candidates skip and estates regret. It specifies the size of the subnet reserved for each namespace segment, its default is 28, and Broadcom states plainly that once you specify it you cannot change it. Everything downstream follows from that one number: how many namespaces a Namespace Network CIDR yields, and how many workload addresses each namespace will ever hold.

Take a /22 Namespace Network CIDR, which is a comfortable allocation on most estates and the one I use in the lab. Here is what each prefix buys, with usable addresses counted after the network, gateway and broadcast addresses come off the top.

I lost most of a Thursday to that first row. We carved a namespace on the middle zone for the PostgreSQL StatefulSet work, took the default prefix of 28 without a second thought, and dropped a three control plane, three worker VKS cluster into it. Fine for a fortnight. Then the autoscaler was asked to take that cluster to twelve workers and it stalled at ten. Machine objects sat in Provisioning with nothing useful on the cluster status, and it was the NCP log on the Supervisor that finally named it: a segment with no free addresses. Thirteen usable, six spent on day one, seven left, exactly as the table says. Because the prefix cannot be edited, there was no fix, only a rebuild. New namespace at prefix 26, storage policy and VM class and content library reattached, cluster redeployed, persistent volumes restored from Velero. Four hours and ten minutes end to end, all of it avoidable by typing 26 instead of accepting 28.

Here is where the popular study advice is backwards. Nearly every walkthrough tells you to be generous with Ingress and Egress CIDRs, because ingress is the part you can see and a virtual IP shortage is loud. Reverse the emphasis. Ingress and Egress CIDRs are additive; Broadcom documents that you can configure additional CIDRs after you create the namespace. Subnet prefix is not additive and never will be. Spend your planning attention on the field you only get to set once.

Fields that lock the moment you click Create

Experienced vSphere admins carry an assumption that hurts them here: namespace settings behave like resource limits, editable whenever. CPU, memory, storage limits and permissions are indeed editable. Three network fields are not.

Two more implications sit behind the override checkbox and both are worth a line each. Overriding requires an NSX build with an Edge cluster dedicated to tier-0 gateways and a separate Edge cluster dedicated to tier-1 gateways, which is not how most single site NSX installs are built. And the moment you override, IP address management becomes yours: Broadcom requires the new Ingress, Egress and Namespace Network subnets to be unique for that Supervisor and unique from every other namespace network on it. There is no allocator watching your back. Selecting a tier-0 gateway also overrides the one you chose when you enabled the Supervisor, so every CIDR has to be supplied again, and the Supervisor still has to route directly to the cluster nodes and ingress subnets, either through a VRF gateway that inherits the Supervisor tier-0 configuration or through BGP between the two tier-0 gateways.

Which is exactly why I stopped reaching for the override on new builds. If what you want is a namespace with its own network boundary, the VPC model gives it to you as the default behaviour rather than as an exception that costs two Edge clusters and a manual IPAM regime. The override survives for one legitimate case on my estate, a namespace that has to hang off a specific tier-0 for an audit boundary, and that is it.

flowchart TD
  A[New vSphere Namespace] --> B{Supervisor networking stack}
  B -->|vDS with Avi| C[No override offered. VKS clusters and VMs only]
  B -->|NSX Segment| D{Needs its own tier zero}
  B -->|NSX VPC| E[Namespace maps to a VPC]
  D -->|No| F[Inherit Supervisor CIDRs. Set subnet prefix once]
  D -->|Yes| G[Override settings. Two Edge clusters and manual IPAM]
  E --> H{Reachable from outside}
  H -->|Yes| I[Public subnet. No NAT required]
  H -->|No| J[Private VPC or Private TGW subnet]

One VPC detail deserves its own warning because it has caught more people than anything else in the 9.0 workflow. Subnet Size in a VPC is a total count of IP addresses, not a mask length. Entering 16 gives you sixteen addresses, several of which NSX reserves for network operations, and not a /16 with sixty five thousand. If you carry vSphere and NSX habits into that field you will build a subnet three orders of magnitude smaller than you intended and only find out when the fourth workload fails to get an address.

Worth knowing for context although it sits outside the 9.0 exam scope: from VCF 9.1 onward, deploying a Supervisor with classic NSX Segment networking moved to an API only option and the vSphere Client goes straight to the VPC workflow. Your exam is built on 9.0, where both are first class in the UI, so answer for 9.0. See the NSX Series for how tier-0, tier-1 and VPC constructs are built in the first place, and the VKS Series for the product walkthrough underneath this study path. If you are arriving from a Tanzu Kubernetes Grid Integrated estate, the TKGI to VKS Series covers the migration reading; this series assumes you are already on VKS.

Exam focus for objective 3.2

Objective checkpoint

Namespace network call for this estate

My pick for the reference estate, and my recommendation for anything you build new on VCF 9.0: NSX VPC, with Private-TGW subnets as the default for VKS namespaces and Public subnets reserved for the few namespaces that genuinely need directly advertised addresses. It gives every namespace a real isolation boundary without the two Edge cluster tax, and it moves address planning into a place where you can add a subnet later instead of rebuilding.

Keep NSX Segment networking where you already run it, and if you must override at namespace level, do it deliberately and document the IPAM allocation somewhere a colleague will find it. Avoid two things outright. First, the vDS stack for any namespace where vSphere Pods or Harbor are even a possibility, because you cannot add those later. Second, and I mean this literally, avoid accepting the default subnet prefix of 28 on any namespace that will host a VKS cluster with an autoscaler attached. Thirteen addresses is a six node cluster plus a rounding error.

Tonight, in your own lab: open Workload Management, pick an existing namespace, and try to change its subnet prefix. Watch the field refuse you. Then write down the prefix and the current node count for every namespace you own, and mark the ones with fewer than ten spare addresses. That list is your rebuild backlog, and it is far better to have it now than at 3 a.m. when an autoscaler stalls. Next Part takes the same namespace and looks at how ingress and egress are actually architected around it, which is Objective 3.3.

References

• Broadcom TechDocs, Create and Configure a vSphere Namespace, VCF 9.0
• VMware Cloud Foundation Blog, VMware Virtual Private Cloud in VCF 9.0
• Broadcom, VCAP-VKS 3V0-24.25 Exam Guide

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts