BiTel

Поскольку вопросы и, в особенности, хотелки на счет VLAN-ов регулярно поднимаются (1, 2, 3, тысячи их), поэтому, пожалуй, стоит вскрыть эту тему.

Настала пора поговорить о VLAN-ах, а точнее о том, что в Бител есть некоторое недопонимание некоторых реалий в работе операторских сетей.
На данный момент БГБ видит и воспринимает сеть так:
При этом, если судить по документации, инет подразумевает, что всегда существуют AGENT_REMOTE_ID и AGENT_CIRCUIT_ID, но совершенно не понятно, что делать, когда речь идет не о сети с Option 82, а о простой и достаточно распространенной схеме сети с L2 connected subscriber, в которой Option 82 нет от слова совсем?
Давайте совсем немного усложним сеть, какой ее видит БГБ, например сделаем такой:
Т.е. VLAN абонента с VID 1000 мы, например на свиче агрегации, обвернем другим VLAN с VID 101, т.е. получим один "верхний", операторский влан и до 4k "нижних/внутренних", клиентских вланов.
В таком варианте в RADIUS прилетит не "NAS-Port-Id=1000", а "NAS-Port-Id=101:1000" и, собсно, негде взять ни AGENT_REMOTE_ID ни AGENT_CIRCUIT_ID.
Как прикажете авторизовать?
Как прикажете создавать подобный сервис в клиенте?
Кстати о о сервисе для клиента. Если создать простую операторскую сеть работающую по такой схеме:
Примерно с таким деревом
И, примерно, с таким типом сервиса



То как указать где "верхний" влан, а где "нижний"? БГБ при создании сервиса знает только про один тип вланов - "нижний/внутренний", а про остальные он слыхом ни слыхивал, как и о том, что для разных типов пользователей могут быть выданы разные диапазоны вланов.

Дискасс.

/summon Amir

такие вещи на вики лучше выкладывать....

а IP адреса у клиентов в описанной выше схеме статические?

Нет, динамические.
Статичным в подобной, как и в любой иной, схеме является только БГБ, который хранит в себе абонентов и все что с ними связано и свысока наблюдает за динамическим изменением окружающего его оборудования
Мой опыт общения с операторами показывает, что подавляющее большинство респондентов использует динамические адреса, а статику используют только в случае предоставления статических белых адресов.

Представьте, что это классическая схема "VLAN на пользователя", где все вланы пользователей стянуты в ядро.
Дело в том, что когда нет DHCP Relay и, соответственно, нет Option 82, то БГБ негде брать информацию о точке подключения абонента, хотя, при этом, в БГБ есть почти абсолютно все, что можно знать о сети. Почему "почти"?
В классической схеме, которую поддерживает БГБ для IPoE абонента в RADIUS прилетит нечто подобное:
И в этом случае в БГБ абсолютно все прекрасно работает, т.к. он, в текущем состоянии, целиком и полностью под это заточен.
В случае использования Q-in-Q в RADIUS прилетит такое - это реальный пакет с реального SE (в примере пакета выше я просто стер верхний тег):
На DHCP-Option можно не смотреть, т.к.

Как его авторизовать?
Можно проставить AGENT_REMOTE_ID и AGENT_CIRCUIT_ID на основе свича и порта из дерева, но, опять же, не ясно какого именно свича и какого именно порта?
Если мы хотим авторизовать по VLAN (у нас же "влан на пользователя", так что все вланы уникальны), то какой VLAN_ID проставлять? Как указать в клиенте или еще каким-либо иным образом сообщить БГБ, что VLAN 1000 находится внутри влана 101?



Представьте, что у вас этих "верхних" вланов не один, а штук 10 и в каждом из них живет по 1000++вланов и все они на одном NASе.
Самое обидное, что в БГБ прописано почти все, что нужно для однозначной идентификации пользователя и не хватает только понятия "верхний влан".

Могу предложить наверное самое простое, решение "тупо-в-лоб":
Необходимо в редакторе VLAN ресурсов добавить справа (дабы много не переделывать) от диапазона поле ввода вланов новое поле и обозвать его просто "S-VLAN" (это достаточно стандартное обозначение верхнего тега). Если это поле пустое, то это означает, что используется простое тегирование (как сейчас), а если оно не пустое или его значение < 1 (упаковать во VLAN с VID < 1 не реально) - это означает, что весь данный диапазон VLAN является C-VLAN.

Я пошел другим путем. Когда смотрел на всякие opt82 то волосы чуть не выпали, решили сделать просто как 2х2. У меня верхний и нижний влан подставляется в логин
и указывается в сервисе:

работает как часы

Схема работает второй год уже. Т.к адреса выдает радиус то с динамикой и статикой нет проблем вообще. В биллинге только 1 устройство это нас. Пользователю для индификации достаточно указать в логине пару верхний и нижний vlan. Все работает по radius. Про редактор vlan ресурсов согласен с snark, поле S-VLAN нужно добавить

2 zavndw:
Идея с логином в виде S-VLAN:C-VLAN - интересная.
А если в влан надо по дхцп отправлять больше одного ип-адреса ? Как из положения выходить в этом случае ?

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

во время тестов для одного влан выдавались больше чем 1 ip. Но до конца не разбирался, т.к тем кому делал нужно было именно 1 vlan - 1 ip выдавать. Они роутеры таким образом сбывают:)

Ага!
1 ип - один рутер.
2 ип - 2рутера + 1 "умный" свитч.
....
....
8 ип - ...+ 8U стойка.

Ахренительный бизнес. И как мы раньше не додумались об этом. Пойду, Dir-у "рацуху" подкину.

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

в принципе могу проверить, будет ли в моей схеме работать выдача пула адресов, надо стенд перенастроить

Тут основной вопрос, зачем вам хранить super-vlan на каждом клиенте? Не избыточно ли это ?
Т.е у вас будет 1000 клиентов с одним одинаковым super vlan 101 ? зачем дублировать эту информацию? Нельзя ли на устройстве в дереве где-то хранить что все что ниже и иерархии это 101 super vlan . И соответственно при поиске сервиса нам учитывать эту настройку устройства. Абонент же в конце концов привязан к конкретному конечному устройству, для которого однозначно выше по иерархии можно определить super vlan. Или у вас не такое однозначное дерево?

А вижу, у вас дерево такое, что nas-ы в другой иерархии, не в той, где свичи. А почему именно такое дерево ?

В вашей папке "папка свичей доступа" можно сделать сделать свичи агрегации (или папки), в которых указать vlan. Т.е почему бы все-таки не указать super vlan-где-то в иерархии, а не для каждого абонента. Это было бы оптимальнее - прописать в одном месте 101-ый super vlan, а не выбирать у 1000 разных абонентов один и тот же 101 super vlan . Вы же начнете ошибаться если вам нужно 1000 раз прописать 101 vlan и сами же попросите придумать решение как определять super vlan автоматом ( по иерархии или как-то еще) при добавлении абонента.

Я не против того, что вам нужен super vlan. Но кажется избыточным и неверным дублировать его для каждого абонента. На момент создания абонента мы откуда-то уже должны знать какой у него super vlan(по иерархии устройств или как-то еще) и не выбирать его заново.

Похожую логику тестировал для ISG+MPLS - абонент идентифицируется по IP, но адреса могут пересекаться в разных VRF. VRF в дереве устройств это виртуальное устройство, в конфигурации которого указаны связи с NAS-Port-Id, по этим связям ProtocolHandler добавляет AGENT_REMOTE_ID в запросы.

P.S. Но VLAN в BGB это все равно не VLAN, а неизвестно что. Вышел какой то идентификатор применимый только к PPPoE/etc услугам, при тарификации по netflow использовать невозможно.

попробую на стенде собрать

Этого совершенно не нужно! Супер влан достаточно хранить только, например, в категории вланов ну или, как вы уже правильно предложили, в дереве устройств.
Грубо говоря, необходимо его где-то указать, дабы напрочь исключить человеческий фактор или, как его иногда называют, синдром блондинки, т.е. когда оператором клиента биллинга является девочка, которая, собственно и создает сервисы, она даже физически не могла допустить ошибку, для чего мы в конфигурации указываем диапазоны влан и некий супер влан для каждого диапазона.
Например, когда подключение происходит в Уфе, то девочка выбирая диапазон вланов для района и нажимая "<<<", она автоматически проставляет влан, а БГБ точно знает, что для Демского района супер влан 101, для Калининского р-на - 102, для Кировского - 103 и т.д.


Даже больше, чем 1000 и у всех один супер влан.
При использовании схемы Vlan-per-user, если использовать диапазон вланов с 1000 по 4000 - это будет 3000 вланов, которые, если использовать 24-х портовые свичи, размажутся по 125 свичам в дереве.


Почему же нельзя? Можно! И, пожалуй, нечто подобное



Т.е. указание S-VLAN где-то в конфиге "агрегатора" нижестоящих свичей, будет самым правильным, наиболее логичным, решением.


Дерево для демонстрации было тупо взято из документации



Кстати, раз речь зашла о доке, то исправьте, пожалуйста, здесь двойное упоминание "radius.password.verification"

добавил в TODO

TODO - это, конечно, хорошо, но что делать сейчас?
RADIUS поймет, если используя "radius.servSearchMode=4" (поскольку VLAN-per-user, то авторизовать по VLAN - самое оно, не?) в предобработке тупо проставить VLAN как 101:1000, 101:1001, 101:1002 и т.д.?
Проще говоря: нид хелп по запуску инет, асап!
Тестовый стенд в наличии.

Так в чем проблема? В предобработке разбираешь Nas-Port-Id, убираешь "101:" из этого атрибута и по "101" находишь в дереве устройств подходящий корневой свич, добавляешь AGENT_REMOTE_ID в запрос. Делать это достаточно только для стартового пакета.
Приатачил свой ProtocolHandler, там несколько сложный алгоритм поиска "агента" через интерфейсы устройств в дереве и с учетом временного периода "активности" устройств, у тебя будет немного проще.

Ты сам знаешь где ускоряется решение вопроса:) всего 2 буквы

А вот https://forum.bitel.ru/viewtopic.php?f=44&t=11478 в туда же можно?
В TODO, в смысле.