Discussion:
Storing?
(te oud om op te antwoorden)
Rob
2019-03-19 15:00:30 UTC
Permalink
Wat is er aan de hand? Extreme packetloss op meerdere aansluitingen,
OK op andere.
A. Dumas
2019-03-19 16:57:32 UTC
Permalink
Post by Rob
Wat is er aan de hand? Extreme packetloss op meerdere aansluitingen,
OK op andere.
Ja, hier ook, af en aan.
Sander Bos
2019-03-19 17:41:23 UTC
Permalink
Post by A. Dumas
Post by Rob
Wat is er aan de hand? Extreme packetloss op meerdere aansluitingen,
OK op andere.
Ja, hier ook, af en aan.
Blij dat ik niet de enige ben.
Op https://www.xs4all.nl/storingen/ staat niks, maar het is toch echt al
meer dan een uur.

Hoe zie je dat er packet loss is, kun je dat ergens in de fritz schermen
zien? Want ik heb rondgeklikt en zie nergens errors, en ook nslookups zijn
instantaan (want had eerst het idee dat het de initiele connecties waren)
Rob
2019-03-19 17:46:32 UTC
Permalink
Post by Sander Bos
Post by A. Dumas
Post by Rob
Wat is er aan de hand? Extreme packetloss op meerdere aansluitingen,
OK op andere.
Ja, hier ook, af en aan.
Blij dat ik niet de enige ben.
Op https://www.xs4all.nl/storingen/ staat niks, maar het is toch echt al
meer dan een uur.
Hoe zie je dat er packet loss is, kun je dat ergens in de fritz schermen
zien? Want ik heb rondgeklikt en zie nergens errors, en ook nslookups zijn
instantaan (want had eerst het idee dat het de initiele connecties waren)
Ik werk niet met Fritzbox maar ik heb wel heel rare problemen.
Het lijkt wel of IPsec meer getroffen wordt dan ander verkeer!
Is de AIVD met een nieuw experiment bezig?

Vanmiddag is mijn eigen IPsec verbinding met het werk weggevallen en
ook die van 1 van de kantoren (die via glas loopt).
Ik kan die locatie wel pingen, ook met 1500 byte packets, maar een
IPsec verbinding komt vanaf thuis helemaal niet tot stand en vanaf dat
bijkantoor blijft ie hooguit een minuut werken en dan stokt ie weer.

Hoe kan dat nou???
Met mijn XS4ALL SIM kaart kan ik wel verbinding maken van thuis uit.
A. Dumas
2019-03-19 17:55:44 UTC
Permalink
Post by Sander Bos
(want had eerst het idee dat het de initiele connecties waren)
Dat dacht ik eerst ook.
Rob
2019-03-19 18:01:26 UTC
Permalink
Post by A. Dumas
Post by Sander Bos
(want had eerst het idee dat het de initiele connecties waren)
Dat dacht ik eerst ook.
Ja het is heel vreemd. Pingen gaat prima maar IPsec werkt niet.
De ISAKMP (phase 1) lukt na een paar keer proberen wel maar phase 2
lukt hier niet. Op het werk wel maar na een minuutje komt er niks
meer door en valt ie weer weg door de keepalive en gaat het weer
opnieuw proberen op te zetten wat na een tijdje weer lukt.

Dit is vanmiddag begonnen, ik schat zo iets van half 4.
Ik heb er zelf last van op een VDSL aansluiting en dat bijkantoor
heeft XS4ALL glas. Een ander kantoor met VDSL is gewoon up maar
heeft op die tijd wel een hik gehad in IPv6 (niet in IPv4).
Daarna is het echter wel stabiel.

Het rare is dat ik met gewoon webverkeer en bijv deze ssh sessie
helemaal geen probleem heb. De PPPoE is er ook niet uit geweest.
Rob
2019-03-19 18:06:42 UTC
Permalink
Post by Rob
Post by A. Dumas
Post by Sander Bos
(want had eerst het idee dat het de initiele connecties waren)
Dat dacht ik eerst ook.
Ja het is heel vreemd. Pingen gaat prima maar IPsec werkt niet.
Ik krijg een ingeving. Het kantoor wat nog wel werkt doet IPsec via NAT-T
en hetgene wat niet werkt (en hier thuis) is zonder NAT-T dus direct
ESP op de internet verbinding, niet over UDP poort 4500.

