DFM - навороченная и неуклюжая по исполнению система обнаружения ошибок на активном сетевом оборудовании. Может работать как самостоятельно, так и интегрированно с CiscoWorks. GUI и help целиком основаны на технологии Java и Internet Explorer, из-за чего все окна имеют соответствующий вид и "медвежий" пользовательский интерфейс а-ля CiscoWorks (не обессудьте).

Архитектура весьма непроста и состоит из нескольких программных компонентов:

1. DFM Domain Manager - ядро системы. Состоит из базы данных устройств (классовая модель DFM Inventory, где каждый класс обслуживаемых устройств имеет свои attributes, relationships, events) и системы анализа событий. На вход DFM Domain Manager поступают events от так называемых Event Adapter-ов, а выходная информация поступает на Notification Adapter-ы. В результате получаются Event Notifications двух видов - Compound Notifications(представляющие взаимосвязанные события как одно целое) и Symptomatic Event Notifications (внутренние события устройства).

2. DFM broker - примочка, упрощающая коммуникацию DFM Domain Manager. Слушает порты, передает какие-то данные.

3. DFM consoles - убогие уже упоминавшиеся управляющие GUI - Monitoring Console (где видны Compound и Symptomatic Event Notifications), Administration Console (видно дерево домена DFM) и связанные с ними окошки. DFM consoles в терминологии Cisco являются клиентами DFM Domain Manager.

4. DFM adapters - тоже клиенты DFM Domain Manager. Это набор дочерних сервисов, реализующих отдельные функции системы DFM. Например, есть inventory adapter-ы для распознавания и работы с обслуживаемыми устройствами, Notification adapters - Mail Notifier Adapter, Trap Notifier Adapter и File Notifier Adapter (эти адаптеры служат для оповещения админа по почте и как-то ещё).

DFM обслуживает следующие устройства:

Bridges
Chassis
Cards
Hosts
Hubs
Interfaces
Module Switch Feature Card (MSFC)
Ports
Power Supplies
Routers
Router Switch Feature Card (RSFC)
Route Switch Modules (RSM)
SNMP Agents
Switches
System Fans
System Memory Resources
System Processor Resources
VLANs

Устройства распознаются по протоколу SNMP (UDP-порты 161 и 162). Каждый обслуживаемый клиент запускает сервачок на UDP-портах 161 и 162, имеет свою базу SNMP, так называемую MIB (Management Information Bases). Подключение возможно как к стандартной MIB, например MIB-II (с некоторыми оговорками), так и к проприетарной Cisco MIB. Я пытался подключить терминальные серваки с запущенной службой SNMP, но у меня не вышло (наверное, из-за незнания каких-нибудь тонкостей).

Информация собирается несколькими сборщиками (probe), которые бывают следующих видов:

System Information Probe. Основное назначение - определить, сертифицировано ли устройство и идентифицировать устройство как уникальное.

Если устройство не отвечает на запросы SNMP от System Information Probe, то domain manager помечает это устройство как Undiscovered и далее не пытается распознать это устройство. Кроме того, устройство помечется как unmanaged - это означает, что устройство мониториться не будет. Если устройство ответило на запрос SNMP, то System Information Probe проверяет sysObjectID устройства на наличие его в файле oid2type.conf (находится в папке c:\Program Files\CSCOpx\objects\smarts\conf\discovery). В этом файле находится "база знаний" по устройствам Cisco. После этого определяется уровень сертификации устройства - Validated (наивысший уровень сертификации), Certified (такие устройства тоже обрабатываются), Template (устройство перечислено в файле oid2type.conf, однако DFM не может поддерживать MIB этого устройства), Undiscovered (произошла ошибка при распознании устройства по протоколу SNMP. Эти устройства отображаются в соответствующей папке дерева домена DFM), Uncertified (устройство ответило на процедуру распознавания, но sysObjectID этого устройства не перечислено в oid2type.conf. Эти устройства отображаются в соответствующей папке дерева домена DFM). Системой DFM полностью поддерживаются Validated и certified устройства.

Containment Probe
Распознаёт элементы устройства (интерфейсы, порты, MAC-адреса, карты и модули) путем опроса соответствующих переменных базы MIB (ipAdEntIfIndex, ifType, ifDescr, ifSpeed, ifMtu, ifPhysAddress, ifName и дополнительные переменные, если база проприетарная). Детали опускаем.
IP Network Probe
Распознает подсоединённость устройства к сети и находит IP-адреса, сконфигурированные в системе (опрос переменных ipAdEntAddr, ipAdEntIfIndex, ipAdEntNetMask).
VLAN Probe
Собирает информацию о идентификаторах VLAN, транках VLAN и принадлежность портов VLAN-ам.
Neighbor Probe
Собирает какую-то дополнительную информацию в MIB с проприетарной топологией.

После распознавания устройств сети система DFM начинает собирать информацию об них. Это делается тремя способами:
- опросы SNMP (SNMP polls)
- обработка сообщений ловушек SNMP (SNMP trap message processing)
- опросы по протоколу ICMP (Internet Control Message Protocol) или по-русски ping.
Информация об ошибках собирается первыми двумя методами по SNMP, а подсоединённость устройств - по ICMP.
Сообщения об ошибках бывают, например, такие:
- высокая скорость появления ошибок на сетевом адаптере;
- большая нагрузка на процессор;
- большое количество ошибок буферной памяти системы.

