DDwrt100

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

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

Данная ошибка , говорит, что в сети находятся два устройства с одним и тем же маком.
Разные ip адреса , вероятно из-за того что используется DHCP в Wi-fi.
Попробуйте найти устройство, попробуйте сменить мак адрес на микротике.
Хотя предпочтительнее все же найти устройство.

UPD :
Если это коммерческая сеть, вероятно кто то пытается атаковать вас.

Ну конечно не циско , но какинибудь Dlink свичи можно вполне приобрести. Или еще что подешевле.
Непонятно , что сейчас есть вообще из инфраструктуры.
По почтовику , купить десктоп , развернуть Ubuntu , и какой нибудь Postfix. Работать будет, как то.

Непонятно, какого типа передача.
Но на вскидку , поиграться с mss в стеке TCP.
Увеличить буферы.

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

Облака это общее название. Они бывают различные SAAS PAAS и тд. Одна из разновидностей облаков , это облако как инфраструктура. Грубо говоря вы покупаете не Microsoft office, а такой виртуальный конструктор, в таком типе облаков вы сами создаете сервера, сами их связываете. Вот когда поднимаете такой сервис, то вам требуется специализрованное оборудование типа фаерволов, балансировщиков. Поэтому вендоры предлагают свою решения в виде виртуализированных образов. Плюс каждый вендор имеет свою идеологию как должно все строиться, свою логику управления. И если вы 20 лет проработали с Cisco , то наверное вам будет эффективнее такое решение использовать в облачном решении.

Не безопасно. IP подменяется элементарно. Там конечно возникают сопуствующие проблемы с маршрутизацией, но в зависимости от типа атаки, они обходимы.

В такой ситуации никак. Программными средствами вы не заблокируете.
Как вариант выловить mac пиратского "DHCP" посмотреть кто производитель, и идти проверять компы на наличие мак адреса. Это если рассматривать со стороны сети.

Возможно есть настройки в операционной системе на приоритет DHCP , надо гуглить.
Однако без центрального управления инфраструктурой, та еще задача.

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

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

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

Все немного хитрее. Со стороны сети 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 технология не о том, но в принципе позволяет иметь несколько проводов в несколько коммутаторов , однако в данном случае в принципе понятие подсети трасформируется во что то другое, ибо как таковых сегментов не остается.

не должно,

Главное преимущество PoE-источников, которые поддерживают эти стандарты, это интеллектуальная схема работы. Она позволяет избежать порчи оборудования, продлить срок его службы, сэкономить потребляемую энергию. Прежде чем подать питание на подключенное устройство, активный PoE-источник (коммутатор или адаптер) стандарта 802.3af/at проводит согласование с ним и устанавливает: Поддерживает ли подключенное устройство технологию питания по витой паре. Если нет, электричество по сетевому кабелю подаваться не будет. Какое напряжение необходимо устройству. PoE-источник установит его класс питания и подаст соответствующее напряжение на порт. Включено ли вообще устройство (потребляет ли оно электроэнергию). Если нет, подача питания по кабелю прекращается. Не произошла ли перегрузка питаемого устройства. Если да, подача питания прекращается.

Источник: https://lantorg.com/article/faq-po-poe-chast-2 © LanTorg.com

https://ip-calculator.ru/blog/ask/upravlenie-prior...

Ну виновники у вас есть, в дампе должны быть ip адреса. В первую очередь смотрите на загруженность портов хостов, есть ли сбросы , не переполнены буфферы на адаптерах. Ну и конечно на потери проверьте.

Так же стоит учитывать что в нормально работающей сети, ретрансмиты могут быть из-за особенности работы протокола TCP, и в какой то мере это нормальное явление.

Для начала посмотрите загруженность wi-fi каналов. Так же посмотрите жив ли модуль wi-fi на телефоне.

Светить в интернет windows плохая идея, сломают.

А так в виндовс есть утилита route. Добавляете два маршрута, 0,0,0,0 через gw, который смотрит в интернет.
И специфики на вашу локальную сеть. Не забудьте добавит ключ -p чтобы все работало после перезагрузки.

1) Провайдер видит только подключение по VPN, что проходит по этому подключению он не видит, так как все зашифровано. Однако есть методы анализа , которые косвенно могут показать, что вы используете в туннеле VPN.
Технически если заморочиться можно сказать что вы пользуетесь торрентом. Однако кому это надо ?
2) Провайдеру это вообще не надо, ему по большей части пофиг, чем вы там занимаетесь. И у нас(в России), нет как таковой практики подачи заявлений за скачивание торрентов. В принципе, если не ошибаюсь даже в странах типа Германии, где такая практика существует, подает заявление не оператор связи, а специальные конторы, которые с провайдерами никак не связаны.
3) Пакет яровой + СОРМ , да они хранят данные