I was wondering the same ... it seems odd to make it both the mirror destination and a regular port at the same time.
On Sun, Sep 10, 2017 at 9:13 PM, Gao Zhenyu <[email protected]> wrote: > A application may link to this destination port for collecting/analysing > mirror > traffic. How to distinguish a packet whether it's regular traffic or > mirror traffic if destination port receives both regular traffic and mirror > traffic? > > Thanks > Zhenyu Gao > > 2017-09-09 11:10 GMT+08:00 <[email protected]>: > >> If destination port only receive mirrored traffic, this function do not >> need add port with new type of taas. In this situation, the mirror flag is >> needed. >> >> But, I think, destination port receive both mirrored traffic and regular >> traffic may be more flexible. >> >> Thanks >> >> >> *Takashi YAMAMOTO <[email protected] <[email protected]>>* >> >> 2017/09/08 20:54 >> >> 收件人： Russell Bryant <[email protected]>, >> 抄送： [email protected], ovs dev <[email protected]>, >> [email protected], xurong00037997 <[email protected]> >> 主题： Re: [ovs-dev] 答复: Re: 答复: Re: 答复: Re: [PATCH v2] ovn: >> Support for taas(tap-as-a-service) function >> >> >> >> >> >> On Wed, Sep 6, 2017 at 3:57 AM, Russell Bryant <*[email protected]* >> <[email protected]>> wrote: >> 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? >> >> in taas, a destination port is supposed to receive both of mirrored >> traffic and regular traffic. >> >> (i haven't looked at this implementation yet) >> >> >> On Thu, Aug 24, 2017 at 10:31 PM, <*[email protected]* >> <[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]> < >> *[email protected]* <[email protected]>>>* >> > >> > 2017/08/25 10:12 >> > >> > 收件人： *[email protected]* <[email protected]>, >> > 抄送： ovs dev <*[email protected]* <[email protected]>>, >> Russell Bryant < >> > *[email protected]* <[email protected]>>, xurong00037997 < >> *[email protected]* <[email protected]>>, >> > *[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]>* >> > <*[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]>* < >> *[email protected]* <[email protected]>>*>* >> > >> > 2017/08/25 09:34 >> > >> > 收件人： **[email protected]* <[email protected]>* >> <*[email protected]* <[email protected]>>, >> > 抄送： Russell Bryant <**[email protected]* <[email protected]>* >> <*[email protected]* <[email protected]>>>, >> > ovs dev <**[email protected]* <[email protected]>* < >> *[email protected]* <[email protected]>>>, >> > **[email protected]* <[email protected]>* < >> *[email protected]* <[email protected]>>, xurong00037997 < >> > **[email protected]* <[email protected]>* <*[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]>* >> > <*[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]>* < >> *[email protected]* <[email protected]>>> >> > 2017/08/25 04:44 >> > >> > 收件人： **[email protected]* <[email protected]>* >> <*[email protected]* <[email protected]>>, >> > 抄送： ovs dev <**[email protected]* <[email protected]>* < >> *[email protected]* <[email protected]>>>, >> > **[email protected]* <[email protected]>* < >> *[email protected]* <[email protected]>>, >> > xurong00037997 <**[email protected]* <[email protected]>* < >> *[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]>* >> > <*[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*> >> > < >> *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*> >> > < >> *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]>* >> > <*[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]>* <*[email protected]* >> <[email protected]>> >> > **https://mail.openvswitch.org/mailman/listinfo/ovs-dev** >> <https://mail.openvswitch.org/mailman/listinfo/ovs-dev*> >> > <*https://mail.openvswitch.org/mailman/listinfo/ovs-dev* >> <https://mail.openvswitch.org/mailman/listinfo/ovs-dev>> >> > >> > >> > >> >> >> -- >> 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
