Патчкорд

Практика (сразу GitHub с топологией лабы) Dynamic BGP neighbors и теория для Cisco, заодно и шаблоны когда BGP соседств действительно много.

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

Строгая математическая модель, даже две, с доказательствами, для выбора оптимального пиринг-партнёра в заданных точках присутствия. И сайт пример расчёта для некоторого количества известных ASn в рамках США. Если совсем коротко, то притягиваются похожие друг на друга.

Напоминание о том что оптику надо чистить и для этого есть большое количество инструментов. Но, на самом деле, к этому вопросу щепетильнее всего относятся те кто уже что-то знает про оптику, но работает с ней мало, не говорим про всякие пограничные случаи, большие дистанции и прочее, там тоже относятся щепетильно. А в провайдерских полях: дунул, плюнул, линк понялся, ошибок нет, уровень в пределах -20dBm, поехали дальше.

DNSSEC и anycast добавляют столько сложности, что те проблемы которые в других случаях прошли бы незаметными стали видны. Но есть обратная сторона, найти конкретное проблемное место стало значительно сложнее. История про залипший экземпляр DNS сервера у Afrinic и как это искали.

Добавим контекста в статье на fierce-network.com к этой завирусившейся картинке с конференции AutoCon2. Никакой новой сути она не несёт и этот спор стар как мир - жить в чистом поле и всё делать самим, ведя натуральный обмен с другими такими же, или разделиться на кланы использующие разные продукты от разных вендоров живя под стенами их городов. В конце концов решили, что нужно хотя бы о терминологии договориться для начала.
Вот сейчас очень кстати, то что невозможно было пропустить если смотрели или были на nexthop, можно вспомнить про клан Yandex и их набор инструментов для сетевой автоматизации Annet, который opensource, если хочется в какой-нибудь клан таки примкнуть.

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

Издание ComNews Research выпустило новую версию карты "Магистральные сети связи в России" с данными на октябрь 2024г.
Аналитику данных и сведений по карте издание приводит в своей статье:
- https://www.comnews.ru/content/236040/2024-11-29/2024-w48/1180/magistralnye-seti-svyazi-rossii-2024#map-section

Согласно результатов опроса:
- рынок магистрального доступа насчитывает более 20 игроков,
- протяженность магистральных ВОЛС которых на территории страны составила в октябре 2024 года 1476 тыс. км

- интерактивная карта.
- карта в pdf.

traceroute-mapper - инструмент для перевода вашей трассировки на географическую карту. Не забывайте очищать карту перед следующем построением, иначе всё наложится друг на друга. IPv6 есть. Внутри, ipinfo.io, тоже приятный whois инструмент, позволяющий работать curl из консоли.

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

Финальная секция оправдала все мои ожидания, вишенка на торте, я бы даже сказал бриллиант Пирингового форума этого года. Нет смысла пересказывать, начинайте смотреть с доклада Максима Раевского, который, завёл аудиторию вполне конкретной актуальной проблемой, которая и обсуждалась дальше, та самая внутрянка телекомов в прямом эфире. Я всё ждал пока заявленное георезервирование выйдет за рамки Москвы, но этого не случилось. Если смотреть с моего столба, то Москва эта точка на карте, я беру каналы до Москвы, а не до какой-то точки внутри Москвы, для меня этой точки внутри не существует. Но с чем нельзя не согласится у нас всё через Москву и проблемы с M9 внутри Москвы, это проблемы всей России, такова данность.

В целом, сегодняшний форум это место где надо было присутствовать лично, потому что всё строилось от панельных дискуссий и доклад по сути был только один, про историю одного DDoS от Леонида Рыжика из П.А.К.Т. прошедшийся очень хорошо по всем аспектам, как это выглядит сейчас, при чём тут ТСПУ и как с ним быть, может быть даже дружить, но не забывать что его тоже могут DDoS'ить. А также техническими и организационным моментам со знакомыми чувствами тех кто видел это сам или погружен в проблематику. Наверное, с него прямо стоит начать смотреть весь форум, потому что все остальные доклады это вступление к обсуждению спикерами на сцене и они не идут в отрыве от этого.

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

Секция про безопасность была сосредоточена на DDoS и в общем борьбой с последствиями какими-то техническими или не техническими решениями. Тут было мало именно Интернета, постольку поскольку всё у нас в Интернете и в какой-то степени обсуждение DDoS из далёкого Yac2013, более полезна практическими вопросами тем что надо делать, чтобы исключить возможности некоторых атак, не на себя, а на других со своей сети - аккуратно применить в своей сети BCP38. Потому что используемые ранее эффективные способы атак никуда не делись, просто к ним добавились другие. А ещё политики MANRS для борьбы с безопасностью маршрутизации в Интернет, про которую было упомянуто лишь вскользь. Интересно, что по внешнему контуру России защититься более менее удалось, средствами ТСПУ в том числе, но и самими защищающимися тоже, поэтому источники DDoS сместились внутрь страны, которые уже не так просто срезать и надо их как минимум классифицировать. В конечном итоге все сошлись на том что ближайшее будущее это борьба двух ИИ между собой, один который формирует атаку, второй который её отбивает.

