Если что-то имеет DHCP (в т.ч. и relay) не на management, а как сервис, то это уже L3 (по модели OSI).
С тем, что сделать изоляцию средствами коммутатора проще и грамотнее, никто не спорит. Но без relay в любом случае это вызовет broadcast storm.
Ладно, заканчиваем полемику о причинах выбора именно этого решения? Я его запихнул в embedded систему, соответственно обвязка ей потребуется более слабая (ну а область применения новой железяки расширится).
DHCP Relay в коммутаторе означает L3. Причину отказа от него см. выше. А вот о «программном решении, но без этого огорода» можно поподробнее? Идею на пальцах или ссылку на реализацию?
Вот я спрашиваю: дизайн с кучей сетей, соответствующими правилами в firewall, с периодическим добавлением/удалением сетей будет проще? Здесь единственный входной параметр: кол-во требуемых VLAN, все остальное может быть создано скриптом с единственным циклом, который создает интерфейсы и добавляет их в бридж.
Так я же и говорю: «или чисто аппаратное решение на коммутаторе L3, или аппаратно-программное решение на коммутаторе с (как минимум) поддержкой 802.1q». Второе выбрал в том числе и потому, что система встраиваемая, и вся эта логика зашивается более-менее жестко. В моем случае конфигурация вообще создается скриптами, а входным параметром является единственное число — кол-во необходимых VLAN. Соответственно требование к обвязке снижается до L2-коммутатора и админа-школьника, способного прописать на нем VLAN-ы.
На каждый VLAN вешать свою подсеть со своим default gateway. Разруливать маршрутизацию iptables. При добавлении vlan добавлять еще одну подсеть. Точно проще будет?
А что тут сложного? Слой relay по умолчанию пользователю не виден. Слой backplate — обычный switch.
Ладно, давайте о дизайне. Прикладная задача для embedded-системы: подключить VoIP-оборудование к общему серверу телефонии.
Каждый VLAN — логически изолированный узел (этаж здания, само здание, отдельный арендатор). Количество оконечных устройств на VLAN-е изначально не определено и может изменяться в процессе эксплуатации. Количество VLAN также может изменяться (арендаторы появляются и пропадают). Какие будут предложения?
Перевыпуск симки — это для девочек на рецепшен. Технари просто отловят смс на заданный номер (или отправят его с этого номера). Или сделают звонок с номера жертвы. Или перехватят такой звонок. А вот найти такую утечку и ее авторов будет на-амного сложнее…
Преимущество «поверх E1» в том, что у нас остается коммутация каналов. Например payload внутри cic вполне может быть и «64 kbit/s unrestricted data», что позволит проводить через Asterisk даже 3GPP видеозвонки (правда только транзитом и только по цифровым каналам).
Ну не обязательно же использовать ОКС на asterisk-е в рабочей системе. Иногда надо быстро собрать стенд для тестирования оборудования или конфигурации. В качестве генератора нагрузки такое решение вполне интересно.
С тем, что сделать изоляцию средствами коммутатора проще и грамотнее, никто не спорит. Но без relay в любом случае это вызовет broadcast storm.
Ладно, заканчиваем полемику о причинах выбора именно этого решения? Я его запихнул в embedded систему, соответственно обвязка ей потребуется более слабая (ну а область применения новой железяки расширится).
Ладно, давайте о дизайне. Прикладная задача для embedded-системы: подключить VoIP-оборудование к общему серверу телефонии.
Каждый VLAN — логически изолированный узел (этаж здания, само здание, отдельный арендатор). Количество оконечных устройств на VLAN-е изначально не определено и может изменяться в процессе эксплуатации. Количество VLAN также может изменяться (арендаторы появляются и пропадают). Какие будут предложения?