Мне подсказывают ещё про xon.sh, спасибо за это большое. Но настоящие адепты Python на меньшее чем IPython не соглашаются )

​BGP спикер к которому можно свободно подключиться и поиграться с Full BGP view. Мой домашний роутер дал дуба при 241000 полученных префиксов, когда я попытался посмотреть на таблицу маршрутизации.

Stub area в OSPF, подробно и обстоятельно с примерами на Juniper и Cisco. Одна из основополагающих вещей в дизайне OSPF сети - знать просто необходимо.

Я очень долго не находил применение простой stub area, которая фильтрует только external маршруты. Но потом и этому применение нашлось, чтобы разделить доступ к сети пиринг партнёра с двумя точками входа - одновременно к внутренней и внешней (за NAT) части сети. Знания тем и ценны, что в любой момент могут пригодиться, даже если не использовались долгое время.

Сегодня во всех новостях. Последствия не сразу, но будут обязательно, чтобы препарировать 20Гб потребуется время.

#Intel exconfidential Lake Platform ;)

This is the first 20gb release in a series of large Intel leaks.

Most of the things here have NOT been published ANYWHERE before and are classified as confidential, under NDA or Intel Restricted Secret. They were given to me by an Anonymous Source who breached them earlier this Year, more details about this will be published soon.

Some of the contents of this first release:
- Intel ME Bringup guides + (flash) tooling + samples for various platforms
- Kabylake (Purley Platform) BIOS Reference Code and Sample Code + Initialization code (some of it as exported git repos with full history)
- Intel CEFDK (Consumer Electronics Firmware Development Kit (Bootloader stuff)) SOURCES
- Silicon / FSP source code packages for various platforms
- Various Intel Development and Debugging Tools
- Simics Simulation for Rocket Lake S and potentially other platforms
- Various roadmaps and other documents
- Binaries for Camera drivers Intel made for SpaceX
- Schematics, Docs, Tools + Firmware for the unreleased Tiger Lake platform
- (very horrible) Kabylake FDK training videos
- Intel Trace Hub + decoder files for various Intel ME versions
- Elkhart Lake Silicon Reference and Platform Sample Code
- Some Verilog stuff for various Xeon Platforms, unsure what it is exactly.
- Debug BIOS/TXE builds for various Platforms
- Bootguard SDK (encrypted zip)
- Intel Snowridge / Snowfish Process Simulator ADK
- Various schematics
- Intel Marketing Material Templates (InDesign)
- Lots of other things

Make sure to archive/mirror this, as I doubt the original Mega link will survive for long. (Torrent coming soon hopefully)

https://mega.nz/folder/CV91XLBZ#CPSDW-8EWetV7hGhgGd8GQ

torrent: magnet:?xt=urn:btih:38f947ceadf06e6d3ffc2b37b807d7ef80b57f21&dn=Intel%20exconfidential%20Lake%20drop%201

Новость на Хабре - опыт Google в построении IPv6 only сети гостевого Wi-Fi в своих офисах.

Можно сразу пойти посмотреть запись или презентацию.

Крутые слайды по истории распределения адресного пространства в Интернет - все самые-самые вехи. На общем интерактивном графике хорошо видно что куда и как убегает, как сокращается legacy, в каком RIR больше всего адресов, а в каком меньше всего и сколько их на самом деле у US DoD.

Обзорная статья про то, как на IOS-XE можно запустить Linux Centos, не сильно подробная, но со всеми нужными ссылками и базовыми примерами. Это полноценный Linux - настолько, что можно обновляться с публичных зеркал. Cамые внимательные увидят даже ссылку на наше зеркало и может быть вспомнят про безопасность своей сети. А кто-то, может быть, купит IOS-XE чтобы Linux запускать ;)

Optical Fiber Telecommunications VII Alan E.Willner, 2020
Оптическая библия

Facebook про то как устроена их сеть, точнее про то как часто обновлять компоненты сети без перерыва в передаче трафика, буквально. По ссылке статья и видеопрезентация. Тезисно, по трём основным подходам, можно глянуть в эту ветку Twitter.

Сейчас проходит SIGCOMM 2020, где этот доклад запланирован на четверг. Но там гораздо больше того, что можно и надо послушать. Формат онлайн, все материалы уже выложены, кроме обсуждений и вопросов, которые будут в "живую".

Система для учёта ваших пиринговых сессий - Peering Manager, для тех кто ещё не учитывает, но понимает что пора. Не заменяет собой PeeringDB, но может использовать, а ещё NAPALM для взаимодействия с роутерами.
Уже версия 1.2.0. Есть готовый докер образ если лень так разворачивать.

BGP Flowspec на ExaBGP и Juniper - простой пример чтобы начать, с построчным объяснением конфигурации.

​В AWS сделали странное, но уже исправились. Всё что попадает в Интернет, там и остаётся - репозиторий в котором можно посмотреть за историей используемых AWS префиксов c 2017 года.

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

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

Одна из тех многих вещей которые мне не даются легко. Посчитать MTU для меня - мука. Но, похоже, счастье есть - https://baturin.org/tools/encapcalc/

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

IPv4 адреса которые были перепроданы на свободном рынке, часто, чаще чем остальные, являются источниками вредоносного трафика. Статья на labs.ripe.net.

Среди автономных систем, те которые участвуют и в приобретениях и в продажах чаще являются источниками вредоносного трафика, чем те кто только покупает или только продаёт.

Кроме как на рынке много IPv4 адресов уже не найдёшь, поэтому покупайте в проверенных местах или мойте их с мылом после покупки.

Отличная статья из двух частей с разницей в 9 месяцев про способы планирования адресного пространства IPv6. Описаны 4 метода, я бы разделил их ещё на два подхода, в которых подробно рассказано про преимущества и области применения.

Для меня не очень очевидным является последний - "случайное распределение", и не очень полезным предпоследний - "максимальное заполнение", который, как мне кажется, совсем не учитывает природу IPv6. В любом случае, в адресном пространстве будут зиять огромные дыры, но и количество адресов настолько огромно, что можно себе позволить зарезервировать префикс для каждого из 4096 виланов записывая его в десятичной нотации, а не в шестнадцатеричной. Примерно так я поступал когда планировал пространство /32, резервируя префикс под каждый порт коммутатора. После чего в какой-то момент осознал, что /32 становится тесноватым для моих планов :)

Стоит ли стремиться к поддержке непрерывности - да стоит, хотя уже сейчас в глобальной таблице маршрутизации BGP IPv6 почти 50% префиксов по /48 - максимальных из тех что рекомендуется маршрутизировать. В IPv4 количество /24 близко к 60%. Но экономить IPv6 не самый разумный вариант их действительно много и можно делать если не навсегда, то как минимум на ближайшие лет 10-15 точно. В статье приводится "разряженный" метод и пример, где под каждую задачу резервируется в 4 раза больше чем надо от самых максимальных потребностей.

И к этому очень быстро привыкаешь, потому что удобно, потому что взгляд цепляется за естественные разделители от цифры к цифре и двоеточиям. В IPv4 с этим было сложно, так-как префиксы (маски) не ложились ровно на десятичные разряды, потому что были двоичные. А изначальная задумка с классами адресов, где точка была естественным разделителем, очень быстро привела к исчерпанию адресного пространства. В IPv6 не так - проще человеку в том числе, визуально проще выделять структуры, даже не смотря на то что адреса стали длиннее, а считать приходится в шестнадцатеричных цифрах.

В продолжении темы адресации, конкретная практика: /48 на клиента, /32 на BRAS, 4-х кратный и 2-х кратный резерв.

Подробный и в хорошем смысле занудный разбор деталей обмена BPDU при изменении топологии в классическом 802.1d STP. Примечателен именно вниманием к тем деталям, которые часто опущены в OCG и недостаточно явно описаны в документации, но которые хорошо бы знать, чтоб понимать работу протокола не "для галочки".
https://www.chrisjhart.com/Deep-Dive-Spanning-Tree-Topology-Change/

И ещё большая, очень большая статья про все сложности NAT и не только - https://tailscale.com/blog/how-nat-traversal-works/, сегодняшний хит. Для тех у кого понедельник начинается в субботу.