Ziggo Router gebridged naar rt2600ac, internet snelheid lager?

[mkoekoek]

@Babylonia

Dank voor de reactie.

Maar het niet DHCP zijn van de RT2600 zal niet van invloed zijn op de snelheid van het dataverkeer.
De RT2600 DHCP server maken zal eerder de situatie verslechteren omdat het DHCP zijn van de RT2600 resources van de RT2600 gebruikt die dan niet beschikbaar zijn voor andere services.

Groet,

MKK

[Babylonia]

@Babylonia
Maar het niet DHCP zijn van de RT2600 zal niet van invloed zijn op de snelheid van het dataverkeer.

Dat weet je niet, want je hebt het gewoonweg nog niet geprobeerd.

Achterliggend worden in routers in zijn algemeenheid wel vaker zaken aan elkaar gekoppeld m.b.t. andere functies in die router, waardoor er een in die samenhang ineens onderdelen ontbreken om in het juist algoritme afgepaste snelheden te waarborgen, als je gedeeltelijk functies niet door diezelfde router laat uitvoeren maar door andere apparaten laat afhandelen. Ook al zou dat volgens de gebruikelijke netwerk conventies "officieel" moeten werken. Ik heb al te vaak gezien dat allerlei officieel uitgedachte functies met verschillende apparaten het in praktijk niet als zodanig werkt, en de beste waarborg voor een optimale werking is, om "routerzaken" gewoon in één apparaat te regelen.

Gewoon even uittesten kan nooit kwaad.
Het biedt je in ieder geval meer inzicht in het isoleren van je probleem van die verkeerde snelheid, welke uitkomst er ook uitkomt.

[pvkan]

@mkoekoek

fyi:
Aan je aansluiting ligt het niet in ieder geval.
Al je kanaal waardes (DocSis 3.x) zijn super.

Downstream signal to Noise Ratio (SNR) ligt prima binnen de tolerantie (>35 dBmV). Je zit wel aan de onderkant van de tolerantie maar dat zal de performance niet beinvloeden. Dan moet je echt onder die 35 zakken.

Upstream Power tolerantie = 32 dBmV - 50 dBmV. Met waardes rond de 41 zit je perfect.
Pas bij 52 dBmV begint het modem kanalen te verliezen.

Peter

[Ben(V)]

Aan wie DHCP server is kan het nooit liggen.
Als je een ip-adres krijgt van de DHCP server werkt het gewoon en verder doet DHCP helemaal niet mee in het snelheid verhaal.
In professionele omgevingen is de DHCP server nooit een router, dat is door de leveranciers van consumentenspul er voor het gemak maar bij in gestopt.

Je zou even een PC rechtstreeks aan je Ziggo modem moeten hangen en kijken of je dan nog te lage snelheid hebt.
Als dat het geval is ligt het gewoon aan Ziggo die niet levert waar je voor betaalt en moet je gewoon hun helpdesk bellen.
Overigens lijkt me dat het meest waarschijnlijke.

[pvkan]

Eens met @benv

Gezien je snelheden lijkt het er meer op dat je signaal wordt afgeknepen in de centrale.
In dat geval komt Ziggo zijn leveringsverplichting niet na !
De verkregen snelheden vallen ver buiten de marge...

Peter

[mkoekoek]

@benv en @pvkan

Dank voor jullie reacties. Nee wie de DHCP is, is hier geen issue.
Natuurlijk goed bedoelt advies van Babylonia, maar in dit geval niet relevant.

Het meest frustrerends is dat ik als netwerkbeheerder werkzaam ben, en het oplossen van dit soort problemen dagelijkse kost is.
Ik heb inmiddels even een laptop (HP Elitebook) met 1Gbps NIC en Cat 6 ethernet kabel direct aan de CB van Ziggo gehangen.

Best wel ff de CB uit gehad maar dat wil ook weer niet erg lukken. Ik krijg dan amper 200Mbps als max download (180-195)
Upload zit achter in de 30.

