diff --git a/docs/design/ovs-pipeline.md b/docs/design/ovs-pipeline.md index cb1ce80451e..ba15c294136 100644 --- a/docs/design/ovs-pipeline.md +++ b/docs/design/ovs-pipeline.md @@ -1138,7 +1138,7 @@ It is worth noting that some bits of ct mark are persisted: - `ServiceCTMark`, to be consumed in tables [L3Forwarding] and [ConntrackCommit], indicating that the current packet and subsequent packets of the connection is for a Service. -- The value of `PktSourceField`is persisted to `ConnSourceCTMarkField`, storing the source of the connection for the +- The value of `PktSourceField` is persisted to `ConnSourceCTMarkField`, storing the source of the connection for the current packet and subsequent packets of the connection. ### AntreaPolicyEgressRule @@ -1189,10 +1189,10 @@ NetworkPolicy is updated. Flows 3-6, whose priorities are all 44900, are installed for the egress rule `AllowToDb` in the sample policy. These flows are described as follows: -- Flow 3 is utilized to match packets with the source IP address in set {10.10.0.24}, which is from the Pods selected - by label `app: web`, constituting the first dimension for `conjunction` with `conj_id` 8. -- Flow 4 is utilized to match packets with the destination IP address in set {10.10.0.25}, which is from the Pods - selected by label `app: db`, constituting the second dimension for `conjunction` with `conj_id` 8. +- Flow 3 is utilized to match packets with the source IP address in set {10.10.0.24}, which has all IP addresses of + the Pods selected by label `app: web`, constituting the first dimension for `conjunction` with `conj_id` 8. +- Flow 4 is utilized to match packets with the destination IP address in set {10.10.0.25}, which has all IP addresses of + the Pods selected by label `app: db`, constituting the second dimension for `conjunction` with `conj_id` 8. - Flow 5 is utilized to match packets with the destination TCP port in set {3306} specified in the rule, constituting the third dimension for `conjunction` with `conj_id` 8. - Flow 6 is utilized to match packets meeting all the three dimensions of `conjunction` with `conj_id` 8 and forward @@ -1205,8 +1205,7 @@ as-is, and there is no need for a table [AntreaPolicyEgressDefault]. These flows - Flow 7 is utilized to match packets with the source IP address in set {10.10.0.24}, which is from the Pods selected by label `app: web`, constituting the first dimension for `conjunction` with `conj_id` 5. -- Flow 8 is utilized to match packets with any destination IP address or any destination port, constituting the - second dimension for `conjunction` with `conj_id` 5. +- Flow 8 is utilized to match any packets, constituting the second dimension for `conjunction` with `conj_id` 5. - Flow 9 is utilized to match packets meeting both dimensions of `conjunction` with `conj_id` 5. `APDenyRegMark`, which will be consumed in table [EgressMetric] to which the packets are forwarded, is loaded. @@ -1230,10 +1229,10 @@ table, you may see the following: Flows 1-4 are installed for egress rule in the sample Kubernetes NetworkPolicy. These flows are described as follows: -- Flow 1 is utilized to match packets with the source IP address in set {10.10.0.24}, which is from the Pods selected - by label `app: web`, constituting the first dimension for `conjunction` with `conj_id` 2. -- Flow 2 is utilized to match packets with the destination IP address in set {10.10.0.25}, which is from the Pods - selected by label `app: db`, constituting the second dimension for `conjunction` with `conj_id` 2. +- Flow 1 is utilized to match packets with the source IP address in set {10.10.0.24}, which has all IP addresses of the + Pods selected by label `app: web`, constituting the first dimension for `conjunction` with `conj_id` 2. +- Flow 2 is utilized to match packets with the destination IP address in set {10.10.0.25}, which has all IP addresses of + the Pods selected by label `app: db`, constituting the second dimension for `conjunction` with `conj_id` 2. - Flow 3 is utilized to match packets with the destination TCP port in set {3306} specified in the rule, constituting the third dimension for `conjunction` with `conj_id` 2. - Flow 4 is utilized to match packets meeting all the three dimensions of `conjunction` with `conj_id` 2 and forward @@ -1256,7 +1255,7 @@ If you dump the flows for this table, you may see the following: 2. table=EgressDefaultRule, priority=0 actions=goto_table:EgressMetric ``` -Flow 1, based on our sample Kubernetes NetworkPolicy, is to drop traffic originating from 10.10.0.24, an IP address +Flow 1, based on our sample Kubernetes NetworkPolicy, is to drop traffic originated from 10.10.0.24, an IP address associated with Pods selected by label `app: web`. Flow 2 is table-miss flow to forwards packets to table [EgressMetric]. @@ -1281,12 +1280,20 @@ If you dump the flows for this table, you may see the following: 6. table=EgressMetric, priority=0 actions=goto_table:L3Forwarding ``` -Flows 1-2, matching packets with `EgressRuleCTLabel` is 2 (the `conj_id` is for the egress rule `AllowToDb` in the sample -Antrea-native NetworkPolicy) which is loaded in table [EgressRule] flow 4, forwards the packets to table [L3Forwarding]. +Flows 1-2, matching packets with `EgressRuleCTLabel` set to 2, the `conj_id` allocated for the sample Kubernetes +NetworkPolicy egress rule and loaded in table [EgressRule] flow 4, are utilized to collect metrics for the egress rule. -Flows 1-2 match packets with `EgressRuleCTLabel` set to 2 (corresponding to the `conj_id` for the egress rule `AllowToDb` -in the sample Antrea-native NetworkPolicy, loaded in in flow 4 of table [EgressRule]), and then forwards them to table -[L3Forwarding]. +Flows 3-4, matching packets with `EgressRuleCTLabel` set to 7, the `conj_id` allocated for the sample Antrea-native +NetworkPolicy egress rule and loaded in table [EgressRule] flow 6, are utilized to collect metrics for the egress rule. + +Flow 5 serves as the default drop rule for the sample Antrea-native NetworkPolicy egress rule. It drops the packets with +`APDenyRegMark` loaded in table [AntreaPolicyEgressRule] flow 9, and `APConjIDField` set to 5, the `conj_id` allocated +the egress rule and loaded in table [AntreaPolicyEgressRule] flow 9. + +It's worth noting that ct label is used in flows 1-4, while reg is used in flow 5. The distinction lies in the fact that +value persisted in ct label can be read throughout the entire lifecycle of a connection, but reg mark is only valid for +the current packet. For a connection permitted by a rule, all its packets should be collected for metrics, thus a ct +label is used. For a connection denied or dropped by a rule, the first packet will be blocked, therefore a reg is enough. ### L3Forwarding @@ -1603,19 +1610,19 @@ If you dump the flows for this table, you should see the following: Flow 1 matches locally generated request packets, identified by `pkt_mark` which is set by iptables in the host network namespace. It forwards the packets to table [ConntrackCommit] directly to bypass all tables for ingress security. -Flow 2 matches packets towards to NodePort Services and forwards them to table [AntreaPolicyIngressRule], avoiding that -packets traversed the Antrea gateway and destined to NodePort Services are matched by flow +Flow 2 matches packets destined to NodePort Services and forwards them to table [AntreaPolicyIngressRule] to enforce +Antrea-native NetworkPolicies applied to NodePort Services. Without this flow, if the selected Endpoint is not a local +Pod, the packets might be matched by one in flows 3-5, skipping table [AntreaPolicyIngressRule]. -- Flow 3-5 are to match some packets destined to the local Antrea gateway, tunnel, uplink port by matching `ToGatewayRegMark`, - `ToTunnelRegMark` or `ToUplinkRegMark` respectively and forward them - to table [IngressMetric] directly to bypass tables for ingress security rules. - - Match condition `reg0=0x20/0xf0` is to match `ToGatewayRegMark`, indicating that packets are destined to local - Antrea gateway. - - Match condition `reg0=0x10/0xf0` is to match `ToTunnelRegMark`, indicating that packets are destined to tunnel. - - Match condition `reg0=0x40/0xf0` is to match `ToUplinkRegMark`, indicating that packets are destined to uplink. -- Flow 5 is to match packets from hairpin connections and forward them to table [ConntrackCommit] directly to bypass - all tables for ingress security. - - Match condition `ct_mark=0x40/0x40` is to match `HairpinCTMark`, indicating that packets are from hairpin connections. +Flows 3-5 matches packets destined to the local Antrea gateway, tunnel, uplink port with `ToGatewayRegMark`, +`ToTunnelRegMark` or `ToUplinkRegMark`, respectively, and forwards them to table [IngressMetric] directly to bypass +all tables for ingress security. + +Flow 5 matches packets from hairpin connections with `HairpinCTMark` and forward them to table [ConntrackCommit] +directly to bypass all tables for ingress security. Refer to this PR +[#5687](https://github.com/antrea-io/antrea/pull/5687) for more information. + +Flow 6 is the table-miss flow. ### AntreaPolicyIngressRule @@ -1630,87 +1637,82 @@ Antrea-native NetworkPolicy other Tiers -> AntreaPolicyIngressRule ``` Again this table, you will need to keep in mind the Antrea-native NetworkPolicy [specification](#antrea-native-networkpolicy-implementation) -that we are using. Since the sample Antrea-native NetworkPolicy resides in the Application tier. One more tip, the OVS -ports of the sample Pods we use are `8` and `9`. If you dump the flows for this table, you may see the following: +that we are using. Since the sample Antrea-native NetworkPolicy resides in the Application tier. If you dump the flows +for this table, you may see the following: ```text 1. table=AntreaPolicyIngressRule, priority=64990,ct_state=-new+est,ip actions=goto_table:IngressMetric 2. table=AntreaPolicyIngressRule, priority=64990,ct_state=-new+rel,ip actions=goto_table:IngressMetric -3. table=AntreaPolicyIngressRule, priority=14000,ip,nw_src=10.10.0.8 actions=conjunction(6,1/3) -4. table=AntreaPolicyIngressRule, priority=14000,ip,nw_src=10.10.0.7 actions=conjunction(6,1/3) -5. table=AntreaPolicyIngressRule, priority=14000,reg1=0x8 actions=conjunction(6,2/3) -6. table=AntreaPolicyIngressRule, priority=14000,reg1=0x9 actions=conjunction(6,2/3) -7. table=AntreaPolicyIngressRule, priority=14000,tcp,tp_dst=80 actions=conjunction(6,3/3) -8. table=AntreaPolicyIngressRule, priority=14000,conj_id=6,ip actions=set_field:0x6->reg6,ct(commit,table=IngressMetric,zone=65520,exec(set_field:0x6/0xffffffff->ct_label)) -9. table=AntreaPolicyIngressRule, priority=13999,reg1=0x8 actions=conjunction(4,1/2) -10. table=AntreaPolicyIngressRule, priority=13999,reg1=0x9 actions=conjunction(4,1/2) -11. table=AntreaPolicyIngressRule, priority=13999,ip actions=conjunction(4,2/2) -12. table=AntreaPolicyIngressRule, priority=13999,conj_id=4 actions=set_field:0x4->reg3,set_field:0x400/0x400->reg0,goto_table:IngressMetric -13. table=AntreaPolicyIngressRule, priority=0 actions=goto_table:IngressRule +3. table=AntreaPolicyIngressRule, priority=44900,ip,nw_src=10.10.0.26 actions=conjunction(6,1/3) +4. table=AntreaPolicyIngressRule, priority=44900,reg1=0x25 actions=conjunction(6,2/3) +5. table=AntreaPolicyIngressRule, priority=44900,tcp,tp_dst=80 actions=conjunction(6,3/3) +6. table=AntreaPolicyIngressRule, priority=44900,conj_id=6,ip actions=set_field:0x6->reg6,ct(commit,table=IngressMetric,zone=65520,exec(set_field:0x6/0xffffffff->ct_label)) +7. table=AntreaPolicyIngressRule, priority=44899,ip actions=conjunction(4,1/2) +8. table=AntreaPolicyIngressRule, priority=44899,reg1=0x25 actions=conjunction(4,2/2) +9. table=AntreaPolicyIngressRule, priority=44899,conj_id=4 actions=set_field:0x4->reg3,set_field:0x400/0x400->reg0,goto_table:IngressMetric +10. table=AntreaPolicyIngressRule, priority=0 actions=goto_table:IngressRule ``` -- Flows 1-2 matches packets of connections with states `ESTABLISHED` or `RELATED` but not `NEW`, forwarding them to table - [IngressMetric] to skip ingress-related flows. -- Flows 3-4 matches packets sourced from `10.10.0.7` or `10.10.0.8`. Action `conjunction(6,1/3)` signifies that the first - dimension of all three dimensions for `conj_id` 6. -- Flows 5-6 matches packets destined to port `8` or `9`. Action `conjunction(6,2/3)` signifies that the second dimension of - all three dimensions for `conj_id` 6. -- Flow 7 matches packets destined to TCP port `80`. Action `conjunction(6,3/3)` signifies that the third dimension of all - three dimensions for `conj_id` 6. -- Flow 8 matches packets meeting all three dimensions for `conj_id` 6 (rule's action is `Allow`). - - Action `set_field:0x6->reg5` is to load `conj_id` to `APConjIDField`, which is used by feature Traceflow. - - Action `ct` is to persist `conj_id` to ct label in `CtZone`. - - Field `commit` means to commit connection to the connection tracking module. - - Field `table=IngressMetric` is the table where packets will be forwarded. - - Field `zone=65520` is to commit connection to `CtZone`. - - Field `exec` sets some bits of ct label. - - Action `set_field:0x600000000/0xffffffff00000000->ct_label` is to load current `conj_id` value to `IngressRuleCTLabel` - for ingress metrics collection purposes. -- Flows 9-10 matches packets destined to port 8 or 9. Action `conjunction(4,1/2)` signifies that the first dimension of - all two dimensions for `conj_id` 4. -- Flow 11 matches IPv4 packets. Action `conjunction(4,2/2)` signifies that the second dimension of all two dimensions for - `conj_id` 4. -- Flow 12 matches packets meeting all two dimensions for `conj_id` 4 (rule's action is `Drop`). - - Action `set_field:0x4->reg3` is to load `conj_id` value to `APConjIDField`, which is used by feature Traceflow. - - Action `set_field:0x400/0x400->reg0` is to load `APDenyRegMark`, indicating that the packet was denied (Drop / Reject), - then Kubernetes default drop will not be recorded in this reg. -- Flow 13 is the auto-generated flow. +Flows 1-2, which are installed by default, hold the highest priorities, matching non-new and "tracked" packets and +forwarding them to table [IngressMetric] to bypass the check from egress rules. This means that if a connection is +established, its packets go straight to table [IngressMetric], with no other match required. In particular, this ensures +that reply traffic is never dropped because of an Antrea-native NetworkPolicy or Kubernetes NetworkPolicy rule. However, +this also means that ongoing connections are not affected if the Antrea-native NetworkPolicy or the Kubernetes +NetworkPolicy is updated. + +Flows 3-6, whose priorities are all 44900, are installed for the egress rule `AllowFromClient` in the sample policy. +These flows are described as follows: + +- Flow 3 is utilized to match packets with the source IP address in set {10.10.0.26}, which has all IP addresses of + the Pods selected by label `app: client`, constituting the first dimension for `cojunction` with `conj_id` 6. +- Flow 4 is utilized to match packets with the output port in set {0x25}, which has all the ports of the Pods selected + by label `app: web`, constituting the second dimension for `conjunction` with `conj_id` 6. +- Flow 5 is utilized to match packets with the destination TCP port in set {80} specified in the rule, constituting + the third dimension for `conjunction` with `conj_id` 6. +- Flow 6 is utilized to match packets meeting all the three dimensions of `conjunction` with `conj_id` 6 and forward + them to table [IngressMetric], persisting `conj_id` to `IngressRuleCTLabel` that is consumed in table [IngressMetric]. + +Flows 7-9, whose priorities are all 44899, are installed for the egress rule with an `Drop` action defined after rule +`AllowFromClient` in the sample policy, serving as a default rule. Unlike the default of Kubernetes NetworkPolicy, +Antrea-native NetworkPolicy have no default rule, and all rules should be explicitly defined. Hence, they are evaluated +as-is, and there is no need for a table [AntreaPolicyIngressDefault]. These flows are described as follows: + +- Flow 7 is utilized to match any packets, constituting the second dimension for `conjunction` with `conj_id` 4. +- Flow 7 is utilized to match packets with the output port in set {0x25}, which has all the ports of the Pods selected + by label `app: web`, constituting the first dimension for `conjunction` with `conj_id` 4. +- Flow 9 is utilized to match packets meeting both dimensions of `conjunction` with `conj_id` 4. `APDenyRegMark`, + which will be consumed in table [IngressMetric] to which the packets are forwarded, is loaded. + +Flow 10 is the table-miss flow to forward packets, which are not matched by other flows, to table [IngressMetric]. ### IngressRule This table is very similar to table [EgressRule], but implements ingress rules for Kubernetes NetworkPolicies. Once again, you will need to keep mind the Kubernetes NetworkPolicy [specification](#kubernetes-networkpolicy-implementation) that -we are using. We have 2 Pods running on the same Node, with IP addresses 10.10.1.2 to 10.10.1.3. They are allowed to talk -to each other using TCP on port 80, but nothing else. +we are using. If you dump the flows for this table, you should see something like this: ```text -1. table=IngressRule, priority=200,ip,nw_src=10.10.0.7 actions=conjunction(7,1/3) -2. table=IngressRule, priority=200,ip,nw_src=10.10.0.8 actions=conjunction(7,1/3) -3. table=IngressRule, priority=200,reg1=0x8 actions=conjunction(7,2/3) -4. table=IngressRule, priority=200,reg1=0x9 actions=conjunction(7,2/3) -5. table=IngressRule, priority=200,tcp,tp_dst=80 actions=conjunction(7,3/3) -6. table=IngressRule, priority=190,conj_id=7,ip actions=set_field:0x7->reg6,ct(commit,table=IngressMetric,zone=65520,exec(set_field:0x7/0xffffffff->ct_label)) -7. table=IngressRule, priority=0 actions=goto_table:IngressDefaultRule +1. table=IngressRule, priority=200,ip,nw_src=10.10.0.26 actions=conjunction(3,1/3) +2. table=IngressRule, priority=200,reg1=0x25 actions=conjunction(3,2/3) +3. table=IngressRule, priority=200,tcp,tp_dst=80 actions=conjunction(3,3/3) +4. table=IngressRule, priority=190,conj_id=3,ip actions=set_field:0x3->reg6,ct(commit,table=IngressMetric,zone=65520,exec(set_field:0x3/0xffffffff->ct_label)) +5. table=IngressRule, priority=0 actions=goto_table:IngressDefaultRule ``` -- Flows 1-2 matches packets sourced from `10.10.0.7` or `10.10.0.8`. Action `conjunction(7,1/3)` signifies that the first - dimension of all three dimensions for `conj_id` 7. -- Flows 3-4 matches packets destined to port `8` or `9` . Action `conjunction(7,2/3)` signifies that the second dimension - of all three dimensions for `conj_id` 7. -- Flow 5 matches packets destined to TCP port `80`. Action `conjunction(7,3/3)` signifies that the third dimension of all - three dimensions for `conj_id` 7. -- Flow 6 matches packets meeting all three dimensions for `conj_id` 7. - - Action `set_field:0x7->reg5` is to load `conj_id` to `APConjIDField`, which is used by feature Traceflow. - - Action `ct` is to persist `conj_id` to ct label in `CtZone`. - - Field `commit` means to commit connection to the connection tracking module. - - Field `table=IngressMetric` is the table where packets will be forwarded. - - Field `zone=65520` is to commit connection to `CtZone`. - - Field `exec` sets some bits of ct label. - - Action `set_field:0x7/0xffffffff->ct_label` is to load current `conj_id` value to `IngressRuleCTLabel` for ingress - metrics collection purposes. -- Flow 7 is the auto-generated flow. +Flows 1-4 are installed for ingress rule in the sample Kubernetes NetworkPolicy. These flows are described as follows: + +- Flow 1 is utilized to match packets with the source IP address in set {10.10.0.26}, which is from the Pods selected + by label `app: client`, constituting the first dimension for `conjunction` with `conj_id` 3. +- Flow 2 is utilized to match packets with the output port in set {0x25}, which has all ports of the Pods selected + by label `app: web`, constituting the second dimension for `conjunction` with `conj_id` 3. +- Flow 3 is utilized to match packets with the destination TCP port in set {80} specified in the rule, constituting + the third dimension for `conjunction` with `conj_id` 3. +- Flow 4 is utilized to match packets meeting all the three dimensions of `conjunction` with `conj_id` 3 and forward + them to table [IngressMetric], persisting `conj_id` to `IngressRuleCTLabel`. + +Flow 5 is the table-miss flow to forward packets, which are not matched by other flows, to table [IngressDefaultRule]. ### IngressDefault @@ -1721,19 +1723,22 @@ Pod](https://kubernetes.io/docs/concepts/services-networking/network-policies/#i table is in charge of dropping traffic destined to Pods to which a NetworkPolicy (with an ingress rule) is applied, and which did not match any of the allow list rules. -Accordingly, based on our Kubernetes NetworkPolicy example, we would expect to see flows to drop traffic destined to -our 2 Pods (port `8` and `9`), which is confirmed by dumping the flows: +If you dump the flows for this table, you may see the following: ```text -1. table=IngressDefaultRule, priority=200,ip,reg1=0x8 actions=drop -2. table=IngressDefaultRule, priority=200,ip,reg1=0x9 actions=drop -3. table=IngressDefaultRule, priority=0 actions=goto_table:IngressMetric +1. table=IngressDefaultRule, priority=200,reg1=0x25 actions=drop +2. table=IngressDefaultRule, priority=0 actions=goto_table:IngressMetric ``` -Similar to table [EgressDefault], this table is also used to implement Antrea-native NetworkPolicy ingress rules that -are created in the Baseline Tier. Since the Baseline Tier is meant to be enforced after Kubernetes NetworkPolicies, the -corresponding flows will be created at a lower priority than Kubernetes NetworkPolicy default drop flows. These flows -are like flows 3-12 in table [AntreaPolicyIngressRule]. +Flow 1, based on our sample Kubernetes NetworkPolicy, is to drop traffic destined to port 0x25, the port number +associated with Pods selected by label `app: web`. + +Flow 2 is table-miss flow to forwards packets to table [IngressMetric]. + +This table is also used to implement Antrea-native NetworkPolicy ingress rules that are created in the Baseline Tier. +Since the Baseline Tier is meant to be enforced after Kubernetes NetworkPolicies, the corresponding flows will be created +at a lower priority than Kubernetes NetworkPolicy default drop flows. These flows are similar to 3-9 in table +[AntreaPolicyIngressRule]. ### IngressMetric @@ -1742,32 +1747,23 @@ This table is very similar to table [EgressMetric], but used to collect ingress If you dump the flows for this table, you may see the following: ```text -1. table=IngressMetric, priority=200,ct_state=+new,ct_label=0x6/0xffffffff,ip actions=goto_table:ConntrackCommit -2. table=IngressMetric, priority=200,ct_state=-new,ct_label=0x6/0xffffffff,ip actions=goto_table:ConntrackCommit -3. table=IngressMetric, priority=200,ct_state=+new,ct_label=0x7/0xffffffff,ip actions=goto_table:ConntrackCommit -4. table=IngressMetric, priority=200,ct_state=-new,ct_label=0x7/0xffffffff,ip actions=goto_table:ConntrackCommit +1. table=IngressMetric, priority=200,ct_state=+new,ct_label=0x3/0xffffffff,ip actions=goto_table:ConntrackCommit +2. table=IngressMetric, priority=200,ct_state=-new,ct_label=0x3/0xffffffff,ip actions=goto_table:ConntrackCommit +3. table=IngressMetric, priority=200,ct_state=+new,ct_label=0x6/0xffffffff,ip actions=goto_table:ConntrackCommit +4. table=IngressMetric, priority=200,ct_state=-new,ct_label=0x6/0xffffffff,ip actions=goto_table:ConntrackCommit 5. table=IngressMetric, priority=200,reg0=0x400/0x400,reg3=0x4 actions=drop 6. table=IngressMetric, priority=0 actions=goto_table:ConntrackCommit ``` -- Flows 1-2 matches packets from the sample Antrea-native NetworkPolicy ingress rule with action `Allow`. - - Match conditions `ct_state=+new` or `ct_state=-new` are to match packets with state `NEW` or not `NEW`. - - Match condition `ct_label=0x6/0xffffffff` is to match `IngressRuleCTLabel` with value 6, which is loaded in table - [AntreaPolicyIngressRule], flow 8. - - Action `goto_table:ConntrackCommit` is to forward packets to table [ConntrackCommit] since the action of the sample - rule is `Allow`. -- Flows 3-4 matches packets from the sample Kubernetes NetworkPolicy ingress rule with action `Allow`. - - Match conditions `ct_state=+new` or `ct_state=-new` are to match packets with state `NEW` or not `NEW`. - - Match condition `ct_label=0x7/0xffffffff` is to match `EgressRuleCTLabel` with value 7, which is loaded in table - [IngressRule], flow 6. - - Action `goto_table:ConntrackCommit` is the same as flows 1-2. -- Flow 5 matches packets of the sample Antrea-native NetworkPolicy ingress rule with action `Drop` or `Reject`, then - drop them. - - Match condition `reg0=0x400/0x400` is to match `APDenyRegMark`, which is loaded in table [AntreaPolicyIngressRule], - flow 12, indicating that the packets should be denied. - - Match condition `reg3=0x4` is to match `APConjIDField`, which is loaded in table [AntreaPolicyIngressRule], flow 12 - - Action `drop` is to drop packets. -- Flow 6 is the auto-generated flow. +Flows 1-2, matching packets with `IngressRuleCTLabel` set to 3, the `conj_id` allocated for the sample Kubernetes +NetworkPolicy ingress rule and loaded in table [IngressRule] flow 4, are utilized to collect metrics for the ingress rule. + +Flows 3-4, matching packets with `IngressRuleCTLabel` set to 6, the `conj_id` allocated for the sample Antrea-native +NetworkPolicy ingress rule and loaded in table [IngressRule] flow 6, are utilized to collect metrics for the ingress rule. + +Flow 5 serves as the default drop rule for the sample Antrea-native NetworkPolicy ingress rule. It drops the packets with +`APDenyRegMark` loaded in table [AntreaPolicyIngressRule] flow 9, and `APConjIDField` set to 4, the `conj_id` allocated +for the egress rule and loaded in table [AntreaPolicyIngressRule] flow 9. ### ConntrackCommit @@ -1780,9 +1776,9 @@ If you dump the flows for this table, you should see the following: 2. table=ConntrackCommit, priority=0 actions=goto_table:Output ``` -Flow 1 is designed to match the first packet from non-Service connections with ct status and `NotServiceCTMark`. -Then it commits the relevant connections in `CtZone`, persists the value of `PktSourceField` to `ConnSourceCTMarkField`, -and forward the packets to table [Output]. +Flow 1 is designed to match the first packet of non-Service connections with the "tracked" state and `NotServiceCTMark`. +Then it commits the relevant connections in `CtZone`, persisting the value of `PktSourceField` to +`ConnSourceCTMarkField`, and forwards the packets to table [Output]. Flow 2 is table-miss flow. @@ -1799,14 +1795,18 @@ following cases: If you dump the flows for this table, you should see the following: ```text -1. table=Output, priority=210,ct_mark=0x40/0x40 actions=IN_PORT -2. table=Output, priority=200,reg0=0x200000/0x600000 actions=output:NXM_NX_REG1[] -3. table=Output, priority=200,reg0=0x2400000/0xfe600000 actions=meter:256,controller(reason=no_match,id=62373,userdata=01.01) -4. table=Output, priority=200,reg0=0x4400000/0xfe600000 actions=meter:256,controller(reason=no_match,id=62373,userdata=01.02) -5. table=Output, priority=0 actions=drop +1. table=Output, priority=212,ct_mark=0x80/0x80,reg0=0x200000/0x600000 actions=push_vlan:0x8100,move:NXM_NX_CT_LABEL[64..75]->OXM_OF_VLAN_VID[],output:"antrea-l7-tap0" +2. table=Output, priority=211,reg0=0x200000/0x600000,reg4=0x400000/0xc00000 actions=output:NXM_NX_REG1[],output:NXM_NX_REG9[] +3. table=Output, priority=211,reg0=0x200000/0x600000,reg4=0x800000/0xc00000 actions=output:NXM_NX_REG9[] +4. table=Output, priority=210,ct_mark=0x40/0x40 actions=IN_PORT +5. table=Output, priority=200,reg0=0x200000/0x600000 actions=output:NXM_NX_REG1[] +6. table=Output, priority=200,reg0=0x2400000/0xfe600000 actions=meter:256,controller(reason=no_match,id=62373,userdata=01.01) +7. table=Output, priority=200,reg0=0x4400000/0xfe600000 actions=meter:256,controller(reason=no_match,id=62373,userdata=01.02) +8. table=Output, priority=0 actions=drop ``` -Flow 1 for case 1. It matches packets from hairpin connections by matching `HairpinCTMark`. +Flow 1 for case 1. It matches packets from hairpin connections by matching `HairpinCTMark` and forwards it back to the +port where they were received. Flow 2 for case 2. It matches packets by matching `OutputToOFPortRegMark` and outputs them to the OVS port specified by the value stored in `TargetOFPortField`. @@ -1835,13 +1835,13 @@ Flow 4 is the table-miss flow for case 4. It drops packets that do not match any [SNATMark]: #snatmark [SNAT]: #snat [L2ForwardingCalc]: #l2forwardingcalc +[TrafficControl]: #trafficcontrol [IngressSecurityClassifier]: #ingresssecurityclassifier [AntreaPolicyIngressRule]: #antreapolicyingressrule [IngressRule]: #ingressrule [IngressDefault]: #ingressdefault [IngressMetric]: #ingressmetric [Output]: #output - [ClusterIP without Endpoint]: #clusterip-without-endpoint [ClusterIP]: #clusterip [ClusterIP with Session Affinity]: #clusterip-with-session-affinity