Beantwoord

weer een routering issue in Brabant?


is er op dit moment weer een routeringsprobleem in Brabant? veel packet loss, hoge ping naar google etc...

icon

Beste antwoord door Jason 21 May 2020, 08:58

Bekijk origineel

35 reacties

Reputatie 2

Yes dank voor de hulp!

Reputatie 6
Badge +2

Mooi om te zien dat er inmiddels een hoop voortgang is gemaakt @Beschuit! Zo te zien komt er aanstaande dinsdag een monteur langs en ik vermoed dat deze een hoop voor je kan betekenen. Voor nu nog een prettig weekend gewenst.

Reputatie 6
Badge +2

Hi @Beschuit, wat inzicht gevend dat je deze details doorspeelt! Na een uitgebreide analyse van jouw internetlijn zie ik inderdaad dat er zich instabiliteit voordoet. Daarom heb ik de technische dienst ingeschakeld en wij gaan de komende dagen uitgebreid jouw internetlijn meten. Op dit moment is mijn vermoeden dat wij een monteur langs gaan sturen, en je zal de eerste zijn die dit te weten komt zodra wij weten welke soort monteur dit moet zijn. Wij gaan hier voor je achteraan!

Reputatie 2

Ik zie weer op meerdere momenten packet loss plaatsvinden naar diverse sites, op verschillende momenten. Tweakers.net bijv. al sinds begin december. Youtube hetzelfde, alhoewel die specifiek de laatste 30u weer geen loss laat zien. Maar O365 toont ook laatste 3 uur weer issues, daar loopt het al sinds september zie ik. 

 

tweakers.net
Youtube.com
O365

 

Reputatie 7
Badge +8

Hi @obbommel, excuses voor de wat latere reactie dit keer. We hebben specifiek jouw voorbeeld en die van Soundwork08 in dit topic doorgezet naar de netwerkengineer die eerder met de packetloss problemen bezig is geweest. Ik verwacht hier begin volgende week meer duidelijkheid over te hebben. Ik houd je uiteraard op de hoogte!

@Brian hoewel er hoopgevende berichten waren dat de oorzaak van het packet loss probleem gevonden was en vervolgens opgelost, zie ik nog steeds veel packet loss, bv naar google.com.

smokeping geeft een continue packet verlies van ~25 % aan naar google.com, en mtr laat nog steeds een issue bij de 4e hop zien.

$ mtr -b -r google.com
Start: 2020-06-29T08:58:43+0200
HOST: fitletpc                    Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- zyxel (192.168.2.254)      0.0%    10    0.6   0.7   0.6   0.9   0.1
  2.|-- 1-4-201-31.ftth.glasopera  0.0%    10    4.1   4.4   4.0   4.6   0.2
  3.|-- 10.10.80.149               0.0%    10    8.6   8.5   8.3   8.9   0.2
  4.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  5.|-- 108.170.229.222            0.0%    10    8.1   8.1   7.8   8.2   0.1
  6.|-- 108.170.236.135            0.0%    10    8.2   8.1   7.9   8.2   0.1
  7.|-- ams16s29-in-f14.1e100.net  0.0%    10    8.4   8.2   7.9   8.5   0.2
 

kan je een update van de status geven?

 

Reputatie 7
Badge +6

Hi @obbommel en @Professorconst,

 

I checked techsupport and they figured that certain hops are programmed to not respond to ICMP packages for security reason (at certain times). It looks like that's the case when there's 100% packet loss. This should not be the reason why you experience packet loss (10-30%). When checking a MTR, we're looking for a hop with a percentage (not 100%) packet loss. That's what could cause the experienced packet loss. At this moment, it's still not clear what's the reason for certain customers on ODF with packet loss. 

Same problem again. And I bet it will be gone again in few hours…

 

Traceroute has started…

 

traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 72 byte packets

1  rt-ac66u_b1-d530 (192.168.1.1)  10.613 ms  2.384 ms  2.814 ms

2  1-4-201-31.ftth.glasoperator.nl (31.201.4.1)  14.096 ms  20.335 ms *

3  10.10.80.149 (10.10.80.149)  29.676 ms  18.816 ms  21.787 ms

4  * * *

5  216.239.46.56 (216.239.46.56)  17.519 ms  16.375 ms  17.341 ms

6  209.85.240.115 (209.85.240.115)  15.961 ms  13.955 ms  17.010 ms

