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

Не будем придираться к fd00::/8, никто с ними никогда не заморачивается.

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

В этом году получилось 591 постов, которые просматривались в среднем 620 раз, самые читаемые про уязвимость в libssh, про новогоднюю ёлочку и про то что надо делать бэкапы. Из недавних, новость про покупку сетей Амазоном и про зарплаты и сертификаты.

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

Большая часть записей отмечена хотя бы одной положительной реакцией и не имеет отрицательной, но такая опция есть и максимально она выражена в постах про ДОМ.RU и Linkedin, про IX, RTT и провайдерские решения и как у нас оптику чуть не оторвало.

Мы по прежнему много цитируем, всего 987 ссылок на разные ресурсы, больше всего на GitHub, Twitter, Habr, RFC, Cisco, RIPE и APNIC. Всего 369 уникальных сайтов.

Телеграм каналы здесь тоже часто упоминаются. Я хотел дополнительно оформить список на всё то на что я подписан, чтобы синхронизировать наши информационные потоки, но получилось много для итогового поста - в сумме больше 130 каналов и чатов более-менее по теме. Я думаю вы и так кликаете по ссылкам и подписываетесь на интересные, хочу только упомянуть @conpoint - про то как делать кабель-порно и @minicomcn - картинки про киски и циски, которые тут встречаются редко, но на них стоит посмотреть.

Как было в предыдущем году можно почитать в похожем резюме, а мы продолжаем в новом году. Спасибо что с нами!

P.S. Вопрос "Про что же данный канал?" переносится на следующий год, я ещё пока не разобрался :) Так что, добро пожаловать, читайте и составляйте своё мнение, а мы вас будем за это благодарить.

Не так давно пришлось вспомнить и поработать в настоящем текстовом терминале, в окружении DOS (в основном) и Linux. Что-то в этом есть - псевдографические интерфейсы не идут ни в какое сравнение с современными TUI в графическом окружении. Уместить в 80x25, 16 цветов и 256 символов  информации не меньше чем сейчас помещается на два монитора, это удивительно. А если ещё и шрифты правильно подобрать. Что впрочем не мешает их использовать и наслаждаться похожими видами в современных условиях.

Немного почти юмора про современное толкование понятий сетей:

Routing Protocol: Used to mean the protocol, including the semantics and algorithm or heuristic, used to calculate the set of loop-free paths through a network. Includes instances such as IS-IS, EIGRP, and OSPF. Now means BGP, as this is the only protocol used in any production network (except SDN).

Router: Used to mean a device that determines the next hop to which the packet should be forwarded using the layer 3 address, replacing the layer 2 header in the process of forwarding the packet. Now means the same thing as a switch.

Switch: Used to mean a device which determined which port through which a packet should be forwarded based on the layer 2 header, did not modify the packet, etc. Now means any device that forwards packets; has generally replaced “router.”

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

До этого доводилось администрировать MX, SRX и даже ERX, правда во времена когда суть для меня была не так понятна. Но в любом случае ощущение от устройства - море свободы в  реализации нужного тебе решения при том, что границы возможностей очень чётко обозначены. Почти уверен что не разочаруюсь.

Подробный разбор процесса начала загрузки web страницы с точки зрения теории TCP и "догмы" уместить все критические данные в первые 14Кб ( первое окно). Практика современных сетей далека от чистого TCP, +TLS, +HTTP/2, как минимум, поэтому такая микрооптимизация не сработает. Конечно это не значит что не стоит собирать важные данные в начале цикла обмена трафиком, но и сильно гнаться за конкретным размером не надо. Важно найти проблемные места и работать с ними и это подходит не только для web.

Шутка (смешная, потому что правда), понятная каждому кто поработал в провайдере - на каждый закопанный в земле кабель, найдётся свой экскаватор.

Через 10 минут после шутки, шутка превратилась в двойной обрыв с одним из наших аплинков, залипшие маршруты в FIB и кольцо маршрутизации через IX. Люблю такие совпадения - когда шутка удаётся :)

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

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

За ссылку большое спасибо нашему подписчику, всегда рад этому.

​Любителям незатейливых, но очень крутых вещиц и любителям IPv6 тоже - https://ipv6board.best-practice.se/ мини проект вдохновлённый новогодней ёлочкой. Пингуем 2001:6b0:1001:105:ASCI:IHEX:CODE:DSTR и видим на экране своё восьмисимвольное сообщение. Видно три последних сообщения, отображается каждое входящее. Не знаю как справится с нагрузкой и будет ли она, но пока всё очень быстро.

​Как потерять терабит/c трафика, сегодня ночью на MSK-IX. Для нас это потеря двух BGP соседств с резервными спикерами наших пиринг партнёров (не страшно) а также потеря небольшой части трафика в основном с апстрима, не в прямом стыке. Но всё достаточно быстро починилось ещё и время ночное, так что почти незаметно прошло. Кто ночью не спал или у кого уже утро пришло, конечно понервничали, даже в чатиках успели обсудить. Но с утра всё выглядит более менее радужно.

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

Краткий обзор двух предложений c IETF 105 в блоге APNIC. Одно для более компактной адресации IPv6 в мире IoT, заключающееся в том чтобы срезать адресацию устройств внутри какой-то локации до 16 бит вместо полного 128 битного адреса в целях упрощения самих устройств и увеличения срока работы от батареек.
Наверное есть резон чтобы сделать попроще, хотя внутри домена IoT можно было бы придумать отдельную адресацию и оторваться от IPv6 стека, но раз он уж есть, переиспользование может быть полезно если получается просто.

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

Но это пока ещё впереди, а сейчас в зоне RIPE принято дополнение к правилам выделения IPv4 адресов, после того как они кончатся - пункт 5.1bis - можно встать и подождать в очереди свои /24. И идёт обсуждение зарезервировать, пока есть ещё из чего, ещё одну сеть /16 для распределения IXP, в сумме резерв на /15. Может быть последняя битва за IPv4 во времена когда они не кончились.

Ещё одна статья про QoS что это не просто, особенно на Интернет каналах. Это правда, но сложность тут больше не качественная, а количественная. QoS - кропотливое занятие: дотошная, аккуратная, постоянная работа.
Наверное, самый значимый второй пункт, оценка пользователями, в конечном счёте всё это делается для них. Очень часто технические специалисты хотят оценить всё технически: отклик, джиттер, потери - просто взять и поговорить бывает иногда полезней. Я знаю, что для телефонии и радиосвязи целые методики были и наверное есть субъективных оценок. Для Интернет может тоже есть, но мне не попадалось. Поэтому просто не забывайте спрашивать своих абонентов про качество, как умеете.

Безопасность кода за последние 15 лет не улучшилось для сетевых устройств начального/домашнего уровня.

https://securityledger.com/2019/08/huge-survey-of-firmware-finds-no-security-gains-in-15-years/amp/?__twitter_impression=true

Не так давно реализованный сервис ris-live.ripe.net для получения потока обновлений BGP открыл много возможностей и упростил многие задачи глобального мониторинга маршрутизации в Интернете. Форматированный машинный вывод, API, множество точек присутствия, поддержка Python и JS. Если раньше требовалось придумывать способы получения нужной информации со своих BGP спикеров, или с других открытых источников, или использовать сторонние сервисы, то теперь надо всего лишь организовать обёртку поверх RIS Live.

Например, в NTT написали утилиту для отслеживания состояний префиксов - видимость и hijack.  Забираем с GitHub, уже есть бинарники, но если хочется самим то всё написано на Node.js.

В ISC, кстати, тоже на Node.js сделали RADIUS Server и поддержку клиентов.  Забираем на их Gitlab.

P.S. Кажется, Node.js для серверных админов, а Python для сетевых, главное не перепутать :)

Qrator про свою систему управления конфигурациями, мало деталей, но есть названия инструментов и высокоуровневое описание подходов. Получилась broadcast/multicast рассылка конфигураций и дополнений к ним на anycast сети по протоколу Apache Thrift с полезной нагрузкой форматированной Msgpack.

Если не видели, ISC собирает у себя на сайте ссылки на утилиты для работы с DNS, в том числе и online. Есть для диагностики, тестов, управления. Плюсом ссылки на тематические инструкции и статьи.

Я уже много лет, очень много лет как выпал из мира администрирования Windows. У меня осталось к этому миру много вопросов, больше чем к миру программирования, вопросы до которых я не добрался. Наверное, вот ответ на один из них: "Как настроить сбор логов и читать их?" - в виде шпаргалок с ссылками куда идти и смотреть дальше. Я подозреваю что не открыл вселенную, но шпаргалки, думаю, будут полезны и для тех кто в курсе.

Интересную идею подсказали: вместо того, чтобы чёрти как генерить для своей любимой лабы жалкое подобие фулвью с непойми какими AS_PATH, надо просто взять и поднять машину скачивающую её каждый день(что просто) и слегка подпиливать дамп, чтобы не было слишком грустно без TCAM (что уже интересней). А потом запихать в свою любимую лабу и быть счастливым.
http://networkingbodges.blogspot.com/2019/04/a-real-full-internet-table-in-lab.html