Hoge ping tijden sinds Ziggo modem in bridge staat

[gerwim]

Sinds kort ben ik een Ziggo klant en heb ik mijn eigen router (pfSense, draait in een VM op ESXi 6.7 U2) d.m.v. de DMZ functionaliteit 'achter' de modem van Ziggo gezet. Dat werkte an sich prima, behalve dat de DMZ implementatie beroerd is van de Arris modem en deze het na 30 minuten begaf. De reden dat ik DMZ wou gebruiken i.t.t. bridge is vanwege een HA setup (d.m.v. CARP).

Contact opgenomen met Ziggo, deze gaven aan dat de DMZ functionaliteit slecht is van deze modem en deze in bridge laten zetten. Opnieuw ellende, want mijn ping tijden variëren extreem:


Download/upload snelheid is wat het zou moeten zijn:


Aangezien deze setup perfect werkte met DMZ functionaliteit (dubbel NAT) heb ik het volgende geprobeerd:

• ESXi geüpgrade naar de laatste versie (6.7.0 Update 2 (Build 13981272))
• Nieuwste igbn driver (I210 netwerkkaart) geïnstalleerd
• Nieuwe pfSense VM aangemaakt en geïnstalleerd
• e1000e en VMXNET3 virtuele kaarten geprobeerd
• pfSense troubleshooting guide geprobeerd
• Laptop rechtstreeks aangesloten op de modem, dan zijn alle ping tijden OK
• Andere netwerkkabel

Aangezien de problemen er niet waren toen pfSense in NAT achter NAT gebruikt werd, daarnaast is het pingen naar de pfSense VM via het interne netwerk prima, en gaat het pingen van LAN -> WAN niet goed. Ik ben het kwijt....

Iemand nog meer ideeën om dit te troubleshooten?

Edit
Na aanleiding van deze post heb ik de power saving instellingen in de bios op disabled gezet, waarna de ping tijden er als volgt uit zien (nog steeds niet top, maar een stuk beter):

[Voor 12% gewijzigd door gerwim op 24-07-2019 21:22]

[gerwim]

Palo Alto schreef op donderdag 25 juli 2019 @ 06:43:
Kan je een traceroute doen vanaf dezelfde client waarmee je de ping verstuurt?
Als je screens stuurt zn saneren op herleidbare info uiteraard

Oortjes schreef op donderdag 25 juli 2019 @ 08:01:
Je zegt dat als je je laptop rechtstreeks verbind met je modem je geen last hebt. Heb je alle bekabeling al nagekeken of vervangen? Een breuk in een ader kan rare storingen geven

Alle bekabeling vervangen, maakt niets uit.

Dutch2007 schreef op donderdag 25 juli 2019 @ 09:26:
een ping doet alleen een eind resultaat geven, probeert 't eens met "pathping 1.1.1.1" ?

Je ziet dan ook de latency per "hop"

DJMaze schreef op donderdag 25 juli 2019 @ 10:13:
[...]


[...]

Dat is logisch, het ding heeft een Puma chipset. Ze hebben geprobeerd het hardware probleem met firmware op te lossen, maar dat is net zoiets als duct tape plakken op het gat in de fietsband (het werkt redelijk, maar niet zoals het hoort).

Dat verklaard niet waarom er geen problemen zijn als ik er rechtstreeks een apparaat op aansluit (in dit geval m'n laptop).

[gerwim]

Dutch2007 schreef op donderdag 25 juli 2019 @ 13:29:
[...]


Sorry, verkeerde app, bedoelde deze:


WinMTR

[Afbeelding]

https://sourceforge.net/projects/winmtr/

Ik weet niet of je hier zo wijzer van wordt.. ;-)

[gerwim]

borft schreef op donderdag 25 juli 2019 @ 13:33:
Wat voor hardware zit er in je router? zou het kunnen dat die netwerkkaarten daar roet in het eten gooien? Als ik ping naar 1.1.1.1 is de gemiddelde rtt rond de 11ms (OpenWRT router, uiteraard bekabeld aangesloten). Kan je zien of er ergens packet loss is? Wat is de gemiddelde rtt naar de Ziggo gateway?

De tool die je zoekt is trouwens mtr (my traceroute).

Hardware is een X11SBA-LN4F (embedded N3700). Er zijn geen problemen met latency intern (d.w.z. pingen van de router zelf). Lijkt puur in het routeren te zitten wat issues geeft.

Gemiddelde rtt naar de gateway is hetzelfde verhaal:

[gerwim]

borft schreef op donderdag 25 juli 2019 @ 14:52:
[...]

hmmm, als dit klopt, dan is je netwerk redelijk gaar.... waarom geeft je eigen router niets terug? Maar als je vanaf je router pingt, is het dus wel goed? Dus het is puur de forwarding die traag lijkt te zijn?

Nee sorry, mijn informatie was niet juist. Als ik ping vanaf de router, is er hetzelfde probleem.


Wat ik nog ga doen om het e.e.a. uit te sluiten:

1. Router vervangen door een Linux variant (ook een VM). Zo sluit ik FreeBSD uit
2. Mocht bovenstaand niets opleveren, sluit ik een andere server aan om de gehele Supermicro machine uit te sluiten

[gerwim]

Nou, ik ben er gedeeltelijk uit: een Linux VM installeren gaf hetzelfde resultaat, pfSense op een andere ESXi machine gedraait en het probleem is verdwenen.

Probleem zit dus specifiek in de originele machine (hardware of software mag ik nu gaan uitzoeken...). Bedankt allen voor jullie reacties! :-)