SNMP en performance impact
Hoi allen, Ik zit al geruime tijd te lurken hier, maar heb nog niet echt gepost - 't moet 'r maar 's van komen ;) M'n vraag is eenvoudig: Ik wil enkele honderden DSLAM's, een paar MGXen, 6400's en 10K's bijna volledig leegtrekken via SNMP, op regelmatige basis. Heeft iemand hier ervaring met 't leegzuigen van grotere netwerkconfiguraties over SNMP, en dan met name impact op performance/load, en/of handige tips om bulk SNMP retrievals te doen op 'n zo vriendelijk mogelijke manier? Groetjes, Robert -- /^"- '-(\__/)-' -"^\ '-.' oo '.-' Holy Jesus! What are these goddamn animals?! `-..-' Finger rvdm at db.debian.org for my GPG key.
Hi Robert, On Fri, Jan 14, 2005 at 03:00:03PM +0100, Robert van der Meulen wrote:
M'n vraag is eenvoudig: Ik wil enkele honderden DSLAM's, een paar MGXen, 6400's en 10K's bijna volledig leegtrekken via SNMP, op regelmatige basis. Heeft iemand hier ervaring met 't leegzuigen van grotere netwerkconfiguraties over SNMP, en dan met name impact op performance/load, en/of handige tips om bulk SNMP retrievals te doen op 'n zo vriendelijk mogelijke manier?
Bij mijn vorige werkgever heb ik voor een SLA project cricket gebruikt met wat modificasties hier en daar. Ik zou echter niet meer een RRD based systeem gebruiken, omdat je in de knoop komt zodra je op je rollover point van je datasources komt. Destijds heb ik ook getest met een SQL backend en dan transaction based insertion, wat een stuk sneller was. Het enige probleem was dat de data hoeveelheid nogal groot werd, je zult dan dus data weg moeten snijden, en dat is een keuze. Wat ook erg belangrijk is voor je cycle is de hoeveelheid datasources die je wil pollen, hoe meer data sources hoe langer je cycle. Wat ook belangrijk is bij de aparatuur die jij wil pollen is dat je dynamisch een "klant" moet kunnen opzoeken, iig eerder was het zo dat een klant een moving target was zodra er een kaartje getrokken werd, op een en hetzelfde device al, Je zult dus klanten moeten "mappen". Je wil namelijk ook niet dat als een engineer iets modificeert je weer opnieuw die klant moet gaan configureren op de een of andere manier in je systeem, dat wordt namelijk veel werk, en vaak gewoon niet gedaan. Een andere optie is RTG, dat leek mij wel wat, maar daar ben ik destijds niet aan toe gekomen, omdat zoals altijd het gisteren af moest zijn. Later ben ik ook nog bezig geweest met een threaded engine in combinatie met een SQL backend, maar de aandacht verslapte nogal snel :) 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 ? 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. Grtz, Funs -- Funs Kessen funsk at nl.demon.net
Hoi Funs, On Mon, 2005-01-17 at 11:23 +0100, Funs Kessen wrote:
Bij mijn vorige werkgever heb ik voor een SLA project cricket gebruikt met wat modificasties hier en daar. Ik zou echter niet meer een RRD based systeem gebruiken, omdat je in de knoop komt zodra je op je rollover point van je datasources komt. Destijds heb ik ook getest met een SQL backend en dan transaction based insertion, wat een stuk sneller was. Het enige probleem was dat de data hoeveelheid nogal groot werd, je zult dan dus data weg moeten snijden, en dat is een keuze. Wat ook erg belangrijk is voor je cycle is de hoeveelheid datasources die je wil pollen, hoe meer data sources hoe langer je 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).
Wat ook belangrijk is bij de aparatuur die jij wil pollen is dat je dynamisch een "klant" moet kunnen opzoeken, iig eerder was het zo dat een klant een moving target was zodra er een kaartje getrokken werd, op een en hetzelfde device al, Je zult dus klanten moeten "mappen". Je wil namelijk ook niet dat als een engineer iets modificeert je weer opnieuw die klant moet gaan configureren op de een of andere manier in je systeem, dat wordt namelijk veel werk, en vaak gewoon niet gedaan.
Dat kan zeker een probleem zijn, inderdaad - het 'in sync' houden van netwerk en database is geen easy feat :/
Een andere optie is RTG, dat leek mij wel wat, maar daar ben ik destijds niet aan toe gekomen, omdat zoals altijd het gisteren af moest zijn. Later ben ik ook nog bezig geweest met een threaded engine in combinatie met een SQL backend, maar de aandacht verslapte nogal snel :)
Zoiets had ik ook in gedachten inderdaad - met name het handig queue-en en combineren van queries die je uit hebt staan lijkt me een voordeel. Enige mate van caching is ook nuttig - zolang 't niet te veel is ;)
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.
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 caches (ook omdat 't zinloos is om dat soort semi-statische data vaker dan 1x per dag op te halen). Groetjes, Robert -- /^"- '-(\__/)-' -"^\ '-.' oo '.-' Holy Jesus! What are these goddamn animals?! `-..-' Finger rvdm at db.debian.org for my GPG key.
Hi Robert,
Ik geloof dat ik je code daarvoor wel 's tegen gekomen ben ;)
Hehe, ow ja dat... :)
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).
Nee dat klopt, maar het probleem zit hem dan vooral in het feit dat je niks en dan ook echt helemaal niks wil baseren op bestaande databases met configuratie data, mischien nog net wel de IPs van de devices waar je bij wil maar verder dan dat ook echt niks.
Je wil namelijk ook niet dat als een engineer iets modificeert je weer opnieuw die klant moet gaan configureren op de een of andere manier in je systeem, dat wordt namelijk veel werk, en vaak gewoon niet gedaan. Dat kan zeker een probleem zijn, inderdaad - het 'in sync' houden van netwerk en database is geen easy feat :/
Dit is inderdaad een van de grotere problemen voor bedrijven die veel verschillende "management suites" door elkaar heen gebruiken. De discrepantie tussen alle data is al genoeg om je een hartverzakking te geven :). Het wordt nog erger als er geen leading, of 180 achtige constructie is.
Een andere optie is RTG, dat leek mij wel wat, maar daar ben ik destijds niet aan toe gekomen, omdat zoals altijd het gisteren af moest zijn. Later ben ik ook nog bezig geweest met een threaded engine in combinatie met een SQL backend, maar de aandacht verslapte nogal snel :) Zoiets had ik ook in gedachten inderdaad - met name het handig queue-en en combineren van queries die je uit hebt staan lijkt me een voordeel. Enige mate van caching is ook nuttig - zolang 't niet te veel is ;)
Hmm dan is het wel voordelig om het transaction based te doen, vooral omdat als je een transaction start de data niet gecommit wordt totdat je hem daadwerkelijk commit, ipv dat je continu aan het wachten bent. Een nadeel is inderdaad dat het niet meer moet worden dan er verwerkt kan worden :)
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.
Hmm komt me bekend voor, maar dat is heel erg goed te doen, je kunt denk ik het hele netwerk in minder dan een kwartier wel in kaart brengen iig customer data, ik weet niet precies welke data je allemaal wil hebben. Er is echter een belangrijke keuze die je moet maken, en dat heeft weer te maken met de toepassing van die data. Ga je het op een per-customer basis aanpakken of op een per-device en dan all die devices aan elkaar knopen ?
met de devices leert mij dat de retrieval van SNMP data niet voor problemen zorgt. 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.
Ik zou me daar niet teveel zorgen over maken, je kunt die devices flink op hun flikker geven voordat ze niet meer responden, en dan bedoel ik ook echt flink. Ik heb in ieder geval nooit meegemaakt dat door een SNMP retrieval een van de devices barfde.
Voor een aantal veelgebruikte zaken gebruik ik nu al caches (ook omdat 't zinloos is om dat soort semi-statische data vaker dan 1x per dag op te halen).
Dat klopt zeker, de configuraties zijn daar ook wel handig voor. dat deed ik voor een tool die gebruikt werd om lijnen up te graden. Daarvoor had ik gewoon een configuration parser geschreven. Die eerst keek of de configuratie aanwezig was, en zo niet hem ging halen van het device. Grtz, Funs -- Funs Kessen funsk at nl.demon.net
Hoi, Quoting Funs Kessen (funsk at nl.demon.net):
Ik geloof dat ik je code daarvoor wel 's tegen gekomen ben ;)
Hehe, ow ja dat... :)
;)
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).
Nee dat klopt, maar het probleem zit hem dan vooral in het feit dat je niks en dan ook echt helemaal niks wil baseren op bestaande databases met configuratie data, mischien nog net wel de IPs van de devices waar je bij wil maar verder dan dat ook echt niks.
Nou, precies - netwerk als uitgangspunt. <snip meer over inconsequent netwerk vs. databases>
Een andere optie is RTG, dat leek mij wel wat, maar daar ben ik destijds niet aan toe gekomen, omdat zoals altijd het gisteren af moest zijn. Later ben ik ook nog bezig geweest met een threaded engine in combinatie met een SQL backend, maar de aandacht verslapte nogal snel :) Zoiets had ik ook in gedachten inderdaad - met name het handig queue-en en combineren van queries die je uit hebt staan lijkt me een voordeel. Enige mate van caching is ook nuttig - zolang 't niet te veel is ;)
Hmm dan is het wel voordelig om het transaction based te doen, vooral omdat als je een transaction start de data niet gecommit wordt totdat je hem daadwerkelijk commit, ipv dat je continu aan het wachten bent. Een nadeel is inderdaad dat het niet meer moet worden dan er verwerkt kan worden :)
Nouja, da's een kwestie van handig verdelen, inderdaad ;)
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.
Hmm komt me bekend voor, maar dat is heel erg goed te doen, je kunt denk ik het hele netwerk in minder dan een kwartier wel in kaart brengen iig customer data, ik weet niet precies welke data je allemaal wil hebben. Er is echter een belangrijke keuze die je moet maken, en dat heeft weer te maken met de toepassing van die data. Ga je het op een per-customer basis aanpakken of op een per-device en dan all die devices aan elkaar knopen ?
Voor dit soort zaken lijkt 't me gekkenwerk om customer-voor-customer dingen na te gaan lopen; veel te veel duplicate data die je ophaalt, overhead. In feite kan je 't best gewoon een device leegzuigen, en 't knoopwerk achteraf doen (en hopen dat er niet teveel is veranderd in de tussentijd).
met de devices leert mij dat de retrieval van SNMP data niet voor problemen zorgt. 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.
Ik zou me daar niet teveel zorgen over maken, je kunt die devices flink op hun flikker geven voordat ze niet meer responden, en dan bedoel ik ook echt flink. Ik heb in ieder geval nooit meegemaakt dat door een SNMP retrieval een van de devices barfde.
Hmm, 't enige wat ik (vaak) heb, is 't afbreken van SNMP sessies bij 't doen van grote walks. Vooral v1 devices zijn daar goed in (wegens de afwezigheid van bulk mogelijkheid).
Voor een aantal veelgebruikte zaken gebruik ik nu al caches (ook omdat 't zinloos is om dat soort semi-statische data vaker dan 1x per dag op te halen).
Dat klopt zeker, de configuraties zijn daar ook wel handig voor. dat deed ik voor een tool die gebruikt werd om lijnen up te graden. Daarvoor had ik gewoon een configuration parser geschreven. Die eerst keek of de configuratie aanwezig was, en zo niet hem ging halen van het device.
Ik heb inderdaad 'n redelijk deel in databases zitten - dat komt de snelheid en 'load' behoorlijk ten goede. Groetjes, Robert -- /^"- '-(\__/)-' -"^\ '-.' oo '.-' Holy Jesus! What are these goddamn animals?! `-..-' Finger rvdm at db.debian.org for my GPG key.
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
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.
participants (3)
-
bvisser-nlnog＠xs4all.nl -
funsk＠nl.demon.net -
nlnog＠wiretrip.org