Load Balancing and Network Services

Beyond switching and routing, OVN provides load balancing, firewalling, traffic shaping and DNS inside the logical network. None of these needs a separate appliance — they are enforced in the same data path as the rest of the traffic.

---

Load balancers

A load balancer maps a virtual IP and port to a pool of backend addresses. Create one on the Load Balancers page, then attach it to the logical switches whose clients should be able to use it.

• Protocol: TCP, UDP or SCTP
• VIP rules: a virtual IP, a port, and one or more address:port backends

Two rules decide whether it works at all:

1. Attach it to a logical switch, not to a distributed router. A router without a dedicated gateway port translates traffic on the way in but not on the way back, so every request appears to return nothing.
2. Give the VIP an address outside the client's subnet. An in-subnet VIP has nothing answering ARP for it, so clients hang before sending anything.

With both right, requests distribute across the backends and you can confirm it by making several requests and seeing different backends answer.

Load balancer groups

A group is a set of load balancers applied together. Attach the group to several switches and every member applies to all of them, which saves attaching each load balancer to each switch by hand. Members are listed by name on the group.

---

Security groups: port groups, address sets and ACLs

Port groups

A port group is a named set of logical switch ports. ACLs are written against the group, so adding a port to the group applies every rule in it — you do not edit the rules when workloads come and go.

Address sets

A named set of addresses or CIDRs, referenced from an ACL match so one rule can cover many sources.

Naming

Port group and address set names are substituted into rule expressions, where OVN reads - as subtraction. A group called db-servers yields a rule that is stored and never enforced. Use underscores: db_servers. Vapor rejects an invalid name as you type it.

ACLs

An ACL is a rule on a port group. It carries:

• Direction — to-lport for traffic arriving at the group's ports, from-lport for traffic leaving them
• Priority — higher wins
• Action — allow-related (stateful, admits replies), allow (does not), drop, reject
• Match — built from protocol, port range and a remote CIDR, address set or port group, or written directly
• Rule name — optional, and worth setting: it appears in the log output
• Log and severity — whether matches are logged, and at what level
• Meter — rate-limits the rule's log messages

Prefer allow-related over allow for anything connection-oriented. Plain allow is stateless and drops the replies.

A meter limits logs, not traffic

An ACL's meter restricts how often the rule writes a log line. It does nothing to the traffic itself — use a QoS rule to shape or police bandwidth.

After adding a rule that should block something, confirm it actually blocks it. An ACL can be stored and reported successfully and still not be applied — see Troubleshooting.

---

QoS

A QoS rule limits or marks traffic on a logical switch, matched by an expression that usually names a port.

• Direction: from-lport or to-lport
• Priority and match
• Either bandwidth — a rate and burst in kbps — or DSCP marking, not both

A rate limit takes effect immediately and is visible in a throughput test: a port limited to 2000 kbps transfers at roughly that rate. Deleting the rule restores full throughput.

Meters

A meter is a named rate limit — a unit (kbps or pktps), a rate, a burst size, and an action. Meters exist to be referenced by ACLs for log rate-limiting, so a noisy rule cannot flood the log.

---

DNS

A DNS record set maps hostnames to addresses, attached to one or more logical switches. OVN answers queries from ports on those switches itself, so workloads resolve internal names without reaching an external resolver.

Records are simple hostname-to-address pairs:

web.internal   10.50.0.11
db.internal    10.50.0.12

Two things to expect when testing:

• Query the address your workloads actually use as their resolver — normally the subnet gateway. Querying a public resolver from a guest with another route will reach the real one and return NXDOMAIN.
• A name OVN does not hold gets no answer rather than a negative one, and a client asking for an IPv6 address for an IPv4-only record likewise gets nothing. Both are correct.