Learn MicroCloud - Networking: MicroOVN

#Introduction

Storage is solid from episode 6. But a cloud without a network is a set of isolated islands — an instance on node A can't talk to an instance on node B, let alone be reached by clients. In episode 7 we dissect MicroOVN: an OVN/OVS-based SDN providing the overlay network for the entire cluster, connecting instances transparently through LXD.

An analogy: imagine a city (cluster) with many buildings (instances) in many districts (nodes). The overlay network is like an elevated road connecting all buildings — no matter the district, the building's address (IP) doesn't change. The underlay is the ground road (physical) the elevated road rests on. MicroOVN builds and maintains this elevated road automatically.

#OVN and Overlay Concepts

#OVN and OVS

OVS (Open vSwitch) is a high-performance virtual switch at the kernel/user-space level. OVN (Open Virtual Network) is the layer on top that adds centralized control: you describe "logical" networks (switches, routers, ACLs), and OVN translates them into OVS rules on every node.

The benefits of this SDN model:

Centralized virtual topology: one view of the network for the whole cluster.
Overlay tunnels: inter-node traffic is wrapped in tunnels, so instances can be on any node without changing their IPs.
Integrated security: logical ACLs can be applied per network or per port.

#Logical Switches and Logical Routers

Logical switch: equivalent to a virtual L2 network — each LXD network gets one. All ports that join (instance vNICs) are on the same L2.
Logical router: connects logical switches to each other, and out to the outside world (via a gateway) — equivalent to a virtual router.

OVN topology in MicroCloud

        ┌───────────────────────────────┐
        │         logical router        │
        └──────┬───────────────┬────────┘
        logical switch "default"  logical switch "prod"
           ┌────┼────┐              ┌────┼────┐
         c1   c2   vm1             vm2   vm3  c3
        (node-a) (node-b) (node-c)  ── overlay di atas
        ─────────────────────────────────────────
        underlay: eth0 / bridge antar-node

#Networks for LXD Instances

#Networks Auto-created by MicroCloud

When init/join runs with OVN enabled, MicroCloud creates a network and profile that are automatically available in LXD:

View the networks MicroCloud created

lxc network list

Example lxc network list output

+---------+------+---------+---------+-------------+------+------+
|  NAME   | TYPE | MANAGED | USED BY | DESCRIPTION |  ... |
+---------+------+---------+---------+-------------+------+------+
| default | ovn  | yes     | 0       | OVN logical switch | |
| lxdfan0 | bridge | yes   | 0       | Fan bridge  |      |
+---------+------+---------+---------+-------------+------+------+

The network of type ovn is the SDN network managed by MicroOVN. lxdfan0 is a helper bridge used for outbound NAT. When lxc launch runs without a custom profile, instances automatically get this network — no manual configuration needed.

#Verification from the LXD and OVN Sides

OVN network details

lxc network show default

OVN cluster status

microovn status

microovn status shows the OVN cluster, members, and underlay configuration.

#Dedicated Underlay (Optional)

#Why the Underlay Deserves Thought

The underlay is the physical network underneath the overlay — where inter-node tunnels and Ceph traffic flow. For production, there's the practice of separating storage traffic (Ceph) from client traffic, or giving the cluster network dedicated bandwidth:

One NIC for management/client: admin traffic and user access.
One NIC (or VLAN) for storage: the heavy Ceph replication traffic.
One NIC (or VLAN) for the OVN overlay: inter-node instance traffic.

MicroOVN uses a single underlay interface that you select during init/join. For further separation, you can:

Choose the right NIC per node when joining.
Use VLAN tagging on the physical switch to separate segments.
Apply per-segment firewalls (we cover this in episode 14).

Tip

For labs and homelabs, one NIC per node is enough. For production, at minimum separate storage traffic from client traffic — either with separate NICs or VLANs. Ceph traffic is very sensitive to latency and packet loss (episode 18).

#Daily Practice

#Creating Additional Networks

Besides the default network, you can create your own OVN networks from LXD:

Create a new OVN network

lxc network create prod --type=ovn --network=default

The prod network is a new logical switch with a gateway to the default network. Instances that join it get their own L2 isolation.

#Viewing OVN Integration in LXD

Check OVN logical ports

microovn status
lxc network list

Both show the same cluster networks from two perspectives: LXD as the user, OVN as the provider.

#Common Pitfalls

Instance has no IP: check whether the instance uses the OVN network (lxc config show <instance>) and whether the underlay is truly connected between nodes.
Tunnels not working: make sure OVN's port (6081, Geneve) isn't blocked by a firewall between nodes.
High inter-node latency: check the underlay — instance traffic is wrapped in tunnels, so the physical network determines performance (episode 18).
Default network missing: don't delete networks managed by MicroCloud (managed: yes); recovery is harder than prevention.

#Closing

Key takeaways:

MicroOVN = OVN/OVS providing the SDN overlay for the whole cluster.
Logical switches and logical routers form a centrally controlled virtual topology.
OVN networks are auto-registered with LXD — instances connect without manual setup.
A dedicated underlay (separate NIC/VLAN) improves isolation and performance for production.
Verify with microovn status and lxc network list.

In the next episode, we'll deploy our first instances: containers & VMs — lxc launch ubuntu:24.04 c1, choosing the Ceph storage pool, running VMs with --vm which supports live migration, and understanding MicroCloud's default profile and custom profiles. Your cloud starts serving workloads!