Сообщения об ошибках можно посмотреть в списке Alarm Log консоли мониторинга (Monitoring Console). Compound-сообщения (которые состоят из нескольких событий) отображаются фиолетовым цветом (те compound-события, которые имеют в столбце count большое число, помечаются тёмно-фиолетовым, что сигнализирует о повышенной опасности), Symptomatic-сообщения высвечиваются оранжевым. Информационные сообщения высвечиваются белым, часто повторяющиеся - жёлтым.

База данных распознанных устройств (просматривается в виде дерева папок Administration Console) хранится в c:\Program Files\CSCOpx\objects\smarts\repos\icf\DFM.rps.
Это простой текстовый файл. При редактировании атрибутов устройства (например, атрибута DisplayName), изменения пишутся именно в этот файл, и никуда более. Некоторые атрибуты недоступны для редактирования из Administration Console.

Обслуживаемые Устройства можно добавлять несколькими способами (прочитал в help по DFM Working with the DFM Inventory\Adding Devices to the Managed Inventory), результат процесса добавления можно посмотреть в логе c:\Program Files\CSCOpx\objects\smarts\logs\DFM.log:
- Administration Console\Inventory\Add Agent..., далее в поле Agent Name вводим IP нового устройства, а в поле Read Community вводим условное словцо-пароль (по умолчанию cisco).
Откроется окошечко, показывающее статус процесса добавления. Через некоторое время раздумья устройство добавляется в определённую папку, в зависимости от результата опроса по SNMP - если это устройство Cisco, то обычно в папки Router, Switch, Uncertified или Undiscovered. Причём в дереве DFM отображаются не все папки - например, нет папки Unsupported. У меня туда попали терминальные сервера при попытке добавить их в дерево DFM, и нашёл я их только по поиску - Administration Console\Edit\Find Instances..., выбираю домен DFM, Class Mask: .*, в поле Instance ввожу IP или имя терминального сервера (terminal0), который я пытался добавить. После этого в окошке ниже появлялось -  DFM::Unsupported::terminal0, и при нажатии кнопки Browse появлялось окошко с деревом DFM, где был виден terminal0 в папке Unsupported.
- с помощью seed-файла, в каждой строке которого имя/IP и community-string
Вот пример файла в таком формате:
#  IP ADDRESS  READ COMMUNITY
jjj.aaa.bbb.ccc  public
ddd.eee.fff.ggg  cisco
mmm.nnn.ooo.ppp  cisco
vvv.ttt.lll.yyy  private
xxx.zzz.sss.kkk  nortel
  Этот файл скармливается через Administration Console\Inventory\Import from seed file...
  В процессе распознавания устройств они в реальном времени начинают появляться в соответствующих папках.
  С помощью утилитки The Windows command is sm_tpmgr.exe можно экспортировать устройства из домена в seed-файл, что может понадобиться для переноса конфигурации DFM:
# NMSROOT\objects\smarts\bin\sm_tpmgr.exe -s DFM --dump-agents > seedfile.txt
- из Resource Manager Essentials Inventory - это база устройств CiscoWorks.
  По сути, в последнем случае ничего добавлять не нужно - база устройств DFM автоматически синхронизируется с базой Essentials, то есть при добавлении устройств в CiscoWorks эти же устройства автоматически попадают в DFM. Лог процесса синхронизации баз Essentials и DFM пишется в NMSROOT/conf/dfm/DfmChangeProbe.log.
  Процесс, передающий в DFM события об изменении базой Essentials, называется DfmChangeProbe. Чтобы подробнее узнать, как синхронизируются DFM inventory и Essentials inventory, читайте "Synchronizing the DFM Inventory with the Essentials Inventory".
  Для того чтобы запретить (или разрешить) процесс DfmChangeProbe, выберите в консоли управления CiscoWorks Device Fault Manager > Administration > Device Discovery > Change Probe, выделите процесс DfmChangeProbe и щелкните Stop (или Start).
  Если Вы запретили процесс, но затем перезагрузили систему, то DfmChangeProbe запустится снова. Для полного запрета DfmChangeProbe нужно его дерегистрировать. Под виндами это делается так:
# NMSROOT\bin\pdcmd.exe -u DfmChangeProbe
  Чтобы снова зарегистрировать процесс (Вам опять захотелось, чтобы он стартовал автоматически), выполните:
# NMSROOT\bin\pdcmd -r DfmChangeProbe.exe -d EssentialsDbEngine,EssentialsDbMonitor -e NMSROOT\bin\cwjava -f "-Xnoclassgc com.cisco.nm.dfm.changeprobe.DfmChangeProbe"

Если по какой-то причине устройство не распозналось, то иногда намек на причину можно посмотреть в атрибуте устройства DiscoveryErrorInfo, но далеко не всегда. Например, если на устройстве не прописан snmp-server community cisco RW 8, а устройство добавляется с Read Community cisco, то устройство молча и без объяснения причин попадёт в папку Undiscovered. Устройство можно перераспознать (например, после устранения причины ошибки), если его выделить в дереве и в меню выбрать Inventory\Rediscover. Через минутную паузу устройство (в случае успеха) перепрыгнет из папки Undiscovered в другую папку (например, Router).

Параметры опроса и пороги срабатывания меняются через Administration Console\Edit\Polling and Tresholds.
Я не понял, как менять пороги и параметры на отдельном устройстве (можно их менять только у группы). Например, в консоли Polling and Thresholds\Закладка Thresholds (внизу)\DFM\System Resource Groups\Routers\Connectivity я поменял параметр IPNetworkNotificationMode на Enabled (это означает Enables or disables the IP Network Inaccessible notification, типа если устройство недоступно, посылать сообщение). То же самое я сделал для System Resource Groups\Switches.