(Перемещено сюда из StackOverflow)
Некоторое время назад почти все рабочие станции в нашей команде (Windows XP SP2) имели прерывистые, но частые задержки при доступе к общим ресурсам в сети. Обычно первый доступ к общему ресурсу, к которому не было доступа в течение некоторого времени, приводил к почти зависанию рабочей станции на срок до 30 секунд. Потом все снова стало нормально работать.
Используя TCPView от Sysinternals, я увидел, что во время этих задержек было соединение с netbios-ssn порт на файловом сервере, который был в состоянии SYN_SENT.
Первая попытка:
Отключить NetBIOS через TCP / IP для сетевого адаптера интрасети.
Проблема решена, но мне не нравилось манипулировать нашей централизованно управляемой сетевой конфигурацией для интрасети.
Вторая попытка:
Отключить NetBIOS через TCP / IP только для сетевого адаптера VMWare (VMNet1 используется только для связи с хостом).
Проблема снова решена!
Мои вопросы:
Дополнительная информация:
Я видел подобное явление.
На первый взгляд симптомы кажутся не слишком похожими: Windows Explorer иногда зависает на несколько секунд независимо от того, осуществляется доступ к локальному диску или к общему сетевому ресурсу.
Но после некоторого расследования я считаю, что зависание вызвано аналогичной проблемой NetBIOS.
Некоторые детали системы:
Я весь день запускал Wireshark, прослушивая пакеты на физическом адаптере. Я заметил, что всякий раз, когда Explorer зависал на несколько секунд одновременно, пакет запроса службы имен NetBIOS отправлялся на WINS-сервер. Эти пакеты содержали один из адресов адаптера 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, пока не истечет время ожидания.
Некоторые вещи, которые я пытался обойти эту проблему:
Я проверил заказ адаптера в сети Подключения-> Дополнительно-> Расширенные настройки а также запустив netsh interface ip show config. Подключение по локальной сети - первое соединение, указанное в обоих местах.
Кроме того, я заметил, что некоторые пакеты NTP с исходным IP-адресом 192.168.137.1, а также 192.168.145.1 отправляются на 192.168.10.192 (это AD DC) через физический адаптер.
Мой опыт показывает, что Vmware NAT - это ограниченные возможности. Также в других сетевых режимах некоторые типы пакетов не возвращаются. Я думаю, что это ошибка в том, как Vmware обрабатывает сетевые данные.
такая же проблема здесь. Захваченные подозрительные пакеты с помощью wirehark: Протокол: NBNS, Информация: Запрос имени NBSTAT
Пакеты с IP от vmnet8 отправляются в физическую сеть, хотя NAT настроен!
Кажется, что эта странная вещь NetBIOS не поддерживает NAT с помощью vmware!
Гюнтер.