7  dns.google (8.8.8.8)  21.351 ms  16.603 ms  16.481 ms

@Brian dit heb ik gedaan, en het maakt niet uit. ook als ik 8.8.8.8 als dns instel, en een mtr doe naar 8.8.8.8 , gaat het bij de 4e hop mis.

 mtr -w -b 8.8.8.8
Start: 2020-06-17T09:44:13+0200
HOST: fitletpc                                     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- zyxel (192.168.2.254)                         0.0%    10    0.8   0.7   0.6   1.0   0.1
  2.|-- 1-4-201-31.ftth.glasoperator.nl (31.201.4.1)  0.0%    10    4.4   4.3   4.1   4.5   0.1
  3.|-- 10.10.80.149                                  0.0%    10    8.5   8.6   8.4   8.9   0.2
  4.|-- ???                                          100.0    10    0.0   0.0   0.0   0.0   0.0
  5.|-- 216.239.46.56                                 0.0%    10   10.1  10.2  10.0  10.6   0.2
  6.|-- 108.170.236.137                               0.0%    10    8.0   8.2   8.0   8.3   0.1
  7.|-- dns.google (8.8.8.8)                          0.0%    10    8.4   8.5   8.3   8.6   0.1
 

Reputatie 7
Badge +8

Hi @obbommel, dank voor het testen! Het zou een mogelijk routing issue kunnen zijn zo te zien. Inderdaad die 4de hop waar het mis gaat. Zou je het ook eens willen testen via de Google DNS? Als het hiermee niet voor komt dan vermoed ik dat het inderdaad onze DNS routing is en zet ik het door naar ons netwerk team om dit verder te onderzoeken. 

@ThijmenNL ik gebruik geen aparte plugin , gewoon [[inputs.ping]] sectie in telegraf.conf ingevuld. 

Die variaties in route lijken me de reden van het probleem, dit verklaart dat de ping tijd naar google tussen 10 - 100ms varieert in blokjes van 5 min (zoals te zien in de grafana plaatjes...)

Reputatie 1

Welke plugin gebruik je in telegraf? Ik gebruik nu pinger in combinatie met prometheus. 

Daarnaast @obbommel is dat ook een totaal andere route die je nu hebt gestuurd, die 4e host zit er niet eens in.

voor die ping en packetloss als functie van de tijd gebruik ik telegraf + influxdb + grafana

op advies van @Brian heb ik mtr gebruikt. het gekke is dat soms die 4e hop wel werkt, zonder packet loss:

mtr -w -b www.google.com
Start: 2020-06-16T11:47:42+0200
HOST: fitletpc                                     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- zyxel (192.168.2.254)                         0.0%    10    0.7   0.7   0.6   0.9   0.1
  2.|-- 1-4-201-31.ftth.glasoperator.nl (31.201.4.1)  0.0%    10    4.1   4.2   3.9   4.5   0.2
  3.|-- 10.10.80.145                                  0.0%    10    8.5   8.5   8.0   9.1   0.3
  4.|-- 72.14.197.78                                  0.0%    10    8.3   8.5   8.2   9.3   0.3
  5.|-- 108.170.241.193                               0.0%    10    8.0   8.0   7.8   8.3   0.2
  6.|-- 108.170.227.3                                 0.0%    10    8.8   8.8   8.4   9.0   0.2
  7.|-- ams16s32-in-f4.1e100.net (172.217.168.196)    0.0%    10    7.7   7.7   7.5   7.9   0.1
 

Reputatie 1

@obbommel Die 4e hop lijkt mij niet het probleem - deze staat simpelweg geen ICMP requests toe. Hoop dat de oplossing snel voor je gevonden is! Mag ik vragen welke tools je gebruikt? Wat gebruik je om door te meten? Hier gebruik ik ook Grafana. Wellicht zou je ook een keer naar smokeping kunnen kijken.

zie hier, dit is de mtr output naar www.google.com, kennelijk gaat er bij de 4e hop wat mis: 100% packet loss. datum/tijdstip : nu. speedtest ( trined in St Oedenrode) is vrij normaal (d: 921 Mbps, u: 844 Mbps)

