Akina

Запустите ярлык на CLI из окна CMD и смотрите сообщения. Больше всего похоже на сбой аутентификации.

Навскидку как-то так:

1. На коммутаторе для VLAN интерфейса к pfSense прописываете статический (и не входящий в диапазон выделения на pfSense) адрес из 192.168.1.0.
   
2. На коммутаторе указываете адрес pfSense дефолтным шлюзом. Проверяете наличие связи коммутатора и pfSense в обе стороны, а также коммутатора к внешним адресам в Инете.
   
3. Для VLAN клиентских портов прописываете статический адрес из 192.168.2.0 и включаете на нём DHCP-сервер. Проверяете факт раздачи адресов и коннект коммутатора и клиента в обе стороны.
   
4. Включаете на коммутаторе маршрутизацию между подсетями.
   
5. Прописываете раздачу DHCP-сервером коммутатора своего адреса как адреса шлюза по умолчанию.
   
6. На pfSense в настройках его DHCP настраиваете раздачу адреса коммутатора из 192.168.1.0 как шлюза в подсеть 192.168.2.0/24. Проверяете. что всё работает.
   

Ну и это вроде бы всё...

Да, часть этих пунктов может, скорее всего, выполниться автоматически по факту настройки этого или предыдущих пунктов. Пункт 5 - почти наверняка.

Как обычно - берём двухинтерфейсный маршрутизатор, один к порту в одном VLAN, другой к другому, адреса из соотв. подсетей, маршрутизация, и его на узлах как шлюз в другую подсеть.
Если коммутатор уровня L2+ (а раз на нём есть DHCP-сервер, то это так), то он сам может работать маршрутизатором - прописываешь соотв. адреса внутреннего интерфейса в соотв. VLAN (один уже не надо, на нём DHCP-сервер), и указываешь их шлюзом.
Да, подсети в разных VLAN не должны пересекаться, ессно.

не до конца наверное понимаю работу vlan

VLAN в первом приближении - это не просто, а очень просто.

Первый шаг - это разделение по отдельным VLAN. Мысленно представляешь, что у тебя не один коммутатор, а несколько. Вот прям вместо коммутатора стоИт стопка один на другом. В первом - только VLANID=1, во втором VLANID=2, и так далее. Каждый коммутатор обслуживает строго один VLAN, а все остальные порты, на которых текущий VLAN отсутствует, тупо залиты цементом. Если коммутаторов несколько - то каждый в схеме размножается таким образом, а соединения между портами коммутаторов ещё и раскрашиваются, например, тегованный кабель синий, а нетегованный красный. Соответственно если у тебя есть транковая связь (гибридный или транковый порт) с каждой из сторон) - то в преобразованной схеме один кабель между такими коммутаторами размножается на несколько, каждый в схеме для своего VLAN. А если попадается случай, когда с одной стороны провода VLANID есть, а с другой стороны его нет - получается кабель, с одной стороны вставленный в порт, а с другой нет. И соответственно в схеме для именно этого VLAN связи между коммутаторами нет. Аналогично для случаев соединения "tag на untag" с одной стороны красный кабель, с другой синий, у обоих вторые концы "в воздухе", а связи нет.

Второй, дополнительный, шаг - это соединение меж собой нетегованных портов разных VLAN в преобразованной схеме, если такие соединения исходно существуют, невзирая на номера VLAN. Скажем, если на порте есть нетегованный VLANID=2 (возможно, с другими VLANID, но тегованными), и порт соединён кабелем с другим портом того же или другого коммутатора, на котором есть нетегованный VLANID=3, то в преобразованной схеме ты соединяешь соотв. порты коммутаторов разных слоёв, соответствующих этим VLAN.

Теоретически можно себе представить, что при настройке порта, один и тот же VLANID на порте прописан и как тегованный, и как нетегованный - но это явная ошибка конфигурации (если на порт придёт пакет в этом VLANID, коммутатор не знает, теговать его или нет, а дублировать пакет он просто не станет, не его это дело), и в подавляющем большинстве случаев конфигуратор такое просто не примет.

После такого разделения ты можешь смело анализировать поведение одного VLAN, не обращая внимания на существование остальных.

Только и исключительно VBA-макросом.
Например, так:

Public Sub process_data(index_range As Range, values_range As Range)
Dim values()
Dim i As Integer
Dim coll As New Collection
Dim onecell As Range
values = values_range.Value
For i = LBound(values, 1) To UBound(values, 1)
    coll.Add Item:=values(i, 1), Key:=Left(values(i, 1), 1)
Next
For Each onecell In index_range
    onecell.Offset(0, 1).Value = coll(onecell.Value)
