该问题最初发布在网络工程 SE 网站上，但因偏离主题而被关闭。
我偶然发现我们网络中的 Windows 主机存在特殊行为。
我们的客户大多位于我们网络的无线部分。出于性能原因，我们使用的 Ubiquiti 接入点会阻止从有线部分到无线部分的多播和广播流量。
当主机（客户）在 WiFi 端联系主机（服务器)，运行 Linux 的有线网络上，一切正常。客户发送一个 ARP 请求，该请求通过广播方式发送到有线网段，服务器使用单播 ARP 回复进行响应，并了解客户进程中获取到的MAC地址，然后就可以正常进行IP数据包的交换了。
使用 Windows服务器，但看起来不一样。如果我 ping服务器10.10.10.4 从客户在 10.10.244.14 上，我看到以下数据包服务器的界面：
15:11:50.892975 4c:32:75:95:b9:7b > Broadcast, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.10.10.4 tell 10.10.244.14, length 46
15:11:50.893725 52:75:9a:65:57:e4 > 4c:32:75:95:b9:7b, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 10.10.10.4 is-at 52:75:9a:65:57:e4, length 46
15:11:50.898967 4c:32:75:95:b9:7b > 52:75:9a:65:57:e4, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 39008, offset 0, flags [none], proto ICMP (1), length 84)
10.10.244.14 > 10.10.10.4: ICMP echo request, id 34083, seq 0, length 64
15:11:50.899285 52:75:9a:65:57:e4 > Broadcast, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.10.244.14 tell 10.10.10.4, length 46
15:11:51.711006 52:75:9a:65:57:e4 > Broadcast, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.10.244.14 tell 10.10.10.4, length 46
15:11:51.895016 4c:32:75:95:b9:7b > 52:75:9a:65:57:e4, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 9988, offset 0, flags [none], proto ICMP (1), length 84)
10.10.244.14 > 10.10.10.4: ICMP echo request, id 34083, seq 1, length 64
[...]
似乎 Windows服务器不会根据收到的 ARP 请求来更新其 ARP 表，而是发送自己的请求来获取客户的 MAC 地址（如上面的第四个数据包所示）。这些请求是广播的，因此永远不会到达客户。因此，ping 无法得到响应，因为服务器不知道把它们发送到哪里。
有趣的是，如果我继续 ping服务器大约两分钟后，服务器在客户似乎变得陈旧，单播ARP 请求被发送到服务器验证缓存的 MAC 地址，从那一刻起，ping 得到答复：
15:13:57.289539 4c:32:75:95:b9:7b > 52:75:9a:65:57:e4, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.10.10.4 (52:75:9a:65:57:e4) tell 10.10.244.14, length 46
15:13:57.289945 52:75:9a:65:57:e4 > 4c:32:75:95:b9:7b, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 128, id 31608, offset 0, flags [none], proto ICMP (1), length 84)
10.10.10.4 > 10.10.244.14: ICMP echo reply, id 34083, seq 126, length 64
15:13:57.290001 52:75:9a:65:57:e4 > 4c:32:75:95:b9:7b, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 10.10.10.4 is-at 52:75:9a:65:57:e4, length 46
15:13:58.292013 4c:32:75:95:b9:7b > 52:75:9a:65:57:e4, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 60751, offset 0, flags [none], proto ICMP (1), length 84)
10.10.244.14 > 10.10.10.4: ICMP echo request, id 34083, seq 127, length 64
15:13:58.292336 52:75:9a:65:57:e4 > 4c:32:75:95:b9:7b, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 128, id 31609, offset 0, flags [none], proto ICMP (1), length 84)
10.10.10.4 > 10.10.244.14: ICMP echo reply, id 34083, seq 127, length 64
对我来说，这看起来就像 Windows服务器仅当该 ARP 请求是单播请求时，它才会在收到针对其自身地址的 ARP 请求后更新自己的 ARP 缓存。
如果我理解请求函数正确，这似乎不是正确的行为。我理解 ARP 请求的接收者应该始终更新如果发送主机已经有条目，则有自己的 ARP 表，或者插入A新的如果 ARP 请求是针对其自己的地址，则为发送主机的条目。
是我误读了规范，还是 Windows 做了一些不同的事情？如果是后者，这种行为可以配置吗？
谢谢您的指点。
答案1
出于性能原因，我们使用的 Ubiquiti 接入点会阻止从有线部分到无线部分的多播和广播流量。
这会中断有线和无线部分之间的所有通信。ARP 需要广播才能工作。
您可以过滤/阻止特定类型的不良广播，但不能全部过滤/阻止。为了获得干净的方法，您应该使用专用无线子网（或多个子网）并在其与其余子网之间进行路由。