Nutanix NCP-NS 7.5 Study Guide, Part 3: Deploy, Upgrade, and Quick Reference

This is Part 3 of the Nutanix NCP-NS 7.5 study guide, and it closes out the blueprint. It covers Section 5, Deploy and Upgrade a Flow Environment, then the quick reference material you want on one page before the exam: ports and protocols, alert IDs, configuration maximums, and a candid list of what the source documents do not cover. As with Parts 1 and 2, nothing here is filled in from general Nutanix knowledge.

Study guidePart 1 · Configure / Part 2 · Troubleshoot / Part 3 · Deploy and reference

Version scope for all three parts: Flow Virtual Networking 6.0, Flow Network Security 5.2 Next-Gen, and Prism Central 7.3. Legacy Flow Network Security procedures, VLAN mode and 4.2.0, are deliberately excluded and flagged where the blueprint still cites them.

Section 5: Deploy and Upgrade a Flow Environment

FNS overhead is in addition to the Network Controller’s. Enabling microsegmentation for the first time also requires enabling Advanced Networking.

Objective 5.1: Prepare a Cluster for Flow Network Security

Knowledge

Enable FNS · Confirm supported versions · Identify required resources

Enable: Prism Central Settings > Microsegmentation > tick Enable Microsegmentation > Save. Disabled by default. Requires a Flow license, or a 60-day trial.

Component	Required for FNS Next-Gen 5.2.0
AOS	7.3 or later
AHV	10.3 or later
Prism Central	pc.7.3 or later, hosted on one of its registered AHV clusters
Network Controller	5.0.0 or later

Version relationship and generation gate The FNS Prism Central version must be ≥ the FNS Prism Element version. And the 5.2.x series is single stack, Next-Gen only: LCM deliberately hides the 5.2.0 bundle if FNS is not enabled, or if you are running FNS 4.x.x or any other current generation version. That is what stops a legacy deployment jumping onto a single stack release. The 4.x releases are dual stack.

Two enablement side effects and two connectivity requirements

A Kafka container called flow_data is created on the cluster hosting Prism Central. It stores data essential for Flow visualization. Do not delete it.
Enabling microsegmentation for the first time also requires enabling Advanced Networking.
On a Prism Central scale out instance, all PC VMs must be powered on.
Allow AHV hosts to reach the Prism Central VMs over TCP port 9446 for connection tracking data.

Alert 200614 catches a version mismatch after the fact and tells you to run an LCM inventory of FNS PE on each attached AHV cluster and upgrade the laggards. KB14262.

Sources
Flow Network Security Guide 5.2.0, Enabling Microsegmentation: Enabling Microsegmentation · Flow Network Security Guide 5.2.0, Enabling Microsegmentation: Microsegmentation Requirements for FNS Next-Gen 5.2.0 · Flow Network Security Guide 5.2.0, Installation and Upgrades: Installation and Upgrades · Flow Network Security Guide 5.2.0, Flow Network Security Product Generation and Release Version: Flow Network Security Product Generation and Release Version · Flow Network Security Guide 5.2.0, Enabling Microsegmentation: Limitations

Knowledge

Create categories and associate to VMs

Policies apply to categories, not to VMs, so any number of VMs starting in a category are secured without administrative intervention. In the Next-Gen policy model any category can be a secured entity, not just AppType. Built-in categories are AppTier, AppType, Environment, Quarantine (immutable), ADGroup, and ADGroup:Default. Bring your own, but never reuse system defined names.

VPC as a category, new in 5.2.0: assign a set of VPCs to a category so a policy scope spans multiple VPCs, usable in inbound and outbound rules, as a secured entity, and inside an entity group.

RBAC split worth knowing here Flow Admin can create, delete, and update Category. Flow Policy Author cannot, but can create, delete, and update Category Mapping. So a Policy Author assigns existing categories to VMs but cannot create new ones.

Association is sourced. Creation is not.

A category is a key value pair that groups similar entities. Associating a policy with a category ensures the policy applies to all entities in the group regardless of how the group scales with time. Currently you can associate only VMs with a category.

Per VM: Infrastructure > Compute > VMs > click the VM > Categories tab > Manage Categories. Each VM has a one to many relationship with categories, and categories have a many to many relationship with policies.
In bulk: Infrastructure > Compute > VMs > tick the target VMs > Actions > Manage Categories > type the name in Set Categories and pick from the matching list.
Hosts, clusters, and images have their own association topics, as does the AHV Administration Guide.
Timing: a host category attach or detach takes around five minutes to reflect in the applicable VM-Host affinity policies. The Entities tab count updates immediately; the two views use different APIs.

Creating a category

Sourced from the Prism Central Admin Center Guide 7.6, topics 059 to 071. This closed the last documentation gap in the guide.

Version caveat, read before memorizing This guide is pc.7.6 against a tested pc.7.3. It is the only source for category creation: the 2024.2 Admin Center Guide has no category topics at all, and neither Prism Central Guide edition carries the procedure. So it is used despite the mismatch. One part is explicitly new in 7.6 and does not apply to the tested version, flagged below.

Procedure: Application Switcher > Admin Center > Categories > New Category.

Field	What goes in it
Key	The attribute type used to filter entities, for example `Department` or `Location`
Description	Optional
Values	The attribute instances. For key `Department`: Engineering, HR, Sales, Marketing

Values are case sensitive when the field checks for duplicates. Sales and sales are treated as two unique values and both are accepted.

Assigning: Application Switcher > Infrastructure > the entity’s dashboard > select entities on the List tab > Other Actions > Manage Categories > Set Categories > Save. Policies associated with the category you pick appear in the Possible Associated Policies field, the closest thing the UI gives to an impact preview.

Rule	Detail
Maximum categories per entity	64
Assignable entity types	Clusters, VMs, hosts, volume groups, images, subnets
Update	User defined only. System defined categories cannot be updated. Category Summary page > Update > change Key, Description or Values > Save
Delete	User defined only, and only when no policy uses the category. Categories List > select > Actions > Delete

Marked Important in the guide: the Storage: $Default category assigns the default storage policy to an entity such as a VM or volume group. Do not associate any other policy with it or change it in any way.

Not a version conflict The 7.6 guide lists six assignable entity types. FVN 6.0’s Category Management topic says “Currently, you can associate only VMs with a category”. Both are true, and they answer different questions.

Prism Central assigns categories to many entity types for grouping and logical organization: clusters, VMs, hosts, volume groups, images, subnets.
Flow Network Security acts on categories at the VM level only. FNS uses categories as the building blocks of security policies to segment traffic between VMs. AppType and AppTier define groups of VMs and secure communication to, from, and between them.

For the exam: a category can carry other entity types, but FNS enforces on VMs. If a question asks what FNS secures, the answer is VMs. If it asks what a category can be assigned to, more than VMs.

For client work, the more useful half: tagging a subnet or a volume group with a category does not put it behind a Flow policy. Do not design as though it does.

Two related points, flagged by source FNS security policies apply only to VMs using the kNormalNic vNIC type, not kDirectNic. This comes from a Nutanix KB rather than from the product guides, where kNormalNic appears only in the traffic mirroring procedure. Unverified against the product documentation, but worth knowing: a VM with a passed through or direct attached NIC silently falls outside Flow enforcement. Verify before relying on it in a client design.

Policy rules applying to VMs within the policy’s project scope is FNS 7.6 behaviour tied to Projects 2.0. It does not apply at the tested FNS 5.2.0, the same way project scoped categories do not apply at the tested pc.7.3. Do not carry it backwards.

Filtering the Categories List: Key or Value conditions are Contains, Equal to, Not equal to, Doesn’t contain, Starts with, Ends with. You can also filter by Owner Projects, Shared Projects, Type (System or User), Entity Types (Cluster, Host, Image, Subnet, VM, Volume Group) and Policy Types (Affinity, Alert, Image Placement, NGT, Protection, QoS, Security, Storage, VM Startup). The list shows Associated Entities and Associated Policies counts; a dash means not available or not applicable.

Project scoped categories: a 7.6 change, NOT the tested behaviour

“Starting with Prism Central pc.7.6, categories transition to a one to one association with projects. Each project owns and manages its categories entirely within its own boundaries.”

This does not apply to pc.7.3, which the exam tests. Recorded only so you recognize it as out of scope if you read the 7.6 guide directly. The related 7.6 concepts are out of scope for the same reason: system defined categories assigned to a Default Project and shared with all projects; on upgrade to pc.7.6 all existing categories migrating to the Default Project as legacy categories with assignments and policies preserved; read only access for Project Admins and standard users; and only a Super Admin, or a Prism Central Admin with administrative privileges over the Default Project, able to modify them.

One naming detail: the system defined Platform-Projects category “appears as Calmproject in the versions earlier than pc.7.6″, so on the tested 7.3 you would see Calmproject.

Sources
Flow Network Security Guide 5.2.0, Security Policies: Security Policies · Flow Network Security Guide 5.2.0, Security Policy Model: Built-In Categories for Security Policies · Flow Network Security Guide 5.2.0, Security Policy Model: Security Policy Model · Flow Network Security Guide 5.2.0, Role-Based Access Control: Flow Network Security Roles and Permissions · Flow Virtual Networking Guide 6.0, Virtual Private Cloud Management: Category Management · Prism Central Infrastructure Guide 7.3, Compute Entities: Categories Tab and Managing Categories, and Policies in Infrastructure: Associating VMs and Clusters with Categories · Prism Central Admin Center Guide 7.6, Category Management

Knowledge

Prism Element CVM memory for Flow Network Security

Alert 200613 Flow Network Security CVM Memory Recommendation carries a figure that appears in no other Nutanix document.

Field	Content
Name	Flow Network Security CVM Memory Check
Description	Flow Network Security needs a minimum of 40 GB on the PE CVMs in order to function at scale
Alert message	CVM memory configured on `cluster_entity` is below `reason`
Cause	FNS deployments where the CVM has less than 40 GB memory have limited rule reconciliation performance and scale of VMs per Security Policy density
Impact	FNS services may fail when operating at scale without additional memory in the CVM
Resolution	Increase PE CVM memory to 40 GB or higher. KB13595

The complete Flow memory picture

Where	Requirement	Source
Each Prism Central VM	resized by 2 GB for FNS	FNS 5.2 guide
Each AHV host	3 GB userspace + 1 GB kernel for FNS	FNS 5.2 guide
Each AHV host	2 GB for the Network Controller	FVN 6.0 guide
Each PC VM, Small PC	+3 GB, +2 vCPU for the Network Controller	FVN 6.0 guide
Each PC VM, Large PC	+4 GB, +3 vCPU for the Network Controller	FVN 6.0 guide
Each Prism Element CVM	40 GB minimum for FNS at scale	Alert 200613, PE Alerts Reference 7.6
Each AHV host	more than 4 GB free for a Flow mode change to succeed	Alert 200606

