Разделить один коммутатор на несколько виртуальных (каждый со своим набором портов)

[Богдан]

Исходные данные:
- типичная многовквартирная многоподъездная многоэтажка;
- в подъезде 4 провайдера;
- множество кабель-каналов и немаркированных (неизвестного происхождения) кабелей внутри подъезда.

Задача:
- организованно подключить все квартиры кабелями Cat5e на патч-панель на техэтаже;
- соединить все квартирные кабеля в единый подъездный коммутатор;
- в тот же самый подъездный коммутатор (или сразу в домовой коммутатор) завести аплинки провайдеров и внутридомовой системы видеонаблюдения;
- распределить порты между провайдерами программно;
- запретить провайдерам хозяйничать в подъезде;
- устранить кабельное безобразие из подъездов.

Решение 1: разделить клиентов каждого провайдера по отдельным физическим коммутаторам.
Недостатки:
- в случае смены провайдера необходимо физически перекоммутировать кабеля, а задача не только в устранении кабельного безобразия в подъезде, но и в полном отстранении представителей провайдера от возможности хозяйничать в подъезде;
- если коммутатор заполнен лишь частично - ресурсы коммутатора будут простаивать.

Решение 2: распределить клиентов при помощи PVLAN/QinQ/прочее.
Недостатки:
- каждому провайдеру "обязательно" понадобится root доступ под каким-либо предлогом. А root-доступ позволит подсматривать всякие там коммерческие тайны, настройки и статистики по трафику других провайдеров. Так что врядли провайдеры согласятся подключать клиентов через активное устройство, которое они не контроллируют или контроллируют, но не только они (речь о конкурентах). И это может стать непреодолимым препятствием;
- для переназначения порта от одного провайдера к другому необходим root-доступ и некая доверенная треться сторона (штатный сотрудник от жильцов или от ЖЕКа, в ответственности которого окажется сетевое хозяйство), а хочется один раз настроить и забыть, чтобы представитель техподдержки со стороны жильцов только накатывал типовый конфиг и устанавливал начальные пароли.

В общем, необходимо как-то разделить один коммутатор на несколько непересекающихся частей с одинаковым набором функций. Пусть даже это будут урезанные функции: например - один коммутатор L3 разделить на несколько виртуальных коммутаторов L2 или L2+.

Вопрос:
Есть ли у Eltex решение, которое позволит предоставить каждому провайдеру не просто порты, а именно часть коммутатора с конкретным набором портов, чтобы провайдеры не могли ​видеть настройки и/или статистику друг-друга?

Я себе представляю это так:
- каждому порту коммутатора присваивается псевдоним (kvartira_5, kvartira_18, camera_2, domofon_1 и т.п.);
- на коммутаторе создаётся необходимое количество "виртуальных устройств";
- на коммутаторе создаётся пул "перемещаемых портов";
- к каждому "виртуальному устройству" привязывается конкретный набор портов из пула "перемещаемых портов";
- каждое "виртуальное устройство" функционирует как отдельный экземпляр устройства, на котором создано (включая базу паролей, таблицы коммутации/маршрутизации, экземпляры RTP/OSFP/..., настройки RADIUS и пр.);
- каждое "виртуальное устройство" не имеет доступа к портам другого "виртуального устройства";
- внутри каждого "виртуального устройства" доступны команды "освободить порт №", "занять порт № из списка свободных в пуле перемещаемых портов";
- отдельно формируется список "неперемещаемые порты", которые недоступны для команд "занять порт" и "освободить порт" изнутри "виртуальных устройств";
- в каждом "виртуальном устройстве" порты именуются по псевдониму (чтобы исключить возможность определения номера физического порта изнутри виртуального устройства);
- внутри "виртуального коммутатора" порты команды "освободить порт №" и "занять порт №" оперируют не физическим наименованием порта, а логическим названием/псевдонимом ("занять порт kvartira_5", "освободить порт kvartira_18");
- на главном устройстве присутствует функция запрета на просматр списка "свободных портов" изнутри "виртуальных устройств", чтобы провайдеры не могли подсматривать список не подключённых к интернету квартир, которых следует заспамить предложениями их услуг интернета.

[Евгений Т]

Здравствуйте.

Из написанного есть несколько непонятных моментов
1) В в этой ситуации на чьей стороне выступаете? Жильцов? Провайдеров? Другая организация.
2) Кто будет покупать этот отдельный коммутатор и в связи с чем появилась такая необходимость? Всегда каждый провайдер устанавливает свой коммутатор в подъезд и настраивает на него свою конфигурацию в соответствие с сервисной моделью. Я даже не уверен, что они согласятся поставить какой-то стороннее оборудование, т.к это небезопасно. Это никак не защищает от подмены со стороны клиента IP/MAC адреса , может мешать сервисной модели в случае, если провайдер выдаёт адрес по DHCP с помощью опции 82, может нарушить 802.1x аутентификацию, если используется и т.д.
3) Подобная реализация есть у другого вендора? Ранее не слышал про подобную задумку.
4) Зачем в реализации OSPF, если все провайдеры на доступ выдают чистый L2 канал?


