Dan Lukes napsal(a):
Miroslav Chlastak wrote:
Napr. pred smazanim maji rozhrani indexy 1,2,3,4,5,6,7,8,9,10. Po
smazani napr. 1,2,3,4,7,8,9,10.
A s tim se snmpwalk a snmpbulkget nedokaze poprat
Nedokazu ted rozsoudit, jestli je to zamerna vlastnost nebo chyba.
A co je jeste slozitejsi - zejmena u snmpbulkget se nabizi odazka,
jestli je to vlastnost/chyba SNMP serveru ze ktereho data ziskavas nebo
toho prikazu, kterym je ziskavas.
Nicmene, resenim (krome pouziti jineho SNMP serveru/klineta) by mohl byt
prikaz
Pouzil jsem i jine klienty a chovani stejne. Jiny server jsem prozatim
nezkousel.
snmpgetnext
Ten by ti pri dotazu na indexy 1,2,3,4 mel vratit stejnou informaci jako
snmpget, ale pri dotazu na informaci "index 5" by ti mel vratit
nejblizsi nasledujici, tedy "index 7"
Je na tobe to ve vystupu rozpoznat (je tam napsano co ti vraci) a
reagovat na to pochopenim, ze 5 a 6 neexistuje, toto je 7 a pristi dotaz
tedy musi smerovat na 8
Pozor, pokud budes po dotazi na index 10 pokracovat dotazem na index 11
tak i to vrati nejakou hodnotu - takze musis rozpoznat, ze uz jsi uplne
vybehl ze stromu indexi a prochazeni ukoncit.
Ano, toto by asi slo. Jenze to pak bude mraky dotazu pres snmp. Kdyz
vezmu v potaz, ze by kazdy router mel 40-50 rozhrani a routeru bylo 30,
tak to nejaky cas (a systemove prostredky) sebere. A to jsem teprve u
zpracovani sitovych rozhrani :(
Existuje nejaky zpusob, jak toto uchodit? Nebo delam jen neco spatne a
ono to funguje pri urcite konfiguraci? Stejny problem pri pouziti
snmpgetbulk napr. v perlu.
Jestli se nepletu, tak v perlu je to jen wrapper vuci net-snmp knihovne.
Shodne chovani tudiz neprekvapi.
Jj. Ja tim chtel ukazat to, ze problem nebude v aplikaci snmpgetbulk a
snmpwalk.
Napada me upravit kod net-snmpd, aby si
indexy iface vytvarel sam a neprebral je ze systemu.
Pak by stacilo po
odstraneni rozhrani restartovat net-snmpd. Nebo si tim na neco nabehnu?
Podle me nabehnes. Zaprve - z hlediska aplikace, ktera data vyuziva.
Budes muset resit, ze zatimco pred okamzikem byl index 5 fxp0 tak ted, o
par vterin pozdeji, to je tun0
Ale nevim an co data sbiras - treba tohle problem neni.
Tohle by problem nebyl.
A pak si myslim, ze ta uprava nebude az tak jednoducha, protoze
inderface index se pouziva na pomerne velikem mnozstvi mist - a to nejen
jako klic, ale i v datove casti. nevim, jak je to uvnitr snmpd udelane,
ale muze to byt daleko slozitejsi nez jen trivialni uprava.
Na tohle jsem zapomnel :(
Tohle by ti ale mozna lepe poradili (i to, jestli je pozorovane chovani
bug or feature i to jak slozite by bylo chovani upravit) v nejakem
diskusnim listu venovanem primo net-snmp ...
Dan
Asi opravdu budu muset napsat primo na net-snmp list, protoze jsem ted
zjistil, ze i tabulka s indexama je timhle "postizena" - takze nactenim
indexu a pak dle toho sestavovat requesty taky nepomuze :(
Pritom IF-MIB::ifNumber.0 = INTEGER: 54 ukazuje spravny pocet rozhrani
v systemu :) Napada me jeste silenost tak dlouho zkouset request na
OID.index + 1, az nactu stejny pocet jako je v tomto OID. Ale to mi
pripada jako skrabani pravou rukou za levym uchem.
--
Mira
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