Verified against KB-13595 The earlier 7.6 version caveat is withdrawn for this figure. KB-13595, last modified 12 December 2025, predates the 7.6 alerts reference and states the same numbers word for word. What the KB adds:

The alert is an NCC check, introduced in NCC 4.6.3.
Severity is INFO, not warning or critical. It is a sizing recommendation, not a gate.
The trigger is vNIC state churn, not policy count alone. Power on and off, live migrations, and bulk category or policy changes queue FNS control plane tasks on the PE clusters and pressure the microsegmentation service memory.
Related failure mode by number: KB15782, FNS unable to apply AHV host security policy rules due to Microsegmentation service OOM. Not documented in the Flow guides.
Workaround when memory cannot be raised: limit the batch size of bulk FNS policy, VM, and category operations with a delay between batches. If not yet migrated to the FNS Next-Gen policy model, wait until after the CVM memory increase before migrating. See objective 5.3.

Checking and increasing CVM memory

Check: Prism UI Menu > VM > Table, tick Include Controller VM, search CVM, review the Memory Capacity column. Or from a CVM, allssh free.

Increase: Prism Element web console > Settings > General > Configure CVM > select Target CVM Memory Allocation > Apply. Run NCC first, per the guide’s own step 2.

Rule	Detail
Web console ceiling	64 GB maximum. To go beyond 64 GB, contact Nutanix support. 40 GB is comfortably inside the 1-click path
ESXi clusters	Enter vCenter Server IP and administrator credentials via Add vCenter first. Credentials are encrypted on the CVM and removed after the update
The value is a floor	AOS allocates to each CVM that has less than the specified amount. A CVM at 20 GB with 28 GB selected goes to 28 GB. A CVM at 48 GB with 28 GB selected stays at 48 GB
Disruption	Resizing requires a restart. Only one CVM restarts at a time, preventing production impact
Not supported	Decreasing CVM memory below the recommended minimum requirements

Foundation context: at cluster creation Foundation sets CVM memory to available RAM minus 16 GiB, capped at 256 GiB from Foundation 5.3 onward, and CVM vCPU to host cores minus 2, capped at 22 vCPUs through Foundation 5.3.x (the cap no longer applies from Foundation 5.4).

Sources
Nutanix KB-13595, Alert A200613 MicrosegCvmMemory · Prism Web Console Guide 7.3, Cluster Management: CVM Memory Configuration · Prism Web Console Guide 7.3, Cluster Management: Increasing the Controller VM Memory Size · Prism Element Alerts Reference 7.6

Objective 5.2: Prepare a Cluster for Flow Virtual Networking

Knowledge

Confirm the Network Controller is enabled and the right version · Cluster compatibility

Enable: Prism Central Settings > Network Controller > Enable, then check the Recommendations section. Auto enabled on X-Large at pc.2023.3 or later.

The dependency The Network Controller depends only on the AHV and Prism Central versions. All clusters managed by the same Prism Central must run the same compatible AHV version.

Four ways incompatibility surfaces

At enablement: NC is created but Prism Central raises alert 130201, “Failed to configure host for Atlas networking”.
At deployment with a compatible PC package but incompatible AHV package: NC is deployed but not enabled.
At registration: NC is not enabled by default on a newly registered PE cluster with incompatible AHV.
At upgrade: the NC upgrade fails to start after the pre check if any FVN enabled cluster runs an incompatible AHV version.

Other prerequisites

Prism Central hosted on an AOS cluster running AHV. Not ESXi, not Hyper-V.
Prism Admin role, or the task fails with User Denied Access.
Microservices Infrastructure enabled, on by default from pc.2022.9.
A Prism Central virtual IP must exist and must not be changed afterwards.
Connectivity PC to PE, plus internet to ECR (Docker images) and S3 (LCM portal) unless dark site.
All AHV clusters at the same site as their registered Prism Central. Each site needs a local PC.
Compute only nodes need AOS 7.0+ and Files 5.1+; CO clusters cannot create VLAN Subnets.

Exclude a cluster with <atlas> config.add_to_excluded_clusters <cluster uuid>, verify with acli atlas_config.get.

Guides disagree on the role FVN 6.0 says Prism Admin is required to enable and use FVN. FVN 7.6.0 says Super Admin is required to deploy the Network Controller by enabling Flow in Integrated mode, and that without it the Flow Management page is not available. The exam is scoped to 6.0.

Sources
Flow Virtual Networking Guide 6.0, Flow Virtual Networking Configurations: Flow Virtual Networking Configurations · Flow Virtual Networking Guide 6.0, Requirements and Limitations of Flow Virtual Networking: Requirements and Limitations of Flow Virtual Networking · Flow Virtual Networking Guide 6.0, Flow Virtual Networking Configurations: Network Controller Health Checks Attributes · Flow Virtual Networking Guide 6.0, Flow Virtual Networking Configurations: Upgrading the Network Controller · Flow Virtual Networking Guide 7.6, Identity and Access Management

Knowledge

Layer 2 subnet extension: prerequisites and best practices

These sit in the back half of the Layer 2 Network Extension chapter and are easy to skim past. Several of them only surface as a broken migration at 2 AM.

Two prerequisites that are easy to miss

Pair the local and remote Prism Centrals (availability zones) to use the Create Subnet Extension wizard and get bidirectional communication. Paired AZs support both VXLAN over VPN and VTEP based extension. You can also use the manual gateway and connection workflows instead of pairing.
Set up a default static route, 0.0.0.0/0, with the external network next hop for the VPC used for any subnet extension. That static route is what gives the Network Gateway appliance its NTP and DNS access.

Retaining VM IP addresses across an extended subnet

With Nutanix IPAM, address ranges in the paired subnets must be unique. From Network Controller 6.0.0 you can no longer update Overlay subnets in a Layer 2 extension to have overlapping IP pools; the product enforces it.
With third party IPAM on both sides you check for conflicts yourself. With Nutanix IPAM on both sides, Prism Central displays a message when a conflict exists.

The ARP trap when moving VMs out to a non Nutanix environment Extend a subnet from Nutanix to non Nutanix, move an IPAM managed VM across, and the Nutanix VM is powered off. The Network Controller keeps answering ARP for that powered off VM, which is its default behaviour, and connectivity breaks in the new environment. Delete the VM NICs on the Nutanix side if you are keeping the VMs. Nothing on the destination side points at this as the cause.

Choosing the extension type

If site to site connectivity is already encrypted, use VTEP only extension and avoid paying for encryption twice.
Use the Subnet Extension to a Third Party Data-Center workflow when extending to more than one other AZ (point to multipoint), or when extending between clusters managed by the same Prism Central.
Avoiding tromboning: provide a valid gateway IP on both the local and remote sides. Supplying one on only one side deliberately hair pins all traffic through that side. Do it on purpose or not at all.

Where the work happens: Network & Security → Connectivity → Subnet Extensions tab. Three paths: Create Subnet Extension Across Availability Zones (point to point over VPN or VTEP), Create Subnet Extension To A Third Party Data-Center (point to point or point to multipoint over VTEP), and Update Subnet Extension Across Availability Zones, which carries the same fields as create and is reached by selecting the extension and clicking Update, or from its Summary tab.

Layer 2 extension over VPN specifically

Use it when the two AZs have no underlying secure connectivity, for example across the Internet, where IPSec supplies both connectivity and encryption. Also for lift and shift from a VLAN subnet to a VPC subnet retaining the same VM IP addresses, where VPN provides Layer 3 connectivity and encryption from the VPC segment back to the other VLAN subnets. Consider VTEP only without VPN when encryption is not required.

Two hard prerequisites for VPN based extension The subnet extension feature supports only the Nutanix VPN solution, not third party VPN, at both AZs. And the VPN gateway version must be 5.0 or higher.

One more, from the Connections Management chapter: you can enable network segmentation on a Layer 2 Network Extension that has no gateway. That points at the Security Guide topic “Segmenting a Stretched L2 Network for Disaster Recovery”, in the same network segmentation chapter covered under objective 5.4. Layer 2 Network Extension is also called Layer 2 Stretch, so both names appear.

Sources
Flow Virtual Networking Guide 6.0, Connections Management: Layer 2 Network Extension · Flow Virtual Networking Guide 6.0, Connections Management: Subnet Extension Workflow · Flow Virtual Networking Guide 6.0, Connections Management: Layer 2 Network Extension Over VPN · Flow Virtual Networking Guide 6.0, Connections Management: Connections Management

Objective 5.3: Determine Order of Upgrades and Upgrade Paths

LCM sequence on Prism Central: Pre Upgrade > Upgrade Prechecks > Continue, then View Upgrade Plan > Apply Updates. In a dark site, LCM must reach the local web server hosting the bundles.

Knowledge

Incompatible clusters, Network Controller updates, FNS updates

Two actions on an incompatible cluster: upgrade AHV with LCM to the version compatible with the Network Controller upgrade version, or exclude the cluster with config.add_to_excluded_clusters. Excluding is also the path to being able to unregister that Prism Element cluster. The one cluster you can never unregister is the one hosting the FVN enabled Prism Central.

Prism Central upgrade in a Nutanix environment

Only through LCM. The upgrade involves Microservices Infrastructure and the services on it.
Dark site needs four bundles on the LCM web server: Security Dashboard CVE Data, LCM Framework, Prism Central LCM, and Prism Central MSP Apps. The Service Manager feature installs PC services and applications at a dark site.
Port 9440 must be open in both directions between the PC VM and any registered clusters.
Microservices Infrastructure enablement takes up to 30 minutes on a supported single VM PC. Confirm with ecli task.list. Failure is reported after about 2 hours 5 minutes.

Network gateway upgrades

Version: Connectivity > Gateways > click the name > Gateway Version in Properties.
Detect: Admin Center > LCM > Inventory tab.
Upgrading the VPN appliance disrupts traffic for the duration of the operation.
Update Gateway fields: External Routing Protocol (Static or eBGP), eBGP ASN (1 to 65000 if you have no BGP environment, must not conflict), VTEP IP Address list, VxLAN UDP port default 4789, do not change, BGP Service IP Address and remote eBGP ASN. Some parameters are greyed out; to change those, create a new gateway and delete the old one.

Cluster expansion with FVN enabled When GENEVE traffic has been moved to non default virtual switches, the FVN stack (Network Controller with brAtlas) is not present on the new node, causing VM migrations to the node to fail. The procedure applies only if the new node is not reimaged by Foundation during expansion. Pre expansion checks: NIC failover on br0 of vs0 targeting under two seconds from link up to positive ping; mokutil --sb-state for Secure Boot; ovs-appctl lacp/show where each uplink bond must read Negotiated, not Active; and manage_ovs show_uplinks from the new node’s CVM.

A sizing prerequisite to the Next-Gen migration KB-13595 states that if the Prism Element CVMs are below the 40 GB FNS recommendation and you have not yet migrated to the Next-Gen policy model, wait until after the CVM memory increase before migrating the security policies. The migration is exactly the kind of bulk policy operation that queues FNS control plane tasks and pressures the microsegmentation service memory on an undersized CVM. Ordering for an undersized cluster: raise PE CVM memory to 40 GB or higher, then migrate to Next-Gen. See objective 5.1 for the Configure CVM procedure and its 64 GB web console ceiling.

General cluster expansion prerequisites,

These come from the general expansion topic rather than the Flow Virtual Networking variant, and are easy to skip past.

Check the Health dashboard first and resolve any failing health checks before adding nodes, then run NCC as a final confirmation.
Wait for any ongoing expand cluster operations to complete. They do not queue.
Check the Hardware dashboard for metadata state. Any node showing “Metadata store disabled on the node” or “Node is removed from metadata store” must be fixed first with Enable Metadata Store.
New nodes must be physically connected on the same subnet as the cluster.
The expansion process compares AOS versions and upgrades whatever is needed so every node lands on the same version. Budget the time.
The process varies with AOS, hypervisor, encryption and hardware. Rack fault tolerance, data at rest encryption and Hyper-V are handled as special case steps out of sequence.

Where to confirm a physical NIC problem rather than a virtual one The Host NICs tab on a selected host lists per NIC: name, speed in KBps, MAC address, received and transmitted packets, dropped Rx and dropped Tx packets, and Rx and Tx packet errors. Clicking a NIC opens time series graphs for each. Drops or errors here mean the problem is below the virtual switch, so stop looking at policies and subnets.

Sources
Flow Virtual Networking Guide 6.0, Flow Virtual Networking Configurations: Upgrading the Network Controller · Flow Virtual Networking Guide 6.0, Flow Virtual Networking Configurations: Control User Access in Flow Virtual Networking (RBAC) · Flow Virtual Networking Guide 6.0, Network Gateway Upgrades: Network Gateway Upgrades · Flow Virtual Networking Guide 6.0, Connections Management: Updating a Network Gateway · Prism Central Infrastructure Guide 7.3, Getting Started: Prism Central Upgrade in Nutanix Environment · Prism Web Console Guide 7.3, Hardware Management: Expanding a Cluster with Flow Virtual Networking Enabled · Prism Web Console Guide 7.3, Hardware Management: Expanding a Cluster (general prerequisites and the Host NICs tab)

Objective 5.4: Configure Virtual Switches and MTU

Knowledge

Segregate East West and North South traffic

The default, which is usually fine By default the system places all VPC East/West traffic in the AHV VLAN, and all North/South traffic in the external network VLAN. Do this procedure only if you require physical network separation.

East/West (intra VPC): sent and received on the AHV host internal port br0 by default, Geneve encapsulated, stays within the VPC.
North/South: enters or exits the VPC. The external subnet determines the virtual switch and VLAN.
With network segmentation on vs1, the AHV internal interface terminates Geneve East/West traffic on internal port br1.

Procedure

# 1. Create the virtual switch (for example vs1) on every host in the cluster.

# 2. (Optional) tag a VLAN on the non-default bridge, on the AHV host as root:
root@ahv# nmcli -f ovs-port con show ovs-port-<bridge-name>
root@ahv# nmcli con modify ovs-port-<bridge-name> ovs-port.tag <vlan-tag> ovs-port.vlan-mode access
root@ahv# nmcli con up ovs-port-<bridge-name>

# 3. From the CVM, set host IPs and gateway for the virtual switch:
nutanix@cvm$ acli net.update_virtual_switch vs1 \
  host_ip_addr_config='{host-uuid1:10.10.10.15/24;host-uuid2:10.10.10.16/24}' \
  gateway_ip_address=10.10.10.1

# 4. Point VPC east-west traffic at it:
nutanix@cvm$ acli net.set_vpc_east_west_traffic_config virtual_switch=vs1
# add permit_all_traffic=true to allow SSH or SNMP to the secondary host IP
# update later with acli net.update_vpc_east_west_traffic_config virtual_switch=vs1

Two things that bite acli net.update_virtual_switch updates one node at a time and can take more than 20 minutes on larger clusters; avoid network activity during that window. And set_vpc_east_west_traffic_config by default blocks all traffic to the secondary IP of the AHV host except GENEVE and ICMP unless you pass permit_all_traffic=true.

Virtual switch IP constraints, each with its own failure message

Constraint	Failure message
Host IP must not be the subnet broadcast address	Host IP address cannot be assigned equal to the subnet broadcast address.
Subnet prefix must be /30 or less, so at least two usable addresses	Prefix length cannot be greater than 30.
All host IPs in one virtual switch must be in the same subnet	Different host IP address subnets found.
Gateway must be in the same subnet as the host IPs	Gateway IP address is not in the same subnet.

Virtual switch requirements and migration gotchas

AOS 5.19 or later with AHV 20201105.12 or later.
Virtual bridges must have the same name, MTU, and uplink bond type on all nodes.
Do not create, update, or delete any virtual switch while an AOS or AHV upgrade is running.
Migration needs the same bond type on all hosts, LACP speed fast or 1 second with no lacp suspend-individual, and upstream spanning-tree portfast or edge trunk. Otherwise a 30-second timeout beats the migration’s 20-second non modifiable timer.
For vs0: all configured uplink ports available, and all host IPs resolvable to the gateway via ARP.

VPN prerequisites, since VPN sits on this plumbing

Guest VM NIC MTU 1356 for VMs sending traffic over Nutanix VPN connections.
Peer IP for iBGP, or Area ID in IP address format for OSPF.
Gateway ASN must not match any on premises BGP ASN; pick from 0 to 65000 if you have none.
Encryption AES128, AES256, 3DES, AES256GCM128. Authentication MD5, SHA1, SHA256, SHA384, SHA512. DH groups 14 (2048-bit MODP), 19 (256-bit random ECP), 20 (384-bit random ECP).

Sources
AHV Administration Guide 6.10, Network Traffic Types · AHV Administration Guide 6.10, Configuring Virtual Switch for VPC Traffic Types · AHV Administration Guide 6.10, Virtual Switch Limitations · Flow Virtual Networking Guide 6.0, Connections Management: Prerequisites for VPN Configurations · Flow Virtual Networking Guide 6.0, Requirements and Limitations of Flow Virtual Networking: Requirements and Limitations of Flow Virtual Networking · Nutanix knowledge base, Enabling Jumbo MTU on AHV for UVMs

Knowledge

Segregate UVM, management, and replication traffic

Where replication traffic segregation actually lives Virtual switches segregate UVM overlay traffic. They do not segregate CVM replication traffic. That is network segmentation, a separate mechanism documented in the Nutanix Security Guide 7.3, which the FVN guide references and which the FVN and AHV guides do not cover. This is the part of objective 5.4 that lives outside the Flow documentation entirely.

Traffic type	What it is	CVM interface
Backplane	Intra cluster traffic the cluster needs to function: CVM to CVM, CVM to host, storage RF replication, host management, high availability. On AHV, VM live migration is backplane too and uses the AHV backplane interface, VLAN and virtual switch	eth2
Management	Administrative traffic: Prism Element, SSH, remote logging, SNMP. Defined as anything not on the backplane network, which includes communication between user VMs and CVMs	eth0

Note that management is defined negatively, as whatever is not backplane. That is Nutanix’s own wording. In an unsegmented cluster the CVM has two vNICs: eth0 on the default external virtual switch carrying all external traffic, backplane and management alike, and eth1 on the internal network to the hypervisor. Segmentation is what moves backplane traffic onto eth2, on its own VLAN or its own physical network.

Five services can be isolated to their own virtual network

Management, the default network, which cannot be moved off CVM eth0
Backplane
RDMA, for Stargate to Stargate over the rdma0 vNIC
Service specific disaster recovery
Service specific Volumes

Three segmentation types and their AOS floors: logical network segmentation from AOS 5.5, physical network segmentation from AOS 5.11, service specific traffic isolation from AOS 5.11.

Host networking comes first, and this is where manage_ovs appears Configuring host networking is a prerequisite for both physical and service specific segmentation, and it differs by node state.

Nodes already in a cluster: remove the uplinks from the default virtual switch vs0, create a virtual switch for the backplane traffic or the service you are isolating, then add the uplinks to it.
An unconfigured node being prepared for cluster expansion: SSH to the AHV host as root, create /dev/shm/config/, then from the CVM run manage_ovs --bridge_name <bridge-name> create_single_bridge and set uplinks with manage_ovs --bridge_name <name> --interfaces <list> --bond_name <name> --bond_mode <mode> update_uplinks. The node must include a cluster_config file for manage_ovs to work, and this is done only on a newly imaged or Foundation setup. The --bridge_name command may print “Failed to fetch gflags. Acropolis service might be down”, which the guide says to ignore.

Prism Element can configure a VLAN only on AHV hosts. On ESXi you configure the VLAN on the physical switch and the port group, and build vSwitches and port groups instead of virtual switches.

Do not confuse this with the VPC traffic type procedure under 5.4 That one creates a virtual switch through the Prism Element web console and tags a VLAN with nmcli, per AHV Admin Guide “Configuring Virtual Switch for VPC Traffic Types”. This one prepares host networking for CVM traffic segmentation and uses manage_ovs. Different mechanism, different commands, different purpose. manage_ovs matters here because it writes cluster configuration that survives host restarts, which manual OVS commands do not.

Then step one of isolation itself is still manual Service specific isolation is a two step process. You configure the networks and uplinks on each host yourself. Prism Element only creates the vNIC the service needs and places it on the bridge or port group you name, so you must create that bridge or port group on every host and add the uplinks. Then configure segmentation for the service in Prism Element: gear icon → Network Configuration → Internal Interfaces → Create New Interface.

Disaster recovery prerequisites, which are the replication answer

The VLAN and subnet for the segment must be routable.
n+1 IP addresses per cluster, where n is the node count. The extra one is the virtual IP.
Segmentation for DR must be enabled at both sites, local and remote, before you configure remote sites at those sites.

Configurations that do not support network segmentation at all

CVMs with a manually created eth2 interface.
CVMs whose eth2 has a manually assigned IP address.
CVM interfaces connected to port groups backed by NSX NVDS switches.

AOS creates eth2 on every CVM during upgrade whether or not you use it, and you must never configure it by hand. Manual multi homed CVM interfaces are deprecated from AOS 5.15, per KB 9479 and Field Advisory 78.

