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