On Thu, Aug 3, 2017 at 4:44 AM, <wang.qia...@zte.com.cn> wrote: > Taas was designed to provide tenants and service providers a means of > monitoring the traffic flowing in their Neutron provisioned virtual > networks. It is useful for network trouble-shooting, security and > analytics. The taas presentations could be found from > https://github.com/openstack/tap-as-a-service/blob/master/doc/source/presentations.rst > , and the api reference could be found from > https://github.com/openstack/tap-as-a-service/blob/master/API_REFERENCE.rst > > To support taas function, this patch add a new logical switch > "logica_mirror_switch" which represents a taas_service in ovn. > This patch also add logica_mirror_switch_port with type of "mirror" and > "taas". port with type "mirror" is used as inport for monitor flow in > logica_mirror_switch, and port with type "taas" is used as outport for > monitor flow in logica_mirror_switch. > > The ovn-controller will make the relation between the logical_switch_port > and logica_mirror_switch_port. > > Signed-off-by: wang qianyu <wang.qia...@zte.com.cn> > --- > ovn/controller/binding.c | 11 +- > ovn/controller/ovn-controller.c | 4 +- > ovn/controller/physical.c | 125 +++++++++++++++- > ovn/northd/ovn-northd.c | 317 > ++++++++++++++++++++++++++++++++++++---- > ovn/ovn-nb.ovsschema | 42 +++++- > ovn/ovn-nb.xml | 167 +++++++++++++++++++++ > ovn/ovn-sb.xml | 85 ++++++++++- > ovn/utilities/ovn-nbctl.c | 152 ++++++++++++++++++- > ovn/utilities/ovn-trace.c | 5 +- > 9 files changed, 865 insertions(+), 43 deletions(-)
Thanks for working on the new feature! The first thing that stands out to me is the new tables in OVN Northbound: Logical_Mirror_Switch and Logical_Mirror_Switch_Port. I'm wondering if we can simplify the design ... what if we only added a new Logical_Switch_Port type of "mirror" with an option to identify which port it is mirroring. That seems like the simplest way to express the feature. Is there a key part of the configuration missed when expressed this way? On the implementation side, I haven't looked too deeply, but what I'd imagine for the new port type: - Always drop packets originating from these ports, as it'd be a passive monitoring port only - For the ingress pipeline, output() to the monitored port should also send a copy of the packet to the mirror port I'm sure there's more important details, but that's roughly what I had imagined this feature looking like. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
