Logs

Een log is alleen iets waard als het er nog is op het moment dat je het nodig hebt. Dat is precies waar RouterOS standaard tekortschiet: alles staat in het geheugen, en het geheugen loopt leeg bij een herstart. Uitgerekend de herstart die je wilde onderzoeken.

Wat er standaard in staat

RouterOS schrijft standaard de topics info, error, warning en critical naar de actie memory: een ringbuffer van een paar honderd regels. Je leest hem met:

/log print

Praktischer is filteren:

/log print where topics~"dhcp"
/log print where message~"login"
/log print follow

Die laatste toont nieuwe regels terwijl ze binnenkomen. Handig bij reproduceren: zet hem aan, trek de kabel eruit, kijk wat er verschijnt.

Met /system logging print zie je welke topics naar welke actie gaan, en met /system logging action print hoe die acties zijn ingesteld.

Waarom het na een herstart weg is

De actie memory is RAM. Bij een herstart, een stroomstoring of een watchdog-reset is de inhoud weg. Dat is geen bug: flash op een router is niet gemaakt voor duizenden kleine schrijfacties per dag.

Gevolg is wel dat je precies mist wat je zoekt. Een router die 's nachts opnieuw opstart laat je 's ochtends een log zien dat begint bij het opstarten. Wil je weten waarom, dan moet het log ergens anders heen. Kijk in elk geval hoelang het apparaat al draait:

/system resource print

Een uptime van veertig minuten terwijl je niets hebt gedaan vertelt je al het halve verhaal.

Wat de tool ervan maakt

Bij Systeem staat het veld Logging met drie keuzes.

Standaard (geheugen)

Het script laat de logging van RouterOS met rust. Prima voor een apparaat dat je toch in de gaten houdt.

Ook naar flash-schijf (info/warning/error)

Het script maakt een actie disk met vijf bestanden van duizend regels en stuurt info,!firewall, warning en error daarheen. Dat is vijfduizend regels historie die een herstart overleeft.

Ook naar een syslog-server

Het script maakt een actie syslog die naar het adres en de poort stuurt die je invult (standaard 514, facility local0) en stuurt info,!firewall, warning, error en critical daarheen.

Het veld Syslog-server accepteert een IP-adres, geen hostnaam. Dat is ook de juiste keuze: een router die net opstart en zijn DNS nog niet heeft, moet nog steeds kunnen loggen.

In alle drie de gevallen zie je in het script een blok /system logging action gevolgd door een paar regels /system logging. Die twee horen bij elkaar: de actie zegt waarheen, de regel zegt wat.

Let op de !firewall in die topics. Firewall-meldingen zijn er zoveel dat ze de rest zouden wegdrukken, dus ze gaan er standaard uit. Wil je ze wel, dan is er de aparte schakelaar Firewall-drops loggen, die het topic firewall naar je syslog-server stuurt, of naar het geheugen als je geen server hebt.

Wat is het waard om te loggen

Het antwoord hangt af van waar het naartoe gaat. Naar een syslog-server mag het ruim: die machine heeft een schijf en een zoekfunctie. Naar de flash van de router mag het niet ruim, want elke regel is een schrijfactie.

Waar je bijna altijd iets aan hebt:

• system, info: herstarts, configuratiewijzigingen, wie wanneer inlogde.
• error en critical: het korte lijstje waar je het eerst naar kijkt.
• interface: poorten die up en down gaan. Zie Kabels en voeding, want een flapperende poort is meestal een kabel.
• dhcp: welk apparaat welk adres kreeg. Zeldzaam nuttig, en dan meteen onmisbaar.

Waar je een schijf mee volschrijft:

• firewall op een router aan internet. Een publiek IP-adres krijgt duizenden scanpogingen per dag. Log dit alleen tijdelijk, en alleen naar een syslog-server.
• debug op welk topic dan ook. Zet het aan voor de duur van het probleem en daarna weer uit.
• wireless of wifi op een druk access point. Elke client die associeert en weer weggaat is een regel.

In Diensten en tools zitten de buren van dit onderwerp: SNMP en NetFlow leveren cijfers in plaats van regels, grafieken tekenen het verloop, en met E-mail versturen kun je jezelf laten waarschuwen. Voor echt in de gaten houden is Netwatch of een monitoringsysteem het juiste gereedschap; een log is voor achteraf.

Een log lezen als er iets stuk is

Werk van achter naar voren. De regel waar je op stuit is meestal een gevolg, niet de oorzaak.

1. Zoek het moment. Klopt de klok? Zonder NTP schrijft RouterOS tijden vanaf 1970 of vanaf de laatste keer dat hij het wist. De tool zet NTP standaard aan; controleer met /system clock print.
2. Kijk of het apparaat opnieuw is opgestart. Staat er een reeks opstartregels, dan begint je onderzoek daar en niet bij wat erna gebeurde.
3. Filter op het onderdeel dat je verdenkt, bijvoorbeeld /log print where topics~"pppoe" voor een verbinding die wegviel.
4. Kijk naar herhaling. Eén keer link down is een kabel die eruit ging. Veertig keer in een uur is een kabel die stuk is.

Staat er niets bruikbaar in, dan is dat ook een antwoord: het apparaat heeft het zelf niet zien gebeuren. Dan zit het probleem ervoor of erachter, niet erin.

Naar buiten met het log

Een syslog-server hoeft geen project te zijn. Een kleine Linux-machine met rsyslog, een NAS die het aanbiedt, of een container op de router zelf doen het al. Wat je wint is dat de logs van al je apparaten op één plek staan, met tijdstempels die je naast elkaar kunt leggen. Een site met een router, twee switches en drie access points is niet te onderzoeken door zes keer /log print te typen.

Stuur je naar een server buiten je netwerk, bedenk dan dat syslog over UDP onversleuteld is en dat er van alles in staat: gebruikersnamen, adressen, welke apparaten er zijn. Houd het binnen je netwerk of stuur het door een tunnel.

Verder lezen: Systeem en tijd voor het veld zelf, Diensten en tools voor SNMP, NetFlow en e-mail, en Als er iets misgaat voor de problemen waar je het log bij nodig hebt.