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

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

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

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

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

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

Благодарность!

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

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

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

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

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

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

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

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

Значит ли это, что развертывание layer2 между зданиями плохо? Вовсе нет ... это действительно зависит от вашей ситуации / бюджета / предпочтений персонала. Тем не менее, я бы пошел со ссылками layer3, если нет веской причины иначе. ¹ К таким причинам могут относиться религиозные предпочтения вашего персонала / mgmt, меньшая осведомленность о конфигах layer3 и т. Д.

---

¹ Для всех, кто интересуется, как я обращаюсь с соединениями центров обработки данных уровня 2, когда между центрами обработки данных существуют связи уровня 3, я предпочитаю псевдопроводы EoMPLS, если нет механизма Nexus. Теоретически OTV выглядит как кандидат, если бы у меня был Nexus, но лично я там еще не был. В итоге, есть решения для туннелирования от Layer2 до Layer3, когда это необходимо.

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

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

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

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

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

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

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

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

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

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

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