Виталий

1. Объединение портов в LAG не означает, что вы на одном устройстве, тестируя до одного сервера, увидите скорость выше одного порта ) LAG означает только, что пакеты будут по какому-то алгоритму балансироваться на разные порты.
2. Из-за этого алгоритма, объединение в LAG трех портов, даст очень непропорциональный выигрыш по сравнению с LAG из двух портов. Обычно объединяют количество портов, кратное двум 2-4-8

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

Вижу, как минимум два варианта решения такой проблемы:
1. С помощью скрипта, отслеживающего изменение текущего GW, и подставляющего измененный в конфиг.
2. Строить eBGP мультихоп, т.е. в качестве GW будет выступать адрес лупбека, а за маршрут до этого лупбека будет отвечать OSPF. Т.о. маршрут до лупбека может динамически меняться в зависимости от ваших реалий, а роутинг с точки зрения BGP меняться не будет.

Зачем вы гадаете на неинформативных ивентах? Не логичнее ли посмотреть логи файрвола (надеюсь, это у вас настроено?) и посмотреть, кто и откуда пытается в это время к вам вломиться.

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

Я подобный вопрос решил тем, что интересующие меня блоки ipv6 роутил также через vpn-туннель. Правда, на самой удаленной площадке приходится согрешить и совершить акт насилия над ipv6 и занатить мои внутренние адреса их внешними ))

А не проще поднять дополнительный DC в нужной сети, после всех репликаций перетянуть на него все роли, и после всех проверок, старый понизить и вывести. При этом DNS сам среплицирует зону и все настройки.

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

NETBIOS в целом, крайне дырявая и уже не рекомендуемая штука. В более-менее нормальных организациях, все персональные шары принудительно закрываются. Трафик NETBIOS между клиентскими устройствами тщательно фильтруется. Остаются только одна/две тщательно контролируемые, возможно распределенные с помощью DFS, на серверах.

Да, все это, а также просто уйму всего еще, можно настроить и посмотреть в ISE

Простите, а вопрос-то в чем? За вас лабу решить?

Catalyst 3750, при всей его L3-шности, далеко не роутер, и это не его основные функции, поэтому, если есть возможность, переносите PBR на роутер, а если нет, то либо описывайте в одной карте все возможные направления, что, повторюсь, не есть правильно для коммутатора, либо изменяйте архитектуру сети, чтобы обойти эти направления.

DHCP Snooping Вам поможет.