среда, 23 сентября 2015 г.

SnmpB - MIB-браузер

Потратив не один час на поиски нашел неплохой MIB-браузер под Windows - SnmpB. Он слегка подзаброшен (не обновляется с 2013 года), но при этом неплох. Отличительная особенность программы в том, что она не требует Java. Большинство других, в т.ч. iReasoning MIB Browser требуют Java для работы.

Небольшой баг программы - она не умеет работать с очень длинными путями к каталогам с файлами с MIB. Добавив несколько каталогов с путями вида ..\usr\share\snmp\mibs\DES-3200_R4.39_MIB_20150306\proprietaryMIB\Dlink-common-mgmt\ долго не мог понять почему программа не видит MIB'ы в основном дереве. Когда уменьшил путь все стало нормально.


По сравнению с браузером от iReasoning браузер SnmpB не имеет ограничения в 10 одновременно подключаемых MIB-файлов. В первом это ограничение очень чувствовалось. Но и минус тоже есть - все пути нужно прописывать явно, диалогового окна выбора нет.

Тем не менее, на данный момент это мой выбор для работы с MIB-файлами под Windows.

понедельник, 31 августа 2015 г.

Несколько слов о QoS в D-Link

Есть некоторая путаница в этих терминах - QoS, CoS, ToS. По-видимому, это связано с историческими причинами, по большей части. Поэтому имеет смысл пояснить термины в двух словах.

QoS (Quality of Service — качество обслуживания) - общие соглашения об качестве трафика, которое в QoS определяется полосой пропусканий, задержкой при передаче, отклонениями при передаче (джиттер) и потерей пакетов. То есть это некое обобщенное название.

CoS (Class of Service) — поле из 3 бит в теге 802.1q Ethernet-кадра. Метод указания приоритета этими битами описывается в стандарте 802.1p.

ToS (Type of Service) — поле в IP-заголовке (1 байт). Предназначено для маркировки трафика на сетевом уровне.
Байт ToS состоит из 6 бит DSCP (Differentiated Services Code Point) и двух бит ECN (Explicit Congestion Notification). При этом ECN занимает младшие два бита и предназначено для явного уведомления о перезгрузке канала, а DSCP занимает старшие 6 бит и определяет приоритет пакета.

Коммутаторы DES-3028/DES-3200-xx (и не только) поддерживают управление трафиком на основе меток 802.1p и DSCP и позволяют выделить нужную полосу пропускания для приложений, критичных к задержке трафика, за счет меньшей скорости передачи остального трафика. Для этой цели используются "очереди". Коммутаторы DES-3028 имеют 4 очереди (от 0 до 3), а последние коммутаторы DES-3200-xx/C1 - 8 очередей (от 0 до 7). Каждый пакет, а, вернее, фрейм, попадает в одну из этих очередей по следующей схеме:
  • В случае наличия метки 802.1p - на основе этой метки.
  • В случае отсутствия метки 802.1p - на основе 802.1p default_priority для каждого порта.
  • В случае включения dscp trust - согласно dscp map .. dscp_priority (при этом метка 802.1p игнорируется).

То есть можно выбрать, направлять трафик в очереди либо по метке 802.1p, либо по DSCP. Лично я предпочитаю использовать DSCP, так как соответствующий байт в трафике очень легко посмотреть, чего не скажешь о 802.1p. Поэтому при использовании DSCP очень легко убедиться, что трафик "покрашен" как надо. И, напротив, очень сложно сделать это в случае использования 802.1p.

Так или иначе, в "очереди" попадает любой трафик, а не только "покрашенный". Дальше коммутатор должен этот трафик передать дальше при помощи одного из двух механизмов. Ниже приведена небольшая выдержка из официальной документации D-Link:
 
При использовании строго режима (Strict mode) обработки очередей пакеты из очереди высшего приоритета всегда обслуживаются первыми. Опустошение очередей происходит, строго следуя их приоритетам. Только тогда, когда очередь более высокого приоритета пуста, обслуживаются пакеты с более низким приоритетом.

В случае использовании взвешенного кругового режима обработки очередей (weighted round robin, WRR) количество пакетов, отправленное из каждой очереди, определяется присвоенным ей взвешенным коэффициентом.


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

Пример настройки DES-3200-28/C1:
config scheduling_mechanism strict
config dscp trust 1-28 state disable
config dscp trust 25 state  enable


Первая строка включает механизм strict, вторая - выключает приоритизацию DSCP на всех портах (переключает на 802.1p), а третья - включает ее на 25-м порту (предполагается, что это uplink-порт).

вторник, 21 июля 2015 г.

Uplink без метки 802.1q и неверный PVID

Данная заметка содержит описание проблемы «нетегированного» аплинка и потери доступа к коммутатору при загрузке конфигурации, где меняется PVID на магистральных портах. Описан способ, которым можно попытаться вернуть доступ к устройству.
 
(Заметка является адаптированной под блог статьей из корпоративной wiki)

Суть проблемы


Чтобы пользователи не могли генерировать фреймы с меткой 802.1q на коммутаторах включается функционал Ingress Checking, который проверяет поступающие фреймы на «попадание» в допустимый vlan. При этом, правда, перестает работать LLDP, т.к. Ingress Checking проверяет и такие пакетики. Чтобы LLDP заработал, на порту должен быть PVID реально существующего VLAN. Поскольку настраивать каждый коммутатор с учетом его собственных VLAN неудобно и, поскольку в моей сети есть multicast vlan, который одинаковый на всех устройствах, то PVID на магистральных портах приравнивается к ID мультикаст-vlan'а. Этим зайцем убиваются все выстрелы (или наоборот) и все работает как задумано.

Проблема появляется тогда, когда сеть управления на стыковочных портах отдается без метки 802.1q, то есть «антегом» (в моей сети такая ситуация - результат ошибки при настройке; при правильной настройке стыки всегда «тегированные»). В этом случае на порту коммутатора PVID равен ID управляющего VLAN. После загрузки новой конфигурации он становится равен 50 (ID моего мультикаст-vlan'а). Доступ к коммутатору при этом пропадает.
 

"Куда нажать?"


Чтобы поднять коммутатор без отправки на ремонтника потребуется сделать финт ушами. Для этого неплохо сначала поскрести по сусекам и отыскать конфигурацию недоступного коммутатора.

Так, например, нас интересуют строчки:

enable pvid auto_assign
config vlan default delete 1-28
config vlan default add untagged 25
...
config ipif System vlan default ipaddress 10.99.91.13/25 state enable


Нетрудно догадаться, что при применении к ним команды из нового конфига:

config gvrp 25-28 pvid 50

Доступ к коммутатору будет потерян.

Как выйти из этой ситуации?

Подсказка: Несмотря на неправильную настройку VLAN, порт 25 по прежнему member в default vlan! Этим и надо воспользоваться! 

Необходимые условия


Чтобы получить доступ нужно кое-что перенастроить:
  • На вышестоящем устройстве получить интерфейс из сети проблемного коммутатора и в таком же VLAN.
  • Настроить управляющий VLAN недоступного коммутатора на стыковочном порту вышестоящего коммутатора как tagged.
  • Проверить, чтобы PVID на стыковочном порту был равен ID управляющего VLAN недоступного коммутатора.
Теперь можно попробовать обратиться с доступного интерфейса на «потерянный» коммутатор. Он должен быть доступен.

Шта?


Как все это работает?
  • Фрейм с доступного хоста в управляющей сети недоступного коммутатора отдается в стыковочный порт с меткой 802.1q.
  • Поскольку на недоступном коммутаторе порт все еще является member данного VLAN, то фрейм попадает в управляющий VLAN и неправильный PVID здесь не помеха, т.к. он оказывает влияние только на фреймы без метки 802.1q.
  • Обратный фрейм с недоступного коммутатора отдается в стыковочный порт без метки 802.1q, т.к. изначально данный порт был настроен как untagged для управляющего VLAN.
  • На доступный коммутатор этот фрейм заворачивается в управляющий VLAN благодаря заранее установленному PVID.

Таким вот способом можно «достать» недоступный коммутатор без его перезагрузки ремонтником.

Подсказка: При манипуляциях с интерфейсом System на вышестоящем коммутаторе желательно запланировать перезагрузку через 5-10 минут и постоянно сдвигать ее. Это поможет получить доступ к данному коммутатору, когда вы ошибетесь. :) 

