Как делится адресное пространство при использовании 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)
