2193
Блог сетевого инженера. Новости телеком, IT и около IT. Связь - @UrgentPirate
Китай не разменивается по мелочам, хотя в рамках Китая может и мелочь, и строит города сразу и только на IPv6. По Википедии в 2020 году 1,2 миллиона населения.
Читать полностью…
Проценты мощности Wi-Fi в dBm в Windows: (percent / 2) – 100 = dBm
Зачем нужны знаки = в завершении base64 кодированной строки?
Читать полностью…
Alpine Linux во FreeBSD jail и пусть все видят кто тут главный. Вообще, после того когда я понял что Linux и *BSD не одно и то же, меня всегда удивляла вот эта поддержка Linux внутри FreeBSD, с другой стороны и Windows теперь там.
Читать полностью…
Рецепт быстрого Web сайта и не только - небольшой размер, всё в памяти, почти всё определяется статически, избавляемся от зависимостей и слоёв вроде БД и JS чтобы работать напрямую. Имея это, нам не так важны облачные сервисы.
На самом деле я понял, что, внезапно, нашёл отличную подборку мировой классики на английском, и уже не так важно как это всё устроено.
В Linux 6.7 впилили новый тип сетевого интерфейса - netkit c BPF фильтрами, с помощью которых можно провести оптимизацию для виртуальных машин, чтобы поскорее принять очевидное решение и два раза внутри сетевого стека трафик не гонять.
Сканирование IPv6 адресов теория и практика во второй части. Конечно, и все это признают, что сканирование в лоб работает плохо, но кто сказал что надо делать именно так. Человеческий фактор когда хочется упростить и повесить свой маршрутизатор на первый адрес в подсети, связанные ресурсы, вроде DNS сдающие все адреса с потрохами, математические методы предсказания действительных адресов - всё это поможет найти достаточно целей в вашей сети, чтобы волноваться и не думать что это невозможно. Да и сканеры подтянулись, поэтому инструментов достаточно.
Juniper новую фишку сделал для своих маршрутизаторов, сообщать в IPFIX причины сброса пакета, помимо тех что попали под ACL, например TTL дошёл до 0, или в MTU не влезли. В статье обзор и ссылка уже на документацию.
MPLS, VPNv4, RD и RT - вспоминаем что к чему и проверяем себя, что будет если забыть одну из частей пазла.
Читать полностью…
Дыхание вашего Интернет подключения gfblip.appspot.com, подробности на Github.
Читать полностью…
Напоминание о том что бывают разные traceroute, стоит только поискать, если вас по каким-то причинам не устраивает стандартная утилита.
Читать полностью…
Итого, SR инженер, который DevOps, это конкретная должность по версии Google причём так же прямолинейно делящая свои обязанности по времени - 50% на операционную деятельность и 50% на инженерную деятельность. Операционная деятельность, рутина - сервису надо больше памяти чем обычно, видим тикет, накидываем память. Инженерная деятельность - найти причину утечки, если она в инфраструктуре, что-то автоматизировать, что-то инфраструктурное переписать, а если дело в самом сервисе то поработать с разработчиками. Если мы знаем что память можно накинуть автоматически, по каким-то предпосылкам, а потом убрать, то можно и так сделать, главное не в ручную. При этом SRE скорее не разработчик, хотя на эту позицию ищут людей с опытом разработки, есть целая глава с примером как писали сервис внутри службы SRE и как это важно - программная разработка, но её наличие мне показалось именно подчеркиванием исключительности этого. Упоминается что это часто что-то не очень большое и разработчики сервисов отделены от SRE, эволюционно (на момент выпуска книги 2016 года), Google пришли к тому что SRE надо приглашать на этапы разработки сервиса, чтобы сразу оценивать его будущую надёжность, но непосредственное участие в разработке они не принимают.
Главное для чего возникла служба SRE - это попытка разбить линейную зависимость между количеством сервисов и количеством сотрудников которые их эксплуатируют. Т.е. количество SR инженеров должно расти медленнее чем количество сервисов которые они обслуживают, за счёт как раз инженерного подхода поиска причин неисправностей, организации работы с сервисами и заданных параметров их надёжности, автоматизации. В конечном счёте, если рассматривать последовательность повествования, сервисы унифицировались до микросервисов.
Интересно про жёсткое следование правилу 50 Dev/50 Ops - если упустить собственно Ops с перекосом в Dev, то инженеры перестанут понимать внутренности построенной системы, не хватит оперативных знаний и опыта и всё начнёт разваливаться. А если будет перекос в Ops то всех заест рутина, эффективность упадёт, сотрудников надо будет набирать больше. В приложениях есть конкретные опросники и примеры документов, в главах есть примеры работы с этими документами. В 2016 году, кстати, Google был за проектные команды в одном физическом месте, так проще с коммуникацией, хотя строгость подхода к дежурствам подразумевает что будь хоть какая авария, обязанность по её ведению передаётся новой смене если текущая смена кончается, пусть она даже заступает за тридевять земель.
Читать стоит, если никогда не касались вопроса организации службы эксплуатации не важно DevOps или нет, я думаю будет интересно. Если касались, настройтесь получить интерес в ответе на вопрос: "А как у них?".
Потому что безопасность должна быть безопасной - Нексусы не нужны и цена не важна. Для безопасного просмотра на Linkedin нужен безопасный VPN. Здесь же где-то берёт начало параллельный импорт ;) ?
Читать полностью…
По автономным системам, с IPv6 префиксами растёт быстрее - 2000 в год, но их всё ещё в два раза меньше чем с поддержкой IPv4, которые росли медленнее - 1000 в год. Не забываем, что это пересекающиеся множества. Может быть в этих графиках появятся данные по автономкам только с IPv4 и IPv6 префиксами, чтобы было понятно за счёт чего этот рост, добавление IPv6 в существующие или создание новых только с IPv6.
Ещё графиков которых нет и которые я собираюсь добавить, это графики с долями по длинам префиксов: IPv4 /24 было 59% в начале года, сейчас 60%. IPv6 /48 - 42,6% выросло до 45,1%. Можно аккуратно предположить что IPv6 в стадии роста конечных пользователей с собственными сетями, а IPv4 кончились совсем, даже разбивать существующие сети уже не на что, но может мы до точки перелома ещё не дошли, когда количество IPv4 префиксов увеличится лавинообразно.
Про допущения проверок цепочек TLS сертификатов в браузерах, когда цепочек-то и нет, а проверки проходят.
Читать полностью…
Russ White про инженеров вообще и сетевых инженеров в частности в двух частях. Сети никуда не делись, пусть границы компетенций немного и размылись это не страшно и даже полезно. Но, быть инженером - это решать проблемы, не свои, а потребителей, а уж как их решать, настраивать BGP или не настраивать, дело десятое.
Эволюция покрытия серверов тестирования скорости Speedtest от Ookla за последние три года. Много про Россию, как пример влияния геополитических событий, когда количество серверов сократилось, при том что почти везде их количество растёт. Про внутренние запреты Ookla РКНом нету, называются другие причины - санкции против телекомов. В Японии тоже сократилось, но там Ookla сама постаралась. А больше всего серверов в Бразилии и динамика роста больше всего в Бразилии, в России хоть и стало меньше, но всё равно в пятёрке.
Читать полностью…
Cisco, Juniper, Huawei, Mikrotik - самые распространённые маршрутизаторы в Интернет и Cisco больше за явным преимуществом. Использовались данные трассировок из Ripe Atlas и комбинации Cisco-Juniper или по отдельности только Cisco и только Juniper самые популярные. Тип маршрутизатора определяли по сигнатурам, и приводимые данные это то, что смогли определить. Подробности метода в публикациях, там же можно попросить сырые данные.
Читать полностью…
Настройка авторизации по RADIUS на SR Linux, вроде как и везде, есть роли сразу из коробки.
Читать полностью…
Семь шагов в семи статьях от Russ White от идеи до RFC.
Прогресс в скорости решения задач оптимизации в линейном программировании с 1989 года составил 20 миллиардов раз. 60 секунд на решение в 2023 и 38000 лет для той же задачи в 1989 году, но конечно её в принципе невозможно было посчитать из-за отсутствия необходимых ресурсов. И это не только рост производительности компьютеров, но и производительности методов решения. В других задачах, может и не так хорошо, а может и ещё лучше, но точно прогресс не стоит на месте. Мы определённо в будущем, в бесконечно далёком от даже 1989 года.
Читать полностью…
И ещё традиционной аналитики от Geoff Huston по размерам таблиц BGP и их обновлениям. И хотя в заключении говорится о неопределённости и сложности долгосрочных прогнозов, в самом начале говорится следующее:
The year 2023 marks a significant point in the evolution of the Internet where the strong growth numbers that were a constant feature of the past thirty years are simply not present in the data. Not only is the Internet’s growth slowing down significantly, but in the IPv4 network it appears to be shrinking, which is unprecedented in the brief history of the Internet to date.
Внутри гораздо больше: выделяются отдельные периоды, ищутся причины, экстраполируются текущие тренды. Миру немного, уже года три-четыре, не до Интернета, но всё может поменяться.
Пока это ещё смешно, парочку на вечер https://procurve.juniper.mx. Но справедливости ради принтеры в отдельной компании вроде бы, не в HPE.
Читать полностью…
Поиск и исправление неисправностей в сети - мысли по поводу, общие принципы поведения и поиска, с примерами и лирическими отступлениями, много. Работайте методично, знайте свою сеть и общайтесь.
Читать полностью…
Windows и Linux разные, очень разные и вряд ли что-то изменилось. Я как-то пытался читать и бросил "Внутреннее устройство Windows" Руссиновича и других авторов - очень сложно для понимания, особенно без практики, там сама суть другая - не UNIX. В комментарии по ссылке выше как раз про это: объекты, фильтры, путешествие всего этого добра по стеку сверху вниз, потом снизу вверх. Могу лишь сказать что с WSL работать пошустрее чем с Cygwin, но утилиты Cygwin в стандартной Windows консоли очень удобно запускаются сильно расширяя классический набор ещё DOS команд, за этим и продолжаю его держать.
Читать полностью…
Обещанные результаты в сравнении с прошлым годом для bgp4/111722109056869809">BGPv4 и bgp6/111722109181353447">BGPv6 по графикам бота от mellowd">Darren O'Connor. Я бы назвал это сохранением трендов - замедление роста IPv4 префиксов до 25-30К за год, в прошлом году 35К и постоянство IPv6 ~30К за год. Если вспомнить допандемийные годы, то там стабильность была в IPv4 и нарастающий темп в IPv6. Наверное, это что-то да значит, но прогноз придётся поправить - миллион префиксов в IPv4 с таким ростом мы в 2024 не увидим, может даже и в 2025 не увидим.
Мой товарищ спросил меня как-то: "Зачем я пишу о книжке, если в конце говорю что её не надо читать?" - очевидный ответ, чтобы её не читали, по причинам про которые я написал :) . Если читали, чтобы сравнить собственные впечатления после прочитанного, с не парадными впечатлениями ещё одного читателя. И в конце-концов отнестись критически и прочитать, чтобы согласится или не согласится с озвученным мнением. Книга в любом случае оставила впечатление достаточное чтобы про него сказать, книги без такого впечатления пылятся дальше без всякого упоминания.
В общем, я с трудом осилил "Site Reliability Engineering" от Google, с трудом, потому что попытки читать перед сном приводили к этому самому сну раньше чем я планировал, а в другое время - к активной скуке, потому что всё в духе Капитана Очевидность. Вроде как опять негативный отзыв, но почитать скорее стоит, чтобы оценить взгляд Google на DevOps и даже не столько на него, тем более есть несколько историй изнутри, не сказать чтобы детально описанных, но они есть, да и актуальность всё ещё присутствует, может быть поэтому и скучно, потому что такого очень много вокруг. Кстати, я почему-то думал что SRE не про DevOps, но книга в общем и не про него.
Структурно это набор статей, в нескольких разделах, где-то есть перекрёстные ссылки, но в целом каждый раздел самостоятелен, часто и каждая глава-статья самостоятельны. Во второй половине третьего раздела практически не упоминается про SRE/DevOps там про балансировку, консистентность, отказы, мониторинг, тесты, развёртывание в распределённых системах, не сказать что технически глубоко, но они больше всего технические. Вся книга по задумке, как мне показалась - про надёжность, в конце делается даже попытка сравнить как дела обстоят в разных отраслях, по отзывам сотрудников Google ранее в этих отраслях работавших. Но это не учебник, да и приведённого небольшого набора практик хватит на то чтобы только оценить свои подходы через ещё одну призму. Про надёжность как предмет изучения, к своему ужасу, я не могу вспомнить ни одной конкретной инженерной лекции в университете, всё больше про абстракции и вероятности, а вот в более приземлённом колледже что-то было, как минимум ориентироваться в терминах учили.
Так вот в Google подошли очень прямолинейно - всё ненадёжно, давайте установим границу этой ненадёжности через SLO, определив параметры мониторинга и оценивая выбранные показатели надёжности за период: месяц, квартал, год - постараемся на это как-то повлиять. При том они знают что сбои часто происходят во время активной работы с сервисами, их обновлениями, запуском, поэтому если с показателями у нас уже не очень за выбранный период, то обновления не делаем, тянем до следующего периода, они это решают через бальную накопительную систему.
Драма сегодняшнего вечера - у Orange Испании угнали учётку от сервисов RIPE NCC и поломали связность изменив принадлежность их префиксов в RPKI. Но уже починили. Я думаю, что теперь остаётся только ждать подробностей, от Orange и от RIPE NCC, кто, что, когда и почему.
Всех тех кто отдыхает и всех тех кто всегда на работе, даже не знаю кого здесь больше, поздравляю с наступившим Новым 2024 годом. А чтобы время не терять зря, экспресс анализ года уходящего по тому, что уже посчитал @FullViewBGPbot.
Напомню, это данные коллектора RRC0 из проекта RIS RIPE NCC, там немного больше префиксов, на несколько десятков тысяч, чем вы можете увидеть у себя в Full View.
Интернет стабильно растёт на 30000 префиксов в IP4 и в IPv6, превысив соответственно миллион и 200000 в каждой из таблиц. Я не строил графики по этим данным за предыдущие годы, поэтому сравнивать не с чем, это мы сделаем чуть позже по данным @bgp_table_bot, но предположу, что сравниться с тем так быстро росло количество префиксов 5 лет назад у нас не выйдет. Миллион, наверное, то что будет во всех Full View в текущем 2024 году, ближе к концу года скорее всего.