2 These commands manage the core OpenFlow switch implementation (called
5 .IP "\fBofproto/list\fR"
6 Lists the names of the running ofproto instances. These are the names
7 that may be used on \fBofproto/trace\fR.
9 .IP "\fBofproto/trace \fIswitch tun_id in_port packet\fR"
10 Traces the path of an imaginary packet through \fIswitch\fR. The
14 The switch on which the packet arrived (one of those listed by
17 The tunnel ID on which the packet arrived. Use
18 \fB0\fR if the packet did not arrive through a tunnel.
20 The OpenFlow port on which the packet arrived. Use \fB65534\fR if the
21 packet arrived on \fBOFPP_LOCAL\fR, the local port.
23 A sequence of hex digits specifying the packet's contents. An
24 Ethernet frame is at least 14 bytes long, so there must be at least 28
25 hex digits. Obviously, it is inconvenient to type in the hex digits
26 by hand, so the \fBovs\-pcap\fR(1) and \fBovs\-tcpundump\fR(1)
27 utilities provide easier ways.
30 \fB\*(PN\fR will respond with extensive information on how the packet
31 would be handled if it were to be received. The packet will not
34 .IP "\fBofproto/trace \fIswitch odp_flow\fR"
35 Traces the path of a packet in an imaginary flow through
36 \fIswitch\fR. The arguments are:
39 The switch on which the packet arrived (one of those listed by
42 A flow in the form printed by \fBovs\-dpctl\fR(8)'s \fBdump\-flows\fR
43 command. This is not an OpenFlow flow: besides other differences, it
44 never contains wildcards.
47 \fB\*(PN\fR will respond with extensive information on how a packet
48 in \fIodp_flow\fR would be handled if it were received by
49 \fIswitch\fR. No packet will actually be sent.
51 This form of \fBofproto/trace\fR cannot determine the complete set of
52 datapath actions in some corner cases. If the results say that this
53 is the case, rerun \fBofproto/trace\fR supplying a packet in the flow
54 to get complete results.