Комментарии 31
Очень круто. Каких только трюков люди не делают, чтобы не делать правильный дизайн сети :-)
У меня лишь один вопрос: как человек после вас будет в этом сервере разбираться? :-)
У меня лишь один вопрос: как человек после вас будет в этом сервере разбираться? :-)
А что тут сложного? Слой relay по умолчанию пользователю не виден. Слой backplate — обычный switch.
Ладно, давайте о дизайне. Прикладная задача для embedded-системы: подключить VoIP-оборудование к общему серверу телефонии.
Каждый VLAN — логически изолированный узел (этаж здания, само здание, отдельный арендатор). Количество оконечных устройств на VLAN-е изначально не определено и может изменяться в процессе эксплуатации. Количество VLAN также может изменяться (арендаторы появляются и пропадают). Какие будут предложения?
Ладно, давайте о дизайне. Прикладная задача для embedded-системы: подключить VoIP-оборудование к общему серверу телефонии.
Каждый VLAN — логически изолированный узел (этаж здания, само здание, отдельный арендатор). Количество оконечных устройств на VLAN-е изначально не определено и может изменяться в процессе эксплуатации. Количество VLAN также может изменяться (арендаторы появляются и пропадают). Какие будут предложения?
НЛО прилетело и опубликовало эту надпись здесь
На каждый VLAN вешать свою подсеть со своим default gateway. Разруливать маршрутизацию iptables. При добавлении vlan добавлять еще одну подсеть. Точно проще будет?
Разбираться — точно проще. В т.ч. и самому после пары лет безпроблемной работы :-)
Просто я такого наслышался: «Досталось мне тут в наследство...». Ведь правильный дизайн он ещё и по возможности простой, в т.ч. и для понимания.
Просто я такого наслышался: «Досталось мне тут в наследство...». Ведь правильный дизайн он ещё и по возможности простой, в т.ч. и для понимания.
Вот я спрашиваю: дизайн с кучей сетей, соответствующими правилами в firewall, с периодическим добавлением/удалением сетей будет проще? Здесь единственный входной параметр: кол-во требуемых VLAN, все остальное может быть создано скриптом с единственным циклом, который создает интерфейсы и добавляет их в бридж.
Роутер/L3-свитч с маршрутизацией между вланами и фильтрацией трафика? Провизить оборудование атрибутами DHCP (давая ссылка на сервер телефонии). Адресация меняется путём измнения IP/mask и DHCP-пула на устройстве. dot1q-сабинтерфейсы добавляются/удаляются там же. При умирании устройства бэкап конфига заливается на ЗИП. Вроде все шесть условий выполняются.
Так я же и говорю: «или чисто аппаратное решение на коммутаторе L3, или аппаратно-программное решение на коммутаторе с (как минимум) поддержкой 802.1q». Второе выбрал в том числе и потому, что система встраиваемая, и вся эта логика зашивается более-менее жестко. В моем случае конфигурация вообще создается скриптами, а входным параметром является единственное число — кол-во необходимых VLAN. Соответственно требование к обвязке снижается до L2-коммутатора и админа-школьника, способного прописать на нем VLAN-ы.
Каждому своё.
Вам проще сделать сложный конфиг сервера и отдать сетевику контроль над голым L2 (который тоже не так то прост). Я же предпочту отдать сетевику сеть (и поставлю для этого железку для коммутации/маршрутизации вместо L2-коммутатора, раз уж он у вас по сути не коммутирует вне влана), разумной сложности, а админу сервера админскую работу (пусть сделает простой и понятный конфиг tftp или через что там провизятся железки).
А конфигурацию к сетевому железу тоже со временем начинаешь генерировать, а не мышой щёлкать :-)
Вам проще сделать сложный конфиг сервера и отдать сетевику контроль над голым L2 (который тоже не так то прост). Я же предпочту отдать сетевику сеть (и поставлю для этого железку для коммутации/маршрутизации вместо L2-коммутатора, раз уж он у вас по сути не коммутирует вне влана), разумной сложности, а админу сервера админскую работу (пусть сделает простой и понятный конфиг tftp или через что там провизятся железки).
А конфигурацию к сетевому железу тоже со временем начинаешь генерировать, а не мышой щёлкать :-)
Не понял зачем было городить такой огород о_О.
У большинства управляемых свитчей L2 уровня всё это уже есть.
Блокировка трафика между пользователями у D-Link называется traffic_segmentation. У остальных (эджкоры, тп-линк и т.д.) то же есть.
DHCP_Relay есть прямо в свитче, соберёт с разных VLAN и портов и отправит на 1 сервер. Ответ вернётся только конкретному клиенту.
ip unnumbered разве что… Но аппаратных решений умеющих это без такого огорода — ОЧЕНЬ много. Даже то же программное. Но не этот огород.
Пока что не понятен смысл… Но как сферический конь в вакууме — интересно :)
У большинства управляемых свитчей L2 уровня всё это уже есть.
Блокировка трафика между пользователями у D-Link называется traffic_segmentation. У остальных (эджкоры, тп-линк и т.д.) то же есть.
DHCP_Relay есть прямо в свитче, соберёт с разных VLAN и портов и отправит на 1 сервер. Ответ вернётся только конкретному клиенту.
ip unnumbered разве что… Но аппаратных решений умеющих это без такого огорода — ОЧЕНЬ много. Даже то же программное. Но не этот огород.
Пока что не понятен смысл… Но как сферический конь в вакууме — интересно :)
DHCP Relay в коммутаторе означает L3. Причину отказа от него см. выше. А вот о «программном решении, но без этого огорода» можно поподробнее? Идею на пальцах или ссылку на реализацию?
DHCP Relay совсем не означает L3. Чистый L2 D-Link DES-3200 или DES-1210/ME прекрасно умеет DHCP Relay. Забирать пакет из VLAN пользователя и направлять его юникастом на DHCP сервер через свой управляющий VLAN. Бродкастовый пакет DHCP даже на соседние порты в общем-то не попадёт. Ответ сервера попадёт юникастом на свитч, а оттуда туда, откуда пришёл. У других производителей то же есть аналогичные свитчи. Больше работал с D-Link, поэтому мне проще их модели сказать.
Опять же изоляция портов пользователей друг от друга traffic_segmentation или Assymetric Vlan (опять же в терминологии D-Link).
Остаётся вопрос, а надо ли ip unnambered вообще. Если нет, задача сводится к правильной архитектуре L2 уровня на нормальных управляхах + нормальный маршрутизатор в ядре (как программный, так и аппаратный).
Правда при использовании варианта из статьи можно использовать СОВСЕМ тупые свитчи, где по факту есть только VLAN и всё. Соответственно экономия. Это единственный плюс который я вижу. Хотя тут легко нарваться на правило — жадный платит дважды.
Опять же изоляция портов пользователей друг от друга traffic_segmentation или Assymetric Vlan (опять же в терминологии D-Link).
Остаётся вопрос, а надо ли ip unnambered вообще. Если нет, задача сводится к правильной архитектуре L2 уровня на нормальных управляхах + нормальный маршрутизатор в ядре (как программный, так и аппаратный).
Правда при использовании варианта из статьи можно использовать СОВСЕМ тупые свитчи, где по факту есть только VLAN и всё. Соответственно экономия. Это единственный плюс который я вижу. Хотя тут легко нарваться на правило — жадный платит дважды.
Если что-то имеет DHCP (в т.ч. и relay) не на management, а как сервис, то это уже L3 (по модели OSI).
С тем, что сделать изоляцию средствами коммутатора проще и грамотнее, никто не спорит. Но без relay в любом случае это вызовет broadcast storm.
Ладно, заканчиваем полемику о причинах выбора именно этого решения? Я его запихнул в embedded систему, соответственно обвязка ей потребуется более слабая (ну а область применения новой железяки расширится).
С тем, что сделать изоляцию средствами коммутатора проще и грамотнее, никто не спорит. Но без relay в любом случае это вызовет broadcast storm.
Ладно, заканчиваем полемику о причинах выбора именно этого решения? Я его запихнул в embedded систему, соответственно обвязка ей потребуется более слабая (ну а область применения новой железяки расширится).
>> Если что-то имеет DHCP (в т.ч. и relay) не на management, а как сервис, то это уже L3 (по модели OSI).
По сути да, но подобные функции реализуют на L2 свитчах, которые не занимаются маршрутизацией. Например всякие снупинги и аклы работают на коммутаторах, хоть и на сетевом уровне. Но это не делает коммутатор еще и маршрутизатором. Хотя функции L3, да.
По сути да, но подобные функции реализуют на L2 свитчах, которые не занимаются маршрутизацией. Например всякие снупинги и аклы работают на коммутаторах, хоть и на сетевом уровне. Но это не делает коммутатор еще и маршрутизатором. Хотя функции L3, да.
НЛО прилетело и опубликовало эту надпись здесь
Обнаружил в статье упоминание оборудования Qtech (это действительно Raisecom?). Есть какие-то объективные причины выбора не D-link, Netgear, Huawei?
для оценки сложности решения — зайдите в соседнюю контору и попросите быстренько поправить проблему с dhcp )
Ну и считайте к-во мата, по мере постижения.
Наворочено, необслуживаемо, немасштабируемо. Вот что вы будете делать после 4к клиентов? ;)
Ну и из личного опыта — подобные навороты на серверах приводят к тому, что в случае возникновения проблем — сетевики кивают на админов, админы на сетевиков, а юзера сидят и матерятся.
Ну и считайте к-во мата, по мере постижения.
Наворочено, необслуживаемо, немасштабируемо. Вот что вы будете делать после 4к клиентов? ;)
Ну и из личного опыта — подобные навороты на серверах приводят к тому, что в случае возникновения проблем — сетевики кивают на админов, админы на сетевиков, а юзера сидят и матерятся.
Вообще-то в комментариях проскакивало, что это решение не для сервера, а для embedded-системы. Необслуживаемо — это верно, обслуживать просто нечего. Схема проста до невозможности и, практически, не использует ip-адресации.
Масштабируемо достаточно сильно: новый клиент добавляется одним шагом цикла в скрипте, который создает для него набор интерфейсов. Кол-во клиентов ограничено кол-вом поддерживаемых VLAN на обвязке. Вы ведь не думаете, что эта конфигурация создается вручную? Один маленький скрипт, получающий на входе требуемое кол-во клиентов и начальный номер VLAN для них (на самом деле еще и распределение VLAN-ов по физическим ethernet, но не суть).
Отлов проблем: зная VLAN с проблемным клиентом просто запустят на нем tcpdump.
Масштабируемо достаточно сильно: новый клиент добавляется одним шагом цикла в скрипте, который создает для него набор интерфейсов. Кол-во клиентов ограничено кол-вом поддерживаемых VLAN на обвязке. Вы ведь не думаете, что эта конфигурация создается вручную? Один маленький скрипт, получающий на входе требуемое кол-во клиентов и начальный номер VLAN для них (на самом деле еще и распределение VLAN-ов по физическим ethernet, но не суть).
Отлов проблем: зная VLAN с проблемным клиентом просто запустят на нем tcpdump.
Для начала, Вы бы писали, под какую платформу ведете рассуждения. А то «надо сделать», а затем сразу «сделать это можно так — раз-раз».
Уже не говорю, что access mode — термин не совсем чтобы универсальный, так что бренд коммутатора тоже бы не помешала.
Понимаю, что звучит это занудно, но Вы же не во конторскую wiki (где все ваши читатели примерно понимают, о чем речь идет) пишете пост, а на ресурс «чуть большей» аудитории — уважайте читателей!
Уже не говорю, что access mode — термин не совсем чтобы универсальный, так что бренд коммутатора тоже бы не помешала.
Понимаю, что звучит это занудно, но Вы же не во конторскую wiki (где все ваши читатели примерно понимают, о чем речь идет) пишете пост, а на ресурс «чуть большей» аудитории — уважайте читателей!
Платформа не важна. Отладка вообще велась на десктопной машине, а целевая система собиралась при помощи buildroot. Но замечание о терминологии принимается, по-возможности внесу в статью исправления. И, возможно, стоит указать минимально необходимые опции сборки ядра для поддержки используемых фич. Хотя в современных generic ядрах все они присутствуют по умолчанию. Интересно, а есть здесь хаб для embedded programming?
Прозвучит пОшло, но linux — это далеко не дефолтная платформа в современном мире, а всего лишь одно из ядер в части дистрибутивов (да Вы это и сами отлично знаете). И «generic ядро», «buildroot» и прочее, что Вы упоминаете в тексте, на части «других» платформ может даже отсутствовать, не говоря, что для сходных задач и понятий могут использоваться другие средства и названия.
Повторюсь: отличный рассказ, но написанный для вашего коллеги, который ваши перипетии знает вдоль и поперек, и который в общем-то в курсе даже версии ядра в вашем дистрибутиве. Представьте, что Вы то же рассказываете не коллеге, а человеку с ИТ-ной подготовкой, но приехавшему к Вам в гости с другого конца страны — Вы же ему хотя бы расскажете явно чуть более подробно, чем написали в посте? Вот и ориентируетесь на такой подход, ведь не все не Хабре по тому, что увидели до ката (да и в тексте), хорошо поняли, о чем разговор.
Повторюсь: отличный рассказ, но написанный для вашего коллеги, который ваши перипетии знает вдоль и поперек, и который в общем-то в курсе даже версии ядра в вашем дистрибутиве. Представьте, что Вы то же рассказываете не коллеге, а человеку с ИТ-ной подготовкой, но приехавшему к Вам в гости с другого конца страны — Вы же ему хотя бы расскажете явно чуть более подробно, чем написали в посте? Вот и ориентируетесь на такой подход, ведь не все не Хабре по тому, что увидели до ката (да и в тексте), хорошо поняли, о чем разговор.
Cлушайте, а зачем, собственно, весь этот дико геморройный огород с бриджем, если можно тупо слушать в каждом интерфейсе на своём ip-нике и раздавать? Ну, придётся dhcp-сервер ребутать при добавлении абонентов, но это ж быстро и если конфиги генерить автоматом по шаблонам, а не руками писать — безопасно. Нафига весь этот огород?
Сейчас есть только 2 используемых IP: DHCP Server (он же default gateway для клиентов из всех VLAN) и DHCP Relay Agent. Если селить сервер на каждый VLAN, то имеем следующее:
— добавление/удаление клиента повлечет за собой операцию выделения/освобождения ip-адреса на интерфейсе (а какую маску ставить будем? На каждый VLAN выделять свою подсеть вместо ее динамического распределения?)
— при изменении общей размерности сети придется изменить параметры на всех интерфейсах;
— разрастание таблицы маршрутизации пропорционально кол-ву клиентов;
— уменьшение пропускной способности из-за увеличения нагрузки на CPU (вместо работы на L2 сначала разберем пакет до уровня L3, затем выполним фильтрацию/маршрутизацию, потом снова L3 соберем в L2).
— добавление/удаление клиента повлечет за собой операцию выделения/освобождения ip-адреса на интерфейсе (а какую маску ставить будем? На каждый VLAN выделять свою подсеть вместо ее динамического распределения?)
— при изменении общей размерности сети придется изменить параметры на всех интерфейсах;
— разрастание таблицы маршрутизации пропорционально кол-ву клиентов;
— уменьшение пропускной способности из-за увеличения нагрузки на CPU (вместо работы на L2 сначала разберем пакет до уровня L3, затем выполним фильтрацию/маршрутизацию, потом снова L3 соберем в L2).
1. Если клиентов не ограничивать, то глючный или злонамеренный клиент выберет у вас весь пул dhcp лиз всех клиентов. Скриптик продемонстрировать или сами догадаетесь?
2. И что, если это делает скрипт?
3. Сюрприз — даже full-view таблица работает в ядре очень быстро.
4. Вы в любом случае всю работу делаете на CPU в ядре. Вы сравнивали реальную производительность L2 и L3 стеков ядра и не написали про это в статье?
2. И что, если это делает скрипт?
3. Сюрприз — даже full-view таблица работает в ядре очень быстро.
4. Вы в любом случае всю работу делаете на CPU в ядре. Вы сравнивали реальную производительность L2 и L3 стеков ядра и не написали про это в статье?
Не выберет, т.к. DHCP Relay Agent в запросе к серверу вполне может отправлять и dhcp option 82. А сервер может ограничить кол-во выдаваемых адресов по клиенту. Просто в моем конкретном случае это излишне (подразумевается наличие клиента с кривыми руками, способного воткнуть не то и не туда, а не злонамеренного хакера).
Каюсь, производительность не сравнивал. Возможно Вы и правы. Хотя что-то мне подсказывает, что дополнительная обработка пакета все-таки должна потреблять какое-то количество времени CPU.
Каюсь, производительность не сравнивал. Возможно Вы и правы. Хотя что-то мне подсказывает, что дополнительная обработка пакета все-таки должна потреблять какое-то количество времени CPU.
Прикольно, у самого была подобная задача пару лет назад, но ядро было 2.6.18 или что-то типа того, а то бы я нагородил что-то подобное :)
Решилось тогда довольно просто: нашёл релей агент, который ответы отсылает не бродкастом, а юникастом. Т.е. получателем ставит мак клиента в явном виде. Тогда никаких проблем с бродкастом не наблюдается и проблема отсутствует как таковая.
ещё комментариев:
1. вланы (ИМХО) правильнее добавлять так: ip link add link eth0 vlan600 type vlan id 660
(не нужно ничего доставлять, нет неявного именования новых интерфесов,
а то, например, на моей системе «vconfig add eth0 600» добавляет eth0.600 а не vlan600 )
2. включение stp на br1 вобщем-то лишено смысла, ведь вы включаете изоляцию клиентов. Т.е. петля/кольцо не поломают вам нечего, т.к. трафик ходить «по кругу» не сможет, а странные проблемы иногда могут появляться в итоге.
Решилось тогда довольно просто: нашёл релей агент, который ответы отсылает не бродкастом, а юникастом. Т.е. получателем ставит мак клиента в явном виде. Тогда никаких проблем с бродкастом не наблюдается и проблема отсутствует как таковая.
ещё комментариев:
1. вланы (ИМХО) правильнее добавлять так: ip link add link eth0 vlan600 type vlan id 660
(не нужно ничего доставлять, нет неявного именования новых интерфесов,
а то, например, на моей системе «vconfig add eth0 600» добавляет eth0.600 а не vlan600 )
2. включение stp на br1 вобщем-то лишено смысла, ведь вы включаете изоляцию клиентов. Т.е. петля/кольцо не поломают вам нечего, т.к. трафик ходить «по кругу» не сможет, а странные проблемы иногда могут появляться в итоге.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
DHCP сервер на нескольких VLAN