Blogs
Space shortcuts
Child pages
  • Валидация конфигурации или "Всё правильно сделал"

Versions Compared

Old Version 3

changes.mady.by.user Andrey

Saved on

compared with

New Version Current

changes.mady.by.user Andrey

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Expand
titleПример валидатора на CLIPS

Приведём пример валидатора, которые проверяет - назначен ли созданному подинтерфейсу VLAN. Для случая Cisco.IOS настройка выглядит так:

interface FastEthernet0/1.200

encapsulation dot1q 200

В случае если в конфиге будет отсутствовать команда "encapsulation dot1q 200" должна выдаваться ошибка.

Перефразируя вопрос - в фактах интерфейсов присутствует поля:

  • vlan_ids - оно заполняется номером влана, который назначен подинтерфейсу
  • afi - в случае подинтерфейса в нём будет присутствовать слово BRIDGED

Необходимо написать правило, которое в случае отсутствия в случае пустого поля vlan_ids и наличия BRIDGED в afi выдавало ошибку. На левой картинке показаны факты с правильно настроенного интерфейса, а на правой - настроенного с ошибкой.


Для данного случае стандартные правила нам не подходят. Напишем своё:

Code Block
themeRDark
languagecpp
linenumberstrue
    (defrule {{RULENAME}}
            (subinterface (vlan_ids) (afi $? "BRIDGE" $?) (name ?n))
            =>
            (assert
                (error (type "Interface | MPLS Without ISIS")
                       (obj ?n)))
    )

Данное правило написано на CLIPS и выполнит задачу. Сделаем некоторые пояснения.

  1. {{RULENAME}} - при выполнении данного правила в логах данное поле заменится строкой из Имени правила. Не возбраняется использовать любую текстовую строку
  2. subinterface - показывает что ходить мы будем по блоку, в котором находятся подинтерфейсы. Названия блоков совпадают с таковыми в Facts.
    1. (vlan_ids) - обозначает пустое поле vlan_ids
    2. (afi $? "BRIDGE" $?) - обозначает что в afi (это массив) должен присутствовать "BRIDGE"
    3. (name ?n) - запоминает значение поля name в переменной ?n
  3. знак => показывает переход к блоку действий
  4. assert - ключевое слово, означающее создать исклюение
  5. error - в данной строке показывается ошибка, которая создаётся если проверка закончилась неуспехом. Доступные типы ошибок находятся в папке "cm/collections/errortypes/"Configuration Management"->Setup->"Error Types"
  6. obj ?n - заменится на имя интерфейса

Ошибки.

При написании собственных правил возникает вопрос создания собственных типов ошибок. Как вариант, дополнения существующих новой информацией. Типы ошибок доступны в меню "Configuration Management"->Setup->"Error Types".

Image AddedImage Added

Для измения доступны поля "Subject Body" и "Body Template". Они применяются при создании аварии, в случае провала проверки.

 

Встроенные обработчики снабжены хорошими комментариями. Поэтому приведём примеры наиболее востребованных:

 
ИмяОписаниеОпцииПример
Config *MUST* match string  В конфигурации должна присутствовать строка.строка, которую необходимо искать в конфигурации 
Hostname *MUST* match regexpПроверяет hostname на соответствие регулярному выражениюрегулярное выражение в формате Python 
Interface CLIPS RulesПозволяет задавать свои CLIPS-based правила, применяются к блоку интерфейсов правило в формате CLIPS 
Object CLIPS RulesПозволяет задавать свои CLIPS-based правила, прменяются ко всем блокамправило в формате CLIPS 

Формируем политики.

После того как написаны правила - необходимо объединить их в политики и привязать к оборудованию (MO). Политики настраиваются в меню "Configuration Management" -> "Setup" -> "Validation Policy".

...

Результаты применения политики отобразятся на том же экране Facts. Появится список ошибок. Также на экране правил (Rule) увеличится число в счётчике ошибок рядом с правилом и создастся Alarm.

Важное примечание.

После создания политики и её назначения на устройство НЕ происходит автоматической проверки конфигурации. Проверка пройдёт только после поступления в базу ИЗМЕНЕНИЙ в конфигурации (парсер фактов работает с базой конфигов НОКа).

Данное поведение связано с 2 моментами:

  1. Действует принцип "Закон обратной силы не имеет". Т.е. считается, что, изначально, все конфиги соответствуют политике.
  2. Мало приятного получить 2 сотни аварий за минуту (smile).

Если очень хочется:

Code Block
themeRDark
languagepy
titleЕсли необходимо проверить устройства на политики сейчас
./noc shell

from noc.cm.engine import Engine
from noc.sa.models.managedobject import ManagedObject
for mo in ManagedObject.objects.filter(is_managed=True):
    e = Engine(mo)
    e.check()

Возможные проблемы

  1. Окошко Facts пустое
    1. Для данного профиля не написан парсер. Проверить можно посмотрев содержимое папки "cm/parsers/".
    2. Парсер написан, но не работает. Ошибки необходимо искать в логах web.
  2. Правило написано, но не обнаруживает ошибку
    1. Необходимо проверить что правило включено в политику, а политика привязана к устройству.
    2. Необходимо нажать кнопку Revalidate в окошке Facts.
    3. Проверить логи web на наличие ошибок (в нём отображается какие правила были применены и результат)

...