Skip to end of metadata
Go to start of metadata

Некоторые производители сетевого оборудования для генерации SNMP-трапов используют отдельные MIBы для каждой модели оборудования. Например, OID'ы и названия одного и того же трапа swL2PortSecurityViolationTrap для разных моделей свичей может иметь вид:

  • 1.3.6.1.4.1.171.11.113.1.3.2.20.0.1 для DES-3200-10
  • 1.3.6.1.4.1.171.11.113.2.3.2.20.0.1 для DES-3200-18
  • 1.3.6.1.4.1.171.11.113.3.3.2.20.0.1 для DES-3200-28
  • 1.3.6.1.4.1.171.11.113.4.3.2.20.0.1 для DES-3200-28f
  • 1.3.6.1.4.1.171.11.113.5.3.2.20.0.1 для DES-3200-26
  • 1.3.6.1.4.1.171.11.70.5.3.2.20.0.1 для DGS-3650
  • 1.3.6.1.4.1.171.11.70.6.3.2.20.0.1 для DGS-3627
  • 1.3.6.1.4.1.171.11.70.7.3.2.20.0.1 для DGS-3626G
  • 1.3.6.1.4.1.171.11.70.8.3.2.20.0.1 для DGS-3612G
  • 1.3.6.1.4.1.171.11.70.9.3.2.20.0.1 для DGS-3612
  • 1.3.6.1.4.1.171.11.118.1.3.2.20.0.1 для DGS-3620-28TC
  • 1.3.6.1.4.1.171.11.118.2.3.2.20.0.1 для DGS-3620-28SC
  • 1.3.6.1.4.1.171.11.118.3.3.2.20.0.1 для DGS-3620-28PC
  • 1.3.6.1.4.1.171.11.118.4.3.2.20.0.1 для DGS-3620-52T
  • 1.3.6.1.4.1.171.11.118.5.3.2.20.0.1 для DGS-3620-52P
  • 1.3.6.1.4.1.171.11.118.8.3.2.20.0.1 для DGS-3620-28TC-DC
  • 1.3.6.1.4.1.171.11.118.9.3.2.20.0.1 для DGS-3620-28SC-DC

Рассмотрим конкретный пример. Пусть с DES3200-28 пришло событие swL2PortLoopOccurred:

{
    "profile": "DLink.DxS",
    "raw_vars": {
        "source": "SNMP Trap",
        "profile": "DLink.DxS",
        "1.3.6.1.6.3.1.1.4.1.0": "1.3.6.1.4.1.171.11.113.1.3.2.20.0.3",
        "1.3.6.1.4.1.171.11.113.1.3.2.21.2.1.1.1.13": "13"
    }
}

Правило для классификации будет иметь вид

{
    "name": "DLink | DxS | Network | LBD | Loop Detected (SNMP)",
    "description": "DES3200-28-L2MGMT-MIB::swL2PortLoopOccurred",
    "event_class__name": "Network | LBD | Loop Detected",
    "preference": 1000,
    "patterns": [
        {
            "key_re": "^source$",
            "value_re": "^SNMP Trap$"
        }, 
        {
            "key_re": "^profile$",
            "value_re": "^DLink\\.DxS$"
        },
        {
            "key_re": "^DES3200-28-L2MGMT-MIB::swL2LoopDetectPortIndex\\.\\d+$",
            "value_re": "^(?P<interface>\\S+)$"
        },
        {
            "key_re": "^SNMPv2-MIB::snmpTrapOID\\.0$",
            "value_re": "^DES3200-28-L2MGMT-MIB::swL2PortLoopOccurred$"
        }
    ] 
 }

Для DES3200-28 аналогичное событие будет иметь вид

{
    "profile": "DLink.DxS",
    "raw_vars": {
        "source": "SNMP Trap",
        "profile": "DLink.DxS",
        "1.3.6.1.6.3.1.1.4.1.0": "1.3.6.1.4.1.171.11.113.1.4.2.20.0.3",
        "1.3.6.1.4.1.171.11.113.1.4.2.21.2.1.1.1.13": "13"
     }
}

Как видно, поменялись OID'ы и названия и наше правило работать не будет. Конечно, всегда можно создать еще одно правило для каждой модели свичей, но тогда нам придется дублировать и аналогичные правила для многих сетевых событий и, со временем, набор правил станет крайне громоздким и при добавлении новых моделей придется дублировать большое количество правил.

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

Для примера, создадим правило клонирования и положем его в файл  fm/collections/cloneclassificationrules/DLink.json

[
    {
        "name": "DES3200-28-L2MGMT-MIB:: -> DES3200-28F-L2MGMT-MIB::",
        "key_re": "SNMPv2-MIB::snmpTrapOID",
        "value_re": "DES3200-28-L2MGMT-MIB::",
        "rewrite_from": "DES3200-28-L2MGMT-MIB::",
        "rewrite_to": "DES3200-28F-L2MGMT-MIB::"
     }
]

 и импортируем его 

/opt/noc$ ./noc sync-collections

В результате для каждого правила, cодержащего строки ( SNMPv2-MIB::snmpTrapOID, DES3200-28-L2MGMT-MIB::*) будет создан клон, в котором все вхождения DES3200-28-L2MGMT-MIB:: будут заменены на DES3200-28F-L2MGMT-MIB::* и для нашего правила автоматически создастся клон:

{
    "name": "DLink | DxS | Network | LBD | Loop Detected (SNMP 1)(Clone DES3200-28-L2MGMT-MIB:: -> DES3200-28F-L2MGMT-MIB::)",
    "description": "DES3200-28-L2MGMT-MIB::swL2PortLoopOccurred",
    "event_class__name": "Network | LBD | Loop Detected",
    "preference": 1000,
    "patterns": [
        {
            "key_re": "^source$",
            "value_re": "^SNMP Trap$"
        },
        {
            "key_re": "^profile$",
            "value_re": "^DLink\\.DxS$"
        },
        {
            "key_re": "^DES3200-28F-L2MGMT-MIB::swL2LoopDetectPortIndex\\.\\d+$",
            "value_re": "^(?P<interface>\\S+)$"
        },
        {
            "key_re": "^SNMPv2-MIB::snmpTrapOID\\.0$",
            "value_re": "^DES3200-28F-L2MGMT-MIB::swL2PortLoopOccurred$"
        }
    ]
 }

Все правила модели DES3200-28F будут адаптированы для DES3200-28

 

Необходимо отметить три момента:

  1. Регулярные выражения правила клонирования проверяют регулярные выражения правила классификации, поэтому необходимо должным образом экранировать элементы регулярного выражения
  2. Клоны правил существуют только в памяти классификатора и создаются в момент загрузки правил (при старте и по SIGHUP) и не требуют какой-либо дополнительной обработки
  3. При создании правил клонирования необходимо подкладывать MIBы и для новых моделей

 Детали реализации можно посмотреть в NOC-99