[Nlnog] SNMP en performance impact

[Robert van der Meulen]

Quoting Boudewijn Visser (bvisser-nlnog at xs4all.nl):
> > Ik geloof dat ik je code daarvoor wel 's tegen gekomen ben ;)
> > Het probleem zit 'm opzich niet zo zeer in 't opslaan/verwerken van de
> > gegevens ('t gaat 'm meer om 't bijhouden van een configuratiesnapshot
> > dan om operationele statistieken).
> 
> Bedoel je puur een configuratie dump (copy running-config tftp, maar dan
> via snmp getriggerd), of wil je ook de interfaces e.d. langs lopen ?

Een configuratiedump zou een mogelijkheid zijn, maar is me eigenlijk een
beetje te weinig dynamisch. Het plan is in feite om alle 'bepalende'
informatie over een circuit op te halen (QoS settings, routes,
encapsulaties, profielen e.d.) en in een database te dumpen; maar dan op
grote schaal ('alle circuits' t.o.v. 'een specifiek circuit').

> Basis tip (Cisco, maar eigenlijk alle vendors) : check de bugnavigator.
> 
> Er zijn een aantal severity 1 bugs (geweest), waarbij de router kan
> reloaden bij een snmp write (wat je gebruikt om de configuratie te laten
> wegschrijven).
> Dit zijn dingen die vervelend zijn om live te ontdekken.

Ik had de (cisco) bugnavigator al gevonden inderdaad ;)
 
> Andere tip : bij zoeken in de bugnavigator, maak *geen* selectie IOS
> feature (zoals SNMP), maar geef alleen SNMP in de search string.
> Sommige SNMP bugs zijn om een of andere reden onder een andere feature, of
> in algemene categorie terecht gekomen.

Daar heb ik wel wat aan - jammer dat de boel zo slecht gecategoriseerd is..
Aan de andere kant - op 't moment dat 't cisco site handig te navigeren is,
en je in no-time wat kan vinden, lijkt 't cisco-gevoel wel een beetje weg ;)

<snip over SNMP load>

> Maar daar heb ik andere (slechte) ervaring mee.
> SNMP op zich hoeft niet zwaar te zijn, maar maar in hoog tempo queries
> doen laat de router CPU load wel degelijk fors omhoog gaan.
> Men neme een entuhprise NMS, die automatisch een topologie wil/kan
> discoveren. Autodiscovery staat default aan, natuurlijk.
> Hij doet dat door (oa) de routing table van het device uit te lezen. Geen
> goed idee, als dat een internet router met full routing is.
> De heuristiek van het systeem "als ik na een kwartier nog bezig ben, moet
> er iets misgegaan zijn, en kan ik beter opnieuw beginnen" hielp ook niet
> erg...
> De router CPU loopt dan erg hoog op.
> Moraal : geen autodiscovery. En geen spervuur van snmp get's doen.

Ouch. Dat spervuur van snmp get's was ik - voor zover mogelijk - niet van
plan, maar 'n redelijke hoeveelheid bulkget's zal 'r toch wel inzitten. Voor
een aantal devices komt dit wel neer op 'n berg get's (aangezien bulk daar
niet ondersteund wordt). Helaas heb ik nog niets kunnen vinden wat
'gracefully' een (grote) SNMP table naar binnen zuigt.
 
> > Nouja, daar gaat 't me inderdaad voornamelijk om. Als ik grote
> > hoeveelheden data naar binnen haal, wil ik niet dat 'r dingen 'averechts
> > beinvloed' worden. Voor een aantal veelgebruikte zaken gebruik ik nu al
> 
> Als je via een snelle verbinding vele duizenden items moet ophalen (10K
> met veel interfaces, allerhande counters ? ) kan dat je router CPU
> inderdaad zwaar belasten.
> Je kunt de queries efficient(er) maken, door meerdere OIDs in een enkel
> packet tegelijk op te vragen.
> (ipv een snmpget per oid) .
> Alleen kun je dan tegen rare bugs oplopen als er gaten in de interface
> index nummering zitten. De router kan dan (afhankelijk van ios versie,
> platform, etc etc) de waarden van een volgende index invullen.
> Leuke bugs dus.

Da's inderdaad een grappige - 't komt zelfs voor dat bij een walk, de
opeenvolgend geretourneerde OID's niet opeenvolgend zijn (ik las zelfs dat
in sommige hele gekke gevallen, de OID's *aflopen*!).

> Ik neem aan dat je weet dat snmp interface index nummers *niet* vast
> staan, maar kunnen veranderen na een reload ?
> (vanwege hot-inserted hardware, of software interfaces als loopback,
> tunnel e.d. Bij een reload worden de snmp indexen opnieuw genummerd).
> Er is in nieuwere IOSen een commando om de index nummering in nvram op te
> slaan. (snmp if-index persistence) .

Yep, erg onprettig (die hernummering).. Gelukkig heb ik de interfacenummers
slechts nodig om verschillende informatie aan elkaar te correleren binnen 1
snmp sessie (indexes in tables).

> Schalen : Denk na over asynchroon werken, of in elk geval tijdige
> dead-device detectie. Als er honderden queries per stuk seconden lang
> moeten time-outen kan je tool heel snel erg lang lopen.
> Als een device onbereikbaar is (maintenance, omgenummerd, typo in de
> community string e.d.).

Ik doe momenteel een snelle system check, waarmee ik tegelijkertijd
controleer of het device van het type is waarvan ik *denk* dat 't is ('hee,
da's geen MGX, da's een 10K' enzo). Momenteel houd ik (nog?) geen rekening
met meerdere sessies naar 1 device, voornamelijk omdat ik geen 'haast' heb
(het opbouwen van alle data mag best een paar uur duren). 
 
> > caches (ook omdat 't zinloos is om dat soort semi-statische data vaker
> > dan 1x per dag op te halen).
> 
> Het punt is niet zozeer het totale datavolume, maar om de CPU (of het
> access circuit, als dat klein mocht zijn) niet met een hoge piek te
> belasten.
> Wat je dus in hand moet houden is het aantal pps (cq snmp q/sec) wat je
> gedurende een bepaalde tijd op een router afvuurt.

Het circuit is opzich geen probleem, ik maak me zorgen over de CPU. Goed
punt om 's te kijken naar een scheduling systeem waarmee ik het aantal SNMP
queries per seconde mee kan limiteren, daar ga ik 's achteraan..

Groetjes,
	Robert

-- 
/^"- '-(\__/)-' -"^\
    '-.' oo '.-' Holy Jesus! What are these goddamn animals?!
       `-..-'       
            Finger rvdm at db.debian.org for my GPG key.