The packet pipeline section documented stale table ranges and an incorrect tunnel ingress target. Align the reference with the current logical and physical pipeline layout while keeping the existing architecture scope.
Assisted-by: GPT-5.6-Luna, OpenCode Signed-off-by: Ales Musil <[email protected]> --- ovn-architecture.7.xml | 303 +++++++++++++++++++++++++---------------- 1 file changed, 185 insertions(+), 118 deletions(-) diff --git a/ovn-architecture.7.xml b/ovn-architecture.7.xml index 3d8aff08e..1fd54e59e 100644 --- a/ovn-architecture.7.xml +++ b/ovn-architecture.7.xml @@ -1263,11 +1263,13 @@ tunnel key. Ramp switch VXLAN tunnels do not transmit the logical output port field, and since they do not carry a logical output port field in the tunnel key, when a packet is received from ramp switch - VXLAN tunnel by an OVN hypervisor, the packet is resubmitted to table 8 - to determine the output port(s); when the packet reaches table 54, - these packets are resubmitted to table 56 for local delivery by - checking a MLF_RCV_FROM_RAMP flag, which is set when the packet - arrives from a ramp tunnel. + VXLAN tunnel by an OVN hypervisor, the packet is resubmitted to + <code>OFTABLE_LOG_INGRESS_PIPELINE</code> to determine the output + port(s); when the packet reaches <code>OFTABLE_REMOTE_OUTPUT</code>, + a higher-priority rule in <code>OFTABLE_REMOTE_OUTPUT</code> resubmits + these packets to <code>OFTABLE_LOCAL_OUTPUT</code> for local delivery + when the MLF_RCV_FROM_RAMP flag is set and MLF_ALLOW_LOOPBACK is clear. + MLF_RCV_FROM_RAMP is set when the packet arrives from a ramp tunnel. </p> </dd> @@ -1335,11 +1337,13 @@ <ol> <li> <p> - OpenFlow table 0 performs physical-to-logical translation. It matches + OpenFlow table <code>OFTABLE_PHY_TO_LOG</code> performs + physical-to-logical translation. It matches the packet's ingress port. Its actions annotate the packet with logical metadata, by setting the logical datapath field to identify the logical datapath that the packet is traversing and the logical input - port field to identify the ingress port. Then it resubmits to table 8 + port field to identify the ingress port. Then it resubmits to + <code>OFTABLE_LOG_INGRESS_PIPELINE</code> to enter the logical ingress pipeline. </p> @@ -1353,7 +1357,8 @@ </p> <p> - Table 0 also processes packets that arrive from other chassis. It + <code>OFTABLE_PHY_TO_LOG</code> also processes packets that arrive from + other chassis. It distinguishes them from other packets by ingress port, which is a tunnel. As with packets just entering the OVN pipeline, the actions annotate these packets with logical datapath metadata. For tunnel types @@ -1362,21 +1367,30 @@ which is available because in OVN tunneling occurs after the logical output port is known. These pieces of information are obtained from the tunnel encapsulation metadata (see <code>Tunnel - Encapsulations</code> for encoding details). Then the actions resubmit - to table 62 to enter the logical egress pipeline. + Encapsulations</code> for encoding details). For ordinary VXLAN and + other tunnel packets, the actions resubmit to + <code>OFTABLE_LOCAL_OUTPUT</code> to deliver them + to the local hypervisor. Ramp switch VXLAN packets are an exception: + because they do not carry the logical output port field, + the actions resubmit them to <code>OFTABLE_LOG_INGRESS_PIPELINE</code> + to determine the logical output port before delivering them locally. </p> </li> <li> <p> - OpenFlow tables 8 through 41 execute the logical ingress pipeline from + OpenFlow tables starting at <code>OFTABLE_LOG_INGRESS_PIPELINE</code> + execute the logical ingress pipeline from the <code>Logical_Flow</code> table in the OVN Southbound database. These tables are expressed entirely in terms of logical concepts like logical ports and logical datapaths. A big part of <code>ovn-controller</code>'s job is to translate them into equivalent - OpenFlow (in particular it translates the table numbers: - <code>Logical_Flow</code> tables 0 through 33 become OpenFlow tables 8 - through 41). + OpenFlow. The logical switch ingress stages run from + <code>ls_in_check_port_sec</code> through + <code>ls_in_l2_unknown</code>, while the logical router ingress stages + run from <code>lr_in_admission</code> through + <code>lr_in_ecmp_stateful_egr</code>. Both are translated to OpenFlow + tables starting at <code>OFTABLE_LOG_INGRESS_PIPELINE</code>. </p> <p> @@ -1418,9 +1432,11 @@ <dl> <dt><code>output:</code></dt> <dd> - Implemented by resubmitting the packet to table 52. If the pipeline + Implemented by resubmitting the packet to + <code>OFTABLE_OUTPUT_LARGE_PKT_DETECT</code>. If the pipeline executes more than one <code>output</code> action, then each one is - separately resubmitted to table 52. This can be used to send + separately resubmitted to <code>OFTABLE_OUTPUT_LARGE_PKT_DETECT</code>. + This can be used to send multiple copies of the packet to multiple ports. (If the packet was not modified between the <code>output</code> actions, and some of the copies are destined to the same hypervisor, then using a logical @@ -1432,11 +1448,12 @@ <dd> <p> Implemented by storing arguments into OpenFlow fields, then - resubmitting to table 90, which <code>ovn-controller</code> + resubmitting to <code>OFTABLE_MAC_BINDING</code>, which + <code>ovn-controller</code> populates with flows generated from the <code>MAC_Binding</code> - table in the OVN Southbound database. If there is a match in table - 90, then its actions store the bound MAC in the Ethernet - destination address field. + table in the OVN Southbound database. If there is a match in + <code>OFTABLE_MAC_BINDING</code>, then its actions store the bound + MAC in the Ethernet destination address field. </p> <p> @@ -1467,10 +1484,12 @@ <dd> <p> Implemented by storing arguments into OpenFlow fields, then - resubmitting to table 91, which <code>ovn-controller</code> + resubmitting to <code>OFTABLE_MAC_LOOKUP</code>, which + <code>ovn-controller</code> populates with flows generated from the <code>MAC_Binding</code> - table in the OVN Southbound database. If there is a match in table - 91, then its actions set the logical flow flag + table in the OVN Southbound database. If there is a match in + <code>OFTABLE_MAC_LOOKUP</code>, then its actions set the logical + flow flag <code>MLF_LOOKUP_MAC</code>. </p> @@ -1485,116 +1504,146 @@ <li> <p> - OpenFlow tables 52 through 57 implement the <code>output</code> action - in the logical ingress pipeline. Specifically, table 52 serves as an - entry point to egress pipeline. Table 52 detects IP packets that are - too big for a corresponding interface. Table 53 produces ICMPv4 - Fragmentation Needed (or ICMPv6 Too Big) errors and deliver them back - to the offending port. Table 54 handles packets to remote hypervisors, - table 56 handles packets to the local hypervisor, and table 57 checks - whether packets whose logical ingress and egress port are the same - should be discarded. + OpenFlow tables from <code>OFTABLE_OUTPUT_LARGE_PKT_DETECT</code> + through <code>OFTABLE_CHECK_LOOPBACK</code> implement the + <code>output</code> action + in the logical ingress pipeline. Specifically, + <code>OFTABLE_OUTPUT_LARGE_PKT_DETECT</code> serves as an + entry point to egress pipeline and detects IP packets that are + too big for a corresponding interface. + <code>OFTABLE_OUTPUT_LARGE_PKT_PROCESS</code> produces ICMPv4 + Fragmentation Needed (or ICMPv6 Too Big) errors and delivers them back + to the offending port. <code>OFTABLE_REMOTE_OUTPUT</code> handles + packets to remote hypervisors, <code>OFTABLE_REMOTE_VTEP_OUTPUT</code> + handles packets to remote VTEPs, <code>OFTABLE_LOCAL_OUTPUT</code> + handles packets to the local hypervisor, and + <code>OFTABLE_CHECK_LOOPBACK</code> checks whether + packets whose logical ingress and egress port are the same should be + discarded. </p> <p> Logical patch ports are a special case. Logical patch ports do not have a physical location and effectively reside on every hypervisor. - Thus, flow table 56, for output to ports on the local hypervisor, + Thus, flow table <code>OFTABLE_LOCAL_OUTPUT</code>, for output to ports + on the local hypervisor, naturally implements output to unicast logical patch ports too. However, applying the same logic to a logical patch port that is part of a logical multicast group yields packet duplication, because each hypervisor that contains a logical port in the multicast group will also output the packet to the logical patch port. Thus, multicast - groups implement output to logical patch ports in table 54. + groups implement output to logical patch ports in + <code>OFTABLE_REMOTE_OUTPUT</code>. </p> <p> - Each flow in table 54 matches on a logical output port for unicast or + Each flow in <code>OFTABLE_REMOTE_OUTPUT</code> matches on a logical + output port for unicast or multicast logical ports that include a logical port on a remote hypervisor. Each flow's actions implement sending a packet to the port it matches. For unicast logical output ports on remote hypervisors, the actions set the tunnel key to the correct value, then send the packet on the tunnel port to the correct hypervisor. (When the remote - hypervisor receives the packet, table 0 there will recognize it as a - tunneled packet and pass it along to table 56.) For multicast logical + hypervisor receives the packet, <code>OFTABLE_PHY_TO_LOG</code> there + will recognize it as a tunneled packet and pass it along to + <code>OFTABLE_LOCAL_OUTPUT</code>.) For multicast logical output ports, the actions send one copy of the packet to each remote hypervisor, in the same way as for unicast destinations. If a multicast group includes a logical port or ports on the local - hypervisor, then its actions also resubmit to table 56. Table 54 also - includes: + hypervisor, then its actions also resubmit to + <code>OFTABLE_LOCAL_OUTPUT</code>. + <code>OFTABLE_REMOTE_OUTPUT</code> also includes: </p> <ul> <li> A higher-priority rule to match packets received from ramp switch - tunnels, based on flag MLF_RCV_FROM_RAMP, and resubmit these packets - to table 56 for local delivery. Packets received from ramp switch - tunnels reach here because of a lack of logical output port field in - the tunnel key and thus these packets needed to be submitted to table - 8 to determine the output port. + tunnels, based on flag MLF_RCV_FROM_RAMP, when MLF_ALLOW_LOOPBACK is + clear, and resubmit these packets to + <code>OFTABLE_LOCAL_OUTPUT</code> for local delivery. Packets + received from ramp switch tunnels reach here because of a lack of + logical output port field in the tunnel key and thus these packets + needed to be submitted to <code>OFTABLE_LOG_INGRESS_PIPELINE</code> + to determine the output port. </li> <li> A higher-priority rule to match packets received from ports of type <code>localport</code>, based on the logical input port, and resubmit - these packets to table 56 for local delivery. Ports of type - <code>localport</code> exist on every hypervisor and by definition - their traffic should never go out through a tunnel. + these packets to <code>OFTABLE_LOCAL_OUTPUT</code> for local + delivery. Ports of type <code>localport</code> exist on every + hypervisor and by definition their traffic should never go out + through a tunnel. </li> <li> A higher-priority rule to match packets that have the MLF_LOCAL_ONLY - logical flow flag set, and whose destination is a multicast address. - This flag indicates that the packet should not be delivered to remote - hypervisors, even if the multicast destination includes ports on - remote hypervisors. This flag is used when - <code>ovn-controller</code> is the originator of the multicast packet. - Since each <code>ovn-controller</code> instance is originating these - packets, the packets only need to be delivered to local ports. + logical flow flag set. This flag indicates that the packet should + not be delivered to remote hypervisors, even if a multicast + destination includes ports on remote hypervisors. This flag is used + when + <code>ovn-controller</code> is the originator of the multicast + packet. Since each <code>ovn-controller</code> instance is + originating these packets, the packets only need to be delivered to + local ports. </li> <li> - A fallback flow that resubmits to table 56 if there is no other - match. + A fallback flow that resubmits to + <code>OFTABLE_REMOTE_VTEP_OUTPUT</code> if there is no other match. </li> </ul> <p> - Flows in table 56 resemble those in table 54 but for logical ports that + <code>OFTABLE_REMOTE_VTEP_OUTPUT</code> handles output to remote VTEPs. + Matching + flows set the tunnel metadata and output the packet through the + appropriate tunnel. A fallback flow resubmits packets that are not + directed to a remote VTEP to <code>OFTABLE_LOCAL_OUTPUT</code>. + </p> + + <p> + Flows in <code>OFTABLE_LOCAL_OUTPUT</code> resemble those in + <code>OFTABLE_REMOTE_OUTPUT</code> but for logical ports that reside locally rather than remotely. For unicast logical output ports - on the local hypervisor, the actions just resubmit to table 57. For + on the local hypervisor, the actions just resubmit to + <code>OFTABLE_CHECK_LOOPBACK</code>. For multicast output ports that include one or more logical ports on the local hypervisor, for each such logical port <var>P</var>, the actions - change the logical output port to <var>P</var>, then resubmit to table - 57. + change the logical output port to <var>P</var>, then resubmit to + <code>OFTABLE_CHECK_LOOPBACK</code>. </p> <p> A special case is that when a localnet port exists on the datapath, remote port is connected by switching to the localnet port. In this - case, instead of adding a flow in table 54 to reach the remote port, a - flow is added in table 56 to switch the logical outport to the localnet - port, and resubmit to table 56 as if it were unicasted to a logical - port on the local hypervisor. + case, instead of adding a flow in <code>OFTABLE_REMOTE_OUTPUT</code> to + reach the remote port, a flow is added in + <code>OFTABLE_LOCAL_OUTPUT</code> to switch the logical outport to the + localnet port, and resubmit to <code>OFTABLE_LOCAL_OUTPUT</code> as if + it were unicasted to a logical port on the local hypervisor. </p> <p> - Table 57 matches and drops packets for which the logical input and + <code>OFTABLE_CHECK_LOOPBACK</code> matches and drops packets for which + the logical input and output ports are the same and the MLF_ALLOW_LOOPBACK flag is not set. It also drops MLF_LOCAL_ONLY packets directed to a localnet port, provided they aren't RAs sent from a gateway or distributed router which is checked via the presence of the bitflag - MLF_OVERRIDE_LOCAL_ONLY. It resubmits other packets to table 62. + MLF_OVERRIDE_LOCAL_ONLY. It resubmits other packets to + <code>OFTABLE_LOG_EGRESS_PIPELINE</code>. </p> </li> <li> <p> - OpenFlow tables 62 through 77 execute the logical egress pipeline from + OpenFlow tables starting at <code>OFTABLE_LOG_EGRESS_PIPELINE</code> + execute the logical egress pipeline from the <code>Logical_Flow</code> table in the OVN Southbound database. The egress pipeline can perform a final stage of validation before packet delivery. Eventually, it may execute an <code>output</code> action, which <code>ovn-controller</code> implements by resubmitting to - table 88. A packet for which the pipeline never executes - <code>output</code> is effectively dropped (although it may have been - transmitted through a tunnel across a physical network). + <code>OFTABLE_SAVE_INPORT</code>. A packet for which the pipeline + never executes <code>output</code> is effectively dropped (although it + may have been transmitted through a tunnel across a physical network). </p> <p> @@ -1605,22 +1654,26 @@ <li> <p> - Table 88 bypasses OpenFlow loopback when MLF_ALLOW_LOOPBACK is set. - Logical loopback was handled in table 57, but OpenFlow by default also + <code>OFTABLE_SAVE_INPORT</code> bypasses OpenFlow loopback when + MLF_ALLOW_LOOPBACK is set. Logical loopback was handled in + <code>OFTABLE_CHECK_LOOPBACK</code>, but OpenFlow by default also prevents loopback to the OpenFlow ingress port. Thus, when - MLF_ALLOW_LOOPBACK is set, OpenFlow table 88 saves the OpenFlow ingress - port, sets it to zero, resubmits to table 89 for logical-to-physical - transformation, and then restores the OpenFlow ingress port, - effectively disabling OpenFlow loopback prevents. When - MLF_ALLOW_LOOPBACK is unset, table 88 flow simply resubmits to table - 89. + MLF_ALLOW_LOOPBACK is set, OpenFlow table + <code>OFTABLE_SAVE_INPORT</code> saves the OpenFlow ingress port, sets + it to zero, resubmits to <code>OFTABLE_LOG_TO_PHY</code> for + logical-to-physical transformation, and then restores the OpenFlow + ingress port, effectively disabling OpenFlow loopback prevention. When + MLF_ALLOW_LOOPBACK is unset, the <code>OFTABLE_SAVE_INPORT</code> flow + simply resubmits to <code>OFTABLE_LOG_TO_PHY</code>. </p> </li> <li> <p> - OpenFlow table 89 performs logical-to-physical translation, the - opposite of table 0. It matches the packet's logical egress port. Its + OpenFlow table <code>OFTABLE_LOG_TO_PHY</code> performs + logical-to-physical translation, the opposite of + <code>OFTABLE_PHY_TO_LOG</code>. It matches the packet's logical + egress port. Its actions output the packet to the port attached to the OVN integration bridge that represents that logical port. If the logical egress port is a container nested with a VM, then before sending the packet the @@ -1641,44 +1694,54 @@ <p> Consider a packet sent from one virtual machine or container to another VM or container that resides on a different subnet. The packet will - traverse tables 0 to 89 as described in the previous section + traverse <code>OFTABLE_PHY_TO_LOG</code> through + <code>OFTABLE_LOG_TO_PHY</code> as described in the previous section <code>Architectural Physical Life Cycle of a Packet</code>, using the logical datapath representing the logical switch that the sender is - attached to. At table 54, the packet will use the fallback flow that - resubmits locally to table 56 on the same hypervisor. In this case, - all of the processing from table 0 to table 89 occurs on the hypervisor - where the sender resides. + attached to. At <code>OFTABLE_REMOTE_OUTPUT</code>, the packet will use + the fallback flow that resubmits to + <code>OFTABLE_REMOTE_VTEP_OUTPUT</code>. Its fallback flow then resubmits + locally to <code>OFTABLE_LOCAL_OUTPUT</code> on the same hypervisor. In + this case, all of the processing from <code>OFTABLE_PHY_TO_LOG</code> to + <code>OFTABLE_LOG_TO_PHY</code> occurs on the hypervisor where the sender + resides. </p> <p> - When the packet reaches table 89, the logical egress port is a - logical patch port. <code>ovn-controller</code> implements output - to the logical patch is packet by cloning and resubmitting + When the packet reaches <code>OFTABLE_LOG_TO_PHY</code>, the logical egress + port is a logical patch port. <code>ovn-controller</code> implements + output to the logical patch port by cloning and resubmitting the packet directly to the first OpenFlow flow table in the ingress pipeline, - setting the logical ingress port to the peer logical patch port, - and using the peer logical patch port's logical datapath (that - represents the logical router). - </p> - - <p> - The packet re-enters the ingress pipeline in order to traverse tables - 8 to 89 again, this time using the logical datapath representing the - logical router. The processing continues as described in the previous - section <code>Architectural Physical Life Cycle of a Packet</code>. - When the packet reaches table 89, the logical egress port will once - again be a logical patch port. In the same manner as described above, - this logical patch port will cause the packet to be resubmitted to - OpenFlow tables 8 to 89, this time using the logical datapath + setting the logical ingress port to the peer logical patch port, and using + the peer logical patch port's logical datapath (that represents the logical + router). + </p> + + <p> + The packet re-enters the ingress pipeline in order to traverse OpenFlow + tables from <code>OFTABLE_LOG_INGRESS_PIPELINE</code> to + <code>OFTABLE_LOG_TO_PHY</code> again, this time using the logical datapath + representing the logical router. The processing continues as described in + the previous section <code>Architectural Physical Life Cycle of a + Packet</code>. + When the packet reaches <code>OFTABLE_LOG_TO_PHY</code>, the logical egress + port will once again be a logical patch port. In the same manner as + described above, this logical patch port will cause the packet to be + resubmitted to OpenFlow tables from + <code>OFTABLE_LOG_INGRESS_PIPELINE</code> to + <code>OFTABLE_LOG_TO_PHY</code>, this time using the logical datapath representing the logical switch that the destination VM or container is attached to. </p> <p> - The packet traverses tables 8 to 89 a third and final time. If the - destination VM or container resides on a remote hypervisor, then table - 54 will send the packet on a tunnel port from the sender's hypervisor - to the remote hypervisor. Finally table 89 will output the packet - directly to the destination VM or container. + The packet traverses from <code>OFTABLE_LOG_INGRESS_PIPELINE</code> to + <code>OFTABLE_LOG_TO_PHY</code> a third and final time. If the + destination VM or container resides on a remote hypervisor, then + <code>OFTABLE_REMOTE_OUTPUT</code> will send the packet on a tunnel port + from the sender's hypervisor to the remote hypervisor. Finally + <code>OFTABLE_LOG_TO_PHY</code> will output the packet directly to the + destination VM or container. </p> <p> @@ -1703,9 +1766,11 @@ When a hypervisor processes a packet on a logical datapath representing a logical switch, and the logical egress port is a <code>l3gateway</code> port representing connectivity to a gateway - router, the packet will match a flow in table 54 that sends the + router, the packet will match a flow in <code>OFTABLE_REMOTE_OUTPUT</code> + that sends the packet on a tunnel port to the chassis where the gateway router - resides. This processing in table 54 is done in the same manner as + resides. This processing in <code>OFTABLE_REMOTE_OUTPUT</code> is done in + the same manner as for VIFs. </p> @@ -1798,21 +1863,22 @@ chassis, one additional mechanism is required. When a packet leaves the ingress pipeline and the logical egress port is the distributed gateway port, one of two different sets of actions is - required at table 54: + required at <code>OFTABLE_REMOTE_OUTPUT</code>: </p> <ul> <li> If the packet can be handled locally on the sender's hypervisor (e.g. one-to-one NAT traffic), then the packet should just be - resubmitted locally to table 56, in the normal manner for - distributed logical patch ports. + resubmitted locally to <code>OFTABLE_LOCAL_OUTPUT</code>, in the normal + manner for distributed logical patch ports. </li> <li> However, if the packet needs to be handled on the chassis associated with the distributed gateway port (e.g. one-to-many - SNAT traffic or non-NAT traffic), then table 54 must send the + SNAT traffic or non-NAT traffic), then <code>OFTABLE_REMOTE_OUTPUT</code> + must send the packet on a tunnel port to that chassis. </li> </ul> @@ -1824,13 +1890,14 @@ egress port to the type <code>chassisredirect</code> logical port is simply a way to indicate that although the packet is destined for the distributed gateway port, it needs to be redirected to a - different chassis. At table 54, packets with this logical egress - port are sent to a specific chassis, in the same way that table 54 + different chassis. At <code>OFTABLE_REMOTE_OUTPUT</code>, packets with + this logical egress port are sent to a specific chassis, in the same way + that <code>OFTABLE_REMOTE_OUTPUT</code> directs packets whose logical egress port is a VIF or a type <code>l3gateway</code> port to different chassis. Once the packet - arrives at that chassis, table 56 resets the logical egress port to - the value representing the distributed gateway port. For each - distributed gateway port, there is one type + arrives at that chassis, <code>OFTABLE_LOCAL_OUTPUT</code> resets the + logical egress port to the value representing the distributed gateway port. + For each distributed gateway port, there is one type <code>chassisredirect</code> port, in addition to the distributed logical patch port representing the distributed gateway port. </p> -- 2.55.0 _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
