Uploaded image for project: 'Red Hat OpenStack Services on OpenShift'
  1. Red Hat OpenStack Services on OpenShift
  2. OSPRH-9186

Topology, Network Policy Correlation for Network Observability Metrics

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • None
    • None
    • None
    • Topology, Network Policy Correlation for Network Observability Metrics
    • False
    • Hide

      None

      Show
      None
    • False
    • Not Selected
    • Proposed
    • Proposed
    • To Do
    • OSPRH-8213 - OVN observability support for Openstack
    • Proposed
    • Proposed
    • 88% To Do, 13% In Progress, 0% Done

      • Even though there are ways to see what OVS/OVN is doing with a particular packet, there is no way to know why
      • OVN/OVS to generate packet samples enriched with some OVN metadata that can be easily correlated back to SDN-specific objects or other human-readable pieces of information that provide insights of what the SDN is doing with a packet and why
      • Drop sampling
      • These samples will contain metadata that can be correlated to the specific place in the OVN pipeline where the drop took place (useful for debugging and support) and human-readable explanations that can be shown to customers
      • Network Policy Correlation
      • Network Policy correlation consists in OVN/OVS generating samples for traffic that goes through specific ACLs (i.e: Network Policies). These samples will contain enough information to correlate them back to the exact Network Policy or policies that the packet went through
      • If there are multiple network policies in a service chain policy correlation should be able to map out the network policies along with the nodes / endpoint information for the point of enforcement information
      • Sampling Enrichment
      • Enrichment for topology 
      • Enrichment for network policy

       

      Metrics Collection Context / Metadata

      (1) Topology Context

      (2) Policy Context

           (a) Security Policy

       

      From a use case perspective, we can think about 2 use cases

      (1) Monitoring

      (2) RCA

      Monitoring PoP metadata may be further divided into

      • Port/Interface (excluding flow level metrics)
      • Node
      • Instance
      • System (PMD, compute resource …)
      • NIC
      • Flow level

       

       

      NOTE: Sampling infrastructure for OVN relies on kernel datapath ebpf hooks producing netlink samples monitored by a consuming agent. This Epic follows this implementation. It means that this Epic does NOT cover scenarios when kernel datapath is not used (DPDK). A separate design / Epic will be needed if we are interesting in sampling NFV workloads.

       

      Draft design document covering the possible Sampling integration with RHOSO can be found here: https://docs.google.com/document/d/1l5vHBiZvOLt8BMCQFQxxb_eUiqptRuv6PyGQ5Go5Tdg/edit Please consult the document if you are working on any of the stories attached to this Epic. The document does not cover all the necessary details, but should be a good first guidance.

            ihrachys Ihar Hrachyshka
            rh-ee-gurpsing Gurpreet Singh
            rhos-dfg-networking-squad-neutron
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: