Заметки сетевого архитектора

Сетевой инженер образовательный.
Не хотите немножечко IaC-а в эти ваши сети?
https://telegra.ph/Nemnozhk-pro-IaC-dlya-setevyh-lab-04-18

Возвращаемся мыслями в 2012
https://telegra.ph/Pochemu-ya-voobshche-dolzhen-byl-ehto-delat-03-12

Такс, ВНЕЗАПНО, у меня почти мильён подписчиков, посему попрошу помощи зала в поисках ответа на свой вопрос.
Вот есть замечательная rfc5549. В кратце что с помощью неё можно делать:
- соединил два коммутатора проводом
- настроил в качестве BGP пира не адрес, но интерфейс, ну например так:

    neighbor ce55 remote-as external   

Где "ce55" - это адрес интерфейса, остальное - ключевые слова, да даже ASN соседа указывать не надо
С другой стороны тоже самое, соостветнно, и вуаля - подымается BGP по ipv6 link-local адресам
Ну а потом по этой BGP сессии можно анонсировать ipv4 af и RIB будет выглядеть так, например

#show ip ro bgp
IP Route Table for VRF "default"
B            10.199.255.5/32 [20/0] via fe80::e69d:73ff:fe35:f919, ce55, 00:08:09
B            10.199.255.6/32 [20/0] via fe80::e69d:73ff:fe35:f919, ce55, 00:08:09

RFC так и зовётся - "Advertising IPv4 NLRI with an IPv6 Next Hop"
Собственно вопрос. Какой номер у RFC которая описывает передачу ipv6 анонсов с таким подходом? И есть ли такая вообще?

Я люблю картинки в общем, поэтому пока телеграм нативно не даёт писать длинные посты с картинками - это всё будет в телеграфе.
Опять таки - из личного опыта всё
https://telegra.ph/All-MTUs-matter-11-07

Лонгрид с матами. Пару человеко-дней сетевого архитектора
https://telegra.ph/Legko-li-zamenit-paru-kommutatorov-10-22

Для онгличан я написал статью на линкедин почему L2 не нужон
https://www.linkedin.com/pulse/l2-bad-roman-pomazanov/?trackingId=e2kQ7dlmR6CdzfcuboT7Mg%3D%3D

#bgp #ucmp
Небольшая заметка-напоминание.
Есть всем известный механизм ECMP - когда у нас трафик распределяется параллельно по нескольким равнозначным маршрутизируемым линкам. Ключевое слово здесь - "равнозначным", то есть Equal (так расшифровывается первая буква из аббревиатуры). Однако иногда есть требование распределить трафик НЕРАВНОМЕРНО, в зависимости от пропускной способности линка, например. То есть 1/6 часть трафика пустить через 200Мb линк, а 5/6 - через гигабитный канал.
У это задачи есть несколько решений. Первое что приходит в голову - использовать EIGRP, по-моему это единственный протокол который нативно использует bandwith при расчётах. Второй вариант, приходящий в голову - это конечно MPLS TE. Но EIGRP по факту проприетарщина, MPLS TE - хуёвщина, которую надо хуевертить, ещё и не каждый осилит, да и подымать MPLS ради такой "простой" задачи - такое себе.
Оказывается в моём любимом BGP эта задача также решается. Надо всего лишь каждый день перед сном...
Кароче, ничего не надо делать перед сном, надо просто использовать фичу "bgp dmzlink bandwith". Почему тут вообще используются буквы "DMZ" - понятия не имею, но это реально работает. Включаем фичу, прописываем фичу в сторону нейборов, ну и ясен красен прописываем bandwith на интерфейсах через которые достижимы соседи. Не обязательно указывать реальный bandwith - достаточно указать пропорции. И после этого оно как-то работает :)
В таблице маршрутизации появляется несколько маршрутов с traffic share count пропорциями. Вот так вот как на картинке прям

#srv6
Первое впечатление от SRv6. Всё сетевое сообщество, попользовавшись каким-то временем IPv6 подумало "Блять, ну нахуй нам вообще столько битов в этом адресе, если мы всё равно ажно на целый хост /64 сеть выделяем? А давайте чтобы добро в виде этих неиспользуемых толком битов не пропадало запихаем туда чё нить? Ну какие-нибудь инструкции может быть, чтобы трафиком можно было гибко управлять, а все транзитные устройства обучим этим инструкции понимать и действовать по ним - инструкции по фаст-рероуту там сделаем, ну или по пути часть трафика на какие-нить анализаторы сливать будем..."

#bgp #add_path
Вообще про BGP, думаю, будет много. В современном мире BGP это решение почти вех задач за счёт своей политической гибкости и возможности передавать внутри BGP практически всего что угодно - ip префиксов, mpls меток, mac-адресов и т.д. и т.п.
Конкретно щас хочу напомнить себе о таком важном механизме как add-path.
В некоторых кейсах, описанная тут - https://t.me/NetArchNotes/3 схеме требует большого количества bgp-связей. Естественно, когда мы хотим получить масштабируемую схему, мы смотрим в сторону рут-рефлекторов (в случае iBGP) или в сторону рут-серверов (eBGP). Но у такого варианта есть очевидный недостаток.
Представим схему с anycast. То есть есть несколько серверов, которые анонсируют один и тот же IP-адрес. Что RR, что RS (тут я на самом деле не уверен, возможно простого включения multipath будет достаточно) в случае получения нескольких анонсов будут отсылать другим своим пирам только ЛУЧШИЙ с их точки зрения маршрут - в итоге у конечных получателей маршрута будет только один путь. Но мы то хотим много путей!
Для этого собственно применяется фича add-path - она позволяет рут-рефлектору отсылать не только лучший с его точки зрения путь, но и ещё дополнительные пути.
Я тут не про инженерию, а про архитектуру, так что как настроить - гугл\ChatGPT поможет

Заметки сетевого архитектора pinned «#rfc Пожалуй запиню свой вольный перевод RFC1925, который называется как "12 истин из мира сетевых технологий". Хотя надо сказать что в целом, оно, наверное, подойдёт под любую IT сферу. Когда кто-то уходит в пространные архитекторские рассуждения всегда надо…»

#rfc
Пожалуй запиню свой вольный перевод RFC1925, который называется как "12 истин из мира сетевых технологий". Хотя надо сказать что в целом, оно, наверное, подойдёт под любую IT сферу. Когда кто-то уходит в пространные архитекторские рассуждения всегда надо помнить про них

1) Хуй знает, должно работать
2) Неважно насколько сильно и старательно вы пытаетесь что-то заставить работать - надо помнить что скорость света не преодолеть
3) Если сильно захотеть - свиньи могут полететь! Но это не значит что им надо летать - не понятно, кароче, где они приземлятся, и вообще пока они летают могут обосрать вас сверху
4) Пока сам не попробуешь - нихуя не поймёшь.
5) Всегда можно взять кучу мелких несвязанных проблем и придумать одно пиздец какое сложно решение для всего сразу. Но лучше так не делать :)
6) Лучше перенести проблему куда-то в другой участок архитектуры , конечно.
7) Постоянно происходит какая-то хуйня
8) Всё сложнее чем кажется!
9) Всегда надо больше ресурсов! Всегда!
10) Нет универсального ответа. Все всегда как говорицца "depends"
11) Как мода цикличная, так и любая новая идея всего лишь реинкарнация какой-то старой.
12) При разработке сетевых протоколов "идеальность" наступает не тогда, когда уже нечего добавить, а когда убавить что-то хуй получится уже

#bgp
Моя мечта, как сетевого архитектора, жить в мире без L2. Оптимально - L3 до сервера, на котором сервисы. Идеальная схема которая покрывает и отказоустойчивость и увеличенную полосу, и масштабируемость - сервис (например веб сайт) висит на dummy\loopback интерфейсе, IP-адрес анонсируется в физическую сеть по какому-то протоколу динамической маршрутизации (BGP как дефакто стандарт) - через каждый линк, например, и анонсы уходят наверх.
Никаких блять LACP, никаких стеков и vpc. Pure L3 routing.

Channel photo updated

Channel created