Вбудоване балансування навантаження BGP від ​​того ж маршрутизатора ISP

У мене є два маршрутизатори BGP для DIA з проблемою з одним провайдером, оскільки два посилання на цього провайдера приземляються на один і той же маршрутизатор SP. Мої передачі Ethernet через два окремі посилання MetroE від іншого провайдера від імені мого основного провайдера, оскільки у одного провайдера вже є волокна на bldg. Якщо хтось також може прояснити термінологію провайдера, коли один постачальник транспортує послуги для іншого, я би вдячний. Два схеми закінчують L3 одним і тим же маршрутизатором SP, тому мої два маршрутизатори кожен одноранговий з тим же маршрутизатором постачальника. Мені призначений простір ПА з цього СП.

Я не маю жодних проблем із балансуванням вихідної навантаження (або розподілом навантаження, як я думаю, було б більш технічно точним). Вихідний, я роблю ECLB на брандмауері, який вибирає один з двох крайових маршрутизаторів на основі хешу srcip / dstip .

Цей конкретний перевізник - забудьте про перевізника, який просто забезпечує транспорт - не врівноважує вхідний трафік від одного їх маршрутизатора через два ланки до моїх двох маршрутизаторів, і це напрямок, де ми могли б використовувати комбінований 5x50Mb BW, який у нас є контракт. ІП бачить рівні шляху до нас для тієї ж рекламованої мережі, і фактично лише перший шлях, який вони вивчають, - це те, що стає найкращим шляхом.

Я перерахував те, що я розглядаю як свої варіанти нижче, щоб отримати трафік по обох контурах, і хотів би дізнатися, що тут вважають фахівці найкраще, особливо якщо ви знайомі з типовими SOP SOP . Оскільки у мене є контракт, зміна контракту наразі не є можливим перебудовувати його іншим способом.

Дозвіл maximum-paths 2у мережі SP виправляє це, але це стосується всіх їхніх клієнтів BGP на тому ж маршрутизаторі, що я не думаю, що вони дозволять. Принаймні один варіант, який буде працювати, включає статичні маршрути, але це не те, що я хотів би віддати перевагу.

Нижче наведено варіанти, які я розглядав у своєму порядку уподобань.

1. Дозволити BGPmaximum-paths 2 на маршрутизаторі SP (стосується всіх клієнтів BGP, які там перебувають), тому / 24 використовується, коли рекламується в обох схемах

2. Розподіліть мою / 24 навпіл і рекламуйте окремо / 25s по кожному посиланню разом з / 24. SP нещодавно заявив, що спільнота без документації може використовувати їх для прийому префіксів> / 24. Це вимагає маніпулювання NAT на моєму брандмауері для використання глобальних адрес у обох / 25-х, оскільки більшість трафіку зараз спрямовано на нас лише за кількома адресами в нижній / 25.

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

4. Статичні маршрути SP до / 25s, щоб примусити префікс ECLB w / BGP / 24 (в RIB, але не застосовується, якщо відмова / 25s).

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

Більшість людей задають цю проблему, як проблему зворотного балансування навантаження.

Я б попросив «максимальні шляхи» (зазвичай це називається ECMP у стандартах та документах, а не ECLB). І якщо ECMP не є початковим, тоді ви повернетесь до плану / 25.

Іншими абревіатурами, які я не міг одразу зрозуміти, були DIA (виділений доступ до Інтернету?) Та SOP (стандартна операційна процедура?). Я не впевнений, чи справді це такі універсальні абревіатури, що їх слід використовувати в зміні stackexchange без принаймні ховертексту для їх вирішення.

Якщо говорити про термінологію, то ви справді вже говорили про транспорт, який, на мою думку, найчастіше називають таким видом послуг. Іноді люди також називатимуть це "прив'язкою".

У вас є ще один варіант переміщення інтерфейсу на вашій стороні до того ж маршрутизатора, а потім налаштування eBGP multihop *** між вами та вашим провайдером. Так, ви втрачаєте надмірність на своїй стороні, але з протилежної сторони все одно переходите до того ж маршрутизатора, тож це суперечливий момент. Це також виключає необхідність провайдера робити eBGP мультипуть, якщо вони не бажають цього робити з вами (але я виявив, що в основному більшість провайдерів добре з цим увімкнено, якщо це вже не ввімкнено) .

Якщо це не здається правдоподібним, тоді, оголосивши два / 25, швидше за все, найкраща ставка, якщо, звичайно, ваш провайдер не бажає ввімкнути maximum-paths(ще раз, якщо припустити, що цього ще не зробили).

*** Здійснення балансування навантаження за допомогою eBGP multihop у вашому сценарії передбачає наступне:

1. Перемістіть друге з'єднання провайдера до одного маршрутизатора на вашій стороні.
2. І ви, і постачальник налаштовуєте update-source Loopback0на кожному з ваших сеансів - вам не доведеться використовувати Lo0, якщо цього не хочете, доки ви, хлопці, домовляєтесь, до якої адреси статичний маршрут.
3. Налаштування 2x / 32 статичних маршрутів для циклів зворотного зв'язку один з одним за допомогою підключених інтерфейсів (або IP-адрес наступного переходу) - саме так працює балансування навантаження, оскільки це насправді лише ECMP.
4. Налаштування ebgp-multihop 2на сеансах один одного (Ви хочете, щоб це число було якомога менше, щоб уникнути викрадення сеансу TCP).

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

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

Отже, враховуючи те, що вони не здаються надзвичайно грамотними, щоб збалансувати трафік, не знімайте свій префікс / 24 - замість цього залиште його та переконайтесь, що ваш / 25 маршрутів позначений тегом NO_EXPORT на додаток до того, що нібито ваш провайдер вимагає, щоб ваші / 25 років випадково не витікали зі своєї АС (не те, що, швидше за все, вийде дуже далеко).

Останнє зауваження - переконайтеся, що ця "незадокументована спільнота" насправді не є спільнотою чорних діл, адже це було б ... знаєте, погано .