#bgp
Моя мечта, как сетевого архитектора, жить в мире без L2. Оптимально - L3 до сервера, на котором сервисы. Идеальная схема которая покрывает и отказоустойчивость и увеличенную полосу, и масштабируемость - сервис (например веб сайт) висит на dummy\loopback интерфейсе, IP-адрес анонсируется в физическую сеть по какому-то протоколу динамической маршрутизации (BGP как дефакто стандарт) - через каждый линк, например, и анонсы уходят наверх.
Никаких блять LACP, никаких стеков и vpc. Pure L3 routing.
Моя мечта, как сетевого архитектора, жить в мире без L2. Оптимально - L3 до сервера, на котором сервисы. Идеальная схема которая покрывает и отказоустойчивость и увеличенную полосу, и масштабируемость - сервис (например веб сайт) висит на dummy\loopback интерфейсе, IP-адрес анонсируется в физическую сеть по какому-то протоколу динамической маршрутизации (BGP как дефакто стандарт) - через каждый линк, например, и анонсы уходят наверх.
Никаких блять LACP, никаких стеков и vpc. Pure L3 routing.
👍6😁1
#rfc
Пожалуй запиню свой вольный перевод RFC1925, который называется как "12 истин из мира сетевых технологий". Хотя надо сказать что в целом, оно, наверное, подойдёт под любую IT сферу. Когда кто-то уходит в пространные архитекторские рассуждения всегда надо помнить про них
1) Хуй знает, должно работать
2) Неважно насколько сильно и старательно вы пытаетесь что-то заставить работать - надо помнить что скорость света не преодолеть
3) Если сильно захотеть - свиньи могут полететь! Но это не значит что им надо летать - не понятно, кароче, где они приземлятся, и вообще пока они летают могут обосрать вас сверху
4) Пока сам не попробуешь - нихуя не поймёшь.
5) Всегда можно взять кучу мелких несвязанных проблем и придумать одно пиздец какое сложно решение для всего сразу. Но лучше так не делать :)
6) Лучше перенести проблему куда-то в другой участок архитектуры , конечно.
7) Постоянно происходит какая-то хуйня
8) Всё сложнее чем кажется!
9) Всегда надо больше ресурсов! Всегда!
10) Нет универсального ответа. Все всегда как говорицца "depends"
11) Как мода цикличная, так и любая новая идея всего лишь реинкарнация какой-то старой.
12) При разработке сетевых протоколов "идеальность" наступает не тогда, когда уже нечего добавить, а когда убавить что-то хуй получится уже
Пожалуй запиню свой вольный перевод RFC1925, который называется как "12 истин из мира сетевых технологий". Хотя надо сказать что в целом, оно, наверное, подойдёт под любую IT сферу. Когда кто-то уходит в пространные архитекторские рассуждения всегда надо помнить про них
1) Хуй знает, должно работать
2) Неважно насколько сильно и старательно вы пытаетесь что-то заставить работать - надо помнить что скорость света не преодолеть
3) Если сильно захотеть - свиньи могут полететь! Но это не значит что им надо летать - не понятно, кароче, где они приземлятся, и вообще пока они летают могут обосрать вас сверху
4) Пока сам не попробуешь - нихуя не поймёшь.
5) Всегда можно взять кучу мелких несвязанных проблем и придумать одно пиздец какое сложно решение для всего сразу. Но лучше так не делать :)
6) Лучше перенести проблему куда-то в другой участок архитектуры , конечно.
7) Постоянно происходит какая-то хуйня
8) Всё сложнее чем кажется!
9) Всегда надо больше ресурсов! Всегда!
10) Нет универсального ответа. Все всегда как говорицца "depends"
11) Как мода цикличная, так и любая новая идея всего лишь реинкарнация какой-то старой.
12) При разработке сетевых протоколов "идеальность" наступает не тогда, когда уже нечего добавить, а когда убавить что-то хуй получится уже
👍7😁2
Заметки сетевого архитектора pinned «#rfc Пожалуй запиню свой вольный перевод RFC1925, который называется как "12 истин из мира сетевых технологий". Хотя надо сказать что в целом, оно, наверное, подойдёт под любую IT сферу. Когда кто-то уходит в пространные архитекторские рассуждения всегда надо…»
#bgp #add_path
Вообще про BGP, думаю, будет много. В современном мире BGP это решение почти вех задач за счёт своей политической гибкости и возможности передавать внутри BGP практически всего что угодно - ip префиксов, mpls меток, mac-адресов и т.д. и т.п.
Конкретно щас хочу напомнить себе о таком важном механизме как add-path.
В некоторых кейсах, описанная тут - https://t.iss.one/NetArchNotes/3 схеме требует большого количества bgp-связей. Естественно, когда мы хотим получить масштабируемую схему, мы смотрим в сторону рут-рефлекторов (в случае iBGP) или в сторону рут-серверов (eBGP). Но у такого варианта есть очевидный недостаток.
Представим схему с anycast. То есть есть несколько серверов, которые анонсируют один и тот же IP-адрес. Что RR, что RS (тут я на самом деле не уверен, возможно простого включения multipath будет достаточно) в случае получения нескольких анонсов будут отсылать другим своим пирам только ЛУЧШИЙ с их точки зрения маршрут - в итоге у конечных получателей маршрута будет только один путь. Но мы то хотим много путей!
Для этого собственно применяется фича add-path - она позволяет рут-рефлектору отсылать не только лучший с его точки зрения путь, но и ещё дополнительные пути.
Я тут не про инженерию, а про архитектуру, так что как настроить - гугл\ChatGPT поможет
Вообще про BGP, думаю, будет много. В современном мире BGP это решение почти вех задач за счёт своей политической гибкости и возможности передавать внутри BGP практически всего что угодно - ip префиксов, mpls меток, mac-адресов и т.д. и т.п.
Конкретно щас хочу напомнить себе о таком важном механизме как add-path.
В некоторых кейсах, описанная тут - https://t.iss.one/NetArchNotes/3 схеме требует большого количества bgp-связей. Естественно, когда мы хотим получить масштабируемую схему, мы смотрим в сторону рут-рефлекторов (в случае iBGP) или в сторону рут-серверов (eBGP). Но у такого варианта есть очевидный недостаток.
Представим схему с anycast. То есть есть несколько серверов, которые анонсируют один и тот же IP-адрес. Что RR, что RS (тут я на самом деле не уверен, возможно простого включения multipath будет достаточно) в случае получения нескольких анонсов будут отсылать другим своим пирам только ЛУЧШИЙ с их точки зрения маршрут - в итоге у конечных получателей маршрута будет только один путь. Но мы то хотим много путей!
Для этого собственно применяется фича add-path - она позволяет рут-рефлектору отсылать не только лучший с его точки зрения путь, но и ещё дополнительные пути.
Я тут не про инженерию, а про архитектуру, так что как настроить - гугл\ChatGPT поможет
Telegram
Заметки сетевого архитектора
Моя мечта, как сетевого архитектора, жить в мире без L2. Оптимально - L3 до сервера, на котором сервисы. Идеальная схема которая покрывает и отказоустойчивость и увеличенную полосу, и масштабируемость - сервис (например веб сайт) висит на dummy\loopback интерфейсе…
#srv6
Первое впечатление от SRv6. Всё сетевое сообщество, попользовавшись каким-то временем IPv6 подумало "Блять, ну нахуй нам вообще столько битов в этом адресе, если мы всё равно ажно на целый хост /64 сеть выделяем? А давайте чтобы добро в виде этих неиспользуемых толком битов не пропадало запихаем туда чё нить? Ну какие-нибудь инструкции может быть, чтобы трафиком можно было гибко управлять, а все транзитные устройства обучим этим инструкции понимать и действовать по ним - инструкции по фаст-рероуту там сделаем, ну или по пути часть трафика на какие-нить анализаторы сливать будем..."
Первое впечатление от SRv6. Всё сетевое сообщество, попользовавшись каким-то временем IPv6 подумало "Блять, ну нахуй нам вообще столько битов в этом адресе, если мы всё равно ажно на целый хост /64 сеть выделяем? А давайте чтобы добро в виде этих неиспользуемых толком битов не пропадало запихаем туда чё нить? Ну какие-нибудь инструкции может быть, чтобы трафиком можно было гибко управлять, а все транзитные устройства обучим этим инструкции понимать и действовать по ним - инструкции по фаст-рероуту там сделаем, ну или по пути часть трафика на какие-нить анализаторы сливать будем..."
🤔1