Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
ovs-ofctl(8)		      Open vSwitch Manual		  ovs-ofctl(8)

NAME
       ovs-ofctl - administer OpenFlow switches

SYNOPSIS
       ovs-ofctl [options] command [switch] [args...]

DESCRIPTION
       The  ovs-ofctl program is a command line	tool for monitoring and	admin-
       istering	OpenFlow switches.  It can also	show the current state	of  an
       OpenFlow	 switch, including features, configuration, and	table entries.
       It should work with any OpenFlow	switch,	not just Open vSwitch.

   OpenFlow Switch Management Commands
       These commands allow ovs-ofctl to monitor and  administer  an  OpenFlow
       switch.	 It  is	 able to show the current state	of a switch, including
       features, configuration,	and table entries.

       Most of these commands take an argument that specifies the  method  for
       connecting to an	OpenFlow switch.  The following	connection methods are
       supported:

	      ssl:host[:port]
	      tcp:host[:port]
		     The  specified  port  on the given	host, which can	be ex-
		     pressed either as a DNS name (if built with  unbound  li-
		     brary)  or	 an IP address in IPv4 or IPv6 address format.
		     Wrap   IPv6   addresses   in   square   brackets,	  e.g.
		     tcp:[::1]:6653.   On  Linux,  use	%device	to designate a
		     scope    for    IPv6    link-level	   addresses,	  e.g.
		     tcp:[fe80::1234%eth0]:6653.   For ssl, the	--private-key,
		     --certificate, and	--ca-cert options are mandatory.

		     If	port is	not specified, it defaults to 6653.

	      unix:file
		     On	POSIX, a Unix domain server socket named file.

		     On	Windows, connect to a local named pipe that is	repre-
		     sented  by	 a  file created in the	path file to mimic the
		     behavior of a Unix	domain socket.

	      file   This is short for unix:file, as long  as  file  does  not
		     contain a colon.

	      bridge This  is short for	unix:/var/run/openvswitch/bridge.mgmt,
		     as	long as	bridge does not	contain	a colon.

	      [type@]dp
		     Attempts to look up the bridge  associated	 with  dp  and
		     open  as above.  If type is given,	it specifies the data-
		     path provider of dp, otherwise the	default	provider  sys-
		     tem is assumed.

       show switch
	      Prints  to the console information on switch, including informa-
	      tion on its flow tables and ports.

       dump-tables switch
	      Prints to	the console statistics for each	 of  the  flow	tables
	      used by switch.

       dump-table-features switch
	      Prints  to the console features for each of the flow tables used
	      by switch.

       dump-table-desc switch
	      Prints to	the console configuration for each of the flow	tables
	      used by switch for OpenFlow 1.4+.

       mod-table switch	table setting
	      This  command configures flow table settings in switch for Open-
	      Flow table table,	which may be expressed as a number or  (unless
	      --no-names is specified) a name.

	      The  available  settings	depend on the OpenFlow version in use.
	      In OpenFlow 1.1 and 1.2 (which must be enabled with the  -O  op-
	      tion)  only, mod-table configures	behavior when no flow is found
	      when a packet is looked up in a flow table.  The following  set-
	      ting values are available:

	      drop   Drop the packet.

	      continue
		     Continue to the next table	in the pipeline.  (This	is how
		     an	OpenFlow 1.0 switch always handles packets that	do not
		     match any flow, in	tables other than the last one.)

	      controller
		     Send  to controller.  (This is how	an OpenFlow 1.0	switch
		     always handles packets that do not	match any flow in  the
		     last table.)

	      In OpenFlow 1.3 and later	(which must be enabled with the	-O op-
	      tion) and	Open vSwitch 2.11 and later only, mod-table can	change
	      the name of a table:

	      name:new-name
		     Changes  the name of the table to new-name.  Use an empty
		     new-name to clear the name.  (This	will be	ineffective if
		     the name is set via the name column in the	Flow_Table ta-
		     ble  in  the  Open_vSwitch	 database  as	described   in
		     ovs-vswitchd.conf.db(5).)

	      In OpenFlow 1.4 and later	(which must be enabled with the	-O op-
	      tion)  only, mod-table configures	the behavior when a controller
	      attempts to add a	flow to	a flow table that is full.   The  fol-
	      lowing setting values are	available:

	      evict  Delete  some existing flow	from the flow table, according
		     to	the algorithm described	for the	 Flow_Table  table  in
		     ovs-vswitchd.conf.db(5).

	      noevict
		     Refuse to add the new flow.  (Eviction might still	be en-
		     abled  through the	overflow_policy	column in the Flow_Ta-
		     ble table documented in ovs-vswitchd.conf.db(5).)

	      vacancy:low,high
		     Enables sending vacancy events to controllers  using  TA-
		     BLE_STATUS	 messages,  based on percentage	thresholds low
		     and high.

	      novacancy
		     Disables vacancy events.

       dump-ports switch [netdev]
	      Prints to	the console statistics for network devices  associated
	      with  switch.  If	netdev is specified, only the statistics asso-
	      ciated with that device will be printed.	netdev can be an Open-
	      Flow assigned port number	or device name,	e.g. eth0.

       dump-ports-desc switch [port]
	      Prints to	the console detailed information about network devices
	      associated with switch.  To dump only a specific	port,  specify
	      its  number as port.  Otherwise, if port is omitted, or if it is
	      specified	as ANY,	then all ports are printed.  This is a	subset
	      of the information provided by the show command.

	      If  the  connection  to  switch negotiates OpenFlow 1.0, 1.2, or
	      1.2, this	command	uses an	OpenFlow extension only	implemented in
	      Open vSwitch (version 1.7	and later).

	      Only OpenFlow 1.5	and later support  dumping  a  specific	 port.
	      Earlier versions of OpenFlow always dump all ports.

       mod-port	switch port action
	      Modify  characteristics  of port port in switch.	port may be an
	      OpenFlow port number or name (unless --no-names is specified) or
	      the keyword LOCAL	(the preferred way to refer  to	 the  OpenFlow
	      local port).  The	action may be any one of the following:
	      up
	      down   Enable  or	 disable the interface.	 This is equivalent to
		     ip	link set up or ip link set down	on a Unix system.

	      stp
	      no-stp Enable or disable 802.1D spanning tree protocol (STP)  on
		     the  interface.  OpenFlow implementations that don't sup-
		     port STP will refuse to enable it.

	      receive
	      no-receive
	      receive-stp
	      no-receive-stp
		     Enable or disable OpenFlow	processing of packets received
		     on	this interface.	 When packet processing	 is  disabled,
		     packets  will  be	dropped	 instead  of  being  processed
		     through the OpenFlow table.  The  receive	or  no-receive
		     setting  applies  to  all	packets	except 802.1D spanning
		     tree packets, which  are  separately  controlled  by  re-
		     ceive-stp or no-receive-stp.

	      forward
	      no-forward
		     Allow  or	disallow  forwarding of	traffic	to this	inter-
		     face.  By default,	forwarding is enabled.

	      flood
	      no-flood
		     Controls whether an OpenFlow flood	action will send traf-
		     fic out this interface.  By default, flooding is enabled.
		     Disabling flooding	is primarily useful to	prevent	 loops
		     when a spanning tree protocol is not in use.

	      packet-in
	      no-packet-in
		     Controls  whether packets received	on this	interface that
		     do	not match a flow table entry generate a	``packet  in''
		     message to	the OpenFlow controller.  By default, ``packet
		     in'' messages are enabled.

	      The show command displays	(among other information) the configu-
	      ration that mod-port changes.

       get-frags switch
	      Prints  switch's	fragment handling mode.	 See set-frags,	below,
	      for a description	of each	fragment handling mode.

	      The show command also prints the fragment	 handling  mode	 among
	      its other	output.

       set-frags switch	frag_mode
	      Configures  switch's  treatment of IPv4 and IPv6 fragments.  The
	      choices for frag_mode are:

	      normal Fragments pass through the	flow table like	non-fragmented
		     packets.  The TCP ports, UDP ports,  and  ICMP  type  and
		     code fields are always set	to 0, even for fragments where
		     that  information would otherwise be available (fragments
		     with offset 0).  This is the  default  fragment  handling
		     mode for an OpenFlow switch.

	      drop   Fragments	are  dropped  without passing through the flow
		     table.

	      reassemble
		     The switch	reassembles fragments into full	IP packets be-
		     fore passing them through the flow	table.	 Open  vSwitch
		     does not implement	this fragment handling mode.

	      nx-match
		     Fragments pass through the	flow table like	non-fragmented
		     packets.	The  TCP  ports,  UDP ports, and ICMP type and
		     code fields are available for matching for	fragments with
		     offset 0, and set to 0 in fragments with nonzero  offset.
		     This mode is a Nicira extension.

	      See  the	description of ip_frag,	in ovs-fields(7), for a	way to
	      match on whether a packet	is a fragment and on its fragment off-
	      set.

       dump-flows switch [flows]
	      Prints to	the console all	flow entries in	switch's  tables  that
	      match  flows.   If flows is omitted, all flows in	the switch are
	      retrieved.  See Flow Syntax, below, for  the  syntax  of	flows.
	      The output format	is described in	Table Entry Output.

	      By default, ovs-ofctl prints flow	entries	in the same order that
	      the switch sends them, which is unlikely to be intuitive or con-
	      sistent.	 Use --sort and	--rsort	to control display order.  The
	      --names/--no-names and --stats/--no-stats	 options  also	affect
	      output formatting.  See the descriptions of these	options, under
	      OPTIONS below, for more information

       dump-aggregate switch [flows]
	      Prints to	the console aggregate statistics for flows in switch's
	      tables  that  match  flows.  If flows is omitted,	the statistics
	      are aggregated across all	flows in  the  switch's	 flow  tables.
	      See  Flow	 Syntax,  below,  for the syntax of flows.  The	output
	      format is	described in Table Entry Output.

       queue-stats switch [port	[queue]]
	      Prints to	the console statistics for the specified queue on port
	      within switch.  port can be an OpenFlow port number or name, the
	      keyword LOCAL (the preferred way to refer	to the OpenFlow	 local
	      port),  or the keyword ALL.  Either of port or queue or both may
	      be omitted (or equivalently the keyword ALL).  If	both are omit-
	      ted, statistics are printed for all queues  on  all  ports.   If
	      only  queue  is  omitted,	 then  statistics  are printed for all
	      queues on	port; if only port is  omitted,	 then  statistics  are
	      printed for queue	on every port where it exists.

       queue-get-config	switch [port [queue]]
	      Prints  to  the  console	the  configuration of queue on port in
	      switch.  If port is omitted or ANY, reports queues for all port.
	      If queue is omitted or ANY, reports all  queues.	 For  OpenFlow
	      1.3 and earlier, the output always includes all queues, ignoring
	      queue if specified.

	      This command has limited usefulness, because ports often have no
	      configured  queues  and  because	the OpenFlow protocol provides
	      only very	limited	 information  about  the  configuration	 of  a
	      queue.

       dump-ipfix-bridge switch
	      Prints to	the console the	statistics of bridge IPFIX for switch.
	      If  bridge  IPFIX	 is configured on the switch, IPFIX statistics
	      can be retrieved.	 Otherwise, error message will be printed.

	      This command uses	an Open	vSwitch	extension that is only in Open
	      vSwitch 2.6 and later.

       dump-ipfix-flow switch
	      Prints to	the console the	statistics  of	flow-based  IPFIX  for
	      switch.	If  flow-based IPFIX is	configured on the switch, sta-
	      tistics of all the collector set	ids  on	 the  switch  will  be
	      printed.	Otherwise, print error message.

	      Refer to ovs-vswitchd.conf.db(5) for more	details	on configuring
	      flow based IPFIX and collector set ids.

	      This command uses	an Open	vSwitch	extension that is only in Open
	      vSwitch 2.6 and later.

       ct-flush-zone switch zone
	      Flushes the connection tracking entries in zone on switch.

	      This command uses	an Open	vSwitch	extension that is only in Open
	      vSwitch 2.6 and later.

   OpenFlow Switch Flow	Table Commands
       These  commands	manage	the flow table in an OpenFlow switch.  In each
       case, flow specifies a flow entry in the	format described in Flow  Syn-
       tax, below, file	is a text file that contains zero or more flows	in the
       same  syntax,  one  per line, and the optional --bundle option operates
       the command as a	single atomic transation, see option --bundle, below.

       [--bundle] add-flow switch flow
       [--bundle] add-flow switch - < file
       [--bundle] add-flows switch file
	      Add each flow entry to switch's tables.  Each flow specification
	      (e.g., each line in file)	may start with	add,  modify,  delete,
	      modify_strict,  or  delete_strict	 keyword  to specify whether a
	      flow is to be added, modified, or	deleted, and whether the  mod-
	      ify  or  delete is strict	or not.	 For backwards compatibility a
	      flow specification without one of	these keywords is treated as a
	      flow add.	 All flow mods are executed in the order specified.

       [--bundle] [--strict] mod-flows switch flow
       [--bundle] [--strict] mod-flows switch -	< file
	      Modify the actions in entries from switch's  tables  that	 match
	      the  specified  flows.  With --strict, wildcards are not treated
	      as active	for matching purposes.

       [--bundle] del-flows switch
       [--bundle] [--strict] del-flows switch [flow]
       [--bundle] [--strict] del-flows switch -	< file
	      Deletes entries from switch's flow table.	 With  only  a	switch
	      argument,	 deletes  all  flows.  Otherwise, deletes flow entries
	      that match the specified flows.  With  --strict,	wildcards  are
	      not treated as active for	matching purposes.

       [--bundle] [--readd] replace-flows switch file
	      Reads flow entries from file (or stdin if	file is	-) and queries
	      the  flow	 table from switch.  Then it fixes up any differences,
	      adding flows from	flow that  are	missing	 on  switch,  deleting
	      flows  from  switch  that	are not	in file, and updating flows in
	      switch whose actions, cookie, or timeouts	differ in file.

	      With --readd, ovs-ofctl adds all the flows from file, even those
	      that exist with the same actions,	cookie,	and timeout in switch.
	      In OpenFlow 1.0 and 1.1, re-adding  a  flow  always  resets  the
	      flow's  packet  and  byte	counters to 0, and in OpenFlow 1.2 and
	      later, it	does so	only if	the reset_counts flag is set.

       diff-flows source1 source2
	      Reads flow entries from source1 and source2 and prints the  dif-
	      ferences.	  A  flow  that	 is  in	 source1 but not in source2 is
	      printed preceded by a -, and a flow that is in source2  but  not
	      in source1 is printed preceded by	a +.  If a flow	exists in both
	      source1 and source2 with different actions, cookie, or timeouts,
	      then  both  versions  are	 printed  preceded by -	and +, respec-
	      tively.

	      source1 and source2 may each name	a file or a switch.  If	a name
	      begins with / or ., then it is considered	to be a	file name.   A
	      name  that  contains : is	considered to be a switch.  Otherwise,
	      it is a file if a	file by	that name exists, a switch if not.

	      For this command,	an exit	status of 0 means that no  differences
	      were  found,  1  means  that an error occurred, and 2 means that
	      some differences were found.

       packet-out switch packet-out
	      Connects to switch and instructs it to  execute  the  packet-out
	      OpenFlow message,	specified as defined in	Packet-Out Syntax sec-
	      tion.

   Group Table Commands
       These  commands	manage the group table in an OpenFlow switch.  In each
       case, group specifies a group entry in the format  described  in	 Group
       Syntax,	below,	and  file  is  a  text file that contains zero or more
       groups in the same syntax, one per line,	and the	optional --bundle  op-
       tion  operates  the  command  as	a single atomic	transation, see	option
       --bundle, below.

       The group commands work only with switches that support OpenFlow	1.1 or
       later or	the Open vSwitch group extensions to OpenFlow  1.0  (added  in
       Open  vSwitch  2.9.90).	 For OpenFlow 1.1 or later, it is necessary to
       explicitly enable these protocol	versions in ovs-ofctl (using -O).  For
       more information, see ``Q: What versions	of OpenFlow does Open  vSwitch
       support?'' in the Open vSwitch FAQ.

       [--bundle] add-group switch group
       [--bundle] add-group switch - < file
       [--bundle] add-groups switch file
	      Add  each	group entry to switch's	tables.	 Each group specifica-
	      tion (e.g., each line in	file)  may  start  with	 add,  modify,
	      add_or_mod,  delete,  insert_bucket, or remove_bucket keyword to
	      specify whether a	flow is	to be added, modified, or deleted,  or
	      whether a	group bucket is	to be added or removed.	 For backwards
	      compatibility  a	group  specification without one of these key-
	      words is treated as a group add.	All group mods are executed in
	      the order	specified.

       [--bundle] [--may-create] mod-group switch group
       [--bundle] [--may-create] mod-group switch - < file
	      Modify the action	buckets	in entries from	 switch's  tables  for
	      each  group entry.  If a specified group does not	already	exist,
	      then without --may-create, this  command	has  no	 effect;  with
	      --may-create,  it	 creates a new group.  The --may-create	option
	      uses an Open vSwitch extension to	OpenFlow only  implemented  in
	      Open vSwitch 2.6 and later.

       [--bundle] del-groups switch
       [--bundle] del-groups switch [group]
       [--bundle] del-groups switch - <	file
	      Deletes  entries	from switch's group table.  With only a	switch
	      argument,	deletes	all groups.  Otherwise,	deletes	the group  for
	      each group entry.

       [--bundle] insert-buckets switch	group
       [--bundle] insert-buckets switch	- < file
	      Add  buckets  to an existing group present in the	switch's group
	      table.  If no command_bucket_id is present in the	group specifi-
	      cation then all buckets of the group are removed.

       [--bundle] remove-buckets switch	group
       [--bundle] remove-buckets switch	- < file
	      Remove buckets to	an existing  group  present  in	 the  switch's
	      group  table.   If  no command_bucket_id is present in the group
	      specification then all buckets of	the group are removed.

       dump-groups switch [group]
	      Prints group entries in switch's tables  to  console.   To  dump
	      only  a specific group, specify its number as group.  Otherwise,
	      if group is omitted, or if it is	specified  as  ALL,  then  all
	      groups are printed.

	      Only  OpenFlow  1.5  and later support dumping a specific	group.
	      Earlier versions of OpenFlow always dump all groups.

       dump-group-features switch
	      Prints to	the console the	group features of the switch.

       dump-group-stats	switch [group]
	      Prints to	the console statistics	for  the  specified  group  in
	      switch's	tables.	  If  group is omitted then statistics for all
	      groups are printed.

   OpenFlow 1.3+ Switch	Meter Table Commands
       These commands manage the meter table in	an OpenFlow switch.   In  each
       case,  meter  specifies	a meter	entry in the format described in Meter
       Syntax, below.

       OpenFlow	1.3 introduced support for meters, so these commands only work
       with switches that support OpenFlow 1.3 or later.  It is	 necessary  to
       explicitly  enable  these protocol versions in ovs-ofctl	(using -O) and
       in the switch itself (with the protocols	column in the  Bridge  table).
       For  more  information,	see  ``Q:  What	versions of OpenFlow does Open
       vSwitch support?'' in the Open vSwitch FAQ.

       add-meter switch	meter
	      Add a meter entry	to switch's tables. The	meter  syntax  is  de-
	      scribed in section Meter Syntax, below.

       mod-meter switch	meter
	      Modify an	existing meter.

       del-meters switch [meter]
	      Delete entries from switch's meter table.	 To delete only	a spe-
	      cific  meter,  specify its number	as meter.  Otherwise, if meter
	      is omitted, or if	it is specified	as all,	then  all  meters  are
	      deleted.

       dump-meters switch [meter]
	      Print  entries  from switch's meter table.  To print only	a spe-
	      cific meter, specify its number as meter.	 Otherwise,  if	 meter
	      is  omitted,  or	if it is specified as all, then	all meters are
	      printed.

       meter-stats switch [meter]
	      Print meter statistics.  meter can specify a single  meter  with
	      syntax meter=id, or all meters with syntax meter=all.

       meter-features switch
	      Print meter features.

   OpenFlow Switch Bundle Command
       Transactional  updates  to  both	flow and group tables can be made with
       the bundle command.  file is a text file	that  contains	zero  or  more
       flow  mods, group mods, or packet-outs in Flow Syntax, Group Syntax, or
       Packet-Out Syntax, each line preceded by	 flow,	group,	or  packet-out
       keyword,	 correspondingly.  The flow keyword may	be optionally followed
       by  one	of  the	 keywords  add,	 modify,  modify_strict,  delete,   or
       delete_strict,  of  which  the  add is assumed if a bare	flow is	given.
       Similarly, the group keyword may	be optionally followed by one  of  the
       keywords	  add,	modify,	 add_or_mod,  delete,  insert_bucket,  or  re-
       move_bucket, of which the add is	assumed	if a bare group	is given.

       bundle switch file
	      Execute all flow and group mods  in  file	 as  a	single	atomic
	      transaction  against switch's tables.  All bundled mods are exe-
	      cuted in the order specified.

   OpenFlow Switch Tunnel TLV Table Commands
       Open vSwitch maintains a	mapping	table between tunnel option TLVs  (de-
       fined  by  <class, type,	length>) and NXM fields	tun_metadatan, where n
       ranges from 0 to	63, that can  be  operated  on	for  the  purposes  of
       matches,	 actions,  etc.	 This  TLV table can be	used for Geneve	option
       TLVs or other protocols with options in same TLV	format as  Geneve  op-
       tions.  This  mapping  must be explicitly specified by the user through
       the following commands.

       A     TLV     mapping	 is	specified     with     the	syntax
       {class=class,type=type,len=length}->tun_metadatan.  When	an option map-
       ping  exists  for  a given tun_metadatan, matching on the defined field
       becomes possible, e.g.:

	      ovs-ofctl			   add-tlv-map			   br0
	      "{class=0xffff,type=0,len=4}->tun_metadata0"

	      ovs-ofctl	add-flow br0 tun_metadata0=1234,actions=controller

       A  mapping  should  not be changed while	it is in active	use by a flow.
       The result of doing so is undefined.

       These commands are Nicira  extensions  to  OpenFlow  and	 require  Open
       vSwitch 2.5 or later.

       add-tlv-map switch option[,option]...
	      Add  each	 option	 to  switch's tables. Duplicate	fields are re-
	      jected.

       del-tlv-map switch [option[,option]]...
	      Delete each option from switch's table, or all option  TLV  map-
	      ping  if	no option is specified.	 Fields	that aren't mapped are
	      ignored.

       dump-tlv-map switch
	      Show the currently mapped	fields in the switch's option table as
	      well as switch capabilities.

   OpenFlow Switch Monitoring Commands
       snoop switch
	      Connects to switch and prints to the console all	OpenFlow  mes-
	      sages  received.	 Unlike	other ovs-ofctl	commands, if switch is
	      the name of a bridge, then the snoop command connects to a  Unix
	      domain	 socket	   named    /var/run/openvswitch/switch.snoop.
	      ovs-vswitchd listens on such a socket for	each bridge and	 sends
	      to  it all of the	OpenFlow messages sent to or received from its
	      configured OpenFlow controller.  Thus, this command can be  used
	      to view OpenFlow protocol	activity between a switch and its con-
	      troller.

	      When  a switch has more than one controller configured, only the
	      traffic to and from a single controller is output.  If  none  of
	      the controllers is configured as a primary or a secondary	(using
	      a	Nicira extension to OpenFlow 1.0 or 1.1, or a standard request
	      in OpenFlow 1.2 or later), then a	controller is chosen arbitrar-
	      ily among	them.  If there	is a primary controller, it is chosen;
	      otherwise,  if  there are	any controllers	that are not primaries
	      or secondaries, one is chosen  arbitrarily;  otherwise,  a  sec-
	      ondary  controller  is  chosen arbitrarily.  This	choice is made
	      once at connection time and does not change as  controllers  re-
	      configure	their roles.

	      If  a  switch has	no controller configured, or if	the configured
	      controller is disconnected, no traffic is	 sent,	so  monitoring
	      will not show any	traffic.

       monitor switch [miss-len] [invalid_ttl] [watch:[spec...]]
	      Connects	to  switch and prints to the console all OpenFlow mes-
	      sages received.  Usually,	switch should specify the  name	 of  a
	      bridge  in  the ovs-vswitchd database. This is available only in
	      OpenFlow 1.0 as Nicira extension.

	      If miss-len is provided, ovs-ofctl sends an OpenFlow ``set  con-
	      figuration''  message  at	 connection  setup  time that requests
	      miss-len bytes of	each packet that misses	the flow table.	  Open
	      vSwitch  does  not send these and	other asynchronous messages to
	      an ovs-ofctl monitor client connection unless a nonzero value is
	      specified	on this	argument.  (Thus, if miss-len  is  not	speci-
	      fied, very little	traffic	will ordinarily	be printed.)

	      If invalid_ttl is	passed,	ovs-ofctl sends	an OpenFlow ``set con-
	      figuration''  message at connection setup	time that requests IN-
	      VALID_TTL_TO_CONTROLLER, so that ovs-ofctl monitor  can  receive
	      ``packet-in''  messages when TTL reaches zero on dec_ttl action.
	      Only OpenFlow 1.1	and 1.2	support	invalid_ttl; Open vSwitch also
	      implements it for	OpenFlow 1.0 as	an extension.

	      watch:[spec...] causes ovs-ofctl to send a  ``monitor  request''
	      Nicira extension message to the switch at	connection setup time.
	      This  message  causes  the switch	to send	information about flow
	      table changes as they occur.  The	following comma-separated spec
	      syntax is	available:

	      !initial
		     Do	not report the switch's	initial	flow table contents.

	      !add   Do	not report newly added flows.

	      !delete
		     Do	not report deleted flows.

	      !modify
		     Do	not report modifications to existing flows.

	      !own   Abbreviate	changes	made to	the flow table by  ovs-ofctl's
		     own  connection  to  the switch.  (These could only occur
		     using the ofctl/send command described below  under  RUN-
		     TIME MANAGEMENT COMMANDS.)

	      !actions
		     Do	not report actions as part of flow updates.

	      table=table
		     Limits  the monitoring to the table with the given	table,
		     which may be expressed as a number	between	0 and  254  or
		     (unless --no-names	is specified) a	name.  By default, all
		     tables are	monitored.

	      out_port=port
		     If	 set,  only  flows  that output	to port	are monitored.
		     The port may be an	OpenFlow port number or	keyword	 (e.g.
		     LOCAL).

	      field=value
		     Monitors  only  flows  that  have	field specified	as the
		     given value.  Any syntax valid for	matching on dump-flows
		     may be used.

	      This command may be useful for debugging	switch	or  controller
	      implementations.	With watch:, it	is particularly	useful for ob-
	      serving how a controller updates flow tables.

   OpenFlow Switch and Controller Commands
       The  following commands,	like those in the previous section, may	be ap-
       plied to	OpenFlow switches, using any of	 the  connection  methods  de-
       scribed	in that	section.  Unlike those commands, these may also	be ap-
       plied to	OpenFlow controllers.

       probe target
	      Sends a single OpenFlow echo-request message to target and waits
	      for the response.	 With the -t or	--timeout option, this command
	      can test whether an OpenFlow switch or controller	is up and run-
	      ning.

       ping target [n]
	      Sends a series of	10 echo	request	packets	to  target  and	 times
	      each  reply.   The  echo	request	packets	consist	of an OpenFlow
	      header plus n bytes (default: 64)	of randomly generated payload.
	      This measures the	latency	of individual requests.

       benchmark target	n count
	      Sends count echo request packets that each consist of  an	 Open-
	      Flow header plus n bytes of payload and waits for	each response.
	      Reports the total	time required.	This is	a measure of the maxi-
	      mum bandwidth to target for round-trips of n-byte	messages.

   Other Commands
       ofp-parse file
	      Reads  file (or stdin if file is -) as a series of OpenFlow mes-
	      sages in the binary format used on an OpenFlow  connection,  and
	      prints  them  to	the  console.  This can	be useful for printing
	      OpenFlow messages	captured from a	TCP stream.

       ofp-parse-pcap file [port...]
	      Reads file, which	must be	in the PCAP  format  used  by  network
	      capture tools such as tcpdump or wireshark, extracts all the TCP
	      streams  for  OpenFlow connections, and prints the OpenFlow mes-
	      sages in those connections in human-readable format on stdout.

	      OpenFlow connections are distinguished by	TCP port number.  Non-
	      OpenFlow packets are ignored.  By	default,  data	on  TCP	 ports
	      6633  and	 6653  are  considered to be OpenFlow.	Specify	one or
	      more port	arguments to override the default.

	      This command cannot usefully print SSL  encrypted	 traffic.   It
	      does not understand IPv6.

   Flow	Syntax
       Some  ovs-ofctl	commands  accept  an argument that describes a flow or
       flows.  Such flow descriptions comprise a series	of field=value assign-
       ments, separated	by commas or white space.  (Embedding  spaces  into  a
       flow  description  normally  requires quoting to	prevent	the shell from
       breaking	the description	into multiple arguments.)

       Flow descriptions should	be in normal form.  This means that a flow may
       only specify a value for	an L3 field if it also specifies a  particular
       L2  protocol,  and  that	a flow may only	specify	an L4 field if it also
       specifies particular L2 and L3 protocol types.  For example, if the  L2
       protocol	type dl_type is	wildcarded, then L3 fields nw_src, nw_dst, and
       nw_proto	 must  also  be	wildcarded.  Similarly,	if dl_type or nw_proto
       (the L3 protocol	type) is wildcarded, so	must be	the L4 fields  tcp_dst
       and tcp_src.  ovs-ofctl will warn about flows not in normal form.

       ovs-fields(7) describes the supported fields and	how to match them.  In
       addition	 to  match fields, commands that operate on flows accept a few
       additional key-value pairs:

       table=table
	      For flow dump commands, limits the flows dumped to those in  ta-
	      ble,  which  may	be  expressed as a number between 0 and	255 or
	      (unless --no-names is specified) a name.	If not	specified  (or
	      if  255  is  specified  as  table), then flows in	all tables are
	      dumped.

	      For flow table modification commands, behavior varies  based  on
	      the OpenFlow version used	to connect to the switch:

	      OpenFlow 1.0
		     OpenFlow  1.0 does	not support table for modifying	flows.
		     ovs-ofctl will exit with an error if  table  (other  than
		     table=255)	 is  specified for a switch that only supports
		     OpenFlow 1.0.

		     In	OpenFlow 1.0, the switch chooses the table into	 which
		     to	 insert	 a new flow.  The Open vSwitch software	switch
		     always chooses table 0.  Other Open vSwitch datapaths and
		     other OpenFlow implementations may	choose	different  ta-
		     bles.

		     The  OpenFlow  1.0	behavior in Open vSwitch for modifying
		     or	removing flows depends on whether  --strict  is	 used.
		     Without  --strict,	 the command applies to	matching flows
		     in	all tables.  With --strict, the	command	 will  operate
		     on	 any  single  matching	flow  in any table; it will do
		     nothing if	there are matches  in  more  than  one	table.
		     (The  distinction between these behaviors only matters if
		     non-OpenFlow 1.0 commands were also used,	because	 Open-
		     Flow  1.0	alone  cannot add flows	with the same matching
		     criteria to multiple tables.)

	      OpenFlow 1.0 with	table_id extension
		     Open vSwitch implements an	OpenFlow extension that	allows
		     the controller to specify the table on which to  operate.
		     ovs-ofctl	automatically enables the extension when table
		     is	specified and OpenFlow 1.0 is used.   ovs-ofctl	 auto-
		     matically	detects	whether	the switch supports the	exten-
		     sion.  As of this writing,	this extension is  only	 known
		     to	be implemented by Open vSwitch.

		     With  this	extension, ovs-ofctl operates on the requested
		     table when	table is specified, and	acts as	described  for
		     OpenFlow 1.0 above	when no	table is specified (or for ta-
		     ble=255).

	      OpenFlow 1.1
		     OpenFlow 1.1 requires flow	table modification commands to
		     specify  a	 table.	  When	table is not specified (or ta-
		     ble=255 is	specified), ovs-ofctl defaults to table	0.

	      OpenFlow 1.2 and later
		     OpenFlow 1.2 and later allow flow deletion	commands,  but
		     not other flow table modification commands, to operate on
		     all  flow	tables,	 with the behavior described above for
		     OpenFlow 1.0.

       duration=...
       n_packet=...
       n_bytes=...
	      ovs-ofctl	ignores	assignments to these ``fields''	to allow  out-
	      put  from	 the  dump-flows command to be used as input for other
	      commands that parse flows.

       The add-flow, add-flows,	and mod-flows commands require	an  additional
       field, which must be the	final field specified:

       actions=[action][,action...]
	      Specifies	 a comma-separated list	of actions to take on a	packet
	      when the flow entry matches.  If no action  is  specified,  then
	      packets  matching	 the flow are dropped.	See ovs-actions(7) for
	      details on the syntax and	semantics of actions.  K

       An opaque identifier called a cookie can	be used	as a handle  to	 iden-
       tify a set of flows:

       cookie=value
	      A	 cookie	 can  be  associated  with  a flow using the add-flow,
	      add-flows, and mod-flows commands.  value	can be any 64-bit num-
	      ber and need not be unique among flows.  If this field is	 omit-
	      ted, a default cookie value of 0 is used.

       cookie=value/mask
	      When using NXM, the cookie can be	used as	a handle for querying,
	      modifying,  and  deleting	flows.	value and mask may be supplied
	      for the del-flows,  mod-flows,  dump-flows,  and	dump-aggregate
	      commands	to  limit matching cookies.  A 1-bit in	mask indicates
	      that the corresponding bit in cookie must	match exactly,	and  a
	      0-bit  wildcards	that bit.  A mask of -1	may be used to exactly
	      match a cookie.

	      The mod-flows command can	update the cookies of flows that match
	      a	cookie by specifying the cookie	field twice (once with a  mask
	      for matching and once without to indicate	the new	value):

	      ovs-ofctl	mod-flows br0 cookie=1,actions=normal
		     Change  all  flows' cookies to 1 and change their actions
		     to	normal.

	      ovs-ofctl	mod-flows br0 cookie=1/-1,cookie=2,actions=normal
		     Update cookies with a value of 1 to 2  and	 change	 their
		     actions to	normal.

	      The ability to match on cookies was added	in Open	vSwitch	1.5.0.

       The following additional	field sets the priority	for flows added	by the
       add-flow	 and  add-flows	 commands.   For  mod-flows and	del-flows when
       --strict	is specified, priority must match along	with the rest  of  the
       flow  specification.   For mod-flows without --strict, priority is only
       significant if the command creates a  new  flow,	 that  is,  non-strict
       mod-flows  does	not match on priority and will not change the priority
       of existing flows.  Other commands do not allow priority	to  be	speci-
       fied.

       priority=value
	      The  priority at which a wildcarded entry	will match in compari-
	      son to others.  value is a number	between	0  and	65535,	inclu-
	      sive.   A	higher value will match	before a lower one.  An	exact-
	      match entry will always have priority over an  entry  containing
	      wildcards,  so it	has an implicit	priority value of 65535.  When
	      adding a flow, if	the field is not specified, the	flow's	prior-
	      ity will default to 32768.

	      OpenFlow	leaves	behavior undefined when	two or more flows with
	      the same priority	can match a single packet.  Some users	expect
	      ``sensible'' behavior, such as more specific flows taking	prece-
	      dence  over  less	 specific flows, but OpenFlow does not specify
	      this and Open vSwitch  does  not	implement  it.	 Users	should
	      therefore	 take  care  to	 use priorities	to ensure the behavior
	      that they	expect.

       The add-flow, add-flows,	and mod-flows commands support	the  following
       additional  options.   These  options affect only new flows.  Thus, for
       add-flow	and add-flows, these options are always	significant,  but  for
       mod-flows  they are significant only if the command creates a new flow,
       that is,	their values do	not update or affect existing flows.

       idle_timeout=seconds
	      Causes the flow to expire	after the given	number of  seconds  of
	      inactivity.  A value of 0	(the default) prevents a flow from ex-
	      piring due to inactivity.

       hard_timeout=seconds
	      Causes the flow to expire	after the given	number of seconds, re-
	      gardless of activity.  A value of	0 (the default)	gives the flow
	      no hard expiration deadline.

       importance=value
	      Sets  the	 importance of a flow.	The flow entry eviction	mecha-
	      nism can use importance as a factor in deciding  which  flow  to
	      evict.   A value of 0 (the default) makes	the flow non-evictable
	      on the basis of importance.   Specify  a	value  between	0  and
	      65535.

	      Only OpenFlow 1.4	and later support importance.

       send_flow_rem
	      Marks  the flow with a flag that causes the switch to generate a
	      ``flow removed'' message and send	it to  interested  controllers
	      when the flow later expires or is	removed.

       check_overlap
	      Forces  the switch to check that the flow	match does not overlap
	      that of any different flow with the same priority	 in  the  same
	      table.  (This check is expensive so it is	best to	avoid it.)

       reset_counts
	      When  this  flag is specified on a flow being added to a switch,
	      and the switch already has a flow	with an	 identical  match,  an
	      OpenFlow 1.2 (or later) switch resets the	flow's packet and byte
	      counters	to  0.	Without	the flag, the packet and byte counters
	      are preserved.

	      OpenFlow 1.0 and 1.1 switches always reset counters in this sit-
	      uation, as if reset_counts were always specified.

	      Open vSwitch 1.10	added support for reset_counts.

       no_packet_counts
       no_byte_counts
	      Adding these flags to a flow advises an OpenFlow 1.3 (or	later)
	      switch  that  the	 controller does not need packet or byte coun-
	      ters, respectively, for the flow.	 Some  switch  implementations
	      might  achieve higher performance	or reduce resource consumption
	      when these flags are used.  These	flags provide  no  benefit  to
	      the Open vSwitch software	switch implementation.

	      OpenFlow 1.2 and earlier do not support these flags.

	      Open   vSwitch  1.10  added  support  for	 no_packet_counts  and
	      no_byte_counts.

       The dump-flows, dump-aggregate, del-flow	and del-flows commands support
       these additional	optional fields:

       out_port=port
	      If set, a	matching flow must include an output action  to	 port,
	      which must be an OpenFlow	port number or name (e.g. local).

       out_group=group
	      If  set,	a  matching  flow  must	include	an group action	naming
	      group, which must	be an OpenFlow group number.   This  field  is
	      supported	 in  Open  vSwitch 2.5 and later and requires OpenFlow
	      1.1 or later.

   Table Entry Output
       The dump-tables and dump-aggregate commands print information about the
       entries in a datapath's tables.	Each line of output is a flow entry as
       described in Flow Syntax, above,	plus some additional fields:

       duration=secs
	      The time,	in seconds, that the entry  has	 been  in  the	table.
	      secs includes as much precision as the switch provides, possibly
	      to nanosecond resolution.

       n_packets
	      The number of packets that have matched the entry.

       n_bytes
	      The total	number of bytes	from packets that have matched the en-
	      try.

       The following additional	fields are included only if the	switch is Open
       vSwitch	1.6  or	later and the NXM flow format is used to dump the flow
       (see the	description of the --flow-format option	below).	 The values of
       these additional	fields	are  approximations  only  and	in  particular
       idle_age	will sometimes become nonzero even for busy flows.

       hard_age=secs
	      The  integer number of seconds since the flow was	added or modi-
	      fied.  hard_age is displayed only	if it differs from the integer
	      part of duration.	  (This	 is  separate  from  duration  because
	      mod-flows	 restarts the hard_timeout timer without zeroing dura-
	      tion.)

       idle_age=secs
	      The integer number of seconds that have passed without any pack-
	      ets passing through the flow.

   Packet-Out Syntax
       ovs-ofctl bundle	command	accepts	packet-outs to	be  specified  in  the
       bundle  file.  Each packet-out comprises	of a series of field=value as-
       signments, separated by commas or white space.  (Embedding spaces  into
       a packet-out description	normally requires quoting to prevent the shell
       from  breaking the description into multiple arguments.).  Unless noted
       otherwise only the last instance	of each	field is honoured.  This  same
       syntax is also supported	by the ovs-ofctl packet-out command.

       in_port=port
	      The port number to be considered the in_port when	processing ac-
	      tions.   This  can  be any valid OpenFlow	port number, or	any of
	      the LOCAL, CONTROLLER, or	NONE.  This field is required.

       pipeline_field=value
	      Optionally, user can specify a list of  pipeline	fields	for  a
	      packet-out  message. The supported pipeline fields includes tun-
	      nel fields and register fields as	defined	in ovs-fields(7).

       packet=hex-string
	      The actual packet	to send, expressed as a	string of  hexadecimal
	      bytes.  This field is required.

       actions=[action][,action...]
	      The  syntax  of  actions are identical to	the actions= field de-
	      scribed in Flow Syntax above.  Specifying	actions= is  optional,
	      but  omitting  actions  is  interpreted as a drop, so the	packet
	      will not be sent anywhere	from  the  switch.   actions  must  be
	      specified	at the end of each line, like for flow mods.

   Group Syntax
       Some  ovs-ofctl	commands  accept an argument that describes a group or
       groups.	Such flow descriptions comprise	a series  field=value  assign-
       ments,  separated  by  commas or	white space.  (Embedding spaces	into a
       group description normally requires quoting to prevent the  shell  from
       breaking	the description	into multiple arguments.). Unless noted	other-
       wise only the last instance of each field is honoured.

       group_id=id
	      The  integer group id of group.  When this field is specified in
	      del-groups or dump-groups, the keyword "all" may be used to des-
	      ignate all groups.  This field is	required.

       type=type
	      The type of the group.  The add-group, add-groups	and mod-groups
	      commands require this field.  It is prohibited  for  other  com-
	      mands. The following keywords designated the allowed types:

	      all    Execute all buckets in the	group.

	      select Execute  one  bucket  in  the group, balancing across the
		     buckets according to their	weights.  To select a  bucket,
		     for  each live bucket, Open vSwitch hashes	flow data with
		     the bucket	ID and multiplies by the bucket	weight to  ob-
		     tain  a  ``score,''  and then selects the bucket with the
		     highest score.  Use selection_method to control the  flow
		     data used for selection.

	      indirect
		     Executes the one bucket in	the group.

	      ff
	      fast_failover
		     Executes  the first live bucket in	the group which	is as-
		     sociated with a live port or group.

       command_bucket_id=id
	      The bucket to operate on.	 The insert-buckets and	remove-buckets
	      commands require this field.  It is prohibited  for  other  com-
	      mands.  id may be	an integer or one of the following keywords:

	      all    Operate  on  all  buckets	in the group.  Only valid when
		     used with the remove-buckets command in  which  case  the
		     effect is to remove all buckets from the group.

	      first  Operate on	the first bucket present in the	group.	In the
		     case  of  the insert-buckets command the effect is	to in-
		     sert new bucets just  before  the	first  bucket  already
		     present  in  the  group; or to replace the	buckets	of the
		     group if there are	no  buckets  already  present  in  the
		     group.  In	the case of the	remove-buckets command the ef-
		     fect  is  to  remove the first bucket of the group; or do
		     nothing if	there are no buckets present in	the group.

	      last   Operate on	the last bucket	present	in the group.  In  the
		     case  of  the insert-buckets command the effect is	to in-
		     sert new  bucets  just  after  the	 last  bucket  already
		     present  in  the  group; or to replace the	buckets	of the
		     group if there are	no  buckets  already  present  in  the
		     group.  In	the case of the	remove-buckets command the ef-
		     fect  is  to  remove  the last bucket of the group; or do
		     nothing if	there are no buckets present in	the group.

	      If id is an integer then it should correspond to	the  bucket_id
	      of a bucket present in the group.	 In case of the	insert-buckets
	      command  the  effect is to insert	buckets	just before the	bucket
	      in the group whose bucket_id is id.  In  case  of	 the  iremove-
	      buckets  command	the effect is to remove	the in the group whose
	      bucket_id	is id.	It is an error if there	is no  bucket  persent
	      group in whose bucket_id is id.

       selection_method=method
	      The selection method used	to select a bucket for a select	group.
	      This  is a string	of 1 to	15 bytes in length known to lower lay-
	      ers.  This field	is  optional  for  add-group,  add-groups  and
	      mod-group	 commands  on groups of	type select. Prohibited	other-
	      wise.  If	no selection method is specified, Open vSwitch	up  to
	      release  2.9  applies  the hash method with default fields. From
	      2.10 onwards Open	vSwitch	defaults to the	 dp_hash  method  with
	      symmetric	 L3/L4	hash  algorithm, as long as the	weighted group
	      buckets can be mapped to dp_hash values  with  sufficient	 accu-
	      racy.   In  2.10 this was	restricted to a	maximum	of 64 buckets,
	      and in 2.17 the limit was	raised to 256 buckets.	In those  rare
	      cases  Open  vSwitch 2.10	and later fall back to the hash	method
	      with the default set of hash fields.

	      dp_hash
		     Use a datapath computed hash value.  The  hash  algorithm
		     varies   accross	different   datapath  implementations.
		     dp_hash  uses  the	 upper	 32   bits   of	  the	selec-
		     tion_method_param	as  the	datapath hash algorithm	selec-
		     tor.  The supported values	are 0 (corresponding  to  hash
		     computation  over the IP 5-tuple) and 1 (corresponding to
		     a symmetric hash computation over the IP  5-tuple).   Se-
		     lecting  specific	fields	with  the fields option	is not
		     supported with dp_hash).  The lower 32 bits are  used  as
		     the hash basis.

		     Using  dp_hash has	the advantage that it does not require
		     the generated datapath flows to  exact  match  any	 addi-
		     tional packet header fields.  For example,	even if	multi-
		     ple TCP connections thus hashed to	different select group
		     buckets have different source port	numbers, generally all
		     of	 them would be handled with a small set	of already es-
		     tablished datapath	flows, resulting in less  latency  for
		     TCP  SYN  packets.	 The downside is that the shared data-
		     path flows	must match each	packet twice, as the  datapath
		     hash  value  calculation  happens only when needed, and a
		     second match is required to match some bits of its	value.
		     This double-matching incurs a  small  additional  latency
		     cost  for each packet, but	this latency is	orders of mag-
		     nitude less than the latency  of  creating	 new  datapath
		     flows for new TCP connections.

	      hash   Use  a  hash  computed over the fields specified with the
		     fields option, see	below.	If no hash fields  are	speci-
		     fied, hash	defaults to a symmetric	hash over the combina-
		     tion  of  MAC  addresses,	VLAN  tags, Ether type,	IP ad-
		     dresses and  L4  port  numbers.   hash  uses  the	selec-
		     tion_method_param as the hash basis.

		     Note  that	 the hashed fields become exact	matched	by the
		     datapath flows.  For example, if the TCP source  port  is
		     hashed,  the  created  datapath flows will	match the spe-
		     cific TCP source port value present  in  the  packet  re-
		     ceived.   Since  each TCP connection generally has	a dif-
		     ferent source port	value, a separate datapath  flow  will
		     be	 need  to  be  inserted	 for  each TCP connection thus
		     hashed to a select	group bucket.

	      This option uses a Netronome OpenFlow extension  which  is  only
	      supported	 when  using  Open vSwitch 2.4 and later with OpenFlow
	      1.5 and later.

       selection_method_param=param
	      64-bit integer parameter to the selection	method selected	by the
	      selection_method field.  The parameter's use is defined  by  the
	      lower-layer  that	 implements  the  selection_method.  It	is op-
	      tional if	the selection_method field is specified	as a non-empty
	      string.  Prohibited otherwise. The default value is zero.

	      This option uses a Netronome OpenFlow extension  which  is  only
	      supported	 when  using  Open vSwitch 2.4 and later with OpenFlow
	      1.5 and later.

       fields=field
       fields(field[=mask]...)
	      The field	parameters to selection	method selected	by the	selec-
	      tion_method  field.  The syntax is described in Flow Syntax with
	      the additional restrictions that if a value is  provided	it  is
	      treated  as a wildcard mask and wildcard masks following a slash
	      are prohibited. The pre-requisites of fields must	be provided by
	      any flows	that output to the group.  The use of  the  fields  is
	      defined by the lower-layer that implements the selection_method.
	      They  are	optional if the	selection_method field is specified as
	      ``hash', prohibited otherwise.  The default is no	fields.

	      This option will use a Netronome	OpenFlow  extension  which  is
	      only  supported when using Open vSwitch 2.4 and later with Open-
	      Flow 1.5 and later.

       bucket=bucket_parameters
	      The add-group, add-groups	 and  mod-group	 commands  require  at
	      least  one  bucket  field.  Bucket  fields must appear after all
	      other fields.  Multiple bucket fields to specify multiple	 buck-
	      ets.   The  order	 in which buckets are specified	corresponds to
	      their order in the group.	If the type of the group is "indirect"
	      then only	one group may be  specified.   bucket_parameters  con-
	      sists  of	a list of field=value assignments, separated by	commas
	      or white space followed by a comma-separated  list  of  actions.
	      The fields for bucket_parameters are:

	      bucket_id=id
		     The  32-bit  integer  group  id  of  the  bucket.	Values
		     greater than 0xffffff00 are  reserved.   This  field  was
		     added  in	Open  vSwitch 2.4 to conform with the OpenFlow
		     1.5 specification.	It is not supported when earlier  ver-
		     sions  of OpenFlow	are used.  Open	vSwitch	will automati-
		     cally allocate bucket ids when they are not specified.

	      actions=[action][,action...]
		     The syntax	of actions are identical to the	actions= field
		     described in Flow Syntax above.  Specifying  actions=  is
		     optional,	any  unknown  bucket  parameter	will be	inter-
		     preted as an action.

	      weight=value
		     The relative weight of the	bucket as an integer. This may
		     be	used by	the switch during  bucket  select  for	groups
		     whose type	is select.

	      watch_port=port
		     Port  used	 to  determine liveness	of group.  This	or the
		     watch_group field is required for groups whose type is ff
		     or	fast_failover.	This or	the watch_group	field can also
		     be	used for groups	whose type is select.

	      watch_group=group_id
		     Group identifier of group used to determine  liveness  of
		     group.   This  or	the  watch_port	 field is required for
		     groups whose type is ff or	fast_failover.	 This  or  the
		     watch_port	 field	can also be used for groups whose type
		     is	select.

   Meter Syntax
       The meter table commands	accept an argument  that  describes  a	meter.
       Such meter descriptions comprise	a series field=value assignments, sep-
       arated  by  commas  or white space.  (Embedding spaces into a group de-
       scription normally requires quoting to prevent the shell	from  breaking
       the  description	into multiple arguments.). Unless noted	otherwise only
       the last	instance of each field is honoured.

       meter=id
	      The identifier for the meter.  An	integer	is used	to  specify  a
	      user-defined  meter.   In	 addition,  the	 keywords "all", "con-
	      troller",	and "slowpath",	are also supported as virtual  meters.
	      The  "controller"	and "slowpath" virtual meters apply to packets
	      sent to the controller and to the	OVS userspace, respectively.

	      When this	field is specified in del-meter, dump-meter, or	meter-
	      stats, the keyword "all" may be used to  designate  all  meters.
	      This  field is required, except for meter-stats, which dumps all
	      stats when this field is not specified.

       kbps
       pktps  The unit for the rate  and  burst_size  band  parameters.	  kbps
	      specifies	 kilobits  per second, and pktps specifies packets per
	      second.  A unit is required for the add-meter and	mod-meter com-
	      mands.

       burst  If set, enables  burst  support  for  meter  bands  through  the
	      burst_size parameter.

       stats  If set, enables the collection of	meter and band statistics.

       bands=band_parameters
	      The  add-meter  and mod-meter commands require at	least one band
	      specification. Bands must	appear after all other fields.

	      type=type
		     The type of the meter band.  This keyword	starts	a  new
		     band  specification.   Each  band	specifies a rate above
		     which the band is to take some action. The	action depends
		     on	the band type.	If multiple bands' rate	 is  exceeded,
		     then  the	band  with the highest rate among the exceeded
		     bands is selected.	 The following keywords	designate  the
		     allowed meter band	types:

		     drop   Drop packets exceeding the band's rate limit.

	      The other	band_parameters	are:

	      rate=value
		     The  relative  rate  limit	for this band, in kilobits per
		     second or packets per second, depending on	 whether  kbps
		     or	pktps was specified.

	      burst_size=size
		     If	burst is specified for the meter entry,	configures the
		     maximum  burst  allowed for the band in kilobits or pack-
		     ets, depending on whether kbps or	pktps  was  specified.
		     If	unspecified, the switch	is free	to select some reason-
		     able value	depending on its configuration.

OPTIONS
       --strict
	      Uses strict matching when	running	flow modification commands.

       --names
       --no-names
	      Every  OpenFlow port has a name and a number, and	every OpenFlow
	      flow table has a number  and  sometimes  a  name.	  By  default,
	      ovs-ofctl	commands accept	both port and table names and numbers,
	      and they display port and	table names if ovs-ofctl is running on
	      an   interactive	console,  numbers  otherwise.	With  --names,
	      ovs-ofctl	commands both accept and display port and table	names;
	      with --no-names, commands	neither	accept nor  display  port  and
	      table names.

	      If  a port or table name contains	special	characters or might be
	      confused with a keyword within a flow, it	 may  be  enclosed  in
	      double  quotes  (escaped	from  the shell).  If necessary, JSON-
	      style escape sequences may be used inside	quotes,	 as  specified
	      in  RFC  7159.  When it displays port and	table names, ovs-ofctl
	      quotes any name that does	not start with a  letter  followed  by
	      letters or digits.

	      Open  vSwitch  added  support  for port names and	these options.
	      Open vSwitch 2.10	added support for table	names.	 Earlier  ver-
	      sions always behaved as if --no-names were specified.

	      Open  vSwitch does not place its own limit on the	length of port
	      names, but OpenFlow limits port  names  to  15  bytes.   Because
	      ovs-ofctl	 uses  OpenFlow	 to  retrieve the mapping between port
	      names and	numbers, names longer than this	limit  will  be	 trun-
	      cated  for  both	display	 and  acceptance.  Truncation can also
	      cause long names that are	different to appear to	be  the	 same;
	      when  a  switch  has  two	 ports with the	same (truncated) name,
	      ovs-ofctl	refuses	to display or accept the name, using the  num-
	      ber instead.

	      OpenFlow and Open	vSwitch	limit table names to 32	bytes.

       --stats
       --no-stats
	      The  dump-flows  command	by  default, or	with --stats, includes
	      flow duration, packet and	byte counts, and idle and hard age  in
	      its  output.  With --no-stats, it	omits all of these, as well as
	      cookie values and	table IDs if they are zero.

       --read-only
	      Do not execute read/write	commands.

       --bundle
	      Execute flow mods	as an OpenFlow 1.4 atomic bundle transaction.

	      	     Within a bundle, all flow mods are	processed in the order
		     they appear and as	a single atomic	 transaction,  meaning
		     that  if  one  of them fails, the whole transaction fails
		     and none of the changes are made to the switch's flow ta-
		     ble, and that each	given datapath packet  traversing  the
		     OpenFlow tables sees the flow tables either as before the
		     transaction,  or  after  all  the flow mods in the	bundle
		     have been successfully applied.

	      	     The beginning and the end of the flow table  modification
		     commands in a bundle are delimited	with OpenFlow 1.4 bun-
		     dle  control  messages, which makes it possible to	stream
		     the included commands without explicit OpenFlow barriers,
		     which are otherwise used after each flow table  modifica-
		     tion  command.  This may make large modifications execute
		     faster as a bundle.

	      	     Bundles require OpenFlow 1.4 or higher.  An  explicit  -O
		     OpenFlow14	 option	is not needed, but you may need	to en-
		     able OpenFlow 1.4 support for OVS by  setting  the	 OVSDB
		     protocols column in the bridge table.

       -O [version[,version]...]
       --protocols=[version[,version]...]
	      Sets the OpenFlow	protocol versions that are allowed when	estab-
	      lishing an OpenFlow session.

	      These protocol versions are enabled by default:

	      	     OpenFlow10, for OpenFlow 1.0.
       The  following  protocol	versions are generally supported, but for com-
       patibility with older versions of Open vSwitch they are not enabled  by
       default:

	      	     OpenFlow11, for OpenFlow 1.1.

	      	     OpenFlow12, for OpenFlow 1.2.

	      	     OpenFlow13, for OpenFlow 1.3.

	      	     OpenFlow14, for OpenFlow 1.4.

	      	     OpenFlow15, for OpenFlow 1.5.

       -F format[,format...]
       --flow-format=format[,format...]
	      ovs-ofctl	 supports  the	following individual flow formats, any
	      number of	which may be listed as format:

	      OpenFlow10-table_id
		     This is the standard OpenFlow 1.0 flow format.  All Open-
		     Flow switches and all versions of	Open  vSwitch  support
		     this flow format.

	      OpenFlow10+table_id
		     This  is  the  standard  OpenFlow	1.0 flow format	plus a
		     Nicira extension that allows  ovs-ofctl  to  specify  the
		     flow  table  in which a particular	flow should be placed.
		     Open vSwitch 1.2 and later	supports this flow format.

	      NXM-table_id (Nicira Extended Match)
		     This Nicira extension to OpenFlow is flexible and	exten-
		     sible.   It  supports  all	of the Nicira flow extensions,
		     such as tun_id and	registers.  Open vSwitch 1.1 and later
		     supports this flow	format.

	      NXM+table_id (Nicira Extended Match)
		     This combines Nicira Extended match with the  ability  to
		     place  a  flow in a specific table.  Open vSwitch 1.2 and
		     later supports this flow format.

	      OXM-OpenFlow12
	      OXM-OpenFlow13
	      OXM-OpenFlow14
	      OXM-OpenFlow15
		     These are the standard OXM	 (OpenFlow  Extensible	Match)
		     flow format in OpenFlow 1.2 and later.

	      ovs-ofctl	 also supports the following abbreviations for collec-
	      tions of flow formats:

	      any    Any supported flow	format.

	      OpenFlow10
		     OpenFlow10-table_id or OpenFlow10+table_id.

	      NXM    NXM-table_id or NXM+table_id.

	      OXM    OXM-OpenFlow12, OXM-OpenFlow13, or	OXM-OpenFlow14.

	      For commands that	modify the flow	table,	ovs-ofctl  by  default
	      negotiates  the  most widely supported flow format that supports
	      the flows	being added.  For commands that	query the flow	table,
	      ovs-ofctl	 by default uses the most advanced format supported by
	      the switch.

	      This option, where format	is a comma-separated list  of  one  or
	      more  of	the formats listed above, limits ovs-ofctl's choice of
	      flow format.  If a command cannot	work as	requested using	one of
	      the specified flow formats, ovs-ofctl will report	a fatal	error.

       -P format
       --packet-in-format=format
	      ovs-ofctl	supports the following ``packet-in'' formats, in order
	      of increasing capability:

	      standard
		     This  uses	 the  OFPT_PACKET_IN  message,	the   standard
		     ``packet-in''  message  for  any  given OpenFlow version.
		     Every OpenFlow switch that	supports a given OpenFlow ver-
		     sion supports this	format.

	      nxt_packet_in
		     This uses the NXT_PACKET_IN message, which	adds  many  of
		     the  capabilities of the OpenFlow 1.1 and later ``packet-
		     in'' messages before those	OpenFlow versions were	avail-
		     able in Open vSwitch.  Open vSwitch 1.1 and later support
		     this  format.   Only Open vSwitch 2.6 and later, however,
		     support it	for OpenFlow 1.1 and later (but	there is  lit-
		     tle reason	to use it with those versions of OpenFlow).

	      nxt_packet_in2
		     This uses the NXT_PACKET_IN2 message, which is extensible
		     and  should  avoid	 the need to define new	formats	later.
		     In	particular, this  format  supports  passing  arbitrary
		     user-provided data	to a controller	using the userdata op-
		     tion  on  the  controller	action.	  Open vSwitch 2.6 and
		     later support this	format.

	      Without this option, ovs-ofctl  prefers  nxt_packet_in2  if  the
	      switch  supports	it.   Otherwise,  if  OpenFlow	1.0 is in use,
	      ovs-ofctl	prefers	nxt_packet_in if the switch supports it.  Oth-
	      erwise, ovs-ofctl	falls back to the standard  packet-in  format.
	      When this	option is specified, ovs-ofctl insists on the selected
	      format.	If  the	 switch	does not support the requested format,
	      ovs-ofctl	will report a fatal error.

	      Before version 2.6, Open vSwitch called  standard	 format	 open-
	      flow10 and nxt_packet_in format nxm, and ovs-ofctl still accepts
	      these  names  as	synonyms.  (The	name openflow10	was a misnomer
	      because this format actually varies from one OpenFlow version to
	      another; it is not consistently OpenFlow 1.0 format.  Similarly,
	      when nxt_packet_in2 was introduced, the name nxm became  confus-
	      ing because it also uses OXM/NXM.)

	      This option affects only the monitor command.

       --timestamp
	      Print a timestamp	before each received packet.  This option only
	      affects the monitor, snoop, and ofp-parse-pcap commands.

       -m
       --more Increases	 the verbosity of OpenFlow messages printed and	logged
	      by ovs-ofctl commands.  Specify this option more	than  once  to
	      increase verbosity further.

       --sort[=field]
       --rsort[=field]
	      Display output sorted by flow field in ascending (--sort)	or de-
	      scending	(--rsort) order, where field is	any of the fields that
	      are allowed for matching or priority to sort by priority.	  When
	      field  is	 omitted,  the	output is sorted by priority.  Specify
	      these options multiple times to sort by multiple fields.

	      Any given	flow will not necessarily specify a value for a	 given
	      field.  This requires special treatement:

	      	     A	flow that does not specify any part of a field that is
		     used for sorting is sorted	after all the  flows  that  do
		     specify the field.	 For example, --sort=tcp_src will sort
		     all the flows that	specify	a TCP source port in ascending
		     order,  followed  by  the flows that do not specify a TCP
		     source port at all.

	      	     A flow that only specifies	some bits in a field is	sorted
		     as	if  the	 wildcarded  bits  were	 zero.	 For  example,
		     --sort=nw_src   would   sort   a	flow   that  specifies
		     nw_src=192.168.0.0/24 the same as nw_src=192.168.0.0.

	      These options currently affect only dump-flows output.

   Daemon Options
       The following options are valid on POSIX	based platforms.

       --pidfile[=pidfile]
	      Causes a file (by	default, ovs-ofctl.pid)	to be created indicat-
	      ing the PID of the running process.  If the pidfile argument  is
	      not  specified,  or if it	does not begin with /, then it is cre-
	      ated in /var/run/openvswitch.

	      If --pidfile is not specified, no	pidfile	is created.

       --overwrite-pidfile
	      By default, when --pidfile is specified and the  specified  pid-
	      file  already  exists  and  is  locked  by  a  running  process,
	      ovs-ofctl	refuses	 to  start.   Specify  --overwrite-pidfile  to
	      cause it to instead overwrite the	pidfile.

	      When --pidfile is	not specified, this option has no effect.

       --detach
	      Runs  ovs-ofctl as a background process.	The process forks, and
	      in the child it starts a new session, closes the	standard  file
	      descriptors  (which  has the side	effect of disabling logging to
	      the console), and	changes	its current directory to the root (un-
	      less --no-chdir is specified).  After the	 child	completes  its
	      initialization,  the parent exits.  ovs-ofctl detaches only when
	      executing	the monitor or snoop commands.

       --monitor
	      Creates an additional process to monitor the  ovs-ofctl  daemon.
	      If  the daemon dies due to a signal that indicates a programming
	      error  (SIGABRT,	SIGALRM,  SIGBUS,  SIGFPE,  SIGILL,   SIGPIPE,
	      SIGSEGV,	SIGXCPU, or SIGXFSZ) then the monitor process starts a
	      new copy of it.  If the daemon dies or exits for another reason,
	      the monitor process exits.

	      This option is normally used with	--detach, but  it  also	 func-
	      tions without it.

       --no-chdir
	      By  default,  when  --detach is specified, ovs-ofctl changes its
	      current working directory	to the root  directory	after  it  de-
	      taches.	Otherwise, invoking ovs-ofctl from a carelessly	chosen
	      directory	would prevent the administrator	 from  unmounting  the
	      file system that holds that directory.

	      Specifying   --no-chdir  suppresses  this	 behavior,  preventing
	      ovs-ofctl	from changing its current working directory.  This may
	      be useful	for collecting core files, since it is common behavior
	      to write core dumps into the current working directory  and  the
	      root directory is	not a good directory to	use.

	      This option has no effect	when --detach is not specified.

       --no-self-confinement
	      By  default  daemon will try to self-confine itself to work with
	      files under well-known directories determined during build.   It
	      is  better  to  stick  with this default behavior	and not	to use
	      this flag	unless some other Access Control is  used  to  confine
	      daemon.  Note that in contrast to	other access control implemen-
	      tations  that are	typically enforced from	kernel-space (e.g. DAC
	      or MAC), self-confinement	is imposed from	the user-space	daemon
	      itself  and hence	should not be considered as a full confinement
	      strategy,	but instead should be viewed as	an additional layer of
	      security.

       --user Causes ovs-ofctl	to  run	 as  a	different  user	 specified  in
	      "user:group",  thus  dropping most of the	root privileges. Short
	      forms "user" and ":group"	are also allowed, with current user or
	      group are	assumed	respectively. Only daemons started by the root
	      user accepts this	argument.

	      On   Linux,   daemons   will   be	  granted   CAP_IPC_LOCK   and
	      CAP_NET_BIND_SERVICES  before  dropping root privileges. Daemons
	      that interact with a datapath, such  as  ovs-vswitchd,  will  be
	      granted  three  additional  capabilities,	 namely	CAP_NET_ADMIN,
	      CAP_NET_BROADCAST	and CAP_NET_RAW.  The capability  change  will
	      apply even if the	new user is root.

	      On Windows, this option is not currently supported. For security
	      reasons,	specifying  this  option will cause the	daemon process
	      not to start.

       --unixctl=socket
	      Sets the name of the control socket on which  ovs-ofctl  listens
	      for  runtime  management	commands  (see RUNTIME MANAGEMENT COM-
	      MANDS, below).  If socket	does not begin with /,	it  is	inter-
	      preted as	relative to /var/run/openvswitch.  If --unixctl	is not
	      used    at   all,	  the	default	  socket   is	/var/run/open-
	      vswitch/ovs-ofctl.pid.ctl, where pid is ovs-ofctl's process ID.

	      On Windows a local named pipe is used to listen for runtime man-
	      agement commands.	 A file	is created in  the  absolute  path  as
	      pointed  by socket or if --unixctl is not	used at	all, a file is
	      created as ovs-ofctl.ctl in the configured OVS_RUNDIR directory.
	      The file exists just to mimic the	 behavior  of  a  Unix	domain
	      socket.

	      Specifying none for socket disables the control socket feature.

   Public Key Infrastructure Options
       -p privkey.pem
       --private-key=privkey.pem
	      Specifies	 a  PEM	 file  containing  the	private	 key  used  as
	      ovs-ofctl's identity for outgoing	SSL connections.

       -c cert.pem
       --certificate=cert.pem
	      Specifies	a PEM file containing a	certificate that certifies the
	      private key specified on -p or --private-key to be  trustworthy.
	      The certificate must be signed by	the certificate	authority (CA)
	      that the peer in SSL connections will use	to verify it.

       -C cacert.pem
       --ca-cert=cacert.pem
	      Specifies	  a  PEM  file	containing  the	 CA  certificate  that
	      ovs-ofctl	should use to verify certificates presented to	it  by
	      SSL peers.  (This	may be the same	certificate that SSL peers use
	      to  verify  the certificate specified on -c or --certificate, or
	      it may be	a different one, depending on the PKI design in	use.)

       -C none
       --ca-cert=none
	      Disables verification of certificates presented  by  SSL	peers.
	      This  introduces a security risk,	because	it means that certifi-
	      cates cannot be verified to be those of known trusted hosts.

       -v[spec]
       --verbose=[spec]
	      Sets logging levels.  Without any	spec, sets the log  level  for
	      every  module and	destination to dbg.  Otherwise,	spec is	a list
	      of words separated by spaces or commas or	colons,	up to one from
	      each category below:

	      	     A valid module name, as displayed by the  vlog/list  com-
		     mand on ovs-appctl(8), limits the log level change	to the
		     specified module.

	      	     syslog,  console,	or file, to limit the log level	change
		     to	only to	the system log,	to the console,	or to a	 file,
		     respectively.    (If  --detach  is	 specified,  ovs-ofctl
		     closes its	standard file descriptors, so logging  to  the
		     console will have no effect.)

		     On	 Windows platform, syslog is accepted as a word	and is
		     only useful along with the	 --syslog-target  option  (the
		     word has no effect	otherwise).

	      	     off,  emer,  err,	warn, info, or dbg, to control the log
		     level.  Messages of the given severity or higher will  be
		     logged,  and  messages of lower severity will be filtered
		     out.  off filters out all	messages.   See	 ovs-appctl(8)
		     for a definition of each log level.

	      Case is not significant within spec.

	      Regardless  of  the  log	levels set for file, logging to	a file
	      will not take place unless --log-file is also specified (see be-
	      low).

	      For compatibility	with older versions of OVS, any	is accepted as
	      a	word but has no	effect.

       -v
       --verbose
	      Sets the maximum logging verbosity level,	equivalent  to	--ver-
	      bose=dbg.

       -vPATTERN:destination:pattern
       --verbose=PATTERN:destination:pattern
	      Sets  the	 log  pattern  for  destination	 to pattern.  Refer to
	      ovs-appctl(8) for	a description of the valid syntax for pattern.

       -vFACILITY:facility
       --verbose=FACILITY:facility
	      Sets the RFC5424 facility	of the log message.  facility  can  be
	      one  of kern, user, mail,	daemon,	auth, syslog, lpr, news, uucp,
	      clock, ftp, ntp, audit, alert, clock2, local0,  local1,  local2,
	      local3,  local4, local5, local6 or local7. If this option	is not
	      specified, daemon	is used	as the default for  the	 local	system
	      syslog  and local0 is used while sending a message to the	target
	      provided via the --syslog-target option.

       --log-file[=file]
	      Enables logging to a file.  If file is  specified,  then	it  is
	      used  as	the exact name for the log file.  The default log file
	      name   used   if	 file	 is    omitted	  is	/var/log/open-
	      vswitch/ovs-ofctl.log.

       --syslog-target=host:port
	      Send  syslog  messages  to  UDP port on host, in addition	to the
	      system syslog.  The host must be a numerical IP address,	not  a
	      hostname.

       --syslog-method=method
	      Specify method how syslog	messages should	be sent	to syslog dae-
	      mon.  Following forms are	supported:

	      	     libc, use libc syslog() function.	Downside of using this
		     options  is  that libc adds fixed prefix to every message
		     before it is actually sent	 to  the  syslog  daemon  over
		     /dev/log UNIX domain socket.

	      	     unix:file,	use UNIX domain	socket directly.  It is	possi-
		     ble to specify arbitrary message format with this option.
		     However,  rsyslogd	 8.9 and older versions	use hard coded
		     parser function anyway that  limits  UNIX	domain	socket
		     use.   If	you  want to use arbitrary message format with
		     older rsyslogd versions, then use UDP socket to localhost
		     IP	address	instead.

	      	     udp:ip:port, use UDP socket.  With	this method it is pos-
		     sible to use arbitrary message  format  also  with	 older
		     rsyslogd.	 When  sending syslog messages over UDP	socket
		     extra precaution needs to be taken	into account, for  ex-
		     ample,  syslog daemon needs to be configured to listen on
		     the specified UDP port, accidental	iptables  rules	 could
		     be	 interfering  with  local syslog traffic and there are
		     some security considerations that apply to	 UDP  sockets,
		     but do not	apply to UNIX domain sockets.

	      	     null, discards all	messages logged	to syslog.

	      The  default  is	taken  from  the OVS_SYSLOG_METHOD environment
	      variable;	if it is unset,	the default is libc.

       --color[=when]
	      Colorize the output (for some commands); when can	be never,  al-
	      ways, or auto (the default).

	      Only some	commands support output	coloring.  Color names and de-
	      fault colors may change in future	releases.

	      The environment variable OVS_COLORS can be used to specify user-
	      defined  colors  and  other attributes used to highlight various
	      parts of the output. If set, its value is	a colon-separated list
	      of	 capabilities	      that	   defaults	    to
	      ac:01;31:dr=34:le=31:pm=36:pr=35:sp=33:vl=32. Supported capabil-
	      ities  were initially designed for coloring flows	from ovs-ofctl
	      dump-flows switch	command, and they are as follows.

		     ac=01;31
			    SGR	substring for actions= keyword in a flow.  The
			    default is a bold red text foreground.

		     dr=34  SGR	substring for drop keyword.  The default is  a
			    dark blue text foreground.

		     le=31  SGR	 substring  for	learn= keyword in a flow.  The
			    default is a red text foreground.

		     pm=36  SGR	substring for flow match attribute names.  The
			    default is a cyan text foreground.

		     pr=35  SGR	substring for keywords in a flow that are fol-
			    lowed by arguments inside  parenthesis.   The  de-
			    fault is a magenta text foreground.

		     sp=33  SGR	substring for some special keywords in a flow,
			    notably: table=, priority=,	load:, output:,	move:,
			    group:,  CONTROLLER:, set_field:, resubmit:, exit.
			    The	default	is a yellow text foreground.

		     vl=32  SGR	substring for a	lone flow match	attribute with
			    no field name.  The	default	is a green text	 fore-
			    ground.

	      See the Select Graphic Rendition (SGR) section in	the documenta-
	      tion  of the text	terminal that is used for permitted values and
	      their meaning as character attributes.

       -h
       --help Prints a brief help message to the console.

       -V
       --version
	      Prints version information to the	console.

RUNTIME	MANAGEMENT COMMANDS
       ovs-appctl(8) can send commands to a running  ovs-ofctl	process.   The
       supported commands are listed below.

       exit   Causes  ovs-ofctl	to gracefully terminate.  This command applies
	      only when	executing the monitor or snoop commands.

       ofctl/set-output-file file
	      Causes all subsequent output to go to file  instead  of  stderr.
	      This  command  applies  only when	executing the monitor or snoop
	      commands.

       ofctl/send ofmsg...
	      Sends each ofmsg,	specified as a sequence	of hex digits that ex-
	      press an OpenFlow	message, on  the  OpenFlow  connection.	  This
	      command is useful	only when executing the	monitor	command.

       ofctl/packet-out	packet-out
	      Sends  an	 OpenFlow  PACKET_OUT  message specified in Packet-Out
	      Syntax, on the OpenFlow connection.  See Packet-Out Syntax  sec-
	      tion for more information.  This command is useful only when ex-
	      ecuting the monitor command.

       ofctl/barrier
	      Sends an OpenFlow	barrier	request	on the OpenFlow	connection and
	      waits  for a reply.  This	command	is useful only for the monitor
	      command.

EXAMPLES
       The following examples assume that ovs-vswitchd has a bridge named  br0
       configured.

       ovs-ofctl dump-tables br0
	      Prints  out the switch's table stats.  (This is more interesting
	      after some traffic has passed through.)

       ovs-ofctl dump-flows br0
	      Prints the flow entries in the switch.

       ovs-ofctl add-flow table=0 actions=learn(table=1,hard_timeout=10,
       NXM_OF_VLAN_TCI[0..11],output:NXM_OF_IN_PORT[]),	resubmit(,1)
	      ovs-ofctl	add-flow  table=1 priority=0 actions=flood  Implements
	      a	level 2	MAC learning switch using the learn.

       ovs-ofctl add-flow br0 'table=0,priority=0 ac-
       tions=load:3->NXM_NX_REG0[0..15],learn(table=0,priority=1,idle_time-
       out=10,NXM_OF_ETH_SRC[],NXM_OF_VLAN_TCI[0..11],out-
       put:NXM_NX_REG0[0..15]),output:2
	      In this use of a learn action, the first packet from each	source
	      MAC will be sent to port 2. Subsequent packets will be output to
	      port 3, with an idle timeout of 10 seconds.  NXM field names and
	      match  field  names  are both accepted, e.g. NXM_NX_REG0 or reg0
	      for the first register, and empty	brackets may be	omitted.

	      Additional examples may be found documented as part  of  related
	      sections.

SEE ALSO
       ovs-fields(7),	 ovs-actions(7),    ovs-appctl(8),    ovs-vswitchd(8),
       ovs-vswitchd.conf.db(8)

Open vSwitch			    2.17.12			  ovs-ofctl(8)

Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=ovs-ofctl&sektion=8&manpath=FreeBSD+Ports+14.3.quarterly>

home | help