kubeovn LS_CT_SKIP_DST_LPORT_IPS

LS_CT_SKIP_DST_LPORT_IPS 出现在 kube-ovn-controller 的启动参数 中，是 控制器逻辑层面影响 OVN NB 配置和流表生成逻辑 的配置项。

下面我来结合 kube-ovn-controller 的源码和架构重新分析这一参数在 控制器（Controller）逻辑中的实际功能、影响和启用机制。

---

🧩 一、上下文定位

kube-ovn-controller 是整个 kube-ovn 控制面的核心组件之一，它主要负责：

• 同步 Kubernetes 对象（Pod、Service、Namespace）到 OVN NB；
• 生成并写入 Logical Switch / Logical Router / ACL / NAT / LB 等配置；
• 调整流表策略（通过 OVN NB 控制逻辑表项）；
• 处理网关、EIP、SNAT 等高级功能。

而参数 --ls-ct-skip-dst-lport-ips 就是控制它在生成 逻辑交换机（Logical Switch）相关流表规则 时，是否为目标端口 IP 设置 “跳过 ConnTrack”。

---

⚙️ 二、源码入口（关键线索）

在 kube-ovn 项目中（例如版本 1.13~1.14 或主分支中），这个参数对应 controller 启动时的 flag：

// pkg/daemon/config.go or cmd/controller.go
flag.BoolVar(&config.LsCtSkipDstLportIPs, "ls-ct-skip-dst-lport-ips", true,
    "Skip conntrack for packets with destination IP matching logical port IPs in logical switch flows")

然后这个配置被传入：

• pkg/ovn/controller/logical_switch.go
• pkg/ovn/controller/policy.go
• pkg/ovn/controller/flow.go

这些文件负责调用 ovn-nbctl 向 NBDB 写入 ACL、流量管控、pipeline 规则。

---

🧠 三、逻辑核心：影响的流表类型

控制器在创建 Logical Switch 时，会根据这个 flag 决定：

if config.LsCtSkipDstLportIPs {
    ovn-nbctl --may-exist ls-set-options <switch> other_config:ct_skip_dst_lport_ips=true
} else {
    ovn-nbctl --may-exist ls-del-options <switch> other_config:ct_skip_dst_lport_ips
}

也就是说，这个参数控制的实际上是 Logical Switch 的 other_config 字段。

在 OVN 的底层机制中，每个 Logical Switch 都可以带有一些调优选项，例如：

Key	含义
ct_skip_dst_lport_ips	是否跳过目标端口 IP 的 conntrack（控制是否执行 ct()）
ct_zone_conflict	控制 zone 重叠行为
mac_binding_age_limit	控制 MAC binding 老化时间
untracked_flows	指定跳过 conntrack 的流类型

---

📘 四、深入原理：OVN 内部行为

在 OVN pipeline 中，当 other_config:ct_skip_dst_lport_ips=true 时：

• 逻辑交换机的 ingress pipeline（table 65 → 70 左右）中，会额外插入 “skip conntrack” 条件；
• 对目标 IP 属于任意逻辑端口（即 Pod 自己 IP）的流量，直接 next;；
• 否则执行 ct() 并进入 conntrack zone。

💡 对应的 OVS 流表动作类似：

table=65, match=(ip && ip.dst==pod_ip), action=next
# 若关闭该参数
table=65, match=(ip && ip.dst==pod_ip), action=ct(...)

---

🧩 五、与 kube-ovn-controller 其他参数的联动关系

参数	含义	关联说明
--ls-dnat-mod-dl-dst	DNAT 后修改目标 MAC	若启用 DNAT/LB，则必须让目的流量经过 ct，因此要求 --ls-ct-skip-dst-lport-ips=false
--enable-lb	启用 OVN LB 功能	同上，如果负载均衡要工作，必须让包经过 conntrack
--enable-eip-snat	EIP SNAT/NAT 模式	同上，依赖 conntrack
--enable-external-vpc	外部 VPC 打通	若流量路径包含外部网关，同样建议关闭该 skip
--pod-nic-type	控制 Pod 接口类型（veth/ipvlan）	对此参数无直接影响，但影响是否支持某些 fast path

---

🧮 六、结合 kube-ovn 架构分析：控制面到数据面的路径

kube-ovn-controller
   ↓
  OVN NB DB (logical_switch.other_config)
   ↓
  ovn-northd → 生成逻辑流表 (pipeline)
   ↓
  ovn-controller (Node) → 下发到 OVS datapath

因此，这个参数虽然在 kube-ovn-controller 层设置，
但最终影响的是每个节点上 br-int 的具体流表逻辑。

---

✅ 七、结论总结（基于 controller 视角）

项目	说明
参数名	--ls-ct-skip-dst-lport-ips
位置	kube-ovn-controller 启动参数
默认值	true
实现逻辑	向每个 Logical Switch 的 other_config 写入 ct_skip_dst_lport_ips=true
影响层面	OVN pipeline（logical switch ingress pipeline）是否跳过目的端口流量的 conntrack
典型用途	提升 intra-switch 性能，减少 conntrack 负载
禁用场景	使用 DNAT/LB、NAT Gateway、安全组（依赖 conntrack）等
生效路径	kube-ovn-controller → OVN NB → ovn-northd → OVS 流表

---

🧭 八、实践建议

场景	推荐值	说明
仅用 kube-ovn 作为纯 VPC/Subnet Overlay	✅ true	性能最佳
需要使用 kube-ovn 的 LoadBalancer / DNAT / SNAT / EIP	❌ false	否则 DNAT/LB 不生效
使用安全策略（NetworkPolicy / SecurityGroup）	❌ false	依赖 ct.state
大规模集群、无 NAT 需求	✅ true	减少 CPU 开销

---