Hello Alexandra and Vladislav, as discussed during the community meeting I have in mind some ideas how to change/simplify to some extent the feature, but I would like to hear your opinion if my understanding for the requirements is right.
Also important thing, I'm not oposed to this feature being in 25.03 probably as "tech preview" so we have a chance to polish it for the next release, but it is still usable. Going back to the beginning with requirements, I have 2 main questions: 1) Do you need elaborate filtering for the mirrors, or is it enough to have a single filter per mirror? If it's enough to have a single filter per mirror we can store it as part of the mirror table in OVN NB itself, thus not requiring an additional table to configure the feature. This could also be applied to existing mirrors, because OvS supports filtering at the mirror level. 2) Is the main reason for OVN port being that you would like to deliver the mirrored traffic locally and remotely without tunnel setup etc. that is required for the OvS mirror to work locally? Or is there a second reason being that you would like to process the mirrored traffic further e.g. by sending it through the switch and possibly being routed etc.? According to my understanding the latter is not possible with the current approach and it would require some changes. That's one of the reasons that makes me think it's mainly about sending it to a remote chassis. I'm asking this because I think we could make it work with pure OvS mirrors even if we want to send it to a remote chassis. It would require some work, that's why it's an IMO candidate for improvement of the feature rather than redesign of the current state. The following hadn't be fully thought through, there might be some missing pieces in the design and it makes assumptions about both questions above: The mirror in OvS would cover filtering, we wouldn't have to install logical flows in the pipeline for that. We would need the concept of mirror sink, either as a separate entity or part of the mirror. You could specify the chassis of the sink and connection to some form of ovs interface (as we do for regular LSPs). OVN would setup a tunnel for the mirrored traffic (separate one actually allows an additional layer of security if needed). And simple ovs bridge setup that would transfer the traffic between the tunnel and remote monitoring port. For local delivery we could just connect the mirror to the port directly as it is available out of the box in current OvS. Please let me know if that would fit your use case or not. Thank you for your patience. Regards, Ales On Mon, Feb 10, 2025 at 4:12 PM Aleksandra Rukomoinikova <[email protected]> wrote: > Hi, Ales! > > We would like to avoid checking for ACL while passing the egress pipeline > on logical switch the where the target port (sink) locates for cloned > packet. > > On 10 Feb 2025, at 17:04, Ales Musil <[email protected]> wrote: > > That makes sense, with that you can probably scratch the suggestion from > last paragraph. > > However, it makes this approach very error prone. If OVN changes the > pipeline order, or adds another pipeline after "ls_in_l2_unknown", > we might break the mirroring. I think it would make it way clearer > and more robust if we would add a new action that would actually do > the whole "clone { outport = "..."; resubmit(,OFTABLE_OUTPUT_INIT) }". > > I'm still a bit confused by the whole CT skip. So the flow matches > on the outport being the mirror port mp-*. Is it because the clone > will continue within the original switch in the egress so you want > to avoid ACLs? > > > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
