~2000 ARP boadcasts per minuut, normaal?

[Toon83]

Beste Tweakers,

Bij een bedrijf van een vriend is een project met accu's gerealisteerd, en toen ik daar langs ging om het te bekijken viel het mij op dat alle lampjes van alle switches wild stonden te knipperen.
Hierna maar even Wireshark op een computer geinstalleerd, en nu zien we (filterend voor ARP) het volgende:

Ongeveer 2000 ARP broadcasts per minuut afkomstig van de accu paketten.
Het bedrijf verantwoordelijk voor de aanleg reageert nogal laconiek met: "joh, niks om je druk over te maken, het werkt toch gewoon?" en "het volume hiervan zou niet direct een probleem moeten zijn voor het netwerk".

Heeft de aanleggende partij hierin gelijk?
Ik ben zelf zeer sceptisch, maar ik heb helaas te weinig ervaring om dit goed te kunnen duiden.

[ Voor 18% gewijzigd door Toon83 op 22-10-2025 16:38 ]

[.Maarten]

Nee dat is niet goed. Niet zozeer die ARP broadcasts maar meer dat het erop lijkt dat IP adressen niet uniek zijn binnen het netwerk en dat is niet goed.

[Boudewijn]

ARP wordt gebruikt om IP-adressen in MAC-adressen om te zetten. Ik weet niet precies wat hier gebeurt, maar je zou eens kunnen kijken naar de IP-nummering van je devices.... het hebben van devices met hetzelfde IP-adres is een recept voor puinzooi.

Mogelijk heeft je ARP-storm hier ook wat mee te maken. Qua traffic zal het wel meevallen maar dit is natuurlijk echt niet hoe het hoort. (in principe zal je OS een ARP-cache hebben en daarin eerst opzoeken of het MAC-adres al bekend is).


Als ik even kijk zie ik sungrow-power _b1:29:fb , b1:53:5e en b0:89:de al op hetzelfde IP zitten. Dat is niet best. Wat is ip-adres 192.168.1.1 trouwens? Een gateway?

[ Voor 14% gewijzigd door Boudewijn op 21-10-2025 21:51 ]

[Ben(V)]

Een ARP brodcast storm word meestal door ofwel een loop ofwel een dubbel IP-adres veroorzaakt.
En aangezien jouw filmpje aangeeft dat er een heleboel duplicate ip adressen zijn zal het wel een netwerk loop zijn.

Vaak veroorzaakt doordat een device zowel via wifi als via kabel aan het netwerk hangt.

[ Voor 52% gewijzigd door Ben(V) op 22-10-2025 11:30 ]

[mash_man02]

Ben(V) schreef op woensdag 22 oktober 2025 @ 11:28:
Een ARP brodcast storm word meestal door ofwel een loop ofwel een dubbel IP-adres veroorzaakt.
En aangezien jouw filmpje aangeeft dat er een heleboel duplicate ip adressen zijn zal het wel een netwerk loop zijn.

Vaak veroorzaakt doordat een device zowel via wifi als via kabel aan het netwerk hangt.

Dat zou men redelijk makkelijk moeten kunnen constateren dan is het ip terug te herleiden naar een machine waarvan de duplicates op basis van de Mac adressen van de netwerk interfaces van dit ene device zijn.

Dat zou wel heel knullig geschreven software moeten zijn maar ook dat is niet uitgesloten.

[ Voor 6% gewijzigd door mash_man02 op 22-10-2025 11:35 ]

[Ben(V)]

Maar een netwerk lus zie daar niet aan en dat is het meest waarschijnlijk want hij heeft veel duplicate adressen waaronder 192.168.1.1 wat vermoedelijk de router en gateway is en dus erg onwaarschijnlijk dat hij die twee keer heeft.

[ Voor 16% gewijzigd door Ben(V) op 22-10-2025 11:38 ]

[Freeaqingme]

Ik zou niet per se focussen op het aantal ARP pakketjes. Afhankelijk van hoe groot je L2 domein is kan dat best. Maar, dat Wireshark die 'duplicate use ... detected'. Dat lijkt me wel iets om even in te duiken.

[jadjong]

Trek de netwerkstekker maar uit die accu, als het dan stopt kan je verder zoeken.

[dehardstyler]

Toon83 schreef op dinsdag 21 oktober 2025 @ 21:34:

Heeft de aanleggende partij hierin gelijk?
Ik ben zelf zeer sceptisch, maar ik heb helaas te weinig ervaring om dit goed te kunnen duiden.

Vraag even of de man aan de telefoon zijn auto aan kan wijzen en trap daar vervolgens een deuk in. Daarna vertel je hem dat de auto nog werkt en kijken we even of hij toch nog iets geleerd heeft op latere leeftijd.

Nee dit is niet normaal. En lijkt zoals de andere zeggen inderdaad een dubbel gebruikt IP adres te zijn, zoals ook Wireshark al aangeeft.

[ Voor 12% gewijzigd door dehardstyler op 22-10-2025 12:38 ]

[EverLast2002]

"Max challenge attempts exceeded. Please refresh the page to try again!"

ik zie geen filmpje of afbeelding in de openingspost......

[Toon83]

EverLast2002 schreef op woensdag 22 oktober 2025 @ 16:29:
"Max challenge attempts exceeded. Please refresh the page to try again!"

ik zie geen filmpje of afbeelding in de openingspost......

Vreemd, het filmpje heeft momenteel 12 views en verloopt pas over ongeveer 29 uur. Ik kan het nog gewoon bekijken. Maar ik heb de openingspost inmiddels aangepast en een foto bijgeplaatst.

[Toon83]

Maar inmiddels ben ik er weer even langs gegaan om de situatie wat beter te inventariseren.
Op het netwerk van het bedrijf zelf worden IP-adressen in de 192.168.0.x range gebruikt.
Als we de UTP kabel die naar de accupakketten gaat loskoppelen dan wordt het weer rustig op het netwerk.
Als we deze kabel daarna in een laptop stoppen zien we in Wireshark weer precies hetzelfde als in bovenstaand filmpje / op de foto.
De inloggegevens van de "controllers" van de accupakketten worden niet verstrekt. We kunnen zelf dus niet naar de instellingen van die accupakketten kijken.

Maar nu het volgende wat ik zelf nog het meest raar vind. De "controllers" (bij gebrek aan een beter woord) van de accupakketten hebben 4 netwerkpoorten. NET1 t/m NET4. In NET1 zit in elke kast een netwerkkabel die verbindt met alle andere sensoren en apparaten in het accupakket. Tot zover nog niet echt iets raars. Maar dan zit bij kast 1 in NET2 de inkomende UTP-kabel voor de netwerkverbinding, en dan zit in NET3 een UTP kabel die verbindt met NET2 van kast 2, en dan zit in NET3 van kast 2 weer een UTP kabel die verbindt met NET2 van kast 3, etc, etc, etc.

Bij navraag waarom dit zo is aangesloten wordt gezegd dat deze manier van aansluiten gebruikelijk is voor industriële busnetwerken. (Is dit überhaupt een argument?) En op de vraag waarom niet alles direct op een switch wordt aangesloten zoals gebruikelijk bij een stertopologie, wordt beweerd dat dit absoluut niet zou kunnen werken (iets met master en slave). Zou hier een kern van waarheid in kunnen zitten, of zegt de aanleggende partij zomaar wat?

[M2M]

Een netwerkkabel of netwerkconnector is uiteindelijk ook maar een connector. Daar kan best wel een ander protocol over heen gaan dan wat jij momenteel aanneemt als "standaard ethernet". En dan heb je inderdaad soms, afhankelijk van het protocol, te maken met rechtstreekse connecties tussen twee poorten van beide systemen. Mocht je er een switch tussen hangen, kan het zelfs zijn dat er rook uit de switch (of controllers) komt.

Dat ze de inloggegevens niet verstrekken vind ik dan wel weer raar. Als je iets 'koopt' ben je in principe 'eigenaar' en zou je in mijn optiek volledige toegang moeten kunnen krijgen tot alle configuratie.

[EverLast2002]

@Toon83

hoe zit alles aan elkaar verbonden, je vermeldt netwerk switches maar ook dat de accu's onderling zijn doorgelust.
Kun je een simpele schets/tekening posten?

[Croga]

M2M schreef op woensdag 22 oktober 2025 @ 16:49:
Dat ze de inloggegevens niet verstrekken vind ik dan wel weer raar. Als je iets 'koopt' ben je in principe 'eigenaar' en zou je in mijn optiek volledige toegang moeten kunnen krijgen tot alle configuratie.

Dat zijn het soort configuraties die zaken in brand kunnen zetten. Laten we daar alsjeblieft niet iedere tom dick en harry de gegevens van geven.

[FredvZ]

Toon83 schreef op woensdag 22 oktober 2025 @ 16:45:
Bij navraag waarom dit zo is aangesloten wordt gezegd dat deze manier van aansluiten gebruikelijk is voor industriële busnetwerken. (Is dit überhaupt een argument?) En op de vraag waarom niet alles direct op een switch wordt aangesloten zoals gebruikelijk bij een stertopologie, wordt beweerd dat dit absoluut niet zou kunnen werken (iets met master en slave). Zou hier een kern van waarheid in kunnen zitten, of zegt de aanleggende partij zomaar wat?

