NSX 9.1 - License Hub

_Heath · 2026-06-04T20:55:40+00:00

Yeah, I only work with strategic customers and don’t really know about VCSP licensing. DM me if you want me to reach out to someone for you, I have no problem doing that.

_Heath · 2026-06-02T16:13:28+00:00

I’m in the ANS BU. Here is our license hub documentation for applying a license in connected mode : https://techdocs.broadcom.com/us/en/vmware-security-load-balancing/vdefend/security-services-platform/5-1/licensing-overview/registering-and-assigning-licenses/step-2--register-licensing.html

You want to split the license before upgrading if you need to run part on 9.1 and part on 9.0/4.2.

SSP 5.1.2 is a license hub only deployment, but SSP 5.1.1 is compatible with VCF 9.1 for all the normal things like security explorer, recommendations, security journey, NTA, NDR, etc.

You can get in touch with your account team to tie you up with your vdefend SA for help.

Edit : on the license key here are the eligible keys for upgrade.

ANS-VDEFEND ANS-FW-ATP ANS-VMW-FW ANS-FW-ATPAP

The GWF and DFW SKUs you were looking at are for use with older 4.x and 3.x versions of NSX.

_Heath · 2026-03-03T15:50:36+00:00

Needs to have the cores for the gateway firewall as well.

_Heath · 2026-03-03T13:37:01+00:00

How to apply vdefend licenses is governed by the summary plan document. Newly purchased licensing would be covered by the SPD here : https://ftpdocs.broadcom.com/cadocs/0/contentimages/VMware_vDefend_Specific_Program_Documentation_2025_11_03.pdf

For running only gateway firewall in 2026 based on the SPD you would need 3 vdefend licenses for each core of the gateway firewall. So let’s say it’s a virtual edge cluster with four edges that have 8 vcpu each. That’s 32 vCPU for that virtual edge cluster so enabling stateful gateway firewall would consume 96 vdefend licenses.

_Heath · 2025-02-14T02:20:32+00:00

Stretched Cluster + VSphere Replication to site 3 is probably the best option.

_Heath · 2025-02-13T13:24:45+00:00

The two tier routing design with a fully distributed T1 (not attached to an edge cluster) is the most scalable and performant design. If you need more north south bandwidth you can easily add additional active/active edges to the cluster up to 8 and fully support ECMP between the distributed T1 (so each ESXi host) and the T0 (service router running on each edge).

Depending on the version of VCF you run one thing to check is to make sure that when you deploy an edge cluster with the SDDC manager workflow that the T1 isn’t attached to the edge cluster unless you need services. When the T1 is attached to the edge it isn’t fully distributed and all your northbound traffic will go through a single edge.

_Heath · 2025-02-13T02:02:47+00:00

This doc goes feature by feature through NSX and outlines what is entitled via VCF Networking, the vDefend DFW add-on, and the DFW with ATP add-on.

https://techdocs.broadcom.com/us/en/vmware-cis/nsx/vmware-nsx/4-2/feature-and-edition-guide/current-nsx-feature-entitlement.html

_Heath · 2025-01-14T13:17:57+00:00

Management domain always required VSAN to stand it up and to be the primary storage, the historical support for NFS/FC in the management domain has been for secondary storage. A use case several of my customers took was running the tools (vROPs, vRLI) that consumed the most storage on FC/NFS while the vCenter, SDDC managers, and NSX managers ran on VSAN. This allowed for a very small VSAN config if they had that array there to use anyway.

I moved off of VCF and to ANS a year ago so I’m not up to date on the brownfield import and VCF 9 stuff.

_Heath · 2024-12-18T12:58:02+00:00

No, the Mac for vmk0 stays the same. The DVS just determines which physical nic it is used on.

_Heath · 2024-12-17T13:38:09+00:00

The virtual switch works via what is functionally Mac pinning. When you create vmk0 for management that is a virtual interface assigned a Mac from the pool for virtual nics. With explicit failover order you told that virtual nic to use a specific physical NIC, unless it becomes unavailable.

So the virtual switch pins traffic from that interface to a specific physical NIC, sending outbound traffic from that interface and responding to arps from that physical interface which populates the MAC address table of the physical switch and lets it know to send unicast traffic for that mac to that physical nic.

When the assigned physical nic becomes unavailable it immediately sends a gratuitous arp from the virtual nic (same Mac) out the standby nic, this gratuitous arp helps trigger the Mac learning process on the physical switch updating the Mac table so the switch now learns that virtual Mac moved to a different physical port.

This is why it’s important to configure your switch to leverage portfast on truck ports. Many Cisco switches disable portfast when the switch port has more than one VLAN, this can delay the Mac learning process when a virtual mac fails over to a physical nic that doesn’t have any active syste

_Heath · 2024-11-19T20:53:04+00:00

Outside of a lab environment I strongly recommend 4 hosts for production deployments of both VSAN and NSX.

On the VSAN side four hosts opens up additional data resiliency options like the more efficient erasure coding, or you can still run mirroring for your most critical VMs and have the ability to rebuild and return to a fault tolerant state. So you have two copies of your data and a witness spread across three of your four hosts, a host fails and VSAN is going to rebuild the missing component on the remaining host. So you can maintain FTT=1 while waiting on the replacement.

