ovn-trace supports the three different forms of output, each
described in a separate section below. Regardless of the selected
output format, ovn-trace starts the output with a line that shows
the microflow being traced in OpenFlow syntax.
Detailed Output
The detailed form of output is also the default form. This form
groups output into sections headed up by the ingress or egress
pipeline being traversed. Each pipeline lists each table that was
visited (by number and name), the ovn-northd source file and line
number of the code that added the flow, the match expression and
priority of the logical flow that was matched, and the actions
that were executed.
The execution of OVN logical actions naturally forms a ``control
stack'' that resembles that of a program in conventional
programming languages such as C or Java. Because the next action
that calls into another logical flow table for a lookup is a
recursive construct, OVN ``programs'' in practice tend to form
deep control stacks that, displayed in the obvious way using
additional indentation for each level, quickly use up the
horizontal space on all but the widest displays. To make detailed
output more readable, without loss of generality, ovn-trace omits
indentation for ``tail recursion,'' that is, when next is the
last action in a logical flow, it does not indent details of the
next table lookup more deeply. Output still uses indentation when
it is needed for clarity.
OVN ``programs'' traces also tend to encounter long strings of
logical flows with match expression 1 (which matches every
packet) and the single action next;. These are uninteresting and
merely clutter output, so ovn-trace omits them entirely even from
detailed output.
The following excerpt from detailed ovn-trace output shows a
section for a packet traversing the ingress pipeline of logical
datapath ls1 with ingress logical port lp111. The packet matches
a logical flow in table 0 (aka ls_in_port_sec_l2) with priority
50 and executes next(1); to pass to table 1. Tables 1 through 11
are trivial and omitted. In table 12 (aka ls_in_l2_lkup), the
packet matches a flow with priority 50 based on its Ethernet
destination address and the flow's actions output the packet to
the lrp11-attachement logical port.
ingress(dp="ls1", inport="lp111")
---------------------------------
0. ls_in_port_sec_l2: inport == "lp111", priority 50
next(1);
12. ls_in_l2_lkup: eth.dst == 00:00:00:00:ff:11, priority 50
outport = "lrp11-attachment";
output;
Summary Output
Summary output includes the logical pipelines visited by a packet
and the logical actions executed on it. Compared to the detailed
output, however, it removes details of tables and logical flows
traversed by a packet. It uses a format closer to that of a
programming language and does not attempt to avoid indentation.
The summary output equivalent to the above detailed output
fragment is:
ingress(dp="ls1", inport="lp111") {
outport = "lrp11-attachment";
output;
...
};
Minimal Output
Minimal output includes only actions that modify packet data (not
including OVN registers or metadata such as outport) and output
actions that actually deliver a packet to a logical port
(excluding patch ports). The operands of actions that modify
packet data are displayed reduced to constants, e.g. ip4.dst =
reg0; might be show as ip4.dst = 192.168.0.1; if that was the
value actually loaded. This yields output even simpler than the
summary format. (Users familiar with Open vSwitch may recognize
this as similar in spirit to the datapath actions listed at the
bottom of ofproto/trace output.)
The minimal output format reflects the externally seen behavior
of the logical networks more than it does the implementation.
This makes this output format the most suitable for use in
regression tests, because it is least likely to change when
logical flow tables are rearranged without semantic change.
