Сколько VLAN слишком мало и слишком много?


23

В настоящее время мы работаем с сетью из 800+ ПК и более 20 серверов, сетевая инфраструктура аналогична Core Switch 10Gb-> Area Switch 2GB-> Local Switch 1GB-> Desktop. Все работающее оборудование 3Com (1).

У нас есть 3 переключателя зоны для четырех областей (A, B, C, D объединены с ядром), к каждому коммутатору зоны будет подключено от 10 до 20 локальных переключателей. Существует также резервный основной коммутатор, с меньшим питанием, но подключенный как основной основной коммутатор.

У нас также есть система IP-телефонии. Компьютеры / серверы и коммутаторы находятся в диапазоне ip 10.x, телефоны в диапазоне 192.168.x. Обычно компьютерам не нужно общаться друг с другом, кроме как в компьютерных классах, но им нужно иметь возможность общаться с большинством наших серверов (AD, DNS, Exchange, хранилище файлов и т. Д.).

Когда мы настраивали, было решено, что у нас будет 3 VLAN, одна для коммутаторов и компьютеров, одна для телефонов и одна для репликации серверов (это противоречило советам инженеров 3Com). С этого момента сеть стабильна и работает (2), но теперь мы начали обновление до среды SAN и виртуализации. Теперь имеет смысл разделить эту новую инфраструктуру на отдельные виртуальные локальные сети, и разумно взглянуть на настройку наших виртуальных локальных сетей.

В настоящее время предлагается, чтобы виртуальные локальные сети устанавливались в каждой комнате, то есть компьютерная лаборатория с 5+ ПК должна быть собственной собственной виртуальной локальной сетью, но если мы будем следовать этой модели, мы будем рассматривать по крайней мере 25 "новых" виртуальных сетей. плюс VLANS для SAN / виртуальных серверов. Что, мне кажется, добавит чрезмерного количества администрации, хотя я вполне рад, что оказался неправ.

Что, по-видимому, может предложить наилучшая практика? Есть ли определенное количество ПК, которые желательно не перебирать / опускать в VLAN.

(1) Коммутаторы 3Com (3870 и 8800) маршрутизируют между виртуальными локальными сетями иначе, чем это делают некоторые другие, для этого не требуется отдельный маршрутизатор, поскольку они являются layer3.

(2) Иногда мы получаем высокие показатели сброса или изменения STP, и время от времени 3Com Network Director сообщает, что коммутаторы недогружены и медленно реагируют на пинг, или произошел сбой коммутатора, которому удается отключить сеть (все телефоны и компьютеры VLANS! некогда не знаю почему)

Ответы:


36

Похоже, что кто-то в вашей организации хочет создать 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.)


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

2

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


На данный момент мы работаем с XP без WINS - выполнение команды nbtstat -r, по-видимому, говорит о том, что мы получаем объем широковещательного трафика.
ванны

1
Измерьте это чем-то вроде Wireshark и посмотрите, что происходит. ПОБЕДЫ не ужасная вещь. Если вы обнаружите, что вы получаете много запросов на поиск имен NetBIOS, либо попробуйте ввести правильные имена в DNS для предотвращения запросов, либо просто запустите WINS.
Эван Андерсон

2

VLAN хороши как дополнительный уровень безопасности. Я не знаю, как 3Com справляется с этим, но обычно вы можете разделить разные функциональные группы на разные VLAN (например, Accounting, WLAN и т. Д.). Затем вы можете контролировать, кто имеет доступ к определенной VLAN.

Я не верю, что существует значительная потеря производительности, если в одной VLAN много компьютеров. Я считаю нецелесообразным сегментировать LAN в каждой комнате, но опять же, я не знаю, как 3Com справляется с этим. Обычно это не размер, а безопасность или эксплуатация.

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


1

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

Очевидно, что вашей SAN нужна собственная VLAN, а не та же VLAN, что и для виртуальных систем LAN и доступа в Интернет! Все это можно сделать через один порт Ethernet в хост-системе, поэтому не стоит беспокоиться о разделении этих функций.

Если у вас есть проблемы с производительностью, рассмотрите возможность установки телефона и SAN на отдельное сетевое оборудование, а не только на VLAN.


0

Всегда будет широковещательный трафик, будь то трансляции с разрешением имен, трансляции ARP и т. Д. Важно следить за объемом широковещательного трафика. Если он превышает 3–5% от общего трафика, то это проблема.

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


Я был с вами до тех пор, пока вы не упомянули о маршрутизации. Маршрутизация сопряжена с большими затратами, но обычно оборудование, которое выполняет L2 / L3, будет пересылать пакеты из одного vlan в другой (и с одного порта на другой) с той же скоростью, как если бы оно пересылалось через L2.
Крис

Правда, в оригинальном посте я не уловил информацию о том, что коммутаторы 3COM могут маршрутизировать трафик между VLAN без использования маршрутизаторов (поэтому я предполагаю, что это коммутаторы L3). Спасибо.
Joeqwerty

Они могут работать на скорости передачи данных, но они по-прежнему являются маршрутизаторами для настройки и управления, даже если они всего лишь объекты уровня 3 внутри коммутаторов. Если они «переключают» пакеты на уровне 3, они являются маршрутизаторами.
Эван Андерсон

0

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

Домены широковещательной рассылки обычно могут иметь размер около 1000 устройств, прежде чем вы начнете видеть проблемы в 100-мегабитных сетях, хотя я бы довел это до 250 устройств, если вы имеете дело с относительно шумными областями Windows.

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


1
Они полезны для сохранения самородка в учете при настройке веб-камеры с IP-адресом почтового сервера ...
chris

0

Они также полезны для предотвращения широковещательных рассылок DHCP для нежелательных сетевых устройств.


1
Снижение проблем с производительностью уже упоминалось, спасибо.
Крис С
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.