Назад | Перейти на главную страницу

подключение удаленного сайта через оптоволокно: виртуальные локальные сети уровня 2 или маршрутизация уровня 3?

Приветствую всех,

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

Теперь у нас есть жгут волокон между двумя географически разделенными участками. Это наше собственное «принадлежащее» волокно, поэтому посредник не беспокоит. Тестирование показывает, что пакет без проблем может обрабатывать многогигабайтный трафик. Кроме того, оптоволоконное кольцо имеет несколько избыточностей, включая отдельные физические пути. Все хорошо.

Учитывая это, считается ли по-прежнему «лучшей практикой» использовать маршрутизацию и разные подсети между удаленными сайтами? Или мы можем расширить нашу «локальную» (основную) сеть до удаленного сайта вместе с виртуальными локальными сетями основного сайта? Это все еще считается неоптимальной или даже плохой практикой? Более того, есть ли причина не делать этого? (Кроме того, я понимаю проблему «прерывания экскаватора-погрузчика»; ожидается, что отдельные физические пути справятся с этой непредвиденной ситуацией).

Другие мысли?

Спасибо!

Теперь у нас есть жгут волокон между двумя географически разделенными участками. Это наше собственное «принадлежащее» волокно, поэтому посредник не является проблемой ... Кроме того, в волоконно-оптическом кольце предусмотрено несколько избыточностей, включая отдельные физические пути. Все хорошо.

Учитывая это, считается ли по-прежнему «лучшей практикой» использование маршрутизации и разных подсетей между удаленными сайтами? Или мы можем расширить нашу «локальную» (основную) сеть до удаленного сайта вместе с виртуальными локальными сетями основного сайта? Это все еще считается неоптимальной или даже плохой практикой? Более того, есть ли причина не делать этого? (Кроме того, я понимаю проблему «прерывания экскаватора-погрузчика»; ожидается, что отдельные физические пути справятся с этой непредвиденной ситуацией).

Во-первых, в этой ситуации не существует лучшей практики. Общие детали дизайна, такие как взаимосвязи сайтов на уровне 2/3, определяются бизнес-потребностями, бюджетом, возможностями вашего персонала, вашими предпочтениями и наборами функций вашего поставщика.

Даже при всей любви к перемещению экземпляров виртуальных машин между центрами обработки данных (что намного проще с межсоединениями уровня 2 между центрами обработки данных), я лично все еще пытаюсь соединять здания на уровне 3, потому что ссылки уровня 3 обычно означают:

  1. Более низкие эксплуатационные расходы и меньшее время до решения проблемы. Подавляющее большинство диагностики сетевых неисправностей основано на IP-сервисах. Например, mtr имеет видимость только на уровне 3. Таким образом, переходы уровня 3 намного легче исправить, когда вы обнаруживаете отбрасывание пакетов из-за перегрузки или ошибок в каналах. Layer3 также легче диагностировать, когда вы имеете дело с проблемами многолучевого распространения (по сравнению, например, с многолучевым распространением, отличным от уровня 3, таким как LACP). Наконец, гораздо проще найти сервер или компьютер, если вы можете трассировать маршрут прямо к пограничному коммутатору.

  2. Меньшие домены широковещательной / лавинной рассылки. Если у вас есть несовпадающие таймеры ARP / CAM, вы уязвимы для неизвестного одноадресного флуда. Исправление для этого хорошо известно, но большинство сетей, которые я вижу, никогда не беспокоятся о правильном сопоставлении таймеров ARP и CAM. Конечный результат? Больше всплесков трафика и наводнений внутри домена Layer2 ... и если вы наводняете ссылки между зданиями Layer2, вы наводняете естественные точки перегрузки сети.

  3. Легче развернуть брандмауэры / ACL / QoS ... все это жестяная банка работают на уровне 2, но они, как правило, лучше работают на уровне 3 (потому что поставщики / органы по стандартизации потратили не менее 15 из предыдущих 20 лет на создание наборов функций поставщиков, предпочитающих уровень 3).

  4. Меньше остовного дерева. MSTP / RSTP сделали связующее дерево гораздо более переносимым, но все разновидности STP по-прежнему сводятся к тому неприятному протоколу, который любит лавинно рассылать широковещательные рассылки в неправильном направлении, когда вы отбрасываете BPDU на ссылку, блокирующую STP. Когда это может случиться? Сильная перегрузка, ненадежные приемопередатчики, однонаправленные ссылки (по какой-либо причине, в том числе из-за человека) или ссылки, которые работают с ошибками.

