Re: [ovs-discuss] output to register
Yes, that is correct. *Vasu Dasari* On Wed, Mar 9, 2022 at 5:06 PM Ashish Varma wrote: > Thanks for the reply Vasu. > > So to clarify, if the rule gets hit, the action would send the packet out > of port number 1 (since reg0 holds the value 1)? > > On Wed, Mar 9, 2022 at 10:28 AM Vasu Dasari wrote: > >> Yes. You can use the registers as part of output specification. >> >> For example, this following rule works: >> >> # If reg0 is 1 and reg1 is 1, then output such packet via reg0 >> # reg0 and reg1 would have been set via learn operations earlier >> ovs-ofctl add-flow br0 table=4 reg0=1,reg1=1 actions=output:reg0 >> >> *Vasu Dasari* >> >> >> On Tue, Mar 8, 2022 at 4:58 PM Ashish Varma >> wrote: >> >>> I am trying to find the meaning of the following statement in the >>> ovs-actions man page: >>> >>> "Output to a register is an OpenFlow extension introduced in Open >>> vSwitch 1.3." >>> >>> Does this mean that we can specify an action like: >>> "output:" and the value of the output port would be taken >>> from the given register? >>> (Just like "output:field") >>> >>> Thanks, >>> Ashish >>> ___ >>> discuss mailing list >>> disc...@openvswitch.org >>> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss >>> >> ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] output to register
Yes. You can use the registers as part of output specification. For example, this following rule works: # If reg0 is 1 and reg1 is 1, then output such packet via reg0 # reg0 and reg1 would have been set via learn operations earlier ovs-ofctl add-flow br0 table=4 reg0=1,reg1=1 actions=output:reg0 *Vasu Dasari* On Tue, Mar 8, 2022 at 4:58 PM Ashish Varma wrote: > I am trying to find the meaning of the following statement in the > ovs-actions man page: > > "Output to a register is an OpenFlow extension introduced in Open vSwitch > 1.3." > > Does this mean that we can specify an action like: "output:" > and the value of the output port would be taken from the given register? > (Just like "output:field") > > Thanks, > Ashish > ___ > discuss mailing list > disc...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Action "mod_nw_tos:" for OPENFLOW13
I could get the command working for OpenFlow10 but not with OpenFlow13 --- $ ovs-ofctl add-flow -O OpenFlow10 br0 "in_port=2,reg2=0,actions=mod_nw_tos:64,load:55->NXM_NX_REG2[0..5],resubmit(,0)" $ --- Probably you might have seen the ovs-actions documentation regarding mod_nw_tos: *--* *The mod_nw_tos and mod_nw_ecn actions* *Syntax:* *mod_nw_tos:**tos* *mod_nw_ecn:**ecn* The *mod_nw_tos *action sets the DSCP bits in the IPv4 ToS/DSCP or IPv6 traffic class field to *tos*, which must be a multiple of 4 between 0 and 255. This action does not modify the two least significant bits of the ToS field (the ECN bits). The *mod_nw_ecn *action sets the ECN bits in the IPv4 ToS or IPv6 traffic class field to *ecn*, which must be a value between 0 and 3, inclusive. This action does not modify the six most significant bits of the field (the DSCP bits). In OpenFlow 1.1 and later, consistency rules allow these actions only in a flow that matches only packets that contain an IPv4 or IPv6 header (or following an action that adds such a header). See ``Inconsistencies’’, above, for more information. *Conformance:* OpenFlow 1.0 has a *mod_nw_tos *action but not *mod_nw_ecn*. Open vSwitch implements the latter in OpenFlow 1.0 as an extension using *NXAST_REG_LOAD*. OpenFlow 1.1 has specialized actions for these purposes. OpenFlow 1.2 and later do not, so Open vSwitch translates them to appropriate *OFPAT_SET_FIELD *actions for those versions. ----- *Vasu Dasari* On Mon, Jul 12, 2021 at 3:13 AM LIU Yulong wrote: > Hi there, > > Recently, I tested OpenStack Neutron with DSCP marking functions. But, I > met some errors related to the action "mod_nw_tos:", the command line > input is: > > """ > ovs-ofctl add-flow -O OpenFlow13 br-int > "hard_timeout=0,idle_timeout=0,priority=65535,cookie=17142212024999476593,in_port=2,table=0,reg2=0,actions=mod_nw_tos:64,load:55->NXM_NX_REG2[0..5],resubmit(,0)" > """ > > The error output is: > """ > ovs-ofctl: none of the usable flow formats (NXM+table_id) is among the > allowed flow formats (OXM-OpenFlow13) > """ > Action "mod_nw_tos:" is causing the error here. > > So, I would ask which action for OPENFLOW13 is to do same work of > "mod_nw_tos:" for OPENFLOW10? These is no doc mentioned such action > for OPENFLOW13. > > > Regards, > LIU Yulong > ___ > discuss mailing list > disc...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Flow Monitoring using OpenFlow 1.4/1.5
Oops. Sorry about copy/paste. Thanks for your comments. Will respond over the ovs-dev thread. *Vasu Dasari* On Mon, May 10, 2021 at 2:58 PM Ben Pfaff wrote: > On Sat, May 08, 2021 at 01:56:05PM -0400, Vasu Dasari wrote: > > I created a patch for supporting flow monitoring on any OpenFlow versions > > messages. > > Where is it? > > > Can you please take a look at my patch at ofproto-dpif: APIs and CLI > > option to add/delete static fdb entry > > < > http://patchwork.ozlabs.org/project/openvswitch/patch/20210508131448.83705-1-vdas...@gmail.com/ > > > > OK, I did that, but it's not related to flow monitoring. > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Flow Monitoring using OpenFlow 1.4/1.5
Hi Ben, I created a patch for supporting flow monitoring on any OpenFlow versions messages. Can you please take a look at my patch at ofproto-dpif: APIs and CLI option to add/delete static fdb entry <http://patchwork.ozlabs.org/project/openvswitch/patch/20210508131448.83705-1-vdas...@gmail.com/> Thanks -Vasu *Vasu Dasari* On Tue, Dec 8, 2020 at 8:39 PM Vasu Dasari wrote: > Sure Ben. I will be on it. > > Meanwhile, not to hijack this thread, can you please comment on my other > question, [ovs-discuss] MAC Learning event to Controller > <https://mail.openvswitch.org/pipermail/ovs-discuss/2020-December/050819.html>. > Flow monitoring is one of the ways by which I think I could achieve MAC > learning event propagation to controllers. If you have any other thoughts > please let me know. > > Thanks > -Vasu > > > <https://mail.openvswitch.org/pipermail/ovs-discuss/2020-December/050819.html> > > *Vasu Dasari* > > > On Tue, Dec 8, 2020 at 12:01 AM Ben Pfaff wrote: > >> On Mon, Dec 07, 2020 at 11:35:02PM -0500, Vasu Dasari wrote: >> > I see that flow monitoring is supported only with OpenFlow 1.1 and >> Nicira >> > extensions. >> >> You probably mean OpenFlow 1.0 with Nicira extensions. >> >> > Currently I am working with a OpenFlow controller software which >> supports >> > 1.3 and 1.4 only. So, sending OF 1.1 messages is not going to be easy. >> > >> > Is there anyone working on supporting Flow Monitoring to support >> negotiated >> > OpenFlow versions(whatever version it may be)? If no one is working on >> > this, I do not mind taking this up. >> >> If it still hasn't been ported to later versions of OpenFlow, it's well >> past time! I don't know of anyone working on it. >> > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] MAC Learning event to Controller
Ok. I agree.
On Wed, Dec 9, 2020 at 12:35 PM Ben Pfaff wrote:
> I respect the desire for symmetry, but it might not justify the effort
> of adding the new feature.
>
> On Wed, Dec 09, 2020 at 11:52:32AM -0500, Vasu Dasari wrote:
> > There is no reason for duplication, other than the reason for
> symmetricity
> > of APIs, "send_flow_rem"(which already exists) and "send_flow_add"(could
> be
> > added).
> >
> > -Vasu
> >
> > *Vasu Dasari*
> >
> >
> > On Wed, Dec 9, 2020 at 11:41 AM Ben Pfaff wrote:
> >
> > > On Wed, Dec 09, 2020 at 10:37:42AM -0500, Vasu Dasari wrote:
> > > > Ben,
> > > >
> > > > Thanks for the response.
> > > >
> > > > I expect the Learning event to come to the controller when a "learn"
> > > > happens. In this case(as in tutorial), when a learn event happens, a
> new
> > > > mac entry is added to table 10. Controller just needs to know that a
> > > learn
> > > > event happened on this {port, Mac, Vlan}. This information is
> > > sufficiently
> > > > populated in new flow information being added to table "10". So, I am
> > > > leaning towards using a flow-monitoring on the table to see when an
> entry
> > > > is added or removed to rely on MAC entry got added or removed to the
> > > > switching pipeline.
> > > >
> > > > "learn" action has options like "limit" which limits number of
> entries
> > > > added to a table, "send_flow_rem" which tells the controller when a
> flow
> > > is
> > > > removed, etc. All these flags are applied on top of the flows that
> are
> > > > added. I was hoping to see an option like "send_flow_add" which
> tells the
> > > > controller when a flow is added. Maybe this could be an enhancement
> to
> > > > "learn" action. What do you think?
> > >
> > > It sounds like flow monitoring already covers that. Is there a reason
> > > to duplicate the functionality?
> > >
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] MAC Learning event to Controller
There is no reason for duplication, other than the reason for symmetricity
of APIs, "send_flow_rem"(which already exists) and "send_flow_add"(could be
added).
-Vasu
*Vasu Dasari*
On Wed, Dec 9, 2020 at 11:41 AM Ben Pfaff wrote:
> On Wed, Dec 09, 2020 at 10:37:42AM -0500, Vasu Dasari wrote:
> > Ben,
> >
> > Thanks for the response.
> >
> > I expect the Learning event to come to the controller when a "learn"
> > happens. In this case(as in tutorial), when a learn event happens, a new
> > mac entry is added to table 10. Controller just needs to know that a
> learn
> > event happened on this {port, Mac, Vlan}. This information is
> sufficiently
> > populated in new flow information being added to table "10". So, I am
> > leaning towards using a flow-monitoring on the table to see when an entry
> > is added or removed to rely on MAC entry got added or removed to the
> > switching pipeline.
> >
> > "learn" action has options like "limit" which limits number of entries
> > added to a table, "send_flow_rem" which tells the controller when a flow
> is
> > removed, etc. All these flags are applied on top of the flows that are
> > added. I was hoping to see an option like "send_flow_add" which tells the
> > controller when a flow is added. Maybe this could be an enhancement to
> > "learn" action. What do you think?
>
> It sounds like flow monitoring already covers that. Is there a reason
> to duplicate the functionality?
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] MAC Learning event to Controller
Ben,
Thanks for the response.
I expect the Learning event to come to the controller when a "learn"
happens. In this case(as in tutorial), when a learn event happens, a new
mac entry is added to table 10. Controller just needs to know that a learn
event happened on this {port, Mac, Vlan}. This information is sufficiently
populated in new flow information being added to table "10". So, I am
leaning towards using a flow-monitoring on the table to see when an entry
is added or removed to rely on MAC entry got added or removed to the
switching pipeline.
"learn" action has options like "limit" which limits number of entries
added to a table, "send_flow_rem" which tells the controller when a flow is
removed, etc. All these flags are applied on top of the flows that are
added. I was hoping to see an option like "send_flow_add" which tells the
controller when a flow is added. Maybe this could be an enhancement to
"learn" action. What do you think?
Thanks
-Vasu
*Vasu Dasari*
On Tue, Dec 8, 2020 at 11:29 PM Ben Pfaff wrote:
> On Sun, Dec 06, 2020 at 08:22:43AM -0500, Vasu Dasari wrote:
> > Hi,
> >
> > I have a use case similar to that presented at Open vSwitch Advanced
> > Features <https://docs.openvswitch.org/en/latest/tutorials/ovs-advanced/
> >
> >
> > Specifically, looking at the flow defined in "Implementing Table 2:
> > MAC+VLAN Learning for Ingress Port"
> >
> > ovs-ofctl add-flow br0 \
> > "table=2 actions=learn(table=10, NXM_OF_VLAN_TCI[0..11], \
> >NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[], \
> >load:NXM_OF_IN_PORT[]->NXM_NX_REG0[0..15]), \
> > resubmit(,3)"
> >
> >
> > This above rule adds/modifies a new flow(MAC learning entry) into table
> 10.
> > My application requires that the controller should be notified of new MAC
> > entry when it is being learnt. In summary when a new flow is added to
> table
> > 10, (not modified) the controller should be notified of the event.
> >
> > Can someone please help me how to achieve this?
>
> Usually this would be done by sending the packet to the controller with
> a controller action.
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Flow Monitoring using OpenFlow 1.4/1.5
Sure Ben. I will be on it. Meanwhile, not to hijack this thread, can you please comment on my other question, [ovs-discuss] MAC Learning event to Controller <https://mail.openvswitch.org/pipermail/ovs-discuss/2020-December/050819.html>. Flow monitoring is one of the ways by which I think I could achieve MAC learning event propagation to controllers. If you have any other thoughts please let me know. Thanks -Vasu <https://mail.openvswitch.org/pipermail/ovs-discuss/2020-December/050819.html> *Vasu Dasari* On Tue, Dec 8, 2020 at 12:01 AM Ben Pfaff wrote: > On Mon, Dec 07, 2020 at 11:35:02PM -0500, Vasu Dasari wrote: > > I see that flow monitoring is supported only with OpenFlow 1.1 and Nicira > > extensions. > > You probably mean OpenFlow 1.0 with Nicira extensions. > > > Currently I am working with a OpenFlow controller software which supports > > 1.3 and 1.4 only. So, sending OF 1.1 messages is not going to be easy. > > > > Is there anyone working on supporting Flow Monitoring to support > negotiated > > OpenFlow versions(whatever version it may be)? If no one is working on > > this, I do not mind taking this up. > > If it still hasn't been ported to later versions of OpenFlow, it's well > past time! I don't know of anyone working on it. > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] Flow Monitoring using OpenFlow 1.4/1.5
Hi, I see that flow monitoring is supported only with OpenFlow 1.1 and Nicira extensions. Currently I am working with a OpenFlow controller software which supports 1.3 and 1.4 only. So, sending OF 1.1 messages is not going to be easy. Is there anyone working on supporting Flow Monitoring to support negotiated OpenFlow versions(whatever version it may be)? If no one is working on this, I do not mind taking this up. Please advise. Thanks -Vasu *Vasu Dasari* ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] MAC Learning event to Controller
Hi, I have a use case similar to that presented at Open vSwitch Advanced Features <https://docs.openvswitch.org/en/latest/tutorials/ovs-advanced/> Specifically, looking at the flow defined in "Implementing Table 2: MAC+VLAN Learning for Ingress Port" ovs-ofctl add-flow br0 \ "table=2 actions=learn(table=10, NXM_OF_VLAN_TCI[0..11], \ NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[], \ load:NXM_OF_IN_PORT[]->NXM_NX_REG0[0..15]), \ resubmit(,3)" This above rule adds/modifies a new flow(MAC learning entry) into table 10. My application requires that the controller should be notified of new MAC entry when it is being learnt. In summary when a new flow is added to table 10, (not modified) the controller should be notified of the event. Can someone please help me how to achieve this? Thanks -Vasu *Vasu Dasari* ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] OVSDB Error:Type mismatch for member 'uuid-name
Thank you Ben. I should have gone through the definition.
Vasu
> On Jun 26, 2020, at 7:52 PM, Ben Pfaff wrote:
>
> On Fri, Jun 26, 2020 at 06:10:09PM -0400, Vasu Dasari wrote:
>> Hi,
>>
>> I am seeing a strange error. Can someone see if this ia bug or I am using
>> this wrong?
>>
>> The following transaction is successful
>>
>> root@ovs1:~# ovsdb-client transact '
>> [
>> "Open_vSwitch",
>> {
>>"op": "insert",
>>"row": {
>> "name": "br1-eth1"
>>},
>>"table": "Interface",
>>"uuid-name": "a33f0e9e60105b9d8f8c15797107f29c"
>> }
>> ]
>> '
>> [{"uuid":["uuid","69ee67e3-4a32-4c88-998f-fd354b7b0509"]}]
>>
>> whereas the following transaction fails:
>> root@ovs1:~# ovsdb-client transact '
>> [
>> "Open_vSwitch",
>> {
>>"op": "insert",
>>"row": {
>> "name": "br1-eth1"
>>},
>>"table": "Interface",
>>"uuid-name": "133f0e9e60105b9d8f8c15797107f29c"
>> }
>> ]
>> '
>> [{"details":"Parsing ovsdb operation 1 of 1 failed: Type mismatch for
>> member 'uuid-name'.","error":"syntax
>> error","syntax":"{\"op\":\"insert\",\"row\":{\"name\":\"br1-eth1\"},\"table\":\"Interface\",\"uuid-name\":\"133f0e9e60105b9d8f8c15797107f29c\"}"}]
>> root@ovs1:~#
>>
>> The only difference in above commands is the uuid-name string.
>> a33f0e9e60105b9d8f8c15797107f29c. << Successful one
>> 133f0e9e60105b9d8f8c15797107f29c. << Failed one
>>
>> Also you can notice that the first letter in the above strings is the only
>> thing that is different. Actually, this command fails if the first letter
>> is any digit(0-9).
>>
>> Can someone please share what's going on here, why this is failing?
>
> As documented in the RFC, uuid-name must be an , which must start
> with _ or a letter.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] OVSDB Error:Type mismatch for member 'uuid-name
Hi,
I am seeing a strange error. Can someone see if this ia bug or I am using
this wrong?
The following transaction is successful
root@ovs1:~# ovsdb-client transact '
[
"Open_vSwitch",
{
"op": "insert",
"row": {
"name": "br1-eth1"
},
"table": "Interface",
"uuid-name": "a33f0e9e60105b9d8f8c15797107f29c"
}
]
'
[{"uuid":["uuid","69ee67e3-4a32-4c88-998f-fd354b7b0509"]}]
whereas the following transaction fails:
root@ovs1:~# ovsdb-client transact '
[
"Open_vSwitch",
{
"op": "insert",
"row": {
"name": "br1-eth1"
},
"table": "Interface",
"uuid-name": "133f0e9e60105b9d8f8c15797107f29c"
}
]
'
[{"details":"Parsing ovsdb operation 1 of 1 failed: Type mismatch for
member 'uuid-name'.","error":"syntax
error","syntax":"{\"op\":\"insert\",\"row\":{\"name\":\"br1-eth1\"},\"table\":\"Interface\",\"uuid-name\":\"133f0e9e60105b9d8f8c15797107f29c\"}"}]
root@ovs1:~#
The only difference in above commands is the uuid-name string.
a33f0e9e60105b9d8f8c15797107f29c. << Successful one
133f0e9e60105b9d8f8c15797107f29c. << Failed one
Also you can notice that the first letter in the above strings is the only
thing that is different. Actually, this command fails if the first letter
is any digit(0-9).
Can someone please share what's going on here, why this is failing?
Thanks
-Vasu
*Vasu Dasari*
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Error messages in ovsdb-server log
Thanks Ben. Should have noticed that. *Vasu Dasari* On Thu, Jun 11, 2020 at 6:01 PM Ben Pfaff wrote: > On Thu, Jun 11, 2020 at 05:27:01PM -0400, Vasu Dasari wrote: > > 19665ac0-ba46-4bcf-83b6-ce5b93c23987 > > Manager "tcp:172.26.0.2:6653" > > Bridge "br0" > > Controller "tcp:172.26.0.2:6653" > > fail_mode: secure > > Port "br0" > > Interface "br0" > > type: internal > > ovs_version: "2.9.7" > > This configuration must be wrong because it tries to connect to the same > endpoint tcp:172.26.0.2:6653 as both OpenFlow and OVSDB, which are > different protocols. > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] Error messages in ovsdb-server log
Hi,
I am seeing these error logs in ovsdb-server.log file:
2020-06-11T13:28:31.293Z|00066|reconnect|INFO|tcp:172.16.246.1:6653:
connected
2020-06-11T13:28:31.298Z|00067|jsonrpc|WARN|tcp:172.16.246.1:6653: error
parsing stream: line 0, column 0, byte 0: invalid character U+0004
2020-06-11T13:28:31.299Z|00068|reconnect|WARN|tcp:172.16.246.1:6653:
connection dropped (Protocol error)
2020-06-11T13:28:39.301Z|00069|reconnect|INFO|tcp:172.16.246.1:6653:
connected
2020-06-11T13:28:39.303Z|00070|jsonrpc|WARN|tcp:172.16.246.1:6653: error
parsing stream: line 0, column 0, byte 0: invalid character U+0004
2020-06-11T13:28:39.304Z|00071|reconnect|WARN|tcp:172.16.246.1:6653:
connection dropped (Protocol error)
2020-06-11T13:28:47.305Z|00072|reconnect|INFO|tcp:172.16.246.1:6653:
connected
2020-06-11T13:28:47.308Z|00073|jsonrpc|WARN|tcp:172.16.246.1:6653: error
parsing stream: line 0, column 0, byte 0: invalid character U+0004
2020-06-11T13:28:47.308Z|00074|reconnect|WARN|tcp:172.16.246.1:6653:
connection dropped (Protocol error)
2020-06-11T13:28:55.312Z|00075|reconnect|INFO|tcp:172.16.246.1:6653:
connected
2020-06-11T13:28:55.316Z|00076|jsonrpc|WARN|tcp:172.16.246.1:6653: error
parsing stream: line 0, column 0, byte 0: invalid character U+0004
2020-06-11T13:28:55.316Z|00077|reconnect|WARN|tcp:172.16.246.1:6653:
connection dropped (Protocol error)
Here is my environment:
1. OVS from branch-2.12 branch, running in a docker-for-mac. And OVS is
operating in userspace datapath.
2. Faucet controller(tried with ryu with simple_l3 as well, with similar
observation). Controller is in docker as well.
I tried OVS from other release branches(branch-2-11/2.10) as well. Are
there any fine tuning adjustments(to adopt for the docker environment) I
can do to avoid these error messages?
OVS Configuration I have is very simple one:
root@c8e13db3de62:~/ovs# ovs-vsctl show
19665ac0-ba46-4bcf-83b6-ce5b93c23987
Manager "tcp:172.26.0.2:6653"
Bridge "br0"
Controller "tcp:172.26.0.2:6653"
fail_mode: secure
Port "br0"
Interface "br0"
type: internal
ovs_version: "2.9.7"
Thanks
-Vasu
*Vasu Dasari*
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Re：Re： Re：[HELP] Question about userspace geneve/vxlan port
I think author of example you referred to in userspace-tunnel.rst tried to show a scenario where underlay and overlay networks are separated on two different bridges. OVS does not need to have two separate bridges for userspace-tunnel to work. *Vasu Dasari* On Wed, Jul 17, 2019 at 5:05 AM txfh2007 via discuss < ovs-discuss@openvswitch.org> wrote: > Hi Ben & all: > Another question about userspace tunnel: in userspace-tunnel.rst , I > have found the tunnel port(vxlan port) and VM port(vhu port e.g.) should on > the same bridge(br-int). Is this necessary ? Should the tunnel port on a > different bridge ? can anyone explain the reason? > > Thanks > Timo > > +--+ > | vm0 | 192.168.1.1/24 > +--+ >(vm_port0) >| >| >| > +--+ > |br-int|192.168.1.2/24 > +--+ +--+ > |vxlan0| |vxlan0| > +--+ +--+ >| | >| | >| | > 172.168.1.1/24 | > +--+ | > |br-phy| 172.168.1.2/24 > +--+ +---+ > | dpdk0/eth1 |--| eth1 | > +--+ +---+ > Host A with OVS. Remote host. > > > Native tunneling and userspace tunneling are the same thing. > > The mechanism should be symmetric: configuration for sending packets out > should also work for parsing them on the way back in. > > On Mon, Jul 08, 2019 at 03:57:46PM +0800, txfh2007 wrote: > > Hi Ben: > > Thanks for your reply ! I didn't find the "native tunneling" > document in OpenvSwitch repository. Did you mean the document > "userspace-tunneling.rst". this document just tells us the br-phy can send > tunnel pkt out, but when dpdk type port receives pkts with tunnel hdr, how > could I configure the "native tunnel" mechanism to parse and handle these > pkts? Or what you mean is currently OVS cannot handle parsing tunnel pkts > in userspace ? > > > > Thank you > > > > Timo > > > > > > -- > > Ben Pfaff > > txfh2007 > > ovs-discuss > > Re: [ovs-discuss] Re：[HELP] Question about userspace geneve/vxlan port > > > > > > On Thu, Jul 04, 2019 at 05:27:28PM +0800, txfh2007 via discuss wrote: > > > I have found theoritically during the upcall process, task > > > tnl_port_receive could be called(via upcall_cb() -> upcall_receive() > > > -> xlate_lookup() ->xport_lookup). But in my env, after tracing code > > > by gdb, I have found the task "tnl_port_should_receive(flow)" always > > > returns "false" for flow->tunnel->ip_dst is "0", even if the pkt > > > received by dpdk port has a tunnel header. > > > > Yes. > > > > > I guess the reason is in userspace task "handle_packet_upcall", the > > > match.tun_md.valid has been set "false", so the expanded flow has no > > > tunnel info, and also in task "miniflow_extract" in flow.c, the > > > packet->md is null as in dfc_processing task the "md_is_valid" flag is > > > always "false". Am I right ? > > > > Yes. > > > > OVS takes what some might consider an idiosyncratic approach to tunnel > > processing. The "obvious" approach is to simply parse tunnel headers > > and throw those into the flow. If OVS did that, then you'd see what you > > expect, but this isn't what OVS does. > > > > Instead, OVS treats tunnel and their headers as metadata. This is > > because of OVS's history as part of the Linux kernel. The Linux kernel > > has tunnel implementations as part of the TCP/IP stack. When a tunnel > > packet arrives at a physical port in Linux, it passes into the TCP/IP > > stack, where it gets processed and received on a tunnel network device. > > This effectively strips the tunnel headers and transforms them into > > metadata. If the
Re: [ovs-discuss] Help with testing please
Thanks Aaron.
I made a small tweaks to ovs-macros.at, so that when test suite fails,
ovs_on_exit() function will be called. And in this function, a check is
made to see if an environment variable to OVS_PAUSE_TEST is set. If it is
set, then test suite is paused and will continue to wait for user input
Ctrl-D. Meanwhile user can poke around the system to see why test case has
failed. Once done with investigation, user can press ctrl-d to cleanup the
test suite.
For example, to re-run test case 139:
export OVS_PAUSE_TEST=1
cd tests/system-userspace-testsuite.dir/139
sudo -E ./run
When error occurs, above command would display something like this:
=
Set environment variable to use various ovs utilities
export
OVS_RUNDIR=/opt/vdasari/Developer/ovs/_build-gcc/tests/system-userspace-testsuite.dir/139
Press ctrl-d to continue:
And from another window, one can execute ovs-xxx commands like:
export
OVS_RUNDIR=/opt/vdasari/Developer/ovs/_build-gcc/tests/system-userspace-testsuite.dir/139
$ ovs-ofctl dump-ports br0
.
.
Here is the tweak looks like:
diff --git a/tests/ovs-macros.at b/tests/ovs-macros.at
index 10593429d..5da61c654 100644
--- a/tests/ovs-macros.at
+++ b/tests/ovs-macros.at
@@ -35,11 +35,36 @@ m4_divert_push([PREPARE_TESTS])
# directory.
ovs_init() {
ovs_base=`pwd`
-trap '. "$ovs_base/cleanup"' 0
+trap ovs_on_exit 0
: > cleanup
ovs_setenv
}
+# Catch testsuite error condition and cleanup test environment by tearing
down
+# all interfaces and processes spawned.
+# User has an option to leave the test environment in error state so that
system
+# can be poked around to get more information. User can enable this option
by setting
+# environment variable OVS_PAUSE_TEST=1. User needs to press CTRL-D to
resume the
+# cleanup operation.
+ovs_pause() {
+echo "="
+echo "Set environment variable to use various ovs utilities"
+echo "export OVS_RUNDIR=$ovs_base"
+echo "Press ctrl-d to continue:"
+while read -s -n 1 key; do
+printf -v keycode "%d" "'$key"
+[ $keycode -ne 4 ] || break
+done
+}
+
+ovs_on_exit () {
+if [ ! -z "${OVS_PAUSE_TEST}" ]; then
+ovs_pause
+fi
+. "$ovs_base/cleanup"
+}
+
# With no parameter or an empty parameter, sets the OVS_*DIR
# environment variables to point to $ovs_base, the base directory in
# which the test is running.
If you think that this would be helpful I can raise a patch with this
change.
-Vasu
*Vasu Dasari*
On Fri, Jun 21, 2019 at 10:49 AM Aaron Conole wrote:
> Vasu Dasari writes:
>
> > Hi,
> >
> > I would like to know what is the procedure you follow to debug "Testing"
> failures.
> >
> > For example, on my Ubuntu system, I am trying to execute
> system-userspace test case like this.
> >
> > sudo make -C _build-gcc/ -s check-system-userspace TESTSUITEFLAGS='-k
> "ptap - triangle bridge setup with L2
> > and L3 GRE tunnels"'
> >
> > This is failing on my system. I would like to debug this by starting a
> switch with the same configuration that
> > was done on the switch.
>
> It's possible in at least two ways I can think of:
>
> 1. modify the 'run' to eliminate the "on_exit" calls that will tear
> down the ovs-vswitchd (and the associated links).
>
> 2. Follow the scripts in '.at' and manually run the tests.
>
> > I do see that test related information is present at
> tests/system-userspace-testsuite.dir/139. And there is a
> > script called "run" which can be used to redo the test. But,
> ovs-vswitchd is killed when script fails.
> >
> > 1. Are there any options I can give to ./run or to "testsuite" to not to
> perform kill operation so that I can
> > continue to debug the switch from where it failed.
> > 2. How can I recreate the switch instance from conf.db we got from
> failed test? I tried to copy conf.db to
> > "ovs/_run" directory and started "utilities/ovs-dev.py run" to start the
> switch. But, not all interfaces created
> > properly. For example, on some interfaces I do see errors like this. So
> probably I might be missing some steps
> > here.
> > Port "p2-0"
> > Interface "p2-0"
> > error: "could not open network device p2-0 (No such
> device)"
>
> That happens because when interfaces and netns are added, there is a
> separate call made to on_exit so that when the script terminates, they
> are torn down.
>
> Hope it helps!
>
> > Thanks
> > -Vasu
> >
> > Vasu Dasari
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] Help with testing please
Hi,
I would like to know what is the procedure you follow to debug "Testing"
failures.
For example, on my Ubuntu system, I am trying to execute system-userspace
test case like this.
sudo make -C _build-gcc/ -s check-system-userspace TESTSUITEFLAGS='-k "ptap
- triangle bridge setup with L2 and L3 GRE tunnels"'
This is failing on my system. I would like to debug this by starting a
switch with the same configuration that was done on the switch.
I do see that test related information is present at
tests/system-userspace-testsuite.dir/139. And there is a script called
"run" which can be used to redo the test. But, ovs-vswitchd is killed when
script fails.
1. Are there any options I can give to ./run or to "testsuite" to not to
perform kill operation so that I can continue to debug the switch from
where it failed.
2. How can I recreate the switch instance from conf.db we got from failed
test? I tried to copy conf.db to "ovs/_run" directory and started
"utilities/ovs-dev.py
run" to start the switch. But, not all interfaces created properly. For
example, on some interfaces I do see errors like this. So probably I might
be missing some steps here.
Port "p2-0"
Interface "p2-0"
error: "could not open network device p2-0 (No such device)"
Thanks
-Vasu
*Vasu Dasari*
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] VxLAN in Userspace
Flavio, Submitted patch link <https://mail.openvswitch.org/pipermail/ovs-dev/2019-June/359914.html>. Regarding, fdb/set, thanks for your inputs, will think more about that. Probably initiate a separate email thread later. -Vasu *Vasu Dasari* On Wed, Jun 19, 2019 at 9:53 AM Flavio Leitner wrote: > On Tue, Jun 18, 2019 at 03:12:51PM -0400, Vasu Dasari wrote: > > On Tue, Jun 18, 2019 at 12:21 PM Flavio Leitner > wrote: > > > > > On Tue, Jun 18, 2019 at 10:41:16AM -0400, Vasu Dasari wrote: > > > > Flavio, > > > > > > > > The device(could be a regular interface) should have been added to > OVS > > > with > > > > "add-port" and when it is removed, ARP entries learnt on it well be > > > removed > > > > as well. > > > > > > Not necessarily. You could have a regular kernel interface with the > > > tunnel endpoint address which is not part of an OVS bridge. > > > > > > > The code being added should cover that as well. Probably you can comment > on > > this after you look at my code. > > OK. > > > > > The code is ready. Regarding, testing the code I am planning on > extending > > > > already existing case where tests are performed to check ARP entry > > > > existence, like for example, "tunnel_push_pop - underlay bridge > match" in > > > > tunnel-push-pop.at. I hope that is fine, or should I be writing a > > > separate > > > > unit test case? > > > > > > Usually we just add more tests to the file to cover additional > > > use-cases. > > > > > > Ok. Will add a new test case then. > > > > On another note, I see ARP neighbor add and show commands. This covers L3 > > side. For L2 side, I see fdb show command, but there is no set command. I > > would like to add that one also. Any comments? > > > > Current fdb show: > > ovs-appctl fdb/show s1 > > > > Proposed CLI for fdb/set operation would look like: > > ovs-appctl fdb/set > > ovs-appctl fdb/set s1 2 0 00:00:01:00:00:02 > > > > What do you think? > > One could add a flow to match on specific MAC and send out on a > specific port as an alternative solution which is not possible to > regular bridges. > > On another hand, for use cases where the flow table last action is > NORMAL, then having static entries might be interesting because > today the FDB has only learned packets which expire/update > dynamically. You also need a way to remove specific static entries > because flushing the whole table has non trivial networking side > effects. > > If you want to pursue that too, I suggest to do as a separate > patchset to not mix bug fixes with enhancements. > > fbl > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] [openvswitch 2.11.90] system-userspace-testsuite: 138 failed
Thank you Aaron. Your suggestion did the trick. Now the testcase passes too. *Vasu Dasari* On Wed, Jun 19, 2019 at 11:10 AM Aaron Conole wrote: > Vasu Dasari writes: > > > Hi, > > > > The following test case is not successful on a Ubuntu 18.04 based VM. > > > > 138: system-interface.at:30 interface - add route to br and verify > clean-up > > > > OVS Code base used: master > > > > Command I used to run the test: > > $ sudo make -C _build-gcc/ -s check-system-userspace TESTSUITEFLAGS='138' > > > > I am attaching the log file and entire > system-userspace-testsuite.dir/138. > > > > On looking at the log file I see these errors: > > > > 2019-06-17T03:37:58.368Z|1|dpif_netdev(revalidator6)|ERR|internal > error parsing flow key skb_priority > > > (0),skb_mark(0),ct_state(0),ct_zone(0),ct_mark(0),ct_label(0),recirc_id(0),dp_hash(0),in_port(2),packet_type > > > (ns=0,id=0),eth(src=aa:55:00:00:00:01,dst=01:00:5e:00:00:16),eth_type(0x0800),ipv4 > > (src=10.0.0.1,dst=224.0.0.22,proto=2,tos=0xc0,ttl=1,frag=no) > > +2019-06-17T03:37:58.368Z|2|dpif(revalidator6)|WARN|netdev@ovs-netdev: > failed to put[modify] (Invalid > > argument) ufid:fd96553e-ce7f-47fe-a983-6e21b5a44d5f > skb_priority(0/0),skb_mark(0/0),ct_state(0/0),ct_zone > > > (0/0),ct_mark(0/0),ct_label(0/0),recirc_id(0),dp_hash(0/0),in_port(2),packet_type(ns=0,id=0),eth > > > (src=aa:55:00:00:00:01/00:00:00:00:00:00,dst=01:00:5e:00:00:16/00:00:00:00:00:00),eth_type > > (0x0800),ipv4(src= > 10.0.0.1/0.0.0.0,dst=224.0.0.22/0.0.0.0,proto=2/0,tos=0xc0/0,ttl=1/0,frag=no > ), > > actions:userspace(pid=0,slow_path(match)) > > > > Is there a problem with my environment or if this is a known issue. > > I think this is something in your environment sending multicast data > over the TAP device when it comes up. Can you check if the following > 'makes it happy': > > echo "0" > /proc/sys/net/ipv4/igmp_max_memberships > echo "0" > /proc/sys/net/ipv4/igmp_max_msf > > I think there are some unsolicited multicast messages flowing through > the tun device on creation. I'm not sure of the best way to fix up this > test case at the moment. > > > Thanks > > -Vasu > > > > Vasu Dasari > > > > > > > > ___ > > discuss mailing list > > disc...@openvswitch.org > > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] VxLAN in Userspace
On Tue, Jun 18, 2019 at 12:21 PM Flavio Leitner wrote: > On Tue, Jun 18, 2019 at 10:41:16AM -0400, Vasu Dasari wrote: > > Flavio, > > > > The device(could be a regular interface) should have been added to OVS > with > > "add-port" and when it is removed, ARP entries learnt on it well be > removed > > as well. > > Not necessarily. You could have a regular kernel interface with the > tunnel endpoint address which is not part of an OVS bridge. > The code being added should cover that as well. Probably you can comment on this after you look at my code. > > > The code is ready. Regarding, testing the code I am planning on extending > > already existing case where tests are performed to check ARP entry > > existence, like for example, "tunnel_push_pop - underlay bridge match" in > > tunnel-push-pop.at. I hope that is fine, or should I be writing a > separate > > unit test case? > > Usually we just add more tests to the file to cover additional > use-cases. > > Ok. Will add a new test case then. On another note, I see ARP neighbor add and show commands. This covers L3 side. For L2 side, I see fdb show command, but there is no set command. I would like to add that one also. Any comments? Current fdb show: ovs-appctl fdb/show s1 Proposed CLI for fdb/set operation would look like: ovs-appctl fdb/set ovs-appctl fdb/set s1 2 0 00:00:01:00:00:02 What do you think? Thanks -Vasu fbl > > > > > -Vasu > > > > *Vasu Dasari* > > > > > > On Fri, Jun 14, 2019 at 9:15 AM Flavio Leitner wrote: > > > > > On Thu, Jun 13, 2019 at 10:58:21PM -0400, Vasu Dasari wrote: > > > > Flavio, > > > > > > > > tnl_neigh_cache_flush(), flushes entire tunnel ARP table. When a > bridge > > > is > > > > removed, ARP entries learnt on that bridge alone have to be removed. > > > > Entries from other bridges have to be in tact. > > > > > > > > I am thinking of doing the following: > > > > > > > > 1. Write a new API in lib/tnl-neigh-cache.c: tnl_neigh_flush(const > char* > > > > br_name) which purges all neighbor entries on bridge br_name. > > > > > > That's better, indeed. > > > > > > > > > > 2. From ofproto/ofproto-dpif-xlate.c: xlate_xbridge_remove() invoke > the > > > > function tnl_neigh_flush () to flush the entries. > > > > > > > > til_neigh_xxx() functions are getting called from > ofproto-dpif-xlate.c, > > > and > > > > hence thinking that xlate_xbridge_remove() is a right place to do the > > > job. > > > > > > > > What do you think? > > > > > > The device with the IP address can be any regular interface, so > > > do you think it would work if you remove a device that is out of > > > OVS? > > > > > > fbl > > > > > > > > > > > -Vasu > > > > > > > > > > > > On Thu, Jun 13, 2019 at 7:27 PM Vasu Dasari > wrote: > > > > > > > > > Yes Flavio. Looking at code to fix this. Will send fix for review > soon. > > > > > > > > > > Vasu > > > > > > > > > > > On Jun 13, 2019, at 7:15 PM, Flavio Leitner > > > wrote: > > > > > > > > > > > >> On Wed, Jun 12, 2019 at 07:18:27PM -0400, Vasu Dasari wrote: > > > > > >> Thanks Ben. Meanwhile I think I found an bug in OVS 2.9.0 with > > > stale ARP > > > > > >> entries after a bridge is deleted. > > > > > >> > > > > > >> I ran my tunneling experiment successfully. Used mininet to > > > simulate the > > > > > >> environment. After quitting the mininet, switch s1 is deleted. > But, > > > I > > > > > still > > > > > >> see the ARP entries in OVS. > > > > > > > > > > > > Looks like when route_table_valid is false we also need to > > > > > > call tnl_neigh_cache_flush() otherwise you will need to wait > > > > > > the ARP entry in the cache to expire (15min?) which is quite > > > > > > a long time. > > > > > > > > > > > > Do you think you can work on a patch? > > > > > > > > > > > >> root@mn1:~# ovs-vsctl show > > > > > >> f6af5f1c-a11c-435f-9b03-7317f364ae48 > > > > > >>Manager "ptcp:6640" > >
Re: [ovs-discuss] VxLAN in Userspace
Flavio, The device(could be a regular interface) should have been added to OVS with "add-port" and when it is removed, ARP entries learnt on it well be removed as well. The code is ready. Regarding, testing the code I am planning on extending already existing case where tests are performed to check ARP entry existence, like for example, "tunnel_push_pop - underlay bridge match" in tunnel-push-pop.at. I hope that is fine, or should I be writing a separate unit test case? -Vasu *Vasu Dasari* On Fri, Jun 14, 2019 at 9:15 AM Flavio Leitner wrote: > On Thu, Jun 13, 2019 at 10:58:21PM -0400, Vasu Dasari wrote: > > Flavio, > > > > tnl_neigh_cache_flush(), flushes entire tunnel ARP table. When a bridge > is > > removed, ARP entries learnt on that bridge alone have to be removed. > > Entries from other bridges have to be in tact. > > > > I am thinking of doing the following: > > > > 1. Write a new API in lib/tnl-neigh-cache.c: tnl_neigh_flush(const char* > > br_name) which purges all neighbor entries on bridge br_name. > > That's better, indeed. > > > > 2. From ofproto/ofproto-dpif-xlate.c: xlate_xbridge_remove() invoke the > > function tnl_neigh_flush () to flush the entries. > > > > til_neigh_xxx() functions are getting called from ofproto-dpif-xlate.c, > and > > hence thinking that xlate_xbridge_remove() is a right place to do the > job. > > > > What do you think? > > The device with the IP address can be any regular interface, so > do you think it would work if you remove a device that is out of > OVS? > > fbl > > > > > -Vasu > > > > > > On Thu, Jun 13, 2019 at 7:27 PM Vasu Dasari wrote: > > > > > Yes Flavio. Looking at code to fix this. Will send fix for review soon. > > > > > > Vasu > > > > > > > On Jun 13, 2019, at 7:15 PM, Flavio Leitner > wrote: > > > > > > > >> On Wed, Jun 12, 2019 at 07:18:27PM -0400, Vasu Dasari wrote: > > > >> Thanks Ben. Meanwhile I think I found an bug in OVS 2.9.0 with > stale ARP > > > >> entries after a bridge is deleted. > > > >> > > > >> I ran my tunneling experiment successfully. Used mininet to > simulate the > > > >> environment. After quitting the mininet, switch s1 is deleted. But, > I > > > still > > > >> see the ARP entries in OVS. > > > > > > > > Looks like when route_table_valid is false we also need to > > > > call tnl_neigh_cache_flush() otherwise you will need to wait > > > > the ARP entry in the cache to expire (15min?) which is quite > > > > a long time. > > > > > > > > Do you think you can work on a patch? > > > > > > > >> root@mn1:~# ovs-vsctl show > > > >> f6af5f1c-a11c-435f-9b03-7317f364ae48 > > > >>Manager "ptcp:6640" > > > >>ovs_version: "2.9.0" > > > >> > > > >> Even thought there is no s1, I still see entries here. > > > >> root@mn1:~# ovs-appctl tnl/arp/show > > > >> IPMAC > Bridge > > > >> > > > > == > > > >> 172.168.1.1 02:42:ac:14:00:02 s1 > > > >> 172.168.1.2 02:42:ac:14:00:03 s1 > > > >> 10.0.0.10 82:ec:29:c0:bc:ef s1 > > > >> 10.0.0.1 d2:54:11:f0:95:df s1 > > > >> > > > >> > > > >> Just for completeness, this is what I had to do to fix my > configuration. > > > >> > > > >> Figured out what was wrong with my configuration. > > > >> > > > >> Modify my bridge s1 to be: > > > >> > > > >> ovs-vsctl --may-exist add-br s1 \ > > > >>-- set Bridge s1 datapath_type=netdev \ > > > >>-- set bridge s1 fail-mode=standalone \ > > > >> other_config:hwaddr=$(cat /sys/class/net/eth1/address) > > > >> > > > >> Add the flows: > > > >> ovs-ofctl add-flow s1 "priority=1,in_port=s1-eth1 actions=vxlan" > > > >> ovs-ofctl add-flow s1 "priority=1,in_port=vxlan actions=s1-eth1" > > > >> ovs-ofctl add-flow s1 "priority=0 actions=NORMAL"
Re: [ovs-discuss] VxLAN in Userspace
Flavio, tnl_neigh_cache_flush(), flushes entire tunnel ARP table. When a bridge is removed, ARP entries learnt on that bridge alone have to be removed. Entries from other bridges have to be in tact. I am thinking of doing the following: 1. Write a new API in lib/tnl-neigh-cache.c: tnl_neigh_flush(const char* br_name) which purges all neighbor entries on bridge br_name. 2. From ofproto/ofproto-dpif-xlate.c: xlate_xbridge_remove() invoke the function tnl_neigh_flush () to flush the entries. til_neigh_xxx() functions are getting called from ofproto-dpif-xlate.c, and hence thinking that xlate_xbridge_remove() is a right place to do the job. What do you think? -Vasu On Thu, Jun 13, 2019 at 7:27 PM Vasu Dasari wrote: > Yes Flavio. Looking at code to fix this. Will send fix for review soon. > > Vasu > > > On Jun 13, 2019, at 7:15 PM, Flavio Leitner wrote: > > > >> On Wed, Jun 12, 2019 at 07:18:27PM -0400, Vasu Dasari wrote: > >> Thanks Ben. Meanwhile I think I found an bug in OVS 2.9.0 with stale ARP > >> entries after a bridge is deleted. > >> > >> I ran my tunneling experiment successfully. Used mininet to simulate the > >> environment. After quitting the mininet, switch s1 is deleted. But, I > still > >> see the ARP entries in OVS. > > > > Looks like when route_table_valid is false we also need to > > call tnl_neigh_cache_flush() otherwise you will need to wait > > the ARP entry in the cache to expire (15min?) which is quite > > a long time. > > > > Do you think you can work on a patch? > > > >> root@mn1:~# ovs-vsctl show > >> f6af5f1c-a11c-435f-9b03-7317f364ae48 > >>Manager "ptcp:6640" > >>ovs_version: "2.9.0" > >> > >> Even thought there is no s1, I still see entries here. > >> root@mn1:~# ovs-appctl tnl/arp/show > >> IPMAC Bridge > >> > == > >> 172.168.1.1 02:42:ac:14:00:02 s1 > >> 172.168.1.2 02:42:ac:14:00:03 s1 > >> 10.0.0.10 82:ec:29:c0:bc:ef s1 > >> 10.0.0.1 d2:54:11:f0:95:df s1 > >> > >> > >> Just for completeness, this is what I had to do to fix my configuration. > >> > >> Figured out what was wrong with my configuration. > >> > >> Modify my bridge s1 to be: > >> > >> ovs-vsctl --may-exist add-br s1 \ > >>-- set Bridge s1 datapath_type=netdev \ > >>-- set bridge s1 fail-mode=standalone \ > >> other_config:hwaddr=$(cat /sys/class/net/eth1/address) > >> > >> Add the flows: > >> ovs-ofctl add-flow s1 "priority=1,in_port=s1-eth1 actions=vxlan" > >> ovs-ofctl add-flow s1 "priority=1,in_port=vxlan actions=s1-eth1" > >> ovs-ofctl add-flow s1 "priority=0 actions=NORMAL" > >> > >> ip addr add 1.1.1.1/24 dev s1 > >> ip link set s1 up > >> ip addr flush dev eth1 2>/dev/null > >> ip link set eth1 up > >> > >> ovs-appctl tnl/arp/set s1 1.1.1.2 00:00:01:00:00:02 > > > > Yeah, that will replace the old entry with the new one. > > > > fbl > > > > > >> > >> *Vasu Dasari* > >> > >> > >>> On Tue, Jun 11, 2019 at 6:22 PM Ben Pfaff wrote: > >>> > >>>> On Tue, Jun 11, 2019 at 03:17:24PM -0400, Vasu Dasari wrote: > >>>> I am running into an issue which sounds pretty basic, probably I > might be > >>>> missing something. > >>> > >>> I think you're trying to use kernel tools to configure userspace > >>> tunnels. Did you read Documentation/howto/userspace-tunneling.rst? > >>> > > > >> ___ > >> discuss mailing list > >> disc...@openvswitch.org > >> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > > > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] VxLAN in Userspace
Yes Flavio. Looking at code to fix this. Will send fix for review soon. Vasu > On Jun 13, 2019, at 7:15 PM, Flavio Leitner wrote: > >> On Wed, Jun 12, 2019 at 07:18:27PM -0400, Vasu Dasari wrote: >> Thanks Ben. Meanwhile I think I found an bug in OVS 2.9.0 with stale ARP >> entries after a bridge is deleted. >> >> I ran my tunneling experiment successfully. Used mininet to simulate the >> environment. After quitting the mininet, switch s1 is deleted. But, I still >> see the ARP entries in OVS. > > Looks like when route_table_valid is false we also need to > call tnl_neigh_cache_flush() otherwise you will need to wait > the ARP entry in the cache to expire (15min?) which is quite > a long time. > > Do you think you can work on a patch? > >> root@mn1:~# ovs-vsctl show >> f6af5f1c-a11c-435f-9b03-7317f364ae48 >>Manager "ptcp:6640" >>ovs_version: "2.9.0" >> >> Even thought there is no s1, I still see entries here. >> root@mn1:~# ovs-appctl tnl/arp/show >> IPMAC Bridge >> == >> 172.168.1.1 02:42:ac:14:00:02 s1 >> 172.168.1.2 02:42:ac:14:00:03 s1 >> 10.0.0.10 82:ec:29:c0:bc:ef s1 >> 10.0.0.1 d2:54:11:f0:95:df s1 >> >> >> Just for completeness, this is what I had to do to fix my configuration. >> >> Figured out what was wrong with my configuration. >> >> Modify my bridge s1 to be: >> >> ovs-vsctl --may-exist add-br s1 \ >>-- set Bridge s1 datapath_type=netdev \ >>-- set bridge s1 fail-mode=standalone \ >> other_config:hwaddr=$(cat /sys/class/net/eth1/address) >> >> Add the flows: >> ovs-ofctl add-flow s1 "priority=1,in_port=s1-eth1 actions=vxlan" >> ovs-ofctl add-flow s1 "priority=1,in_port=vxlan actions=s1-eth1" >> ovs-ofctl add-flow s1 "priority=0 actions=NORMAL" >> >> ip addr add 1.1.1.1/24 dev s1 >> ip link set s1 up >> ip addr flush dev eth1 2>/dev/null >> ip link set eth1 up >> >> ovs-appctl tnl/arp/set s1 1.1.1.2 00:00:01:00:00:02 > > Yeah, that will replace the old entry with the new one. > > fbl > > >> >> *Vasu Dasari* >> >> >>> On Tue, Jun 11, 2019 at 6:22 PM Ben Pfaff wrote: >>> >>>> On Tue, Jun 11, 2019 at 03:17:24PM -0400, Vasu Dasari wrote: >>>> I am running into an issue which sounds pretty basic, probably I might be >>>> missing something. >>> >>> I think you're trying to use kernel tools to configure userspace >>> tunnels. Did you read Documentation/howto/userspace-tunneling.rst? >>> > >> ___ >> discuss mailing list >> disc...@openvswitch.org >> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] VxLAN in Userspace
Thanks Ben. Meanwhile I think I found an bug in OVS 2.9.0 with stale ARP entries after a bridge is deleted. I ran my tunneling experiment successfully. Used mininet to simulate the environment. After quitting the mininet, switch s1 is deleted. But, I still see the ARP entries in OVS. root@mn1:~# ovs-vsctl show f6af5f1c-a11c-435f-9b03-7317f364ae48 Manager "ptcp:6640" ovs_version: "2.9.0" Even thought there is no s1, I still see entries here. root@mn1:~# ovs-appctl tnl/arp/show IPMAC Bridge == 172.168.1.1 02:42:ac:14:00:02 s1 172.168.1.2 02:42:ac:14:00:03 s1 10.0.0.10 82:ec:29:c0:bc:ef s1 10.0.0.1 d2:54:11:f0:95:df s1 Just for completeness, this is what I had to do to fix my configuration. Figured out what was wrong with my configuration. Modify my bridge s1 to be: ovs-vsctl --may-exist add-br s1 \ -- set Bridge s1 datapath_type=netdev \ -- set bridge s1 fail-mode=standalone \ other_config:hwaddr=$(cat /sys/class/net/eth1/address) Add the flows: ovs-ofctl add-flow s1 "priority=1,in_port=s1-eth1 actions=vxlan" ovs-ofctl add-flow s1 "priority=1,in_port=vxlan actions=s1-eth1" ovs-ofctl add-flow s1 "priority=0 actions=NORMAL" ip addr add 1.1.1.1/24 dev s1 ip link set s1 up ip addr flush dev eth1 2>/dev/null ip link set eth1 up ovs-appctl tnl/arp/set s1 1.1.1.2 00:00:01:00:00:02 *Vasu Dasari* On Tue, Jun 11, 2019 at 6:22 PM Ben Pfaff wrote: > On Tue, Jun 11, 2019 at 03:17:24PM -0400, Vasu Dasari wrote: > > I am running into an issue which sounds pretty basic, probably I might be > > missing something. > > I think you're trying to use kernel tools to configure userspace > tunnels. Did you read Documentation/howto/userspace-tunneling.rst? > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] VxLAN in Userspace
Hi,
I am running into an issue which sounds pretty basic, probably I might be
missing something.
Using, OVS: 2.9.0:
1. Created a mininet instance using:
mn --topo single,3
2. Converted switch s1 to userspace switch and executed following commands:
# Delete controller
ovs-vsctl del-controller s1
#Convert s1 to userspace switch
ovs-vsctl set Bridge s1 datapath_type=netdev
# Add a VxLAN interface
ovs-vsctl add-port s1 vxlan -- set Interface vxlan type=vxlan \
options:key=5 options:local_ip=1.1.1.1 options:remote_ip=1.1.1.2
ofport_request=10
# Add a Flow to pick any packet coming in on port 1(s1-eth1) egress out of
vlan port
ovs-ofctl add-flow s1 "table=0,in_port=1 actions=output:10"
# Configure s1-eth3 to be the interface which connects to 1.1.1.0/24
ifconfig s1-eth3 1.1.1.1
arp -s 1.1.1.2 00:00:01:00:00:01
3. Now, I started ping h1 to h2 via mininet CLI.
I expected to see VxLAN tagged packets on s1-eth3. But I do not.
When I do ofproto/trace I see an error appears, "native tunnel routing
failed"
root@mininet:~# ovs-ofctl dump-flows s1
cookie=0x0, duration=197.045s, table=0, n_packets=3, n_bytes=210,
in_port="s1-eth1" actions=output:vxlan
root@mininet:~# ovs-appctl ofproto/trace s1
in_port=1,dl_dst=00:01:02:03:04:05
Flow:
in_port=1,vlan_tci=0x,dl_src=00:00:00:00:00:00,dl_dst=00:01:02:03:04:05,dl_type=0x
bridge("s1")
0. in_port=1, priority 32768
output:10
-> output to native tunnel
>> native tunnel routing failed
Final flow: unchanged
Megaflow: recirc_id=0,eth,in_port=1,dl_type=0x
Datapath actions: drop
root@mininet:~# ovs-appctl ovs/route/lookup 1.1.1.2
src 1.1.1.1
gateway ::
dev s1-eth3
Question is: Is there anything extra I need to configure if the switch were
to use userspace datapath? Or what I am seeing is a bug?
If I do the same configuration on kernel datapath mode(everything except
the step which changes bridge datapath type), I see VxLAN packets on
s1-eth3.
Thanks
*Vasu Dasari*
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] VxLAN Configuration
Sure Ben. Let me see what I can do. -Vasu *Vasu Dasari* On Tue, Jun 4, 2019 at 2:02 PM Ben Pfaff wrote: > One could add support to OVS for this model of VXLAN and other > protocols. I do not see how tun_metadataXX is relevant to VXLAN, > because it does not have Geneve- or NSH-like TLV options. > > On Tue, Jun 04, 2019 at 01:48:56PM -0400, Vasu Dasari wrote: > > Ben, > > > > Do you think, is there a way I can use "tun_metadataXX" infrastructure > with > > "push" and "pop" actions to achieve adding and remove headers? Or these > > operations are quite centric to ash/geneveve, etc?? > > > > -Vasu > > > > *Vasu Dasari* > > > > > > On Tue, Jun 4, 2019 at 1:13 PM Ben Pfaff wrote: > > > > > On Mon, Jun 03, 2019 at 09:33:03PM -0400, Vasu Dasari wrote: > > > > I would like to specify VxLAN header fields in its entirety. That is, > > > would > > > > like to specify following fields of the VxLAN packet:, > > > > > > > > Output port: Physical port from which frame needs to leave. > > > > Encapsulated L2 header: Ethernet Source, Destination, Vlan Tag > > > > Encapsulated L3 header: IP source, Ip destination > > > > VxLAN Header: VNI > > > > > > > > I see that I can specify L3 and VNI fields using, tun-src, tun-dst, > > > tun-id > > > > fields. > > > > I am wondering how would I specify encapsulated L2 header and > physical > > > > output port information? > > > > > > OVS doesn't currently implement VXLAN that way. > > > > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] VxLAN Configuration
Ben, Do you think, is there a way I can use "tun_metadataXX" infrastructure with "push" and "pop" actions to achieve adding and remove headers? Or these operations are quite centric to ash/geneveve, etc?? -Vasu *Vasu Dasari* On Tue, Jun 4, 2019 at 1:13 PM Ben Pfaff wrote: > On Mon, Jun 03, 2019 at 09:33:03PM -0400, Vasu Dasari wrote: > > I would like to specify VxLAN header fields in its entirety. That is, > would > > like to specify following fields of the VxLAN packet:, > > > > Output port: Physical port from which frame needs to leave. > > Encapsulated L2 header: Ethernet Source, Destination, Vlan Tag > > Encapsulated L3 header: IP source, Ip destination > > VxLAN Header: VNI > > > > I see that I can specify L3 and VNI fields using, tun-src, tun-dst, > tun-id > > fields. > > I am wondering how would I specify encapsulated L2 header and physical > > output port information? > > OVS doesn't currently implement VXLAN that way. > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] VxLAN Configuration
Hi, I would like to specify VxLAN header fields in its entirety. That is, would like to specify following fields of the VxLAN packet:, Output port: Physical port from which frame needs to leave. Encapsulated L2 header: Ethernet Source, Destination, Vlan Tag Encapsulated L3 header: IP source, Ip destination VxLAN Header: VNI I see that I can specify L3 and VNI fields using, tun-src, tun-dst, tun-id fields. I am wondering how would I specify encapsulated L2 header and physical output port information? Without specifying L2 information explicitly, OVS will construct the frame as per the Linux routing, ARP table and interface information. Consider the following topology, where I would like to encapsulate traffic between V1 and V2, S1 and S3 are VTEPs here. ARP for S3 would have been learnt over path P1. But I would like to send tunneled traffic from S1 to S3 on path P2. ++ || +--P1 -+ S2 +P1+ | || | | ++ | | | +-+--+ +-+--+ || || V1 ++ S1 | | S3 +--+ V2 || || +-+--+ +-+--+ | | | ++ | | || | +--P2--+ S4 +-P2---+ || ++ I tried this command, but it did not work. I know it will not be this simple :) ovs-ofctl add-flow s1 "table=0,in_port=2 actions=\ set_field:00:00:01:01:01:01->eth_dst, \ set_field:00:00:02:02:02:02->eth_src, \ set_field:5->tun_id, \ set_field:1.1.1.1->tun_src, \ set_field:2.2.2.2->tun_dst, \ output:1 \ " Can someone please help me with this? Thanks -Vasu *Vasu Dasari* ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Flow Monitoring
Thanks for the clarification. *Vasu Dasari* On Thu, May 23, 2019 at 11:39 PM Ben Pfaff wrote: > On Thu, May 23, 2019 at 10:46:40PM -0400, Vasu Dasari wrote: > > Thanks for digging into this. My comments inline. I am sorry that I had > to > > differ from your analysis. > > Thank you for the correction. You are right: this is buggy. OVS does > not and should not claim to support flow monitoring except as an OVS > extension. I knew that the support was not there before, although I > though we had added it recently, but I did not know that OVS tried > to support it before. > > Ashish submitted a patch back in January to add full support: > https://mail.openvswitch.org/pipermail/ovs-dev/2019-January/355778.html > and we discussed it a bit: > https://mail.openvswitch.org/pipermail/ovs-dev/2019-February/355901.html > but I do not know of a v3. > > Ashish, is there a newer version of this patch? > > However, for 2.11 and earlier, I expect that the best we can do is to > simply change this request so that it provokes an error. > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Flow Monitoring
Thanks for digging into this. My comments inline. I am sorry that I had to differ from your analysis. *Vasu Dasari* On Thu, May 23, 2019 at 5:54 PM Ben Pfaff wrote: > On Thu, May 23, 2019 at 04:37:41PM -0400, Vasu Dasari wrote: > > There are two "flags" fields in tcpdump output I shared earlier. > > 1. First one is 0 which is part of OFPT_MULTIPART_REQUEST, saying there > are > > no more parts. This is first two bytes in row 0040 > > 2. And second one is "00 01" and it is indicating to receive "add" > > notifications. And these are 2nd two bytes in row 0050. > > > > Can you tell which bytes do you think are representing "flags" field in > > above bytes output? > > > > You can open the pcap file in Wireshark to see my analysis. > > Stripping off the TCP and other headers, we have the following: > > 05 12 00 28 00 00 00 00-00 10 00 00 00 00 00 00 > |...(| > 0010 05 f5 e1 00 00 00 00 00-ff ff ff ff 00 01 00 00 > || > 0020 00 01 00 04 00 00 00 00-| > | > > "05 f5 e1 00" is the id, the following 00 00 is the flags. > 05 f5 e1 00 => Is Monitor Id which is decimal 1, set by controller. And field after that is "00 00 00 00" which is Out Port. ff ff ff ff => Out Group 00 01 => Monitor Flags, "Initial" bit is set. 00 => Table Id - 0 00 => Add Operation So from above parsing I see that flags is set as "00 01". > > > Also, is there a specification for nicera extensions? Can you please > point > > it to me? > > Beyond the 100+ relevant lines of comments in nicira-ext.h? No. > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Flow Monitoring
There are two "flags" fields in tcpdump output I shared earlier. 1. First one is 0 which is part of OFPT_MULTIPART_REQUEST, saying there are no more parts. This is first two bytes in row 0040 2. And second one is "00 01" and it is indicating to receive "add" notifications. And these are 2nd two bytes in row 0050. Can you tell which bytes do you think are representing "flags" field in above bytes output? You can open the pcap file in Wireshark to see my analysis. Also, is there a specification for nicera extensions? Can you please point it to me? -Vasu *Vasu Dasari* On Thu, May 23, 2019 at 4:17 PM Ben Pfaff wrote: > On Wed, May 22, 2019 at 01:30:19PM -0400, Vasu Dasari wrote: > > Here is the data: > > > > Request: > > 02 42 ac 18 00 02 02 42 c7 b9 8f ef 08 00 45 00 .B.B..E. > > 0010 00 50 22 94 00 00 25 06 c5 4f c0 a8 41 02 ac 18 .P"...%..O..A... > > 0020 00 02 19 fe d4 22 1a fe f8 dd a4 5c 18 1d 50 18 .".\..P. > > 0030 ff ff 57 23 00 00 05 12 00 28 00 00 00 00 00 10 ..W#.(.. > > 0040 00 00 00 00 00 00 05 f5 e1 00 00 00 00 00 ff ff > > 0050 ff ff 00 01 00 00 00 01 00 04 00 00 00 00.. > > This request has a flags word of 0. The flags word has to request > notifications for at least one of add or delete or modify operations, > otherwise there's no point since no notifications would ever occur. > Therefore, OVS rejects the request. > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Flow Monitoring
Hi Ben,
I see that from nicer-ext.h:
struct nx_flow_monitor_request {
ovs_be32 id;/* Controller-assigned ID for this monitor.
*/
ovs_be16 flags; /* NXFMF_*. */
ovs_be16 out_port; /* Required output port, if not OFPP_NONE.
*/
ovs_be16 match_len; /* Length of nx_match. */
uint8_t table_id; /* One table's ID or 0xff for all tables. */
uint8_t zeros[5]; /* Align to 64 bits (must be zero). */
/* Followed by:
* - Exactly match_len (possibly 0) bytes containing the nx_match,
then
* - Exactly (match_len + 7)/8*8 - match_len (between 0 and 7) bytes
of
* all-zero bytes. */
};
But, the data populated by controller is in the following sequence:
monitor_id: 32,
out_port: 16,
out_group: 16,
monitor_flags: 16,
table_id: 8,
command: 8,
match_and_padding
The place where the flags is being extracted
ofputil_decode_flow_monitor_request(),
I see that flags is extracted first. This could be an issue.
I have't tried out my assumption yet. Does it make sense??
Could this be a software bug?
Thanks,
-Vasu
*Vasu Dasari*
On Wed, May 22, 2019 at 1:30 PM Vasu Dasari wrote:
> Here is the data:
>
> Request:
> 02 42 ac 18 00 02 02 42 c7 b9 8f ef 08 00 45 00 .B.B..E.
> 0010 00 50 22 94 00 00 25 06 c5 4f c0 a8 41 02 ac 18 .P"...%..O..A...
> 0020 00 02 19 fe d4 22 1a fe f8 dd a4 5c 18 1d 50 18 .".\..P.
> 0030 ff ff 57 23 00 00 05 12 00 28 00 00 00 00 00 10 ..W#.(..
> 0040 00 00 00 00 00 00 05 f5 e1 00 00 00 00 00 ff ff
> 0050 ff ff 00 01 00 00 00 01 00 04 00 00 00 00..
>
> Response:
> 02 42 c7 b9 8f ef 02 42 ac 18 00 02 08 00 45 c0 .B.B..E.
> 0010 00 5c 57 db 40 00 40 06 34 3c ac 18 00 02 c0 a8 .\W.@.@.4<..
> 0020 41 02 d4 22 19 fe a4 5c 18 1d 1a fe f9 05 50 18 A.."...\..P.
> 0030 04 b0 ae 13 00 00 05 01 00 34 00 00 00 00 00 10 .4..
> 0040 00 05 05 12 00 28 00 00 00 00 00 10 00 00 00 00 .(..
> 0050 00 00 05 f5 e1 00 00 00 00 00 ff ff ff ff 00 01
> 0060 00 00 00 01 00 04 00 00 00 00 ..
>
> Also attaching pcap file.
>
> Thanks
> -Vasu
>
> *Vasu Dasari*
>
>
> On Wed, May 22, 2019 at 12:45 PM Ben Pfaff wrote:
>
>> On Wed, May 22, 2019 at 10:31:13AM -0400, Vasu Dasari wrote:
>> > Hi,
>> >
>> > I am trying to perform flow monitoring from my controller. Constructed
>> the
>> > packet as follows:
>> >
>> > OpenFlow 1.4
>> > Version: 1.4 (0x05)
>> > Type: OFPT_MULTIPART_REQUEST (18)
>> > Length: 40
>> > Transaction ID: 0
>> > Type: OFPMP_FLOW_MONITOR (16)
>> > Flags: 0x
>> > ...0 = OFPMPF_REQ_MORE: 0x0
>> > Pad:
>> > Monitor ID: 1
>> > Out port: 0
>> > Out group: OFPG_ANY (0x)
>> > Flags: 0x000f
>> > ...1 = OFPFMF_INITIAL: 0x1
>> > ..1. = OFPFMF_ADD: 0x1
>> > .1.. = OFPFMF_REMOVED: 0x1
>> > 1... = OFPFMF_MODIFY: 0x1
>> > ...0 = OFPFMF_INSTRUCTIONS: 0x0
>> > ..0. = OFPFMF_NO_ABBREV: 0x0
>> > .0.. = OFPFMF_ONLY_OWN: 0x0
>> > Table ID: 0
>> > Command: OFPFMC_ADD (0)
>> > Match
>> > Type: OFPMT_OXM (1)
>> > Length: 4
>> > Pad:
>>
>> Would you please provide a hex or binary dump of the request? I will
>> check it out.
>>
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Flow Monitoring
Here is the data: Request: 02 42 ac 18 00 02 02 42 c7 b9 8f ef 08 00 45 00 .B.B..E. 0010 00 50 22 94 00 00 25 06 c5 4f c0 a8 41 02 ac 18 .P"...%..O..A... 0020 00 02 19 fe d4 22 1a fe f8 dd a4 5c 18 1d 50 18 .".\..P. 0030 ff ff 57 23 00 00 05 12 00 28 00 00 00 00 00 10 ..W#.(.. 0040 00 00 00 00 00 00 05 f5 e1 00 00 00 00 00 ff ff 0050 ff ff 00 01 00 00 00 01 00 04 00 00 00 00.. Response: 02 42 c7 b9 8f ef 02 42 ac 18 00 02 08 00 45 c0 .B.B..E. 0010 00 5c 57 db 40 00 40 06 34 3c ac 18 00 02 c0 a8 .\W.@.@.4<.. 0020 41 02 d4 22 19 fe a4 5c 18 1d 1a fe f9 05 50 18 A.."...\..P. 0030 04 b0 ae 13 00 00 05 01 00 34 00 00 00 00 00 10 .4.. 0040 00 05 05 12 00 28 00 00 00 00 00 10 00 00 00 00 .(.. 0050 00 00 05 f5 e1 00 00 00 00 00 ff ff ff ff 00 01 0060 00 00 00 01 00 04 00 00 00 00.. Also attaching pcap file. Thanks -Vasu *Vasu Dasari* On Wed, May 22, 2019 at 12:45 PM Ben Pfaff wrote: > On Wed, May 22, 2019 at 10:31:13AM -0400, Vasu Dasari wrote: > > Hi, > > > > I am trying to perform flow monitoring from my controller. Constructed > the > > packet as follows: > > > > OpenFlow 1.4 > > Version: 1.4 (0x05) > > Type: OFPT_MULTIPART_REQUEST (18) > > Length: 40 > > Transaction ID: 0 > > Type: OFPMP_FLOW_MONITOR (16) > > Flags: 0x > > ...0 = OFPMPF_REQ_MORE: 0x0 > > Pad: > > Monitor ID: 1 > > Out port: 0 > > Out group: OFPG_ANY (0x) > > Flags: 0x000f > > ...1 = OFPFMF_INITIAL: 0x1 > > ..1. = OFPFMF_ADD: 0x1 > > .1.. = OFPFMF_REMOVED: 0x1 > > 1... = OFPFMF_MODIFY: 0x1 > > ...0 = OFPFMF_INSTRUCTIONS: 0x0 > > ..0. = OFPFMF_NO_ABBREV: 0x0 > > .0.. = OFPFMF_ONLY_OWN: 0x0 > > Table ID: 0 > > Command: OFPFMC_ADD (0) > > Match > > Type: OFPMT_OXM (1) > > Length: 4 > > Pad: > > Would you please provide a hex or binary dump of the request? I will > check it out. > flow_monitor.pcap Description: Binary data ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] Flow Monitoring
Hi, I am trying to perform flow monitoring from my controller. Constructed the packet as follows: OpenFlow 1.4 Version: 1.4 (0x05) Type: OFPT_MULTIPART_REQUEST (18) Length: 40 Transaction ID: 0 Type: OFPMP_FLOW_MONITOR (16) Flags: 0x ...0 = OFPMPF_REQ_MORE: 0x0 Pad: Monitor ID: 1 Out port: 0 Out group: OFPG_ANY (0x) Flags: 0x000f ...1 = OFPFMF_INITIAL: 0x1 ..1. = OFPFMF_ADD: 0x1 .1.. = OFPFMF_REMOVED: 0x1 1... = OFPFMF_MODIFY: 0x1 ...0 = OFPFMF_INSTRUCTIONS: 0x0 ..0. = OFPFMF_NO_ABBREV: 0x0 .0.. = OFPFMF_ONLY_OWN: 0x0 Table ID: 0 Command: OFPFMC_ADD (0) Match Type: OFPMT_OXM (1) Length: 4 Pad: I am not sure what is wrong in this packet, but I get an error from OVS which is running 2.9. And here is it: OpenFlow 1.4 Version: 1.4 (0x05) Type: OFPT_ERROR (1) Length: 52 Transaction ID: 0 Type: OFPET_FLOW_MONITOR_FAILED (16) Code: OFPMOFC_BAD_FLAGS (5) Unknown error body. [Expert Info (Note/Undecoded): Unknown error body.] [Unknown error body.] [Severity level: Note] [Group: Undecoded] Can someone please let me know what is that I am doing wrong? I could do the monitor while I am on switch though using this command. So something from my controller it is not right. root@mininet:/setup# ovs-ofctl monitor s1 watch:\!initial NXST_FLOW_MONITOR reply (xid=0x4): NXST_FLOW_MONITOR reply (xid=0x0): event=ADDED table=1 cookie=0xa in_port="s1-eth1" actions=resubmit(,2) NXST_FLOW_MONITOR reply (xid=0x0): event=DELETED reason=delete table=1 cookie=0xa in_port="s1-eth1" actions=resubmit(,2) Thanks -Vasu *Vasu Dasari* ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