Je ziet het inderdaad vaker in industriële omgevingen dat er een daisy-chain wordt gemaakt, deels uit gewoonte, deels door gebrek aan kennis. Zeker als er een ooit een overstap is gemaakt van Modbus/RS485 zie ik vaker dat de werking van Modbus-over-TCP niet goed begrepen wordt.
Mogelijk is dat hier ook aan de hand en beseft men niet eens dat alle apparaten allemaal met hetzelfde IP-adres werken: "Want we gebruiken Modbus, en het werkt, dus het het zal wel goed zijn."

Maar voordat je nu heel veel tijd hierin gaat steken:
- Wiens probleem los je op? (Is er überhaupt een probleem? Don't fix it if it ain't broken)
- Wat schiet je vriend hiermee op?
- en als er al een probleem is, waarom zou jij het dan moeten oplossen?

[Toon83]

Er is een 5 poorts unmanaged TP-Link switch, die switch verbind met een router en vanuit die switch gaat er een kabel naar een computer, een access point, internetradio en dus ook een kabel naar de accupakketten.
En vanaf daar is het switch-kast1-kast2-kast3-kast4-etc.

Voor zover ik kan zien zijn alle kasten met accupakketten identiek, maar zeker weten doe ik dit niet.
Maar dan zegt mijn boerenverstand, als NET2 van kast 1 gewoon op een ethernet switch kan worden aangesloten, dan moet NET2 van kast 2 toch ook gewoon op een ethernet switch kunnen worden aangesloten? Met dat daisy chainen creëer je dan toch alleen maar extra punten waarop dingen fout kunnen gaan?

Nog wel het volgende gevonden in een handleiding:

[BCC]

Mijn accu’s van goodwe gebruiken ook utp om te daisy chainen maar daar gaat zeker geen tcp ip overheen. Hang er een nat router tussen met een extern ip wat niet conflicteert en bob is your uncle.

[FredvZ]

Toon83 schreef op woensdag 22 oktober 2025 @ 17:14:
Voor zover ik kan zien zijn alle kasten met accupakketten identiek, maar zeker weten doe ik dit niet.
Maar dan zegt mijn boerenverstand, als NET2 van kast 1 gewoon op een ethernet switch kan worden aangesloten, dan moet NET2 van kast 2 toch ook gewoon op een ethernet switch kunnen worden aangesloten?

Die kans is inderdaad heel groot, al lost het niet het probleem van de vele ARP-berichten op.

Met dat daisy chainen creëer je dan toch alleen maar extra punten waarop dingen fout kunnen gaan?

Dat klopt.

[nooberke]

Toon83 schreef op woensdag 22 oktober 2025 @ 17:14:


Nog wel het volgende gevonden in een handleiding:

Staan daar toevallig ook niet de default credentials in? Zou er niet raar van opkijken als je daar mee kan inloggen op de interface

[Toon83]

nooberke schreef op woensdag 22 oktober 2025 @ 17:32:
[...]


Staan daar toevallig ook niet de default credentials in? Zou er niet raar van opkijken als je daar mee kan inloggen op de interface

De standaard credentials staan zelfs op de loginpagina van zo'n accupakket. Maar helaas, die zijn aangepast.

[M2M]

Croga schreef op woensdag 22 oktober 2025 @ 17:07:
[...]

Dat zijn het soort configuraties die zaken in brand kunnen zetten. Laten we daar alsjeblieft niet iedere tom dick en harry de gegevens van geven.

Als de installateur al niet eens weet hoe hij op een fatsoenlijke manier ip adressering uitvoert, zou ik meer vertrouwen hebben in mijn eigen config skills met een gedegen fabrikanthandleiding dan de zogenaamde installateur...

[MasterL]

Denk dat er wat weinig info is om hier serieus een conclusie aan te verbinden:
1: Er zijn accu-packs (ofzo) die een daisy-chain constructie hebben.. Dit zegt niet zoveel
kijk eens naar een SAS (JBOD) aansluitschema of een switch stack schema..
Dit lijkt niet logisch in een ster netwerk configuratie maar is erg logisch in andere configs, het lijkt in die zin meer op een ring netwerk. Elke kast aansluiten op ethernet/IP kan maar dan heb je weer een failover protocol nodig (VRRP/CARP ofzo) en is misschien gewoon de moeite niet waard als de communicatie op "IP" niveau niet mission critical is (alleen wat stats/config werk bijvoorbeeld). Dit is wel gokwerk maar ik kan mij best voorstellen dat het zo zou kunnen werken.