Задумка в том виде, в котором описывается, нереализуема.
Можно создать учётные записи, в которых разрешить только определённые команды для каждой учётки. При этом раздление по портам будет в виде VLAN, потому что каждый провайдер будет использовать свои VLAN. Прописывать вланы на порты они будут сами. Действия будут логироваться, поэтому в случае чего можно будет понять кто сделал невалидные настройки. Можно вланы вообще динамически с Radius-сервера назначать. Тогда уже к настройкам Radius нужно будет ограничивать доступ провайдера.

[Богдан]

1) На стороне жильцов. В правовом смысле - как юрлицо, которое будет создано жильцами в качестве первого обязательного шага по реализации проекта.
2) Покупать - юрлицо (как представитель интерессов жильцов). Идея собрать квартиры каждого подъезда в отдельный подъездный коммутатор - лишь начальный этап длинного многолетнего плана по преображению микрораёна в цифровом направлении.
Если интересы жильцов будет представлять официальное юрлицо, которое выступит неким гарантом - в качестве препятствия останется только техническая задача сопряжения нескольких провайдеров в одной железке, с условием "пускай бремя логического администрирования сети останется в отвественности провайдеров в качестве оплаты за эксплуатацию активного оборудования жильцов, а проконтроллировать физический доступ в сеть сможет и не ИТ-специалист".
3) Надеюсь. Описал своё представление желаемого в надежде, что белее подкованные в теме специалисты смогут направить в нужном мне направлении, если такое где-то существует. В маршрутизаторах Cisco есть некое подобие (VRF), но там всё-равно вирутализация лишь по части маршрутизации и предполагается, что у всех VRF - единый администратор.
4) На типичном порту провайдера в сторону квартирного кабеля - L2. Цель - всунуть "независимого" (официального) посредника между провайдером и жильцами (между провайдером и коммутатором доступа), чтобы исключить безпардонные действия провайдерских монтажников в подъездах. А в сторону провайдера с коммутатора доступа отправляется явно не голый L2. OSPF приведён как пример того, что может выходить с коммутатора доступа (не принадлежащего провайдеру, но управляемому им) в сторону провайдера.

"Собрать несколько коммутаторов в стек (единое устройство)" - это описано на каждом углу профильных ресурсов интернета. Сделать строго обартную операцию, ничего не выдумывая - "разделить ресурсы одного физического коммутатора на несколько логических самостоятельных устройств" - тишина (я не находил).
Если рассмотреть типичный 24-портовый коммутатор как "стек" из 24-х двухпортовых коммутаторов, у которых второй порт всегда завёрнут в единую для остальных портов шину - то не такая уж и хитрая арифметика получается. При этом вполне допустимо, если в силу ограничений по производительности в таком режиме, основным будет коммутатор уровня L3 (аргегации), а логическими - L2 или L2+ с минимально необходимыми возможностями, допустимыми для провайдеров в целях размещения на уровне доступа.

В моём представлении, это должна быть функция типичного коммутатора (небольшие дополнения в стандартный ASIC или хитрое использование обычных функций уже существующего и эксплуатируемого ASIC), а не отдельное устройство.

[Евгений Т]

Добрый день.

2) Остаётся вопрос о согласии провайдера на установку подобного оборудования, т.к у каждого провайдера свой функционал на коммутаторах доступа настраивается и своя сервисная модель
3) VRF тут не подойдёт. Это функционал, относящийся к маршрутизации и администратор действительно единый. Т.е никто нему не помешает изменить конфигурацию на "территории" другого провайдера. Если рассматривать коммутацию, то можно настроить изоляцию портов, а ещё проще вланы (ранее писал как вижу схему я). Но слышал, чтобы у кого-то из вендоров была реализована именно описанная задумка.
Эти пункты точно сейчас никак не выполнить:

- каждое "виртуальное устройство" не имеет доступа к портам другого "виртуального устройства";
- внутри каждого "виртуального устройства" доступны команды "освободить порт №", "занять порт № из списка свободных в пуле перемещаемых портов";
- отдельно формируется список "неперемещаемые порты", которые недоступны для команд "занять порт" и "освободить порт" изнутри "виртуальных устройств";
- в каждом "виртуальном устройстве" порты именуются по псевдониму (чтобы исключить возможность определения номера физического порта изнутри виртуального устройства);
- внутри "виртуального коммутатора" порты команды "освободить порт №" и "занять порт №" оперируют не физическим наименованием порта, а логическим названием/псевдонимом ("занять порт kvartira_5", "освободить порт kvartira_18");
- на главном устройстве присутствует функция запрета на просматр списка "свободных портов" изнутри "виртуальных устройств", чтобы провайдеры не могли подсматривать список не подключённых к интернету квартир, которых следует заспамить предложениями их услуг интернета.

4)
>А в сторону провайдера с коммутатора доступа отправляется явно не голый L2.
В сторону провайдера с коммутатора доступа именно L2. Шлюзом, как правило, является коммутатор агрегации. Между шлюзом и абонентом L2.
Допускаю, что есть провайдеры, у которых L3 на коммутаторе доступа, но таких единицы (я попытался вспомнить у кого из провайдеров видел такие конфигурации, и даже на ум ничего сходу не приходит)

[sandrew]

Извините, что вмешиваюсь в ваше обсуждение, но т.к. сам являюсь провайдером, то могу с уверенностью сказать: вероятность того, что провайдеры согласятся на подобную совместную эксплуатацию близка к "0".
В вашем случае, если вы просто хотите навести порядок в доме, то просто надо свести в один общий шкаф все абонентские линии и перенести в него коммутаторы всех провайдеров. Все будет красиво и каждый провайдер управляет своим железом.

[CSKT]

Извините, что вмешиваюсь в ваше обсуждение, но т.к. сам являюсь провайдером, то могу с уверенностью сказать: вероятность того, что провайдеры согласятся на подобную совместную эксплуатацию близка к "0".
В вашем случае, если вы просто хотите навести порядок в доме, то просто надо свести в один общий шкаф все абонентские линии и перенести в него коммутаторы всех провайдеров. Все будет красиво и каждый провайдер управляет своим железом.

Да, это хороший вариант.

Добавлю чуть совета:
- В шкафе установить патч-панели и завести туда все линии от квартир и видеокамер на патч-панели и подписать порты номерами квартир.

- Как выше сообщалось, пригласить провайдеров завести в шкаф их магистральные линии и установить коммутаторы доступа.

- ИТ-Представитель всех жильцов с провайдером будет короткими патч-кордами соединять/переподключать порты патч-панелей с портом коммутатора согласно новому договору оформления на подключение к интернету. Поэтому жилец должен заранее уведомить представителя о смене провайдера.

Минусы:
- провайдеры согласятся на такое?
- всё равно будет видно, к чьему коммутатору наибольшее кол-во патч-кордов будет подведено и будут предлагать к ним переходить.

Плюсы:
- не нужно тянуть дублирующие новые линии в квартиры
- В шкафу и в подъезде будет порядок.

[Богдан]

Извините, что вмешиваюсь в ваше обсуждение, но т.к. сам являюсь провайдером, то могу с уверенностью сказать: вероятность того, что провайдеры согласятся на подобную совместную эксплуатацию близка к "0".
В вашем случае, если вы просто хотите навести порядок в доме, то просто надо свести в один общий шкаф все абонентские линии и перенести в него коммутаторы всех провайдеров. Все будет красиво и каждый провайдер управляет своим железом.

Да, это хороший вариант.
...

Порядок с кабелями в подъезде - только один из этапов.

Один из примеров: Домовое IPTV-видеонаблюдение:

Состав узла на дом:
- NVR на 16 камер (резерв на 2 подъезда);
- система видеоаналитики (на будущее).

Состав узла на подъезд:
- 8 камер (IPTV, multicast);
- видеорегистратор NVR;
- POE-коммутатор.

Связь между узлами - через коммутаторы доступа, объединённые в кольцо в пределах дома.
Камеры заведены на POE-коммутатор. Один Uplink соединён с NVR. Второй Uplink выводит multicast с камер на коммутатор доступа.

Задачи:
- вывод Multicast для 8 камер всем жителям подъезда;
- на случай отказа локального NVR, все видеопотоки должны быть доступны на удалённом резервном NVR;
- по 2 камеры с подъезда должны быть доступны всем жителям дома;
- те самые "по 2 камеры с подъезда" должны быть доступны в кабеле службы ОТС (Оперативно-техническая связь - которая заведует ключами от лифтовых помещений), расположенной в соседнем здании;
- прямой доступ к IP-адресам NVR-ов ИТ-представителю дома.

Вопросы:
- согласитесь ли вы как провайдер иметь дело с клиентским IPTV/multicast через своё оборудование?
- будет ли клиентское IPTV/Multicast без дополнительной оплаты для клиента, в кабеле из провайдерского коммутатора?

