Многие из вас читали предыдущую статью про то, как неправильная визуализация для объяснения работы JOIN-ов в некоторых случаях может запутать. Круги Венна не могут полноценно проиллюстрировать некоторые моменты, например, если значения в таблице повторяются.

При подготовке к записи шестого выпуска подкаста "Цинковый прод" (где мы договорились обсудить статью) кажется удалось нащупать один интересный вариант визуализации. Кроме того, в комментариях к изначальной статье тоже предлагали похожий вариант.

Все желающие приглашаются под кат

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

Чаще всего ответ примерно такой: "inner join — это как бы пересечение множеств, т.е. остается только то, что есть в обеих таблицах, а left join — это когда левая таблица остается без изменений, а от правой добавляется пересечение множеств. Для всех остальных строк добавляется null". Еще, бывает, рисуют пересекающиеся круги.

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

Дело в том, что этот ответ в общем случае неверен. Ну или, как минимум, не точен.

Технология eXpress Data Path (XDP) позволяет выполнить произвольную обработку трафика на интерфейсах Linux до того, как пакеты поступят в сетевой стек ядра. Применение XDP — защита от DDoS-атак (CloudFlare), сложные фильтры, сбор статистики (Netflix). Программы XDP исполняются виртуальной машиной eBPF, поэтому имеют ограничения как на свой код, так и на доступные функции ядра в зависимости от типа фильтра.

Статья призвана восполнить недостатки многочисленных материалов по XDP. Во-первых, в них дается готовый код, который сразу обходит особенности XDP: подготовлен для верификации или слишком прост, чтобы вызвать проблемы. При попытке потом написать свой код с нуля нет понимания, что делать с характерными ошибками. Во-вторых, не освещаются способы локально тестировать XDP без ВМ и «железа», при том, что у них свои «подводные камни». Текст рассчитан на программистов, знакомых с сетями и Linux, которым интересен XDP и eBPF.

Сегодня мы поговорим об очередной интересной технологии — VxLAN — что это за зверь и с чем его едят, да и вообще нужен ли он вам. Мое знакомство с данной технологией началось с изучения гипервизоров — я постоянно натыкался на термин VxLAN, но что это и как работает не знал. В один прекрасный день я решил все-таки прочитать, что это за зверь. Прочитав пару-тройку статей, я усвоил для себя основные аспекты работы технологии и облегченно выдохнул, прочитав, что данная технология — удел гипервизоров и к транспорту имеет косвенное отношение (хотя, как оказалось позже отношение VxLAN к транспорту имеет самое, что ни на есть прямое). После чего про технологию благополучно забыл и вернулся я к ней снова только через год, когда начал погружаться в EVPN — большинство статей и мануалов были именно о симбиозе EVPN и VxLAN. Литературы по данной технологии много, особенно если вы владеете английским. Я же попробую в данной статье рассказать об основах работы данной технологии и показать на практике — как это настраивается и работает. Но начнем с MPLS…

В жизни каждого системного администратора наступают моменты, когда возникает необходимость автоматизировать выполнение каких-то операций или, например, приходится часть своих полномочий делегировать подчиненным. Причем, желательно это сделать безопасно, а возможность накосячить свести к минимуму. Хорошо, если речь идет про сервер под управлением *NIX-системы — имеется превеликое множество предназначенных для этого инструментов. Но так везет не всегда…

Перед любым системным администратором рано или поздно возникает задача количественного анализа трафика (откуда / куда, по каким протоколам / портам, в каких объемах и т. п.), проходящего по его сети. Особенно неприятно, когда эта задача возникает спонтанно, как побочный результат DDoS-а, а денег на серьезные решения от Cisco или Arbor, как обычно, нет. И хорошо еще, если шлюзом для сети выступает сервер, на котором можно запустить tcpdump или wireshark, но что делать если:

• шлюзом выступает устройство провайдера, а в сети есть только файл-сервер;
• данные о трафике нужны не постоянно, а от времени к времени;
• устройство не поддерживает возможность запуска на нем сторонних программ;
• трафика столько, что сервер после запуска tcpdump-а «клеит ласты»;
• или наоборот, настолько мало, что его уровень сравним с долей (хотя и значительной) обычного трафика?