Ik struikel wel een beetje over de IP-adressering je schrijft over een 192.168.0.x (subnet?) netwerk
maar ik zie ARP requests met een SRC van 192.168.1.x en 192.168.13.x hoe groot is je lokale subnet dan wel niet? Als ik dan lees dat er een " 5 poorts unmanaged TP-Link switch" in gebruik is lijkt me dit ehm apart.
Ik verwacht geen noodzaak voor een </24 netwerk.
Dus welke subnets zijn daadwerkelijk in gebruik of zitten er meerdere subnets in 1 L2 domain (LAN/VLAN?)

Buiten dat is ARP met dat betreft natuurlijk een beetje aan apart protocol, een implementatie kan elke seconde een "gratuitous arp" versturen als het daar zin in heeft (zie je vooral in HA setups) en/of arp poisoning danwel bewust of conflicterende IP's.

[jeroen3]

Kan het zijn dat er een MAC adress duplicate is?

[Toon83]

Ik vrees dat de situatie veel te complex wordt voorgesteld. Het bedrijf waar dit wordt gerealiseerd is geen IT bedrijf, dit is een bedrijf in de agrarische sector met een paar computers, accesspoints en beveiligingscamera's. Er zijn geen meerdere subnetten. Er staat een router die DCHP gebruikt met IP-adressen in de 192.168.0.x range. En als er ergens meerdere netwerkpoorten nodig zijn dan gaat er vanuit de router een kabel naar een switch. En that's it. Het is veel meer te vergelijken met een thuissituatie.

En dan wordt er een project met accu's gerealiseerd, de aanleggende partij vraagt of er ergens een vrije netwerkpoort voor internet beschikbaar is, en daar pluggen ze een kabel in. En daarna wordt aan mij gevraagd of ik even langs wil komen, want "er lijkt iets aan de hand te zijn met het internet / het netwerk". (Ik was daar natuurlijk niet geheel toevallig, al ben ik zelf helaas ook geen netwerk Guru.)

Al die IP-adressen en subnetten wat te zien is in Wireshark zijn afkomstig van die accupakketten. Maar het is voor mij dankzij dit topic inmiddels al een stuk duidelijker wat er speelt. Al kan ik zelf nu ook niet meer zoveel doen en zijn we afhankelijk van de aanleggende partij.

FredvZ schreef op woensdag 22 oktober 2025 @ 17:08:
Je ziet het inderdaad vaker in industriële omgevingen dat er een daisy-chain wordt gemaakt, deels uit gewoonte, deels door gebrek aan kennis. Zeker als er een ooit een overstap is gemaakt van Modbus/RS485 zie ik vaker dat de werking van Modbus-over-TCP niet goed begrepen wordt.
Mogelijk is dat hier ook aan de hand en beseft men niet eens dat alle apparaten allemaal met hetzelfde IP-adres werken: "Want we gebruiken Modbus, en het werkt, dus het het zal wel goed zijn."

Bovenstaande bericht van FredvZ slaat volgens mij de spijker op zijn kop. Het grootste probleem zit momenteel dus vooral in de partij verantwoordlijk voor de aanleg duidelijk maken dat er iets fout zit in hun configuratie en dat dit opgelost moet worden.

"Joh, het werkt toch gewoon?" "Volgens ons heeft dit echt helemaal geen nadelige effecten." "Kan het oplevercontract niet getekend worden?"

Dit soort werk, compleet onprofessioneel. Het is vooral heel erg treurig. De fabrikant van de accupakketten zit in China en deze verzorgt blijkbaar ook de configuratie, de fabrikant communiceert alleen met dealers. De aanleggende partij is een dealer. De aanleggende partij heeft qua netwerken blijkbaar geen idee waar ze mee bezig zijn. En puntje bij paaltje wijzen ze naar China. Het is een lekkere soap, ik zal jullie wel op de hoogte houden.

[jadjong]

Gezien je lokale range van 0.x en de conflicten in de 1.x en 13.x mag de accu-knoeier even terugkomen om op zijn minst de apparaten ieder een uniek IP te geven. Ook al doen die IP's niets functioneels.

[MasterL]

De situatie is niet complex maar op afstand (lees op een forum) troubleshooten met te weinig informatie wel.
ik ben denk ik wel met je eens dat waarschijnlijk de boel niet goed geconfigureerd is maar een simpele vraag over welk subnet je gebruikt blijft onbeantwoord.

192.168.0.x is geen subnet:
192.168.0.x/24 = 192.168.0.0 - 192.168.0.255
192.168.0.x/20 = 192.168.0.0 - 192.168.15.255

