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

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

Cloudflare запустил анализатор веб сайтов, пока в бете, прямая ссылка - https://radar.cloudflare.com/scan. По URL вытаскивает сертификаты, адреса, DNS, куки, хостеров, фреймворки, перекрёстные ссылки. Наверное будет полезно, сами они говорят про безопасность. Как минимум в одном месте собраны результаты тестов с разных сторон.

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

Очередной раз столкнулся с проблемой что SFP не взлетели в коммутаторе. Очень дорогие SFP в очень дорогом коммутаторе, одного и того же вендора. Я не могу сказать что я стал сталкиваться с этим чаще, но и реже не стал. Иметь в наборе 20 SFP вместо одной за ту же цену, есть же разница, при том что и то и то может не определиться в устройстве, да ещё иметь чуть отличные длины волн, чтобы наверняка только парную использовать той же модели.

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

Если смотрели Mr.Robot то знаете что источники бесперебойного питания очень взрывоопасные штуки и это не фантазия. С тех пор стало хуже и никакие хакеры для этого не нужны.

Если вы когда-то залипали вот в это, то сейчас можно повторить это почти по-настоящему с самой подробной картой Марса.

Кому принадлежит почта, а так как про DNS мы уже знаем, то правильный ответ можно попытаться угадать заранее. Yandex и Mail.ru на этот пир тоже приглашены, если считать среди первого миллиона доменов.

RETN на UKNOF51 рассказывает как пережил прошедший год на Украине - обрывы, отсутствие электропитания, непрогнозируемое перераспределение трафика в том числе и из-за блокировки российских AS, проблемы с доставкой оборудования и запасных частей к нему. Со всем справились.

Что только не придумают лишь бы коннектор не переобжимать.

Обстоятельно про размер буферов в маршрутизаторах с точки зрения производителя. Хочется поменьше и к этому вынуждают вполне реальные технические ограничения и достижения алгоритмов контроля потоков, хотя в мире TCP/IP они не являются гарантией. Но оправданные запросы на большие буферы есть и пока с этим как-то справляются даже на терабитных скоростях.

Как проектировать IPv6 сеть, которая совсем не IPv4. Много примеров для провайдеров, датацентров и корпоративных сетей, VPN, а ещё про NAT и безопасность, и то что меньше /32 брать не надо.

Когда уже нельзя остановиться в придумывании всё более и более безопасного способа загрузки web странички. Помните же про фрагментирование Интернет по технологическому аспекту? Хорошим решением было бы вообще не подключаться к сети, но и тут никто гарантий дать не сможет. Всё из-за Эдварда, нашего, Сноудена.

Во всех новостях сегодня, а нигде прямой ссылки нету- https://portal.noc.gov.ru/ru/monitoring/. Говорят что анализируют, в том числе, маршрутную информацию которую отдают владельцы AS по закону. Downdetector.com строится на постоянном наблюдении тысяч непосредственных пользователей сервисов, и тут уже вопрос что надёжнее при определении сбоя, непосредственный пользовательский опыт или технический мониторинг. Есть ещё downradar.ru, там тоже что-то детектируется, но при таком способе очень важно сколько глаз следят за ресурсами.

Внимательные читатели, конечно, заметили и написали мне чтобы я не пропустил, за что им большое спасибо, что там ещё один сервис рекламируется и он более полезный в повседневной работе - это Looking Glass https://portal.noc.gov.ru/ru/lg/ с очень большим набором узлов разных провайдеров. Мой домашний префикс нашёлся больше в чем 1000 мест, в каждом видно AS_PATH и community. Можно искать по ASn и IPv6, строится график связности. Если префикс не нашёлся, попробуйте задать его другой длины.

Ещё одна статья про атаку по количеству анонсируемых префиксов с целью исчерпания ресурсов маршрутизаторов. Здесь больше практического подхода, авторы попробовали построить распределённую инфраструктуру необходимую для атаки и у них, в целом, всё получилось. Собственно, тот же Китай, может себе позволить анонсировать несколько тысяч автономных систем за раз, по одному префиксу, а если там будет 1000 префиксов, а 10000? Но обычно то к чему готовишься не случается, я бы всё же смотрел больше на IPv4, там добавить надо всего лишь чуть.

Если очень хочется то можно и OSPF в датацентр на underlay затащить, но всегда думайте про масштабирование своей сети. Хотя это и выглядит сильно проще по настройкам в статье, подводных камней с OSPF может быть побольше.

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

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

Сейчас я всегда ставлю .1, точнее первый доступный хост, маски /24 остались в домашней сети, одновременно с этим резервируя место в начале и в конце адресов на восемь. Например, в случае FHRP, адреса на физических интерфейсах я нумерую с конца, виртуальный остаётся в начале, а если сеть маленькая, то всё попадает вперёд.
Я не вижу причин которые должны были бы вас остановить делать как удобно именно вам, но .254 я действительно давно не встречал.

Если кто, как и я, не увидел слона https://t.iss.one/yourcybergrandpa/284.