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

У меня есть два 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.

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

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

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

У вас есть другая возможность перенести интерфейс на той же маршрутизаторе и затем настроить 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-сессии).

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

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

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

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