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

Test Plan: OVS-compatible skb tracking solution for NetObserv + UDN

    • Icon: Task Task
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • None
    • openvswitch3.4
    • False
    • Hide

      None

      Show
      None
    • False
    • Hide

      ( ) The new test plan is aligned with the epic's acceptance criteria

      ( ) The test plan/test case pass successfully on all non blocking functions of the feature

      Show
      ( ) The new test plan is aligned with the epic's acceptance criteria ( ) The test plan/test case pass successfully on all non blocking functions of the feature
    • None
    • rhel-net-ovs-dpdk

      This task is tracking the test case writing activities to cover the feature request 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: