[netwerkswitch] ping timeouts en ICMP loss

[EverLast2002]

Beste,

ik heb een vreemd fenomeen (probleem is het eigenlijk niet omdat de switch niet uitvalt) :
via Zabbix monitor ik mijn thuisnetwerk, werkt prima.
Nu ben ik erachtergekomen (door Zabbix) dat mijn core switch per uur een paar timeouts heeft,
en een paar keer een ICMP loss heeft van >500ms.

Ik heb in de switch de logs bekeken en oa de cpu en memory grafieken een tijdje aan gehad.
De logs laten geen errors zien, geen collisions, alles foutloos.
Het cpu verbruik ligt rond 15%, het memory verbruik rond 36%

Ik noem het een core switch, omdat er nog 2 andere switches op aangesloten zitten,
en ik heb de binnenkomende internetlijn erop aangesloten.
mbv VLANs heb ik dat verder richting router verdeeld.
Het is een TP-Link 8 poort managed switch.

Mijn vraag is: waar komen die ping timeouts en hoge ICMP loss vandaan??

[jvanhambelgium]

De "ping" die jij doet naar de switch en wat timeouts/latency geeft wil niet zeggen dat het verkeer dat ERDOOR gaat daar ook last van heeft.
Het CPU'tje van zo'n switch moet wat zaken afhandelen waaronder ook je ICMP-request en eventueel SNMP-pollings etc. (en nog ander dingen ook natuurlijk)
Je zou eens een host moeten pingen die op die switch zit, of zelfs een host die op een andere switch hangt (en je ping dus 2 switches moet passeren)

Al bij al moeilijk te zeggen "waarom" die TP-LINK af en toe wat trager is in het beantwoorden van je ICMP Echo Request of eentje laat vallen.

[EverLast2002]

jvanhambelgium schreef op donderdag 10 augustus 2023 @ 22:50:
De "ping" die jij doet naar de switch en wat timeouts/latency geeft wil niet zeggen dat het verkeer dat ERDOOR gaat daar ook last van heeft.

Dank voor je toelichting.
Je eerste opmerking had ik ook al geconstateerd.
En wat ik al erbij schreef, de switch doet prima zijn werk zonder uitval.
De Zabbix server (en ook mijn werk pc) zien dus een ping timeout.
Ik dacht in eerste instantie dat het te maken had doordat ik mijn glasmodem rechtstreeks in die core switch heb aangesloten. Die kabel had ik voorheen in mijn router ingeplugd zitten.

Ik ga jouw test ook eens doen, dus apparatuur achter de core switch monitoren.

[Kabouterplop01]

Zie je een trend in die loss?
-Is het op een bepaald tijdstip?

Je zegt dat je het modem rechtstreeks op je coreswitch hebt aangesloten. Heb je dan je publieke ip adres op je switch? Of bridge je een VLAN naar een host waar je je pub ip op krijgt?

[EverLast2002]

Kabouterplop01 schreef op zaterdag 12 augustus 2023 @ 08:50:
Zie je een trend in die loss?
-Is het op een bepaald tijdstip?

Je zegt dat je het modem rechtstreeks op je coreswitch hebt aangesloten. Heb je dan je publieke ip adres op je switch? Of bridge je een VLAN naar een host waar je je pub ip op krijgt?

Er zit geen patroon in, dus willekeurig. Soms paar keer in 10 minuten tijd, soms na een uur.

Ik heb met een vlan en een pvid het publieke adres naar de switch lopen op een poort en van daaruit naar mijn router.
Mijn eerste ingeving was dat de switch de vele internetpakketjes niet aankon. Maar wat ik al zei, cpu en memory verbruik is ruim beneden zijn maximale kunnen.

[EverLast2002]

De 8 poort TP-Link die nu als core switch dienst doet is vrij robuust.
Ik heb nog een 5 poort TP-Link op de plank liggen, waarvan bekend is (bug?) dat je vanuit een willekeurig VLAN naar een ander VLAN kan communiceren (bijv met ping.exe).
Die switch gebruik ik dus niet meer met dat in het achterhoofd...

[Kabouterplop01]

Ik denk dat je daar deels gelijk hebt, over het algemeen is ICMP verkeer niet hoog geprioriteerd (ook al gebruik je wellicht geen QoS) Het kan dus zijn dat er inderdaad behoorlijk wat frames door je switch vloeien. Als je geen onderbreking in je data hebt maar je verliest wat ICMP packets is dat denk ik omdat het andere verkeer meer prio heeft. Is wel een aanname.

Heb je al eens getracht dat vlan door te trekken tot op je router zodat je switch de bridge vormt tussen je modem en router en je je pub IP krijgt op de router?(Tenzij je goed weet wat je doet en je op de TP-Link hetzelfde kunt)

[EverLast2002]

Kabouterplop01 schreef op zaterdag 12 augustus 2023 @ 17:34:
Ik denk dat je daar deels gelijk hebt, over het algemeen is ICMP verkeer niet hoog geprioriteerd (ook al gebruik je wellicht geen QoS) Het kan dus zijn dat er inderdaad behoorlijk wat frames door je switch vloeien. Als je geen onderbreking in je data hebt maar je verliest wat ICMP packets is dat denk ik omdat het andere verkeer meer prio heeft. Is wel een aanname.

Heb je al eens getracht dat vlan door te trekken tot op je router zodat je switch de bridge vormt tussen je modem en router en je je pub IP krijgt op de router?(Tenzij je goed weet wat je doet en je op de TP-Link hetzelfde kunt)

Voorheen had ik de utp kabel vanuit het glasmodem direct in de router (wan) zitten.
Daar heb ik nooit errors of uitval op gehad.
Sinds de utp kabel vanuit het glasmodem in de switchpoort zit, zie ik die timeouts.

Oh, en ik praat steeds over ICMP loss, maar het is ICMP response time.
Die schiet regelmatig omhoog naar meer dan 500ms.
Mijn andere switches zitten rond de 5ms, om een vergelijking te geven.

[Vorkie]

Dat CPUtje is gewoon druk, er komt echt een hoop zooi op WAN voorbij. Van dhcp, port scanning etc etc.

ICMP / Ping hebben de allerlaagste prio en krijg je dus zulke lag spikes.

[Kabouterplop01]

Vorkie schreef op zaterdag 12 augustus 2023 @ 18:18:
Dat CPUtje is gewoon druk, er komt echt een hoop zooi op WAN voorbij. Van dhcp, port scanning etc etc.

ICMP / Ping hebben de allerlaagste prio en krijg je dus zulke lag spikes.

Yep, alleen op ICMP

[EverLast2002]

Ik heb hier nog een MikroTik RB750Gr3 liggen, zou die beter presteren dan een TP-Link?
dit is geen echte switch maar een router, met een zwakkere cpu en daardoor minder geschikt voor VLANs.
Een RB260 zou wel geschikt zijn.

[ Voor 45% gewijzigd door EverLast2002 op 13-08-2023 16:01 ]