Two prerequisites that bite Proxy ARP must be disabled within the Nutanix VLAN before configuring segmentation. And if the cluster is registered to Prism Central with a segmented Data Services IP in a secondary subnet, you must add a second DSIP in Prism Central’s original subnet, because Prism Central cannot perform upgrade operations over a segmented DSIP. The segmented DSIP and the cluster DSIP are distinct entities.

Troubleshooting hook

“Failed to restart one or more services after Backplane was enabled” means the segmentation task completed but one or more services did not restart in time. SSH to a CVM, run cluster start, and confirm every service reads UP.

Physical segmentation with Volumes Stargate does not monitor the health of a segmented network, so with physical segmentation a network failure or connectivity issue is not tolerated. Build redundancy in: two or more uplinks in a fault tolerant configuration, connected to two separate physical switches.

Sources
Nutanix Security Guide 7.3, Securing Traffic Through Network Segmentation: Traffic Types In a Segmented Network · Nutanix Security Guide 7.3, Securing Traffic Through Network Segmentation: Segmented and Unsegmented Networks · Nutanix Security Guide 7.3, Securing Traffic Through Network Segmentation: Prerequisites · Nutanix Security Guide 7.3, Securing Traffic Through Network Segmentation: Limitations · Nutanix Security Guide 7.3, Securing Traffic Through Network Segmentation: Cluster Services That Support Traffic Isolation · Nutanix Security Guide 7.3, Securing Traffic Through Network Segmentation: Unsupported Configurations for Network Segmentation · Nutanix Security Guide 7.3, Securing Traffic Through Network Segmentation: Troubleshooting Tips · Nutanix Security Guide 7.3, Securing Traffic Through Network Segmentation: Service-Specific Traffic Isolation · Nutanix Security Guide 7.3, Securing Traffic Through Network Segmentation: Isolating Service-Specific Traffic

Knowledge

Multicluster virtual switches

Everything above describes the single cluster virtual switch created in Prism Element. FVN 6.0 adds a second, different construct created in Prism Central. Objective 5.4 does not qualify which kind, so both belong here. Minimum versions are exactly the tested stack: Prism Central pc.7.3, Network Controller 6.0.0, AOS 7.3, AHV 10.3.

	Single cluster virtual switch	Multicluster virtual switch
Created in	Prism Element web console	Prism Central only
Spans	All hosts and ports on the one cluster it is created in	Hosts and uplink ports across multiple clusters managed by that Prism Central
Name in the list	Suffixed Single Cluster	No suffix
Scope attribute	`Single Cluster`	`Multi Cluster`

The trap A virtual switch created on a Prism Central instance is a multicluster virtual switch even if that Prism Central manages only one cluster. Only a virtual switch created in the Prism Element web console is a single cluster virtual switch. The classification is by where you created it, not by how many clusters it touches.

What can attach, and a UI gotcha

Only a Network Controller based VLAN Subnet can be mapped to a multicluster virtual switch. Not a VLAN Basic Subnet, not an individual Overlay subnet. Associating a VPC is v4 API only, with no UI path.

While creating a VLAN Subnet, multicluster virtual switches do not appear in the Virtual Switch dropdown. You must clear the VLAN Basic Networking checkbox in Advanced Configuration to make them appear. This ties to the default VLAN type setting under objective 1.2: if the default is still the AHV based VLAN Basic Subnet, the dropdown will not offer your multicluster switch.

Limitations, and two are design constraints rather than footnotes

Cannot attach VLAN Basic Subnets or individual Overlay subnets.
Cannot migrate an existing single cluster virtual switch to a multicluster one. There is no conversion path.
Cannot migrate VMs using cross cluster live migration (CCLM).
Cannot protect VMs using Nutanix Disaster Recovery recovery plans.

Creating one

Prism Central > Infrastructure > Network & Security > Virtual Switches > Create Virtual Switch. General tab takes Name, optional Description, and Physical NIC MTU (bytes), which shows a default of 1500 that you must delete before typing. Range 1280 to 9000, and Nutanix recommends a value higher than 1500. Uplink Ports tab takes a Bond Type, then +Add Uplink Ports: expand each cluster, tick the clusters to uplink, click Select Uplink Ports, expand each selected cluster, tick the ports on each host, Save.

All bond types except No Bond require a minimum of two ports on each host in every cluster that Prism Central manages.

Bond type	Use case	Max VM NIC	Max host
Active-Backup	Recommended. Default. All traffic over a single active adapter	10 GB	10 GB
Active-Active with MAC pinning (balance-slb)	Caveats for multicast. Each VM NIC on one adapter at a time. Do not use with LACP	10 GB	20 GB
Active-Active (LACP with balance-tcp)	Requires LACP and link aggregation. Balances VM NIC TCP and UDP sessions across adapters	20 GB	20 GB
No Uplink Bond	No uplink or a single uplink per host. 0 or 1 uplinks	n/a	n/a

Throughput figures assume 2 x 10 Gb adapters and the guide says they are not hard limits. Default LACP settings for Active-Active: Speed Fast (1s), Mode Active fallback-active-backup, Priority Default and not configurable.

Mapping the traffic, which is API only

After creating the switch you must map the secondary IP addresses of the hosts of every cluster in it, and optionally map its UUID to a VPC. Both are v4 API only. You need the secondary IPs with prefix, their gateway IPs, a valid VLAN ID configured in the underlay and connected to the relevant upstream router, and the switch UUID (from its details page, or extId under data from the Virtual Switch API GET).

"ownerType": "PC" is what marks a virtual switch as multicluster. Any virtual switch created in Prism Central specifies ownerType as PC.
Per host: extId, internalBridgeName (for example br1), hostNics (for example eth1, eth3), ipAddress.
Per cluster: extId, hosts, gatewayIpAddress, vlanIdentifier.
vlanIdentifier is the VLAN ID of the cluster on which you deploy the switch. It is NOT the VLAN ID that the Controller VMs or hosts use.

Nutanix recommends connecting all the clusters to the same VLAN when a multicluster virtual switch connects them. Alternatively, ensure all the VLANs the clusters use connect to the same upstream router or switch.

Viewing, updating, deleting

List attributes: Name, Scope, Cluster, Bond Type, MTU. Scope is only visible if you build a custom view and add it, so the name suffix is the quicker tell. Filters: Name, Scope, MTU range, Bond Type. Details page has only two tabs, Summary and Alerts. The Summary tab carries a Properties widget, an Associated Subnets widget (default subnet type VLAN), and an Uplink Ports widget counting 25G and 10G NIC ports. A virtual switch alert typically indicates a problem with the switch or its associated Open vSwitch (OVS) bridges on AHV hosts.

Changing the Bond Type resets the selected uplink ports. A confirmation dialog warns you, and after confirming you must reselect them. You can update uplink ports without changing the bond type.

Before deleting, you must remove all networking resources on the switch: VLANs, Overlay subnets, and Externally Routable Prefixes.

One referenced topic has no matching content The guide points at “Multicluster Virtual Switch Mapping Update Behavior” for what happens when you change an existing mapping. No topic with that title exists in any Flow Virtual Networking or Prism Central guide. Update-behaviour detail for a live mapping is unsourced here.

Sources
Flow Virtual Networking Guide 6.0, Network and Security Entities: Multicluster Virtual Switches · Flow Virtual Networking Guide 6.0, Network and Security Entities: Multicluster Virtual Switches summary and details views · Flow Virtual Networking Guide 6.0, Multicluster Virtual Switch Management: Multicluster Virtual Switch Management · Flow Virtual Networking Guide 6.0, Multicluster Virtual Switch Management: Creating a Multicluster Virtual Switch · Flow Virtual Networking Guide 6.0, Multicluster Virtual Switch Management: Assign a Subnet to a Multicluster Virtual Switch · Flow Virtual Networking Guide 6.0, Multicluster Virtual Switch Management: Mapping the Multicluster Virtual Switch Traffic · Flow Virtual Networking Guide 6.0, Multicluster Virtual Switch Management: Virtual Switch API Payload · Flow Virtual Networking Guide 6.0, Multicluster Virtual Switch Management: Updating a Multicluster Virtual Switch · Flow Virtual Networking Guide 6.0, Multicluster Virtual Switch Management: Deleting a Multicluster Virtual Switch

Knowledge

Prism Element health checks that back this objective

from Prism Element Alerts Reference 7.6. These are the checks that fire when the virtual switch and bond plumbing is wrong.

Alert	Name	What it catches
3070	AHV Secondary IP Ping Check from Node	Whether each AHV host can ping the secondary IP of all other hosts. Stated impact: advanced networking may encounter issues if enabled and configured to use the corresponding virtual switch. This is the check that fires when east west traffic is segregated onto a non default virtual switch and the secondary host IPs are wrong
103101	Inconsistent Bridge/vSwitch configuration	Bridge or vSwitch config on a host differs from other hosts or from the zeus configuration. Cause: config modified during cluster lifetime without restarting genesis. KB 8018
103106	Bond uplink VLAN config check	VLAN misconfiguration on uplink ports in a bond. Hosts, CVM or user VMs can lose connectivity if the active uplink changes, and balance-slb and balance-tcp may underperform. Requires link layer unicast with an IPv4 payload, including link local 169.254.0.0/24, to pass
103107	Bond uplink connectivity check	At least two uplinks in the bond must be connected or network redundancy is lost

Version caveat. The alert reference is v7.6 against a tested 7.3.

Sources
Prism Element Alerts Reference 7.6, Alerts and Health Checks: Network

Objective 5.5: Configure and Manage User Roles

Knowledge

Which roles can and cannot create a VPC

The permissions table carries an explicit line: Network Controller operations are available to the Super Admin and Prism Admin roles. Separately, FVN 6.0 requires Prism Admin to enable and use it, and IPFIX operations require Super Admin only.

Super Admin belongs in the answer The Prism Central 7.3 Built-in Roles List gives the three network relevant entries verbatim: VPC Admin, “Manage VPCs and related entities. Agnostic of the physical network infrastructure.” Network Infra Admin, “Manage the infrastructure and underlay networking.” Network Shared Resources Viewer, “View access for shared resources in underlay and overlay networking.”

Read the VPC Admin line carefully. “Agnostic of the physical network infrastructure” states the split more cleanly than the permission counts do. Above both sits Super Admin, “every feature in the platform”, with the table note “Highest level admin with full infrastructure and tenant access”. Every feature includes creating a VPC.

Short answer: Super Admin and VPC Admin can. Network Infra Admin and Network Shared Resources Viewer cannot. Prism Admin is the role that enables Flow Virtual Networking in the first place at 6.0.

On the “cannot” half: no Nutanix document contains a sentence saying Network Infra Admin cannot create a VPC. It is read from the boundary between the two role descriptions and from the permissions table, where the VPC rows split cleanly. Solid, but read rather than stated.

