У нас есть сеть среднего размера, состоящая примерно из 200 узлов, и в настоящее время мы занимаемся заменой старых гирляндных коммутаторов на коммутаторы с возможностью объединения в стек или шасси.
Сейчас наша сеть разбита на подсети: производство, управление, интеллектуальная собственность (IP) и т.д., каждая из которых находится в отдельной подсети. Было бы более выгодным создание VLAN вместо подсетей?
Наша общая цель - предотвратить возникновение узких мест, разделить трафик в целях безопасности и упростить управление трафиком.
VLANs и подсетьs решать разные проблемы. VLAN работают на Слой 2, тем самым изменяя широковещательные домены (например). В то время как подсети Слой 3 в текущем контексте
Одно из предложений - реализовать оба
Имейте, например, VLAN 10-15 для различных типов устройств (Dev, Test, Production, Users и т. Д.)
VLAN 10, у вас может быть подсеть 192.168.54.x / 24 VLAN 11, у вас может быть подсеть 192.168.55.x / 24
И так далее
Для этого потребуется, чтобы в вашей сети был маршрутизатор, хотя
От вас зависит, по какому маршруту вы пойдете (вы знаете свою сеть лучше, чем я когда-либо). Если вы думаете, что размер вашего широковещательного домена будет проблемой, используйте VLAN. Если вы считаете, что размер ваших доменов управления сетью (например, вашей сети управления), возможно, используйте сеть ближе к / 16 из а / 24
Ваши 200 узлов поместятся в / 24, но это, очевидно, не дает вам больших возможностей для роста.
Судя по всему, вы уже используете разные подсети для разных типов устройств. Так почему бы не придерживаться этого? При желании вы можете связать каждую подсеть с VLAN. Сегментация уровня 2 приведет к тому, что поведение вашей сети изменится по сравнению с текущим.
Вам нужно будет изучить потенциальное влияние этого
(Я был в дороге весь день и пропустил прыжок на этом ... Тем не менее, поздно до игры, я посмотрю, что я могу сделать.)
Обычно вы создаете сети VLAN в Ethernet и назначаете им IP-подсети 1 к 1. Есть способы не делать этого, но придерживаясь строго "простого" мира, вы должны создать VLAN, придумать IP-подсеть для использования в VLAN, назначить некоторому маршрутизатору IP-адрес в этой VLAN, подключить этот маршрутизатор к VLAN (либо с физическим интерфейсом, либо с виртуальным подынтерфейсом на маршрутизаторе), подключите некоторые хосты к VLAN и назначьте им IP-адреса в указанной вами подсети и направьте их трафик в VLAN и из нее.
Вы не должны начинать разбиение на подсети локальной сети Ethernet, если у вас нет веских причин для этого. Две лучшие причины:
Устранение проблем с производительностью. Локальные сети Ethernet не могут масштабироваться бесконечно. Чрезмерные широковещательные рассылки или поток кадров в неизвестные места назначения ограничат их масштаб. Любое из этих условий может быть вызвано слишком большим размером одного широковещательного домена в локальной сети Ethernet. Широковещательный трафик легко понять, но лавинная рассылка кадров в неизвестные места назначения немного более неясна. Если у вас так много устройств, что таблицы MAC-адресов вашего коммутатора переполняются, коммутаторы будут вынуждены лавинно рассылать нешироковещательные кадры из всех портов, если место назначения кадра не соответствует ни одной записи в таблице MAC-адресов. Если у вас достаточно большой одиночный широковещательный домен в локальной сети Ethernet с профилем трафика, при котором хосты разговаривают нечасто (то есть достаточно редко, чтобы их записи устарели в таблицах MAC-адресов на ваших коммутаторах), вы также можете получить чрезмерную лавинную рассылку кадров. .
Желание ограничить / контролировать трафик, перемещающийся между хостами на уровне 3 или выше. Вы можете взломать трафик на уровне 2 (ala Linux ebtables), но с этим трудно справиться (потому что правила привязаны к MAC-адресам, а изменение сетевых адаптеров требует изменения правил) может вызвать то, что кажется действительно очень странным (выполнение прозрачное проксирование HTTP на уровне 2, например, причудливо и весело, но совершенно неестественно и может быть очень не интуитивно понятным для устранения неполадок) и, как правило, сложно выполнить на более низких уровнях (потому что инструменты уровня 2 похожи на палки и помогает справиться с проблемами уровня 3+). Если вы хотите управлять трафиком IP (или TCP, или UDP и т. Д.) Между хостами, а не решать проблему на уровне 2, вам следует подсеть и прикрепить брандмауэры / маршрутизаторы с ACL между подсетями.
Проблемы нехватки полосы пропускания (если они не вызваны широковещательными пакетами или лавинной рассылкой кадров) обычно не решаются с помощью виртуальных локальных сетей и подсетей. Они возникают из-за отсутствия физического подключения (слишком мало сетевых адаптеров на сервере, слишком мало портов в группе агрегации, необходимость перехода на более высокую скорость порта) и не могут быть решены путем разделения на подсети или развертывания виртуальных локальных сетей, поскольку это победило. Не увеличивайте доступную пропускную способность.
Если у вас нет даже чего-то простого, например, MRTG, отображающего статистику трафика по портам на ваших коммутаторах, это действительно ваш первый бизнес, прежде чем вы начнете потенциально введение узкие места с благими намерениями, но неинформированным разделением подсетей. Необработанный подсчет байтов - хорошее начало, но вы должны продолжить его целевым анализом, чтобы получить более подробную информацию о профилях трафика.
Как только вы узнаете, как движется трафик в вашей локальной сети, вы можете начать думать о подсетях по соображениям производительности.
Что касается «безопасности», вам нужно будет много знать о своем прикладном программном обеспечении и о том, как оно работает, прежде чем вы сможете продолжить.
Несколько лет назад я спроектировал LAN / WAN приемлемого размера для медицинского заказчика, и меня попросили поместить списки доступа в объект уровня 3 (модуль супервизора Cisco Catalyst 6509) для управления трафиком, перемещающимся между подсетями с помощью " инженер, "который мало понимал, какая работа на самом деле потребуется, но очень интересовался" безопасностью ". Когда я вернулся с предложением учиться каждый приложение для определения необходимых портов TCP / UDP и хостов назначения я получил шокированный ответ от «инженера», заявив, что это не должно быть так сложно. Последнее, что я слышал, они запускают объект уровня 3 без списков доступа, потому что они не могут заставить все свое программное обеспечение работать надежно.
Мораль: если вы действительно собираетесь попытаться ограничить пакетный и потоковый доступ между виртуальными локальными сетями, будьте готовы много работать с прикладным программным обеспечением и изучать / перепроектировать, как оно взаимодействует по сети. Ограничение доступа хостов к серверам часто может быть выполнено с помощью функции фильтрации на серверах. Ограничение доступа по сети может вызвать ложное чувство безопасности и убаюкать администраторов, когда они думают: «Ну, мне не нужно настраивать приложение. Безопасно, потому что хосты, которые могут общаться с приложением. Ограничены« сеть '. " Я рекомендую вам проверить безопасность конфигурации вашего сервера, прежде чем я начну ограничивать связь между хостами по сети.
В 99% случаев подсеть должна быть эквивалентна VLAN (т.е. каждая подсеть доступа должна соответствовать одной и только одной VLAN).
Если у вас есть хосты из более чем одной IP-подсети в одной и той же VLAN, вы лишаетесь цели VLAN, поскольку две (или более) подсети будут в одном широковещательном домене.
В качестве альтернативы, если вы поместите одну IP-подсеть в несколько VLAN, узлы в IP-подсети не смогут связываться с узлами в другой VLAN, если ваш маршрутизатор не прокси ARP включен.
Я в основном согласен с Дэвид Пэшли: