Hop 1) is een stabiele hop van < 3ms maar hop 2) heeft random ping tijden die varieert van <3ms tot 128ms.
Is dit normaal?
Tracing route to google.com [216.58.208.110]
1 <1 ms <1 ms <1 ms SERVER [10.1.128.1]
2 3 ms 3 ms 5 ms lo0-2.bras0.fi001.nl.freedomnet.nl [185.93.175.230]
3 95 ms 5 ms 128 ms et-0-0-2-1001.core0.fi001.freedomnet.nl [185.93.175.223]
4 3 ms 3 ms 3 ms 74.125.48.190
5 4 ms 4 ms 3 ms 142.251.70.73
6 4 ms 4 ms 4 ms 172.253.66.187
7 3 ms 3 ms 3 ms ams17s08-in-f14.1e100.net [216.58.208.110]
Reply from 185.93.175.223: bytes=32 time=3ms TTL=62
Reply from 185.93.175.223: bytes=32 time=3ms TTL=62
Reply from 185.93.175.223: bytes=32 time=26ms TTL=62
Reply from 185.93.175.223: bytes=32 time=4ms TTL=62
Reply from 185.93.175.223: bytes=32 time=3ms TTL=62
Reply from 185.93.175.223: bytes=32 time=3ms TTL=62
Reply from 185.93.175.223: bytes=32 time=83ms TTL=62
Reply from 185.93.175.223: bytes=32 time=3ms TTL=62
Reply from 185.93.175.223: bytes=32 time=3ms TTL=62
Reply from 185.93.175.223: bytes=32 time=97ms TTL=62
Reply from 185.93.175.223: bytes=32 time=3ms TTL=62
Ja, veelal wel maar het is niet altijd zo dat de route hetzelfde loopt. Je kan een situatie hebben waarin je wel over IPv4 peert met een partij maar niet over IPv6, of andersom. Voor transits hetzelfde verhaal. In de praktijk kom ik regelmatig tegen dat routes over IPv6 en IPv4 anders lopen, de ene keer in het voordeel van de een en de andere keer in het voordeel van de ander. Nadeel is wel dat problemen in het IPv6 verkeer vaak minder snel worden opgemerkt, vermoedelijk staat veel monitoring alleen nog maar op IPv4 bij veel partijen.
Ervaring leert dat dit voor het overgrote deel problemen gerelateerd aan niet-Fritzbox routers betreffen. Eg. Linux of xBSD servers.
Onderstaande link is al eerder hier gedeeld. Dit betreft een Pi4, maar dit verhaal is ook van toepassing op ander hardware waar Linux op draait. In het kort gaat het erom om de interrupts van de netwerkkaarten en de softintrrupts (naar de netwerkkaarten) hard te verdelen over de CPU-cores.
Ik heb net een test afgerond met een fritz 4060 en daar was het probleem niet aanwezig.
Moet toch, met wat schaamrood op de kaken, het probleem bij pppoe plugin in mijn Debian server zoeken. Had niet verwacht dat dat, met de specs van die server, een bottleneck zou zijn maar kennelijk moet er wat getweaked worden.
Bedankt voor de link, zal kijken of ik daar verder mee kom.
Interrupt-processing en netwerken op hoge frame rates gaan slecht samen.
Vandaar projecten als DPDK [1] en XDP (eXpress Data Path) [2]. Op die laatste zou toch een moderne PPP-implementatie te maken moeten dacht ik tijdens het schrijven van dit antwoord, Een snelle blik op github leert dat iemand daar al werk in steekt [3]. Maar dat werk lijkt nog niet af.
Ik heb de 2 x intel I210 welke 4 interrupts heeft. Ipv Irq balancing heb ik alle interrupts van 1 NIC aan een dezelfde core toegewezen en alle interrupts van de andere NIC aan een andere core. Dus niet meer scattered over alle cores.
Begrijp (nog) niet waarom dit bij Tweak (geen pppoe) geen issue was en nu wel. Belangrijkste is dat het is getackeld.
Ik heb ook nog even op mijn eigen server gekeken. Een Ryzen met C6 disabled en 6.1 kernel:
IRQ van enp30s0 (LAN) zit volledig op CPU1 en enp33s0 (WAN) volledig op CPU3.
Dit met een default install.
Met balancing is het een drama, en ook mijn bevinding is dat elke nic op z’n eigen CPU het soepelst draait. Waarom dit vroeger bij dhcp geen issue was snap ik nog niet. Ik heb nu irq balancing gedisabled want ik kan volgens mij niet dynamisch doorgeven dat bepaalde IRQ’s in de ban moeten. Ik zou dit kunnen doen door de opstart argumenten in de config aan te passen via script en dan de deamon (her)starten maar weet niet of dat allemaal wel de moeite waard is.
Heb jij balancing aanstaan? en zo ja hoe hou je die gepinde IRQ’s dan op hun plek?
Ik heb een script die uitgevoerd wordt tijdens ifup welke de IRQ’s van de NIC opvraagt en vervolgens op een vaste CPU zetten (6 en 7 in mijn geval).
Grt
Grad
Gebruikte server
Lenovo rs140 E3-1276
Debian 11 - kernel 5.10
