BiTel

Порт абсолютно любого акцесного свича, может быть настроен, применительно к провайдингу, в 2-х разных режимах:
- access - для подключения конечных пользователей, попросту говоря компов;
- trunk - для подключения "свичей" (своих свичей, абонентов с VLAN-ами и т.п.).
Да, я знаю, что существует режим access+trunk, но речь сейчас не об этом.

В типе устройства, в sa.command.*, мы можем указать команды для создания сервиса, но этот сервис будет только одного типа (не в терминах БГБ) - либо access либо trunk.

Т.к., как об этом сказано выше, порт свича может находится как минимум в 2-х состояниях (access и trunk - это стандартное состояние порта абсолютно любого свича), то возможно, имеет смысл добавить возможность использования sa.command.1.*, sa.command.2.* ... sa.command.N.*.
Имея на руках такую конструкцию:
- в рамках одного типа устройства мы будем иметь несколько различных наборов команд для различных состояний порта свича этого устройства;
- в типе сервиса, простой ссылкой на номер sa.command, мы сможем указать какие именно команды необходимо применить для этого сервиса.

При текущем положении дел пока не понятно, как стандартными средствами сделать такое (для примера команд используется цисковский свич):

• Простым абонентам в договор добавляем сервис типа access, т.е., мы мы отправляем железке что-то такое:
  
  Код:
  interface GigabitEthernet $iface
   switchport mode access
   switchport access vlan $vlan
  
  Данный тип сервиса позволяет вести учет портов и вообще участвует во всех биллинговых делах (учет трафика и т.д. и т.п.).
  
  
• На служебный договор добавляем порты типа trunk, для чего отправляем железке что-то такое:
  
  Код:
  interface GigabitEthernet $iface
   switchport mode trunk
  
  Данный тип сервиса позволяет вести учет портов не занятых абонентами и конфигурить железо прямо из БГБ.

Проще говоря - надо иметь возможность в рамках одного типа устройства указать разные команды для разных сервисов связанных с одним устройством

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

Есть одно очень радикальное решение - библиотека устройств, с созданием для второги типа сервисов отдельного дерева, привязка того же терминального SA, но с другим набором команд. Тут всё будет работать, что говорится из "коробки"

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

Для D-Link, когда при добавлении порта в VLAN указывается только tagged/untagged это дело можно обыграть через deviceAttr (закладка Дополнительно в редакторе сервиса указывать параметр, скажем portMode) - тут вообще сервисы будут одного типа, а в командах подставляем макрос $deviceAttr(1). И если сегодня он access, а завтра нужен trunk будет, то просто меняем в сервисе значение параметра, а не закрываем текущий и создаем новый сервис.

Для CIsco немного разный набор команд для access/trunk. Помимо различных команд по типу сервисов можно модифицировать SA для выполнения разных(дополнительных) команд для одинаковых сервисов, но отличных по параметрам сервиса.

Не попало оно, потому что я забыл...

Выкладывается.

Спасибо!