A trap if you research this elsewhere Searches on this topic surface the NC2 console role hierarchy: Customer Administrator, Organization Administrator, Cluster Administrator, the matching Auditor roles, and Nutanix Central User. Those are not Prism Central IAM roles. They govern the NC2 cloud management console, they do not appear in the Prism Central Built-in Roles List, and the exam scope here is on premises FVN 6.0 with Prism Central 7.3. The same caution applies to Project Admin and Project Manager, which are real Prism Central roles but govern project and self service scope, not VPC creation.

Prism Admin and Super Admin are two different roles

Distinct built-in Prism Central roles that coexist in every release in the folder. The blueprint’s enablement question turns on this.

Role	Description, Prism Central 7.3 Built-in Roles List
Prism Admin	“Manage the infrastructure and platform, but cannot entitle other users to be admins.”
Super Admin	“Manage Nutanix deployment, set up, configure, and make use of every feature in the platform.” Table note: “Highest level admin with full infrastructure and tenant access.”

The proof they were not renamed into one another Both names appear side by side inside both FVN guides’ own permissions tables.

FVN 6.0: “Super Admin and Prism Admin Roles have permissions to perform this operation”, and separately “Super Admin role can only perform this operation”.
FVN 7.6.0: “Network Controller: Super Admin role and Prism Admin role provide permissions necessary to perform this operation”, “Overlay External Subnets: Super Admin and Prism Admin Roles provide the necessary permissions”, “NIC Profile: Only Super Admin and Prism Admin Roles have permissions”, and “IPFix: Only Super Admin role can perform this operation.”

IPFIX is the cleanest demonstration. In both releases it requires Super Admin and Prism Admin is not enough. If the two were one role renamed, that line could not exist.

So the 6.0-to-7.6 change is a real tightening of the enablement requirement, not a rename. It arrives alongside 7.6’s Integrated and Standalone deployment modes, which do not exist in 6.0. The exam is scoped to FVN 6.0, so Prism Admin is the answer.

On the User Admin rename: the rename of User Admin to Super Admin in newer Prism Central is real but is a different thread. In this folder “User Admin” appears only in the Prism Element directory role mapping list (Viewer, User Admin, Cluster Admin, Backup Admin). The Prism Central 7.3 built-in roles catalogue contains no User Admin at all, so that rename cannot explain Prism Admin versus Super Admin.

Independent confirmation The Prism Central Guide 7.3 states that two built-in roles can configure traffic mirroring: Network Infra Admin and Prism Admin. VPC Admin is not among them, which matches the FVN roles table showing every Traffic Mirror permission as Yes for Network Infra Admin and No for VPC Admin. The split holds in both directions: VPC Admin owns overlay and VPC objects, Network Infra Admin owns host level and underlay objects including mirror sessions. Custom role permissions for traffic mirroring: Create, Delete, Update, View, and View Stats for Traffic Mirror, plus View Cluster, View Cluster Networking Capabilities, View Host, View Uplink Bond, and View VM.

A role alone does nothing “Ensure that you assign an Authorization Policy to any user that you create for Flow Virtual Networking configurations and operations.” The same holds for FNS: “Even though the roles have pre configured permissions, they are not effective. You must define the scope for the entities at the time of creating authorization policy.”

Sources
Flow Virtual Networking Guide 6.0, Flow Virtual Networking Configurations: Control User Access in Flow Virtual Networking (RBAC), Roles and Permissions, Updated Authorization Policy Scope · Nutanix Security Guide 7.3, Security Management Using Prism Central: Built-in Roles List · Flow Network Security Guide 5.2.0, Role-Based Access Control: Flow Network Security Roles and Permissions

Knowledge

FNS RBAC roles and their pre configured permissions

Entity and operation	Flow Admin	Flow Policy Author	Flow Viewer
Create / Delete / Update Category	Yes	No	No
Create / Delete / Update Category Mapping	Yes	Yes	No
Create / Delete / Update Address Group	Yes	Yes	No
Create / Delete / Update Service Group	Yes	Yes	No
Create / Delete / Update Flow Policy	Yes	Yes	No
Export / Import Flow Policy	Yes	Yes	No
Create / Delete / Update Directory Server Config	Yes	Yes	No
Update Identity Categorization Config	Yes	Yes	No
Create / Delete / Update Network Entity Group	Yes	No	No
View Network Entity Group	Yes	No	Yes
Create / Delete / Update Network Function	Yes	No	No
Sync Entity Sync Policy	Yes	No	Yes
View AHV VM, VM NIC, Alert, Cluster, VPC, Flow Policy	Yes	Yes	Yes

The Built-in Roles List describes them as: Flow Admin, full access including categories provisioning; Flow Policy Author, full access except categories provisioning; Flow Viewer, view access.

Three lines to memorize

Category create, delete, update: Flow Admin only.
Network Entity Group and Network Function: Flow Admin only, and Policy Author cannot even view a Network Entity Group.
Sync Entity Sync Policy: Admin and Viewer, not Policy Author.

Sources
Flow Network Security Guide 5.2.0, Role-Based Access Control: Role-Based Access Control · Flow Network Security Guide 5.2.0, Role-Based Access Control: Flow Network Security Roles and Permissions · Nutanix Security Guide 7.3, Security Management Using Prism Central: Built-in Roles List

Knowledge

Custom roles, authorization policies, and limiting an admin to specific VPCs

Custom role: Admin Center > IAM > Roles > Create Role > New Role (unique name, built-in names not allowed; filter by Entity Type or Operation; add operations and their recommended related operations, which Nutanix recommends selecting in full) or From Existing Role (note: the new role does not include system operations from the existing role, and some operations are pre selected). Save, or Save & Create Authorization Policy. Duplicate, Update, and Delete are under Actions. Built-in roles cannot be updated or deleted, only duplicated, viewed, and given an authorization policy.

Authorization policy for FNS: log in as administrator or super admin, Admin Center > IAM > Roles > select a role > Actions > Add Authorization Policy > Choose Role > Define Scope (Full access or Configure access) > Assign Users. FNS roles do not support cluster and category based scoping for All Entities. Granular RBAC works on Address Group and Service Group by Individual Entity or by Owner for self owned.

Limiting to specific VPCs: edit the authorization policy, and on Define Scope set Entity Type to Subnet or VPC, set Filter to Advanced to add Subnet Type or VPC Type with the AND operator, then tick at least one search value.

Old Entity Type	New Entity Type	New Filter	Search value
Overlay Subnet	Subnet	Subnet Type	Overlay Subnet
Overlay External Subnet	Subnet	Subnet Type	Overlay External Subnet
VLAN Subnet	Subnet	Subnet Type	VLAN Subnet
VLAN External Subnet	Subnet	Subnet Type	VLAN External Subnet
VPCs	VPC	VPC Type	Regular VPC
Transit VPC	VPC	VPC Type	Transit VPC

Upgrade action item This mapping changed at AOS 7.0 and pc.2024.3. When you upgrade Prism Central from a version earlier than pc.2024.3, update the existing authorization policies that authorize Flow Virtual Networking users. Separately, before upgrading to pc.2023.4 or later, rename or delete custom roles whose names collide with default roles.

Documented RBAC limitations

No bulk operations on policies for a custom role.
A user with only import permission can import address groups, service groups, and flow policies without access to them.
No selective policy import or export. It is all policies or none.
Importing revokes RBAC permissions on the newly imported policies, since existing policies are overridden. Users with Full Access or All Entities are unaffected.
A user can see policies in the list even without VPC access.
An AD server config entity cannot be added to a role scoped to self owned entities only.

Sources
Nutanix Security Guide 7.3, Security Management Using Prism Central: Creating, Duplicating and Updating a Custom Role · Flow Network Security Guide 5.2.0, Role-Based Access Control: Role-Based Access Control and Creating an Authorization Policy for FNS Next-Gen · Flow Virtual Networking Guide 6.0, Flow Virtual Networking Configurations: Updated Authorization Policy Scope · Flow Virtual Networking Guide 6.0, Flow Virtual Networking Configurations: Troubleshooting Tips

Memorize: section 5

FNS 5.2.0: AOS 7.3, AHV 10.3, PC pc.7.3, Network Controller 5.0.0. 60-day trial without a license.
FNS memory: PC VM +2 GB, AHV host 3 GB userspace + 1 GB kernel. NC memory: Small +3 GB/+2 vCPU, Large +4 GB/+3 vCPU, host 2 GB. PE CVM 40 GB minimum at scale (alert A200613, severity INFO, NCC 4.6.3 and later, KB13595).
Prism Element web console allocates CVM memory up to 64 GB. Beyond that, contact Nutanix support. Path: Settings > General > Configure CVM. The value is a floor, CVMs already above it are left alone. Rolling restart, one CVM at a time, no production impact. ESXi clusters need vCenter credentials. Decreasing below the recommended minimum is not supported.
Raise PE CVM memory to 40 GB before migrating policies to FNS Next-Gen on an undersized cluster. Run NCC before any upgrade procedure, on both Prism Element and Prism Central.
TCP 9446 AHV to PC for connection tracking. Port 9440 both ways PC to registered clusters.
FNS PC version ≥ FNS PE version. 5.x single stack Next-Gen, 4.x dual stack.
Upgrade order: AHV, then PC and Network Controller, then FNS.
PC in a Nutanix environment upgrades only via LCM. Dark site needs four bundles plus Service Manager. MSP enablement up to 30 minutes, failure reported after ~2 h 5 min.
vs0 MTU 1500 to 9000, recommended 9000, physical switch around 9216. AHV maximum 9000 or less.
East/West on br0 (Geneve), segregated to br1 on vs1. North/South VLAN comes from the external subnet.
set_vpc_east_west_traffic_config blocks everything to the secondary host IP except GENEVE and ICMP unless permit_all_traffic=true.
Virtual switch subnet prefix /30 or less. VS migration timer is 20 seconds, non modifiable.
VPC Admin 83/21, Network Infra Admin 60/17, Network Shared Resources Viewer 1/1.
Category create is Flow Admin only. Entity groups and network functions are Flow Admin only. Entity Sync is Admin and Viewer.
pc.2024.3 changed VPC and Subnet entity types and filters. Update authorization policies after upgrading from earlier.
Cluster expansion with FVN: brAtlas is absent on the new node, so migrations to it fail. NIC failover target under two seconds. LACP must read Negotiated.

Ports and protocols

Source: Port_Protocols_Details_List.csv, the Nutanix Ports and Protocols reference: 1,838 rows across 127 product sections. This closes reference #41, cited by objective 3.1, which has no sourceable content in any other Nutanix document.

Three rules before you use these tables The CSV references AOS 7.5 and pc.2024.3 and is not version stamped to FVN 6.0.

