Network

Note

Use this section for network operations across Physical Network, Guest Network, SDN Fabric, Network Topology, IPAM, DNS Analytics, and VPCs.

See also

Prerequisites for network changes:

• Infrastructure with at least one enabled zone/pod/cluster

• Virtual Machines if validating network behavior with live workloads

• Appendices for quick troubleshooting references

Table of Contents

• Network Overview

• Physical Networks

• Guest Networks

• SDN Fabric

• Network Topology

• IPAM

• DNS Analytics

• VPCs

Quick Tasks

Use Network Quick Tasks for fast, action-only workflows.

Common screen checks

Use these checks for read-only network dashboard and table views before retrying:

1. Confirm you are in the correct zone or environment scope for the target network object.

2. Verify your role can view or manage network resources in that scope.

3. If expected rows are missing, re-check upstream Infrastructure state before retrying.

1. Network Overview

1.1. Network Types

Physical Networks

• Zone-level network configuration

• Defines traffic types (Guest, Management, Storage, Public)

• Sets isolation method (VLAN, VXLAN, or GRE)

• Template for infrastructure networking

Guest Networks

• VM-level network configuration

• Two types: Isolated and Shared

• VMs connect to guest networks

• Provides network services to VMs

Isolation Method Selection (VLAN vs VXLAN vs GRE)

Use this quick guide when creating or updating physical networks:

Method	Choose when	Watch-outs
VLAN	You need simple L2 segmentation and your switch fabric is already VLAN-based.	Limited ID space (1-4094), requires switch trunk/allowed-VLAN alignment.
VXLAN	You need large-scale tenant segmentation or stretched overlay design across L3 underlay.	Requires overlay-capable network design and MTU headroom for encapsulation overhead.
GRE	You need routed tunnel-style isolation where GRE is a defined platform standard.	Confirm hardware/network policy support first; avoid ad-hoc GRE use without architecture approval.

1.1.1. Why Configure Traffic Types

Traffic types exist so each class of traffic can be controlled independently for reliability, security, and scale.

Traffic Type	Why it exists	When you need to add/change it
Management	Carries host and system-VM control-plane communication.	Add or expand when onboarding more hosts/system VMs or when management IP capacity is low.
Storage	Carries host-to-storage I/O paths and helps isolate storage load from other traffic.	Add or expand when storage traffic grows, latency is high, or storage IP capacity is low.
Public	Provides internet-facing IP space for NAT, port forwarding, VPN, and external exposure.	Add when workloads need public ingress/egress; skip for internal-only deployments.
Guest	Defines the VM-attached networks where workload traffic actually flows.	Change when you need new tenant/network segments, custom VLAN/VXLAN mapping, or shared-subnet design.

1.1.2. Guest Network Type Descriptions (Plain Language)

• Isolated: private VM network with built-in network services (DHCP/NAT/firewall).

• Shared: flat VM network on a shared subnet. Use when VMs must be directly reachable on an existing network design.

1.2. Network Hierarchy

Zone
└── Physical Network
├── Guest Traffic Type → Guest Networks (VMs)
├── Management Traffic Type (Hosts, System VMs)
├── Storage Traffic Type (Storage communication)
└── Public Traffic Type (External access)

1.3. Network Modules (UI)

The Network sidebar currently includes:

• Physical Network: Control Center -> Network -> Physical Network

• Guest Network: Control Center -> Network -> Guest Network

• SDN Fabric: Control Center -> Network -> SDN Fabric

• Network Topology: Control Center -> Network -> Network Topology

• IPAM: Control Center -> Network -> IPAM

• DNS Analytics: Control Center -> Network -> DNS Analytics

• VPCs: Control Center -> Network -> VPCs

Note

This guide includes full new-user paths for all network modules listed above, including VPCs.

2. 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.

2.1.1. Key Concepts

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

• Isolation Method: VLAN (Layer-2 tagging), VXLAN (overlay tunneling), or GRE (encapsulation tunnel) 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, VXLAN, or GRE).
VLAN / VNI	Allocated ID range (for example 1000-1002).
Tags	Labels used for organization and filtering.
Actions	Row action icons for Edit and Enable/Disable.

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:

• Control Center -> Network -> Physical Network

Dashboard usage:

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

• Click a Physical Network name to open details.

• Click + Add Physical Network (top-right) to open the create form.

• Use the Actions column icons to edit network settings or toggle enabled/disabled state.

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

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 Control Center -> Network -> Physical Network.

2. Click the top-right help icon.

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

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

Create form screenshot:

When to Use:

• Use this to create a new physical-network container for tenant traffic and traffic-type configuration.

Purpose:

• Create a zone-scoped physical network with valid isolation and VLAN/VNI ranges for downstream guest-network allocation.

Steps:

1. Open Control Center -> Network -> Physical Network.

2. Click + Add Physical Network.

3. Fill required fields:

   • Network Name

   • Zone

   • VLAN/VNI Ranges (Start/End; use + Add Range for multiple ranges)

   • Isolation Method (VLAN/VXLAN/GRE)

   • Tags

4. Optional fields:

   • Broadcast Domain Range

   • Domain ID

   • Network Speed

5. Click Create.

Required field notes:

• Network Name: use a clear, unique naming pattern.

• Zone: network can be used only within the selected zone.

• VLAN/VNI Ranges: avoid overlaps with existing ranges in the same zone.

• Isolation Method: choose the method used in your network design.

Expected Outcome:

• New physical-network row appears in the table with selected isolation/range settings.

If this fails:

1. Reopen Add Physical Network and re-validate required form inputs.

2. Confirm required fields are populated and VLAN/VNI ranges do not overlap existing ranges.

3. Confirm your account can create physical networks in the selected zone.

Warning

Plan VLAN/VNI ranges before creation. Overlapping ranges in the same zone can cause conflicts.

Note

A new physical network is not useful until at least one traffic type is configured.

2.4. Edit and State Actions

When to Use:

• Use this to adjust editable network attributes or control whether new allocations are allowed.

Purpose:

• Apply safe operational changes without recreating the physical network.

Actions-column icon reference:

Steps:

1. Open Control Center -> Network -> Physical Network.

2. In the target row, use the icons in the Actions column.

3. For Edit, update allowed fields:

   • VLAN/VNI range values

   • Network Speed

   • Tags

4. Confirm non-editable fields remain unchanged:

   • Network Name

   • Zone

   • Isolation Method

5. For state control, use the power-state action icon:

   • Disable blocks new allocations (existing resources continue running)

   • Enable allows new allocations again

Expected Outcome:

• Requested edits are saved.

• Network state updates as expected for new-allocation control.

If this fails:

1. Verify that only editable fields are being modified.

2. Confirm your role has permission for edit/state actions.

3. Retry after refreshing the table and re-opening row actions.

Warning

Updating VLAN/VNI ranges affects only new guest-network allocations.

2.5. 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 Control Center -> Network -> 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.

Details tab:

• Basic Information: Name, State, Zone.

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

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.6. Traffic Types

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

• Guest Traffic

• Management Traffic

• Storage Traffic

• Public Traffic

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 or Shared) 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/firewall path for the guest network.

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

Guest Networks Table Columns:

Column	Description
Name	Guest network name. Click to open guest-network details.
Type	Shared or Isolated.
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.

Details page shows:

• 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 workflows.

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

Steps:

1. Open Control Center -> Network -> 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. Click Create Network.

Isolated-network fields:

• Zone (required)

• VLAN or VXLAN (VNI) (required, depending on selected mode)

• Network Name (required)

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

• Gateway and Netmask (required)

• DNS 1 and DNS 2 (optional)

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

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

VXLAN option in this flow:

VXLAN-specific fields:

• VXLAN (VNI) (required)

• Network Offering set to a VXLAN-capable isolated offering

• Gateway and Netmask (required)

• DNS 1 and DNS 2 (optional)

Expected Outcome:

• New network appears in guest network lists.

• Initial state can remain Allocated until first VM triggers isolated-network initialization.

Tip

Watch for state movement Allocated -> Implementing -> Setup after first isolated-network VM provisioning.

Warning

Allocated is normal for newly created isolated networks. Do not recreate the network because it is not yet Setup.

If this fails:

1. Follow Section 3.5 failure checks first (required fields, offering compatibility, name uniqueness).

2. 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.

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 Create Network.

Shared-network fields:

• Zone (required)

• Network Offering (required; must support shared networks)

• 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

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 in Setup after successful creation.

• 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 Section 3.5 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:

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.

Details layout reference:

Details page shows:

• 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 Control Center -> Network -> 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 Control Center -> Network -> 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.

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.
Actions	Delete action for the range row.

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.

Details layout reference:

Details page shows:

• Storage IP range rows with pod, subnet, VLAN, and actions.

• + 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.

• Delete existing ranges when no longer needed.

Steps:

1. Open Control Center -> Network -> 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 add/delete actions.

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 Control Center -> Network -> 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.

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.

Step: Delete Storage IP Range

When to Use: Use this when a specific storage range is no longer needed.

Purpose: Removing unused ranges keeps storage addressing clean and avoids stale allocations.

Start from the Storage traffic details page shown in Task: Open Storage Traffic Details Page above and locate the target row in the Storage IP Ranges table.

Steps:

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

2. Click the trash icon in the Actions column.

3. Confirm deletion when prompted.

4. Refresh and confirm the row is removed.

Expected Outcome:

• The selected storage range is removed.

• Existing hosts using already-assigned IPs continue operating.

• New hosts cannot receive storage IPs if no storage ranges remain.

Warning

Delete only after confirming capacity and growth requirements are still satisfied.

If this fails:

1. Check whether the range is still referenced by active services.

2. Verify you have permission for delete action.

3. Retry after releasing dependent allocations.

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.

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.

Details page shows:

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

• Actions for in-place edit/delete.

• + 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 Control Center -> Network -> 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 Control Center -> Network -> 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

   • VLAN (or untagged)

   • Gateway

   • Netmask

   • Start IP

   • End IP

6. Click Create IP Range.

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.

4. Save 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:

• 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.

3. Guest Networks

3.1. What are Guest Networks?

Guest networks are where VMs attach and receive their runtime IP connectivity.

Quick selection:

• Isolated: private network with built-in network services.

• Shared: flat subnet model with explicit VLAN/IP inputs.

What These Terms Mean:

• CIDR: Classless Inter-Domain Routing notation for subnet size (for example 10.1.0.0/16).

• NIC: Network Interface Card attached to a VM.

• NAT: Network Address Translation for private-to-public traffic mapping.

• Gateway: default route endpoint used by VMs to reach other networks.

For create/delete tasks, use Sections 3.5 and 3.6.

3.2. Network States

State/action quick reference:

State	What It Means	Typical Operator Action
Allocated	Created, waiting for first isolated-network VM/service activation	Attach/provision first VM to activate services
Implementing	Isolated-network services are being initialized	Wait and monitor; avoid concurrent config changes
Setup	Operational and ready for VM use	Attach additional VMs and continue normal operations

3.3. First VM Activation and Guest-Network State Change

After creating an isolated guest network, first-VM provisioning performs initial network-service activation.

Expected state flow:

• First isolated-network VM provisioning triggers state progression Allocated -> Implementing -> Setup.

• Additional VMs on the same guest network use the existing initialized network services.

Tip

Watch guest-network state changes between Allocated and Setup while the first VM is being created.

If the network remains Implementing after provisioning tasks complete, review the If this fails guidance in the related Guest Network tasks in this section.

3.4. Viewing Guest Networks

Access: Control Center → Network → Guest Network

This dashboard shows all guest networks in the selected environment and provides the main entry points for create, review, and delete actions.

Actions you can perform:

1. Click + Add Guest Network to open the guest-network creation form.

2. Click a value in Guest Network column to open that network’s details page.

3. Click the trash icon in Actions to delete a guest network row.

4. Review State badges (for example Setup) to confirm whether a network is ready for VM attachment.

5. Hover the i icons in table headers (where shown) for inline field help.

VXLAN visibility in this screen:

• VXLAN-backed guest networks appear in the same Guest Network table as other network types.

• In the screenshot above, VXLAN-5000 is an example of a VXLAN guest-network row.

• Use the same actions for VXLAN rows: open details from Guest Network name, verify State, and use row Actions.

Dashboard cards and definitions:

Card	Definition
Total Networks	Total count of guest networks in this view, with isolated and shared totals shown below the count.
Allocated	Count of networks currently in Allocated state.
Implemented	Implemented/active-state summary shown as count and percentage.
Setup	Networks currently ready for workload attachment, shown as count and percentage.
Bandwidth	Aggregate bandwidth usage shown as used versus total capacity.
IP Usage	Aggregate IP consumption shown as used versus total IPs.

Table columns and definitions:

Column	Definition
Guest Network	Guest network name. Click to open details.
Network Type	Network model: Isolated or Shared.
State	Current network lifecycle state (for example Allocated, Implementing, Setup).
Guest CIDR	IPv4 subnet assigned to the guest network.
Gateway	Default gateway for that guest subnet.
VLAN	Segment identifier shown for the network (VLAN value, or overlay segment value for VXLAN-backed rows), or untagged where applicable.
Actions	Row-level action icons (for example delete).

Use this screen first to validate guest-network readiness before VM deployment.

3.4.1. Open Guest Network Help Panel

When to Use:

• Use this after reviewing the Guest Network dashboard when you need help text for fields and actions.

Purpose:

• Open the dashboard help panel as a separate step so users can read quick-reference guidance before performing create/delete operations.

Steps:

1. Open Control Center -> Network -> Guest Network.

2. Click the top-right help icon.

3. Review the Quick Reference content and use search to find specific field guidance.

Expected Outcome:

• Guest Networks help content opens in the right-side panel.

• You can review key concepts such as isolated networks, shared networks, network offerings, guest CIDR, and VLAN/VNI usage.

• You can return to dashboard actions with clear field guidance.

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 Guest Network.

3.5. Creating Guest Network

Use this section when creating guest networks from Control Center -> Network -> Guest Network.

Step: Add Isolated Guest Network (from Guest Network page)

When to Use: Use this when creating a tenant-isolated network directly from the Guest Network module.

Purpose: Create an isolated guest network with the required offering and network parameters.

Steps:

1. Open Control Center -> Network -> Guest Network.

2. Click + Add Guest Network.

3. Keep Network Type as Isolated.

4. Select VLAN or VXLAN based on the network segment you are creating.

5. Complete the required network details.

6. Acknowledge the Before you continue notice when it appears.

7. Click Create Network.

Isolated-network fields:

• Zone (required)

• VLAN or VXLAN (VNI) (required, depending on selected mode)

• Network Name (required)

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

• Network Offering (required; use a VLAN-capable or VXLAN-capable isolated offering)

• Gateway and Netmask (required)

• DNS 1 and DNS 2 (optional)

VXLAN option (isolated):

VXLAN-specific fields:

• VXLAN (VNI) (required)

• Network Offering set to a VXLAN-capable isolated offering

• Gateway and Netmask (required)

• DNS 1 and DNS 2 (optional)

Expected Outcome:

• New isolated network is listed.

• Initial state can be Allocated until first VM/network-service activation.

Tip

Confirm the network appears in the list before attempting to create it again.

Warning

Network offering choice affects available services and can not be easily changed later.

If this fails:

1. Confirm required fields are not blank.

2. Confirm offering supports isolated mode.

3. Verify network name is unique in zone.

Step: Add Shared Guest Network (from Guest Network page)

When to Use: Use this when creating a shared guest network directly from the Guest Network module.

Purpose: Create a shared guest network with explicit VLAN and IP-range settings.

Steps:

1. Open Control Center -> Network -> Guest Network.

2. Click + Add Guest Network.

3. Select Network Type -> Shared.

4. Complete the required network details.

5. Click Create Network.

Shared-network fields:

• Zone (required)

• Network Offering (required; must support shared networks)

• VLAN (required; or untagged where applicable)

• Network Name (required)

• NIC Mode: Tagged or Untagged

• Start IP and End IP (required)

• Gateway and Netmask (required)

• DNS 1 and DNS 2 (optional)

Expected Outcome:

• Shared network is listed in Setup after successful creation.

• VMs consume IPs from the provided range.

Expected Behavior

Shared networks do not require isolated-network service initialization.

Warning

Common First-Time Mistake

Wrong: gateway placed inside VM allocation pool.

Symptom: IP conflicts or unstable connectivity.

Correct pattern:

• CIDR: 192.168.10.0/24

• Gateway: 192.168.10.1 (reserved)

• Start IP: 192.168.10.10

• End IP: 192.168.10.250

Tip

If you do not know Physical Network ID, use Add Shared Guest Network from Physical Network. That flow pre-populates the physical network context.

If this fails:

1. Verify subnet math and gateway reachability.

2. Verify no overlap with existing ranges.

3. Verify VLAN value is valid for target physical network.

3.6. Guest Network Details

Step: Review Guest Network Details

When to Use: Use this when validating configuration and identity fields for one guest network.

Purpose: Inspect the selected guest network before VM attachment, change review, or troubleshooting.

Steps:

1. Open Control Center -> Network -> Guest Network.

2. Click a network name from the table.

3. Validate:

   • ID for API calls, automation, and log correlation

   • State and Type

   • CIDR, Netmask, Gateway

   • DNS and MTU values in advanced fields

Expected Outcome:

• You confirm the guest network identifier and whether core network values match design intent.

If this fails: 1. Refresh the guest network list and reopen the same row. 2. Confirm the network still exists and is visible in the table. 3. Confirm your account can access guest-network details.

Step: Delete Guest Network

When to Use: Use this when a guest network is no longer needed and has no required dependents.

Purpose: Remove a guest network from inventory and confirm it is no longer available for VM attachment.

Use the Guest network details screenshot shown in Task: Review Guest Network Details above.

Steps:

1. Open Control Center -> Network -> Guest Network.

2. Click the target network name.

3. In details page, click Delete (top-right).

4. Confirm deletion.

5. Return to guest network list and verify the row is removed.

Expected Outcome:

• The guest network is removed from inventory.

• It no longer appears as an attachable network during VM provisioning.

Warning

Delete only after detaching workloads and dependent services.

If this fails:

1. Check whether VMs or services are still attached.

2. Check whether related NAT/LB/firewall objects still reference this network.

3. Retry after dependencies are removed.

4. SDN Fabric

Use SDN Fabric to verify virtual-network health across compute nodes. This page shows whether routing and EVPN-VXLAN control-plane exchange are healthy.

Term Definitions:

• BGP: Border Gateway Protocol used for route exchange between SDN nodes.

• OSPF: Open Shortest Path First used for underlay reachability between nodes.

• EVPN: Ethernet VPN control-plane for sharing MAC/IP endpoint information.

• RIB: Routing Information Base, the route table used for forwarding decisions.

• VTEP: VXLAN Tunnel Endpoint on a node.

• VNI: VXLAN Network Identifier for an overlay segment.

Pre-Info: What Karios Configures

When to Use:

• Read this before starting SDN checks so you know the expected baseline state.

Purpose:

• Confirm baseline SDN components that should exist after SDN fabric enablement.

When SDN fabric is enabled in setup, Karios configures node routing and overlay components required for VM traffic.

Provisioning outcomes include:

• Compute nodes configured with routing, tunnel endpoints, and bridge paths for VM traffic.

• VXLAN guest-network baseline available for workload placement.

• BGP peering configured between participating nodes and fabric endpoints.

Operational verification:

1. Launch two VMs on the same VXLAN guest network on different hosts.

2. Test connectivity between the VMs.

3. Use SDN Fabric tabs to confirm BGP, OSPF, EVPN, and RIB health.

Expected Outcome:

• You can verify whether baseline SDN provisioning exists before deeper troubleshooting.

If this fails:

1. Confirm SDN fabric was enabled during setup for the target environment.

2. Validate node registration and routing-node visibility in SDN Fabric.

3. Continue to BGP/OSPF/EVPN/RIB tabs to isolate where baseline behavior diverges.

4.1. SDN Fabric Dashboard

Purpose:

• Provide a single landing view of SDN fabric health and entry points to node-level routing checks.

When to Use:

• Use this first for SDN health checks and before opening BGP, OSPF, EVPN, or RIB on a node.

• Use this when VMs on different hosts cannot communicate and you need an initial baseline.

Dashboard components:

• Top cards: BGP Peers, Total Routes, EVPN VNIs, OSPF Neighbors, BFD Peers, BGP Messages, Session Flaps.

• Routing Nodes table with columns: Node Name, IP Address, Status, AS Number, FRR Version, BGP Peers, OSPF Neighbors, VNIs, Total Routes, BFD Peers.

• Search nodes... field for filtering node rows quickly.

What you can do from this screen:

• Establish a quick baseline for SDN control-plane health from summary cards.

• Identify which node to investigate from table status and routing counters.

• Search for a specific node by name or IP.

• Click a node name to open node details for BGP, OSPF, EVPN, and RIB checks.

• Open page help from the top-right help icon.

Steps:

1. Open Control Center -> Network -> SDN Fabric.

2. Review top summary cards for immediate routing health signals.

3. Review the Routing Nodes table and identify the node to inspect.

4. Optional: use Search nodes... to find a specific node quickly.

5. Optional: click a node name to drill into BGP/OSPF/EVPN/RIB tabs.

Expected Outcome:

• You can identify SDN baseline health and the correct node for deeper troubleshooting.

• You can proceed to help and node-level BGP/OSPF/EVPN/RIB tabs with the right context.

If this fails:

1. Refresh the page and reopen SDN Fabric.

2. Verify your account can access Network observability pages.

3. If Routing Nodes is empty, verify node discovery/registration in your environment.

Node search field:

