VMWARE NETWORKS → STACKIT · ARCHITECTURE
From vSwitches and VLANs to STACKIT network segments
On VMware, segmentation is a stack of virtual switches, port groups and VLAN IDs. On STACKIT it is networks, a project router and security groups on the network interface. StackToIT turns every port group into a network and leaves the topology decision open. This page sets out the options, with a ten-machine demo estate whose run shows where the draft stops.
Four ways to carry the segmentation
| Option | How it looks on STACKIT | What you trade |
|---|---|---|
| A · One network per port group | Each port group becomes a network with its own address range. Traffic between networks of one project passes the project router, and security groups at the network interface decide what is let in. | Closest to today's layout and the draft StackToIT writes. More prefixes to assign and more rules to write between tiers. |
| B · Fewer networks, security groups as the boundary | Several tiers share one network. Separation is expressed by security groups named after the function they protect. | Less address planning, but isolation depends entirely on rule quality. A layer-2 boundary no longer backs it up. |
| C · One project per zone, joined by a network area | Zones such as production and management live in separate projects. Projects in a STACKIT Network Area are connected implicitly, and traffic between them still has to be allowed by security groups. | Strong administrative separation. Existing network ranges of an area cannot be changed later, and the documentation says a network area currently works within a region. |
| D · Keep a firewall appliance | A multi-homed VM such as fw-dmz01 keeps a leg in each zone. A server can have up to 5 network interfaces. | Keeps your rule base and tooling. You run and patch the appliance, and five legs are the ceiling. |
Options combine, for example a firewall appliance in front of the DMZ with option A behind it. Statements about networks, routing, security groups and the network area follow the STACKIT Core Networking documentation listed under sources.
What the engine drafts: a network per port group
A ten-machine export written for this page and assessed by StackToIT on 4 November 2026. Left: the prefix variable the draft declares for the DMZ network. Right: the decision recorded for that port group in assessment.json.
variable "network_PG_DMZ_ipv4_prefix" {
type = string
description = "IPv4 prefix (CIDR) for the network replacing port group PG-DMZ. Addresses seen on it: 198.51.100.10, 198.51.100.11."
}{
"id": "network.PG-DMZ",
"result": {
"class": "RECONFIGURE",
"confidence": "MEDIUM",
"target": {
"service": "STACKIT network"
},
"reason": "A port group becomes a STACKIT network. VLAN IDs and virtual switches have no meaning on STACKIT; the IP prefix has to be set explicitly (RVTools does not export subnet masks) and kept if the VMs keep their addresses."
}
}Option A is the default draft
All 8 port groups of the estate are classified RECONFIGURE and become 8 networks in wave 1. The 10 machines follow in wave 2.
The prefix is yours
RVTools exports no subnet mask. The variable only lists the addresses seen on the port group, here the two DMZ addresses of lb01 and fw-dmz01.
VLAN IDs and switches end here
The reason text says it plainly: VLAN IDs and virtual switches have no meaning on STACKIT. The segmentation intent has to come from you.
The same name on two switches
From the same run. Left: the vNetwork rows of the port group PG-Mgmt, which exists on vSwitch0 and on vSwitch2. Right: the two networks the draft wrote for them.
VM,NIC label,Adapter,Network,Switch,Connected,IPv4 Address,VM UUID
fw-dmz01,Network adapter 3,Vmxnet3,PG-Mgmt,vSwitch0,True,10.60.99.5,6002-cccc-0001
bkp01,Network adapter 2,Vmxnet3,PG-Mgmt,vSwitch0,True,10.60.99.10,6002-cccc-0008
jump01,Network adapter 1,Vmxnet3,PG-Mgmt,vSwitch0,True,10.60.99.20,6002-cccc-0009
jump02,Network adapter 1,Vmxnet3,PG-Mgmt,vSwitch2,True,10.61.99.20,6002-cccc-0010resource "stackit_network" "network_PG_Mgmt_45abe3c6" {
project_id = var.project_id
name = "pg-mgmt-45abe3c6"
ipv4_prefix = var.network_PG_Mgmt_45abe3c6_ipv4_prefix
ipv4_nameservers = var.network_PG_Mgmt_45abe3c6_ipv4_nameservers
}
resource "stackit_network" "network_PG_Mgmt_8e1ad156" {
project_id = var.project_id
name = "pg-mgmt-8e1ad156"
ipv4_prefix = var.network_PG_Mgmt_8e1ad156_ipv4_prefix
ipv4_nameservers = var.network_PG_Mgmt_8e1ad156_ipv4_nameservers
}Two networks, not one
The engine treats the two PG-Mgmt port groups as separate units. The network names are made unique with a suffix derived from each port group's address in the source, as the comment above each block states.
The wiring is left to you
In this run every interface on that name, for fw-dmz01, bkp01, jump01 and jump02, reads its network id from a variable instead of pointing at either network. You say which of the two it joins.
Why it matters for design
Duplicate names often point to two sites or two clusters. That is a chance to decide whether they become one network, two networks or two projects.
A multi-homed firewall VM
From the same run. Left: the three adapters of fw-dmz01. Right: the three network interfaces drafted for it.
VM,NIC label,Adapter,Network,Switch,Connected,IPv4 Address,VM UUID
fw-dmz01,Network adapter 1,Vmxnet3,PG-DMZ,dvs-dmz,True,198.51.100.10,6002-cccc-0001
fw-dmz01,Network adapter 2,Vmxnet3,PG-Web,dvs-prod,True,10.60.10.1,6002-cccc-0001
fw-dmz01,Network adapter 3,Vmxnet3,PG-Mgmt,vSwitch0,True,10.60.99.5,6002-cccc-0001resource "stackit_network_interface" "vm_fw_dmz01_nic1" {
project_id = var.project_id
network_id = stackit_network.network_PG_DMZ.network_id
ipv4 = "198.51.100.10"
}
resource "stackit_network_interface" "vm_fw_dmz01_nic2" {
project_id = var.project_id
network_id = stackit_network.network_PG_Web.network_id
ipv4 = "10.60.10.1"
}
resource "stackit_network_interface" "vm_fw_dmz01_nic3" {
project_id = var.project_id
network_id = var.vm_fw_dmz01_nic3_network_id
ipv4 = "10.60.99.5"
}One interface per adapter
Three adapters give three interfaces, each with the address from the export. Three is within the limit of five interfaces per server stated in the STACKIT documentation.
Public-looking addresses need a decision
On STACKIT a floating IP is mapped by NAT to the private address and is not visible inside the operating system. A guest that carries a public address on its own adapter cannot simply keep it.
No security groups in the draft
The four Terraform files of the run contain no security group. Which flows the firewall leg allowed is design work for you.
Where the VMware picture and the STACKIT picture differ
| VMware element | What the run does | Your decision |
|---|---|---|
| Standard and distributed switches | Not carried. The run lists the switch among the properties the draft leaves out. | Nothing to rebuild. Decide the zones instead. |
| Port group and VLAN | One network per port group, prefix and DNS servers as variables. | The CIDR per network. Keep the old range if machines keep their addresses. |
| Inter-VLAN firewall rules | Not drafted. | Security groups at the interface, or an appliance. Start from flows, not from port group names. |
| Machines with several adapters | One interface per adapter, wired by name. | Whether the machine still needs every leg. Remember the limit of five. |
| Unconnected adapters | jump02 has a PG-Spare adapter with Connected = False. A network and an interface are drafted anyway. | Drop dead port groups before you migrate them. |
The demo uses the documentation address ranges 198.51.100.0/24 and 192.0.2.0/24 as stand-ins for public addresses. The STACKIT Network Area FAQ lists both among the ranges that cannot be used, so check your real ranges against that list.
How to decide
Count trust zones, not port groups
List the zones that have different rules, for example internet-facing, application, data, backup and management. Port groups that serve one zone are candidates to merge.
Decide where the filtering lives
Security groups at the interface, an appliance, or both. The STACKIT guidance on networks advises least privilege and removing the default allow entries.
Fix the addressing
Keep the ranges if machines keep their addresses, otherwise re-address and plan the DNS changes. Settle this before you choose a network area, because its ranges cannot be changed later.
Choose one project or several
As a rule of thumb, start with one project per environment. Move to several projects only when administrative separation justifies the extra rules between them.
Write the allow-list from the flows
Take the flows from the application owners and from a dependency review. RVTools shows where machines sit, not who talks to whom.
Prove it with the first wave
Networks come first in the plan. Apply them in a test project, attach one machine per tier and test the rules before you move the rest.
Questions about network segmentation
Do VLAN IDs carry over to STACKIT?
No. The run states that VLAN IDs and virtual switches have no meaning on STACKIT. Each port group becomes a network, and the separation is rebuilt from networks and security groups.
Does StackToIT create security groups?
Not in this run. The draft holds networks, interfaces, servers and volumes. The STACKIT documentation describes security groups as stateful, with incoming traffic blocked unless permitted, so every flow you need is a rule you add.
Can machines in different networks reach each other?
Traffic between networks of one project is handled by the project router. Whether a packet arrives is still decided by the security groups of the destination interface.
When is a network area worth it?
When you want separate projects that still reach each other privately. Plan the ranges and the transfer network carefully: the STACKIT FAQ says existing ranges cannot be changed.
What if two port groups have the same name?
If they sit on different switches the run keeps them as two networks and asks you to wire the interfaces. Treat it as a cue to check whether the two are really the same segment.
Sources
Your next move: STACKIT.
Tell us about your estate. We show you what StackToIT delivers for it: target architecture, Terraform artifacts and a structured migration plan.