In het eerste geval (/24) zijn er IP-adressen in je L2 domein (LAN/VLAN) die daar niet thuishoren want we zien requests van 192.168.1.x en 192.168.13.x. In het geval je /20 gebruikt kan dit prima.
Oké dan gebruik je een achterlijk groot subnet voor de situatie maar is technisch niet incorrect.
Als ik de netwerkbeheerder zou zijn van wat voor netwerk dan ook zou ik van tevoren vragen:
1: Hoeveel devices worden er aangesloten en hoeveel IP-adressen heb je nodig?
2: Welke poorten/services moeten er open staan in de firewall?

Als je deze vragen stelt hou je automatisch een beetje controle niet perse technisch wat natuurlijk niet kan in deze situatie met deze apparatuur maar dan wel een reden om een fatsoenlijke configuratie af te dwingen en/of te kunnen controleren. En uiteindelijk dus geen oplevering tekenen mits niet oké.

Tevens als je gebruik wil maken van de kennis op het forum is het ook handig om te problemen te omschrijven:

Toon83 schreef op donderdag 23 oktober 2025 @ 14:26:
En daarna wordt aan mij gevraagd of ik even langs wil komen, want "er lijkt iets aan de hand te zijn met het internet / het netwerk". (Ik was daar natuurlijk niet geheel toevallig, al ben ik zelf helaas ook geen netwerk Guru.)

Dit hele topic is gebaseerd op de ARP requests terwijl er wellicht nog 100.000 dingen aan de hand kunnen zijn. Ik kom terug op mijn eerste zin.. Dit is heel lastig meedenken zo. Als je echt advies of wellicht een oplossing wil van netwerk Guru's waar ik mijzelf even heel bescheiden onder reken is er toch echt wat meer info nodig. Zo niet wens ik je veel succes met de leverancier

[ Voor 25% gewijzigd door MasterL op 24-10-2025 10:35 ]

[Toon83]

Er wordt gebruikt gemaakt van 192.168.0.x/24 = 192.168.0.0 - 192.168.0.255 en niet van een achterlijk groot subnet.

Na de vele reacties in dit topic ben ik er zelf inmiddels ook achter dat de ARP broadcasts niet de kern van het probleem zijn. Maar dit was gewoon hetgene wat mij opviel.

Bij de aanleg van de installatie werd er om 25 vaste IP-adressen gevraagd. Om hiervoor plek te maken is de DHCP-scope verkleind zodat deze vaste IP-adressen er buiten zouden vallen.

Er zijn 2 groepen met 9 accupakketten, en iedere groep heeft een management systeem.
Management systeem 1 zit op 192.168.0.21, accupakketten 1 t/m 9 zitten op 192.168.0.22 t/m 192.168.0.30.
Management systeem 2 zit op 192.168.0.31, accupakketten 10t/m 18 zitten op 192.168.0.32 t/m 192.168.0.40.

Om je een idee geven, dit is zo'n accupakket: https://nl.sungrowpower.com/productDetail/3053
En daar dus 18 stuks van. En hoe deze accupakketten intern zijn geconfigureerd zou ik zelf ook wel heel erg graag willen weten, maar deze informatie is voor mij niet beschikbaar.

Maar als ik je goed begrijp dan moet de leverancier er nu dus voor gaan zorgen dat we geen enkel request van 192.168.1.x en 192.168.13.x meer zullen zien op ons netwerk?

Mocht je nog meer vragen hebben dan zal ik deze echt zo goed mogelijk proberen te beantwoorden, maar het grootste probleem is momenteel volgens mij de leverancier.

[jadjong]

Ergens in deze stapel accu's heeft iemand niet begrepen hoe IP werkt en alle accupacks of controllers op hetzelfde IP gezet.

Overview
The UMCG is designed with two network ports NET1 and NET2.
• Default IP address of NET1: 192.168.0.100
• Default IP address of NET2: 192.168.13.127
Access the WEB interface through the NET1 port by default


Geen idee of er ook een UMCG geinstalleerd is, maar subnet 13.x is geen vreemde voor Sungrower.

[Damic]

Na al de reacties enzo te lezen zou het me niet verbazen als er ergens 1 netwerk kabel verkeerd steekt, waardoor al het verkeerd van de overige accu pakketten verkeerd loopt, zoals @jadjong aanhaalt.

Net1 = netwerk van klant
Net2 & 3 = netwerk accu pakket
Net4 = ????condensator pakket????

[ Voor 7% gewijzigd door Damic op 25-10-2025 18:06 ]