Whitepaper over best practices voor basisprocessen

Inleiding

Dit document beschrijft basislijnconcepten en procedures voor netwerken met hoge beschikbaarheid. Het bevat kritieke succesfactoren voor het baselineren van netwerken en drempelwaarden om succes te helpen evalueren. Het biedt ook belangrijke details voor baseline- en drempelprocessen en implementatie die de richtlijnen voor best practices volgen die zijn vastgesteld door het team van Cisco's High Availability Services (HAS).

Dit document neemt u stap voor stap door het proces van baselining. Sommige huidige producten van het netwerkbeheersysteem (NMS) kunnen dit proces helpen automatiseren, maar het basislijnproces blijft hetzelfde, of u nu geautomatiseerde of handmatige hulpmiddelen gebruikt. Als u deze NMS-producten gebruikt, moet u de standaarddrempelinstellingen voor uw unieke netwerkomgeving aanpassen. Het is belangrijk om een proces te hebben om die drempels op een intelligente manier te kiezen, zodat ze zinvol en correct zijn.

basislijn

Wat is een baseline?

Een baseline is een proces om het netwerk op regelmatige tijdstippen te bestuderen om ervoor te zorgen dat het netwerk werkt zoals ontworpen. Het is meer dan een enkel rapport waarin de gezondheid van het netwerk op een bepaald moment wordt beschreven. Door het basislijnproces te volgen, kunt u de volgende informatie verkrijgen:

• Krijg waardevolle informatie over de gezondheid van de hardware en software

• Bepaal het huidige gebruik van netwerkbronnen

• Nauwkeurige beslissingen nemen over de alarmdrempels van het netwerk

• Huidige netwerkproblemen identificeren

• Toekomstige problemen voorspellen

Een andere manier om naar de basislijn te kijken, wordt geïllustreerd in het volgende diagram.

De rode lijn, het netwerkbreekpunt, is het punt waarop het netwerk zal breken, dat wordt bepaald door de kennis van hoe de hardware en software presteren. De groene lijn, de netwerkbelasting, is de natuurlijke voortgang van de belasting op het netwerk als nieuwe toepassingen worden toegevoegd, en andere dergelijke factoren.

Het doel van een baseline is om te bepalen:

• Waar uw netwerk zich bevindt op de groene lijn

• Hoe snel de netwerkbelasting toeneemt

• Hopelijk voorspellen we op welk moment de twee elkaar kruisen

Door regelmatig een basislijn uit te voeren, kunt u de huidige toestand achterhalen en extrapoleren wanneer er fouten optreden en u er van tevoren op voorbereiden. Dit helpt u ook om beter geïnformeerde beslissingen te nemen over wanneer, waar en hoe u budgetgeld kunt besteden aan netwerkupgrades.

Waarom een baseline?

Een basisproces helpt u bij het identificeren en goed plannen van kritieke bronbeperkingsproblemen in het netwerk. Deze problemen kunnen worden beschreven als controlevliegtuigbronnen of gegevensvliegtuigbronnen. Besturingsvliegtuigbronnen zijn uniek voor het specifieke platform en de modules in het apparaat en kunnen worden beïnvloed door een aantal problemen, waaronder:

• Gegevensgebruik

• Functies ingeschakeld

• Netwerkontwerp

Besturingsvliegtuigbronnen bevatten parameters zoals:

• CPU-gebruik

• Geheugengebruik

• Buffergebruik

De bronnen van het gegevensvlak worden alleen beïnvloed door het type en de hoeveelheid verkeer en omvatten het gebruik van verbindingen en backplanegebruik. Door het gebruik van bronnen voor kritieke gebieden te baselen, kunt u ernstige prestatieproblemen voorkomen, of erger nog, een netwerkmeltdown.

Met de introductie van latentiegevoelige toepassingen zoals spraak en video is baselining nu belangrijker dan ooit. Traditionele Transmission Control Protocol/Internet Protocol (TCP/IP) toepassingen zijn vergevingsgezind en zorgen voor een zekere mate van vertraging. Voice en video zijn gebaseerd op het User Datagram Protocol (UDP) en staan geen heruitzendingen of netwerkcongestie toe.

Dankzij de nieuwe mix van toepassingen helpt baselining u om zowel problemen met het gebruik van de besturingsvlakken als met het gebruik van de databasebronnen te begrijpen en proactief te plannen voor wijzigingen en upgrades om blijvend succes te garanderen.

Datanetwerken bestaan al jaren. Tot voor kort was het houden van de netwerken een redelijk vergevingsgezind proces, met enige foutmarge. Met de toenemende acceptatie van latentiegevoelige applicaties zoals Voice over IP (VoIP), wordt het runnen van het netwerk steeds moeilijker en vereist het meer precisie. Om preciezer te zijn en een netwerkbeheerder een solide basis te geven waarop het netwerk kan worden beheerd, is het belangrijk om een idee te hebben van hoe het netwerk werkt. Om dit te doen, moet u een proces doorlopen dat een basislijn wordt genoemd.

basisdoelstelling

Het doel van een baseline is:

1. De huidige status van netwerkapparaten bepalen

2. Vergelijk die status met standaard prestatierichtlijnen

3. Stel drempelwaarden in om u te waarschuwen wanneer de status deze richtlijnen overschrijdt

Vanwege de grote hoeveelheid gegevens en de hoeveelheid tijd die het kost om de gegevens te analyseren, moet u eerst de reikwijdte van een basislijn beperken om het gemakkelijker te maken om het proces te leren. De meest logische, en soms de meest voordelige, plek om te beginnen is met de kern van het netwerk. Dit deel van het netwerk is meestal het kleinste en vereist de meeste stabiliteit.

Eenvoudigheidshalve wordt in dit document uitgelegd hoe u een zeer belangrijke Simple Network Management Protocol Management Information Base (SNMP MIB) kunt baselen: cpmCPUTotal5min. cpmCPUTotal5min is het vijf minuten durende rottingsgemiddelde van de centrale verwerkingseenheid (CPU) van een Cisco-router en is een prestatie-indicator voor het controlevlak. De basislijn wordt uitgevoerd op een Cisco 7000-serie router.

Zodra u het proces hebt geleerd, kunt u het toepassen op alle gegevens die beschikbaar zijn in de uitgebreide SNMP-database die beschikbaar is in de meeste Cisco-apparaten, zoals:

• Gebruik van Integrated Services Digital Network (ISDN)

• Asynchronous Transfer Mode (ATM)-celverlies

• Gratis systeemgeheugen

Stroomdiagram basislijn

Het volgende stroomschema toont de basisstappen van het basislijnproces van de kern. Hoewel er producten en hulpmiddelen beschikbaar zijn om een aantal van deze stappen voor u uit te voeren, hebben ze vaak hiaten in flexibiliteit of gebruiksgemak. Zelfs als u van plan bent om tools voor netwerkbeheersystemen (NMS) te gebruiken om baselining uit te voeren, is dit nog steeds een goede oefening in het bestuderen van het proces en het begrijpen hoe uw netwerk echt werkt. Dit proces kan ook een deel van het mysterie wegnemen van hoe sommige NMS-tools werken, omdat de meeste tools in wezen dezelfde dingen doen.

Basisprocedure

Stap 1: Een inventaris van hardware, software en configuratie samenstellen

Het is uiterst belangrijk dat u om verschillende redenen een inventaris van hardware, software en configuratie opstelt. Ten eerste zijn Cisco SNMP MIB's in sommige gevallen specifiek voor de Cisco IOS-release die u uitvoert. Sommige MIB-objecten worden vervangen door nieuwe of worden soms volledig geëlimineerd. De hardware-inventaris is het belangrijkst nadat de gegevens zijn verzameld, omdat de drempels die u na de initiële basislijn moet instellen, vaak zijn gebaseerd op het type CPU, de hoeveelheid geheugen, enzovoort, op de Cisco-apparaten. De configuratie-inventaris is ook belangrijk om ervoor te zorgen dat u de huidige configuraties kent: u kunt apparaatconfiguraties na uw basislijn wijzigen om buffers af te stemmen, enzovoort.

De meest efficiënte manier om dit deel van de basislijn voor een Cisco-netwerk te doen, is met CiscoWorks2000 Resource Manager Essentials (Essentials). Als deze software correct in het netwerk is geïnstalleerd, moet Essentials de huidige inventarissen van alle apparaten in de database hebben. U hoeft alleen maar naar de inventarissen te kijken om te zien of er problemen zijn.

De volgende tabel is een voorbeeld van een Cisco Router Class-software-inventarisatierapport dat is geëxporteerd vanuit Essentials en vervolgens is bewerkt in Microsoft Excel. Merk op dat u uit deze inventarisatie SNMP MIB-gegevens en Object Identifiers (OID's) moet gebruiken die zijn gevonden in de 12.0x en 12.1x Cisco IOS-releases.

Device Name (Apparaatnaam)	Routertype	Versie	Softwareversie
field-2500a.embu-mlab.cisco.com	Cisco 2511	M	12.1(1)
qdm-7200.embu-mlab.cisco.com	Cisco 7204	B	12.1, lid 1, onder e)
voip-3640.embu-mlab.cisco.com	Cisco 3640	0x00	12,0(3c)
wan-1700a.embu-mlab.cisco.com	Cisco 1720	0x101	12.1(4)
wan-2500a.embu-mlab.cisco.com	Cisco 2514	L	12.0(1)
wan-3600a.embu-mlab.cisco.com	Cisco 3640	0x00	12.1(3)
wan-7200a.embu-mlab.cisco.com	Cisco 7204	B	12.1, lid 1, onder e)
172.16.71.80	Cisco 7204	B	12,0(5T)

Als Essentials niet in het netwerk is geïnstalleerd, kunt u de UNIX-opdrachtregeltool snmpwalk vanaf een UNIX-werkstation gebruiken om de IOS-versie te vinden. Dit wordt getoond in het volgende voorbeeld. Als u niet zeker weet hoe deze opdracht werkt, typt u man snmpwalk bij de UNIX-prompt voor meer informatie. De IOS-versie is belangrijk wanneer u begint met het kiezen van welke MIB-OID's u wilt baselen, omdat de MIB-objecten afhankelijk zijn van IOS. Merk ook op dat door het routertype te kennen, u later kunt bepalen wat de drempels moeten zijn voor CPU, buffers, enzovoort.

nsahpov6% snmpwalk -v1 -c private 172.16.71.80 system
system.sysDescr.0 : DISPLAY STRING- (ascii): Cisco Internetwork Operating System Software
IOS (tm) 7200 Software (C7200-JS-M), Version 12.0(5)T, RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2001 by cisco Systems, Inc.
Compiled Fri 23-Jul-2001 23:02 by kpma
system.sysObjectID.0 : OBJECT IDENTIFIER:
.iso.org.dod.internet.private.enterprises.cisco.ciscoProducts.cisco7204

Stap 2: Controleer of de SNMP MIB wordt ondersteund in de router

Nu u een inventaris hebt van het apparaat dat u wilt peilen voor uw basislijn, kunt u beginnen met het kiezen van de specifieke OID's die u wilt peilen. Het scheelt een hoop frustratie als je van tevoren controleert of de data die je wilt er daadwerkelijk is. Het object cpmCPUTotal5min MIB bevindt zich in het CISCO-PROCESS-MIB.

