6
6
Lists the names of the running ofproto instances. These are the names
7
7
that may be used on \fBofproto/trace\fR.
9
.IP "\fBofproto/trace \fIswitch priority tun_id in_port mark packet\fR"
10
.IQ "\fBofproto/trace \fIswitch flow \fB\-generate\fR"
11
Traces the path of an imaginary packet through \fIswitch\fR. Both
12
forms require \fIswitch\fR, the switch on which the packet arrived
13
(one of those listed by \fBofproto/list\fR). The first form specifies
14
a packet's contents explicitly:
17
Packet QoS priority. Use \fB0\fR if QoS is not setup.
19
The tunnel ID on which the packet arrived. Use
20
\fB0\fR if the packet did not arrive through a tunnel.
22
The OpenFlow port on which the packet arrived. Use \fB65534\fR if the
23
packet arrived on \fBOFPP_LOCAL\fR, the local port.
25
SKB mark of the packet. Use \fB0\fR if Netfilter marks are not used.
27
A sequence of hex digits specifying the packet's contents. An
28
Ethernet frame is at least 14 bytes long, so there must be at least 28
29
hex digits. Obviously, it is inconvenient to type in the hex digits
30
by hand, so the \fBovs\-pcap\fR(1) and \fBovs\-tcpundump\fR(1)
31
utilities provide easier ways.
34
The second form specifies the packet's contents implicitly:
37
A flow in one of two forms: either the form printed by
38
\fBovs\-dpctl\fR(8)'s \fBdump\-flows\fR command, or in a format
39
similar to that accepted by \fBovs\-ofctl\fR(8)'s \fBadd\-flow\fR
40
command. This is not an OpenFlow flow: besides other differences, it
41
never contains wildcards. \fB\*(PN\fR generates an arbitrary packet
42
that has the specified \fIflow\fR.
45
\fB\*(PN\fR will respond with extensive information on how the packet
46
would be handled if it were to be received. The packet will not
47
actually be sent, but side effects such as MAC learning will occur.
49
.IP "\fBofproto/trace \fIswitch flow\fR"
50
Traces the path of a packet in an imaginary flow through
51
\fIswitch\fR. The arguments are:
54
The switch on which the packet arrived (one of those listed by
57
A flow in one of two forms: either the form printed by
58
\fBovs\-dpctl\fR(8)'s \fBdump\-flows\fR command, or in a format
59
similar to that accepted by \fBovs\-ofctl\fR(8)'s \fBadd\-flow\fR
60
command. This is not an OpenFlow flow: besides other differences, it
61
never contains wildcards.
64
\fB\*(PN\fR will respond with extensive information on how a packet
65
in \fIflow\fR would be handled if it were received by
66
\fIswitch\fR. No packet will actually be sent. Some side effects may
67
occur, but MAC learning in particular will not.
69
This form of \fBofproto/trace\fR cannot determine the complete set of
70
datapath actions in some corner cases. If the results say that this
71
is the case, rerun \fBofproto/trace\fR supplying a packet in the flow
72
to get complete results.
9
.IP "\fBofproto/trace\fR [\fIdpname\fR] \fIodp_flow\fR [\fB\-generate \fR| \
11
.IQ "\fBofproto/trace\fR \fIbridge\fR \fIbr_flow\fR \
12
[\fB\-generate \fR| \fIpacket\fR]"
13
Traces the path of an imaginary packet through \fIswitch\fR and
14
reports the path that it took. The packet's headers (e.g. source and
15
destination) and metadata (e.g. input port), together called its
16
``flow,'' are usually all that matter for this purpose. You can
17
specify the flow in the following ways:
20
.IP "\fIdpname\fR \fIodp_flow\fR"
21
\fIodp_flow\fR is a flow in the form printed by \fBovs\-dpctl\fR(8)'s
22
\fBdump\-flows\fR command. If all of your bridges have the same type,
23
which is the common case, then you can omit \fIdpname\fR, but if you
24
have bridges of different types (say, both \fBovs-netdev\fR and
25
\fBovs-system\fR), then you need to specify a \fIdpname\fR to disambiguate.
27
.IP "\fIbridge\fR \fIbr_flow\fR"
28
\fIbr_flow\fR is a flow in the form similar to that accepted by
29
\fBovs\-ofctl\fR(8)'s \fBadd\-flow\fR command. (This is not an
30
OpenFlow flow: besides other differences, it never contains
31
wildcards.) \fIbridge\fR names of the bridge through which
32
\fIbr_flow\fR should be traced.
36
Most commonly, one specifies only a flow, using one of the forms
37
above, but sometimes one might need to specify an actual packet
38
instead of just a flow:
42
Some actions have side effects. For example, the \fBnormal\fR action
43
can update the MAC learning table, and the \fBlearn\fR action can
44
change OpenFlow tables. \fBofproto/trace\fR only performs side
45
effects when a packet is specified. If you want side effects to take
46
place, then you must supply a packet.
49
(Output actions are obviously side effects too, but
50
\fBofproto/trace\fR never executes them, even when one specifies a
53
.IP "Incomplete information."
54
Most of the time, Open vSwitch can figure out everything about the
55
path of a packet using just the flow, but in some special
56
circumstances it needs to look at parts of the packet that are not
57
included in the flow. When this is the case, and you do not supply a
58
packet, then \fBofproto/trace\fR will tell you it needs a packet.
62
If you wish to include a packet as part of the \fBofproto/trace\fR
63
operation, there are two ways to do it:
67
This option, added to one of the ways to specify a flow already
68
described, causes Open vSwitch to internally generate a packet with
69
the flow described and then to use that packet. If your goal is to
70
execute side effects, then \fB\-generate\fR is the easiest way to do
71
it, but \fB\-generate\fR is not a good way to fill in incomplete
72
information, because it generates packets based on only the flow
73
information, which means that the packets really do not have any more
74
information than the flow.
77
This form supplies an explicit \fIpacket\fR as a sequence of hex
78
digits. An Ethernet frame is at least 14 bytes long, so there must be
79
at least 28 hex digits. Obviously, it is inconvenient to type in the
80
hex digits by hand, so the \fBovs\-pcap\fR(1) and
81
\fBovs\-tcpundump\fR(1) utilities provide easier ways.
83
With this form, packet headers are extracted directly from
84
\fIpacket\fR, so the \fIodp_flow\fR or \fIbr_flow\fR should specify
85
only metadata. The metadata can be:
87
.IP \fIskb_priority\fR
90
SKB mark of the packet.
92
The tunnel ID on which the packet arrived.
94
The port on which the packet arrived.
97
The in_port value is kernel datapath port number for the first format
98
and OpenFlow port number for the second format. The numbering of these
99
two types of port usually differs and there is no relationship.
73
101
.IP "\fBofproto/self\-check\fR [\fIswitch\fR]"
74
102
Runs an internal consistency check on \fIswitch\fR, if specified,
75
103
otherwise on all ofproto instances, and responds with a brief summary
added
removed
ofproto/ofproto-unixctl.man