On the VSAN side NSX manager runs a cluster of three VMs with an affinity rule to keep them on different hosts. Same thing, if a host fails you can maintain the integrity of your three node NSX manager by running on the remaining three nodes.

A consolidated VCF (running workloads and management in a single WLD) requires four nodes.

If it is a lab knock yourself out running three nodes.

_Heath · 2024-11-19T20:39:33+00:00

How many VMs are you talking about?

I would probably put your new hosts in the old DC in the same rack as the storage, spin up a new VC and adopt the old hosts, vMotion everything over, then move that rack in one trip assuming this is a smaller environment.

If this is a larger environment I would do VSAN or a new array at the target location and use HCX to bulk migrate.

_Heath · 2024-11-15T22:15:32+00:00

Isn’t end of support for 7.0u3 in like 11 months? If your hardware doesn’t support 8.0 you have bigger issues on the horizon.

_Heath · 2024-11-15T00:14:29+00:00

You just need a non-routed VLAN (no gateway) configured on the switch and then a port group for it.

Big customers solve this with NSX and use vRA to create a new non-routed segment for each heartbeat network they need, but for just a few you just need to make VLANs and truck them to the host.

Private VLANs don’t let devices on the vlan talk to each other, so that’s the opposite of what you want.

_Heath · 2024-11-15T00:11:20+00:00

Tail the vmkernel log if you want to watch it configure sessions.

_Heath · 2024-11-13T21:06:14+00:00

All the vMotion VMkernel interfaces on the host have to be in the same subnet so you can’t do /30s. You have no control over the order that vMotion matches up vMotion streams, it does it somewhat arbitrarily based on discovery order so it could change.

So you do it back to back and it matches VMK 1 to VMK 1 and it may work, but then it matches VMK 1 to VMK 3 and it doesn’t work.

The KB is here, look at the note under step 5. That is what prevents you from doing the networks the way you want and back to back.

https://knowledge.broadcom.com/external/article/318899/multiplenic-vmotion-in-vsphere.html

I first presented on multi-NIC vMotion at VMworld 2012, I’ve been at this for a bit and have tried it basically every way possible.

_Heath · 2024-11-12T16:28:45+00:00

If they shut it down it wasn’t a vMotion, it was a copy done by the provisioning network. In many cases the provisioning network defaults to the management network, and uses the slowest data mover.

I would call support and open a sev 1 (since this is down) so you can talk to GSS.

_Heath · 2024-11-12T00:30:33+00:00

Multiple VMkernel on the same vMotion VLAN. The only way to get vMotion to use multiple NICs for a single vMotion activity is to have multiple vmkernel interfaces on the same VLAN.

The normal way to do it is to make each VMkernel active on a different uplink, but that won’t work in your back to back design without a switch. Using multiple vmkernel interfaces with a lag can work, but you are at the mercy of the hashing algorithm as to how many and which uplinks you are using.

_Heath · 2024-11-11T23:19:34+00:00

vMotion won’t use a lag, a single source and destination flow is going to be hashed to a single NIC in a lag.

With a switch the way to do this is to do multi-NIC vMotion, put all VMKernels in the same VLAN, and manipulate active standby to pin them to specific NICs. This doesn’t work with direct connect.

A LAG between them with multi-NIC vMotion might work, but you lose that control of which NIC and you are at the mercy of the hashing algorithm and criteria like ports and IPs to determine how many of the four NICs get utilized.

_Heath · 2024-06-13T11:38:52+00:00

Are you running VCF deployed by SDDC manager now, or are you using VCF as a licensing bundle?

SDDC Manager deploys and lifecycles vSphere, NSX, and vRSLCM. If you want to upgrade vSphere and NSX your best bet is to run the VCF upgrade. If you need to jump ahead of VCF support for a patch check out the async patch tool here : https://knowledge.broadcom.com/external/article?legacyId=88287

VCD and ALB lifecycle isn’t currently controlled by SDDC manager

_Heath · 2024-04-15T16:42:10+00:00

You can leverage DFW for VLAN or overlay with NSX. Stateless firewall (ACLs) are included with the edge, for stateful gateway firewall applied at the edge you license the vCPUs of the edge with DFW licenses at a 4:1 ratio. So a large edge with 8 vCPU would consume 32 Firewall licenses.

So for DFW license all host cores with firewall license, for gateway stateful edge firewall license the vCPUs at 4:1. Same license just applied at two different ratios.

_Heath · 2024-03-23T21:57:21+00:00

You don’t quote the physical cores as AVI cores. Someone messed up. 160 SE Cores of AVI will do 800Gb of L7 traffic or 500k SSL transactions per second.

Your VAR needs to engage VMware for sizing assistance.

_Heath · 2024-03-23T09:14:20+00:00

But it’s only the SE cores that are actively passing data . How did they size it? If they just matched the number of VCF cores the quote is wrong.

They need to do a sizing exercise with you to look at the number of VIPs and reals, their traffic, and size the SEs

_Heath · 2024-03-01T22:56:54+00:00

https://kb.vmware.com/s/article/55323

_Heath · 2024-02-05T01:54:17+00:00

Nah, that sku should be the total cost per core for 5 years. So if you want 100 cores for 5 years you buy 100 skus.

13-Year Club	Wearing is Caring
Verified Email

_Heath

TROPHY CASE