Имеет ли смысл развертывать OSPF через Metro Ethernet?

Когда мне нужно подключить несколько филиалов друг к другу для клиента, я обычно рекомендую MPLS VPN через доверенную несущую. CE на каждом сайте говорит BGP с его восходящим PE, и каждый сайт пронумерован собственным ASN. Это очень удобно для нас, поскольку BGP предоставляет множество инструментов для управления трафиком, а наши смежности ограничены n + 1 для n сайтов (+1 - наша среда colo).

В последнее время, однако, я заметил растущий интерес клиентов к решениям Metro Ethernet. Многие из наших клиентов имеют филиалы в общей зоне метро, ​​а котировки MetroE поступают на несколько сотен долларов (USD) меньше, чем у MPLS для схем с одинаковой скоростью. Хотя это привлекательно, я не уверен, как наилучшим образом установить маршрутизацию между двумя магистральными магистралями, избегая при этом превращения топологии сетки в hub-and-spoke.

BGP потребовал бы полной сетки смежностей между сайтами филиалов, чтобы поддерживать связь в сетке, что, очевидно, нежелательно с точки зрения масштабируемости. Другим вариантом является развертывание IGP, а именно OSPF, и все сайты образуют смежности в глобальной сети. Я хотел бы адресовать каждый сайт как свою собственную область, которая кажется излишней, но я хочу сохранить возможность обобщать маршруты, рекламируемые с каждого сайта, и это можно сделать только на границах области.

Это имеет смысл? Существуют ли какие-либо предостережения, которые следует учитывать при развертывании OSPF таким образом (например, следует ли мне отключить наводнение LSA)? Или есть другое решение, которое я забыл?
25 голосов | спросил Jeremy Stretch 8 Mayam13 2013, 02:31:43

7 ответов


12

Это довольно сложный вопрос, поскольку два разных продукта очень разные. Цепочка 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 - используйте рефлектор с двумя маршрутами.

ответил nicotine 8 Mayam13 2013, 02:52:48
9

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

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

По протоколу это немного сложный вопрос для ответа без дополнительной информации, поскольку лучший выбор зависит от ваших планов движения и роста.

Это только один большой клиент, которому нужны внутренние и интернет-соединения, или же он продает возможность подключения? Предполагая, что это все внутреннее, тогда вы просто будете развертывать IGP и, возможно, запускаете некоторый eBGP для объявления путей.

Если у вас очень мало сайтов или внутренних префиксов, протокол состояния ссылки, такой как OSPF или IS-IS, имеет наибольший смысл, поскольку он будет сходиться быстро и может быстро построить FIB из RIB, если есть только несколько префиксов.

Если у вас будет много сайтов или множество префиксов, это начнет взимать налоги с ваших платформ маршрутизации, поскольку каждый из них должен обрабатывать каждый. Это то, что начинает принимать n 2 . Если у вас есть сайты, которые часто появляются вверх и вниз, этот откат в состоянии ссылки также может начать взимать налоги с вашего пула маршрутизаторов.

Если у вас будет много сайтов, множество коротких сайтов (один путь «вверх по течению», ни один другой маршрутизатор нисходящего потока), или много сбоев маршрута, вам нужно будет изучить другие протоколы или топологии.

В таком случае я бы рекомендовал использовать BGP с некоторыми отражателями маршрута. Таким образом, вы можете предоставить 2+ сверхмощные отражатели маршрута, о которых объявляют спицы, и для которых другие спицы могут захватывать таблицу маршрутизации. Таким образом, вы можете развернуть легкие CPE на своих многоязычных сайтах, которые просто подключаются, сообщают о своем пространстве и получают внутреннюю таблицу или маршрут по умолчанию к маршрутизатору, который это делает.

Примерно я бы предложил несколько весов и передач (и предполагал пропускную способность субгигабитов):

  • 1 - 20 спиц - OSPFv3 между всеми сайтами. Juniper SRX240 или аналогичный для всех сайтов.
  • 20 - 100 спиц - iBGP с отражателями маршрута. Juniper SRX240 в спицах, Juniper MX5 /10/40/80 для отражения маршрута (или Debian Linux /BIRD).
  • 100 - 500 спиц - начните разбивать их на разные сети L2, AS или области.
ответил jof 8 Mayam13 2013, 04:06:24
6

Просто добавьте два часто игнорируемых бита в обсуждение BGP:

  • Если вы запустите iBGP, вам обычно нужен другой протокол маршрутизации, чтобы установить соединение между BGP в следующих перелетах. С точки зрения дизайна iBGP является более масштабируемым инструментом, чем протокол маршрутизации;
  • Если вы запустите eBGP, вам не нужна полная сетка сессий BGP для оптимальных сквозных потоков трафика; Обработка BGP следующего хопа прекрасно решает эти проблемы.

См. http://blog.ioshints.info/2011/08/bgp- next-hop-processing.html для более подробной информации

ответил ioshints 9 Maypm13 2013, 17:06:15
4

Вы можете очень хорошо запустить OSPF (или другой IGP) в многоточечном сервисе metro-Ethernet, и он должен работать очень хорошо.

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

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

Так, например, если у вас есть сетка уровня 2 с маршрутизаторами A, B и C на нем, и у вас есть узлы BGP между A и B и между B и C, когда C получает обновления для маршрутов, созданных в A , он будет иметь A в качестве следующего хопа, хотя они были изучены через сеанс пиринга с B. Очевидно, что вам нужно больше пиринга маршрута, чем просто один хаб-спикер, поэтому вы не зависите от единого концентратора , но вам не нужна полная сетка.

Вы по-прежнему получаете все преимущества политики маршрутизации при запуске BGP, если вы это сделаете ... и он также, как сказал еще один ответчик, может использовать одно и то же личное пространство AS-номеров и может даже связываться с существующим L3VPN, поэтому ваша модель и механизмы поддержки не нуждаются в изменении.

Сказав это, у меня есть пара ссылок metro-E (точка-точка в моем случае), что я запускаю OSPF и iBGP, и все работает отлично.

ответил Jeff McAdams 8 Mayam13 2013, 03:46:10
2

Как насчет конфигурации маршрута-сервера с «спицами» для клиентов-концентраторов /главных маршрутизаторов?

Несмотря на то, что peerings bgp будут похожи на топологию hub & спиц, все спицы должны иметь возможность отправлять трафик непосредственно всем остальным.

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

ответил petrus 8 Mayam13 2013, 02:41:19
1

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

Независимо от того, что вы делаете, МАРШРУТ НАД ЭТО НЕ ПОВТОРЯЕТСЯ НЕ ПРИСОЕДИНЯЙТЕСЬ НА СЛОЕ 2, вы просто просите о проблемах позже, если вам нужна взаимосвязь между слоями 2, используйте OTV или другой уровень 2 поверх 3-го уровня.

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

ответил wintermute000 8 Mayam13 2013, 08:52:33
1

OSPF над metroE отлично работает, но вам нужно убедиться, что он соответствует вашим потребностям, и вы архитектор соответственно. Одно из предостережений, о которых я не упоминал, заключается в том, чтобы убедиться, что вы знаете, что поддерживает ваш провайдер MTU. Я видел падение MTU на линии metroE во время обслуживания провайдера, потому что сосед OSPF не появился. Вероятно, это только проблема, потому что они действительно не поддерживают большие рамки, но они сделали именно для нас :) Быть красивым иногда не окупается.

ответил Jay 14 Maypm13 2013, 16:35:32

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132