Ecmp группа что это
RouterOS-ECMP
Принцип работы ECMP в RouterOS
Equal Cost Multi-Path
Вы прекрасно помните, что двух одинаковых активных маршрутов, не может быть в одной таблице маршрутизации. Но если перед вами встала задача балансировать трафик через несколько шлюзов (именно шлюзов, а не интерфейсов) вам может прийти на помощь ECMP.
Схема сети
Для лучшего восприятия, наша схема сети.
Маршрутизация
Давайте поймём в чем суть.
Создадим на нашем маршрутизаторе два маршрут до необходимой сети.
Как видите у второго маршрута нет флага Active и до сети назначения, есть только один активный маршрут, все из-за того, что «в таблице маршрутизации не может быть двух одинаковых маршрутов в одной таблице маршрутизации«. Даже если и представить, что можно было бы так сделать, то маршрутизатору необходимо было бы указать, по какому принципу в какой шлюз трафик.
Для того чтобы настроить ECMP необходимо, создать обычный маршрут, но немного по другому.
Удалим все созданные маршруты
И настроим непосредственно маршрут ECMP. Перечислив шлюзы через запятую.
Как видите, у нас теперь один маршрут, но который доступен через несколько шлюзов.
Принцип работы
Когда маршрутизатор, выбирает маршрут ECMP для отправки пакета, он рассчитывает хеш для таких полей как source address, destination address, source interface, routing mark и ToS (5-tuple) из пакета, далее для данного хеша по принципу Round-Robin (по кругу) RouterOS выбирает шлюз из маршрута ECMP. Выбранный шлюз и хеш маршрутизатор записывает в FIB (Forwarding Information Base).
Такое поведение явно указывает нам на то, что балансировки по пакетам не происходит для связи двух хостов, так как при расчёте хеша, результат функции хеширования будет всегда один и тот-же.
Но в RouteOS принцип формирования хеша немного другой.
Если протокол поддерживает порты, т.е UDP или TCP, то к хешу добавляется ещё и данная информация из следующего заголовка. Поэтому одно соединение в протокол TCP или UDP будет использовать один и тот-же шлюз выбранные по RR и вполне возможно, что трафик будет примерно разделяться поровну, но именно по количеству соединений, а не по пакетам, но если протокол какой-нибудь другой, то его хеш всегда будет одинаковый и шлюз будет один и тот-же.
Для того чтобы происходила перебалансировка трафика, раз в 10 минут происходит обнуления кеша, и выбор шлюза происходит заново для каждого уникального хеша. Это немного не верное утверждение, но очень удобное для восприятия.
Первоначально я не хотел этого писать и так глубоко погружаться.
Дело в том, что при формировании хеша используется алгоритм Jenkins и к данным из пакета добавляется соль именно эта соль обновляется каждые десять минут. Алгоритм хеширования не сильный и не очень стойкий. Если злоумышленник начнёт, для примера в одном и том же пакете менять TOS, а так как значение TOS учитывается при формировании хеша, может так совпасть что хеш будет одинаковые (коллизия) с каким-нибудь другим пакетом, маршрутизатор выберет неправильный интерфейс выхода, а значит пакет может уйти в неправильное направление с оригинальными заголовками, что позволит злоумышленнику отправить пакет в другую сеть, с неправильными заголовками.
Именно поэтому каждые 10 минут, обновляется соль, для того чтобы уменьшить шанс коллизии, и постфактум очищается и Кеш, так как старые хеши со старой солью уже не актуальны и могу привести как к забиванию памяти так и к проблемам безопастности.
Также таблица кеша очищается каждый раз, когда происходит изменение таблицы маршрутизации. Т.е. Если вы изменили маршрут ECMP или по какой-то причине он сам изменился, то Кеш чистится и снова происходит расчет для каждого хеша свой уникальный шлюз.
Check-gataway
Эта известная проблема, если в маршруте ECMP вы поставите check-gatеway, то по факту это не работает, хотя и должны быть. Обратите внимание, не правильно поведение только при маршруте ECMP.
Я покажу вам скриншот
Как видите, не оного пакета icmp не было отправлено до шлюзов, это известный баг, который обходится просто, необходимо создать любой, даже самый дурацкий маршрут до шлюза.
И пинги сразу пойдут, как вы помните, что шлюз это общая сущность для всей таблицы маршрутизации и если шлюз признан как недоступный ВСЕ МАРШРУТЫ даже в тех где не установлено check-gatеway выпадут и таблицы маршрутизации.
И соответственно КЕШ очистится и заново будет пересчитываться без учёта «мёртвого» шлюза.
Балансировка
Если по ширине каналы разные, то можно указать в пропорциях количество шлюзов одноствольно друг друга, так как процесс выбора для каждого хеша происходит по технологии Round Robin, то увеличения количества записей одного и того же шлюза приведёт к большему попаданию по выбор.
Главное помните, что всё ровно используется хеш, и если соединение уже пошло через медленный канал, больше чем пропускная способность до шлюза, данное соединение уже не получит суммарную скорость. Чаще всего я в своей практике если и использую ECMP то использую чтобы снизить нагрузку на оборудование, допустим если разные маршрутизаторы по загрузки CPU, то вполне можно таким образом увести львиную долю трафика на другой маршрутизатор.
А можно ли добиться того чтобы трафик по пакетно маршрутизировался? Мой ответ ДА, но только очень аккуратно, честно я не проводил нагрузочного тестирования не на стенде не на реальном проде, но у нас есть возможность отключить Кеш, и тогда вы увидите такую картину.
Для того чтобы отключить КЕШ необходимо выполнить вселишь одну команду.
Я настоятельно рекомендую без тестов и уверенности этого не делать, так как для каждого пакета маршрутизатор будет выбирать каждые раз шлюз.
Я возможно в будущем проведу эксперименты на стенде, в которых проверим, разные размеры таблиц маршрутизации и при разной нагрузки pps и возможности моделей микротик.
RouterOS v7
А теперь я бы хотел рассмотреть, что нас ждём в новой версии RouterOS относительно ECMP.
В отличии от шестой версии, теперь необходимо создавать два маршрута
Теперь маршрутизатор сам соберёт ECMP маршрут, если dst-address И distance одинаковые.
Обратите внимание на флаг +.
Теперь для того, что бы принудительно перечитать хеши, можно заставить маршрутизатор перезапустить процессы формирования FIB
Надо сказать уверенно что седьмая версия RouterOS ещё не готова для прода.
Лишние элементы или как мы балансируем между серверами
Привет, Хабр! Какое-то время назад люди осознали, что увеличивать мощность сервера в соответствии с ростом нагрузки просто невозможно. Тогда-то мы и узнали слово «кластер». Но как бы красиво это слово не звучало, всё равно приходится технически объединять разрозненные серверы в единое целое – тот самый кластер. По городам и весям мы добрались до наших узлов в моём предыдущем опусе. А сегодня мой рассказ пойдёт о том, как делят нагрузку между членами кластера системные интеграторы, и как это сделали мы.
Внутри публикации вас также ждёт бонус в виде трёх сертификатов на месячную подписку ivi+.
Делай как все
Какие задачи ставят для кластера?
1. Много трафика
2. Высокая надёжность
03d63a0996fb
Как этого добиться? Самый простой способ поделить нагрузку между серверами – не делить её. Вернее так: дадим полный список серверов – пусть клиенты сами разбираются. Как? Да просто прописав все IP-адреса серверов в DNS для заданного имени. Древняя и знаменитейшая балансировка round-robin DNS. И в целом неплохо работает, пока не возникает потребность добавить узел – я уже писал про инертность DNS-кэшей. Выглядит DNS-балансировка так:
Первое, во что обычно упираются, это ARP-кэш на роутере, который не хочет понимать, что IP-адрес переехал на другой MAC. Впрочем, современные реализации либо «пингуют» роутер с нового MAC’а (обновляя кэш таким образом), либо вообще используют виртуальный MAC, который не меняется во время работы.
Второе, что бьёт по голове – это серверные ресурсы. Мы ведь не будем держать один сервер из двух в горячем standby? Сервер должен работать! Поэтому мы будет резервировать по VRRP два адреса на каждом сервере: один – primary и один backup. Если один из серверов пары сломается, второй примет на себя всю его нагрузку… может быть… если справится. И вот такая «парность» и будет главным недостатком, ибо не всегда есть возможность или целесообразность держать двойной запас серверной мощности.
Также нельзя не заметить, что каждый сервер требует своего собственного, глобально маршрутизируемого IP-адреса. В наше нелёгкое время это может стать большой проблемой.
В целом, мне скорее не нравится такой способ балансировки и резервирования, но для целого ряда задач и объёмов трафика он хорош. Прост. Не требует дополнительного оборудования – всё делается серверным софтом.
На шару
Продолжая перечисление простых решений, а может, стоит просто навесить один и тот же IP-адрес на несколько серверов? Ну, в IPv6 есть возможность сделать anycast в одном домене (и то балансировка там будет только для хостов внутри него, а для внешних – совсем не так), а вот в IPv4 такая штука просто создаст ARP-конфликт (более известный как конфликт адресов). Но это если «в лоб».
А если использовать небольшой наворот под кодовым названием «shared address» (разделяемый адрес), то такое возможно. Суть трюка заключается в том, чтобы сначала превратить входящий уникаст в броадкаст (ладно, если кто хочет – пусть делает мультикаст), а затем только один из серверов отвечает на пакеты от данного клиента. Как осуществляется превращение? Очень просто: все серверы кластера в ответ на ARP-запрос возвращают один и тот же MAC: либо несуществующий на сети, либо мультикастовый. После этого сеть сама размножит входящие пакеты на все члены кластера. А как серверы договариваются о том, кто отвечает? Для простоты скажем так: по остатку от деления srcIP на количество серверов в кластере. Дальше – дело техники.
Балансировка с разделяемым адресом
Такую технику реализуют разные модули и разные протоколы. Для FreeBSD такая возможность реализована в CARP. Для Linux в прошлой жизни мне доводилось использовать ClusterIP. Сейчас он, видимо, не развивается. Но я уверен, что есть и другие реализации. Для Windows такая штука есть во встроенных средствах кластеризации. В общем, выбор есть.
Преимуществом такой балансировки всё так же является чисто серверная реализация: никакой особой настройки со стороны сети не требуется. Публичный адрес используется всего один. Добавление или отключение одного сервера в кластере происходит быстро.
В недостатках же, во-первых, числится необходимость дополнительной проверки на уровне приложения, а во-вторых (и даже «в главных») – это ограничение по входящей полосе: количество входящего трафика не может превышать полосу в физическом подключении серверов. И это очевидно: ведь входящий трафик попадает на все серверы одновременно.
Так что в целом это неплохой способ балансировать трафик, если у вас немного входящего трафика, но употреблять его следует с умом. И тут я скромно скажу, что сейчас мы этот метод не используем. Как раз из-за проблемы входящего трафика.
Никогда не заговаривайте с интеграторами
Мне почему-то кажется, что задача балансировки между серверами должна быть типовой. А для типовой задачи должны быть типовые решения. А кто хорошо продаёт типовые решения? Интеграторы! И мы спросили…
Надо ли говорить, что нам предложили решения из вагонов самого разного оборудования? От Cisco ACE и до всяческих F5 BigIP LTM. Дорого. Но хорошо ли? Ладно, есть ещё прекрасный бесплатный софтовый L7-балансировщик haproxy.
В чём же смысл этих штучек? Смысл в том, что балансировку они делают на уровне приложения – Layer 7. Фактически, такие балансировщики являются полными прокси (full proxy): они устанавливают соединение с клиентом и с сервером от своего имени. В теории это хорошо тем, что они могут осуществлять прилипание клиента к определённому серверу (server affinity) и даже выбирать бэкэнд в зависимости от запрошенного контента (крайне полезная штука для такого ресурса как ivi.ru). А при определённой настройке – и фильтровать запросы по URL, защищаясь от различного рода атак. Главное же преимущество – такие балансировщики могут определять жизнеспособность каждого узла в кластере самостоятельно.
Балансировщики включаются в сеть как-то так
Признаюсь, мой прошлый опыт кричал «Без балансировщиков сделать ничего не возможно». Мы посчитали… И ужаснулись.
Самые производительные балансировщики, которые нам предложили, имели пропускную способность 10Гбит/с. По нашим меркам не смешно (серверы с тяжелым контентом у нас подключаются 2 * 10Гбит/с). Соответственно, чтобы получить нужную полосу, надо было бы набить целую стойку такими балансировщиками, с учётом резервирования. Посмотрите вот на эту схему:
Так выглядит физическое подключение балансировщика.
Конечно, есть ещё режим частичного прокси (half-proxy), когда через балансировщик проходит только половина трафика: от клиента к серверу, а обратно от сервера – идёт напрямую. Но такой режим отключает L7 функциональность, и балансировщик становится L3-L4, что резко снижает его ценность. А дальше последовательно возникает две проблемы: сначала нужно сделать достаточную мощности сети (в первую очередь – по портам, потом – по надёжности). Затем возникает вопрос: а как балансировать нагрузку между балансировщиками? В Москве поставить стойку с оборудованием для балансировки, в теории, наверно, можно. А вот в регионах, где наши узлы минималистичны (серверы да циска) добавление нескольких балансировщиков уже как-то не смешно. К тому же, чем длиннее цепочка, тем ниже надёжность. А оно нам надо?
ECMP или ничего лишнего
Решение нагуглилось почти случайно. Оказывается, современный роутер сам по себе умеет балансировать трафик. Если подумать, это разумно: ведь одна и та же подсеть может быть доступна через разные каналы с одинаковым качеством. Такая функция называется ECMP – Equal Cost Multiple Paths. Видя одинаковые по своей метрике (в общем смысле этого слова) маршруты, роутер просто делит пакеты между этими маршрутами.
ОК, идея интересная, но будет ли это работать? Тестовый запуск мы провели, прописывая статические маршруты с роутера в сторону нескольких серверов. Концепт оказался работоспособным, но потребовалась дополнительная проработка.
Во-первых, необходимо обеспечить попадание всех IP-пакетов, относящихся к одной TCP-сессии на один и тот же сервер. Ведь иначе TCP-сессия просто не состоится. Это так называемый режим «per-flow» (или «per-destination»), и он вроде как включен по умолчанию на роутерах Cisco.
Но сам BGP гарантирует только сетевую доступность сервера, но не прикладную. Чтобы проверять работоспособность прикладного софта, на сервере запущен скрипт, который осуществляет ряд проверок, и если что-то пошло не так, просто гасит BGP. Дальше дело роутера – перестать слать пакеты на этот сервер.
В третьих, была замечена неоднородность распределения запросов между серверами. Небольшая, и компенсируемая нашим ПО кластеризации, Но хотелось-то равномерности. Выяснилось, что по умолчанию роутер балансирует пакеты исходя из адресов отправителя и получателя пакета, то есть L3-балансировка. Исходя из того, что адрес получателя (сервера) всегда один и тот же, это указывает на неоднородность в адресах-источниках. Учитывая массовую NAT’изацию интернета, это неудивительно. Решение оказалось простым – заставить роутер учитывать порты получателя и источника (L4-балансировка) при помощи команды вроде
в зависимости от IOS. Главное только, чтобы у вас не было такой команды:
Итоговая схема выглядит вот так:
Ничего знакомого не заметили? Ну там, что это фактически anycast, только не между регионами, а внутри одного узла? Так это он и есть!
Преимуществами L3-L4 балансировки можно назвать эффективность: роутер должен быть, без него никак. Надёжность тоже на должном уровне – если вдруг сломается роутер, то дальше уже неважно. Дополнительное оборудование не приобретается – это хорошо. Публичные адреса тоже не расходуются – один и тот же IP обслуживается сразу несколькими серверами.
Есть, увы, и недостатки.
1. На сервер приходится ставить дополнительный софт, настраивать его и т.п. Правда, этот софт достаточно скромен, и не расходует ресурсы сервера. Так что – терпимо.
2. Переходные процессы одного сервера (включение в кластер или исключение) влияют на весь кластер. Ведь роутер ничего не знает о серверах – он думает, что имеет дело с роутерами и каналами. Соответственно, все соединения распределяются на все доступные каналы. Никакого server-affinity. В результате при выключении сервера все соединения перетасовываются между всеми оставшимися серверами. И все активные TCP-сессий разрываются (строго говоря – не все, есть шанс, что часть вернётся на тот же сервер). Это плохо, но учитывая нашу защиту от таких ситуаций (плеер перезапрашивает контент при разрыве соединений) и некоторые финты ушами (о которых я ещё расскажу), жить можно.
3. Существуют ограничения, на сколько равных маршрутов роутер может разделить трафик: на cisco 3750X и 4500-X это 8, на 6500+Sup2T – это 32 (но там есть один прикол). В целом этого достаточно, к тому же есть трюки, которые позволяют раскрутить это ограничение.
4. При такой схеме нагрузка на все серверы распределяется равномерно, что накладывает требование одинаковости на все серверы. И если добавлять в кластер более современный, мощный, сервер, нагрузка на него будет не больше, чем на соседа. К счастью, наш софт кластеризации эту проблему в значительной степени нивелирует. К тому же, в роутерах еще есть функция unequal cost multiple paths, которую мы пока не задействовали.
Промежуточный итог
Исключение балансировщиков из цепочки прохождения трафика позволило сэкономить на оборудовании, повысило надёжность системы и сохранило минималистичность наших региональных узлов. Нам пришлось применить несколько трюков, чтобы компенсировать недостатки такой схемы балансировки (надеюсь, у меня ещё будет шанс рассказать об этих трюках). Но в существующей схеме всё ещё есть лишний элемент. И я очень надеюсь убрать его в этом году и рассказать, как нам это удалось.
Кстати, пока я писал (точнее, черновик вылёживался) эту статью, коллеги на Хабре написали очень неплохую статью про алгоритмы балансировки. Рекомендую к прочтению!
ECMP и превратности балансировки на сетевом оборудовании
Содержание
Что, по сути своей, такое ECMP? Это балансировка трафика по равноценным путям. Разберёмся сначала со словом «балансировка».
Балансировка нагрузки
Она может осуществляться либо по пакетам, либо по потокам.
При большом числе потоков, они сравнительно равномерно раскладываются по путям.
Раньше у некоторых вендоров было два ограничения: строгая рекомендация по использованию числа линков в ECMP, кратного степени двойки, и ограничение на количество путей в ECMP. Оба были вызваны аппаратными возможностями. На сегодняшний день это уже неактуально.
Описанный подход называется статическим хэшированием, поскольку независимо от обстоятельств чип применят хэш-функцию на заголовки пакетов и возвращает путь, на который указал остаток от деления.
Особенности статического хэширования
Статическое хэширование замечательно работает на статической же сети, в которой ничего не флапает. Однако, стоит убрать или добавить путь, как вся таблица пересчитается. Разберёмся на примере. У Вани было 4 некстхопа и 5 потоков. На основе простейшего алгоритма по остатку от деления потоки распределяются так:
Маша забирает у Вани 1 поток, выдернув провод. И вот как меняется распределение:
Anycast
Ситуация кардинально меняется, когда речь заходит об Anycast»е. Напомню, что это один и тот же префикс, обычно /32, который анонсируется разными устройствами. И трафик на данный префикс отправляется к ближайшему устройству. То есть, запросы к одному IP-адресу могут фактически обрабатываться разными серверами, на которых он настроен. Такая конфигурация используется для балансировки нагрузки. И только таким способом можно обслужить терабиты трафика и миллиарды пользователей, когда имеется максимум пара 25Гб/с порт на одном сервере. Заводим 100 бэкендов за одним IP-адресом и получаем возможность обработать терабит трафика.
Resilient/Consistent Hashing
Читается, как ризилиент! Били ограничения статического хэширования по всем и больно, поэтому некий Каргер в MIT описал такой алгоритм хэширования, который позволял с минимальными нарушениями переживать изменение количества бакетов. Под бакетами (или слотами) в нашем случае будем иметь в виду доступные пути. И вот как это достигается.
У нас N бакетов (путей). Каждому из этих N бакетов сопоставлено какое-то число в диапазоне [o, M], то есть они рассредоточены по окружности.
Ключи (хэши от 5-Tuple) тоже находятся в диапазоне [0, M] и тоже наносятся на эту же окружность.
В чём разница со статическим хэшированием, спросите вы? А давайте посмотрим.
Сценарий 1. Удаление пути
Допустим, путь №21 исчезает. Тогда с окружности удаляется эта точка, а все сессии, перебегают на путь №29.
При этом, остаются неизменными все сессии, что лежат через пути №5, 12 и 29. То есть, фактически, дёрнутся только те, которые и так дёрнулись бы.
Сценарий 2. Добавление пути
Теперь добавляется путь №17. Тогда все сессии, что находятся между путями 12 и 17, которые до этого шли через путь 29, перенаправятся в путь №17.
И опять же ничего не случится с теми, которые идут через пути 5 и 12. И будет затронута только часть маршрутов, идущих через 29. Безусловно, это простая реализация, в которой, например, не поддерживается равномерность балансировки, но она даёт представление, как реализуется Resilient Hashing. С фактической его работой на сетевом оборудовании не всё так просто, поэтому не все устройства его поддерживают. А те, что поддерживают, дают лишь ограниченное число записей.
Поляризация трафика при балансировке
Ещё про Anycast
И вдруг падает линк Leaf0 Spine0. Трафик сессии перетекает на Spine1, где от его 5-Tuple считается хэш. И вот, если хэш-функция одна и та же, и порты подключения Leaf0 и Leaf1 одни и те же, то сессия автоматически снова ляжет через Leaf0 на LB0 и, конечно, тот же самый реальных бэкенд.
То есть, для этого сценария нам полезно использовать одни и те же порты для подключения Leaf к Spine.
MPLS Load Balancing
Не IP единым, как говорится. Много где бегает MPLS. Возможно, это не совсем относится к датацентровым сетям, но мы же не только про них говорим.
И всё же, что делать, если меток больше трёх, если тип нагрузки неизвестен и P-маршрутизатор не может определить, как балансировать? На помощь спешит Entropy Label RFC6790.
Entropy Label
Мыши и слоны
И вот, если пауза между двумя соседними флоулетами больше определённого порога, то их можно безопасно отправить в разные линки, таким образом эффективно разложив один поток на несколько путей. Что же до длины паузы, то она должна быть больше, чем возможная разница во времени доставки пакетов по различным путям ECMP. Например, если эта разница лежит в диапазоне 300-500 мкс, то 1 мс паузы должно быть достаточно, чтобы исключить любой реордеринг.
Теперь мы готовы обратиться к слову «равноценный» во фразе «Что, по сути своей, такое ECMP? Это балансировка трафика по равноценным путям».
Equal Cost
Всё просто в первом приближении. Однако, тут на сцену выходит гонка за ресурсами и оптимизацией. В случае мощной фабрики на каждый маршрут легко иметь 8 и больше некстхопов. Если счёт маршрутов идёт на тысячи и десятки тысяч, очень легко упереться в ресурсы аппаратного FIB, поэтому прибегают к ухищрениям. Так появилась концепция ECMP-групп.
ECMP Groups
Или нет? Мне лично оно непонятно. И каждый раз, как я на него смотрю, мне всё так же непонятно. Попробую сделать пару абзацев ECMP Groups Explained. И давайте для примера возьмём вот такую замысловатую сетоньку.
То есть, в FIB есть структура, содержащая 4 некстхопа, на которую указывают 100 маршрутов.
Когда происходит лукап адреса назначения в FIB, возвращается именно эта ECMP-группа. На основе заголовка пакета вычисляется значение хэш-функции, и для этого конкретного пакета выбирается определённый маршрут из этой группы и, соответственно, набор действий, которые нужно осуществить над пакетом.
На самом деле, если постараться, то
можно и FIB сломатьупереться можно. Флап линка Leaf Spine может вызывать высокую частоту обновления маршрутов. Если их много, вполне возможно, что не все они будут приезжать одновременно. И, несмотря на то, что в конечном состоянии должна остаться одна ECMP-группа (например, было 4 некстхопа, стало 3), из-за переходных периодов, могут начать создаваться новые ECMP-группы. У них есть какой-то lease-период, в течение которого они продолжают существовать даже при отсутствии маршрутов на них ссылающихся, поэтому новые группы могут создаваться быстрее, чем удаляются старые.
ECMP-группы при MPLS
А пикантности здесь добавляет MPLS. Как только мы добавим коммутацию по меткам, ситуация заиграет новыми красками. При голом IP некстхоп характеризовался параметрами (Egress_Interface, NH_MAC). В случае наличия метки, некстхоп уже состоит из трёх параметров: (Egress_Interface, NH_MAC, Label). А Label здесь уникален для префикса назначения и пути. То есть, даже если сети за удалёнными лифами будут резолвиться через лупбэки этих лифов, мы, возвращаясь к той же картинке, сходу получим 5 ECMP-групп. Внутри каждой группы по-прежнему сохраняется полный набор некстхопов и конкретный выбирается на основе хэша. Но именно из-за того, что метки, которые нужно записать в стек, разные, приходится держать отдельный набор NH под каждый маршрут.
Иллюстрация из доклада Дмитрия Афанасьева с Yandex Next Hop 2019. Фактически, в случае MPLS на лифах получается отдельная ECMP-группа на каждый маршрут. Представим теперь 8 ДЦ по 512 стоек в каждом. Даже без всяких внешних маршрутов получается 4096 лупбэков и, соответственно, ECMP-групп. А когда группы кончаются, начинает отбрасываться трафик. Такая беда. Ситуация приобретает ещё более тонкие оттенки, когда мы говорим о Transit LSP. В этом случае, в зависимости от конфигурации и производителя, возможна и ситуация с отдельной ECMP-группой на Transit LSP, что увеличивает их кратно.
Заключение
Была у меня идея, наконец, немного разобраться с тем, как работают сети. Так начался СДСМ. Потом СДСМ официально закончился. Но тут захотелось разобраться, что такое ECMP. Ну вы поняли. Разделаться полностью с вопросами балансировки задачи не стояло. Поэтому мы пролетели мимо VIP и туннелирования, DSR, L3/L4/L7 балансировщиков, GSLB, Global Unicast. Вопрос глобальной балансировки тянет на ещё одну статью, но для ознакомления рекомендую два видео, на которые я дал ссылки в следующем разделе.