Om de OID te vinden die u wilt peilen, hebt u een conversietabel nodig die beschikbaar is op de CCO-website van Cisco. Om toegang te krijgen tot deze website vanuit een webbrowser, gaat u naar de MIB's-pagina van Cisco en klikt u op de koppeling OID's.

Als u deze website vanaf een FTP-server wilt openen, typt u ftp://ftp.cisco.com/pub/mibs/oid/. Vanaf deze site kunt u de specifieke MIB downloaden die is gedecodeerd en gesorteerd op OID-nummers.

Het volgende voorbeeld is geëxtraheerd uit de CISCO-PROCESS-MIB.oid tabel. Dit voorbeeld laat zien dat de OID voor de cpmCPUTotal5min MIB .1.3.6.1.4.1.9.9.109.1.1.1.1.5 is.

Opmerking: Vergeet niet om een "." toe te voegen aan het begin van de OID of u krijgt een fout wanneer u probeert om het te pollen. U moet ook een ".1" toevoegen aan het einde van de OID om deze te instantiëren. Dit vertelt het apparaat de instantie van de OID die u zoekt. In sommige gevallen hebben OID's meer dan één exemplaar van een bepaald type gegevens, zoals wanneer een router meerdere CPU's heeft.

ftp://ftp.cisco.com/pub/mibs/oid/CISCO-PROCESS-MIB.oid
### THIS FILE WAS GENERATED BY MIB2SCHEMA
"org" "1.3"
"dod" "1.3.6"
"internet" "1.3.6.1"
"directory" "1.3.6.1.1"
"mgmt" "1.3.6.1.2"
"experimental" "1.3.6.1.3"
"private" "1.3.6.1.4"
"enterprises" "1.3.6.1.4.1"
"cisco" "1.3.6.1.4.1.9"
"ciscoMgmt" "1.3.6.1.4.1.9.9"
"ciscoProcessMIB" "1.3.6.1.4.1.9.9.109"
"ciscoProcessMIBObjects" "1.3.6.1.4.1.9.9.109.1"
"ciscoProcessMIBNotifications" "1.3.6.1.4.1.9.9.109.2"
"ciscoProcessMIBConformance" "1.3.6.1.4.1.9.9.109.3"
"cpmCPU" "1.3.6.1.4.1.9.9.109.1.1"
"cpmProcess" "1.3.6.1.4.1.9.9.109.1.2"
"cpmCPUTotalTable" "1.3.6.1.4.1.9.9.109.1.1.1"
"cpmCPUTotalEntry" "1.3.6.1.4.1.9.9.109.1.1.1.1"
"cpmCPUTotalIndex" "1.3.6.1.4.1.9.9.109.1.1.1.1.1"
"cpmCPUTotalPhysicalIndex" "1.3.6.1.4.1.9.9.109.1.1.1.1.2"
"cpmCPUTotal5sec" "1.3.6.1.4.1.9.9.109.1.1.1.1.3"
"cpmCPUTotal1min" "1.3.6.1.4.1.9.9.109.1.1.1.1.4"
"cpmCPUTotal5min" "1.3.6.1.4.1.9.9.109.1.1.1.1.5"

Er zijn twee veel voorkomende manieren om de MIBOID te peilen om ervoor te zorgen dat deze beschikbaar en functioneel is. Het is een goed idee om dit te doen voordat u begint met het verzamelen van bulkgegevens, zodat u geen tijd verspilt aan het pollen van iets dat er niet is en eindigt met een lege database. Een manier om dit te doen is om een MIB-walker van uw NMS-platform te gebruiken, zoals HP OpenView Network Node Manager (NNM) of CiscoWorks Windows, en voer de OID in die u wilt controleren.

Het volgende is een voorbeeld van HP OpenView SNMP MIB walker.

Een andere eenvoudige manier om de MIB OID te peilen, is door de UNIX-opdracht snmpwalk te gebruiken zoals in het volgende voorbeeld wordt getoond.

nsahpov6% cd /opt/OV/bin
nsahpov6% snmpwalk -v1 -c private 172.16.71.80 .1.3.6.1.4.1.9.9.109.1.1.1.1.5.1

cisco.ciscoMgmt.ciscoProcessMIB.ciscoProcessMIBObjects.cpmCPU.cpmCPUTotalTable.cpmCPUTotalEntry.cpmCPUTotal5min.1 : Gauge32: 0

In beide voorbeelden retourneerde de MIB een waarde van 0, wat betekent dat voor die pollingcyclus de CPU gemiddeld 0 procent gebruik had. Als u moeite heeft om het apparaat te laten reageren met de juiste gegevens, probeer dan het apparaat te pingen en toegang te krijgen tot het apparaat via Telnet. Als u nog steeds een probleem hebt, controleert u de SNMP-configuratie en de SNMP-communitytekenreeksen. Mogelijk moet u een alternatieve MIB of een andere versie van IOS vinden om dit te laten werken.

Stap 3: Poll en Record Specific SNMP MIB Object van de Router

Er zijn verschillende manieren om MIB-objecten te peilen en de uitvoer op te nemen. Er zijn kant-en-klare producten, sharewareproducten, scripts en hulpmiddelen van leveranciers beschikbaar. Alle front-end tools gebruiken het SNMP get proces om de informatie te verkrijgen. De belangrijkste verschillen zijn de flexibiliteit van de configuratie en de manier waarop de gegevens in een database worden vastgelegd. Nogmaals, kijk naar de processor MIB om te zien hoe deze verschillende methoden werken.