Учитывая следующие факты:
1) все 4 провайдера, присутствующие в доме, предоставляют доступ в свою сеть через L2-на-BRAS;
2) в силу причиниы №1 соединения P2P исключены как класс и оборудование в половине провайдеров вообще не поддерживает Multicast (соотетственно, если провайдер таки согласится решить такую задачу, то всё видеонаблюдение направится кольцом через BRAS);
3) один из провайдеров на столько отстал от реальности, что применяет свич (16 портов по 100M, аплинк там не предусмотрен);
4) один из провайдеров (крупный!) - прокидывает витую пару из другого подъезда через крышу;
то доступ к собственному домовому IPTV-видеонаблюдению через единый интернет-кабель так и останется лишь фантазией жильцов.

Есть основания полагать, что закончится дело так:
- мелкий провайдер: "сервис хотите вы - вот вы и финансируйте соответствующую железку повышенным тарифом";
- остальные 3 крупных провайдера: "нет технической возможности" (ни оборудование не вывезет, ни схема сети не предусматривает, ни аплинков не хватает гонять клиентский мультикаст через BRAS) или "100-500 денег за ваш каприз".

Вопрос: на кой нам за свой счёт покупать каждому провайдеру по железке и большой шкаф, а затем ещё оплачивать лишнюю нагрузку на аплинки, если можно купить 1 железку на всех жителей подъезда сразу, сэкономив одновременно и на электроэнергии, и на габаритах и, если вдаваться в крайности, можно даже сэкономить на патч-панелях с коммутационным шкафом (да к тому же оборудование останется в нашей собственности)?

Из всех сложностей только одна непреодолимая - отказ провайдеров смотреть лицом в сторону клиента, готового за свой же счёт профинансировать последнюю милю до 1G/на клиента и 10G-Uplink/на подъезд, получив за это некоторые безоплатные сервисы на базе своего же оборудования.


И так будет с каждым "сервисом", будь до IPTV-видеонаблюдение, или несколько других, о которых умолчу, но которые ориентированы на эффективную работу именно на уровне последней мили, т.е. провайдер там больше как "поставщик интернета", нежели как интегратор (т.е. "третий - лишний")...


P.S. Если не найду эффективного технического решения, пока собираем стартовый капитал, будет банальное "кто первый согласился взять под своё крыло локалку дома - тот и остаётся". Остальные провайдеры уйдут сами за ненадобностью.
На крайний случай оформим "агентский договор" между нашим юрлицом и провайдером, и настроим всё сами...

P.S.2 Пока провайдеры придерживаться модели L2-на-BRAS-на-самом-простом-оборудовании, эффективной для роли "бюджетный провайдер интернета", до тех пор быть им именно "поставщиками интернета", а не интеграторами клиентских сервисов...
Не мы хотим чего-то "эдакого" - это провайдеры желают остаться в своём комфортном ПРОШЛОМ...

[asy]

P.S. Если не найду эффективного технического решения, пока собираем стартовый капитал, будет банальное "кто первый согласился взять под своё крыло локалку дома - тот и остаётся". Остальные провайдеры уйдут сами за ненадобностью.
На крайний случай оформим "агентский договор" между нашим юрлицом и провайдером, и настроим всё сами...

Тут будет проблема в согласии жильцов пользоваться услугами одного оператора. Если эту проблему решить получится, тогда возможно наверное. А если нет, то, кажется, нет механизма заставить разорвать клиента уже заключенный договор. Если только оператору невыносимые условия создать, но там могут быть проблемы с законом, что-то в конце прошлого года принимать собирались.

[Богдан]

P.S. Если не найду эффективного технического решения, пока собираем стартовый капитал, будет банальное "кто первый согласился взять под своё крыло локалку дома - тот и остаётся". Остальные провайдеры уйдут сами за ненадобностью.
На крайний случай оформим "агентский договор" между нашим юрлицом и провайдером, и настроим всё сами...

Тут будет проблема в согласии жильцов пользоваться услугами одного оператора. Если эту проблему решить получится, тогда возможно наверное. А если нет, то, кажется, нет механизма заставить разорвать клиента уже заключенный договор. Если только оператору невыносимые условия создать, но там могут быть проблемы с законом, что-то в конце прошлого года принимать собирались.

Учитывая мнимую разницу в тарифах и ничтожно малую разницу в перечне и качестве предоставляемых услуг - большинство обывателей легко поменяет провайдера уже в следующем расчётном периоде, особенно те, кто скидывается деньгами на общую сеть дома...
Остальные жильцы вынуждены будут только подвинуть свои кабели в централизированные межэтажные кабель-каналы (естественно - перепрокладка кабеля будет организована за счёт провайдера).

Так что у жильцов - никаких проблем.