Патчкорд

Отличная коллекция статей по применению протокола NTP https://blog.webernetz.net/ntp/

В OpenNET сегодня решили отпраздновать 50-летие UNIX, почему бы и нет? Хороший повод перечитать первую публичную статью по теме от создателей, вышедшую в 1974 году - The UNIX Time-Sharing System.

МТС с 1 сентября закрывает CSD. Заканчивается целая эпоха. Хотя многие даже и не подозревали, что CSD до сих пор работает. Если вообще в курсе, что это такое. CSD - это модемный дозвон для подключения к интернету. Помните в 90-е мы через модемы, подключенные к компьютеру, звонили на телефонный номер и подключались к интернету. Скорость тогда была разной, зависела как от модема, так и от качества телефонной линии. И при всем желании больше 56 килобит получить было невозможно. 30 в лучшем случае. Так вот, автор этих строк настолько стар, что прекрасно помнит, как он настраивал CSD на SonyEricsson T630. И какой был восторг от того, что с мобильного телефона можно было подключиться к интернету. GPRS тогда еще не было, если что. В последние годы CSD использовался все меньше. Основные потребители - старые как известно что мамонта устройства. Терминалы, которые в ночи буквально звонили по модему через мобильную связь и передавали в некий центр данные. Передать можно немного, у МТС скорость CSD была 9600 бод. Один килобайт в секунду. 0,001 мегабит в секунду, если рассуждать в современных терминах. Что ж. Помянем CSD. GSM стоит приготовиться и, как говорят в таких случаях, привести дела в порядок.

​Как далеко до Интернета в текущих реалиях означает как далеко до ближайшей точки присутствия CDN, статья на labs.ripe.net как раз про это. Из России до GoogleCloud ближе всего. Я не поленился и попинговал ресурсы которые приводятся в статье. Получилось вот такое RTT: Googlecloud 37мс Fastly 38мс Cloudfront 44мс Akamai 49мс Cachefly 55мс Cloudflare 61мс Azure 65мс Google первый, потому что прыгает в ближайший IX, остальное всё через магистральных операторов. Не то чтобы тот же Microsoft не присутствовал на точках обмена трафиком, но IP фигурирующего в статье там нет. Да, ещё стоит не забывать про кеши где аккумулируется тяжёлый контент, а не заглавные страницы.

Пройденный путь иногда ценнее полученного результата, а если про это ещё и красиво рассказать. Как сдать CCIE начав в 2012 - просто история, хорошая и добрая история. Не про технологии, а про человека.

Давайте ещё один "другой" traceroute сегодня и ещё раз большая благодарность нашему подписчику. fbtracert от Facebook - это pathping (или mtr, кому что ближе) на стероидах, который массированно загружает весь путь от источника до приёмника и смотрит где и что потерялось. Под Windows у меня не взлетело, потому что TCP на raw socket нельзя, оказывается. Не самая понятная и дружелюбная вещь, но использовать при случае сгодится. Как это видят в Facebook можно посмотреть на Youtube или вот тут почитать.

​Спасибо что делитесь со мной крутыми вещами! Вдогонку к предыдущему посту ссылка от нашего подписчика - traceroute на стероидах, dublin-traceroute. Много как технических фишек, например, определение ECMP и NAT. Так и визуальных - генерация диаграм, вывод в JSON. Посмотреть точно есть на что. Ставить можно из репозиториев, правда не из main. Или GitHub, если есть желание собирать самим.

Пример поиска причин проблемы в вопросе: "Почему traceroute не добирается до конца", от Daniel Dib. Как и в любой проблеме сошлось много факторов - traceroute может быть не самым простым и файрволы часто слишком умные, Об этом стоит помнить и уметь собирать всё в кучу.

Меня правильно поправляют, что ARouteServer только для BIRD и OpenBGPD, но не всё сразу.

Ansible очень простой и практичный инструмент для автоматизации. Если знаешь как решается задача, то сформировать её в виде playbook не составит большого труда. Хитростей никаких нет, есть задача - решаешь. По сути, нужен справочник по тому что умеют модули, если их самим не писать. Любая статья и даже книги в итоге скатывается к тому как использовать конкретные модули, или точнее как решать задачи используя Ansible. Например, как что-то сделать на Cisco IOS-XR, в котором Ansible, как и положено отличному инструменту почти незаметен, фокус на задаче. Поэтому на первом месте в автоматизации всегда вопрос что же мы автоматизируем, а потом всё остальное. Наверное, какие-то задачи перерастают во что-то большее и ценное само по себе. Я не думаю что нельзя было бы написать для Ansible playbook который бы генерировал полноценную конфигурацию для BGP роутера, со всеми фильтрами и ограничениями построенными по различным IRR и данными из PeeringDB. Для BIRD и OpenBGPD уже есть отдельное решение - ARouteServer, те же YAML и Jinja2, а остальное можно и Ansible оставить.

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

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

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

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

Не так давно реализованный сервис 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 для сетевых, главное не перепутать :)

Безопасность кода за последние 15 лет не улучшилось для сетевых устройств начального/домашнего уровня. https://securityledger.com/2019/08/huge-survey-of-firmware-finds-no-security-gains-in-15-years/amp/?__twitter_impression=true

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

Краткий обзор двух предложений c IETF 105 в блоге APNIC. Одно для более компактной адресации IPv6 в мире IoT, заключающееся в том чтобы срезать адресацию устройств внутри какой-то локации до 16 бит вместо полного 128 битного адреса в целях упрощения самих устройств и увеличения срока работы от батареек. Наверное есть резон чтобы сделать попроще, хотя внутри домена IoT можно было бы придумать отдельную адресацию и оторваться от IPv6 стека, но раз он уж есть, переиспользование может быть полезно если получается просто. Второе, перейти к адресации не узлов, а адресации услуг (сервисов), а уж как к этой услуге добраться решает сервис провайдер. Соответственно классическая адресация может предоставляться как сервис. Такие идеи периодически возникают уже достаточно давно, и наверное мы к этому всё ближе и ближе. Всё это вырисовывается из современных облачных провайдеров. Вот даже NFV ругают что слишком монолитно, надо не функции реального железа повторять, а дробить на более мелкие части и задачи. Но это пока ещё впереди, а сейчас в зоне RIPE принято дополнение к правилам выделения IPv4 адресов, после того как они кончатся - пункт 5.1bis - можно встать и подождать в очереди свои /24. И идёт обсуждение зарезервировать, пока есть ещё из чего, ещё одну сеть /16 для распределения IXP, в сумме резерв на /15. Может быть последняя битва за IPv4 во времена когда они не кончились.

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

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