Mag dat niet meer bij XS4ALL tegenwoordig???
Sander Bos
2019-03-19 18:12:37 UTC
Permalink
Post by Rob
Post by Rob
Ja het is heel vreemd. Pingen gaat prima maar IPsec werkt niet.
Ik krijg een ingeving. Het kantoor wat nog wel werkt doet IPsec via
NAT-T en hetgene wat niet werkt (en hier thuis) is zonder NAT-T dus
direct ESP op de internet verbinding, niet over UDP poort 4500.
Mag dat niet meer bij XS4ALL tegenwoordig???
Blijkbaar heb jij toch wat anders dan ik. Bij mij heeft het niks met IPsec
of VPN te maken, maar gewoon https connecties in de browser, lege
thumbnails in youtube, comment secties die leeg blijven en hele pagina's
die langzaam laden.

Maar in het laatste half uur (dus zeg sinds 18:30) is het niet perfect maar
sterk verbeterd hier.
Rob
2019-03-19 18:23:13 UTC
Permalink
Post by Sander Bos
Post by Rob
Post by Rob
Ja het is heel vreemd. Pingen gaat prima maar IPsec werkt niet.
Ik krijg een ingeving. Het kantoor wat nog wel werkt doet IPsec via
NAT-T en hetgene wat niet werkt (en hier thuis) is zonder NAT-T dus
direct ESP op de internet verbinding, niet over UDP poort 4500.
Mag dat niet meer bij XS4ALL tegenwoordig???
Blijkbaar heb jij toch wat anders dan ik. Bij mij heeft het niks met IPsec
of VPN te maken, maar gewoon https connecties in de browser, lege
thumbnails in youtube, comment secties die leeg blijven en hele pagina's
die langzaam laden.
Maar in het laatste half uur (dus zeg sinds 18:30) is het niet perfect maar
sterk verbeterd hier.
Kennelijk varierende problemen, ik heb nu weer een ESP verbinding met
het hoofdkantoor (via Eurofiber) maar via Ziggo glas werkt het niet.
(we hebben daar 2 glas aansluitingen)
Rob
2019-03-19 19:43:26 UTC
Permalink
Post by Rob
Post by Sander Bos
Post by Rob
Post by Rob
Ja het is heel vreemd. Pingen gaat prima maar IPsec werkt niet.
Ik krijg een ingeving. Het kantoor wat nog wel werkt doet IPsec via
NAT-T en hetgene wat niet werkt (en hier thuis) is zonder NAT-T dus
direct ESP op de internet verbinding, niet over UDP poort 4500.
Mag dat niet meer bij XS4ALL tegenwoordig???
Blijkbaar heb jij toch wat anders dan ik. Bij mij heeft het niks met IPsec
of VPN te maken, maar gewoon https connecties in de browser, lege
thumbnails in youtube, comment secties die leeg blijven en hele pagina's
die langzaam laden.
Maar in het laatste half uur (dus zeg sinds 18:30) is het niet perfect maar
sterk verbeterd hier.
Kennelijk varierende problemen, ik heb nu weer een ESP verbinding met
het hoofdkantoor (via Eurofiber) maar via Ziggo glas werkt het niet.
(we hebben daar 2 glas aansluitingen)
Inmiddels zijn al mijn verbindingen weer een kwartiertje up.
Het lijkt opgelost te zijn. Maar ik ben toch wel erg benieuwd wat
zo iets kan veroorzaken...
Jan Pieter
2019-03-19 20:15:10 UTC
Permalink
Post by Rob
Post by Rob
Post by Sander Bos
Post by Rob
Post by Rob
Ja het is heel vreemd. Pingen gaat prima maar IPsec werkt niet.
Ik krijg een ingeving. Het kantoor wat nog wel werkt doet IPsec via
NAT-T en hetgene wat niet werkt (en hier thuis) is zonder NAT-T dus
direct ESP op de internet verbinding, niet over UDP poort 4500.
Mag dat niet meer bij XS4ALL tegenwoordig???
Blijkbaar heb jij toch wat anders dan ik. Bij mij heeft het niks met IPsec
of VPN te maken, maar gewoon https connecties in de browser, lege
thumbnails in youtube, comment secties die leeg blijven en hele pagina's
die langzaam laden.
Maar in het laatste half uur (dus zeg sinds 18:30) is het niet perfect maar
sterk verbeterd hier.
Kennelijk varierende problemen, ik heb nu weer een ESP verbinding met
het hoofdkantoor (via Eurofiber) maar via Ziggo glas werkt het niet.
(we hebben daar 2 glas aansluitingen)
Inmiddels zijn al mijn verbindingen weer een kwartiertje up.
Het lijkt opgelost te zijn. Maar ik ben toch wel erg benieuwd wat
zo iets kan veroorzaken...
Wel verdacht toevallig dat de storing net nadat ie was verholpen door
xs4all werd gemeld. <5c914740$0$22340$***@news.xs4all.nl>
Rob
2019-03-19 21:15:12 UTC
Permalink
Post by Jan Pieter
Wel verdacht toevallig dat de storing net nadat ie was verholpen door
Heeft wel lang geduurd inderdaad.
En nou weten we nog niet wat er nou fout was...
Hopelijk komt er nog een keer een medewerker langs in deze thread.
(als die geen spreekverbod van de AIVD hebben natuurlijk)
A. Dumas
2019-03-19 18:30:23 UTC
Permalink
Post by Sander Bos
Blijkbaar heb jij toch wat anders dan ik. Bij mij heeft het niks met IPsec
of VPN te maken, maar gewoon https connecties in de browser, lege
thumbnails in youtube, comment secties die leeg blijven en hele pagina's
die langzaam laden.
Ja, dat. Ik speculeerde dat het met beveiligde verbindingen te maken had
(inderdaad, AIVD tests naar aanleiding van gisteren <zet aluhoedje
op>...), maar ja, welke verbinding is niet beveiligd tegenwoordig.
Ergens tussen 11 en 12 had ik er al een keer last van met scp/rsync naar
shell.xs4all.nl vanaf externe eduroam verbinding.
Miquel van Smoorenburg
2019-03-19 23:33:47 UTC
Permalink
Post by Rob
Wat is er aan de hand? Extreme packetloss op meerdere aansluitingen,
OK op andere.
Het was packetloss cq packetverminking op een een aantal 10G poorten
die elk ook weer onderdeel waren van een aantal LAGs (aggregated ethernet).
Adh van de symptomen was dat al snel duidelijk, alleen heeft het best een
tijd geduurd voordat we konden pinpointen waar in het netwerk dat nou was.
Geen storingen ergens, geen alarm meldingen, geen health meldingen, en
zeer lastig te reproduceren.

