Как делится адресное пространство при использовании l3 коммутаторов на уровне доступа?
Всегда работал с l2 устройствами на уровне доступа, там вопросов не возникает, обеспечиваем отказоустойчивый l2 домен( петлями и агрегацией ) и дальше прокидываем VLAN'ами до l3 устройства( маршрутизатора ), на котором уже работаем с l3 трафиком, отказоустойчивость на периметре l3 реализуем через VRRP, внутри l3 ECMP, метрики, динамическая маршрутизация. Если нужно обеспечить отказоустойчивость клиентского подключения, можно использовать стэк из коммутаторов и cross ethernet channel
Но как работать когда l3 устройства находится на уровне доступа?
Как назначать адреса клиентам, чтобы не было проблем с маршрутизацией, кидать подсеть по количеству портов и настраивать файрволл на каждый порт( т.е. на 24 портовый коммутатор кидаем 27 подсеть ) или делить по подсетям, но тогда очень много подсетей получается.
Или каждом клиенту дать 30 подсеть? Но это 24 тридцатых подсети на коммутатор, т.е. сразу 25 подсеть на один коммутатор, т.е. в пять раз больше чем необходимо для такого кол-ва устройств.
Как обеспечивать отказоустойчивость до клиента, кидать два линка с разными адресами в разных подсетях до двух l3 устройств и на клиенте настраивать метрики?
Есть какой-нибудь приличный гайд по планированию адресов с l3 уровнем доступа, best practice, чтобы по граблям не ходить?
Валентин
@vvpoloskin Куратор тега Компьютерные сети
Даже EVPN/VXVLAN подразумевает, что шлюзом для серверов являются центральные маршрутизаторы (overlay уровень). Ответьте себе на вопрос, чего вы хотите добиться, перетащив L3 уровень на обычную не оверлейную сеть. Я вижу только два смысла: убрать коварные L2 петли и разгрузить линки «вертикального» трафика. Но перенося L3 на доступ в лоб вы становитесь завязаны на то, что, IP адрес физического сервера завязан на конкретный узел доступа. Надо переключить сервер физически (например, плату сетевую поменять), переключаем на новый коммутатор и даём новый IP адрес. Владельцам приложений на сервере это очень не понравится. Для избегания этого и придумали оверлейные сети.
И очень осмысленно делайте функции файрвола на шлюзах. Рано или поздно это приведёт к тому, что производительности их в части фильтрации будет не хватать, а для проходящих потоков эта фильтрация будет не нужна (тот же видео контент).
Всё зависит от ваших хотелок и имеющегося оборудования.
1. Какие у вас свичи?
2. Чего вы хотите добиться прописывая ip на свичах, а не на роутерах?
3. Отказаустойчивость обеспечивается не до клиента, а до свича протоколами маршрутизации. Надо связать свич с двумя другими свичами/роутерами. Метрики это не про отказоустойчивость.
4. Если IP серые, то можете хоть /31 прописывать для каждого клиента если оборудование позволяет. Если белые, то всё зависит от ваших хотелок. Можно например всех в одну сеть закинуть, но потом если вам понадобится фильтровать траффик на свиче для каждого клиента отдельно, то это будет проблематично, потому чо коммутатор это не фаирволл. Если делать ACL для каждого клиента отдельно, то может переполнится TCAM(всё зависит от самого фильтра и железки), если переполнится TCAM, то пакеты пойдут в CPU и он может загнутся. + если прописать IP на свиче, то надо будет городить более сложный Control Plane Policy, чем для L2 свича.
5. У меня больше вопросов, чем ответов. Сперва опеделите для себя зачем это вам нужно. Если есть конкретная задача, то опишите её. Если хотите сделать всё красиво для серверов, то смотрите дизайн топологий для датацентров (VPC, VXLAN)
1 не надо зацикливаться что на Л3 устройствах нужно обязательно использовать весь возможный функционал Л3 и только его.
как вариант. на пользовательских устройствах делим пользователей (при необходимости или желании) на группы и разделяем по VLAN. например можно отделить пользователей и принтеры, пользователей и принтеры по отделам/этажам. каждому VLAN отдельный диапазон/ широковещательный домен. VLAN живут только на коммутаторах доступа, дальше все на Л3 динамической маршрутизацией. соответсвенно на ядре бекбон, доступ - в stab. с другой стороны сервисы + оборудование так же делим на диапазоны которые так же маршрутизим на ядре.
Как разделить адресное пространство с l3-коммутаторами? Также как в привычной схеме с маршрутизаторами.
L3-коммутаторы применяются, чтобы разгрузить и без того загруженные процессоры маршрутизаторов, выполняющих функции файерволинга, натирования, какого-нибудь контроллера, конечно маршрутизатора и много чего ещё. И что делать, если 16-ядерного маршрутизатора не хватает? Купить ещё дороже с ещё бОльшим количеством ядер. Но как известно деньги не берутся из воздуха, а покупать новую железку, когда лежит ещё свежая, но "менее производительная" нерационально.
Именно поэтому есть l3 коммутаторы которые снимают с маршрутизатора нагрузку в межвлановой маршрутизации.
На коммутаторах фирмы MikroTík с версии RouterOS 7 на некоторых коммутаторах появилась аппаратная маршрутизация, т.е. на свитч-чипе.
Подытог.
Планируйте свою сеть также как и с маршрутизатором, но на коммутаторах.
Возможно придётся применять динамическую маршрутизацию, так как схема стала чуть сложнее.
Простой
