As modern cloud infrastructure becomes increasingly complex and multi-tenant, observability and security monitoring have become foundational requirements for OpenStack operators. One key network diagnostic technique used in traditional and virtualized environments is port mirroring, which allows administrators to capture and analyze traffic flowing through a particular interface. You can redirect mirrored traffic to third-party analytics tools and solutions hosted on a different or same host as the mirror port. Typically, the mirrored traffic is carried over overlay tunnels established between the source and destination of the mirror.
This functionality, when integrated and offered as an easily consumable, scalable service within Red Hat OpenStack Services on OpenShift, is known as TAP-as-a-Service (TAPaaS). TAP refers to a test access point, a logical or physical traffic mirroring point exposed as a service, allowing tenants or operators to capture and analyze network traffic. This article will detail how to operationalize TAPaaS within an OpenStack Services on OpenShift deployment.
Port mirroring
Port mirroring is available at OVS and OVN levels through a CLI interface, however, in highly dynamic, software-defined environments like OpenStack Services on OpenShift, traditional port mirroring doesn’t scale well and does not offer the tenant-level abstraction and isolation.
TAPaaS provides a OpenStack Services on OpenShift integrated framework for scalable port mirroring in a multi-tenant shared environment maintaining the tenant isolation boundaries in deployments.
Port mirroring enables the following:
- Security monitoring: Capture mirrored traffic for inspection by IDS/IPS tools.
- Performance analysis: Monitor bottlenecks, latency, and packet loss in real-time.
- Troubleshooting: Debug issues without logging into tenant VMs or affecting production traffic.
- Compliance auditing: Log and analyze data flows for regulatory purposes.
- Lawful intercept: In jurisdictions that require service providers to support legal requests for targeted surveillance, TAPaaS offers a programmable, isolated way to mirror traffic for specific endpoints without impacting other tenants or violating privacy constraints.
TAPaaS is a Neutron extension that enables on-demand traffic mirroring for tenant or administrator purposes. It allows users to create TAP services that mirror traffic from one or more Neutron ports and redirect it to a TAP destination—often a virtual network packet broker (NPB), intrusion detection system (IDS), or traffic analyzer instance.
Components and workflow for ML2-OVN
The OVN Northbound Database (NB DB) contains logical representations of the network, including:
- Logical switches
- Logical ports
- Mirror configurations with mirror type (remote-GRE, remote-ERSPAN)
When making a TAPaaS request, the ML2-OVN plug-in adds mirror configurations to the NB DB with appropriate tunnel parameters for remote mirroring.
OVN southbound database (SB DB)
The SB DB translates the logical configurations in the NB DB into physical implementations. For port mirroring, it will:
- Map logical mirrors to physical implementation details
- Specify which physical chassis should implement the mirroring
- Determine the encapsulation method (GRE, ERSPAN) for mirrored traffic
- Contain tunnel configuration for remote mirroring
OVN controller
The OVN controller monitors the SB DB for changes. It implements mirror configurations on the compute nodes and uses OpenFlow rules to duplicate traffic, directing mirrored packets to the specified destination. Furthermore, the controller sets up tunneling using GRE or ERSPAN for remote mirroring.
Enable TAPaaS in OpenStack Services on OpenShift
To enable TAPaaS in Neutron, set the service_plug-ins
and create service_prvider
section in the Neutron customServiceConfig
.
Determine the current service_plug-ins
and then add taas,tapmirror
. Here is a simple script to accomplish that.
#!/bin/bash
set -e
Find one of neutron pods name
neutron_pod=$(oc get pods -l service=neutron -o name | head -n 1)
if [[ -z $neutron_pod ]]; then
echo neutron_pod variable is empty
exit 1
fi
Read current service_plugins
service_plugins=$(oc exec $neutron_pod -c neutron-api -- crudini --get /etc/neutron/neutron.conf.d/01-neutron.conf DEFAULT service_plugins)
Append new service plugins
service_plugins+=",taas,tapmirror"
echo service_plugins=$service_plugins
Edit openstackcontrolplane
CR, neutron section. Add service_plugins
under the DEFAULT
section and add the new service_providers
as shown in the following output.
$ oc edit openstackcontrolplanes.core.openstack.org controlplane
Then in your editor change the .spec.neutron.template.customServiceConfig section as shown below:
spec:
neutron:
...
template:
...
customServiceConfig: |
[DEFAULT]
vlan_transparent = true
agent_down_time = 600
router_distributed = true
router_scheduler_driver = neutron.scheduler.l3_agent_scheduler.ChanceScheduler
allow_automatic_l3agent_failover = true
debug = true
default_availability_zones = zone-1,zone-2
service_plugins = qos,ovn-router,trunk,segments,port_forwarding,log,taas,tapmirror
[service_providers]
service_provider = TAAS:TAAS:neutron_taas.services.taas.service_drivers.ovn.taas_ovn.TaasOvnDriver:default
...
Port mirror installation workflow
The diagram in Figure 1 shows the workflow for creating a remote port mirror using TAPaaS in an OpenStack Services on OpenShift deployment.
The process involves several steps for operationalizing TAP-as-a-Service (TAPaaS) in an OpenStack Services on OpenShift deployment. First, the ML2-OVN component translates the TAPaaS objects into OVN mirror entries, adding tunneling if necessary. This mirror configuration is then added to the OVN Northbound (NB) DB via an update. The OVN Southbound (SB) DB processes this information, translating it into physical implementation details. Finally, the OVN controller implementation applies the mirroring rules on the compute nodes and creates tunnel interfaces for remote mirroring.
Configure remote port mirroring using TAPaaS
Assuming an existing VM port is called vm_port
. This command selects vm_port
as the port to mirror. The mirrored traffic will be in the IN (ingress) direction, encapsulated in a erspanv1
which will be tagged with the tag 101. Lastly, the mirrored traffic will be sent to 10.100.0.20 IP.
$ openstack tap mirror create --port vm_port --name mirror1 --directions IN=101 --remote-ip 10.100.0.20 --mirror-type erspanv1
To get other options, use the following command:
openstack tap mirror create –help
Tunneling protocols for remote mirroring
Generic routing encapsulation (GRE) is a tunneling protocol that can encapsulate a wide variety of network layer protocols inside virtual point-to-point links. In the context of TAPaaS:
- Encapsulation: Mirrored packets are encapsulated in GRE headers
- Protocol ID: Uses protocol ID 0x6558 for mirrored traffic
- Header format:
- 4 bytes of GRE header with optional fields
- Preserve the original packet as payload
ERSPAN tunneling
Encapsulated remote switched port analyzer (ERSPAN) is a Cisco proprietary tunneling protocol specifically designed for port mirroring over routed networks. It adds more metadata about the mirrored traffic:
- Encapsulation: Mirrored packets are encapsulated in ERSPAN headers + GRE
- Protocol ID: Uses GRE protocol ID 0x88BE
Header format:
- 8-byte ERSPAN header containing:
- Session ID (to identify the mirror session)
- Direction (ingress/egress)
- VLAN information
- Timestamp
- Original packet is preserved as payload
Future work and considerations
Security and performance considerations must be well understood before deploying TAP-as-a-Service. Performance in the form of resource footprint required for deploying a port mirror and the impact on performance of the user workloads. Although port mirroring enables applications such as lawful intercept, additional features may need to be implemented to fully enable lawful intercept using TAPaaS.
The current feature enables TAPaaS for ML2-OVN, but additional feature capabilities such as support for port mirroring in both ingress and egress directions, precautionary quota limits, VM migration need to be investigated. To learn more about TAPaaS, visit the GitHub page.
Facts Only
TAP-as-a-Service (TAPaaS) is a Neutron extension for OpenStack Services on OpenShift, enabling scalable port mirroring in multi-tenant environments.
Port mirroring allows administrators to capture and analyze traffic from specific interfaces, redirecting it to analytics tools via overlay tunnels.
TAPaaS supports security monitoring, performance analysis, troubleshooting, compliance auditing, and lawful intercept.
The system uses OVN components: Northbound Database (NB DB) for logical configurations, Southbound Database (SB DB) for physical implementations, and OVN controllers to apply mirroring rules.
Mirrored traffic can be encapsulated using GRE or ERSPAN tunneling protocols.
Enabling TAPaaS requires configuring Neutron service plugins (taas, tapmirror) and service providers in the OpenStack control plane.
A CLI command (`openstack tap mirror create`) configures remote port mirroring, specifying parameters like direction, encapsulation type, and destination IP.
GRE uses protocol ID 0x6558, while ERSPAN uses 0x88BE and includes additional metadata like session ID and timestamps.
Current limitations include unidirectional mirroring (ingress only) and the need for future enhancements like quota limits and VM migration support.
The solution is designed for ML2-OVN deployments in OpenStack Services on OpenShift.
Executive Summary
Full Take
**Constructive Mode**
TAPaaS represents a significant step forward in making network observability and security monitoring more accessible and scalable in OpenStack environments. By abstracting port mirroring into a tenant-isolated service, it addresses the operational friction of traditional methods while maintaining the flexibility needed for compliance and debugging. The integration with OVN’s logical and physical networking layers is particularly noteworthy, as it leverages existing infrastructure without requiring wholesale changes. However, the focus on ingress-only mirroring and the lack of built-in safeguards (e.g., quotas) suggest that this is an evolving capability rather than a complete solution. The emphasis on lawful intercept also raises important questions about how such features are governed—who controls access, and what audit trails exist to prevent misuse?
**Generative Questions:**
How might TAPaaS be extended to support bidirectional mirroring without compromising performance?
What mechanisms could ensure that lawful intercept capabilities are used transparently and accountably?
How does the resource overhead of TAPaaS compare to alternative monitoring solutions in production environments?
**Patterns detected:** None
**Counterstrike Scan:**
If this were part of a coordinated influence campaign, the playbook might emphasize the "lawful intercept" angle to frame TAPaaS as a surveillance tool, potentially alienating privacy-conscious users. However, the article’s focus on technical implementation and operational benefits—rather than political or ethical debates—suggests a clean, educational intent. The content aligns with Red Hat’s documented efforts to improve OpenStack observability, not with manipulative narratives.
Sentinel — Human
This text functions as a highly technical, instructional guide detailing the implementation of a specific cloud networking feature (TAPaaS) within a complex orchestration environment, demonstrating deep domain expertise.