Балансировка нагрузки входящего BGP с того же маршрутизатора ISP

10

У меня есть два BGP-маршрутизатора для DIA с проблемой с одним провайдером, поскольку две ссылки на этого провайдера находятся на одном и том же SP-маршрутизаторе. Передача моего Ethernet через две отдельные линии MetroE от другого провайдера от имени моего основного провайдера, так как у одного провайдера уже было оптоволокно к зданию. Если бы кто-то также мог прояснить терминологию интернет-провайдера, когда один провайдер передает услуги другому, я был бы признателен. Два канала завершают L3 одним и тем же маршрутизатором SP, поэтому каждый из двух маршрутизаторов одноранговый с одним и тем же маршрутизатором поставщика. Я назначен PA пространство от этого SP.

У меня нет проблем с исходящей балансировкой нагрузки (или с распределением нагрузки, так как, я думаю, это будет технически более точным). Исходя, я делаю ECLB на брандмауэре, который выбирает один из двух пограничных маршрутизаторов на основе хэша srcip / dstip .

Этот конкретный оператор - забудьте о поставщике, который просто предоставляет транспорт - не балансирует нагрузку входящего трафика от их одного маршрутизатора через два канала к двум моим маршрутизаторам, и это направление, в котором мы могли бы использовать объединенную 5x50Mb BW, которую мы имеем по контракту. SP видит для нас равные пути для одной и той же рекламируемой сети, и, по сути, только первый путь, который они изучают, становится тем, что становится лучшим путем.

Я перечислил то, что я рассматриваю в качестве своих вариантов ниже, чтобы получить трафик по обоим каналам, и хотел бы знать, что эксперты здесь считают лучшим, особенно если вы знакомы с типичными SP SOP . Поскольку у меня есть контракт, изменение контракта в настоящее время не позволяет перестроить его каким-либо другим способом.

Разрешение maximum-paths 2в сети SP исправляет это, но это относится ко всем их клиентам BGP на том же маршрутизаторе, который я не думаю, что они позволят. По крайней мере, один вариант, который будет работать, связан со статическими маршрутами, но это не то, что я бы предпочел.

Ниже приведены варианты, которые я рассмотрел в своем порядке предпочтений.

  1. Разрешить BGPmaximum-paths 2 на маршрутизаторе SP (влияет на всех клиентов BGP, размещенных там), поэтому / 24 используется при объявлении на обоих каналах

  2. Разделите мои / 24 пополам и разместите рекламу / 25 по каждой ссылке вместе с / 24. SP недавно заявил, что недокументированное сообщество может использоваться для принятия префиксов> / 24. Это требует манипулирования NAT на моем брандмауэре для использования глобальных адресов в обоих / 25, так как большая часть трафика теперь направляется нам только по нескольким адресам в нижнем / 25.

  3. Статические маршруты SP к / 24 для принудительного распределения нагрузки с BGP / 24 (плавающий маршрут).

  4. Статические SP-маршруты направляются в / 25 с для принудительного использования префикса ECLB с BGP / 24 (в RIB, но не используются, если не произошел сбой / 25 с).

Я думаю, что реклама / 25s в BGP - лучший вариант, который я только недавно обнаружил, возможен с недокументированным сообществом SP, но есть ли другие варианты, которые я не рассматривал, или опасения по поводу неупорядоченных пакетов с некоторыми из этих вариантов выбора ?

Это своего рода проблема обратной балансировки нагрузки, которую большинство людей задают с BGP.

generalnetworkerror
источник
1
Максимальные пути могут работать, даже если вы подключены к двум разным маршрутизаторам, в случае, если для каждого входящего PE в сети оператора необходимо включить максимальные пути и получать оба пути от iBGP.
ytti
Были ли у меня сомнения по этому поводу, когда я это написал ... Вопрос пересмотрен.
generalnetworkerror

Ответы:

8

Я бы попросил «максимальные пути» (в стандартах и ​​документах это обычно называется ECMP, а не ECLB). И если ECMP не является стартовым, то отступите к вашему / 25 плану.

Другими аббревиатурами, которые я не мог сразу понять, были DIA (выделенный доступ в интернет?) И SOP (стандартная рабочая процедура?). Я не уверен, действительно ли это настолько универсальные аббревиатуры, что их следует использовать в stackexchange без хотя бы ховертекста для их разрешения.

ytti
источник
Спасибо, я знал, что ECLB звучит неправильно, но я не мог вспомнить ECMP на макушке. И ты прямо на TLA. ;-) DIA - это универсальный термин, который каждый провайдер первого уровня, которого я использовал в течение последнего десятилетия, использует в контрактах на обслуживание через Интернет по прямым ссылкам. SOP также универсален, но я дам вам понять, что это было натяжение, используя его в акронимовой дисциплине, такой как NE.
generalnetworkerror
6

Говоря о терминологии, вы на самом деле уже говорили о транспорте, который, как мне кажется, чаще всего называют этим типом услуг. Иногда люди также будут называть это «привязью».

У вас есть другая возможность перенести интерфейс на той же маршрутизаторе и затем настроить eBGP multihop *** между вами и вашим провайдером. Да, вы теряете избыточность на своей стороне, но на противоположной стороне он все равно идет к одному и тому же маршрутизатору, так что это своего рода спорный вопрос. Это также устраняет необходимость того, чтобы провайдер использовал многолучевое распространение eBGP, в случае, если они не хотят делать это с вами (но я обнаружил, что в большинстве случаев провайдеры в порядке, если он еще не включен) ,

Если это не кажется правдоподобным, то объявление двух / 25, вероятно, будет лучшим выбором, если, конечно, ваш провайдер не захочет включить maximum-paths(опять же, если они этого еще не сделали).

*** Выполнение балансировки нагрузки с помощью eBGP multihop в вашем сценарии будет включать следующее:

  1. Переместите второе подключение к провайдеру на один маршрутизатор на вашей стороне.
  2. И вы, и провайдер настраиваете update-source Loopback0на каждом из ваших сеансов - вам не нужно использовать Lo0, если вы не хотите, если вы, ребята, договариваетесь о том, к какому адресу подключаться static-route.
  3. Сконфигурируйте статические маршруты 2x / 32 для петель друг друга через подключенные интерфейсы (или IP-адреса следующего перехода) - так работает балансировка нагрузки, поскольку на самом деле это просто ECMP.
  4. Настройте ebgp-multihop 2на сеансах друг друга (вы хотите, чтобы это число было как можно меньше, чтобы избежать перехвата TCP-сессии).

Вуаля, балансировка нагрузки. Это также масштабируется для интерфейса, так как добавление нового порта будет включать добавление другого интерфейса и статического маршрута.

Джон Дженсен
источник
Можете ли вы объяснить, как оператор начнет отправку трафика по обоим каналам, переместив eBGP на тот же маршрутизатор на стороне клиента, если многолучевое распространение не включено.
ytti
Конечно, я изменю свой ответ.
Джон Дженсен
Строго говоря, это не требует многопоточности или миграции на тот же маршрутизатор. Это просто требует, чтобы вы изменили свой следующий шаг протокола BGP, чтобы он был одинаковым как для одноранговых узлов eBGP, так и для поставщика, принимающего «удаленный следующий переход» и статический маршрут к ним.
ytti
Я не уверен, что ты имеешь в виду. Использование EBGP многоинтервального для балансировки нагрузки в этой моде ли требует параллельных соединений между теми же 2 маршрутизаторами.
Джон Дженсен
Вам не нужно перемещать существующие сеансы eBGP. Вы можете просто сбросить следующий переход в маршрутной карте на некоторый адрес, такой же в обоих eBGP (вам даже не нужно нигде настраивать IP). До тех пор, пока провайдер принимает этот измененный следующий переход (требуется переключение в IOS и JunOS) и настраивает статические маршруты, как вы объяснили, он прекрасно работает без многократного переключения или перемещения eBGP на стороне клиента.
ytti
3

Оптимальным решением здесь является BGP ECMP через maximum-paths 2- однако я скажу, что «принятие маршрутов> / 24», требующее наличия тега сообщества, звучит как эпическая глупость - если вы являетесь их клиентом, они должны принять все, что вы дадите им до Максимальное количество префиксов и просто фильтровать исходящие в соответствии с соглашениями, которые они имеют с другими партнерами. один из вышеперечисленных источников ставит меня в аналогичную ситуацию с тем, что я не выполняю ECMP, я всегда ожидаю, что мне будет разрешено объявить любой префикс размера, который я желаю, для транзитного провайдера, и пусть они его используют.

Поэтому, учитывая, что они не кажутся ужасно компетентными, чтобы сбалансировать трафик, не снимайте свой префикс / 24 - вместо этого оставьте его и убедитесь, что ваши / 25 маршруты помечены NO_EXPORT в дополнение к тому, что, как утверждается, ваш провайдер требует, чтобы ваши / 25 не случайно вытекли из их AS (не то, чтобы, скорее всего, это было бы очень далеко).

И последнее замечание - убедитесь, что это «недокументированное сообщество» на самом деле не сообщество черных дыр, потому что это было бы… ну, знаете, плохо .

Olipro
источник
Это из известного уровня 1, и все интернет-провайдеры, где я делал BGP, не допускают это gt 24в качестве общей политики. Я планировал установить NO_EXPORT на / 25s.
generalnetworkerror
все мои апстримы примут > / 24 от меня, они просто не будут его экспортировать. Я фактически использую этот эффект для шунтирования трафика, так как они не делают ECMP.
Олипро
Кроме того, такая вещь была бы ужасна в случае атаки - если вы не можете объявить / 32 своему восходящему потоку с сообществом черных дыр, у вас проблемы.
Олипро
Они допускают объявления чёрной дыры любого размера с нужным сообществом.
generalnetworkerror