Use its Flow Virtual Networking section. It matches the Network Controller / ANC architecture the FVN 6.0 guide describes.
Ignore its “Flow Controller” section for the exam. That describes a newer SMSP model with load balancer frontend IPs, worker VMs, an API server VIP, NATS on 4222 and NodeProxy on 9361/9362. The terms “Flow Controller” and “SMSP” appear in zero FVN 6.0 topics and zero FVN 7.6.0 topics.
Use Flow Network Security Next-Gen, not the plain “Flow Network Security” section, which is legacy. Next-Gen adds 6652, 6653 and 53 for the ANC control channel.

No FVN guide topic states the ICMP mechanism. It comes only from the ports reference.

Flow Virtual Networking

Port	Proto	Source	Bidir	Destination	Service
6081	UDP	AHV Host 1 AZ1	Yes	AHV Host 2 AZ1	Geneve, VPC east west
4789	UDP	Network Gateway AZ1	Yes	Network Gateway AZ2	VxLAN, VTEP subnet extension
6652	TCP/UDP	AHV Host AZ1	Yes	ANC PC-AZ1	OpenFlow, AHV to controller
6653	TCP/UDP	ANC PC-AZ1	Yes	AHV Host AZ1	OpenFlow, controller to AHV
500	UDP	Network Gateway AZ1	Yes	Network Gateway AZ2	IKEv2
4500	UDP	Network Gateway AZ1	Yes	Network Gateway AZ2	IKEv2 over NAT
179	TCP	Network Gateway AZ1	Yes	Router AZ1	BGP sessions
9440	TCP/UDP	Prism Central AZ1	Yes	Prism Element Host AZ1	Prism
8888	TCP/UDP	Prism Central AZ1	No	Network Gateway AZ1	REST, config and maintenance
53	UDP	AHV Host AZ1	Yes	MSP DNS Service Container AZ1	DNS for AHV calls to the NC
4812	TCP	AHV Host AZ1	No	ANC PC-AZ1	IPFIX, N-S, routing policy, LB stats
80	TCP	Prism Central AZ1	No	download.nutanix.com	VTEP network gateway VM image
22	TCP	Prism Central	No	Network gateway VM	SSH, troubleshooting only
ICMP 8	ICMP	Prism Central AZ1	No	Network Gateway AZ1	Echo, reachability probe
ICMP 0	ICMP	Network Gateway AZ1	No	Prism Central AZ1	Echo Reply. Absent means Down
443	TCP	Prism Central VM	No	*.quay.io	Network Controller docker images
443	TCP	Prism Central VM	No	docker.io, .docker.com, .cloudfront.net, cloudflare, AWS ECR and S3	MSP Controller docker images
443	TCP	Prism Central VM	No	*.nutanix.github.io	CMSP Service Manager, helm charts

Flow Network Security Next-Gen

Port	Proto	Source	Bidir	Destination	Service and purpose
9446	TCP	AHV	No	Prism Central	Kafka. Flow visualization and traffic events. The AHV service is `conntrack_stats_collector`
6652	TCP	AHV	No	Prism Central	Hermes. AHV to the ANC
6653	TCP	Prism Central	No	AHV	Hermes. ANC to AHV
53	UDP	AHV	No	Prism Central	AHV resolves the ANC URL via DNS
135, 49152-65535	TCP	Prism Central	No	Active Directory	WMI log scraping for ID based security and VDI policies
389, 3268	TCP	Prism Central	No	Active Directory	LDAP for ID based security and VDI policies. 3268 is Global Catalog
9300, 9301	TCP	Prism Central	Yes	CVM	Mercury, Fanout gRPC, PC to PE

What this fixes in objective 4.3 The FNS 5.2 guide says “you must allow WMI access from Prism Central to all the Active Directory Domain Controllers in your network firewall and Active Directory firewall” and never gives the ports. Now you have them. The ephemeral range 49152 to 65535 on the WMI path is exactly what a firewall team pushes back on, and is the most likely concrete root cause behind alert 803003, “not reachable and accepting LDAP or WMI connections”.

The legacy “Flow Network Security” section of the CSV has only 4 rows: 9446, the two Active Directory rows, and 9300/9301. It lacks 6652, 6653 and 53, which makes sense because legacy FNS does not require the Network Controller. That difference is a clean way to remember what Next-Gen added.

AHV host, Flow relevant rows

Port	Proto	Path	Purpose
6652	TCP	AHV host to Prism Central	Query flows to program on host
6653	TCP	Prism Central to AHV host	Query FNS policy metadata
6081	UDP	AHV host to AHV host	OVN Controller, VPC east west encapsulated traffic
9446	TCP	AHV host to Prism Central	Stats collector used by `conntrack_stats_collector`
Configurable	TCP/UDP	Prism Central to remote collectors	IPFIX Exporter in Prism Central
Configurable	TCP/UDP	AHV host to remote syslog	Cluster logs to a remote syslog server
7030	TCP	CVM, PC, test utility to AHV host	AHV Gateway, the hypervisor API
16514	TCP	AHV host to AHV host	Libvirt, TLS live migration control stream
49152-49215	TCP	AHV host to AHV host	TCP migration stream
123	UDP	AHV host to NTP	Cluster time sync

IPFIX, Security Central and LCM

Port	Proto	Path	Purpose
4739	UDP	AHV to Security Central VM	IPFIX, the standard IANA port, when network log collection is enabled
9440	TCP	Security Central VM to Prism Central VM	Prism
22	TCP	Security Central VM to CVM and PC VM	SSH for NCC audits. Can be blocked, with consequences
443	TCP	Security Central VM outbound	.nutanix.com and .amazonaws.com. Strict firewalls: searchlight.beam.nutanix.com, flow.nutanix.com, http://www.nutanix.com
2106	TCP	Prism Central to Prism Element	PC LCM to PE LCM
80, 443	TCP	CVM and PC VM to download.nutanix.com and release-api.nutanix.com	1-click updates. LCM may be unreachable over these URLs if you use reverse DNS lookup
80, 443	TCP	Hypervisor host to 169.254.0.0/16	Redfish-based LCM operations

Memorize: ports

6081 UDP Geneve. 4789 UDP VxLAN. Those two carry the data plane.
6652 AHV to controller, 6653 controller to AHV. Direction matters.
500 IKEv2, 4500 IKEv2 once NAT is in the path.
179 BGP. 8888 PC to network gateway REST. 9440 PC to PE.
4812 IPFIX AHV to ANC. 4739 UDP IPFIX AHV to Security Central.
9446 one way AHV to PC, Kafka, flow visualization, service conntrack_stats_collector.
135 + 49152-65535 WMI and 389, 3268 LDAP, Prism Central to Active Directory, ID firewall.
9300, 9301 Mercury Fanout gRPC, bidirectional PC to CVM.
2106 PC LCM to PE LCM. 7030 AHV Gateway API. 16514 Libvirt live migration.
ICMP 8 out, 0 back. No reply means the gateway is marked Down.
Remote syslog and the PC to IPFIX collector ports are configurable. Nothing to memorize there.

Sources
Nutanix Ports and Protocols reference, sections Flow Virtual Networking, Flow Network Security Next-Gen, AHV, Security Central and LCM

Alert ID reference

Every Flow relevant alert used in this guide, in ID order. Most come from the Prism Central Alert Reference 7.3, Network section.

Six alerts that hide outside the Network section This guide originally used only the Network section of the Prism Central Alert Reference 7.3. Sweeping the other thirteen sections found six Flow relevant alerts hiding elsewhere: 150003 and 150010 under Cluster, 200337, 200343 and 103110 under Controller VM, and 806203 under Nutanix Files, of all places. All are at the tested 7.3.

Three near miss pairings the exam would enjoy: 150010 exporter cannot be enabled versus 150011 exporter host update failed versus 150012 OVN Connection Unhealthy. 200337 category count versus 200343 category association count. 806203 Network Controller unhealthy versus 802001 ANC not healthy.

Three more in the DR section touch categories and secure policies, worth recognizing rather than memorizing: 110402 Protection Policy Max entities per Category Check Failed, 130393 Secure protection policy updated or deleted, 130404 Entity protected by secure protection policy is unprotected.

ID	Name	Impact in one line
103110	IPSet Firewall consistency check (new )	IPSet firewall not enabled on all CVMs, so some nodes are less secure than others. Easy to mistake for a Flow policy problem
130201	Failed to configure host for Atlas networking	VMs on Atlas networks cannot run on that host
130202	Failed to reserve host memory for Atlas networking	Random VMs may be powered off if hypervisor memory is exhausted
130388	VM vNIC learned IP limit reached	FNS policies involving that VM may not work as expected
130389	Advanced Networking Subnet not recovered from a PC recovery point	vNIC connectivity unavailable until the vNIC is reassigned or recreated
130403	Flow gateway is down	The Flow gateway VM or flow-gateway-agent service is down
150003	Flow visualization statistics collector service monitor (new )	Collector restarted 10 times in 15 minutes on a host. Flow visualization may not show real time data. KB 8911
150010	IPFIX exporter cannot be enabled on the cluster (new )	Exporter never comes up. Cause is a PE or AHV version floor, or an unhealthy PC to PE connection
150011	IPFIX exporter host update failed	The exporter on that host may not be working
150017	VM traffic impacted, link down on host NIC in NIC profile	Connectivity or throughput impacted for VMs using that NIC profile
200601	Flow Rule Failed	VMs will not be protected by that rule
200602	Flow Network Security Control Plane Failed	No new or updated policies can be made
200606	Flow Mode Change Failed	Flow in default mode, traffic hitting policies is not logged by AHV
200610	Atlas unreachable to apply Flow rule	VMs will not be protected by the rule
200611	Rule update failed in Atlas, invalid arguments	Policies not enforced for affected VMs
200612	Rule update failed in Atlas, parameter not found	VMs in the policy will not be protected
200613	Flow Network Security CVM Memory Recommendation	FNS needs a minimum of 40 GB on the PE CVMs to function at scale. Below that, limited rule reconciliation performance and VMs per policy density. KB13595. PE reference 7.6
200614	FNS version too low on registered PE cluster	That cluster may not support the policy features in use
200615	High number of Cadmus service flows	Flows past the limit are not shown in the UI
801001	Maximum VPN BGP route limit reached	Connectivity between AZs over the VPN may be impacted
801002	VPN IPSEC tunnel down	Connectivity between AZs impacted
801003	eBGP session between VPN endpoints down	Routes cannot be exchanged
801004	Invalid routes received by VPN connection	Those routes are rejected
801101	L2 subnet extension deletion failed on the remote site	Remote PC still shows the subnet extended
801102	ANC version does not support L2 subnet extension	ARP and unknown unicast from the peer AZ dropped
801103	VPN gateway version does not support L2 subnet extension	Same ARP impact
801104	VPN connection for the L2 extension not found	VMs across AZs cannot communicate
801105	Peer AZ not reachable	VMs on the extended subnet may not communicate
801106	Subnet involved in the L2 extension not found	No vNICs can use that network UUID
801107	CIDR of the subnets do not match	Some VMs cannot communicate on the extended subnet
801108	DHCP pools overlap or include VPN interface IPs	Some VMs cannot communicate
801109	Local VPN interface IP in use in the peer AZ	Some VMs cannot reach the peer AZ. KB-10395
801110	Remote VPN interface IP in use in this AZ	Some VMs cannot reach the peer AZ
801111	Common IP addresses across the extended subnets	Some VMs cannot reach the peer AZ
801112	Layer-2 subnet extension is down	Connectivity to the remote endpoint or VxLAN device availability
802001	Advanced Networking Controller is not healthy	Ability to make network related configurations may be impacted
802002	Cannot resolve an ANC service DNS name	Same. PC nameserver configuration is incorrect
802003	Cannot apply a VPC reroute routing policy	Traffic does not hit the inactive routing policy
802005	Network gateway is down	Gateway marked unreachable; REST server down or PC cannot ping it
802006	Internal route installation for VPC ERPs failed	Remove and reconfigure the VPC with ERPs
802007	VPC ERPs are not subnets of the transit VPC’s ERPs	Those ERPs may have no north south connectivity outside the transit VPC
802008	VPC ERPs overlap subnet CIDRs in the transit VPC	Local routes win over ERP routes, disrupting north south
802009	ERPs removed from the transit VPC are supernets of attached VPC ERPs	Those ERPs stop being advertised
803003	ID Firewall lost connectivity to a domain controller	Flow VDI policies may not be enforced. KB-10219
803005	ID Firewall did not recover state after reconnecting	Applied policies may not be enforced. Users log out and back in. KB-10220
803007	ID Firewall service account is invalid	Flow VDI policies may not be enforced
803008	Flow security enforcement failure for a Kubernetes cluster	Cluster security enforcement may not be updated
806101	Maximum route limit reached for a BGP session	Only the first max_routes are installed
806102	Approaching maximum route limit for a BGP session	Same
806103	Mismatch between BGP sessions and VPC active gateways	Session count does not line up with active gateways
806104	Serviced VPC missing externally routable address spaces	Nothing to advertise
806105	Serviced VPC missing external subnet without NAT	Received routes are ignored
806106	BGP session is down	Verify gateway and session configuration
806107	Configured externally routable addresses not advertised	Session ERPs must be a subset of the VPC’s ERPs
806201	Load balancer session targets are unhealthy	One documented cause is a security policy blocking health checks
806202	Network function virtual NIC pairs are unhealthy	Service VMs down, datapath engine down, or NICs deleted
806203	Network Controller is unhealthy (new )	One or more Network Controller services are unhealthy or in crashloop. Go to Prism Central Settings → Network Controller. Distinct from 802001, ANC not healthy

Prism Element alerts,

From Prism Element Alerts Reference 7.6. These do not appear in the Prism Central Network alert reference. Version caveat: v7.6 against a tested 7.3.

ID	Name	Impact in one line
3064	CVM Connectivity Failure	General reachability
3065	Host IP Not Reachable	General reachability
3067	NIC Link Down	General reachability
3070	AHV Secondary IP Ping Check from Node	Advanced networking may encounter issues if enabled and configured to use the corresponding virtual switch. The check behind east west segregation onto a non default virtual switch
6202	CVM Host Subnet Mismatch	General reachability
6404	Transmit packet drop check	Throughput rather than reachability
6405	NIC RX packet drop rate high	Throughput rather than reachability
103094	CVM NIC Link Down	General reachability
103101	Inconsistent Bridge/vSwitch configuration	Config modified during cluster lifetime without restarting genesis. Potentially breaks configured services. KB 8018
103103	IPv6 Config check	Manual IPv6 configuration on CVM interfaces. FNS blocks IPv6 by default
103104	Corrupted packets are reaching the CVM	Throughput
103105	Network interface configuration file for eth0 is malformed	Host networking
103106	Bond uplink VLAN config check	Connectivity lost if the active uplink changes. Requires link layer unicast with an IPv4 payload, including 169.254.0.0/24
103107	Bond uplink connectivity check	At least two uplinks in the bond must be connected or redundancy is lost
150018	Address Translation Services not enabled on PCIe passthrough NIC	ATS not enabled in the NIC profile. A reboot is required

Flow alerts present in both references, so the ID is safe either way: 130201, 130202, 130388, 150011, 200601, 200602, 200606, 801106, 803003, 803005.

Configuration maximums

Flow Network Security 5.2.0

Version exact with the tested FNS release. On premises figures unless noted.

Global, VLAN and VPC on premises

Item	VLAN on prem	VPC on prem	NC2 on AWS / Azure
Address Groups per PC	5000	5000	n/a
Addresses per Address Group	250	250	20
Categories per Secured Entity	8	8	2
Entity Groups per PC	1000	1000	n/a
Rules per PC	24000	24000	3030
Secured Entities per PC, all types	4000	4000	709
Service Groups	3000	3000	5
Services per Service Group	2500	2500	n/a
VMs per category	2000	2000	1000
VMs per PC, large PC	10000	10000	3000
VPCs per PC	n/a	500	25
CIDR and Subnets	n/a	4000 across 500 VPCs	500

Services per Service Group is 2500, expressed as 10 services per row with 250 rows maximum.

By policy type, on premises

Policy type	Scope	Policies per PC	Secured Entities	VMs per category	VMs per PC	Rules
Application	VLAN	1000	2000	2000	10000	24000
Application	VPC	1000	2000	2000	10000	24000
Isolation	VLAN	100	2000	2000	10000	n/a
Isolation	VPC	100	2000	2000	10000	n/a
Quarantine	VLAN	2	1	25	50	2
Quarantine	VPC	1000	1000	15	100	1000

Address group maximum: it is 5000, and the guide says otherwise Two Nutanix documents disagreed. The FNS 5.2 guide’s guardrails table lists 3000; Configuration Maximums 5.2.0.csv lists 5000. The live Nutanix Configuration Maximums page gives 5000 for FNS 5.2.0, so the CSV is right and the guardrails table is wrong.

Use 5000. The exam tests FNS 5.2. Note that the error is isolated to that one row: everything else in the guardrails table agrees with the CSV (24000 rules, 4000 secured entities, 3000 service groups), so the table is not generally unreliable.

The 7.6 value is 40000, an eightfold jump. Not the exam answer, but a number to have for client work on 7.6, and a reminder to re check maximums per release rather than carrying them forward.

Sourcing note: both figures come from the live Nutanix Configuration Maximums page, not from any product guide. The guides alone get you to the conflict, not to the answer.

Sources
Nutanix Configuration Maximums, Flow Network Security 5.2.0 · Nutanix Configuration Maximums, verified against the live portal page · Flow Network Security Guide 5.2.0, Security Policy Model: FNS Next-Gen Guardrails (address group row is incorrect)

Flow Virtual Networking 7.6.0

From FVN Configuration Maximums 7.6.0.csv, 237 rows across six Prism Central sizings.

Version caveat, and it is the important part This CSV is 7.6.0. The exam tests FVN 6.0. Nutanix maximums move hard between releases: the FNS address group limit went from 5,000 in 5.2.0 to 40,000 in 7.6, an eightfold jump. Do not assume any of these held at 6.0 unless something else corroborates it. The first table below is corroborated. The rest is orientation.

Corroborated by an FVN 6.0 or PC 7.3 source, so safe to memorize

Maximum	Value	Corroborating statement
Routes learned per BGP session	250	“The BGP appliance can learn and install up to 250 routes”
Sources per traffic mirroring session	4	PC Guide 7.3 traffic mirroring scale table
Destinations per traffic mirroring session	2	Same
Traffic mirroring sessions per host	2	Same, “2 active per host”
NAT external subnets per VPC	1	“A maximum of one NAT and one No-NAT external network for a specific VPC”
NAT gateway hosts per external VLAN subnet per VPC	4	Scale out to up to four hosts
No-NAT gateway hosts per external VLAN subnet per VPC	4	Same

That agreement across three independent documents is itself the finding: these numbers did not change between 6.0 and 7.6.

Values that scale with Prism Central size

Maximum	Small	Large	X-Large
Number of VPCs	50	250	500
Subnets across all VPCs (includes Overlay External)	500	2,500	5,000
Ports (virtual NICs) across all VPCs	5,000	25,000	50,000
Floating IPs per PC	250	1,250	2,000
ERPs per on premises PC	500	2,500	5,000
ERPs per NC2 PC	500	1,000	1,000
Routing policies per PC	600	3,000	10,000
Routing policies per VPC	600	1,000	1,000
VPC gateway hosts per PC	200	1,000	2,000
VPCs per transit VPC	49	100	100
VTEP gateways	5	5	10
Subnet extensions per VTEP gateway	5	5	10

This reconciles a number already in the guide The FNS Configuration Maximums 5.2.0 CSV gives “VPCs per PC: 500”, carried in Section 2. That is the X-Large figure. On a Small PC it is 50. Both are right; they are different sizings.

Two rows where scale out is LOWER than single instance

Maximum	Large single	Large scale out	X-Large single	X-Large scale out
Network load balancer sessions per PC	250	50	500	50
VTEP gateway HA pairs	10	5	10	5

Scale out caps load balancer sessions at 50 regardless of PC size, down from 250 or 500 on a single instance. Counterintuitive enough that if it appears on the exam it will be as a trap. The documentation gives no explanation, and none is invented here.

Constant across every PC size

Maximum	Value
BGP gateways per PC	10
BGP sessions per network gateway	10
VPN gateways per PC	5
Subnet extensions per VPN gateway	5
ERPs per VPC	100
IPFIX exporter destinations per AHV host	5
Virtual switches per cluster	20
NIC profiles per PC (SR-IOV or Network Offload)	500
Virtual functions per supported NIC	8
Target VM vNICs per load balancer session	32
VPC connections per external subnet	100
VPCs per Kubernetes cluster	10
NAT gateway hosts per external Overlay subnet per VPC	1
No-NAT gateway hosts per external Overlay subnet per VPC	1

Two of these connect to material elsewhere in this guide. IPFIX exporter destinations per AHV host = 5 belongs with objective 3.2, and virtual switches per cluster = 20 belongs with objective 5.4. Neither number appears in any FVN 6.0 document.

The overlay versus VLAN gateway host split is a real design point: an external VLAN subnet scales out to 4 gateway hosts, but an external Overlay subnet is fixed at 1. Overlay external subnets do not get NAT gateway scale out.

One row in the Configuration Maximums file is wrong The CSV row “Number of NO NAT External VLAN Subnets per VPC” = 4. Ignore it.

