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

#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 поможет

#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 пропорциями. Вот так вот как на картинке прям