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 ]

[Verwijderd]

Kan je een traceroute doen vanaf dezelfde client waarmee je de ping verstuurt?
Als je screens stuurt zn saneren op herleidbare info uiteraard

[ Voor 29% gewijzigd door Verwijderd op 25-07-2019 06:52 ]

[Oortjes]

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

[Dutch2007]

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"

[ Voor 18% gewijzigd door Dutch2007 op 25-07-2019 09:26 ]

[DJMaze]

gerwim schreef op woensdag 24 juli 2019 @ 20:39:
de Arris modem

gerwim schreef op woensdag 24 juli 2019 @ 20:39:
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):

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).

[ Voor 4% gewijzigd door DJMaze op 25-07-2019 10:21 ]

[gerwim]

Verwijderd 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).

[Dutch2007]

gerwim schreef op donderdag 25 juli 2019 @ 13:26:
[...]

Sorry, verkeerde app, bedoelde deze:


WinMTR



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

[borft]

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).

[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:

[Brahiewahiewa]

gerwim schreef op donderdag 25 juli 2019 @ 13:34:
[...]


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

't scheelt misschien als je de laatste versie 0.92 gaat gebruiken

[borft]

gerwim schreef op donderdag 25 juli 2019 @ 13:39:
[...]


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:
[Afbeelding]

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?

[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! :-)

[DJMaze]

gerwim schreef op donderdag 25 juli 2019 @ 13:26:
Dat verklaard niet waarom er geen problemen zijn als ik er rechtstreeks een apparaat op aansluit (in dit geval m'n laptop).

http://www.dslreports.com/tools/puma6
Als je geen problemen hebt, krijg je zoiets:

code:

32ms : x
33ms : xx
34ms : xxxxxxxxxxxxxxxxxxxxx
35ms : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
36ms : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
37ms : xxxxxxxxxxxxxxxxxxxxxxxxxxxx
38ms : xxxxxxxxxxx
39ms : xxxx
40ms : xxxxxx
41ms : xxxx
42ms : x
43ms : xxx
44ms : x
45ms : xx
64ms : x

Je moet dus altijd lokaal pingen en met iperf testen.
Dan weet je 100% zeker dat het lokaal is.

[ Voor 6% gewijzigd door DJMaze op 26-07-2019 14:55 ]