我有以下 Linux 网络设置：有一个 eth10 网络接口，分配的地址为 10.11.0.1/24。然后有一个分配了虚拟地址 0.0.0.1/32 的 tap0 网络接口（我分配了一个虚拟地址来启动接口），并且来自/到它的流量由最初创建 tap0 接口的用户空间程序控制。在 tap0 接口的另一侧，有一个用户空间程序通过原始套接字使用它，该程序查找 ARP 请求并构建响应。
现在，当用户空间程序构造一个请求 10.11.0.1 的 ARP 请求时，我希望另一个原始套接字用户空间程序回复它。但是，我得到了两个回复：一个来自原始套接字程序，另一个来自 Linux 内核。
显然，Linux 内核推断 10.11.0.1 是属于它的地址，因此做出了答复。但是10.11.0.1并不是tap0接口的地址。它是 eth10 接口的地址。
我的问题是：为什么 Linux 内核会这样做？有什么办法可以禁用错误接口上的 ARP 回复？
我对这个问题的临时解决方案是使用 10.11.0.1 以外的其他地址用于原始套接字/tap0 目的。但是，因为这个系统应该是一个可以在任何开发机器上运行的应用程序的系统级测试，所以我不能保证与其他接口没有 IP 地址冲突。因此，最好在错误的接口上禁用 ARP 回复。
这个问题的另一个解决方案是使用 netmap 为用户空间应用程序保留整个接口，防止内核在用户空间应用程序运行时使用它。但我希望我的测试在没有 netmap 的情况下运行。
我可以访问两台 NUMA 服务器。其中之一是 Dell R720，具有以下 CPU：
$ cat /proc/cpuinfo |grep Xeon|sort|uniq -c
24 model name : Intel(R) Xeon(R) CPU E5-2630L v2 @ 2.40GHz
另一个是 HPE DL360 Gen8，具有以下 CPU：
$ cat /proc/cpuinfo |grep Xeon|sort|uniq -c
24 model name : Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz
在我们拥有许多 HPE Gen9 服务器的工作中，我已经习惯了 CPU 编号（socket0、socket1、socket0 超线程、socket1 超线程）。HPE DL360 Gen8 似乎使用以下编号：
$ cat /proc/cpuinfo |grep physical.id|uniq -c
6 physical id : 0
6 physical id : 1
6 physical id : 0
6 physical id …