Skip to main content

Hallo,

Sinds enige tijd al heb ik IPTV (vip5202) via een SLM2008 switch (met IGMP snooping). Werkte redelijk, maar toch wel vaak het bekende blauwe beeld. Nu sinds gisteren heb ik een Netgear GS108E eraan gehangen. Deze lijkt het een stuk beter te doen, alleen op de poort naar de vip5202 zie ik vele CRC errors voorbij komen. Ethernet kabel vervangen, maakt niets uit. In een uur pakt hij zo 900 CRC errors op, terwijl de KPN ontvanger uit staat.

Is dit normaal gedrag, of moet ik nog eea aanpassen? Op de Netgear staat igmp snooping enabled, geen vlan ingevuld, Validate IGMPv3 IP Header disabled en ook Block Unknown Multicast Address op disabled.

CRC errors kunnen ontstaan door verschillende oorzaken. Wat gemeenschappelijk is, dat de ontvangen data anders is dan de verzonden data, dus er is iets afgegaan of bijgekomen.

Veelal is het een hardware error, dus een slechte kabel (heb je al vervangen) een slechte poort op de switch of op het apparaat aan de andere kant van de kabel. Verhuist de error mee als je de kabels op andere poorten aansluit?

Soms is het een software issue, dus je hebt misschien de switch (de genoemde settings staan goed) al naar de laatste firmware gezet (https://www.netgear.com/support/product/GS108Ev3.aspx#download)  en naar fabrieksinstellingen teruggezet.

Of bij iets in je netwerk staat de packet size niet standaard of jumbo frames staat anders.

Heb je de kabeltest geprobeerd?

Het kan zeker goed zijn, ik heb 4 netgearGS108EV3 in huis en er is er niet een met ook maar 1 crc error.

 


Voor mij was het CRC errorstroom-fenomeen ook "nieuw", op de oude switch nooit gezien. Firmware kwam als "latest” uit de doos (en is een GS108Ev3).

Wat stom dat ik wel de kabel, maar nog niet de poort heb veranderd. Zojuist poort 1 naar poort 8 gezet, vip5202 uit en weer aangezet en nu lijkt het allemaal zonder CRC errors te verlopen. Voorheen per 5 minuten 50 CRC errors, nu al een minuut of 5 foutloos. Ik ben voorzichtig positief ;)

Gloednieuwe Netgear, dus ik ga er wel eens iets anders aanknopen aan die poort 1 en kijken of die ook CRC errors genereert. Zo ja → > omruilen die hap.

Bedankt voor het snelle antwoord!


Gloednieuwe Netgear, dus ik ga er wel eens iets anders aanknopen aan die poort 1 en kijken of die ook CRC errors genereert. Zo ja → > omruilen die hap.

Bedankt voor het snelle antwoord!


Verwisseling van poort zegt helemaal niets over de betrouwbaarheid van een Netgear switch op zich.

Als contacten van een poortje wat zijn vervuild, zou simpelweg eruit halen van een plug, en opnieuw terugsteken in de poort, contacten voldoende kunnen zijn “schoon geschraapt”, dat de balans erna
“wel voldoende” is voor een goede connectie.

Niks nieuws. Dat heb ik eerder bij netwerkbeheer ook wel meegemaakt.

Benut beter de “kabel test” utility wat onderdeel uitmaakt van de gebruikersinterface van zo'n Netgear switch. Kom je erachter of je ethernetkabels überhaupt wel voldoen.

Die meet demping (bijv. bij CCA) en elektromagnetische interferentie (overspraak) van kabels.
Een uiterst nauwkeurige en betrouwbare analyse. Te vergelijken met kostbare netwerk meet apparatuur (Fluke). Alleen zonder grafische voorstelling met grafieken en meetgegevens in detail. Gewoon goed of slecht (dat het niet voldoet).

Er is tegenwoordig zoveel rotzooi aan kabels in omloop, dat het meer uitzondering lijkt gaan te worden dat je “toevallig” goede kabels gebruikt, dan dat het “voorwaarde” is om ermee te starten.

Dus begin eens daarmee, in de plaats van “omruilen die hap”.


Nou ja, intussen al meerdere malen meerdere UTP kabels in en uit poort 1 gehaald. Kabel tests komen allemaal terug als OK. Maar poort 1 blijft CRC errors geven.

 

Ik heb al veel te vaak veel te veel uren besteed aan dit soort vage dingen. Dus toch echt een gevalletje "omruilen die hap”.


Ondanks wel een goede kabel, als die “OK” geeft.
Zou het best ook de “toevoer kunnen zijn” vanuit een ander apparaat naar die poort 1  ??

Zolang iets “vaag” blijft, en je niet daadwerkelijk kunt traceren of achterhalen wat de oorzaak is.
Is elke suggestie een willekeurige slag in de ruimte.

Het gaat er juist om dat je testen uitvoert in een zodanig logisch “aansluitschema” met afkoppelen of juist aankoppelen van bepaalde apparaten, dat je met “zekerheid” weet wat het probleem is.


Als dezelfde kabel, met hetzelfde apparaat op poort 1 errors geeft en op poort 8 niet, dan zou ik hem ook omruilen.


Ook dat is te traceren.  Dat soort “vreemde” situaties kan ik hier ook erg simpel simuleren.

Omdat het om een managed switch gaat, zou het bijv. ook aan instellingen kunnen liggen die in een managed switch zijn vastgelegd, voor de ene of andere poort. Daar is geen enkele info over gegeven.
Ook (bij uitzondering) toevallige afwijkingen van instellingen kunnen dat veroorzaken.

Complete fabrieksreset, controleren of er firmware updates zijn.
Allemaal zaken die je eerst zou kunnen controleren.

Zolang iets “vaag” blijft, en je niet daadwerkelijk kunt traceren of achterhalen wat de oorzaak is.
Is elke suggestie een willekeurige slag in de ruimte.


Ja precies dit dus hierboven. Ik kan uren spenderen om te gaan traceren waar het probleem ligt. Of gewoon de switch omruilen. Heb helemaal geen tijd of zin om een quasi-DOA te gaan analyseren, zeker niet een gloednieuw device van 4 tientjes.

 

Poort 1 geeft CRC errors met diverse kabels naar diverse devices. CRC errors uit een instelling lijkt me onwaarschijnlijk. Poort fixen op snelheid ook nog geprobeerd trouwens. Analyse genoeg vind ik ;)


CRC errors uit een instelling lijkt me onwaarschijnlijk…..

En waar baseer je dat op??  Heb je de instellingen nagelopen dan?
Ook (bij uitzondering) toevallige afwijkingen van instellingen kunnen dat veroorzaken.
Zoals voorgesteld fabrieksreset, controleren of er firmware updates zijn??

Je kunt een switch terugsturen voor een ander, is het maar de vraag of het is opgelost?

Zolang iets “vaag” blijft, en je niet daadwerkelijk kunt traceren of achterhalen wat de oorzaak is.
Is elke suggestie een willekeurige slag in de ruimte.