On Mon, Feb 10, 2025 at 8:56 PM Vladislav Odintsov <[email protected]> wrote:
> Hi Ales, > > First of all, thank you for your time spent on digging into this change > request! > Hi Vladislav, thank you for the response. > 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). > So is my understanding right that you don't care about further processing on the target (sink) switch, just to deliver to the LSP? 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. > It is a bit unfortunate that negative conditions are a bit hard to express, but it should still be doable. > > 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. > The problem with this approach is that it's not compatible, you either have a filter per mirror or filtering in lflows, so for users it might be a bit counterintuitive what to configure where. This RFE actually allows users to attach the filter to "pure" ovs filter, which the code doesn't prevent AFAICT. So the user won't get any warning, but the filter won't work unless it's lport target. > > > > > > 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. > There is also extra cost for very careful configuration as the current approach is very fragile and can be broken accidentally by unrelated change. > > 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 :) > One question that wasn't answered is if you are ok with this being an experimental feature in 25.03 with potential to polish it in 25.09? > > > > > 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? > Because this point on the pipeline is well defined, it's not part of the lflow pipeline. In the code it can be defined to always correspond to "output" resubmit for ingress instead of jumping to the last lflow table. > > > >> > >> 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. > I think the requirements and the steps taken are clear to me now. > -- > Regards, > Vladislav Odintsov > > Thanks, Ales _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
