Dette indlæg er alene udtryk for skribentens egen holdning.

Network Management: en skuffelse

3 kommentarer.  Hop til debatten
Blogindlæg17. april 2008 kl. 22:44
errorÆldre end 30 dage

Der er et spørgsmål jeg ikke ser stillet i forbindelse med IBM's syge switch:

Hvorfor kunne IBM avancerede network management console ikke på ganske få minutter give en helt klar diagnose og sige "Jeg har disablet port 7 på grund af en loop" ?

Hvis der er noget gyldent løfte fra Internettets barndom vi stadig mangler at se indfriet, så er det network management der kan mere end et barn med et whiteboard kan: tegne ting i klare farver.

Hvis jeg skal være helt grov, så har SNMP branchen spillet fallit.

Artiklen fortsætter efter annoncen

Siden 1990 har min standardudfordring, til folk der er stolte af deres network management system, været om de kan lave en alarm når en point-to-point linie taber pakker over en eller anden grænseværdi.

Alle med leased-lines ved hvorfor det er interessant at vide: blame-allocation overfor tele udbydere.

Med mindre de har lavet denne helt basale funktionalitet i de sidste 15 måneder, så er der stadig ingen af de "store" i det marked der kan lave denne helt simple alarmfunktion.

Filmen knækkede for SNMP helt fra begyndelsen, for to af de koryfæer der var faddere for SNMP protokollen, Jeff "Dr. SNMP" Case og Marshall Rose, havde den helt klare indstilling at netværksenheder blot skulle exportere de rå data, så skulle management-konsollen nok selv finde ud af hvad der var galt. Det hænger muligvis sammen med at de begge forsøgte at tjene penge på at sælge managementkonsoller.

Artiklen fortsætter efter annoncen

Hvis man bladrer MIB'erne igennem for en mellemstor router idag, så er det ikke usædvanligt at finde flere tusinde SNMP variabler man bør holde øje med, hvis man vil kunne sige "alt vel" med nogen som helst overbevisning.

Og det siger sig selv, at hvis der er netværksproblemer er det ikke altid nemt at hente et par tusinde SNMP variabler...

Jeg er ked af at sige det, men med mindre spørgsmålet er så simpelt som "hvad farve lyser lysdioderne" er svaret ikke SNMP.

IBM's NetView er langt fra den ringeste af SNMP konsollerne, men overfor for en eller anden tilfældig switch, der er del i en loop, nytter det ikke noget.

I bedste fald lyste et stort segment af nettet op i rødt, netop som den første kunde hang i telefonen og brokkede sig.

phk

3 kommentarer.  Hop til debatten
Debatten
Log ind for at deltage i debatten.
settingsDebatindstillinger
3
18. april 2008 kl. 13:50

Det kræver også stort mod (big b*lls) at beskytte sig med f.eks. de muligheder Cisco tillader. F.eks. kan du få en Cisco til at shutte en port hvis en bestemt type af traffik fylder mere end x% af båndbredden.. men hvem vil lige stå til ansvar den dag backuppen tilfældigvis når grænsen og nettet går ned fordi switchen troede der var et loop ?

2
18. april 2008 kl. 10:09

Jeg synes, at SNMP er ganske fint, bortset fra: Det kan være svært at skaffe MIB'er (som er nødvendige for at omsætte de numeriske OIDer til noget nogenlunde håndtérbart). Fx. har IBM ikke noget centralt download-sted for MIBer til IBM-produkter. Og hvis vi bliver ved IBM er der adskillige af IBMs produkter, som man ikke kan overvåge med SNMP, selvom det ville være oplagt (fx. IBMs DS4000 SAN-systemer - og senest har DB2 mistet SNMP-overvågningsmulighed).

At finde de rette parametre og tærskelværdier ved monitorering er under alle omstændigheder en ikke-triviel opgave som kræver vedholdenhed. - Ligegyldig om SNMP bruges som "transportvej" eller ej.

1
17. april 2008 kl. 23:54

Nu har jeg selv haft "fornøjelsen" at skrive en del software til at hente diverse information med SNMP og at hente et par tusinde SNMP værdier kan godt lade sig gøre, dog med lidt besvær:

For det er jo ikke kun en kasse man skal hente fra, det er jo samtlige og dem kan der godt være 2000-3000 af på et stort netværk.

Og da man jo godt vil sende flere requests til samme kasse så det går lidt hurtigere kommer man hurtigt op på 10-20 udestående requests pr. kasse.

Og 60000 tråde er de færreste servere langt fra glade for at holde styr på. Og som en lille bonus kan nogen kasse godt finde på at sende korrumperede pakker hvis software er lidt for gammel og de har travlt. Noget de flest standard snmp libs ikke helt kan håndtere uden seqfault.

Så skal der også lige tages højde for 10-15 års forskellige MIB version, vendor specifikke MIB's og halve implementationer der ikke helt lever op til hvad de burde.

Men hvis man først er kommet så langt så er det pære nemt :)

Men når alt det er sagt, så har det sikkert også stået i loggen, noget pænt mange "Enterprise" virksomheder ikke helt har så meget styr på som de burde.