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

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

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

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

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

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

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

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

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

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

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

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

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

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 Chimney, TCPIP Offload Engine (TOE) или TCP Segmentation Offload (TSO) Обратите внимание на исправление Win2008

И в Информация о функциях TCP Chimney Offload, Receive Side Scaling и Network Direct Memory Access в 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

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

Это также могут быть «расширенные» атрибуты сетевого адаптера, такие как атрибуты управления питанием или приоритет IRQ. Если у вас одна и та же версия драйверов. Перейти к:

Device Manager -> Network Interfaces -> Properties для сетевой карты -> Advanced Tab.

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

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

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

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

UPD:

Если используются jumbo-кадры, то все сетевое оборудование в широковещательном домене должно использовать его. Это невозможно с устаревшими устройствами на 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?)

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

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

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

• Даже если оба интерфейса жестко настроены на автоматический / полный дуплекс, некоторые сетевые адаптеры (или плохо написанные драйверы 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.

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

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 Compatibility содержит техническую основу для эффектов, описанных в цитированных выше отрывках. Основой для этого являются некоторые ключевые детали работы протокола автосогласования:

(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) Используйте надежные технические ссылки и аргументы, чтобы мотивировать бюджет на модернизацию коммутаторов там, где это необходимо.