Re: [ovs-discuss] Inactivity Probe configuration not taking effect in OVS 2.14.0

[Ben Pfaff]

I think you will have to get help from someone else.  I'm no longer
deeply involved in OVS.

On Mon, Oct 11, 2021 at 01:20:03PM +, Saurabh Deokate wrote:
> Hi Ben, do we have any update on this ?
> 
> On 08/09/21, 9:31 PM, "Saurabh Deokate"  wrote:
> 
> Hi Ben, do we have any update on this issue ?  
> 
> ~Saurabh.
> 
> On 24/08/21, 11:21 AM, "Saurabh Deokate"  
> wrote:
> 
> Hi Ben, can you please help us understand why are we seeing these 
> retrying even after setting inactivity_probe to 0. Are we missing on some 
> configuration ? 
> 
> ~Saurabh.
> 
> On 18/08/21, 11:50 AM, "Saurabh Deokate" 
>  wrote:
> 
> Hi Ben,
> 
> I tested with latest OVS 2.16, which has your fix, even after 
> setting inactivity_probe to 0, we are still seeing ovs retrying after every 5 
> sec. 
> Can you please help us with this ?
> 
> Here are the details - 
> root@ip-10-192-20-160:/home/ubuntu# ovs-vsctl --version 
> ovs-vsctl (Open vSwitch) 2.16.0
> DB Schema 8.3.0
> 
> root@ip-10-192-20-160:/home/ubuntu# ovs-vsctl list controller 
> _uuid   : e2947bdf-3695-42d0-a8fc-5efc7c1a7a01
> connection_mode : []
> controller_burst_limit: []
> controller_queue_size: []
> controller_rate_limit: []
> enable_async_messages: []
> external_ids: {}
> inactivity_probe: 0
> is_connected: true
> local_gateway   : []
> local_ip: []
> local_netmask   : []
> max_backoff : []
> other_config: {}
> role: other
> status  : {last_error="Connection timed out", 
> sec_since_connect="7", sec_since_disconnect="9", state=IDLE}
> target  : "tcp:127.0.0.1:1"
> type: []
> 
> LOGS - /var/log//openvswitch/ovs-vswitchd.log  
> 
> 
> 2021-08-18T06:06:06.874Z|00830|rconn|ERR|br0<->tcp:127.0.0.1:1: no 
> response to inactivity probe after 5 seconds, disconnecting
> 
> 2021-08-18T06:06:07.884Z|00831|rconn|INFO|br0<->tcp:127.0.0.1:1: 
> connecting...
> 
> 2021-08-18T06:06:07.889Z|00832|rconn|INFO|br0<->tcp:127.0.0.1:1: connected
> 
> 2021-08-18T06:06:17.890Z|00833|rconn|ERR|br0<->tcp:127.0.0.1:1: no 
> response to inactivity probe after 5 seconds, disconnecting
> 
> 2021-08-18T06:06:18.903Z|00834|rconn|INFO|br0<->tcp:127.0.0.1:1: 
> connecting...
> 
> 2021-08-18T06:06:19.404Z|00835|rconn|INFO|br0<->tcp:127.0.0.1:1: connected
> 2021-08-18T06:06:20.405Z|00836|fail_open|INFO|Still in fail-open 
> mode after 184 seconds disconnected from controller
> 
> 2021-08-18T06:06:29.405Z|00837|rconn|ERR|br0<->tcp:127.0.0.1:1: no 
> response to inactivity probe after 5 seconds, disconnecting
> 
> 2021-08-18T06:06:30.419Z|00838|rconn|INFO|br0<->tcp:127.0.0.1:1: 
> connecting...
> 
> 2021-08-18T06:06:30.884Z|00839|rconn|INFO|br0<->tcp:127.0.0.1:1: connected
> 
> 2021-08-18T06:06:40.884Z|00840|rconn|ERR|br0<->tcp:127.0.0.1:1: no 
> response to inactivity probe after 5 seconds, disconnecting
> 
> 2021-08-18T06:06:41.884Z|00841|rconn|INFO|br0<->tcp:127.0.0.1:1: 
> connecting...
> 
> 2021-08-18T06:06:41.935Z|00842|rconn|INFO|br0<->tcp:127.0.0.1:1: connected
> 
> On 02/07/21, 11:40 PM, "Ben Pfaff"  wrote:
> 
> I just pushed the fixes to the repo, so it'll be released as 
> part of the
> next regular OVS release.
> 
> Building from a patch isn't any different from building any 
> other way.
> 
> On Thu, Jul 01, 2021 at 06:19:08AM +, Saurabh Deokate 
> wrote:
> > Hi Ben, 
> > 
> > I have two questions,
> > 1. When is this patch going to be released ? 
> > 2. Do we have any documentation for building modules from 
> patch?
> > 
> > On 28/06/21, 10:25 PM, "Ben Pfaff"  wrote:
> > 
> > I recommend trying the patches that I posted:
> 

Re: [ovs-discuss] OVN: Any objections for making logical router and logical switches tables indexed by name?

[Ben Pfaff]

On Tue, Aug 10, 2021 at 12:22:01PM -0400, Flavio Fernandes wrote:
> After listening to episode 72 of OVS Orbit [4], I would like to ask:
> does anyone have objections to adding "indexes": [["name"]], to the
> logical-router [2] and logical-switch [3] tables? I understand Ben's
> point on making the implementation of the locally-cached tables have
> these types of optimizations, but at the same time, I see these 2
> tables as low-hanging fruits when scaling deployments with lots of
> lr's and ls's. Unless there is an implementation that use nameless
> rows for these tables, I cannot think of a usage case where duplicate
> names are useful. Do you?

It seems likely that this will break deployments where they don't assign
meaningful names, but I don't have data to back that up.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] An error occurred while recompiling OVS

[Ben Pfaff]

On Wed, Aug 11, 2021 at 10:35:38AM +0800, mythosmonkeyking wrote:
> I used the following command to compile OVS and encountered an error, the 
> detailed error information is as follows:

I don't know why you're having trouble with Sphinx.  Maybe you can just
avoid building the documentation.

If you figure out the problem, please submit a more detailed bug report
or a patch.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] my email was ovs-bu...@openvswitch.org refused

[Ben Pfaff]

On Wed, Aug 11, 2021 at 10:06:11AM +0800, mythosmonkeyking wrote:
> I want to join the OVS discussion group and pay attention to relevant 
> developments. What do I need to do? I need help, thank you!!!

You have subscribed to ovs-dev and ovs-discuss.

> 
> When I email ovs-bu...@openvswitch.org my email was rejected when I was. 
> The content of the email I received is as follows:

The build mailing list is for automated build reports only.  Use
ovs-discuss for general discussion and ovs-dev for development.  This is
clearly stated on the list's webpage.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVSDB key, indexes

[Ben Pfaff]

On Mon, Aug 02, 2021 at 02:04:59PM +, Rutuja Umesh Madhure wrote:
> I had a question about key, indexes in ovsdb. Referring to
> RFC7047, the 'type'
> of a column can be a 'key'. What does that exactly mean.

OVSDB supports various kinds of types, including maps from keys to
values.  When a type isn't a map, OVSDB considers it to just contain
keys instead of key-value pairs.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [External] : Re: ovsdb-server --private-key=db:OVN_Northbound, SSL, private_key etc

[Ben Pfaff]

On Tue, Jul 20, 2021 at 10:27:30AM +0100, Brendan Doyle wrote:
> 
> 
> On 19/07/2021 17:32, Ben Pfaff wrote:
> > On Mon, Jul 19, 2021 at 04: 29:07PM +0100, Brendan Doyle wrote:
> > 
> > > When I start OVN/OVs using ovn-ctl /ovs-ctl the ovsdb-server processes 
> > > have
> > > SSL credentials of the form:
> > > 
> > > --private-key=db:Open_vSwitch,SSL,private_key
> > > --certificate=db:Open_vSwitch,SSL,certificate
> > > --bootstrap-ca-cert=db:Open_vSwitch,SSL,ca_cert
> > > 
> > > --private-key=db:OVN_Northbound,SSL,private_key
> > > --certificate=db:OVN_Northbound,SSL,certificate
> > > --ca-cert=db:OVN_Northbound,SSL,ca_cert
> > > --ssl-protocols=db:OVN_Northbound,SSL,ssl_protocols
> > > --ssl-ciphers=db:OVN_Northbound,SSL,ssl_ciphers
> > > 
> > > --private-key=db:OVN_Southbound,SSL,private_key
> > > --certificate=db:OVN_Southbound,SSL,certificate
> > > --ca-cert=db:OVN_Southbound,SSL,ca_cert
> > > --ssl-protocols=db:OVN_Southbound,SSL,ssl_protocols
> > > --ssl-ciphers=db:OVN_Southbound,SSL,ssl_ciphers
> > > 
> > >  From what I gather this means it gets these values from the database, 
> > > OVS,
> > > OVN North/South?
> > > 
> > > But does that mean that SSL is enabled by default and use a default set of
> > > credentials/cipers?
> > > 
> > > Or does it mean If these values (Open_vSwitch,SSL,certificate e,g) are not
> > > set in the OVS, or OVN North/South bound data base
> > > then the connections are not SSL.
> > > 
> > > And if the later is the case how are these set?
> > It means that SSL/TLS connections will use these values.  Whether SSL is
> > in use is separately configured.  If you see "pssl:..." in a remote,
> > that's an SSL one; "ptcp:..." is for non-SSL TCP.
> 
> 
> OK not used if SSL not configured. If SSL configured uses the credentials
> pointed to by
> --private-key etc, which can be in the Open_vSwitch, OVN_Northbound or
> OVN_Southbound
> databases in the specified table or else where. So wondering are there
> helper tools
> (ovn-ctl /ovs-ctl ?) to set these DB tables or are they created/manipulated
> by modifying the
> DB directly. Guess read the manual.

ovs-vsctl, ovn-nbctl, and ovn-sbctl have commands to manipulate these
tables.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Hello, please add my email address to subscribter.

[Ben Pfaff]

On Fri, Jul 16, 2021 at 02:06:30AM +, wen yuxuan wrote:
> Hello,when I try to subscribe
> ovs-discuss
> always appear "No ReCAPTCHA response provided ".

I'm sorry it didn't work.  I've subscribed you manually now.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ovsdb-server --private-key=db:OVN_Northbound, SSL, private_key etc

[Ben Pfaff]

On Mon, Jul 19, 2021 at 04:29:07PM +0100, Brendan Doyle wrote:
> When I start OVN/OVs using ovn-ctl /ovs-ctl the ovsdb-server processes have
> SSL credentials of the form:
> 
> --private-key=db:Open_vSwitch,SSL,private_key
> --certificate=db:Open_vSwitch,SSL,certificate
> --bootstrap-ca-cert=db:Open_vSwitch,SSL,ca_cert
> 
> --private-key=db:OVN_Northbound,SSL,private_key
> --certificate=db:OVN_Northbound,SSL,certificate
> --ca-cert=db:OVN_Northbound,SSL,ca_cert
> --ssl-protocols=db:OVN_Northbound,SSL,ssl_protocols
> --ssl-ciphers=db:OVN_Northbound,SSL,ssl_ciphers
> 
> --private-key=db:OVN_Southbound,SSL,private_key
> --certificate=db:OVN_Southbound,SSL,certificate
> --ca-cert=db:OVN_Southbound,SSL,ca_cert
> --ssl-protocols=db:OVN_Southbound,SSL,ssl_protocols
> --ssl-ciphers=db:OVN_Southbound,SSL,ssl_ciphers
> 
> From what I gather this means it gets these values from the database, OVS,
> OVN North/South?
> 
> But does that mean that SSL is enabled by default and use a default set of
> credentials/cipers?
> 
> Or does it mean If these values (Open_vSwitch,SSL,certificate e,g) are not
> set in the OVS, or OVN North/South bound data base
> then the connections are not SSL.
> 
> And if the later is the case how are these set?

It means that SSL/TLS connections will use these values.  Whether SSL is
in use is separately configured.  If you see "pssl:..." in a remote,
that's an SSL one; "ptcp:..." is for non-SSL TCP.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [ovn/ovs] hit and miss

[Ben Pfaff]

On Fri, Jul 16, 2021 at 11:26:45AM +0500, Ammad Syed wrote:
> I have checked ovs-dpctl stats.
> 
> Node01# ovs-dpctl show
> system@ovs-system:
>   lookups: hit:24147954 missed:294831 lost:4
>   flows: 21
>   masks: hit:161013147 total:4 hit/pkt:6.59
>   port 0: ovs-system (internal)
>   port 1: br-int (internal)
>   port 2: tapeee623a9-24
>   port 3: tap18ca5a79-10
>   port 4: br-vlan (internal)
>   port 5: bond0
>   port 6: genev_sys_6081 (geneve: packet_type=ptap)
>   port 8: tap0181d519-c0
>   port 9: tap630cd3eb-61
> 
> Node02# ovs-dpctl show
> system@ovs-system:
>   lookups: hit:23287526 missed:1140779 lost:5
>   flows: 19
>   masks: hit:196158405 total:11 hit/pkt:8.03
>   port 0: ovs-system (internal)
>   port 1: br-int (internal)
>   port 2: br-vlan (internal)
>   port 3: bond0
>   port 4: genev_sys_6081 (geneve: packet_type=ptap)
>   port 5: tap58e445c4-75
>   port 6: tap0181d519-c0
> 
> Are above stats ok or do I need to perform any other tuning on kernel or at
> ovs level ?

These stats don't stand out as unusual to me.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OFPFC_DELETE and OFPFC_DELETE_STRICT commands don't delete openflow rules

[Ben Pfaff]

Thanks.

This shows that there is some important difference between what the
controller is sending and what ovs-ofctl is sending, since the message
from ovs-ofctl works and the one from the controller does not.  It would
be helpful to get OVS's idea of what it's receiving from the controller.
You can make ovs-vswitchd dump all the OpenFlow it sends and receives to
the log by turning up the log level for the "vconn" module, for example
with:

ovs-appctl vlog/set vconn

On Fri, Jul 16, 2021 at 06:37:18PM +0200, alejandro.llor...@entel.upc.edu wrote:
> Hi,
> 
> This is my flow table:
> ubuntu@bqn-vdu-redirector:~$ sudo ovs-ofctl dump-flows br2
>  cookie=0x0, duration=1295.729s, table=0, n_packets=0, n_bytes=0,
> priority=65535,dl_dst=01:80:c2:00:00:0e,dl_type=0x88cc
> actions=CONTROLLER:65535
>  cookie=0x0, duration=1243.681s, table=0, n_packets=6, n_bytes=588,
> priority=500,ip,nw_src=10.10.10.116,nw_dst=10.10.10.13 actions=output:ens6
>  cookie=0x0, duration=1238.441s, table=0, n_packets=1, n_bytes=42,
> priority=500,arp,arp_spa=10.10.10.116,arp_tpa=10.10.10.13
> actions=output:ens6
>  cookie=0x0, duration=1202.476s, table=0, n_packets=5, n_bytes=490,
> priority=500,ip,nw_src=10.10.10.139,nw_dst=10.10.10.13 actions=output:ens6
>  cookie=0x0, duration=1197.353s, table=0, n_packets=1, n_bytes=42,
> priority=500,arp,arp_spa=10.10.10.139,arp_tpa=10.10.10.13
> actions=output:ens6
>  cookie=0x0, duration=1243.680s, table=0, n_packets=17, n_bytes=1386,
> priority=500,in_port=ens6 actions=output:ens4
>  cookie=0x0, duration=1166.525s, table=0, n_packets=4, n_bytes=280,
> priority=500,in_port=ens7 actions=output:ens4
>  cookie=0x0, duration=904.379s, table=0, n_packets=0, n_bytes=0,
> priority=500,in_port=ens5 actions=output:ens4
>  cookie=0x0, duration=1295.733s, table=0, n_packets=6, n_bytes=392,
> priority=0 actions=CONTROLLER:65535
> 
> The controller sends the following message to delete the flows that match
> outport -> ens6 (openflow port 3):
> version=None,msg_type=None,msg_len=None,xid=None,OFPFlowMod(buffer_id=429496
> 7295,command=3,cookie=0,cookie_mask=0,flags=0,hard_timeout=0,idle_timeout=0,
> instructions=[],match=OFPMatch(oxm_fields={}),out_group=0,out_port=3,priorit
> y=32768,table_id=255)
> 
> After sending the previous message the flow table keeps showing the flow
> rules associated to ens6 interface. As you can see in output log, there is a
> flow_mod message coming from the controller to delete the flows. 
> ubuntu@bqn-vdu-redirector:~$ cat /var/log/cloud-init-output.log | grep
> delete
> checking whether nf_ct_delete( matches in
> /lib/modules/4.15.0-122-generic/build/include/net/netfilter/nf_conntrack.h..
> . yes
> 2021-07-16T16:07:25Z|12824|connmgr|INFO|br2<->tcp:172.27.15.215:6633: 1
> flow_mods 10 s ago (1 deletes) 
> 
> However, when executing the del-flow command in the terminal this works fine
> since the flow rules associated to ens6 were deleted as shown below.
> ubuntu@bqn-vdu-redirector:~$ sudo ovs-ofctl del-flows br2 out_port=ens6
> ubuntu@bqn-vdu-redirector:~$ sudo ovs-ofctl dump-flows br2
>  cookie=0x0, duration=1366.088s, table=0, n_packets=0, n_bytes=0,
> priority=65535,dl_dst=01:80:c2:00:00:0e,dl_type=0x88cc
> actions=CONTROLLER:65535
>  cookie=0x0, duration=1314.039s, table=0, n_packets=17, n_bytes=1386,
> priority=500,in_port=ens6 actions=output:ens4
>  cookie=0x0, duration=1236.884s, table=0, n_packets=4, n_bytes=280,
> priority=500,in_port=ens7 actions=output:ens4
>  cookie=0x0, duration=974.738s, table=0, n_packets=0, n_bytes=0,
> priority=500,in_port=ens5 actions=output:ens4
>  cookie=0x0, duration=57.213s, table=0, n_packets=0, n_bytes=0,
> idle_timeout=60, priority=0,in_port=ens4 actions=output:ens7
>  cookie=0x0, duration=1366.092s, table=0, n_packets=7, n_bytes=462,
> priority=0 actions=CONTROLLER:65535
> 
> Finally, you can see the ovsdb log with the last delete action.
> ubuntu@bqn-vdu-redirector:~$ cat /var/log/cloud-init-output.log | grep
> delete
> checking whether nf_ct_delete( matches in
> /lib/modules/4.15.0-122-generic/build/include/net/netfilter/nf_conntrack.h..
> . yes
> 2021-07-16T16:07:25Z|12824|connmgr|INFO|br2<->tcp:172.27.15.215:6633: 1
> flow_mods 10 s ago (1 deletes)
> 2021-07-16T16:18:15Z|12826|connmgr|INFO|br2<->unix#98: 1 flow_mods in the
> last 0 s (1 deletes)
> 
> I hope this information helps you to solve the problem.
> 
> Regards, 
> 
> Alejandro Llorens
> 
> -Mensaje original-
> De: Ben Pfaff  
> Enviado el: Thursday, July 15, 2021 8:05 PM
> Para: Alejandro Llorens Carrodeguas 
> CC: b...@openvswitch.org; 'Irian' ; 'Cristina
> Cervelló-Pastor' 
> Asunto: Re: [ovs-discuss] OFPFC_DELETE and OFPFC_DELETE_STRICT commands
> don't delete openflow rules

Re: [ovs-discuss] Custom Experimenter Message

[Ben Pfaff]

If you run "gitk" or "git log" on include/openvswitch/ofp-msgs.h, you
will find plenty of commits that add new experimenter messages.

On Tue, Jul 13, 2021 at 05:21:33PM +0300, Apostolis Prassas wrote:
> Hello again,
> 
> Thanks for the reply. That was my first approach, that is, to find an
> existent experimenter pattern and follow it to build mine. However,
> I have not found something similar, so could you be more specific and give
> me an example of such a message/pattern that is already implemented ?
> In terms of the 'ONFST' type, I have already tried it but the problem
> remains the same as I described in my first email.
> 
> Thanks for your time,
> Apostolis
> 
> Στις Δευ, 12 Ιουλ 2021 στις 10:00 μ.μ., ο/η Ben Pfaff  έγραψε:
> 
> > On Mon, Jul 12, 2021 at 08:39:21PM +0300, Apostolis Prassas wrote:
> > > Hello everyone,
> > >
> > > First of all, I am new it this mailing list, and I would like to
> > apologize
> > > if there is already a relative thread. I have searched for it, but I did
> > > not find anything similar.
> > >
> > > So, to start with which is my goal. While I'm using an SDN controller
> > > (Ryu), I'm sending an Experimenter message ( specifically an
> > > ExperimenterStatsRequest message) to the open vswitch, and I would like
> > the
> > > switch to decode it and reply with a respective (ExperimenterStatsReply)
> > > one.
> > >
> > > Following the Documentation, I have already added these two new messages
> > > into *enum ofpraw* structure (ofp-msgs.h) like:
> > > /* OFPST 1.3+ (65535): struct ofp_prop_experimenter. */
> > > OFPRAW_OFPST13_EXPERIMENTER_REQUEST
> > >
> > > /* OFPST 1.3+ (65535): struct ofp_prop_experimenter. */
> > >  OFPRAW_OFPST13_EXPERIMENTER_REPLY,
> >
> > This is the right place but wrong approach there.  OVS has builtin
> > support for experimenter messages and you can't just override that by
> > trying to claim all of them.  I would look at the pattern for the
> > existing experiment messages.  Since you're working on a stats message,
> > I would follow the pattern for the Open Networking Foundation multipart
> > messages (ONFST).
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OFPFC_DELETE and OFPFC_DELETE_STRICT commands don't delete openflow rules

[Ben Pfaff]

Hi.  We do test OFPFC_DELETE with out_port.  What's in your flow table
and what is an example of a command that fails?

On Thu, Jul 15, 2021 at 12:50:50PM +0200, Alejandro Llorens Carrodeguas wrote:
> Hello,
> 
> Thanks for your quick response.
> 
> In order to clarify our use case, I share the method that should delete the
> flows according to certain outport match.
> Our scenario is formed by a Ryu Controller (version 4.34) and an OVS switch
> (version 2.15.90) that interconnect several machines. Both applications
> (controller and OVS switch) run in the same VM with Ubuntu Server 18.04. Our
> idea is to delete the existing OpenFlow rules associated to a given a port
> that connects a failed host.
> As you can see in the method to delete the flows, we save the information
> port in a dictionary called host_ovsports where the keys are the host id and
> the values are the OVS ports. Thus, the controller can know the port that
> connects a given host.
> 
> def del_flow():
> """
> Delete specific flows taking into account a matching outport
> """
> outport = host_ovsports[host_id]
>  ofproto = switch_datapath.ofproto
>  parser = switch_datapath.ofproto_parser
>  cmd = ofproto.OFPFC_DELETE
>  match = parser.OFPMatch()
>  mod = parser.OFPFlowMod(datapath= switch_datapath,
> table_id=ofproto.OFPTT_ALL, command=cmd, out_port=outport)
>   switch_datapath.send_msg(mod)
> 
> I also attach a simplified topology of our use case and what we want to do.
> If you need more information let me know.
> We are having a similar problem to the one described in the following link:
> https://ryu-devel.narkive.com/i8Kl0aFy/ryu-delete-flow-entry-basing-on-prior
> ity#post4
> 
> They are trying to delete a flow based on the priority and we want to do it
> by taking into account the outport.
> 
> Thank in advance.
> 
> Regards,
> 
> Alejandro Llorens
> 
> -Original Message-
> From: Ben Pfaff 
> Sent: jueves, 15 de julio de 2021 1:45
> To: Alejandro Llorens Carrodeguas 
> Cc: b...@openvswitch.org; 'Irian' ; 'Cristina
> Cervelló-Pastor' 
> Subject: Re: [ovs-discuss] OFPFC_DELETE and OFPFC_DELETE_STRICT commands
> don't delete openflow rules
> 
> On Wed, Jul 14, 2021 at 06:34:46PM +0200, Alejandro Llorens Carrodeguas
> wrote:
> > We’re having trouble deleting OpenFlow rules using the OFPFC_DELETE or 
> > OFPFC_DELETE_STRICT commands that send a Ryu controller to the OVS switch.
> 
> Thanks for the report.
> 
> So far, you've just told us that these commands don't work for your case.  I
> can assure you that they do work in the cases we know about.
> So, we will need an example or a way to reproduce the problem.  The easiest
> you make it for us, the easier it will be to understand the problem you're
> seeing and either explain why your expectations are wrong or to fix the
> problem.
> 
> 
> --
> El software de antivirus Avast ha analizado este correo electrónico en busca 
> de virus.
> https://www.avast.com/antivirus


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OFPFC_DELETE and OFPFC_DELETE_STRICT commands don't delete openflow rules

[Ben Pfaff]

On Wed, Jul 14, 2021 at 06:34:46PM +0200, Alejandro Llorens Carrodeguas wrote:
> We’re having trouble deleting OpenFlow rules using the OFPFC_DELETE or
> OFPFC_DELETE_STRICT commands that send a Ryu controller to the OVS switch.

Thanks for the report.

So far, you've just told us that these commands don't work for your
case.  I can assure you that they do work in the cases we know about.
So, we will need an example or a way to reproduce the problem.  The
easiest you make it for us, the easier it will be to understand the
problem you're seeing and either explain why your expectations are wrong
or to fix the problem.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] How to use masked_set_action?

[Ben Pfaff]

On Wed, Jul 14, 2021 at 08:51:44AM +0800, taoyunupt wrote:
> Hi,
>  I found some info from vswitch.xml，it says "Masked data can improve 
> performance by allowing megaflows to match on fewer fields."  
>  I do not know What kinds of flow atcion will use 'masked_set_action'.   
> Can you give some demo flows and situation？ 

Anything that sets some fields in a header but not others.  For example,
setting the IP destination address (but not other IP fields) will use
it.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Custom Experimenter Message

[Ben Pfaff]

On Mon, Jul 12, 2021 at 08:39:21PM +0300, Apostolis Prassas wrote:
> Hello everyone,
> 
> First of all, I am new it this mailing list, and I would like to apologize
> if there is already a relative thread. I have searched for it, but I did
> not find anything similar.
> 
> So, to start with which is my goal. While I'm using an SDN controller
> (Ryu), I'm sending an Experimenter message ( specifically an
> ExperimenterStatsRequest message) to the open vswitch, and I would like the
> switch to decode it and reply with a respective (ExperimenterStatsReply)
> one.
> 
> Following the Documentation, I have already added these two new messages
> into *enum ofpraw* structure (ofp-msgs.h) like:
> /* OFPST 1.3+ (65535): struct ofp_prop_experimenter. */
> OFPRAW_OFPST13_EXPERIMENTER_REQUEST
> 
> /* OFPST 1.3+ (65535): struct ofp_prop_experimenter. */
>  OFPRAW_OFPST13_EXPERIMENTER_REPLY,

This is the right place but wrong approach there.  OVS has builtin
support for experimenter messages and you can't just override that by
trying to claim all of them.  I would look at the pattern for the
existing experiment messages.  Since you're working on a stats message,
I would follow the pattern for the Open Networking Foundation multipart
messages (ONFST).
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Action "mod_nw_tos:" for OPENFLOW13

[Ben Pfaff]

On Mon, Jul 12, 2021 at 03:13:13PM +0800, LIU Yulong wrote:
> 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.

OpenFlow 1.3 replaced all of the individual actions for setting fields
with the more general "set_field" action.  You should be able to use
that.  You will need to shift the TOS values two bits right to match the
OF1.3 format, I believe.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [EXT] Re: How to match on the physical and logical ingress ports

[Ben Pfaff]

Ah.  I recognize what you're trying to do now.  OVS doesn't have good
support for the push/pop model for tunnels.  The "encap" action is a
start at this, but it currently supports only nsh and I'm not convinced
that the implementation is high quality.

On Thu, Jul 08, 2021 at 05:35:27PM +, Dr. Helen Chen wrote:
> When my OVS contains both gre and the physical interface, packets match on 
> in_port=physical-intf, rather than in_port=gre.  Is there a way to force the 
> packet to be matched on gre and have them recognized as tunneled packets?  I 
> tried resubmit and mirroring, but they didn't work.
> 
> For what it's worth, what I want OVS to do with respect to GRE is more like 
> pushing/popping MPLS labels based on routing, instead of bridging, assuming 
> that mixing packets in different domains means mixing packets in different 
> bridge domains.
> 
> Thanks,
> Helen
> 
> On 7/7/21, 12:27 PM, "Ben Pfaff"  wrote:
> 
> It's possible but not widely done, since it doesn't generally make sense
> from the perspective of mixing packets in different domains.  I don't
> know anyone who does it.
> 
> On Wed, Jul 07, 2021 at 03:38:39PM +, Dr. Helen Chen wrote:
> > In the OVS documentation quoted below, it states that "physical ingress 
> ports (which need not be part of any switch)...".
> >
> > Is it correct to assume that the physical ingress port (of the gre 
> tunnel) can optionally be part of the switch that also has the gre tunnel?  
> If so, is there documented example configuration?  (So far, I've only seen 
> OVS configuration where switch consists of only gre tunnel but not the 
> physical ingress port of the tunnel.)
> > 
> > Thanks,
> > Helen
> > 
> > -Original Message-
> > From: Ben Pfaff  
> > Sent: Friday, July 2, 2021 1:46 PM
> > To: Dr. Shukri George Abdallah 
> > Cc: ovs-discuss@openvswitch.org
> > Subject: Re: [EXT] Re: [ovs-discuss] How to match on the physical 
> and logical ingress ports
> > 
> > The documentation says this:
> > 
> >A  packet’s  ingress  port and physical ingress port are 
> identical except
> >for packets processed by a switch feature such as  bonding  
> or  tunneling
> >that  makes  a  packet  appear to arrive on a ``virtual’’ 
> port associated
> >with the bond or the tunnel. For such packets, the ingress  
> port  is  the
> >virtual  port  and  the physical ingress port is, naturally, 
> the physical
> >port. Open vSwitch implements both bonding and tunneling, 
> but its bonding
> >implementation  does  not use virtual ports and its tunnels 
> are typically
> >not on the same OpenFlow switch as their physical  ingress  
> ports  (which
> >need not be part of any switch), so the ingress port and 
> physical ingress
> >port are always the same in Open vSwitch.
> > 
> > For bonding, OVS in_port always matches on the physical input port.
> > 
> > For tunneling, OVS doesn't pass along the physical input port but 
> only the virtual one.  You might be able to set the packet mark in the 
> physical bridge and then match on it in the virtual one, though.
> > 
> > On Thu, Jul 01, 2021 at 06:04:29PM +, Dr. Shukri George 
> Abdallah wrote:
> > > Hi
> > > 
> > > Please see 
> https://opennetworking.org/wp-content/uploads/2014/10/openflow-switch-v1.3.5.pdf
>  Section 7.2.3.9 .This link uses the term "logical"
> > > 
> > > Please see 
> https://www.man7.org/linux/man-pages/man7/ovs-fields.7.html. This link uses 
> the term "virtual".
> > > 
> > > The context is GRE tunneling
> > > 
> > > Shukri
> > > -Original Message-
> > > From: Ben Pfaff 
> > > Sent: Thursday, July 1, 2021 1:37 PM
> > > To: Dr. Shukri George Abdallah 
> > > Cc: ovs-discuss@openvswitch.org
> > > Subject: [EXT] Re: [ovs-discuss] How to match on the physical and 
> > > logical ingress ports
> > > 
> > > On Thu, Jul 01, 2021 at 02:51:13PM +, Dr. Shukri George 
> Abdallah wrote:
> > > > When the physical ingress port is different than the logical 
> ingress 
> > > > port, using

Re: [ovs-discuss] How to match on the physical and logical ingress ports

[Ben Pfaff]

It's possible but not widely done, since it doesn't generally make sense
from the perspective of mixing packets in different domains.  I don't
know anyone who does it.

On Wed, Jul 07, 2021 at 03:38:39PM +, Dr. Helen Chen wrote:
> In the OVS documentation quoted below, it states that "physical ingress ports 
> (which need not be part of any switch)...".
>
> Is it correct to assume that the physical ingress port (of the gre tunnel) 
> can optionally be part of the switch that also has the gre tunnel?  If so, is 
> there documented example configuration?  (So far, I've only seen OVS 
> configuration where switch consists of only gre tunnel but not the physical 
> ingress port of the tunnel.)
> 
> Thanks,
> Helen
> 
> -Original Message-
> From: Ben Pfaff  
> Sent: Friday, July 2, 2021 1:46 PM
> To: Dr. Shukri George Abdallah 
> Cc: ovs-discuss@openvswitch.org
> Subject: Re: [EXT] Re: [ovs-discuss] How to match on the physical and 
> logical ingress ports
> 
> The documentation says this:
> 
>A  packet’s  ingress  port and physical ingress port are identical 
> except
>for packets processed by a switch feature such as  bonding  or  
> tunneling
>that  makes  a  packet  appear to arrive on a ``virtual’’ port 
> associated
>with the bond or the tunnel. For such packets, the ingress  port  
> is  the
>virtual  port  and  the physical ingress port is, naturally, the 
> physical
>port. Open vSwitch implements both bonding and tunneling, but its 
> bonding
>implementation  does  not use virtual ports and its tunnels are 
> typically
>not on the same OpenFlow switch as their physical  ingress  ports  
> (which
>need not be part of any switch), so the ingress port and physical 
> ingress
>port are always the same in Open vSwitch.
> 
> For bonding, OVS in_port always matches on the physical input port.
> 
> For tunneling, OVS doesn't pass along the physical input port but only 
> the virtual one.  You might be able to set the packet mark in the physical 
> bridge and then match on it in the virtual one, though.
> 
> On Thu, Jul 01, 2021 at 06:04:29PM +, Dr. Shukri George Abdallah 
> wrote:
> > Hi
> > 
> > Please see 
> https://opennetworking.org/wp-content/uploads/2014/10/openflow-switch-v1.3.5.pdf
>  Section 7.2.3.9 .This link uses the term "logical"
> > 
> > Please see https://www.man7.org/linux/man-pages/man7/ovs-fields.7.html. 
> This link uses the term "virtual".
> > 
> > The context is GRE tunneling
> > 
> > Shukri
> > -Original Message-
> > From: Ben Pfaff 
> > Sent: Thursday, July 1, 2021 1:37 PM
> > To: Dr. Shukri George Abdallah 
> > Cc: ovs-discuss@openvswitch.org
> > Subject: [EXT] Re: [ovs-discuss] How to match on the physical and 
> > logical ingress ports
> > 
> > On Thu, Jul 01, 2021 at 02:51:13PM +, Dr. Shukri George Abdallah 
> wrote:
> > > When the physical ingress port is different than the logical ingress 
> > > port, using the ovs-ofctl utility, how can one match on the physical 
> > > and logical ingress ports?
> > 
> > How are you defining "physical" and "logical" ingress ports here?  Out 
> of context, it's not clear.
> 
> ___
> 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] Inactivity Probe configuration not taking effect in OVS 2.14.0

[Ben Pfaff]

I just pushed the fixes to the repo, so it'll be released as part of the
next regular OVS release.

Building from a patch isn't any different from building any other way.

On Thu, Jul 01, 2021 at 06:19:08AM +, Saurabh Deokate wrote:
> Hi Ben, 
> 
> I have two questions,
> 1. When is this patch going to be released ? 
> 2. Do we have any documentation for building modules from patch?
> 
> On 28/06/21, 10:25 PM, "Ben Pfaff"  wrote:
> 
> I recommend trying the patches that I posted:
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_pipermail_ovs-2Ddev_2021-2DJune_383783.html=DwIDaQ=s883GpUCOChKOHiocYtGcg=jK9phexdherJTNL6qWfkjyz7vNK2P5VYFIeRp9Vdy5s=0Y5dlQZ6-TXyNkmMDUiCUN6JaZJeIf_W69zr7CdJ_3A=7gXiz2Z8l7MPXHoqsyHwzyX4sozNLZM5RFJam3PSMRA=
>  
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_pipermail_ovs-2Ddev_2021-2DJune_383784.html=DwIDaQ=s883GpUCOChKOHiocYtGcg=jK9phexdherJTNL6qWfkjyz7vNK2P5VYFIeRp9Vdy5s=0Y5dlQZ6-TXyNkmMDUiCUN6JaZJeIf_W69zr7CdJ_3A=GZqZu8jql-ra0ik1wyfKSM4p6uNSvycyhJnMkTtIJTc=
>  
> 
> On Tue, Jun 15, 2021 at 07:24:06AM +, Saurabh Deokate wrote:
> > Hi Ben,
> > 
> > Here is the output for ovs-vsctl list controller 
> > 
> > [root@172-31-64-26-aws-eu-central-1c ~]# ovs-vsctl list controller
> > _uuid : eb56176a-ad32-4eb0-9cd8-7ab3bd448a68
> > connection_mode : out-of-band
> > controller_burst_limit: []
> > controller_queue_size: []
> > controller_rate_limit: []
> > enable_async_messages: []
> > external_ids : {}
> > inactivity_probe : 0
> > is_connected : true
> > local_gateway : []
> > local_ip : []
> > local_netmask : []
> > max_backoff : []
> > other_config : {}
> > role : other
> > status : {last_error="Connection refused", sec_since_connect="42606", 
> sec_since_disconnect="42614", state=ACTIVE}
> > target : "tcp:127.0.0.1:6653"
> > type : []
> > 
> > Let me know if you need any other details.
> > 
> > ~Saurabh.
> > 
> > On 11/06/21, 4:03 AM, "Ben Pfaff"  wrote:
> > 
> > On Mon, Jun 07, 2021 at 02:51:58PM +, Saurabh Deokate wrote:
> > > Hi Team,
> > > 
> > > We are seeing an issue in OVS 2.14.0 after moving from 2.8.0. We 
> first set the controller on the bridge and then set inactivity probe for our 
> controller to 0 to disable new connection attempts by ovs. After this we 
> start our controller to serve request. But in the new version of OVS somehow 
> we still see inactivity probe kicking in after every 5s and trying to 
> reconnect. This issue is triggered when we are in the middle of handling a 
> packet in our controller (i.e. OFController) which is blocked for almost 40s.
> > > 
> > > 
> > > Kernel version: CentOS Linux release 7.9.2009
> > > Output of ovs-vsctl list controller command shows 
> inactivity_probe: 0
> > > 
> > > Below is the snippet from ovs-vswitchd.log
> > > 
> > > 
> 021-05-11T22:32:55.378Z|00608|rconn|INFO|br0.uvms<->tcp:127.0.0.1:6653: 
> connected
> > > 
> 2021-05-11T22:33:05.382Z|00609|connmgr|INFO|br0.uvms<->tcp:127.0.0.1:6653: 44 
> flow_mods 10 s ago (44 adds)
> > > 
> 2021-05-11T22:33:05.386Z|00610|rconn|ERR|br0.uvms<->tcp:127.0.0.1:6653: no 
> response to inactivity probe after 5 seconds, disconnecting
> > > 
> 2021-05-11T22:33:06.406Z|00611|rconn|INFO|br0.uvms<->tcp:127.0.0.1:6653: 
> connecting...
> > > 
> 2021-05-11T22:33:06.438Z|00612|rconn|INFO|br0.uvms<->tcp:127.0.0.1:6653: 
> connected
> > > 
> 2021-05-11T22:33:16.438Z|00613|rconn|ERR|br0.uvms<->tcp:127.0.0.1:6653: no 
> response to inactivity probe after 5 seconds, disconnecting
> > > 
> 2021-05-11T22:33:17.921Z|00614|rconn|INFO|br0.uvms<->tcp:127.0.0.1:6653: 
> connecting...
> > > 
> 2021-05-11T22:33:18.108Z|00615|rconn|INFO|br0.uvms<->tcp:127.0.0.1:6653: 
> connected
> > > 
> 2021-05-11T22:33:28.110Z|00616|rconn|ERR|br0.uvms<->tcp:127.0.0.1:6653: no 
> response to inactivity probe after 5 seconds, disconnecting
> > > 
> 2021-05-11T22:33:29.433Z|00617|rconn|INFO|br0.uvms<->tcp:127.0.0.1:6653: 
> connecting...
> > > 
> 2021-05-11T22:33:29.933Z|00618|rconn|INFO|br0.uvms<->tcp:127.0.0.1:6653: 
&g

Re: [ovs-discuss] [EXT] Re: How to match on the physical and logical ingress ports

[Ben Pfaff]

The documentation says this:

   A  packet’s  ingress  port and physical ingress port are identical except
   for packets processed by a switch feature such as  bonding  or  tunneling
   that  makes  a  packet  appear to arrive on a ``virtual’’ port associated
   with the bond or the tunnel. For such packets, the ingress  port  is  the
   virtual  port  and  the physical ingress port is, naturally, the physical
   port. Open vSwitch implements both bonding and tunneling, but its bonding
   implementation  does  not use virtual ports and its tunnels are typically
   not on the same OpenFlow switch as their physical  ingress  ports  (which
   need not be part of any switch), so the ingress port and physical ingress
   port are always the same in Open vSwitch.

For bonding, OVS in_port always matches on the physical input port.

For tunneling, OVS doesn't pass along the physical input port but only
the virtual one.  You might be able to set the packet mark in the
physical bridge and then match on it in the virtual one, though.

On Thu, Jul 01, 2021 at 06:04:29PM +, Dr. Shukri George Abdallah wrote:
> Hi
> 
> Please see 
> https://opennetworking.org/wp-content/uploads/2014/10/openflow-switch-v1.3.5.pdf
>  Section 7.2.3.9 .This link uses the term "logical"
> 
> Please see https://www.man7.org/linux/man-pages/man7/ovs-fields.7.html. This 
> link uses the term "virtual".
> 
> The context is GRE tunneling
> 
> Shukri
> -Original Message-
> From: Ben Pfaff  
> Sent: Thursday, July 1, 2021 1:37 PM
> To: Dr. Shukri George Abdallah 
> Cc: ovs-discuss@openvswitch.org
> Subject: [EXT] Re: [ovs-discuss] How to match on the physical and logical 
> ingress ports
> 
> On Thu, Jul 01, 2021 at 02:51:13PM +, Dr. Shukri George Abdallah wrote:
> > When the physical ingress port is different than the logical ingress 
> > port, using the ovs-ofctl utility, how can one match on the physical 
> > and logical ingress ports?
> 
> How are you defining "physical" and "logical" ingress ports here?  Out of 
> context, it's not clear.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] How to match on the physical and logical ingress ports

[Ben Pfaff]

On Thu, Jul 01, 2021 at 02:51:13PM +, Dr. Shukri George Abdallah wrote:
> When the physical ingress port is different than the logical ingress
> port, using the ovs-ofctl utility, how can one match on the physical
> and logical ingress ports?

How are you defining "physical" and "logical" ingress ports here?  Out
of context, it's not clear.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [ovs] Adding tagged interfaces to ovs-system managed interface in the system configuration.

[Ben Pfaff]

This makes sense because the packets get taken off for the VLAN before
they reach OVS.

You might be able to make this work but it's not a recommended
configuration because in some cases MAC learning needs to have insight
into bond members.  I don't know what kind of bonding you're using.  If
it's LACP-based then that's probably the best bet.

