Здравствуйте. Появилось у меня 3 задачи. И куча вопросов...
Сначала задачи. Первая задача. Объединить несколько приходящих ко мне vlan-ов в единую сеть с единым адресным пространством. Т.е., образно выражаясь, «воткнуть» их в один коммутатор.
В общем есть интерфейсы eth1.3000, eth1.3001, eth1.3002 и т. д. Где eth1.3001, eth1.3002… - это приходящие vlan. А eth1.3000 это, так сказать, центральная сеть, где находится DHCP-сервер и маршрутизатор.
Решилось все просто, а именно созданием бриджа br0. В него были добавлены все перечисленные выше интерфейсы. Ip-адреса у него нет, ибо не нужен.
Вторая задача чуть сложнее.
Сделать так, чтобы пользователи в vlan-ах, т.е за интерфейсами eth1.3001 … 1.300n, не видели друг друга, а видели только «центральный» vlan eth1.3000.
Другими словами изолировать порты нашего виртуального ком-ра друг от друга и сделать так, чтобы они видели только условный uplink. На ком-рах D-Link это реализуется через traffic_segmentation, у Cisco - switchport protected, а у SNR- port isolation.
Сначала я нашел в просторах Интернета такое:
ebtables -A FORWARD --logical-in br0 --logical-out br0 -j DROP.
Ходить-то между интерфейсами перестало, но я потом долго думал как разрешить хождение пакетов на eth1.3000.
В итоге сделал иначе. Сначала просто ebtables -P FORWARD DROP
А затем:
ebtables -A FORWARD --logical-out br0 -i eth1.3000 -j ACCEPT
ebtables -A FORWARD --logical-out br0 -o eth1.3000 -j ACCEPT
Работать то работает, но правильно ли я сделал? И не будет ли у меня трафик внутри железа лишние «круги нарезать»? Подскажите, пожалуйста, новичку.
Задача третья. Сделать на одной железке несколько таких бриджей, у каждого из которых свой «uplink» и свои «порты». Адресное пространство у каждого, соответственно, своё. Пересекаться пользователи с этих бриджей будут, только через маршрутизацию на другом железе… а может и на этом.
И вот вопрос: а сработает ли такая настройка ebtables с несколькими бриджами, т. е. если просто для каждого бриджа добавлять правила
ebtables -A FORWARD --logical-out brX -i ethX -j ACCEPT
ebtables -A FORWARD --logical-out brX -o ethX -j ACCEPT
И будет ли подобное работать, если в качестве «uplink» к бриджу добавить bond интерфейс?
Например,
brctl addif br0 bond0
А на ebtables:
ebtables -A FORWARD --logical-out br0 -i bond0 -j ACCEPT
ebtables -A FORWARD --logical-out br0 -o bond0 -j ACCEPT
Или есть какие-то тонкости в ebtables, например?
И еще куча вопросов возникла. Если кто-то знает ответы на них, подскажите, пожалуйста. Я буду тестировать по мере возможностей, но надо сориентироваться побыстрее, так как времени мало.
1) Насколько безопасна такая схема в плане обеспечения стабильной работы сети. (Т.е. защиты ее от колец, штормов, хакеров, вирусов и т. п.) На конечных коммутаторах, куда подключены пользователи, включена защита от колец на порту и настроен storm control. Порты пользователей на ком-рах изолированы друг от друга. Размер одной сети (в одном бридже) до /19, хотя была мысль, все же уменьшить размер сети до /22 или /23.
Нужны ли текущей схеме какие-либо настройки ещё и на iptables, если ни у бриджей, ни у входящих в них интерфейсов нет ip-адресов. По логике я понимаю, что нет... Но мало ли, я совсем не имею опыта работы с ebtables.
2)Какая предположительно будет нагрузка на железо (процессор, память) при пропуске трафика 6-7 Гбит/с. Пользователей во всех бриджах будет 7-8 тысяч.
И при 15-20 Гбит/с (пользователей 20 тысяч)? Как Вы думаете, можно ли будет для этого использовать Intel Celeron J3455 4x1.5 ГГц?
И как вырастет нагрузка, если все же добавить ip адреса и настроить маршрутизацию между сетями прямо на этой машине? Т.е. если прогонять трафик не просто на канальном уровне, а еще что-то маршрутизировать. Трафик между сетями ожидается небольшой. Как минимум на порядок ниже, чем на uplink.
