-
Feature
-
Resolution: Done
-
Critical
-
None
-
None
-
False
-
False
-
-
-
0
-
0
-
0% To Do, 0% In Progress, 100% Done
-
rhos-connectivity-neutron
-
Technology Preview
-
-
Done
Background:
With an increasing number of network functions implemented as VNFs and acting as a transit point for the bulk of the network traffic, support for remote port mirroring to third-party analyzers for troubleshooting, billing, and other management activities are paramount.
OVS and OVN provide remote port mirroring API support using GRE tunnels. Service providers can use the OVS/OVN API in combination with automation using tools such as ansible. This allows Service Providers to enable monitoring and analytics via 3rd party analytics and monitoring tools. This monitoring capability. Although this capability may be sufficient for Service Providers, but it does not help with providing this capability for tenants.
Openstack being multi-tenant environment, opening this capability on a port basis via OVS/OVN API violates the tenant separation / boundary and presents a security risk.
TAPaaS project implements / exposes the port mirroring capability as a service and maintains tenant separation and addresses the associated security concerns.
Refer to Openstack TAPaaS for additional details on the project.
Requirements
Current TAPaaS implementation does not support ML2-OVN and relies on a TAPaaS agent to be deployed on the compute node. Implementing TAPaaS with SDN controller without using TAPaaS agent was brought up in the past in upstream community, but no work has been done in this direction.
Supporting TAPaaS for RHOSO 18, would require OVN support for TAPaaS and hence involve upsteam work.
| Description | MVP (Y/N) | EPICs |
| OVN support for TAPaaS using ERSPAN/GRE tunnels | Y | |
| Verify functional operation (a) Remote port mirroring scenarios listed below the table in a multi-tenant deployment (b) Tenant separation i.e. if the port-mirroring service is deployed by Tenant 1, Tenant 2 with workloads sharing the same compute node and physical interface should not be able to view the traffic from tenant 1. (c) Mirrors from multiple tenants on the same compute nodes and physical port |
Y | |
| Compute resource footprint of a port mirror with data points for varying traffic mix and workload | N |
Port Mirroring Scenarios
- Remote Port Mirroring using GRE tunnel (i.e 1 local ip to 1 remote IP) and using a single mirror
- Remote Port Mirroring using 1 GRE tunnel (i.e 1 local ip and 1 remote IP) and using a single mirror but having multiple select_dst_port and select_src_port
- Remote Port Mirroring using GRE tunnel and 1 local ip to 2 remote IPs [2 mirrors and 2 GRE tunnels]
- Mirror0 - incoming traffic of vf0
- Mirror1 - incoming traffic of vf1
- Remote Port Mirroring using GRE tunnel and 1 local ip to 2 remote IPs [2 mirrors and 2 GRE tunnels]
- Mirror0 - incoming and outgoing traffic of vf0
-
- Mirror1 - incoming and outgoing traffic of vf1
References:
Blogs:
https://arthurchiao.art/blog/traffic-mirror-with-tc-and-tunneling/
https://arthurchiao.art/blog/traffic-mirror-with-ovs/
https://man7.org/linux/man-pages/man8/tc-mirred.8.html
https://www.youtube.com/watch?v=rpIt9K2IsAc
Acceptance criteria:
1. Get upstream project (tap-as-a-service) to downstream and ensure packaging in RHOSO
2. All functionality of upstream project should work as is
3. Since we are targeting Tech Preview, this is not QE efforts here
4. Upstream docs should be used for all config/deployment related guidelines
5. Out of scope: Customer documentation (release note only for TP)
Performance Testing
Port mirroring can consume excessive CPU cycles from the primary tasks for VNFs or applications deployed on the compute nodes. Guidelines for the impact of port mirroring and the resource footprint of traffic is important.
- Trend analysis for CPU and memory usage with increase in traffic mirroring vs no traffic mirroring
