Отброшенные пакеты, только при получении, только в Server 2008 и скорости сети 100 Мбит / с

Это звучит как несоответствие скорости / дуплекса, вызывающее столкновения и повторные передачи. Это может привести к неправильной настройке между сервером и другой стороной. Еще одной причиной несоответствия может быть сбой автосогласования.

Убедитесь, что оба конца соединения настроены одинаково относительно скорости и дуплекса.

Я полагаю, вам следует выяснить, относятся ли какие-либо из настроек драйвера NIC / разгрузки NDIS к Windows к вашей проблеме. Я наиболее подозрительно отношусь к функции LSO (Large Send Offload), так как видел, что она полностью разрушает службу (сервер Dell с Broadcom NIC) способом, который не поддается никаким определениям книг по устранению неполадок.

Фактический эффект LSO, когда он нарушает, а не усиливает, состоит в том, что механизм LSO может передавать большие кадры данных, которые поддерживает коммутатор. Это заставляет коммутатор молча отбрасывать эти кадры. Излишне говорить, что это приводит к снижению производительности и потере пакетов. Отказ может быть неизбежным, но также может быть прерывистым, что чрезвычайно затрудняет поиск и устранение неисправностей. Это подробно описано здесь: большая разгрузка при отправке и производительность сети

Отказ от ответственности: это всего лишь наилучшие мысли о возможном ракурсе вашей проблемы. Внедрение любого из приведенных ниже изменений нарушит вашу сетевую связь. Компьютер должен быть перезагружен после применения любых настроек. Я копирую / вставляю наиболее интересные настройки для справки, но ссылки содержат всю хардкорную информацию и предостережения. Я настоятельно рекомендую использовать официальные документы в качестве основы для изменений, и этот пост в большинстве своем напоминает контрольный список.

Прежде чем продолжить с этим, сделайте резервную копию вашего реестра:

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Одна из причин отсутствия охлаждения связана с официальной ошибкой, описанной ниже, которая изменяет некоторые несвязанные значения при отправке определенных настроек через командную строку.

Я свободно признаю, что там, где настройки присутствуют как в графическом интерфейсе драйвера сетевой платы Windows, так и в Windows, я никогда не получал ясности в том, нужно ли отключать как в графическом интерфейсе, так и через CMD/Registry Windows, или если этого достаточно. Блоги, которые я читал и в которых содержался ответ, были несовместимы с некоторыми мелкими деталями, поэтому я никогда не был уверен. В настоящее время я пытаюсь измениться везде, где я нахожу возможность выбрать ту настройку, на которой я сосредоточен. Опции GUI здесь не представлены, но описаны в официальных документах.

Кроме того, разные драйверы NIC для одной и той же карты могут иметь разную степень детализации в дополнительных настройках в графическом интерфейсе.

Отключение выгрузки задач

Этот параметр реестра отключает разгрузку задач, как указано в разделе "Использование значений реестра для включения и отключения разгрузки подключений".

HKLM\System\CurrentControlSet\Services\TCPIP\Parameters\DisableTaskOffload
Setting this value to one disables all of the task offloads from the TCP/IP
transport. Setting this value to zero enables all of the task offloads.

Если вышеуказанные настройки имеют какой-либо эффект, вы можете попытаться перейти на гранулярный, как указано в ссылке. Существует множество параметров, регулирующих это, поэтому я не буду вставлять их все.

Я поставлю LSO, хотя:

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\LsoV1IPv4
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\LsoV2IPv4
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\LsoV2IPv6

For all three: Enabled = 1(default). Disabled = 0.

Отключение разгрузки соединения

Как определено в разделе Использование значений реестра для включения и отключения разгрузки соединения.

HKLM\System\CurrentControlSet\Services\TCPIP\Parameters\TCPConnectionOffloadIPv4
Describes whether the device enabled or disabled the offload of TCP connections
over IPv4. Enabled = 1 (Default). Disabled = 0.

HKLM\System\CurrentControlSet\Services\TCPIP\Parameters\TCPConnectionOffloadIPv6
Describes whether the device enabled or disabled the offload of TCP connections
over IPv6. Enabled = 1 (Default). Disabled = 0.

Отключение TCP Chimney, TOE и TSO

Как указано в разделе Как отключить TCP-дымоход, механизм разгрузки TCPIP (TOE) или разгрузку сегментации TCP (TSO), обратите внимание на исправление Win2008

и в разделе Сведения о функциях разгрузки TCP-канала, масштабирования на стороне приема и прямого доступа к сети в Windows Server 2008.

