• Blog
  • Info Support
  • Career
  • Training
  • International Group
  • Info Support
  • Blog
  • Career
  • Training
  • International Group
  • Search
logo InfoSupport
  • Latest blogs
  • Popular blogs
  • Experts
      • All
      • Bloggers
      • Speakers
  • Meet us
  • About us
    • nl
    • en
    • .NET
    • 3D printing
    • Advanced Analytics
    • Agile
    • Akka
    • Alexa
    • Algorithms
    • Api's
    • Architectuur
    • Artificial Intelligence
    • ATDD
    • Augmented Reality
    • AWS
    • Azure
    • Big Data
    • Blockchain
    • Business Intelligence
    • Chatbots
    • Cloud
    • Code Combat
    • Cognitive Services
    • Communicatie
    • Containers
    • Continuous Delivery
    • CQRS
    • Cyber Security
    • Dapr
    • Data
    • Data & Analystics
    • Data Science
    • Data Warehousing
    • Databricks
    • DataOps
    • Developers life
    • DevOps
    • Digital Days
    • Digital Twin
    • Docker
    • eHealth
    • Enterprise Architecture
    • Event Sourcing
    • Hacking
    • Infrastructure & Hosting
    • Innovatie
    • Integration
    • Internet of Things
    • Java
    • Machine Learning
    • Microservices
    • Microsoft
    • Microsoft Bot Framework
    • Microsoft Data Platform
    • Mobile Development
    • Mutation Testing
    • Open source
    • Pepper
    • Power BI
    • Privacy & Ethiek
    • Python
    • Quality Assistance & Test
    • Quality Assurance & Test
    • Requirements Management
    • Scala
    • Scratch
    • Security
    • SharePoint
    • Software Architecture
    • Software development
    • Software Factory
    • SQL Server
    • SSL
    • Start-up
    • Startup thinking
    • Stryker
    • Test Quality
    • Testing
    • TLS
    • TypeScript
    • Various
    • Web Development
    • Web-scale IT
    • Xamarin
    • All
    • Bloggers
    • Speakers
Home » TCP Resets in Docker
  • TCP Resets in Docker

    • By Luc Klaassen
    • Containers 4 years ago
    • Containers 0 comments
    • Containers Containers
    TCP Resets in Docker

    Een aantal maanden geleden is binnen de afdeling waar ik werk, namelijk het PDC, een probleem opgetreden met TCP verbindingen binnen onze Docker containers. Op het issue is een flinke deep-dive gedaan en er zijn wat interessante resultaten uit gekomen. In dit artikel zal uitgelegd worden wat het probleem was, hoe we de oorzaak hebben gevonden, en de oplossing die we hebben gevonden.

    Het probleem

    Binnen het PDC kwamen we al eerder wat rare verbindingsproblemen vanuit Docker containers tegen. Dit was echter altijd eenmalig en zeer sporadisch. Tot op een ochtend ineens een van onze repositories niet meer gecloned kon worden vanuit onze jenkins instance. Nadat de clone begon, werd er na een aantal seconden plots geen data meer ontvangen van GitLab. Jenkins dacht echter dat er nog data aan zou komen, en hield dus de connectie open totdat na 10 minuten een timeout optrad. Gezien het feit dat het plots consistent fout ging, moest er gezocht worden naar een oplossing.

    De zoektocht

    Als er plots connectieproblemen optreden, vermoed je al snel dat de volledige verbinding problemen heeft. Het rare aan de situatie was echter dat het alleen bij deze ene repository voorkwam. We wisten dus niet goed hoe we dit probleem verder gingen onderzoeken. We besloten om de jenkins instance en GitLab opnieuw op te starten, om te kijken of dat het probleem zou oplossen. Dit was inderdaad het geval. Dit was natuurlijk geen permanente oplossing, dus gingen we verder op zoek naar een oplossing. Na een tijd begonnen de problemen zich weer voor te doen. Nu waren er meerdere repositories die problemen hadden. Het viel ons op dat de grootte van de repository meespeelde. De allereerste repository die problemen kreeg was de grootste die we hadden, maar niet dusdanig groot (12 MB) dat we dachten dat verkleinen van de repository een oplossing was.

    Omdat de problemen zich begonnen te verspreiden en we in de verbinding an sich geen problemen zagen (de jenkins en gitlab instanties konden elkaar zonder problemen vinden in het netwerk en een verbinding opzetten), wilden we het probleem reproduceerbaar te maken buiten jenkins. We besloten een checkout te doen van de repository op de host van de Jenkins docker container. Toen viel ons ineens op dat buiten de containers de git clone nog wel werkte. Binnen de container faalde het echter.

    Op dat punt besloten we om het netwerkverkeer te analyseren. Zoals verwacht zagen we buiten de container niks geks gebeuren bij een clone, omdat de checkout hier succesvol was. Toen we echter de clone binnen de container deden, zagen we na een aantal seconden geen data meer binnenkomen. Toen we buiten de container het verkeer analyseerden zagen we het probleem. Er werd een RST packet gestuurd vanuit GitLab.

    Een TCP dump van de RST packet

    Waarom dit precies gebeurt is nog helaas nog steeds niet 100% duidelijk. Gezien de werkende oplossing die hieronder beschreven staat kunnen we in ieder geval zeker zijn dat het komt doordat er ongeldige TCP packets ontvangen worden bij GitLab, waardoor deze van slag raakt en de verbinding wilt resetten.

    De oplossing

    Na flink rondneuzen op het internet kwamen we uit bij een issue wat enigszins wat weghad van het probleem waar we tegenaan liepen*. In dit issue word gesproken over een retransmit door AWS machines waardoor een RST packet werd verstuurd op de verbinding. De oorzaak is mogelijk niet hetzelfde als in ons geval, maar de workaround die genoemd word werkt gelukkig ook voor ons. De workaround is het volgende commando:

    iptables -I INPUT -m conntrack –ctstate INVALID -j DROP

    Wat dit commando doet is de server vertellen dat hij invalid packets moet negeren, in plaats van een RST terug te sturen. Dit commando voeren we uit op de host van onze GitLab instantie. Nadat we dit gedaan hadden waren onze problemen verdwenen. Hierdoor durven we met enige zekerheid te zeggen dat de client ongeldige TCP packets stuurt naar onze GitLab instantie.

    Eindstand

    Er zijn nog een aantal losse eindes aan dit probleem helaas.

    Zo weten we nog steeds niet precies waarom vanuit onze docker container ongeldige TCP packets gestuurd worden. Ik vermoed zelf dat het te maken heeft met TCP window scaling**.

    Ook viel het ons op dat we van binnen onze container geen RST packet ontvingen. De connectie wordt dus op host niveau getermineerd, maar deze reset wordt niet naar binnen de docker container gestuurd. Hierdoor krijgt hij uiteindelijk een timeout.

    Als laatste hebben we de problemen ook al een aantal keer op andere plekken teruggezien waar grotere downloads gedaan worden tussen docker containers op 2 verschillende hosts. De workaround heeft in alle gevallen de problemen verholpen, maar het duidt wel op een terugkerend probleem.

    Mocht je nog ideeën of vragen hebben over het probleem, laat het ons ook vooral weten.

     

    Luc Klaassen

    PDC – Info Support

     

    * https://github.com/docker/libnetwork/issues/1090

    ** https://www.pitt-pladdy.com/blog/_20091125-185551_0000_Linux_Netfilter_and_Window_Scaling/

    https://github.com/docker/distribution/issues/785

     

     

     

     

    Share this

