Настройка контроллеров домена в разных подсетях

Длина маски подсети

Рассмотрим пример. Маршрутизатор принял пакет на ip-адрес (192.168.100.23), в таблице маршрутизации есть 2 записи (192.168.100.0/24 и 192.168.0.0/16) под который подходит этот ip-адрес, но у них разная длина маски. Какую из этих записей выбрать? Выбирается та запись, где маска длиннее, предполагается, что запись с более длинной маской содержит лучший маршрут интересующей нас сети.

Чтобы понять почему так происходит, давайте рассмотрим составную сеть гипотетического университета. Университет получил блок ip-адресов, разделил этот блок ip-адресов на две части, и каждую часть выделил отдельному кампусу.

На кампусе находятся свои маршрутизаторы, на которых сеть была дальше разделена на части предназначенные для отдельных факультетов. Разделение сетей производится с помощью увеличения длины маски, весь блок адресов имеет маску / 16, блоки кампусов имеют маску / 17, а блоки факультетов / 18.

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

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

И так получается, что выбирается всегда маршрут с маской максимальной длины. Общие правила выбора маршрутов следующие.

Самая длинная маска 32 — это маршрут конкретному хосту, если в таблице маршрутизации есть такой маршрут, то выбирается он.
Затем выполняется поиск маршрута подсети с маской максимальной длины.
И только после этого используется маршрут по умолчанию, где маска / 0 под которую подходят все ip-адреса.

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

Как правило такая таблица содержит описание присоединенной сети, который подключен данный компьютер.
Адрес маршрутизатора по умолчанию (шлюз или gateway) через который, выполняется подключение к интернет, или к корпоративной сети предприятия.
А также могут быть дополнительные маршруты к некоторым знакомым сетям, но это необязательно.

Для того чтобы просмотреть таблицу маршрутизации, можно использовать команды route или ip route (route print (Windows); route и ip route (Linux)).

Маршрутизация — поиск маршрута доставки пакета между сетями через транзитные узлы — маршрутизаторы.

Анонимайзеры

Анонимайзерами называют сервисы, представляющие собой самый простой вид прокси-сервера, не требующий изменения настроек компьютера. Адрес IP изменяется только для одного конкретного перехода на сайт. В списке самых популярных анонимайзеров можно найти proxylistpro.com или 2ip. Некоторыми из них можно пользоваться бесплатно, за услуги других придётся заплатить. Для проверки эффективности смены IP-адреса анонимайзером следует сначала определить свой адрес с помощью специального сервиса. Затем перейти на эту же страницу с помощью такого анонимного прокси. Если адреса для первого и второго входа на определяющий IP сервис будут разными, значит, анонимайзер работает и его услугами можно пользоваться.

Настройка Windows 2016 Server для виртуальной машины с приватным IP адресом

А вот эта часть меня неожиданно подкосила. Нам надо вывести в большой и взрослый интернет VM2 и VM3 с приватными адресами. Для этого нам нужен хоть какой-нибудь роутинг.

И вот тут я честно скажем затупил. Решение в виде установки роли Remote Access, чтобы получить Routing тянуло за собой полный IIS. Мне совсем не понятно зачем это Microsoft и поэтому от этой идеи я отказался. Тут я подумал что это тупик. Но потом вспомнил, а зачем нам полноценный роутинг, если нам надо просто выпустить машины в интернет. Для этого же есть NAT. Осталось каким-то образом получить виртуальный сетевой интерфейс, к которому мы потом будет подключать виртуальные машины. И вот тут незнание Windows меня очень сильно затормозило. Но в итоге решение оказалось в паре команд на PowerShell.

Настройка виртуальных локальных сетей для Hyper-V

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

Для настройки виртуальных ЛС потребуется следующее:

Физический сетевой адаптер и драйвер, поддерживающие маркировку VLAN 802.1 q.
Физический сетевой коммутатор, поддерживающий маркировку VLAN 802.1 q.

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

