Skip to content

Architecture

STACKIT Core Networking provides a comprehensive, layered architecture that enables secure, scalable, and flexible cloud networking. Understanding how these components work together helps you design efficient network topologies and troubleshoot connectivity issues.

Core Networking is built on software-defined networking (SDN) principles, separating the control plane from the data plane. This architecture provides:

  • Virtual network isolation through network virtualization
  • Flexible routing with dynamic route management
  • Distributed security enforcement at multiple layers
  • Scalable design that grows with your requirements
  • API-driven management for automation and infrastructure as code

The architecture consists of several interconnected layers, each providing specific functionality while working together as a cohesive system.

At the highest level, each STACKIT project serves as an organizational and security boundary. Projects contain:

  • One or more Virtual Networks with independent IP address spaces
  • A project router that manages traffic between networks and to external destinations
  • Security policies that apply to all resources within the project
  • Resource quotas that control the number of networks, IPs, and NICs

Projects are isolated from each other by default. Cross-project communication requires explicit configuration through STACKIT Network Area (SNA) or public IP connectivity.

Within a project, Virtual Networks provide the fundamental isolation and connectivity layer:

  • CIDR block definition specifying the IP address range (e.g., 10.0.0.0/16)
  • Subnet capability for logical segmentation (implementation varies by region)
  • Routing tables managed automatically by STACKIT
  • DNS configuration pointing to STACKIT DNS Resolvers
  • Connection to project router for inter-network and external traffic

Each Virtual Network operates as an isolated layer-2 broadcast domain. Resources within the same network can communicate directly, while traffic to other networks flows through the project router.

Network Interfaces (NICs) connect compute resources to Virtual Networks:

  • One primary NIC required for each server
  • Up to 4 additional NICs for multi-homed configurations
  • Fixed IPv4 address assigned from the network’s CIDR block
  • MAC address automatically assigned
  • Security Group associations for traffic filtering

NICs act as the enforcement point for network security policies, applying Security Group rules to all traffic passing through them.

Virtual Networks are implemented using network virtualization technology that creates isolated layer-2 segments:

  1. Overlay networking encapsulates tenant traffic in a virtualized network layer
  2. Virtual switching within hypervisors handles local traffic efficiently
  3. Tunneling protocols carry traffic between physical hosts
  4. Distributed routing enables high-performance inter-network communication

This design ensures:

  • Complete isolation between customer networks
  • No MAC or IP address conflicts between projects
  • Optimal performance through local traffic handling
  • Scalability without physical network limitations

Each project has a virtual router that serves as the gateway for:

Internal traffic:

  • Routing between multiple Virtual Networks in the same project
  • Route advertisement and learning for connected networks
  • Next-hop determination for outbound traffic

External traffic:

  • NAT for outbound internet access (Router IP)
  • Floating IP management for inbound connections
  • Default route to external networks

The project router automatically maintains routing tables as you create, modify, or delete Virtual Networks. You don’t need to manually configure routes for standard scenarios.

Security Groups operate as distributed, stateful firewalls implemented at the hypervisor level:

Rule evaluation:

  1. When traffic arrives at a NIC, Security Group rules are evaluated
  2. Rules are processed in priority order
  3. First matching rule determines the action (allow or deny)
  4. If no rules match, default policy applies (deny ingress, allow egress)

State tracking:

  • Allowed connections are tracked in a connection table
  • Return traffic for established connections bypasses rule evaluation
  • Connection tracking operates at the flow level (5-tuple: protocol, source IP/port, destination IP/port)

Performance optimization:

  • Rules are compiled into efficient data structures
  • Evaluation occurs in kernel space for minimal latency
  • Changes propagate to affected NICs within seconds

Public IP connectivity uses a hierarchical NAT architecture:

