Владимир Пилипчук

Архитектура решения не верная в корне. Кто это делал? Сын маминой подруги в героиновом трипе?
Прикрепите схему коммутации решения. Уверен, там у вас все очень интересно.

У вас как минимум несколько функциональных доменов:

1. Networking
   
2. Applications
   
3. Infrastructure
   
4. Backups
   

Держать все это в одном сегменте - не лучшее решение. Плохо предсказуемое поведение и практически не управляемое.

Лучше все же использовать inter-vlan routing и строить управление L2/L3 отдельно.

Например, если хочется активной балансировки, multi-homing и всего такого - поднимаем нужное количество VLAN, BGP/EIGRP, и упариваемся в shortcut/TE.

Если все же физически сервер один, и приобретать дополнительные не хочется (при условии того, что ресурсов достаточно) - превратите железку в полноценный сервер на базе VMware / Hyperv и поднимите на нем все необходимое по отдельности. Разделите уровни пользователя, приложений и инфраструктуры. они не должны пересекаться и аффектить друг на друга.

Udp натится с оговорками. И одна из причин прописана в rfc. И порт обязательно будет меняться. Только конусный нат возможен.
Читайте разницу в трансляциях tcp и udp.

Команда trim поддерживается на уровне контроллера устройства всеми производителями последние 10 лет точно... macOS умеет в trim года с 2015-2016.
Вообще странно, что человек сидящий на Хакинтоше, задаёт столь простой вопрос...
Ну а важна или нет - решите сами.

Павел Межуев хороший вариант предложил.
Я бы дополнил следующим:

SNR-S2982G-8T - не достаточно для построения такой топологии. Я бы использовал что-то помощнее. Либо L3-коммутатор, либо маршрутизатор.

Разбить сеть на /24 VLANы
- в каждом офисе для пользователей свой VLAN
- для серверной подсети свой VLAN
- для сети управления свой MGMT VLAN
Связность между бранчами лучше городить на L2, если есть возможность. И если так, то лучше использовать QinQ на транспорте, чтобы нативно иметь связность между офисами на L2 и получить PortMash сеть. Вдруг нужно будет потом VLAN из одного офиса кинуть в другой/другие. Это более универсальная топология, позволяющая менять архитектуру СПД on-the-fly.
Между CE поднимаем OSPF/BGP/EIGRP/etc. Это позволит более эффективно управлять маршрутизацией.

потому, что есть потери на оверхед на каждом из уровней. И они будут тем больше, чем меньше вы попали в VTD, MTU и NUMA/vNUMA на каждом из уровней.
Если не попали - то с каждым уровнем у нас будет все больше пропусков вычислений так как не попали в тайм-слот такта вычислений.
Для решения этих и многих других проблем с производительностью сети придуманы разные технологии и инструменты.
Управление vNUMA, vSwitch, VLAN translation и множество других, которые так или иначе позволяют снизить оверхед виртуализации и оптимизировать нагрузки.
В vmware workstation таких инструментов не предусмотрено. Вам нужен ESX или уходите на нативный HyperV, там есть немного инструментов... Типа NIC teaming, которая при включении позволяет прокидывать фреймы нативно на уровень хоста без оверхеда.
Еще не маловажно использовать оборудование, которое способно работать с этими технологиями, например поддержка vt-d, vt-x и тп, и решать проблемы вложенной виртуализации.

Вы какую цель преследуете?
Вообще таких устройств не существует, особенно USB
Существуют технологии, позволяющие так или иначе агрегировать трафик. Мультиплексоры, например.
Есть технологии, позволяющие агрегировать трафик на L2-L7.
Например, в теории, если у вас есть своя AS и с операторами поднят BGP, через эти модемы, тогда вымажете разлить входящий трафик по этим модемам...
Но так чтобы воткнул какое-то устройство и оно полетело - так не бывает. Вспомните, что маршрут по умолчанию у нас всегда один. Если таких маршрутов много, тогда нужно как-то их разруливать, городить VRF и тп... Это инженерный вопрос, который нужно решать.

На хабре есть хороший цикл "Сети для самых маленьких". Начните с него.

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

У меня бы ТАКОЕ умерло еще на стадии макета...
А вообще, самое простое - тремя div это собрать с бэкграундом, порезав картинку. Левая часть, верхняя часть и нижняя часть. У верхней сделать отрицательный margin а у конnертного блока bg-repeat. Но такой подход сложно будет назвать адаптивным. Куча ограничений.

Вопроса два - кто занимается указанием MIME и какие типы указаны в конфигурации?
"В лоб" решение - в нужном location указать add_header Content-Type image/jpg; Но это не очень правильно.

Вот тут найдете ответ

Если вас на границе сети стоит маршрутизатор - просто исключите трансляцию/маршрутизацию адресов в Bogoon-подсети через интерфейс провайдера.
Неадекватных инженеров провайдеров, в последнее время, более, чем хотелось бы, это факт. Но это не очень страшно. Можно решить своими силами.
Создайте ACL или пропишите их явно (зависимости от того, что у Вас на границе)