Чтобы разрешить виртуальному коммутатору использовать виртуальную ЛС

Откройте — Диспетчер Hyper V.

В меню Действия выберите пункт Диспетчер виртуальных коммутаторов.

В разделе виртуальные коммутаторы выберите виртуальный коммутатор, подключенный к физическому сетевому адаптеру, который поддерживает виртуальные ЛС.

В области справа в разделе идентификатор виртуальной ЛС выберите включить идентификацию виртуальной локальной сети , а затем введите номер виртуальной ЛС.

Весь трафик, проходящий через физический сетевой адаптер, подключенный к виртуальному коммутатору, будет помечен заданным ИДЕНТИФИКАТОРом виртуальной ЛС.

Чтобы разрешить виртуальной машине использовать виртуальную ЛС

Откройте — Диспетчер Hyper V.

в области результатов в разделе виртуальные машины выберите соответствующую виртуальную машину, а затем щелкните правой кнопкой мыши Параметры.

В разделе оборудование выберите виртуальный коммутатор, для которого настроена виртуальная ЛС.

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

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

Подключение несколько виртуальных сетевых адаптеров для соответствующих виртуальных коммутаторов и назначьте идентификаторы виртуальных лс. Убедитесь, что правильно настроены IP-адреса и что трафик, который нужно маршрутизировать через виртуальную ЛС, также использует правильный IP-адрес.

Настройте виртуальный сетевой адаптер в режиме магистрали с помощью командлета Set — вмнетворкадаптервлан .

Источник

Терминология

Итак, определяющим понятием HNV является сеть заказчика (Customer Network), обладающая уникальным идентификатором Routing Domain ID (RDID). Это и есть та самая виртуализованная сеть. Для Customer Network существует несколько синонимов, в зависимости от того, каким инструментом вы пользуетесь:

в VMM это VM Network;
в PowerShell это Routing Domain;
во многих статьях и блогах это Tenant или Tenant Virtual Network.

Но все эти термины суть Customer Network. Каждая сеть заказчика состоит из одной или более виртуальных подсетей (Virtual Subnet), и у каждой виртуальной подсети есть свой уникальный 24-битный идентификатор VSID. Маршрутизация пакетов между ВМ, принадлежащими одной сети заказчика, осуществляется автоматически, независимо от того, расположены ли эти машины в одной виртуальной подсети или в разных, на одном физическом хосте, или на разных. А вот если нужна связь с внешним миром, то есть необходимо передать пакеты за пределы Customer Network, то должен быть настроен HNV-шлюз (HNV Gateway, HNVGW).

Мониторинг физических сетевых устройств

VMM поддерживает протокол LLDP (Link Layer Discovery Protocol). Теперь вы можете использовать сведения об LLDP для удаленного мониторинга свойств и данных на физических сетевых устройствах. Эти данные можно просмотреть с помощью консоли VMM и PowerShell.

Просмотр в консоли

Чтобы получить сведения о сетевых устройствах через консоль VMM, последовательно откройте Представление > Узел > Свойства > Конфигурация оборудования > Сетевой адаптер.

В списке подробных сведений содержится метка времени (дата обновления). Чтобы получить актуальные сведения, обновите страницу.

Отобразятся следующие сведения об LLDP:

Отображаемые сведения	Описание
Идентификатор корпуса	Идентификатор корпуса коммутатора
Идентификатор порта	Порт коммутатора, к которому подключен сетевой адаптер
Описание порта	Сведения о порте (например, его тип)
Системное имя Производитель	Производитель, сведения о версии программного обеспечения
Описание системы	Подробное описание системы
Доступные возможности	Доступные системные возможности (коммутация, маршрутизация и т. п.)
Включенные возможности	Включенные системные возможности (коммутация, маршрутизация и т. п.)
ИД виртуальной ЛС	Идентификатор виртуальной локальной сети
Адрес управления	IP-адрес управления

