[Nlnog] SNMP en performance impact

[Boudewijn Visser]

> Hoi Funs,
>

[knip cricket etc, cycle ]

>
>
> 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 ?

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.


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.

[knip]


>> Mijn vraag hiernaast is dan ook nog wat regelmatige basis is ?, elke
>> vijf
>> minuten, elke tien minuten, elke minuut ? En wat voor data wil je
>> specifiek
>> pollen ?
>
> Mwa, veel minder regelmatig; dagelijks, of wellicht nog minder frequent.
> Het gaat echt specifiek om configuratiedata - welke circuits zijn er,
> met welke parameters en route.
>
>> Load wise hoeft het niet veel te zijn, SNMP is heel licht, dus dat is
>> geen
>> issue, het is vaak de onderliggende crap en slechte implementatie die
>> ervoor
>> zorgt dat er problemen zijn met SNMP. Veel devices supporten niet echt
>> netjes
>> bulk retrieval en bouwen voor elke OID die gevraagd wordt de hele table
>> opnieuw (net-snmp/snmpx/enz). Daar komt het verhaal ook vandaan dat snmp
>> "zwaar" zou zijn voor sommige devices, de brakke implementatie in de
>> software van deze devices zorgde er in het verleden nog weleens voor dat
>> dingen op hun gezicht gingen. De aparatuur die jij boven noemt heeft er
>> relatief weinig last van, er zijn mensen die zeggen van wel, maar het
>> spelen
>> met de devices leert mij dat de retrieval van SNMP data niet voor
>> problemen
>> zorgt.

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.

>
> 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.

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) .

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.).

> 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.

Boudewijn