Краще корпоративний мультихомінг

Я хотів би отримати деякі думки щодо способів, як я можу вдосконалити дизайн подвійного провайдера BGP, подвійний маршрутизатор. Кожен постачальник постачає публічну підмережу / 24. Я буду називати маршрутизатори, мікросхеми, підмережі, групи HSRP і провайдери як A і B відповідно. Пропускна здатність кожного контуру є адекватною для всього навантаження.

Поточний дизайн

Поточний дизайн намагається досягти симетричності кожного постачальника. У сталому стані призначена логіка маршрутизації полягає в тому, що трафік до / з підмережі A проходить тільки ланцюг A, а трафік до / з підмережі B проходить тільки ланцюг B. Схеми підтримують один одного в невдалому стані.

Постачальники рекламують лише маршрут за замовчуванням. Вихідна маршрутизація тягне за собою поєднання PBR та HSRP. Маршрутизатори не мають маршрутизації між собою: Ні iBGP, ні OSPF, ні статична маршрутизація. Натомість є дві групи HSRP, які відстежують маршрут за замовчуванням. Маршрутизатор A є основним для групи HSRP A, а маршрутизатор B - первинним для групи HSRP B. Пристрої нижче за течією мають маршрут за замовчуванням, що вказує на групи ASR і HSRP, що спрямовує трафік з підмережі B до групи HSRP B. На вхідну маршрутизацію впливають попередньо і громади. Підмережа A є попередньою та передається в ланцюг B, а підмережа B є попередньою та передається в ланцюг A.

Я бачу багато можливостей для вдосконалення цього дизайну. Відсутність обізнаності з топологією Інтернету в поєднанні зі спорідненістю ланцюга повністю виключає найкращий вибір шляху. Виникають занепокоєння щодо призначення рівнів постачальників, і дизайн був раціоналізований як такий, що забезпечує "прийнятну ефективність" та простіший для усунення несправностей. Дійсно, дизайн не міг бути простішим. Я продемонстрував, що транзит додаткової АС додає 6 НТ і 63 мс (+ 421%) до RTT. Я вважаю за краще не погоджуватися на прийнятне.

Кращий дизайн

Кращий дизайн забезпечує маршрутизаторам якомога більше поінформованості про Інтернет-топологію. Найкращий алгоритм шляху залишається для визначення логіки вхідної та вихідної маршрутизації. Схеми будуть підтримувати один одного в невдалому стані.

Постачальники рекламують повний перегляд. Маршрутизатори працюють iBGP та OSPF. HSRP усувається. Вихідна маршрутизація буде суто найкращим шляхом на основі призначення, а вхідна маршрутизація залишатиметься найкращим алгоритмом шляху та примхами постачальника транзиту.

Тепер, коли я його набираю, це здається більш простим. Принаймні, для пояснення знадобилося менше слів. Є питання про асиметрію, але я бачив багато асиметрії в сучасній конструкції. Я думаю, що вони, мабуть, однаково схильні до асиметрії, і це насправді не хвилює мене. Ми ніколи не бачили проблем у результаті. На сьогоднішній день він передається царині ifs: "Що" якщо "нам довелося щось виправити?"

Я тут від бази, чи вдарив цвяхом по голові? Як інші вирішили цю проблему? Що робитиме Google?

Так, ти все-таки вдарився цвяхом по голові.

Ви отримаєте асиметрію в покращеному дизайні, але асиметрія - це факт життя в Інтернеті, і справді немає вагомих причин очікувати симетричного маршрутизації трафіку до / з. Зрозумійте, вся концепція маршрутизації пакетів полягає в тому, що окремі пакети маршрутизуються незалежно один від одного і можуть проходити різними шляхами, навіть пакети, що йдуть в одному напрямку.

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

Повний Інтернет-маршрути у ваших маршрутизаторах потребують певного звикання, але коли ви звикнете, це зрозуміти та вирішити неполадки. Безумовно, існує менше «рухомих частин» різних протоколів.

Ви не хочете, щоб у вашій базі даних OSPF були повноцінні Інтернет-маршрути, тому ви хочете рекламувати за замовчуванням через OSPF у внутрішній частині вашої мережі (або, можливо, статичний дефолт ... особисто я вважаю за краще за замовчуванням в OSPF). Це перемістить трафік до маршрутизаторів, що говорять на BGP, які можуть прийняти більш повноцінне рішення про повноцінні маршрути в Інтернеті.

Це дасть вам близький до "кращого шляху на основі призначення". Ще будуть випадки, коли трафік буде робити те, що ви не зовсім очікуєте, тому вам захочеться ознайомитись із процесом вибору маршруту BGP.

Запропонувати інший підхід до інших, що вже даються, який може бути або не бути кращим, ніж існуючі ідеї, але в першу чергу через деякі додаткові ідеї там;

Я б сказав, що два простих кроки, які ви можете зробити, щоб покращити свою ситуацію, такі:

Крок 1 ;

Отримайте повні таблиці BGP від ​​обох постачальників - Тепер у вас буде більш оптимальна вихідна маршрутизація, оскільки ви будете маршрутизувати через транзитного постачальника з найменшим маршрутом AS до місця призначення. Як ви вже говорили, ви можете видалити HSRP і просто розмістити маршрут за замовчуванням в OSPF та запустити iBGP між двома крайовими маршрутизаторами.

