Похоже, что кто-то в вашей организации хочет создать VLAN без понимания причин, почему вы это делаете, и плюсов / минусов, связанных с ними. Похоже, вам нужно провести какое-то измерение и придумать реальные причины сделать это, прежде чем двигаться вперед, по крайней мере с безумной глупостью «VLAN для комнаты».
Вы не должны начинать разбивать локальную сеть Ethernet на VLAN, если у вас нет веских причин для этого. Две лучшие причины:
Смягчение проблем с производительностью. Локальные сети Ethernet не могут масштабироваться бесконечно. Чрезмерное вещание или переполнение кадров в неизвестные места назначения ограничат их масштаб. Любое из этих условий может быть вызвано слишком большим одиночным широковещательным доменом в локальной сети Ethernet. Широковещательный трафик легко понять, но затопление кадров в неизвестные места назначения немного более неясно ( настолько, что ни один из постеров здесь даже не упоминает об этом!). Если вы получаете так много устройств, что ваши таблицы MAC коммутатора переполнены, коммутаторы будут вынуждены заполнять не широковещательные кадры по всем портам, если назначение кадра не соответствует ни одной записи в таблице MAC. Если у вас достаточно большой один широковещательный домен в локальной сети Ethernet с профилем трафика, на котором хосты общаются редко (то есть достаточно редко, чтобы их записи устарели из таблиц MAC на коммутаторах), вы также можете получить чрезмерное переполнение кадров. ,
Желание ограничить / контролировать трафик, перемещающийся между хостами на уровне 3 или выше. Вы можете провести некоторую хакерскую проверку трафика на уровне 2 (например, в Linux ebtables), но это сложно управлять (поскольку правила привязаны к MAC-адресам, а изменение сетевых карт требует изменений правил), что может привести к действительно странному поведению (выполнение Прозрачное проксирование HTTP на уровне 2, например, странно и забавно, но совершенно неестественно и может быть очень не интуитивно понятным для устранения неполадок), и, как правило, это трудно сделать на более низких уровнях (потому что инструменты уровня 2 подобны ручкам и раскачивается при решении проблем уровня 3+). Если вы хотите контролировать трафик IP (или TCP, или UDP и т. Д.) Между хостами, а не атаковать проблему на уровне 2, вам следует подсеть и прикрепить межсетевые экраны / маршрутизаторы с ACL между подсетями.
Проблемы исчерпания полосы пропускания (если они не вызваны широковещательными пакетами или переполнением кадров) обычно не решаются с помощью VLAN. Они происходят из-за отсутствия физического подключения (слишком мало сетевых адаптеров на сервере, слишком мало портов в группе агрегации, необходимость перехода на более высокую скорость портов) и не могут быть решены с помощью подсетей или развертывания VLAN, поскольку это Не увеличивайте количество доступной полосы пропускания.
Если у вас даже нет чего-то простого, например, MRTG, выполняющего построение графиков статистики трафика по портам на ваших коммутаторах, это действительно ваш первый заказ, прежде чем вы начнете вводить узкие места с благонамеренной, но неинформированной сегментацией VLAN. Необработанные подсчеты байтов - хорошее начало, но вы должны следить за этим, чтобы получить более подробную информацию о профилях трафика.
Как только вы узнаете, как движется трафик в вашей локальной сети, вы можете начать думать о сегментации локальной сети по соображениям производительности.
Если вы действительно хотите попробовать и переключить доступ на уровне пакетов и потоков между виртуальными локальными сетями, будьте готовы проделать большую работу с прикладным программным обеспечением и изучить / проанализировать, как он общается по проводам. Ограничение доступа хостов к серверам часто может быть достигнуто с помощью функции фильтрации на серверах. Ограничение доступа по проводам может дать ложное чувство безопасности и утешить администраторов в самодовольство, когда они думают: «Мне не нужно настраивать приложение безопасно, потому что хосты, которые могут общаться с приложением, ограничены». сеть».» Я бы посоветовал вам проверить безопасность конфигурации вашего сервера, прежде чем я начну ограничивать обмен данными между хостами по проводам.
Обычно вы создаете VLAN в Ethernet и сопоставляете IP-подсети 1-к-1 на них. Вы будете нуждаться в ЛО в IP - подсетей для того, что вы описываете, и , возможно , много маршрутизации записей таблицы. Лучше спланируйте эти подсети с помощью VLSM, чтобы суммировать записи таблицы маршрутизации, а?
(Да, да - есть способы не использовать отдельную подсеть для каждой VLAN, но придерживаясь строго «простого ванильного» мира, вы создадите VLAN, придумаете IP-подсеть для использования в VLAN, назначьте некоторый маршрутизатор IP-адрес в этой VLAN, подключите этот маршрутизатор к VLAN с помощью физического интерфейса или виртуального подчиненного интерфейса на маршрутизаторе, подключите некоторые хосты к VLAN и назначьте им IP-адреса в определенной вами подсети, а также направьте их трафик и вне VLAN.)
VLAN действительно полезны только для ограничения широковещательного трафика. Если что-то собирается делать много вещания, то выделите это в свою собственную VLAN, иначе я бы не стал беспокоиться. Возможно, вы захотите иметь виртуализированное дублирование работающей системы в той же сети и захотите использовать тот же диапазон адресов, и опять же, это может стоить отдельной VLAN.
источник
VLAN хороши как дополнительный уровень безопасности. Я не знаю, как 3Com справляется с этим, но обычно вы можете разделить разные функциональные группы на разные VLAN (например, Accounting, WLAN и т. Д.). Затем вы можете контролировать, кто имеет доступ к определенной VLAN.
Я не верю, что существует значительная потеря производительности, если в одной VLAN много компьютеров. Я считаю нецелесообразным сегментировать LAN в каждой комнате, но опять же, я не знаю, как 3Com справляется с этим. Обычно это не размер, а безопасность или эксплуатация.
По сути, я не вижу никакой причины даже сегментировать LAN на разные VLAN, если нет безопасности или эксплуатационных выгод.
источник
Если у вас нет 25 групп тестирования и разработки, которые регулярно убивают сеть из-за широковещательных потоков, 25 виртуальных локальных сетей на каждую комнату - это слишком много.
Очевидно, что вашей SAN нужна собственная VLAN, а не та же VLAN, что и для виртуальных систем LAN и доступа в Интернет! Все это можно сделать через один порт Ethernet в хост-системе, поэтому не стоит беспокоиться о разделении этих функций.
Если у вас есть проблемы с производительностью, рассмотрите возможность установки телефона и SAN на отдельное сетевое оборудование, а не только на VLAN.
источник
Всегда будет широковещательный трафик, будь то трансляции с разрешением имен, трансляции ARP и т. Д. Важно следить за объемом широковещательного трафика. Если он превышает 3–5% от общего трафика, то это проблема.
VLAN хороши для уменьшения размера широковещательных доменов (как сказал Дэвид) или для обеспечения безопасности, или для создания выделенных сетей резервного копирования. Они не предназначены для управления доменами. Кроме того, вы добавите сложность маршрутизации и накладные расходы в вашу сеть, внедрив VLAN.
источник
Как правило, вы хотите использовать VLAN только в тех случаях, когда вам нужно помещать устройства в карантин (например, область, в которую пользователи могут вносить свои собственные ноутбуки, или когда у вас есть критически важная инфраструктура сервера, которая должна быть защищена) или если ваш широковещательный домен слишком высоко.
Домены широковещательной рассылки обычно могут иметь размер около 1000 устройств, прежде чем вы начнете видеть проблемы в 100-мегабитных сетях, хотя я бы довел это до 250 устройств, если вы имеете дело с относительно шумными областями Windows.
По большей части современные сети не нуждаются в VLAN, если вы не делаете этот карантин (с соответствующим межсетевым экраном, конечно, используя ACL) или широковещательные ограничения.
источник
Они также полезны для предотвращения широковещательных рассылок DHCP для нежелательных сетевых устройств.
источник