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

OVS-compatible skb tracking solution for NetObserv + UDN

    • Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • None
    • ovs-dpdk
    • None
    • OVS-compatible skb tracking solution for NetObserv + UDN
    • False
    • Hide

      None

      Show
      None
    • False
    • Hide

      Please mark each item below with ( / ) if completed or ( x ) if incomplete:

      ( ) The acceptance criteria defined below are met.


      ( ) The epics work is available in a downstream build (nightly/async or other)


      ( ) Test coverage is available in downstream CI if applicable


      ( ) All cards under the epic have been moved to Done


      ( ) Failed Test Plans have bugs added as children to the epic/feature.

      Show
      Please mark each item below with ( / ) if completed or ( x ) if incomplete: ( ) The acceptance criteria defined below are met. ( ) The epics work is available in a downstream build (nightly/async or other) ( ) Test coverage is available in downstream CI if applicable ( ) All cards under the epic have been moved to Done ( ) Failed Test Plans have bugs added as children to the epic/feature.
    • rhel-net-ovs-dpdk
    • 100% To Do, 0% In Progress, 0% Done
    • ssg_networking

      This epic tracks all the effort needed to deliver the solution related to 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-bot ovsdpdk bot
              amorenoz@redhat.com Adrian Moreno
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated: