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, unless the weighted group buck-
	      ets cannot be mapped to a	maximum	of 64 dp_hash values with suf-
	      ficient  accuracy.   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.

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

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

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

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

	      o	     OpenFlow11, for OpenFlow 1.1.

	      o	     OpenFlow12, for OpenFlow 1.2.

	      o	     OpenFlow13, for OpenFlow 1.3.

	      o	     OpenFlow14, for OpenFlow 1.4.

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

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

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

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

	      o	     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).

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

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

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

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

	      o	     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.16.0			  ovs-ofctl(8)

NAME | SYNOPSIS | DESCRIPTION | OPTIONS | RUNTIME MANAGEMENT COMMANDS | EXAMPLES | SEE ALSO

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

home | help