Uiteindelijk is het gevonden, de defecte kaart uitgeschakeld zodat het
verkeer eromheen ging, daarna de boel vervangen en weer aangezet.

Mike.
Paul van der Vlis
2019-03-20 08:20:28 UTC
Permalink
Post by Miquel van Smoorenburg
Post by Rob
Wat is er aan de hand? Extreme packetloss op meerdere aansluitingen,
OK op andere.
Het was packetloss cq packetverminking op een een aantal 10G poorten
die elk ook weer onderdeel waren van een aantal LAGs (aggregated ethernet).
Adh van de symptomen was dat al snel duidelijk, alleen heeft het best een
tijd geduurd voordat we konden pinpointen waar in het netwerk dat nou was.
Geen storingen ergens, geen alarm meldingen, geen health meldingen, en
zeer lastig te reproduceren.
Uiteindelijk is het gevonden, de defecte kaart uitgeschakeld zodat het
verkeer eromheen ging, daarna de boel vervangen en weer aangezet.
Ik heb er ook veel last van gehad, en verschillende klanten belden me.
Wat ik dan toch mis is een melding op https://www.xs4all.nl/storingen/

Ah, ik zie dat het er gisteravond om 20:47 nog op gezet is, maar ik
kreeg de eerste melding om 14:47, toen een om 15:57, en meerdere rond 18:00.