И начало про про КИИ, на самом деле про импортозамещение. Насколько я оптимистичен, но даже мне показалось через чур оптимистичным: во всём мы лучшие и в NAT и в BRAS и всё у нас скоро своё будет. Наверное да, наверное в какой-то степени можно говорить это про телеком, где набор функций достаточно прямолинеен и важны объёмы. В кровавом энтерпрайзе нужен универсальный комбайн, как раз то что ругали в том числе, где есть немного NAT, немного туннелей, немного шифрования, немного MPLS, немного того и всего. Но Пиринговый форум точно не про кровавый энтерпрайз, поэтому мы подождём ещё, пока производители обратят внимание на этот сектор.

Вот пожалуй по большому счёту и всё. Главное отличие, как я уже говорил, это то что всё строится от дискуссий. При том что они все про Интернет и операторов, в конечном итоге не было, почти не было, упоминаний BGP, да и вообще никакой технической конкретики протоколов и процедур Интернета. Но вместе с этим поднимались вопросы одновременно над этим, на 8 уровне, и вопросы под этим, что делает именно дискуссию интересней в более широких границах. Поэтому надо было быть лично и, думаю, вечерний фуршет должен в этом году особенно удастся. Но я не жалею, свою потребность в общении в этом году я с лихвой удовлетворил на nexthop.

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

Ещё стоит упомянуть книгу Интернет изнутри: Архитектура экосистемы Интернета / Андрей Робачевский, новое издание которой презентовали на форуме. В далёком, не помню каком году, я с удовольствием получил экземпляр из рук автора с автографом и тут же прочитал пока возвращался домой, после чего передал её в библиотеку тогдашнего работодателя. Читайте новое издание, которое теперь можно скачать, хотя и без живого автографа, хуже оно от этого не становится.

Сначала напишу про ситуацию с NTP и Yandex станцией, потому что сегодняшний Пиринговый форум расставил некоторые точки. На картинке, слайд из презентации Александра Ильина про технические новости MSK-IX за год.

Начиная с 15 октября все потихонечку начинают страдать, в первую очередь те кто находится в ru.pool.ntp.org, включая MSK-IX, потом операторы связи которые видят проблемы с трафиком UDP и даже знают кто его генерирует. Те операторы которые не видят, чувствуют что есть какие-то проблемы, потому что, вероятно, ТСПУ тоже от этого страдает, пытаясь отбить DDoS из NTP запросов, или не пытаясь, а просто реагируя на проходящий трафик, как рассказывается в презентации Леонида Рыжика из П.А.К.Т на сегодняшнем Пиринговом форуме.
C 3 ноября, на форуме ntppool.org начинают обсуждать проблему высокой нагрузки. 14 ноября kkrusor, автор статьи и на Habr, сообщает в этой теме о своих проблемах. А 15 обсуждают уже конкретно про Россию. Всё это не зная про проблемы операторов, и, в основном, сходятся на DDoS, который не редкость. А потом, уже на Habr, где в комментариях проскакивает связь с Yandex станцией.
С 10 ноября в Yandex узнают о проблеме, видимо от жалоб тех операторов которые видят растущее количество UDP запросов, но не считают её критичной. 20 ноября, раньше чем статья на Habr, проблема внутри Yandex решена, но обновление прошивки выпущено только в выходные в экстренном режиме, уже после статьи на Habr.

Но это только предыстория, маркер ситуации, я хотел сказать про другое. Никакие чатики в телеге, обсуждения на официальной площадке проекта ntppool.org, то что это затронуло, в том числе и такого гиганта как MSK-IX, знания о проблеме внутри Yandex, не изменили привычного распорядка дня. Можно как угодно ругать Habr, но похоже это единственное связующее звено русскоязычного IT сообщества. При том такого, мнение которого имеет вес, без наличия этого веса ничего не происходит. Этот вес принёс сразу рост количества серверов в пуле, при существующей проблеме с трафиком, ещё до решения проблемы.
С другой стороны, можно констатировать, что это самое сообщество находится в сильно раздробленном состоянии, части которого общаются между собой мало, если вообще общаются. В любом случае, я думаю, что именно это общение победило, не сразу но победило, наверное могло бы победить раньше если бы общения было больше и сообщество сильнее и уважаемей, а обсуждаемые вопросы находились в конструктивном техническом ключе и не тонули в море флуда особенно в чатиках.

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

Мы начинаем 🎉

Зал: Инфраструктура и сетевые сервисы

Секция: КИИ, Постановление 1912 и оборудование для провайдеров

Алексей Болдин из компании RDP.RU открывает секцию с докладом на тему:
«КИИ: требования импортозамещать!»

Алексей расскажет, как критическая информационная инфраструктура (КИИ) связана с операторами связи, какие объекты КИИ есть у провайдеров, и как их категоризация влияет на их действия. Также обсудим переход на доверенное ПО и оборудование в рамках Постановления №1912.

🚩 Прямая трансляция форума

Пока я жду в аэропорту и думаю какой из моих домашних роутеров я прокачаю до 800G, поделюсь с вами впечатлением о прошедшем nexthop 2024.
Получилась очень практическая конференция, на все презентации я, конечно, не попал, поэтому жду видео, чтобы пересмотреть.

Но из того что я смог послушать, можно сказать, что подход который был взят в прошлом году, условно без матана, в этом году максимально реализовали. Естественно, для каждого матан свой, проходных и поверхностных докладов я не видел, над всем надо думать. К сожалению, я пропустил первый доклад от Hadal и про Dragonfly в Yandex (то о чём писал eucariot) и подозреваю что весь матан был сосредоточен в них, в записи увидим.

Отдельно отмечу близкие мне провайдерские темы про VK CDN от Андрея Старченкова, с программерской точки зрения, и мониторинг инцидентов BGP изнутри от Александра Азимова и Андрея Шабарова. Ещё было интересно узнать что офисная сеть Yandex живёт на FreeBSD роутерах, и что WLAN PI цветёт и пахнет со всей силой, особенно если собрать самому в два раза дешевле, а в Linux продолжают замещать стандартные функции ядра своими в userspace, потому что быстрее, о чём рассказывает Александр Демиденко в своей истории.

Всем кого встретил вчера, кто узнал и не узнал большой привет, было очень приятно пообщаться. Организаторам отдельное спасибо за организацию. Завтра Пиринговый форум вместе с которым до нового года можно каждый вечер заполнить просмотром чего-то интересного.

З.Ы. Продолжаю ругать фронтендоров, которые не реализовали прямые ссылки на описания докладов, поэтому без ссылок, щёлкайте сами с главной.

Яндекс признал и осознал, что не может не радовать

15 октября мы раскатили прошивку на 10% устройств. Поэтапная раскатка обновления — это стандартная практика. Она предназначена в том числе для того, чтобы выявлять проблемы новых версий на ранней стадии. И прежде чем увеличивать процент раскатки, мы отсматриваем метрики всех ключевых пользовательских сценариев. Но число генерируемых нами NTP‑запросов исторически никогда не входило в метрики, требующие валидации, потому что NTP‑клиент годами существовал практически без изменений и не приводил к проблемам.

К 24 октября новая прошивка докатилась до 100% колонок. Опять же, критичные для пользователей сценарии покрыты автоматическим мониторингом. Если что‑то важное ломается, мы получаем уведомление. Но, как вы уже догадались, для NTP‑клиента таких уведомлений настроено не было.
. . .
Жалоб было мало, действующий регламент поддержки не был рассчитан на подобные ситуации, поэтому обращения рассматривали не в самом высоком приоритете. К 20 ноября мы нашли ошибку, внесли исправление в код и начали готовить новый релиз.

В выходные 23–24 ноября ситуация с NTP‑серверами обостряется: доступными остаются лишь четыре сервера. К этому моменту мы уже начали раскатывать релиз с исправлением на 10% устройств.
. . .
В воскресенье мы выпустили хотфикс в виде новой рантайм‑конфигурации для NTP‑клиента, который увеличивал период перезапроса с 5 до 600 секунд, уменьшая нагрузку на серверы в 120 раз. Хотфикс не исправлял проблему полностью, но был единственным быстрым способом снять чрезмерную нагрузку с NTP-серверов.
. . .
мы запланировали выделить ресурсы в общий пул NTP‑серверов. Это займёт некоторое время, потому что наши дата‑центры удалены от основных точек обмена трафиком, а для NTP‑серверов RTT (Round Trip Time) это — ключевой фактор качества. Мы установим и запустим мощности на основных точках обмена трафиком.

Для наших устройств мы заведём именную зону в соответствии с гайдлайнами проекта NTPPool.org для бо́льшей прозрачности. Генерируемый ими трафик будет локализован на наших NTP‑серверах, если мы продолжим полагаться на публичную инфраструктуру проекта.

Ещё мы добавим метрики, связанные с NTP, на этап валидации A/Б‑экспериментов, а также реалтайм‑уведомления о неполадках в этом компоненте. В том числе расширим сценарии мониторинга исходящего и входящего служебного трафика устройства в целом. Также поработаем над каналами коммуникаций и поддержкой, чтобы подобные проблемы быстрее до нас эскалировались.

Об инциденте с NTP-серверами
https://habr.com/ru/companies/yandex/articles/861538/

Спасибо подписчику за ссылку

Too big to…. но этим все большие страдают.

Сегодня день кофе и nexthop.

Напоминание о том что такое Интернет и от том, что от этого понимания очень многое зависит, особенно когда начинаешь что-то в нём менять. Результат изменений за последние 40 лет мы уже видим и что из Интернета получится, конечно, тоже увидим.

Why I stopped using OpenBSD?

Last month, I decided to leave the OpenBSD team as I have not been using OpenBSD myself for a while. A lot of people asked me why I stopped using OpenBSD, although I have been advocating it for a while. Let me share my thoughts. First, I like OpenBSD, it has values, and it is important that it exists. It just does not fit all needs, it does not fit mine anymore...

https://dataswamp.org/~solene/2024-11-15-why-i-stopped-using-openbsd.html

#system #hardware #problems

P. S. Well, such feedback should be taken into account, too.

Рано перешли на BSD, возвращаемся:

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

У APNIC есть сервис который пытается отображать количество пользователей в автономных системах. Geoff Huston пишет как это устроено - на рекламных объявлениях. С точностью правда беда, в основном об этой беде вся статья. Но так как, в принципе, такой информацией мало кто делится, а если и делится то тоже привирает, поэтому хоть что-то лучше чем ничего.

Эксперименты Cisco SD-WAN со Starlink, хотя статья маркетинговая с перечислением фишек, но результаты тестов Starlink интересные. Чистый тест хуже ожиданий, потери до 4% и задержки выше, зависимость от географии. Но после того как покрутили настройки, всё, конечно, стало значительно лучше.

Juniper про новую функцию vpn-global-import, которая должна упростить жизнь провайдерам.
Механизм разнообразных таблиц, типов маршрутов и метрик у них достаточно объёмный, что выливается в такой же объёмный конфиг для решения рядовых задач. Но с другой стороны десять раз подумаешь, а стоит ли нарушать границы, которые часто сам же и провёл.

RIPE NCC подробно, со ссылочками и ценами, рассказывает про разные способы получения IPv6 и IPv4 адресов, документ на русском в pdf. IPv4 у них нет, точнее придётся подождать в очереди 1,5 года, поэтому только аренда у тех у кого есть или покупка на рынке.

Кстати, да.

Вспоминая свои первые шаги в профессии - понимание виланов, транковых и портов доступа, тегов, было наверное самым сложным, после этого всё завертелось быстрее.
Недавно в разговоре я столкнулся с тем, что начинающие практиковаться в сетях неотъемлемо связывают виланы с маршрутизацей и IP адресацией. Почти как здесь, где происходит в основном настройка интерфейсов маршрутизации (сабинтерфейсов, SVI) хотя названо всё это настройкой виланов. У себя я такого не помню, одно от другого было отделено, может быть потому что меня сразу пускали только коммутаторы настраивать. Вилан как сущность - это одно, а интерфейс с адресом - это другое, и одно без другого прекрасно существует.

Дизайн централизованной внеполосной сети управления для провайдеров, можно взять как пример, но тут, конечно, сразу всего много, с учётом опыта громких падений последнего времени. В любом случае придётся построить полноценную сеть рядом, что провайдерам особенно аукнется, с учётом того что даже продуктовые каналы не всегда есть возможность зарезервировать.
В датацентрах часто присутствует услуга удалённой консоли, которая, наверное, не будет доступна при проблемах самого датацентра, но по крайней мере будет доступна при проблемах с вашей сетью или устройствами. В своей инфраструктуре можно начать с консольного сервера для критичных вещей, например, Opengear, или Moxa NPort, а у Cisco есть aux порт и reverse telnet/ssh. Когда все аварийные вопросы закрыты, можно смотреть в полноценную OOB сеть, если конечно её не построили сразу в момент проектирования основной.

Я не знаю как к такому можно быть готовым: Kentik рапортует об увеличении трафика Netflix в 4 раза, то же и на пиринге у Ohaio IX где в абсолютных цифрах выглядит страшнее. Эфирное телевидение с такими событиями лучше справляется, сколько бы народу не смотрело, а Netflix, судя по многочисленным отзывам не справился. Операторам связи, скорее всего, тоже досталось, вряд ли кто-то держит четырёхкратный запас, чтобы такое переварить, если заранее не знать.

Обзор методов работы с файлами из приложений. Всё, конечно, не просто.

Чуть больше подробностей о том как Fortnite распространяет свои обновления, что это становится заметно всем. И они так делают не первый раз, и не только они.

Ох, сравнение в одной статье QinQ, MPLS и SDH c DWDM. Всё это, конечно, для передачи Ethernet как сервиса, но чтобы так в лоб сравнивать. Интересно, что автор называет QinQ проще чем MPLS, но в то же время противоречит сам себе и говорит, что обычно опыта работы с L2 не хватает поэтому большинство выбирает MPLS.
Масштабно QinQ мне встречался 15 лет назад и это была только провайдерская сеть, где для сегментации обычной нумерации виланов не хватило и пришлось добавлять второй тег. Но позже, несколько раз приходилось использовать двойное тегирование в том смысле в котором написано в статье, чтобы перенести клиентские виланы сквозь собственную сеть, не нарушив инкапсуляцию. В таком микро виде, с минимум подготовительной работы, QinQ действительно проще. Но L2 сети остаются L2 сетями со своими заморочками, а при том количестве материалов описывающих MPLS в различных видах, он не кажется сильно сложнее или дороже в эксплуатации.

Fastly радуется тому что не попал в новости и поэтому делает новость сам про RPKI и проверку маршрутов. Проблема утечки и перехватов маршрутов в Интернет, как и технология RPKI давно уже не новая и широко используется, настолько, что государства обратили на неё внимание, как минимум в США и России (ищем на 71 странице pdf).
Сейчас подписано больше половины всех маршрутизируемых префиксов, пора внедрять проверку для широкого круга, а это делается немного сложнее чем просто подписать, но делать тоже надо. В будущем, наверное, доживём когда неподписанные прификсы приравняют к сбойным и тогда можно будет считать вопрос в этом аспекте решённым.

Помните про serverless? Говорят что оно возвращается. На мой взгляд далекого от этого человека всё выглядит дико странно. Серверы никуда не делись, поставщики просто переподняли их у себя, на примере AWS Fargate, поменяв сложность обслуживания серверов на сложность взаимодействия с облачным провайдером, скорее всего не одним, и построение собственного слоя абстракции.

Пошаговый разбор момента установки BGP сессии в дампах трафика, начиная с рукопожатия TCP, на минимальной конфигурации BIRD.

Автоматизация чего-то вещь сугубо индивидуальная и для этого не существует коробочного решения, особенно если говорить об автоматизации всего, а не какого-то отдельного элемента. И это только о чисто технических вопросах, а ведь ещё есть и человеческий фактор.
В сертификатах, не только по автоматизации, особенно вендорских, есть другая проблема, о чём написано в самом первом абзаце, но дальше мысль раскрывается другая. Очень сложно соблюсти баланс общего и частного и не скатиться, с одной стороны к перечислению методов конкретного API, а с другой стороны к описанию принципов работы интерпретаторов, например. Очень хорошо понимаю вендоров когда в их экзаменах только их технологии и подходы, но это всё разваливается если нет какого-то общего знаменателя для всех. Названия пунктов меню конкретного продукта, очень быстро устаревают и помнить их нужно только до момента сдачи экзамена. Важнее система, в хороших продуктах она есть, в очень хороших эта система становится общей для отрасли. Без системы это сертификат одного продукта, что в общем тоже полезно и имеет место быть.
Наше высшее образование частенько ругают за отсутствие практики, но согласитесь, что двоичная арифметика, алгебра логики, теория множеств, теория графов, пережила уже не одного вендора, а конкретные применения всего этого понять проще и быстрее зная основы.
Список сертификатов по сетевой автоматизации есть в статье. Я в самом начале посматривал на сдачу DevNet, но конкретные ссылки методов в конкретном продукте меня тогда сильно смутили. А вот Ansible, YAML, Pyhon, REST и все остальные инструменты и технологии которые понимаются сейчас под автоматизацией и стали отраслевым стандартом, вполне себе можно изучать в деталях.

После 3-х лет теперь стандарт RFC9687. Чиним проблему зависших сессий BGP, когда TCP нам не друг.

Амазон про криптографические алгоритмы на эллиптических кривых, что это такое, зачем там простые числа и как они их хорошо реализовали. Результат смотрим на Github.

Kentik про очередной BGP route leak, на этот раз через Узбектелеком. Что и куда утекло, через Россию, и как это отразилось на Интернет. Что делать тоже понятно, надо только делать.

ИИ в сетях. Помимо очевидного анализа данных в повседневных задачах - AIOps, в том числе и в домашних условиях, который можно делать уже прямо сейчас, ещё можно продавать "лопаты для золотоискателей" - строить ЦОДы для задач ИИ. Немного ссылок, экономики и скепсиса. Как всегда результаты узнаем через несколько лет, насколько это было хайпом или не хайпом.

Кровавый энтерпрайз be like. Где-то в недрах Yandex. Конфколл:
- Так, нам надо провести конференцию для сетевиков. Мы такое уже делали, поэтому все всё должны знать. Нужные таски я уже завёл. Маша, на тебе форма регистрации.
....
Маша: "Фронтедеров знаю, бэкендеров знаю, девопсов тоже знаю. Сетевики хммм, если из инфраструктуры, то, точно не HR. Наверное, программисты такие. А у нас и стандартная форма есть, добавлю ещё согласие на предложения работы, программистов мы всегда ищем."
Фронтедеры: Размещают форму регистрации без прямой ссылки, чтобы ей никто не мог поделиться.

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

А как же NAT? А к нему настолько все привыкли, что по умолчанию сразу проектируют как его обходить, вот пример для QUIC p2p. Причём QUIC сразу не закладывался на привязку к каким-либо IP адресам, у него свои идентификаторы, которые всегда обеспечивают связность из конца в конец, даже при смене IP на лету, а бонусом multipath передачу.

Geoff Huston озвучивает то о чём многие не только догадывались, но и вполне себе знали - IPv6 не несёт ничего нового с собой в современный мир, поэтому ждать скорого поголовного внедрения не приходится. Как всегда много истории про то что было, как принимались решения, что предполагалось. IPv6 старый протокол, его придумали чтобы решить в основном проблему нехватки IPv4 и поэтому не сделали там ничего особенного по сравнению с IPv4. Вот это "ничего особенного" и не позволило выиграть за явным преимуществом сразу. А потом весь Интернет изменился, сети больше не на центральном месте в экономике потребления контента, сети просто сети, рулят приложения и DNS, поэтому сквозная проходимость не нужна, и уникальные адреса не нужны, хватает и переупаковки того что уже есть.
В начале статьи приводится срок окончания перехода на IPv6 - 2045 год, при условии сохранения линейного роста, а заканчивается статья на том, что переход может и не закончится, но никому до этого не будет никакого дела.

Я конечно, не Geoff Huston, но таки смахнул слезу и перечитал свою статью от 2015 года - "IPv6 не нужен?", где заголовок статьи не вопрос нужности или не нужности самого IPv6, а вопрос продавца-провайдера на рынке, который ходит и предлагает IPv6, а его никто из абонентов не берёт, потому что не видит разницы. Гадания когда всё закончится у нас тоже регулярно проводятся, последнее показывает что линейный рост кончился.

В любом случае, это не значит что сейчас надо бросить и не заниматься IPv6, конечно нет. 45% это ого-го! уже 45%, почти половина и их будет ещё больше, не в этом так в следующем году перевалим за половину. Поэтому без поддержки этого уже не нового протокола может внезапно стать хуже, и хотя бы к этому, чтобы не стало хуже, не говоря про то чтобы стало лучше, надо быть готовым.

Зафиксируем ситуацию. Из проголосовавших, PON продают большинство, 10G-PON много. Наверное, PON, и 10G-PON, и 50G-PON в перспективе, хороший такой фактор увеличения скоростей доступа к Интернет. С Ethernet для скоростей больше 1G всё равно придётся переходить на оптику, для чего надо будет постараться, в PON это от рождения. Одинаковую скорость восходящего и нисходящего канала в PON тоже придумали. Мой скептицизм по поводу более закрытого и узкоспециализированого решения никуда не делся, но в этом витке технологий ITU побеждает, предлагая классический стандарт связи.

Чат, привет!

Я выпустил новую версию NextBox UI Plugin для отрисовки сетевых топологий в NetBox, и это самый большой релиз за 4 года его существования:

– Новый движок визуализации, написанный мной же с нуля (в итоге назвал его topoSphere).
– Основательно переработанные фильтры.
– Поддержка темного режима.
– Экспорт в PNG/JPEG/JSON.

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

С безопасностью почты, настоящей, той что SMTP, всё очень плохо. DANE из-за DNSSEC не летит. MTA-STS тоже не летит, но тут скорее из-за того что смешали вместе веб и почту, хотя с ним вроде бы проще должно быть по замыслу. В итоге, все всё знают, что не стоит посылать важных писем почтой, вроде сбросов паролей или доступов в личный кабинет, но продолжают так делать.

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

Новое, самое большое на сейчас простое число 2^136279841-1

Больше разрядность процессора - больше места под указатели памяти и данные, больше места - больше обрабатывать, больше обрабатывать - меньше скорость. Всё так и не так одновременно, при сравнении 32-битных и 64-битных архитектур. Поменялись не только размеры, но и подходы в том числе, что нивелировало фактор размера, но всё равно имеет свою цену.

Broadcom объявляет, что 50G-PON уже здесь. Дополнительно встроили туда AI и ML, по делу или не по делу, но сейчас без этого как минимум в анонсах, ни у кого не обходится. Наверное, стоит ждать массового перехода на 10G-PON, раз уж что-то более новое появилось.

Я никогда не смотрел обзоры на сериал, мне нравится и так, поэтому я не знаю была ли это отсылка, или сценаристы снова это придумали в одном из любимых моих моментов, или это я просто придумываю. В эпизоде "410 Gone" Элиот и Дарлин сидят в парке и наблюдают как у всех вокруг звонят телефоны, получив оповещение о зачислении Ecoin, так же как "газонокосильщик" Джоб заставил звонить все телефоны в мире оповещая о своём успехе. Такая связь, даже если я её придумал сам, меня сильно впечатлила, поставив у меня в голове эти фильмы на один уровень.
Искренне могу советовать смотреть, я знаю что далеко не всем нравится, по разным причинам. Но как в настоящем произведении здесь есть только доля выдумки и ещё айтишный антураж и не только он.

Поделюсь с вами пятничным настроением. Мне нравится сериал Mr. Robot, настолько что я купил эту маску. Вещь, как оказалась, не сильно популярная и оттого гораздо дороже чем маска Гая Фокса или новогодняя маска зайчика. Поэтому я сомневался, забывал на несколько лет, вспоминал, возвращался, искал, смотрел на цену, понимал что не хочу столько отдавать за бесполезную вещь, и так по кругу. Но теперь я доволен, хотя максимум через неделю или две положу на дальнюю полку и опять забуду на несколько лет.

Geoff Huston про то какого размера должен быть пакет данных передаваемый в Интернет. Но сначала история всего того что есть сейчас начиная с 10Мбит/c Ethernet, где 1500 октетов было обусловлено компромисным техническим решением. И как оказалось это решение более чем удачно работает до сих пор. Может быть это из-за того, что если что-то поменять, то очень многое отвалится и никакие path MTU Discovery не спасут, а может, потому что и правда больше не нужно. В любом случае, новый QUIC тоже такие правила принял.

Симпатичный IPv4 калькулятор, можно одним движением делить и объединять подсети, что наглядно отображает получившуюся иерархию. Ещё можно каждый префикс прокомментировать и экспортировать при желании.

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

Все бросаем Linux и переходим на BSD, в которой всё прекрасно, даже The Register впечатлился. Это личная история автора начиная с середины 90-х, наверное где-то больше эмоциональная чем техническая, поэтому недостатки Linux видны хорошо, а недостатки BSD не очень. В любом случае у нас есть и то и другое, чтобы выбирать.

В Британии тоже переживают, что ECH поломает всю малину с фильтрацией, конкретно в школах, и дают несколько советов как этого, по возможности, избежать - заставить устройства не использовать ECH. Применимо не только в школах, конечно же. Самое простое, если вы контролируете всю инфраструктуры вплоть до конечных устройств, что в школах скорее всего и реализовано. Ещё предлагают пройти тест на testfiltering.com, очень хорошо замаскированный в тексте статьи, чтобы оценить насколько ваш фильтр хорошо работает, опять же с прицелом на ограничения в школах и публичных местах.

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

На Habr перевели быстрее чем я оригинал прочитал - про реальный мир, и виртуальный, и судьбу домена верхнего уровня IO. Пожалуй один вопрос остался не затронутым, это правила регистрации в страновом домене всех подряд без разбора. Красивых двухбуквенных доменов много, не только IO, а например AI. Но ответ, наверное, тот же - деньги. И как бы автору не хотелось, реальный мир продолжает управляет виртуальным.

Google переосмыслил синтаксис SQL, говорит, слишком сложно всё было и непонятно. Назвали GoogleSQL.

Пинговалка на TCP - tcping, всё по современному, есть и докер образ. А если прошли мимо nping, то посмотрите на него сначала, там возможностей побольше.

IPv6 всё ещё остаётся новым протоколом с детскими болезнями, которые всплывают то там то там. Больше рекламная статья, но которая расскажет вам что в Node.js было не всё хорошо с Happy Eyeballs. Этот механизм сам по себе костыль переходного периода, но так как переход на IPv6 процесс из многих этапов, то проблемы будут ещё возникать при смене каждого из этапов. И даже на самом последнем, когда IPv6 будет много, а IPv4 мало, отключение IPv4, но скорее отключение механизмов доступности IPv4 из IPv6, обязательно что-нибудь да сломает.

Позавчера вечером RIPE NCC предупредил всех о фишинговой атаке на членов RIPE. Сегодня чатиком принесло пример письма. Вполне себе цепляет, поэтому внимательность, внимательность и ещё раз внимательность. Невнимательность дорого обходится.

Как обстоят дела с доверием PKI в вебе и его частями CAA и DANE? Не очень хорошо и про это мы знаем. А всё потому что DNSSEC, по сути ещё на зачаточном уровне, а без него остальное имеет мало смысла. Записей CAA больше и ошибок в них меньше, потому что их вставляют автоматически большие хостеры, вроде Cloudflare. Но если вспомнить что DNSSEC, по хорошему, и для CAA нужен, то всё опять становится не радостно. DANE вообще в браузерах на поддерживается, но хоть в почте его кто-то использует. Остаётся CT, который сам по себе реактивный механизм и не решает даже тех задач для которых разрабатывался.