Luc Klaassen

View profile

Data Discovery Channel

  • Modern Data Platform

  • Gartner Data & Analytics Summit 2022

  • De Data Architecture ®Evolution

Nieuwsbrief

* verplichte velden

Contact

  • Head office NL
  • Kruisboog 42
  • 3905 TG Veenendaal
  • T +31 318 552020
  • Call
  • Mail
  • Directions
  • Head office BE
  • Generaal De Wittelaan 17
  • bus 30 2800 Mechelen
  • T +32 15 286370
  • Call
  • Mail
  • Directions

Follow us

  • Twitter
  • Facebook
  • Linkedin
  • Youtube

Newsletter

Sign in

Extra

  • Media Library
  • Disclaimer
  • Algemene voorwaarden
  • ISHBS Webmail
  • Extranet
Beheer cookie toestemming
Deze website maakt gebruik van Functionele en Analytische cookies voor website optimalisatie en statistieken.
Functioneel Always active
De technische opslag of toegang is strikt noodzakelijk voor het legitieme doel het gebruik mogelijk te maken van een specifieke dienst waarom de abonnee of gebruiker uitdrukkelijk heeft gevraagd, of met als enig doel de uitvoering van de transmissie van een communicatie over een elektronisch communicatienetwerk.
Voorkeuren
De technische opslag of toegang is noodzakelijk voor het legitieme doel voorkeuren op te slaan die niet door de abonnee of gebruiker zijn aangevraagd.
Statistieken
De technische opslag of toegang die uitsluitend voor statistische doeleinden wordt gebruikt. De technische opslag of toegang die uitsluitend wordt gebruikt voor anonieme statistische doeleinden. Zonder dagvaarding, vrijwillige naleving door uw Internet Service Provider, of aanvullende gegevens van een derde partij, kan informatie die alleen voor dit doel wordt opgeslagen of opgehaald gewoonlijk niet worden gebruikt om je te identificeren.
Marketing
De technische opslag of toegang is nodig om gebruikersprofielen op te stellen voor het verzenden van reclame, of om de gebruiker op een website of over verschillende websites te volgen voor soortgelijke marketingdoeleinden.
Manage options Manage services Manage vendors Read more about these purposes
Voorkeuren
{title} {title} {title}