Next
End Sub

Sub test()
Call process_data(ThisWorkbook.Sheets(1).Range("A1:A26"), ThisWorkbook.Sheets(1).Range("B1:B3"))
End Sub

=ВЫБОР(2 * ЕПУСТО(A1) +  (A1 <> 0) + 1;"false";"publish";"")

Вот не вижу проблем.

1. Есть количество товаров, приобретённых юзером. То есть, грубо говоря, известно, что пропустить и откуда считать.
   
2. Если надо набрать указанную сумму, то по имеющимся товарам нужна сумма с накоплением. А чтобы не учитывать уже купленное - домножать на признак "ещё не куплено", являющийся результатом сравнения текущего номера товара и количества приобретённых товаров.
   
3. Отдельно вспомним, что стоимость - штука сугубо положительная. А после домножения на признак - неотрицательная. И, значит, сумма с накоплением строго неубывающая на начальных нулях, а дальше так и вообще строго возрастающая. Иными словами - сортированная.
   
4. Осталось вовремя остановиться. Но именно так работает ВПР()/ГПР() на сортированном списке при поиске ближайшего/неточного значения.
   

Как мне объяснить микротику, что на одном из портов стоит коммутатор?

Ему вообще-то похрен.
А циска пусть работает как тупой свитч. То есть абсолютно всё, кроме коммутирования - нахрен.

я докупил Cisco Catalyst WS-C2960-24TC-L

Можно было обойтись любым неуправляемым коммутатором на нужное число портов.

программа которая видит через какие маршрутизаторы и роутеры и т.д проходит отправляемый запрос

В общем случае получение полного маршрута - вообще без шансов.

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

на работе в серверной куча лапши из проводов и свичей

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

Я, когда пришёл на свою нынешнюю работу, угрохал на такое разбирательство почти два месяца.

Функция, встроенная или определённая пользователем, при использовании в формуле ячейки НЕ МОЖЕТ ИЗМЕНЯТЬ ЗНАЧЕНИЯ ЯЧЕЕК. В принципе не может. А любая такая попытка в определённой пользователем функции немедленно приводит к ошибке и аварийному завершению работы функции.

Схематично:

WITH cte AS (
    SELECT *, ROW_NUMBER() OVER (ORDER BY id) rn
    FROM tablename
    WHERE type = @type
    )
SELECT /* DISTINCT */ t2.*
FROM cte t1
JOIN cte t2 ON t2.rn IN (t1.rn - 1, t1.rn, t1.rn + 1)
WHERE t1.status = @status
ORDER BY t2.rn

Любой маршрут пакета может быть представлен так:

(source IP1) - (IP2 router1 IP3) - (IP4 router2 IP5) - ... - (IPn destination)

У тебя весь маршрут точно известен. А потому временно добавляем на источнике (IP1) маршруты во все промежуточные подсети, если они не покрываются маршрутом по умолчанию или более широкими частными маршрутами, и с источника (IP1) начинаем последовательно пинговать IP2, IP3, IP4, .. и так до узла назначения.

Где-то возникнет проблема, и очередной IP не ответит. Вот именно знание, кто не ответил, и какой именно тип ошибки пинга возвращён, и позволит определить, на каком узле и по какой причине грабли. Конечно, следует понимать, что в маршруте может быть несколько последовательных ошибок, и даже несколько параллельных на одном узле.

Например, если проходит пинг на IP4, но не проходит на IP5, то в случае ответа No route to host проблема - в отсутствии маршрута в подсеть IP5 на узлах source (забыли добавить или сделали это неправильно) или router1, а в случае ответа Timeout проблемы с маршрутизацией на узле router2 или файрволом на любом из трёх задействованных в маршруте узлов.

в какой таблице будет храниться набор необходимых полей для вставки неизвестно

Бред сивой кобылы (извиняюсь). Структура (точные имена полей, и в какой таблице какое поле) обязана быть заранее известна. Даже если используется псевдодинамическая структура на базе EAV или иным способом организованная.

у меня есть 2 таблицы или допустим будет 3 ... Я хочу при выполнении insert into или update использовать эти таблицы

MySQL не реализует одновременную вставку в более чем одну таблицу. А также не реализует использование запроса на вставку в CTE. Напрямую задача не решается.

Правильная реализация - создание хранимой процедуры, которая принимает значения для всех параметров, и выполняет вставку нужных значений в таблицы последовательно выполняемыми запросами, при необходимости получая значения автоинкрементных полей из предыдущей вставки.

Возможная (но нерекомендуемая) реализация - триггер на базовой таблице и передача параметров для подчинённых таблиц через определённые пользователем переменные.