Поразмышлять перед сном. Лично мне не хватает BNG/BRAS, не вообще, а одного конкретного, но его уже никто не заменит. А в текущих потребностях нормального корпоративного маршрутизатора где всего понемножку: с туннелями, NAT'ом, файрволлом с кластеризацией и асимметрией, SD-что-то пусть тоже там будет.

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

Балансировка нагрузки сетевого UDP приложения средствами сетевого стека Linux: SO_REUSEPORT и SO_ATTACH_REUSEPORT_CBPF в двух частях. Все грабли и суть во второй части вместе с очень простым примером программы на BPF и способом его компиляции, а также кодом самого сервера на разных этапах по ссылкам на Github.

В коллекцию говорящих PTR в трассировке, не буду приводить полностью, просто один шаг:

6 34 ms 34 ms 35 ms tspu-6364.no-hope.msk-m9-cr5.ae666-3002.rascom.as20764.net [80.64.97.55]

Но надежда, что Telegram вернется к жизни ещё остаётся.

Красивая шпаргалка по основным моментам BGP, но это если не придираться к деталям, которые показывают насколько глубоко вы в BGP погружены.

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

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

А теперь, как замена двух коммутаторов выглядит в реальных красках. Утащено у автора Заметок сетевого архитектора.

Краткая история Ethernet к 50 юбилею на NANOG 89 и слайды.

Практика обеспечения отказоустойчивости DHCP и зачем нужно поле secs, на примере Windows серверов.

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

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

За три года накопилось немного случаев с той стороны (со стороны абонента провайдера), и в комментариях тоже есть немного. Я люблю провайдеров, вы про настоящие сети. Провайдеры, любите своих клиентов, я знаю вы умеете когда захотите.

Товарищи подсказывают что сегодня ночью время Unix перевалило за 1700000000, всех поздравляю с новыми прожитыми 100000000 секундами.

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

Сегодня nexthop, первые доклады уже прошли, два зала, из каждого есть трансляция.

А теперь немного сложнее, про MPLS, там же на Хабр, на примере той же Cisco. Когда нюансы имеют значение.

Незамутнённый научный взгляд спрашивает: "А можем ли мы ещё усилить DNS атаку основанную на отражении?" и проведя соответствующее исследование отвечает: "Конечно можем, ведь до сих пор злоумышленники делали всё неправильно". Помимо увеличения объёмов трафика за счёт увеличения размеров пакета, количество повторных пакетов в ответе на один запрос тоже можно увеличить. Механизмов несколько, один из которых, вероятно, системы фильтрации и Китай впереди планеты всей в этом вопросе.

Не всем нравится что стандартизация новых возможностей в BGP проходит слишком медленно, медианное значение 3,5 года. Поэтому надо сделать подход к реализации BGP модульным и независимым от платформы, и тогда попробовать что-то можно будет на раз два, самостоятельно реализовав собственный модуль. 3 года прошло уже, может быть и полетит, если стандартизуется конечно.

Свежая статья которая могла бы быть актуальной и 5, если не 10 лет назад и скорее всего будет актуальной через 5 лет, надеюсь не через 10 - Почему внедрение IPv6 проходит медленно. Несмотря на все преимущества, провайдеры сопротивляются, сотрудники не обучаются и приложения не переписываются. Внезапно это сложно и дорого так как от многого придётся отказаться и многое переделать, а тех преимуществ которые есть видимо недостаточно для ускорения процесса. Даже всякие обходные пути придумали, чтобы IPv4 подольше использовать, хотя: "IPv6 boasts addresses in a simplified hexadecimal format".

Прочитал Алана Купера "Психбольница в руках пациентов", книга аутотренинг где одна мысль повторяется разными словами каждые 5-10 страниц, плюс несколько техник, и всё это на 300 с лишним страниц, поэтому читается скучновато и, в целом, прямо захватывающих сюжетов в ней сейчас нет, хотя и приводятся примеры и обсуждаются компании со всем известными именами вроде Microsoft и Apple. Первое издание было в конце прошлого века, а я читал авторское переиздание начала века и там некоторые вещи уже устарели, буквально за 5-7 лет, на что сам автор указывает, особенно цены и технологии.
Но книга актуальна сейчас не меньше чем тогда, даже скорее больше с основным посылом - у нас кошмарное программное обеспечение созданное не для людей, и это не только собственно программы, но и всё что хоть как-то завязано на компьютеры, т.е. в наше время это вообще всё. Веб, как отдельный портал в ад, тоже отмечается автором, помним что это был тёплый и ламповый веб конца прошлого века. Какова же причина? Программисты - психи, конечно не такими словами, но определённо автор относит их к отдельному виду людей и они не могут понять остальных людей, поэтому пишут программы для себя, с соответствующими интерфейсами и способами взаимодействия. А так как других программистов у нас нет, то пользоваться приходится тем что делают они, хотя это почти всегда не очень удобно.
Решение тоже предлагается - не начинать писать программы быстро, а потратить время, очень, ооочень много времени на проектирование с точки зрения конечного пользователя. Не с точки зрения функционала и наличия опций, а с точки зрения взаимодействия. Имея чёткое представление о конечном результате с детально проработанными механиками и целями, на сам код потратится гораздо меньше времени, чем если начать его писать с первого дня проекта и набивать всеми возможными фишками лишь бы побольше. Иронично, что в то же время мир программистов стал покорять Agile где на первое место ставится скорость реализации опций, работающий, легко модифицируемый и технически совершенный код, а также сам программист, его удобство и комфорт. Про взаимодействие в Agile тоже есть, внутри команд в основном. То есть, согласно книге победил критикуемый случайный подход - при котором успех продукта определяется не чётким планом, а волей случая. Поэтому чтобы сделать успешный продукт, надо быстро сделать много продуктов и выпускать их на рынок, если какой-то из них выстрелит, допиливать в нём то о чём не успели подумать сразу.
Читать, наверное, не стоит, там всё слишком очевидно от чего скучновато, да и Брукс пишет поинтереснее, если хочется историй изнутри, кстати, в книге он упоминается не раз. Но читать, чтобы узнать себя в каких-то привычных мелочах - стоит, я себя узнал.