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?
> 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
