DDwrt100

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

https://info-comp.ru/top-5-programs-for-employee-m...

В среде Hyper-V вам необходимо создать виртуальный коммутатор. К коммутатору подвести сеть, в которой должны быть машины.

По поводу выделения адресов. Обычно это отдельные сети под хостовые машины, пробрасываются с помощью Vlan.
У вас все терминируется L3 сегментом, это создает определнные сложности.

VRRP , HSRP ваш вариант, остальное будет изварщением.

Собственно из названий все понятно.
Броадкаст, тип трафика который передается безусловно всем получателям, в определенной среде.
Коллизии это эффект когда несколько источников передают в одну среду передачу данных(например провод который используется как шина, хаб), при этом происходит порча пакетов.

Например , если три устройства будут подключены через хаб, и будут генерировать броадкаст трафик, то это будет один домен коллизий и броадкаста. Потому что хаб это повторитель, и пакеты "могут друг с другом столкнуться", и один домен броадкаста, потому что пакеты сформированные источником как броадкаст пакеты будут получены всеми устройствами.

А если мы изменим схему. Вместо хаба поставим свич. То тут будут разные домены. Пакеты так же всем будут доставляться, но они не будут сталкиваться(создавать коллизии).

Все немного хитрее. Со стороны сети access порт это все го лишь указание коммутатору вырезать метку Vlan из пакета. Приемник , например рабочая станция, ничего не знает о режиме порта коммутатора. Trunk указывает , что данные идут с меткой Vlan. Однако есть два исключения это 1 Vlan, если говорим о Cisco, в идиологии Cisco это как раз пакеты которые не имеют метки. И вторая это указание native-vlan 200 например, что будет указывать что при прохождении трафика метка будет снята с порта. Если мы выполним одно из двух условий, то сможем на trunk сэмулировать поведение порта access.

Тут все не однозначно. Есть несколько технологий объединения портов.
Если взять за основу что мы включаем в разные свичи.
1) Вариант это стекируемые свичи, собственно в конечном итоге со стороны сети это большой виртуальный свич.
поэтому в данном случае подключение не будет отличаться от того как если бы провода были в одном свиче.
2) Технологичя vPC , в данном случае разнос проводов строиться относительно одного L2 сегмента.
Один L2 сегмент, один и тот же адрес в конечном итоге.
3) Так называемый Teaming . Тут интереснее, насколько помню данная технология создает виртуальный интерфейс , к котором подключаются физические порты. При этом один физический порт работает , а второй на подхвате если первый помрет. Сам Ip адрес находится на виртуальном адаптере, и с переключениями активных проводов никак не затрагивается. Однако если перевести адаптер в режим DHCP, и если в зависимости от провода будут разные мак адреса, вполне наверное можно получить различие ip адреса зависящие от активного провода. Но честно извращение какое то .
4) VxVlan технология не о том, но в принципе позволяет иметь несколько проводов в несколько коммутаторов , однако в данном случае в принципе понятие подсети трасформируется во что то другое, ибо как таковых сегментов не остается.

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

Научиться посылать на .... три буквы.
Тут проблема не в инструментах а в обще человеческих отношениях.
Можно придумывать какие угодно инструменты, но пока не научишься говорить нет, это будет не эффективно.

SDN и ipv6

Рулить как хотите ? через сервер ?
Посмотрите решения связанные с потоковым вещанием с сервера. VLC сервер например.

Принципиальная разница в уровне абстракции.

Nat "на лету" изменяет поле ip адрес в пакетах проходящих через устройство.

Proxy устанавливает соединение с клиентом , а потом от имени себя транслирует запросы клиента в исходящую сеть(Например в интернет), хотя бывают прозрачные прокси.

Отсюда следует следующие.
Технология Nat относительно легкое решение , однако она умеет делать только одно менять ip адреса.

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

UPD. СОбствено область применения у этих технологий разная.
Nat используется как инструмент организации сети, для экономии адресного плана, скрытия адресов, организации пипринга.

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

Каждый из больших вендоров сетевого оборудования имеет линейку сертификации.
Посмотрите курсы по этим статусам.
Например Cisco CCNA-CCNP-CCIE, у них не плохо разбираются согласного уровню сетевые технологии.

Насколько помню, так оно и есть. Локальный механизм управления командами, не очень удобный. Можно пробовать управлять правами с помощью AAA сервера tacacs+.Там должно быть полегче.

Смотря на какую позицию вы претендуете. Вообще Packet Tracer симулятор для начального обучения. Если вы входите в профессию. То можно, типа строил тестовые сети на Packet Tracer.