Hi Ales, First of all, thank you for your time spent on digging into this change request!
While Aleksandra has already gave some comments regarding local/remote mirroring, let me give more description for full understanding of this feature. We've gonna integrate Network Traffic Analysis (NTA) solutions into our platform. This functionality requires next features to be supported by network virtualization platform: 1. Support mirroring (multiple) LSP(s) traffic to another one LSP regardless of physical location of source(s) and target (sink). 2. Support selection of traffic, which: - needs to be mirrored by direction (to-lport/from-lport); - needs to be mirrored by packet's 5-tuple (multiple rules per mirror should be allowed); - needs NOT to be mirrored by packet's 5-tuple (multiple rules per mirror should be allowed). All these requirements should be able to be mixed in the same mirror resource. This allows to make effective mirroring configurations for NTA - not to mirror elephant and costly for processing traffic (for example, backups) to NTA sensors. For example, we should be able to express next statement: "mirror all traffic except tcp/1111 and udp/2222 from LSPs lp1, lp2 connected to Logical Switch ls1, lp3 connected to ls2 to lp4 connected to ls2". If we're talking about our current implementation, we create one mirror object of type "lport" with sink "lp4". Then we attach this mirror to lp1, lp2, lp3 and add 2 rules to this mirror: priority=101, match="ip4 && udp && udp.dport === 2222", action=skip priority=100, match="ip4 && tcp && tcp.dport == 1111", action=skip If user wants more complex rules (mirror ONLY this traffic), rules should be: priority=101, match="ip4 && udp && udp.dport === 2222", action=mirror priority=100, match="ip4 && tcp && tcp.dport == 1111", action=mirror priority=1, match="1", action=skip. This is about current implementation. Please also see my answers inline. On 10.02.2025 19:45, Ales Musil wrote: > 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. We do want to have an ability to configure multiple rules for mirroring (for cases like above, where we want to skip or explicitly mirror only part of traffic). We also thought about adoption of filtering to OVS filters and decided that if this is needed by someone, it can be implemented with just a limitation of one filter rule per mirror of type "local/erspan/gre". "match" can be used to express openflow mirror filter rule OR alternatively OVN lflow rule can be automatically expanded by ovn-controller into openflow syntax for consequent passing to OVS filter. So, the abstraction should work fine here. > > > 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. We just want to deliver mirrored traffic to normal OVN logical switch port regardless of its location - on current chassis or remote. OVN-IC unfortunately is not supported here. Maybe later it could be possible to "output" traffic to lport of remote AZ. > > 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. We thought about such setup. It looks like we should send traffic from underlay (OVS mirror with type erspan) into overlay network. Without significant OVS changes I don't see an option here. VRFs, multitenancy should be somehow addressed in this case. > > 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. OVN has already implemented all the tunnels configuration logic complexity. Extra-bridges seem to make things more complex at first glance. Current implementation reuses all this stuff from OVN with the cost of extra-flows. So, if my explanation gave more light on things which are happening, maybe you got new questions or comments? Or maybe you just agree with those points :) > > 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) }". > It is an interesting tip, but I couldn't catch, how this can help not to be dependent on OVN logical pipeline changes? Could you please elaborate? > >> >> 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? > Yes, this definitely solves the problem, that the target network interface can be a part of a port-group (security group) with configured stateless or stateful ACLs, so we do not want to process this traffic against ACLs and don't want to consult conntrack for the connection state, which is not interested in case of traffic mirroring. Again, many thanks for your attention to this change. Let me know if you need any description for things that are still not clear. -- Regards, Vladislav Odintsov _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