Вот, кстати, пример контента на широкую управленческую аудиторию, чтобы обозначить хотя бы термины которыми эти ваши инженеры общаются - всё вперемешку, техника вместе с маркетингом. Не показывайте своему ПМ, иначе потом будет вот так: "Я знаю бокс, самбо, карате и много других страшных слов".

А вот программисты никак не могут смириться с тем, что их профессия теперь рабочая специальность: далее, далее, готово... Но к этому и стремились, вроде бы. Та самая обратная сторона массовости и понятности.

Тезисы выступления нашего автора Дмитрия Завалишина, основателя и гендиректора DZ Systems, на конференции, посвящённой 25-летию ассоциации РУССОФТ.

Невозможно одномоментно добавить на рынок миллион опытных разработчиков. Но возможно разделить ПО на классы и требовать ответственного отношения к процессу проектирования.

В IT-индустрии практически двойная нехватка кадров. Есть сервисы, которые учат соискателей не программировать, а проходить собеседования. Из-за этого в IT огромное количество людей, которые не умеют качественно разрабатывать ПО.

Современный процессор обгоняет Pentium в 50-100 раз. При этом программы работают на процессорах, которые в 100 раз быстрее, с прежней эффективностью. Программы стали хуже в 100 раз? Да.

Современный программист не разрабатывает, он компонует результат из готовых библиотек. Результат такой «разработки» — излишняя сложность систем с большим количеством обёрток, прокладок и костылей в коде. Это полная победа Agile-программирования, где важнее построить систему абы как, без качественного проектирования. И даже критичные программные системы исправляются только после поломок.

Никогда не считал что "Сетевая инженерия" популярная или была популярная, хотя может я, конечно, этот момент не застал. Из всех тех с кем я учился до того как стал работать по специальности, включая профильное направление "ЭВМ, комплексы, системы и сети", сетевиком никто не стал. Да и мой путь в большей степени случайность, чем осознанный выбор. Поэтому мне не понятно почему надо опять сделать её популярной, а не просто популярной.
То что раньше было лучше, это понятное брюзжание, это вообще всего IT касалось и не IT, а не только сетей. То что облака, программирование и кибербез привлекают больше внимания, трудно спорить. В какой-то степени это более понятно и доступно из-за обилия информации вокруг. Для сетей, при том что с ними все сталкиваются ежедневно, такой информационный фон создать труднее, просто потому что на бытовом уровне на сети никак не повлиять, только страдать когда что-то ломается и читать в новостях про неведомый BGP. А "облаками" пользуются многие далёкие от IT люди, по крайней мере думают что пользуются, так же как и сталкиваются с вирусами и мошенниками. Ролики в Интернете, наверное, кого-то привлекут, но как и весь популярный контент рассчитанный на широкую аудиторию, порой больше вводит в заблуждение относительно специальности, чем объективно что-то рассказывает. Но что правда, то правда, чисто сетевого контента на широкую публику, не так уж и много. С другой стороны, осознанный выбор не раскрученной специальности, должен быстрее провести от новичка до профессионала, по причине большего желания заниматься именно этим.
Стоит передать привет телефонистам и связистам вообще, которые вроде как справились со своей "непопулярностью". А компьютерные связисты, пока ещё в стадии переживания по этому поводу.

Собирать и хранить данные BGP задача требующая много ресурсов и существующие системы покрывают только единицы процентов от общей картины, что не позволяет делать достоверные выводы о многих событиях происходящий внутри глобальной BGP таблицы. Предлагаемый выход - увеличивать количество точек наблюдения и сокращать избыточность данных, что и реализуется в новом подходе названном GILL. Посмотреть как это уже работает можно на bgproutes.io, там же подать заявку на пиринг, чтобы помочь расширить охват.

А текущее состояние глобальной BGP в существующем агрегаторе RIS от RIPE NCC, можно увидеть не выходя из телеграмма в моём боте @FullViewBGPbot.
Что касается второго бота - @BGP-TableBot, я недооценил проблему возвращения на Twitter в качестве источника обновления сведений, так как там все нужные для работы функции API теперь только по подписке. Но хорошая новость, я написал автору оригинального бота и он постарается починить обновления через Mastodon, как до этого дойдут руки. Поэтому как только будет альтернативный канал, так сразу я на него переключусь, но пока без вариантов, ищем первоисточник здесь и здесь.

LLDP как способ идентификации конечных устройств. Мне почем-то сразу подумалось про DHCP opt. 82 или 37 для IPv6, если всё равно есть DHCP и приходится обрабатывать идентификаторы где-то на сервере, а вот если бы DHCP не было бы... Но, наверное, такой путь для автора был короче. Мне в этом решении сильно не нравится, что конечные устройства умнеют для того чтобы смочь обработать поступающий к ним LLDP, когда мы хотим их сохранить простыми - классическая инженерная дилемма, разрешить которую можно многими и многими способами.