Пока ещё не все провайдеры настроили DoH на своих DNS. Может и не настроят никогда, вот я даже за нас сказать не могу. В любом случае время отклика тех кто уже настроил, правда из Сингапура, а это сильно влияет на конечный результат.

Вот на таком уровне у нас IPv6 в мире. На самом деле это хороший вопрос ученика который идёт вслепую. Такие же вопросы, например, в IPv4 есть про маску: "Почему она всегда 255.255.255.0?" - и подобные этому.
На них надо отвечать обязательно и это, наверное, самая важная составляющая в развитии IPv6 - чтобы он стал понятным для тех кто его касается. Хотя мой опыт подсказывает что даже если думать что IPv4 маска всегда /24 можно в принципе успешно справляться с настройками сетей. Вот такой вот расклад, нужно удовлетворять клиента (своего клиента), а не свои желания и бездушную железку этими вот MPLS, SD-WAN и прочим :)

Больше казусов IPv6 на IPv6 Excuses в Twitter.

То чувство когда только WiFi абонентов на Cisco Live больше половины всех твоих абонентов.

Хорошая пятничная картинка на xkcd.com. Ещё не все слои распределены (да и все не нужны), остался Network и Transport. Интересный постмодерн намечается.

Интересная инициатива от RIPE NCC.
Очевидно, что создание множества тулов и счётчиков, вроде RIPEstat, RIPE Atlas, RIPE Labs statistics, обеспечило райпу доступ до множества данных о владельцах ресурсов, коннективити, роутинге, распространённости протоколов и прочей увлекательной статистики.
И чтобы ценный мех не лежат просто так, RIPE NCC планирует выпускать статистические отчёты о положении дел в разных странах. Конечно, не глобально, а в зоне их ответственности. А дабы не создать очередную пачку бумаг с графиками, они пытаются играть в угадайку, предсказывая путь развития сетей в конкретной стране.
Начать решили с Саудовской Аравии.
https://labs.ripe.net/Members/chrisb/ripencc-saudiarabia-report-jan2019.pdf

Routing Policy Language из Cisco IOS XR одно из тех очевидных изменений которые видны сразу. И я очень долго не мог понять что не так с этой мощной штукой, почему она вызывает диссонанс. Вроде добавили уйму гибкости, добавили кучу мест где можно применять, ну изменили синтаксис и изменили.

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

Явные следы различия в подходах видны в том, что редактирование политик на RPL не вписалось в обычный conf t режим, и для удобного редактирования надо идти в настоящий редактор : nano, emacs, vim.
В дополнение ко всему сам язык определяется очень избыточно. Например, нет единого оператора in, есть destination in и source in, при этом схожий по смыслу оператор для набора community имеет вид community matches-any. И так для всего, т.е. в самом языке спутаны разные парадигмы.

Если уж программирование то программирование, прикольно было бы иметь весь конфиг в виде программы, что-то типа:

...
Interface gi1 = GigabitInterface(card=0, num=1)
userInterfaces.add(gi1)
for userinterface in userInterfaces do
userinterface->shutdown = False
end
...

Но такого может и не будет, перейдём совсем на API исключив необходимость заходить в CLI режим, а конфигурация будет где нибудь в базе данных лежать.
Если вспомнить начало 2000-х, то не такой уж и оригинальный подход. Тогда многие сетевые устройства конфигурировались через псевдографический интерфейс или через специальную утилиту. Конфигурации как таковой не было - она была бинарная в закрытом формате, ровно так, как осталось до сих пор в домашних маршрутизаторах.

Иногда проще показать, чем рассказать. Меня конечно сильно раздражает когда в чатики кидают скрины cli вместо текста (хотя казалось бы) - сразу убивается поиск, возможность скопировать и тут же попробовать... ладно, современный подход. Коллеги, не делайте так!
С гифками это имеет хоть какой-то смысл - видно действие, что интереснее. Утилита которая записывает гифки из Linux консоли, на node.js. GitHub.

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

Помимо Terminalizer, можно упомянуть
https://asciinema.org/ (https://github.com/asciinema)
https://showterm.io/ (https://github.com/ConradIrwin/showterm)

A также вспомнить несколько мертвых проектов:
TermRecord (https://github.com/theonewolf/TermRecord)
Shelr (https://github.com/antono/shelr)
Terminal-Recorder (https://github.com/cortezcristian/terminal-recorder)

Взрывной рост DANE для SMTP - не проспите. Не понятно кто кого тянет, так как тут ещё DNSSEC завязан. Это не так просто как использовать готовые скрипты от Let's Encrypt, но заметное движение есть. Почта уходит вслед за вебом.

IPv4 кончаются и это не новость. В RIPE NCC об этом конечно знают и предлагаю всё-таки прикрыть лавочку невиданной щедрости раздавая новым LIR по /22 в руки - сократить до /24. Пока в стадии обсуждения, поэтому присоединяйтесь к дискуссии. Медитировать на остаток IPv4 можно тут.

Не мытьём так катаньем, как говорится. Эра IPv6-only сетей не за горами и не думать об этом безответственно. Как можно напомнить об этом IPv4 пользователям если у вас Nginx - интересный подход с использованием geo.

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

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

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

Ещё что отличает этот экзамен надо понимать принципы многих направлений Cisco: есть про датацентры и безопасность, беспроводные сети. Только гайд я бы сразу рекомендовал читать для CCDP, он покрывает всё то что есть в CCDA в большей степени. CCDA руководство тоже неплохое, коллега сдал практически используя только его.

Другой момент, за рамками RS чаще случается так что дампы не актуальны и даже сильно не актуальны, всё-таки спрос рождает предложение. Автор не пользуется, но купил дополнение с движком для тестов и вопросами к официальному руководству. Потому что готовиться именно к экзамену не менее важно, даже при наличии всех необходимых знаний стоит привыкнуть к формулировкам вопросов, как минимум. На learningnetwork.cisco.com есть раздел практики, и хотя написано что он не отражают текущую ситуацию (что правда, обычно он формируется в момент создания трека или смены номера версии), но по большому счёту это полезный инструмент, игнорировать его не стоит (надо быть залогининым).

Если уходить ещё дальше, то и официальных руководств конкретно под экзамен может не оказаться, вот это уже сильно печальнее. Всё-таки имея описанный путь идти проще.

Раз начали сегодня со шпаргалок пусть ещё будут https://catonmat.net/projects/cheat-sheets - на разные темы из мира Unix/Linux, разной степени новизны и детальности.

Обзор WiFi IPv6 со стороны клиента на CiscoLive 2019. Больше про IPv6 чем про WiFi, много ссылок на стандарты и лучшие практики, плюс комментарии полученные от NOC, ответы на вопросы почему было сделано именно так. Сколько там было абонентов мы помним.

Новый выпуск в серии Juniper DayOne. Тема выпуска - BGP Security.
68 страниц о формировании удобного подхода к фильтрации маршрутной информации, инфраструктуре RPKI, продвинутой работе с маршрутными политиками и прочим.

Прямо очень радужные прогнозы для IPv6 в 2015 году. Годом ранее наш собственный проект IPv6 далеко не улетел и ситуацию мы оценивали совсем по-другому.
К 2025 может всё так и будет, но характер роста сейчас определённо другой. Возможно всё за пару лет решится.

Если не используете IPv6 лучше понизить ему приоритет чем выключить - совет из блогов Microsoft. Приводится случай из практики, когда выключение IPv6 привело к проблемам. Случай конечно спорный, скорее тут надо о другом говорить. Но ссылки на все варианты приведены, даже на собственно отключение - когда точно знаешь что хочешь сделать.

Из нашей практики: дуалстек, конечно, добавляет проблем. Совсем недавно коллега жаловался что Firefox его время от времени перекидывает на captive portal, при этом всё работает без проблем, в Firefox в том числе. Стали разбираться и нашли что IPv6 адрес который используется для определения живости интернета Firefox'ом попал в блэкхолинг после очередных наших работ.
Чинится легко, но ищется долго, не каждый раз проблема возникает у профессионала и далеко не каждый раз её можно повторить. Мы всё-таки сначала на Firefox грешили (что отчасти правда, но не причина).

​Заканчивающаяся неделя опять нам подкинула новостей про суверенный интернет. Интересная тема в разрезе роли государства в капиталистическом обществе. Понятная цель заботы о собственной безопасности, правда понятная. Но если хочется безопасности и надёжности, я бы строил свой интернет - новый, со всеми академическими выкладками, расчётами и проектами на каждом уровне, чтобы понимать что если у тебя выпало больше положенной нормы осадков в какой-нибудь области, то вероятность выхода из строя магистрали Москва-Камчатка вырастает от 30% до 70%. И да, это будет дорого. Очень.
Но когда всё будет построено будем иметь хороший резерв для стратегических ресурсов. Это уже отдельная задача определить какие ресурсы стратегические и являются ли таковыми Госуслуги или не являются. А потом предоставить всем операторам связи на некоммерческой основе данный резерв, чтобы стратегические ресурсы были доступны всегда. Так как их количество сильно ограничено, то и трафика там не много. А если учесть что это только резервный путь, то можно строить на очень непроизводительном оборудовании со всеми слоями шифрования, для чего отечественная промышленность уже готова. А обычный Интернет пускай им и остаётся. Наверное, я за такой путь, мне он был бы понятен.

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

Вряд ли подобная карта есть вообще у кого либо из операторов, в лучшем случае она детализирована до оперативно необходимой степени и не более. У нас есть отдельно L2 связности ("бумажная"). Отдельно L1 тоже "бумажная" в нескольких вариантах, отдельная для строителей, отдельная для админов, ещё и в разных форматах. Некоторые участки этих карт детализированы чуть сильнее - добавлен L3 уровень. Из электронных вариантов есть автоматическая карта виланов и адресного плана, который есть отдельно ещё в "бумажном" виде.
С натяжкой можно сказать что таблицы маршрутизации и есть та самая карта, причём определённая формально и строго математически, подходит для анализа и расчётов. В ней уже показаны оптимальные и резервные маршруты. Но она покрывает опять же, только один из уровней, часто какой-то средний.

Как себе представляет это и что будет делать РКН - вопрос. Сейчас есть реестр инфраструктуры связи в котором ведётся количественный учёт операторов и некоторых из их характеристик для населённых пунктов (не всех). В частности можно узнать максимальную и минимальную заявленную скорость провайдером, количество теле- и радиоканалов, количество таксофонов и почтовых отделений. Это интересно, но мало, очень мало и поверхностно, например совсем нельзя понять кто от кого зависит. RIPE NCC или Qrator со своей картой BGP связности знает больше об этом. И это только BGP, что далеко не всё.

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

P.S. Картинка - это мой реестр провайдеров Интернет Волгограда, не очень актуальный, основанный по большей части на BGP, но не только. Слегка запутанный, но наверное дающий какой-то представление о положение вещей. Не работа, хобби, на которое никак не хватает времени.