Hi Dumitru, On 15.10.2024 10:47, Dumitru Ceara wrote: > On 10/14/24 15:38, Aleksandra Rukomoinikova wrote: >> Hey there, >> > Hi Aleksandra, > > Thanks for reaching out! > >> I am writing to seek clarification on the feasibility of implementing >> traffic filters for port mirroring in ovn, specifically regarding the >> encapsulation of traffic to overlay using Geneve, VXLAN, or ERSPAN. >> >> In the current setup, it is understood that remote port mirroring >> assumes the destination lies outside the OVN cluster. >> > Just to make sure I understand your requirement, it's actually two-fold, > right? > > A. Add the capability to define a filter (match on packet fields) to > the NB.Mirror rules attached to a (source) logical switch port. > > This seems useful in general and I don't see why we shouldn't do it. > > B. Allow using sinks that are actual logical switch ports (local or > remote compared to the source), potentially on different logical > switches than the sources. > > To expand on this, do you envision a logical topology as below? > > Two logical switches with logical switch ports bound to different > hypervisors and one logical switch with a logical switch port that acts > as sink for some of the traffic mirrored from the first two logical > switches? > > LS-A (lsp1, lsp2, lsp3) - on different hvs > LS-B (lsp4, lsp5, lsp6) - on different hvs > LS-monitoring (lsp-sink) > > Mirroring rules attached to some LSPs, e.g., lsp2, lsp5, lsp6. > > I'm guessing lsp-sink in this case would be bound to a workload that > processes the traffic mirrored from lsp2, lsp5, lsp6. > > Is my guess along the lines of what you had in mind? > >> Upon examination, there appear to be two potential strategies to address >> this issue: >> >> 1. Utilizing Filters in OVS: While this approach presents itself as a >> feasible option, it comes with certain drawbacks. Primarily, when >> executing remote port mirroring, ovs encapsulates the packet within the >> underlay header. Consequently, this inhibits the ability to mirror >> traffic to a port situated on a separate host within the OVN cluster. >> > Configuring the "filter" field on the OVS Mirror seems like a good > idea to me. If "A" above is accurate then we could just store the > NB.Mirror.filter in the OVS.Mirror.filter. > >> 2. Integrating New Logic into the Logical Flow in the Southbound >> Database: it's constrained by its capability to output traffic solely on >> ports that reside within the same logical switch. This poses a >> limitation in its implementation. >> > This sounds a bit like the topology I described in "B". Is that correct? > > If so, I agree, if we change the logical flows so that we're able > to mirror to logical switch ports we could only output to ports on > the same logical switch. > > However, what about reusing an already existing OVN feature: "container > ports"? > From our documentation: > > When a large number of containers are nested within a VM, it may be > too > expensive to dedicate a VIF to each container. OVN can use VLAN tags > to support such cases. Each container is assigned a VLAN ID and each > packet that passes between the hypervisor and the VM is tagged with > the > appropriate ID for the container. Such VLAN IDs never appear on a > physical wire, even inside a tunnel, so they need not be unique > except > relative to a single VM on a hypervisor. > > This talks about containers and VMs but from OVN perspective it's basically > just a hierarchy of "sub"-logical-ports on top of a logical port bound to a > single VIF. > > We could change the same sample topology as I outlined in "B" to: > > LS-A (lsp1, lsp2, lsp3, lsp-sink-A) > LS-B (lsp4, lsp5, lsp6, lsp-sink-B) > LS-monitoring (lsp-sink) > > And set: > lsp-sink-A.parent_name = lsp-sink > lsp-sink-B.parent_name = lsp-sink > > lsp2.Mirror.sink = lsp-sink-A (not supported yet but we can expand the NB > schema) > lsp5.Mirror.sink = lsp-sink-B > lsp6.Mirror.sink = lsp-sink-B > > If the new logic in the SB logical flows ensures traffic is mirrored > accordingly to each lsp-sink-X, would that achieve the effect you're > aiming for?
Thanks for your idea, it's very interesting! Alternatively, we were talking to Aleksandra offline and thought of possibility to clone incoming traffic from LSP (or outgoing to LSP) with openflow: one branch continues normal processing, while another one is a subject to mirroring. We thought it will be very useful to have an ability to encap this traffic with a VXLAN, GENEVE, GRE or ERSPAN tunneling (different network analyzing solutions support these protocols for mirrored traffic; AWS does the same), set outer src/dst-ip, correct tunnel key and inject it into the LS pipeline, so that this encapsulated packet can traverse inside the overlay (actually, double-encaped) in any point of infrastructure relying on overlay routing. This gives us ability to send this mirrored traffic to any destination inside overlay topology - another subnet, even to another availability zone or outside of ovn but inside same vrf. But we faced that OF encap() action supports only nsh and mpls. Can you give us an advice whether it is possible to send double-encaped traffic with OVN somehow? Or we should extend encap() functinoality in this case? Potentially this double-encap can be reused for feature similar to AWS Gateway Load balancers [1]. 1: https://aws.amazon.com/elasticloadbalancing/gateway-load-balancer/ > >> since both options are currently not possible, I would greatly >> appreciate any insights or advice you may have regarding these approaches. >> > Thanks, > Dumitru > > > _______________________________________________ > dev mailing list > [email protected] > https://mail.openvswitch.org/mailman/listinfo/ovs-dev -- Regards, Vladislav Odintsov _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