Крок 2 ;

Налаштуйте AS наперед і спільноти тощо на двох крайових маршрутизаторах, щоб контролювати вихідний трафік по мірі необхідності. Таким чином, ISP B може мати кращий маршрут до якоїсь підмережі, але ви можете придбати більше транзиту від ISP A, а скоріше, коли через них, і так далі.

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

Почніть просто, а потім додайте складності лише за потреби. Я б запитав, чи є навіть необхідність запускати OSPF на ваших крайових маршрутизаторах Інтернету. Завантажте PBR до бордюру та використовуйте лише у внутрішній мережі.

1. Візьміть повні маршрути в Інтернеті, якщо ваш маршрутизатор має пам'ять, але фільтруйте! Кинути що-небудь gt a / 24.
2. Пройдіть за замовчуванням маршрут від A і B.
3. Потрібно запустити iBGP, щоб маршрутизатори могли приймати рішення щодо найкращого шляху, враховуючи всі префікси, отримані від A і B.
4. Якщо ви плануєте використовувати як A, так і B / 24s з обома постачальниками, то ви можете краще впливати на вхідний трафік, додавши A / 24 в мережу B і навпаки. Обоє / 24 повинні бути рекламовані! Зверніться до свого Інтернет-провайдера щодо їх спільнот, щоб встановити претендії для вас.
5. Використовуйте дві різні групи HSRP для вихідного трафіку з брандмауера; ви можете налаштувати ECLB для завантаження спільного доступу до двох ваших маршрутизаторів. Збалансування навантаження за рівними витратами .

Все це може бути спрощено, якщо ви просто використовуєте один / 24, рекламований як для A, так і для B.

Пізніше слід розглянути більш складні питання для кращої інженерії та захисту дорожнього руху:

1. Ознайомтеся з спільнотами A і B, оскільки, можливо, ви бажаєте використовувати однорангові карти маршрутів, щоб встановити localpref, щоб визначити, які маршрути використовують A та B.

2. Встановіть плаваючий статичний маршрут за замовчуванням на обох маршрутизаторах як аварійне резервне копіювання для всього іншого, якщо ваш BGP вибухне.

   ip route 0.0.0.0 0.0.0.0 a.b.c.d 254
   

3. Розгляньте більш складні способи реклами для управління вхідною політикою, наприклад, половина вашого ІР-простору, що проходить через A, а друга половина через B. Для даного / 24 ви можете рекламувати / 24 на A і B, але розділити його на два / 25-х та рекламують нижній / 25-A та верхній / 25-B.

4. Використовуйте програмне перенастроювання, щоб ви могли налаштувати свою політику і зробити плавне скидання на сеансі BGP, щоб не викликати затухання ваших префіксів з іншого боку, якщо повністю скинути (або очистити) сеанс. Зміни в політиці потребують перезавантаження.

Тож, що я розумію з написання, - це те, що вам насправді не потрібно приймати рішення, засновані на шляхах AS, щоб дістатися до зовнішніх підмереж, і єдиною метою подвійного підключення до двох провайдерів є придбання надмірності для доступу до Інтернету. Якщо це так, то вам не потрібно запускати BGP. Ви можете просто прийняти ті самі маршрути за замовчуванням, які ви вже отримуєте від свого постачальника послуг. Тепер для локальної сторони мережі запустіть єдину область ospf на маршрутизаторах, які підключаються до Інтернет-провайдера в інтерфейсі, зверненому до вашої локальної мережі (не включайте інтерфейс ISP в процес) і залежно від того, наскільки простий повинен бути дизайн. Ви можете додавати маршрутизатори в різних областях і підсумовувати підмережі за межами мережі, але для двох підмереж я думаю, що розмір бази даних OSPF або кількість затоплених LSA не викликає великого занепокоєння,

На кожному маршрутизаторі OSPF, який підключається до ISP, перерозподіліть вивчені маршрути за замовчуванням в OSPF, використовуючи оператор "джерело інформації за замовчуванням".

Пара переваг:

1. Завдяки такому дизайну, коли ви розвиваєте мережу, ви можете включити BGP з постачальниками послуг та просто прийняти маршрут за замовчуванням, не торкаючись нічого пристроїв нижче. Поки ви не переконаєтеся, що отримуєте маршрут за замовчуванням від BGP, ви добре.

2. Кожного разу, коли вам потрібно буде маршрутизувати трафік провайдера для обслуговування, просто видаліть "вихідну інформацію за замовчуванням" з-під процесу OSPF на цьому маршрутизаторі та продовжуйте обслуговування. Більше нічого не потрібно.

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

Якщо повна таблиця BGP для вас занадто велика, я думаю, ви могли б розглянути можливість отримання порції. Можливо, провайдери A і B рекламують маршрут за замовчуванням та їх локальні маршрути AS. Вам потрібно запустити iBGP внутрішньо. Таким чином, у вас був би найкоротший маршрут для будь-якого, що безпосередньо пов'язаний з провайдерами, і ви взяли б або для нижчих AS маршрутів.