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:/usr/local/var/run/open‐
                     vswitch/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.

       ct-flush switch [zone=N] [mark=X[/M]] [labels=Y[/N]] [ct-orig-tuple
       [ct-reply-tuple]]
              Flushes  the  connection  entries on switch based on zone, mark,
              labels and connection tracking tuples ct-[orig|reply]-tuple.

              If ct-[orig|reply]-tuple is not provided, flushes all  the  con‐
              nection entries.  If zone is specified, only flushes the connec‐
              tions in zone. if mark or labels is provided, it will flush only
              entries that are matching specific mark/labels.

              If ct-[orig|reply]-tuple is provided, flushes the connection en‐
              try  specified  by  ct-[orig|reply]-tuple in zone.  The zone de‐
              faults to 0 if it is not provided.  The mark and labels defaults
              to "0/0" if  it  is  not  provided.   The  userspace  connection
              tracker  requires flushing with the original pre-NATed tuple and
              a warning log will be otherwise generated.   The  tuple  can  be
              partial and will remove all connections that are matching on the
              specified fields.  In order to specify only ct-reply-tuple, pro‐
              vide empty string as ct-orig-tuple.

              Note: Currently there is limitation for matching on ICMP, in or‐
              der  to  partially  match  on  ICMP  parameters the ct-[orig|re‐
              ply]-tuple has to include either source or destination IP.

              An example of an IPv4 ICMP ct-[orig|reply]-tuple:

              "ct_nw_src=10.1.1.1,ct_nw_dst=10.1.1.2,ct_nw_proto=1,icmp_type=8,icmp_code=0,icmp_id=10"

              An example of an IPv6 TCP ct-[orig|reply]-tuple:

              "ct_ipv6_src=fc00::1,ct_ipv6_dst=fc00::2,ct_nw_proto=6,ct_tp_src=1,ct_tp_dst=2"

              This command uses an Open vSwitch extension that is only in Open
              vSwitch 3.1 and later.  Support for matching on mark and  labels
              is only in Open vSwitch 3.3 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 transaction, 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 transaction, 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 /usr/local/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).

              out_group=group
                     If set, only flows that output to group number are  moni‐
                     tored.   This  field requires OpenFlow 1.4 (-OOpenFlow14)
                     or later.

              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   across   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 /usr/local/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   /usr/local/var/run/openvswitch.    If
              --unixctl  is  not  used  at all, the default socket is /usr/lo‐
              cal/var/run/openvswitch/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  /usr/local/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                         3.4.0                        ovs-ofctl(8)