HDUO Lab

分类： 网络虚拟化与架构

  • 深入 Macvlan 广播风暴排查：CAM 表溢出引发的未知单播泛洪与 ksoftirqd 软中断打满实战

    某次接手一个号称为了“极致网络性能”而将 K8S CNI 从 VXLAN 模式改为纯 Macvlan 的生产集群。业务上线后，节点负载出现间歇性雪崩，核心接口 P99 延迟从正常的 20ms 飙升至 3s 甚至超时，节点 Load Average 狂飙。排查到底层的结论很直接：高密度 Pod 产生的离散 MAC 地址不仅打穿了单机网卡的硬件过滤表，更是直接打爆了 ToR 交换机的 CAM（MAC 地址表）。交换机被迫退化成 Hub，引发全网段“未知单播泛洪”（Unknown Unicast Flooding）。所有节点的 ksoftirqd 进程因处理海量非本机的垃圾报文将 CPU 软中断打满。盲目追求扁平网络而不评估物理网络和硬件容量，纯属给自己挖坑。

    案发现场与指标表现

    报警爆发时，业务端反馈连接池超时，但在容器内 ping 网关却时通时断。登录其中一台高负载节点排查，执行 mpstat -P ALL 1，发现部分 CPU 核心的 %soft（软中断）指标死死顶在 100%：

    10:14:01 AM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %idle
10:14:02 AM    2    1.00    0.00    3.00    0.00    0.00  100.00    0.00    0.00   0.00
10:14:02 AM    5    0.50    0.00    2.50    0.00    0.00  100.00    0.00    0.00   0.00

    查看 /proc/softirqs，NET_RX（网络接收软中断）的计数值在特定核上正在以每秒数十万的速率疯狂拉升。

    直接抓取网卡吞吐，sar -n DEV 1 显示物理网卡 eth0 的 rxpck/s（每秒接收包数）高达 40w+，但节点实际的业务 QPS 根本没有这么大，且大部分包被内核默默丢弃了（rxdrop/s 同样极高）。

    剥丝抽茧：谁在塞满接收队列？

    既然有海量不明报文涌入，直接祭出 tcpdump 在宿主机物理网卡上抓包分析。为了过滤掉正常的本机流量，明确指定抓取目的 MAC 不是本机的报文：

    tcpdump -i eth0 -n -e -c 1000 not ether dst $(cat /sys/class/net/eth0/address)

    抓包结果让人大跌眼镜：屏幕上疯狂滚动着目的 MAC 地址属于其他节点上运行的 Pod 的单播报文。

    正常情况下，交换机通过 CAM 表记录 MAC 地址与物理端口的映射，单播包应该精确转发到对应端口，为什么这些单播包会被广播到所有节点？

    结合 Macvlan 的底层机制，问题的技术逻辑链条浮出水面： Macvlan 的核心原理是为宿主机网卡创建多个子接口，每个子接口（即每个 Pod）分配一个独立的、真实的 MAC 地址。

    # Macvlan 底层创建逻辑示例
ip link add link eth0 name macvlan0 type macvlan mode bridge

    第一层雪崩：物理网卡 UC Filter 被迫降级 普通的物理网卡（如 Intel X710 等）硬件支持的单播 MAC 地址过滤表（Unicast Filter Table）容量极其有限（通常在 128 到 512 个之间）。当单台宿主机上调度的 Pod 数量超过网卡硬件限制时，网卡驱动为了保证网络连通性，会直接放弃硬件过滤，强制将网卡设置为混杂模式（Promiscuous Mode）。 通过 dmesg | grep promiscuous 确认了这一点，系统日志中赫然躺着： eth0: entered promiscuous mode 这意味着网卡会将网络上收到的所有报文全部通过 DMA 拷贝到内存，并触发中断交由内核 ksoftirqd 处理。

    第二层雪崩：ToR 交换机 CAM 表溢出 集群规模约 100 台，每台节点平均 150 个 Pod，总计 15000+ 个 MAC 地址。而机架顶部的 ToR 交换机的 CAM 表容量上限仅为 8192。 当交换机学习到的 MAC 地址超过 8192 时，新来的 MAC 无法被记录，或者旧的活跃 MAC 被挤出。当交换机收到目的地址不在 CAM 表中的单播报文时，它的处理机制是：将该报文向 VLAN 内除源端口外的所有端口泛洪（Flooding）。

    两层雪崩叠加，灾难诞生了：交换机将海量的单播报文当成广播往全网段狂塞，而所有宿主机的物理网卡均因超过硬件过滤上限处于混杂模式，全盘接收这些垃圾报文。内核网络栈被迫对这每秒数十万的包进行解析、路由判断并最终丢弃，直接耗尽了 CPU 的软中断处理能力，导致正常的业务报文排队超时，业务被一波带走。

    破局与架构避坑

    不要一听到 VXLAN 的封包解包开销，就急着上 Macvlan。扁平网络带来的不仅是性能，还有对二层物理网络的巨大冲击。

    对于这种问题，除了临时扩容交换机 CAM 表（如果硬件支持的话）或降低 Pod 密度外，根本的技术解法是抛弃 Macvlan，转向 IPVLAN (L2 模式)。

    IPVLAN 与 Macvlan 类似，都能提供直接接入 Underlay 网络的低损耗，但 IPVLAN 的核心区别在于：所有 Pod 共享宿主机物理网卡的 MAC 地址。

    # IPVLAN 底层创建逻辑示例
ip link add link eth0 name ipvlan0 type ipvlan mode l2

    使用 IPVLAN 后：

    1. ToR 交换机解脱：无论节点上跑 10 个还是 1000 个 Pod，交换机在对应端口上只看到 1 个宿主机的 MAC，彻底根绝 CAM 表溢出风险。

    2. 物理网卡解脱：无需占用网卡硬件 MAC 过滤表，网卡无需开启混杂模式，异常泛洪报文在网卡硬件层即被丢弃。

    3. 内核分发：报文到达内核后，IPVLAN 驱动根据网络层的 IP 地址（而不是 MAC）将流量精准分发到对应的 Pod 网络命名空间。

    同类问题速查排查清单

    1. NET_RX 软中断飙升定性：遇到网络高延迟，第一时间 mpstat -P ALL 1 查看 %soft，并用 cat /proc/softirqs 确认是否为 NET_RX 引起。若单核被打满，往往伴随网卡多队列未开启或哈希不均（RSS 配置问题）。

    2. 未知单播泛洪检测：使用 tcpdump -i eth0 -n -e not ether dst <本机MAC> 抓包。如果抓到大量不属于本机且非广播/多播的报文，立即检查交换机 MAC 学习表是否溢出或未学习到对应路由。

    3. 网卡混杂模式暗坑排查：高密度容器场景下，通过 dmesg | grep promiscuous 或 ip link show 检查物理网卡是否处于 PROMISC 状态。如果是且非主动开启（如抓包），需警惕硬件 MAC 过滤表已满。

    4. Macvlan 宿主机互通死角：如果开发反馈 Macvlan 模式下 Pod 无法 ping 通所在的宿主机（常导致 Kubelet 健康检查失败），这是 Macvlan 规范限制。必须在宿主机额外创建一个 Macvlan 虚接口，并将宿主机 IP 移至该虚接口并配置对应路由才能绕过此隔离限制。