I detta avsnitt går vi igenom hur nätverksenheter kommunicerar viktiga händelser och tillstånd genom ett meddelande baserat system med hjälp av protokollet Syslog. Vi tittar på hur det fungerar och hur det används för att övervaka och felsöka nätverk.

Efter genomgången kommer du att ha en grundläggande förståelse för hur Syslog bidrar till en mer kontrollerad, pålitlig och säker nätverksmiljö.

Inledning

Ungefär som en ”Check Engine”-lampa på bilens instrumentpanel kan komponenterna i ett nätverk signalera om något är fel. Syslog-protokollet utvecklades för att möjliggöra att dessa meddelanden kan tas emot, tolkas och åtgärdas. När händelser inträffar i nätverket har enheter som routrar, switchar och brandväggar pålitliga mekanismer för att meddela administratören genom detaljerade meddelande baserat system.

Dessa syslog-meddelanden kan vara både icke-kritiska och mycket betydelsefulla. Nätverksadministratörer har flera alternativ för att lagra, filtrera, analysera och visa dessa meddelanden. Det går även att konfigurera varningar för de meddelanden som kan ha störst påverkan på nätverks infrastrukturen.

Syslog är både en standard och namnet på det protokoll som utvecklades för denna standard. Det togs ursprungligen fram för UNIX-system på 1980-talet och dokumenterades formellt som RFC 3164 av IETF år 2001. Syslog använder UDP port 514 för att skicka event notification meddelande över IP-nätverk till särskilda mottagare som kallas Event message collectors, vilket illustreras i figuren.

Många nätverksenheter har stöd för Syslog, inklusive routrar, switchar, applikations servrar, brandväggar (firewalls) och andra nätverksapplikationer (network appliances). Syslog-protokollet gör det möjligt för dessa enheter att skicka meddelanden över nätverket till en eller flera syslog-servrar.

Det finns flera olika syslog server software packages tillgängliga för både Windows och UNIX. Många av dessa finns som gratisprogram (freeware), vilket gör det enkelt att komma igång med centraliserad logghantering.

Syslog logging service tillhandahåller tre huvudsakliga funktioner:

• Möjlighet att samla in loggnings information för övervakning och felsökning
• Möjlighet att välja vilken typ av loggnings information som ska registreras
• Möjlighet att ange vart de insamlade syslog meddelande ska skickas

Syslog – funktion och användning

På Cisco-nätverksenheter börjar Syslog-protokollet med att skicka system messages och debug output till en lokal logging process som är intern i enheten. Hur denna process hanterar meddelandena beror på enhetens konfiguration.

Till exempel kan syslog-meddelanden skickas över nätverket till en extern syslog server. På så sätt kan administratören granska meddelandena utan att behöva logga in direkt på enheten. Meddelanden som lagras på en extern server kan dessutom sammanställas i rapporter, vilket förenklar analys och felsökning.

Ett annat alternativ är att meddelandena skickas till en intern buffert. Dessa meddelanden kan då endast läsas via enhetens CLI (Command-Line Interface).

Administratören kan även konfigurera vilka typer av meddelanden som ska skickas till vilka destinationer. Exempelvis kan enheten ställas in att skicka alla system meddelanden till en extern syslog server, medan debug-level meddelanden enbart skickas till den interna bufferten och därmed endast är tillgängliga lokalt

Som visas i figuren är vanliga destinationer för syslog meddelanden följande:

• Logging buffer (RAM i en router eller switch)
• Console line
• Terminal line
• Syslog server

Det är möjligt att övervaka systemmeddelanden på distans genom att visa loggarna på en syslog server, eller genom att ansluta till enheten via Telnet, SSH eller via console port.

Syslog-meddelande format

Cisco-enheter genererar syslog-meddelanden som svar på olika nätverkshändelser. Varje syslog-meddelande innehåller två viktiga delar: en severity level (allvarlighetsnivå) och en facility (källa eller funktion inom systemet).

Ju lägre siffra på allvarlighets nivån, desto mer kritiskt är meddelandet. Severity level kan konfigureras för att styra var olika typer av Syslog-meddelanden ska visas – till exempel på enhetens konsol, i en loggbuffer, eller skickas vidare till en Syslog-server.

I tabellen nedan visas en översikt över samtliga Syslog-nivåer, från de mest kritiska till de minst allvarliga.

Syslog Levels – HTML-tabell

Förklaring av nivåerna:

Syslog-meddelanden delas in i olika severity levels, där varje nivå speglar hur allvarlig händelsen är. Här följer en översikt över de vanligaste nivåerna:

