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

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

Почти 15 лет назад, когда я пришёл работать в свой первый провайдер, у нас была одна Cisco 7301, потом вторая, потом третья, потом их стало пять. Каждая из них играла роль PPPoE концентратора, каждая принимала и отвечала на запросы всех пользователей, мы даже не делали балансировки: она получалась естественным образом соответственно нагрузке каждого из устройств. Это были независимые устройства, выход каждого из строя не стоил бы нам ничего, если бы мы не экономили на них и использовали, хотя бы, с минимальным резервом N+1, но мы всегда были почти на грани, иногда за ней.

Потом пришла мода на большие коробки - BRASы, вокруг которых строилась инфраструктура. Но кто-то продолжал покупать 7301 или что-то, что позволяло обслуживать 1000-3000 абонентов на ограниченной территории, строя свой мини-интернет в рамках города или области. Потеря одного узла - почти ничто, отсутствие центральной точки отказа многого стоит, расшириться тоже очень легко - не надо покупать большую коробку, достаточно маленькой и дешёвой.

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

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

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

Лаба в PacketTracer c Vlan, STP, VTP - подробнейшее описание со схемами, логами, командами. Прямая ссылка на Dropbox.

Время VTP прошло, вроде бы, хотя у меня в 2018 году интересовались про отличие версии 2 и 3 на собеседовании перед началом одного проекта. Может быть, если у вас только Cisco одной модели, в изолированной сети и вы знаете что делать, то это оправдано, если вообще оправдано держать большие широковещательные сегменты.

Сейчас vlan pruning, самое интересное в VTP, собственно, как и распространение настроек виланов по устройством решается автоматизацией, а у многих других вендоров всегда только так решалось. Главное предсказуемость, а кажущаяся простота VTP тут обманчива.

​Если очень сильно любите Python, до такой степени, что вместо консольных команд набираете его операторы, то вот вам www.marceltheshell.org, с пылу с жару. Github.

Мне подсказывают ещё про 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 адресов уже не найдёшь, поэтому покупайте в проверенных местах или мойте их с мылом после покупки.