Hi. I’m still working on this since I haven’t touched it in a while. I still have the critical alerts since I wanted to get to the bottom of this before acknowledging them. Traffic seems to be working fine, despite the alerts persisting.
There are 2 physical switches going to the vDS: HP ProCurve —> Flex-10 pair switch —> vDS
The ProCurve pair is trunking 3 Vlans to the Flex-10s:
2 ports in a trunk (x2, 4 total, 2 per switch)
Vlan 100 Untagged
Vlan 200 Tagged
Lan 300 Tagged
The Flex-10s configuration shows the same:
6 nics per host x 5 hosts (30 uplinks to vDS)
Vlan 100 (Native)
Vlan 200
Vlan 300
vDS:
dvUplink Group 1 (6 links x 5 hosts = 30 total)
Port Group A (Vlan ID = 0)
Port Group B (Vlan ID = 0)
Port Group C (Vlan ID = 0)
These links from the Flex-10s are all trunked to a single dvUplink group on the vDS, and then there are a few vDistributed Port Groups and each of those have no Vlan ID assigned, as mentioned (so, Vlan ID = 0)
For some reason, all 5 of the hosts appear to be configured the same but only one of them now shows no critical alerts. I don’t recall acknowledging the alerts.
I’m thinking of testing out just assigning the matching Vlan IDs to the Port Groups as recommended, but I’d like more info before I break something.
I read at the link below that if tagging is done on the physical switch, the Port Groups’ Vlan ID on the Virtual Switch should be zero, but I’m not sure if this applies here or if they mean in a situation where the vDS is connecting to an ACCESS port in a Vlan on the physical switch, or something else. Any clarification or additional help would be great, based on the detail I’ve added. Thanks.
VMware Knowledge Base
I was doing some testing of the new vSphere 5.1 features and came across something odd with the new Distributed Switch Health Check feature with Cisco UCS.
In my lab I have 4 ESXi 5.1 hosts running on older B200 M1s with VIC M81KR adaptors.
On my ESXi service profiles I have 8 vNICs; 2 for management, 2 for vMotion 2 for IP storage and 2 for VM networking.
Each pair of vNICs has 1 in Fabric A and 1 in Fabric B
In VMware there are 3 standard vSwitches and 1 Distributed vSwitch for VM networking VLANs.
On the Distributed switch I enabled the new Health Check feature via the new vSphere Web Client.
About a minute later the following Alerts were triggered.
“vSphere Distributed Switch MTU supported status”
“vSphere Distributed Switch vlan trunked status”
The first thing I did was double check my vNICs to make sure they had the same VLANs trunked and to make sure my MTU settings were the default of 1500.
This got thinking that it must be something to do with the way UCS Fabric Interconnects handle vNICs or something to do with how End Host mode works. I then remembered the new option on the Network Control policy that controls the VLANs that vNIC MAC addresses get registered on.
I was already using a custom Network Control policy to enable CDP on ESXi vNICs.
By default the Network Control policy is set to only register vNIC MACs on the native VLAN. This is set this way to reduce the size of the MAC address tables on the Fabric Interconnects.
I changed this policy to register on all host VLANs and about a minute later the Health Check alerts cleared.
The max MAC addresses per Fabric Interconnect in UCS firmware 2.0/2.1 – http://www.cisco.com/en/US/docs/unified_computing/ucs/sw/configuration_limits/2.0/b_UCS_Configuration_Limits_2_0.html
6100s = 13800
6200s = 20000
Those are fairly high limits so I don’t think most folks would run into that limit if the Network Control policy is changed to all host vlans.
This posting is ~5 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.
During the replacement of some VMware ESXi hosts at a customer, I discovered a recurrent failure of the vSphere Distributed Switch health checks. A VLAN and MTU mismatch was reported. On the physical side, the ESXi hosts were connected to two HPE 5820 switches, that were configured as an IRF stack. Inside the VMware bubble, the hosts were sharing a vSphere Distributed Switch.
The switch ports of the old ESXi hosts were configured as Hybrid ports. The switch ports of the new hosts were configured as Trunk ports, to streamline the switch and port configuration.
Some words about port types
Comware knows three different port types:
- Access
- Hybrid
- Trunk
If you were familiar with Cisco, you will know Access and Trunk ports. If you were familiar with HPE ProCurve or Alcatel-Lucent Enterprise, these two port types refer to untagged and tagged ports.
So what is a Hybrid port? A Hybrid port can belong to multiple VLANs where they can be untagged and tagged. Yes, multiple untagged VLANs on a port are possible, but the switch will need additional information to bridge the traffic into correct untagged VLANs. This additional information can be MAC addresses, IP addresses, LLDP-MED etc. Typically, hybrid ports are used for in VoIP deployments.
The benefit of a Hybrid port is, that I can put the native VLAN of a specific port, which is often referred as Port VLAN identifier (PVID), as a tagged VLAN on that port. This configuration allows, that all dvPortGroups have a VLAN tag assigned, even if the VLAN tag represents the native VLAN of a switch port.
Failing health checks
A failed health check rises a vCenter alarm. In my case, a VLAN and MTU alarm was reported. In both cases, VLAN 1 was causing the error. According to VMware, the three main causes for failed health checks are:
- Mismatched VLAN trunks between a vSphere distributed switch and physical switch
- Mismatched MTU settings between physical network adapters, distributed switches, and physical switch ports
- Mismatched virtual switch teaming policies for the physical switch port-channel settings.
Let’s take a look at the port configuration on the Comware switch:
# interface Ten-GigabitEthernet1/0/9 port link-mode bridge description "ESX-05 NIC1" port link-type trunk port trunk permit vlan all stp edged-port enable #
As you can see, this is a normal trunk port. All VLANs will be passed to the host. This is an except from the display interface Ten-GigabitEthernet1/0/9 output:
PVID: 1 Mdi type: auto Port link-type: trunk VLAN passing : 1(default vlan), 2-3, 5-7, 100-109 VLAN permitted: 1(default vlan), 2-4094 Trunk port encapsulation: IEEE 802.1q
The native VLAN is 1, this is the default configuration. Traffic, that is received and sent from a trunk port, is always tagged with a VLAN id of the originating VLAN – except traffic from the default (native) VLAN! This traffic is sent without a VLAN tag, and if frames were received with a VLAN tag, this frames will be dropped!
If you have a dvPortGroup for the default (native) VLAN, and this dvPortGroup is sending tagged frames, the frames will be dropped if you use a “standard” trunk port. And this is why the health check fails!
Ways to resolve this issue
In my case, the dvPortGroup was configured for VLAN 1, which is the default (native) VLAN on the switch ports.
There are two ways to solve this issue:
- Remove the VLAN tag from the dvPortGroup configuration
- Change the PVID for the trunk port
To change the PVID for a trunk port, you have to enter the following command in the interface context:
[ToR-Ten-GigabitEthernet1/0/9] port trunk pvid vlan 999
You have to change the PVID on all ESXi facing switch ports. You can use a non-existing VLAN ID for this.
vSphere Distributed Switch health check will switch to green for VLAN and MTU immediately.
Please note, that this is not the solution for all VLAN-related problems. You should make sure that you are not getting any side effects.
- Author
- Recent Posts
vcloudnine.de is the personal blog of Patrick Terlisten. Patrick has a strong focus on virtualization & cloud solutions, but also storage, networking, and IT infrastructure in general. He is a fan of Lean Management and agile methods, and practices continuous improvement whereever it is possible.
Feel free to follow him on Twitter and/ or leave a comment.
Сегодня создадим Distributed Switch на vCenter 6.7.
Идея распределённого коммутатора заключается в следующем — создать один коммутатор, который будет обслуживать сразу несколько гипервизоров. Вы получаете один единственный логический коммутатор, существующий сразу на всех серверах ESX(i). Распределённый — потому что он рулится из одной точки — vCenter, а распределяется на все хосты. Если vCenter выйдет из строя, то коммутатор продолжит работу. Мы просто потеряем возможность настраивать коммутатор.
Распределённый коммутатор имеет несколько больший функционал в отличие от обычного. Ключевые моменты:
- Private VLAN.
- Bi-directional Traffic Shaping.
- Network VMotion.
Ссылки
Установка vCenter 6.7
vCenter 6.7 — создаём Datacenter
vCenter 6.7 — создаём Cluster
Добавление хоста ESXi 6.0 в vCenter 6.7 c LACP через UI
vCenter 6.7 — добавляем LAG (Link Aggregation Group) в Distributed Switch
Создаём Distributed Switch
Будем считать, что вы уже знаете зачем собираетесь устанавливать Distributed Switch. Ставим.
Заходим в vCenter, переходим в раздел Networking. Нажимаем правой кнопкой на выбранный кластер,выбираем Distributed Switch > New Distributed Switch.
Открывается мастер создания распределённого коммутатора. Мы на вкладке Name and location.
Указываем название, NEXT. Мы на вкладке Select version.
Выбираем версию коммутатора. Коммутатор 6.0 не поддерживает хосты версии 6.5. Так что я выбираю последнюю версию. NEXT. Мы на вкладке Configure settings.
Выбираем количество аплинков. Можно включить Network I/O Control. Можно выбрать галку для создания дефолтной port group и указать её название. Я буду использовать эту группу для управления гипервизорами и vCenter, называю HV. NEXT. Мы на вкладке Ready to complete.
Проверяем настройки и нажимаем FINISH. Distributed Switch создан. Давайте его настроим. Нажимаем правой кнопкой на коммутатор — Settings > Edit Settings. Переключаемся в раздел Advanced. Находим блок Discovery protocol. Type — ставим в Cisco Discovery Protocol. Operations — Both.
OK.
Настройка LACP
Отдельная инструкция по настройке LACP на Distributed Switch:
vCenter 6.7 — добавляем LAG (Link Aggregation Group) в Distributed Switch
Выбираем Distributed Switch в UI. Открываем Configure > Settings > LACP.
Нажимаем кнопку +NEW. Открывается мастер создания группы LAG.
Указываем название, я оставляю по умолчанию — lag1.
В поле Number of ports указываем количество линков. В моей практики встречалось 4 гигабитных линка, 2 десятигигабитных. Всё зависит от вашей конфигурации.
Mode — Passive. Здесь могут быть варианты в разных сетях.
Load balancing mode — я ставлю Source and destination IP address. Если вы используете Cisco, то это оправдано, иначе MAC адрес сетевухи может скакать с одного интерфейса на другой.
OK.
LACP создан.
Настройка Default Port Group
Выбираем созданную вместе с коммутатором port group, мы назвали её HV. Нажимаем правой кнопкой — Edit Settings.
Открывается мастер настройки. Мы в разделе General. Port binding ставим в Static binding. Port allocation — Elastic.
Переключаемся на раздел VLAN. Эту группу портов мы будем использовать для управления хостами, поэтому настраиваем такой же VLAN, в котором живут ESXi и vCenter.
Переключаемся на раздел Teaming and failover.
По умолчанию у Port Group LACP не используется, включим. Перетаскиваем lag1 вверх, а аплинки вниз.
OK. Сохраняем. Каждый раз потом при создании новой группы портов нужно настраивать LACP для этой группы. Можно это делать прямо в процессе создания.
Добавление хоста в Distributed Switch
Добавляем хост в vCenter, если он ещё не добавлен:
Добавление хоста ESXi 6.0 в vCenter 6.7 c LACP через UI
Нажимаем правой кнопкой на Distributed Switch — Add and Manage Hosts.
Открывается мастер. Мы попадаем в раздел Select task.
Выбираем Add hosts. NEXT. Мы попадаем в раздел Select hosts.
Нажимаем кнопку + New hosts. Открывается окно со списком доступных хостов. У меня пока один — hv00.
Выделяем хост галкой, OK.
NEXT. Мы попадаем в раздел Manage physical adapters.
vmnic1 цепляем кнопкой Assign upling к lag1-1.
Наша задача добиться того, чтобы хост одной ногой был в старом коммутаторе, а второй — в новом. NEXT. Мы попадаем в раздел Manage VMkernel adapter.
Пока ничего не меняем, пусть vmk0 будет на старом локальном коммутаторе. NEXT. Мы попадаем в раздел Migrate VM networking.
NEXT. Мы попадаем в раздел Ready to complete.
FINISH. Ждём когда хост добавится.
Снова нажимаем правой кнопкой на Distributed Switch — Add and Manage Hosts.
Открывается мастер. Мы попадаем в раздел Select task.
Теперь выбираем пункт Manage host networking. NEXT. Доходим до раздела Manage VMkernel adapter.
Выбираем vmk0, нажимаем Assign port group.
Выбираем наш Port Group с названием HV, который находится в управляющем VLAN. OK.
NEXT. Мы попадаем в раздел Migrate VM networking.
NEXT. Мы попадаем в раздел Ready to complete.
FINISH. Управление хостом должно перейти на Distributed Switch.
Снова редактируем сеть хоста.
vmnik0 привязываем к lag1-0.
OK.
NEXT. NEXT. NEXT. FINISH.
Теперь можно зайти в хост — Configure > Networking > Virtual switches и удалить локальный vSwitch0.
Потом заходим в хост — Configure > Networking > VMkernel adapters, выбираем vmk0, редактируем, разрешаем галкой vMotion.
OK.
Резюме
Итак, мы создали Distributed Switch, перенесли в него хосты, настроили LACP, разрешили vMotion.
Objective 3.4 Topics:
- Perform a vDS Health Check for Teaming, MTU, mismatches etc…
- Configure Port Groups to Properly Isolate Network Traffic
- Use Command Line Tools to Troubleshoot and Identify Configuration Issues
- Use Command Line Tools to Trouble and Identify VLAN Configurations
- Use DCUI Network Tool to Correct Network Connectivity Issues
Perform a vDS Hath Check for Teaming, MTU, Mismatches etc…
The health check support in vSphere Distributed Switch 5.1 and later helps you identify and troubleshoot configuration errors in a vSphere Distributed Switch.
vSphere runs regular health checks to examine certain settings on the distributed and physical switches to identify common errors in the networking configuration. The default interval between two health checks is 1 minute.
Checks:
- VLAN trunk ranges on dVS match that on the physical switch
- MTU settings on vDS and physical switch match
- Teaming policy on port groups match that of the port-channel on the physical switch
Enable/Disable Health Check on the Distributed Switch
View Distributed Health Status
My teaming and Failover shows as unknown since the vDS’s aren’t connected to a physical switch, since this is a nested environment.
Use Command Line Tools to Troubleshoot and Identify Configuration Issues
Linux commands for retrieving networking information are not included in the ESXi Shell. You can instead use ESXCLI commands
On ESXi 5.0 and later, ifconfig information is the information for the VMkernel NIC that attaches to the Management Network port group.
Retrieve Network Information
Information on our vmkernels
IP information on a specific vmkernel
Information on a IP 6 on a vmkernel
Information on IP 6 addresses.
Retrieve Information about DNS
Information on the search domain
Information on the DNS servers used
Information on the connections
Retrieve Information on the vSwitch Configuration and VMkernel interfaces
Add/Remove Network Cards (vmnics) to/from a Standard Switch
esxcli network vswitch standard uplink remove –uplink-name=vmnic –vswitch-name=vSwitch # unlink an uplink
esxcli network vswitch standard uplink add –uplink-name=vmnic –vswitch-name=vSwitch # add an uplink
Add/Remove Network Cards (vmnics) to/from a Distributed Switch
esxcfg-vswitch -Q vmnic -V dvPort_ID_of_vmnic dvSwitch # unlink/remove a vDS uplink
esxcfg-vswitch -P vmnic -V unused_dvPort_ID dvSwitch # add a vDS uplink
Remove an Existing VMkernel port on vDS
esxcli network ip interface remove –interface-name=vmkX
Note: The vmk interface number used for management can be determined by running the esxcli network ip interface list command.
Create new Standard Switch and Port Group
esxcli network vswitch standard add –vswitch-name=vSwitch
esxcli network vswitch standard portgroup add –portgroup-name=portgroup –vswitch-name=vSwitch
Create VMkernel port and Attach it to a Port Group
esxcli network ip interface add –interface-name=vmkX –portgroup-name=portgroup
esxcli network ip interface ipv4 set –interface-name=vmkX –ipv4=ipaddress –netmask=netmask –type=static
To set a VLAN ID we can run the following command:
esxcli network vswitch standard portgroup set -p portgroup –vlan-id VLAN
We might need to restart the management agents if network connectivity is not working. services.sh restart
Use Command Line Tools to Troubleshoot and Identify VLAN Configurations
Setting the Port Group VLAN ID
A VLAN ID restricts port group traffic to a logical Ethernet segment within the physical network.
- Set the VLAN ID to 4095 to allow a port group to reach port groups located on other VLAN.
- Set the VLAN ID to 0 to disable the VLAN for this port group.
Allow port groups to reach port groups located on other VLANs
esxcli <conn_options> network vswitch standard portgroup set -p <pg_name> –vlan-id 4095
Disable VLAN for Port Group
esxcli <conn_options> network vswitch standard portgroup set –vlan-id 0 -p <pg_name>
Host Networking Rollbacks
Host networking rollbacks occur when an invalid change is made to the networking configuration for the connection with vCenter Server.
Below is a list of changes that could trigger a rollback:
- Updating speed/duplex of a physical NIC
- Updating DNS/Routing settings
- Updating teaming/failover policies
- Updating traffic shaping policies for management traffic
- Updating VLANs for management traffic
- Updating MTU of management adapters
- Changing UP settings of management VMkernel adapters
- Removing management VMkernel network adapters from a standard or vDS switch
- Removing a physical NIC of a standard/vDS switch from management VMkernel
- Migrating the management VMkernel adapter from standard to vDS switch
If a network disconnects for any of these reasons, the task fails and the host reverts to the last valid configuration.
Restoring the Standard Switch
From the DCUI.
The same can be done for the distributed switch if the management network is affected by am adverse change.
Мне приходится вести довольно обширную переписку. Угадайте по какой теме 🙂
Слово “приходится” не означает, что я недоволен – мне нравится такое положение вещей.
Может быть, не всегда есть возможность ответить развернуто, а иногда ответ я и не знаю, но без внимания я не оставляю ни одного письма.
Что меня радует, иногда обращающиеся ко мне специалисты склонны и делиться знаниями. Вот как раз такой случай:
Настройка VLAN на vSphere Distributed Switch и блейд-свитче HP GbE2c Layer 2/3.
Давайте рассмотрим задачу организации сети с несколькими vlan на распределенном свитче.
Когда и кому это может понадобиться?
Представим себе следующий классический вариант – сервер с 2-мя сетевыми адаптерами. Один физический адаптер необходимо зарезервировать под служебные нужды VMWare, такие как Service Console и VMkernel. На базе же второго адаптера мы можем создать только один виртуальный свитч для проброса сети для виртуальных машин. А что делать, если виртуальным машинам необходимо пробросить как минимум две изолированных сети, а то и 3-4.
Ну или другой вариант – пусть мы озаботились заранее и купили сервер с четырьмя сетевыми интерфейсам. Но при постройке среды виртуализации сделали все правильно и один физический адаптер отвели под ServiceConsole, а другой под VMkernel Port. Остается два адаптера для проброса сетей виртуальным машинам. В большинстве случаев этого достаточно. Но вот появляется срочная задача прокинуть еще одну изолированную сеть в виртуальную среду.
Что делать? Пожалуй, самый очевидный и простой вариант – купить сетевую карту и на ее базе создать очередной виртуальный свитч. Но бывают ситуации, когда нет времени на долгий процесс закупки, или нет слотов в сервере под дополнительную сетевую карту и т.п. Вот тут на помощь нам приходят vlan. Именно настройка vlan на виртуальном и физическом свитче позволит вам через один физический интерфейс прокинуть несколько разных сетей виртуальным машинам.
Рассмотрим конкретную практическую задачу.
Есть хост ESX(блейд-лезвие), с четырьмя сетевыми интерфейсам подключенный в блейд-свитч HP GbE2c Layer 2/3. Один интерфейс ESX хоста, как описывалось выше, отведен под Service Console, а второй VMkernel Port для vMotion. Двум оставшимся интерфейсам соответствуют два распределенных свитча Distributed Switch 1&2, позволяющие вывести две группы виртуальных машины в две изолированных сети. Появляется третья группа виртуальных машин, которым необходима третья изолированная сеть. Решено настроить vlan`ы на одном из двух существующих распределенных свитчей.
Дополнительная сеть – это дополнительный трафик. После мониторинга становится понятно, что виртуальный свитч Distributed Switch2 менее нагружен и легко перенесет добавочный трафик, поэтому через него будут проброшены две сети. Distributed Switch 1 конфигурироваться не будет.
*При использовании большого количества vlan, рекомендую мониторить текущую и планировать будущую нагрузку. Можно пробросить несколько сетей с малой нагрузкой через один виртуальный свитч, а второй оставить под сеть с основным трафиком. Если же виртуальные машины генерируют примерно одинаковый трафик в каждую сеть, то следует размазывать нагрузку и конфигурировать по несколько vlan на каждый виртуальный свитч. Всегда помним, что каждый виртуальный свитч опирается на физический интерфейс с ограниченной пропускной способностью.
Теперь о прикладной задаче. При пробросе трех сетей для виртуальных машин это выглядит так:
Настройка очень проста. Каждая группа портов виртуального распределенного свитча, соответствующая отдельной изолированной сети, должна находиться в отдельном vlan`е. Порты-аплинки между свитчами, должны быть сконфигурированы как tagged порты (т.е. могут пропускать через себя трафик разных vlan`ов).
Для распределенного коммутатора Distributed Switch 2 необходимо сделать следующие настройки:
1. Создаем 2-е группы портов на одном распределенном коммутаторе.
2. В настройках 1-й группы портов в пункте VLAN указать VLAN Type = VLAN и задать VLAN ID (для текущего примера VID=6).
3. В настройках 2-й группы портов в пункте VLAN указать VLAN Type = VLAN и задать VLAN ID (для текущего примера VID=5).
4. В настройках Uplink-группы в пункте VLAN указать VLAN Type = VLAN Trunking. В поле VLAN trunk range указать VLAN ID, для vlan, созданных выше.
На этом вся конфигурации виртуальной среды завершена. Остается настроить физический блейд-свитч.
Ниже приведена настройка для свитча HP GbE2c Layer 2/3. Хосты ESX подключены к внутренним портам 1,2,9,10. Порт 21, 23 внешние аплинки в разные сети.
Включаем тегирование и задаем default vlan внутренних портов.
/cfg/port 1
tag e
pvid 5
/cfg/port 2
tag e
pvid 5
/cfg/port 9
tag e
pvid 5
/cfg/port 10
tag e
pvid 5
Создаем Vlan, включаем их, задаем имя и порты
/cfg/l2/vlan 5
ena
name “…”
def 1 2 9 10 21
/cfg/l2/vlan 6
Ena
name “…”
def 1 2 9 10 23
На этом настройка закончена.
thx Kirill Shusherin.
Выполняем настройку групп агрегации каналов (Link Aggregation Groups) с использованием LACP на распределённом коммутаторе vSphere (vSphere Distributed Switch)
В данной статье мы рассмотрим пример настройки агрегации для VMware vSAN.
Агрегация каналов позволяет объединять несколько сетевых подключений параллельно для увеличения пропускной способности и обеспечения избыточности. Когда группирование сетевых адаптеров настроено с помощью LACP, происходит распределение нагрузки сети vSAN по нескольким аплинкам. Однако это происходит на сетевом уровне, а не через vSAN.
Ознакомиться с общей информацией об агрегировании каналов можно в одной из моих статей про Агрегирование каналов Cisco
В то время как объединение каналов является очень свободным термином, для целей этой статьи основное внимание будет уделяться протоколу управления объединением каналов или LACP. В то время как IEEE имеет свой собственный стандарт LACP 802.3ad, некоторые производители разработали проприетарные типы LACP. Например, PAgP (протокол агрегации портов) похож на LAG, но является собственностью Cisco. Таким образом, руководство поставщика имеет решающее значение, и следует всегда придерживаться лучших практик поставщиков.
Основным выводом при реализации LACP является то, что он использует отраслевой стандарт и реализован с использованием port-channel. Там может быть много алгоритмов хеширования. Политика группы портов vSwitch и конфигурация канала порта (хэш) должны совпадать и соответствовать.
Добавляем LAG
Переходим в наш распределённый коммутатор и создаём новую группу агрегации. Указываем имя, количество портов агрегации, режим работы, а так же режим балансировки.
Активный режим (Active) — устройства немедленно отправляют сообщения LACP, когда порт подходит. Конечные устройства с включенным LACP отправляют/получают кадры, называемые сообщениями LACP, друг другу для согласования создания LAG.
Пассивный режим (Passive) — переводит порт в состояние пассивного согласования, в котором порт отвечает только на полученные сообщения LACP, но не инициирует согласование.
Обратите внимание, что если хост и коммутатор находятся в пассивном режиме, LAG не будет инициализирован, так как нет активной части, которая инициировала бы соединение.
Назначаем LAG для PortGroup
Назначаем созданную группу агрегации необходимой порт группе и переводим LAG в режим ожидания (Standby).
При подтверждение изменений появится предупреждающее окно, о том, что использование комбинации активных аплинков и LAG в режиме ожидания поддерживается только для переноса физических адаптеров между LAG и автономными аплинками. Нажимаем ОК.
Проверяем, что LAG добавился.
Настраиваем адаптеры на хостах
Переходим в меню “Добавление и редактирование хостов” нашего распределённого коммутатора, выбираем пункт “Редактирование хостов”, добавляем хосты, которые подключены к данному distributed switch.
Назначаем LAG-порты к соответствующим vmnic. По аналогии назначаем порты для других хостов.
Создаём PortChannel на Cisco
Тема конфигурации PortChannel затронута в одной из моих статей по настройке объединения портов (bonding) Cisco IOS и CentOS LACP
Рассмотрим пример нашего тестового стенда:
4900m(config)
4900m(config-if-rang)
4900m(config-if-rang)
Creating a port-channel interface Port-channel 2
4900m(config-if-range)
interface Port-channel2
description slv-esxi01[vSAN-LAG]
switchport
switchport access vlan 2
switchport mode access
spanning-tree portfast trunk
spanning-tree bpdufilter enable
interface TenGigabitEthernet1/1
description slv-esxi01[vSAN-LAG]_Uplink1
switchport access vlan 2
switchport mode access
channel-group 2 mode active
spanning-tree portfast trunk
spanning-tree bpdufilter enable
interface TenGigabitEthernet1/2
description slv-esxi01[vSAN-LAG]_Uplink2
switchport access vlan 2
switchport mode access
channel-group 2 mode active
spanning-tree portfast trunk
spanning-tree bpdufilter enable
Проверьте какой алгоритм балансировки используется на физическом коммутаторе.
4900m
port-channel load-balance src-dst-ip
Проверяем состояние PortChannel.
C4900m
Flags: D - down P - bundled in port-channel
I - stand-alone s - suspended
R - Layer3 S - Layer2
U - in use f - failed to allocate aggregator
M - not in use, minimum links not met
u - unsuitable for bundling
w - waiting to be aggregated
d - default port
Number of channel-groups in use: 4
Number of aggregators: 4
Group Port-channel Protocol Ports
------+-------------+-----------+-----------------------------------------------
2 Po2(SU) LACP Te1/1(P) Te1/2(P)
3 Po3(SU) LACP Te1/3(P) Te1/4(P)
4 Po4(SU) LACP Te1/5(P) Te1/6(P)
5 Po5(SU) LACP Te1/7(P) Te1/8(P)
Переводим LAG в активный режим
Возвращаемся к настройкам нашего распределённого коммутатора, переходим в настройки порт группы и переводим LAG в режим Active, а автономные аплинки — в раздел неиспользуемых.
Обратите внимание, что когда LAG выбран, как основной аплинк, режим балансировки порт группы наследуется от режима балансировки, указанного в LAG, о чём нас дополнительно информируют.
Ещё раз проверяем топологию сети.
Особое внимание хочу уделить тому факту, что данная настройка не увеличивает пропускную способность, а выполняет роль отказоустойчивости и балансировки нагрузки.
Источники:
LACP Support on a vSphere Distributed Switch
VMware® vSAN Network Design