• Emergency (Level 0) – Warning (Level 4):
  Dessa nivåer omfattar fel i mjukvara eller hårdvara som påverkar enhetens funktionalitet. Ju allvarligare problemet är, desto lägre blir nivån på meddelandet. Till exempel kan ett kritiskt fel i ett gränssnitt eller ett systemfel rapporteras som en Level 0 eller Level 2-händelse.
• Notification (Level 5):
  Meddelanden på denna nivå informerar om normala men viktiga händelser, såsom när ett interface går upp eller ner, eller vid en systemomstart.
• Informational (Level 6):
  Denna nivå innehåller rena informationsmeddelanden som inte påverkar enhetens funktion. Exempelvis kan ett meddelande som visas vid uppstart vara:
  %LICENSE-6-EULA_ACCEPT_ALL: The Right to Use End User License Agreement is accepted.
• Debugging (Level 7):
  Här visas resultat från olika debug commands som körs på enheten. Dessa meddelanden används främst vid felsökning.

Syslog Facilities

Förutom severity innehåller varje Syslog-meddelande även information om facility, vilket anger vilken del av systemet som genererat meddelandet. En facility fungerar som en tjänsteidentifierare och används för att kategorisera systemstatusdata i samband med fel och händelser.

Vilka loggning på facility options som finns beror på enhetens modell och programvaruversion. Till exempel:

• Cisco 2960 Series switches med Cisco IOS Release 15.0(2)
• Cisco 1941 routers med Cisco IOS Release 15.2(4)

Dessa två Cisco maskiner stöder 24 olika facility alternativ, indelade i 12 olika facility typer.

Exempel på vanliga facility-koder i Cisco IOS:

• IF – Meddelandet genererades av ett interface.
• IP – Meddelandet genererades av IP.
• OSPF – Meddelandet kommer från OSPF routing protocol.
• SYS – Meddelandet genererades av enhetens operativsystem.
• IPSEC – Meddelandet kommer från IP Security encryption protocol.

Olika nätverksenheter stöder olika mängder facility-alternativ, beroende på modell och mjukvaruversion. Till exempel stöder vissa Cisco-enheter upp till 24 olika facility-alternativ, indelade i 12 olika funktions typer.

Dessa alternativ gör det möjligt att filtrera och organisera syslog-meddelanden utifrån deras ursprung i systemet – något som är mycket värdefullt vid felsökning och granskning.

Som standard har syslog-meddelanden i Cisco IOS Software följande format:

%facility-severity-MNEMONIC: beskrivning

Ett exempel på en typisk utskrift från en Cisco-switch när en EtherChannel-länk ändrar tillstånd till up är:

%LINK-3-UPDOWN: Interface Port-channel1, changed state to up

I detta exempel är facility LINK, severity level är 3, och MNEMONIC (förkortad händelsekod) är UPDOWN.

De vanligaste Syslog-meddelandena gäller när ett interface går upp eller ner (link up/down), samt när enheten avslutar konfigurationsläge (configuration mode). Om ACL loggning är aktiverat, genererar enheten även Syslog-meddelanden när paket matchar ett angivet villkor i en ACL.

Konfigurera tidsstämpel för Syslog

Som standard innehåller loggmeddelanden i Cisco IOS ingen tidsstämpel. Det innebär att när exempelvis interfacet GigabitEthernet 0/0/0 på R1 stängs av med kommandot shutdown, visas ett meddelande på konsolen, men det framgår inte när händelsen inträffade.

För att kunna följa upp händelser i rätt tidsordning – särskilt när loggar skickas till en extern destination som en Syslog-server – bör varje loggmeddelande innehålla datum och tid.

Detta aktiveras med kommandot:

service timestamps log datetime

När denna inställning är aktiverad visas tidsstämpel i varje loggning. I vårt exempel kommer meddelandet som genereras när GigabitEthernet 0/0/0 återaktiveras att inkludera både datum och tid, vilket gör felsökning och analys betydligt mer effektiv.

R1# configure terminal
R1(config)# interface g0/0/0
R1(config-if)# shutdown
%LINK-5-CHANGED: Interface GigabitEthernet0/0/0, changed state to administratively down
%LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0/0, changed state to down
R1(config-if)# exit
R1(config)# service timestamps log datetime
R1(config)# interface g0/0/0
R1(config-if)# no shutdown
*Mar 1 11:52:42: %LINK-3-UPDOWN: Interface GigabitEthernet0/0/0, changed state to down
*Mar 1 11:52:45: %LINK-3-UPDOWN: Interface GigabitEthernet0/0/0, changed state to up
*Mar 1 11:52:46: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0/0,
changed state to up
R1(config-if)#

Observera: När du använder nyckelordet datetime måste klockan på nätverksenheten vara inställd – antingen manuellt eller via NTP (Network Time Protocol), som tidigare diskuterats.