Чи має сенс розміщувати OSPF через Metro Ethernet?

Коли мені потрібно підключити кілька клієнтських сайтів один до одного для клієнта, я зазвичай рекомендую MPLS VPN через надійного оператора. CE на кожному майданчику розмовляє BGP зі своїм ПЕ, і кожен сайт має нумерований власний приватний ASN. Це дуже зручно для нас, оскільки BGP надає безліч інструментів інженерії трафіку, а наші суміжності обмежені n + 1 для n сайтів (+1 - це наше коло-середовище).

Однак останнім часом я помітив зростання інтересу клієнтів до рішень Metro Ethernet. Багато наших клієнтів мають відділення в межах загальної метрополітену, і котирування MetroE надходять на кілька сотень доларів (USD) менше, ніж послуга MPLS для схем однакової швидкості. Незважаючи на те, що це привабливо, я не впевнений, як найкраще встановити маршрутизацію по магістралі шару двох, уникаючи перетворення сітчастої топології на вузол з розмовою.

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

Це має сенс? Чи є якісь застереження, на які слід звертати увагу при розгортанні OSPF таким чином (наприклад, чи варто розглянути можливість вимкнення затоплення LSA)? Або є інше рішення, яке я не помітив?

Це своєрідне складне питання, оскільки два різних вироби дуже різні. Схема MPLS L3VPN по суті є повною сіткою між усіма локаціями, які беруть участь, тоді як з'єднання MetroE, як правило, пов'язує точки до точки між двома конкретними сайтами.

На мій досвід, схема MetroE - це безпосередньо передбачений шлях, без служб захисту, якщо не укладено контракт із захисним шляхом. Це означає, що відмова інтерфейсу або маршрутизатора по певному шляху буде переривати трафік між двома сайтами, які безпосередньо пов'язані сервісом MetroE. MPLS L3VPN заживе навколо відмов інтерфейсу / маршрутизації, щоб зберегти повну сітку між вашими сайтами. Зазвичай це різниця в ціні між ними.

Немає нічого поганого в створенні власних служб на платформі MetroE - вам просто потрібно працювати з вимогами замовника, щоб визначити, який тип маршрутизації підходить. Якщо ви працюєте з невеликою офісною мережею, OSPF / IS-IS / EIGRP може стати прекрасним способом обміну інформацією про маршрутизацію між створеними вами безпосередньо підключеними сайтами. Якщо ви більше NSP / ISP / * SP, розділення інфраструктури та клієнтських маршрутів між IGP та EGP стає набагато важливішим за масштабом.

Як інженер провайдерів, ми широко використовуємо посилання MetroE та EWAN для створення нашої основи та використовуємо наші знання про фізичні посилання для розробки нашого середовища iBGP / eBGP. У багатьох випадках ми використовуємо відбивачі маршрутів та подвійні відбивачі маршруту (маршрут-рефлектор-клієнт з обох сторін пірингу), щоб зменшити кількість однорангових iBGP. Однак, якщо ви не маєте справу з 6+ маршрутизаторами в POP, iBGP масштабує досить добре.

Якщо коротко - якщо це для одного клієнта, який не пропонує мережевих послуг власним клієнтам - дотримуйтесь IGP. Якщо зовнішнє підключення потрібно ділити між сайтами, з відмовою / надлишком / тощо, уважно вивчіть фізичні шляхи, які ви маєте, та спроектуйте свій eBGP / iBGP, щоб це відобразило. Немає сенсу мати маршрутизатор у віддаленому місці із лише 1 посиланням за межами сайту до однорангового iBGP з усіма іншими маршрутизаторами в AS - використовуйте подвійний маршрутизатор.

Перехід від керованого L3VPN (що я вважаю, що ви мали на увазі "MPLS VPN") на L2VPN - хороший крок у тому, що ви можете запускати протоколи, що не стосуються IP, та отримувати повний контроль над протоколами маршрутизації та платформами маршрутизації, які визначають вашу маршрутизацію топологія.

Якщо припустити, що ви розміщуєте лише одну MAC-адресу Ethernet на CPE-стороні кожного з ваших сайтів, обладнання провайдера набагато простіше вивчати та пересилати 1 MAC-адреси на кожен сайт, ніж вивчати та маршрутизувати потенційно-багато підмереж на сайт.

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

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

Якщо у вас не дуже багато сайтів або внутрішніх префіксів, протокол стану зв'язку, наприклад OSPF або IS-IS, має найбільш сенс, оскільки він швидко сходиться і може швидко створити FIB з RIB, якщо є лише кілька префіксів .

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

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

У такому випадку я рекомендую використовувати BGP з деякими відбивачами маршруту. Таким чином, ви можете надати 2+ важких маршрутизаторів-рефлекторів, про які оголошують спиці, і для яких інші спиці можуть захопити таблицю маршрутизації. Таким чином, ви можете розгорнути легкі CPE на ваших сайтах з багатьма спікерами, які просто підключаються, оголошують простір і отримують внутрішню таблицю або маршрут за замовчуванням до маршрутизатора, який це робить.

Приблизно, я б запропонував декілька масштабів і передач (і припускаючи пробіги на низьких гігабітах):

• 1 - 20 спиць - OSPFv3 між усіма сайтами. Ялівець SRX240 або подібний для всіх сайтів.
• 20 - 100 спиць - iBGP з маршрутичними відбивачами. Ялівець SRX240 на спиці, Juniper MX5 / 10/40/80 для відображення маршруту (або Debian Linux / BIRD).
• 100 - 500 спиць - Почніть розбивати їх на різні мережі L2, ASes або області

Просто додайте до обговорення BGP два часто переглянуті біти:

• Якщо ви запускаєте iBGP, вам зазвичай потрібен інший протокол маршрутизації, щоб встановити зв'язок між наступними пересказами BGP. З точки зору дизайну, iBGP - це більше інструмент масштабування, ніж протокол маршрутизації;
• Якщо ви запускаєте eBGP, вам не потрібна повна сітка сеансів BGP для оптимальних потоків трафіку в кінці; Наступна обробка хмелю BGP чудово вирішує ці питання.

Докладніші відомості див. На веб-сторінці http://blog.ioshints.info/2011/08/bgp-next-hop-processing.html

Ви можете дуже добре запустити OSPF (або інший IGP) на багатоточковому метро-Ethernet-сервісі, і це має працювати дуже добре.

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

Вам не обов'язково розміщувати всі ваші динаміки BGP в одному AS в такій "широкомовної" мережі. Подумайте про це як про якийсь внутрішній IXP, керований телекомом, де ваші приватні АС можуть з'єднуватися між собою через шар 2-х сіток. Вам навіть не доведеться обов'язково підтримувати повну сітку пирінгів BGP, оскільки оновлення BGP можуть містити наступний скачок у своєму повідомленні про оновлення, що не є таким, звідки надходить сеанс однорангових програм.

Наприклад, якщо у вас є сітка 2-го рівня з маршрутизаторами A, B і C на ній, і у вас є однорангові BGP між A і B, і між B і C, коли C отримує оновлення для маршрутів, що виникли в A, це буде мати A як наступний скачок, навіть якщо вони були вивчені під час сеансу "peering" з B. Очевидно, ви хочете отримати більше пирінгу маршруту, ніж просто один хаб і говорив, так що ви не залежні від одного центру, але ви не потрібно повноцінна сітка будь-якими способами.

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

Попри це, у мене є декілька посилань на метро-E (в моєму випадку "точка-точка"), що я запускаю OSPF та iBGP, і це працює чудово.

А як щодо конфігурації маршруту-сервера з "спицями", що ведуть rs-клієнтів концентратора / основних маршрутизаторів?

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

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

Я настійно рекомендую ознайомитись і прийняти рішення щодо альтернативних топологій OSPF, таких як запуск як NBMA замість стандартних. Ви незабаром зрозумієте, що OSPF не може правильно вибрати між двома шляхами, що йдуть до того ж маршрутизатора / сайту в межах одного метрополітену, через те, що вартість розраховується через вихідний інтерфейс, і основні, і резервні посилання WAN будуть виглядати однаковими вартість в стандартному OSPF. Однак якщо ви вирішили використовувати NBMA, наприклад, ви можете вручну визначити витрати сусідів - але тепер вам доведеться вручну визначити сітку / суміжності.

Що б ви не робили, НЕ ПОВТОРЮЙТЕ НЕ ПОВТОРЮЙТЕ НЕ ПРИЄДНАЙТЕСЬ НА 2 РОЗВИТКУ, ви просто просите проблеми пізніше, якщо вам потрібен взаємозв'язок рівня 2, використовуйте функцію OTV або інший шар 2 над шаром 3.

Ви швидко дізнаєтесь, що дізнаєтесь набагато більше про OSPF (і потрібно знати набагато більше), ніж порівняно з простим провайдером MPLS-VPN, де ядро ​​WAN приховано від вас.

OSPF над метро працює чудово, але вам потрібно переконатися, що він відповідає вашим потребам, і ви архітектор відповідно. Одне застереження, якого я не бачив, - це переконатися, що ви знаєте, що підтримує ваш провайдер MTU. Я бачив перепад MTU на посилання metroE під час обслуговування провайдера, через що сусід OSPF не з'являється. Напевно, лише проблема, оскільки вони насправді не підтримують джамбо-кадри, але вони зробили саме для нас :) Бути приємним часом не окупається.