PowerShell

Для просмотра и изменения сведений об LLDP используйте следующую команду PowerShell:

По умолчанию время ожидания пакета LLDP равно 30 секундам. Это значение можно изменить в разделе реестра Software\Microsoft\Microsoft System Center Virtual Machine Manager Server\Settings\LLdpPacketWaitIntervalSeconds. Минимальное поддерживаемое значение — 5 секунд, а максимальное — 300 секунд.

Источник

Настройка через оснастку

В контекстном меню вкладки «Общие» (SERVER1 –> IP-маршрутизация –> Общие) нужно выбрать пункт «Новый протокол маршрутизации».

Затем выделяем строку «RIP версии 2 для IP».
В контекстном меню появившейся вкладки «RIP» выберите «Новый интерфейс». Выделите строку «Подключение по локальной сети» и нажмите ОК.
Перед вами появиться окно.

В появившемся окне необходимо задать следующие настройки:

Режим работы –> Режим периодического обновления.
Протокол для исходящих пакетов –> Для RIP версии 1.
Протокол входящих пакетов –> Только для RIP версии 1.

Оставьте оставшиеся настройки по умолчанию и нажмите ОК.

Далее необходимо выполнить эти действия для второго сетевого интерфейса.

После выполните те же действия для Sever2.

Проверьте, с помощью команды ping, работу сети.

Поздравляю! Маршрутизация в Windows изучена.

Очереди виртуальных машин (ВМКС)

ВМКС — это функция сетевого интерфейса, которая выделяет очередь для каждой виртуальной машины. Когда Hyper-V включен; также необходимо включить VMQ. в Windows Server 2016 вмкс использовать NIC Switch впортс с одной очередью, назначенной впорт, для предоставления тех же функций.

В зависимости от режима конфигурации коммутатора и алгоритма распределения нагрузки объединение сетевых карт представляет собой минимальное количество доступных и поддерживаемых очередей любым адаптером в группе (режим min-Queues) или общее число очередей, доступных для всех участников группы (режим SUM-of-Queues).

Если команда находится в режиме объединения Switch-Independent и вы устанавливаете распределение нагрузки в режим порта Hyper-V или динамический режим, число сообщаемых очередей — это сумма всех очередей, доступных для членов группы (режим SUM-of-Queues). В противном случае количество очередей в отчете является наименьшим числом очередей, поддерживаемых любым участником команды (режим min-Queues).

Далее описывается, почему это происходит:

