asmelnik

Дабы "железо" не убивали ДДОС-ом icmp, есть обычная практика -- на магистральном железе резать icmp полисером.
Т.к. на конечном узле потерь нет, есть высокая вероятность того, что промежуточные вам просто не отвечают в должном объеме.

Подробности описывать -- трактат наваять надо.
В двух словах -- icmp запрос магистральному маршрутизатору напрягает CPU, а транзитный трафик обрабатывают отдельные ASIC-и в объемах на порядки выше, чем это делает CPU. Поэтому icmp ограничивают.

Проверяйте iperf -ом например связь точка-точка.
И поиграйтесь с размерами пакетов.

Смотрите в сторону тех, у кого есть полный набор всего, что надо и кто не ушел из РФ.

https://www.cnews.ru/news/top/2022-03-04_znamenity...
Т.е. микрот типа ушел. И смысл его в новые проекты закладывать??

Huawei -- полный спектр любого уровня. По разнообразию телекомовского железа там ни зюх ни микрот и рядом не валялся.
Или из отечественного смотрите.

https://glpi-project.org/
Вот этим пользовались довольно долго.

Ripe ncc- источник данных
ripe.net
Для Европы и части Азии.
Если глобально:
IANA+ICAN
https://www.iana.org/numbers
Далее 6 RIR-ов.
Все остальное вторично.
whois- актуально с отставанием в пару недель.

Датаграмма UDP может прийти в неверном порядке. Как это?

Данные "внутри" одной датаграммы -- нет, не могут прийти в произвольном порядке.
Если ваш вопрос переформулировать как

ДатаграммЫ UDP моГУТ прийти в неверном порядке. Как это?

То да, могут.
Отправив датаграммы с номерами 0,1,2,3,4
Вы на принимающей стороне их можете получить в произвольном порядке. Это заложено в самом IP и НИКАК не исправляется средствами IP или UDP.
Только протоколом более высокого уровня "внутри" UDP и то на стороне приемника в процессе обработки всей серии.

Классика говорит, что НЕТ!
Сети НЕ ДОЛЖНЫ ПЕРЕСЕКАТЬСЯ!

"Костыли" при определенных условиях возможны, вроде proxy arp, проброса портов и.т.д.
Но они имеют свои ограничения и условия применимости.

Самое правильное одну из сетей перекинуть в другой диапазон, например
192.168.1-255.0/24
Если так уж принципиально 192.168.0.xxx
Можно одну сеть сделать
192.168.0.0/25 (адреса 1-126)
вторую
192.168.0.128/25 (адреса 129-254)
Если в каждой сети менее 120-ти хостов,
и маршруты 192.168.0.0/24 указать в VPN.

Учитывая отсутствие возможности изменения второй сети и жесткое условие сохранения адрессации -- нормального решения НЕТ!
Узел 192.168.0.12 в сети 1 НИКОГДА не сможет связаться (по IP) с узлом 192.168.0.12 в другой сети.
Вот СОВСЕМ!
(Проброс портов не считаем, это несколько иное условие).

Что происходит с тегированным кадром если он приходит на неуправляемый свич?

В 99.9% случаев такой кадр будет скоммутирован как обычный.
Исключения:
у вас древняя Cisco, которая отправляет кадры в своем собственном формате.
Или довольно редкий и древний неуправляемый зверь с коммутацией store-and-forward и максимальным размером фрейма менее 1522 байт.
или управляемый в конфигурации по умолчанию, но вы о нем не знаете, что он управляемый.
Есть еще более редкие вариации.

И можно ли построить VLAN если промежуточные свичи неуправляемые?

В большинстве случаев можно, но не нужно.
Т.к. ЛЮБОЙ подключенный к неуправляемому коммутатору имеет возможность "влезть" в ваш VLAN, а вы и знать ничего не будете...

На 192.168.1.1 надо прописать маршрут к сети 192.168.20.0/24 через 192.168.1.11
И у всех в сети 192.168.20.0/24 шлюзом должен быть 192.168.20.1
И у Вашего L3 коммутатора, который 192.168.1.11, шлюзом должен быть 192.168.1.1

И да, могут быть на 192.168.1.1 приколы, связанные с icmp redirect...
Т.к. у вас пакет из 192.168.1.0/24 для 192.168.20.0/24 шлюз 192.168.1.1 должен отправить в тот же интерфейс, с которого принял. А в IPv4 на этот счет есть отдельные заморочки.

Такая проблема "рулится" легко.
Итерация 1-- путь запросов в инет:
1) есть ли шлюз у хоста? Доступен ли он?
2) на шлюзе хоста >=2 интерфейса? шлюз "смотрит" в какой интерфейс? Доступен ли щлюз?
3) повторяем 2) для следующего шлюза пока до выхода в инет не дойдем.

Итерация 2 -- путь ответов из инета:
1) знает ли инетовский шлюз, что сеть "хоста" (в вашем случае VLAN20) где-то есть?если нет -- прописываем маршрут, если да -- доступен ли шлюз для этой сети и идем на него.
2) Знает ли следующий шлюз о сети "хоста" (в вашем случае VLAN20)? если нет -- прописываем маршрут, если да -- доступен ли шлюз для этой сети и идем на него. ... повторяем 2), пока не дойдем до самого "хоста"

IP -- он не симметричен, каждый маршрутизатор принимает самостоятельное решение куда отправить пакет исключительно опираясь на адрес назначения (по классике, иное настраивается отдельно для особых случаев).
Есть отдельный путь "туда", и совершенно независимый "обратно", автоматического "туда-обратно" в IP НЕ ПРЕДУСМОТРЕНО от слова "совсем".

Практически любой современный физический интерфейс на компьютере --ПОСЛЕДОВАТЕЛЬНЫЙ: USB, Ethernet (100/1000/2500/5000/10000 Мбит), PON, SATA... (параллельные LPT и IDE(PATA) давно сошли со сцены)
Т.е. сколько физически (Но не логически) интерфейсов вы задействуете, столько и получите одновременных потоков.
При этом если USB -- то это шина, т.е.в каждый момент времени только одно устройство передает данные. И сколько бы вы устройств на одну шину не повесили -- физически это один поток данных.
Если что-то хотите передавать в сеть в реальные 16 или 32 потока -- вам надо соответствующее количество физических интерфейсов.
Но возникает вопрос "зачем"??
Не просто так от параллельных интерфейсов перешли на последовательные :)

Обычный NAT на 2-м микротике, как WAN интерфейс указывается интерфейс к 3-ему микротику.
Если вам пошаговую инструкцию то как пример
https://ooomarat.com/mikrotik-nastrojka-nat.html
Если прям сделать за вас -- так вам не в Q&A, а на "Фриланс" :)