When you assign a Floating IP to a NIC:

  1. The public IP is reserved in STACKIT’s public address pool
  2. A 1:1 NAT mapping is created between the public and private IP
  3. The NAT translation occurs at the network edge, before traffic reaches your project
  4. Inbound traffic to the public IP is translated and forwarded to the NIC
  5. Outbound traffic from the NIC is source-translated to the public IP

Router IP provides shared outbound connectivity:

  1. When any VM in the project has a Floating IP, the project router becomes externally reachable
  2. The router advertises itself as the default gateway to all VMs
  3. Outbound traffic from VMs without Floating IPs flows through the router
  4. The router performs source NAT (SNAT) using its own public IP
  5. Multiple concurrent connections are tracked using port translation

NICs bridge the gap between compute resources and Virtual Networks:

Attachment process:

  1. NIC is created with an IP address from the target network
  2. NIC is associated with Security Groups
  3. NIC is attached to a server (at creation or later)
  4. Server’s hypervisor configures the virtual network interface
  5. Guest OS detects the new interface (may require OS configuration)

Traffic flow:

  • Outbound: Server → Virtual NIC → Security Groups → Virtual Switch → Network
  • Inbound: Network → Virtual Switch → Security Groups → Virtual NIC → Server

NIC Security features:

  • Anti-spoofing: Drops packets with mismatched source IP/MAC
  • Allowed addresses: Permits specific additional addresses for routing scenarios
  • DHCP protection: Prevents unauthorized DHCP servers
  • Port security: Enforces MAC address limits

SNA extends the networking architecture to enable cross-project connectivity:

Transfer network:

  • A dedicated virtual network shared by all SNA member projects
  • Automatically configured IP addressing
  • Optimized routing between projects
  • Regional scope (per-region deployment)

Project integration:

  • Each member project’s router connects to the transfer network
  • Routes to other project networks are automatically exchanged
  • Security Groups continue to control inter-project traffic
  • No manual route configuration required

When resources in different SNA projects communicate:

  1. Source VM sends traffic to destination IP
  2. Source project router recognizes the destination is in another SNA project
  3. Traffic is routed through the SNA transfer network
  4. Destination project router receives the traffic
  5. Traffic is delivered to the destination VM’s network
  6. Security Groups on the destination NIC evaluate the traffic

This architecture enables direct, low-latency communication between projects without traversing the public internet.

The DNS Resolver service provides hierarchical name resolution:

Caching layer:

  • High-performance cache stores recent query results
  • TTL-based expiration ensures data freshness
  • Cache warming for frequently accessed domains
  • Query deduplication prevents redundant external lookups

Recursive resolution:

  • Multi-tier query system (root → TLD → authoritative)
  • Parallel queries for improved performance
  • Fallback mechanisms for reliability
  • DNSSEC validation support

Integration:

  • Virtual Networks are pre-configured with STACKIT DNS Resolver IPs
  • DHCP automatically provides DNS configuration to VMs
  • Private DNS zones can be integrated (where supported)
VM A (10.0.1.10) → VM B (10.0.1.20)
└─ Direct communication within Virtual Network
└─ Security Groups on VM B's NIC evaluate incoming traffic
└─ If allowed, traffic reaches VM B

This is the most efficient path—traffic never leaves the Virtual Network.

Scenario 2: VM to VM in Different Networks (Same Project)

Section titled “Scenario 2: VM to VM in Different Networks (Same Project)”
VM A (10.0.1.10) → VM C (10.0.2.10)
└─ Traffic sent to default gateway (project router)
└─ Router forwards to destination network (10.0.2.0/24)
└─ Security Groups on VM C's NIC evaluate traffic
└─ If allowed, traffic reaches VM C

The project router handles inter-network routing automatically.

VM with Floating IP (private: 10.0.1.10, public: 203.0.113.5) → Internet
└─ VM sends outbound traffic with source 10.0.1.10
└─ Security Groups evaluate outbound traffic
└─ Project router performs SNAT: 10.0.1.10 → 203.0.113.5
└─ Traffic exits to internet with public source IP
Internet → Floating IP (203.0.113.5)
└─ Edge router performs DNAT: 203.0.113.5 → 10.0.1.10
└─ Project router forwards to destination network
└─ Security Groups evaluate incoming traffic
└─ If allowed, traffic reaches VM