4.1.1. Open SDN Fabric Help Panel

When to Use:

• Use this after reviewing the SDN dashboard when you need BGP/OSPF/EVPN/RIB and card definitions.

Purpose:

• Open page help separately so users can read guidance before troubleshooting BGP/OSPF/EVPN/RIB tabs.

Steps:

1. Open Control Center -> Network -> SDN Fabric.

2. Click the top-right help icon.

3. Review and search the SDN help panel content.

Expected Outcome:

• SDN Fabric quick-reference guidance opens in the right-side panel.

• You can continue BGP/OSPF/EVPN/RIB checks with field-level context.

If this fails:

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

2. Verify pop-up/panel rendering is not blocked by browser extensions.

3. Confirm access permissions for in-product help content.

4.1.2. Open SDN Node Details Page

When to Use:

• Use this after reviewing SDN summary cards to drill down into one routing node.

Purpose:

• Navigate from the SDN landing page to the selected node’s detailed routing view.

Steps:

1. Open Control Center -> Network -> SDN Fabric.

2. Optional: use Search nodes... to find the required node by name or IP.

3. In the Routing Nodes table, click the target node name.

Expected Outcome:

• SDN node details page opens for the selected node.

• BGP opens by default for the selected node.

• You can access additional tabs: OSPF, EVPN, and RIB.

If this fails:

1. Clear the node search filter and retry from the full node list.

2. Verify the target node row is present in Routing Nodes.

3. Refresh the page and re-open the same node.

4.1.3. BGP, OSPF, EVPN, and RIB: Quick Meanings

Use this quick reference before reviewing BGP/OSPF/EVPN/RIB tabs:

Term	What It Means	Why It Matters Here
BGP	Border Gateway Protocol for route exchange between SDN nodes.	Determines whether nodes are exchanging reachability information.
OSPF	Open Shortest Path First underlay routing service.	Confirms node-to-node path reachability in the fabric underlay.
EVPN	Ethernet VPN control-plane for MAC/IP endpoint advertisement.	Confirms overlay endpoint and segment membership across nodes.
RIB	Routing Information Base (active route table view).	Shows which routes are selected and installed for forwarding.

4.2. BGP Summary

When to Use:

• Use this when validating BGP adjacency and route exchange for one SDN node.

Purpose:

• Confirm whether BGP sessions are established and carrying route updates.

Definition:

• BGP is the control-plane service used to exchange routing information between SDN nodes.

Steps:

1. Open Control Center -> Network -> SDN Fabric.

2. Click a node in Routing Nodes.

3. Confirm the BGP tab is active (default landing tab). If not, click BGP.

Top-card context:

• Node identity (IP)

• Peer count

• ASN/group identifier

Expected Outcome:

• BGP session and counter data is visible for the selected node.

• You can determine whether route exchange is healthy before checking EVPN/RIB.

If this fails:

1. Confirm the selected node is online in Routing Nodes.

2. Reopen node details and retry BGP.

3. Refresh the page and re-check session visibility.

What to check:

Check	Meaning
State = Established	Healthy session and route exchange.
State = Active or Connect	Peer is not reachable or session is blocked.
State = Idle	Session is not progressing to active exchange.
State = OpenSent or OpenConfirm	Session reached negotiation stages but parameters do not fully converge.
Prefixes 0/0	Session is up but no useful route exchange is occurring.
Msgs Rcvd/Sent	Counters should increase over time and not stall.
Uptime	Frequent resets indicate instability.

4.3. OSPF

When to Use:

• Use this when checking underlay routing health between SDN nodes.

Purpose:

• Validate OSPF neighbor state and LSDB freshness before overlay troubleshooting.

Definition:

• OSPF is the underlay routing service used for node-to-node path visibility and adjacency health.

Steps:

1. Open Control Center -> Network -> SDN Fabric.

2. Click a node in Routing Nodes.

3. Click OSPF.

Expected Outcome:

• OSPF views are available for the selected node.

• You can proceed to area, neighbor, and LSDB checks.

If this fails:

1. Confirm node details opened successfully before selecting OSPF.

2. Verify node routing services are active and node status is online.

3. Refresh and retry opening OSPF views.

4.3.1. Review OSPF Areas

When to Use:

• Use this first in OSPF when validating area-level health and adjacency totals.

Purpose:

• Confirm the selected node has healthy OSPF area state before deeper neighbor/LSDB analysis.

Areas view shows:

• Router ID: node routing identity

• Neighbors: adjacency count

• Areas: area summary and full-adjacency counters

Steps:

1. Open Control Center -> Network -> SDN Fabric.

2. Click a node in Routing Nodes.

3. Click OSPF.

4. Review Areas and Full Adjacencies values.

Expected Outcome:

• You can confirm whether OSPF areas are healthy for the selected node.

If this fails:

1. Confirm node status is online in Routing Nodes.

2. Refresh and reopen OSPF.

3. Continue to Neighbors checks to isolate adjacency-level faults.

Areas checks:

Check	Meaning
Areas -> Full Adjacencies	Healthy complete adjacencies for the node.

4.3.2. Review OSPF Neighbors

When to Use:

• Use this when node-to-node adjacency is unstable or underlay reachability is degraded.

Purpose:

• Validate OSPF neighbor-state progression and session stability.

Steps:

1. Open Control Center -> Network -> SDN Fabric.

2. Click a node in Routing Nodes.

3. Click OSPF.

4. Open Neighbors and review state and dead-time values.

Expected Outcome:

• You can identify healthy versus failing OSPF neighbors.

If this fails:

1. Confirm OSPF neighbor data is populated for the selected node.

2. Refresh and reopen Neighbors.

3. Validate MTU consistency when peers remain in ExStart.

Neighbors checks:

Check	Meaning
Neighbors -> State Full/DR	Healthy neighbor relationship.
Neighbors -> State Down	Neighbor is unreachable.
Neighbors -> State Init	One-way communication is present; bidirectional adjacency is not complete.
Neighbors -> State ExStart	indicates MTU mismatch or adjacency negotiation failure.
Neighbors -> Dead Time	Timer should reset repeatedly while adjacency is healthy; sustained drop toward 0 indicates session failure risk.

4.3.3. Review OSPF Link State Database

When to Use:

• Use this when topology visibility appears incomplete or routes are inconsistent across nodes.

Purpose:

• Validate LSDB completeness and freshness for OSPF-learned topology state.

Steps:

1. Open Control Center -> Network -> SDN Fabric.

2. Click a node in Routing Nodes.

3. Click OSPF.

4. Open Link State Database and review router, external, and age values.

Expected Outcome:

• You can confirm LSDB entries are present, current, and aligned with expected topology.

If this fails:

1. Refresh and reopen Link State Database.

2. Compare results with Neighbors state to find adjacency-driven gaps.

3. Re-check affected nodes for missing router/external entries.

LSDB guidance:

• Router entries should include expected fabric nodes.

• External entries represent non-fabric destinations learned through redistribution/policy.

• Stale or missing entries indicate reachability or adjacency issues.

• Age values approaching refresh expiry can indicate stale origin state.

4.4. EVPN

When to Use:

• Use this when checking overlay membership and endpoint advertisement.

Purpose:

• Validate that VNIs and EVPN routes are present for cross-host workload connectivity.

Definition:

• EVPN is the overlay control-plane used to advertise endpoint and segment information.

EVPN means:

• EVPN (Ethernet VPN) is the control-plane that advertises VM endpoint and segment information between nodes.

• VNI (VXLAN Network Identifier) identifies each overlay segment.

• VTEP (VXLAN Tunnel Endpoint) is the node endpoint that encapsulates/decapsulates VXLAN traffic.

• BUM means Broadcast, Unknown-unicast, and Multicast traffic classes.

4.4.1. Review EVPN Routes

When to Use:

• Use this when checking whether endpoint and segment route advertisements are present.

Purpose:

• Validate EVPN route exchange required for cross-host VM connectivity.

Steps:

1. Open Control Center -> Network -> SDN Fabric.

2. Click a node in Routing Nodes.

3. Click EVPN.

4. Review routes, next-hop values, and route-type coverage.

Expected Outcome:

• EVPN routes are visible for the selected node.

• You can confirm whether route advertisements are present for workload segments.

If this fails:

1. Confirm BGP sessions are established for the same node.

2. Refresh and reopen EVPN.

3. Verify target guest networks exist in the environment.

Route types:

• Type 2 (MAC/IP): endpoint advertisement for VM MAC/IP presence.

• Type 3 (IMET): VTEP membership for BUM replication domain.

• Type 5 (IP Prefix): routed prefix advertisement between virtual networks.

Warning

If EVPN routes are missing, cross-host VM communication can fail.

Note

If the EVPN view reports No EVPN routes found, verify that target VNIs/guest networks exist and that BGP peering is established.

4.4.2. Review EVPN VNIs

When to Use:

• Use this when validating overlay-segment membership across nodes.

Purpose:

• Confirm VNI inventory and remote VTEP participation for the selected node.

Steps:

1. Open Control Center -> Network -> SDN Fabric.

2. Click a node in Routing Nodes.

3. Click EVPN.

4. Open VNIs and review VNI rows and counters.

Expected Outcome:

• VNI inventory is visible for the selected node.

• You can confirm whether overlay segments span expected remote VTEPs.

If this fails:

1. Confirm BGP and EVPN route data is visible for the same node.

2. Refresh and reopen the VNIs view.

3. Verify required guest networks/VNIs are created.

VNI checks:

• Num MACs should reflect learned endpoints for active workloads.

• Num Remote VTEPs should be non-zero when the segment spans hosts.

4.5. RIB

When to Use:

• Use this when verifying final route selection and forwarding installation state.

Purpose:

• Confirm whether expected underlay/overlay routes are selected and installed.

Definition:

• RIB is the routing table view that shows selected and installed forwarding routes.

Steps:

1. Open Control Center -> Network -> SDN Fabric.

2. Click a node in Routing Nodes.

3. Click RIB.

Expected Outcome:

• Route sources and install state are visible for the selected node.

• You can confirm whether forwarding uses expected paths.

If this fails:

1. Confirm node details loaded and RIB tab is selectable.

2. Reopen node details and retry.

3. Refresh and repeat the same navigation.

Route source interpretation:

Source	What It Is	Trust Level
kernel	Route created by the operating system	Highest
connected	Directly attached network route	Highest
ospf	Route learned from OSPF neighbors	Medium
bgp	Route learned through BGP	Varies

Install-state checks:

• Selected = Yes and Installed = Yes: active forwarding route.

• Selected = No and Installed = No: alternate or backup route.

• Selected = Yes and Installed = No: unresolved next hop or install issue.

What to look for:

• OSPF-learned routes to remote tunnel endpoint /32 destinations should be present and installed.

4.6. Troubleshooting Flow

When to Use:

• Use this when VMs on different hosts cannot communicate over the SDN fabric.

Purpose:

