Большая и обстоятельная статья про то что делать дальше с корневой зоной DNS, которая всё ещё держится, что удивительно, на чистом альтруизме. Количество запросов растёт и очень быстро и не всегда они ожидаемы и полезны, но всегда должны обрабатываться. Новых альтруистов найти, наверное, не получится.

Ситуацию, во многом и пока решает кеширование. Для DNSSEC ещё и новый RFC8198 позволяющий сразу исключать из проверки целые группы имён в алфавитном порядке за один запрос/ответ. Он же помогает и в случае NXNSAttack, вы же подписали и поддерживаете DNSSEC в своих зонах?

Другой подход - каждому держать свою копию корневой зоны. Опять же, вопрос её достоверности должен решить DNSSEC, а вопрос распространения - строго заданное расписание публикаций. С CDN и раздачей статических файлов, худо-бедно современный Интернет научился справляться. Но для этого придётся изменить правила, сразу и для всех, чего добиться будет ой как не просто, тем более что всё ещё есть альтруисты в этом мире.

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

И самый главный из них - это актуальность и согласованность данных. Тут, безусловно, надо преодолевать преграду, и может быть это самый сложный шаг, после которого всё станет значительно проще, в том числе выставит естественный барьер неограниченного роста рабочих инструментов. А успех этого важного шага зависит от того, есть ли в компании люди которые занимаются внутренними разработками, и для инженеров тоже, а не только для менеджеров и бизнеса. Подход - инженеры сами себе всё сделают, конечно, работает, но не всегда хорошо. Научившись программировать, не факт что сетевик останется сетевиком, а не уйдёт программировать себе дальше.

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

Так скоро и Неуловимых Джо не останется.

Окей, эта история просто заслуживает войти в the best этого канала!

Короче, некто сжёг автомобиль у дома свидетеля, который проходит по делу певца R. Kelly. Федеральные органы запросили у Гугл информацию о всех пользователях, которые искали в Гугле адрес, по которому проживает этот свидетель, в рамках времени, когда произошёл поджог. Этот запрос с ордером привёл к запросу с определённого IP-адреса в соседнем штате за пару дней до поджога. IP адрес принадлежал телефону, который был записан на некоего гражданина. Который оказался родственником издателя певца R. Kelly. Затем представители правоохранительных органов проанализировали логи с базовых станций вокруг дома, где был подожжен автомобиль. Сюрприз-сюрприз, в логах БС оказался тот же телефон, принадлежащий уже установленному гражданину, и по логам он там фигурировал прямо во время поджога. Агенты арестовали его, и в телефоне обнаружилась информация о поездке в день поджога, с остановкой возле места, где произошёл поджог. Такой вот цифровой след. Детали расследования по ссылке в документе

https://www.documentcloud.org/documents/7222789-Another-R-Kelly-Search-Warrant.html

В общем-то ничего невероятного, если вы в принципе ведёте и имеете потребность в формальной документации по сети. Для многих хватает оперативной, совмещённой с активными системами мониторинга/учёта/управления, откуда можно надёргать всего и разного в любом виде. Кстати, провайдерам как никогда эта задача становится актуальной в связи с "законом о суверенном интернете" и требованиями РКН по заполнению формальных машиночитаемых XML шаблонов с топологией сети, составом оборудования, точками присоединения...

CloudFlare запустили совсем неочевидный массам продукт Cloudflare One - это такой комплексный инструмент для построения ваших собственных (корпоративных например) сетей. Идея в том, чтобы с помощью простого приложения создавать ваши собственные приватные сети так, чтобы вы и ваши сотрудники могли воспользоваться всеми вашими внутренними сервисами, а внешние люди нет. Конкурентов у Cloudflare One много, два самых явных это ZeroTier и TailScale - функции те же самые. Главное отличие нового продукта - интеграция с другими системами идентификации пользователей, по сути вы можете сделать виртуальную сеть для всех, кто из вашего домена (если он заведен на google workspace например).

Понимаю что сложно, но вообще это потенциальная революция в мире корпоративных VPN решений https://blog.cloudflare.com/introducing-cloudflare-one/

