Разочарования и узнавания

Сегодня (вчера) у меня немного пригорело, но обо всём по порядку.

Предприятие Mikrotik позиционирует себя как производитель SOHO (small-office/home-office) оборудования для масс. Однако в линейке продукции данного предприятия также есть железки с замахом на инсталляции в датацентрах. Ну есть и есть, нормальные люди ими не пользуются. Есть же всякие juniper/cisco и прочее промышленное оборудование. Но как же вы ошибаетесь в своих предположениях... Достаточно большое количество дноминистраторов, в числе которых, каюсь, был и ваш покорный слуга привыкли для решения задач использовать инструменты, которые им знакомее, чем другие знакомые. В общем сложно выйти из зоны комфорта. И вот лет 5 назад я решил, что Mirktoik CCR1036 или что-то такое будет отличным решением под пограничный маршрутизатор в датацентре. Однако я же сейчас занимаюсь проектом кросс-сайтового соединения, одной большой красивой приватной сетью и тому подобными запчастями. И в очередной раз я столкнулся с тем какой же некротик неповоротливый.

Вкрации, есть таблицы маршрутизации (vrf на умном). По сути можно представить себе это как отдельные виртуальные маршрутизаторы внутри физического. Соответственно есть основная vrf таблица – main и можно создать что-то типа до 2 или 3 тысяч своих. И вроде бы всё хорошо, vrf работают, изолируют маршруты друг от друга, но что делать, когда возникает потребность ходить из одной vrf в другую? В микротике возникает коллапс, поскольку утекание маршрутов (routing leaks) из/в таблицу main просто нормально (никак) не реализовано. Господа из некротик сообщают, что вот вот мы уже всё это починим. Начиная с версии 7.14... Сейчас на дворе 7.20.1.

В общем хочешь сделать хорошо – посмотри как у других и сделай это сам. И тут второй раз у меня пригорело, но уже по другому поводу.

Есть такое понятие как LLM (большие языковые модели) – обывателю продаются под соусом искуственного интеллекта. И вот эти замечательные модели, якобы, улучшают нашу жизнь и сокращают время доступа к искомой информации. Но (!) есть нюансы, как и во всём вокруг, а именно – LLM не серебрянная пуля и чтобы получить ответ именно о том, о чём ты спрашиваешь – нужно самому понять вопрос, иначе можно нарваться на галлюцинации модели и прочий бред. Ещё есть опасность того, что вместо решения какой-то одной конкретной задачи могут начаться длительные поэтические изыскания на различные темы с уходом в сторону от проблемы. Поэтому все вот эти исследования на тему того, что AI помощники для программистов – ухудшают качество кода + уменьшают производительность труда вполне реальны, я провёл личное исследование в течении месяца и да, всё так и есть. Основная причина, как мне кажется, кроется в психологии людей – мозг штука хитрая и ищет возможности решать проблемы самым малозатратным способом, а тут джинн в банке, который даёт ответы на всё вокруг. Но джинны, как известно, хоть и выполняют желания своего нанимателя, но не всегда таким образом, которым он хотел, чаще даже наоборот.

Так вот, продолжая про микротик. Проблему мы определили, vrf main у нас “неутекаемый”. Определяли мы это с ChatGPT вчера 3 часа, он предлагал разные варианты, с бриджами, с veth, с macvlan (которые к бриджам вообще не применимы) и прочие “обходные пути”, но ни один из них не работал. Штош, я по-старинке пошёл в гугель и уже оттуда узнал о проблемах с main таблицей, множетсво жалоб пользователей, обещаний разработчиков и прочем, о чём LLM тактически умолчал (ну его же не спрашивали напрямую, вот он и решал задачу, которую, как он считал, перед нима поставили)

В конечном итоге после прочтения документации, опыта пользователей и куче другой инфы “постаринке” я пришёл к выводу, что на Mikrotik оборудовании для работы с vrf лучше всего и чище всего таблицу main не трогать вообще. И тогда всё красиво можно утекать. Две пользовательские таблицы нормально стекуются через внутренний BGPVPN (тоже костыль, но рабочий) и всё нормально (наверное, вот сейчас допишу и буду пробовать) “утекает” друг в друга по фильтрам, которые сам настроишь. В общем моё решение на текущий момент создать две vrf – upstream (для всех приходящих ко мне провайдеров, в ней конечно же сделать все анонсы агрегатов и отправлять их наверх) и transit (для моей транзитной оверлей сети, которая будет впоследствии растянута между сайтами) Из transit в main будут утекать только специфики + в main будут анонсируемые префиксы в блэкхол, которые я и буду отдавать апстримам. Из плюсов такого подхода – если в transit (по сути на серверах) нет такого адреса – бордер сразу же отрежет весь входящий траффик по маршруту blackhole, что в свою очередь снизит количество arp траффика внутри сайта и тому подобные флуктуации со сканнерами. Из main же утечёт только маршрут по умолчанию, причём аггрегированный (0.0.0.0/0), что позволит не тянуть fullview, при наличи такового в main таблице и сократит количество обсчитываемых маршрутов в других vrf, (опять же каинд оф оптимизация)

Какие выводы мы сделали:

  1. Никаких

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

  3. Mikrotik не подходит для использования в датацентрах (ну то есть как, подходит, но только в роли временной затычки, и памяти мало, и скорость небольшая, и много архитектурных особенностей, которые привносят боль в жизнь сетевого инженегра)

  4. LLM не является серебряной пулей и не стоит думать, что он всеведущ. Он отвечает только на заданные вопросы, причём прямо и топорно, не учитывая в большинстве случае контекст и/или подводные камни, которые лежат вот совсем на поверхности. В целом его можно использовать как дополнение к гуглежу, однако не более.

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