  OFPROTO COMMANDS
These commands manage the core OpenFlow switch implementation (called ofproto).

ofproto/list
    Lists the names of the running ofproto instances. These are the names that may be used on ofproto/trace.

ofproto/trace [dpname] odp_flow [-generate | packet]
    Traces the path of an imaginary packet through switch and reports the path that it took. The packet's headers (e.g. source and destination) and metadata (e.g. input port), together called its ``flow,'' are usually all that matter for this purpose. You can specify the flow in the following ways:

    dpname odp_flow
        odp_flow is a flow in the form printed by ovs-dpctl(8)'s dump-flows command. If all of your bridges have the same type, which is the common case, then you can omit dpname, but if you have bridges of different types (say, both ovs-netdev and ovs-system), then you need to specify a dpname to disambiguate.

    bridge br_flow
        br_flow is a flow in the form similar to that accepted by ovs-ofctl(8)'s add-flow command. (This is not an OpenFlow flow: besides other differences, it never contains wildcards.) bridge names of the bridge through which br_flow should be traced.

    Most commonly, one specifies only a flow, using one of the forms above, but sometimes one might need to specify an actual packet instead of just a flow:

    Side effects.
        Some actions have side effects. For example, the normal action can update the MAC learning table, and the learn action can change OpenFlow tables. ofproto/trace only performs side effects when a packet is specified. If you want side effects to take place, then you must supply a packet.

        (Output actions are obviously side effects too, but ofproto/trace never executes them, even when one specifies a packet.)

    Incomplete information.
        Most of the time, Open vSwitch can figure out everything about the path of a packet using just the flow, but in some special circumstances it needs to look at parts of the packet that are not included in the flow. When this is the case, and you do not supply a packet, then ofproto/trace will tell you it needs a packet.

    If you wish to include a packet as part of the ofproto/trace operation, there are two ways to do it:

    -generate
        This option, added to one of the ways to specify a flow already described, causes Open vSwitch to internally generate a packet with the flow described and then to use that packet. If your goal is to execute side effects, then -generate is the easiest way to do it, but -generate is not a good way to fill in incomplete information, because it generates packets based on only the flow information, which means that the packets really do not have any more information than the flow.

    packet
        This form supplies an explicit packet as a sequence of hex digits. An Ethernet frame is at least 14 bytes long, so there must be at least 28 hex digits. Obviously, it is inconvenient to type in the hex digits by hand, so the ovs-pcap(1) and ovs-tcpundump(1) utilities provide easier ways.

        With this form, packet headers are extracted directly from packet, so the odp_flow or br_flow should specify only metadata. The metadata can be:

        skb_priority
            Packet QoS priority.

        pkt_mark
            Mark of the packet.

        tun_id
            The tunnel ID on which the packet arrived.

        in_port
            The port on which the packet arrived.
    The in_port value is kernel datapath port number for the first format and OpenFlow port number for the second format. The numbering of these two types of port usually differs and there is no relationship.

ofproto/self-check [switch]
    Runs an internal consistency check on switch, if specified, otherwise on all ofproto instances, and responds with a brief summary of the results. If the summary reports any errors, then the Open vSwitch logs should contain more detailed information. Please pass along errors reported by this command to the Open vSwitch developers as bugs.