• Provide a fixed troubleshooting order so control-plane faults are isolated quickly.

Steps:

1. Check BGP Summary: peer state should be Established.

2. Check EVPN: routes and VNIs should be present for target segments.

3. Check RIB: underlay/overlay routes should be selected and installed.

4. Check OSPF: neighbors should be Full.

Additional checks:

• Frequent route/session drops: validate OSPF/underlay stability first.

• OSPF stuck in ExStart: validate MTU consistency between peers.

• No EVPN routes: verify VNIs/guest networks exist and BGP peering is healthy.

Expected Outcome:

• You can identify which routing layer is failing and move directly to targeted remediation.

If this fails:

1. Reopen the affected node in SDN Fabric and repeat checks in the same order.

2. Confirm node status is online and BGP/OSPF/EVPN/RIB tabs are populated.

3. Escalate with captured BGP/OSPF/EVPN/RIB evidence for the failing node.

4.7. Why EVPN-VXLAN

When to Use:

• Use this when you need architecture context before troubleshooting SDN behavior.

Purpose:

• Explain why EVPN-VXLAN is used for scalable, isolated, cross-host VM networking.

Steps:

1. Open Control Center -> Network -> SDN Fabric.

2. Open the SDN help panel.

3. Review the EVPN-VXLAN rationale before tab-level troubleshooting.

Karios uses EVPN-VXLAN because it supports large-scale segmented networking and host-to-host network distribution without relying on limited VLAN-only designs.

Key outcomes:

• Scale: virtual-segment scale beyond the traditional 4094 VLAN limit.

• Efficiency: control-plane exchange reduces unnecessary flooding.

• Performance: available links can be used in parallel.

• Isolation: tenant/workload network separation is maintained.

Expected Outcome:

• You can map SDN symptoms to the right routing layer with the correct EVPN-VXLAN context.

If this fails:

1. Reopen the SDN help panel and review the EVPN-VXLAN explanation.

2. Continue with checks using BGP, OSPF, EVPN, and RIB tabs.

5. Network Topology

Use Network Topology for real-time visibility into physical and virtual network health across compute nodes.

This page combines host-level and fabric-level networking views in one place:

• Dashboard summary cards for overall health and capacity indicators

• Nodes tab for per-node quick status

• Alerts tab for active network issues

• Node detail tabs for Bridges, Interfaces, and VXLANs

Term Definitions:

• MTU: Maximum Transmission Unit, the largest packet size sent without fragmentation.

• Carrier: whether a network link is physically/operationally up.

• RX/TX: received/transmitted traffic counters.

• CRC: Cyclic Redundancy Check error indicator for link/data corruption.

Step: Open Network Topology

When to Use: Use this for initial network-fabric triage and node-level drilldown.

Purpose: Open Network Topology and establish a baseline before reviewing nodes or alerts.

Dashboard shows:

• Summary cards for network health, total interfaces, total bridges, total errors, MTU issues, and total traffic.

• Nodes and Alerts tabs for host-level and issue-level troubleshooting entry points.

• Nodes is the default first view and shows the Host Table immediately on page load.

• Node rows show physical link state, top talker, offloads, anchor bridge, bridge inventory, active VXLAN count, and an action to open details.

What you can do from this screen:

• Start triage from high-level health indicators.

• Switch to Alerts for active issues.

• Open node details for bridges, interfaces, and VXLAN analysis.

Steps:

1. Open Control Center -> Network -> Network Topology.

2. Confirm Nodes is selected (default first view).

3. Review dashboard summary cards.

4. Review the node list shown in the first view.

5. Use Nodes and Alerts tabs for triage.

6. Click a node to open detail tabs.

Expected Outcome:

• You get the Nodes-first dashboard view with summary cards and node list visible.

• You get direct entry points for alert review and node-level troubleshooting.

If this fails:

1. Reload Network Topology and clear any active node search/filter before retrying.

2. Confirm your account can access Network Topology.

3. Confirm networking telemetry is available for your environment.

Step: Open Network Topology Help Panel

When to Use: Use this after opening the Network Topology dashboard when you need definitions for cards, tabs, and alerts.

Purpose: Open page help as a separate step from dashboard review.

Steps:

1. Open Control Center -> Network -> Network Topology.

2. Click the top-right help icon.

3. Review the help panel guidance.

Expected Outcome:

• Network Topology help opens in the right-side panel.

• You can review the complete reference for dashboard cards, node details, and tab-level troubleshooting.

• You can continue dashboard triage with clear 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 Network Topology.

Summary Cards

Card	Description	Click Action	Common Task
Network Health	Overall health percentage across nodes and network objects.	Informational	Monitor overall networking baseline.
Total Interfaces	Count of links up versus total interfaces.	Informational	Investigate when links are down.
Total Bridges	Total Linux bridge count across nodes.	Informational	Validate bridge topology scale.
Total Errors	Cumulative NIC/bridge error count.	Open Alerts tab	Drill into active error conditions.
MTU Issues	Nodes with MTU mismatch/drift conditions.	Informational	Use Alerts tab to identify affected devices.
Total Traffic	Aggregate traffic volume across nodes.	Informational	Capacity and traffic trend review.

Warning

MTU mismatches between bridges and interfaces can cause packet drops and unstable connectivity.

Step: Review Nodes View (Default)

When to Use: Use this to identify which host requires detailed bridge/interface/VXLAN investigation.

Purpose: Review node status and open a specific node for deeper network analysis.

Steps:

1. Open Control Center -> Network -> Network Topology.

2. Stay on the default Nodes view.

3. Review the host list.

4. Review physical link, top talker, offload, bridge, and VXLAN summary fields.

5. Use the row action to open node details.

Expected Outcome:

• You can identify which node requires deeper bridge/interface/VXLAN inspection.

Nodes table:

Column	Description
Node	Host IP or FQDN. Click to open node detail page.
Physical Link	Primary physical link state and interface name.
Top Talker	Highest-traffic interface or bridge on that node.
Offloads	LRO/GRO/TSO status summary.
Anchor Bridge	Primary bridge and MTU shown for the node.
Bridges	L2 bridge membership and MTU status.
Active VXLANs	Number of attached VXLAN interfaces.
Actions	Open node details.

If this fails: 1. Refresh Nodes and clear any active filter. 2. Confirm node inventory is available in your environment. 3. Reopen Network Topology and retry node selection.

Step: Review Alerts Tab

When to Use: Use this when troubleshooting active network faults by severity and category.

Purpose: Review current network alerts and pivot to affected nodes for root-cause analysis.

Steps:

1. In Network Topology, click Alerts.

2. Filter by node when focusing investigation.

3. Open the affected node from the alert row.

4. Verify issue context in node detail tabs.

Expected Outcome:

• You can isolate active network faults by severity/category and pivot directly to the affected node.

If this fails:

1. Reopen the Alerts tab and confirm alert stream data is loading.

2. Confirm alert stream and node inventory are available.

3. Reopen Network Topology and retry Alerts tab.

Network Alerts table:

Severity	Category	Node	Device	Message
Critical/Warning/Info	Link Down, Errors, MTU, MTU Drift	Host where alert occurred	Interface/bridge name	Human-readable issue description

Common alert categories:

• Link Down: interface operational/admin down

• Errors: elevated RX/TX/CRC errors

• MTU: MTU mismatch between connected components

• MTU Drift: inconsistent MTU values on the same node

Node Detail Page

Click any node from Nodes or Alerts to open node details.

The node detail view includes three operational tabs:

• Bridges

• Interfaces

• VXLANs

Bridges Tab

When to Use:

Use this when network issues point to bridge state, bridge membership, carrier loss, or bridge-level errors.

Purpose:

Validate Linux bridge health and identify which bridge/member is causing impact.

Steps:

1. Open Control Center -> Network -> Network Topology.

2. In Nodes, click the target node to open node details.

3. Open the Bridges tab.

4. Review cards and bridge rows for state, MTU, members, carrier, and error indicators.

Expected Outcome:

• You can confirm whether bridge-layer connectivity is healthy.

• You can identify the affected bridge/member for follow-up action.

If this fails:

1. Refresh node details and reopen Bridges.

2. Confirm the node is online in Nodes.

3. Retry from the related Alerts row for the same node.

Use this tab to inspect Linux bridge state, membership, and error counters.

Bridge details page:

Bridge stats cards include:

• Total bridges

• Active

• Inactive/Down

• Total errors

• Most traffic

Bridge row details include:

• Name (for example cloudbr0)

• Layer type and MAC address

• Binding/member interface

• Bridge MTU and TX queue

• Admin, operational, and carrier state

• Flags and member interfaces

• Traffic, error, and drop counters

Interfaces Tab

When to Use:

Use this when you need NIC-level or virtual-interface-level status and packet counters.

Purpose:

Verify interface state, drops, and errors to isolate link or port-level faults.

Steps:

1. Open Control Center -> Network -> Network Topology.

2. In Nodes, click the target node to open node details.

3. Open the Interfaces tab.

4. Review links-up, error, and drop counters and check affected interface rows.

Expected Outcome:

• You can identify which interface is down, noisy, or dropping traffic.

• You can separate interface faults from bridge or overlay faults.

If this fails:

1. Refresh node details and reopen Interfaces.

2. Confirm interface telemetry is available for the node.

3. Cross-check with Alerts for the same node/device.

Use this tab to inspect physical and virtual interface health and counters.

Interface stats cards include:

• Links up

• Packet errors

• Packet drops

• VXLAN tunnels

Interface table fields include:

• Interface

• Layer and type

• Master

• MTU

• TX queue

• Admin, operational, and carrier state

• RX/TX traffic

• State change age

• Hardware details and linked bridge

VXLANs Tab

When to Use:

Use this when overlays are suspected (cross-host VM connectivity, VNI spread, tunnel state).

Purpose:

Validate VXLAN tunnel health and VNI participation on the selected node.

Steps:

1. Open Control Center -> Network -> Network Topology.

2. In Nodes, click the target node to open node details.

3. Open the VXLANs tab.

4. Review tunnel state, VNI values, local/remote endpoint fields, and error/drop counters.

Expected Outcome:

• You can confirm whether VXLAN tunnels are up and VNIs are present as expected.

• You can identify overlay mismatches for targeted SDN follow-up.

If this fails:

1. Refresh node details and reopen VXLANs.

2. Verify the node has active VXLAN interfaces in this environment.

3. Cross-check with SDN Fabric EVPN/VNI views.

Use this tab to inspect overlay tunnels and VNI participation state.

VXLAN stats cards include:

• VXLAN tunnels

• Tunnels up

• Unique VNIs

• Learning off

VXLAN card fields include:

• Name

• VNI

• Local IP

• Group/multicast value

• MTU and TX queue

• Learning state

• Admin and operational state

Common Tasks

• Check network health: start from Network Health, then move to Alerts when degraded.

• Investigate errors: open Total Errors and filter by node/device.

• Inspect a node: open node details and compare Bridges, Interfaces, and VXLANs.