Groet,
Paul
--
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/
Rob
2019-03-20 08:31:36 UTC
Permalink
Post by Miquel van Smoorenburg
Post by Rob
Wat is er aan de hand? Extreme packetloss op meerdere aansluitingen,
OK op andere.
Het was packetloss cq packetverminking op een een aantal 10G poorten
die elk ook weer onderdeel waren van een aantal LAGs (aggregated ethernet).
Adh van de symptomen was dat al snel duidelijk, alleen heeft het best een
tijd geduurd voordat we konden pinpointen waar in het netwerk dat nou was.
Geen storingen ergens, geen alarm meldingen, geen health meldingen, en
zeer lastig te reproduceren.
Uiteindelijk is het gevonden, de defecte kaart uitgeschakeld zodat het
verkeer eromheen ging, daarna de boel vervangen en weer aangezet.
Heel mooi, bedankt voor de info Mike!
Maar is er ook een reden te bedenken waarom dat probleem afhankelijk
was van de SOORT verkeer en bijvoorbeeld ping prima ging maar IPsec niet?

Is het soms zo dat die aggregatie gebeurt op basis van een hash van een
beperkt aantal velden zoals source/dest IP en protocol, zodat het kan
zijn dat je IPsec verkeer allemaal over die defecte kaart liep terwijl
ICMP verkeer tussen diezelfde adressen over een goede kaart liep?
Miquel van Smoorenburg
2019-03-20 10:12:07 UTC
Permalink
Post by Rob
Heel mooi, bedankt voor de info Mike!
Maar is er ook een reden te bedenken waarom dat probleem afhankelijk
was van de SOORT verkeer en bijvoorbeeld ping prima ging maar IPsec niet?
Is het soms zo dat die aggregatie gebeurt op basis van een hash van een
beperkt aantal velden zoals source/dest IP en protocol, zodat het kan
zijn dat je IPsec verkeer allemaal over die defecte kaart liep terwijl
ICMP verkeer tussen diezelfde adressen over een goede kaart liep?
Inderdaad, exact dat.

In het begin ('s middags) was het symptoom vaak
ook "hoge pingtijden EN packetloss", dus dat maakt het nog moeilijker
te vinden, want dan zoek je naar een volle link. Die er niet is.

Mike.
Rob
2019-03-20 10:48:34 UTC
Permalink
Post by Miquel van Smoorenburg
Post by Rob
Heel mooi, bedankt voor de info Mike!
Maar is er ook een reden te bedenken waarom dat probleem afhankelijk
was van de SOORT verkeer en bijvoorbeeld ping prima ging maar IPsec niet?
Is het soms zo dat die aggregatie gebeurt op basis van een hash van een
beperkt aantal velden zoals source/dest IP en protocol, zodat het kan
zijn dat je IPsec verkeer allemaal over die defecte kaart liep terwijl
ICMP verkeer tussen diezelfde adressen over een goede kaart liep?
Inderdaad, exact dat.
Dat zijn leuke dingen...
Ik kwam er op een gegeven moment achter dat een niet-werkende IPsec
verbinding (ESP) het wel deed als er NAT-T (UDP) gebruikt werd.
Post by Miquel van Smoorenburg
In het begin ('s middags) was het symptoom vaak
ook "hoge pingtijden EN packetloss", dus dat maakt het nog moeilijker
te vinden, want dan zoek je naar een volle link. Die er niet is.
Hoge pingtijden heb ik niet gezien. Extreme packetloss wel. Op een
gegeven moment lag de IPsec verbinding naar mijn huis eruit en toen heb
ik vanaf de shellserver gepinged en kreeg minder dan 10% retour maar
wat er retour kwam dat was OK kwa pingtijd.
Toen ik later thuis kwam constateerde ik dat ander verkeer, bijvoorbeeld
een unencrypted GRE tunnel, geen seconde onderbroken geweest was.

De IPsec verbinding kwam wel door phase1 heen maar op phase2 was er geen
enkel antwoord meer. Maar wel met NAT-T dus. Toen begon ik te denken
dat ESP geblokkeerd was naar buiten. Vooral ook omdat op een andere
aansluiting het fenomeen hetzelfde was.
(ik had op datzelfde moment wel een ESP verbinding naar een andere XS4ALL
aansluiting open staan en die was helemaal niet down geweest)

Loading...