Scenario 5: VM to Internet (Router IP only)

Section titled “Scenario 5: VM to Internet (Router IP only)”
VM without Floating IP (10.0.1.10) → Internet
└─ VM sends to default gateway (project router)
└─ Router performs SNAT using Router IP (203.0.113.100)
└─ Traffic exits to internet with shared source IP

Note: Inbound connections are not possible in this scenario.

Project A VM (10.0.1.10) → Project B VM (10.1.1.10)
└─ Project A router routes via SNA transfer network
└─ SNA transfer network forwards to Project B
└─ Project B router delivers to destination network
└─ Security Groups on destination evaluate traffic
└─ If allowed, traffic reaches destination

Core Networking scales horizontally to handle growing workloads:

  • Network virtualization eliminates physical network constraints
  • Distributed routing avoids central bottlenecks
  • Hypervisor-based switching scales with compute resources
  • Regional deployment distributes load across infrastructure

Latency:

  • Intra-network: < 1ms typical
  • Inter-network (same project): < 2ms typical
  • Cross-project via SNA: < 3ms typical
  • Internet via public IP: variable based on destination

Throughput:

  • Limited by VM instance type, not network infrastructure
  • Full line-rate performance for most instance sizes
  • No oversubscription on backbone networks

Packet processing:

  • Hardware offloading where available
  • Optimized virtual switching in hypervisors
  • Minimal overhead for Security Group evaluation
  • Multi-path networking within infrastructure
  • Redundant routers for external connectivity
  • Distributed DNS resolvers for reliability
  • No single points of failure in the control plane
  • Automatic failover for infrastructure failures
  • Connection preservation during failover events
  • Rapid convergence after topology changes
  • Health monitoring of all networking components

You can manage Core Networking resources through:

  • STACKIT Portal – Web-based graphical interface
  • STACKIT CLI – Command-line tool for automation
  • STACKIT API – REST APIs for programmatic access
  • Terraform Provider – Infrastructure as Code support
  • Cloud Foundry – Platform-level integration

All management operations go through the control plane, which:

  1. Validates requests and authorization
  2. Updates the configuration database
  3. Pushes changes to affected infrastructure components
  4. Confirms successful application
  5. Returns status to the caller

Core Networking integrates with STACKIT’s observability platform:

  • Metrics: Traffic volume, packet rates, error rates
  • Logs: Configuration changes, security events, connectivity issues
  • Traces: End-to-end visibility for troubleshooting

Core Networking implements multiple security layers:

  1. Physical isolation of tenant networks
  2. Virtualization-level isolation preventing cross-tenant access
  3. Network-level security via Security Groups
  4. Host-level security with NIC Security features
  5. Application-level security (customer responsibility)
  • Encryption in transit for management operations
  • Network segmentation for compliance boundaries
  • Audit logging of all configuration changes
  • Access controls via STACKIT IAM integration
  1. Plan IP address space carefully

    • Choose CIDR blocks that accommodate growth
    • Avoid conflicts if using SNA or hybrid connectivity
    • Document network allocations
  2. Apply least-privilege security

    • Start with deny-all Security Groups
    • Add only necessary rules
    • Use separate Security Groups for different roles
  3. Implement network segmentation

    • Separate tiers (web, app, database) into different networks
    • Use Security Groups for fine-grained control
    • Consider SNA for cross-project segmentation
  4. Optimize for performance

    • Keep frequently communicating resources in the same network
    • Use multiple NICs for high-throughput workloads
    • Monitor and tune Security Group rules
  5. Design for high availability

    • Distribute resources across availability zones where available
    • Use redundant NICs for critical paths
    • Test failover scenarios

Now that you understand the Core Networking architecture: