What if a mirror port *only* receives mirrored packets? If the only packets it ever receives are mirrored packets, a new flag would not be necessary.
Do you intend for the port to operate as both a regular port *and* to receive a mirror of traffic for another port? On Thu, Aug 24, 2017 at 10:31 PM, <[email protected]> wrote: > I know your mean. > The receiver need to distinguish the traffic is regular or mirror. This > may need some special flow table to deal with it. > > Thanks > > > > *Gao Zhenyu <[email protected] <[email protected]>>* > > 2017/08/25 10:12 > > 收件人： [email protected], > 抄送： ovs dev <[email protected]>, Russell Bryant < > [email protected]>, xurong00037997 <[email protected]>, > [email protected] > 主题： Re: 答复: Re: [ovs-dev] 答复: Re: [PATCH v2] ovn: Support > for taas(tap-as-a-service) function > > > I mean for regular packet, ovs should not add the geneve option, the new > geneve option is only for mirror traffic. > > Did you meant some mirror traffic has mirror flag and some would not have? > > Thanks > Zhenyu Gao > > 2017-08-25 9:44 GMT+08:00 <*[email protected]* > <[email protected]>>: > Hi zhenyu, > Thanks for your opinion. > The mirror flag is not always exist, so I do not think add a new geneve > option is a good idea. > > Thanks. > > > *Gao Zhenyu <**[email protected]* <[email protected]>*>* > > 2017/08/25 09:34 > > 收件人： *[email protected]* <[email protected]>, > 抄送： Russell Bryant <*[email protected]* <[email protected]>>, > ovs dev <*[email protected]* <[email protected]>>, > *[email protected]* <[email protected]>, xurong00037997 < > *[email protected]* <[email protected]>> > 主题： Re: [ovs-dev] 答复: Re: [PATCH v2] ovn: Support for > taas(tap-as-a-service) function > > > > Although adding a new geneve option is more complicate but I think it > still worth having that. > Once the destination chassis found that geneve option, it can tag the > mirror flag on packet. And it make the whole process looks same no matter > on same chassis or not. > > Thanks > Zhenyu Gao > > 2017-08-25 9:15 GMT+08:00 <*[email protected]* > <[email protected]>>: > Hi Russell, > > Thanks for your review. > > When the mirror destination is in other chassis, the mirror flag which > used to mark the packet need be transmitted to the destination chassis. > > We could use the inport, geneve option or new type of out port to indicate > the packet as a mirrored packet. > > When we use inport to indicate the flag, this may need use inport as the > match field in the egress pipeline, I think this may conflict with the > egress pipeline. > > If use geneve option to deliver the mirror flag, this may be more > complicated. So, I add a new type of port as the destination of mirror > flow. The port types of mirror and taas corresponding to configurations of > tap-flow and tap-service. > > Thanks. > > > > > > Russell Bryant <*[email protected]* <[email protected]>> > 2017/08/25 04:44 > > 收件人： *[email protected]* <[email protected]>, > 抄送： ovs dev <*[email protected]* <[email protected]>>, > *[email protected]* <[email protected]>, > xurong00037997 <*[email protected]* <[email protected]>> > 主题： Re: [ovs-dev] [PATCH v2] ovn: Support for > taas(tap-as-a-service) function > > > Sorry for the delay in getting back to this ... > > On Tue, Aug 15, 2017 at 4:28 AM, <*[email protected]* > <[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* > <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* > <https://github.com/openstack/tap-as-a-service/blob/master/API_REFERENCE.rst> > > > > > To support taas function, this patch add two type of logica_switch_port, > > "mirror" and "taas". port with type "mirror" is used as inport for > monitor > > flow in logica_switch, and port with type "taas" is used as outport for > > monitor flow in logica_switch. > > > > The ovn-controller will make the relations of the ports in tap_service > and > > tap_flow to mirror port and taas port. > > > > Signed-off-by: wang qianyu <*[email protected]* > <[email protected]>> > > > diff --git a/ovn/ovn-nb.xml b/ovn/ovn-nb.xml > > index 31303a8..5fdd045 100644 > > --- a/ovn/ovn-nb.xml > > +++ b/ovn/ovn-nb.xml > > @@ -301,6 +301,20 @@ > > <dd> > > A port to a logical switch on a VTEP gateway. > > </dd> > > + > > + <dt><code>mirror</code></dt> > > + <dd> > > + A port indicate the inport of mirrored flows. The user need > > to > > + create this port in the logical_switch. This port should > one > > to > > + one correspondence with the the tap_flows > > + </dd> > > + > > + <dt><code>taas</code></dt> > > + <dd> > > + A port indicate the outport of mirrored flows. The user > need > > to > > + create this port in logical_switch. This port should one to > > + one correspondence with the the tap_service. > > + </dd> > > </dl> > > </column> > > </group> > > @@ -445,6 +459,61 @@ > > interface, in bits. > > </column> > > </group> > > + > > + <group title="Options for mirror ports"> > > + <p> > > + These options apply when <ref column="type"/> is > > + <code>mirror</code>. > > + </p> > > + > > + <column name="options" key="source-port"> > > + Required. The <ref column="name"/> of the <ref > > + table="Logical_switch_Port"/> that indicates where the > > + cloned flows come from. > > + </column> > > + > > + <column name="options" key="taas-port"> > > + Required. The <ref column="name"/> of the <ref > > + table="Logical_switch_Port"/> with type taas. > > + </column> > > + > > + <column name="options" key="direction"> > > + <p> > > + This option indicates whitch > direction(from-port/to-port/all) > > of > > + packet will be cloned to the taas-port. The directions are > > defined > > + as follow: > > + </p> > > + <dl> > > + <dt><code>from-port</code></dt> > > + <dd> > > + The packets from this port will be cloned to specified > > mirror > > + port. > > + </dd> > > + <dt><code>to-port</code></dt> > > + <dd> > > + The packets to this port will be cloned to specified > mirror > > + port. > > + </dd> > > + <dt><code>both</code></dt> > > + <dd> > > + The packets both from and to this port will be cloned to > > + specified mirror port. > > + </dd> > > + </dl> > > + </column> > > + </group> > > + > > + <group title="Options for taas ports"> > > + <p> > > + These options apply when <ref column="type"/> is > > <code>taas</code>. > > + </p> > > + > > + <column name="options" key="target-port"> > > + Required. The <ref column="name"/> of the <ref > > + table="Logical_switch_Port"/> that indicates where the > > + cloned flows come to. > > + </column> > > + </group> > > </group> > > > > <group title="Containers"> > > I'm having a hard time understanding this schema. Could you expand on > why both a "mirror" and "taas" port type was needed? > > I was hoping for only a single new port type, "mirror" for example, > with options to specify what port it is receiving a mirror of traffic > for. > > Does something like that not express everything needed here? > > -- > Russell Bryant > > > _______________________________________________ > dev mailing list > *[email protected]* <[email protected]> > *https://mail.openvswitch.org/mailman/listinfo/ovs-dev* > <https://mail.openvswitch.org/mailman/listinfo/ovs-dev> > > > -- Russell Bryant _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
