2010-03-24 18 views
12

Minęło trochę czasu, odkąd napisałem ASN.1, więc ..SNMP: ASN.1 MIB Definicje. Odwoływanie się do tabeli w tabeli

Nasz model danych składa się z kilku definicji tabel w tabeli. To nie działa w SNMP, więc musimy spłaszczyć definicje. Najprościej to zrobić, jeśli tabela osadzona zostanie zindeksowana przez ten sam identyfikator OID, co tabela nadrzędna. Zatem

someTableEntry ::= SEQUENCE { 
    someTableIndex 
     Integer32, 
    someTableDomain 
     Integer32, 
    someTableFooTable 
     SEQUENCE OF SomeTableFooTable 
} 

staje

someTableEntry ::= SEQUENCE { 
     someTableIndex 
      Integer32, 
     someTableDomain 
      Integer32, 
    } 

someTableFooTable ::= SEQUENCE { 
    someTableIndex 
     Integer32, 
.... 
} 

Dobrą rzeczą jest to, że w naszej aplikacji nigdy nie będzie dowolny rodzaj SET, GET lub GET NEXT więc nie ma potrzeby spacer SNMP (istnieje kilka bardzo dobrych powodów za to, że zastępują potrzebę elegancji zarządzania siecią. Wszystkie atrybuty będą zgłaszane poprzez pułapki tylko. Myślę, że jest to ważne definicje SNMP MIB, ale chciał, aby uzyskać pewne informacje zwrotne.

Dzięki z góry.

Odpowiedz

19

Wygląda na to, że jesteś na dobrej drodze. Aby zdefiniować tabelę jako podrzędność innej tabeli, wystarczy ją zindeksować według indeksu nadrzędnego oraz indeksu podrzędnego (np. 0.1.8.23.7.2.42, gdzie 2 jest indeksem nadrzędnym, a 42 jest indeksem podrzędnym).

Na przykład, można zdefiniować rodzica jak:

parentTable OBJECT-TYPE 
    SYNTAX  SEQUENCE OF parentEntry 
    MAX-ACCESS not-accessible 
    STATUS  current 
    DESCRIPTION "Parent table" 
    ::= { example 1 } 

parentEntry OBJECT-TYPE 
    SYNTAX  ParentEntry 
    MAX-ACCESS not-accessible 
    STATUS  current 
    DESCRIPTION "Entry in Parent table" 
    INDEX  { parentIndex } 
    ::= { parentTable 1 } 

ParentEntry ::= SEQUENCE { 
    parentIndex   Unsigned32, 
    -- other columns in the table 
    } 

-- define the columns in the parent table 

z tabeli podrzędnej zdefiniowany jako:

childTable OBJECT-TYPE 
    SYNTAX  SEQUENCE OF childEntry 
    MAX-ACCESS not-accessible 
    STATUS  current 
    DESCRIPTION "Child table" 
    ::= { example 2 } 

childEntry OBJECT-TYPE 
    SYNTAX  ChildEntry 
    MAX-ACCESS not-accessible 
    STATUS  current 
    DESCRIPTION "Entry in Child table" 
    INDEX  { parentIndex, 
        childIndex } 
    ::= { childTable 1 } 

ChildEntry ::= SEQUENCE { 
    childIndex   Unsigned32, 
    -- other columns in the table 
    } 

-- define the columns in the child table 

pamiętać, że nie jest to konieczne do listy parentIndex w sekwencji ChildEntry ponieważ już być zadeklarowane w innym miejscu MIB.

Ta metoda działa dobrze, a nawet reaguje na spacery snmp bez problemu.

Gdy masz już MIB, który według ciebie dokładnie definiuje żądaną strukturę, możesz ją zweryfikować za pomocą smilint, jeśli jesteś na komputerze z systemem Linux lub masz zainstalowane cygwin lub możesz validate it online.

Aktualizacja

Ten wzór będzie pracować dla głębszego gniazdowania, jak również.

Tabela wnuczek może być zdefiniowane jako:

grandChildTable OBJECT-TYPE 
    SYNTAX  SEQUENCE OF grandChildEntry 
    MAX-ACCESS not-accessible 
    STATUS  current 
    DESCRIPTION "Grandchild table" 
    ::= { example 3 } 

grandChildEntry OBJECT-TYPE 
    SYNTAX  GrandChildEntry 
    MAX-ACCESS not-accessible 
    STATUS  current 
    DESCRIPTION "Entry in Grandchild table" 
    INDEX  { parentIndex, 
        childIndex, 
        grandChildIndex } 
    ::= { grandChildTable 1 } 

grandChildEntry ::= SEQUENCE { 
    grandChildIndex   Unsigned32, 
    -- other columns in the table 
    } 

-- define the columns in the grandChild table 

Jedyne ograniczenie kaskadowania jest maksymalna długość OID (które, jak uważa, jest 127) podstawy OID długość A słupa plus liczba indeksów tabela musi być mniejsza niż maksymalna długość OID.

Należy jeszcze wspomnieć, że na każdym poziomie może być wiele rodzeństwa.

Drugie dziecko może być zdefiniowana jako:

secondchildTable OBJECT-TYPE 
    SYNTAX  SEQUENCE OF secondchildEntry 
    MAX-ACCESS not-accessible 
    STATUS  current 
    DESCRIPTION "Second child table" 
    ::= { example 4 } 

secondchildEntry OBJECT-TYPE 
    SYNTAX  SecondchildEntry 
    MAX-ACCESS not-accessible 
    STATUS  current 
    DESCRIPTION "Entry in Second child table" 
    INDEX  { parentIndex, 
        secondchildIndex } 
    ::= { secondchildTable 1 } 

SecondchildEntry ::= SEQUENCE { 
    secondchildIndex   Unsigned32, 
    -- other columns in the table 
    } 

-- define the columns in the second child table 
+1

Bardzo dobre. Dzięki za szybką reakcję. – Doug

+1

czy zasada ma zastosowanie do trzeciej tabeli, tj. Miałaby 3 wskaźniki lub czy istnieją lepsze sposoby zarządzania nią w miarę wzrostu głębokości hierarchii? – TheJuice

+2

@TheJuice: Tak, zasada dotyczy tabel dzieci do maksymalnej długości OID głębokiej (która, jak sądzę, jest 127). Jak można się domyślić, każdy dodatkowy poziom miałby inny indeks. Zmienię moją odpowiedź na przykład. Nie znam żadnych lepszych sposobów zarządzania głębszymi hierarchiami. – lostriebo

Powiązane problemy