M.a.w. alles wijst wel in de richting Ziggo. Maar daar zit dan ook gelijk het probleem in de hele problematiek.
Bellen heeft niet veel zin, dat is nu al twee keer gedaan en dan blijft het erbij dat op afstand gekeken wordt en dat de waardes in het modem goed zijn en dat de verbinding TOP is.
Monteur ter plaatste meet de lijn en zegt dat signaalsterkte eigenlijk hoger is dan gebruikelijk.
Die heeft destijds, 3 à 4 weken terug, het technicolor modem voor de CB verwisseld.
Toen was de snelheid met de zelfde laptop er direct aan net aan 300Mbps. Dat was voor 1 oktober en dus de maximaal beschikbare snelheid.

Ik zit in (oud) Ziggo gebied, en daar zijn nog even, t/m ongeveer 6 oktober 2017 problemen geweest met de 400Mbps.
Maar dat zou nu dus ook al lang verholpen moeten zijn. Zie ook Ziggo community hier over.

Maandag nog maar weer eens bellen, en ik zal nog voor die tijd een vraag op de Ziggo community plaatsen, direct aan de moderator van dit topic. Dat werkt soms beter ;-)

Inmiddels ook reactie van Synology support, om de secondary WAN (LAN!) poort te gebruiken.....
Mooi klusje voor morgen :-) Weet nog even niet hoe ik dat zou moeten toepassen....

Zodra er nieuws is zet ik dat hier weer neer, mocht er nog iemand een gelijke ervaring hebben en liefst ook een oplossing daarvoor, dan graag natuurlijk.

Mart

[Birdy]

Inmiddels ook reactie van Synology support, om de secondary WAN (LAN!) poort te gebruiken.....
Mooi klusje voor morgen :-) Weet nog even niet hoe ik dat zou moeten toepassen....

Simpel:
Je moet dus LAN poort 1 gaan gebruiken i.p.v. WAN poort en LAN 1 inschakelen:



Ik heb het net even getest, WAN poort geeft dan een waarschuwing maar heb netjes verbinding met LAN1/WAN (Failover dus)



Smart WAN:

[mkoekoek]

Hi Birdy en anderen.

Dank voor de heldere tekening met uitleg.
Ik had dit nog niet serieus bekeken omdat ik toch geen back-up lijn heb, en dus was even benieuwt hoe zich dat zou ontvouwen.

Inderdaad een kwestie secundaire interface aan zetten en kabel van CB van WAN naar LAN1 prikken.
Ik moest wel handmatig de optie "Instellen als standaardgateway" omzetten, uit bij de niet actieve interface en aan bij de actieve.
En alles herstarten, vanzelf omschakelen was er niet bij, waarschijnlijk door het ontbreken van twee actieve lijnen.

Ook hier op de LAN1 poort een ander IP adres beginnend met 94 (net als op de direct aangesloten laptop)
Het zal vast een ander uniek adres zijn geweest omdat het natuurlijk (weer) een ander mac adres is.

Helaas, helaas heeft het alleen niet tot gevolg gehad dat de snelheid er beter van werd, wederom 200-220Mbps.
Morgen eerst maar eens wat op het Ziggo forum zetten t.a.v. de snelheid verhoging naar 400Mbps.
Een PB naar de moderator van deze topic dan, want dat heeft in het verleden op andere gebieden ook het beste geholpen.
Met een beetje mazzel kan ik dan maandag de helpdesk weer bellen zodat er toch vanuit die hoe nog eens gekeken kan worden.

Nogmaals dank voor reacties, bij nieuws zal ik weer reageren. Hopelijk met de oplossing ;-)

Groet,
Mart

[Birdy]

En alles herstarten, vanzelf omschakelen was er niet bij, waarschijnlijk door het ontbreken van twee actieve lijnen.

Bij mij was herstarten niet nodig hoor, gewoon ompluggen WAN > LAN en LAN > WAN....heel even wachten en ik had weer Internet, anders kan het geen failover optie zijn.

(Ik heb ook geen 2e WAN-lijntje)

[Briolet]

Een heel andere vraag: Hoe meet je de snelheid, want dat vind ik niet terug. Alleen ergens halverwege dit draadje staat een plaatje van een ziggo test?

Ookla heeft tegenwoordig een beta-speedtest lopen die bij sommige mensen een te lage snelheid geeft. Ook de Ziggo speedtest gebruikt deze beta versie. Bij mij werkt die Ziggo test niet eens, terwijl de kpn speedtester, die ook via Ookla loopt, en significant te lage snelheid geeft. Ook sommige andere Ziggo klanten geven aan dat de Ziggo test bij hun een te lage snelheid aangeeft, terwijl de snelheid volgens andere test wel goed is.

Dit probleem ligt hier niet aan de pc, want ik heb het op elk apparaat, incl de telefoon.

De legacy test van Ookla geeft bij mij wel de verwachte snelheid. Net als de test van DSLReports

[mkoekoek]

@Birdy,

Zojuist opnieuw even de failover functie en dus de back-up (LAN1) interface gecontroleerd.

De instellingen zoals het bijgesloten screenshot gezet, en dit opgeslagen. Router daarna herstart.
Nadat de router weer een tijdje draaide met deze instelling heb ik de kabel van de CB van Ziggo dus van WAN naar LAN1 verplaatst.
Dat heeft dus bij mij het beoogde effect niet, zelfs na een kwartier was er nog geen verbinding met internet.
Ik heb natuurlijk nu even kritischer naar het gedrag van de RT2600ac gekeken. De poorten WAN en LAN1 wisselen wel keurig van status. En de LED's op de voorkant wisselen keurig tussen WAN1 en WAN2 overeenkomstig de gebruikte interface.
Na het weer terug steken van LAN1 naar WAN is er vrijwel gelijk wel weer verbinding.

RT2600ac failover functie lijkt prima te werken, maar er wordt niet opnieuw een IP adres vanuit de provider uitgedeeld op de Back-up LAN1 interface. Ik heb daarna nog een keer de kabel om gestoken van WAN naar LAN1, en daarbij dan tevens de CB van Ziggo herstart en verder niet aan de RT2600ac gezeten.
Dit geeft nadat de CB weer is opgestart weer internet access.
En ja, dan wordt op de back-up interface wel een (ander) IP adres uitgedeeld door de provider.

Kortom, failover functie RT2600ac is prima en werkt ook, CB van Ziggo snapt dit niet en moet even uit en weer aan dan.
Vanzelf gaat dit dus in deze combinatie niet. In mijn eerdere poging was ik wat rigoureuzer en herstartte alles gewoon....

Maar moraal, op beide interfaces van RT2600ac wordt niet de snelheid gehaald die gehaald zou moeten worden.

@Briolet,

Ik gebruik in principe altijd de Ziggo speedtest, Voorheen, toen ik nog geen RT2600ac had, kwam ik dan op ruim 300Mbps met het technicolor modem van Ziggo.
Na aanschaf van de RT2600ac en het technicolor modem in bridge mode was deze nog maar de genoemde 200Mbps (augustus 2017)
Na contact met Ziggo en bezoek monteur heb ik dus de CB van Ziggo, maar is de gemeten snelheid bij Ziggo dus 200Mbps. (september 2017)

Niet de eerder gemeten 300 met dezelfde tool.
Inmiddels (oktober 2017) is de snelheid van het afgenomen abonnement verhoogd naar 400Mbps, maar zoals duidelijk zal zijn haal ik maar 200Mbps.

Ik heb ook de speedtest van KPN uitgevoerd, dat geeft een marginaal verschil, evenals een test bij Ookla.

Ik heb zojuist ook even via de link uit je reactie, DSLReports, een test gedaan, die komt wel wat hoger uit, 260Mbps, maar nog steeds niet de 400Mbps die mijn abonnement beloofd.
Ik besef dat de metingen indicaties zijn en bij benadering, zowel positief als negatief een indicatie zullen zijn.
Mijn abo beloofd mij 400Mbps, als ik tussen 380 en 410 zou meten ben ik tevreden. En 38 - 41 Mbps voor de upload.

