Опыт синтеза языка управления работой сетевыми коммутаторами Cisco

А.М.Терентьев

В ходе разработки средств автоматизированного управления сетевыми коммутаторами Catalyst [12], в рамках построения заявленной системы сетевого мониторинга и аудита [19], было обеспечено автоматическое установление TelNet-сеанса связи с коммутатором, исполнение заранее написанной последовательности команд и корректное завершение сеанса.

Заявленной целью автоматизированного управления сетевыми коммутаторами на начальных этапах проектирования системы сетевого мониторинга и аудита была необходимость оперативно, автоматически реагировать на нарушения сетевыми объектами правил поведения в сети. Однако, уже в то время ожидалось, что подобные средства весьма удобно эксплуатировать и в полуавтоматическом режиме для оперативного управления коммутатором: подключения новых пользователей, выдачи различной справочной информации о состоянии коммутатора и т.п.

На том этапе работы представлялось, что достаточным решением проблемы автоматизации станет организация заранее подготовленных и тщательно выверенных блоков (последовательностей) команд управления с возможностью расширения их макросредствами для подключения меняющихся параметров. Так, для временного прекращения доступа некоторого сетевого устройства к ЛВС казалось достаточным подать следующие команды (1) (см. рис. 3):

Рис. 3. Простая процедура временного запрета по Static-списку

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

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

Немаловажным также является то, что кажущаяся алгоритмическая детерминированность управления на самом деле представляет собой реальный процесс в сетевой среде, который может по тем или иным причинам быть прерванным. Результаты такого прерванного сеанса можно установить только специальными запросами о состоянии управляемого объекта, так что эти запросы и анализ ответной информации следует предусмотреть до выдачи управляющих команд.

Далее, оказалось, что в ряде случаев для выдачи верной команды управления требуется дополнительная информация, которая не может быть априори известна. Так, в вышеприведенном примере после получения второй команды коммутатор может сообщить, что указанный MAC-адрес не является статическим (STATIC), а принадлежит, к примеру, некоторому интерфейсу с включенной Secure-функцией и, таким образом, является SECURE, а не STATIC. В этом случае следует выполнить совершенно другие команды управления для реального блокирования сетевого устройства. Для добавления же очередной строки к Secure-списку нужно получить актуальное количество строк списка, проверить его на предельное значение, увеличить на 1, задать новое значение и лишь после этого выполнить команду добавления нового устройства в список. Номер интерфейса и тем более количество строк в его Secure-списке легко узнаются соответствующими командами, но, как видим, необходим аппарат съема числовых и текстовых значений из получаемого от коммутатора потока информации, необходимы арифметические операции над числовыми переменными и операции сравнения как числовых, так и текстовых значений с возможностью разветвления последовательности подачи команд.

Более того, проектируемое средство управления отнюдь не является единственным управляющим клиентом. В ряде ситуаций вполне возможно вмешательство системных инженеров, например, после отключения подачи электропитания, которые посчитают необходимым подать на сетевой коммутатор свои Практика работы показывает, что возможны и самопроизвольные перезапуски коммутатора с восстановлением ранее запомненной конфигурации. При экспериментах с сетевыми коммутаторами в ЦЭМИ РАН, оказалось возможным подобрать последовательность формально легальных команд на сетевом коммутаторе Cysco Catalyst 2950 (IOS 12.1), которая с некоторой вероятностью вызывала перезагрузку IOS.

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

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

Таким образом, проблема надежного управления коммутатором с помощью заранее написанных целевых управляющих последовательностей команд предстаёт проблемой дополнения управляющих команд средствами анализа корректности завершения исполнившейся команды, средствами съема актуальной информации во внутренние переменные, ряда операций с этими переменными, средствами разветвления процесса и иными.

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

Анализ объекта

Сетевые коммутаторы Cisco Catalyst, широко используемые в целях оперативного управления локальными сетями, в своём базовом математическом обеспечении всегда имеют поддержку протокола TelNet. Характеристические особенности этого протокола применительно к усечённому варианту, используемому в коммутаторах Cisco, исследованы в [12].

Применительно к поставленной проблеме создания языковой надстройки, объектом исследования выступает процесс выдачи управляющих команд и приёма ответной информации. Этот процесс обладает следующими основными особенностями и свойствами.

• С момента заявки на аутентификацию пользователя, процесс является неразрывным во времени. Превышение некоторого предела временной задержки перед подачей очередной команды (обычно 3 мин.) неминуемо ведёт к разрыву сеанса.

• Команды управления образованы буквами латинского алфавита с немногочисленными специальными символами и всегда начинаются с буквы. Терминальными символами окончания ввода являются символы конца строки (совокупность 0D0Ah) и вопросительного знака. Вместо одного пробела всегда можно указать несколько.

• При ожидании ввода команды всегда присутствует терминальное приглашение (промпт), начинающееся символами “lan_switch” и заканчивающееся диезом “#”. Между этими группами могут находиться другие термы, идентифицирующие текущий уровень управления.

• Существует команда, последовательное повторение которой всегда выводит с любого места управляемый объект на начальный уровень управления (“lan_switch#”), а поданная на начальном уровне, эта команда приводит к корректному завершению сеанса работы.

• Существует единственный однозначный признак успешного завершения выполнения поданной команды – очередной промпт без промежуточно выданных строк. Однако, этот признак достаточен, но не необходим: выданная промежуточная информация может являться, а может и не являться признаком некорректности или невыполнимости команды. В то же время, появление строки, начинающейся с процента (“%”), однозначно свидетельствует об ошибке выполнения команды. В частности, все ошибки синтаксического уровня всегда вызывают появление ремарки, предваряемой процентом.

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

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

• Каждая команда языка управления долна занимать ровно 1 строку, начинаться с позиции 1 и заканчиваться символами конца строки

• В отличие от прямых команд управления коммутатором, команды синтезируемого языка (в дальнейшем именуемые "псевдокоманды", или сокращенно ПСК) должны начинаться с небуквенных символов.

• Целесообразно ввести типовой признак Ошибки выполнения команды, устанавливаемый в случаях появления в выходной информации коммутатора строк, начинающихся с символа «процент».

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

• Многоуровневость управления неминуемо влечёт за собой необходимость последовательной проверки как минимум двух различных числовых значений. Проверка или съём каждого требует максимум двух текстовых и одной числовой переменной. Таким образом, учитывая необходимость хранить результаты одной предыдущей проверки, достаточно использовать 3 текстовых и 3 числовых переменных в языке для формирования любых, сколь угодно сложных алгоритмов проверки, плюс организации разветвления алгоритма по условию.

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

• Полужирный прямой шрифт использован для обозначения элементов языка точно так, как они должны быть заданы в тексте процедур.

• Полужирный курсив использован для идентификации объектов, которым при написании процедур должны быть приданы конкретные значения.

• Квадратные скобки без жирности используются для указания необязательных элементов или конструкций.

• Фигурные скобки и вертикальная черта без жирности определяют необходимость выбора одного из нескольких указанных элементов.

Организация процедур

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

Процедура состоит из заголовка и остальных строк, которыми могут быть исполняемые TelNet-команды, псевдокоманды скрипта (сокращённо «ПСК») и комментарии. Строки набираются в обычном текстовом редакторе. Каждая команда или ПСК начинается с первой позиции новой строки и должна умещаться в одну строку. Пустые строки не допускаются. Все процедуры записываются подряд одна за другой, начало следующей означает конец предыдущей. Концом всех процедур является конец конфигурационного файла мониторной программы.

В данной реализации языка не предусмотрена возможность комментариев после содержательной части строки; комментарии должны быть отдельными строками. Таким образом, например, в псевдокоманде :Метка именем метки считается всё после двоеточия до конца строки, включая пробелы. За корректностью идентификаторов меток следует следить программисту.

Семантика

В данной опытной версии языка может использоваться 9 переменных.

Переменная V считается предопределенной и отражает vlan. Её значение определяется специальным оператором конфигурационного файла и не может изменяться. При появлении в тексте исполняемой команды макровызова &V, перед исполнением команды такая конструкция заменяется на номер vlan.

Переменные M и I также предопределены в каждой процедуре и не могут быть изменены внутри них. Они предназначены для определения MAC-адреса интересуемого объекта и интерфейса (порта коммутатора). Вставка конкретных значений в текст исполняемых команд осуществляется по макровызовам &M и &I. По &M вставляется MAC-адрес в принятой в командах управления коммутаторами форме (3 группы 16-ричных символов через две точки), по &I вставляется одно- или двузначное целое число. Если процедура использует входными параметрами MAC-адрес и/или интерфейс, то соответствующие символы должны присутствовать в её заголовке, тогда эти параметры будут запрошены от оператора перед исполнением процедуры.

Переменные X, Y и Z являются свободными числовыми переменными. Их значения могут устанавливаться и меняться внутри процедуры. Перед началом процедуры значения переменных не определены. Существует специальная псевдокоманда проверки, установлено ли значение переменной. Для включения значения переменной в строку исполняемой команды или комментария следует использовать макровызов - знак амперсенда и имя переменной. При попытке использования значения неустановленной переменной, даже в !-комментарии, исполнение скрипта блокируется.

Единственным способом установки значения числовой переменной является приём этого значения из выходного потока коммутатора с помощью оператора #. В дальнейшем можно увеличить или уменьшить на 1 это значение специальными псевдокомандами.

Переменные U, W и T являются свободными текстовыми переменными. Их значения могут устанавливаться и меняться внутри процедуры. Перед началом процедуры значения переменных не определены. Существует специальная псевдокоманда проверки, установлено ли значение переменной. При попытке использования значения неустановленной переменной, даже в !-комментарии, исполнение скрипта блокируется.

Единственным способом установки значения текстовой переменной является приём этого значения из выходного потока коммутатора с помощью оператора $.

Синтаксис

[ИмяПр] [M] [I] [{D | R}] -  строка-заголовок новой процедуры. ИмяПр обязано быть уникальным среди прочих. Команды и псевдокоманды следуют строками далее. Конец процедуры определяется по началу следующей процедуры или концу конфигурационного файла. Признаки M и I обозначают необходимость указания вручную соответственно MAC-адреса и интерфейса для исполнения процедуры. Признак D должен быть задан ровно в одной процедуре и отмечает процедуру, которая должна автоматически вызываться для блокировки (drop) ПК по данным наблюдающей станции. Признак R должен быть также задан ровно для одной процедуры, отмечая процедуру, автоматически вызываемую для восстановления (restore) ранее заблокированного ПК.

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

!Комментарий - строка-комментарий для пользователя. Появление этой строки вызывает включение комментария в вывод TelNet-сеанса и общий протокол работы мониторной программы. Таким образом, данный оператор является исполняемым.

Исполняемая-команда - строка, передаваемая на исполнение коммутатору. Опознается по отсутствию в первой позиции одного из специальных символов, означающих псевдокоманду. Может содержать макровызовы любой из переменных, однако они должны быть определены. Перед передачей исполняемой команды коммутатору, интерпретатор сбрасывает флаг Ошибки. Завершение исполнения исполняемой команды автоматически сбрасывает все заданные псевдокомандами # и $ требования на контекстный поиск и установку значений переменных. В случае, если выданный по данной команде коммутатором текст содержал хоть одну строку, начинающуюся с символа %, устанавливается флаг Ошибки.

:Метка - псевдокоманда, определяющая метку в процедуре. При прохождении в порядке следования пропускается, флагов интерпретатора не изменяет. Возникшая необходимость перехода на метку вызывает просмотр операторов до конца процедуры с поиском данного оператора с нужной меткой (см. пояснение в предыдущем разделе «Семантика»). При нахождении исполняется следующий после найденной метки оператор. Стало быть, в скрипте допускаются дублирующие метки; целесообразность их использования определяет программист.

>Метка - псевдокоманда немедленной передачи управления на указанную метку. Метка ищется ниже по тексту процедуры.

%Метка - псевдокоманда условной передачи управления на указанную метку. Метка ищется ниже по тексту процедуры. Управление будет передано, если флаг Ошибки установлен. Данная ПСК не сбрасывает флаг Ошибки.

#”Образец”Имя<Начало - псевдокоманда задания режима поиска среди выводных строк коммутатора строки, содержащей Образец. При нахождении таковой, числовой переменной Имя будет присвоено значение, содержащееся в найденной строке, начиная с позиции Начало, до первого нецифрового символа или до конца строки. Лидирующие пробелы отбрасываются, однако пробел после первого же цифрового символа уже считается концом числа. В случае, если Начало больше длины строки, в которой найден Образец, исполнение процедуры прекращается с аварийным сообщением. Для выяснения, произошло ли реальное присвоение, следует воспользоваться оператором ?Имя%>Метка.

$”Образец”Имя<Начало,Длина - псевдокоманда задания режима поиска среди выводных строк коммутатора строки, содержащей Образец. При нахождении таковой, текстовой переменной Имя будет присвоено значение, содержащееся в найденной строке, начиная с позиции Начало, числом позиций Длина. В случае, если Начало больше длины строки, в которой найден Образец, либо Начало+Длина выходит за пределы строки, исполнение процедуры прекращается с аварийным сообщением. Для выяснения, произошло ли реальное присвоение, следует воспользоваться оператором ?Имя%>Метка.

?Имя%>Метка - псевдокоманда проверки, имеет ли переменная Имя значение. При отсутствии значения осуществляется переход на указанную метку. Оператор следует использовать только для свободных (см. «Семантика») переменных.

?Имя=Константа>Метка - псевдокоманда проверки соответствия значения числовой переменной Имя и числовой Константы. Переход на метку осуществляется при равенстве. Если переменная Имя не определена, дальнейшее исполнение процедуры блокируется.

?Имя=”Константа”>Метка - псевдокоманда проверки соответствия значения текстовой переменной Имя и текстовой Константы. Переход на метку осуществляется при точном совпадении. Если переменная Имя не определена, дальнейшее исполнение процедуры блокируется.

=Имя+ - псевдокоманда увеличения значения числовой переменной на 1. Если переменная Имя не определена, дальнейшее исполнение процедуры блокируется.

=Имя- - псевдокоманда уменьшения значения числовой переменной на 1. Если переменная Имя не определена, дальнейшее исполнение процедуры блокируется.

^+ - псевдокоманда успешного завершения процедуры. Исполнение процедуры прекращается, индицируется успешный результат. При отсутствии данного оператора в потоке исполнения и прекращении работы процедуры по иным причинам, результат процедуры не считается успешным.

^- - псевдокоманда аварийного завершения процедуры. Исполнение процедуры прекращается, результат не достигнут. Данная ПСК не является обязательной для индикации неуспеха и служит только эффективности написания процедур.

Результаты

Рассмотренная версия языковых средств полностью реализована в мониторной программе, исполняемой на ПК-сателлите в общей схеме сетевого мониторинга ЛВС ЦЭМИ РАН, описанной в [8].

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

Как видим, в простой процедуре удаления используется 12 строк, составляющих заголовок процедуры, строку комментария и 10 команд, среди которых 7 исполняемых и 3 ПСК.

Первая ПСК задаёт в дальнейшем выводе необходимость искать строку с текстом “Maximum”, причём при нахождении таковой строки присвоить переменной X числовое значение, находящееся в той же строке и записанное с позиции 30.

Далее следует команда show, вызывающая вывод ряда строк, среди которых и будет искаться строка с текстом “Maximum”.

Далее следует ПСК, уменьшающая значение переменной X на 1. Строго говоря, перед этим неплохо было бы проверить, получила ли эта переменная значение, и является ли оно большим чем 1 (нельзя задать значение 0), но оставим эти замечания для окончательного варианта процедуры, отметив только, что языковые возможности ПСК позволяют всё это сделать.

Далее следует 6 команд прямого управления, осуществляющие нужную конфигурацию: вход в управление нужным портом, исключение из списка Secure нужного МАС-адреса, задание нового значения максимального числа Secure-адресов на этом порту и выходы на исходный уровень управления.

Команды login и завершающая команда exit не задаются, они считаются присутствующими по умолчанию. Интерпретирующий блок мониторной программы при связи с коммутатором их вставляет всегда.

Обратим внимание, что в тексте команд процедуры встречаются макровызовы &M, &I и &X. Как следует из заголовка процедуры, переменные M и I являются её параметрами и, стало быть, будут запрошены от оператора до старта процедуры. Переменная же X определяется в ходе исполнения самой процедуры. Стало быть, все макровызовы перед подачей команды на коммутатор будут заменены на реальные значения.

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

Из протокола работы мониторной программы на рис. 6 легко видеть, что оператор начал вызов процедуры удаления и ввод параметров в 03:50:46, в 03:51:53 процедура стартовала, а в 03:52:26 уже была завершена. Таким образом, на исполнение процедуры ушло примерно полминуты. Указанный вызов был осуществлен дистанционно, через Dial-Up. Работа через обычный TelNet потребовала бы несколько минут вследствие ручного набора команд, а исполнение тех же шагов с помощью «современного» графического средства Claster Management Suite - порядка 15 минут, значительная доля которых ушла бы на подгрузку объёмных графических апплетов через медленный модем 33600.

Обратная процедура пополнения Secure-списка приведена на рис. 7, а протокол вывода коммутатора при её исполнении - на рис. 8.

Как уже было отмечено выше, приведенные процедуры очень просты, не содержат проверок допустимости и результатов каждого шага, и приведены здесь только в целях иллюстрации практического применения созданной реализации скриптового языка. Реально используемые процедуры содержат больше операторов, причём весьма значительную (до 80%) их часть составляют именно псевдокоманды скрипта. Поскольку ПСК интерпретируются блоками приложения (мониторной программой) и не предназначены для передачи через TelNet, их исполнение не вызывает заметного увеличения времени выполнения таких сложных процедур.

Заключение

Разработанные языковые средства и их программная интерпретация реализованы в версиях мониторной программы, начиная с лета 2006г. При разработке этой программы, помимо автоматического вызова процедуры изоляции нужного сетевого устройства по его МАС-адресу, с самого начала была заложена возможность полуавтоматической работы процедур, т.е. их вызова оператором.

Реальный процесс управления работой коммутатора, описанный в [8] (см. рис. 2 на стр. 13 данного сборника), оказался настолько простым и удачным по эффективности, что сразу же после появления работоспособной версии МП с этими возможностями только она и использовалась для оперативного управления действующим сетевым коммутатором. Иные средства более не применялись. Ко времени данной публикации уже создано более 10 процедур на описанном языке, их каталог постоянно пополняется, а сами процедуры совершенствуются.

Предложенный язык может служить основой и для не зависимых от системы сетевого мониторинга и аудита средств полуавтоматического управления сетевыми коммутаторами Cisco Catalyst. При этом, поскольку тексты процедур хранятся в обычном виде, блок процедур легко можно настроить на конкретные особенности IOS управляемого коммутатора.

1) Разумеется, после установления связи и успешного прохождения аутентификации. Во всех примерах данной работы, где явно не указано иное, это предполагается выполненным.

Статья опубликована в 2006 г.