Архитектура может быть разной. Судя по ответам восьмёрок - там целая ферма.
У меня тоже есть свой рекурсер. Он держит зоны и резолвит весь "интернет" для инфраструктуры. Запросов очень много.
Сделал так:
На входе стоит 2 аппаратных балансировщика. Все запросы на DNS-порты отправляются на 4 резолвера на базе Unbound, которые пересылают запросы, ответов на которые нет в локальном кэше на 4 DNS-сервера за каждым.
Балансёры равномерно разливают запросы на 4 резолвера, резолверы, в свою очередь, не менее равномерно разливают запросы по 16 серверам.
Как-то так.

Итого: 16 DNS-серверов спрятаны за 4 резолвера, которые стоят за двумя балансерами.
Думаю так сделано у многих хостеров, регистраторов и компаний, которые получают большой трафик.

Очень похоже на проблему split dns. В кэш попадают ответы на рекурсивные запросы снаружи. Но так как сервер не имеет возможности понять откуда пришел запрос - отдает ответы из общей кучи.
Если хотите, чтобы ответы для венки и внутренни как-то контролировались - используйте функционал view.

Не браузер разбирает ответ DNS, а DNS-клиент ОС.

Ну как сделайте безусловный редирект. Либо на стороне web-сервера, либо на странице сайта заголовком.
Все зависит от того, что у вас за приложение и как оно реализовано.

Тот который ему присвоит оператор сети. ipv4/v6 очевидно. Скорее всего из приватного диапазона.
Белый/серый... это такие условности... в любом случае Вам нужно эти вопросы задавать не здесь, а оператору.

Первое, что необходимо сделать - создать целевую топологию. Описать как должно быть, какие технологии должны быть использованы и как все должно быть коммутировано и настроено. Только после этого можно переходить к этапу планирования изменений. Сейчас Вы заряжаете ружье, чтобы стрельнуть себе в ногу и в голову одновременно.

Допустим перейдете вы на VLANы, все везде пропишите..., растянете их по всей сети, в одном прекрасном месте у вас получается не явное кольцо и вся сеть ложится по STP... а все потому что allowed vlan ни где не настроен...
Или между двумя большими сегментами сети не поднимается маршрутизация (BGP/OSPF/EIGRP) потому, что между ними есть устройство со включённым IGMP Snooping и mcast не проходит.
Или при отработке QoS на PortChannel наблюдается большая потеря пакетов, так как использован не тот режим агрегации... и теперь нужно все перевыбирать...
А может вам лучше не на VLAN переходить, а сразу строить транспортный MPLS домен и заниматься трафик-инженирингом?

Да много конфигураций можно наплодить.
BVI - это бридж. Обычно его используют для пробросать трафика с провода в воздух.
Иногда на нем терминируют подсеть управления, чтобы иметь доступ к самой точке (ssh/telnet/etc).

Могут ли несколько точек (2-3) работать без контроллера в бесшовном режиме?

Смотря что вы под этом подразумеваете.
Теоретически - да могут. На всех точках настраиваете одинаковые ssid и авторизацию... клонируете в обшем. Клиенты по мере удаления будут терять старую точку, и переключаться на новую. Но вот роуминга не будет, так как сессии должен кто-то перетаскивать с точки на точку, и это делает контроллер. Без него сессии будут рваться при переключении.
Ну и стоит помнить, что это все же разные устройства, которые работают на одной частоте. Естественно они будут создавать друг-другу помехи. Разнесением по частоте, каналам, и управление мощностью передатчика для минимизации помех - тоже контроллер занимается.

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

Отсутствует роутинг. Отсутсвует NAT целевых vlan.
маршрутизации 0.0.0.0/24 на 10.99.100.1 - это роутинг локального трафика самого коммутатора, а не ваших vlan. Их вы должны сроутить на маршрутизаторе, и там же настроить NAT.

router eigrp 1
passive-interface default
no passive-interface ***
no auto-summary
eigrp router-id ***
network 1 wildcard
network 2 wildcard
network N
...

Как-то так... смаршрутизировать вам их нужно... можете конечно статически маршрутов написать ...

Что не искал там речь про vlan, но тут все физическое... думал в сторону ip route, но не могу допетрить...

Думаю причина в том, ч то теоретической базы сильно не хватает. Какая разница физическое или нет?
Вы в курсе что физическое - это default vlan, который обычно VLAN ID 1. Поднимите транк между маршрутизаторами и гоняйте там вланы. На маршрутизаторах 2 интереса не потому, что один IN а второй OUT, а для того, чтобы bandwidth не страдал, и была возможность физически подключить более одного Линка, более и не требуется на самом деле. Роутинг это функционал, а порты маршрутизатора обычно расширяются коммутаторами.

EIGRP обменивается сессионной и маршрутной информацией по multicast, проверьте, не блокируется ли он на устройствах. Если хотите unicast - прописывайте соседство статически.
Убедитесь, что все анонсируемые подсети в UP, а если это виртуальные интерфейсы - то порты, на которых ALLOW данные vlan - тоже в статусе UP.
Так же в анонс с обеих сторон добавьте подсеть пиринга (10.1.24.0/30) и соседство поднимется. Почему так - описано в доке по EIGRP.