Если независимая команда находится в режиме порта Hyper-V или в динамическом режиме, входящий трафик для порта коммутатора Hyper-V (ВМ) всегда поступает на один и тот же участник команды. Узел может предсказать или контролировать, какой член получает трафик для конкретной виртуальной машины, чтобы объединение сетевых карт было более продуманным, чем очереди VMQ, выделяемые для конкретного участника команды. Объединение сетевых карт, работа с коммутатором Hyper-V, устанавливает VMQ для виртуальной машины на точно одном члене команды и определяет, что входящий трафик поступает в эту очередь.
Если команда находится в любом режиме, зависимом от переключения (статическое объединение или объединение LACP), коммутатор, к которому подключена команда, управляет распределением входящего трафика. Программному обеспечению для объединения сетевых карт не удается предсказать, какой член команды получает входящий трафик для виртуальной машины. возможно, коммутатор распределяет трафик для виртуальной машины по всем членам группы. В результате работы программы объединения сетевых карт, работающей с коммутатором Hyper-V, программа программирует очередь для виртуальной машины на всех участниках группы, а не только на одном члене команды.
Если команда находится в режиме, независимом от переключения, и использует балансировку нагрузки хэша адреса, входящий трафик всегда поступает на один сетевой адаптер (основной член группы) — все это только один участник команды. Поскольку другие члены команды не работают с входящим трафиком, они запрограммированы с помощью тех же очередей, что и основной участник, поэтому при сбое основного участника любой другой член команды может использоваться для получения входящего трафика, и очереди уже существуют.
Большинство сетевых адаптеров используют очереди для масштабирования на стороне приема (RSS) или VMQ, но не в одно и то же время. Некоторые параметры VMQ выглядят как параметры для очередей RSS, но являются параметрами универсальных очередей, которые используются как для RSS, так и для VMQ в зависимости от того, какая функция используется в настоящее время. Каждая сетевая карта имеет в своих дополнительных свойствах значения * Рссбасепрокнумбер и * Максрсспроцессорс. Ниже приведены несколько параметров VMQ, обеспечивающих лучшую производительность системы.
В идеале для каждой сетевой карты необходимо, чтобы для параметра * Рссбасепрокнумбер было установлено четное число, большее или равное двум (2). Первый физический процессор, ядро 0 (логические процессоры 0 и 1) обычно выполняет большую часть системной обработки, поэтому сетевая обработка должна отойти от этого физического процессора. Некоторые архитектуры компьютеров не имеют двух логических процессоров на один физический процессор, поэтому для таких компьютеров базовый процессор должен быть больше или равен 1. Если вы сомневаетесь в том, что ваш узел использует 2 логических процессора на архитектуру физического процессора.
Если команда находится в режиме суммирования очередей, процессоры членов группы должны быть не перекрывающиеся. Например, в 4-ядерном хосте (8 логических процессорах) с группой из 2 10 Гбит/сетевых интерфейсов можно установить первый из них, чтобы использовать базовый процессор 2 и использовать 4 ядра; второй будет установлен для использования базового процессора 6 и 2 ядер.
Если команда работает в Min-Queues режиме, наборы процессоров, используемые членами команды, должны быть идентичны.

Типы Виртуальных Коммутаторов Hyper-V

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

Существует три различных типа виртуальных коммутаторов Hyper-V, которые используются для подключения сетевых карт виртуальных машин Hyper-V:

Внешний Виртуальный Коммутатор
Внутренний Виртуальный Коммутатор
Частный Виртуальный Коммутатор

Внешний Виртуальный Коммутатор

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

The characteristics of the external virtual switch include:

Ability to connect VMs to the physical network
Allows VMs to talk to each other on the same Hyper-V host or different Hyper-V hosts
The default option when creating a new Hyper-V virtual switch

The external virtual switch provides connectivity to LAN and WAN traffic as routed/segmented in the physical network.

Internal Virtual Switch

As you would imagine, the Internal Virtual Switch intuitively does not provide access external to the Hyper-V host. The internal virtual switch is a type of virtual switch that allows VMs connected to the switch to talk to one another and also to the Hyper-V host.

Хороший способ думать о виртуальном коммутаторе интернета-это думать о физическом коммутаторе, который не связан ни с каким другим коммутатором. Любое устройство, подключенное к коммутатору, может взаимодействовать друг с другом, но не может взаимодействовать с другими устройствами, внешними по отношению к коммутатору. Внутренний виртуальный коммутатор не поддерживается физической сетевой картой на узле Hyper-V.

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

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

Ниже приведен пример использования виртуальной машины маршрутизатора для маршрутизации трафика между виртуальными машинами, расположенными на внутреннем виртуальном коммутаторе, и теми, которые расположены на внешнем виртуальном коммутаторе. Это в равной степени относится и к маршрутизации трафика на внешние виртуальные машины или физические машины за пределами самого узла Hyper-V.

Анонимный прокси-сервер

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

Адрес выбранного прокси-сервера можно указать в настройках и отдельной программы, например, браузера, или всего компьютера (в параметрах адаптера).

Найти такие ресурсы можно на специальных сайтах – в том числе, на HideMy.name или FineProxy. Часть прокси-серверов могут быть бесплатными – но отличаются низкой скоростью, а иногда вообще не работать. Решение проблемы – выбор платного прокси, более стабильного и эффективного.

