Каким образом организовать подключение оконечных устройств в несколько вланов?

Абонентские порты не должны принимать и слать тегированный трафик. Для проброса к абоненту трафика из влана с мультикастом на коммутаторах бывает поддержка технологии MVR(у каждого вендора своё название)

не обязательно. Телефоны часто имеют два порта, в один берут tag pc + untag phone, со второго растегируют и шлют трафик компу чтоб на один кабель и телефон и комп вешать.

И много провайдеров так подключают абонентов? То что вы пишите верно для сети предприятия, в провайдерских сетях так не делают(как минимум потому что обычно провайдерам нет никакого смысла какие-то там телефоны абонента в отдельный влан включать)

да делают они если хорошо попросить. понятно что всем подряд это нафиг не надо, но если ну очень хочется - то могут. за деньги, разумеется

Получается, тогда на коммутаторе доступа порты 1-27 оставить в первом влане? Как тогда отключать абонента, если у него закончились средства? Если блокировать на маршрутизаторе, то абонент всё равно сможет пользоваться локальной сетью. Использовать ACL?

Включать отключать сервис лучше всего на сервере доступа который взаимодействует с биллингом например по RADIUS. Пытаться сделать всё на свитчах - плохая идея.

да делают они если хорошо попросить. понятно что всем подряд это нафиг не надо, но если ну очень хочется - то могут. за деньги, разумеется

Они конечно могут, вот только не совсем понятно зачем абоненту(тому самому который не подряд) провайдера просить изолировать собственный телефон от себя же.

Смысл voip vlan есть в сети предприятий где администратор хочет выделить все _свои_ телефоны в отдельный влан в _своей_ сети, для удобства и «улучшения безопасности».

Кстати vlan 1 лучше не использовать для трафика, тк некоторые свитчи любят весь броадкаст который в нем есть слать на процессор. Потому в vlan1 можно делать управление(но лучше не нужно), а для абонентов использовать какой-то другой номер.

Хорошо. А MVR даёт возможность получать мультикаст только тем, кому это разрешено? Ведь если клиенты в одном влане, то как только один из них запросит мультикаст (пусть из другого влана), он повалит всем.

MVR копирует мультикаст поток непосредственно на порт(а не в vlan) который его попросил(и не весь, а только нужный канал). Но контроль доступа придется делать таки на свитчах, если вы желаете продавать этот сервис отдельно. Некоторые свитчи сразу могут слать запрос в радиус при подписке на группу. Но стоит крепко подумать прежде чем запускать iptv именно мультикастом - для начала посчитать какой процент абонентов будет пользоваться этим сервисом, тогда увидите будет ли вообще экономия от мультикаста. В пользу отказа от мультикаста - более широкий выбор коммутаторов доступа(потенциально меньшие затраты на них), тк не нужно будет учитывать «особенности» работы каждой модели + работа с любыми роутерами на стороне абонента без проблем и костылей.

Вообще в данном случае первично именно IPTV - кабельный телевизионный оператор желает перевести абонентов на цифру. Разумеется, никто не мешает дуть в кабель обычный DVB-C (и так делают в данный момент), но желают и вариант с set-top box'ами, OTT и прочими новомодными плюшками. Ибо конкуренты. Клиентов - несколько тысяч. Ну а поскольку всё равно многие кабельные сети надо менять из-за физического износа, то решили заодно попробовать и сеть передачи данных сделать. Ситуация осложняется отсутствием специалистов по сетевому оборудованию в принципе. Они как бы есть, но работают у прямых конкурентов, а фирм-подрядчиков, которые бы сделали сеть «под ключ», в регионе не имеется. Я вообще просто товарищ главного инженера, который попросил помочь.

понятие «провайдер» растяжимо. В складском комплексе провайдер часто предоставляет телефоны арендаторам.

Хочется организовать несколько вланов, например, 100-й - для интернета/локального трафика, 500-й - для iptv с мультикастами, 4000-й - для управления самими коммутаторами.

Рекомендую еще разделить группы пользователей (если их несколько сотен и более) по группам IP (/24 например) и каждую повесить влан (критерий разделения может быть разным. Например: по улицам и по типу пользователя (физик/юрик) и.т.д. ) - будет лучше управляемость и меньше проблем с вирусняком.
Ну и ACL на свитчах (если поддерживается) не забывай - полезная штука для запрета всякого мусора, гуляющего в сети.

понятие «провайдер» растяжимо. В складском комплексе провайдер часто предоставляет телефоны арендаторам

В таком случае в порт коммутатора, включается не абонент, а телефон администрируемый провайдером(в рамках сервиса телефонии), таким образом понятие «Абонентский порт», о котором я говорил, неприменимо к такому порту. Мне кажется вы пытаетесь высосать из пальца кейс чисто чтобы опровергнуть моё первое сообщение. Уж лучше бы рассказали про dot1q tunnel - это куда как более реальный пример(ну правда к вопросу ТС он не имеет отношения).

Если уж делать так, то можно и vlan per user замутить, со всякими option 82 и dynamic arp inspection. Правда, я не знаю что будет в случае, если число пользователей превысит максимальное число вланов.

Рекомендую еще разделить группы пользователей (если их несколько сотен и более) по группам IP (/24 например) и каждую повесить влан (критерий разделения может быть разным

+1

Можно поступить более радикально - vlan per user, терминировать всё это дело например на линуксах с accel-ppp. Из плюсов - дешевый доступ, подойдут практически любые управляемые коммутаторы(тк все умеют вланы). Из минусов - на аггрегации/в ядре при большом кол-ве абонентов нужен будет q-in-q.

Однако это конечно фантазии, тк масштабы и хотелки ТС никому не известны.

суть vlan per user в том, что всякие option 82 и dynamic arp inspection как раз не нужны, потому свитчи на доступе должны уметь только лупдетект и вланы.

Правда, я не знаю что будет в случае, если число пользователей превысит максимальное число вланов.

И тут на помощь приходит Q-in-Q

Кстати идеи о локальной сети лучше сразу забыть. Я конечно не знаю какие у вас условия и рынок, но нынче процент абонентов которым это нужно минимален, а гемороя добавляется. Потому даже если не делать vlan-per-user - лучше всего сразу включать изоляцию портов везде где это можно.

Не-не-не, никаких PPP и прочих впнов. Человек должен воткнуть шнурок в девайс и оно должно работать без дополнительных телодвижений.

А где я говорил про ppp? Вероятно вам смутило accel-ppp, однако этот софт работает и с IPoE, просто название никто не менял. В этой схеме его можно использовать для удобной терминации vlan-per-user

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

А, окей, тогда посмотрю что это и как его можно приспособить.

это в республике Беларусь так?

Вы бы более подробно описали масштабы и задачи.

Пример трубочек скинешь годных таких?

Да, в ней. Масштабы - один райцентр, 60 тысяч населения, второй райцентр, такой же примерно, и клубочек кабельных сетей в столице. Точных цифр не знаю, но в первом райцентре порядка 10-15 тысяч абонентов кабельного телевидения. Цифровое вещание запустили одними из первых в республике (и в эфир, и в кабель), а вот с интернетом дотянули до того, что из областного центра пришёл крупный оператор и махом откусил солидный кусок клиентской базы, предоставляя и телевидение, и интернет. С другой стороны начал щемить государственный оператор, предоставляя ADSL, а по нему заодно опять же цифровое телевидение (сейчас адсл уже отмирает потихоньку, в спальных районах его меняют на оптику до квартиры, но частный сектор на нём ещё долго будет сидеть). На этом фоне местному кабельному оператору стало совсем кисло, и его государственную долю продали латвийским инвесторам. Те заодно прикупили мелкую столичную кабельную сеть, второй райцентр, где уже имеется недоделаная сеть передачи данных на ручном управлении, и поставили задачу сделать быстро, дёшево и сердито. Ну и по более-менее современным технологиям.

Таким образом, будет три географически далёкие сети, в которых необходим единый биллинг и единообразное управление. Ядро сети (в частности, маршрутизатор) скорее всего Mikrotik cloud core. Это на данном этапе не обсуждается, ибо латыши заявили, что хотят поддерживать своего производителя, плюс в другом райцентре на нём уже работают. Коммутаторы - DCN, SNR либо ещё что-то китайское или российское. DCN я в данный момент ковыряю, и если тот, который подороже, работает без нареканий, то тот, который подешевле, после включения показал 15% cpu utilization в консоли. Длинки стояли у конкурента, они их сейчас снимают и меняют как раз на DCN. Огребли каких-то проблем, но каких именно - не знаю.

Оптика по городу уже лежит, с запасом - успели положить до кризиса, когда только начали внедрять цифровое вещание. Так что с «магистральными» каналами проблем нет. На коммутацию планируют ставить по одному свитчу на три подъезда. Затем это агрегируется на районных коммутаторах и после этого идёт на ядро. Ядро - коммутатор и маршрутизатор. Маршрутизатор раздаёт юзерам инет, в коммутатор же воткнут шнурок, по которому идёт мультикаст со станций вещания - примерно 300 мбит/сек. В перспективе ещё и всякое fullhd, и видео по запросу, так что будет больше. Для инета уже куплены блоки внешних адресов, по /32 на оператора. Заодно хотим для полного счастья выдавать абонентам ipv6, благо в этом году национальный оператор клятвенно обещает его внедрить. Но сначала хотя бы с ipv4 разобраться - юзеров придётся садить за нат и выдавать по адресу на несколько абонентов. Поскольку локальный ip-адрес одному абоненту будет присваиваться один и тот же, можно будет равномерно распределять абонентов по внешним адресам. У конкурентов двойной нат, во втором райцентре на 17 адресах полторы тысячи абонентов, так что будем думать. По поводу локалки уже озвучил - тот же дц-хаб может здорово снизить нагрузку на внешние каналы, особенно если будем поощрять активных пользователей - скачал новинку, выложил - получи бонус к интернету.

Таким образом, нам надо выпускать людей в инет, дать им возможность обмениваться трафиком внутри сети и смотреть цифровое телевидение по одному кабелю и без заморочек со всякими pptp, l2tp и тому подобным. Абонентам будут выдаваться домашние роутеры (скорее всего tp-link) и set-top боксы. Все три сети надо привести к единому виду и централизованному управлению. Более подробно описать вряд ли могу, потому что опыта в проектировании сетей нет. Разве что архитектура сети - классическая звезда с тремя уровнями: коммутация, агрегация, ядро.

тебе дект или настолки? Настолки почти все умеют, у нас были аастровские 44xx и 67xx (дороговато, но вся инфраструктура на аастрах была). Сиськи вроде умеют, но без сиськостанции я бы брать не стал, их сип это особый, уличный сип, там даже инвайт переписан. Грандстрёмы точно умеют почти все.

Из дектов вроде умел какой-то зухель, страшный как срань. Нашел, P-2300RDL EE.

Да просто посмотри в маркете том же или на сайте производителя. Если два порта - скорее всего именно такая схема

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

Если идти таким путем - свитчи на доступе должны уметь mvr, на аггрегации и в ядре - q-in-q. Dlink на самом деле очень неплохой вариант, по крайней мере они стараются фиксить проблемы оперативно.

Можно впрочем и не делать q-in-q, но тогда коммутаторы должны уметь кучу всего - dhcp option 82, развитые acl и прочие вещи такого рода.

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

PS: Описываемые вами 15% cpu utilization ничего не значат и могут не являться проблемой сами по себе, тот же длинк dgs-3120 меньше 21% cpu не показывает, что не мешает ему отлично работать. Свитчи ведь не процессором трафик коммутируют.

Мне настолки интересны. Понял. Спасибо, весьма, весьма ценная информация. В телефонии я нуб тот ещё...

Не знаю, на микротиках народ вполне успешно делает граничные маршрутизаторы. Полторы тысячи абонентов даже при пиковых нагрузках, когда трафик достигает 600 мбит/с, не оказывают существенного влияния на микротиковский low-end роутер. Проблемы начинаются, если загнать туда списки контроля доступа (в Беларуси тоже блокируют сайты), что-то около 6000 правил. Их он обрабатывает на процессоре и загрузка сразу лезет вверх. Какого-то аналога ipset я не нашёл там, но толком ещё и не искал.

Биллинга нет, есть какая-то древняя софтина родом из девяностых, на фокспро. Биллинг выбирают другие люди. Отдельная железка будет под кусок биллинга, DHCP, радиус. Сам биллинг, скорее всего, будет крутиться где-то в интернете, так как надо связать воедино три филиала.

Покопавшись, завёл muticast vlan registration на свитче Eltex, а вот на DCN - ни в какую. Отписал поставщикам, те посоветовали включить pim dense-mode, которого на этих коммутаторах нет (как и multicast routing). По крайней мере, у них в командах даже близко ничего похожего нет (хотя в документации описано, но документация там одна на целый парк моделей). Vlan per user ни мне, ни моему товарищу не сильно хочется заводить - гонять внутрилокальный трафик через ядро, не иметь возможности поднять в локалке свой сервис... Лично мне хочется сеть, к которой я сам захочу подключиться. Ставить на коммутацию продвинутые свитчи не проблема, сейчас, по-моему, вообще не осталось «тупых» коммутаторов. То есть они есть, но по цене практически не отличаются. У длинков вроде бы проблемы с мультикастом как раз и ещё с автоматическими счётчиками электричества (которые считают, сколько потребил сам свитч, для энергосбыта). Поэтому у другого оператора их и поменяли на dcn'ы.