• Find MTU issues: use MTU Issues and Alerts categories MTU or MTU Drift.

• Verify overlay status: in VXLANs, confirm Tunnels Up aligns with expected tunnel count.

6. IPAM

Use IPAM (IP Address Management) to audit IP addresses, VLANs, and DHCP scopes across your environment.

IPAM helps with:

• Address-capacity planning

• Assignment and ownership audit

• VLAN/subnet consistency checks

• DNS and DHCP alignment validation

Term Definitions:

• IPAM: IP Address Management, inventory and lifecycle tracking of IP resources.

• Prefix: subnet in CIDR form (for example 192.168.10.0/24).

• VRF: Virtual Routing and Forwarding instance that isolates routing tables.

• Gateway: default next hop for traffic leaving a subnet.

Step: Open IPAM

When to Use: Use this for IP, VLAN, and DHCP capacity and assignment audits.

Purpose: Open IPAM to baseline address inventory, segmentation, and scope utilization.

Dashboard shows:

• Summary cards for total counts and role-based filters.

• Three operational tabs: IP Addresses, VLANs, and DHCP Scopes.

• Addressing inventory and utilization context across the environment.

What you can do from this screen:

• Audit address ownership and availability.

• Validate VLAN/subnet/gateway consistency.

• Check DHCP scope utilization before deployment.

Steps:

1. Open Control Center -> Network -> IPAM.

2. Review the top summary cards.

3. Switch between IP Addresses, VLANs, and DHCP Scopes tabs.

Expected Outcome:

• You can baseline addressing health, segmentation, and DHCP utilization from one page.

If this fails:

1. Reopen IPAM and return to IP Addresses before retrying tab navigation.

2. Confirm your account can access IPAM.

3. Confirm IPAM data sources are available in your environment.

Step: Open IPAM Help Panel

When to Use: Use this after opening IPAM when you need field and role definitions.

Purpose: Open page help separately from dashboard review.

Steps:

1. Open Control Center -> Network -> IPAM.

2. Click the top-right help icon.

3. Review and search the help panel content.

Expected Outcome:

• IPAM help opens in the right-side panel.

• You can continue tab-level operations with clearer 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 IPAM.

Tabs Overview

When to Use:

Use this before analysis when deciding which IPAM tab matches your goal.

Purpose:

Select the correct tab first so you review the right dataset.

Steps:

1. Open Control Center -> Network -> IPAM.

2. Review available tabs: IP Addresses, VLANs, DHCP Scopes.

3. Select the tab that matches your current task.

Expected Outcome:

• You select the correct tab before filtering or troubleshooting.

If this fails:

1. Refresh IPAM and confirm tabs render correctly.

2. Confirm your account can access all IPAM tabs.

3. Reopen IPAM and retry tab selection.

Tab	What It Shows
IP Addresses	IP records with status, role, device, VLAN, VRF, and gateway.
VLANs	VLAN segments with role, prefix, gateway, DNS zone, and linked DHCP scope.
DHCP Scopes	DHCP subnets with role, VLAN, gateway, and utilization.

Stats Cards (Summary Bar)

When to Use:

Use this to get a quick role-based snapshot before drilling into table rows.

Purpose:

Use card counts and role filters to narrow data quickly.

Steps:

1. Open Control Center -> Network -> IPAM.

2. Stay on the target tab (IP Addresses, VLANs, or DHCP Scopes).

3. Click TOTAL to show all rows.

4. Click a role card (BMC, MANAGEMENT, PUBLIC, STORAGE, GUEST) to filter.

5. Click the same role again or TOTAL to clear filter.

Expected Outcome:

• Card counts provide immediate distribution context.

• Table rows are filtered to the selected role.

If this fails:

1. Clear filters with TOTAL and retry.

2. Refresh the page and reapply the role filter.

3. Confirm role-tagged data exists for the current tab.

At the top of each tab, cards show counts and provide role-based filters.

TOTAL card:

• Meaning: total row count for the current tab.

• Click action: clears role filtering (shows all rows).

Role cards (BMC, MANAGEMENT, PUBLIC, STORAGE, GUEST):

• Meaning: item count for that role category.

• Click action: filter current tab to selected role.

• Click the same role again or click TOTAL to clear filter.

Role guidance:

• BMC: out-of-band management addressing.

• MANAGEMENT: control-plane and host-management addressing.

• PUBLIC: external/public addressing.

• STORAGE: storage-network addressing.

• GUEST: workload/tenant network addressing.

IP Addresses Tab

When to Use

Use this when auditing IP ownership, allocation state, and subnet context.

Purpose

Review IP-level records to identify active, reserved, and available addresses.

Steps

1. Open Control Center -> Network -> IPAM.

2. Click IP Addresses.

3. Optional: apply role filter cards.

4. Review key columns: IP / PREFIX, STATUS, ROLE, DEVICE, VLAN, VRF, GATEWAY.

5. Open row details for deeper assignment context when needed.

Expected Outcome

• You can confirm IP assignment, state, and routing context for affected records.

If this fails

1. Clear role filters by clicking TOTAL.

2. Verify the expected subnet exists in VLANs.

3. Refresh and reopen IP Addresses.

Each row represents one IP address record and its network context.

Table columns:

Column	Meaning
IP / PREFIX	IP address and associated CIDR subnet.
STATUS	Active, Reserved, or Available.
ROLE	Traffic/purpose role of the IP.
DEVICE	Assigned host/device and interface context when allocated.
VLAN	VLAN segment identifier and name.
VRF	Routing instance context.
GATEWAY	Default gateway for the subnet.

How to use:

• Audit active vs available capacity.

• Filter by role cards for targeted views.

• Open row details for full assignment context.

VLANs Tab

When to Use

Use this when validating VLAN segmentation, subnet mapping, and DNS/DHCP linkage.

Purpose

Review VLAN-level design and ensure prefix, gateway, and service mappings are consistent.

Steps

1. Open Control Center -> Network -> IPAM.

2. Click VLANs.

3. Optional: apply role filter cards.

4. Review VID / NAME, ROLE, PREFIX, GATEWAY, DNS ZONE, and DHCP SCOPE.

Expected Outcome

• You can verify VLAN segmentation and associated L3/service mappings.

If this fails

1. Clear role filters with TOTAL.

2. Confirm VLAN inventory is available for the current environment.

3. Refresh and reopen VLANs.

Each row represents one VLAN segment and its L3/DNS/DHCP associations.

Table columns:

Column	Meaning
VID / NAME	VLAN identifier and VLAN name.
STATUS	Operational or reserved state.
ROLE	Traffic role for this VLAN.
PREFIX	Associated CIDR subnet.
GATEWAY	Default gateway for the VLAN subnet.
DNS ZONE	DNS zone associated with this subnet.
DHCP SCOPE	Linked DHCP scope name when DHCP is in use.

How to use:

• Validate segmentation design by role.

• Confirm VLAN prefix and gateway values.

• Verify DNS zone and DHCP scope alignment.

DHCP Scopes Tab

When to Use

Use this before provisioning workloads to check scope utilization and exhaustion risk.

Purpose

Review DHCP capacity and subnet consistency for reliable IP assignment.

Steps

1. Open Control Center -> Network -> IPAM.

2. Click DHCP Scopes.

3. Optional: apply role filter cards.

4. Review PREFIX, VLAN, GATEWAY, and UTILIZATION.

Expected Outcome

• You can identify scopes approaching exhaustion and plan expansion before deployments fail.

If this fails

1. Clear role filters with TOTAL.

2. Confirm DHCP scope data exists for the selected environment.

3. Refresh and reopen DHCP Scopes.

Each row represents a DHCP scope and its subnet utilization.

Table columns:

Column	Meaning
PREFIX	CIDR subnet used for the DHCP scope.
STATUS	Scope state.
ROLE	Traffic role for the scope.
VLAN	VLAN tied to this scope.
GATEWAY	Default gateway for the scope subnet.
UTILIZATION	Used addresses vs total available in scope.

How to use:

• Track utilization to prevent scope exhaustion.

• Confirm subnet/gateway/VLAN consistency.

• Use role filters for targeted capacity review.

Quick Reference

Goal	Where to Go
Audit IP assignments by role	IP Addresses tab + role cards
Review VLAN segments and prefixes	VLANs tab
Prevent DHCP exhaustion	DHCP Scopes tab + UTILIZATION column
Check VLAN DNS/DHCP linkage	VLANs tab (DNS ZONE and DHCP SCOPE columns)

Tips

• Start with TOTAL first, then apply role cards to avoid false conclusions from filtered views.

• Review DHCP Scopes utilization before adding new VM batches.

• Use IP Addresses tab when validating host/VM assignment issues.

Warnings

• DHCP scope utilization near exhaustion can block new VM IP allocation.

• Inconsistent VLAN/PREFIX/GATEWAY values across tabs can indicate configuration drift.

Troubleshooting

• Empty table unexpectedly: clear role filter by clicking TOTAL and verify no search filter is active.

• Expected IP missing: check the correct role card and confirm the subnet exists in VLANs.

• Scope running out of addresses: expand the subnet scope or add a new scope before provisioning more workloads.

7. DNS Analytics

Use DNS Analytics to monitor query volume, response outcomes, top clients/domains, and protocol/query-type distribution over time.

Term Definitions:

• NXDOMAIN: DNS response meaning the queried name does not exist.

• SERVFAIL: DNS server failure while processing a query.

• Authoritative: response served from authoritative zone data.

• DoT: DNS over TLS (encrypted DNS transport).

• DoH: DNS over HTTPS (encrypted DNS transport over HTTPS).

Step: Open DNS Analytics

When to Use: Use this when reviewing DNS traffic trends, error classes, and top sources.

Purpose: Open DNS Analytics to baseline DNS query behavior for the selected time range.

Dashboard shows:

• Query volume trend and outcome cards for the selected time range.

• Donut visualizations for response classes, query types, and protocols.

• Top clients and top domains tables for traffic source analysis.

What you can do from this screen:

• Detect DNS error spikes quickly.

• Identify heavy query sources and domains.

• Compare DNS traffic behavior across time windows.

Steps:

1. Open Control Center -> Network -> DNS Analytics.

2. Set the time range in the header.

3. Review summary cards, trend charts, and top tables.

Expected Outcome:

• You can identify DNS load patterns, error classes, and top query sources for the selected time window.

If this fails:

1. Reopen DNS Analytics and retry with a shorter time range.

2. Confirm your account can access DNS Analytics.

3. Confirm DNS analytics data is available for the selected time range.

Step: Open DNS Analytics Help Panel

When to Use: Use this after opening DNS Analytics when you need metric and chart definitions.

Purpose: Open page help separately from dashboard review.

Steps:

1. Open Control Center -> Network -> DNS Analytics.

2. Click the top-right help icon.

3. Review and search the help panel content.

Expected Outcome:

• DNS Analytics help opens in the right-side panel.

• You can continue dashboard analysis with clear metric definitions.

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 DNS Analytics.

What This Page Shows

• Query-volume trends by time

• Response outcomes (success/failure/NXDOMAIN)

• Query-type mix (A, AAAA, PTR, MX, and others)

• Protocol usage (UDP/TCP/DoT/DoH)

• Top clients and top queried domains

Filters

When to Use

Use this first when the default time window does not match the incident or trend you are investigating.

Purpose

Set one consistent time scope for all cards, charts, and ranking tables.

Steps

1. Open Control Center -> Network -> DNS Analytics.

2. Open the Time range control in the page header.

3. Select Last hour, Last 24 hours, Last 7 days, Last 30 days, or a custom range.

4. Confirm the dashboard refreshes with the selected range.

Expected Outcome

• All DNS Analytics widgets update to the same selected time window.

If this fails

1. Reopen the Time range selector and reapply the window.

2. Refresh the page and set the filter again.

3. Select a broader window to confirm data exists.

Use Time range in the header; changes apply immediately.

Filter	Description
Time range	Last hour, Last 24 hours, Last 7 days, Last 30 days, or custom start/end range.

Stats Cards (Summary Bar)

When to Use

Use this at the start of DNS analysis to get a quick error/success baseline.

Purpose

Use card totals to compare response outcomes and isolate chart series quickly.

Steps

1. Keep the target Time range selected.

2. Review card totals: Total Queries, No Error, Server Failure, NX Domain, Authoritative, Zones.

3. Click a card to show or hide its matching series in Query Volume Over Time.

4. Click again to toggle that series back.

Expected Outcome

• You can quickly identify dominant outcomes and focus the trend chart on specific series.

If this fails

1. Confirm a valid Time range is selected.

2. Refresh the page and retry card toggles.

3. Ensure the selected window has DNS traffic.

Cards show aggregate counts for the selected time window. Click a card to show or hide that series in the query-volume chart.

Card	Meaning
Total Queries	Total DNS queries in selected period.
No Error	Successful responses (RCODE 0).
Server Failure	Server-side failures (RCODE 2).
NX Domain	Name does not exist (RCODE 3).
Authoritative	Responses served from authoritative data.
Zones	DNS-zone count (informational).

Query Volume Over Time

When to Use

Use this when you need to correlate DNS spikes and error bursts over time.

Purpose

Visualize trend direction and compare selected DNS series at each timestamp.

Steps

1. Open Query Volume Over Time.

2. Use Series to control which lines are visible.

3. Optionally use summary-card toggles to hide or show specific series.

4. Hover points on the chart to read exact values at a timestamp.

Expected Outcome

• You can pinpoint when DNS volume or error classes changed.

If this fails

1. Confirm at least one series is selected.

2. Expand the time range to include active traffic.

3. Refresh and reapply chart series selections.

Use this chart to visualize DNS volume and error trends.

• Series selector controls visible metrics.

• Card toggles are linked to chart series visibility.

• Hover to inspect exact values at a timestamp.

Donut Charts

When to Use

Use this when you need distribution view instead of timeline view.

Purpose

Break DNS traffic into response classes, record types, and transport mix.

Steps

1. Review Query Response for success/error distribution.

2. Review Query Type for record-type mix (for example A, AAAA, PTR, MX).

3. Review Protocol for transport usage (UDP, TCP, DoT, DoH).

4. Hover donut segments to read counts and percentages.

Expected Outcome

• You can identify dominant response, type, and protocol distributions for the selected window.

If this fails

1. Confirm the selected time window has DNS query volume.

2. Refresh the page and recheck segment values.

3. Use a wider time range when counts are too low for distribution analysis.

Three donut charts summarize response behavior, query types, and transport protocols.

Chart	Description
Query Response	Distribution of responses (success, NXDOMAIN, SERVFAIL, dropped).
Query Type	Distribution of record types (A, AAAA, PTR, MX, and others).
Protocol	Distribution by transport (UDP, TCP, DoT, DoH).

Query-type interpretation:

• A: IPv4 lookup

• AAAA: IPv6 lookup

• PTR: reverse-DNS lookup

• MX: mail-exchanger lookup

• SOA / SRV / others: zone and service-oriented lookups

Protocol interpretation:

• UDP: default DNS transport

• TCP: fallback/large response transport

• DoT / DoH: encrypted DNS transport

Top Clients and Top Domains

When to Use

Use this after identifying spikes or errors to find who and what generated the most traffic.

Purpose

Identify highest-volume query sources and most-queried domains for targeted follow-up.

Steps

1. Open Top Clients and review the highest-hit sources.

2. Open Top Domains and review the highest-hit domains.

3. Compare both tables together to identify noisy client-domain combinations.

Expected Outcome

• You can isolate heavy clients and domains driving DNS load or error patterns.

If this fails

1. Confirm the selected time range includes active DNS traffic.

2. Refresh and reload the tables.

3. Expand the time range to increase sample size.

Use the two ranking tables to identify heavy query sources and frequently queried domains.

Table	Description
Top Clients	Highest-volume query sources (client, domain, hits).
Top Domains	Most frequently queried domains (domain, hits).

Quick Reference

Goal	Where to Go
Audit DNS query volume and outcomes	Summary cards + Query Volume chart
Identify DNS errors (NXDOMAIN/SERVFAIL)	Query Response chart + related cards
Check query transport mix	Protocol donut chart
Find heavy DNS clients/domains	Top Clients and Top Domains tables

Tips

• Use the Time range filter to scope analysis (Last hour, Last 24 hours, Last 7 days, Last 30 days, or custom range).

• Use card toggles to isolate one error series at a time in Query Volume Over Time.

• Compare Top Clients and Top Domains together to find noisy client-domain pairs quickly.

Warnings

• DNS totals and percentages are time-range dependent. Changing the Time range changes all chart and table values.

• Empty or near-empty charts can mean no traffic in the selected window; verify the selected time range before further analysis.

Troubleshooting

• Chart looks flat or empty: confirm the selected time range includes active DNS traffic.

• High error counts: use Top Clients and Top Domains to identify the highest-hit sources and queried domains.

• Unexpected transport mix: use the Protocol donut chart and hover values to compare UDP/TCP/DoT/DoH distribution in the selected window.

8. VPCs

Use VPCs to create isolated, account-owned virtual networks with multiple subnets, built-in routing, firewall controls, load balancing, and optional VPN connectivity.

Note

Use the ? help icon in the top-right of each VPC page for inline field definitions and quick-reference guidance.

Typical first-time workflow:

1. Create a VPC (section 8.4) — define the zone, name, and IP supernet.

2. Add tiers (section 8.5) — create subnets inside the VPC for each workload layer.

3. Deploy VMs into tiers (section 8.6) — provision instances that receive IPs from tier CIDRs.

4. Acquire a Public IP (section 8.7.1) — pull an IP from the zone pool for inbound access.

5. Add rules — choose Static NAT (8.7.2), Port Forwarding (8.7.3), or Load Balancer (8.8.1) depending on your traffic pattern.

6. Apply Network ACLs (section 8.9) — control which traffic is allowed into or out of each tier.

7. Connect on-premises networks (section 8.10) — optional Site-to-Site VPN or Remote Access VPN.

8.1. What is a VPC?

A VPC (Virtual Private Cloud) is a private virtual network scoped to your account. It gives you:

• Private IP space — a CIDR block you define, fully isolated from other VPCs.

• Multiple subnets (“tiers”) inside it, each with its own CIDR and access policy.

• Built-in router that handles east-west traffic between tiers and north-south traffic to the internet.

• Stateful firewall for ingress and egress controls per tier.

• Load balancers — public (internet-facing) and internal (east-west between tiers).

• Public IP attach with NAT and port-forwarding rules.

• Site-to-Site VPN to connect on-premises networks.

• Remote Access VPN (L2TP / IPsec) for individual users to dial in from their devices.

Think of a VPC as a software-defined private datacenter with everything needed to host a multi-tier application in isolation.

8.2. VPC and Tier Offerings

8.2.1. VPC Offering

The VPC offering is pre-selected at creation. Karios ships one offering:

Name	Type	Description
Karios VPC (NAT’d)	NAT’d + Static routing	The default Karios VPC. Outbound NAT via the VPC router, public IPs attached on demand, public and internal load balancing supported inside.

8.2.2. Tier Offerings

When creating a tier (subnet) inside the VPC, pick one offering based on what that tier serves:

Tier Offering	Best For	What You Get
Karios VPC Tier – Default	Internet-facing tiers (web frontends, APIs)	Public LB, Static NAT, Port Forwarding, VPN, AutoScale
Karios VPC Tier – Hybrid	Tiers that need an internal VIP AND the ability to attach a public IP (bastion, mixed backend)	Internal LB + Static NAT, Port Forwarding, VPN. No Public Load Balancer.
Karios VPC Tier – InternalLB	Pure internal tiers (databases, internal microservices)	Internal LB only — no public IP access by design

Tip

Use the Tier Offering Selection Guide in section 8.12 to choose the right offering for your topology before creating tiers.

8.3. VPC Dashboard

When to Use:

• Use this as the entry point before creating, managing, or troubleshooting VPCs.

Purpose:

• Review existing VPCs, check their state, and access create and detail actions.

Path:

• Control Center -> Network -> VPCs

Dashboard shows:

• Summary cards: Total VPCs, Operational, NAT / public edge, and Routed internal counts.

• VPC table with columns: Name, CIDR, Mode, State, Zone.

• + Add VPC button (top-right) for new VPC creation.

• Per-row state badge — shows current VPC state (Enabled / Disabled).

What you can do from this screen:

• Click + Add VPC to open the create form.

• Click a VPC name to open the VPC detail page.

• Review the VPC state (Enabled / Disabled) and mode (Natted) before making changes.

• Click the top-right ? help icon for inline guidance.

Expected Outcome:

• You can identify existing VPCs, confirm their state, and proceed to create or manage actions.

If this fails:

See Common screen checks before retrying this screen.

8.4. Create a VPC

When to Use:

• Use this when you need a new isolated virtual network for a workload or application group.

Purpose:

• Create a VPC with a defined IP supernet, zone, and offering so tiers and VMs can be placed inside it.

Path:

• Control Center -> Network -> VPCs -> Add VPC

Steps:

1. Open Control Center -> Network -> VPCs.

2. Click + Add VPC. The form opens showing the pre-selected Karios VPC (NAT’d) offering with its included services.

3. Fill in the required fields:

   • Zone — the physical zone where this VPC is hosted.

   • VPC Name — human-readable identifier (for example prod-east).

   • VPC CIDR — the supernet for the VPC (for example 10.0.0.0/16). Tiers will use sub-prefixes from this range.

4. Optional fields:

   • Redundant VPC — toggle on to run the VPC with a redundant router pair for higher availability.

   • Display Text — a friendly description shown in listings.

   • VR size — the router VM size (default: Medium, 2 vCPU / 1024 MB). Increase for high-traffic VPCs.

5. Click Create VPC.

Field guidance:

• VPC CIDR: choose a supernet that does not overlap your on-premises networks if you plan to use Site-to-Site VPN.

• VPC CIDR is immutable after creation — plan the supernet range before creating.

• Zone: a VPC is scoped to one zone. Cross-zone VPCs are not supported in the current release.

Expected Outcome:

• The VPC appears in the VPCs table with state Enabled.

• The VPC router is created automatically.

• The VPC’s CIDR is registered in IPAM automatically.

• You can proceed to add tiers.

Clicking the VPC name opens the detail page:

VPC detail page header badges (top-right):

• NATTED — the VPC offering type.

• Static — VPN/routing mode indicator.

• Enabled — current VPC state.

VPC detail page tabs:

• Overview — VPC summary, platform capabilities, public IPs at a glance, and a built-in 4-step quickstart guide.

• Tiers — create and manage subnets inside the VPC.

• ACL Lists — create and attach Network ACL lists to tiers.

• Load Balancers — view, add, and manage both Public and Internal load balancer rules.

• Routers — view VPC router state, health, public IP, and redundancy role.

• VPN Gateways — register remote on-premises VPN customer gateways.

• VPN Connections — create and manage Site-to-Site VPN tunnels.

• VMs — list all VMs deployed across all tiers in this VPC.

• Remote Access — enable and manage the Remote Access VPN endpoint.

• LB SSL Certs — upload and manage SSL certificates for TLS termination on Public LB rules.

The Routers tab confirms the VPC router was created automatically:

The Routers tab shows: router name, state, version, health, public IP, guest network, HA pair, and redundant role. This view is read-only — use it to verify the router is Running and OK before adding rules.

If this fails:

1. Confirm required fields are complete.

2. Confirm the CIDR does not overlap an existing VPC in the same zone.

3. Verify your account has permission to create VPCs in the selected zone.

Warning

VPC CIDR cannot be changed after creation. Choose the supernet carefully at create time.

8.5. Add a Tier

When to Use:

• Use this to add a subnet inside an existing VPC for a specific workload tier.

Purpose:

• Create a tier with the correct offering and CIDR so VMs in that tier get the right networking behavior.

Path:

• Control Center -> Network -> VPCs -> [VPC name] -> Tiers tab -> Create Tier

Steps:

1. Open Control Center -> Network -> VPCs.

2. Click the target VPC name.

3. Click the Tiers tab.

4. Click Create Tier (top-right).

5. Fill in the required fields:

   • Tier Offering — Default, Hybrid, or InternalLB (see section 8.2.2).

   • Tier Name — for example web, app, or db.

   • CIDR — a sub-prefix of the VPC’s CIDR (for example 10.20.1.0/24).

   • Gateway — typically the first address of the subnet (for example 10.20.1.1).

   • Netmask — subnet mask (for example 255.255.255.0 for a /24).

6. Click Create.

Tiers tab columns and actions:

• Table columns: Name, CIDR, VLAN (auto-assigned), Status, ACL (attached ACL list name).

• Tier status shows Setup while the tier is being provisioned — this is normal and resolves automatically.

• Top-right buttons: Create Tier to add another subnet; Create VM to deploy a VM directly into a tier from this tab.

• Per-tier row actions:

  • Edit (pencil icon) — update the tier name or ACL.

  • Delete (trash icon) — remove the tier. The tier must have no VMs before it can be deleted.

  • Add (+ Add button) — attach or change the ACL list assigned to that tier.

Field guidance:

• CIDR: must be inside the VPC supernet and must not overlap any existing tier.

• A VPC supports up to 3 tiers by default.

• Typical pattern: web (Default), app (Hybrid or InternalLB), db (InternalLB).

Expected Outcome:

• The tier appears under the Tiers tab with the selected offering and CIDR.

• VMs can now be deployed into this tier.

If this fails:

1. Confirm the tier CIDR is within the VPC supernet and does not overlap an existing tier — the error message will name the conflict.

2. Confirm required fields are complete and valid.

3. Verify your account has permission to modify the selected VPC.

8.6. Deploy a VM into a Tier

When to Use:

• Use this when you are ready to place a VM inside a VPC tier.

Purpose:

• Provision a VM that receives an IP from the selected tier’s CIDR and uses the VPC router for outbound traffic.

Steps:

1. Open the VPC detail page, click the Tiers tab, and click Create VM (top-right), or go to Control Center -> Compute -> VMs and click Create VM — then select the VPC tier from the Network field in the form.

2. In the Provision Virtual Machine form, fill in the required fields. In the Network field, select the target VPC tier.

3. Click Provision VM.

What the VM gets:

• An IP from the tier’s CIDR (auto-assigned, or you can pin a specific address).

• A NIC attached to the VPC router.

• Outbound internet access via the VPC router’s Source NAT — no public IP required for outbound-only traffic.

Expected Outcome:

• The VM appears in the VMs tab of the VPC with a private IP from the tier’s CIDR and state Running.

• The VM can reach the internet outbound via Source NAT without needing a public IP.

If this fails:

1. Confirm the selected tier exists and is in state Active.

2. Confirm the VM template and service offering are available in the zone.

3. Check the Events log for provisioning errors.

See also

For full VM creation steps, use Compute - Virtual Machines.

8.7. Public IPs

Public IPs give VMs in internet-facing tiers inbound connectivity via the VPC router. A public IP is VPC-scoped — it is not assigned to a tier until you create the first rule on it (Static NAT, Port Forwarding, or Load Balancer).

8.7.1. Acquire a Public IP

When to Use:

• Use this when a tier needs a public IP for inbound access (Static NAT, Port Forwarding, or Load Balancer).

Purpose:

• Pull a public IP from the zone pool and attach it to the VPC so you can create rules on it.

Path:

• Control Center -> Network -> VPCs -> [VPC name] -> Overview tab -> Public IPs section

Steps:

1. Open the VPC detail page. The Overview tab shows the Public IPs section at the bottom, listing all IPs currently acquired for this VPC.

2. Click Acquire (top-right of the Public IPs section).

3. Confirm the zone in the dialog and click OK.

Expected Outcome:

• The new IP appears in the Public IPs section with no rules attached yet.

• Click the IP address or Add rules to open its detail page and create rules (Static NAT, Port Forwarding, or Load Balancer).

Note

Changes propagate to the VPC router within approximately 30 seconds after a rule is added.

If this fails:

1. Confirm public IPs are available in the zone’s public pool.

2. Confirm your account has permission to acquire public IPs.

3. Refresh the Public IPs tab and retry.

8.7.2. Static NAT

When to Use:

• Use this when one VM needs its own dedicated public IP — for example, a bastion host or a single-server service.

Purpose:

• Create a 1-to-1 mapping between a public IP and one VM so all inbound traffic to that IP goes directly to that VM.

Path:

• Control Center -> Network -> VPCs -> [VPC name] -> Overview tab -> Public IPs section -> [IP address] -> Static NAT

Steps:

1. In the Public IPs section on the Overview tab, click the target IP address to open its detail page.

2. Click Static NAT.

3. Select the target tier from the dropdown — only tiers with eligible VMs are shown.

4. Select the target VM.

5. Click OK to enable.

Expected Outcome:

• The public IP detail page shows Static NAT as Enabled with the selected VM listed.

• All inbound traffic to the public IP is forwarded to that VM on all ports.

• The VM can also send outbound traffic through this public IP.

If this fails:

1. Confirm the target VM is in a Default or Hybrid tier — InternalLB tiers do not support Static NAT.

2. Confirm the selected public IP does not already have a Port Forwarding or Load Balancer rule — a public IP can only be bound to one rule type.

8.7.3. Port Forwarding

When to Use:

• Use this when one public IP needs to serve multiple VMs on different ports — for example, port 22 goes to a bastion, port 80 goes to a web VM.

Purpose:

• Map specific public port ranges on a public IP to specific VMs and ports.

Path:

• Control Center -> Network -> VPCs -> [VPC name] -> Overview tab -> Public IPs section -> [IP address] -> Port Forwarding

Steps:

1. In the Public IPs section on the Overview tab, click the target IP address to open its detail page.

2. Click Port Forwarding.

3. Click Add Port Forwarding Rule and fill in:

   • Public Start/End Port — the port range exposed on the public IP.

   • Protocol — TCP or UDP.

   • Private Start/End Port — the corresponding port range on the target VM.

   • Target VM — select from the tier.

4. Click OK to save the rule.

Expected Outcome:

• The rule appears in the Port Forwarding list.

• Traffic arriving on the public IP at the specified port is forwarded to the target VM’s private port.

• Multiple rules can be added on the same public IP for different VMs or ports.

If this fails:

1. Confirm the target tier is Default or Hybrid — InternalLB tiers do not support Port Forwarding.

2. Confirm the port range does not conflict with an existing rule on the same public IP.

8.8. Load Balancing

8.8.1. Public Load Balancer

When to Use:

• Use this when you need to distribute internet traffic across multiple VMs in a Default tier.

Purpose:

• Create an internet-facing load balancer rule on a public IP, targeting a pool of VMs in the tier.

Path:

• Control Center -> Network -> VPCs -> [VPC name] -> Load Balancers tab

The Load Balancers tab shows a summary bar (Total Rules, Backends, Public IPs, Internal VIPs, Tiers) and lists Public Load Balancers and Internal Load Balancers in separate sections.

Steps:

1. Open the VPC detail page and click the Load Balancers tab.

2. In the Public Load Balancers section, click + Add Public LB.

3. Configure the rule:

   • Name

   • Public Port

   • Private Port

   • Algorithm — Round Robin, Least Connections, or Source IP Hash.

   • Protocol — use ssl for TLS termination at the load balancer; use tcp for passthrough.

4. Click OK to save the rule, then open the rule and click Attach VMs on the Members tab to add backend VMs from the selected tier.

Load balancer rules list:

Rule configuration — port, protocol, and algorithm:

Backend members — VMs added to the pool:

Optional settings:

• Stickiness — session affinity to keep a client on the same backend VM. Click Update in the Stickiness column of the Listeners section to configure.

• SSL termination — terminate HTTPS at the load balancer by attaching a certificate. See below.

• Multiple listeners — multiple port rules can be added to the same LB rule via the Listeners section.

SSL certificate workflow:

SSL certificates are managed at the VPC level on the LB SSL Certs tab, then attached to individual LB rules.

To upload a certificate:

1. Open the VPC detail page and click the LB SSL Certs tab.

2. Click + Upload SSL Certificate.

3. Fill in the fields:

   • Name — a label for this certificate (for example wildcard-prod-2026).

   • Certificate (PEM) — paste the full certificate in PEM format.

   • Private key (PEM) — paste the private key. The key is write-only and never returned after upload.

   • Certificate chain (PEM, optional) — paste concatenated intermediate certificates, root last.

4. Click Upload.

To attach the certificate to an LB rule:

1. Open the LB rule from the Load Balancers tab.

2. In the SSL certificate section on the rule’s Overview tab, click Attach cert.

3. Select the uploaded certificate from the list.

Expected Outcome:

• Inbound traffic to the public IP on the configured port is distributed across the backend VM pool.

If this fails:

1. Confirm the tier is Default — Public LB is not available on InternalLB tiers.

2. Confirm VMs are running and are in the same tier as the LB rule.

3. Confirm the public IP is not already bound to a Static NAT rule.

Note

If the LB rule is created but not reachable, confirm the public IP is bound by checking that at least one rule exists on it. Changes propagate within approximately 30 seconds.

8.8.2. Internal Load Balancer

When to Use:

• Use this when backend services need a VIP for service-to-service traffic within the VPC (not internet-facing).

Purpose:

• Create an internal-only VIP on a Hybrid or InternalLB tier so services can reach a stable address regardless of which VM handles traffic.

Path:

• Control Center -> Network -> VPCs -> [VPC name] -> Load Balancers tab

Steps:

1. Open the VPC detail page and click the Load Balancers tab.

2. In the Internal Load Balancers section, click + Add Internal LB.

3. Fill in the rule fields:

   • Name — a label for this internal LB rule.

   • Source IP — the internal VIP address that other VMs will connect to.

   • Source Port — the port exposed on the VIP.

   • Instance Port — the port on the backend VMs.

   • Algorithm — Round Robin, Least Connections, or Source IP Hash.

   • Protocol — TCP or UDP.

4. Click OK to save the rule, then open the rule and click Attach VMs to add backend VMs from the same tier to the pool.

Expected Outcome:

• The internal LB rule appears in the tier’s Internal LB list with the configured VIP and port.

• VMs in the VPC can reach the VIP address and traffic is distributed across the backend pool.

If this fails:

1. Confirm the tier offering is Hybrid or InternalLB — Default tiers do not support Internal LB.

2. Confirm the backend VMs are running and in the same tier as the rule.

3. Confirm the Source IP is within the tier’s CIDR range.

8.9. Network ACLs

When to Use:

• Use this to control which traffic is allowed into or out of a tier.

Purpose:

• Apply ingress and egress rules at the tier level to enforce security policy. Tiers without an explicit allow rule deny all ingress by default.

Path:

• Control Center -> Network -> VPCs -> [VPC name] -> ACL Lists tab

Steps:

1. Open the VPC detail page and click the ACL Lists tab. The tab shows all ACL lists for this VPC, including two built-in lists: default_allow (allow all) and default_deny (deny all). These cannot be deleted.

2. Click + Create ACL List, give it a name (for example web-tier-acl), and click OK.

3. Click the ACL list name to open it, then click + Add Rule to add each rule:

   • Action — Allow or Deny.

   • Direction — Ingress (inbound to tier) or Egress (outbound from tier).

   • Protocol — TCP, UDP, ICMP, or All.

   • Ports — port or port range (for TCP/UDP rules).

   • Source CIDR — the IP range the rule applies to.

   • ICMP T/C — ICMP type and code (for ICMP rules only).

   • Reason — optional label for this rule.

4. After adding rules, go back to the Tiers tab. In the target tier row, click the + Add button and select the ACL list to attach it.

ACL Lists tab row actions:

• Edit (pencil icon) — rename the ACL list.

• Delete (trash icon) — remove the ACL list. Built-in lists (default_allow, default_deny) cannot be deleted.

• Remove — detach the ACL list from a tier (shown in the Attached tiers column).

Key behavior:

• ACL lists are reusable — one list can be attached to multiple tiers.

• Different tiers can have different ACL lists (different security postures per tier).

• Default behavior is deny-all ingress until an explicit allow rule is added.

• Rules are evaluated in order — first match wins.

Expected Outcome:

• The tier accepts or rejects traffic according to the ACL rules in the attached list.

If this fails:

1. Confirm the ACL list is attached to the correct tier.

2. Review rule order — a deny rule earlier in the list blocks traffic before a later allow rule is evaluated.

3. Confirm the protocol, port range, and CIDR in the rule match the expected traffic.

8.10. Site-to-Site VPN

When to Use:

• Use this to connect an on-premises network to the VPC so on-premises hosts can communicate with VMs in VPC tiers.

Purpose:

• Create an encrypted tunnel between the VPC and an on-premises firewall or VPN device.

Site-to-Site VPN uses two separate tabs — VPN Gateways and VPN Connections. Complete them in order.

Step 1 — Add a VPN Gateway

Path: Control Center -> Network -> VPCs -> [VPC name] -> VPN Gateways tab

1. Open the VPC detail page and click the VPN Gateways tab. The tab shows the VPC’s public IP — this is the Karios side of the tunnel.

2. Click Create VPN Gateway if one does not already exist.

Step 2 — Add a Customer Gateway and Connection

Path: Control Center -> Network -> VPCs -> [VPC name] -> VPN Connections tab

1. Click the VPN Connections tab.

2. In the Customer gateways (peers) section, click Add Customer Gateway.

3. Fill in the remote on-premises endpoint details (public IP and remote CIDR).

4. Click Add Connection to create the tunnel between the VPC gateway and the customer gateway.

5. Confirm the tunnel state in the S2S VPN connections section.

Expected Outcome:

• The S2S VPN connection appears in the list with an active state.

• On-premises hosts can reach VMs in the VPC tiers over the tunnel.

If this fails:

1. Confirm the customer gateway public IP and remote CIDR are correct.

2. Confirm the VPC CIDR does not overlap the on-premises network CIDR.

3. Review the connection status for negotiation errors — the status field shows the current phase.

8.10.1. Remote Access VPN (L2TP / IPsec)

When to Use:

• Use this when individual users need to dial in to the VPC from their device — not for connecting entire on-premises networks (use Site-to-Site VPN for that).

Purpose:

• Enable a per-user L2TP/IPsec VPN endpoint on the VPC so remote users can reach VMs inside the VPC.

Compatible clients: macOS, Windows, iOS, Android, strongSwan / xl2tpd on Linux — all using the native L2TP/IPsec VPN client built into the OS.

Path:

• Control Center -> Network -> VPCs -> [VPC name] -> Remote Access tab

Prerequisite:

• The VPC must have a Source NAT public IP already acquired. The Remote Access endpoint is bound to this IP. If no source NAT IP exists, acquire one first from the Public IPs tab — the Enable RAS button will be unavailable until this is done.

Steps — Enable the RAS server:

1. Open the VPC detail page and click the Remote Access tab.

2. In the RAS server section, click Enable RAS.

3. Note the public IP and the auto-generated pre-shared key (PSK) that appear after enabling.

Steps — Add dial-in users:

1. In the Dial-in users section, click Add user.

2. Enter the username and password for the user.

3. Share the public IP, PSK, username, and password with the user so they can configure their VPN client.

Expected Outcome:

• RAS server section shows the VPN as enabled with the public IP and PSK.

• Dial-in users section lists added users with state Active.

• Users can connect using the L2TP/IPsec client on their device with the public IP, PSK, and their credentials.

If this fails:

1. Confirm the VPC has a Source NAT public IP — the Enable RAS button is unavailable without one.

2. Confirm the VPC router is in state Running (check the Routers tab).

3. If a user cannot connect: verify the public IP, PSK, and credentials are correct. If a Site-to-Site customer gateway already uses the user’s IP as its gateway, remove the conflicting gateway first.

8.11. AutoScale

When to Use:

• Use this when a public-facing tier needs to automatically add or remove VMs based on load.

Purpose:

• Attach an AutoScale VM group to a Public Load Balancer rule on a Default tier so VM count adjusts automatically.

Requirements:

• Tier must use the Karios VPC Tier – Default offering.

• A Public Load Balancer rule must already exist on the tier.

Steps:

1. Open the Public Load Balancer rule on a Default tier.

2. Click Attach AutoScale VM Group.

3. Configure:

   • Min and max VM instance counts.

   • Scale-up and scale-down policies (CPU or memory thresholds).

   • VM template and service offering for new instances.

4. Save the AutoScale group.

Expected Outcome:

• New VMs are provisioned automatically when scale-up conditions are met and removed when scale-down conditions are met.

If this fails:

1. Confirm the tier is Default — the Attach VM Group option is not available on Hybrid or InternalLB tiers.

2. Confirm a Public Load Balancer rule exists before attaching the AutoScale group.

8.12. Tier Offering Selection Guide

Use this guide to choose the correct tier offering before creating tiers:

Does this tier need a public IP (LB / Static NAT / Port Forwarding)?
├── Yes → Does it ALSO need an internal VIP for service-to-service traffic?
│   ├── Yes → Hybrid
│   └── No  → Default
└── No  → InternalLB

Examples:

Topology	Tier Pattern
3-tier web application	web = Default, app = InternalLB, db = InternalLB
App with public bastion and private database	bastion = Default, db = InternalLB
Mixed-mode tier (jumphost + internal service VIP)	Hybrid

8.13. Current Release Limitations

Feature	Status
Routed (BGP) mode VPCs	Not supported. Only NAT’d mode is available.
IPv6	Not supported. IPv4 only.
Cross-zone VPCs	Not supported. One VPC lives in one zone.
VPC peering	Not supported in current release. On the roadmap.
CIDR resize after creation	Not supported. Plan the supernet at create time.

8.14. Troubleshooting

Symptom	First Place to Check
Tier create rejected	Tier CIDR overlaps an existing tier or is outside the VPC supernet. The error message names the conflict.
VM in tier cannot reach the internet	Confirm the tier offering. InternalLB tiers have no outbound NAT by design.
Public LB rule created but not reachable	The public IP must have at least one rule bound to a tier. Wait up to 30 seconds for propagation after adding the rule.
Attach VM Group button is not available	AutoScale requires a Default tier. Hybrid and InternalLB tiers do not support AutoScale.
LB listener on port 443 but TLS is not terminating at the load balancer	tcp protocol is passthrough; ssl terminates TLS at the load balancer. Recreate the rule with protocol ssl and attach a certificate.

Quick Links

Use these quick navigation links:

• Traffic Types for Management/Storage/Public/Guest traffic operations.

• Network States for Allocated/Implementing/Setup behavior.

• Create Guest Network for isolated/shared network creation fields.

• SDN Fabric for routing observability (OSPF/BGP/EVPN/RIB).

• Network Topology for dashboard, node, alert, and tab-level network health checks.

• IPAM for IP, VLAN, and DHCP scope audit/capacity visibility.

• DNS Analytics for DNS volume, response, client/domain, and protocol visibility.

• Bridges for bridge-member and traffic/error visibility in node details.

• Interfaces for NIC-level health and counters in node details.

• VPCs for isolated virtual networks, tiers, public IPs, load balancing, ACLs, and VPN.

• VPC Tier Selection Guide for choosing Default, Hybrid, or InternalLB tier offerings.

---

→ Next: Storage