The answer is one NAT and one No-NAT external VLAN per VPC, confirmed as fact and matching what FVN 6.0 states in three separate places: “You can add a maximum of two external subnets, one external subnet with NAT and one external subnet without NAT to a VPC. Both external subnets cannot be of the same type.” So the maximum is two external subnets per VPC, one of each type.

A meta point worth carrying, because this is the second time. On the FNS address group maximum the guide was wrong (3,000) and the Configuration Maximums CSV was right (5,000). Here it is the reverse: the CSV is wrong (4) and the guide is right (1). Neither source type is reliably authoritative on maximums. When a number matters for a client design, check the live Nutanix Configuration Maximums page rather than trusting whichever document is nearest.

Sources
Nutanix Configuration Maximums, Flow Virtual Networking 7.6.0 · Flow Virtual Networking Guide 6.0, Flow Virtual Networking Overview: Essential Concepts, and Virtual Private Cloud Management: Creating a Virtual Private Cloud

What this guide does not cover, and what to check yourself

Three things the Nutanix documentation does not answer, five places where two Nutanix statements look contradictory and are not, and the sources that sit at a version other than the one the exam tests.

Three genuine gaps, and no document closes them

Gap	Why no document fixes it	What to do instead
NCC check names, for example the check that reports conntrack table status	Nutanix does not publish an NCC check catalogue. The NCC guide says so directly: checks are documented as continuously updated support portal KB articles	Find one through the portal knowledge base, or in the UI at Health → Actions → Manage Checks, where each check links to its own KB. On a live cluster, `ncc health_checks` enumerates the categories
IPFIX record structure and exported fields	Transport is documented. The payload is not. No guide states what an IPFIX record from an AHV host contains	Capture one. The exporter ports and the failure alerts are covered above, which is enough to confirm the exporter is working
Flow Virtual Networking configuration maximums at 6.0	The published maximums file is 7.6.0. Seven values are independently corroborated at 6.0 or Prism Central 7.3; the rest are 7.6 only	Check the live Nutanix Configuration Maximums page for any number that matters in a design

Five apparent contradictions that are not contradictions

Each of these looks, on a first read, like two Nutanix documents disagreeing. In every case both statements are true and they answer different questions. This is the single most useful pattern in this guide. If something in the Flow documentation reads as a self contradiction, work out what question each sentence is actually answering before concluding that one of them is wrong.

What looks like a conflict	What is actually going on
BGP Session Status shows Established or Active in one place and Up or Down in another	Two different fields. Overall session status is Up or Down on the details Properties widget. eBGP protocol state is Established or Active, shown as eBGP Status on the details widget and as Session Status on the list page. Established corresponds to Up. Only the filter pane mixes the two vocabularies
Monitor mode is called the default, but the Review tab offers three buttons	Two layers. There are two enforcement modes, monitor and enforce, and monitor is the documented default. Save is a draft state that sits above them, not a third enforcement mode
NCC “cannot” run from the Prism Central web console, yet the same topic gives a Prism Central web console procedure	The “cannot” sentence belongs to the pre upgrade instruction above it, which tells you to use the command line before any upgrade. It reads as text left in place when Run Cluster Checks was added. NCC runs from the Prism Element GUI, the Prism Central GUI, or any command line. The version floor is what matters: Run Cluster Checks needs Prism Central pc.7.5
Load balancer health checks are attributed to the Network Controller in one topic and to the AHV host in another	Two layers again. The Network Controller is responsible for running the health checks. The AHV host transmits the packets, because the load balancer is distributed and implemented at host level. The entity that puts the TCP SYN on the wire is the local AHV host where the target VM runs
Categories can be assigned to six entity types in one guide and to VMs only in another	Different scopes. Prism Central assigns categories to many entity types for grouping and organization. Flow Network Security acts on them at the VM level. Tagging a subnet or a volume group does not put it behind a Flow policy

One documented error worth knowing about

The Flow Network Security 5.2 guardrails table is wrong on address groups The FNS 5.2 guide prints 3,000 as the maximum number of address groups. The correct figure for 5.2.0 is 5,000, per the Nutanix Configuration Maximums page. The 7.6 value is 40,000.

The wider lesson is the useful part. Neither product guides nor Configuration Maximums files are reliably authoritative on limits. On address groups the guide is wrong and the maximums file is right. On No-NAT external VLAN subnets per VPC the maximums file is wrong (it says 4) and the guide is right (the answer is one NAT and one No-NAT per VPC). For any number that drives a design decision, check the live Configuration Maximums page.

Sources that sit at a different version from the tested stack

Where no version matched document exists, this guide uses the nearest available source and says so inline. These are the ones worth knowing about.

Source	Version	What to watch
Prism Element Alerts Reference	7.6	Eleven alert IDs used here are corroborated against the Prism Central Alert Reference 7.3. Fourteen are platform and hardware alerts a Prism Central reference would not carry, so they are unverified at 7.3 rather than suspect
Prism Central Admin Center Guide	7.6	The only source for category creation. Project scoped categories, the Default Project, legacy category migration and their read only rules are new in pc.7.6 and do not apply at 7.3
Nutanix Cluster Check Guide	6.0	Requires AOS 7.6 and Prism Central 7.6. Its status types, module and plugin model, command syntax, logbay tags and scheduling are long stable. Do not quote its compatibility table
Flow Network Security release notes	5.2.1	Removing the intra tier rule and cross policy visualization are 5.2.1 features that do not exist in 5.2.0
AHV Administration Guide	6.10	Policy based routing concepts and virtual switch limitations. Long stable, low risk
Prism Central Admin Center Guide	2024.2	Syslog modules. Confirmed unchanged at Prism Central 7.3
Nutanix Cloud Clusters on AWS Deployment Guide	NC2	Used for two routing rules where no on premises topic exists. The routing behaviour is the same; the auto created transit VPC and the `overlay-external-subnet-nat` subnet around it do not exist on premises
TN-2094 tech note	none stated	Mixes legacy and Next-Gen, sometimes in adjacent paragraphs. It states the legacy 1:1 AppType mapping rule two paragraphs before describing the Next-Gen model where one policy can call multiple secured entities. Only the Next-Gen half applies

Where the exam blueprint points at the wrong document

Five blueprint references do not match the objective they are attached to. This is not a gap in the product documentation; it explains why some objectives are thinner than others.

Reference	Attached to	What it actually covers
Lifecycle Modes for Dark Sites	2.3, Manage Policy Lifecycle and Modes	LCM update sources. No relationship to security policy lifecycle modes. The word “lifecycle” is doing double duty
Failure Handling in a Nutanix Cluster	4.2, Analyze Logs	Platform hardware fault tolerance: drive, node, block, network link and rack failures, RF and FT levels, Witness VM. Addresses none of the objective’s bullets
Configuring a Role Mapping	4.3 and 5.5	The Prism Element directory role mapping workflow. Flow RBAC is a Prism Central IAM workflow with entirely different roles. Both are covered above, because confusing them is a real failure mode
Security Policy Management	4.1	A short pointer topic that defines security policies and redirects elsewhere
Security Management using Prism Central	4.3	A broad IAM chapter opener. Useful background, thin on identity based policy troubleshooting

What the LCM dark site topic actually says

Since the blueprint cites it, here it is. LCM Settings → Source is either Dark Site (Direct Upload) or Dark Site (Local Web Server). For the web server method: enter the URL to the extracted tar directory ending in /release, tick Enable HTTPs, tick Auto Inventory and Auto Update with a time (default 3:00 AM if unspecified), and tick Enable Auto Update for NCC. The connected site equivalent sets Source to Nutanix Portal at download.nutanix.com/lcm.

Sources
Life Cycle Manager Guide 3.0, LCM Settings and Dark Site topics

Nutanix NCP-NS 7.5 Study Guide, Part 3: Deploy, Upgrade, and Quick Reference

Section 5: Deploy and Upgrade a Flow Environment

Objective 5.1: Prepare a Cluster for Flow Network Security

Enable FNS · Confirm supported versions · Identify required resources

Two enablement side effects and two connectivity requirements

Create categories and associate to VMs

Association is sourced. Creation is not.

Creating a category

Project scoped categories: a 7.6 change, NOT the tested behaviour

Prism Element CVM memory for Flow Network Security

The complete Flow memory picture

Checking and increasing CVM memory

Objective 5.2: Prepare a Cluster for Flow Virtual Networking

Confirm the Network Controller is enabled and the right version · Cluster compatibility

Four ways incompatibility surfaces

Other prerequisites

Layer 2 subnet extension: prerequisites and best practices

Two prerequisites that are easy to miss

Retaining VM IP addresses across an extended subnet

Choosing the extension type

Layer 2 extension over VPN specifically

Objective 5.3: Determine Order of Upgrades and Upgrade Paths

Incompatible clusters, Network Controller updates, FNS updates

Prism Central upgrade in a Nutanix environment

Network gateway upgrades

General cluster expansion prerequisites,

Objective 5.4: Configure Virtual Switches and MTU

Segregate East West and North South traffic

Procedure

Virtual switch IP constraints, each with its own failure message

Virtual switch requirements and migration gotchas

VPN prerequisites, since VPN sits on this plumbing

Segregate UVM, management, and replication traffic

Five services can be isolated to their own virtual network

Disaster recovery prerequisites, which are the replication answer

Configurations that do not support network segmentation at all

Troubleshooting hook

Multicluster virtual switches

What can attach, and a UI gotcha

Limitations, and two are design constraints rather than footnotes

Creating one

Mapping the traffic, which is API only

Viewing, updating, deleting

Prism Element health checks that back this objective

Objective 5.5: Configure and Manage User Roles

Which roles can and cannot create a VPC

Prism Admin and Super Admin are two different roles

FNS RBAC roles and their pre configured permissions

Three lines to memorize

Custom roles, authorization policies, and limiting an admin to specific VPCs

Documented RBAC limitations

Memorize: section 5

Ports and protocols

Flow Virtual Networking

Flow Network Security Next-Gen

AHV host, Flow relevant rows

IPFIX, Security Central and LCM

Memorize: ports

Alert ID reference

Prism Element alerts,

Configuration maximums

Flow Network Security 5.2.0

Global, VLAN and VPC on premises

By policy type, on premises

Flow Virtual Networking 7.6.0

Corroborated by an FVN 6.0 or PC 7.3 source, so safe to memorize

Values that scale with Prism Central size

Two rows where scale out is LOWER than single instance

Constant across every PC size

What this guide does not cover, and what to check yourself

Three genuine gaps, and no document closes them

Five apparent contradictions that are not contradictions

One documented error worth knowing about

Sources that sit at a different version from the tested stack

Where the exam blueprint points at the wrong document

What the LCM dark site topic actually says

Share this:

Like this:

Comments

Leave a ReplyCancel reply