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.