On Tue, Jun 29, 2021 at 07:19:20PM +0200, Krzysztof Klimonda wrote:
> Right, but it seems it's only when I create internal interface in OVS for use 
> in the host system. If instead I create a system-level bond and use it for 
> both vswitchd and vlan interfaces (like I've shown in my example) the 
> resulting system interfaces, even though created on a bond that now has 
> "master ovs-system", seem to be working fine even if vswitchd is not running.
> 
> I understand this is not a "proper" configuration, but I'm trying to 
> understand what's wrong about it and how to measure its "wrongness" - frankly 
> I don't even fully understand why it works at all, especially when vswitchd 
> is turned off.
> 
> Best Regards,
> Krzysztof
> 
> On Tue, Jun 29, 2021, at 18:03, Ben Pfaff wrote:
> > Any use of OVS will bring down the network if vswitch fails.
> > 
> > On Mon, Jun 28, 2021 at 03:26:00PM +0200, Krzysztof Klimonda wrote:
> > > Hi,
> > > 
> > > Could you elaborate on that? Is there some documentation on this 
> > > interaction I could read? Is this a potential performance issue, or 
> > > offloading issue? What would be a better way to configure bonding with 
> > > ovs that does not bring down network in case of vswitchd failure?
> > > 
> > > Best Regards,
> > > Krzysztof
> > > 
> > > On Fri, Jun 25, 2021, at 01:49, Ben Pfaff wrote:
> > > > Linux bonds and OVS bridges don't necessarily mix well.
> > > > 
> > > > On Thu, Jun 24, 2021 at 10:25:58AM +0200, Krzysztof Klimonda wrote:
> > > > > Hi,
> > > > > 
> > > > > I had a configuration like that in mind:
> > > > > 
> > > > > # ip link add bond0 type bond
> > > > > # ip link set em1 master bond0
> > > > > # ip link set em2 master bond0
> > > > > # ip link add link bond0 name mgmt type vlan id 100
> > > > > # ip link add link bond0 name ovs_tunnel type vlan id 200
> > > > > 
> > > > > # ovs-vsctl add-br br0
> > > > > # ovs-vsctl add-port bond0
> > > > > 
> > > > > # ip link |grep bond0
> > > > > 6: bond0:  mtu 9000 qdisc 
> > > > > noqueue master ovs-system state UP mode DEFAULT group default qlen 
> > > > > 1000
> > > > > 7: mgmt@bond0:  mtu 9000 qdisc 
> > > > > noqueue state UP mode DEFAULT group default qlen 1000
> > > > > #
> > > > > 
> > > > > On Wed, Jun 23, 2021, at 18:51, Ben Pfaff wrote:
> > > > > > On Tue, Jun 22, 2021 at 09:58:49PM +0200, Krzysztof Klimonda wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > I have tried the following configuration for the system-level 
> > > > > > > network in the lab:
> > > > > > > 
> > > > > > >
> > > > > > >   +--vlan10@bond0
> > > > > > > ens1--+  |  
> > > > > > >---bond0 (ovs-system)--+--vlan20@bond0
> > > > > > > ens2--+  |  
> > > > > > >   +--vlan30@bond0
> > > > > > > 
> > > > > > > The idea is to plug bond0 into openvswitch so that I can add 
> > > > > > > specific VLANs to my virtual topology, but push some of those 
> > > > > > > VLANs into system without doing any specific configuration on the 
> > > > > > > ovs side (for example, to have access to the management interface 
> > > > > > > even if vswitchd is down).
> > > > > > > 
> > > > > > > This seems to be working fine in my lab (there is access to the 
> > > > > > > management interface - vlan10 - even when bond0 has ovs-system as 
> > > > > > > master), but are there any drawbacks to such a configuration?
> > > > > > 
> > > > > > It's hard to guess how you're implementing this.  If you're doing it
> > > > > > with something like this:
> > > > > > 
> > > > > > ovs-vsctl add-port br0 ens1
> > > > > > ovs-vsctl add-port br0 ens2
> > > > > > ovs-vsctl add-bond br0 bond0 ens1 ens2
> > > > > > ovs-vsctl add-port br0 vlan1 tag=1 -- set interface vlan1 
> > > > > > type=internal
> > > > > > ovs-vsctl add-port br0 vlan2 tag=2 -- set interface vlan2 
> > > > > > type=internal
> > > > > > ovs-vsctl add-port br0 vlan3 tag=3 -- set interface vlan3 
> > > > > > type=internal
> > > > > > 
> > > > > > then it ought to work fine.
> > > > > > 
> > > > > 
> > > > > 
> > > > > -- 
> > > > >   Krzysztof Klimonda
> > > > >   kklimo...@syntaxhighlighted.com
> > > > 
> > > 
> > > 
> > > -- 
> > >   Krzysztof Klimonda
> > >   kklimo...@syntaxhighlighted.com
> > 
> 
> 
> -- 
>   Krzysztof Klimonda
>   kklimo...@syntaxhighlighted.com
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [ovs] Adding tagged interfaces to ovs-system managed interface in the system configuration.

[Ben Pfaff]

Any use of OVS will bring down the network if vswitch fails.

On Mon, Jun 28, 2021 at 03:26:00PM +0200, Krzysztof Klimonda wrote:
> Hi,
> 
> Could you elaborate on that? Is there some documentation on this interaction 
> I could read? Is this a potential performance issue, or offloading issue? 
> What would be a better way to configure bonding with ovs that does not bring 
> down network in case of vswitchd failure?
> 
> Best Regards,
> Krzysztof
> 
> On Fri, Jun 25, 2021, at 01:49, Ben Pfaff wrote:
> > Linux bonds and OVS bridges don't necessarily mix well.
> > 
> > On Thu, Jun 24, 2021 at 10:25:58AM +0200, Krzysztof Klimonda wrote:
> > > Hi,
> > > 
> > > I had a configuration like that in mind:
> > > 
> > > # ip link add bond0 type bond
> > > # ip link set em1 master bond0
> > > # ip link set em2 master bond0
> > > # ip link add link bond0 name mgmt type vlan id 100
> > > # ip link add link bond0 name ovs_tunnel type vlan id 200
> > > 
> > > # ovs-vsctl add-br br0
> > > # ovs-vsctl add-port bond0
> > > 
> > > # ip link |grep bond0
> > > 6: bond0:  mtu 9000 qdisc noqueue 
> > > master ovs-system state UP mode DEFAULT group default qlen 1000
> > > 7: mgmt@bond0:  mtu 9000 qdisc noqueue 
> > > state UP mode DEFAULT group default qlen 1000
> > > #
> > > 
> > > On Wed, Jun 23, 2021, at 18:51, Ben Pfaff wrote:
> > > > On Tue, Jun 22, 2021 at 09:58:49PM +0200, Krzysztof Klimonda wrote:
> > > > > Hi,
> > > > > 
> > > > > I have tried the following configuration for the system-level network 
> > > > > in the lab:
> > > > > 
> > > > >
> > > > >   +--vlan10@bond0
> > > > > ens1--+  |  
> > > > >---bond0 (ovs-system)--+--vlan20@bond0
> > > > > ens2--+  |  
> > > > >   +--vlan30@bond0
> > > > > 
> > > > > The idea is to plug bond0 into openvswitch so that I can add specific 
> > > > > VLANs to my virtual topology, but push some of those VLANs into 
> > > > > system without doing any specific configuration on the ovs side (for 
> > > > > example, to have access to the management interface even if vswitchd 
> > > > > is down).
> > > > > 
> > > > > This seems to be working fine in my lab (there is access to the 
> > > > > management interface - vlan10 - even when bond0 has ovs-system as 
> > > > > master), but are there any drawbacks to such a configuration?
> > > > 
> > > > It's hard to guess how you're implementing this.  If you're doing it
> > > > with something like this:
> > > > 
> > > > ovs-vsctl add-port br0 ens1
> > > > ovs-vsctl add-port br0 ens2
> > > > ovs-vsctl add-bond br0 bond0 ens1 ens2
> > > > ovs-vsctl add-port br0 vlan1 tag=1 -- set interface vlan1 
> > > > type=internal
> > > > ovs-vsctl add-port br0 vlan2 tag=2 -- set interface vlan2 
> > > > type=internal
> > > > ovs-vsctl add-port br0 vlan3 tag=3 -- set interface vlan3 
> > > > type=internal
> > > > 
> > > > then it ought to work fine.
> > > > 
> > > 
> > > 
> > > -- 
> > >   Krzysztof Klimonda
> > >   kklimo...@syntaxhighlighted.com
> > 
> 
> 
> -- 
>   Krzysztof Klimonda
>   kklimo...@syntaxhighlighted.com
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Inactivity Probe configuration not taking effect in OVS 2.14.0

[Ben Pfaff]

I recommend trying the patches that I posted:
https://mail.openvswitch.org/pipermail/ovs-dev/2021-June/383783.html
https://mail.openvswitch.org/pipermail/ovs-dev/2021-June/383784.html

On Tue, Jun 15, 2021 at 07:24:06AM +, Saurabh Deokate wrote:
> Hi Ben,
> 
> Here is the output for ovs-vsctl list controller 
> 
> [root@172-31-64-26-aws-eu-central-1c ~]# ovs-vsctl list controller
> _uuid : eb56176a-ad32-4eb0-9cd8-7ab3bd448a68
> connection_mode : out-of-band
> controller_burst_limit: []
> controller_queue_size: []
> controller_rate_limit: []
> enable_async_messages: []
> external_ids : {}
> inactivity_probe : 0
> is_connected : true
> local_gateway : []
> local_ip : []
> local_netmask : []
> max_backoff : []
> other_config : {}
> role : other
> status : {last_error="Connection refused", sec_since_connect="42606", 
> sec_since_disconnect="42614", state=ACTIVE}
> target : "tcp:127.0.0.1:6653"
> type : []
> 
> Let me know if you need any other details.
> 
> ~Saurabh.
> 
> On 11/06/21, 4:03 AM, "Ben Pfaff"  wrote:
> 
> On Mon, Jun 07, 2021 at 02:51:58PM +, Saurabh Deokate wrote:
> > Hi Team,
> > 
> > We are seeing an issue in OVS 2.14.0 after moving from 2.8.0. We first 
> set the controller on the bridge and then set inactivity probe for our 
> controller to 0 to disable new connection attempts by ovs. After this we 
> start our controller to serve request. But in the new version of OVS somehow 
> we still see inactivity probe kicking in after every 5s and trying to 
> reconnect. This issue is triggered when we are in the middle of handling a 
> packet in our controller (i.e. OFController) which is blocked for almost 40s.
> > 
> > 
> > Kernel version: CentOS Linux release 7.9.2009
> > Output of ovs-vsctl list controller command shows inactivity_probe: 0
> > 
> > Below is the snippet from ovs-vswitchd.log
> > 
> > 021-05-11T22:32:55.378Z|00608|rconn|INFO|br0.uvms<->tcp:127.0.0.1:6653: 
> connected
> > 
> 2021-05-11T22:33:05.382Z|00609|connmgr|INFO|br0.uvms<->tcp:127.0.0.1:6653: 44 
> flow_mods 10 s ago (44 adds)
> > 2021-05-11T22:33:05.386Z|00610|rconn|ERR|br0.uvms<->tcp:127.0.0.1:6653: 
> no response to inactivity probe after 5 seconds, disconnecting
> > 
> 2021-05-11T22:33:06.406Z|00611|rconn|INFO|br0.uvms<->tcp:127.0.0.1:6653: 
> connecting...
> > 
> 2021-05-11T22:33:06.438Z|00612|rconn|INFO|br0.uvms<->tcp:127.0.0.1:6653: 
> connected
> > 2021-05-11T22:33:16.438Z|00613|rconn|ERR|br0.uvms<->tcp:127.0.0.1:6653: 
> no response to inactivity probe after 5 seconds, disconnecting
> > 
> 2021-05-11T22:33:17.921Z|00614|rconn|INFO|br0.uvms<->tcp:127.0.0.1:6653: 
> connecting...
> > 
> 2021-05-11T22:33:18.108Z|00615|rconn|INFO|br0.uvms<->tcp:127.0.0.1:6653: 
> connected
> > 2021-05-11T22:33:28.110Z|00616|rconn|ERR|br0.uvms<->tcp:127.0.0.1:6653: 
> no response to inactivity probe after 5 seconds, disconnecting
> > 
> 2021-05-11T22:33:29.433Z|00617|rconn|INFO|br0.uvms<->tcp:127.0.0.1:6653: 
> connecting...
> > 
> 2021-05-11T22:33:29.933Z|00618|rconn|INFO|br0.uvms<->tcp:127.0.0.1:6653: 
> connected
> > 
> > 
> > Can you please help us find out what could be wrong with this 
> configuration and what is the expected behaviour from ovs switch when the 
> receiver on the controller is blocked for long.
> 
> Hmm, I can't reproduce this with current OVS.  I do see a problem with
> the fail-open implementation; I'll see a patch for that.
> 
> Can you show the output of "ovs-vsctl list controller"?
> 
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [ovs] Adding tagged interfaces to ovs-system managed interface in the system configuration.

[Ben Pfaff]

Linux bonds and OVS bridges don't necessarily mix well.

On Thu, Jun 24, 2021 at 10:25:58AM +0200, Krzysztof Klimonda wrote:
> Hi,
> 
> I had a configuration like that in mind:
> 
> # ip link add bond0 type bond
> # ip link set em1 master bond0
> # ip link set em2 master bond0
> # ip link add link bond0 name mgmt type vlan id 100
> # ip link add link bond0 name ovs_tunnel type vlan id 200
> 
> # ovs-vsctl add-br br0
> # ovs-vsctl add-port bond0
> 
> # ip link |grep bond0
> 6: bond0:  mtu 9000 qdisc noqueue 
> master ovs-system state UP mode DEFAULT group default qlen 1000
> 7: mgmt@bond0:  mtu 9000 qdisc noqueue state 
> UP mode DEFAULT group default qlen 1000
> #
> 
> On Wed, Jun 23, 2021, at 18:51, Ben Pfaff wrote:
> > On Tue, Jun 22, 2021 at 09:58:49PM +0200, Krzysztof Klimonda wrote:
> > > Hi,
> > > 
> > > I have tried the following configuration for the system-level network in 
> > > the lab:
> > > 
> > >
> > >   +--vlan10@bond0
> > > ens1--+  |  
> > >---bond0 (ovs-system)--+--vlan20@bond0
> > > ens2--+  |  
> > >   +--vlan30@bond0
> > > 
> > > The idea is to plug bond0 into openvswitch so that I can add specific 
> > > VLANs to my virtual topology, but push some of those VLANs into system 
> > > without doing any specific configuration on the ovs side (for example, to 
> > > have access to the management interface even if vswitchd is down).
> > > 
> > > This seems to be working fine in my lab (there is access to the 
> > > management interface - vlan10 - even when bond0 has ovs-system as 
> > > master), but are there any drawbacks to such a configuration?
> > 
> > It's hard to guess how you're implementing this.  If you're doing it
> > with something like this:
> > 
> > ovs-vsctl add-port br0 ens1
> > ovs-vsctl add-port br0 ens2
> > ovs-vsctl add-bond br0 bond0 ens1 ens2
> > ovs-vsctl add-port br0 vlan1 tag=1 -- set interface vlan1 type=internal
> > ovs-vsctl add-port br0 vlan2 tag=2 -- set interface vlan2 type=internal
> > ovs-vsctl add-port br0 vlan3 tag=3 -- set interface vlan3 type=internal
> > 
> > then it ought to work fine.
> > 
> 
> 
> -- 
>   Krzysztof Klimonda
>   kklimo...@syntaxhighlighted.com
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [ovs] Adding tagged interfaces to ovs-system managed interface in the system configuration.

[Ben Pfaff]

On Tue, Jun 22, 2021 at 09:58:49PM +0200, Krzysztof Klimonda wrote:
> Hi,
> 
> I have tried the following configuration for the system-level network in the 
> lab:
> 
>
>   +--vlan10@bond0
> ens1--+  |  
>---bond0 (ovs-system)--+--vlan20@bond0
> ens2--+  |  
>   +--vlan30@bond0
> 
> The idea is to plug bond0 into openvswitch so that I can add specific VLANs 
> to my virtual topology, but push some of those VLANs into system without 
> doing any specific configuration on the ovs side (for example, to have access 
> to the management interface even if vswitchd is down).
> 
> This seems to be working fine in my lab (there is access to the management 
> interface - vlan10 - even when bond0 has ovs-system as master), but are there 
> any drawbacks to such a configuration?

It's hard to guess how you're implementing this.  If you're doing it
with something like this:

ovs-vsctl add-port br0 ens1
ovs-vsctl add-port br0 ens2
ovs-vsctl add-bond br0 bond0 ens1 ens2
ovs-vsctl add-port br0 vlan1 tag=1 -- set interface vlan1 type=internal
ovs-vsctl add-port br0 vlan2 tag=2 -- set interface vlan2 type=internal
ovs-vsctl add-port br0 vlan3 tag=3 -- set interface vlan3 type=internal

then it ought to work fine.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] 回复: An error in file ovn-sb.ovsschema

[Ben Pfaff]

Thanks, I applied this to OVN master.

On Wed, Jun 23, 2021 at 06:32:10AM +, wen yuxuan wrote:
> Sure, it works!
> Coz we are going to create a mount of vm to use ovn load balancer.
> 
> ____
> 发件人: Ben Pfaff 
> 发送时间: 2021年6月23日 0:20
> 收件人: wen yuxuan 
> 抄送: b...@openvswitch.org 
> 主题: Re: [ovs-discuss] An error in file ovn-sb.ovsschema
> 
> On Tue, Jun 22, 2021 at 02:59:44AM +, wen yuxuan wrote:
> > Hi，
> > I found an error in file ovn-sb.ovsschema recently. The port field of 
> > talble Service_Monitor maxInteger is 32767, but this field in code is 
> > uint16_t, maximum value is 65535(in function create_or_get_service_mon). 
> > When I configure port number over 32767  ovn-nb is broken.
> 
> Indeed, I think that the following should be folded in.  Can you verify
> that this fixes the problem?  By the way, high port numbers like this
> should usually be reserved for ephemeral ports.
> 
> diff --git a/ovn-sb.ovsschema b/ovn-sb.ovsschema
> index 205a30a37cee..bbf60781dd72 100644
> --- a/ovn-sb.ovsschema
> +++ b/ovn-sb.ovsschema
> @@ -1,7 +1,7 @@
>  {
>  "name": "OVN_Southbound",
> -"version": "20.17.0",
> -"cksum": "669123379 26536",
> +"version": "20.18.0",
> +"cksum": "1816525029 26536",
>  "tables": {
>  "SB_Global": {
>  "columns": {
> @@ -452,7 +452,7 @@
>   "min": 0, "max": 1}},
>  "port": {"type": {"key": {"type": "integer",
>"minInteger": 0,
> -  "maxInteger": 32767}}},
> +  "maxInteger": 65535}}},
>  "logical_port": {"type": "string"},
>  "src_mac": {"type": "string"},
>  "src_ip": {"type": "string"},
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] An error in file ovn-sb.ovsschema

[Ben Pfaff]

On Tue, Jun 22, 2021 at 02:59:44AM +, wen yuxuan wrote:
> Hi，
> I found an error in file ovn-sb.ovsschema recently. The port field of talble 
> Service_Monitor maxInteger is 32767, but this field in code is uint16_t, 
> maximum value is 65535(in function create_or_get_service_mon). When I 
> configure port number over 32767  ovn-nb is broken.

Indeed, I think that the following should be folded in.  Can you verify
that this fixes the problem?  By the way, high port numbers like this
should usually be reserved for ephemeral ports.

diff --git a/ovn-sb.ovsschema b/ovn-sb.ovsschema
index 205a30a37cee..bbf60781dd72 100644
--- a/ovn-sb.ovsschema
+++ b/ovn-sb.ovsschema
@@ -1,7 +1,7 @@
 {
 "name": "OVN_Southbound",
-"version": "20.17.0",
-"cksum": "669123379 26536",
+"version": "20.18.0",
+"cksum": "1816525029 26536",
 "tables": {
 "SB_Global": {
 "columns": {
@@ -452,7 +452,7 @@
  "min": 0, "max": 1}},
 "port": {"type": {"key": {"type": "integer",
   "minInteger": 0,
-  "maxInteger": 32767}}},
+  "maxInteger": 65535}}},
 "logical_port": {"type": "string"},
 "src_mac": {"type": "string"},
 "src_ip": {"type": "string"},
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] error: "could not add network device s1u to ofproto (Address family not supported by protocol)"

[Ben Pfaff]

On Mon, Jun 14, 2021 at 05:20:19PM +0100, tony yang wrote:
> Dear all:
> 
> I had a error when I run the ovs-gtp using the command sudo
> ./1-setup-switch.sh
> 
> yangtony1999@yangtony1999:~/mosaic5g/ovs-gtp$ sudo ./1-setup-switch.sh
> ovs-vsctl: Error detected while setting up 'edge': could not open network
> device edge (File exists).  See ovs-vswitchd log for details.
> ovs-vsctl: The default log directory is "/usr/local/var/log/openvswitch".
> ovs-vsctl: Error detected while setting up 's1u': could not add network
> device s1u to ofproto (Address family not supported by protocol).  See
> ovs-vswitchd log for details.
> ovs-vsctl: The default log directory is "/usr/local/var/log/openvswitch".
> yangtony1999@yangtony1999:~/mosaic5g/ovs-gtp$ sudo ovs-vsctl
> show568a1f72-0e94-4c16-a8fd-ef9218a97ccb
> Bridge edge
> Controller "tcp:192.168.12.42:6653"
> Port edge
> Interface edge
> type: internal
> Port "s1u"
> Interface "s1u"
> type: gtp
> options: {key=flow, remote_ip=flow}
> error: "could not add network device s1u to ofproto
> (Address family not supported by protocol)"
> Port "enp68s0"
> Interface "enp68s0"

What's in the log?
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Where does complex packet_out/meters behaviour test belong?

[Ben Pfaff]

It looks like you followed up on this with a patch and that you and Ilya
worked it out.  If I should look deeper, let me know!

