ECMP с BGP и GRE

[Joseph W. Doherty]

@dibbledobble
написал:
Для обеспечения доступности туннельных пунктов назначения на нашей стороне мы получаем маршрут по умолчанию от нашего интернет-провайдера на каждом канале, и маршрутизатор устанавливает оба маршрута как равные. Если маршрутизатор «видит» оба туннеля как одинаково действительные по любому из путей, т. е. пункты назначения туннеля маршрутизатора проходят через маршрут по умолчанию ECMP, то любой из туннелей может использовать любой из путей, и вероятность того, что оба туннеля будут использовать один и тот же физический путь, составляет 50/50. Эту проблему можно решить, используя статический маршрут с приоритетом выше, чем у маршрута по умолчанию, и выбирая конкретный интерфейс выхода для каждого туннельного пункта назначения. (Если один путь выходит из строя, либо туннель выходит из строя, заставляя весь трафик использовать один туннель, либо трафик туннеля переключается на оставшийся путь. В обоих случаях обеспечивается избыточность.) @dibbledobble
написал:
Еще один вопрос: какое разделение обычно наблюдается для обратного/входящего трафика и есть ли способ повлиять на него, чтобы он был равномерно сбалансирован? Третья сторона также использует ECMP, я понимаю, что есть элементы, такие как транзитные сети и интернет-провайдеры, над которыми мы не имеем контроля, но мне просто интересно, какой опыт у других людей в этом вопросе? Выбор пути входящего трафика в реальном мире очень изменчив. По моим наблюдениям, при наличии нескольких интернет-соединений (почти всегда от разных интернет-провайдеров — если бы это был один и тот же интернет-провайдер, то, вероятно, многопортовый Ethernet использовал бы Etherchannel), трафик в Интернете часто использует один путь входящего трафика, даже если ECMP возможен. Если ваш исходящий трафик не является просто настройками ECMP по умолчанию, лучший путь для исходящего трафика часто является также лучшим путем для входящего трафика для одной и той же пары src/dst. Не слишком сложно отправить трафик по нужному пути, но может быть сложно заставить ответный трафик использовать нужный входящий путь. (Вы можете, работая с разными интернет-провайдерами, попытаться обеспечить, чтобы определенные пары src/dst, входящий трафик, использовали нужный вам путь). Однако, работая только с одним интернет-провайдером, они должны быть в состоянии сделать практически то же самое для вашего входящего трафика, что и вы для своего исходящего трафика к ним. То есть общий интернет-трафик может использовать ECMP для вас, но два туннеля должны быть «привязаны» к определенному пути. Опять же, это зеркальное отражение вашей конфигурации для них.

[Joseph W. Doherty]

#2 Обычные протоколы маршрутизатора ECMP, нет. PfR от Cisco мог бы решить эту проблему, но не уверен, что он все еще доступен. #1 У вас один туннель для каждого физического соединения или только один туннель? Если у вас только один туннель, он рассматривается как единый поток, поэтому обычно он будет использовать только одно физическое соединение, если не используется распределение пакетов по пакетам, тогда туннелируемые пакеты будут распределены по двум физическим путям. (Это НЕ рекомендуется! [Поскольку это часто приводит к доставке пакетов не в порядке, что часто имеет негативные последствия.]) Я помню (???) что более поздняя версия IOS имела некоторые (опциональные?) улучшения для многопутевых соединений и туннелей, но не помню подробностей. Т. е. возможно, она позволяла распределять пакеты одного туннеля по ECMP по потокам. Если у вас есть несколько туннелей, я полагаю, что их можно использовать в режиме ECMP. Функция, о которой я думал, как я полагаю, — это
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipswitch_cef/configuration/xe-16/isw-cef-xe-16-book/isw-cef-ecmp-loadbalance-with-tunnel-visibility.html

[Ramblin Tech]

Привет
[, @Joseph W. Doherty] Я не могу сказать, как маршрутизаторы на базе программного обеспечения IOS/XE могут обрабатывать № 1, но возможность аппаратного маршрутизатора выполнять хеширование внутреннего заголовка (полезной нагрузки) будет зависеть от платформы. В большинстве случаев пользователь захочет выполнить хеширование внутреннего заголовка, поскольку внешний заголовок (GRE) обычно имеет меньше вариаций, чем внутренний (т. е. меньше туннелей, чем потоков внутри туннелей). Чтобы хешировать внутренний заголовок, аппаратный механизм пересылки должен быть спроектирован таким образом, чтобы распознавать внешнюю инкапсуляцию (GRE, MPLS и т. д.) и знать правильное смещение, чтобы глубже проанализировать пакет и найти внутренние поля хеширования (например, IP-адреса полезной нагрузки). «Современные» NPU могут легко это сделать, но не все оборудование в этой области является современным. Возможно, автор вопроса может ответить, указав модель своего маршрутизатора, и кто-то, знакомый с ней, сможет проверить, можно ли использовать внутренний заголовок для хеширования. Однако здесь следует учесть, что это ответит только на вопрос о трафике, выходящем из сети клиента в сторону ISP, поскольку распределение трафика в обратном направлении, в сторону клиента, находится под контролем ISP. Отказ от ответственности: я давно работаю в CSCO. Неправильные ответы — моя вина, так как они не генерируются ИИ.

[Joseph W. Doherty]

Хм, я не уверен, есть ли необходимость комментировать информацию Джима, так как она полностью верна, но, прочитав то, что он написал, я задаюсь вопросом, не может ли кто-нибудь предположить то, что не было сказано. Джим пишет: «
В большинстве случаев пользователь захочет хешировать внутренний...
» (заголовок). Я считаю, что он прав на 100 %. Однако могут возникнуть и другие вопросы, например:
«В большинстве случаев использования пользователю действительно нужно хешировать внутренние заголовки?». И/или, несмотря на соображения, связанные с программным обеспечением/аппаратным обеспечением/платформой, «Доступны ли внутренние заголовки для проверки?». Подумайте о шифровании. Для OP есть желание LB через оба SP-связи (о, и это здорово, что Джим упомянул, что мы контролируем только SP), и мы просто используем GRE, по крайней мере, шифрование не является проблемой. В любом случае, на программных платформах, игнорируя шифрование, использование внутреннего заголовка было бы относительно простым, но при использовании специального оборудования все обстоит иначе (хотя Джим также прав, последние NPU, вероятно, имеют такую возможность, но, скорее всего, все равно потребуется программное обеспечение для ее настройки). Таким образом, поскольку поставщики, такие как Cisco, по крайней мере на рынке Enterprise, вероятно, не получают большого спроса на эту возможность, они, вероятно, не спешат ее предоставлять, особенно если можно настроить туннель через оба пути, LB будет работать так же, как для двух физических интерфейсов, что может быть вполне приемлемо. Подводя итог, можно сказать, что разделение одного туннеля на несколько физических путей в значительной степени зависит от платформы, но разделение трафика на несколько туннелей («привязанных» к определенному физическому пути), вероятно, может быть выполнено так же, как и для нескольких физических интерфейсов. Динамический LB, за пределами SD-WAN (?), я знаю только в мире Cisco, поддерживаемый PfR. Кстати, теоретически, ECMP, если одно соединение достигает 100%, все соединения должны быть 100%. На практике, если потоки проходят LB, это не так, но часто даже оптимальный LB на основе потока не будет равным. CEF пакет за пакетом очень близок к действительно равномерному распределению нагрузки, но из-за проблем с последовательностью потоков не рекомендуется. Другие подходы, такие как ATM IMUX или MLPPP, также обеспечивают хорошее равномерное распределение нагрузки, но каждый из них имеет свои особенности. Возможно, если вы можете достичь одного туннеля, «привязанного» к каждому соединению, вы достигнете «нормального» ECMP, который будет «достаточно хорошим». О, так же, как и в случае с выбором алгоритмов распределения нагрузки Etherchannel, полагаю, что некоторые CEF ECMP могут предлагать варианты улучшения распределения нагрузки в конкретных случаях; однако это еще одна зависимость от платформы.

[dibbledobble]

Спасибо, Джозеф, посмотрю PfR. У нас есть два туннеля, использующие один и тот же исходный IP-адрес, настроенный на обратную связь, который объявляется по обоим каналам ISP для обеспечения отказоустойчивости. Допустим, мы объявляем сеть 10.10.10.0 нашей третьей стороне, они видят маршруты с равной стоимостью через IP-адреса туннелей, а также есть маршруты с равной стоимостью обратно к нашему исходному IP-адресу. Как ECMP решает распределять трафик? Наша конфигурация туннеля: интерфейс Tunnel0
ip адрес 172.16.100.2 255.255.255.252 <--IP-адрес туннеля
источник туннеля 1.1.1.1 <--исходный IP-адрес
туннеля назначение 2.2.2.2 интерфейс Tunnel1
ip адрес 172.16.100.6 255.255.255.252 <--IP туннеля
источник туннеля 1.1.1.1 <--IP-адрес источника
назначение туннеля 3.3.3.3 ============================================= Таблица маршрутизации третьей стороны: B 1.1.1.1 [20/0] через 192.168.100.2
[20/0] через 192.168.100.6 B 10.10.10.0 [20/0] через 172.16.100.2
[20/0] через 172.16.100.6

[Joseph W. Doherty]

Я полагаю, что ECMP будет работать в обоих туннелях. Однако, что видно для маршрутизации в вашем примере, пункты назначения туннелей 2.2.2.2 и 3.3.3.3? То есть возможно, что трафик обоих туннелей будет направляться на одно и то же физическое соединение.

[dibbledobble]

Для обеспечения доступности туннельных пунктов назначения на нашей стороне мы получаем маршрут по умолчанию от нашего интернет-провайдера на каждом канале, и маршрутизатор устанавливает оба маршрута как равные. Еще один вопрос: какое распределение обычно наблюдается для обратного/входящего трафика и есть ли способ повлиять на него, чтобы он был равномерно сбалансирован? Третья сторона также использует ECMP. Я понимаю, что есть элементы, такие как транзитные сети и интернет-провайдеры, над которыми мы не имеем контроля, но мне просто интересно, какой опыт у других людей в этом вопросе?

[dibbledobble]

Если маршрутизатор «видит» оба туннеля как одинаково действительные для обоих путей, т. е. пункты назначения туннелей маршрутизатора находятся по умолчанию на маршруте ECMP, то любой из туннелей может использовать любой из путей, и вероятность того, что оба туннеля будут использовать один и тот же физический путь, составляет 50/50.
Эту проблему можно решить с помощью статического маршрута с приоритетом выше, чем у маршрута по умолчанию, выбрав конкретный интерфейс выхода для каждого пункта назначения туннеля. (Если один путь выходит из строя, либо туннель выходит из строя, заставляя весь трафик использовать один туннель, либо трафик туннеля переключается на оставшийся путь. В обоих случаях обеспечивается избыточность.) Я пытался реализовать статические маршруты в лаборатории, чтобы все туннели не использовали один и тот же путь. Итак, у меня есть два контура и четыре туннеля, статические маршруты к каждому из конечных пунктов назначения туннеля. В нашей среде мы используем GRE keepalives, поэтому в рамках тестирования я снизил их до 5 2. Желаемая настройка — два туннеля используют цепь A, а два других — цепь B. Для тестирования я отключил цепь A и ожидал, что два туннеля выйдут из строя, однако даже со статическими маршрутами вышли из строя три туннеля. Достаточно ли одних статических маршрутов, чтобы заставить туннели использовать цепь/физический путь, или обратный трафик также должен быть спроектирован так, чтобы отражать исходящий поток?

[Joseph W. Doherty]

Достаточно ли одних статических маршрутов, чтобы заставить туннели использовать цепь/физический путь, или обратный трафик также необходимо настроить так, чтобы он отражал исходящий поток? Не могу сказать без дополнительной информации, такой как фактическая топология лаборатории, конфигурации устройств и то, что именно вы сделали, чтобы отключить цепь. Я не думаю, что это вероятно, но какие лабораторные платформы (и IOS) использовались на самом деле? (Мне интересно, смогу ли я воспроизвести это в своей копии CML.)

[dibbledobble]

Извините, что так долго не отвечал. Я объявил оба IP-адреса источника туннеля из обоих цепей, и, по-моему, это вызывало проблемы. После того как я изменил настройки, чтобы объявлять один IP-адрес источника на каждую цепь, туннели теперь, похоже, работают как положено. Спасибо всем за помощь!