Voor zover dit al niet duidelijk was, ligt de oorzaak wel bij Ziggo als provider, ik heb in elk geval dankzij al jullie input wel de nodige munitie om opnieuw bij Ziggo aan de bel te trekken en ook met de concreet uitgevoerde acties daar een case duidelijk te maken.

Wederom dank voor jullie reacties, verder zoals gepland, via Ziggo community en PB naar moderator het vuur opstoken en maandag helpdesk bellen.

Groet,

Mart

[Ben(V)]

Die failover is ook niet bedoelt als failover van een defecte poort of zo.
Die is bedoelt voor als je een tweede WAN aansluiting hebt (bijvoorbeeld 4G) dan kan bij het wegvallen van het normale WAN de router een failover doen naar de andere poort en het alternatieve 4G gebruiken.

Hoe zou de ziggo router overigens het verschil kunnen zien tussen een benodigde failover en het uitzetten van je Synology router?
Dan zou je elke keer als je de router even uitzet een ander ipadres krijgen, denk niet dat je daar blij van wordt.

[Birdy]

Nu heb ik dus geen Ziggo maar, waarschijnlijk is deze handmatig ingesteld, misschien wordt die instelling niet overgenomen als je gaat switchen en na een reboot wel.
De failover functionaliteit is natuurlijk bedoelt om, zonder reboot, wel te kunnen switchen.

Zelf heb ik Telfort(KPN) (was xmsnet) glasvezel en hoef deze niet handmatig in te stellen, bij mij staat deze dus op Auto:



Misschien maakt DAT het verschil ?

[mkoekoek]

@Birdy en Ben(v),

Een failover functie zou alles wat er mis gaat moeten opvangen, ook een poort die defect gaat.
Maar hier ligt dus wel het wezenlijke verschil tussen Kabel en DSL aan ten grondslag. Of eigenlijk de implementatie van de provider daarvan.

Een provider met DSL levert vaste IP adressen op zijn aansluitingen, heb je twee lijnen, dan heb je ook twee IP adressen (of meer).
Een kabel provider levert IP adressen die geregistreerd en gekoppeld zijn aan mac adressen, op DHCP manier.

Waar het bij mij in dit failover verhaal mis gaat is het feit dat Ziggo een kabel provider is.
WAN en LAN1 poort hebben elk een verschillend mac adres, aan het mac adres van WAN poort is IP adres x toegewezen, en aan het mac adres van LAN1 poort is IP adres Y toegewezen. Helaas is de D van het DHCP deel iets minder dynamisch als bij de DSL provider.
Als ik bijvoorbeeld die kabel een uur los zou laten hangen en dan in de andere poort stop, dan zou het misschien wel werken.
Er zit een bepaalde TTL cache op die toegewezen IP adressen op mac adres. Als je dit trouwens te veel wisselt dan werd je in het verleden gewoon tijdelijk geheel afgesloten. Dat valt anno 2017 gelukkig mee.

Zoals u bekend zal zijn, zijn de publieke IP adressen schaars, zo niet op. Providers zullen dus controle over de uitgifte van Publieke adressen moeten voeren. Met vaste adressen zoals DSL vergt dat geen technisch ingrijpen, met de DHCP manier bij kabel providers wel. Daar wordt dus net een wat minder dynamisch als verwacht geschakeld. Bij Birdy zal ook bij het wisselen van WAN naar LAN1 altijd het zelfde publieke IP adres gelden, dat is per slot aan de lijn gekoppeld. In mijn geval, kabel provider is dat dus anders en daardoor werkt dat in deze opzet niet.

Maar zoals al gemeld, hier ligt dus geen oorzaak t.a.v. de niet gehaalde snelheid ;-)

Dank weer voor jullie reacties,

Mart

[Birdy]

Bij Birdy zal ook bij het wisselen van WAN naar LAN1 altijd het zelfde publieke IP adres gelden, dat is per slot aan de lijn gekoppeld.

Klopt.