☰

需要解释：VMware 网络适配器上的 TCP/IP 上的 NetBIOS 会干扰对网络共享的访问

tag-icon • tag-icon windows-xp tcpip vmware-workstation netbios
需要解释：VMware 网络适配器上的 TCP/IP 上的 NetBIOS 会干扰对网络共享的访问

（从 StackOverflow 移至此处）

前段时间，我们团队的几乎所有工作站（Windows XP SP2）在访问网络共享时都出现了间歇性但频繁的延迟。通常，第一次访问一段时间未访问的共享会导致工作站几乎冻结长达 30 秒。然后一切又开始正常工作。

使用 Sysinternals 的 TCPView，我看到在延迟期间，有一个连接到netbios-ssn文件服务器上的端口处于SYN_SENT。

第一次尝试：

禁用TCP/IP 上的 NetBIOS用于内联网网络适配器。

问题解决了，但我不喜欢操纵我们集中管理的内部网网络配置。

第二次尝试：

禁用TCP/IP 上的 NetBIOS仅适用于 VMWare 网络适配器（VMNet1 用于仅主机通信）。

问题又解决了！

我的问题：

  • 为什么TCP/IP 上的 NetBIOS一个网络适配器上的 TCP/IP 会干扰另一个网络适配器上的 NetBIOS 吗？
  • 该问题是否特定于 VMWare 网络适配器？
  • 还有人见过这种现象吗？

附加信息：

  • VMWare Workstation 版本 6.0.3
  • 当我开始认真分析问题时，已经不可能找出问题出现时我们的系统发生了什么改变。

答案1

我也见过类似的现象。

症状乍一看不太相似：无论访问本地磁盘还是网络共享，Windows 资源管理器有时会挂起几秒钟。

但经过一番调查后，我相信挂起是由类似的 NetBIOS 问题引起的。

一些系统细节：

  • Windows XP 专业版 SP3
  • 已安装 VMware Server 1.0.9
  • 已启用 VMNet1（仅主机）网络适配器和 NetBOIS over TCP/IP
  • 已启用 VMNet8 (NAT) 网络适配器和 NetBOIS over TCP/IP
  • 系统的唯一物理网络适配器的静态 IP 地址为 192.168.10.111。此适配器配置为使用 192.168.10.192 作为其唯一的 WINS 服务器。MAC 地址：00-16-17-FA-2C-D4
  • 在 VMNet1 适配器上，系统的静态 IP 地址为 192.168.137.1。未配置 WINS 服务器。MAC 地址：00-50-56-C0-00-01
  • 在 VMNet8 适配器上，系统的静态地址为 192.168.145.1。未配置 WINS 服务器。MAC 地址：00-50-56-C0-00-08
  • 所有虚拟机都配置为使用 NAT 但无论如何都被停止了。

我整天都在运行 Wireshark 嗅探物理适配器上的数据包。我注意到，每当 Explorer 挂起几秒钟时，就会同时向 WINS 服务器发送一个 NetBIOS 名称服务查询数据包。这些数据包包含 VMNet 适配器的地址之一作为其源 IP 地址！

以下是其中一个可疑数据包：

Frame 25475 (92 bytes on wire, 92 bytes captured)
Ethernet II, Src: 00:16:17:fa:2c:d4 (00:16:17:fa:2c:d4), Dst: 00:15:c5:87:4f:6a (00:15:c5:87:4f:6a)
Internet Protocol, Src: 192.168.145.1 (192.168.145.1), Dst: 192.168.10.192 (192.168.10.192)
User Datagram Protocol, Src Port: netbios-ns (137), Dst Port: netbios-ns (137)
NetBIOS Name Service
  Transaction ID: 0x82a5
  Flags: 0x0000 (Name query)
  Questions: 1
  Answer RRs: 0
  Authority RRs: 0
  Additional RRs: 0
  Queries
    *<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>: type NBSTAT, class IN

我认为这不对。数据包的源 IP 地址应设置为 192.168.10.111。

我没有在 WINS 服务器的接口上嗅探数据包。但是我预计它会通过其默认网关向 192.168.145.1 发送回复，因为它未连接到 192.168.145.0 网络。网关应该拒绝此数据包并提示“网络不可达”。

由于这是 UDP 数据包，因此没有处于 SYN_SENT 状态的连接。但是，以同样方式“损坏”的 TCP SYN 数据包应该让连接处于 SYN_SENT 状态，直到发生超时。

我尝试了一些方法来解决这个问题：

  1. 禁用两个 VMNet 适配器：问题解决。没有可疑数据包。
  2. 重新启用 VMnet1：Explorer 有时会再次挂起。来源为 192.168.137.1 的可疑数据包。
  3. 禁用 VMNet1 并重新启用 VMNet8：Explorer 有时会挂起。来源为 192.168.145.1 的可疑数据包。
  4. 启用两个 VMNet 适配器，但禁用两者的 TCP/IP 上的 NetBIOS：问题已解决。没有可疑数据包。
  5. 为 VMNet1 重新启用 TCP/IP 上的 NetBIOS：Explorer 有时会再次挂起。来源为 192.168.137.1 的可疑数据包。
  6. 禁用 VMNet1 的 TCP/IP 上的 NetBIOS，然后重新启用 VMNet8 的 TCP/IP 上的 NetBIOS：Explorer 有时会挂起。来源为 192.168.145.1 的可疑数据包。
  7. 将所有接口的接口度量从自动度量更改为静态值。具有最低度量的 LAN 适配器：Explorer 有时仍会挂起，并捕获可疑数据包。

我已经检查了网络中的适配器排序连接->高级->高级设置以及运行netsh 接口 ip 显示配置。本地连接是两个地方列出的第一个连接。

此外，我注意到一些源 IP 地址为 192.168.137.1 和 192.168.145.1 的 NTP 数据包通过物理适配器发送到 192.168.10.192（它是一个 AD DC）。

答案2

同样的问题。使用 wireshark 捕获可疑数据包：协议：NBNS，信息：名称查询 NBSTAT

尽管配置了 NAT，但具有来自 vmnet8 的 IP 的数据包仍在物理网络上发送！

  • 禁用“WAN 上的 Netbios”-> 物理连接上没有发送任何可疑数据包（带有 vmnet8 的发送方 IP）。
  • 在 vmware quest 中禁用 samba 服务 -> 没有发送可疑数据包

看来这个奇怪的 NetBIOS 东西没有被 vmware NAT ！

冈特。

答案3

我的经验发现，Vmware NAT 功能有限。在其他网络模式下，某些类型的数据包不会返回。我认为这是 Vmware 处理网络数据的一个错误。

相关内容