你好，针对你在AWS c5n.2xlarge实例上遇到的Strongswan IPsec解密流量全集中在单CPU、无法分摊到多核心的问题，我帮你梳理下核心原因和可落地的解决方案：

问题根源拆解 #

你提到加密流量能自动分摊到8个CPU，但解密全挤在一个核心，核心问题出在网卡的RSS（接收端缩放）哈希规则上：

• 你的8个IPsec SA共享完全相同的源/目的IP和UDP 4500端口，默认情况下网卡只会基于L3（IP）和L4（端口）字段计算哈希，所有解密流量会被分到同一个网卡队列，最终绑定到同一个CPU处理。
• 内核的ECMP配置是针对转发路径的，无法干预网卡接收阶段的队列分配，所以你尝试的几种ECMP哈希策略都没效果。

具体解决方案 #

1. 调整ENA网卡的RSS哈希规则（核心步骤） #

AWS c5n实例使用的ENA网卡默认不会把ESP协议的SPI（安全参数索引）纳入哈希计算，我们需要手动修改这个规则，让不同SPI的SA流量分到不同队列：

• 先查看当前ESP协议的哈希配置：

  ethtool -n eth0 rx-flow-hash esp4
  

  正常输出会是ESP over IPv4 flows use these fields for computing hash: SrcIP DstIP，只用到了IP地址。

• 修改哈希规则，加入SPI字段：

  ethtool -N eth0 rx-flow-hash esp4 sdf
  

  这里的s=源IP、d=目的IP、f=ESP SPI，修改后再用第一条命令确认，输出应该包含SPI字段。

  要是你用到IPv6环境，对应命令是ethtool -N eth0 rx-flow-hash esp6 sdf

2. 确认网卡多队列与CPU的绑定 #

确保网卡的队列数和CPU核心数匹配（c5n.2xlarge是8核，队列数也应该设为8）：

• 查看当前队列数：

  ethtool -l eth0
  

• 如果队列数不足，调整为8：

  ethtool -L eth0 combined 8
  

3. 内核IPsec参数优化 #

为了让IPsec栈更好地适配多CPU环境，再调整几个内核参数：

• 启用XFRM的 per-CPU 统计，方便后续监控：

  sysctl -w net.ipv4.xfrm4_percpu_stats=1
  

• 提高XFRM垃圾回收阈值，避免单CPU堆积过多SA：

  sysctl -w net.ipv4.xfrm4_gc_thresh=4096
  

• 启用RPS/RFS增强流量分发（ENA网卡默认支持，但手动确认更稳妥）：

  sysctl -w net.core.rps_sock_flow_entries=32768
  for q in /sys/class/net/eth0/queues/rx-*/rps_cpus; do echo f > $q; done
  

  这里的f表示允许所有CPU处理该队列流量，你也可以根据需求绑定特定CPU。

4. 验证负载分摊效果 #

修改完成后，发送解密流量，通过以下方式验证：

• 用top -1观察各CPU负载，确认解密相关的CPU占用不再集中在单个核心。
• 用ethtool -S eth0查看各RX队列的数据包计数，确认多个队列都有流量进入。
• 结合ip xfrm state和perf top，查看解密操作的CPU分布情况。

额外注意事项 #

• 如果后续切换到其他云环境或使用不同网卡（比如Intel X710），核心思路不变：让网卡哈希规则包含ESP SPI字段，只是具体命令可能略有差异。
• 确保每个SA的SPI是唯一的（从你提供的ip xfrm state输出看已经满足），这是流量能分流的基础。
• 以上配置重启后会失效，建议把内核参数写入/etc/sysctl.d/99-ipsec-tuning.conf，网卡配置通过netplan或systemd-networkd持久化。

备注：内容来源于stack exchange，提问作者Jeff Learman