Nu u weet dat de OID wordt ondersteund in de router, moet u beslissen hoe vaak u deze wilt pollen en hoe u deze wilt opnemen. Cisco raadt aan om de MIB van de CPU met tussenpozen van vijf minuten te peilen. Een lager interval zou de belasting op het netwerk of apparaat verhogen, en aangezien de MIB-waarde toch een gemiddelde van vijf minuten is, zou het niet nuttig zijn om het vaker te peilen dan de gemiddelde waarde. Het wordt ook over het algemeen aanbevolen dat basispeilingen ten minste een periode van twee weken hebben, zodat u ten minste twee wekelijkse bedrijfscycli op het netwerk kunt analyseren.

De volgende schermen laten zien hoe u MIB-objecten kunt toevoegen met HP OpenView Network Node Manager versie 6.1. Selecteer in het hoofdscherm Opties > Gegevensverzameling en drempelwaarden.

Selecteer vervolgens Bewerken > Toevoegen > MIB-objecten.

Voeg in het menu de OID-tekenreeks toe en klik op Toepassen. U hebt nu het MIB-object ingevoerd in het HP OpenView-platform, zodat het kan worden gepolst.

Vervolgens moet u HP OpenView laten weten welke router u moet kiezen voor deze OID.

Selecteer in het menu Gegevensverzameling Bewerken > Toevoegen > MIB-verzamelingen.

Voer in het veld Bron de naam of het IP-adres van het Domain Naming System (DNS) van de router in die moet worden gepolst.

Selecteer Winkel, Geen drempelwaarden in de lijst Verzamelmodus instellen.

Stel het steminterval in op 5 m, voor intervallen van vijf minuten.

Klik op Apply (Toepassen).

U moet Bestand > Opslaan selecteren om de wijzigingen te kunnen doorvoeren.

Als u wilt controleren of de verzameling goed is ingesteld, markeert u de regel voor het overzicht van de verzameling voor de router en selecteert u Acties > SNMP testen. Dit controleert of de community string correct is en zal pollen voor alle instanties van de OID.

Klik op Sluiten en laat de collectie een week lopen. Aan het einde van de wekelijkse periode extraheert u de gegevens voor analyse.

De gegevens worden gemakkelijker geanalyseerd als u deze naar een ASCII-bestand dumpt en importeert in een spreadsheetprogramma zoals Microsoft Excel. Om dit te doen met HP OpenView NNNM, kunt u de opdrachtregeltool gebruiken, snmpCoolDump. Elke geconfigureerde verzameling schrijft naar een bestand in de directory /var/opt/OV/share/databases/snmpCollect/.

Extract de gegevens naar een ASCII-bestand genaamd testfile met de volgende opdracht:

snmpColDump /var/opt/OV/share/databases/snmpCollect/cpmCPUTotal5min.1 > testfile

Opmerking: cpmCPUTotal5min.1 is het databasebestand dat HP OpenView NNM heeft gemaakt toen de OID-polling begon.

Het gegenereerde testbestand lijkt op het volgende voorbeeld.

03/01/2001 14:09:10 nsa-gw.cisco.com 1
03/01/2001 14:14:10 nsa-gw.cisco.com 1
03/01/2001 14:19:10 nsa-gw.cisco.com 1
03/01/2001 14:24:10 nsa-gw.cisco.com 1
03/01/2001 14:29:10 nsa-gw.cisco.com 1
03/01/2001 14:34:10 nsa-gw.cisco.com 1
03/01/2001 14:39:10 nsa-gw.cisco.com 1
03/01/2001 14:44:10 nsa-gw.cisco.com 1
03/01/2001 14:49:10 nsa-gw.cisco.com 1
03/01/2001 14:54:10 nsa-gw.cisco.com 1
03/01/2001 14:59:10 nsa-gw.cisco.com 1
03/………

Zodra de uitvoer van het testbestand op uw UNIX-station staat, kunt u het overbrengen naar uw pc met behulp van FTP (File Transfer Protocol).

U kunt de gegevens ook verzamelen met behulp van uw eigen scripts. Om dit te doen, voert u elke vijf minuten een snmpget voor de CPU-OID uit en dumpt u de resultaten in een .csv-bestand.

Stap 4: Gegevens analyseren om drempelwaarden te bepalen

Nu je wat gegevens hebt, kun je beginnen met het analyseren ervan. Deze fase van de basislijn bepaalt de drempelwaarde-instellingen die u kunt gebruiken en die een nauwkeurige meting van prestaties of fouten zijn en niet te veel alarmen zullen afgaan wanneer u drempelwaardebewaking inschakelt. Een van de eenvoudigste manieren om dit te doen is om de gegevens te importeren in een spreadsheet zoals Microsoft Excel en een spreidingsdiagram te plotten. Deze methode maakt het heel gemakkelijk om te zien hoe vaak een bepaald apparaat een uitzonderingswaarschuwing zou hebben gemaakt als u het voor een bepaalde drempel zou monitoren. Het is niet raadzaam om drempelwaarden in te schakelen zonder een basislijn te gebruiken, omdat dit waarschuwingsstormen kan veroorzaken van apparaten die de door u gekozen drempelwaarde hebben overschreden.

Als u het testbestand in een Excel-spreadsheet wilt importeren, opent u Excel en selecteert u Bestand > Openen en selecteert u uw gegevensbestand.

De Excel-toepassing vraagt u vervolgens om het bestand te importeren.

Als u klaar bent, moet het geïmporteerde bestand er ongeveer hetzelfde uitzien als in het volgende scherm.

Met een spreidingsdiagram kunt u gemakkelijker visualiseren hoe verschillende drempelinstellingen op het netwerk zouden werken.

Als u het spreidingsdiagram wilt maken, markeert u kolom C in het geïmporteerde bestand en klikt u op het pictogram van de wizard Grafiek. Volg vervolgens de stappen door de wizard Grafiek voor het maken van een spreidingsdiagram.

Selecteer in stap 1 van de wizard Grafiek, zoals hieronder wordt weergegeven, het tabblad Standaardtypen en selecteer het type XY (Scatter)-grafiek. Klik vervolgens op Volgende.

Selecteer in stap 2 van de wizard Grafiek, zoals hieronder wordt weergegeven, het tabblad Gegevensbereik en selecteer het gegevensbereik en de optie Kolommen. Klik op Next (Volgende).

Voer in stap 3 van de wizard Grafiek, zoals hieronder wordt weergegeven, de grafiektitel en de waarden van de X- en Y-as in en klik vervolgens op Volgende.

Selecteer in stap 4 van de wizard Grafiek of u het spreidingsdiagram op een nieuwe pagina of als object op de bestaande pagina wilt hebben.

Klik op Voltooien om de grafiek op de gewenste locatie te plaatsen.

"Wat als?" analyse

U kunt nu de spreidingsgrafiek gebruiken voor analyse. Voordat u verder gaat, moet u echter de volgende vragen stellen:

• Wat beveelt de leverancier (in dit voorbeeld is Cisco de leverancier) aan als drempel voor deze MIB-variabele?

  In het algemeen beveelt Cisco aan dat een core router niet meer dan 60 procent gemiddeld CPU-gebruik. Zestig procent werd gekozen omdat een router wat overhead nodig heeft voor het geval het problemen ondervindt of het netwerk enkele storingen heeft. Cisco schat dat een core router ongeveer 40 procent CPU-overhead nodig heeft in het geval dat een routeringsprotocol opnieuw moet berekenen of converteren. Deze percentages variëren op basis van de protocollen die u gebruikt en de topologie en stabiliteit van uw netwerk.

• Wat als ik 60 procent als drempelwaarde gebruik?

  Als u een lijn over de spreidingsgrafiek horizontaal op 60 tekent, ziet u dat geen van de gegevenspunten meer is dan 60 procent CPU-gebruik. Een drempel van 60 op uw netwerkbeheersysteem (NMS) stations zal dus geen drempelalarm hebben ingesteld tijdens de stemperiode. Een percentage van 60 is acceptabel voor deze router. Merk echter op in het spreidingsdiagram dat sommige gegevenspunten dicht bij 60 liggen. Het zou leuk zijn om te weten wanneer een router de drempel van 60 procent nadert, zodat u van tevoren kunt weten dat de CPU de 60 procent nadert en een plan hebt voor wat u moet doen als het dat punt bereikt.

• Wat als ik de drempel op 50 procent zet?

  Er wordt geschat dat deze router vier keer 50 procent gebruik bereikte tijdens deze pollingcyclus en elke keer een drempelalarm zou hebben gegenereerd. Dit proces wordt belangrijker wanneer u naar groepen routers kijkt om te zien wat de verschillende drempelinstellingen zouden doen. Bijvoorbeeld: "Wat als ik de drempel voor het hele kernnetwerk op 50 procent stel?" Het is moeilijk om slechts één nummer te kiezen.

CPU-drempelwaarde "What If"-analyse

Een strategie die u kunt gebruiken om dit gemakkelijker te maken, is de drempelmethode Ready, Set, Go. Deze methode gebruikt drie drempelgetallen achter elkaar.

• Klaar - de drempel die u instelt als voorspeller van welke apparaten in de toekomst waarschijnlijk aandacht nodig hebben

• Stel—de drempel in die wordt gebruikt als een vroege indicator, die u waarschuwt om te beginnen met de planning voor een reparatie, herconfiguratie of upgrade

• Ga - de drempel die u en / of de leverancier geloven is een fout voorwaarde en vereist enige actie om het te repareren; in dit voorbeeld is het 60 procent

De volgende tabel toont de strategie van de strategie Ready, Set, Go.

drempel	Actie	resultaat
45 procent	Verder onderzoeken	Lijst van opties voor actieplannen
50 procent	Actieplan opstellen	Lijst van stappen in het actieplan
60 procent	Uitvoering van het actieplan	Router overschrijdt niet langer de drempelwaarden. Terug naar Ready-modus

De methode Ready, Set, Go wijzigt de oorspronkelijke basislijngrafiek die eerder is besproken. Het volgende diagram toont de gewijzigde basislijngrafiek. Als u de andere snijpunten op de grafiek kunt identificeren, hebt u nu meer tijd om te plannen en te reageren dan voorheen.

Merk op dat in dit proces de aandacht is gericht op de uitzonderingen in het netwerk en zich niet bezighoudt met andere apparaten. Er wordt aangenomen dat zolang apparaten onder de drempelwaarden liggen, ze prima zijn.

Als u deze stappen vanaf het begin hebt bedacht, bent u goed voorbereid op het gezond houden van het netwerk. Het uitvoeren van dit soort planning is ook zeer nuttig voor de budgetplanning. Als u weet wat uw top vijf go-routers, uw middelste set-routers en uw onderste klaar routers zijn, kunt u eenvoudig plannen hoeveel budget u nodig heeft voor upgrades op basis van wat voor soort routers ze zijn en wat uw opties voor een actieplan zijn. Dezelfde strategie kan worden gebruikt voor WAN-verbindingen (Wide Area Network) of andere MIB OID.

Stap 5: Identificeer directe problemen

Dit is een van de gemakkelijkste onderdelen van het basisproces. Zodra u hebt vastgesteld welke apparaten de go-drempel overschrijden, moet u een actieplan maken om die apparaten weer onder de drempel te krijgen.