Создание дискового хранилища для виртуальных машин

Теперь настало время создать хранилище файлов виртуальных машин и файлов виртуальных дисков. Для хранения данных будем использовать отдельный раздел на физическом диске. Для начала посмотрим список командлетов PowerShell, которые используются для управления носителями. Как обычно будем использовать для этого командлет Get-Command. Во втором случае мы получим список командлетов, служащих для получения информации.

Get-Command -Module Storage

Get-Command -Verb *Get* -Module Storage

Просмотрим список физических дисков на сервере.

Get-Disk

Создаем новый раздел на диске максимально возможного размера, назначаем букву D. Используем id из Get-Disk. После этого форматируем раздел в NTFS и указываем его метку.

New-Partition -DiskNumber 0 -DriveLetter D –UseMaximumSize

Format-Volume -DriveLetter D -FileSystem NTFS -NewFileSystemLabel «VMStore»

Убедимся в правильности проделанных нами операций с помощью оснастки MMC Disk Management на удаленном хосте, для этого включим соответствующие правила на межсетевом экране.

Enable-NetFirewallRule RVM-VDS-In-TCP,RVM-VDSLDR-In-TCP,RVM-RPCSS-In-TCP

Как мы видим, наш только что созданный диск прекрасно отображается в Disk Management.

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

New-Item -Path «D:\Hyper-V\Virtual Hard Disks» -Type Directory

Создадим папки D:\Distrib и D:\ImportedVM, которые будем соответственно использовать для хранения дистрибутивов ОС и импортированных ВМ с других хостов виртуализации.

New-Item -Path D:\Distrib -ItemType Directory

New-Item -Path D:\ImportedVM -ItemType Directory

Для создания шары используем командлет New-SmbShare, с помощью которого дадим полный доступ по сети для группы локальных администраторов сервера.

New-SmbShare -Path D:\Distrib -Name Distrib -Description «OS Distributives» -FullAccess «BUILTIN\Administrators»

New-SmbShare -Path D:\ImportedVM -Name ImportedVM -Description «Imported VMs» -FullAccess » BUILTIN\Administrators»

Проверяем с помощью PowerShell и с помощью ServerManager с хоста управления.

Get-SmbShare -Name Distrib,ImportedVM | Format-List

Get-SmbShareAccess -Name Distrib,ImportedVM | Format-List

Общий список командлетов, относящихся к SMB (ServerMessageBlock), как обычно можно получить с помощью командлета Get-Command.

Get-Command -ModuleSmbShare

В заключение этой темы добавлю только то, что если на сервере не используется физический или логический RAID, то для повышения производительности и надежности работы с хранилищем ВМ целесообразно использование технологии Storage Pools (к примеру, такие командлеты, как New-StoragePool, New-Volume). Более подробнее об использовании Storage Pools совместно с Hyper-V я напишу в одной из будущих статей.

Только следующий шаг!

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

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

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

Настройка NIC Teaming в Windows Server 2019

Вы можете настроить NIC Teaming в Windows Server начиная с версии 2012. Рассмотрим, как объединить несколько сетевых адаптеров в Windows Server 2019 в одну группу NIC Teaming. Режим NIC Teaming по умолчанию отключен в Windows Server.

Чтобы включить его, откройте консоль Server Manager, выберите локальный сервер (Local Server) и в его свойствах выберите пункт “NIC Teaming: Disabled“.

В появившемся окне в левой нижней панели выберите пункт Tasks -> New Team (Создать группу).

Далее нужно указать имя группы (Team Name) и выбрать сетевые адаптеры, которые будут входить в эту группу.

В Windows Server 2019 в одну NIC Teaming групп можно объединить до 32 физических сетевых адаптеров, главное, чтобы они работали на одной скорости.

Ниже можно настроить специальные параметры группы. От данных параметров зависит правила и эффективность NIC Teaming. Рассмотрим эти настройки подробнее.

Режим поддержки групп (Teaming Mode). Данный параметр определяет способ взаимодействия группы с сетевым оборудованием (коммутатором)

Static Teaming (IEEE 802.3ad)— статический режим работы с зависимостью от сетевого оборудования. Все адаптеры группы должны быть подключены к одному коммутатору, Ethernet порты которого настроены на использование статической агрегации каналов (требуется настройка на коммутаторе);
Switch Independent (режим по-умолчанию) – группа работает независимо от коммутатора, для реализации не нужно дополнительно настраивать сетевое оборудование. В этом режиме разные сетевые адаптеры группы можно подключить к разным коммутаторам для повышения отказоустойчивости (защита от сбоев в коммутаторах);
LACP (Link Aggregation Control Protocol, LACP, IEEE 802.1ax) – режим также зависит от сетевого оборудования. Нужно включить и настроить на коммутаторе динамическую агрегацию каналов по протоколу LACP.

Режим балансировки нагрузки (Load Balancing mode) – задает как распределяется сетевой трафик по NIC в группе.

Address Hash — для каждого из адаптеров вычисляется специальный хэш (на основании MAC или IP-адресов отправителя и получателя) и привязывается определенному физическому адаптеру. Весь трафик от данного отправителя будет идти через этот NIC;
Hyper-V Port — режим можно использовать для сервера с ролью Hyper-V. Позволяет привязать конкретный адаптер группу NIC teaming к конкретному порту на виртуальном коммутаторе Hyper-V;
Dynamic – опция по умолчанию, совмещает оба типа балансировки нагрузки.

Один из адаптеров в группе можно назначить резервным (Standby adapter). В обычном режиме работы данная NIC не используется для передачи трафика. При неполадке на любом другом адаптере в группе NIC Teaming, он тут-же занимает его место. В общем случае и без данной функции при выходе из строя любой сетевой карты, не будет простоя сервиса, т.к. ее нагрузка автоматически распределится между оставшимися картами в группе.

Выберите нужные параметры, нажмите ОК и новая группа Nic Teaming будет создана.

Откройте список сетевых подключения в панели управления Windows. Убедитесь, что в Windows Server появился новый сетевой адаптер Microsoft Network Adapter Multiplexor Driver (его иконка немного отличается). Это и есть виртуальный адаптер группы NIC Teaming.

Дальнейшая настройка параметров сетевой карты (протоколы, IPv4/v6 адрес) осуществляется теперь в свойствах этого адаптера.

У всех остальных сетевых адаптеров, которые вы добавили в группу NIC Teaming уже не будет собственных IP адресов.

При удалении группы NIC Teaming предыдущие настройки сетевых адаптеров восстанавливаются.

В дальнейшем вы можете добавить или удалить сетевые адаптеры в группу NIC Teaming.

Вы можете использовать группу NIC Teaming для настройки нескольких VLAN интерфейсов в Windows Server. Для этого можно даже создать группу NIC Teaming из одного сетевого адаптера.

Сводка

Центры регистрации и обработки данных на основе технологии облака могут обеспечивать множество преимуществ, например улучшенную масштабируемость и более эффективное использование ресурсов. Реализация этих потенциальных преимуществ требует применения технологии, посвященной принципиальному решению проблем многоклиентской масштабируемости в динамической среде. Виртуализация сети Hyper-V создана для решения этих проблем и повышения рабочей эффективности центров обработки данных за счет разделения топологий виртуальной и физической сетей. Основываясь на существующем стандарте, HNV работает в современном центре обработки данных и работает с существующей инфраструктурой VXLAN. Клиенты с HNV теперь могут консолидировать свои центры обработки данных в частном облаке или легко расширять свои центры обработки данных до среды поставщика серверов размещения с гибридным облаком.