Простая схема SNMPConf - 3
Работа команды SNMP PUT, которая будет выполнять изменение конфигурации устройства в соответствии с правилами, зависит от создания библиотек методов и MIB фирм-поставщиков. Чтобы доказать работоспособность этого механизма, рабочая группа SNMPConf создает базу данных методов DiffServ Policy MIB. Она должна устанавливать соответствия между Policy MIB и DiffServ MIB.
Простота этого подхода лучше всего видна на примере. Пусть Policy MIB определяет следующие булевские конструкции: Policy Filter и Policy Action, которые сначала выбирают объект применения правил, а затем применяют соответствующее правило. В этом им помогают входящие в Policy MIB новые MIB-таблицы, определяющие роли, возможности, пропускную способность и время. Например, чтобы выбрать интерфейсы, имеющие связь с Интернет, вам следует использовать следующий фильтр: [if (((type == interface) || (type == circuit)) && roleMatch(“internet”))]. Интерфейсы, отвечающие этому фильтру, могут выполнить следующее действие: свести Microsoft-трафик к нулю и тем самым предотвратить его передачу по каналам территориально распределенной сети.
Рассмотрим еще один пример: все Cisco-маршрутизаторы можно сконфигурировать так, чтобы им был задан доступ к работе с определенной версией IOS. В этом случае Policy Filter будет выглядеть следующим образом: [if ((type=system) && (strcmp(getstring(sysOID), “1.3.6.1.4.1.9”)) && roleMatch(“access”))], а возможное действие - например, так: [“set string(ciscoImageVersion.0, “12.1”)”]. Параметр roleMatch представляет собой текстовую строку, содержащую неформальную информацию. Такого рода информация делится на четыре класса: административный (политический, в частности руководящий, торговый или эксплуатационный), финансово-юридический (бесплатный, жизненно важный или демо), географический (юго-запад, третий этаж или 11-й район) и архитектурный (канал, резервная линия или магистраль). Это всего лишь текстовая строка, поступающая в БД Policy MIB конкретного устройства.