[Robot_NagNews]

Материал:

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

 

Полный текст

[Saab95]

В статье описаны балансировки внутри сети, обычно с ними не бывает проблем, особенно если используется современное L3 оборудование.

[fomka31ru]

Обычно, производитель исходит из того, что в транке максимум 8 активных интерфейсов.

это было давно и не правда :) У той же циски хеш давно считается основываясь на цифре 256 (если мне не изменяет память). У джуна в лаге уже есть цифры 16, 32, 64 линка. Так что информация у вас устаревшая.

Инженер продумал архитектуру сети и организовал сначала ECMP, а потом двухгигабитный LAG, но наблюдает странную картину - на линии между R1 и R2/R3 балансировка идеальная. R2-R4 - всё уходит в один интерфейс. Дело в том, что на обоих участках используется одинаковая хэш-функция. R1 разделил потоки равномерно. На R2 попал уже сепарированный поток, в котором все параметры, как на подбор, дают одинаковый результат после применения хэш-функции. То есть R2 и рад бы распределить, но с алгоритмами не поспоришь.

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

По этой причине существует официальный костыль - Entropy Labels.

Entropy Labels - это не костыть, а механизм с помощью которого меняется алгоритм поведения для балансировки. Есть EL - круто, мы точно знаем что делать дальше и где заканчивается стек меток (Хотя мы и так знаем, можем просто не дойти до него). Нет - значит пытаемся дойти до конца стека меток стандартным способом (алгоритмом). Есть, кстати, другой rfc6391, который описывает балансировку по pw (оффтоп).

И блок-схемы этих алгоритмов не настолько просты.

Добавлять дополнительную метку в самый низ стека, которая не играет вообще никакой роли.

Она играет самую важную роль - выбор алгоритма (уже писал выше)

А вот вам следующий вопрос: кто в маршрутизаторе озадачен вопросом, в какой интерфейс отправить очередной пакет?.......И последний, кто остаётся в очереди - плата, получившая пакет. С платы обработки на неё уже загружен FIB, поэтому про то, какие члены есть у того или иного транка ей известно, и всё, что остаётся сделать - посчитать хэш и послать в нужном направлении.

С одним физическим портом на входе понятно, а что делать в случае, если на входе LAG состоящий из портов разных линейных карт?

 

PS: как-то так... к автору статьи претензий нет, просто высказал свои мысли

Изменено 27 августа, 2014 пользователем fomka31ru

[eucariot]

В статье описаны балансировки внутри сети, обычно с ними не бывает проблем, особенно если используется современное L3 оборудование.

Балансировка MPLS VPN вполне себе проблема, которую без костылей не решишь.

А между сетями - это BGP и всяческие Inter-AS VPN, там действительно всё сложно.

[SergeiK]

В статье описаны балансировки внутри сети, обычно с ними не бывает проблем, особенно если используется современное L3 оборудование.

LOL! И поэтому надо использовать Микротик :)!

Как раз на современном L3 оборудовании все подобные проблемы и вылезают, и именно они описаны.

[eucariot]

это было давно и не правда :) У той же циски хеш давно считается основываясь на цифре 256 (если мне не изменяет память). У джуна в лаге уже есть цифры 16, 32, 64 линка. Так что информация у вас устаревшая

Посыпаю голову пеплом. Видимо, мало читал. Явного упоминания этого в статьях не видел.

 

Добавлять дополнительную метку в самый низ стека, которая не играет вообще никакой роли.

Имелось в виду в маршрутизации MPLS-пакетов.

 

С одним физическим портом на входе понятно, а что делать в случае, если на входе LAG состоящий из портов разных линейных карт?

Подозреваю, что здесь нет никакой особой проблемы - каждая плата принимает решения самостоятельно. Если алгоритмы одинаковые, то разные потоки снова должны попасть в разные интерфейсы.

 

Спасибо за поправки к статье.

[s.lobanov]

Посыпаю голову пеплом. Видимо, мало читал. Явного упоминания этого в статьях не видел.

 

Да даже ваш Huawei S9300 с какими-то простенькими платами нормально балансирует по 3ём линкам

 

Последнее, что видел что плохо балансирует по 3ём линкам - Cisco 7600 с обычной лан-картой 67xx. Распределение было примерно 0.5, 0.25, 0.25

[DelSt]

Посыпаю голову пеплом. Видимо, мало читал. Явного упоминания этого в статьях не видел.

 

Да даже ваш Huawei S9300 с какими-то простенькими платами нормально балансирует по 3ём линкам

 

Последнее, что видел что плохо балансирует по 3ём линкам - Cisco 7600 с обычной лан-картой 67xx. Распределение было примерно 0.5, 0.25, 0.25

На 7600 3-битный хеш. это на всех 65/76 со всеми картами, кроме sup2t/dfc4.

раскладывается 3:3:2

Изменено 27 августа, 2014 пользователем DelSt

[orlik]

В статье описаны балансировки внутри сети, обычно с ними не бывает проблем, особенно если используется современное L3 оборудование.

Балансировка MPLS VPN вполне себе проблема, которую без костылей не решишь.

А между сетями - это BGP и всяческие Inter-AS VPN, там действительно всё сложно.

 

никаких проблем с балансировкой mpls vpn нет (современное оборудование без проблем загрядывает внутрь пакета и высчтитывает хеш) , некоторый проблемы возникают с PW но и тут уже фактические есть решение в виде entropy label (RFC 6790).