Incus Networking OVN (Open Virtual Network) and Custom Bridges
Managed bridge is the default on a new install and it provides immediate plug-and-play connectivity for basic workloads. However, enterprise infrastructures and self-hosted environments will outgrow simple setups.
This is where advanced networking in Incus comes into play and it relies on two primary things Custom Linux Bridges and Open Virtual Network (OVN). These two networking layers provide fine-grained traffic control, multi-tenant network isolation, transparent VLAN tagging, and scalable cross-host overlay networks.
When you first initialize an Incus daemon, it typically creates a managed bridge named incusbr0. This default interface handles IP allocation via DHCP, sets up local NAT rules through iptables or nftables, and provides immediate internet outbound routing for instances. This is convenient, but the default model treats every instance as part of a single shared local subnet bound strictly to a single host.
In enterprise production deployments or homelabs, relying solely on host-managed NAT bridges introduces some limitations. System administrators need containers to exist directly on physical local area network subnets, expose distinct public IPv4 or IPv6 addresses without layer 4 port translation, or communicate across multiple physical hypervisors on isolated overlay channels. Transitioning to custom Linux bridges or software-defined networking through OVN resolves these constraints by decoupling instance connectivity from basic host-level NAT.
Custom Linux Bridges
These allow Incus instances to attach directly to host network interfaces that are configured outside of Incus itself. Instead of letting Incus manage the DHCP daemon, routing tables, and firewall rules, a custom bridge delegates network governance to your host operating system network manager, such as netplan, systemd-networkd, or traditional interfaces files.
When you bind an Incus profile or instance network interface to an unmanaged custom Linux bridge like br0, the instance virtual Ethernet pair connects straight into the host bridge kernel module. This architecture effectively turns the host bridge into a virtual Layer 2 switch. Any container or virtual machine attached to this custom bridge appears directly on the physical network switch connected to the physical host NIC.
The benefit of custom bridges is direct Layer 2 exposure. Instances can request IP addresses directly from external enterprise DHCP servers, announce their own IP addresses via ARP or Neighbor Discovery, and run network services on standard ports without relying on proxy devices or NAT rules.
Configuration and Use Cases for Custom Bridges
Bridges help when combined with IEEE 802.1Q VLAN tagging. Creating a custom bridge on top of a physical VLAN interface for instance, bond0.100 for VLAN 100 Incus instances connected to that bridge automatically inherit the network isolation and routing policies configured on the physical network switch. Alternatively, Incus supports passing raw VLAN tags to instances on a trunked custom bridge, allowing individual instances to manage multiple tagged sub-interfaces internally.
Custom bridges are also good for hosting network virtual appliances such as OPNsense, pfSense, or custom router containers. Attaching multiple custom bridges representing distinct physical or virtual network segments to a single router VM, you can construct firewall topologies directly inside Incus. In this pattern, Incus acts as a transparent hypervisor, leaving all Layer 3 routing, domain name resolution, and filtering to the dedicated virtual appliance.
However, custom Linux bridges have scaling limits. Because traditional bridges operate strictly within the kernel of a single physical machine, stretching a bridge across multiple physical Incus hosts requires external physical network configuration like GRE tunnels, VXLAN interfaces managed at the OS level, or enterprise hardware switches supporting multi-chassis link aggregation.
Software-Defined Networking with OVN
Open Virtual Network, or OVN, is an open-source software-defined networking system developed under the Open vSwitch project. Incus integrates natively with OVN to provide logical Layer 2 switches, logical Layer 3 routers, distributed firewalls, and dynamic network tunneling across single nodes and multi-node clusters alike.
This is different from Linux bridges that forward frames between local interfaces, OVN introduces an abstraction layer above physical hardware. When you create an OVN network in Incus, you define a complete virtual network topology including logical subnets, gateway routers, static routes, and access control lists. Incus translates these human-readable declarations into logical flows stored within the OVN Northbound database. OVN daemons then translate these logical flows into physical OpenFlow rules executed by Open vSwitch instances on each hypervisor node.
The primary architectural driver for choosing OVN is complete isolation combined with logical flexibility. In multi-tenant environments, different teams or applications can spin up overlapping IP subnets without colliding. OVN encapsulates packet traffic using Geneve tunnels, allowing logical networks to span across disparate host nodes regardless of the underlying physical network topology.
Mechanics of Incus OVN Networks
An Incus OVN network relies on a host bridge to serve as its uplink, typically an unmanaged bridge or an Incus-managed bridge providing external connectivity. From there, OVN constructs virtual logical routers that perform SNAT and DNAT operations, IPv6 router advertisements, and distributed DHCP services directly within Open vSwitch, completely eliminating the need for separate dnsmasq processes per network.
Security in OVN is built into the data plane rather than layered on top via host firewall rules. Incus leverages OVN Network ACLs to enforce stateful packet filtering at the virtual port level. This means firewall policies follow the instance wherever it migrates within an Incus cluster. If a container moves from Host A to Host B, its logical switch port bindings, firewall rules, and floating IP associations move with it without requiring physical network re-learning or switch reconfigurations.
Additionally, OVN natively supports load balancing and Floating IPs. You can allocate public or external IP addresses from an uplink network and map them directly to private instance IPs running inside isolated OVN logical networks. This provides enterprise-grade ingress capabilities comparable to public cloud providers, allowing fine-grained exposure of individual services without exposing internal network structures.
Multi-Host Clustering and Distributed Virtual Routing
In a standard multi-host cluster without OVN, instance communication across hosts must travel through traditional physical routing, requiring pre-allocated static routes or physical VLANs for every subnet. With OVN, Incus manages a fully distributed virtual router across all cluster members.
When Instance A on Host 1 sends a packet to Instance B on Host 2 on the same logical network, the local Open vSwitch on Host 1 encapsulates the frame in a Geneve tunnel and transmits it directly across the physical network to Host 2. If the traffic requires Layer 3 routing between two different logical networks, the routing logic is executed locally on Host 1 before encapsulation, avoiding unnecessary hairpinned hops to a centralized gateway node.
This distributed virtual routing architecture eliminates single points of failure and bandwidth bottlenecks. East-West traffic between containers on different hosts flows over short paths with minimal latency, while North-South traffic to the outer internet can be distributed across multiple chassis nodes equipped with external network uplinks.
Deciding whether to implement custom Linux bridges or OVN depends on your structural scale, performance targets, and underlying infrastructure control. Custom Linux bridges are simple, zero software-defined networking overhead, and native performance for single-host topologies or environments where physical switches already manage VLANs and Layer 3 routing. They are good for high-throughput database workloads, bare-metal integration, and simple homelabs where instances need simple local LAN exposure.
On the other hand, OVN is the ideal solution for multi-tenant environments, large Incus clusters, cloud-native deployments, and setups requiring programmatic network isolation. Although OVN introduces extra software components like Open vSwitch and OVN databases, it helps administrators with automated multi-host tunneling, integrated distributed firewalls, floating IPs, and cloud-like networking flexibility.
Incus Networking vs. Proxmox VE
Comparing Incus networking to Proxmox VE shows distinct design philosophies in guest management and software-defined networking (SDN). Both platforms leverage standard Linux bridges for direct, host-level Layer 2 connectivity, their approaches to overlay networking, state synchronization, and SDN architecture are different.
Proxmox VE structures its networking around a host-centric model, historically relying on standard Linux bridges, Open vSwitch, and its built-in SDN feature set introduced in recent releases. Proxmox SDN organizes networks using Zones and VNets, leaning heavily on traditional EVPN-BGP and VXLAN models to stretch Layer 2 networks across cluster nodes. Control plane synchronization across a Proxmox cluster depends on Corosync and the Proxmox Cluster File System (pmxcfs). This setup is okay at mapping virtual machines into existing enterprise VLANs and physical networking gear, it treats advanced overlay networking as an additional management layer sitting on top of host configurations.
Incus treats network logical abstractions as first-class primitives integrated directly into its daemon and REST API. Instead of relying on Corosync or external BGP EVPN control planes for overlay networking, Incus embeds OVN as a native network provider. When running an Incus cluster, network state synchronizes via an integrated Raft consensus database rather than a shared cluster file system. This design allows Incus to program logical switches, distributed virtual routers, NAT rules, stateful ACL firewalls, and dynamic DHCP services across cluster nodes using Geneve encapsulation without requiring network fabric switches or external BGP daemons.
Really.. the difference comes down to target use cases and operational ergonomics. Proxmox VE provides a GUI-driven operational experience tailored toward hypervisor-level virtual machine administration, making simple bridge and VLAN management immediately accessible for traditional virtualization admins. Incus provides an API-first, declarative model where OVN logical topologies including micro-segmentation, floating public IPs, and multi-tenant overlay routers can be spun up, modified, and torn down through CLI commands or infrastructure-as-code automation. Infrastructure engineers choosing between the two must weigh Proxmox's traditional hypervisor ecosystem against Incus's lightweight, programmable cloud-style SDN fabric.