Over Arnie

Ik zou aanraden voor een unmanaged switch te kiezen. Zowel Netgear alsook TP-link hebben verschillende modellen. Bijvoorbeeld de Netgear GS316. ... Meer weergeven

Als je tevreden bent met de D-Link DGS 1005D kun je er gewoon nog zo één aanschaffen, en die ook op de HGW aansluiten. Je kunt die dan eventueel op een andere lokatie in je huis plaatsen waar je meerde aansluitingen nodig hebt. Bijvoorbeeld één in de living bij de TV, de ander in de ruimte waar je PC staat. Als ze direkt bij elkaar komen te staan, zou ik persoonlijk de voorkeur geven aan een switch met meer poorten (16 bijvoorbeeld). Dat is meer om esthetische redenen dan om technisch/functionele redenen.   ... Meer weergeven

Bedankt @nickw  Defragmentation en fragmentation zijn wel het tegenovergestelde van elkaar. Foutje in de titel / probleembeschrijving?   Op zich maakt dat wel meer zin. Indien de PS5 grote IP paketten verstuuurd, die door de HGW niet doorgestuurd kunnen worden aan de volgende router (next hop), bijvoorbeeld omdat het tussenliggende medium zulke grote paketten niet ondersteund, dan zijn er twee mogelijkheden voor de router: 1) indien de "do not fragment" bit in het pakket niet gezet is, zal de router de pakketen fragmenteren. 2) indien de "do not fragment" bit wel gezet is in het pakket van de PS5, dan zal de router dit pakket droppen, en naar de verzender een ICMP berichtje sturen om deze hierover te informeren. De hosts (PS5) zal dan moeten weten kleinere pakketen te versturen.   Meer info: https://en.wikipedia.org/wiki/IP_fragmentation   Zoals aangegeven is het misschien het probreren waard de configuratie van de PS5 aan te passen, en de MTU te verlagen. Op die manier zou het mogelijk zijn de PS5 te forceren kleinere paketten te versturen, en zodoende te vermijden dat de router moet fragmenteren. Ik weet echter niet of dit een confgureerbare parameter in de PS5 is. Dit is al meer advanced, en misschien niet mogelijk.   Ik begin langzaam de indruk te krijgen dat de CH8568LG inderdaad wat problemen heeft met fragmentatie. Het is nog een vermoeden, maar er zijn verschillende topics hier op het forum die in die richting duiden. ... Meer weergeven

Dag @Jerry78  Defragmentation in de netwerk wereld wil zeggen het terug samenstellen van een IP paket wat als meerdere fragmenten (stukjes) ontvangen is. De fragmentatie zelf wordt normaal gesproken ergens in het trajekt gedaan door een router, omdat de MTU (Maximum Transmission Unit) op de verbinding geen grote pakketen toelaat. Het grote pakket wordt dan opgedeeld in kleinere stukken, die later door de ontvanger terug samengesteld dienen te worden.   Met andere woorden, de MTU van de PS5 speelt hier geen rol. Het gaat namelijk niet om de grootte van de paketten die de PS5 verstuurd, maar het terug samenstellen van ontvangen pakketen.   Defragmentatie (het terug samenstellen van het pakket) is niet de taak van een router, maar van de ontvangende host. Dit omdat de fragmenten eventueel een andere weg over het internet kunnen nemen, en pas bij de host zelf terug samen op bestemming komen.   Ik denk dat defragmentation in dit geval niets met het netwerk te maken heeft, maar eerder betrekking heeft op de HD van de PS5. Ook hier wordt fragmentatie gebruikt. Een bestand wat op de harde schijf wordt opgeslagen wordt in stukjes opgedeeld, en daar geplaatste waar plaats is. In een speciaal bestand (een database) staat per file beschreven waar zich de verschillende fragmenten bevinden. Ik vermoed dat daar een probleem mee is. Hoe luidt de fout boodschap precies, en wanneer treedt die op?   ... Meer weergeven

Ja, we hebben te weinig informatie om het probleem te kunnen vinden. In eerste instantie was ik meer in de richting van MTU aan het denken. Misschien verzenden de hosts zeer grote pakketen, en verslikt de HGW zich in het fragmenteren. Als de firewall een kleine MTU instelling heeft voor zijn externe poort, zal deze nu al het fragmentatie werk doen, en misschien is deze daar beter in.   Gewoon zomaar een gedacht, maar we zijn aan het gissen, zonder data om echt het probleem te kunnen analyseren.   ... Meer weergeven

De theorie is juist, maar het effect voor de gebruiker zou in dat geval hetzelfde zijn. Het is immers nu niet de CV8560E die crasht of zoiets, het zij de clients die problemen ondervinden in de vorm van latency, wellicht doordat zoals je zegt de NAT router verzadigd raakt, en daarom sessies begint af te blokken, omdat de limitet van 2 x 64K bereikt is. Of dit dan de eigen NAT router (firewall) of de HGW is zou eigenlijk geen verschil mogen geven. ... Meer weergeven

Ik bergijp nu wat je wilde zeggen. De firewall kan max 2 x 64K sessies aanbieden aan de HGW. De afzonderlijke hosts zouden elk afzonderlijk 2 x 64K sessies aan de HGW kunnen aanbieden. Dat is theoretisch correct. Het lijkt me echter onwaarschijnlijk dat er zoveel sessies gelijktijdig aktief zouden zijn. Mochten er effectief zoveel sessies op gezet worden bij direkt verbonden hosts, dan gaat dit ook een probleem op de firewall geven. Die is immers ook beperkt tot 2 x 64K sessies.   Het lijkt me onwaarschijnlijk dat het geheugen van de HGW voor zijn NAT tabel de bottle-neck is. ... Meer weergeven

@Steven-E  schreef: Als er geen NAT gebeurt door een achterliggende firewall moet de Telenet HGW dit ook doen, maar niet voor één IP, maar voor verschillende IP's. Dat is dus voor TCP: 65536 x het aantal interne hosts. Dus het maakt echt wel een verschil Volgens mij niet.   Voorbeeld 1 direct verbonden hosts, die een webserver op het internet aanspreken 1: source 192.168.0.100:50000 destination:www.google.com:80 2: source 192.168.0.101:50000 destination:www.google.com:80 In HGW NAT tabel: source 192.168.0.100:50000 wordt [public-ip]:60000 source 192.168.0.101:50000 wordt [public-ip]:60001 Voorbeeld 2 dezelfde twee hosts, maar nu achter een NAT firewarll, met IP adres 192.168.0.10 1 source 192.168.1.100:50000 wordt in de firewall 192.168.0.10:55000 2 source 192.168.1.101:50000 wordt in de firewall 192.168.0.10:55001 In de HGW vindt opnieuw NAT plaats 192.168.0.10:55000 wordt [public-ip]:60000 192.168.0.10:55001 wordt [public-ip]:60001 In beide gevallen is het resultaat 2 sessies in de NAT tabel van de HGW. In het tweede geval weliswaar beide met hetzelfde source IP adres, maar toch 2 entries. ... Meer weergeven

@Steven-E  schreef: Aangezien je het probleem kan oplossen door er een firewall voor te zetten, zou ik denken in een te kleine NAT tabel van je Telenet HGW.  De NAT tabel van je eigen firewall is wellicht groter dan die van je Telenet HGW.  Dan kan verklaren waarom het even werkt na een herstart van je modem (de NAT tabel is dan nog niet vol gelopen). De CV8560E met mac bridging is dan een goede oplossing. Volgens mij maakt het voor de NAT werking van de HGW weinig tot geen verschil of het verkeer van verschillende hosts afkomstig is, of dat alles van één host (de firewall) komt.Er spelen weliswaar minder unieke IP adressen een rol, het aantal unieke IP+port sessies die in de NAT tabel moeten worden bijgehouden blijft gelijk. ... Meer weergeven

@itractus  schreef: PUMA, NOT SO FAST Geen inhoudelijke reactie op het gebruik van de Puma chipset? Het kan ook goed zijn dat de routing table, of eender welke andere table in de modem vol liep. Ik gebruik mijn netwerk namelijk redelijk zwaar. 'Slechts' 20 clients zorgen toch voor een hoge belasting, zeker aangezien 2 van deze clients, servers zijn. Het feit blijft, dat we GEEN ZICHT hebben over de modem. En dus allemaal in het duister tasten met wat er nu juist mis gaat, ofja, ging.   Of je de clients eerst door een eigen router/firewall stuurt met NAT of niet zou eigenlijk geen verschil mogen maken. Dat heeft in ieder geval geen invloed op de routing table, hooguit de ARP tabel, maar dat zou toch echt geen probleem mogen vormen.   In een setup met lokaal verbonden clients zullen de verschillende gebruikers in de ARP tabel verschijnen van de HGW met hun IP adres (192.168.0.0 /24 subnet) en hun MAC adres. Als het verkeer eerst door je firewall passeert en NAT ondergaat zal de ARP tabel maar uit één enkel ip en mac adres bestaan. Dat is immers de werking van NAT. Het source adres in de IP header wordt vervangen met dat van de firewall. De HGW zal denken dat al het verkeer afkomstig is van één host. De HGW zal zelfs niet kunnen weten dat deze host eigenlijk een firewall/router is.   Met ~20 hosts zou dat echt geen probleem mogen vormen.   ... Meer weergeven

@itractus, ik kan ook niet helemaal volgen. Je hebt nu een firewall/router aangesloten op de HGW. Dat wil zeggen dat er niet langer meerdere hosts direct op het LAN verbonden zijn, maar dat nu alles via één firewall verloopt. Het verkeersaanbod is echter niet veranderd, enkel dat het nu via één router/firewall komt. Fijn natuurlijk dat het probleem zich hiermee oplost, maar de oorzaak is eigenlijk nog altijd niet duidelijk.   Het zou interessant zijn geweest om een packet-trace (wireshark / tcpdump) te zien, om te kijken wat er juist fout gaat op het netwerk. ... Meer weergeven

Controlleer zeker even of de email wel echt van Telent afkomstig was (bekijk ook even de full header). Waarschijnlijk is het fishing; ze lokken je naar een website (die op Telenet lijkt), waar ze je gebruikersnaam en wachtwoord zullen vragen.   Klik niet op een link in de email, maar bezoek webmail via de link https://webmail.telenet.be/     ... Meer weergeven

Als er nu analoge TV binnenkomt via de kabel (ongeacht eigenlijk of het om een multi- of gewone-aansluting gaat), dan zal normaal digitale TV via een CI+ kaartje werken. Je CI+ kaartje op je hoofdadres regstreren, maar op een ander adres gebruiken, is natuurlijk niet conform de Telenet regels, maar zal technisch wel werken. ... Meer weergeven

Kun je nog eens je setup toelichten? Je hebt een Telenet HGW, met op de LAN het 192.168.0.0 / 24 subnet? Welk type HGW van Telenet heb je? Daarachter heb je nog een eigen router? Waar bevind zich de bewuste server? Bevind deze zich gewoon in het LAN van de Telenet HGW (welk jij dan DMZ noemt) ?   Indien je via port 443 de interface (WAN) van je firewall wilt benaderen, dan kijk je best ook even de settings van die firewall na. Vaak laten die enkel lokale connecties toe (dus afkomstig vanaf een IP adres binnen hetzelfde subnet als de interface).   ... Meer weergeven

Heeft de server wel internet toegang / kun je vanaf de server zelf het internet bereiken? Mocht er bijvoorbeeld geen (default) route ingesteld zijn, dan kan de server enkel met het lokale IP subnet communiceren.   ... Meer weergeven