Uploaded image for project: 'Fast Datapath Product'
  1. Fast Datapath Product
  2. FDP-2514

QE verification: OVS-compatible skb tracking solution for NetObserv + UDN

    • False
    • Hide

      None

      Show
      None
    • False
    • Hide

      ( ) The bug has been reproduced and verified by QE members
      ( ) Test coverage has been added to downstream CI
      ( ) For new feature, failed test plans have bugs added as children to the epic
      ( ) The bug is cloned to any relevant release that we support and/or is needed

      Show
      ( ) The bug has been reproduced and verified by QE members ( ) Test coverage has been added to downstream CI ( ) For new feature, failed test plans have bugs added as children to the epic ( ) The bug is cloned to any relevant release that we support and/or is needed
    • None
    • rhel-net-ovs-dpdk

      This ticket is tracking the QE verification effort for the solution to the problem described below.
      Part of a broader effort triggered by NetObserv and SDN teams.

      Essentially there are 2+1 high level problems to solve. Some of them have high priority so we might need to have a short term partial solution before we fix everything.

      1 - NAT Observability: NetObserv currently watches on each interface at ingress and egress. When a pod talks to a service they see two packets but they cannot tell if they are part of the same "stream" (they call it netflow but I'm trying to avoid that term). The reason: they use the 5-tuple to identify a "stream" but the 5-tuple changes because of NATing. They want to correlate those to packets into a single "stream".

      2 - UDN Observability: Apart from using the 5-tuple to identify a "stream" they use the source/destination IP address to identify the source/destination Pod. In UDN, networks may overlap and this technique is no longer valid. They need to tie the "stream" to a source and destination Pod reliably.

      3 - (Longer term, optional?) Cross-node tracking: When a packet is sent to another node (via GENEVE), NetObserv sees a new "stream" on the receiving node. They want to correlate it to the one they saw on the source node. This might be solvable purely by NetObserv post-processing the samples so it might not need any explicit FDP support.

      This task is to help in the design of a solution that works and is well supported by OVS/OVN.

              ovsdpdk-triage ovsdpdk triage
              nstbot NST Bot
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: