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
Bardzo dobre. Dzięki za szybką reakcję. – Doug
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
@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