I had the same thought about the tables. Regards, Miguel Ángel
On Thu, Aug 3, 2017 at 5:11 PM, Russell Bryant <[email protected]> wrote: > On Thu, Aug 3, 2017 at 4:44 AM, <[email protected]> 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 <[email protected]> > > --- > > 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 > [email protected] > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
