Virtual Network Security, QoS, and Quality Assurance: Security Groups, ACLs, and Traffic Management

1. Security Groups

Security groups are a key virtual‑network feature that enforce policies on a vswitch port by matching IP address, layer‑4 protocol, port numbers, and traffic direction, then applying actions such as drop or allow.

1.1 Linux Bridge + iptables + OVS

In early OVS deployments, OVS lacked native security‑policy support, so iptables running in the Linux kernel was used. By enabling net.bridge.bridge-nf-call-iptables , traffic passing through a Linux bridge could be processed by iptables. Virtual interfaces (veth, tap) connect OVS to the Linux bridge, allowing packets to flow from OVS to the bridge, be filtered by iptables, and then forwarded to the VM, albeit with a longer internal path.

1.2 OVS + Conntrack (CT)

Modern OVS versions provide built‑in security‑group functionality via conntrack actions (state: new, est, rel, etc.; action: commit, force, zone, exec, nat, …). Two deployment models exist: Linux‑kernel‑based OVS where conntrack runs in kernel space, and OVS‑DPDK where conntrack is implemented in user space, keeping the data‑plane entirely in user space for higher performance.

2. Network ACL

Network ACLs differ from security groups in that they apply to routers or whole sub‑net ranges rather than individual VM ports. Open‑source solutions like OVN implement ACLs on logical switches, but they still rely on security‑group processing before ACL evaluation, and they do not affect logical routers.

3. QoS

QoS controls bandwidth on a vswitch port in both ingress and egress directions. Two common implementations are described.

3.1 Linux TC + OVS

When OVS runs in kernel mode, it configures QoS by sending netlink messages to the Linux TC subsystem, which applies rate and burst limits to the virtual interface.

3.2 DPDK QoS + OVS

In OVS‑DPDK deployments, the Linux TC module cannot be used, so DPDK’s own QoS engine is employed. DPDK provides three‑color marking (srTCM, trTCM) based on token‑bucket algorithms, packet dropping thresholds, and hierarchical scheduling (port → subport → pipe → traffic class → queue).

4. Quality Assurance

Virtual‑network quality assurance addresses latency, packet loss, and reachability issues that can arise at various points in the data‑plane, from physical NICs to vswitch processing and VM‑side virtio back‑ends.

4.1 Active Probing

Active probing injects specially marked packets into the virtual network to measure reachability, delay, and loss. Probes can be generated inside VMs (in‑VM probes) or outside the VM using bypass NICs or vswitch‑bootstrapped mechanisms, each with its own trade‑offs regarding intrusiveness and compatibility.

4.2 Passive Observation

Passive observation monitors real traffic at the vswitch level, focusing on TCP connection states to detect anomalies such as failed handshakes, retransmissions, or resets, without impacting forwarding performance.

5. Security Awareness

Network security for private‑cloud environments is addressed from both external (underlay/public‑internet) and internal (VPC‑internal) perspectives. Centralized gateways or edge firewalls filter inbound attacks, while the compute‑node vswitch performs inline analysis, anomaly detection, and optional redirection to dedicated security modules.

The article concludes that virtual‑network security, QoS, and quality‑assurance are essential extensions built on the core virtualization and packet‑forwarding layers.