Syslog Oversikt Og Konfigurasjon

har du noen gang blitt frekt avbrutt av en ruter eller bryteren din? Akkurat slik skriver du bort, du tenker på din egen virksomhet, og plutselig, poof, er det en melding, og så en annen. Du fortsetter å skrive, en annen, hva er de? Disse er kjent som syslog-meldinger, og de er meldinger som våre rutere og våre brytere genererer for å varsle oss om noe som har skjedd. Og det kan være et bredt spekter av ting som har skjedd fra alt relatert til en nødsituasjon til noe som bare er et enkelt varsel. Nå som syslog melding som vi ser, det ser ut til oss hvordan? Vel, hvis vi er trøstet i, det vises til oss på vår konsoll linje. Hvis Vi Har Telnet inn eller SSHed inn, så vises det på våre terminallinjer. Men vent litt, jeg har et spørsmål til deg. Hvis Jeg Telnet ELLER SSH til en enhet, vil jeg se syslog meldinger som standard?

Nei, Og Det er ganske forvirrende, og du vil ikke engang se debugs, ok, du vil ikke engang se feilsøkingsmeldinger. Du slår på en feilsøking, du vet at det skal spytte ut noen utdata, nei. Og det er fordi vi må bruke terminal monitor-kommandoen for å aktivere det. Og grunnen til at de ikke ville oversvømme vty-økter med veldig chatty debugs og låsing, og i utgangspunktet støter noen av en brukbar økt fordi det er så mye informasjon som går på den måten. I utgangspunktet kan du konfigurere syslog meldinger som skal videresendes til ulike destinasjoner:

• logging buffer
• konsolllinje
• terminallinje
• syslog server

så som standard går syslog-meldinger til konsolllinjen, men ikke til terminallinjene. Vi kan også sende disse syslog meldinger til vår buffer. Hva er bufferen? Minne, folkens, minne. Men disse tre alternativene som vi ser oppført først, buffer, konsoll linje, terminal linje… hva kommer til å skje hvis vi for eksempel mister strøm eller vi logger av enheten og kommer tilbake? Er disse meldingene fortsatt kommer til å være der? De er borte, de er borte for godt. Så det hjelper oss ikke etter det faktum. Hvis du har trøstet deg, ser du det, flott, det kommer til å hjelpe oss på det tidspunktet, men hvis det blir generert når vi ikke er logget inn, kommer vi ikke til å se informasjonen vi trenger. Så det nederste alternativet-syslog-serveren, det er et veldig godt alternativ. La oss ta disse syslog meldinger og la oss sende dem til en syslog server. Og så når de er på den syslog-serveren, kan vi filtrere dem, vi kan bla gjennom dem, vi kan se om det er noe unormalt.

Syslog message format

jeg vil at dere folk tenker, hvordan kan jeg trekke ut noen brukbar informasjon som jeg kan søke på mitt eget miljø i denne modulen som vi er i akkurat nå? Nå Er Simple Network Management Protocol, ELLER SNMP, tvilsom riktig? Du har kanskje ikke budsjettet, programvaren og utholdenheten til Å gjøre EN SNMP-utrulling. Men syslog er helt annerledes, det er så darned lett å konfigurere og så kraftig samtidig. Og det er gratis syslog servere som er der ute. Så faktisk er det egentlig ikke en god unnskyldning for ikke å gjøre syslog-ledelsen, og vi er store fans av Det I Cisco, det er vi virkelig. Du snakker med noen som har gjort Mange Cisco-ting i karrieren, og de er fans av det.

Hva er den mest effektive loggingsmekanismen når det gjelder overhead på chassis? Jeg vil at du skal kunne svare på dette, kanskje ikke for ditt flertallsnivå, men hvis du noen gang snakker om syslog i et eksamensmiljø, er det det ene spørsmålet som er slags felles sted. Så hva synes dere folk? Svaret er å logge på bufferen, ok. Logging til bufferen er mye mer effektiv enn noen annen modalitet. Hvorfor? FORDI DET ER RAM og RAM er rask. Så bare en liten nugget å ta bort fra dette, bare i tilfelle.

det er noe som kalles innretningen av syslog meldinger, og når du hører dette ordet anlegget, er det vanskelig å, faktisk, vet hva det betyr bare ved en analyse av ordet, som er uheldig. Facility betyr egentlig at formateringen er gjort for all denne informasjonen. Tenk, vi fikk mye informasjon, ikke sant. Hvordan formaterer jeg det? Og så, i noen tilfeller vil du reformatere dette. Og det spesifikke tilfellet jeg har i tankene er CiscoWorks. Hvis Vi er grensesnitt Med CiscoWorks, vi ønsker å endre anlegget for å logge meldinger til local 7.

Generelt format for syslog-meldinger generert av syslog-prosessen på Cisco IOS-programvaren:

beskrivelse

Eksempel på syslog-melding, som informerer administratoren Om At FastEthernet 0/24-grensesnittet kom opp:

*Feb 22 11:29:55:423: %LINEPROTO-5-UPDOWN: Linjeprotokoll På Grensesnitt FastEthernet0/24, endret tilstand til opp

Så CiscoWorks er ikke Bare En Nettverksadministrasjonsprogramvare, eller NMS, fra enkel nettverksadministrasjons perspektiv, men vi kunne også sende syslog-meldinger til ciscoworks ‘ boks. Og det er faktisk hvor mange AV DISSE nms-enhetene fungerer, de trenger informasjon fra mange forskjellige kilder for å få et fullstendig bilde av hva som skjer?

så la oss si at jeg fikk anlegget mitt satt opp som normalt, og vanligvis berører vi ikke dette hvis vi bare sender til en syslog-melding eller en syslog-server forresten. Men hvis Det Er CiscoWorks, kan vi si lokal 7 for anlegget. Men jeg ser mange ting som skjer her når det gjelder tall,som et alvorlighetsgrad. Hva er greia med alvorlighetsgraden av syslog-meldingene?

disse alvorlighetsnivåene skal indikere hvor viktig denne syslog-meldingen er for oss på dette bestemte tidspunktet. For eksempel, se på nivå 6, informativ; det gir oss litt informasjon om noe som har skjedd. Vårt eksempel viser et nivå 5, nivå 5 er et varsel. Melding om hva? Vel vårt grensesnitt endret tilstand til opp. Men jeg vil at du skal se mønsteret her. Vi går fra 0 til 7, 0 er det verste, 7 er feilsøking. Hvordan slår vi på et nivå 7 syslog melding? Vi må aktivere en feilsøkingskommando som er hvordan de skal vises. Så som standard kan du ikke se noen nivå 7s.

Men alt annet fra 0 til 6, det er rettferdig spill rett utenfor flaggermuset. Det vil være veldig flott å vite om vi har en nødsituasjon og ruteren vår er ustabil. Men legg merke til hvordan vi har et navn knyttet til hvert av disse nivåene også. Og i begynnelsen er det vanskelig å huske disse, det er vanskelig å huske at 2 er kritisk, eller 4 er advarsler. Men over tid, jo mer du leker med syslog, jo mer du ser på et bord, jo mer vil du huske at vi har disse nivåene knyttet til disse navnene og hva de betyr.

Syslog configuration

Svært få protokoller og teknologier er så enkle å konfigurere,og jeg elsker grei. Jeg mener, jeg liker også kompleks som du vet, men denne er flott, ok. Så du går inn i den globale konfigurasjonsmodus og forresten, vi er ikke syslog servere. Jeg vil at du skal forstå det, vi er ikke en syslog-server, ruteren, bryteren, nei det er en syslog-klient! Vi pumper til serveren. Så det ville bety at vi måtte ha et program som kjører på en type enhet som kan samle disse syslog-meldingene. Ja, og det er noen gratis syslog-programvare som er der ute, det er også noen dyre ting som gjør det bedre å korrelere dataene som er inne i det og rapportere. MEN DU vil HA IP-tilkobling mellom klienten og serveren, og vi er klienten og vi peker på serveren MED IP-adressen.

R1 (config)#logging 10.1.10.100
R1 (config)#logging trap informative

nå er det faktisk den eneste kommandoen som ville være nødvendig for å begynne å skyte disse syslog-meldingene over til serveren. Men husk alvorlighetsgraden nivåer? Vel, vi vil ikke logge alt, og det er den generelle tommelfingerregelen. Hva var rekkevidden? 0 til 7, 7 er feilsøking, vi utelukker vanligvis det og ofte utelukker vi også nivå 6. Jeg har det bra med 6 og under, men når du sier logging trap kommandoen du sier, hvor ille eller hvor ubetydelig vil du gå? Hvor inkonsekvent vil du gå?

og de generelle tankene er logg 5 til 0 eller 6 til 0. Men unntatt 7, med mindre du har et bestemt problem som du har å gjøre med som krever en langvarig feilsøking, noe som er veldig situasjonelt fordi det kommer til å påvirke chassiset ditt på en negativ måte. Og vi gjør vårt beste for å prøve å unngå feilsøking i lengre perioder. Men her er de gode nyhetene, du vil konfigurere syslog, bare en kommando, den øverste som er alt som trengs.