Uploaded image for project: 'OpenShift Container Platform (OCP) Strategy'
  1. OpenShift Container Platform (OCP) Strategy
  2. OCPSTRAT-1594

Port mirroring support in OVN-Kubernetes

XMLWordPrintable

    • BU Product Work
    • False
    • Hide

      None

      Show
      None
    • False
    • 100% To Do, 0% In Progress, 0% Done
    • 0

      Feature Overview (aka. Goal Summary)  

      Add port-mirroring support in OVN-Kubernetes, with optional source/destination address packet filtering. 

      Port mirroring is a network feature that allows a network switch to send a copy of network packets seen on one port (or an entire VLAN) to another port on the same switch for monitoring and analysis. This technique is often used for network diagnostics, security monitoring, and troubleshooting.

      Goals (aka. expected user outcomes)

      For several use cases, customers require the ability to capture some or all ingress and egress traffic of pods/VMs located within an OpenShift cluster for the primary purposes of analysis and debugging.  The logging endpoint for the traffic should be generic in nature, as that device is unique to each customer and is not directly supported by OpenShift.  

      Because the amount of traffic logged can be voluminous, optional specification of targeted (or non-targeted) source and destination IP addresses can be specified. 

      Requirements (aka. Acceptance Criteria):

      Anyone reviewing this Feature needs to know which deployment configurations that the Feature will apply to (or not) once it's been completed.  Describe specific needs (or indicate N/A) for each of the following deployment scenarios. For specific configurations that are out-of-scope for a given release, ensure you provide the OCPSTRAT (for the future to be supported configuration) as well.

      Deployment considerations List applicable specific needs (N/A = not applicable)
      Self-managed, managed, or both  
      Classic (standalone cluster)  
      Hosted control planes  
      Multi node, Compact (three node), or Single node (SNO), or all  
      Connected / Restricted Network  
      Architectures, e.g. x86_x64, ARM (aarch64), IBM Power (ppc64le), and IBM Z (s390x)  
      Operator compatibility  
      Backport needed (list applicable versions)  
      UI need (e.g. OpenShift Console, dynamic plugin, OCM)  
      Other (please specify)  

      Use Cases (Optional):

      • Regulatory compliance requirement
      • Post-event forensic analysis
      • Debugging
      • Traffic pattern analysis

      Questions to Answer (Optional):

      • How to filter traffic

        Out of Scope

      • Layer-7 (request header) Traffic filtering

        Background

        Customer Considerations

        Documentation Considerations

        Interoperability Considerations

              ddharwar@redhat.com Deepthi Dharwar
              ddharwar@redhat.com Deepthi Dharwar
              Ashley Hardin Ashley Hardin
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated: