Physical Networks

2.1. What are Physical Networks?

Physical Networks are zone-level templates for host bridge configuration. They model how cloud traffic flows under the hood and define the parent isolation policy used by guest networks.

Note

Karios provisions the zone’s physical network and all four traffic types (Management, Public, Guest, Storage) automatically during installation, and creates additional physical networks on demand when you add guest networks and register fabric switches (see 2.3). Multiple physical networks per zone are normal. Day-to-day operation does not require creating one by hand - review the existing rows first.

2.1.1. Key Concepts

  • Zone: every physical network belongs to exactly one zone.

  • Isolation Method: VLAN (Layer-2 tagging), or VXLAN (overlay tunneling) for tenant separation.

  • VLAN/VNI Range: pool consumed when new guest networks are created. VNI means VXLAN Network Identifier.

  • Traffic Types: Guest, Management, Public, and Storage traffic categories.

  • Broadcast Domain Range: scope of broadcast domains (ZONE or POD).

  • Guest Network Inheritance: guest NIC networks inherit parent physical-network isolation settings.

2.1.2. Table Columns

Column

Description

Physical Network

Network name. Click to open details.

State

Enabled or Disabled.

Isolation Method

Tenant isolation mode (VLAN or VXLAN).

Underlay bridge

Linux bridge on each KVM node that egresses this physical network’s traffic (for example cloudbr0).

Tags

Labels used for organization and filtering.

2.2. Physical Network Dashboard

When to Use:

  • Use this before creating, editing, or troubleshooting physical-network configuration.

Purpose:

  • Validate existing physical networks, isolation methods, and action availability from a single dashboard.

Path:

  • K-Nets -> Physical Network

Note

Every K-Nets -> path on this page is also reachable at Control Center -> Network -> .... Non-root tenant accounts do not see the K-Nets module and must use the Control Center path.

Physical network dashboard

Dashboard usage:

  • Review each row for State and Isolation Method before making changes.

  • Click a Physical Network name to open details.

  • Review the Underlay bridge column to confirm which host bridge carries each network.

  • Use the info icon beside Physical Network in the table header for quick context.

Note

The physical-network list is read-only. There is no + Add Physical Network button and no per-row edit or enable/disable action in the current UI - Karios provisions the physical network and its traffic types automatically at install (see 2.3).

Expected Outcome:

  • You can identify the correct network row for your next action.

  • You can confirm whether target networks are Enabled before creating dependent resources.

If this fails:

See Common screen checks before retrying this screen.

2.2.1. Open Physical Network Help Panel

When to Use:

  • Use this when you need inline definitions and quick-reference guidance for the Physical Network page.

Purpose:

  • Open the page help panel after reviewing the dashboard so field meanings and actions are clear.

Steps:

  1. Open K-Nets -> Physical Network.

  2. Click the top-right help icon.

  3. Review the quick-reference panel and search inside it if needed.

Physical Network help panel opened from the dashboard

Expected Outcome:

  • Physical Network page guidance opens in the side help panel.

  • You can continue dashboard actions with field-level context.

If this fails:

  1. Refresh the page and click the help icon again.

  2. Confirm your account can access in-product help content.

  3. Retry after reopening Physical Network.

2.3. Create Physical Network

Physical networks are created automatically - you rarely create one by hand:

  • At install, the installer provisions the zone’s Advanced physical network and its traffic types (Management, Public, Guest, Storage).

  • When you create a guest network, Karios provisions the backing physical network on demand: a per-bridge, VLAN-isolated physical network (named nic-<bridge>, for example nic-cloudbr0) for an Isolated or L2 guest network in VLAN mode, or a shared vxlan-tagged physical network for a VXLAN guest network. During this the zone is briefly disabled and re-enabled, because the platform rejects physical-network creation on an enabled zone.

    A Shared network is the exception: it is attached by explicit physical-network ID, so an existing physical network whose Guest traffic type already egresses on the right bridge is reused as-is and no nic-<bridge> network is created.

  • When you register a fabric switch (SDN Fabric), Karios creates the karios-vxlan-fabric physical network for the EVPN overlay. This runs in the background and is deliberately non-fatal: if the platform is briefly unavailable the save still succeeds, and the physical network is created on the next save or on the next restart of the network service.

Note

Multiple physical networks per zone are normal. A running zone typically shows the installer-provisioned network plus one or more auto-created nic-<bridge> and karios-vxlan-fabric networks. Review the existing rows on the dashboard before assuming a network is missing.

As covered in 2.2, the Physical Network page has no create button; physical-network creation is automatic, or performed through the platform API for advanced automation. There is normally nothing to create here by hand.

Note

A physical network is not useful until at least one traffic type is configured. Karios configures the traffic types automatically for the networks it creates.

2.4. Physical Network Details

When to Use:

  • Use this to inspect one physical network before traffic-type configuration or edits.

Purpose:

  • Validate core network properties on the details page and move to Traffic Types for traffic actions.

Steps:

  1. Open K-Nets -> Physical Network.

  2. Click the target physical network name in the table.

  3. On the details page, review Details tab fields and open Traffic Types tab for traffic operations.

Physical network details page

Details tab:

  • Basic Information: Name, State, Zone, Tags.

  • Network Configuration: Isolation Method, VLAN/VNI, Broadcast Domain Range.

Note

A physical network’s own MTU is not configured on this page. The underlay MTU is declared once at the installer/bootstrap layer. To see a bridge’s live MTU use K-Nets -> Network Topology (node Bridges tab); the fabric-managed values are shown on K-Nets -> SDN Fabric as Underlay MTU and VR uplink MTU, where Underlay MTU is locked read-only once the live cluster value is known. The overlay MTU is always derived as underlay MTU - 50; it is never entered separately. The Guest MTU field on the guest-network create form is a different, per-network value.

Traffic Types tab:

  • Configure which traffic categories this physical network carries.

  • Available categories: Guest, Management, Public, Storage.

  • Traffic-type actions are performed from this Traffic Types tab.

  • Available actions vary by traffic type and your role permissions.

Expected Outcome:

  • The selected physical-network details page opens.

  • You can verify Name, State, Zone, Isolation Method, and VLAN/VNI values.

  • You can continue to Traffic Types for traffic-type-specific actions.

If this fails:

  1. Return to Physical Network dashboard and verify the correct row was selected.

  2. Refresh the page and retry opening the same network.

  3. Verify your account has access to Network details pages.

2.5. Traffic Types

Traffic-type operations are documented in the specific sections below:

Guest Traffic

Purpose:

  • Manage the guest networks attached to a physical network.

Guest traffic represents whole VM networks carried by the parent physical network. Each guest network becomes a VM NIC network and consumes VLAN/VNI capacity from the parent physical-network range.

How Guest Networks Work:

  1. A physical network defines a VLAN/VNI pool (for example 1000-1002).

  2. Creating a guest network consumes one VLAN/VNI from that pool.

  3. VMs attached to that guest network receive NICs and IPs from the guest-network subnet.

  4. Network type (Isolated, Shared, or L2) determines routing model and access behavior.

Tip

Monitor VLAN/VNI usage in this table. If the range is exhausted, no new guest networks can be created until you expand the range or add a new physical network.

Guest Network Types:

  • Isolated:

    • Private network model scoped to a tenant/account.

    • Uses virtual-router services from the selected offering (NAT, firewall, VPN, load balancing).

    • Source NAT egress is provided by isolated-network services.

    • Inbound access is controlled through NAT/firewall rules.

  • Shared:

    • Flat subnet model that can be used across accounts.

    • No virtual-router NAT or firewall path for the guest network. A virtual router may still be deployed to provide DHCP, DNS, or user-data, depending on the selected offering.

    • VMs receive IPs directly from the configured shared-network range.

  • L2:

    • Pure Layer-2 segment, carried either as a VXLAN VNI on the EVPN fabric or as a native 802.1Q VLAN on an existing VLAN physical network. You choose the encapsulation on the VLAN / VXLAN control when you create the network.

    • No virtual router, no gateway, no DHCP/DNS from Karios - your own network services handle addressing.

    • Use for lift-and-shift workloads that bring their own DHCP/gateway, or appliance-style VMs.

Note

Only the VXLAN-backed L2 family needs a configured EVPN fabric. The VLAN-backed L2 family rides the operator’s existing 802.1Q VLAN physical network and is exempt from the fabric readiness gate, so it still works when no fabric is configured.

Guest Networks Table Columns:

Column

Description

Name

Guest network name. Click to open guest-network details.

Type

Isolated, Shared, or L2.

VLAN/VNI

Assigned VLAN/VNI ID or untagged when applicable.

Broadcast URI

Broadcast-domain identifier (for example vlan://1001).

CIDR

IPv4 subnet for the guest network.

IPv6 CIDR

IPv6 subnet when configured, otherwise -.

Step: Open Guest Traffic Details Page

When to Use: Use this when you need to review guest networks on a specific physical network.

Purpose: Guest networks consume VLAN/VNI IDs from the parent physical network, so this is the primary place to verify capacity and network inventory.

Guest traffic details page showing the Base Bridge panel and the guest networks table

Details page shows:

  • A Base Bridge · Guest Traffic panel naming the Linux bridge (for example cloudbr3) this traffic type egresses on each host.

  • Guest network rows with Name, Type, VLAN/VNI, Broadcast URI, and CIDR columns.

  • + Add Guest Network action for new network creation.

What you can do from this screen:

  • Open guest-network details by clicking a network name.

  • Launch guest-network creation for Isolated, Shared, and L2 workflows.

  • Validate current VLAN/VNI consumption in this physical network.

Steps:

  1. Open K-Nets -> Physical Network.

  2. Click the target physical network name.

  3. Click Traffic Types.

  4. Click Guest.

Expected Outcome:

  • You can review all guest networks on the selected physical network.

  • You can create guest networks and open each network’s detail page.

Continue with Page Help Review:

  1. Click the top-right help icon.

  2. Use the i icon near Guest Networks for quick column definitions.

  3. For help-panel behavior, follow the same flow used in 2.2.1 Open Physical Network Help Panel.

If this fails: 1. Confirm you opened the intended physical network row. 2. Refresh and reopen Traffic Types -> Guest. 3. Verify your account can access networking pages.

Step: Add Isolated Guest Network (from Physical Network)

When to Use: Use this when you need a tenant-private network with isolated-network services.

Purpose: Isolated networks provide private VM networking with network services based on the selected offering.

Step 1: choose Network Type as Isolated.

Steps:

  1. From Traffic Types -> Guest, click + Add Guest Network.

  2. Keep Network Type set to Isolated.

  3. Choose VLAN or VXLAN based on the physical network design.

  4. Complete the required network details.

  5. For a VLAN-isolated network, click Next and complete the NIC assignment step, then click Create Network. For a VXLAN-isolated network, click Create Network directly.

Note

L2 networks - both VLAN- and VXLAN-backed - also create in a single step. There is no NIC assignment step for them, and the primary button already reads Create Network. Shared networks always take the NIC assignment step.

Isolated-network fields:

  • Zone (required)

  • VLAN or VXLAN (VNI) (required unless an Auto-VNI offering is selected - see below)

  • Network Name (required)

  • Network Offering (required; must support isolated-network capabilities)

  • Gateway and Netmask (required)

  • DNS 1 and DNS 2 (optional)

  • Guest MTU (optional)

  • NIC Mode: Tagged or Untagged when VLAN mode is selected

Note

If the selected network offering is an Auto-VNI offering, the VXLAN (VNI) field is hidden and the platform allocates the VNI from the pool. Enter a VNI only for a manual offering that requires one.

Use the canonical field-level steps in Create Guest Network (Section 3.5).

Add isolated guest network form using VLAN from physical network traffic types

VXLAN option in this flow:

Add isolated guest network with VXLAN selected from physical network traffic types

VXLAN-specific fields:

  • VXLAN (VNI) (required unless an Auto-VNI offering is selected)

  • Network Offering set to a VXLAN-capable isolated offering

  • Gateway and Netmask (required)

  • DNS 1 and DNS 2 (optional)

  • Guest MTU (optional)

Expected Outcome:

  • Creation is asynchronous: the request is accepted and a progress panel tracks bridge, network, and virtual-router provisioning live. The network does not appear in the list the instant you click Create Network.

  • Once provisioning finishes, the new network appears in guest network lists.

Which initial state you should expect depends on the offering:

Offering

Initial state

What happens next

Takes an explicit VLAN/VXLAN (VNI) and is not persistent (the default Karios-VLAN-Isolated / Karios-VXLAN-Isolated)

Setup

Setup is the normal, operational, terminal state for these. The network never moves to Implementing/Implemented, and the virtual router is deployed when the first VM lands on it.

Auto-VNI or persistent (for example Karios-VXLAN-Auto-Isolated, *-AutoScale)

Allocated

Progresses Allocated -> Implementing -> Implemented. Implemented is the operational state for these (VR up, Source NAT IP present).

Warning

Do not recreate a network because it sits in Setup and never reaches Implemented. For an explicit-VLAN/VNI, non-persistent offering that progression does not exist, and Setup is the healthy state.

If this fails:

  1. Follow the Create Guest Network failure checks first (required fields, offering compatibility, name uniqueness).

  2. For a VXLAN-isolated network, confirm the EVPN fabric is ready. Creation is blocked when the fabric switch is not registered, its rollout has not completed or has failed, nodes have not converged, or BGP peering to the fabric is not established. Register and verify the fabric first - see SDN Fabric. This gate does not apply to VLAN-isolated or VLAN-backed L2 networks.

  3. Reopen Traffic Types -> Guest details page and confirm whether the network row was created.

Step: Add Shared Guest Network (from Physical Network)

When to Use: Use this when VMs must use a common flat subnet without isolated-network NAT/firewall path.

Purpose: Shared-network IP, VLAN, and gateway values directly control the VM address pool and subnet behavior.

Add shared guest network form from physical network traffic types

Step 1: choose Network Type as Shared.

Steps:

  1. From Traffic Types -> Guest, click + Add Guest Network.

  2. Set Network Type to Shared.

  3. Complete the required network details.

  4. Click Next and complete the NIC assignment step, then click Create Network.

Shared-network fields:

  • Zone (required)

  • Network Offering (required; must support shared networks)

  • PVLAN Type (optional; defaults to not a PVLAN)

  • VLAN (required; or untagged where applicable)

  • Network Name (required)

  • NIC Mode: Tagged or Untagged

  • Start IP and End IP (required)

  • Gateway (required)

  • Netmask (required)

  • DNS values when required by the environment

  • Guest MTU (optional)

Note

The shared-network IP range is the actual VM allocation pool. Size it for expected VM count.

Use the canonical field-level steps in Create Guest Network (Section 3.5).

Expected Outcome:

  • Network appears with state Setup after successful creation. Setup is the normal, operational state for a shared network - it is not an intermediate step waiting to become Implemented.

  • VMs can consume IPs from the configured range.

Warning

Keep the gateway outside the VM allocation pool to avoid IP conflicts.

Warning

For shared networks, ensure VLAN is within the parent physical-network VLAN range (or use untagged when supported).

If this fails:

  1. Follow the Create Guest Network shared-network failure checks first (subnet math, overlap, VLAN validity).

  2. Confirm Physical Network ID matches the expected physical network.

Step: Open Guest Network Details

When to Use: Use this when you need full configuration for one guest network.

Purpose: The details page is the source for network configuration verification before attaching workloads.

Start from the Guest traffic details page shown in Task: Open Guest Traffic Details Page above.

Steps:

  1. In Traffic Types -> Guest, click a network name in the Name column.

  2. Review full network configuration and attached workload context on the detail page.

Result page:

Guest network details page opened from the Guest traffic list

Expected Outcome:

  • The Guest Network details page opens.

  • You can review Basic Information, Network Configuration, and Advanced Configuration cards.

If this fails: 1. Verify the selected row exists in Traffic Types -> Guest. 2. Refresh and retry opening the same network row. 3. Confirm access rights for guest-network details.

Tips:

  • Use Isolated when tenant separation and NAT/firewall controls are required.

  • Use Shared when workloads must be directly reachable on a common subnet.

  • Network offering selection controls available services (DHCP, DNS, NAT, firewall, load balancing, VPN).

Management Traffic

Purpose:

  • Manage the internal control-plane network used by Karios infrastructure components.

Management traffic is the control plane for hosts, virtual routers, system VMs, and management services. Each management IP range is assigned per pod, and hosts consume IPs from the range of the pod they join.

Warning

Management IP exhaustion can block host onboarding and delay system-VM operations.

What Uses Management Traffic:

  • Hosts (KVM compute nodes)

  • Virtual Routers (network-service system VMs)

  • System VMs (for platform services)

  • Management Server control-plane communication

Management IP Ranges Table Columns:

Column

Description

Pod

Pod this range belongs to. Pod name links to pod details.

Zone

Zone where the pod resides.

Start IP

First IP in the management range.

End IP

Last IP in the management range.

VLAN

VLAN tag or Untagged when no VLAN tag is used.

For System VMs

Whether the range is reserved for system VMs only (Yes/No).

Step: Open Management Traffic Details Page

When to Use: Use this when reviewing control-plane IP ranges for a physical network.

Purpose: Management ranges determine addressing for hosts and system components in each pod.

Management traffic details page showing the management IP range table

Details page shows:

  • A Base Bridge · Management Traffic panel naming the Linux bridge (for example cloudbr0) this traffic type egresses on each host. This panel appears on every traffic-type tab; it reads Not set when the traffic type has no bridge label.

  • Management IP range rows with pod, zone, subnet, VLAN, and system-VM reservation context.

  • + Add Management IP Range action for control-plane capacity expansion.

What you can do from this screen:

  • Review management addressing coverage per pod.

  • Add new management IP ranges.

  • Validate whether ranges are reserved for system VMs.

Steps:

  1. Open K-Nets -> Physical Network.

  2. Click the target physical network name.

  3. Click Traffic Types.

  4. Click Management.

Expected Outcome:

  • You can review all management IP ranges for this physical network.

  • You can add ranges, validate pod assignment, and verify system-VM reservation settings.

Continue with Page Help Review:

  1. Click the top-right help icon.

  2. Use the i icon beside Management IP Ranges for field definitions.

  3. For help-panel behavior, follow the same flow used in 2.2.1 Open Physical Network Help Panel.

If this fails:

  1. Refresh and reopen Traffic Types -> Management.

  2. Confirm the selected physical network row is correct.

  3. Confirm your account can open traffic-type details pages.

Step: Add Management IP Range

When to Use: Use this when a pod needs additional management addressing capacity.

Purpose: Hosts and system services consume management IPs from pod-scoped ranges.

Steps:

  1. Open K-Nets -> Physical Network.

  2. Click the physical network name.

  3. Click Traffic Types -> Management.

  4. Click + Add Management IP Range.

  5. Fill required form fields:

    • Pod (required)

    • Gateway (required)

    • Netmask (required)

    • Start IP (required)

    • End IP (required)

  6. Click Create IP Range.

Create management IP range form

Field guidance:

  • Pod: only pods in the physical network’s zone are available.

  • Gateway, Netmask, Start IP, and End IP must be valid IPv4 values in the same subnet.

  • Ensure Start IP <= End IP.

Expected Outcome:

  • New row appears in Management IP Ranges for the selected pod.

How Many IPs to Plan:

  • One management IP per host added to the pod

  • Additional IPs for system VMs

  • Additional IPs for virtual routers when isolated guest networks are used

Tip

Allocate headroom in management ranges to avoid blocking future host or system-VM placement.

Warning

Do not overlap management range with guest, storage, or public ranges.

If this fails:

  1. Verify pod selection is correct.

  2. Verify IPv4 format and subnet math (gateway/start/end in same subnet).

  3. Ensure Start IP <= End IP.

  4. Confirm the range is not already present.

Management Tips:

  • Keep management traffic on a stable, dedicated network path.

  • Use pod-specific management ranges to avoid cross-pod conflicts.

  • Use For System VMs: Yes ranges when separating system-VM addressing from host management addressing.

Storage Traffic

Purpose:

  • Manage storage-network IP ranges used by hosts and storage services.

Storage traffic defines how hosts communicate with shared storage backends across Karios. These ranges are pod-scoped and are isolated on dedicated VLANs or subnets so storage I/O does not compete with management or guest traffic.

Warning

Running out of storage IPs can block new host onboarding and storage access expansion.

What Uses Storage Traffic:

  • Instance Storage backends (for VM disk volume read/write paths)

  • Image Storage services (VM template, Boot Image, and snapshot transfer paths)

  • Hosts that mount and access shared storage

Storage IP Ranges Table Columns:

Column

Description

Pod

Pod this storage range belongs to.

Gateway

Gateway for the storage subnet.

Netmask

Subnet mask for the storage subnet.

Start IP

First IP in the storage range.

End IP

Last IP in the storage range.

VLAN

VLAN tag for this range, or Untagged.

Note

The Storage IP Ranges table has no Actions column. Storage IP ranges are platform-managed: deletion is intentionally not exposed in the UI, so an operator cannot accidentally remove the storage networking the platform depends on. Storage ranges are removed only through the platform teardown flow.

Step: Open Storage Traffic Details Page

When to Use: Use this when checking storage-network ranges on a physical network.

Purpose: Storage ranges are required for host-to-storage communication and expansion planning.

Storage traffic details page showing the storage IP range table

Details page shows:

  • A Base Bridge · Storage Traffic panel naming the Linux bridge (for example cloudbr1) this traffic type egresses on each host. It reads Not set when the traffic type has no bridge label.

  • Storage IP range rows with pod, subnet, and VLAN. There is no per-row action column.

  • + Add Storage IP Range action for storage-network capacity expansion.

What you can do from this screen:

  • Review storage network ranges per pod.

  • Add new storage IP ranges.

Steps:

  1. Open K-Nets -> Physical Network.

  2. Click the target physical network name.

  3. Click Traffic Types.

  4. Click Storage.

Expected Outcome:

  • You can review storage ranges and launch the add action.

Continue with Page Help Review:

  1. Click the top-right help icon.

  2. Use the i icon beside Storage IP Ranges for field definitions.

  3. For help-panel behavior, follow the same flow used in 2.2.1 Open Physical Network Help Panel.

If this fails:

  1. Refresh and reopen Traffic Types -> Storage.

  2. Confirm the selected physical network row is correct.

  3. Confirm your account can open storage traffic details.

Step: Add Storage IP Range

When to Use: Use this when a pod needs more storage-network IP capacity.

Purpose: Each host and storage service path consumes storage IPs from these ranges.

Steps:

  1. Open K-Nets -> Physical Network.

  2. Click the physical network name.

  3. Click Traffic Types -> Storage.

  4. Click + Add Storage IP Range.

  5. Fill required fields:

    • Pod

    • Gateway

    • Netmask

    • Start IP

    • End IP

  6. Click Create IP Range.

Create storage IP range form

Field guidance:

  • Pod: choose the pod this range belongs to.

  • Gateway, Netmask, Start IP, and End IP must be valid IPv4 values in one subnet.

  • Ensure Start IP <= End IP.

Expected Outcome:

  • New row appears in Storage IP Ranges.

How Many IPs to Plan:

  • One storage IP per host in the pod

  • One storage IP for image-storage services

  • Additional spare IPs for future host additions

Tip

Keep storage traffic on a dedicated low-latency network path where possible.

If this fails:

  1. Confirm valid pod and subnet values.

  2. Confirm no overlap with management/guest/public ranges.

  3. Confirm Start IP <= End IP.

Removing a Storage IP Range

There is no delete action for storage IP ranges in the UI. Storage IP ranges are platform-managed and are removed only through the platform teardown flow - deletion is deliberately withheld so an operator cannot remove the storage networking that hosts and image-storage services depend on.

If a storage range is wrong or too small, add a correctly sized range instead; existing hosts keep the IPs they already hold.

Storage Tips:

  • Use dedicated VLANs/subnets for storage traffic to protect storage performance.

  • Multiple storage ranges can exist in the same pod for separate storage backends.

  • Validate storage network bandwidth and latency to match backend requirements.

Public Traffic

Purpose:

  • Manage internet-facing IP ranges used for external connectivity services.

Public traffic provides the public IP inventory used for outbound and inbound connectivity in cloud networking workflows.

What Public IPs Are Used For:

  • Source NAT: outbound internet access for isolated guest networks.

  • Static NAT: one-to-one public-to-private VM mapping.

  • Port Forwarding: port-level mapping from public IP to VM service ports.

  • Firewall: ingress policy control applied to public-IP traffic.

  • Load Balancing: front-end public VIPs distributed to backend VM pools.

  • VPN: remote-access and site-to-site tunnel endpoints.

Warning

Incorrect gateway or routing for public ranges can break all external connectivity for dependent services.

Public IP Ranges Table Columns:

Column

Description

VLAN

VLAN tag for this range, or Untagged.

Gateway

Upstream gateway for the public subnet.

Netmask

Subnet mask for the public range.

Start IP

First public IP in the range.

End IP

Last public IP in the range.

Actions

Edit and Delete controls for the range.

Note

The edit and delete icons render only for accounts holding the NETWORK_MANAGE permission. Without it the Actions cell is empty and the + Add Public IP Range button is absent. The same permission gates the add action on every traffic type.

Step: Open Public Traffic Details Page

When to Use: Use this when reviewing internet-facing IP inventory and range actions.

Purpose: Public ranges back Source NAT, Static NAT, load balancer, VPN, and forwarding workflows.

Public traffic details page showing the Base Bridge panel and the public IP ranges table with edit and delete actions

Details page shows:

  • A Base Bridge · Public Traffic panel naming the Linux bridge (for example cloudbr2) this traffic type egresses on each host.

  • Public IP range rows with VLAN, Gateway, Netmask, and IP boundaries.

  • Actions column with pencil (edit) and trash (delete) icons per range.

  • + Add Public IP Range action for expanding public inventory.

What you can do from this screen:

  • Review current public subnet inventory.

  • Add, edit, and delete public IP ranges.

  • Validate gateway/subnet consistency before NAT and exposure workflows.

Steps:

  1. Open K-Nets -> Physical Network.

  2. Click the target physical network name.

  3. Click Traffic Types.

  4. Click Public.

Expected Outcome:

  • You can view configured public IP ranges and launch create/edit/delete actions.

Continue with Page Help Review:

  1. Click the top-right help icon.

  2. Use the i icon beside Public IP Ranges for field definitions.

  3. For help-panel behavior, follow the same flow used in 2.2.1 Open Physical Network Help Panel.

If this fails:

  1. Refresh and reopen Traffic Types -> Public.

  2. Confirm the selected physical network row is correct.

  3. Confirm your account can open public traffic details.

Step: Add Public IP Range

When to Use: Use this when you need additional public addresses for external connectivity services.

Purpose: Public IP pool size controls how many NAT, VPN, and public service mappings can be created.

Start from the Public traffic details page shown in Task: Open Public Traffic Details Page above.

Steps:

  1. Open K-Nets -> Physical Network.

  2. Click the physical network name.

  3. Click Traffic Types -> Public.

  4. Click + Add Public IP Range.

  5. Fill required fields:

    • Physical Network

    • Zone

    • Gateway

    • Netmask

    • Start IP

    • End IP

    Optional:

    • VLAN - the VLAN ID, or leave blank/untagged for an untagged range.

  6. Click Create IP Range.

Create public IP range form

Field guidance:

  • Physical Network: parent network for this range.

  • Zone: populated from the selected physical network.

  • VLAN: tagged VLAN ID or untagged.

  • Gateway, Netmask, Start IP, and End IP must be valid IPv4 values in the same subnet.

Expected Outcome:

  • New range appears in Public IP Ranges.

How Many Public IPs to Plan:

  • One Source NAT IP per isolated guest network.

  • One IP per static NAT VM mapping.

  • Additional IPs for VPN and load-balancer endpoints.

  • Port-forwarding services can share a public IP when port mappings do not overlap.

If this fails:

  1. Verify Gateway, Netmask, Start IP, and End IP are valid and in the same subnet.

  2. Confirm range does not overlap an existing public range.

  3. Confirm VLAN/tagging selection is valid for the selected physical network.

Step: Edit Public IP Range

When to Use: Use this when correcting gateway/netmask/start/end values on an existing range.

Purpose: In-place edits adjust usable public range boundaries without recreating the range object.

Start from the Public traffic details page shown in Task: Open Public Traffic Details Page above.

Steps:

  1. In Traffic Types -> Public, locate the target row.

  2. Click the pencil icon in Actions.

  3. Update allowed fields in the edit form. All four are resubmitted together, so the form arrives pre-filled with the current values - change only what you need and leave the rest as-is.

  4. Click Update IP Range and verify the updated values in the table.

Expected Outcome:

  • Updated range values are visible in the Public IP Ranges table.

  • Existing allocations remain unchanged; only range boundaries/metadata are updated.

Tip

Use edit for boundary corrections; use new range creation for major subnet redesigns.

Editable fields:

  • Gateway

  • Netmask

  • Start IP

  • End IP

Not editable in-place (these are not shown on the edit form at all, not merely disabled):

  • VLAN

  • Physical Network

  • Zone

Warning

Shrinking a range affects only unallocated IPs. In-use IP allocations are not reclaimed automatically.

If this fails:

  1. Confirm you are editing allowed fields only (gateway/netmask/start/end).

  2. Verify updated values remain in one valid subnet.

  3. Refresh the page and retry the edit action.

Step: Delete Public IP Range

When to Use: Use this when a public range is no longer required.

Purpose: Removing unused ranges keeps the public IP inventory aligned to active services.

Start from the Public traffic details page shown in Task: Open Public Traffic Details Page above.

Steps:

  1. In Traffic Types -> Public, locate the target row.

  2. Click the trash icon in Actions.

  3. Confirm deletion.

  4. Refresh and verify row removal.

Expected Outcome:

  • The selected public IP range is removed from the table.

  • Deleted range space is no longer available for new allocation.

Warning

Delete is blocked when IPs are still allocated to NAT, load balancer, VPN, or forwarding rules.

If this fails:

  1. Confirm subnet and gateway correctness.

  2. Check whether any public IP from the range is in active use.

  3. Validate you have sufficient privileges for the action.

  4. Retry after releasing dependent public IP allocations.

Tips:

  • Public IPs are finite resources. Use port forwarding where possible to reduce one-IP-per-service consumption.

  • Multiple public ranges can be added to one physical network when needed.

  • Isolated networks consume public IPs for Source NAT; shared networks use their own guest-network IP definitions.

  • Always verify upstream gateway reachability before creating ranges.

→ Next: Guest Networks