Привет. Да ну не, отдельная стойка принципиально не нужна (но я не могу запретить) В целом не важно где именно находятся NLB\ALB хоть на отдельных стойках, хоть прямо на тех же Leaf-свичах, хоть в другом городе (не рекомендую). Главное, чтобы фабрика могла до них дотянуться по тем же принципам, что мы обсуждали: Anycast, BGP или другие "джентельменские соглашения" между железками. Ну а дальше ты начинаешь смотреть конкретно для своего кейса. Важно ли тебе чтобы латенси от точки входа в фабрику до NLB был маленький? А есть ли физическая возможность NLB поставить "поближе" к Интернету? Если это железные балансировщики - это одно. Если речь про какие-то облачные решения, где NLB - это какой-то сервис который динамически размещается в тенанте клиента - цэ другое. Ну а лиф-коммутаторы, конечно, здесь приведены для "упрощения" схемы. Когда стоит вопрос балансинга трафика между DC по каким-то "умным" алгоритмам (когда условный simple run bgp не справляется) лучше и юзать что-то поумнее коммутаторов (ну типа роутеры) - будем считать что это у меня заложено вот тут:
Вообще, главный посыл статьи - "серебряной пули нет" и "надо думать"
Привет, я хз на самом деле. Так глубоко не копал. Anyway ответ будет скорее всего зависеть от конкретного набора вендор\железка\тип overlay... если пофантазировать то, кажется что для "простого" VXLAN/UDP - современные свичи (типа Arista 7280CR3 или Juniper QFX) умеют заглядывать внутрь инкапсуляции и хешировать по внутреннему 5-tuple. Но если твой оверлей завёрнут в MPLS-over-GRE-over-VXLAN (кто тебя так обидел?) - тут уже надо смотреть на DPI или flow-steering (https://docs.nvidia.com/networking/display/mlnxofedv583070lts/flow+steering) .
В идеальном мире - можно было бы использовать что-то вроде Geneve с метаданными о flowlet'ах прямо в заголовке. Но мы же живём не в идеальном мире :(
(P.S. Если у тебя есть реальный кейс - расскажи, вместе посмеёмся/поплачем)
Вообще, задача очень интересная! Как управлять и что самое интересно - мониторить всё это дело ) Но сказать по ней мне вообще нечего. У нас FRR живёт в кубе и его конфигурим полустатично с помощью конфиг-мап кубовых.
Дмитрий, добрый день! Спасибо за статью!
Я правильно понял, что бы сделать такой LB кластер как минимум «внешние» интерфейсы должны быть в одной сети? Есть ли возможность собрать кластер когда ноды находятся в разных датацентрах, с разными IP адресами?
+ как быть в случае NAT, когда внешний интерфейс ASA спрятан за другим файрволлом, например? Что указывать в качестве VIP адреса? Публичнный или внутренний?
Спасибо!
Отличная интересная статья. Спасибо за перевод!
Единственное что термин «следующий участок сети» слегка режет слух сетевику. Полагаю, в оригинале было «next hop»? Вряд ли это можно нормально перевести, но в данном конексте звучало бы лучше если бы использовалось просто понятие маршрута. Сравните:
«Перехэширование случается, когда изменяется информация о следующих участках сети… Указывая в таблице маршрутизации статичные следующие участки сети, мы можем заставить коммутатор...»
и
«Перехэширование случается, когда изменяется информация о маршрутах… Указывая в таблице маршрутизации статические маршруты, мы можем заставить коммутатор...»
Спасибо за ответ в частности, и за статью в принципе!
То есть в итоге, есть некоторый коэффициент, ну допустим «K» (который в начале равен именно 10 в нашем случае), и растёт именно этот «K», пока произведение K*MSS (читай cwnd) не достигнет awnd? Именно этот «K» и определяет «количество отправляемых сегментов без ACK». И например при MSS = 1460 байт, «K» достигнет максимума при значении 64000/1460≈43
Это означает, что данный ПК может отправить сразу 10 пакетов, не дожидаясь получения подтверждения на них в виде ACK.
и подумал, что cwnd — это всегда количество пакетов, которые можно отправить без ACK. Возможно что подумал неверно, отсюда и вопрос.
Я в данной теории слаб, поэтому и хочу потдверждения\опровежения, что в рамках tcp сессии существует возможность отправить 64 000 сегмента не получая ACK от получателя
Сергей, добрый день. Не могу понять одной вещи.
Вот есть у нас параметр cwnd, о нём пишется:
По умолчанию значение окна перегрузки (congestion window — cwnd) для TCP-сессии в Windows 10 равно 10. Это означает, что данный ПК может отправить сразу 10 пакетов, не дожидаясь получения подтверждения на них в виде ACK.
То есть параметр cwnd вроде как отвечает за количество отправляемых пакетов (полагаю, правильно тут — сегментов, но не суть)
Далее есть параметры ssthresh и awnd:
В качестве начального значения порога прекращения работы алгоритма slow-start (ssthresh) и перехода в режим избегания перегрузки (congestion avoidence) берётся значение максимального окна, которое предоставил получатель (advertised window — awnd). В нашем случае ssthresh=awnd=64K
То есть, «в нашем случае awnd=64 000», и речь уже об объёме данных.
Итого cwnd показывает количество сегментов, awnd — объём данных.
Я не могу понять, как в таком случае сопоставляются данные параметры во фразе
Размер окна cwnd достигает максимального значения и становится равным awnd, а значит, cwnd = ssthersh.
Неужели в нашем случае количество отправляемых пакетов может достигнуть числа 64000?
Administrators are advised to allow only trusted users to have SNMP access
и
The attacker must know the community strings to successfully launch an attack against an affected device.
ACL + крепкий community стринг должен спасти, ага.
Я полагаю (ну а скорее мечтаю, зная реалии) что люди, которые испольщуют Cisco ASA, должны следовать данным правилам по дефолту
Привет. Да ну не, отдельная стойка принципиально не нужна (но я не могу запретить)
В целом не важно где именно находятся NLB\ALB хоть на отдельных стойках, хоть прямо на тех же Leaf-свичах, хоть в другом городе (не рекомендую). Главное, чтобы фабрика могла до них дотянуться по тем же принципам, что мы обсуждали: Anycast, BGP или другие "джентельменские соглашения" между железками.
Ну а дальше ты начинаешь смотреть конкретно для своего кейса. Важно ли тебе чтобы латенси от точки входа в фабрику до NLB был маленький? А есть ли физическая возможность NLB поставить "поближе" к Интернету? Если это железные балансировщики - это одно. Если речь про какие-то облачные решения, где NLB - это какой-то сервис который динамически размещается в тенанте клиента - цэ другое.
Ну а лиф-коммутаторы, конечно, здесь приведены для "упрощения" схемы. Когда стоит вопрос балансинга трафика между DC по каким-то "умным" алгоритмам (когда условный simple run bgp не справляется) лучше и юзать что-то поумнее коммутаторов (ну типа роутеры) - будем считать что это у меня заложено вот тут:
Вообще, главный посыл статьи - "серебряной пули нет" и "надо думать"
Привет, я хз на самом деле. Так глубоко не копал. Anyway ответ будет скорее всего зависеть от конкретного набора вендор\железка\тип overlay... если пофантазировать то, кажется что для "простого" VXLAN/UDP - современные свичи (типа Arista 7280CR3 или Juniper QFX) умеют заглядывать внутрь инкапсуляции и хешировать по внутреннему 5-tuple. Но если твой оверлей завёрнут в MPLS-over-GRE-over-VXLAN (кто тебя так обидел?) - тут уже надо смотреть на DPI или flow-steering (https://docs.nvidia.com/networking/display/mlnxofedv583070lts/flow+steering) .
В идеальном мире - можно было бы использовать что-то вроде Geneve с метаданными о flowlet'ах прямо в заголовке. Но мы же живём не в идеальном мире :(
(P.S. Если у тебя есть реальный кейс - расскажи, вместе посмеёмся/поплачем)
Привет! Ты что нагенерировал с помощью нейросетей сравнение несравнимых вещей и опубликовал это как статью на Хабре? О_о
rp_filter - это конечно ещё одна беда линук-сетевика, особенно когда со всяким оверлеем работаешь
Вообще, задача очень интересная! Как управлять и что самое интересно - мониторить всё это дело )
Но сказать по ней мне вообще нечего. У нас FRR живёт в кубе и его конфигурим полустатично с помощью конфиг-мап кубовых.
Лучше никто не сможет xD
Кулстори, спасибо)
Слушай, ну логику я описал, за фряху ты вроде шаришь - осталось написать статью ;))
Ага! Я догадывался что с помощью ip route2 можно и бриджы конфигурить, а не только vrf-ы с vxlan-ами!
Тем временем реальность - https://razrabs.ru/post/0e4e0a21-7fab-4f7f-a5f8-250b460e4d21
Привет! У VK, полагаю, тоже самое. Но суть статьи это не меняет. Теперь просто работаете по BYOL концепции.
Я правильно понял, что бы сделать такой LB кластер как минимум «внешние» интерфейсы должны быть в одной сети? Есть ли возможность собрать кластер когда ноды находятся в разных датацентрах, с разными IP адресами?
+ как быть в случае NAT, когда внешний интерфейс ASA спрятан за другим файрволлом, например? Что указывать в качестве VIP адреса? Публичнный или внутренний?
Спасибо!
Я не до конца понял, почему Вы разделили EVPN и MP-BGP EVPN. Бывает EVPN без BGP?
Единственное что термин «следующий участок сети» слегка режет слух сетевику. Полагаю, в оригинале было «next hop»? Вряд ли это можно нормально перевести, но в данном конексте звучало бы лучше если бы использовалось просто понятие маршрута. Сравните:
«Перехэширование случается, когда изменяется информация о следующих участках сети… Указывая в таблице маршрутизации статичные следующие участки сети, мы можем заставить коммутатор...»
и
«Перехэширование случается, когда изменяется информация о маршрутах… Указывая в таблице маршрутизации статические маршруты, мы можем заставить коммутатор...»
То есть в итоге, есть некоторый коэффициент, ну допустим «K» (который в начале равен именно 10 в нашем случае), и растёт именно этот «K», пока произведение K*MSS (читай cwnd) не достигнет awnd? Именно этот «K» и определяет «количество отправляемых сегментов без ACK». И например при MSS = 1460 байт, «K» достигнет максимума при значении 64000/1460≈43
и подумал, что cwnd — это всегда количество пакетов, которые можно отправить без ACK. Возможно что подумал неверно, отсюда и вопрос.
Я в данной теории слаб, поэтому и хочу потдверждения\опровежения, что в рамках tcp сессии существует возможность отправить 64 000 сегмента не получая ACK от получателя
Вот есть у нас параметр cwnd, о нём пишется:
То есть параметр cwnd вроде как отвечает за количество отправляемых пакетов (полагаю, правильно тут — сегментов, но не суть)
Далее есть параметры ssthresh и awnd:
То есть, «в нашем случае awnd=64 000», и речь уже об объёме данных.
Итого cwnd показывает количество сегментов, awnd — объём данных.
Я не могу понять, как в таком случае сопоставляются данные параметры во фразе
Неужели в нашем случае количество отправляемых пакетов может достигнуть числа 64000?
Но всё равно, спасибо!
и
ACL + крепкий community стринг должен спасти, ага.
Я полагаю (ну а скорее мечтаю, зная реалии) что люди, которые испольщуют Cisco ASA, должны следовать данным правилам по дефолту