[ovs-dev] 答复: Re: [PATCH] ovn: Support for taas(tap-as-a-service) function
wang.qianyu at zte.com.cn
wang.qianyu at zte.com.cn
Fri Aug 4 00:52:38 UTC 2017
Miguel Ángel and Russell
Thanks for your reviews.
Current taas function just for port monitor, in this situation, we can
simplify the design by just add new port type. But we have the plane to
add flow_classifier to tap_flow to monitor special flows of given port.
The flow_classifier definition may like as follow:
'flow_classifiers': {
'id': {'allow_post': False, 'allow_put': False,
'validate': {'type:uuid': None}, 'is_visible': True,
'primary_key': True},
'tenant_id': {'allow_post': True, 'allow_put': False,
'validate': {'type:string': None},
'required_by_policy': True, 'is_visible': True},
'name': {'allow_post': True, 'allow_put': True,
'validate': {'type:string': None},
'is_visible': True, 'default': ''},
'description': {'allow_post': True, 'allow_put': True,
'validate': {'type:string': None},
'is_visible': True, 'default': ''},
'protocol': {'allow_post': True, 'allow_put': True,
'validate': {'type:string': None},
'is_visible': True, 'default': ''},
'src_port_range_min': {'allow_post': True, 'allow_put': True,
'convert_to': attr.convert_to_int,
'is_visible': True, 'default': 0},
'src_port_range_max': {'allow_post': True, 'allow_put': True,
'convert_to': attr.convert_to_int,
'is_visible': True, 'default': 0},
'dst_port_range_min': {'allow_post': True, 'allow_put': True,
'convert_to': attr.convert_to_int,
'is_visible': True, 'default': 0},
'dst_port_range_max': {'allow_post': True, 'allow_put': True,
'convert_to': attr.convert_to_int,
'is_visible': True, 'default': 0},
'src_ip_prefix': {'allow_post': True, 'allow_put': True,
'validate': {'type:subnet':
attr._validate_subnet},
'is_visible': True, 'default': '0.0.0.0/0'},
'dst_ip_prefix': {'allow_post': True, 'allow_put': True,
'validate': {'type:subnet':
attr._validate_subnet},
'is_visible': True, 'default': '0.0.0.0/0'}
}
This may need more complex pipeline. So I think add a new table and new
pipeline may be a easier way.
Thanks.
Miguel Angel Ajo Pelayo <majopela at redhat.com>
2017/08/03 23:21
收件人: Russell Bryant <russell at ovn.org>,
抄送: wang.qianyu at zte.com.cn, ovs dev <dev at openvswitch.org>,
zhou.huijing at zte.com.cn, xurong00037997 <xu.rong at zte.com.cn>
主题: Re: [ovs-dev] [PATCH] ovn: Support for
taas(tap-as-a-service) function
I had the same thought about the tables.
Regards,
Miguel Ángel
On Thu, Aug 3, 2017 at 5:11 PM, Russell Bryant <russell at ovn.org> wrote:
On Thu, Aug 3, 2017 at 4:44 AM, <wang.qianyu at 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.qianyu at 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
dev at openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
More information about the dev
mailing list