Валентин

В зависимости от объемов лабы. Но я бы точно не мучался с COM-портами. Да и вообще с множеством физических железок. Обкатать особенности аппаратной циски можно и на одном девайсе. Но если уж сильно хочется именно аппаратной лабы (я когда-то такое собирал), все же лучше обычными портами сетевыми, подключить их в отдельный коммутатор, в отдельную сеть и влан. И использовать эти порты только для управления.

Если речь именно про коммутатор, то
1) разные VLAN, штатная ситуация, выходящий порт определяется по хешу от мак-адреса и влана.
2) кольцо в сети, все глючит, пакеты отправляются в рандомные порты, бродкаст заваливает трафиком порты
3) коллизия мак-адресов, трафик вообще ходит в разные порты и вланы, аналогично с кольцом, только оно распространяется ещё рандомнее по всей сети

Похожая в каком плане?
Как устроена внутри? Ну если только всякие китайские спутниковые модемы. Просто она очень старая, поэтому внутри примитивная. + на эту старость накручена поддержка модульных железок и всякие стекирования. Поэтому она уникальна.
Синтаксис? Да полно: huawei, edge-core…
Функционал? Juniper, huawei.

Сами головой дойдите. При агрегации портов устройства делает хеш от определенного параметра, и на основании него раскидывает пакеты по определенным портам. Вот есть агрегированный порт между двумя маршрутизаторами. Хеш по мак-адресу для всех пакетов будет одинаковый, все пойдёт в один физический порт. Хеш по IP-адресу будет лучше, так как как правило на маршрутизатор приходят пакеты с разных IP адресов.

Дальше, при использовании между коммутаторами доступа и агрегации. Как правило, есть выявленные точки тяготения трафика (видеосервисы). Все пользователи дробятся к одному IP-адресу. Но у всех них разные Мак-адреса. В таком случае будет лучше балансировка по src-Mac.

Раньше выбор способа балансировки был творческим процессом и выбирался эмпирическим путём. Включили алгоритм, через день посмотрели графики MRTG, не понравилось, включили другой, посмотрели графики и мадитируем над ровной балансировкой. Так было потому, что у всех все по разному: есть балансировки по BGP, есть наты, есть MPLS, есть маршрутизация на агрегации-доступе… сейчас вроде у всех внедорожник есть алгоритм src-dst-mac-ip. И только в среде MPLS начинается геморрой с его flow-label. Но это уже совсем другая история.

Можете начать с настройки заббикса (включая алярмы в телеграмм и фильтрацию событий для разных пользователей), сислога, такакса, системы резервного копирования конфигураций (бекап конфигурации), системы IPAM, системы автоматической генерации конфигурации (чтобы можно было создать конфигурации на 100 отднотипгых коммутаторов, различающихся только ip-адресами и дескриптором портов), системой автоматизации конфигурации (ansimble, openconf). Естественно, выбираете варианты с сертификатами/шифрованиями, а для автоматизации используете bash/python.
А дальше думаете, как все, что вы настроили, перенести в облако за 1 час.

Ну мы же не знаем, что именно нагружает процессор вашего центрального коммутатора. Это может быть STP, CDP/LLDP, загрузка базы мак-адресами и какая-то проверка поступающих маков, загрузка ARP… детально надо изучать процессы.

Сразу же гуглится.

Не, а как вы думаете, для чего к ним разные блоки питания с разным номиналом? Забьете всю плату оптическими 10GE модулями, потребление будет большим, блок питания не выдержит, будете его менять на более мощный. Это касается всего: платы с POE имеют своё максимальное потребление, сервис процессоры - своё, платы DWDM - своё и тд. Если хотите статистику в тех условиях, что вы описали, то от 300 ватт до 24 киловатт.
Если же про ваш 3RU коммутатор, то в случаях переменного электропитания, при условии отсутствия оптических модулей и PoE питания, при использовании старого процессора жрать будет ватт 600. Подробнее открывайте по каждой плате hardware installation guide и смотрите ее спецификации.

Ищи дампы на трекерах. Dumps, pearsonvue.

Это что, вопрос из дампов CCNA? Подумайте, с какого IP адреса на какой должны идти пакеты и под какое правило маршрутизации они попадают. Подсказка: что-то не так на R2 со статическим маршрутом.