Означает ли это, что размещать слой 2 между зданиями - это плохо? Вовсе нет ... это действительно зависит от вашей ситуации / бюджета / предпочтений персонала. Тем не менее, я бы выбрал ссылки на layer3, если нет веских причин.1 Эти причины могут включать религиозные предпочтения вашего персонала / менеджера, более низкое знакомство с конфигурациями уровня 3 и т. Д.


1For anyone wondering how I handle layer2 data center interconnections when there are layer3 links between the datacenters, I prefer EoMPLS pseudowires if there is no Nexus gear. Theoretically OTV seems like a candidate if I had Nexus, but I personally haven't been there yet. Bottom line, there are solutions for tunneling Layer2 through Layer3 when you have to.

Это довольно сложно, поскольку у обоих подходов есть свои преимущества и недостатки. В моей предыдущей жизни, когда в мои должностные обязанности входило гораздо больше сетевого администрирования, а не системного администрирования, у нас было около двух десятков сайтов в пределах 12-мильной географической области. Около половины этих сайтов были настроены как отдельные сайты уровня 3, которые были маршрутизированы обратно в главный офис, а другая половина была настроена как сайты уровня 2 (т.е. мы просто расширили VLAN до этого сайта).

Преимущества сайтов «Уровня-2» заключались в том, что их было намного проще настраивать и поддерживать; Никаких маршрутизаторов, никаких обновлений наших статических маршрутов, никакого DHCP-ретранслятора, никакой отдельной конфигурации VLAN и так далее. Основные недостатки, с которыми я столкнулся, были нетехническими, например, когда ваш домен вещания находится в 12 разных зданиях на расстоянии нескольких миль друг от друга, гораздо сложнее найти мошеннический DHCP-сервер. Многие административные задачи становятся более сложными, когда вам не хватает разделения сети на разные сайты. Такие вещи, как разные правила брандмауэра для Office A и Office B, но не для Office C, становятся сложными, когда все они используют одну и ту же VLAN / подсеть. Я полагаю, вы также можете столкнуться с проблемой с широковещательными рассылками, в зависимости от того, сколько устройств у вас есть, но с сегодняшней технологией коммутации вы можете втиснуть удивительное количество хостов в широковещательный домен, прежде чем это действительно станет проблемой.

Преимущества сайтов "Layer-3" почти противоположны сайтам "Layer-2". Вы получаете разделение, вы можете писать правила брандмауэра для каждого сайта и знаете, в каком именно здании находится этот чертов маршрутизатор Linksys. Недостатки, очевидно, заключаются в оборудовании, необходимом для выполнения маршрутизации, а также в необходимой конфигурации и обслуживании. Протоколы динамической маршрутизации и такие вещи, как VTP (если вы осмелитесь его использовать!), Могут облегчить бремя настройки, если ваша сеть достаточно сложна.

Мой ответ без ответа: не разделяйте без необходимости (то есть не поддавайтесь искушению быть чрезмерно умным), но не позволяйте краткосрочному простому решению победить там, где имеет смысл иметь отдельные VLAN / подсети. Как человек, преследовавший мою долю Rogue DHCP-серверов Linksys ... э-э "Маршрутизаторы" ... я думаю, что есть веские основания для одной VLAN / подсети на проект сети здания, просто чтобы ограничить ущерб, который они неправильная конфигурация сможет сделать. С другой стороны, если у вас всего два сайта, и они находятся по соседству, возможно, им имеет смысл использовать одну и ту же VLAN / подсеть.

Как многие говорили, как у L2, так и у L3-решения есть хорошие и менее хорошие стороны. Раньше я работал в телефонной компании и помогал запускать небольшие сети.

L2-решения проще понять и дешевле, если все работает. Заводская часть обычно разрушается, если кто-то повторно подключает кабель, который, по их мнению, был случайно отключен. Защита от петель и связующее дерево могут быть полезны, но, скорее всего, принесут больше вреда, чем пользы.

L3-решения, по моему опыту, было труднее понять сторонам, которым я помогал. Стоимость также может стать проблемой, если оборудование и программное обеспечение должны поддерживаться производителем. Linux на машине x86 - очень рентабельный и многофункциональный маршрутизатор.

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

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

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

Думаю, маршрутизация - лучший выбор. Вся ваша сеть выйдет из строя, если будет повреждено волокно. И маршрутизация с коммутаторами уровня 3 (коммутация уровня 3) выполняется быстро, как переключение уровня 2, если вы используете CEF или что-то в этом роде.