On Sun, May 30, 2021 at 10:40:27PM +, Tony van der Peet wrote:
> Thanks Ben. I have written a test and can confirm that latest OVS has a 
> vswitchd crash in this case. After a long chain of calls starting with 
> handle_packet_out calling  ofproto_packet_out_finish, and ending with 
> dp_netdev_run_meter, dp_packet_delete is called to dispose of the message. 
> Then handle_packet_out calls ofproto_packet_out_uninit which calls 
> dp_packet_delete to delete the same message.
> 
> I am a bit stumped as to how to fix this. Stopping the meter code from 
> deleting the packet would not work for other cases which don't seem to crash, 
> stopping the packet_out code from deleting the packet would not work for when 
> the meter is not invoked. Creating a copy of the packet wouldn't work because 
> it would then have to be disposed of in the normal, non-meter case. Adding 
> special flags would be a major change, as would reference counting on the 
> packet buffer. About the best I can think of is a flag to cover this specific 
> case, maybe added to the packet metadata, which would need to be initialised 
> false, and then be set true by the packet_out code. Maybe call it 
> "meter_do_not_delete"? I can try this to see if it works but wonder if 
> packet_metadata can be altered just like that. Or if there are better ways of 
> doing this.
> 
> Tony
> 
> From: Ben Pfaff 
> Sent: Saturday, 29 May 2021 5:27 a.m.
> To: Tony van der Peet
> Cc: b...@openvswitch.org
> Subject: Re: [ovs-discuss] Where does complex packet_out/meters behaviour 
> test belong?
> 
> On Fri, May 28, 2021 at 05:00:46AM +, Tony van der Peet wrote:
> > I want to add a unit test that checks what happens when a packet_out 
> > message with output port OFPP_TABLE is dropped due to the action of a meter 
> > (our version of vswitchd crashes when I run this test with our oftest 
> > framework).
> >
> >
> > Where do you suggest I put this test?
> 
> There are a few packet-out tests in 
> http://scanmail.trustwave.com/?c=20988=iKix4E8S7LYunNE_BL4IXm1Ak3fMb7yMJ8K3pmQBJw=http%3a%2f%2fofproto-dpif%2eat
>  perhaps just after
> this cluster:
> 
> ofproto-dpif.at:AT_SETUP([ofproto-dpif packet-out controller])
> ofproto-dpif.at:AT_SETUP([ofproto-dpif packet-out controller (patch port)])
> ofproto-dpif.at:AT_SETUP([ofproto-dpif packet-out pipeline match field 
> (OpenFlow 1.5)])
> ofproto-dpif.at:AT_SETUP([ofproto-dpif packet-out goto_table])
> ofproto-dpif.at:AT_SETUP([ofproto-dpif packet-out table-miss (continue)])
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Inactivity Probe configuration not taking effect in OVS 2.14.0

[Ben Pfaff]

On Mon, Jun 07, 2021 at 02:51:58PM +, Saurabh Deokate wrote:
> Hi Team,
> 
> We are seeing an issue in OVS 2.14.0 after moving from 2.8.0. We first set 
> the controller on the bridge and then set inactivity probe for our controller 
> to 0 to disable new connection attempts by ovs. After this we start our 
> controller to serve request. But in the new version of OVS somehow we still 
> see inactivity probe kicking in after every 5s and trying to reconnect. This 
> issue is triggered when we are in the middle of handling a packet in our 
> controller (i.e. OFController) which is blocked for almost 40s.
> 
> 
> Kernel version: CentOS Linux release 7.9.2009
> Output of ovs-vsctl list controller command shows inactivity_probe: 0
> 
> Below is the snippet from ovs-vswitchd.log
> 
> 021-05-11T22:32:55.378Z|00608|rconn|INFO|br0.uvms<->tcp:127.0.0.1:6653: 
> connected
> 2021-05-11T22:33:05.382Z|00609|connmgr|INFO|br0.uvms<->tcp:127.0.0.1:6653: 44 
> flow_mods 10 s ago (44 adds)
> 2021-05-11T22:33:05.386Z|00610|rconn|ERR|br0.uvms<->tcp:127.0.0.1:6653: no 
> response to inactivity probe after 5 seconds, disconnecting
> 2021-05-11T22:33:06.406Z|00611|rconn|INFO|br0.uvms<->tcp:127.0.0.1:6653: 
> connecting...
> 2021-05-11T22:33:06.438Z|00612|rconn|INFO|br0.uvms<->tcp:127.0.0.1:6653: 
> connected
> 2021-05-11T22:33:16.438Z|00613|rconn|ERR|br0.uvms<->tcp:127.0.0.1:6653: no 
> response to inactivity probe after 5 seconds, disconnecting
> 2021-05-11T22:33:17.921Z|00614|rconn|INFO|br0.uvms<->tcp:127.0.0.1:6653: 
> connecting...
> 2021-05-11T22:33:18.108Z|00615|rconn|INFO|br0.uvms<->tcp:127.0.0.1:6653: 
> connected
> 2021-05-11T22:33:28.110Z|00616|rconn|ERR|br0.uvms<->tcp:127.0.0.1:6653: no 
> response to inactivity probe after 5 seconds, disconnecting
> 2021-05-11T22:33:29.433Z|00617|rconn|INFO|br0.uvms<->tcp:127.0.0.1:6653: 
> connecting...
> 2021-05-11T22:33:29.933Z|00618|rconn|INFO|br0.uvms<->tcp:127.0.0.1:6653: 
> connected
> 
> 
> Can you please help us find out what could be wrong with this configuration 
> and what is the expected behaviour from ovs switch when the receiver on the 
> controller is blocked for long.

Hmm, I can't reproduce this with current OVS.  I do see a problem with
the fail-open implementation; I'll see a patch for that.

Can you show the output of "ovs-vsctl list controller"?
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Why OVS behaves difference between ovs-vswitchd and ovs-vswitchd-dpdk?

[Ben Pfaff]

On Fri, Jun 04, 2021 at 02:11:23PM +0800, Harry Lee wrote:
> Hello,
> 
> My server is running debian testing. I install two ovs version through apt:
> 
> ```
> openvswitch-switch/testing,unstable,now 2.15.0+ds1-2 amd64 [installed]
>   Open vSwitch switch implementations
> 
> openvswitch-switch-dpdk/testing,unstable,now 2.15.0+ds1-2 amd64 [installed]
>   DPDK enabled Open vSwitch switch implementation
> ```
> 
> Then I found something  difference between them.
> 
> Here's my experience:
> 
> ```
> # switch ovs version to ovs-vswitchd
> update-alternatives --set ovs-vswitchd 
> /usr/lib/openvswitch-common/ovs-vswitchd
> /etc/init.d/openvswitch-switch restart
> ip addr add 10.90.67.148/25 dev br0
> ping 10.90.67.129  # network is ok
> 
> # switch ovs version to ovs-vswitchd-dpdk
> update-alternatives --set ovs-vswitchd 
> /usr/lib/openvswitch-switch-dpdk/ovs-vswitchd-dpdk
> /etc/init.d/openvswitch-switch restart
> ip addr add 10.90.67.148/25 dev br0
> ping 10.90.67.129  # unreachable
> ```
> 
> The same configuration, using ovs-vswitchd was reachable while using 
> ovs-vswitchd-dpdk was unreachable.
> 
> Then I used `tcpdump br0` to checkout if there are packets from br0, and I 
> found some ARP packets:
> 
> ```
> root@debian:~# tcpdump -i br0 -nnn
> tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
> listening on br0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
> 02:14:27.010265 ARP, Request who-has 10.90.67.129 tell 10.90.67.148, length 28
> 02:14:28.034127 ARP, Request who-has 10.90.67.129 tell 10.90.67.148, length 28
> 02:14:29.058128 ARP, Request who-has 10.90.67.129 tell 10.90.67.148, length 28
> ```
> 
> But when I ran `ovs-ofctl dump-flows br0`, I saw n_packets is 0:
> 
> ```
> root@debian:~# ovs-ofctl dump-flows br0
>  cookie=0x0, duration=1016.243s, table=0, n_packets=0, n_bytes=0, priority=0 
> actions=NORMAL
> ```
> 
> Why does ovs-vswitchd-dpdk ignore the packet from br0? Does it need 
> additional configuration?

Did you configure the dpdk version to use DPDK devices and the userspace
datapath?  If you didn't, then these two versions of OVS were using the
same code in the same way, so it's puzzling why there would have been
any difference.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [ovs-dev] Moving of the primary #openvswitch channel to irc.libera.chat ?

[Ben Pfaff]

[seems I saved this as a draft and never sent it, oops]

On Wed, May 26, 2021 at 01:41:01PM +0200, Ilya Maximets wrote:
> On 5/26/21 9:39 AM, Frode Nordahl wrote:
> > On Thu, May 20, 2021 at 10:08 PM Ihar Hrachyshka  
> > wrote:
> > Our, and some 700 other channels, were just taken over for advertising
> > other IRC networks in topic (see attached screenshot). I think this is
> > the cue to leave Freenode.
> 
> Yes, this looks like no way back.
> 
> Ben did you lose control over the channel on freenode?

Yes.  I can't even get into #openvswitch.  It's invitation-only now.
Somehow I got put into ##openvswitch instead, but that is owned by a
freenode bot:

ChanServ: (notice) Information on ##openvswitch:
ChanServ: (notice) Founder: freenode-placeholder-account
ChanServ: (notice) Registered : May 26 02:38:03 2021 (1d 13h 54m 48s ago)
ChanServ: (notice) Last used  : May 26 02:38:03 2021 (1d 13h 54m 48s ago)
ChanServ: (notice) Mode lock  : +ntF
ChanServ: (notice) Flags  : GUARD
ChanServ: (notice) *** End of Info ***

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] openvswitch-2.14.0 crashes

[Ben Pfaff]

On Mon, May 31, 2021 at 04:44:11PM +, Miroslav Kubiczek wrote:
> Hello,
> We observe a crash with certain packets (BGP UPDATE with 2096 bytes whereas 
> MTU was 1500):
> 
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> Core was generated by `ovs-vswitchd unix:/var/run/openvswitch/db.sock 
> -vconsole:emer -vsyslog:err -vfi'.
> Program terminated with signal 11, Segmentation fault.
> #0  dp_packet_set_size (v=572, b=0x0) at lib/dp-packet.h:578
> 578 b->mbuf.data_len = (uint16_t)v;  /* Current seg length. */
> Missing separate debuginfos, use: debuginfo-install 
> glibc-2.17-307.el7.1.x86_64 keyutils-libs-1.5.8-3.el7.x86_64 
> krb5-libs-1.15.1-46.el7.x86_64 libatomic-4.8.5-44.el7.x86_64 
> libcom_err-1.42.9-17.el7.x86_64 libevent-2.0.21-4.el7.x86_64 
> libgcc-4.8.5-39.el7.x86_64 libpcap-1.5.3-12.el7.x86_64 
> libselinux-2.5-15.el7.x86_64 libunwind-1.2-2.el7.x86_64 
> numactl-libs-2.0.12-5.el7.x86_64 openssl-libs-1.0.2k-19.el7.x86_64 
> pcre-8.32-17.el7.x86_64 python-libs-2.7.5-88.el7.x86_64 
> unbound-libs-1.6.6-3.el7.x86_64 zlib-1.2.7-18.el7.x86_64
> (gdb) backtrace
> #0  dp_packet_set_size (v=572, b=0x0) at lib/dp-packet.h:578
> #1  netdev_linux_batch_rxq_recv_sock (rx=rx@entry=0x20b1c90, mtu= out>, batch=batch@entry=0x7ffcf27baee0) at lib/netdev-linux.c:1306

This looks something of a weird case overall, because it suggests that
you're using the userspace datapath but not DPDK network devices.  Is
that correct?

This crash appears to be here:

if (mmsgs[i].msg_len > std_len) {
/* Build a single linear TSO packet by prepending the data from
 * std_len buffer to the aux_buf. */
pkt = rx->aux_bufs[i];
dp_packet_set_size(pkt, mmsgs[i].msg_len - std_len);

Ending up passing a null 'pkt' to dp_packet_set_size() indicates that
somehow aux_bufs[i] didn't get initialized.  I don't see how that would
happen.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVN cluster join question

[Ben Pfaff]

On Mon, May 31, 2021 at 12:24:01PM -0400, Satish Patel wrote:
> 
> Folks,
> 
> I have few question related cluster member relationship. Let’s say I have 
> started following 3 node cluster 
> 
> 1. Node-1 ( first mode)
> 2. Node-2 ( join first node-1)
> 3. Node-3 (join first node-1)
> 
> Life is good till now. 
> 
> Node if some reason node-1 is dead ( total hardware failure), in this case if 
> I build fresh node-1 then am I going to join node-2 (or whoever the leader in 
> existing 2 node?) 
> 
> Or should I be destroying everything and rebuilding whole cluster in above 
> scenario? 
> 
> I’m trying to create ansible playbook to handle all these scenario to make 
> life easier. 

After node 2 joins the cluster, there's nothing special about node 1.
It's just a member of the cluster.  Similarly, after node 3 joins the
cluster, there's nothing special about any of the nodes.

"How to Maintain a Clustered Database" in ovsdb.7.rst describes how to
kick an unrecoverably dead node out of a cluster.  That works for any of
the nodes in the cluster.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Where does complex packet_out/meters behaviour test belong?

[Ben Pfaff]

On Fri, May 28, 2021 at 05:00:46AM +, Tony van der Peet wrote:
> I want to add a unit test that checks what happens when a packet_out message 
> with output port OFPP_TABLE is dropped due to the action of a meter (our 
> version of vswitchd crashes when I run this test with our oftest framework).
> 
> 
> Where do you suggest I put this test?

There are a few packet-out tests in ofproto-dpif.at, perhaps just after
this cluster:

ofproto-dpif.at:AT_SETUP([ofproto-dpif packet-out controller])
ofproto-dpif.at:AT_SETUP([ofproto-dpif packet-out controller (patch port)])
ofproto-dpif.at:AT_SETUP([ofproto-dpif packet-out pipeline match field 
(OpenFlow 1.5)])
ofproto-dpif.at:AT_SETUP([ofproto-dpif packet-out goto_table])
ofproto-dpif.at:AT_SETUP([ofproto-dpif packet-out table-miss (continue)])
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ovn ovsdb clustering question

[Ben Pfaff]

It's always useful to get feedback from people new to the project.  It
would be even better if you would send some an update to or a bug report
for the documentation, so that the next person to try it will have a
better experience.  A blog post is great but it's something external to
the project so it's harder to find.

On Wed, May 26, 2021 at 10:05:56AM -0400, Satish Patel wrote:
> Hi Numan,
> 
> Finally i have created small blog on OVSDB clustering so it help out
> new folks - https://satishdotpatel.github.io/openstack-ansible-ovn-clustering/
> 
> On Mon, May 24, 2021 at 5:58 PM Satish Patel  wrote:
> >
> > Hi Numan,
> >
> > Sorry for delay reply but I figured it out how to setup cluster basically I 
> > have to remove everything from /var/lib/ovn directory on each new nodes 
> > before I join them to cluster.
> >
> > Now I have other issue where I messed up my cluster using leave command and 
> > don’t know how to rejoin it. So basically I destroy cluster and rebuild it 
> > but in that process i lost my ovsdb database and now I don’t know how to 
> > restore previous data? I found some backup files inside /var/lib/ovn/ 
> > directories and I did restore using ovsdb-client utility but they didn’t 
> > help.
> >
> > I love ovn design but missing documents specially related cluster operation 
> > and whenever I google something all I found people asking question but not 
> > good answer. It would be great to have nice cluster operation and 
> > management doc. (I’m planning to write blog once I get everything working 
> > in lab)
> >
> > Sent from my iPhone
> >
> > > On May 21, 2021, at 4:35 PM, Numan Siddique  wrote:
> > >
> > > On Fri, May 21, 2021 at 9:53 AM Satish Patel  
> > > wrote:
> > >>
> > >> Folks,
> > >>
> > >> I have 3 controller nodes and am trying to setup clustering for OVN
> > >> deployment, but lack enough documentation and have some issues and
> > >> questions regarding it.
> > >>
> > >> I found this document but again its little confusing and very old -
> > >> https://mail.openvswitch.org/pipermail/ovs-discuss/2018-March/046470.html
> > >>
> > >> # controller 1
> > >>
> > >> /usr/share/ovn/scripts/ovn-ctl --db-nb-addr=172.30.40.93 \
> > >> --db-nb-create-insecure-remote=yes \
> > >> --db-sb-addr=172.30.40.93 \
> > >> --db-sb-create-insecure-remote=yes \
> > >> --db-nb-cluster-local-addr=172.30.40.93 \
> > >> --db-sb-cluster-local-addr=172.30.40.93 \
> > >> --ovn-northd-nb-db=tcp:172.30.40.93:6641,tcp:172.30.40.25:6641,tcp:172.30.40.177:6641
> > >> \
> > >> --ovn-northd-sb-db=tcp:172.30.40.93:6642,tcp:172.30.40.25:6642,tcp:172.30.40.177:6642
> > >> \
> > >> start_northd
> > >>
> > >>
> > >> # controller 2
> > >>
> > >> /usr/share/ovn/scripts/ovn-ctl --db-nb-addr=172.30.40.25 \
> > >> --db-nb-create-insecure-remote=yes \
> > >> --db-sb-addr=172.30.40.25 \
> > >> --db-sb-create-insecure-remote=yes \
> > >> --db-nb-cluster-local-addr=172.30.40.25 \
> > >> --db-sb-cluster-local-addr=172.30.40.25 \
> > >> --db-nb-cluster-remote-addr=172.30.40.93 \
> > >> --db-sb-cluster-remote-addr=172.30.40.93 \
> > >> --ovn-northd-nb-db=tcp:172.30.40.93:6641,tcp:172.30.40.25:6641,tcp:172.30.40.177:6641
> > >> \
> > >> --ovn-northd-sb-db=tcp:172.30.40.93:6642,tcp:172.30.40.25:6642,tcp:172.30.40.177:6642
> > >> \
> > >> start_northd
> > >>
> > >>
> > >> # controller 3
> > >>
> > >> /usr/share/ovn/scripts/ovn-ctl --db-nb-addr=172.30.40.177 \
> > >> --db-nb-create-insecure-remote=yes \
> > >> --db-nb-cluster-local-addr=172.30.40.177 \
> > >> --db-sb-addr=172.30.40.177 \
> > >> --db-sb-create-insecure-remote=yes \
> > >> --db-sb-cluster-local-addr=172.30.40.177 \
> > >> --db-nb-cluster-remote-addr=172.30.40.93 \
> > >> --db-sb-cluster-remote-addr=172.30.40.93 \
> > >> --ovn-northd-nb-db=tcp:172.30.40.93:6641,tcp:172.30.40.25:6641,tcp:172.30.40.177:6641
> > >> \
> > >> --ovn-northd-sb-db=tcp:172.30.40.93:6642,tcp:172.30.40.25:6642,tcp:172.30.40.177:6642
> > >> \
> > >> start_northd
> > >>
> > >> ## Validation steps
> > >>
> > >> controller-2# export\
> > >> remote="tcp:172.30.40.93:6641,tcp:172.30.40.25:6641,tcp:172.30.40.177:6641"
> > >>
> > >> controller-2# ovn-nbctl --db=$remote show
> > >> controller-2#
> > >>
> > >> In the above command i am seeing output only when it hit controller-1
> > >> node, but for node-2 and note-3 giving me empty output that means data
> > >> replication doesn't work. what is the command to verify
> > >> synchronization working between all 3 nodes?
> > >>
> > >> Do I need to restart any other services?
> > >
> > > Hi Satish,
> > >
> > > Can you check out this script and try it -
> > > https://github.com/ovn-org/ovn-fake-multinode/blob/master/ovn_cluster.sh#L353
> > >
> > > Probably there is no need for you to start northd on all three nodes.
> > > If you want to start northd on 3 nodes,
> > > then they should be configured to connect to the clustered databases.
> > > Probably in your case, ovn-norths
> > > are connecting to the local unix sockets of ovsdb servers.
> > >
> > > 

Re: [ovs-discuss] OVN cluster: how to ensure that both northbound and southbound instances are leaders on the same node?

[Ben Pfaff]

On Tue, May 25, 2021 at 02:00:05AM +, Arkadi Poliakevitch wrote:
> Hi Ben, thanks for your answer but could you please clarify this sentence 
> 
> "There isn't any reason that ovn-northd needs to connect to northbound and 
> southbound databases simultaneously." 
> 
> How would it work then? My understanding is that ovn-northd translates data 
> from Northbound to Southbound dbs as well as propagates some changes 
> backwards like port status. If it only connects to one end, say Southbound, 
> then how does it work?

ovn-northd definitely connects to both databases and remains connected.
You seemed to be saying it does so with some kind of precise timing.  It
doesn't.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVN cluster: how to ensure that both northbound and southbound instances are leaders on the same node?

[Ben Pfaff]

On Mon, May 24, 2021 at 06:49:56AM +, Arkadi Poliakevitch wrote:
> I'm recently puzzled at the situation when northbound ovsdb-server is
> the leader on one cluster node but the southbound ovsdb-server is the
> leader on the other node. My understanding is that the same ovn-northd
> instance should connect to both northbound and southbound sockets at
> the same time in order to function properly, which is not the
> case. One ovn-northd instance locks the connection to the southbound
> leader and the other ovn-northd instance - to the northbound leader,
> which makes no sense, of course. Any thoughts on this?

The northbound and southbound databases are independent.  There is no
need for them to have the same cluster nodes.  They don't even
necessarily both have to be clustered databases.

There isn't any reason that ovn-northd needs to connect to northbound
and southbound databases simultaneously.  In fact, the idea of
simultaneity in a distributed system is problematic.

ovn-northd only locks the connection to the southbound database.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Moving of the primary #openvswitch channel to irc.libera.chat ?

[Ben Pfaff]

On Thu, May 20, 2021 at 09:46:01AM -0300, Flavio Leitner wrote:
> On Wed, May 19, 2021 at 01:22:58PM -0700, Ben Pfaff wrote:
> > On Wed, May 19, 2021 at 10:03:57PM +0200, Ilya Maximets wrote:
> > > Hi.
> > > 
> > > Taking into account some very unhealthy things that happened recently
> > > with FreeNode network and resigning of lots of its stuff [1], we
> > > probably need to discuss if Open vSwitch project wants to change the
> > > IRC server for a primary #openvswitch channel.  User's data is the
> > > main concern, IIUC, as it's unclear what the new management will
> > > do with the network.
> > > 
> > > The main alternative now seems to be the Libera.Chat [2] where most of
> > > the former FreeNode stuff.
> > > 
> > > Some projects already announced [3][4] movement to Libera.Chat.  Others
> > > are discussing the possibility [5].
> > > 
> > > So, I think, it make sense to discuss the future of #openvswitch
> > > channel too.  Any thoughts?
> > > 
> > > Will we have an OVN meeting on a different server tomorrow?
> > 
> > Thanks for sending such a detailed message (with footnotes!).
> > I think I support the move.  I have already registered the #openvswitch
> > channel on libera.chat (and copied the topic across).
> 
> Great! Thanks.
> 
> 
> > I'm going to log in on both servers tomorrow but I suggest that we
> > transition to libera.chat after tomorrow's meeting, since this is pretty
> > short notice and I think that most of us (including me) are only light
> > users of IRC.
> > 
> > Also, I suspect that the infrastructure for recording meetings has not
> > yet moved to libera.chat.  (I did notice that the 'openstack' user just
> > dropped out of #openvswitch.  I think that's the bot that did the
> > meeting recordings.  So maybe that infastructure is moving across right
> > as I write.)
> 
> When things are ported, please change freenode's #openvswitch topic
> to say that we are moving to the new network.

That makes sense.  I will do that.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Moving of the primary #openvswitch channel to irc.libera.chat ?

[Ben Pfaff]

On Wed, May 19, 2021 at 10:03:57PM +0200, Ilya Maximets wrote:
> Hi.
> 
> Taking into account some very unhealthy things that happened recently
> with FreeNode network and resigning of lots of its stuff [1], we
> probably need to discuss if Open vSwitch project wants to change the
> IRC server for a primary #openvswitch channel.  User's data is the
> main concern, IIUC, as it's unclear what the new management will
> do with the network.
> 
> The main alternative now seems to be the Libera.Chat [2] where most of
> the former FreeNode stuff.
> 
> Some projects already announced [3][4] movement to Libera.Chat.  Others
> are discussing the possibility [5].
> 
> So, I think, it make sense to discuss the future of #openvswitch
> channel too.  Any thoughts?
> 
> Will we have an OVN meeting on a different server tomorrow?

Thanks for sending such a detailed message (with footnotes!).
I think I support the move.  I have already registered the #openvswitch
channel on libera.chat (and copied the topic across).

I'm going to log in on both servers tomorrow but I suggest that we
transition to libera.chat after tomorrow's meeting, since this is pretty
short notice and I think that most of us (including me) are only light
users of IRC.

Also, I suspect that the infrastructure for recording meetings has not
yet moved to libera.chat.  (I did notice that the 'openstack' user just
dropped out of #openvswitch.  I think that's the bot that did the
meeting recordings.  So maybe that infastructure is moving across right
as I write.)
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] freenode mess - transition to libera.chat?

[Ben Pfaff]

There's a bit of a mess with the freenode IRC network:
https://lwn.net/Articles/856543

It sounds like we should move #openvswitch to libera.chat.

Comments?  I only use IRC a little bit, so I don't have any personal
context here.

For tomorrow's regular weekly meeting, let's stick to freenode so that
we're not taking people by surprise.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Clustered OVSDB

[Ben Pfaff]

On Tue, May 18, 2021 at 04:36:15PM +0530, RUTUJA MADHURE wrote:
> Hi,
> 
> I was trying to create a clustered ovsdb with three ovsdb-servers.
> 
> 
>- *Node 1*: sudo ovsdb-tool create-cluster /etc/trial/cluster.db
>/etc/trial/cluster.ovsschema tcp:[ip_1]:6000
>- *Node 2*: sudo ovsdb-tool join-cluster /etc/trial/cluster.db cluster
>tcp:[ip_2]:6000 tcp:[ip_1]:6000
>- *Node 3*: sudo ovsdb-tool join-cluster /etc/trial/cluster.db cluster
>tcp:[ip_3]:6000 tcp:[ip_1]:6000
> 
> On all nodes,
> 
>- sudo ovsdb-server --pidfile --detach --log-file --remote ptcp:6222
>/etc/trial/cluster.db
> 
> When the ovsdb-client does a transaction on Node 1 using only Node1 IP, it
> works fine. However, on another Node, below error is shown:
> 
> 
>- sudo ovsdb-client transact
>tcp:[ip_3]:6222,tcp:[ip_2]:6222,tcp:[ip_3]:6222 '["cluster",{"op":"insert",
>"table":"List", "row":{"name":"Item 1"} }]'
> 
> 
> *error: ovsdb-client: transaction returned error:** {"details":"transact
> request specifies database cluster which is not yet available because it
> has not completed joining its cluster","error":"database not available"}*

Seems pretty clear that nodes 2 and 3 didn't successfully connect to
node 1 and join the cluster.  I would first look in the server logs for
nodes 2 and 3.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Regarding OVSDB server

[Ben Pfaff]

On Wed, May 12, 2021 at 04:58:34PM +0530, RUTUJA MADHURE wrote:
> Can you please let me know if an ovsdb-server can serve multiple DBs
> simultaneously and what is the command for adding these DBs to it.

Yes, just specify them on the command line or use ovsdb-server/add-db.
See ovsdb-server(1).

> Also, can we have one clustered database and others being non-clustered
> (normal standalone) managed by the same ovsdb server.

Yes.
___
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

[Ben Pfaff]

On Mon, May 10, 2021 at 11:58:29AM -0700, 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?

I found it.
___
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

[Ben Pfaff]

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
> 

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] EXTERNAL: Re: Unable to add flows - Operation not permitted

[Ben Pfaff]

I don't know.  The problem would be different, since it would be about
whether OVS-DPDK can get the required access to the network device
rather than the kernel module.

On Thu, May 06, 2021 at 01:04:14AM +, Seshadri, Usha wrote:
> Thanks for your response Ben. Since kernel datapath requires root, would 
> using DPDK solve this problem? Can OVS-DPDK run as non-root?
> 
> Thanks,
> Usha
> 
> 
> -Original Message-
> From: Ben Pfaff  
> Sent: Wednesday, May 5, 2021 7:25 PM
> To: Seshadri, Usha (US) 
> Cc: ovs-discuss@openvswitch.org
> Subject: EXTERNAL: Re: [ovs-discuss] Unable to add flows - Operation not 
> permitted
> 
> On Wed, May 05, 2021 at 07:38:45PM +, Seshadri, Usha wrote:
> >   1.  I am trying to add flows by executing the following command on the 
> > CLI as a non-root user, but I see 'Operation not permitted' errors in the 
> > log file as provided below:
> 
> [...]
> 
> > 2021-05-05T16:05:15.278Z|00012|ofproto_dpif|ERR|failed to open 
> > datapath of type system: Operation not permitted 
> > 2021-05-05T16:05:15.278Z|00013|ofproto|ERR|failed to open datapath 
> > br0: Operation not permitted 
> > 2021-05-05T16:05:15.278Z|00014|bridge|ERR|failed to create bridge br0: 
> > Operation not permitted
> 
> I guess that you are using the OVS datapath that uses the Linux kernel 
> module.  Ordinarily, this does require root.  People who work with containers 
> a lot (nto me) might know some workaround.
> 
> >   1.  Running the command again says the bridge already exists.
> > 
> > ovs-vsctl add-br br0
> > ovs-vsctl: cannot create a bridge named br0 because a bridge named br0 
> > already exists
> 
> Yes.  ovs-vsctl just modifies the database, which already has an entry for 
> the bridge.  OVS tries to configure the system to look like the database, but 
> it doesn't succeed because it doesn't have the right permissions.
> 
> > It appears I may be running into permissions issue. The owner + group 
> > permissions are identical, owned by root. The user in OpenShift belongs to 
> > the root group. Does OVS need to run as root? Any help with this is greatly 
> > appreciated.
> 
> I can't help with this part, but maybe someone else can.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Discussion on the logical rationality of flow-limit

[Ben Pfaff]

On Thu, May 06, 2021 at 09:58:57AM +0800, taoyunupt wrote:
> 在 2021-05-06 03:26:46，"Ben Pfaff"  写道：
> 
> >On Fri, Apr 30, 2021 at 06:10:43PM +0800, taoyunupt wrote:
> >> 
> >> 
> >> 
> >> At 2021-04-29 06:39:11, "Ben Pfaff"  wrote:
> >> >On Wed, Apr 28, 2021 at 08:12:06PM +0800, taoyunupt wrote:
> >> >> Hi，
> >> >>  Recently I encountered a TCP connection performance problem, the 
> >> >> test tool is Apache benchmark.
> >> >>  The OVS  in my environment is set for  hardware offload solution.  
> >> >> The "Requests per second" is about 6000/s， it closed to non-offload 
> >> >> solution.
> >> >> 
> >> >> 
> >> >>   "flow-lmit"  has a dynamic balance in udpif_revalidator, it will 
> >> >> modify by the OVS condition（which is pind to "duration"）.   In the 
> >> >> revalidate function, when the number of flows is greater than twice the 
> >> >> "flow-limit" , the delete flow operation will be triggered to delete 
> >> >> all flows; when the number of flows is greater than the "flow-limit", 
> >> >> the aging time will be adjusted to 0.1s, Slowly delete flow.   
> >> >> 
> >> >> 
> >> >>  
> >> >>  I found that the reason for the poor performance is that when the 
> >> >> number of flows in the datapath increases and the processing power of 
> >> >> OVS decreases, a large number of flow deletions are generated. 
> >> >>  As we know, In the hardware offloading scenario, although there 
> >> >> are a lot of flows, in fact, apart from the first packet, there is no 
> >> >> need to process subsequent packets. 
> >> >>  In my opinion, the dynamic balance mechanism is very necessary, 
> >> >> but we need to increase the value of “duration”, or provide some new 
> >> >> switches for some high-performance scenarios, such as hardware 
> >> >> offloading.
> >> >>  Do we still need to restrict the number of flows so strictly? By 
> >> >> the way, do you have another solution to resolve this?   
> >> >
> >> >It's been a long time since I worked on this, but I recall two reasons
> >> >for the flow limit.  First, each flow takes up memory.  Second, each
> >> >flow must be revalidated periodically, meaning that it uses CPU as
> >> >well.
> >> >
> >> >I don't, off-hand, remember the real reasons why the logic for deleting
> >> >flows works as it does.  It might be in the comments or the commit
> >> >messages.  But, I suspect, it is because above the flow-limit we want to
> >> >try to reduce the amount of memory and CPU time dedicated to the cache
> >> >and, if we arrive at twice the flow limit, we conclude that that try
> >> >failed and that we must have a large number of very short flows so that
> >> >caching is not very valuable anyhow.
> >> >
> >> >In a hardware offload scenario, we get rid of some costs (the cost of
> >> >processing and forwarding packets and perhaps the memory cost in the
> >> >datapath) but we still have the cost of revalidating them.  When there
> >> >are many flows, we add the extra cost of balancing flows between
> >> >software and the offload hardware.
> >> >
> >> >Because of the remaining cost and the added ones when there is hardware
> >> >offload, it's not obvious to me that we can stop limiting the number of
> >> >flows.  I think that experimentation and measurements would be needed.
> >> >Perhaps this would be an adjustment to the dynamic algorithm, rather
> >> 
> >> >than a removal of it.
> >> 
> >> 
> >> I think we can increase the init `flow_limit` in udpif_create,1 is a 
> >> small number for current server and OS, and if 'duration' is small ,we 
> >> should increase faster by a lager number not `flow_limit += 1000;`.
> >> I have not better idea for this situation. Do you have some suggestion? I 
> >> am very glad to do this change.
> >
> >What kind of number are you thinking about?  I'd like to come up with a
> >rationale for choosing it.  It might be even better to come up with an
> 
> >algorithm or a heuristic for choosing it.
> 
> 
> I think we could set the initial value to 200,000, and adjust the
> increase to 20,000 each time.  Can you describe the rationale
> algorithm you meationed in detailed ?

I'd expect that whoever is changing it would propose the rationale.

I believe that part of the current rationale is to keep the limit at a
level such that revalidation takes no more than 1 second.  That's an
important aspect too.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Unable to add flows - Operation not permitted

[Ben Pfaff]

On Wed, May 05, 2021 at 07:38:45PM +, Seshadri, Usha wrote:
>   1.  I am trying to add flows by executing the following command on the CLI 
> as a non-root user, but I see 'Operation not permitted' errors in the log 
> file as provided below:

[...]

> 2021-05-05T16:05:15.278Z|00012|ofproto_dpif|ERR|failed to open datapath of 
> type system: Operation not permitted
> 2021-05-05T16:05:15.278Z|00013|ofproto|ERR|failed to open datapath br0: 
> Operation not permitted
> 2021-05-05T16:05:15.278Z|00014|bridge|ERR|failed to create bridge br0: 
> Operation not permitted

I guess that you are using the OVS datapath that uses the Linux kernel
module.  Ordinarily, this does require root.  People who work with
containers a lot (nto me) might know some workaround.

>   1.  Running the command again says the bridge already exists.
> 
> ovs-vsctl add-br br0
> ovs-vsctl: cannot create a bridge named br0 because a bridge named br0 
> already exists

Yes.  ovs-vsctl just modifies the database, which already has an entry
for the bridge.  OVS tries to configure the system to look like the
database, but it doesn't succeed because it doesn't have the right
permissions.

> It appears I may be running into permissions issue. The owner + group 
> permissions are identical, owned by root. The user in OpenShift belongs to 
> the root group. Does OVS need to run as root? Any help with this is greatly 
> appreciated.

I can't help with this part, but maybe someone else can.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Cannot create gtp tunnel

[Ben Pfaff]

On Tue, Apr 27, 2021 at 10:28:10AM +0430, Ash Ash wrote:
> The release docs says
> GTPU tunnel is only supported on userspace datapath. Does it mean that I
> have to use netdev as datapath_type and ovs-vsctl add-br br0 won't work?

The userspace datapath uses datapath_type netdev, yes.

"add-br" is still a valid way to add such a datapath, you just have to
set the datapath-type afterward.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Discussion on the logical rationality of flow-limit

[Ben Pfaff]

On Fri, Apr 30, 2021 at 06:10:43PM +0800, taoyunupt wrote:
> 
> 
> 
> At 2021-04-29 06:39:11, "Ben Pfaff"  wrote:
> >On Wed, Apr 28, 2021 at 08:12:06PM +0800, taoyunupt wrote:
> >> Hi，
> >>  Recently I encountered a TCP connection performance problem, the test 
> >> tool is Apache benchmark.
> >>  The OVS  in my environment is set for  hardware offload solution.  
> >> The "Requests per second" is about 6000/s， it closed to non-offload 
> >> solution.
> >> 
> >> 
> >>   "flow-lmit"  has a dynamic balance in udpif_revalidator, it will 
> >> modify by the OVS condition（which is pind to "duration"）.   In the 
> >> revalidate function, when the number of flows is greater than twice the 
> >> "flow-limit" , the delete flow operation will be triggered to delete all 
> >> flows; when the number of flows is greater than the "flow-limit", the 
> >> aging time will be adjusted to 0.1s, Slowly delete flow.   
> >> 
> >> 
> >>  
> >>  I found that the reason for the poor performance is that when the 
> >> number of flows in the datapath increases and the processing power of OVS 
> >> decreases, a large number of flow deletions are generated. 
> >>  As we know, In the hardware offloading scenario, although there are a 
> >> lot of flows, in fact, apart from the first packet, there is no need to 
> >> process subsequent packets. 
> >>  In my opinion, the dynamic balance mechanism is very necessary, but 
> >> we need to increase the value of “duration”, or provide some new switches 
> >> for some high-performance scenarios, such as hardware offloading.
> >>  Do we still need to restrict the number of flows so strictly? By the 
> >> way, do you have another solution to resolve this?   
> >
> >It's been a long time since I worked on this, but I recall two reasons
> >for the flow limit.  First, each flow takes up memory.  Second, each
> >flow must be revalidated periodically, meaning that it uses CPU as
> >well.
> >
> >I don't, off-hand, remember the real reasons why the logic for deleting
> >flows works as it does.  It might be in the comments or the commit
> >messages.  But, I suspect, it is because above the flow-limit we want to
> >try to reduce the amount of memory and CPU time dedicated to the cache
> >and, if we arrive at twice the flow limit, we conclude that that try
> >failed and that we must have a large number of very short flows so that
> >caching is not very valuable anyhow.
> >
> >In a hardware offload scenario, we get rid of some costs (the cost of
> >processing and forwarding packets and perhaps the memory cost in the
> >datapath) but we still have the cost of revalidating them.  When there
> >are many flows, we add the extra cost of balancing flows between
> >software and the offload hardware.
> >
> >Because of the remaining cost and the added ones when there is hardware
> >offload, it's not obvious to me that we can stop limiting the number of
> >flows.  I think that experimentation and measurements would be needed.
> >Perhaps this would be an adjustment to the dynamic algorithm, rather
> 
> >than a removal of it.
> 
> 
> I think we can increase the init `flow_limit` in udpif_create,1 is a 
> small number for current server and OS, and if 'duration' is small ,we should 
> increase faster by a lager number not `flow_limit += 1000;`.
> I have not better idea for this situation. Do you have some suggestion? I am 
> very glad to do this change.

What kind of number are you thinking about?  I'd like to come up with a
rationale for choosing it.  It might be even better to come up with an
algorithm or a heuristic for choosing it.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Discussion on the logical rationality of flow-limit

[Ben Pfaff]

On Wed, Apr 28, 2021 at 08:12:06PM +0800, taoyunupt wrote:
> Hi，
>  Recently I encountered a TCP connection performance problem, the test 
> tool is Apache benchmark.
>  The OVS  in my environment is set for  hardware offload solution.  The 
> "Requests per second" is about 6000/s， it closed to non-offload solution.
> 
> 
>   "flow-lmit"  has a dynamic balance in udpif_revalidator, it will modify 
> by the OVS condition（which is pind to "duration"）.   In the revalidate 
> function, when the number of flows is greater than twice the "flow-limit" , 
> the delete flow operation will be triggered to delete all flows; when the 
> number of flows is greater than the "flow-limit", the aging time will be 
> adjusted to 0.1s, Slowly delete flow.   
> 
> 
>  
>  I found that the reason for the poor performance is that when the number 
> of flows in the datapath increases and the processing power of OVS decreases, 
> a large number of flow deletions are generated. 
>  As we know, In the hardware offloading scenario, although there are a 
> lot of flows, in fact, apart from the first packet, there is no need to 
> process subsequent packets. 
>  In my opinion, the dynamic balance mechanism is very necessary, but we 
> need to increase the value of “duration”, or provide some new switches for 
> some high-performance scenarios, such as hardware offloading.
>  Do we still need to restrict the number of flows so strictly? By the 
> way, do you have another solution to resolve this?   

It's been a long time since I worked on this, but I recall two reasons
for the flow limit.  First, each flow takes up memory.  Second, each
flow must be revalidated periodically, meaning that it uses CPU as
well.

I don't, off-hand, remember the real reasons why the logic for deleting
flows works as it does.  It might be in the comments or the commit
messages.  But, I suspect, it is because above the flow-limit we want to
try to reduce the amount of memory and CPU time dedicated to the cache
and, if we arrive at twice the flow limit, we conclude that that try
failed and that we must have a large number of very short flows so that
caching is not very valuable anyhow.

In a hardware offload scenario, we get rid of some costs (the cost of
processing and forwarding packets and perhaps the memory cost in the
datapath) but we still have the cost of revalidating them.  When there
are many flows, we add the extra cost of balancing flows between
software and the offload hardware.

Because of the remaining cost and the added ones when there is hardware
offload, it's not obvious to me that we can stop limiting the number of
flows.  I think that experimentation and measurements would be needed.
Perhaps this would be an adjustment to the dynamic algorithm, rather
than a removal of it.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] pop_vlan action is missing in datapath actions with write_action(group)

[Ben Pfaff]

On Wed, Apr 07, 2021 at 11:02:25PM +0530, Rudra Surya Bhaskara Rao via discuss 
wrote:
> Hi,
> 
>  
> 
> Please help me with the below issue. Please let me know is it expected
> behaviour or issue.
> 
> With the write_actions(group) inside a group bucket is ignoring the
> pop_vlan action . Please find the sample flows and groups configuration
> below:

I think you're running into the way that each bucket is executed
independently and doesn't affect what happens later in the pipeline.
ovs-actions(7) documents it as follows.  This complies with my
understanding of the OpenFlow specification:

   A group action usually executes the action set or sets in one or
   more group buckets. Open vSwitch saves the packet and metadata
   before it executes each bucket, and then restores it
   afterward. Thus, when a group executes more than one bucket, this
   means that each bucket executes on the same packet and meta‐data.
   Moreover, regardless of the number of buckets executed, the
   packet and metadata are the same before and after executing the
   group.

   Sometimes saving and restoring the packet and metadata can be
   undesirable.  In these situations, workarounds are possible. For
   example, consider a pipeline design in which a select group
   bucket is to communicate to a later stage of processing a value
   based on which bucket was selected. An obvious design would be
   for the bucket to communicate the value via set_field on a
   register.  This does not work because registers are part of the
   metadata that group saves and restores. The following alternative
   bucket designs do work:

  • Recursively invoke the rest of the pipeline with
resubmit.

  • Use resubmit into a table that uses push to put the
value on the stack for the caller to pop off. This works
because group preserves only packet data and metadata,
not the stack.

(This design requires indirection through resubmit
because actions sets may not contain push or pop
actions.)
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Forwarding delay of packets sent from the tap interface

[Ben Pfaff]

On Fri, Apr 02, 2021 at 07:03:04AM +, Nobuhiro Miki wrote:
> Hi all,
> 
> I have a question about the main thread in ovs-vswitch.c. The following
> are the details, and any comments would be appreciated.
> 
> In ovs-vswitchd, netdev_linux_rxq_recv function [1] and
> handle_flow_stats_request function [2] are running on the same thread.

I don't think that should be the case when PMDs are enabled.

Your sample shell script shows enabling DPDK with dpdk-init after
starting OVS.  Most OVS features can be reconfigured at runtime, but not
this one.  Changing this value requires restarting the daemon.  That
might be the problem you see.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [Issue]Datapath somehow change from system to netdev

[Ben Pfaff]

On Fri, Mar 12, 2021 at 11:38:03AM +0800, Jhen-Hao Yu wrote:
> The datapath is orignailly "system", but somehow change to "netdev"
> after rebooting compute node.
> 
> Could you give us some advice on this issue?

OVS would not change that on its own.  Some outside agent, such as
something in OpenStack, must have done it.  You might be able to find
out what by reading the database log via "ovsdb-tool -mm show-log".  The
comments often say what made a given database change.

You should probably follow up with the OpenStack networking folks.  We
can't really help much.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Netlink for Dump-flow command

[Ben Pfaff]

I don't see how this can hope to dump flows because it doesn't have the
name of the Generic Netlink group for the flow table in it anywhere.

It also has some oddities that might show a misunderstanding of how
Netlink works.  A netlink dump operation can't fail due to packet drops
or buffer overruns because the buffer isn't filled on a timer or all at
once; it's generated by the kernel chunk by chunk as userspace reads it.

You might want to read the OVS code for dumping flows.

On Fri, Mar 12, 2021 at 08:42:17PM +0530, Muddu Prasad wrote:
> Hi,
> 
> I am trying to develop netlink interface to fetch flow details that are
> displayed as part of ovs-dpctl dump-flow command.
> 
> For the request I send I am getting invalid response from kernel.
> Can somebody help me please?
> 
> Attached is the code that I am using to capture flow details,
> 
> Regards,
> Prasad
> 
> -- 
> Disclaimer:This message is intended only for the designated recipient(s). 
> It may contain confidential or proprietary information and may be subject 
> to other confidentiality protections. If you are not a designated 
> recipient, you may not review, copy or distribute this message. Please 
> notify the sender by e-mail and delete this message. GlobalEdge does not 
> accept any liability for virus infected mails.
> 

> 
> static int data_cb(const struct nlmsghdr *nlh, void *data)
> {
> struct nf_conntrack *ct;
> char buf[BUFF_SIZE];
> memset(buf, OK, sizeof(buf));
> unsigned int flags = NFCT_OF_ID;
> #if 0
> ct = nfct_new();
> if (ct == NULL) return MNL_CB_OK;
> 
> nfct_nlmsg_parse(nlh, ct);
> nfct_snprintf(buf, sizeof(buf), ct, NFCT_T_UNKNOWN, NFCT_O_DEFAULT, 
> flags);
> printf("%s\n\n", buf);
> 
> nfct_destroy(ct);
> #endif
> return MNL_CB_OK;
> }
> 
> static void  timeout_cb(EV_P_ ev_timer *w, int revents)
> {
> struct mnl_socket *nl;
> struct nlmsghdr *nlh;
> //struct nfgenmsg *nfh;
> struct genlmsghdr *nfh;
> char buf[MNL_SOCKET_DUMP_SIZE];
> unsigned int seq, portid;
> int ret= OK, on = OK,  buffersize = (1 << 22);
> 
> /* Set high priority for this process, less chances to overrun
>  * the netlink receiver buffer since the scheduler gives this process
>  * more chances to run.
>  */
> nice(-20);
>  //   nl = mnl_socket_open(NETLINK_NETFILTER);
> nl = mnl_socket_open(NETLINK_GENERIC);
> if (nl == NULL)
> {
> printf("%s: mnl_socket_open failed: %s", __func__, strerror(errno));
> exit(EXIT_FAILURE);
> }
> 
> ret = mnl_socket_bind(nl, 0, MNL_SOCKET_AUTOPID);
> if(ret < OK)
> {
> printf("%s: mnl_socket_bind failed: %s", __func__, strerror(errno));
> exit(EXIT_FAILURE);
> }
> 
> /* Set netlink receiver buffer to 16 MBytes, to avoid packet drops */
> setsockopt(mnl_socket_get_fd(nl), SOL_SOCKET, SO_RCVBUFFORCE,
> , sizeof(socklen_t));
> 
> /* The two tweaks below enable reliable event delivery, packets may
>  * be dropped if the netlink receiver buffer overruns. This happens ...
>  *
>  * a) if the kernel spams this user-space process until the receiver
>  *is filled.
>  *
>  * or:
>  *
>  * b) if the user-space process does not pull messages from the
>  *receiver buffer so often.
>  */
> mnl_socket_setsockopt(nl, NETLINK_BROADCAST_ERROR, , sizeof(int));
> mnl_socket_setsockopt(nl, NETLINK_NO_ENOBUFS, , sizeof(int));
> 
> portid = mnl_socket_get_portid(nl);
> nlh = mnl_nlmsg_put_header(buf);
> nlh->nlmsg_type =  16; //(NFNL_SUBSYS_CTNETLINK << 8) | IPCTNL_MSG_CT_GET;
> nlh->nlmsg_flags = NLM_F_ACK | NLM_F_REQUEST | NLM_F_DUMP;
> nlh->nlmsg_seq = seq = time(NULL);
> 
> nfh = mnl_nlmsg_put_extra_header(nlh, sizeof(struct genlmsghdr 
> /*nfgenmsg*/));
>// nfh->nfgen_family = AF_INET;
> nfh->cmd = OVS_DP_CMD_GET; //AF_INET;
> nfh->version = NFNETLINK_V0;
> //nfh->res_id = OK;
> nfh->reserved = OK;
> printf("Before sending \n");
> ret = mnl_socket_sendto(nl, nlh, nlh->nlmsg_len);
> 
> printf("After Sending %d  \n", ret);
> if (ret == NO_OK)
> {
> printf("%s: mnl_socket_sendto failed: %s", __func__, strerror(errno));
> exit(EXIT_FAILURE);
> }
> 
> ret = mnl_socket_recvfrom(nl, buf, sizeof(buf));
> printf("After receiving %d \n ", ret);
> while (ret > OK)
> {
>   printf(" Processing Retrun value \n ");
>   ret = mnl_cb_run(buf, ret, seq, portid, data_cb, NULL);
> if (ret <= MNL_CB_STOP) break;
> 
> ret = mnl_socket_recvfrom(nl, buf, sizeof(buf));
> }
> if (ret == NO_OK)
> {
> printf("%s: mnl_socket_recvfrom failed: %s", __func__, 
> strerror(errno));
> exit(EXIT_FAILURE);
> }
> 
> mnl_socket_close(nl);
> return;
> 
> }
> 
> int main(void)
> {
> struct ev_loop *loop = ev_default_loop(0);
>// target_log_open("CONNTRACK Test\n", 0);
>// 

Re: [ovs-discuss] Bond-Failover between VM and PHY possible

[Ben Pfaff]

On Fri, Mar 12, 2021 at 01:51:14AM +0100, ToXiC ToXiC wrote:
> Hello,
> I was wondering if it would be possible to use OVS to create a failover
> bond and attach it to a bridge.
> 
> I know how to setup an ovs bridge so that all my VMs can communicate, one
> of them is my virtualRouter using opnSense. Whe this virtualRouter is down
> I would like to add a physical NIC as failover for my virtualRouter since I
> can plug this physical NIC to my switch who also have connection to a
> failover opnSense router that could take over and keep traffic flowing,
> albeit at lower speeds since my virtualRouter has several physical NICs in
> a LAG and a single 10GB/s virtual link to my other VMS, while the failover
> would only have 1GB/s to the ovs bridge to my other VMs
> 
> Confirmation of the feasibility and insights on how to set that up would be
> realy welcome.

OVS has a couple of mechanisms that can help with implementing failover.
One of them is the "bundle" action that you can find documented in the
ovs-actions manpage.  Another is "fast-failover" groups, which work as
documented in the OpenFlow specifications.  Either way, you would need
to figure out how OVS can decide that the virtual router has
failed.  I think that you could use OVS's support for BFD or CFM for
this; some other method might be appropriate.

Some assembly would be required here.  I don't know of a place where you
can find a documented recipe for this.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] vxlan port was deleted while using `ovs-ctl restart` to do ovs hot upgrading

[Ben Pfaff]

Thanks for sending a technical question to the discuss mailing list.  I
don't think you'll get a very good discussion going by sending HTML-only
email.  I'd encourage you to re-send your question in text-only or in
HTML+plaintext format.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] BGP EVPN support

[Ben Pfaff]

I'm not arguing against it, I just don't know of anyone working on it.

On Wed, Mar 10, 2021 at 12:23:31AM +0300, Sergey Chekanov wrote:
> I mean why not use EVPN to extend OVN logical switch (with current VTEP
> Gateway functionality)?
> Is it a good Idea to implement it as a BGP daemon which will takes records
> from vtep database?
> The reason is: not all switches support vtep schema, but almost all support
> EVPN.
> 
> Maybe it is bad idea... We just start use OVN, so I am not sure, will be
> happy to listen your opinions.
> 
> On 10.03.2021 00:11, Ben Pfaff wrote:
> > On Mon, Mar 08, 2021 at 01:40:58PM +0300, Sergey Chekanov wrote:
> > > Is there are any plans for support BGP EVPN for extending virtual networks
> > > to ToR hardware switches?
> > > Or why it is bad idea?
> > I haven't heard anyone mention such plans.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] BGP EVPN support

[Ben Pfaff]

On Mon, Mar 08, 2021 at 01:40:58PM +0300, Sergey Chekanov wrote:
> Is there are any plans for support BGP EVPN for extending virtual networks
> to ToR hardware switches?
> Or why it is bad idea?

I haven't heard anyone mention such plans.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ovn-northd-ddlog and rust crate build process

[Ben Pfaff]

On Sun, Mar 07, 2021 at 12:40:56PM +0100, Frode Nordahl wrote:
> On Fri, Mar 5, 2021 at 11:17 PM Ben Pfaff  wrote:
> >
> > On Fri, Mar 05, 2021 at 11:13:09PM +0100, Frode Nordahl wrote:
> > > However, when I got to the building of the rust crates part I found
> > > that it would both rebuild stuff when not needed and not do any
> > > parallelization for individual crate builds.
> > >
> > > This will probably itch enough for me to eventually look at it, but I
> > > thought it would be worthwhile to send this e-mail to the list and ask
> > > if anyone has ideas for how to improve re-use of already built objects
> > > and parallelization of individual crate builds for a rust build
> > > process.
> >
> > I don't think that building an individual crate is something that can be
> > parallelized.  (I'd be happy to be shown to be wrong.)
> 
> Unfortunately you're right, this fairly recent update [0] in the Rustc
> development guide suggests there is a fair amount of groundwork that
> needs to be done before any parallelizing work can come to fruition.
> 
> Some people suggest splitting code into Cargo Workspaces, and I see we
> already do that to some extent, and I kind of doubt it would be worth
> splitting any further just for the sake of faster compilation. Having
> said that, some of the generated rust code files are pretty huge, so
> maybe there could be something there.

Leonid has started work on dividing the ddlog-generated code into
multiple crates.  Some ddlog programs benefit from it already, but OVN
is the largest ddlog program out there and it doesn't divide up very
easily automatically.

Trust me, I'd like to parallelize it better myself, I have a 64-core
Threadripper 3990X here.

One thing I haven't asked Leonid yet is, would it help if we divided the
.dl files up into multiple files more granularly?
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ovn-northd-ddlog and rust crate build process

[Ben Pfaff]

On Fri, Mar 05, 2021 at 11:13:09PM +0100, Frode Nordahl wrote:
> However, when I got to the building of the rust crates part I found
> that it would both rebuild stuff when not needed and not do any
> parallelization for individual crate builds.
> 
> This will probably itch enough for me to eventually look at it, but I
> thought it would be worthwhile to send this e-mail to the list and ask
> if anyone has ideas for how to improve re-use of already built objects
> and parallelization of individual crate builds for a rust build
> process.

I don't think that building an individual crate is something that can be
parallelized.  (I'd be happy to be shown to be wrong.)

I haven't noticed unnecessary rebuilds.  Do you have an example?
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Contribution to OVS source code

[Ben Pfaff]

On Tue, Feb 23, 2021 at 01:28:45AM +0500, Farhat Ullah wrote:
> I am interested in contributing to OVS source code by improving the
> functionality and adding new features. Currently, I know how to set up the
> OVS bridges and VFs, add ovs-ofctl rules. I am also aware of TC/Flower
> rules and how OVS works with TC/Flower to offload the rules to the
> hardware. I have done some work on ndo_setup_tc and parsing of the rules.
> 
> Can you guide me? What is the procedure?

Hi Farhat.  You can read about how to contribute to OVS in
Documentation/internals/contributing/ in the source tree.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Modifying udp ports with OVS flows, match on udp_dst=53 but can't do mod_udp_dst=30053

[Ben Pfaff]

On Mon, Feb 22, 2021 at 05:45:41PM +, Brendan Doyle wrote:
> If I try add a rule as follows:
> ovs-ofctl add-flow br-ext 
> priority=1001,ip,in_port="patch-ln-ls_vcn",nw_proto=17,nw_dst=169.254.239.254,udp_dst=53,actions=mod_nw_dst:253.255.0.31,mod_udp_dst=30053,output:"bond0.3900"
> 
> I get :
> ovs-ofctl: unknown action mod_udp_dst
> 
> 
> Yet OVS is quiet happy with:
> 
> 
> ovs-ofctl add-flow br-ext 
> priority=1001,ip,in_port="patch-ln-ls_vcn",nw_proto=17,nw_dst=169.254.239.254,udp_dst=53,actions=mod_nw_dst:253.255.0.31,mod_tp_dst=30053,output:"bond0.3900"
> 
> So how come I can use udp_dst to match, but have to use tp_dst to modify?

You might be under the misapprehension that "tp" stands for "tcp".  It
does not.  It stands for "transport", i.e. the L4 protocol in use.
Similarly, "nw" stands for "network" (L3) and the "dl" used elsewhere
stands for "datalink" (L2).

For matching, it makes some sense to be able to specify the transport
protocol when matching the transport port, since then the nw_proto can
be omitted (although I see you included it anyway).  But there's no
value in specifying the particular transport protocol for modifying it,
since it doesn't normally make sense to modify a transport port without
knowing the transport protocol.

> And is the above the same as having:
> 
> ovs-ofctl add-flow br-ext 
> priority=1001,ip,in_port="patch-ln-ls_vcn",nw_proto=17,nw_dst=169.254.239.254,tp_dst=53,actions=mod_nw_dst:253.255.0.31,mod_tp_dst=30053,output:"bond0.3900"

Yes, since nw_proto=17 is still in there.  Without it, OVS wouldn't know
what transport protocol tp_dst=53 is supposed to match against.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] xml parsing issues with lib/db-ctl-base.xml

[Ben Pfaff]

On Wed, Feb 03, 2021 at 06:02:02PM +0100, Ilya Maximets wrote:
> > On Tue, Feb 02, 2021 at 05:02:54PM -0500, Flavio Fernandes wrote:
> >> Hi Ben,
> >> 
> >> compiling ovn master with ovs master is upset because of an xml issue in 
> >> the file:  lib/db-ctl-base.xml
> >> 
> >> Could you help fixing it, please?
> > 
> > Oops, I applied this:
> 
> 
> 
> Thanks, Ben for fixing this.  I missed that typo during review.
> 
> I was trying to figure out why we didn't catch this issue in OVS build
> and I found that we actually have 2 copies of several parts of manpages.
> One .man file and one .xml file for following docs:
> 
> lib/common.xml
> lib/daemon.xml
> lib/db-ctl-base.xml
> lib/ssl.xml
> lib/ssl-bootstrap.xml
> lib/ssl-peer-ca-cert.xml
> lib/table.xml
> lib/vlog.xml
> lib/unixctl.xml
> 
> All these files were added to be used in OVN man pages and has no users in
> OVS code base.  We should, probably, generate man pages from these xml files
> instead of having *.man duplicates to catch this kind of issues.

At one point I was trying to convert all the manpages to XML.  I stopped
before I finished.

These days, .rst files might be a better solution.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] xml parsing issues with lib/db-ctl-base.xml

[Ben Pfaff]

On Tue, Feb 02, 2021 at 05:02:54PM -0500, Flavio Fernandes wrote:
> Hi Ben,
> 
> compiling ovn master with ovs master is upset because of an xml issue in the 
> file:  lib/db-ctl-base.xml
> 
> Could you help fixing it, please?

Oops, I applied this:

-8<--cut here------>8--

From: Ben Pfaff 
Date: Tue, 2 Feb 2021 14:37:43 -0800
Subject: [PATCH] db-ctl-base: Fix XML syntax error.

Signed-off-by: Ben Pfaff 
Fixes: 9513c0233dca ("db-ctl-base: Add {in} and {not-in} set relational 
operators.")
Reported-by: Flavio Fernandes 
---
 lib/db-ctl-base.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/db-ctl-base.xml b/lib/db-ctl-base.xml
index 379af2d07760..f6efe98eaf03 100644
--- a/lib/db-ctl-base.xml
+++ b/lib/db-ctl-base.xml
@@ -152,7 +152,7 @@
 later:
   
 
-  
 {in}
 
   Selects records in which every element in
-- 
2.28.0

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] "ovs-vsctl get openvswitch . other_config" results in "WARN connection dropped"

[Ben Pfaff]

On Tue, Feb 02, 2021 at 07:22:55PM +0100, Ilya Maximets wrote:
> We might explore different ways to fix that though, e.g. allow
> ovsdb-server to not reply to 'db_change_aware' requests if client
> will set a special flag, or something like that.  

To take that approach, I'd recommend introducing a JSON-RPC notification
instead of using a request, because JSON-RPC specifies that requests are
paired with replies (and notifications are not).
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] "ovs-vsctl get openvswitch . other_config" results in "WARN connection dropped"

[Ben Pfaff]

Probably, some debugging of the situation could lead to figuring out
what's going on and thereby avoiding the messages.  I don't have the
necessary cycles to do that myself.

On Mon, Feb 01, 2021 at 10:33:58PM +, Tobias Hofmann (tohofman) wrote:
> I just see the warning, however on our system we periodically run “ovs-vsctl 
> get openvswitch . other_config” which bloats the log file over time. I’d like 
> to prevent that.
> 
> From: Ben Pfaff 
> Date: Monday, 1. February 2021 at 22:09
> To: Tobias Hofmann (tohofman) 
> Cc: ovs-discuss@openvswitch.org 
> Subject: Re: [ovs-discuss] "ovs-vsctl get openvswitch . other_config" results 
> in "WARN connection dropped"
> On Mon, Feb 01, 2021 at 01:41:05PM +, Tobias Hofmann (tohofman) via 
> discuss wrote:
> > Hello everybody,
> >
> > I have Open vSwitch 2.11.1 installed with DPDK 18.11.0 and DB Schema 7.16.1.
> > Every time I execute: “ovs-vsctl get open_vswitch . other_config”. I get 
> > the following WARN message in ovsdb-server.log:
> > 2021-02-01T13:31:21.773Z|07709|jsonrpc|WARN|unix#7443: receive error: 
> > Connection reset by peer
> > 2021-02-01T13:31:21.774Z|07710|reconnect|WARN|unix#7443: connection dropped 
> > (Connection reset by peer)
> >
> > When running: ”ovs-vsctl show” I don’t see any of these WARN logs.
> > Interestingly, when running: “ovs-vsctl -vjsonrpc get open_vswitch . 
> > other_config”. I also DO NOT see any WARN log messages.
> >
> > Does anyone have an idea what causes this issue and how to fix it?
> 
> Do you see some actual issue, or just a warning message in the log?  The
> most probable reason for the message is that ovsdb-server has some RPC
> message queued up to send ovs-vsctl, but ovs-vsctl is done and exits
> without reading it.  Probably, adding -vjsonrpc slows ovs-vsctl down
> enough that it reads that RPC, suppressing the log.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] "ovs-vsctl get openvswitch . other_config" results in "WARN connection dropped"

[Ben Pfaff]

On Mon, Feb 01, 2021 at 01:41:05PM +, Tobias Hofmann (tohofman) via discuss 
wrote:
> Hello everybody,
> 
> I have Open vSwitch 2.11.1 installed with DPDK 18.11.0 and DB Schema 7.16.1.
> Every time I execute: “ovs-vsctl get open_vswitch . other_config”. I get the 
> following WARN message in ovsdb-server.log:
> 2021-02-01T13:31:21.773Z|07709|jsonrpc|WARN|unix#7443: receive error: 
> Connection reset by peer
> 2021-02-01T13:31:21.774Z|07710|reconnect|WARN|unix#7443: connection dropped 
> (Connection reset by peer)
> 
> When running: ”ovs-vsctl show” I don’t see any of these WARN logs.
> Interestingly, when running: “ovs-vsctl -vjsonrpc get open_vswitch . 
> other_config”. I also DO NOT see any WARN log messages.
> 
> Does anyone have an idea what causes this issue and how to fix it?

Do you see some actual issue, or just a warning message in the log?  The
most probable reason for the message is that ovsdb-server has some RPC
message queued up to send ovs-vsctl, but ovs-vsctl is done and exits
without reading it.  Probably, adding -vjsonrpc slows ovs-vsctl down
enough that it reads that RPC, suppressing the log.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] why the datapath-id choose the minimum non-local MAC address among all of the ports in bridge

[Ben Pfaff]

On Thu, Jan 28, 2021 at 09:57:49AM +0800, taoyunupt wrote:
> At 2021-01-28 09:29:45, "Ben Pfaff"  wrote:
> >On Wed, Jan 27, 2021 at 06:13:12PM +0800, taoyunupt wrote:
> >> Hi,
> >> If no configure of "datapath-id" in other_config of br, then it will  
> >> choose the minimum non-local MAC address among all of the ports in bridge. 
> >> The relevant code is in the find_local_hw_addr 
> >> function（https://github.com/openvswitch/ovs/blob/master/vswitchd/bridge.c#L2322）.
> >>   
> >> 
> >> In this case, If a new  port with miner mac, it will change the dpid 
> >> ,and the mac of br-int. It will cause frequently reset with SDN controller 
> >> by ofproto_set_datapath_id function.
> >> Is this reasonable？
> >
> >This solution is the best one we know.  It yields a predictable port MAC
> >address and datapath ID given a particular collection of ports.  It's
> >been that way for perhaps 10 years or so.
> >
> 
> >I don't know what a miner mac is.
> 
> 
> The "miner" should be "smaller"， sorry for that. 
> 
> 
> If a new  port with smaller MAC, it will change the dpid ,and the MAC of  
> bridge, so  a connection  reset will happen. I don't understand why the mac 
> address of the port affects the mac address of the bridge . I think hold a 
> MAC address(such as default ea?) steady is neccesary, what do you think?

The reason that this happens is exactly to keep the MAC address of the
bridge steady.

Here's the use case it was designed to address.  It started with
XenServer, but other hypervisors work similarly.  Each physical NIC that
might have VMs on it gets put into a bridge, and then the IP address for
that NIC (if any) gets migrated from the pnic to the bridge device.  You
want the bridge device to have the same MAC address as the physical NIC,
so taking the minimum MAC address does that.  Adding virtual NICs
doesn't change it because OVS ignores random MACs.

If you want a stable MAC, but you have some different situation, set
your own MAC.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] why the datapath-id choose the minimum non-local MAC address among all of the ports in bridge

[Ben Pfaff]

On Wed, Jan 27, 2021 at 06:13:12PM +0800, taoyunupt wrote:
> Hi,
> If no configure of "datapath-id" in other_config of br, then it will  
> choose the minimum non-local MAC address among all of the ports in bridge. 
> The relevant code is in the find_local_hw_addr 
> function（https://github.com/openvswitch/ovs/blob/master/vswitchd/bridge.c#L2322）.
>   
> 
> In this case, If a new  port with miner mac, it will change the dpid ,and 
> the mac of br-int. It will cause frequently reset with SDN controller by 
> ofproto_set_datapath_id function.
> Is this reasonable？

This solution is the best one we know.  It yields a predictable port MAC
address and datapath ID given a particular collection of ports.  It's
been that way for perhaps 10 years or so.

I don't know what a miner mac is.

If you want a bridge to have a particular MAC address, it's easy to set
one.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ovs-ofctl broken when getting table features reply

[Ben Pfaff]

Oh, I see.  I'm glad I was able to help.

On Fri, Jan 22, 2021 at 10:21:21AM +0800, Dickens Yeh wrote:
> Thanks for helping me.
> 
> I find the section in OF1.3.2 spec, and re-check with pcap file as you said.
> I think I was missed the important message: "table features message missing
> required property",
> but only focus on "received bad reply: (***only uses 512 bytes out of
> 7056***)".
> 
> Thanks.
> 
> best wishes,
> Dickens Yeh
> 
> 
> 
> 
> 
> Ben Pfaff  於 2021年1月22日 週五 上午6:44寫道：
> 
> > OK, I figured out the problem.
> >
> > Property 10, OFPTFPT_WILDCARDS, is missing.  OF1.3 section 7.3.5.5.2
> > says that it's mandatory: "If a specific property does not have any
> > capability (for example no Set-Field support), a property with an empty
> > list must be included in the property list."  I think that OVS is
> > correctly rejecting this set of table features.
> >
> > On Fri, Jan 08, 2021 at 01:00:36PM +0800, Dickens Yeh wrote:
> > > Hi Ben,
> > > Thanks for your reply.
> > >
> > > I can open it with Wireshark, decode as 'OpenFlow', and it shows info as
> > > following(also in attachment file):
> > > OFPT_HELLO,
> > > OFPT_MULTIPART_REQUEST, OFPMP_FLOW
> > > OFPT_MULTIPART_REPLY, OFPMP_FLOW
> > > OFPT_HELLO,
> > > OFPT_MULTIPART_REUQEST, OFPMP_TABLE_FEATURES
> > > OFPT_MULTIPART_REPLY, OFPMP_TABLE_FEATURES
> > >
> > > I also use your command to parse pcap file, I don't know why it shows
> > > "OFPST_FLOW request" but there is no "OFPST_FLOW reply" message.
> > > Maybe it cannot show the MULTIPART reply message, and the table features
> > > reply didn't show with the same reason.
> > >
> > > best wishes,
> > > Dickens Yeh
> > >
> > >
> > >
> > > Ben Pfaff  於 2021年1月8日 週五 上午3:36寫道：
> > >
> > > > On Mon, Jan 04, 2021 at 11:13:53AM +0800, Dickens Yeh wrote:
> > > > > Hi,
> > > > > When I using the ovs-ofctl utility tool to dump flows from a
> > > > > non-openvswitch switch without --no-names parameter, and I got error
> > > > > message.
> > > > >
> > > > > cmd:
> > > > >
> > > > > ~/openvswitch-2.13.1/utilities/ovs-ofctl -O OpenFlow13 dump-flows
> > tcp:
> > > > > 192.168.17.166:6644
> > > > >
> > > > > msg:
> > > > > 2020-12-31T10:12:22Z|1|ofp_table|WARN|table features message
> > missing
> > > > > required property
> > > > > ovs-ofctl: received bad reply: (***only uses 512 bytes out of
> > 7056***)
> > > > >   04 50 02 00 00 00 00 00-6e 6f 76 69 5f 74 61 62
> > > > |.P..novi_tab|
> > > > > 0010  6c 65 5f 32 00 00 00 00-00 00 00 00 00 00 00 00
> > > > |le_2|
> > > > > ...
> > > > >
> > > > > I also attached the pcap file, please tell me if the switch should be
> > > > fixed
> > > > > with the reply messages.
> > > >
> > > > I ran "ovs-ofctl ofp-parse-pcap dump-error.pcap 6644" and got only the
> > > > following output:
> > > >
> > > > 192.168.13.141.52476 > 192.168.17.166.6644:
> > > > OFPT_HELLO (OF1.3) (xid=0x1):
> > > >  version bitmap: 0x04
> > > >
> > > > 192.168.13.141.52476 > 192.168.17.166.6644:
> > > > OFPST_FLOW request (OF1.3) (xid=0x2):
> > > >
> > > > 192.168.13.141.52478 > 192.168.17.166.6644:
> > > > OFPT_HELLO (OF1.3) (xid=0x3):
> > > >  version bitmap: 0x04
> > > >
> > > > 192.168.13.141.52478 > 192.168.17.166.6644:
> > > > OFPST_TABLE_FEATURES request (OF1.3) (xid=0x4):
> > > >
> > > > I don't think the table features reply is in the pcap.
> > > >
> >
> >
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ovs-ofctl broken when getting table features reply

[Ben Pfaff]

OK, I figured out the problem.

Property 10, OFPTFPT_WILDCARDS, is missing.  OF1.3 section 7.3.5.5.2
says that it's mandatory: "If a specific property does not have any
capability (for example no Set-Field support), a property with an empty
list must be included in the property list."  I think that OVS is
correctly rejecting this set of table features.

On Fri, Jan 08, 2021 at 01:00:36PM +0800, Dickens Yeh wrote:
> Hi Ben,
> Thanks for your reply.
> 
> I can open it with Wireshark, decode as 'OpenFlow', and it shows info as
> following(also in attachment file):
> OFPT_HELLO,
> OFPT_MULTIPART_REQUEST, OFPMP_FLOW
> OFPT_MULTIPART_REPLY, OFPMP_FLOW
> OFPT_HELLO,
> OFPT_MULTIPART_REUQEST, OFPMP_TABLE_FEATURES
> OFPT_MULTIPART_REPLY, OFPMP_TABLE_FEATURES
> 
> I also use your command to parse pcap file, I don't know why it shows
> "OFPST_FLOW request" but there is no "OFPST_FLOW reply" message.
> Maybe it cannot show the MULTIPART reply message, and the table features
> reply didn't show with the same reason.
> 
> best wishes,
> Dickens Yeh
> 
> 
> 
> Ben Pfaff  於 2021年1月8日 週五 上午3:36寫道：
> 
> > On Mon, Jan 04, 2021 at 11:13:53AM +0800, Dickens Yeh wrote:
> > > Hi,
> > > When I using the ovs-ofctl utility tool to dump flows from a
> > > non-openvswitch switch without --no-names parameter, and I got error
> > > message.
> > >
> > > cmd:
> > >
> > > ~/openvswitch-2.13.1/utilities/ovs-ofctl -O OpenFlow13 dump-flows tcp:
> > > 192.168.17.166:6644
> > >
> > > msg:
> > > 2020-12-31T10:12:22Z|1|ofp_table|WARN|table features message missing
> > > required property
> > > ovs-ofctl: received bad reply: (***only uses 512 bytes out of 7056***)
> > >   04 50 02 00 00 00 00 00-6e 6f 76 69 5f 74 61 62
> > |.P..novi_tab|
> > > 0010  6c 65 5f 32 00 00 00 00-00 00 00 00 00 00 00 00
> > |le_2|
> > > ...
> > >
> > > I also attached the pcap file, please tell me if the switch should be
> > fixed
> > > with the reply messages.
> >
> > I ran "ovs-ofctl ofp-parse-pcap dump-error.pcap 6644" and got only the
> > following output:
> >
> > 192.168.13.141.52476 > 192.168.17.166.6644:
> > OFPT_HELLO (OF1.3) (xid=0x1):
> >  version bitmap: 0x04
> >
> > 192.168.13.141.52476 > 192.168.17.166.6644:
> > OFPST_FLOW request (OF1.3) (xid=0x2):
> >
> > 192.168.13.141.52478 > 192.168.17.166.6644:
> > OFPT_HELLO (OF1.3) (xid=0x3):
> >  version bitmap: 0x04
> >
> > 192.168.13.141.52478 > 192.168.17.166.6644:
> > OFPST_TABLE_FEATURES request (OF1.3) (xid=0x4):
> >
> > I don't think the table features reply is in the pcap.
> >


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] watch_group liveness check for OVS groups

[Ben Pfaff]

On Thu, Jan 21, 2021 at 08:20:16PM +0100, Alexander Constantinescu wrote:
> I have not been able to find much documentation surrounding watch_group,
> the only doc I've been basing myself on is:
> http://www.openvswitch.org/support/dist-docs/ovs-ofctl.8.html

OVS follows the OpenFlow standard here, so reading up on its definitions
is probably what you should do.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] watch_group liveness check for OVS groups

[Ben Pfaff]

On Thu, Jan 21, 2021 at 08:20:16PM +0100, Alexander Constantinescu wrote:
> Hi,
> 
> TL;DR: I am wondering if there's any specific action/convention that needs
> to be defined for groups which are referenced by a watch_group, as to have
> the liveness check correctly working? FYI: I can't use a liveness check on
> a dedicated OVS port in this case.
> 
> I have not been able to find much documentation surrounding watch_group,
> the only doc I've been basing myself on is:
> http://www.openvswitch.org/support/dist-docs/ovs-ofctl.8.html
> 
> I am working on a POC where the goal of my work is to load balance packets
> between two nexthops for packets matching a given flow. Essentially, I have
> this flow which gets hit:
> 
>  cookie=0x0, duration=12657.001s, table=100, n_packets=1423,
> n_bytes=113190, priority=100,ip,reg0=0x5d41f9 actions=group:2
> 
> for which I have the following groups defined:
> 
>  
> group_id=3,type=select,bucket=weight:100,actions=ct(commit),move:NXM_NX_REG0[]->NXM_NX_TUN_ID[0..31],set_field:172.19.0.2->tun_dst,output:vxlan0
> 
> group_id=2,type=select,bucket=weight:100,watch_group:3,actions=group:3,bucket=weight:100,watch_group:4,actions=group:4
>  
> group_id=4,type=select,bucket=weight:100,actions=ct(commit),move:NXM_NX_REG0[]->NXM_NX_TUN_ID[0..31],set_field:172.19.0.4->tun_dst,output:vxlan0
> 
> Group 2 thus load balances between group 3 (which forwards packets to
> nexthop 172.19.0.2) and 4 (corresponding to nexthop 172.19.0.4) in an equal
> way.
> 
> The load balancing works, however the watch_group does not seem to have any
> impact, and what I mean by that is: if I shutdown the nodes corresponding
> to either of my nexthops, group 2 will still try to send packets to the
> nexthop (node) which I've just shut down.

I think that the problem is that groups 3 and 4 don't have any liveness
criteria defined, so they are always considered live.  Try adding a
watch_port to each of them.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] change configuration of VLAN access port

[Ben Pfaff]

On Wed, Jan 20, 2021 at 05:25:49PM +0100, Matthias Waehlisch wrote:
> Hi,
> 
>   i'm wondering how to change the VLAN setting of an access-port 
> without deleting the port.
> 
>   when i already added a port to a switch (ovs-vsctl add-port ...), and 
> and want to change the VLAN setting via "ovs-vsctl add-port ..." (e.g., 
> to change the VLAN the port is assigned to), i get an error message that 
> ovs-vsctl: cannot create a port xyz because a port named xyz exists on 
> bridge br0.
> 
>   i can execute "ovs-vsctl set PORT_NAME tag=10" but then all Ethernet 
> frames are tagged.

ovs-vsctl clear port $name tag
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ovs-ofctl broken when getting table features reply

[Ben Pfaff]

On Mon, Jan 04, 2021 at 11:13:53AM +0800, Dickens Yeh wrote:
> Hi,
> When I using the ovs-ofctl utility tool to dump flows from a
> non-openvswitch switch without --no-names parameter, and I got error
> message.
> 
> cmd:
> 
> ~/openvswitch-2.13.1/utilities/ovs-ofctl -O OpenFlow13 dump-flows tcp:
> 192.168.17.166:6644
> 
> msg:
> 2020-12-31T10:12:22Z|1|ofp_table|WARN|table features message missing
> required property
> ovs-ofctl: received bad reply: (***only uses 512 bytes out of 7056***)
>   04 50 02 00 00 00 00 00-6e 6f 76 69 5f 74 61 62 |.P..novi_tab|
> 0010  6c 65 5f 32 00 00 00 00-00 00 00 00 00 00 00 00 |le_2|
> ...
> 
> I also attached the pcap file, please tell me if the switch should be fixed
> with the reply messages.

I ran "ovs-ofctl ofp-parse-pcap dump-error.pcap 6644" and got only the
following output:

192.168.13.141.52476 > 192.168.17.166.6644:
OFPT_HELLO (OF1.3) (xid=0x1):
 version bitmap: 0x04

192.168.13.141.52476 > 192.168.17.166.6644:
OFPST_FLOW request (OF1.3) (xid=0x2):

192.168.13.141.52478 > 192.168.17.166.6644:
OFPT_HELLO (OF1.3) (xid=0x3):
 version bitmap: 0x04

192.168.13.141.52478 > 192.168.17.166.6644:
OFPST_TABLE_FEATURES request (OF1.3) (xid=0x4):

I don't think the table features reply is in the pcap.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ASAN RCU use-after-free

[Ben Pfaff]

On Tue, Jan 05, 2021 at 05:05:37PM +0200, Eli Britstein wrote:
> I am trying to use Address Sanitizer to detect issues.
> With a simple code of use-after-free it works, but with postponed free,
> there
> is no detection of the problem.

[...]

> This way it is up to a race between the RCU thread and the write of xx[1].
> Any thoughts of a better tool or technique that is more suitable?

The problem (I guess you realize this too) is that the normal ovsrcu
primitives only ensure that callbacks *can* be called, without actually
waiting for them to be called.

I don't think there's a way built into ovsrcu to make it safely wait for
all existing callbacks to execute.  I think that this would require
adding a new operation to the ovsrcu API.  It might be a good idea, if
you want to enable better checking here.  I think that the kernel RCU
API has something like this for enabling module unload.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] MAC Learning event to Controller

[Ben Pfaff]

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

[Ben Pfaff]

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 Pfaff]

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 
> 
> 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

[Ben Pfaff]

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] [ovs-security] BUG REPORT

[Ben Pfaff]

On Thu, Nov 26, 2020 at 02:07:51PM +0530, Security Researcher wrote:
> I am Vaishnavi Pardeshi working as a security researcher and I found a bug
> in your website . Report of bug is as Follows .
> 
> a) VULNERABILITY TYPE- DMARC RECORD MISSING.

Thanks for the report.  You don't have to keep reporting this.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] 答复: 答复: [ovs-announce] OVS and OVN 2020 Fall Conference schedule and registration now available

[Ben Pfaff]

I see your registration, thank you!

On Wed, Nov 25, 2020 at 03:52:39AM +, Yi Yang (杨燚)-云服务集团 wrote:
> Thanks Ben, I have registered myself by VPN, so it isn't an issue for me. 
> 
> -邮件原件-
> 发件人: Ben Pfaff [mailto:b...@ovn.org] 
> 发送时间: 2020年11月25日 11:47
> 收件人: Yi Yang (杨燚)-云服务集团 
> 抄送: disc...@openvswitch.org
> 主题: Re: 答复: [ovs-announce] OVS and OVN 2020 Fall Conference schedule and 
> registration now available
> 
> I don't want to set up a web service myself, that's why I used Google.
> 
> Just let me know what session you plan to attend (A or B or both) and I'll 
> add you to the registration list.  That's really all that's on the form 
> anyway.
> 
> On Wed, Nov 25, 2020 at 12:48:50AM +, Yi Yang (杨燚)-云服务集团 wrote:
> > Hi, Ben
> > 
> > We can't access google docs https://forms.gle/zD2VZRNrZkqFjKCh9 in China, 
> > maybe you can put a register page in 
> > https://www.openvswitch.org/support/ovscon2020/ for more attendees. 
> > 
> > -----邮件原件-
> > 发件人: announce [mailto:ovs-announce-boun...@openvswitch.org] 代表 Ben 
> > Pfaff
> > 发送时间: 2020年11月25日 5:45
> > 收件人: ovs-annou...@openvswitch.org
> > 主题: [ovs-announce] OVS and OVN 2020 Fall Conference schedule and 
> > registration now available
> > 
> > The Open vSwitch and OVN 2020 Fall Conference will be held online Dec. 8 
> > and 9 (and Dec. 10, depending on time zone).  Talks will be pre-recorded 
> > and played back during the conference.  We will use an online system that 
> > allows for text-based discussion and Q while the talk is being played.  
> > We will also allow a few minutes after each talk for further discussion via 
> > both text and over video and audio with the presenters.
> > 
> > Each talk will be given twice, 11 hours apart, to accommodate a wide 
> > variety of time zones.  Not all of the talks will be attended by their 
> > speakers in both sessions.  We will record both sessions.
> > 
> > We encourage you to register to receive an email notification when we 
> > update the conference information.  Registration is not required to attend.
> > 
> > The schedule for ovscon is posted at https://ovscon.site/.
> > The registration link is available there, or you may navigate to it 
> > directly at https://forms.gle/zD2VZRNrZkqFjKCh9.
> > ___
> > announce mailing list
> > annou...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-announce
> 
> 
> 


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] 答复: [ovs-announce] OVS and OVN 2020 Fall Conference schedule and registration now available

[Ben Pfaff]

I don't want to set up a web service myself, that's why I used Google.

Just let me know what session you plan to attend (A or B or both) and
I'll add you to the registration list.  That's really all that's on the
form anyway.

On Wed, Nov 25, 2020 at 12:48:50AM +, Yi Yang (杨燚)-云服务集团 wrote:
> Hi, Ben
> 
> We can't access google docs https://forms.gle/zD2VZRNrZkqFjKCh9 in China, 
> maybe you can put a register page in 
> https://www.openvswitch.org/support/ovscon2020/ for more attendees. 
> 
> -邮件原件-
> 发件人: announce [mailto:ovs-announce-boun...@openvswitch.org] 代表 Ben Pfaff
> 发送时间: 2020年11月25日 5:45
> 收件人: ovs-annou...@openvswitch.org
> 主题: [ovs-announce] OVS and OVN 2020 Fall Conference schedule and registration 
> now available
> 
> The Open vSwitch and OVN 2020 Fall Conference will be held online Dec. 8 and 
> 9 (and Dec. 10, depending on time zone).  Talks will be pre-recorded and 
> played back during the conference.  We will use an online system that allows 
> for text-based discussion and Q while the talk is being played.  We will 
> also allow a few minutes after each talk for further discussion via both text 
> and over video and audio with the presenters.
> 
> Each talk will be given twice, 11 hours apart, to accommodate a wide variety 
> of time zones.  Not all of the talks will be attended by their speakers in 
> both sessions.  We will record both sessions.
> 
> We encourage you to register to receive an email notification when we update 
> the conference information.  Registration is not required to attend.
> 
> The schedule for ovscon is posted at https://ovscon.site/.
> The registration link is available there, or you may navigate to it directly 
> at https://forms.gle/zD2VZRNrZkqFjKCh9.
> ___
> announce mailing list
> annou...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-announce



___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] OVS and OVN 2020 Fall Conference schedule and registration now available

[Ben Pfaff]

The Open vSwitch and OVN 2020 Fall Conference will be held online Dec. 8
and 9 (and Dec. 10, depending on time zone).  Talks will be pre-recorded
and played back during the conference.  We will use an online system
that allows for text-based discussion and Q while the talk is being
played.  We will also allow a few minutes after each talk for further
discussion via both text and over video and audio with the presenters.

Each talk will be given twice, 11 hours apart, to accommodate a wide
variety of time zones.  Not all of the talks will be attended by their
speakers in both sessions.  We will record both sessions.

We encourage you to register to receive an email notification when we
update the conference information.  Registration is not required to
attend.

The schedule for ovscon is posted at https://ovscon.site/.
The registration link is available there, or you may navigate to it
directly at https://forms.gle/zD2VZRNrZkqFjKCh9.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Way of handling rules at the OVS flow-table is there any time order?

[Ben Pfaff]

On Fri, Nov 20, 2020 at 10:25:30AM +0100, Jordi Baranda wrote:
> On 19/11/2020 18:35, Ben Pfaff wrote:
> > On Thu, Nov 19, 2020 at 12:20:01PM +0100, Jordi Baranda wrote:
> > > If I use break-before-make, there is no problem because I replace the 
> > > rules
> > > and that is. However for the make-before-break approach, I foresee that 
> > > there
> > > will be some flow rules with the same match fields but different action
> > > fields. (e.g, t0: in_port: 3 -> out_port: 2 vs t1: in_port: 3 -> 
> > > out_port:4,
> > > where t0 means time0 and t1 means time1 and t1 > t0 (older time instant) 
> > > ).  I
> > > know I could handle that with priorities but I think this may add further
> > > complexity to the SDN controller app.
> > I don't think this makes any sense.  You cannot have two flows in a
> > table with the same match fields and the same priority.  Those are the
> > same flow, and it has either one set of actions or another.
> Yes, I understand. These entries will coexist for short time due to the
> make-before-break approach. I will install the "new rule" with the same
> match and different action and then remove the "old rule". My question as
> you well described bellow is what happens while they coexist.

This is like saying that you're going to have two files with the same
name in a directory for a brief time.  Doesn't work.

> > > I am wondering if I can skip this treatment at the SDN controller app 
> > > making
> > > use of how OVS applies/evaluates rules in the flow table. More 
> > > specifically,
> > > rules in the flow table of OVS (for the same priority) are evaluated in 
> > > any
> > > time order? That is, OVS is considering "t1 rule" (which is more recent 
> > > than
> > > the one of t0) before than "t0 rule"  (however, t0 rule will be erased
> > > afterwards)? Or are the flow-rules in the flow table ordered/evaluated
> > > "randomly"? Additionally, has this changed through the OVS versions?
> > I'm not sure I understand the question.  Skipping by the problem above,
> > let me rephrase my understanding of it in another way, and you can
> > correct me if I get it wrong.  I think you are saying, if a given packet
> > has two "best match" flows at the same priority, will OVS choose the one
> > added later by preference?  No, OVS doesn't work that way; it has never
> > used the order in which flows are added as an input into the
> > classification process.
> 
> Yes, the problem is as you described. While the rules coexists, which one
> will be applied? According to what I read, I suppose OVS checks the rules in
> the flow table and applies the first one making match. However, as I
> understand, OVS is not applying "any given order" to evaluate the rules in
> the flow-table, it could be that sometimes applies one rule and other time
> applies the other rule. Is my understanding correct? I have found a thread
> in stackoverflow asking about the same issue 
> <https://stackoverflow.com/questions/45195182/what-if-there-are-multiple-forwarding-rules-for-the-same-flow-in-the-openflow-sw>
> that I am presenting. They say OVS will match the new rule, but maybe it was
> casual. Is the behaviour that they see consistent in OVS?

OVS doesn't guarantee any behavior here.  It probably changes from one
version to the next, or maybe even from one run to the next.

I suggest using transactions to replace the contents of the flow table
atomically.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Way of handling rules at the OVS flow-table is there any time order?

[Ben Pfaff]

On Thu, Nov 19, 2020 at 12:20:01PM +0100, Jordi Baranda wrote:
> If I use break-before-make, there is no problem because I replace the rules
> and that is. However for the make-before-break approach, I foresee that there
> will be some flow rules with the same match fields but different action
> fields. (e.g, t0: in_port: 3 -> out_port: 2 vs t1: in_port: 3 -> out_port:4,
> where t0 means time0 and t1 means time1 and t1 > t0 (older time instant) ).  I
> know I could handle that with priorities but I think this may add further
> complexity to the SDN controller app.

I don't think this makes any sense.  You cannot have two flows in a
table with the same match fields and the same priority.  Those are the
same flow, and it has either one set of actions or another.

> I am wondering if I can skip this treatment at the SDN controller app making
> use of how OVS applies/evaluates rules in the flow table. More specifically,
> rules in the flow table of OVS (for the same priority) are evaluated in any
> time order? That is, OVS is considering "t1 rule" (which is more recent than
> the one of t0) before than "t0 rule"  (however, t0 rule will be erased
> afterwards)? Or are the flow-rules in the flow table ordered/evaluated
> "randomly"? Additionally, has this changed through the OVS versions?

I'm not sure I understand the question.  Skipping by the problem above,
let me rephrase my understanding of it in another way, and you can
correct me if I get it wrong.  I think you are saying, if a given packet
has two "best match" flows at the same priority, will OVS choose the one
added later by preference?  No, OVS doesn't work that way; it has never
used the order in which flows are added as an input into the
classification process.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [ovn] non-maskable OVS meta-flow fields not correctly handled

[Ben Pfaff]

On Thu, Nov 12, 2020 at 09:45:42AM +, ythomas1@orange.com wrote:
> As shown in the following traces, we can see that mpls_label and
> mpls_bos fields are ignored in mf_set(). Their mask not being NULL or
> all-1-bits or all-0-bits, we are falling in the switch case where they
> are not handled
> (https://github.com/openvswitch/ovs/blob/master/lib/meta-flow.c#L2328).

[...]

> So what should be the fix ? Should OVN ensure that the mask be set to
> all zeroes or all ones when calling mf_mask_subfield, or should mf_set
> be adjusted (e.g. treat mpls fields as 'a nontrivial mask' (to quote
> https://github.com/openvswitch/ovs/blob/master/lib/meta-flow.c#L2324 )
> after introducing suitable
> match_set_mpls_label_masked/match_set_mpls_bos_masked/match_set_mpls_tc_masked/match_set_mpls_ttl_masked
> functions) ?

I think that it would probably be better to improve mf_set() to
gracefully handle this case.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Connecting two servers over layer 2 openvswitch without encapsulation

[Ben Pfaff]

On Fri, Nov 13, 2020 at 05:29:10AM +, Gilbert Standen wrote:
> So this may be a very dumb question, but is there any way to connect
> two separate physical servers with layer 2 openvswitches on each
> separate server over a physical layer 3 network without using an
> encapsulation scheme (e.g. GRE, VXLAN, etc) ?  There are many
> workloads that are somewhat hobbled by having to use MTU other than
> 1500 or 9000, such as database workloads, and so I'm asking this
> probably dumb question, because just me, I cannot see how it is
> possible to avoid encapsulation when pushing data between servers over
> a layer 2 network running on a physical layer 3 network, but I thought
> I would ask anyway.  Thanks, Gilbert

It appears that you have described what networks do anyway.  No special
configuration is needed.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [ovn] non-maskable OVS meta-flow fields not correctly handled

[Ben Pfaff]

On Thu, Nov 05, 2020 at 12:39:38PM +, ythomas1@orange.com wrote:
> I’m currently working on OVN to add MPLS logical fields (such as
> 'mpls_label', 'mpls_bos') to support BGP/MPLS technology.
> 
> As indicated in 'mf_field' struct in meta-flow.h, most OVS meta-flow
> fields have n_bytes * 8 == n_bits size but there are few exceptions
> such as 'mpls_label', 'mpls_bos', etc…
> 
> In OVN case, when calling 'mf_mask_subfield' method from meta-flow.c,
> for example for 'mpls_label' OVS meta-flow field which has 20 useful
> bits over 32 bits, the 'mask' value parsed in OVN is set to 0x00ff
> (which seems correct).

OVN doesn't use that function much.  I see one use in constrain_match().

I don't understand where 0x00ff comes from.  The mask should not be
discontiguous like that.

> The problem is that in 'mf_set' method, 'mpls_label' OVS meta-flow
> field is supposed to only have a NULL, all-1-bits or all-0-bits 'mask'
> value to be set, as shown below:

[...]

> However, as mentioned in 'mf_set' method comment, “The caller is
> responsible for ensuring that 'match' meets 'mf''s prerequisites”.
> 
> So, since the 'mpls_label' OVS meta-flow field is indicated as not
> maskable in meta-flow.h, shouldn't OVN ensure that 'mask' is set to
> NULL when calling 'mf_mask_subfield' ?

The mask isn't a prerequisite.  The prerequisite for mpls_label is that
the flow is an MPLS flow, that is, it has an MPLS ethertype.  See
mf_are_prereqs_ok().
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS 2.13.1-1: ovs-pki req+sign option is not generating the certificate NAME-cert.pem file.

[Ben Pfaff]

What version of OpenSSL are you using?  Run "openssl version".

On Mon, Oct 19, 2020 at 01:26:05PM +0530, NR 85 wrote:
> Hi Ben,
> 
> Here is the contents of the ovs-pki.log when executing "/usr/bin/ovs-pki
> req+sign test --force".
> 
> ovs-pki.log :
> 
> Generating RSA private key, 2048 bit long modulus
> .+
> ...+
> e is 65537 (0x010001)
> Using configuration from ca.cnf
> Error Loading extension section usr_cert
> 
> Kindly help resolve this issue.
> 
> Thank you,
> Warm Regards,
> Ramesh.G
> 
> On Sat, Oct 17, 2020 at 10:08 AM Ben Pfaff  wrote:
> 
> > On Fri, Oct 16, 2020 at 06:28:45PM +0530, NR 85 wrote:
> > > Hi Team,
> > >
> > > I am facing an issue in ovs-pki in which req+sign option is not
> > generating
> > > the certificate. Kindly look into this issue and provide your suggestion.
> > >
> > > From the logs below it will be clear that the "test-cert.pem" file is not
> > > generated and the file with name "test-cert.pem.tmp18614" is generated
> > with
> > > zero byte.
> >
> > ovs-pki produces its own log.  It's probably named ovs-pki.log and
> > probably in /var/log.  What's in it?
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OpenvSwitch Message too large

[Ben Pfaff]

On Mon, Oct 19, 2020 at 09:59:13PM +0700, KhacThuan Bk wrote:
>  Hi all,
> 
> I'm using ovs with bonding interface. All interface is using mtu 1500.
> But in ovs-vswitchd.log i saw some log about "Message too long". I cannot
> use ovs-tcpdump to trace message. Any one used face this problem can tell
> my what is problem. I have some info follow this.

There really is probably something odd going on with MTU, especially
since the bonding driver is involved.  Make sure that the members of the
bond all have MTU 1500 too.

OVS has its own bonding implementation, it's odd to use the kernel's
instead, especially with the userspace datapath.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS 2.13.1-1: ovs-pki req+sign option is not generating the certificate NAME-cert.pem file.

[Ben Pfaff]

On Fri, Oct 16, 2020 at 06:28:45PM +0530, NR 85 wrote:
> Hi Team,
> 
> I am facing an issue in ovs-pki in which req+sign option is not generating
> the certificate. Kindly look into this issue and provide your suggestion.
> 
> From the logs below it will be clear that the "test-cert.pem" file is not
> generated and the file with name "test-cert.pem.tmp18614" is generated with
> zero byte.

ovs-pki produces its own log.  It's probably named ovs-pki.log and
probably in /var/log.  What's in it?
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OvS Processes

[Ben Pfaff]

ovs-vswitchd normally has only one process.  If you use --monitor, then
it creates a second process to restart the main one if it crashes.  If
you see more than that, either they are actually threads within
ovs-vswitchd (it can have several) or you somehow started multiple
copies of ovs-vswitchd.

On Fri, Oct 16, 2020 at 07:28:58PM -0300, Filipe Lemos wrote:
> Sorry,
> for some reason it wasn't accepting to send the email. I guess it remove
> the screenshot and after trying to send to both groups it choose to sed
> booths.
> Well, the processes are ovsdb-server and ovs-vswitchd (which seems to have
> a tree of processes under it ).
> 
> Em sex., 16 de out. de 2020 às 19:23, Ben Pfaff  escreveu:
> 
> > On Fri, Oct 16, 2020 at 06:23:24PM -0300, Filipe Lemos wrote:
> > > I tried to learn more about each process created by running OvS while my
> > > bridge runs as a SDN switch connected to a controller. I can see that
> > there
> > > are 4 processes with ovs in the name, as shown in the attached
> > screenshot.
> > > What does each one of them do? There is any documentation explaining
> > them?
> >
> > Please don't crosspost to both lists.
> >
> > I don't see an attached screenshot.  What are the names of the
> > processes?
> >
> 
> 
> -- 
> 
> *Filipe Augusto da Luz Lemos* M.Sc.
> 
> *PhD Graduate Student | Networks and Distributed Systems | Federal
> University of Technology Paraná*
> 
> *Forensic Sciences* |* Syracuse University*
> 
> 
> *Electrical Engineering | Federal University of Technology Paraná*
> 
> fadal...@syr.edu *|* http://forensics.syr.edu/
> 
> *fle...@alunos.utfpr.edu.br
>  | http://utfpr.edu.br <http://utfpr.edu.br/> *
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OvS Processes

[Ben Pfaff]

On Fri, Oct 16, 2020 at 06:23:24PM -0300, Filipe Lemos wrote:
> I tried to learn more about each process created by running OvS while my
> bridge runs as a SDN switch connected to a controller. I can see that there
> are 4 processes with ovs in the name, as shown in the attached screenshot.
> What does each one of them do? There is any documentation explaining them?

Please don't crosspost to both lists.

I don't see an attached screenshot.  What are the names of the
processes?
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Does OVS support egress table specified in OpenFlow 1.5?

[Ben Pfaff]

On Wed, Sep 23, 2020 at 02:32:17PM +0800, Shouxi Luo wrote:
> Does OVS (say 2.13 for instance) support the egress table specified in
> OpenFlow 1.5?

No.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] OVS+OVN '20: Call for Participation

[Ben Pfaff]

The Open vSwitch and OVN projects will host their seventh annual
conference focused on Open vSwitch and OVN on Dec. 7 to 11, 2020.  We
are seeking long and short ("lightning") talks on topics related to Open
vSwitch and OVN.  We expect long talks to last 20 minutes with an
additional 5 minutes for questions, and short talks to last 7 minutes
with 3 minutes for questions.  We are also seeking proposals for
30-minute live panel discussions led by a moderator.

We will use an online format.  Talks will be prerecorded and played
during the conference.  During the playback, text chat will give the
attendees and the presenters an opportunity to interact.  During the
question period, the presenters will answer questions live over audio
(and video, at the persenters' discretion).  Video will also be
available for offline viewing.

Since presenters and attendees will not be in a single location, time
zones are a question.  We will survey attendees and presenters to
determine the best times for everyone involved.  We will not fill the
entire week but rather use shorter blocks of time that are more
comfortable for participants and easier to fit into a schedule.  We
might present some talks multiple times, given interest from
participants.

The conference will be free this year.

Topics
--

Topics that may be considered, among others, include:

 * The future of Open vSwitch (e.g., AF_XDP, P4, eBPF).

 * NAT, DPI, and stateful processing with Open vSwitch. 

 * Deploying and using OVN.

 * Testing and scaling OVN.

 * NIC acceleration of Open vSwitch.

 * Using Open vSwitch to realize NFV and service chaining.

 * Porting Open vSwitch to new operating systems, hypervisors,
   or container systems.

 * Integrating Open vSwitch into larger systems.

 * Troubleshooting and debugging Open vSwitch installations.

 * Open vSwitch development and testing practices.

 * Performance measurements or approaches to improving
   performance.

 * End-user or service provider experiences with Open vSwitch.

 * Hardware ports of Open vSwitch (existing, in progress, or
   speculative).

 * The relationship between OpenFlow and Open vSwitch.

 * Using, developing, or administering OpenFlow controllers in
   conjunction with Open vSwitch.

 * Comparisons to other implementations of features found in
   Open vSwitch (e.g. other OpenFlow implementations, other
   software switches, etc.).

 * Increasing the size and diversity of the Open vSwitch user
   and developer base.

 * Tutorials and walkthroughs of use cases.

 * Demos.

How to propose a talk
-

We are soliciting proposals for full talks and short ("lightning")
talks in a single round.  You may propose a talk as a full talk, a
lightning talk, or for either one at the committee's discretion.

We will also accept proposals for live panel discussions with a
moderator.  Please make it clear in the description that it is a
panel.

Please submit proposals to ovs...@openvswitch.org.  Proposals should
include:

* Title and abstract.

* Speaker names, email addresses, and affiliations.

* Whether you are proposing a full talk, a lightning talk,
  either one at the committee's discretion, or a panel
  discussion.

* For a panel discussion, a list of panelists.


Important Dates
---

* Deadline for proposals: October 16.

* Notification of acceptance: October 30.

* Conference: December 7-11.

More information


To reach the organizers, email ovs...@openvswitch.org.  For general
discussion of the conference, please use the ovs-discuss mailing list
at disc...@openvswitch.org.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] proposed CFP for OVS+OVN'20

[Ben Pfaff]

Hi!  I've been talking to folks at Red Hat and elsewhere about this
year's OVS and OVN conference.  Here is a draft of a CFP.  I am asking
for your feedback.

Thanks,

Ben.

-8<--cut here-->8--

Subject: OVS+OVN '20: Call for Participation

The Open vSwitch and OVN projects will host their seventh annual
conference focused on Open vSwitch and OVN Dec. 7 to 11, 2020.  We are
seeking long and short ("lightning") talks on topics related to Open
vSwitch and OVN.  We expect long talks to last 20 minutes with an
additional 5 minutes for questions, and short talks to last 7 minutes
with 3 minutes for questions.  We are also seeking proposals for
30-minute live panel discussions led by a moderator.

We will use an online format.  Talks will be prerecorded and played
during the conference.  During the playback, text chat will give the
attendees and the presenters an opportunity to interact.  During the
question period, the presenters will answer questions live over audio
(and video, at the persenters' discretion).  Video will also be
available for offline viewing.

Since presenters and attendees will not be in a single location, time
zones are a question.  We intend to conduct a survey of attendees and
presenters to determine the best times for everyone involved.  We
might decide to present some talks at different times, if attendees
are interested and presenters are willing.

The conference will be free this year.

Topics
--

Topics that may be considered, among others, include:

 * The future of Open vSwitch (e.g., AF_XDP, P4, eBPF).

 * NAT, DPI, and stateful processing with Open vSwitch. 

 * Deploying and using OVN.

 * Testing and scaling OVN.

 * NIC acceleration of Open vSwitch.

 * Using Open vSwitch to realize NFV and service chaining.

 * Porting Open vSwitch to new operating systems, hypervisors,
   or container systems.

 * Integrating Open vSwitch into larger systems.

 * Troubleshooting and debugging Open vSwitch installations.

 * Open vSwitch development and testing practices.

 * Performance measurements or approaches to improving
   performance.

 * End-user or service provider experiences with Open vSwitch.

 * Hardware ports of Open vSwitch (existing, in progress, or
   speculative).

 * The relationship between OpenFlow and Open vSwitch.

 * Using, developing, or administering OpenFlow controllers in
   conjunction with Open vSwitch.

 * Comparisons to other implementations of features found in
   Open vSwitch (e.g. other OpenFlow implementations, other
   software switches, etc.).

 * Increasing the size and diversity of the Open vSwitch user
   and developer base.

 * Tutorials and walkthroughs of use cases.

 * Demos.

How to propose a talk
-

We are soliciting proposals for full talks and short ("lightning")
talks in a single round.  You may propose a talk as a full talk, a
lightning talk, or for either one at the committee's discretion.

We will also accept proposals for live panel discussions with a
moderator.  Please make it clear in the description that it is a
panel.

Please submit proposals to ovs...@openvswitch.org.  Proposals should
include:

* Title and abstract.

* Speaker names, email addresses, and affiliations.

* Whether you are proposing a full talk, a lightning talk,
  either one at the committee's discretion, or a panel
  discussion.

* For a panel discussion, a list of panelists.


Important Dates
---

* Deadline for proposals: October 16.

* Notification of acceptance: October 30.

* Conference: December 7-11.

More information


To reach the organizers, email ovs...@openvswitch.org.  For general
discussion of the conference, please use the ovs-discuss mailing list
at disc...@openvswitch.org.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Inquiry for DDlog status for ovn-northd

[Ben Pfaff]

On Tue, Aug 25, 2020 at 06:43:51PM +0200, Dumitru Ceara wrote:
> On 8/25/20 6:01 PM, Ben Pfaff wrote:
> > On Mon, Aug 24, 2020 at 04:28:22PM -0700, Han Zhou wrote:
> >> As I remember you were working on the new ovn-northd that utilizes DDlog
> >> for incremental processing. Could you share the current status?
> >>
> >> Now that some more improvements have been made in ovn-controller and OVSDB,
> >> the ovn-northd becomes the more obvious bottleneck for OVN use in large
> >> scale environments. Since you were not in the OVN meetings for the last
> >> couple of weeks, could you share here the status and plan moving forward?
> > 
> > The status is basically that I haven't yet succeeded at getting Red
> > Hat's recommended benchmarks running.  I'm told that is important before
> > we merge it.  I find them super difficult to set up.  I tried a few
> > weeks ago and basically gave up.  Piles and piles of repos all linked
> > together in tricky ways, making it really difficult to substitute my own
> > branches.  I intend to try again soon, though.  I have a new computer
> > that should be arriving soon, which should also allow it to proceed more
> > quickly.
> 
> Hi Ben,
> 
> I can try to help with setting up ovn-heater, in theory it should be
> enough to export OVS_REPO, OVS_BRANCH, OVN_REPO, OVN_BRANCH, make them
> point to your repos and branches and then run "do.sh install" and it
> should take care of installing all the dependencies and repos.
> 
> I can also try to run the scale tests on our downstream if that helps.

It's probably better if I come up with something locally, because I
expect to have to run it multiple times, maybe many times, since I will
presumably discover bottlenecks.

This time around, I'll speak up when I run into problems.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss