240.0.0.0/4 в большом Интернете - исследование RIPE Labs, судя по которому у Amazon совсем плохо всё с адресами и они себе этот блок задействовали по полной и не только они одни.

Если не завели себе HTTPS запись для своего домена в DNS, видимо пора это уже сделать.

Не стоит тестировать на проде, но если очень хочется, то вы знаете ответ. Cтатья в целом про сеть как причину, хотя конкретно совсем про другое, но написана легко чтобы уделить время, есть пример боевого применения tc qdisc add dev eth0 root netem delay.

Тут хорошие люди делают документальный фильм о Linux в России. Уже даже первый трейлер выкатили, качество которого прям очень порадовало

https://www.youtube.com/watch?v=PMg8d1N6Dy0

Список участников фильма глянуть можно на сайте проекта
https://www.serotoninja.com/linstoria/

Канал проекта в телеге - @linstoria

Если есть желание помочь проекту, то есть boosty - https://boosty.to/linstoria
Другие способы для помощи можно посмотреть так же на сайте проекта по ссылке выше.

DNS для самых маленьких, умудрённые опытом тоже могут заходить. А nslookup.io стоит добавить в копилку полезных инструментов.

Пока вы выбираете что лучше BBR или CUBIC в MIT нашли что всё плохо и этого не исправишь, реальный мир слишком жесток и несправедлив чтобы втиснуть его в алгоритмические рамки. Статья в PDF целиком.

Формат документов, текстов RFC, с чего всё начиналось и к чему мы пришли сейчас. Не ГОСТ, но нормоконтроль тоже надо пройти, прежде чем делиться своим новым протоколом со всем миром.

Зарядка для ума для любителей BGP - как построить сеть без колец при использовании Route Servers. Где-то тут скрыт и ответ на вопрос, про то почему клиенты IX сидят в одной подсети.

Основы базовой настройки коммутатора из коробки - не оставляйте ничего по умолчанию и автоматически. Vlan 1 для этого слишком известный, чтобы быть безопасным.

Cisco ASA странная и вас не должно смущать что это Cisco - эффект зловещей долины по полной. И за большую часть своей сетевой деятельности я почти не сталкивался с ней, при этом в консоль я даже не пытался заглядывать, только ASDM. Но так случилось что пришлось разобраться и даже можно сказать что мне это понравилось. На самом деле, за рамками остаётся какая-то часть с пользовательским VPN. Но IPSec site-to-site, NAT, который мне нравится больше всего по лаконичности настроек, Firewall, хоть иногда и подкидывают задачек, но уже на уровне азарта: "Ах вот тут как завернули!". А подобные статьи в духе двойного NAT за IPSec туннелями с кучей консольных команд читаются на одном дыхании - только консоль и никакой ASDM с ужасными автоматическими именами. Статья совсем не новая, в какой-то момент произошёл пересмотр части команд, которые отправились в запрещённые, поэтому беря на вооружения подход сверяйтесь с актуальной документацией, чтобы не попасть в зловещую долину уже между версиями ASA.

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

Что такое симметричная и асимметричная маршрутизация. В норме для Интернет что маршрутизация асимметричная, даже если у вас один интерфейс выше по течению пакеты будут добираться разными путями. Диагностика с одной стороны всегда показывает лишь половину необходимого, если ничего не придумывать. Если у вас два интерфейса и больше и особенно на конечном хосте, то почти всегда надо потрудиться чтобы всё работало правильно - то rp_filter не такой или ARP сломан, а про файрволы уж и говорить нечего.

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

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

За сезон обычно много меняется и шансов увидеть повторение такого поведения было не много, но прошло полгода и проблема вернулась. Тогда мой коллега, который впоследствии ушёл в программисты и продолжает там оставаться, решил докопаться. В ход пошли многие средства контроля, включая видеозапись, чтобы отследить моменты с максимальной точностью. Никакой связи с работой системы охлаждения выявить не удалось, замена патчей и портов на оборудовании тоже не помогла. И тогда от отчаяния, но скорее по приколу мой коллега выпустил пар и просто наорал на трансивер, вот как здесь, наше оборудование тоже было из примерно того времени, хотя события происходили лет на 5 позже. И внезапно ошибок не стало. Не совсем, конечно, как только крик прекратился они вернулись. Не поверив собственным глазам, эксперимент повторился, а потом ещё раз и ещё раз, в присутствии меня, на видеозапись. Каждый раз одно и то же, ошибки есть - кричишь, громко и сильно - ошибок нет. Это не решало нашей проблемы и никак не указывало нам на причину, но сама ситуация была так для нас необычна, что линк в таком виде прожил ещё один сезон. А после чего мы заменили трансивер, который был в достаточной мере уникален чтобы менять его просто так и больше ошибок мы не видели.

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

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

Про балансировку ещё раз для неравнозначных каналов. И ещё один грязный хак который описывается в статье и до которого мне пришлось один раз даже дойти, в моём случае надо было очень тонко порулить ну очень загруженные каналы, к счастью, участок быстро расширили. Обещанную вторую часть я тоже жду, но пока её нет. Если не удалось зайти на сайт, попробуйте VPN.
Подробнее про CEF polarization и про UCMP с EIGRHP и CEF.

Сегодня 0377 день в году и я надеюсь настоящие программисты всё ещё ведут счёт с нуля и могут в системы счисления - их с праздником. Не совсем настоящих программистов, которые не боятся в Shell, Perl, Tcl, Python, PS, CMD, Lua и модный ныне Go тоже с праздником. Пусть сегодня будет такой список.
Умеете писать цикл и сортировку пузырьком, решать свои инженерные задачи доступными вам алгоритмическими инструментами - не бойтесь называть себя программистом, оставаясь при этом инженером в своей области. Это не отменяет необходимости учиться, но и не делает вас хуже тех самых настоящих. Лучшие результаты получаются у того кто знает досконально предметную область, а не досконально какой-то из языков программирования. Если не умеете - учитесь, это не только практический и полезный навык, но и основы позволяющие понять первопричину очень многого в IT.
С днём программиста!

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

DNS трафик перехватывается и подменяется и это ни для кого не секрет, для RIPE Labs в том числе. Потому что это просто, потому что это работает, потому что это бывает полезно не только для цензуры. В статье взяли facebook.com и google.com и сделали запрос из разных частей света к корневым серверам, контрольный домен ripe.net. Результат - это делают почти все, для AAAA в два раза реже чем для A, TCP тоже почти не трогают в отличие от UDP, и в большинстве случаев перехватывается только запросы на некоторые домены, а не все подряд. Есть статистика по странам, по ASn, по корневым серверам.

Дотошный, практический пример работы с Cisco IP SLA в ситуации два аплинка со статикой. Хорошо прошлись по всем возможным граблям с маршрутами, про что обычно забывают, а также про различные возможности опроса и их комбинации. Стоит отметить что механизм track у Cisco можно встроить во многие места, к HSRP, к route-map. Иногда приходится полировать сверху Embedded Event Manager, чтобы, например, при переключении почистить NAT трансляции.
Не скажу что мне нравится такой подход активного мониторинга - большая проблема подобрать правильные параметры и реакцию на события. В ситуации когда нету доверия внешним ресурсам, например, что будет если 8.8.8.8 само по себе сломается, а не потому что провайдер что-то там не пропускает? Но даже в случае использования BGP и провайдерских фишек застраховаться от того что ваш провайдер блокирует весь трафик, или резко роняет качество его прохождения, такой способ, при аккуратном использовании, поможет.
IP SLA в принципе, как следует из названия, хорош для отслеживания качества каналов, при условии наличия оборудования с поддержкой IP SLA с двух сторон. Тогда в вашем распоряжении будут графики с потерями в каждую из сторон, с задержками, jitter, тестовыми голосовыми вызовами и агрегированными отчётом качества этих вызовов прямо из коробки.

IPv6 не был нужен - мнение Ивана Пепельняка. Уже ничего не изменишь, да и любое другое решение находилось бы в тех же обстоятельствах цены и необходимости. Можно вспомнить как задумывался IPv6 и чем он не стал. CLNP и IS-IS свою нишу заняли как раз потому что они не IP, что позволило строить действительно независимый слой, поверх которого маршрутизировать всё что душе угодно.