Там же тыкаешь далее и всё

ну тогда первый вопль должен был быть ГДЕ МОИ ДАННЫЕ С ВИНДЫ!

там же авто разбиением можно ненароком удалить все разделы :)

После этого вопля и начинается видео 😂

Коллеги. приветствую, кто может подсказать советом, из-за чего может возникать проблема:
Был 1 стек из 3 свитчей DELL и стек из двух 3750. Между ними с каждого свитча DELL было по два линка в сторону Cisco и собрано в портченнел. Итого получили работающий портченнел из 6 линков. Недавно добавили еще 1 свитч в стек DELL, соответственно нужно было еще два линка сделать с него. Протянули, добавили линки в существующий порт-ченнел. Итого, все начинает работать изначально корректно. После минут 20-30 начинает отваливаться связь до рандомных серверов, которые находятся на DELL. Чтобы связь восстановилась, помогает почистить АРП данного узла на Cisco(на нем поднят интерфейс-влан). Ошибок на портах нет, не знаю в какую сторону копать.

в каком режиме этот самый LACP собран?

L2?

Group  Port-channel  Protocol    Ports
------+-------------+-----------+-----------------------------------------------
15     Po15(SU)        LACP      Gi1/0/1(P)  Gi1/0/2(P)  Gi1/0/3(P)  
                                Gi1/0/18(D) Gi2/0/1(P)  Gi2/0/2(P)  
                                Gi2/0/3(P)  Gi2/0/18(P)

Да, л2 линки.

тип балансировки (хеш) с обеих сторон одинаково стоит?

(и какой)

явно какой-то глюк. тип etherchannel и балансировка не имеют значения

Вот, это момент есть различие, со стороны dell стоит   6 - Source/Destination IP and source/destination TCP/UDP Port

вообще говоря, влиять это не должно, но я видел имплементации eth-channel (правда, этот eth-channel был в сторону фабрики) у одного вендора, который отбрасывал пакеты, которые, по его мнению, пришли не на ту ногу этого eth-channel

а как со стороны cisco посмотреть хэш?

~30 минут - это типичное время протухания ARP-записи, во фре по умолчанию 1200с, в линуксе не знаю

show etherchannel load-balance
EtherChannel Load-Balancing Configuration:
       src-dst-ip

EtherChannel Load-Balancing Addresses Used Per-Protocol:
Non-IP: Source XOR Destination MAC address
 IPv4: Source XOR Destination IP address
 IPv6: Source XOR Destination IP address

даже протухание ARP записи привело бы только к фладу пакетов в поисках MAC-адреса

show etherchannel load-balance

Со стороны делл есть такие варианты: