BiTel

В некоторых, известных мне, биллинговых системах иерархия устройств устроена по другому. В них можно линковать устройства друг с другом, т.е. фактически строить карту сети, по которой потом можно пробросить влан от коммутатора доступа до коммутатора агрегации, если используется vlan на абонента. Здесь никаких намёков на это нет и приходится использовать gvrp



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

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

Всё бы было хорошо, но в сети есть порядка 40 свичей, на которых gvrp нет и добавлять такой фунционал разработчик не собирается.
1. Такие свичи приходится ставить в конец цепи, т.к. через них по gvrp vlan не прокидывается.
2. Если свич таки стоит в конце цепи, и средствами биллинга можно добавить на клиентском порту нужный влан аксессом и транком на аплинке (который всегда придется менять руками в каждом конкретном случае, либо вешать его на все порты, которые могут быть аплинковыми) то всёравно нужно будет заходить на свич, который стоит выше в цепи, создавать там влан и вешать его на порт, в сторону свича без gvrp.

Есть ли какие-то идеи как автоматизировать данный процесс? Заранее создавать на всех свичах вланы или отказыватся от схемы vlan на абонента предлагать не надо.

_________________
Сервер: вер. 7.0.1409 / 03.09.2018 20:20:58
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Хм, по мотивам NOC-проекта на НАГ-е ?
А автоматизировать создание вланов на свитчах длинк планируете с помощью snmp или telnet-а ?
В обоих случаях придется создавать и поддерживать все модели в "типах устройств" в актуальном состоянии( сменили прошивку, аппаратную версия или модель свитча ) - будте любезны корректировать .
Да и смысл дерева устройств в БЖБ несколько другой .

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

Этого nocproject'a?

btw, такого функционала в нём тоже нет и неизвестно будет ли вообще.


Телнет.



Я и так поддерживаю всё в актуальном состоянии. Все свичи приведены к той версии прошивки, где синтаксис комманд для них не отличается. Да и каких-то отличающихся друг от друга ревизий у меня нет/их мало. В каждом типе устройств свой набор команд для каждого типа сервиса. Всё уже настроено и условно работает, за исключением косяков в конфигах некоторых свичей.

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

_________________
Сервер: вер. 7.0.1409 / 03.09.2018 20:20:58
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

InetAccess и сейчас подключается к вышестоящим устройствам, если у них указан ServiceActivator.
Проблема, как я понимаю, только в том, что в ServiceActivator'е свича агрегации не будет информации на какой именно порт или порты (через которые подключен конечный коммутатор) добавлять VLAN.

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

Также можно создать в Справочники - Атрибуты Сущность, добавить туда текстовый параметр Порты подключения и указать эту сущность в типе устройства конечного коммутатора.
Далее на вкладке атрибуты устройства-коммутатора указать значение. В TelnetServiceActivator можно искользовать как $deviceAttr($servDeviceId,1).

Вообще думали сделать возможность привязки на вкладке Интерфейсы интерфейса к интерфейсу другого устройства. Но пока не просили такого, да и времени не было.

Кстати, а нельзя по MAC-адресу конечного коммутатора командами telnet на коммутаторе агрегации узнать, через какие порты подключен конечный?

Проблема не только в этом. Если у меня есть 2 разных коммутатора: коммутатор агрегации и коммутатор доступа, то ваше решение вроде подходит. Но таких мест на сети практически нет. Везде идут деревья:
Коммутатор агрегации -> коммутатор доступа -> коммутатор доступа -> коммутатор доступа
От одного коммутатора доступа могут быть включены сразу несколько других таких же. Конфиг таких коммутаторов выглядит примерно так:



Если я расположу их в дереве устройств не на одном уровне друг с другом, а подключенными друг от друга, то ничего дельного из этого не выйдет. Создавать для каждого свича, от которого что-то подключено, отдельное устройство с другими настройками - это вообще не вариант. Конкретно для этих ~40 свичей, конечно, можно делать какие-то вышестоящие устройства другого типа, если очень сильно захотеть (это как раз и получается тот костыль, который мне был нужен), но хотелось бы какое-то универсальное решение, чтобы в идеале можно было прокидывать влан целиком по всему пути статикой.


Это можно сделать на любом, известном мне, управляемом свиче. Разница будет только в выводе информации:

_________________
Сервер: вер. 7.0.1409 / 03.09.2018 20:20:58
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Кстати. А как сделать так, чтобы костыльный свич не участвовал в поиске сервиса, при запросах dhcp option82? Достаточно будет удалить все настройки связанные с dhcp, по типу dhcp.servSearchMode ?
Просто было такое, что я создавал 2 устройства с одним IP адресом и делал им разные типы и разные настройки, и когда прилетал запрос dhcp от клиента, биллинг искал сервис на том устройстве, у которого ID меньше, и из-за этого выбирал то, к которому сервис не привязан.

_________________
Сервер: вер. 7.0.1409 / 03.09.2018 20:20:58
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

up

_________________
Сервер: вер. 7.0.1409 / 03.09.2018 20:20:58
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45