Windows 2008 Server:
If the operating system is Microsoft Windows Server 2008 (any version
including R2), run the following from a Command prompt:

1. netsh int tcp set global chimney=disabled
2. netsh int tcp set global rss=disabled
3. netsh int tcp set global netdma=disabled

Note: To display current global TCP settings, use the net shell command:
netsh int tcp show global

4. Restart the server.

Note: Microsoft has identified an issue running the netsh command to set global
TCP parameters on Windows Server 2008 and Vista machines.  Some global
parameters, such as TCPTimedWaitDelay, can be changed from their default or
manually set values to 0xffffffff.  Before running the above command, Symantec
recommends reviewing Microsoft KB Article 967224 (support.microsoft.com/kb/967224).
Upon completion of the above command's execution, Symantec also recommends
reviewing the TCP Parameters noted in the KB Article and applying the hotfix from
the article if needed.

`Исправление описывает проблему следующим образом:

After you run the command, the values of the following unrelated settings are
changed to 0xFFFFFFFF:
KeepAliveInterval
KeepAliveTime
TcpTimedWaitDelay

In addition, the "TcpMaxDataRetransmissions" are changed to 0xFF.

Опять же, поэтому вы можете сделать резервную копию всего раздела реестра, прежде чем делать что-либо:

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Если вы решите проблему с помощью выгрузки основных моментов, указанных выше, вы не найдете конца публикациям, статьям и блогам, описывающим подобные проблемы из-за разгрузки NIC. Но если это все еще не работает, то я думаю, что вы можете перейти вверх по стеку, чтобы попробовать другие вещи, потому что это не из-за полуразрушенного кабеля, сетевой платы или порта коммутатора, верно?

Всегда смотрите на сетевое устройство для подсказок..... так, если cisco, делает "show interfaces f0/11" или что бы то ни было в вашем случае. повторные передачи также могут быть вызваны неправильным портом Ethernet / nic / кабелем, например, из-за "перекрестных помех"..... show int на коммутаторе должен показать вам эту статистику ошибок, если это так, и это, очевидно, будет слишком высоко

РЕДАКТИРОВАТЬ: так как это Microsoft, скорее всего, это ваша проблема, но, кроме этого, в общем, начните с первого уровня (убедитесь, что физические кабели хороши), и продвинуться вверх по стеку... то есть слой 2, скорость / дуплекс / макинтош адрес трепетает, затем брандмауэр ip / udp / tcp 3-го уровня и т. д.

Это также могут быть "расширенные" атрибуты NIC, например, атрибуты PowerManagement или приоритет IRQ. Предполагая, что у вас та же версия драйверов. Идти к:

Device Manager -> Network Interfaces -> Properties для NIC -> Advanced Tab,

Проверьте и сравните все значения здесь.

Эффекты, которые вы описываете в своих последующих выводах, соответствуют принципам работы IEEE 802.3u:

• Если вы жестко установите скорость одного из интерфейсов (NIC/Switchport) и установите для другого значение Авто, вы, вероятно, столкнетесь с несоответствием дуплексного режима.

• Если вы жестко настроили один из интерфейсов на полный дуплекс, другой не сможет автоматически согласовать дуплекс, но он также должен быть жестко настроен.

• Даже если оба интерфейса жестко настроены на автоматический / полный дуплекс, некоторые сетевые адаптеры (или плохо написанные драйверы Windows) по-прежнему оставляют автоматическое согласование в рабочем режиме и по умолчанию полудуплексный.

Вот где я получил эти факты:

Два документа от Cisco относятся (среди прочего) к коммутаторам серии 2900 и сетевым адаптерам для устранения проблем с подключением портов. Они включают конкретные действия по устранению неполадок, особенно для коммутатора, а также для сетевых адаптеров. Поскольку Cisco является лидером по практическому сетевому анализу, включая глубокое знание фундаментальных предварительных условий (таких как электрический протокол автоматического согласования), вполне вероятно, что PowerConnect имеет схожие рабочие условия (разработанные в соответствии с теми же стандартами протокола). Я приведу свободную цитату для полноты и уточню ее чуть позже, но я бы призываю вас просмотреть их:

Устранение неполадок коммутаторов Cisco Catalyst с проблемами совместимости сетевых карт

Конфигурирование и устранение неполадок Ethernet 10/100/1000 Мб / полудуплексное автоматическое согласование

Здесь я процитирую некоторые действительно интересные вещи:

Действительная таблица конфигурации автосогласования

Speed determination issues can result in no connectivity. However, issues 
with autonegotiation of duplex generally do not result in link establishment
issues. Instead, autonegotiation issues mainly result in performance-related
issues. The most common problems with NIC issues deal with speed and duplex
configuration.  

Table 1 summarizes all possible settings of speed and duplex for FastEthernet 
NICs and switch ports.

Затем следует чрезвычайно полезная таблица, которую я постараюсь перенести сюда позже, не теряя форматирования. Таблица также включает комбинации скорости 1 Гбит / с с похожими интересными эффектами и комментариями. Тем не менее, основные моменты включают в себя:

* Configuration NIC (Speed/Duplex): 100Mbps, full duplex
* Configuration Switch (Speed/Duplex): auto
* Resulting NIC Speed/Duplex: 100Mbps
* Resulting Catalyst Speed/Duplex: 100Mbps half duplex
Comments: duplex mismatch (footnote 1)

* Configuration NIC (Speed/Duplex): auto
* Configuration Switch (Speed/Duplex): 100Mbps, full duplex
* Resulting NIC Speed/Duplex: 100Mbps full duplex
* Resulting Catalyst Speed/Duplex: 100Mbps half duplex
Comments: duplex mismatch (footnote 1)

* Configuration NIC (Speed/Duplex): 100Mbps, full duplex
* Configuration Switch (Speed/Duplex): 100Mbps, full duplex
* Resulting NIC Speed/Duplex: 100Mbps, full duplex
* Resulting Catalyst Speed/Duplex: 100Mbps, full duplex
Comments: Correct manual config (footnote 2)

Сноски таблицы наиболее интересны:

(1) A duplex mismatch can result in performance issues, intermittent
connectivity, and loss of communication. When you troubleshoot NIC issues,
verify that the NIC and switch use a valid configuration.

(2) Some third-party NIC cards can fall back to half-duplex operation mode,
even though both the switchport and NIC configuration are manually configured
for 100 Mbps, full-duplex. This is because NIC autonegotiation link detection
still operates when the NIC is manually configured. This causes duplex
inconsistency between the switchport and the NIC. Symptoms include poor port  
performance and frame check sequence (FCS) errors that increment on the
switchport. In order to troubleshoot this issue, try to manually configure
the switchport to 100 Mbps, half-duplex. If this action resolves the
connectivity problems, this NIC issue is the possible cause. Try to update
to the latest drivers for your NIC, or contact your NIC card vendor for
additional support.

Почему скорость и дуплекс не могут быть жестко закодированы только для одного партнера Link?

As indicated in Table 1, a manual setup of the speed and duplex for
full-duplex on one link partner results in a duplex mismatch. This happens
when you disable autonegotiation on one link partner while the other link
partner defaults to a half-duplex configuration. A duplex mismatch results
in slow performance, intermittent connectivity, data link errors, and other
issues. If the intent is not to use autonegotiation, both link partners must
be manually configured for speed and duplex for full-duplex settings.

Самая последняя тема ссылки на совместимость с NIC содержит техническую основу для эффектов, описанных в приведенных выше отрывках. Основой для этого фона являются некоторые ключевые детали работы протокола автосогласования:

(Table of bits shortened down for relevance)
0.13     Rate Selection (least-significant bit [LSB])
             0.6 0.13 1 1 reserved
             1 0 1000 Mbps : 0 1 100 Mbps : 0 0 10 Mbps

0.12     Autonegotiation Enable 
             1 = autonegotiaton enabled
             0 = autonegotiation disabled

0.8  Duplex Mode     1 = full-duplex 0 = half-duplex

0.6  Rate Selection (most-significant bit [MSB]). See bit 0.13

The register bits relevant to this document include 0.13, 0.12, 0.8, and 0.6.
The other register bits are documented in the IEEE 802.3u specification.
Based on IEEE 802.3u, in order to manually set the rate (speed), the
autonegotiation bit, 0.12, must be set to a value of 0. As a result,
autonegotiation must be disabled in order to manually set the speed and
duplex.
If the autonegotiation bit 0.12 is set to a a value of 1, bits 0.13 and 0.8
have no significance, and the link uses autonegotiation to determine the
speed and duplex. When autonegotiation is disabled, the default value for
duplex is half-duplex, unless the 0.8 is programmed to 1, which represents
full-duplex.

Based on IEEE 802.3u, it is not possible to manually configure one link
partner for 100 Mbps, full-duplex and still autonegotiate to full-duplex
with the other link partner. If you attempt to configure one link partner
for 100 Mbps, full-duplex and the other link partner for autonegotiation,
it results in a duplex mismatch. This is because one link partner
autonegotiates and does not see any autonegotiation parameters from the
other link partner and defaults to half-duplex.

Кроме того, я нашел сообщения об ошибках аналогичного эффекта от Cisco, но они очень специфичны в отношении комбинаций аппаратного / программного обеспечения коммутатора, версии ОС, сетевых адаптеров и драйверов. Не зная точных деталей, это становится слишком умозрительным.

Я полагаю, что это может быть только подтверждением ваших выводов посредством определения протокола и операнда.

Решения

Итак, предполагая, что это была не дикая (но веселая) погоня за гусем, я цитирую вас:

1) "Если я установлю каждый интерфейс, сервер, клиент и коммутатор Cisco 2960 на 100 Мбит / с, то проблема исчезнет. Если я установлю сервер и интерфейс коммутатора автоматически или 1 Гбит, проблема вернется".

2) "Если я обойду коммутатор с помощью коммутатора Netgear 10/100 и настрою и клиента, и сервер на автоматический режим, у меня не возникнет проблем".

3) Попробуйте найти комбинации сетевых карт и драйверов, совместимые со старыми коммутаторами. Покупка как необходимая.

4) Используйте надежные технические ссылки и аргументацию, чтобы мотивировать бюджет на модернизацию коммутаторов там, где это необходимо.

Вы проверяли, что в вашей сети 100/1000 отключены большие кадры?

UPD:

Если используются гигантские кадры, то это должно использоваться всем оборудованием для сетевого вещания в широковещательном домене. Это невозможно с устаревшими устройствами 100 Мб.

Я не знаю, как именно работает win2008 tcp, но, предоставляя jombo-кадры, он может начать масштабирование окна передачи с размером пакета (а не количеством пакетов, как обычно). Тогда вы будете наблюдать ситуацию, как описано.

К вашему сведению: http://m.windowsitpro.com/windows/q-how-do-i-enable-jumbo-frames

UPD2:

Я посмотрел на дамп пакета, который вы предоставили, и увидел много пакетов с длиной> 1500 и неправильными контрольными суммами (контрольные суммы для длин < 1500 в порядке). Это подтверждает мое предположение.

Единственное, чего я не могу понять - они имеют отношение к первому сеансу: от клиента к серверу (!!!???):

22:25:06.041113 IP (tos 0x0, ttl 128, id 31391, offset 0, flags [DF], proto TCP (6), length 40)  192.168.0.109.49225 > 192.168.0.252.microsoft-ds: Flags [.], cksum 0x9422 (correct), ack 1453, win 1234, length 0

22:25:06.041223 IP (tos 0x0, ttl 128, id 31392, offset 0, flags [DF], proto TCP (6), length 64280, bad cksum 0 (->285)!) 192.168.0.109.49225 > 192.168.0.252.microsoft-ds: Flags [.], cksum 0x82c0 (incorrect -> 0xc9bb), seq 718652:782892, ack 1453, win 1234, length 64240SMB-over-TCP packet:(raw data or continuation?

22:25:06.041254 IP (tos 0x0, ttl 128, id 31437, offset 0, flags [DF], proto TCP (6), length 1452) 192.168.0.109.49225 > 192.168.0.252.microsoft-ds: Flags [P.], cksum 0x0517 (correct), seq 782892:784304, ack 1453, win 1234, length 1412SMB-over-TCP packet:(raw data or continuation?)

22:25:06.041278 IP (tos 0x0, ttl 128, id 31438, offset 0, flags [DF], proto TCP (6), length 2960, bad cksum 0 (->f1df)!) 192.168.0.109.49225 > 192.168.0.252.microsoft-ds: Flags [.], cksum 0x82c0 (incorrect -> 0xfa12), seq 784304:787224, ack 1453, win 1234, length 2920SMB-over-TCP packet:(raw data or continuation?)

22:25:06.042134 IP (tos 0x0, ttl 128, id 31441, offset 0, flags [DF], proto TCP (6), length 2960, bad cksum 0 (->f1dc)!) 192.168.0.109.49225 > 192.168.0.252.microsoft-ds: Flags [.], cksum 0x82c0 (incorrect -> 0x1d7e), seq 787224:790144, ack 1453, win 1234, length 2920SMB-over-TCP packet:(raw data or continuation?)

22:25:06.042492 IP (tos 0x0, ttl 128, id 31444, offset 0, flags [DF], proto TCP (6), length 5880, bad cksum 0 (->e671)!) 192.168.0.109.49225 > 192.168.0.252.microsoft-ds: Flags [.], cksum 0x82c0 (incorrect -> 0xa74e), seq 790144:795984, ack 1453, win 1234, length 5840SMB-over-TCP packet:(raw data or continuation?)