$ mtr -w -b www.google.com
Start: 2020-06-16T10:54:35+0200
HOST: fitletpc                                     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- zyxel (192.168.2.254)                         0.0%    10    0.8   0.7   0.6   0.8   0.1
  2.|-- 1-4-201-31.ftth.glasoperator.nl (31.201.4.1)  0.0%    10    4.3   4.4   4.1   5.7   0.5
  3.|-- 10.10.80.149                                  0.0%    10    8.6   8.7   8.5   8.9   0.1
  4.|-- ???                                          100.0    10    0.0   0.0   0.0   0.0   0.0
  5.|-- 216.239.43.230                                0.0%    10    9.9  10.3   9.9  11.3   0.4
  6.|-- 108.170.237.45                                0.0%    10    8.7   8.5   8.2   8.7   0.1
  7.|-- ams15s32-in-f4.1e100.net (216.58.211.100)     0.0%    10    8.3   8.2   8.1   8.4   0.1
 

Reputatie 7
Badge +8

Hi @obbommel, dank voor de informatie. Hmm het lijkt dus inderdaad vanaf buiten het eigen netwerk mis te gaan. Zou het voor jou mogelijk zijn om nog een traceroute te doen via onderstaande wijze? Dan ga ik de resultaten doorspelen aan onze technische dienst:

 

Om te zorgen dat we het wel zo snel mogelijk kunnen tackelen willen we graag onderstaande informatie ontvangen:

  • Wanneer speelt het probleem (datum/tijdstippen)
  • Naar welke websites of servers speelt het probleem
  • Wat zijn de resultaten van een speedtest en naar welke server is die test gedaan
  • Wat zijn de resultaten van een MTR (Windows / Linux) naar de betreffende website of server.

We vragen in dit geval om een MTR ipv een normale trace route omdat een MTR een ping stuurt naar een specifieke hop in het pad. Dan kunnen we precies zien op welke hop het probleem zit of vanaf waar het fout gaat.

bedankt voor de update. Nee, ik zie nog geen verschil:

  • oplopend trappetjes patroon waarin de ping tijd naar colocenter.nl oploopt van 9ms naar ± 900 ms blijft te zien
  • ping naar google.com is normaal rond 9 ms, maar regelmatig (paar keer per uur) blokjes van 5 min dat het stijgt naar +-100 ms, wel constant , niet oplopend zoals bij colocenter
  • ping 1.1.1.1 is over het algemeen constant 9 ms.
  •  

Reputatie 7
Badge +6

Hoi @obbommel,

 

Sinds vanochtend (mogelijk gisteravond al?) is er een probleem met de verbinding geweest in Eindhoven en Tilburg. Wellicht dat dit de oorzaak was van de packet loss. Zou je nu (problemen zijn nu inmiddels verholpen) opnieuw een traceroute kunnen uitvoeren en kijken of het nu beter gaat? 

het valt me op dat de ping naar bv 1.1.1.1 vrij constant en OK is. de issues zitten vooral in NL, bv naar nl-ix.

het valt me dat de ping naar bv colocenter.nl (gekoppeld aan de nl-ix exchange) zeer variabel is:

ping naar colocenter

het valt op dat het een soort trappetjes zijn, steeds hoger ping waarde, en dan weer normaal (~10ms)

bij traceroute is dit bevestigd:

volgens mij heeft dit relatie met de packet loss issues, met name naar NL servers...

Reputatie 7
Badge +6

Hi @Professorconst,

 

Could you (like lex333 dit above) please send a traceroute or MTR trace in this topic? That way we can trace the origin of the drop in speed. I'm determined to find the reason for these glitches. 

 

Do you still experience packet loss? Could you give me an idea how long and at what times these happen?

And here we go again. Same problem with download speed, lost packets etc.

sorry, t-mobile. But it is time...

Reputatie 7
Badge +8

Hi @lex333, ik heb zojuist gereageerd op je privébericht. In jouw geval lijkt er specifiek iets met de binnenkomende verbinding aan de hand. Ik hoor graag wat je bevindingen zijn, dan gaan we er mee aan de slag!

@Sander

het is nu weer waardeloos, naar  google

 

Ping verlies is ongeveer 18% van de pings…

Speedtest via fast.com: heb een 1gbit abo...

 

Reputatie 7
Badge +6

Hi @Professorconst & @lex333 & @egonw,

 

It seems there was a short glitch in internetspeed wednesday evening (and apparantly again this weekend). Luckily it didn't last long. If for some reason the downloadspeed (or upload) drops again, could you please send a traceroute or MTR trace in this topic? That way we can trace the origin of the drop in speed. 

 

Thanks in advance!

Reageer