суббота, 11 июля 2015 г.

Небольшие обновления Briseis и Dracon

Немного отвлекся от монстров в Diablo и обновил свои проекты Briseis и Dracon.

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

Еще удобно использовать переменную {$target}, которая будет заменена на IP-адрес коммутатора. Я добавил этот шаблон в конфиг:
config snmp system_name {$target}
И теперь по LLDP вижу не только MAC соседнего коммутатора, но и его IP (т.к. по LLDP передается system name)

Briseis теперь удобнее использовать для управления командами выгрузки и загрузки конфигурации, благодаря возможности сделать паузу между отправкой set-команд.

Я сделал такую последовательность SNMP-команд:
  1. Сохраняем конфигурацию в памяти коммутатора.
  2. Выгружаем конфигурацию на сервис Dracon.
  3. Получаем новую конфигурацию с сервиса Dracon.
Между каждой командой проходит 5 секунд, чтобы дать коммутатору время сделать свои дела и не получить ошибку с сообщением, что файловая система занята. Затем пишем в статистику, завершаем цикл и 2-3 секунды ждем до начала нового. Итого общее время на проход я выставил в 20 секунд. За раз из базы выбирается 10 коммутаторов. Получается в минуту сохраняются, бекапятся и обновляются 30 коммутаторов.

Как буду уверен, что новый конфиг применяется корректно, то обновлю все устройства по всей сети. Сейчас же обновил около трех сотен, для проверки самого механизма обновления через Briseis и Dracon.

пятница, 3 июля 2015 г.

Show log? No entry!

Случайно заметили проблему на коммутаторе DGS-3120-24SC - при попытке посмотреть лог командой show log устройство весело рапортовало No entry! Обновление ПО и перезагрузка не помогли. Решение, впрочем, нашлось довольно быстро при помощи Яндекса. Описано оно тут. Все, что нужно сделать, это выполнить команду clear log. Теме 6 лет, между прочим!

Очередной раз налицо подтверждение тому, что все новое - хорошо забытое старое. Век живи - век учись! :)

пятница, 19 июня 2015 г.

Разработка ACL для DES-3200-28/C1

Недавно наконец-то закончил разбираться с ACL-ками для ревизии C1. Коммутаторы DES-3200-28 этой ревизии являются самыми распространенными в моей сети - их число приближается к 900. Долгое время они не имели вообще никаких ACL - ситуацию спасали сегментация трафика и влан-на-коммутатор - но хотелось дополнительной защиты от потенциального спуфинга.

Итак, задачи, которые должны решать ACL:

  • Блокировка трафика от абонентов к сетям управления.
  • Блокировка определенных портов для предотвращения доступа к общим сетевым ресурсам.
  • Блокировка неправильных ARP-пакетов от абонентов (в целях предотвращения ARP-spoofing'а).
  • Блокировка IP-пакетов с поддельными SRC IP-адресами (IP-Spoofing) в целях предотвращения DDoS-атак и исчерпания пула NAT.
  • Отправка приоритетного трафика (телевидение) в определенную очередь (резервирование полосы пропускания).
  • Блокировка мультикаста от абонентов.
  • Разрешение любого трафика с порта (включается вручную).
На коммутаторах ревизии C1 логика работы ACL менялась в процессе разработки ПО. В результате этого не вся информация, приведенная на форумах и в официальных презентациях, является актуальной.

Сейчас все выглядит так:
  • На коммутаторе может быть всего 4 ACL профиля, причем 2 из них уже созданы - это Ethernet и IP.
  • Можно создать еще два профиля на выбор из набора Ethernet, IP, IPv6 и PCF, причем PCF профиль может быть всего один.
  • Кадр сопоставляется с правилами последовательно, так, как идут правила в профилях. Профили тоже проверяются последовательно. То есть все точно также, как и на других моделях.
  • В PCF правила можно добавлять до 4-х chunk по 4 байта каждый.
Ограничения по количеству профилей накладывают ограничения и на общую структуру правил. То есть, если один чанк уже был использован с одной маской, то именно в эту маску именно в этом профиле и придется уложить все правила, где проверяются соответствующие чанку байты.

Примечание: Соответствие chunk и байт смотри тут.

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

Конкретно замедитировав, я остановился на следующей логике:
  1. Профиль #1 (vip): Безусловно разрешается трафик для нужных портов. Настраивается исключительно вручную и при необходимости.
  2. Профиль #2 (vlandscp): Разрешается трафик для управляющих и служебных сетей (коммутаторы, камеры, wi-fi). Меняется приоритет правильным мультикаст-группам.
  3. Профиль #3 (security): Запрещается мультикаст от абонентов и некоторые не очень хорошие TCP порты
  4. Профиль #4 (pcf): Запрещается трафик к служебным сетям от абонентов. Разрешаются только корректные ARP и source IP. Остальные ARP и IP для абонентов блокируются.

После разбирательств с QoS и идеи вообще не фильтровать трафик на служебных портах профиль №2 потерял свою актуальность. Здесь я оставлю его просто в качестве примера правил.

Профиль vip:
create access_profile profile_id 1 profile_name vip ethernet source_mac 00-00-00-00-00-00
#to manually allow any traffic for port X add following rule:
#config access_profile profile_name vip add access_id auto_assign ethernet source_mac 00-00-00-00-00-00 port X permit


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

create access_profile profile_id 2 profile_name vlandscp ip destination_ip_mask 255.255.248.0 vlan 0xFF0
#allow vlans with tag 0-15, 16-31 (management) 448-463, 464-479 (wi-fi), 576-591 (cams 586)
config access_profile profile_name vlandscp add access_id auto_assign ip vlan_id 1 port all permit
config access_profile profile_name vlandscp add access_id auto_assign ip vlan_id 16 port all permit
config access_profile profile_name vlandscp add access_id auto_assign ip vlan_id 448 port all permit
config access_profile profile_name vlandscp add access_id auto_assign ip vlan_id 464 port all permit
config access_profile profile_name vlandscp add access_id auto_assign ip vlan_id 576 port all permit
 

#replace priority on multicast groups in range 239.1.8.0/21
config access_profile profile_name vlandscp add access_id 64 ip destination_ip 239.1.8.0 port [up] permit priority 6 replace_dscp_with 48
config access_profile profile_name vlandscp add access_id 64 ip destination_ip 239.1.8.0 port [pu] permit priority 6 replace_dscp_with 48


Если профиль vip имел тип ethernet, то vlandscp имеет тип ip (оба эти профиля зарезервированы и уже созданы системой). В последнем случае профиль создан с destination_ip_mask для сетей /21 и диапазона из 16 vlan. Последнее достигается из-за использования бинарной/неполной маски 0xFF0.

Первые 5 правил разрешают трафик в 5 диапазонах из 16 служебных vlan. Следующие два правила отправляют телевидение в 6-ю очередь и переписывают метку dscp.

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

Фактически весь трафик попадает под обработку только двух оставшихся профилей - security и pcf.

Профиль security:

create access_profile profile_id 3 profile_name security ip destination_ip_mask 240.0.0.0 tcp dst_port_mask 0xFFFF
#deny multicast from subscribers
config access_profile profile_name security add access_id auto_assign ip destination_ip 224.0.0.0 port [ss] deny
#deny TCP 135,139,445,2869,3587,5357,5358
config access_profile profile_name security add access_id auto_assign ip tcp dst_port  135 port [ss] deny
config access_profile profile_name security add access_id auto_assign ip tcp dst_port  139 port [ss] deny
config access_profile profile_name security add access_id auto_assign ip tcp dst_port  445 port [ss] deny
config access_profile profile_name security add access_id auto_assign ip tcp dst_port 2869 port [ss] deny
config access_profile profile_name security add access_id auto_assign ip tcp dst_port 3587 port [ss] deny
config access_profile profile_name security add access_id auto_assign ip tcp dst_port 5357 port [ss] deny
config access_profile profile_name security add access_id auto_assign ip tcp dst_port 5358 port [ss] deny


Сначала блокируется multicast с абонентских портов, после чего блокируются некоторые не очень нужные абоненту TCP-порты. В моем случае блокировка TCP-портов несколько избыточна, но я решил оставить ее на всякий случай. Остальной трафик для обнаружения сетевых ресурсов будет заблокирован из-за сегментации трафика, ACL на маршрутизаторе и vlan, ограничивающегося коммутатором.

Ну и самый интересный профиль - pcf:
create access_profile profile_id 4 profile_name pcf packet_content_mask offset_chunk_1 3 0xFFFF offset_chunk_2 7 0xFFFFFEF8 offset_chunk_3 8 0xFFF80000
#deny networks 172.16.0.0/13 and 10.99.0.0/13 for subscribers
config access_profile profile_name pcf add access_id 8 packet_content offset_chunk_1 0x0800 offset_chunk_3 0xAC100000 port [ss] deny
config access_profile profile_name pcf add access_id 9 packet_content offset_chunk_1 0x0800 offset_chunk_3 0x0A600000 port [ss] deny
#allow specific source network (10.XX.YY.port_N*8 0.0.1.7) for a customer
config access_profile profile_name pcf add access_id
auto_assign packet_content offset_chunk_1 0x0800 offset_chunk_2 0x0A(fn_2oct#custom1)(fn_3oct#custom1)08 port  [ss#1] permit
config access_profile profile_name pcf add access_id
auto_assign packet_content offset_chunk_1 0x0800 offset_chunk_2 0x0A(fn_2oct#custom1)(fn_3oct#custom1)10 port  [ss#2] permit
...
#permit ARP with correct 4th octet (between port_N*8 and port_N*8+7)
config access_profile profile_name pcf add access_id
auto_assign packet_content offset_chunk_1 0x0806 offset_chunk_3 0x(fn_3oct#custom1)080000 port  [ss#1] permit
config access_profile profile_name pcf add access_id auto_assign packet_content offset_chunk_1 0x0806 offset_chunk_3 0x(fn_3oct_p1#custom1)080000 port  [ss#1] permit
config access_profile profile_name pcf add access_id auto_assign packet_content offset_chunk_1 0x0806 offset_chunk_3 0x(fn_3oct#custom1)100000 port  [ss#2] permit
config access_profile profile_name pcf add access_id auto_assign packet_content offset_chunk_1 0x0806 offset_chunk_3 0x(fn_3oct_p1#custom1)100000 port  [ss#2] permit

...
#deny IP
config access_profile profile_name pcf add access_id 254 packet_content offset_chunk_1 0x0800 port [ss] deny
#deny ARP
config access_profile profile_name pcf add access_id 255 packet_content offset_chunk_1 0x0806 port [ss] deny


Обратите внимание на используемые чанки и их маски: offset_chunk_1 3 0xFFFF, offset_chunk_2 7 0xFFFFFEF8 и offset_chunk_3 8 0xFFF80000.

В этом профиле мы фильтруем ethertype, ip src, ip dst, arp src. Посмотрим на расположение этих данных в структуре кадра:
ethertype - байты 12  и 13
arp src ip - байты 28, 29, 30 и 31
ip src - байты 26, 27, 28  и 29
ip dst - байты 30, 31, 32 и 33

Поэтому согласно приведенной выше таблице нас интересуют чанки №3, №7 и №8, которые включают в себя все нужные нам байты. Самое забавное в нашей ситуации то, что arp src ip находится "между" чанками 7 и 8, т.е. захватывает вторую половину 7 чанка и первую половину 8-го чанка. При этом, как я уже упоминал выше, мы можем использовать каждый чанк только 1 раз. Поэтому придется строить правила с учетом этого нюанса.

Разберем что именно нам надо описать в правилах:
В сети каждому абоненту выдается диапазон адресов /29, основанный на номере порта. При этом первый бит третьего октета IP-адреса может меняться на единичку. Исторически это использовалось для блокирования должников. При этом сама сеть, в которую попадают абоненты одного коммутатора, имеет маску /23.

Это будет лучше понятно на примере:
Если абонент подключен в порт №1 и для абонентов этого коммутатора выделена сеть 10.128.4.0/23, то правильными адресами для абонента будут 10.128.4.8/29  и 10.128.5.8/29.
Аналогично для 10-го порта и сети 10.133.56.0/23 - соответственно 10.133.56.80/29 и 10.133.57.80/29.

Как нетрудно догадаться, такая схема описывается маской 0xFFFFFEF8. В бинарном представлении последние два байта здесь будут выглядеть как 0b11111110 и 0b11111000. Если кто забыл, это, фактически, инверсия cisco wildcard mask, где биты, соответствующие нулевым битам маски, игнорирутся.

Таким образом мы разобрались с одной маской для IP SRC (чанк 7) - это 0xFFFFFEF8. Теперь аналогичным образом нужно описать ARP. Но ARP SRC IP смещен на 2 байта по отношение к IP SRC и самые интересный нам байты попадают уже в чанк 8. Это байты с номерами 30 и 31. А вот остальные 2 байта нам уже не нужны. Отсюда наша маска для чанка 8 должна была бы быть 0xFEF80000. Однако, согласно техзаданию нам надо блокировать еще доступ и к сетям управления, которые в нашем случае описываются как 172.16.0.0/15 и 10.99.0.0/16. Как видно, 172 и 10 - это байт №30, а 16 и 99 - байт №31, т.е. те же самые байты, которые мы пытаемся описать для ARP SRC IP. И если для байта №31 мы еще можем позволить себе забрать дополнительные 8 адресов (т.к. это локальные адреса), то забирать по 1 дополнительному адресу для байта №30 было бы слишком роскошно. Отсюда вывод: использовать маску 0xFFFFFFF8 и описывать ARP двумя правилами - с жестко заданными третьим октетом X и X+1.*

Ну и чтобы отделять мух от котлет ARP от IP нам потребуется знать ethertype. Его задаем жестко, поэтому используем маску 0xFFFF (0x0000FFFF).

* Эту "мелочь" я обнаружил уже в процессе написания заметки. Изначально я забыл про "нечетный" третий октет для ARP. Все-таки полезно иногда писать такие статьи и заново все разбирать. :)

Итак, первые два правила запрещают доступ к 172.16.0.0/13 и 10.99.0.0/13. Такая избыточная маска получается из-за упомянутых выше ограничений. С этим придется мириться, ага.

Потом одним правилом разрешаем абонентский блок 10.XX.YY.port_N*8 0.0.1.7 (и YY+1).

Далее двумя правилами разрешаем валидные ARP-пакеты.

И последними двумя правилами запрещаем остальные IP и ARP от абонентов.

Ну и в конце классика жанра:
enable cpu_interface_filtering

create cpu access_profile profile_id 1 ip destination_ip_mask 255.255.255.255
config cpu access_profile profile_id 1 add access_id 1 ip destination_ip 224.0.0.2 port all permit

create cpu access_profile profile_id 2 ip destination_ip_mask 255.255.248.0
config cpu access_profile profile_id 2 add access_id 1 ip destination_ip 239.1.8.0 port all permit

#deny multicast-query for subscribers
create cpu access_profile profile_id 3 ip destination_ip_mask 240.0.0.0
config cpu access_profile profile_id 3 add access_id 1 ip destination_ip 224.0.0.0 port [ss] deny


И еще:
config cpu_filter l3_control_pkt [all] all state disable
config cpu_filter l3_control_pkt  [ss] all state  enable


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

P.S. Правила в процессе обкатки, пока ни один пользователь не пострадал, но, возможно, я что-то еще поменяю.

P.P.S. О конструкциях типа [ss], [all] и (fn_3oct#custom1) можно прочитать на странице сервиса генерации конфигов Dracon.

среда, 17 июня 2015 г.

Dracon - сервис генерации конфигурационных файлов 'на лету'

Выложил на гитхаб Dracon. Это виртуальный TFTP-сервер, который хранит в своей памяти информацию о коммутаторах и портах и по запросу выдает конфигурацию на основе этих данных и предварительно сгенерированного шаблона.

В самом шаблоне при этом можно писать что-то вроде:
config ports [ss] state enable

Где [ss] при выгрузке заменяется на нужный диапазон портов.

Можно использовать собственные функции, например для подстановки в ACL нужных IP или MAC адресов.

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

Проще говоря, если вдруг поменялся uplink, добавилась новая магистраль или подключился VIP-клиент со специфичными настройками порта - просто правим нужные свойства в биллинге и запрашиваем с коммутатора новый конфиг у Dracon.