U kunt een kwestie openen bij het Technical Assistance Center (TAC) van Cisco of contact opnemen met uw systeemingenieur voor beschikbare opties. Je moet er niet van uitgaan dat het terugkrijgen van dingen onder de drempel je geld kost. Sommige CPU-problemen kunnen worden opgelost door de configuratie te wijzigen om ervoor te zorgen dat alle processen op de meest efficiënte manier worden uitgevoerd. Sommige Access Control Lists (ACL's) kunnen bijvoorbeeld een router-CPU zeer hoog laten werken vanwege het pad dat de pakketten door de router nemen. In sommige gevallen kunt u NetFlow-switching implementeren om het pakketschakelpad te wijzigen en de impact van de ACL op de CPU te verminderen. Wat de problemen ook zijn, het is noodzakelijk om alle routers in deze stap weer onder de drempel te krijgen, zodat u de drempels later kunt implementeren zonder het risico te lopen dat de NMS-stations worden overspoeld met te veel drempelalarmen.

Stap 6: Controle testdrempel

Deze stap omvat het testen van de drempels in het laboratorium met behulp van de tools die u in het productienetwerk zult gebruiken. Er zijn twee gemeenschappelijke benaderingen voor het toezicht op de drempels. U moet beslissen welke methode het beste is voor uw netwerk.

• Methode voor pollen en vergelijken met behulp van een SNMP-platform of een ander SNMP-monitoringprogramma

  Deze methode gebruikt meer netwerkbandbreedte voor het pollen van verkeer en neemt verwerkingscycli op uw SNMP-platform in beslag.

• Gebruik Remote Monitoring (RMON) Alarm- en gebeurtenisconfiguraties in de routers, zodat ze alleen een waarschuwing verzenden wanneer een drempelwaarde wordt overschreden

  Deze methode vermindert het gebruik van netwerkbandbreedte, maar verhoogt ook het geheugen- en CPU-gebruik op de routers.

Een drempelwaarde implementeren met SNMP

Als u de SNMP-methode wilt instellen met HP OpenView NNM, selecteert u Opties > Gegevensverzameling en drempelwaarden zoals u hebt gedaan bij het instellen van de eerste polling. Deze keer selecteert u echter Winkel, Drempelwaarden controleren in plaats van Opslaan, Geen drempelwaarden in het menu Verzamelingen. Nadat u de drempel hebt ingesteld, kunt u het CPU-gebruik op de router verhogen door deze meerdere pings en / of meerdere SNMP-wandelingen te verzenden. Mogelijk moet u de drempelwaarde verlagen als u de CPU niet hoog genoeg kunt forceren om de drempelwaarde te overschrijden. U moet er in ieder geval voor zorgen dat het drempelmechanisme werkt.

Een van de beperkingen van het gebruik van deze methode is dat u niet meerdere drempels tegelijk kunt implementeren. Je hebt drie SNMP-platforms nodig om drie verschillende drempels tegelijk in te stellen. Tools zoals Concord Network Health en Trinagy TREND staan meerdere drempelwaarden toe voor dezelfde OID-instantie.

Als uw systeem slechts één drempel tegelijk aankan, kunt u de strategie Klaar, instellen, gaan op seriële wijze overwegen. Dat wil zeggen, wanneer de drempel klaar voortdurend wordt bereikt, begint u uw onderzoek en verhoogt u de drempel naar het ingestelde niveau voor dat apparaat. Wanneer het ingestelde niveau voortdurend wordt bereikt, begint u uw actieplan te formuleren en de drempel te verhogen tot het go-niveau voor dat apparaat. Wanneer de go-drempel vervolgens voortdurend wordt bereikt, voert u uw actieplan uit. Dit zou net zo goed moeten werken als de methode met drie gelijktijdige drempelwaarden. Het kost alleen wat meer tijd om de drempelinstellingen van het SNMP-platform te wijzigen.

Een drempelwaarde implementeren met RMON-alarm en -gebeurtenis

Met behulp van RMON-alarm- en gebeurtenisconfiguraties kunt u de router zelf voor meerdere drempels laten bewaken. Wanneer de router een overdrempelvoorwaarde detecteert, verzendt deze een SNMP-trap naar het SNMP-platform. U moet een SNMP-trapontvanger hebben ingesteld in uw routerconfiguratie om de trap door te sturen. Er is een verband tussen een alarm en een gebeurtenis. Het alarm controleert de OID voor de opgegeven drempel. Als de drempelwaarde is bereikt, vuurt het alarmproces het gebeurtenisproces af dat een SNMP-overvulbericht kan verzenden, een RMON-logboekvermelding kan maken of beide. Zie RMON Alarm and Event Configuration Commands voor meer informatie over deze opdracht.

De volgende routerconfiguratieopdrachten hebben de routermonitor cpmCPUTotal5min elke 300 seconden. Het vuurt gebeurtenis 1 af als de CPU meer dan 60 procent is en vuurt gebeurtenis 2 af wanneer de CPU terugvalt naar 40 procent. In beide gevallen wordt een SNMP-overvulbericht verzonden naar het NMS-station met de community-privétekenreeks.

Als u de methode Ready, Set, Go wilt gebruiken, gebruikt u alle volgende configuratieinstructies.

rmon event 1 trap private description "cpu hit60%" owner jharp
rmon event 2 trap private description "cpu recovered" owner jharp
rmon alarm 10 cpmCPUTotalTable.1.5.1 300 absolute rising 60 1 falling 40 2 owner jharp


rmon event 3 trap private description "cpu hit50%" owner jharp
rmon event 4 trap private description "cpu recovered" owner jharp
rmon alarm 20 cpmCPUTotalTable.1.5.1 300 absolute rising 50 3 falling 40 4 owner jharp

rmon event 5 trap private description "cpu hit 45%" owner jharp
rmon event 6 trap private description "cpu recovered" owner jharp
rmon alarm 30 cpmCPUTotalTable.1.5.1 300 absolute rising 45 5 falling 40 6 owner jharp

In het volgende voorbeeld wordt de uitvoer van de opdracht show rmon alarm weergegeven die door de bovenstaande instructies is geconfigureerd.

zack#sh rmon alarm
Alarm 10 is active, owned by jharp
 Monitors cpmCPUTotalTable.1.5.1 every 300 second(s)
 Taking absolute samples, last value was 0
 Rising threshold is 60, assigned to event 
1
 Falling threshold is 40, assigned to event 
2
 On startup enable rising or falling alarm
Alarm 20 is active, owned by jharp
 Monitors cpmCPUTotalTable.1.5.1 every 300 second(s)
 Taking absolute samples, last value was 0
 Rising threshold is 50, assigned to event 
3
 Falling threshold is 40, assigned to event 
4
 On startup enable rising or falling alarm
Alarm 30 is active, owned by jharp
 Monitors cpmCPUTotalTable.1.5.1 every 300 second(s)
 Taking absolute samples, last value was 0
 Rising threshold is 45, assigned to event 
5
 Falling threshold is 40, assigned to event 
6
 On startup enable rising or falling alarm

Het volgende voorbeeld toont de uitvoer van de opdracht show rmon event.

zack#sh rmon event
Event 1 is active, owned by jharp
 Description is cpu hit60%
 Event firing causes trap to community 
private, last fired 00:00:00
Event 2 is active, owned by jharp
 Description is cpu recovered
 Event firing causes trap to community 
private, last fired 02:40:29
Event 3 is active, owned by jharp
 Description is cpu hit50%
 Event firing causes trap to community 
private, last fired 00:00:00
Event 4 is active, owned by jharp
 Description is cpu recovered
 Event firing causes trap to community 
private, last fired 00:00:00
Event 5 is active, owned by jharp
 Description is cpu hit 45%
 Event firing causes trap to community 
private, last fired 00:00:00
Event 6 is active, owned by jharp
 Description is cpu recovered
 Event firing causes trap to community 
private, last fired 02:45:47

Misschien wilt u beide methoden proberen om te zien welke methode het beste bij uw omgeving past. Je kunt zelfs merken dat een combinatie van methoden goed werkt. In ieder geval moeten testen in een laboratoriumomgeving worden uitgevoerd om ervoor te zorgen dat alles correct werkt. Na het testen in het laboratorium kunt u met een beperkte implementatie op een kleine groep routers het proces testen voor het verzenden van waarschuwingen naar uw Operations Center.

In dit geval moet u de drempels verlagen om het proces te testen: proberen de CPU op een productierouter kunstmatig te verhogen, wordt niet aanbevolen. U moet er ook voor zorgen dat wanneer de waarschuwingen de NMS-stations binnenkomen in het Operations Center, er een escalatiebeleid is om ervoor te zorgen dat u op de hoogte bent wanneer apparaten de drempelwaarden overschrijden. Deze configuraties zijn getest in een laboratorium met Cisco IOS versie 12.1(7). Als u problemen ondervindt, moet u contact opnemen met Cisco Engineering of Systems Engineers om te zien of u een bug in uw IOS-versie hebt.

Stap 7: Drempelwaardebewaking implementeren met SNMP of RMON

Zodra u de drempelbewaking in het laboratorium grondig hebt getest en in een beperkte implementatie, bent u klaar om drempelwaarden in het hele kernnetwerk te implementeren. U kunt dit basislijnproces nu systematisch doorlopen voor andere belangrijke MIB-variabelen op uw netwerk, zoals buffers, vrij geheugen, cyclische redundantiecontrole (CRC) -fouten, AMT-celverlies, enzovoort.

Als u RMON-alarm- en gebeurtenisconfiguraties gebruikt, kunt u nu stoppen met pollen vanaf uw NMS-station. Dit vermindert de belasting op uw NMS-server en vermindert de hoeveelheid pollinggegevens op het netwerk. Door dit proces systematisch te doorlopen voor belangrijke netwerkgezondheidsindicatoren, kunt u gemakkelijk op het punt komen dat de netwerkapparatuur zichzelf bewaakt met behulp van RMON Alarm en Event.

Extra MIB's

Nadat u dit proces hebt geleerd, wilt u mogelijk andere MIB's onderzoeken om de basislijn te bepalen en te controleren. De volgende subsecties geven een korte lijst met enkele OID's en beschrijvingen die u mogelijk nuttig vindt.

Router-MIB's

Geheugenkenmerken zijn zeer nuttig bij het bepalen van de gezondheid van een router. Een gezonde router moet bijna altijd beschikbare bufferruimte hebben om mee te werken. Als de router geen bufferruimte meer heeft, zal de CPU harder moeten werken om nieuwe buffers te maken en om buffers te vinden voor inkomende en uitgaande pakketten. Een diepgaande discussie over buffers valt buiten het bestek van dit document. Als algemene regel geldt echter dat een gezonde router zeer weinig of geen buffer mist en geen bufferfouten of een toestand van nul vrij geheugen mag hebben.

object	Beschrijving	OID
CiscoMemoryPoolFree	Het aantal bytes uit de geheugenpool dat momenteel niet wordt gebruikt op het beheerde apparaat	1.3.6.1.4.1.9.9.48.1.1.1.6
CiscoMemoryPoolBiggestFree	Het grootste aantal aaneengesloten bytes uit de geheugenpool dat momenteel niet wordt gebruikt	1.3.6.1.4.1.9.9.48.1.1.1.7
bufferElMiss	Het aantal ontbrekende bufferelementen	1.3.6.1.4.1.9.2.1.12
bufferstoring	Het aantal mislukte buffertoewijzingen	1.3.6.1.4.1.9.2.1.46
bufferNoMem	Het aantal bufferfouten als gevolg van het ontbreken van vrij geheugen	1.3.6.1.4.1.9.2.1.47

Catalyst Switch MIBs

object	Beschrijving	OID
cpmCPUTotal5min	Totale CPU-bezettingspercentage in de laatste vijf minuten. Dit object waardeert het object avgBusy5 van het OLD-CISCO-SYSTEM-MIB	1.3.6.1.4.1.9.9.109.1.1.1.5
cpmCPUTotal5sec	Totale CPU-bezettingspercentage in de laatste periode van vijf seconden. Dit object veroudert het object busyPer van het OLD-CISCO-SYSTEM-MIB	1.3.6.1.4.1.9.9.109.1.1.1.3
sysTraffic	Het percentage bandbreedtegebruik voor het vorige pollinginterval	1.3.6.1.4.1.9.5.1.1.8
sysTrafficPeak	De waarde van de piekverkeersmeter sinds de laatste keer dat de poorttellers zijn gewist of het systeem is gestart	1.3.6.1.4.1.9.5.1.1.19
sysTrafficPeaktime	De tijd (in honderdsten van een seconde) sinds de piekwaarde van de verkeersmeter optrad	1.3.6.1.4.1.9.5.1.1.20
portTopNUutilisatie	Gebruik van de haven in het systeem	1.3.6.1.4.1.9.5.1.20.2.1.4
portTopNBufferOverFlow	Het aantal bufferoverlopen van de haven in het systeem	1.3.6.1.4.1.9.5.1.20.2.1.10

Serial Link MIB's

object	Beschrijving	OID
lockIfInputQueueDrops	Het aantal pakketten is gedaald omdat de invoerwachtrij vol was	1.3.6.1.4.1.9.2.2.1.1.26
lockIfOutputQueueDrops	Het aantal pakketten is gedaald omdat de uitvoerwachtrij vol was	1.3.6.1.4.1.9.2.2.1.1.27
locIfInCRC	Het aantal invoerpakketten met cyclische redundantie-controlesomfouten	1.3.6.1.4.1.9.2.2.1.1.12

RMON-alarm- en gebeurtenisconfiguratieopdrachten

Alarmen

RMON-alarmen kunnen worden geconfigureerd met de volgende syntaxis:

rmon alarm number variable interval {delta | absolute} rising-threshold value
           [event-number] falling-threshold value [event-number]
           [owner string]

element	Beschrijving
aantal	Het alarmnummer, dat identiek is aan de alarmIndex in de alarmTable in de RMON MIB.
veranderlijk	Het MIB object om te monitoren, wat zich vertaalt in de alarmVariable die wordt gebruikt in de alarmTable van de RMON MIB.
interval	De tijd, in seconden, bewaakt het alarm de MIB-variabele, die identiek is aan het alarmInterval dat wordt gebruikt in de alarmTable van de RMON MIB.
delta	Test de verandering tussen MIB-variabelen, die van invloed is op het alarmSampleType in de alarmTable van de RMON MIB.
absoluut	Test elke MIB-variabele rechtstreeks, wat van invloed is op het alarmSampleType in de alarmTable van de RMON MIB.
stijgende drempelwaarde	De waarde waarbij het alarm wordt geactiveerd.
gebeurtenisnummer	(Optioneel) Het gebeurtenisnummer dat moet worden geactiveerd wanneer de stijgende of dalende drempel de limiet overschrijdt. Deze waarde is identiek aan de alarmRisingEventIndex of de alarmFallingEventIndex in de alarmTable van de RMON MIB.
dalende drempelwaarde	De waarde waarbij het alarm wordt gereset.
eigenaarsstring	(Optioneel) Specificeert een eigenaar voor het alarm, die identiek is aan de alarmOwner in de alarmTable van de RMON MIB.

Gebeurtenissen

RMON-gebeurtenissen kunnen worden geconfigureerd met de volgende syntaxis:

rmon event number [log] [trap community] [description string] 
           [owner string]

element	Beschrijving
aantal	Toegewezen gebeurtenisnummer, dat identiek is aan de eventIndex in de eventTable in de RMON MIB.
logboek	(Optioneel) Genereert een RMON-logboekvermelding wanneer de gebeurtenis wordt geactiveerd en stelt het eventType in het RMON-MIB in op log of log-and-trap.
trap-gemeenschap	(Optioneel) SNMP-communitytekenreeks die voor deze val wordt gebruikt. Configureert de instelling van eventType in de RMON MIB voor deze rij als snmp-trap of log-and-trap. Deze waarde is identiek aan de eventCommunityValue in de eventTable in de RMON MIB.
beschrijvingsreeks	(Optioneel) Geeft een beschrijving van de gebeurtenis op die identiek is aan de beschrijving van de gebeurtenis in de gebeurtenistabel van de RMON MIB.
eigenaarsstring	(Optioneel) Eigenaar van dit evenement, dat identiek is aan de eventOwner in de eventTable van de RMON MIB.

Implementatie van RMON-alarm en -gebeurtenissen

Lees voor gedetailleerde informatie over de implementatie van RMON-alarm- en -gebeurtenissen het gedeelte RMON Alarm and Event Implementation van de whitepaper Network Management Systems Best Practices.

Gerelateerde informatie

• Technische ondersteuning en documentatie - Cisco Systems