Если вам привезли кучу цисок, которые вам надо обновить прямо сразу как вы достали их из коробок, то путь ваш лежит в царство маловнятной магии с hex параметрами для вашего DHCP.
Однако добрые люди перевели на человеческий эту часть недокументированных знаний.
https://vincent.bernat.ch/en/blog/2020-dhcp-cisco-ios

Так что, нужны сетевики или нет? Наверное, телефонистам очень обидно, про них вообще не вспоминают :). Большой привет всем телефонистам, коллегам и не только, вы нужные и полезные, без сомнения.

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

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

Нужно ли в современных условиях учиться новому, в частности программировать? Несомненно и не только в современных. Программирование, под которым я понимаю алгоритмы и работу c данными - базовая вещь. Никто лучше сетевика не сможет описать что ему надо, поэтому даже плохой код от сетевика, вероятно, будет справляться с задачей лучше чем идеальный и каноничный код программиста который никогда не видел сетей. Это не сама цель - это ещё один рабочий инструмент и у многих с кем мне приходилось встречаться он был в арсенале. Некоторые, даже, в программисты переквалифицируются, вам тоже привет :)

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

И тут привет всем сетевикам от сетевика, отдельный @Night_Snake и @Linkmeup :) и всей нашей общей, не большой, но тёплой сетевой Телеграм компании.

​Google рекламирует свои сервисы через запугивание страшными DDoS атаками. Тут больше интересны тренды, которые ещё бы наложить на рост трафика в их сети, чтобы понимать долю или превышение над обычными значениями.

Чтобы было с чем сравнивать. По трафику современные устройства на границе сети у провайдера могут перелопачивать десятки гигабит/c, включая NAT и нарезку скоростей каждому абоненту в одной коробке. Каналы в Интернет, соответственно, тоже где-то в этом диапазоне от единиц до сотен гигабит/c. Tier1 и Tier2 в своих пресс-релизах хвалятся суммарной пропускной способностью во всех направлениях в единицах терабит/c.

Гораздо важнее PPS, типичные значения - несколько миллионов пакетов в секунду на устройство, опять же включая NAT и нарезку скорости, а не просто маршрутизацию и пересылку трафика. По графикам Google здесь видно многократное превышение, но тут скорее всего мы имеем дело с суммарным значением распределённым по многочисленным точкам присутствия, а не атаке пришедшейся на одну точку. Как это работает можно послушать в докладе IVI на PF2018.

А вот RPS мне не с чем сравнить, но тут дело не в количестве а в качестве, можно и одним запросом много дел натворить.

Последнее время часто стали попадаться на глаза симуляторы работы сети, чтобы придумать и построить топологию, задать начальные условия и посмотреть что в итоге вышло. Ещё один, вот настолько простой насколько можно, при условии, что надо уметь в Python - NeST и вводная статья про него на APNIC. Простейшая топология умещается в несколько строчек:

n0 = Node('n0')
n1 = Node('n1')

(n0_n1, n1_n0) = connect(n0, n1)

n0_n1.set_address('10.0.0.1/24')
n1_n0.set_address('10.0.0.2/24')

n0_n1.set_attributes('5mbit', '5ms', 'pfifo')
n1_n0.set_attributes('10mbit', '100ms', 'pfifo')

flow = Flow(n0, n1, n1_n0.get_address(), 0, 10, 2)

exp = Experiment('tcp_1up')
exp.add_tcp_flow(flow, 'reno')

exp.run()

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

Просто замечательный пост для адептов Juniper про commit check.

Я сам частенько делаю сначала commit check, а сразу потом commit. Тут дело не во времени, пока мои конфигурации не выросли до таких размеров чтобы применяться по 15 минут. Дело в уверенности, пусть это и чисто психологический момент. Ведь технически нет никакой разницы - commit в любом случае проверит конфигурацию на синтаксическую корректность перед применением. Но когда процесс финального применения внезапно прерывается ошибкой, где-то начинает грустить один администратор. Это как спотыкнуться и упасть перед самым финишем.

Настоящие инженеры не должны поддаваться и идти на поводу у чувств и тратить своё время зря. Настоящие инженеры используют commit confirm, а уже потом commit check.

Не бывает мало IPv4 адресов, бывает мало денег. Показательно, к вопросу о нехватке, что "про запас" лежит почти половина, так у всех интересно? И, конечно, никто не будет раскулачивать legacy блоки, они вполне уходят по рыночной цене.

Пятница и пока ещё актуальная картинка, всё ещё.

И мой фаворит.

Магистральные сети связи в России.

Файл в .pdf от comnews ⬇️

🕸

За последние 1,5 недели посмотрел весь Next Hop 2020 - всё очень качественно, почти без провисов в докладах, стоит обязательно уделить время и, как минимум, посмотреть по темам которые заинтересовали. Мой шорт-лист:

- Александр Азимов наконец-то показал реальное полезное применение IPv6 не связанное с размером адреса (шутка). На самом деле, хватило бы ещё одного поля в IPv4, но взять его негде. А звёзды сложились так, что Flow Label удачно вписался в современные архитектуры датацентров, да ещё и нужные реализации в Linux оказались. Поэтому IPv6 - практически без альтернатив.

- OpenVPN для удалёнки, если вы Яндекс. Хороший конкретный доклад, как готовить удалённый доступ. Очень точно про необходимость туннелей поверх TCP, поэтому, кстати, OpenVPN и мой личный выбор.

- Очень познавательно и доступно про программируемые сетевые функции, язык P4, но в основном как это обеспечивается железом. От основ и принципов до программируемости и гибкости. Это уровень управления каждым отдельно взятым пакетом на очень и очень больших скоростях, потому что в железе.

Из остального. Большие и известные рассказали как внутри у них работает:

- Mail.ru про свой антиDDoS - стильно, модно, молодёжно - SYN cookie, Python, Go, FlowBGP, Kubernetes.

- МТС про автоматизацию. Если вдруг в конце года будет что-то падать, знайте, они на прод выкатывать это собирались.

- Qrator про Linux switchdev на whitebox. Со стороны интерфейса пользователя это всё ещё обычный Linux, поэтому по-старинке в Qrator сделали Perl скрипты к нему, чтобы хоть как-то усложнить. Кроме шуток, это настолько просто, что не пришлось ничего патчить, что даже вызвало удивление у ведущего - берите и используйте.

Тренды:

- Сетевые карты умнеют, что в частности позволяет использовать Linux в коммутаторах, а коммутаторы в облаках. Хороший обзор подходов, архитектур и технологий. Любимые уже всеми DPDK, eBPF и не только.

- А телеметрия спускается всё глубже и глубже, если это BGP то непосредственно до UPDATEов, если это коммутаторы, то до пакетного процессора.

- Segment Routing. При том что докладчик постоянно ссылался на то что "все должны знать" получился хороший ликбез по SR и SRv6 для тех кто совсем ничего не знает.

- Terraform и автоматизация развёртывания. Похоже, GUI проигрывает раунд, если со всеми фишечками и рюшечками интерфейсов Cisco ACI и vCenter удобнее использовать Terraform и Ansible. Основной накал теперь CLI vs. API.

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

Не пропускайте, смотрите, потому что скоро Пиринговый форум 2020 online, который тоже не стоит упускать из виду.

Всем известно что программисты праздник HelloWin не отмечают, они делают более страшные вещи - ip -json addr. Для следящих за Linux это, конечно, не новость.

С ходу не могу придумать достойного применения и не хочется думать что это сериализация ради сериализации. Это уже интерфейс командной строки поверх системных вызовов и структур сетевой подсистемы. При использовании, того же Python, туда проще добираться не используя шелл и вызов внешних утилит, по пути ещё и форматы преобразовывать. А вот пропихивать это для отправки на удалённый узел - может быть.

Unix-way выглядит скорее так - jc. Одна утилита, один функционал, а то и так уже опций больше чем букв в алфавите. Но раз уж сделали, так пусть будет. На всех не угодишь, но кому-то точно пригодится.

​Pktvisor: Open source tool for network visibility

NS1 announced that pktvisor, a lightweight, open source tool for real-time network visibility, is available on Github. Читать дальше.

Репыч на Гитхабе.

OVH открыли своё решение в области защиты доступа к инфраструктуре - The Bastion. А кому нужно попроще, можно обойтись Jump host, только про управление ключами не забыть.