Однажды я заметил, что с ноутбука очень долго загружались фотографии в Google Photos. Я посмотрел торренты, и они тоже раздавались со скоростью значительно ниже ожидаемой. Зайдя в SpeedTest, я увидел такую картину:

Я начал разбираться…

[+] Сегодня в программе

Первый этап диагностики

Мой ноутбук был подключен по Wi-Fi к двухдиапазонному маршрутизатору ASUS RT-N66U. Низкая скорость наблюдалась на обеих частотах, однако в других ПК и телефоне все было нормально. С подключением к проводной сети при отключенном Wi-Fi все тоже было в порядке.

Все пути вели к беспроводному адаптеру Intel Centrino Advanced-N 6205 в ноутбуке. Он был не новый, и свежие драйверы к нему давно не выпускали. У меня была установлена последняя версия с WU. Поэтому я с легким сердцем удалил адаптер из диспетчера устройств, добавил снова, и все наладилось.

Повод для рассказа появился, когда спустя какое-то время проблема повторилась. Я воткнул кабель Ethernet, но скорость исходящего соединения осталась низкой. Отключился от Wi-Fi – скорость поднялась к ожидаемым 90+ Мбит/с.

Получается, при подключении одновременно к Ethernet и Wi-Fi система использовала беспроводное соединение с возродившейся проблемой.

О виртуальных коммутаторах Hyper-V и приоритете маршрутов

На каждом заборе написано, что в Windows проводное подключение имеет приоритет над беспроводным. Другими словами, если вы одновременно подключены к Ethernet и Wi-Fi, в Интернет вы будет ходить по проводу.

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

Виртуальные коммутаторы

У меня виртуальные машины крутятся на Hyper-V, а в сеть ходят через созданный виртуальный коммутатор. Поскольку ноутбук почти всегда был подключен только к Wi-Fi, виртуальный коммутатор я создавал на основе адаптера беспроводной сети. Появившийся позже в 1709 «коммутатор по умолчанию» я не использовал.

Когда я удалил беспроводной адаптер из диспетчера устройств, мой виртуальный коммутатор исчез, но я заметил это не сразу, а только спустя некоторое время при следующем включении ВМ – в ней не было сети.

Я создал виртуальный коммутатор заново, но измерить скорость исходящих подключений в тот момент мне в голову не пришло. Лишь напоровшись на проблему снова, я назначил Hyper-V главным подозреваемым.

Дело в том, что хост использует виртуальный сетевой адаптер vEthernet для подключения к сети. Даже если виртуальный коммутатор Hyper-V основан на беспроводном адаптере, подключение к vEthernet считается проводным.

Это не вполне очевидно, хотя название адаптера намекает :)

Приоритет маршрутов

При этом у меня подключение по vEthernet преобладало над обычным проводным подключением Ethernet. Сам я приоритеты не менял, но на всякий случай убедился в этом.

Приоритет маршрута определяется метрикой, и в дополнительных параметрах IPv4 сетевого адаптера можно посмотреть, задается ли она автоматически (и указать значение, если нужно).  Но давайте перейдем в командную строку.

Настройка приоритетa для сетевых интерфейсов

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

Команда ipconfig /all выводит список сетевых адаптеров и их IP-адреса.

ipconfig /all                                                                                   

Ethernet adapter Ethernet:
   Description . . . . . . . . . . . : Intel(R) 82579LM Gigabit Network Connection
   IPv4 Address. . . . . . . . . . . : 192.168.1.149(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0

Ethernet adapter vEthernet (Wi-Fi):
   Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter
   IPv4 Address. . . . . . . . . . . : 192.168.1.211(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0

Ethernet adapter vEthernet (Default Switch):
   Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #2
   IPv4 Address. . . . . . . . . . . : 192.168.70.17(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.240

Сводку по сетевым интерфейсам выдает команда netstat -rn | more.

netstat -rn | more                                                                              ===========================================================================
Interface List
  4...3c 97 0e ce b8 41 ......Intel(R) 82579LM Gigabit Network Connection
 32...a4 4e 31 94 9a 28 ......Hyper-V Virtual Ethernet Adapter
 22...a4 4e 31 94 9a 29 ......Microsoft Wi-Fi Direct Virtual Adapter #4
 10...a6 4e 31 94 9a 28 ......Microsoft Wi-Fi Direct Virtual Adapter #5
  9...3c 77 e6 ed 0d 46 ......Bluetooth Device (Personal Area Network)
  1...........................Software Loopback Interface 1
 64...00 15 5d 18 c5 02 ......Hyper-V Virtual Ethernet Adapter #2
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.1.1    192.168.1.211     10
          0.0.0.0          0.0.0.0      192.168.1.1    192.168.1.149     20
===========================================================================

В первом блоке можно определить приоритет сетевого интерфейса по номеру слева – чем меньше номер, тем выше приоритет. Значение метрики для интерфейса отображается во втором блоке – таблице маршрутов IPv4.

В результатах команд видно, что маршрут через виртуальный адаптер 192.168.1.211 преобладает над проводным 192.168.1.149.

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

netsh interface show interface                                                                  
Admin State    State          Type             Interface Name
-------------------------------------------------------------------------
Enabled        Connected      Dedicated        Wi-Fi
Enabled        Connected      Dedicated        Local Area Connection* 3
Enabled        Connected      Dedicated        vEthernet (Wi-Fi)
Enabled        Connected      Dedicated        Network Bridge
Enabled        Connected      Dedicated        Ethernet
Enabled        Connected      Dedicated        vEthernet (Default Switch)

Затем указал метрики, поменяв значения местами:

netsh interface IP set interface interface="Ethernet" metric=10
netsh interface IP set interface interface="vEthernet (Wi-Fi)" metric=20

Теперь, подключив одновременно Ethernet и Wi-Fi, я убедился в высокой скорости исходящего соединения. Проводное соединение получило приоритет, но проблему низкой скорости по Wi-Fi это не решало, конечно.

Второй этап диагностики

В настройках Hyper-V я удалил попавший под подозрение коммутатор, что убрало связь между адаптером Wi-Fi и виртуальным адаптером Hyper-V. Без лишней прокладки адаптер беспроводной сети работал как положено – скорость исходящего соединения пришла в норму.

Я пообщался с Денисом Дягилевым, и он, в принципе, задал верное направление диагностики – параметры Virtual Machine Queue (VMQ). Однако такой настройки в настройках адаптера у меня не нашлось.

Решение

Первой мыслью было занести баг в Feedback Hub, но сначала положено искать, чтобы не плодить дубликатов. По запросу hyper- v switch нашлось описание моей проблемы, а заодно и обходной путь – отключение параметра Large Send Offload Version 2 (IPv4) в параметрах виртуального адаптера Hyper-V.

Эти же сведения можно посмотреть в PowerShell:

Get-NetAdapterAdvancedProperty -Name vEthernet* | ? DisplayName -like 'Large Send Offload*' | ft -wrap

Name                      DisplayName                    DisplayValue                   RegistryKeyword RegistryValue
----                      -----------                    ------------                   --------------- -------------
vEthernet (Wi-Fi)    Large Send Offload Version 2   Enabled                        *LsoV2IPv4      {1}
                          (IPv4)
vEthernet (Wi-Fi)    Large Send Offload Version 2   Enabled                        *LsoV2IPv6      {1}
                          (IPv6)

и поменять значение, не покидая консоль:

Get-NetAdapterAdvancedProperty -Name vEthernet* | ? DisplayName -like 'Large Send Offload*v4*' | 
Set-NetAdapterAdvancedProperty -DisplayValue "Disabled"

Изменив настройки адаптера, я заново создал виртуальный коммутатор и проверил скорость – все наладилось.

Конец квеста!

Заключение

Эта история произошла в 2018 году. Регрессия возникла в Windows 10 1809. Поскольку основная система у меня была в кольце Release Preview (RP), я напоролся на проблему еще до того, как сборку отозвали. Дефект устранили в декабре 2018 года накопительным обновлением KB4469342, первом после перевыпуска 1809. Мне в RP оно пришло чуть раньше, я протестировал и отписался в комментариях к статье о белках-истеричках.

Я писал материал по горячим следам, но Денис Дягилев подал идею протестировать пользу параметра Large Send Offload в практических сценариях. Времени на это я так и не нашел. А когда Microsoft устранила проблему, публикация вроде бы стала неактуальной. И я замариновал статью в черновиках – почти на 5 лет 🤷‍♂️

Однако за эти годы вопросы приоритета сетевых интерфейсов и особенно параметра Large Send Offload обсуждалась в чате неоднократно. И каждый раз я сетовал, что не выпустил статью в свет. На прошлой неделе тема LSO вновь всплыла 🍑🔥 со вполне современным сетевым адаптером, что окончательно убедило меня выложить материал в блог.

Бонус: о приоритете сетевых интерфейсов (когда метрики не помогают)

Иногда желаемого результата не удается достичь, меняя метрики маршрутов. Все равно LAN имеет приоритет над Mobile broadband, а Bluetooth PAN над WWAN (внезапно). В таких случаях должна помочь групповая политика, о которой я написал в канале.