OVN support for remote port mirroring using GRE
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.
- Port Mirroring support from a source on an OVN compute node to a destination that may or may not be an OVN compute node
- Traffic from the source is replicated and mirrored traffic is GRE encapsulated for mirroring the destination
Port Mirroring Use Cases
- Remote Port Mirroring using GRE tunnel
- Remote port mirroring using ERSPAN
- Remote port mirroring using VxLAN overlay tunnels (integration with nuage)
- Local port mirroring
Requirement | Details | MVP | Priority | EPIC |
---|---|---|---|---|
Remote Port Mirroring using GRE tunnel with HWOL | (a) 1 local ip to 1 remote IP Single mirror (b) 1 local ip and 1 remote IP Single mirror multiple select_dst_port and select_src_port (c)1 local ip to 2 remote IPs [2 mirrors and 2 GRE tunnels] * Mirror0 - incoming traffic of vf0 Mirror1 - incoming traffic of vf1 (d) 1 local ip to 2 remote IPs [2 mirrors and 2 GRE tunnels]
|
Yes | 1 | |
Remote Port Mirroring using ERSPAN with HWOL | (a) 1 local ip to 1 remote IP Single mirror (b) 1 local ip and 1 remote IP Single mirror multiple select_dst_port and select_src_port (c)1 local ip to 2 remote IPs [2 mirrors and 2 GRE tunnels] * Mirror0 - incoming traffic of vf0 Mirror1 - incoming traffic of vf1 (d) 1 local ip to 2 remote IPs [2 mirrors and 2 GRE tunnels]
|
Yes | 1 | |
Local Port Mirroring | No | 3 | ||
Remote port mirroring using VxLAN overlay | No | 3 |
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