Masquerade uses OVN-K over eno2/br-ex — no bridge setup required
Test cases(24 of 50)
Complete prerequisites first ([PRE-01](PRE-01) → [PRE-08](PRE-08) minimum) before running these tests. Go to prerequisites
NOT POSSIBLE on SNO — live migration requires ≥2 nodes. Documented as an expected failure.
Test on local storage
Optimal for single-NIC — OVN-K over eno2/br-ex, no bridge setup required
✗ NOT TESTABLE ON HETZNER -- TOS violation! OVN-K localnet works technically (verified 30.06.2026: ping successful), but any VM MAC that reaches eno2/the physical switch via this interface is detected and reported by Hetzner as an unauthorised MAC (server suspension threatened). Only the registered server MAC is permitted.
✗ NOT TESTABLE — SR-IOV requires a dedicated second NIC (Intel X710, Mellanox ConnectX). The sole NIC eno2 is consumed by OVN-K and cannot be used for SR-IOV VFs.
Variant A uses pure software bridges br-net1/2/3 (port: []) — no VM MAC leaves eno2/the physical switch, no TOS risk. Variant B (on-premises, trunk port) is relevant only with your own switch.
purely internal software bridges br-net1/br-net2 (port: []) — no VM MAC leaves the node
UserDefinedNetwork with Layer2 topology is a pure overlay (encapsulated Geneve tunnel within OVN-K) — explicitly NOT localnet, so no VM MAC leaves the node.
⚠️ DEDICATED NAMESPACE REQUIRED: see NOTE below.
2 Pools: internal-pool binds to br-net1 — external-pool binds to eno2, requires a 2nd public IP
external-pool uses a provider-registered additional IP (e.g. Hetzner Additional IP); MetalLB speaker announces with the node's own MAC.
⚠️ SHARED RESOURCE: external-pool currently has only ONE IP — Clean up after this test (delete vm-ssh-lb) before starting TC-HCP-002
⚠️ NOT usable by default on the current SNO cluster: there is no customer-controlled router in the path for peering. Left for documentation purposes and future tests.
BGP mode: LB IPs are announced into the network via BGP. No ARP flooding, true routing approach. LB IPs reachable across subnets.
# NOTE: Relevant only for on-premises with a dedicated BGP router.
# Dedicated IP pool ONLY for the BGP test (adjust placeholder range!)
cat <<EOF | oc apply -f -
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
name: bgp-pool
namespace: metallb-system
spec:
addresses:
- 10.99.0.0/24 # Placeholder — adapt to your on-premises environment
autoAssign: false
---
# BGP Peer
apiVersion: metallb.io/v1beta2
kind: BGPPeer
metadata:
name: main-router
namespace: metallb-system
spec:
myASN: 64513
peerASN: 64512
peerAddress: 10.99.0.1 # Router IP — adjust
holdTime: "90s"
keepaliveTime: "30s"
---
apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
name: bgp-advert
namespace: metallb-system
spec:
ipAddressPools:
- bgp-pool
aggregationLength: 32
EOF
# VyOS router peer side (example):
# set protocols bgp 64512 neighbor 10.99.0.50 remote-as 64513
# set protocols bgp 64512 parameters router-id 10.99.0.1
# commit
# BGP status in the speaker pod:
SPEAKER=$(oc get pod -n metallb-system -l component=speaker -o name | head -1)
oc exec -n metallb-system $SPEAKER -- vtysh -c 'show bgp summary'
# Neighbor V AS Up/Down State/PfxRcd
# 10.99.0.1 4 64512 00:05:12 2 ← Established!L2Advertisement explicitly binds to br-net1/br-net2 — ARP announcements stay node-internal.
Single-NIC OK — HyperShift pods use the OVN-K pod network.
⚠️ Check Pod/Node Capacity before starting TC-HCP-002 — see steps below.
⚠️ SNO EXAMPLE INSTALLATION: --control-plane-availability-policy SingleReplica is mandatory on a single-node cluster.
⚠️ Be sure enough compute resources are available on the SNO node before starting this test.
Import over OVN-K — bandwidth is shared with OCP traffic on eno2/br-ex in this cluster