nApoBo3

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

Трафик между vlan идет по третьему уровню, настройте маршрутизацию и фаервол и все будет работать.

Плюс два момента:
Насколько я помню, в tagged нужно еще и сам birdge добавлять, вроде раньше так было, может быть поправили, но я не уверен.
Не понятно зачем у вас у каждого ПК два ip интерфейса ip: 10.30.0.20/24, ip vlan: 10.30.0.22/24. При этом оба они в одной подсети, в таком сценарии нужно будет руками много чего прописывать.

Если вам нужна авторизация на уровне системы, то альтернатив у вас особо нет.
Альтернативный подход, авторизация на уровне сервисов. Например office 365 и Azure AD.

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

1. Оптика. Этот же вариант правильный. В данном варианте у вас здания гальванически развязаны.
2. Poe удлинитель, например от mikrotik, у них есть уличный, штука компактная и удобная.

Нужно смотреть коммутацию и настройки маршрутизации. В общем случае могут. В вашем случае, возможно на маршрутизаторе настроен nat или фаервол.

1. Вы не совсем понимаете, что такое потеря 50% пакетов. В вашем гипотетическом сценарии, это потеря каждого второго пакета, но в реальной жизни это не так.
Удвоением кол-ва пакетов вы проблему усугубите.
2. И да, эту проблему можно для части протоколов решить программно, но не уверен, что такие решения есть в готовом виде. Вам потребуется реализовать собственный аналог tcp для ситуации с большой потерей пакетов, работающий поверх udp или более низких протоколов, плюс промежуточный прокси.
Возможно подобные решения есть, я про подобные вещи когда-то читал для нефтяники на спутниковых каналах, там были свои протоколы, для ускорения передачи данных, поскольку tcp плохо подходит для каналов с большими задержками.

Если вы vlan настраиваете на bridge, вам надо в настройки моста настроить target и untarget порты.

Вы не понимаете даже в общих чертах как "работает" модель osi.
У вас нет "конвертации" пакетов, у вас есть упаковка пакетов, она происходит у отправителя от большего уровня к меньшему, у получателя распаковка от меньшего к большему. Если очень просто, пакет третьего уровня составляет датасекцию пакета второго уровня, к ней добавляются заголовки пакета второго уровня.

Xeon v3 как процессор сильно слабее современных cpu при том же кол-ве ядер и частоте.
https://3dnews.ru/1065050/obzor-xeon-e52640-v3-e52...
Но не следует забывать и об особенностях многопоточность, не исключено, что ваше приложение с ростом кол-ва потоков становится медленнее на каждый поток.
Плюс, возможно у вас xeon работал на достаточно низкой частоте, поскольку были загружены все ядра.

Например gns3.

Нужно смотреть, что за роутеры. На большинстве soho решений проход из wan в lan заблокирован.

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

Без управляемых коммутаторов, только ручками на компах, можно например на ps скрипт написать, но он только с компьютерами на win сработает, к тому же только с известными. Если управляемых коммутаторов нет, ставьте в разрез любой маленький управляемый, да его придется купить или арендовать, и отлавливайте сигмет постепенно его сужая.

Если HP J9449 умеет снимите дамп( если не умеет, поставьте в разрез что-нибудь, что умеет ). Посмотрите приходят ли на него icmp запросы и уходят ли ответы.

Делайте балансировку средствами OSPF.

Зы: gre-туннели рабочие. С маршрутизатора на маршрутизатор трафик ходит как задумано - по маршрутам OSPF. Проблема именно с трафиком из локалки в локалку.

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

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

Это не ресурс для поплакать, никто не должен с вами ничем делить, по mikrotik есть большой объем документации и курсы.

Есть ещё один вариант на некоторых коммутаторах, mac based vlan.

Должны через роутер. Коммутатор по идее не должен анализировать l3 пакет, если l2 пакет предназначен не ему, но конечно зависит от того как этот самый коммутатор настроен.

Вы очень сумбурно описываете задачу:

Можно ли сделать папку на сетевом устройстве в сети 192.168.100.0( вероятно /24 ) доступную по адресу 192.168.200.0.
Да можно, способов несколько, первый это nat для конкретного адреса и обратно, второй просто разместить в сети 192.168.100.0 устройство с адресом из сети 192.168.200.0 и корректно прописать маршрутизацию на роутере.

Можно ли сделать удаленную папку с медленным каналом быстрее.
Да можно, способов тоже несколько, все они завязаны на кэширование.
1. Автономные папки.
2. BranchCache ( требует серьезной и дорогой win инфраструктуры )
3. Синхронизация хранилищ, протокол зависит от того, что хранилища поддерживают.

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