Вот тестируем, к примеру, 25 порт. Тогда, на mes1124 это gi1/0/1, на mes2124 - gi1/0/25 и на mes2324fb - te1/0/1. На всех коммутаторах по 28 портов - 24 "абонентские", 4 - под под аплинки. Настоящие номера будут 49, 73 и 105.
Не хотелось заводить промежуточное звено. Данные ведь все известны - порт из запроса, смещение из описание модуля. Причем смещение должно быть двухступенчатым. Стекирование мы не используем в принципе.
Не хотелось заводить промежуточное звено. Данные ведь все известны - порт из запроса, смещение из описание модуля. Причем смещение должно быть двухступенчатым. Стекирование мы не используем в принципе.
А что такое тогда "в обвязке"? Под промежуточным звеном я имел ввиду - посылаем запрос, он принимается и в зависимости от коммутатора модифицируется и отдается ядру. Этакая трехзвенка.
к примеру, есть задача выключить порт абоненту. в биллинге это порт №1. делаем два запроса к коммутатору: забираем ShiftIndex и следующим запросом выключаем порт, указав индекс 1+ShiftIndex.
в модулях и в ядре всевозможных костылей все равно не учтешь. какая то логика нужна снаружи. именно поэтому сам движок это просто движок. так функционал в итоге гибче. но и сложнее, не спорю
Я не отрицаю, что оно все работает. Но "костылей" для нормализации входных данных всего два - для номера порта и vlan, больше не придумать. И подмена на лету запроса (ведь она все равно есть в prepare_oid, только в виде раскидывания параметров) логично бы смотрелась в ядре.