Synliggjøre kvalitetsfeil i nettverket

[sjurtf]

I dag titter vi ikke på CRC/drops osv som finnes i nettet.
Dette bør vi legge til støtte for å redusere helsen på en switch/ruter.

[KristianLyng]

Fase en her er:

1. Ta en titt på det vi har av SNMP-tellere alt - vi ønsker nok å legge til et par OIDer etter hvert, men det går fint å begynne med det vi har. Jeg tenker ifOutDiscards, ifOutErrors, ifInErrors og ifInDiscards er de relevante her. Dette er statiske tellere som alltid går opp. Du må bruke nmsData sin "then" struktur for å sammenligne to forskjellige målinger for å finne en endring. Se på "trafficUpdater()" i nms-map-handler.js for et eksempel på dette. Det enkleste her er å titte på tg19-data - eller vente til gondul er oppe i skipet (som skjer straks).
2. Lag en ny map-handler i nms-map-handlers.js - den eneste funksjonen som må implementeres er "getInfo" - handler_health vil ta seg av å faktisk kalle den for deg så lenge handleren er nevnt i var handlers (nms-map-handlers.js:136 i min kopi). Det er litt vrient å vite hva som er riktig "score" her, men jeg foreslår relativt lav - 200 kanskje som baseline om det er diff i de tellerene jeg nevnte over - det vil påvirke farge/alvorsgrad.
3. Jeg tror ikke vi bryr oss om alle porter. Jeg tenker et godt startpunkt er: Har ikke porten noen verdi på "ifAlias" (spiller ingen rolle hva verdien er i starten - det betyr at den er definert i konfig i praksis) ELLER porten har ifOperStatus som ikke er "up" (porten er nede - da vil det være naturlig med discards i det noen plugger den ut f.eks.) så kan vi ignorere den. Jeg mistenker vi må til med mer magi her for å luke ut støy, men et sted må vi begynne.
4. Dette VIL måtte justeres under TG - her er poenget mest å bare starte litt.

[sklirg]

Vi så ifErrors på e2.bird under avvikling av TG23, så der burde det være data å teste mot.