Wat is Network Congestion?
Network Congestion (netwerkcongestie) is de toestand waarin een netwerkverbinding of switchpoort meer verkeer krijgt aangeboden dan zij kan doorgeven, waardoor pakketten in buffers moeten wachten en bij volle buffers worden weggegooid. Het gevolg is extra vertraging, wisselende vertraging en pakketverlies. In OT-netwerken is dat ernstiger dan in kantoornetwerken: cyclische besturingsprotocollen verwachten hun data binnen enkele milliseconden en schakelen bij uitblijven over naar een veilige toestand. Congestie is daardoor geen comfortprobleem maar een risico voor beschikbaarheid en deterministisch gedrag.
🧠 Hoe ontstaat netwerkcongestie?
Een switch ontvangt frames op een of meer ingangen en zet ze in een wachtrij voor de uitgaande poort. Zolang er per tijdseenheid niet meer bits binnenkomen dan de uitgang kan versturen, blijft die wachtrij leeg. Komen er meer, dan groeit de wachtrij; is de buffer vol, dan gooit de switch nieuwe frames weg (tail drop).
Belangrijk is dat congestie per poort en per moment ontstaat, niet per netwerk en per gemiddelde:
- Veel-op-één (incast) - tientallen apparaten sturen tegelijk naar één SCADA-server of historian; de poort richting die server loopt vol, ook al is het totale netwerk rustig.
- Snelheidsverschil - een 1 Gbit/s-uplink voedt een 100 Mbit/s-apparaat. Een burst van de snelle kant moet in de buffer van de trage poort passen.
- Microbursts - pieken van enkele milliseconden die in een gemiddelde over vijf minuten onzichtbaar zijn. Een poort met 5% gemiddelde belasting kan dus toch pakketten verliezen.
- Flooding - broadcast, onbekend unicastverkeer en multicast zonder filtering worden naar álle poorten in een VLAN gekopieerd en belasten zo ook apparaten die het verkeer niet nodig hebben.
Ter illustratie van de tijdschaal: een maximaal Ethernetframe van 1.518 bytes duurt op 100 Mbit/s ongeveer 121 µs om te versturen, op 1 Gbit/s ongeveer 12 µs. Staan er dertig van zulke frames vóór een besturingsframe in de wachtrij van een 100 Mbit/s-poort, dan is dat al ruim 3,6 ms extra vertraging, langer dan een typische PROFINET-cyclus.
⚠️ Welke symptomen herkent u in een industrieel netwerk?
| Symptoom | Effect op industriële systemen |
|---|---|
| Verhoogde latency | Cyclustijden worden onvoorspelbaar, regelkringen reageren trager |
| Jitter | Wisselende aankomsttijden verstoren motion control en tijdsynchronisatie |
| Packet loss | Procesdata of commando’s gaan verloren; cyclische protocollen sturen niets opnieuw |
| Watchdog-time-outs | Verbinding tussen controller en I/O valt weg, uitgangen gaan naar hun veilige waarde |
| Trage HMI-schermen | Waarden bevriezen of tonen “communicatiefout”, operators verliezen overzicht |
| Gaten in historische data | Logging en rapportages missen meetpunten |
| Hoge CPU-belasting op apparaten | Oudere PLC’s en I/O-modules raken overbelast door verkeer dat niet voor hen bedoeld is |
Het verraderlijke is dat de symptomen vaak sporadisch zijn. Een storing die alleen optreedt tijdens de nachtelijke back-up of bij het openen van een groot trendscherm wordt gemakkelijk aan “slechte kabels” toegeschreven.
🔍 Wat zijn de belangrijkste oorzaken in OT?
| Oorzaak | Beschrijving |
|---|---|
| IT- en OT-verkeer op één segment | Back-ups, software-updates of videostreams verdringen besturingsverkeer |
| Onvoldoende netwerksegmentatie | Geen scheiding tussen realtime en niet-realtime verkeer |
| Broadcast storms | Een netwerklus zonder werkend RSTP of een defecte netwerkkaart laat broadcasts eindeloos rondgaan |
| Ongefilterde multicast | Multicast-I/O (bijvoorbeeld bij IP) wordt zonder IGMP-snooping naar elke poort gestuurd |
| Ontbrekende of verkeerde QoS | Besturingsframes krijgen geen voorrang in de wachtrij |
| Unmanaged switches | Geen prioriteiten, geen storm control, geen diagnose |
| Actieve scans | Een netwerkscan of inventarisatietool overspoelt kwetsbare veldapparaten |
| Aanvallen | Een DDoS-aanval of malware die zich over het netwerk verspreidt, veroorzaakt bewust of onbedoeld overbelasting |
Een bekend voorbeeld is Browns Ferry 3 in de Verenigde Staten. Op 19 augustus 2006 moest de reactor handmatig worden afgeschakeld nadat beide recirculatiepompen uitvielen. De Amerikaanse toezichthouder NRC stelde vast dat de besturingen van de frequentieregelaars waren vastgelopen door overmatig verkeer op het interne besturingsnetwerk. Er was geen aanval; de oplossing bestond onder meer uit firewalls die het verkeer naar gevoelige apparaten begrenzen.
🔧 Waarom is congestie in OT erger dan in IT?
In IT-netwerken lost TCP congestie grotendeels zelf op. Na de congestie-ineenstorting van het vroege internet in 1986 kreeg TCP algoritmen die bij pakketverlies de zendsnelheid verlagen (slow start en congestion avoidance, tegenwoordig vastgelegd in RFC 5681). Een webpagina laadt dan wat trager, maar alles komt aan.
Industriële realtime protocollen werken anders:
- Geen hertransmissie - PROFINET RT draait direct op Ethernet en EtherNet/IP impliciete I/O op UDP. Een verloren frame wordt niet opnieuw gestuurd; de volgende cyclus brengt pas nieuwe data.
- Watchdogs - bij ProfiNET is de standaard-watchdog drie keer de updatetijd. Met een updatetijd van 1 ms verbreekt het apparaat de verbinding na ongeveer 3 ms zonder data. Bij EtherNet/IP volgt de time-out uit de RPI (Requested Packet Interval) maal een multiplier.
- Veilige reactie - het verbreken van de verbinding zet uitgangen in hun fail-safe-stand. Bij veiligheidsprotocollen kan dat een noodstop of het stilleggen van een machine betekenen.
- Beperkte apparaten - veel sensoren, I/O-stations en oudere controllers hebben kleine netwerkstacks. Een broadcast storm die een server negeert, kan zo’n apparaat volledig blokkeren.
Daarom vraagt IEC 62443-3-3 bij FR 7 (beschikbaarheid van middelen) om bescherming tegen denial-of-service (SR 7.1) en beheer van systeemmiddelen (SR 7.2): een systeem moet onder hoge netwerkbelasting zijn essentiële functies blijven uitvoeren.
✅ Hoe voorkomt en beperkt u congestie?
| Maatregel | Toelichting |
|---|---|
| Netwerksegmentatie | Scheid realtime OT-verkeer van niet-kritieke dataflows, bijvoorbeeld per zone volgens het Purdue Model; een EtherCAT-segment draait meestal als eigen, afgesloten netwerk |
| VLAN’s | Begrenzen broadcastdomeinen; op een gedeelde trunk delen VLAN’s wel dezelfde bandbreedte |
| QoS | IEEE 802.1Q kent acht prioriteitsniveaus; PROFINET RT gebruikt prioriteit 6, op IP-niveau markeert DSCP het verkeer |
| Storm control en rate limiting | Begrens broadcast-, multicast- en onbekend unicastverkeer per poort |
| IGMP-snooping | Stuur multicast alleen naar poorten met abonnees, met een querier per VLAN |
| Managed of industriële switches | Voldoende buffers, prioriteitswachtrijen, poortstatistieken en SNMP-diagnose |
| Netwerkmonitoring | Meet belasting, drops en fouten per poort; leg verkeer vast via SPAN of TAP |
| TSN | Time-Sensitive Networking (onder meer IEEE 802.1Qbv) reserveert tijdvensters, zodat realtime verkeer gegarandeerd ruimte krijgt |
| Firewall of zonegrens | Beperk verbindingen en verkeer naar kwetsbare apparaten, zoals na Browns Ferry |
Meer bandbreedte helpt alleen als het knelpunt structureel is. Bij microbursts, lussen of incast verplaatst een snellere link het probleem vaak alleen.
🏭 Hoe pakt u congestie in de praktijk aan?
Een praktische aanpak voor een bestaande installatie:
- Inventariseer de stromen - welke controllers praten met welke I/O, HMI’s en servers, met welke cyclustijd? Zonder dat overzicht is QoS gokken.
- Meet in plaats van te schatten - lees per poort de teller voor output drops, CRC-fouten en broadcastaantallen uit. Een Wireshark-opname via een SPAN-poort of TAP laat zien of er bursts of lussen zijn. Gebruik bij voorkeur passieve monitoring, want actieve scans kunnen zelf congestie veroorzaken.
- Reken de cyclische belasting door - in de PROFINET-ontwerppraktijk geldt een vuistregel: onder 20% cyclische belasting per link is geen actie nodig, tussen 20 en 50% moet u het ontwerp controleren en boven 50% moet de belasting omlaag, zodat er ruimte blijft voor niet-realtime verkeer.
- Ontwerp de topologie - vermijd lange lijnen met veel apparaten achter elkaar, plaats servers en historians buiten de besturingszone en gebruik ringredundantie met een geconfigureerd protocol zodat lussen niet tot storms leiden.
- Configureer de switches - prioriteiten, storm control, IGMP-snooping en uitgeschakelde ongebruikte poorten. Leg die configuratie vast als standaard.
- Plan zware taken - back-ups, firmware-uitrol en historian-synchronisatie buiten productiepieken of via een apart segment.
- Bewaak continu - stel drempelwaarden in voor poortbelasting en drops, zodat u congestie ziet voordat de installatie stilvalt.
Voor Nederlandse organisaties die onder de Cyberbeveiligingswet vallen, past dit bij de zorgplicht om de beschikbaarheid van netwerk- en informatiesystemen te borgen. Congestie is daarbij zowel een ontwerprisico als een aanvalsvector.
🔄 Wat is het verschil tussen congestie, bandbreedtebeperking en jitter?
| Begrip | Betekenis | Typische oplossing |
|---|---|---|
| Congestie | Tijdelijk meer verkeer aangeboden dan een poort kan doorgeven | QoS, segmentatie, storm control, betere verkeersverdeling |
| Bandbreedtebeperking | Structurele limiet van een verbinding, bijvoorbeeld 100 Mbit/s | Snellere link of minder data |
| Latency | De totale vertraging van zender naar ontvanger | Kortere paden, minder hops, snellere links |
| Jitter | Variatie in die vertraging, vaak een gevolg van congestie | Prioriteit, TSN, minder wachtrijvorming |
| Packet loss | Frames die niet aankomen, onder meer door volle buffers | Congestie wegnemen, fysieke fouten herstellen |
❓ Veelgestelde vragen
Kan een netwerk met lage gemiddelde belasting toch congestie hebben?
Ja, netwerkcongestie ontstaat per poort en per moment. Microbursts van enkele milliseconden of veel apparaten die tegelijk naar één server sturen, kunnen een buffer laten overlopen terwijl het gemiddelde over vijf minuten maar een paar procent is.
Lost een snellere switch netwerkcongestie op?
Een snellere switch helpt alleen als de capaciteit structureel tekortschiet. Bij broadcast storms, netwerklussen of ongefilterde multicast groeit het verkeer mee, en bij een overgang van 1 Gbit/s naar 100 Mbit/s blijft de trage poort het knelpunt.
Waarom valt een PLC-verbinding weg bij congestie?
Industriële protocollen zoals PROFINET en EtherNet/IP bewaken de cyclische communicatie met een watchdog. Komen er enkele cycli achter elkaar geen frames aan, bij PROFINET standaard drie, dan verbreekt het apparaat de verbinding en gaan de uitgangen naar hun veilige stand.
Wat is het verschil tussen congestie en een DDoS-aanval?
Netwerkcongestie is het effect: meer verkeer dan het netwerk kan verwerken. Een DDoS-aanval is één mogelijke oorzaak, maar in OT ontstaat congestie vaker onbedoeld, door lussen, back-ups, scans of een defect apparaat.
Hoe meet u netwerkcongestie in een OT-netwerk?
U leest per switchpoort de tellers voor belasting, output drops en broadcasts uit, bijvoorbeeld via SNMP. Een passieve opname via een SPAN-poort of TAP toont vervolgens welke stromen de pieken veroorzaken, zonder extra verkeer op het besturingsnetwerk.
Helpt QoS tegen netwerkcongestie?
QoS voorkomt congestie niet, maar bepaalt wie voorrang krijgt als een wachtrij volloopt. Met prioriteit voor besturingsverkeer blijven PROFINET- en EtherNet/IP-frames aankomen, terwijl een back-up of webverkeer de vertraging opvangt.
📌 Samengevat
Netwerkcongestie ontstaat wanneer een poort tijdelijk meer verkeer krijgt dan zij kan doorgeven; in OT leidt dat via watchdog-time-outs direct tot stilstand.
Congestie is in OT-netwerken een beschikbaarheidsrisico, omdat realtime protocollen geen hertransmissie kennen en bij gemiste cycli de verbinding verbreken. U beheerst het met segmentatie, QoS, storm control, IGMP-snooping, passieve monitoring en een doordacht ontwerp, niet alleen met meer bandbreedte.