2.5GB Performance issue i.c.m. Ubiquiti en KPN Glasvezel

[laurens0619]

Is het mogelijk die kabel direct van je pc in de udm se te stoppen?
Als het dan wel goed dan weet je alweer meer

[_JGC_]

Wat @laurens0619 voorstelt eerst eens proberen, kan je de switch uitsluiten.

Verder zie ik dat je KPN gebruikt, dus PPPoE met VLANs. Welke MTU heb je op de PPPoE tunnel staan? Is dat 1500, of een kleinere MTU met bijbehorende instellingen voor MSS clamping? Naar mijn weten kan Unifi nog steeds niet zonder hacks out-of-the box baby jumbo frames instellen

Ik denk dat er ergens een buffer vol loopt, en dat ligt dan waarschijnlijk niet eens aan je Unifi apparatuur. Je Genexis is waar nu de bottleneck zit: dat is een goedkoop apparaat met een aftandse versie van OpenWRT die 2.5Gbit binnenkrijgt en dat met 1Gbit op het glas gaat zetten. Zodra die buffer volloopt gaat dat ding verkeer droppen of pause frames versturen en dan stort je snelheid in.

Ik herken dit issue uit een mixed 100/1000 netwerk: fileserver op 1Gbit switch, webserver op 100Mbit switch met Gbit uplink. Fileserver duwt een grote file transfer naar de switch met 1Gbit, die duwt het naar de volgende switch en daar loopt de buffer vol omdat het met 100Mbit naar de webserver moet. Gevolg is gedropt verkeer en fouten op diverse poorten.

[Tonne]

Welke firmware draai je op de udm se? En kun je op de nas een speedtest draaien? Of je de 2,5 Gbps dan haalt ben ik benieuwd naar.

Dat van een vollopende buffer vind ik logisch klinken. Alleen als de WAN op 1 Gbps staat dan treedt het probleem ook op. Maar dan zou het de buffer van de udm se zijn.

Kun je de modem van de provider er tussen zetten? En kijken wat er dan gebeurt? Er zijn veel vage problemen geweest met de udm en udm se in combinatie met PPPoE. Misschien is dit een nieuwe.

[Workaholic]

laurens0619 schreef op dinsdag 4 oktober 2022 @ 23:04:
Is het mogelijk die kabel direct van je pc in de udm se te stoppen?
Als het dan wel goed dan weet je alweer meer

Dat heb ik gedaan, zowel in switch als udm. Gaat goed omdat de udm se alleen 1g LAN porten heeft. Pas als ik de 2.5g Port gebruik op de switch gaat het mis

_JGC_ schreef op dinsdag 4 oktober 2022 @ 23:28:
Wat @laurens0619 voorstelt eerst eens proberen, kan je de switch uitsluiten.

Verder zie ik dat je KPN gebruikt, dus PPPoE met VLANs. Welke MTU heb je op de PPPoE tunnel staan? Is dat 1500, of een kleinere MTU met bijbehorende instellingen voor MSS clamping? Naar mijn weten kan Unifi nog steeds niet zonder hacks out-of-the box baby jumbo frames instellen

Ik denk dat er ergens een buffer vol loopt, en dat ligt dan waarschijnlijk niet eens aan je Unifi apparatuur. Je Genexis is waar nu de bottleneck zit: dat is een goedkoop apparaat met een aftandse versie van OpenWRT die 2.5Gbit binnenkrijgt en dat met 1Gbit op het glas gaat zetten. Zodra die buffer volloopt gaat dat ding verkeer droppen of pause frames versturen en dan stort je snelheid in.

Ik herken dit issue uit een mixed 100/1000 netwerk: fileserver op 1Gbit switch, webserver op 100Mbit switch met Gbit uplink. Fileserver duwt een grote file transfer naar de switch met 1Gbit, die duwt het naar de volgende switch en daar loopt de buffer vol omdat het met 100Mbit naar de webserver moet. Gevolg is gedropt verkeer en fouten op diverse poorten.

Ik kan alleen bij WAN instellingen oa de VLAN instellen meen ik. Hij staat nu op VLAN 6 en idd PPPOE.

Zou het probleem weg zijn als ik het modem er tussen plaats en dan deze op het WAN Port van de udm se aansluit? Zonder unify gear aansluiten kan ook maar zal gewoon goed gaan omdat deze geen 2.5g switch Port heeft.

Klinkt logisch dat het de NTU is, maar zou het probleem dan niet weg moeten zijn als ik de WAN Port aanpas naar 1gb FDX? Gek genoeg blijft het probleem aanwezig dan.

Tonne schreef op woensdag 5 oktober 2022 @ 05:34:
Welke firmware draai je op de udm se? En kun je op de nas een speedtest draaien? Of je de 2,5 Gbps dan haalt ben ik benieuwd naar.

Dat van een vollopende buffer vind ik logisch klinken. Alleen als de WAN op 1 Gbps staat dan treedt het probleem ook op. Maar dan zou het de buffer van de udm se zijn.

Kun je de modem van de provider er tussen zetten? En kijken wat er dan gebeurt? Er zijn veel vage problemen geweest met de udm en udm se in combinatie met PPPoE. Misschien is dit een nieuwe.

Laatst beschikbare versie. Alles is up to date. Geen beta versies in gebruik

Dat heb ik eerder getest en gaat goed omdat ik dan geen 2.5g switch Port beschikbaar heb. Dus dan treed het probleem niet op, dit is namelijk ook het geval wanneer ik mijn pc op een 1g Port zet of vastzet op 1g fdx.

[ Voor 21% gewijzigd door Workaholic op 05-10-2022 07:13 ]

[Tonne]

Ik bedoel de modem op de WAN port van de udm se

Een andere optie. Kun je de verbinding tussen de switch en de udm se 1gbit maken? Bijv door een utp kabel te gebruiken ipv de sfp dac kabel.

Ik zou toch zeggen dat het de buffering van de udm se is die wat geks doet. En zo verplaats je de buffering naar de switch.

En zou je ipv ‘laatst beschikbare versie’ een nummer willen noemen van wat je draait?

[ Voor 86% gewijzigd door Tonne op 05-10-2022 07:30 ]

[Workaholic]

Tonne schreef op woensdag 5 oktober 2022 @ 07:25:
Ik bedoel de modem op de WAN port van de udm se


Ik zou toch zeggen dat het de buffering van de udm se is die wat geks doet. En zo verplaats je de buffering naar de switch.

En zou je ipv ‘laatst beschikbare versie’ een nummer willen noemen van wat je draait?

Kun je dan aub uitleggen wat je zou willen dat ik doe met de WAN port op de UDM Se? Direct met de pc koppelen? Moet even kijken hoe ik de verbinding dan test.

Een andere optie. Kun je de verbinding tussen de switch en de udm se 1gbit maken? Bijv door een utp kabel te gebruiken ipv de sfp dac kabel.

Klinkt logisch inderdaad. Ik heb ipv andere kabel de SFP op 1gb gezet ipv 10G en het upload issue is weg. Maar ik beperk nu brandbreedte naar de UDM SE vanuit de switch en dat wil je imho niet.

Is dit niet hetzelfde als 1G port gebruiken voor de desktop of de desktop port op 1G fdx te forceren?

Firmware : Device Version 2.5.11

[ Voor 34% gewijzigd door Workaholic op 05-10-2022 08:02 ]

[Thralas]

Workaholic schreef op dinsdag 4 oktober 2022 @ 22:31:
- de WAN verbinding tussen UDM SE (WAN RJ45 2.5G) loopt direct naar de NTU en deze geeft een link van 2.5G. Als ik deze op 1G vastzet aan de UDM SE kant blijft het probleem aanwezig.

Weet je dat zeker? Zijn er NTUs met 2GbE?

- Als ik de WAN verbinding weer terug zet op auto-negotiate (en dus weer op 2.5G) heb staan en de PC op 1G vastzet in windows is het probleem OPGELOST. Maar ik wil graag naar mijn netwerk, NAS etc 2.5G hebben. Ook komt dit op mij over als een lapmiddel en niet een oplossing

Waarom wijzig je hier twee variabelen? Dat laatste (PC naar 1G) lijkt me het effect te verklaren.

- En om het nog complexer te maken als ik een iperf doe tussen werkplek en laptop haal ik het maximale van 1G (laptop heeft maar 1G nic) terwijl je hier zou verwachten dat hij net zoals via de speedtest een lagere upload zou moeten hebben? Hierbij blijft de traffic binnen de switch en gaat deze niet naar WAN of de UDM SE.

Niet persé. Ligt eraan waar de frames droppen in het andere scenario.

- Als ik de vorige bullet nogmaals doe maar dan met de laptop in de UDM SE switch en de PC in de normale witch heb ik ook geen issues (hiermee test ik dus de connectie tussen switch/udm se)

Welke 'normale switch'?

- Zie wel tx/rx dropped op de verschillende porten, deze lopen ook op als ik 2.5G in gebruik heb.

Zorgelijk.

Vraag
Is dit microstuttering? Buffers die vol lopen?

Heeft alle schijn van dat laatste (microbursts, trouwens, niet -stutter).

Snappen jullie waarom iperf wel goed gaat? Althans naar de laptop en niet naar WAN. Dit zou toch gewoon moeten werken - 2.5G PC -> 2.5G switch.

Hoewel je duidelijk je best gedaan hebt qua testen, is me niet echt duidelijk hoe de verschillende scenario's er nu uitzien.

Je internetpad is PC <2.5G> USW <10G> UDM <2.5G?> NTU <??G> KPN. Dat zijn tenminste twee rate conversions, en hoewel je je probleem ermee aantoont is het daarmee geen goede test.

Probeer de tests nog eens op een rijtje te zetten, met liefst 1 rate conversion per scenario?

Wat doet de PC naar het internet als je 'm direct op de UDM prikt?

En dáár waar je tx/rx failure counters ziet oplopen door iperf is natuurlijk hoofdverdacht.

[sambaloedjek]

Flow control aanzetten op de wan poort?

[laurens0619]

@Workaholic
Is het mogelijk om een speedtest tussen je pc en de UDM SE uit te voeren? Dus los van de internet verbinding? Ik lees iets over "Wifiman" en dat dit ook de test richting de udm kan doen?

iPadPro WiFiman 0.13.3

Running a WiFiman speed test from the iPad will sometimes test through to Internet AND against the local UDM-Pro (I find the latter measurements more useful). Other times it will only run the internet portion of the test. Is there a setting to always enable the gateway test?

UDM-Pro firmware 1.9.0

https://community.ui.com/...a5-4ec5-81b1-8756229513bc

En dan kijken wat het verschil is bij 1GB link en 10/2.5 GB link naar je switch toe

Als dit niet kan kun je ook dit testen:
- Zet een pc met gbit verbinding achter de WAN poort en start daar Iperf.
- Test vanaf je 2.5gbit pc nu een iperf test naar het WAN ip (wat dus eigenlijk je computer is als "nep" internet verbinding).

Dan kun je de ntu iig uitsluiten

[ Voor 76% gewijzigd door laurens0619 op 05-10-2022 09:54 ]

[Ben(V)]

KPN levert volgens mij geen NTU's 2.5Gbps aan kunnen, dus als je PC met 2.5Gbps data gaat verzenden moet dat ergens teruggebracht worden naar 1Gbps en dat moet die UDM se dan doen en die heeft daar overduidelijk problemen mee.

Zet gewoon de hele boel op 1Gbps, het enige wat 2,5Gbps aan kan is je PC, maar verder heb je niets dat daar iets mee kan dus is het niet zinvol dat te proberen te gebruiken.

[ Voor 6% gewijzigd door Ben(V) op 05-10-2022 10:02 ]

[laurens0619]

@Ben(V)
Ik gok ook dat in de udm de oorzaak ligt .
Maar "terugklokken" lijkt mij wat zonde na die investering. Ik gok dat deze complete setup zo richting de 2a3K gaat en dan zou ik persoonlijk ook alles willen proberen om die snelheden (ook al theoreitsch) te kunnen benutten ipv terugklokken.

Als je al gaat terugklokken, klok dan de uplink tussen de udm en de switch terug naar 1GBIT. Dan blijft de rest van netwerk iig op 2.5 draaien.

Persoonlijk had ik die UDM SE nooit gekocht. Wifi van Unifi is prima (ook steeds minder helaas) maar routers (en soms ook switches met igmp) kennen gewoon rare issues. OVerpriced voor de kwaliteit.

Uniforme setup is mooi maar kwaliteit vind ik belangrijker, dan maar mix.

edit:
Ik zat nog beetje op GoT te lezen en schijnbaar (wist ik niet) is een 1/2.5/10gbit mix wel eens vaker problematisch. Zie bijvoorbeeld dit topic: 10GbE naar 1GbE benodigde packet buffer berekenen

[ Voor 37% gewijzigd door laurens0619 op 05-10-2022 10:36 ]

[Ben(V)]

@laurens0619 Ik begrijp je punt, maar hij heeft helemaal geen 2.5Gbps infrastructuur, enkel die PC kan dat aan.
Het is dus een keuze tussen de boel gewoon op 1Gbps zetten (want 2,5Gbps kan toch nergens gebruikt worden) of die UDM SE vervangen en dan kun je nog steeds nergens 2.5Gbps gebruiken.

Ik zou zeggen vervang die UDM SE pas op het moment dat je ook ergens 2.5Gbps kunt gaan gebruiken.

En persoonlijk vind ik ook dat een argument als "ik wil alles van hetzelfde merk hebben" een beetje onzinnig is.
Koop gewoon de beste prijs/kwaliteit verhouding ongeacht het merk.
Daar zijn standaarden voor uitgevonden om dat gewoon netjes werkbaar te hebben.

[laurens0619]

Stel je wifi clients uit de keuken vragen iets op van kantoor pc met 800mbit traffic + de macbook wired met 1gbit dan zit je op 1.8 en heb je dus wel iets aan de 2.5

Ja ik weet het, thereoretisch maar als je je pc dus op 2.5gbit laat staan en je switch uplink op 1gbit dan heb je het "beste" van beide werelden. Dan kunnen de clients onderling nog 2.5 praten en is alleen het verkeer naar de udm beperkt op 1gbit. Ik geloof dat @Workaholic IP cameras heeft die naar de UDM streamen dus ergens ga je daar toch ook inleveren.

Mrja allemaal theoretisch en erg in het kader "omdat het kan". Terugklokken naar 1gbit overal zou geen significant effect moeten hebben op het netwerk.

[Ben(V)]

Je argument snijd alleen hout als je iets van een centrale server of een Nas hebt die vanuit meerder bronnen gebruikt worden.
Een PC is 90% van de tijd enkel maar PC (PC = Personal Computer).

Kortom zoals je zelf zegt erg theoretisch en om daar dan nieuwe apparatuur voor te gaan kopen een beetje ver gezocht.

Maar kijken of je alleen de connectie tussen die UDM se en die NTU op 1Gbps te zetten helpt is zeker het proberen waard, maar ik vrees dat die UDM se gewoon problemen heeft met de buffering om die 2.5Gbps naar 1Gbps terug te brengen en dan helpt dat terugbrengen van die ene link niets.
Die link zal effectief vermoedelijk toch al 1Gbps zijn, want volgens mij kunnen de KPN Ntu's helemaal geen 2.5Gbps

[ Voor 39% gewijzigd door Ben(V) op 05-10-2022 11:27 ]

[laurens0619]

@Ben(V)
Ik bedoel verbinding tussen de UDM se en de Switch, die van 10gbit naar 1gbit zetten.
Dat helpt, had TS al getest, dus lijkt mij voor nu de meest pragmatische oplossing. Blijf rest van je netwerk 2.5 gbit.
Owja verder eens hoor, zwaar theoretisch

[ Voor 8% gewijzigd door laurens0619 op 05-10-2022 11:34 ]

[Verwijderd]

Ben(V) schreef op woensdag 5 oktober 2022 @ 10:00:
KPN levert volgens mij geen NTU's 2.5Gbps aan kunnen

Op XGS-Pon leveren ze een ONT die tot 10G kan .

Yes i know, het is een ONT en geen NTU

@Workaholic Gezien het goed werkt met de UDM -> Switch op 1G klink het als een probleem tussen Switch en UDM. Gooi je verhaal even op de UI forum met de Unifi OS support file als prive file dan kunnen hun engineers eens kijken.

[ Voor 25% gewijzigd door Verwijderd op 05-10-2022 11:56 ]

[Tonne]

Workaholic schreef op woensdag 5 oktober 2022 @ 07:58:
[...]


Kun je dan aub uitleggen wat je zou willen dat ik doe met de WAN port op de UDM Se? Direct met de pc koppelen? Moet even kijken hoe ik de verbinding dan test.


[...]


Klinkt logisch inderdaad. Ik heb ipv andere kabel de SFP op 1gb gezet ipv 10G en het upload issue is weg. Maar ik beperk nu brandbreedte naar de UDM SE vanuit de switch en dat wil je imho niet.

Is dit niet hetzelfde als 1G port gebruiken voor de desktop of de desktop port op 1G fdx te forceren?

Firmware : Device Version 2.5.11

Ja dat is hetzelfde. Maar dat betekent dat het probleem zit in het bufferen door de UDM SE. Laat @nero355 het maar niet horen . Nee dat wil je eigenlijk niet. Maar het is beter dan wat je had. Ik zou het probleem melden bij Ubiquiti.
Komt toch neer op een versie van wat je zei, microbursts. Als ik goed begrijp wat microbursts zijn.
Zolang je 2,5 Gbit verkeer in hetzelfde vlan blijft heb je er maar weinig last van dat de verbinding met de UDM SE maar 1 Gbit is.

[Workaholic]

Thralas schreef op woensdag 5 oktober 2022 @ 08:10:
[...]


Weet je dat zeker? Zijn er NTUs met 2GbE?

Dat zwarte kastje in de meterkast waar fiber op binnenkomt - geeft 2.5G inderdaad als auto-negotiate.
Via-via had ik begrepen dat dit nu standaard was op nieuwe glasvezel installaties.

Waarom wijzig je hier twee variabelen? Dat laatste (PC naar 1G) lijkt me het effect te verklaren.

Ik heb allebei de zaken los van elkaar getest. Wijzigen van WAN kant naar 1G FDX maakt geen verschil, alleen de desktop naar 1G FDX zetten lost dus het probleem op.

Dankzij een ander idee hebben we nu geconstateerd dat wanneer ik alles op auto laat staan (dus WAN kant en desktop kant) maar alleen de uplink tussen UDM SE en Switch aanpas van 10G -> 1G FDX - werkt alles weer naar behoren.

Welke 'normale switch'?

Ik heb mijn fysieke PC naar de patch ruimte gebracht en het volgende getest met nieuwe patch kabels (om interne bekabeling uit te sluiten)

- PC in USW-Enterprise (2.5G)
- Laptop in UDM SE switch (1g)

Dit geeft issues zoals eerder beschreven. Pas als ik de PC op de 1G port aansluit op de USW-Enterprise OF wanneer ik deze direct op de UDM switch aansluit (ook 1G!) zijn de issues weg.

Wat ook werkt is dus DAC SFP kabel limiteren op 1G tussen UDM SE en switch of de 2.5G port naar mijn PC vastzetten op 1G.

Hoewel je duidelijk je best gedaan hebt qua testen, is me niet echt duidelijk hoe de verschillende scenario's er nu uitzien.

Je internetpad is PC <2.5G> USW <10G> UDM <2.5G?> NTU <??G> KPN. Dat zijn tenminste twee rate conversions, en hoewel je je probleem ermee aantoont is het daarmee geen goede test.

Probeer de tests nog eens op een rijtje te zetten, met liefst 1 rate conversion per scenario?

Wat doet de PC naar het internet als je 'm direct op de UDM prikt?

En dáár waar je tx/rx failure counters ziet oplopen door iperf is natuurlijk hoofdverdacht.

Internet pad is inderdaad PC -> 2.5G -> USW Enterprise op 2.5G -> 10G DAC SFP -> UDM SE -> NTU 2.5G -> KPN

Zoals hierboven aangegeven zodra ik de DAC op 1G vastzet of de PC op 1G vastzet (of een 1G port pak) is het probleem weg.

sambaloedjek schreef op woensdag 5 oktober 2022 @ 08:16:
Flow control aanzetten op de wan poort?

Deze optie lijkt niet beschikbaar in de webgui.

laurens0619 schreef op woensdag 5 oktober 2022 @ 09:50:
@Workaholic
Is het mogelijk om een speedtest tussen je pc en de UDM SE uit te voeren? Dus los van de internet verbinding? Ik lees iets over "Wifiman" en dat dit ook de test richting de udm kan doen?

Werkt helaas alleen op IOS en Android. Geen werkende windows app.
Wil jouw idee van de WAN port wel even proberen, dan moet ik denk ik de laptop in de WAN port aansluiten en een statisch ip server geven (eens? geen dhcp).

Ben(V) schreef op woensdag 5 oktober 2022 @ 10:00:
KPN levert volgens mij geen NTU's 2.5Gbps aan kunnen, dus als je PC met 2.5Gbps data gaat verzenden moet dat ergens teruggebracht worden naar 1Gbps en dat moet die UDM se dan doen en die heeft daar overduidelijk problemen mee.

Zet gewoon de hele boel op 1Gbps, het enige wat 2,5Gbps aan kan is je PC, maar verder heb je niets dat daar iets mee kan dus is het niet zinvol dat te proberen te gebruiken.

Ik heb er toch echt één.. denk ook om straks meer dan 1G internet te kunnen leveren.

Verwijderd schreef op woensdag 5 oktober 2022 @ 11:51:
[...]


Op XGS-Pon leveren ze een ONT die tot 10G kan .

Yes i know, het is een ONT en geen NTU

@Workaholic Gezien het goed werkt met de UDM -> Switch op 1G klink het als een probleem tussen Switch en UDM. Gooi je verhaal even op de UI forum met de Unifi OS support file als prive file dan kunnen hun engineers eens kijken.

Excuses het is dan inderdaad een ONT - en het betreft inderdaad dit kastje (zie foto hieronder van mijn meterkast)

Tonne schreef op woensdag 5 oktober 2022 @ 14:09:
[...]

Ja dat is hetzelfde. Maar dat betekent dat het probleem zit in het bufferen door de UDM SE. Laat @nero355 het maar niet horen . Nee dat wil je eigenlijk niet. Maar het is beter dan wat je had. Ik zou het probleem melden bij Ubiquiti.
Komt toch neer op een versie van wat je zei, microbursts. Als ik goed begrijp wat microbursts zijn.
Zolang je 2,5 Gbit verkeer in hetzelfde vlan blijft heb je er maar weinig last van dat de verbinding met de UDM SE maar 1 Gbit is.

Dus toch microbursts? Ligt het dan aan de hoeveelheid conversies en de 10G dac kabel? Ik zal even een unify forum topic aanmaken met de hoop dat we dit softwarematig kunnen fixen want ik wil het liefst gewoon 2.5G kunnen gebruiken en zeker niet mijn uplink limiteren op 1G. Ook vanuit principe omdat ik hardware heb aangeschaft met 2.5G, 10G sfp etc.

[Verwijderd]

Als je inlogt met SSH op de switch en UDM en tijdens de test kijkt bij wat top en /var/log/messages laat zien. Misshien dat daar nog een hint in zit.

Workaholic schreef op woensdag 5 oktober 2022 @ 16:44:

Deze optie lijkt niet beschikbaar in de webgui.

Zou onder de device settings van de switch moeten staan.

[ Voor 46% gewijzigd door Verwijderd op 05-10-2022 16:59 ]

[nero355]

Workaholic schreef op woensdag 5 oktober 2022 @ 16:44:
alleen de desktop naar 1G FDX zetten lost dus het probleem op.

Ik kreeg net een brainfart en moest opeens aan dit denken : https://wccftech.com/inte...90-motherboards-affected/

Gezien het om een GigaByte moederbord gaat moet je met alles rekening houden tenslotte...

[Tonne]

Ik zie dat het ook een layer 3 switch is. Als je dan de 1Gbit poorten van de UDM SE niet gebruikt dan is er helemaal niets mis met het gebruiken van een 1 Gbit link tussen de switch en de UDM SE. Het inter-vlan verkeer wordt door de switch gerouteerd. En je hebt de router enkel voor de internetverbinding nodig.

Alleen kijkend naar de toekomst wil je dit natuurlijk wel werkend hebben. En je zou ook zeker mogen verwachten dat het wel goed werkt.

Wat er volgens mij gebeurt. Er gaat data met 2,5 Gbit naar de UDM. Die gaat met 1 Gbit naar het internet. Normaal vindt hier een buffering plaats. Maar daar gaat iets mis.

[nero355]

Tonne schreef op woensdag 5 oktober 2022 @ 18:41:
Ik zie dat het ook een layer 3 switch is. Als je dan de 1Gbit poorten van de UDM SE niet gebruikt dan is er helemaal niets mis met het gebruiken van een 1 Gbit link tussen de switch en de UDM SE. Het inter-vlan verkeer wordt door de switch gerouteerd. En je hebt de router enkel voor de internetverbinding nodig.

Volgens mij wordt er standaard nog steeds de Router als DHCP Server en Default Gateway gekozen bij het aanmaken van een nieuwe VLAN of beter gezegd netwerk

[Tonne]

nero355 schreef op woensdag 5 oktober 2022 @ 18:46:
[...]

Volgens mij wordt er standaard nog steeds de Router als DHCP Server en Default Gateway gekozen bij het aanmaken van een nieuwe VLAN of beter gezegd netwerk

Ja maar dan heb je toch geen last van de 1Gbps verbinding? Van de huidige situatie uitgaand, dat de WAN snelheid 1 Gbps is.

[Workaholic]

Verwijderd schreef op woensdag 5 oktober 2022 @ 16:53:
Als je inlogt met SSH op de switch en UDM en tijdens de test kijkt bij wat top en /var/log/messages laat zien. Misshien dat daar nog een hint in zit.

[...]

Zou onder de device settings van de switch moeten staan.

Geen rare meldingen tegengekomen. Zie wel wat errors voorbij komen bij de counters. Ook bij de AP's.
Errors vallen mee, zijn vooral drops

nero355 schreef op woensdag 5 oktober 2022 @ 17:48:
[...]

Ik kreeg net een brainfart en moest opeens aan dit denken : https://wccftech.com/inte...90-motherboards-affected/

Gezien het om een GigaByte moederbord gaat moet je met alles rekening houden tenslotte...

Het is een realtek kaart.. had juist liever intel gehad . Heb voor de zekerheid bios update gedaan en realtek drivers vernieuwd. Geen verschil.

Tonne schreef op woensdag 5 oktober 2022 @ 18:41:
Ik zie dat het ook een layer 3 switch is. Als je dan de 1Gbit poorten van de UDM SE niet gebruikt dan is er helemaal niets mis met het gebruiken van een 1 Gbit link tussen de switch en de UDM SE. Het inter-vlan verkeer wordt door de switch gerouteerd. En je hebt de router enkel voor de internetverbinding nodig.

Alleen kijkend naar de toekomst wil je dit natuurlijk wel werkend hebben. En je zou ook zeker mogen verwachten dat het wel goed werkt.

Wat er volgens mij gebeurt. Er gaat data met 2,5 Gbit naar de UDM. Die gaat met 1 Gbit naar het internet. Normaal vindt hier een buffering plaats. Maar daar gaat iets mis.

Klopt - alleen heb ik niet het idee dat het nu zo werkt, traffic routering gaat echt via de UDM. Ook als het tussen twee subnets is (IoT & Secure). Ik moet me hier nog even in verdiepen maar denk dat een layer 3 weinig voordelen heeft voor thuis..

En inderdaad het gaat vooral om het principe dat het gewoon moet werken en voor het geval KPN straks een 2G internet verbinding oid gaat aanbieden.

sambaloedjek schreef op woensdag 5 oktober 2022 @ 08:16:
Flow control aanzetten op de wan poort?

Deze optie heb ik gevonden bij global switch settings. Is deze specifiek alleen voor WAN beschikbaar? Dit lijkt het voor alle switches aan te passen - en mogelijk dus niet alleen voor de WAN port ?

Upload probleem blijft met 2.5G icm flow control enabled overigens. Mijn download snelheid lijkt wel iets hoger te zijn, maar dit kan ook een moment opname zijn (zit nu boven de 900 @ speedtest en eerder rond de 800-850). Lees ook wel veel negatieve verhalen over flowcontrol - dus voor nu maar weer uitgeschakeld omdat ik niet kan bevestigen of het echt verschil uitmaakt en het probleem blijft



Overigens heb ik nu ook een support ticket en forum topic aangemaakt bij Ubiquiti. Door jullie input/hulp weten we nu vrij zeker waar het probleem zit en ik zou graag zien dat Unify hier wat mee doet.. . Eerst via de chat geprobeerd maar dat was geen succes.. dat was nog van het niveau van start, uitvoeren, ipconfig. Ik ben benieuwd!

[ Voor 25% gewijzigd door Workaholic op 05-10-2022 20:50 ]

[Kabouterplop01]

Tonne schreef op woensdag 5 oktober 2022 @ 18:41:
Ik zie dat het ook een layer 3 switch is. Als je dan de 1Gbit poorten van de UDM SE niet gebruikt dan is er helemaal niets mis met het gebruiken van een 1 Gbit link tussen de switch en de UDM SE. Het inter-vlan verkeer wordt door de switch gerouteerd. En je hebt de router enkel voor de internetverbinding nodig.

Alleen kijkend naar de toekomst wil je dit natuurlijk wel werkend hebben. En je zou ook zeker mogen verwachten dat het wel goed werkt.

Wat er volgens mij gebeurt. Er gaat data met 2,5 Gbit naar de UDM. Die gaat met 1 Gbit naar het internet. Normaal vindt hier een buffering plaats. Maar daar gaat iets mis.

Ik denk dat dat is wat er speelt; ik denk dat er iets mis gaat met die sliding window size negotiation.

Ben echt benieuwd wat hier uit komt.

[nero355]

Tonne schreef op woensdag 5 oktober 2022 @ 19:48:
Ja maar dan heb je toch geen last van de 1Gbps verbinding? Van de huidige situatie uitgaand, dat de WAN snelheid 1 Gbps is.

Eerlijk gezegd durf ik dat niet zomaar te stellen, want het verhaal is best wel een warboel aan het worden voor mij dus ik zou zeggen :
- Koop een Aquantia 10 Gbps NIC zoals deze : ASUS XG-C100C
- Ga daarmee eens testen @ 2,5 Gbps snelheden

Workaholic schreef op woensdag 5 oktober 2022 @ 19:50:
Het is een realtek kaart.. had juist liever intel gehad . Heb voor de zekerheid bios update gedaan en realtek drivers vernieuwd. Geen verschil.

Welk model RealTek

En heb je de drivers echt van de RealTek website gehaald ?!

Ik zat me suf te zoeken en clicken op die GigaByte website maar zag echt nergens om welke NIC het ging dus ik gokte maar op Intel

[Tonne]

Er is een update voor de UDM SE waarin de utp port driver is geupdate. Versie 3.0.13. Wellicht dat het probleem in deze versie is opgelost?

[Workaholic]

Tonne schreef op zondag 4 december 2022 @ 21:31:
Er is een update voor de UDM SE waarin de utp port driver is geupdate. Versie 3.0.13. Wellicht dat het probleem in deze versie is opgelost?

Helaas niet Krijg ook geen reactie meer van Ubiquiti behalve we are aware of the issue and hope to resolve in a future release.. kortom geen zekerheid of ETA helaas.

[Tonne]

Ja zo gaat het vaker hoor ik. Ik had gehoopt dat de 3.0 release wat minder van dat soort kinderziektes had. Ook omdat ze aankondigen dat al hun apparatuur deze kant op gaat. Nouja ooit 😉

[Workaholic]

Even een update nog steeds geen bugfix helaas.

Let op dat wanneer je dus een USW-Enterprise-24-PoE icm 2.5G LAN devices gebruikt je snelheid (upload) totaal ruk is. DL gaat wel goed vreemd genoeg. Alleen wanneer ik mijn desktop op 1G full duplex zet zijn de problemen weg (belachelijk als je een Enterprise switch aanschaft met 2.5G porten + UDM SE voor 2.5G RJ45 naar WAN)

Client op 2.5G of autonegotiate geeft:


Bij limit op 1G op de 2.5G nic / client krijg ik wel de juiste upload:

[ Voor 48% gewijzigd door Workaholic op 18-03-2023 19:06 ]

[Ben(V)]

Ubiquiti maakt prima wifi spullen met de rest van hun producten voldoen zeker niet aan de prijs die ze ervoor vragen.
Als je gaat rondkijken vind je heel erg veel problemen met de firmware van al hun router en managed switches en zelden of nooit firmware fixes.

[Workaholic]

Hier nog even het issue in één afbeelding

[jadjong]

Wat houdt je tegen om de connectie tussen UDM en switch op 1Gbit te forceren? Je hebt nu nog geen 2.5Gbit internet en die 8x 1Gbit op de UDM is sowieso niet bedoelt voor apparaten die bandbreedte vreten.

[laurens0619]

@Workaholic ubiquiti kennende gaan ze dit waarsch niet oplossen, ze lanceren liever nieuwe producten dan bugs fixen.

Misschien wat zuur maar ben bang wel de waarheid, ik zou of de gbit accepteren of de falende onderdelen vervangen

[ Voor 24% gewijzigd door laurens0619 op 18-03-2023 21:34 ]

[stormfly]

Workaholic schreef op zaterdag 18 maart 2023 @ 21:06:
Hier nog even het issue in één afbeelding

[Afbeelding]

Heb je wel eens getest met een shielded of unshielded UTP of dat nog uitmaakt tussen de UDM-SE en 24Ent?

[Workaholic]

jadjong schreef op zaterdag 18 maart 2023 @ 21:28:
Wat houdt je tegen om de connectie tussen UDM en switch op 1Gbit te forceren? Je hebt nu nog geen 2.5Gbit internet en die 8x 1Gbit op de UDM is sowieso niet bedoelt voor apparaten die bandbreedte vreten.

Gaat mij om het principe - ik koop een futureproof switch met 2.5G porten en ook een UDM Se met 2.5G wan uplink. Ik had nu net zo goed een 1G switch kunnen aanschaffen en de UDM Pro.

Ook wanneer KPN meer gaat leveren dan 1000/1000 blijf ik tegen dit probleem aanlopen.

Overigens - met 1000/1000 fiber heb je wel degelijk baat bij een 2.5G connectie door overhead (zie download speed als voorbeeld)

stormfly schreef op zaterdag 18 maart 2023 @ 21:43:
[...]


Heb je wel eens getest met een shielded of unshielded UTP of dat nog uitmaakt tussen de UDM-SE en 24Ent?

Er zit een SFP+ DAC tussen

[ Voor 25% gewijzigd door Workaholic op 18-03-2023 21:44 ]

[SambalBij]

Ik heb het topic heel verticaal gelezen; maar dit klinkt als een duplex probleem ergens.
Staan de poorten op je switch niet perongeluk op fixed speed en/of duplex?

Als je je PC op auto negotiation zet, en je upload stort in, dan betekend dat in mijn ervaring dat de switch vast staat of bijvoorbeeld op auto/fdx.

Op het moment dat namelijk de switch fixed staat, gaat die niet meer reageren op de auto-negotiation die je pc probeert te doen. In dat geval gaat de pc naar *half* duplex! En daar gaat je upload -> Je switch blijft gewoon data sturen (want full duplex) en je PC ziet collisions bij het sturen van data, en breekt het versturen af.

Stel je vervolgens je PC ook in op fixed full duplex, dan is je probleem weg, want fixed aan beide zijden.

Tweede aanwijzing dat ik zou vermoeden dat dat de issue is, is dat het goed werkt wanneer je die PC op full duplex vastzet. Zou je switch dan wel op auto negotiation staan, en je de PC fixed instellen, dan zou je switch vervolgens naar half duplex gaan, en zou het probleem omgekeerd optreden. (Switch gaat naar half, ziet collisions, en je download stort in omdat de switch afbreekt en gaan retransmitten)

Edit:

Then again... Als ik nu hier mijn desktop PC (1Gb kaart aan een gigabit switch) op 1Gbps full duplex zet, gaat mijn switch ook nog steeds naar full duplex... Ik vermoed dat mijn nic driver niet daadwerkelijk auto negotiation helemaal uitzet, maar eerst probeert te negotiaten naar de ingestelde snelheid, want ook met 100Mbit full én half duplex vastgezet, gaat de switch netjes mee, en dat zou niet moeten voor zover ik weet...

Edit 2:
Check in Windows je duplex gewoon eens wanneer je het probleem hebt; In de GUI zie je dat nergens meer terug, maar wel via Powershell"

Dit is wat er bij mij gebeurt wanneer ik mijn switch vastzet op 100Mbit full duplex:

code:

PS C:\Users\Username> Get-Netadapter | Select name,interfacedescription,Linkspeed,fullduplex

name                           interfacedescription                        LinkSpeed fullduplex
----                           --------------------                        --------- ----------
Bluetooth Network Connection 2 Bluetooth Device (Personal Area Network) #2 3 Mbps          True
Ethernet 4                     TAP-NordVPN Windows Adapter V9              1 Gbps          True
Local Area Connection          TAP-Windows Adapter V9 for OpenVPN Connect  1 Gbps          True
Ethernet 2                     Intel(R) Ethernet Connection (7) I219-LM    100 Mbps       False
Ethernet 3                     Intel(R) I210 Gigabit Network Connection    0 bps

Mijn gebruikte adapter is Ethernet 2; je zie dat die nu naar *half* duplex is gegaan. (En doe ik nu een speedtest dan haal ik zo''n 30Mbit, terwijl mijn Ziggo lijntje 1000/50 Mbit is)

[ Voor 43% gewijzigd door SambalBij op 18-03-2023 22:14 ]

[stormfly]

Workaholic schreef op zaterdag 18 maart 2023 @ 21:43:
Er zit een SFP+ DAC tussen

Die is van het UI merk, wel eens een ander merk DAC getest? Ik mis een beetje de mgmt samenvatting in je topic. Je ervaart traagheid over de verbinding tussen je switch en de UDM-SE, en als je de client op fixed 1G zet gaat het wel goed?

[Workaholic]

stormfly schreef op zaterdag 18 maart 2023 @ 21:46:
[...]


Die is van het UI merk, wel eens een ander merk DAC getest? Ik mis een beetje de mgmt samenvatting in je topic. Je ervaart traagheid over de verbinding tussen je switch en de UDM-SE, en als je de client op fixed 1G zet gaat het wel goed?

neen - zou ik wel kunnen proberen. Zie mijn laatste afbeelding voor de management samenvatting

stormfly schreef op zaterdag 18 maart 2023 @ 21:48:
[...]


Ja daar gaat het mis :-)

De rode tekst hoort bij de speedtest foto's?
De linker tabel in het zwarte kader, over welke fysieke porten spreek je dan? Je vult net aan DAC maar dat haal je niet uit de tekening.

Ook wel eens het andere slot gebruikt van de SFP+ sloten? Heb je kunnen aantonen dat hij inzakt op de port naar de UDM? Waarschijnlijk wel omdat je aangeeft dat hij tussen de PC's full speed blijft draaien?

Rode tekst hoort bij speedtest en laat verschil/issue zien. Zwarte kader beschrijft de port settings per device.

Dac type staat beschreven bij de kabel tussen de UDM Se en de Switch en lijntje loopt naar SFP+ porten.

Zou eigenlijk een SFP module naar RJ45 moeten aanschaffen en die op de UDM SE icm 2de PC nic moeten testen. Benieuwd of het al bij de DAC 10G mis gaat of bij de WAN port.

Heb wel allebei de SFP+ porten getest met de DAC kabel. Ik blijf denken dat de verschillende port snelheden door elkaar zorgen voor de problemen (PC 2.5->2.5->10G->2.5G WAN->1G internet)

[ Voor 56% gewijzigd door Workaholic op 18-03-2023 21:59 ]

[stormfly]

Workaholic schreef op zaterdag 18 maart 2023 @ 21:46:
[...]


neen - zou ik wel kunnen proberen. Zie mijn laatste afbeelding voor de management samenvatting

Ja daar gaat het mis :-)

De rode tekst hoort bij de speedtest foto's?
De linker tabel in het zwarte kader, over welke fysieke porten spreek je dan? Je vult net aan DAC maar dat haal je niet uit de tekening.

Ook wel eens het andere slot gebruikt van de SFP+ sloten? Heb je kunnen aantonen dat hij inzakt op de port naar de UDM? Waarschijnlijk wel omdat je aangeeft dat hij tussen de PC's full speed blijft draaien?

[ Voor 26% gewijzigd door stormfly op 18-03-2023 21:50 ]

[stormfly]

Workaholic schreef op zaterdag 18 maart 2023 @ 21:46:
[...]


neen - zou ik wel kunnen proberen. Zie mijn laatste afbeelding voor de management samenvatting


[...]


Rode tekst hoort bij speedtest en laat verschil/issue zien. Zwarte kader beschrijft de port settings per device.

Dac type staat beschreven bij de kabel tussen de UDM Se en de Switch en lijntje loopt naar SFP+ porten.

Zou eigenlijk een SFP module naar RJ45 moeten aanschaffen en die op de UDM SE icm 2de PC nic moeten testen. Benieuwd of het al bij de DAC 10G mis gaat of bij de WAN port.

Heb wel allebei de SFP+ porten getest met de DAC kabel. Ik blijf denken dat de verschillende port snelheden door elkaar zorgen voor de problemen (PC 2.5->2.5->10G->2.5G WAN->1G internet)

Je kan ook een iPerf server op de UTP WAN aansluiting aansluiten, het hoeft niet perse internet te zijn. Zolang het maar routeert. In feite is je pad groot genoeg tot aan je WAN, 2,5 past prima in 10.

Ik heb hier een topton China N5105 box van 180e met pfSense. De 2.5G port traint net als bij jou in met 2.5G naar de ONT van KPN. Ik haal dan 940/940 als ik erachter via mijn Gigabit switch een test doe.

Hoe werkt deze bij jou: (PC 2.5->2.5->1G->2.5G WAN->1G internet) Je verlaagd dan het koppelvlak tussen de UDM-SE en de 24PEnterprise. Je kunt dan nog testen met een 1G utp (lekker snel uit te voeren) of via 2x een SFP van fs.com en een fiber in je SFP+ sloten.

Als deze test, met UTP, aantoont dat je dan ook 940/940 haalt. Dan weet je dat het DAC koppelvlak de oorzaak is. Daarna zou je nog kunnen kijken of het DAC kabel specifiek is of ook met SFP's van 1G of 10G inzakt.

[Workaholic]

Als ik de dac op 1g zet heb ik ook 940/940. Ditzelfde heb ik als ik mijn pc op 1g lock en de dac op 10g laat staan. Dus allebei de scenario’s krijg ik prima 1g throughput. Ook naar het internet. Pas als ik mijn pc op 2.5 zet en hij meer ruimte krijgt gaat het pas mis.

Ik ga jouw tip met iperf op de wan Port is proberen. Daar zou ik ook een 2.5g pc op kunnen aansluiten.

[nero355]

Ben(V) schreef op zaterdag 18 maart 2023 @ 13:32:
Ubiquiti maakt prima wifi spullen met de rest van hun producten voldoen zeker niet aan de prijs die ze ervoor vragen.

De WiFi kent soms ook serieus rare bugs hoor :

[UAP] Fix wired APs occasionally meshing with each other instead of relying on wired uplinks when SFP connections are used between switches.

Hoe krijg je het voor elkaar ?!?!

[_JGC_]

Workaholic schreef op zaterdag 18 maart 2023 @ 22:24:
Als ik de dac op 1g zet heb ik ook 940/940. Ditzelfde heb ik als ik mijn pc op 1g lock en de dac op 10g laat staan. Dus allebei de scenario’s krijg ik prima 1g throughput. Ook naar het internet. Pas als ik mijn pc op 2.5 zet en hij meer ruimte krijgt gaat het pas mis.

Ik ga jouw tip met iperf op de wan Port is proberen. Daar zou ik ook een 2.5g pc op kunnen aansluiten.

Dan nog is het niet vergelijkbaar met de setup die je nu hebt. Ik verwacht dat je test gewoon 2.5Gbit/s naar die PC kan duwen door switch en router heen.
Je probleem zit waarschijnlijk in het gebruik van PPPoE. Je duwt met 2.5Gbit/s een softwarematige buffer vol die met 1Gbit/s wordt leeggetrokken aan de andere kant van de tunnel.

[jadjong]

Workaholic schreef op woensdag 5 oktober 2022 @ 19:50:

Deze optie heb ik gevonden bij global switch settings. Is deze specifiek alleen voor WAN beschikbaar? Dit lijkt het voor alle switches aan te passen - en mogelijk dus niet alleen voor de WAN port ?

Upload probleem blijft met 2.5G icm flow control enabled overigens. Mijn download snelheid lijkt wel iets hoger te zijn, maar dit kan ook een moment opname zijn (zit nu boven de 900 @ speedtest en eerder rond de 800-850). Lees ook wel veel negatieve verhalen over flowcontrol - dus voor nu maar weer uitgeschakeld omdat ik niet kan bevestigen of het echt verschil uitmaakt en het probleem blijft

https://blog.mikeswanson....g-25gbps-with-the-udm-pro

Misschien is deze flow control anders dan de global variant.

[stormfly]

jadjong schreef op zaterdag 18 maart 2023 @ 23:26:
[...]

[Afbeelding]

https://blog.mikeswanson....g-25gbps-with-the-udm-pro

Misschien is deze flow control anders dan de global variant.

https://www.smallnetbuild...trol-is-not-a-good-thing/

[Workaholic]

_JGC_ schreef op zaterdag 18 maart 2023 @ 23:20:
[...]

Dan nog is het niet vergelijkbaar met de setup die je nu hebt. Ik verwacht dat je test gewoon 2.5Gbit/s naar die PC kan duwen door switch en router heen.
Je probleem zit waarschijnlijk in het gebruik van PPPoE. Je duwt met 2.5Gbit/s een softwarematige buffer vol die met 1Gbit/s wordt leeggetrokken aan de andere kant van de tunnel.

Klinkt logisch maar hoe verklaar je dan dat het alleen misgaat bij de upload bij het aanpassen naar 2.5?

jadjong schreef op zaterdag 18 maart 2023 @ 23:26:
[...]

[Afbeelding]

https://blog.mikeswanson....g-25gbps-with-the-udm-pro

Misschien is deze flow control anders dan de global variant.

Thanks - deze had ik ook geprobeerd en helaas geen verschil.

[_JGC_]

Workaholic schreef op zondag 19 maart 2023 @ 07:46:
[...]


Klinkt logisch maar hoe verklaar je dan dat het alleen misgaat bij de upload bij het aanpassen naar 2.5?


[...]


Thanks - deze had ik ook geprobeerd en helaas geen verschil.

Je UDM SE moet PPPoE volledig in software afhandelen, er is geen hardware offlload. Als ik zo wat zoek op dat ding is 2Gbit download en 1Gbit upload het maximale dat je kunt halen op dat ding.

Je probeert 2.5Gbit/s door een pijp van 1Gbit/s te proppen, dat wordt gebufferd en als die buffer vol loopt verdwijnt er verkeer. Dat zorgt voor vertragingen en daardoor klapt je snelheid naar beneden. Waarschijnlijk draait tijdens je test een van de cores ook gewoon 100%.
Je zou het met traffic shaping op kunnen lossen, maar ik gok dat je UDM SE dan helemaal zijn snelheid niet meer haalt.

Niet om Ubiquiti te bashen, maar PPPoE is gewoon een kut protocol en Ubiquiti heeft dat gewoon niet fatsoenlijk voorelkaar. Daarin zijn ze niet de enige. De tunnel draait in software en alle verkeer heeft 1 bron en 1 doel en het is 1 stream met packets. Dat zorgt er ook nog eens voor dat de onderliggende ethernet hardware er niks mee kan qua optimalisatie.

[jadjong]

Workaholic schreef op woensdag 5 oktober 2022 @ 16:44:

Ik heb allebei de zaken los van elkaar getest. Wijzigen van WAN kant naar 1G FDX maakt geen verschil, alleen de desktop naar 1G FDX zetten lost dus het probleem op.

Heb je het originele provider-modem nog? Dan is je WAN 1gpbs (wat geen verschil zou maken) maar hoeft de UDM geen pppoe te doen.

[Workaholic]

Dat heb ik toevallig gisteren ook getest. Maar deze heeft maar 1g porten dus dan kan ik het probleem niet reproduceren.

Ben het overigens eens dat pppoe niet heel fijn is maar ik lees op unify fora dat ze gewoon 2/2 of zelfs 3/3 halen op de udm se.

Ik zie de rx counters ook echt oplopen bij 2.5 ingeschakeld en bij 1g niet. Dus ik blijf er bij dat die verschillende Port snelheden zorgen voor issues. De vraag is of dit normaal is of dat de apparaten dit zouden moeten opvangen.

Ga morgen even een 2.5 pc aan de wan Port aansluiten en iperf draaien zodat we pppoe kunnen uitsluiten. Vandaag niet thuis. Heel fijn dat jullie zo meedenken ☺️

[ Voor 5% gewijzigd door Workaholic op 19-03-2023 08:33 ]

[Workaholic]

Aanvulling:

Uitgevonden dat ik IPERF3 op de shell van de UDM SE kon draaien als server.
Dit geeft nu:



Lijkt er dus op dat we de DAC kunnen uitsluiten? Gaat pas mis als we de WAN interface benaderen? Dus PPPOE issue of de port snelheid 2.5G vs 10G dac? Wat denken jullie? Wat zijn jullie conclusies o.b.v. deze results?

edit:

zie nog wel rx dropped toenemen wanneer ik iperf draai tussen UDM SE en LAN 2.5G client. (ik test dus 10G dac hiermee)



Lijkt mij ook niet goed.

[ Voor 32% gewijzigd door Workaholic op 19-03-2023 12:23 ]

[CirclDigital]

Workaholic schreef op zondag 19 maart 2023 @ 12:06:
Wat zijn jullie conclusies o.b.v. deze results?

Mijn conclusie is eigenlijk dat je niet alleen je eigen tijd aan het verspillen bent maar ook de onze :-).

Zinloos al die testen als je maar 1x 2,5G apparaat hebt. Dan test je helemaal niets zinvols behalve wat buffers hier en daar. Oftewel zorg voor minstens 2x een 2,5G aansluiting waarbij je zinvol datatransfers zinvol kan testen of blijf alles gewoon op 1G gebruiken.

Je bent nu al maanden een beetje theoretisch aan het prutsen zonder enige praktische waarde.

[ Voor 8% gewijzigd door CirclDigital op 19-03-2023 12:23 ]

[Workaholic]

CirclDigital schreef op zondag 19 maart 2023 @ 12:22:
[...]

Mijn conclusie is eigenlijk dat je niet alleen je eigen tijd aan het verspillen bent maar ook de onze :-).

Zinloos al die testen als je maar 1x 2,5G apparaat hebt. Dan test je helemaal niets zinvols behalve wat buffers hier en daar. Oftewel zorg voor minstens 2x een 2,5G aansluiting waarbij je zinvol datatransfers zinvol kan testen of blijf alles gewoon op 1G gebruiken.

Je bent nu al maanden een beetje theoretisch aan het prutsen zonder enige praktische waarde.

Waarom is het zinloos?

- Als KPN meer dan 1G fiber gaat aanbieden kan ik het niet gebruiken zonder problemen
- Ik kan mijn 2.5G connectie niet gebruiken op mijn pc zonder dat mijn upload instort
- Lagere fiber snelheid door 1G overhead wanneer ik geen 2.5g gebruik (ONT 2.5G port scheelt +-50Mb)
- Principieel super vervelend als je een 2.5G switch en 2.5G firewall koopt die ik moet limiteren tot 1G.
- NAS heeft meerdere 1G porten in LACP waar ik niets aan heb als DAC gaat beperken tot 1G

[ Voor 8% gewijzigd door Workaholic op 19-03-2023 12:32 ]

[CirclDigital]

Allemaal onzin argumenten die NU helemaal niet van toepassing zijn.
Je hebt gewoon niets op 2,5G behalve 1 NIC en dat is dus totaal zinloos.

Koop een 2e 2,5G apparaat en test dan iets zinvols. En dan werkt het natuurlijk gewoon.

[jadjong]

Workaholic schreef op zondag 19 maart 2023 @ 08:31:
Dat heb ik toevallig gisteren ook getest. Maar deze heeft maar 1g porten dus dan kan ik het probleem niet reproduceren.

Zoals ik het lees heb je met de UDM fixed op 1Gbps en pppoe problemen. Maar met het KPN modem er tussen, dus 1Gbps zonder pppoe op de UDM, geen problemen. Klopt dat?

[stormfly]

Workaholic schreef op zondag 19 maart 2023 @ 12:06:
Aanvulling:

Uitgevonden dat ik IPERF3 op de shell van de UDM SE kon draaien als server.
Dit geeft nu:

[Afbeelding]

Lijkt er dus op dat we de DAC kunnen uitsluiten? Gaat pas mis als we de WAN interface benaderen? Dus PPPOE issue of de port snelheid 2.5G vs 10G dac? Wat denken jullie? Wat zijn jullie conclusies o.b.v. deze results?

edit:

zie nog wel rx dropped toenemen wanneer ik iperf draai tussen UDM SE en LAN 2.5G client. (ik test dus 10G dac hiermee)

[Afbeelding]

Lijkt mij ook niet goed.

Heb je flow control overal ingeschakeld? Kan per device maar ook generiek in 7.x controllers.

[nero355]

jadjong schreef op zondag 19 maart 2023 @ 08:21:
Heb je het originele provider-modem nog?

Dan is je WAN 1gpbs (wat geen verschil zou maken) maar hoeft de UDM geen pppoe te doen.

Het is een Glasvezel verbinding en daarvoor heeft KPN in ieder geen optie om de ExperiaBox als een Passthrough Modem te gebruiken zoals men dat deed op KPN xDSL verbindingen op basis van een DrayTek 130/160/165 model :
- DrayTek bouwt de PPPoE verbinding op en schuift het IP adres door naar de Router.
- De Router doet dan het NATten en alles.

Ik geloof dat er zelfs een ExperiaBox V8 was die ook zoiets kon, maar die is niet meer leverbaar...


Verder vind ik dit echt een verschrikkelijke reactie :

CirclDigital schreef op zondag 19 maart 2023 @ 12:22:
Mijn conclusie is eigenlijk dat je niet alleen je eigen tijd aan het verspillen bent maar ook de onze :-).

Zinloos al die testen als je maar 1x 2,5G apparaat hebt. Dan test je helemaal niets zinvols behalve wat buffers hier en daar. Oftewel zorg voor minstens 2x een 2,5G aansluiting waarbij je zinvol datatransfers zinvol kan testen of blijf alles gewoon op 1G gebruiken.

Je bent nu al maanden een beetje theoretisch aan het prutsen zonder enige praktische waarde.

CirclDigital schreef op zondag 19 maart 2023 @ 12:39:
Allemaal onzin argumenten die NU helemaal niet van toepassing zijn.
Je hebt gewoon niets op 2,5G behalve 1 NIC en dat is dus totaal zinloos.

Koop een 2e 2,5G apparaat en test dan iets zinvols. En dan werkt het natuurlijk gewoon.

- Waar zou iemand niet volledig zijn eigen hardware mogen benutten
- Niemand dwingt je om in dit Topic actief te zijn...

[jadjong]

nero355 schreef op zondag 19 maart 2023 @ 18:23:
[...]

Het is een Glasvezel verbinding en daarvoor heeft KPN in ieder geen optie om de ExperiaBox als een Passthrough Modem te gebruiken

Dubbel NAT is voor de test niet erg.

[laurens0619]

Waarom die focus op pppoe?
Als alles op gigabit geforceerd staat dan haalt die gewoon gigabit. Wat is de relevantie van pppoe dan?

Het gaat schijnbaar mis als die van 2.5 naar 1 moet gaan. Dat een speedtest goed gaat naar de router is een 2.5 <> 2.5 dus daar gaat die idd goed.

[nero355]

jadjong schreef op zondag 19 maart 2023 @ 18:33:
Dubbel NAT is voor de test niet erg.

Volgens mij gaat dat niks uithalen, want 1 Gbps poorten op die ExperiaBox voor zover ik weet

Wat mij veel interessanter lijkt :
Dezelfde opstelling bij iemand die @Workaholic kent en toevallig iets van Delta/Caiway/T-Mobile/Helden van Nu/Online.nl heeft die ook een ONT gebruiken die 2,5 Gbps of zelfs sneller aan kan, maar geen PPPoE gebruiken!

Maar dan moet je dus wel gek genoeg zijn om ALLES mee te nemen richting een vriend/kennis/collega om het bij hem/haar thuis te testen!

laurens0619 schreef op zondag 19 maart 2023 @ 18:33:
Waarom die focus op pppoe?
Als alles op gigabit geforceerd staat dan haalt die gewoon gigabit. Wat is de relevantie van pppoe dan?

Omdat het niet de eerste keer zou zijn dat er een fout in de PPPoE toestand van Ubiquiti zit : Zowel de Edge als de UniFi reeks heeft dat soort problemen gekend!

Het gaat schijnbaar mis als die van 2.5 naar 1 moet gaan.

Het zou me niet verbazen als er dus iets van Buffering verkeerd gaat i.c.m. PPPoE

[jadjong]

nero355 schreef op zondag 19 maart 2023 @ 18:56:
[...]

Volgens mij gaat dat niks uithalen, want 1 Gbps poorten op die ExperiaBox voor zover ik weet

Jep, maar als hij de WAN SFP op 1Gbps vast zet (zonder Experia er tussen) blijft het probleem bestaan. Daarom WAN via Experia proberen, dan heb je welliswaar ook de UDM WAN op 1Gbps, maar zonder pppoe.
Deze test zal uitslag geven of het wel/niet door pppoe komt. Beetje hetzelfde als jouw idee om de hele setup naar de buren te verhuizen, maar dan zonder te verhuizen.

[nero355]

jadjong schreef op zondag 19 maart 2023 @ 19:06:
Jep, maar als hij de WAN SFP op 1Gbps vast zet (zonder Experia er tussen) blijft het probleem bestaan. Daarom WAN via Experia proberen, dan heb je welliswaar ook de UDM WAN op 1Gbps, maar zonder pppoe.
Deze test zal uitslag geven of het wel/niet door pppoe komt.

Er is geen WAN SFP/SFP+ aanwezig : Workaholic in "2.5GB Performance issue i.c.m. Ubiquiti en KPN Glasvezel"

Beetje hetzelfde als jouw idee om de hele setup naar de buren te verhuizen, maar dan zonder te verhuizen.

Ik weet ook wel dat het gestoord klinkt hoor, maar ik zou het wel de ultieme test vinden!

[CirclDigital]

nero355 schreef op zondag 19 maart 2023 @ 18:23:
[...]
Verder vind ik dit echt een verschrikkelijke reactie :
- Waar zou iemand niet volledig zijn eigen hardware mogen benutten
- Niemand dwingt je om in dit Topic actief te zijn...

Dat mag, maar ik vindt die van jou een stuk irritanter....

We hebben hier te maken met iemand die welgeteld 1x een 2,5 nic heeft en dan een beetje data zijn infrastructuur in zit te pompen terwijl er nergens een ontvanger is die die snelheid aankan. Wat test je dan? Helemaal niets. En dat al met een doorlooptijd van zo'n 5 maanden sinds de initiële post....aanmoedigen van dit soort onzin is gewoon tijd verdoen van iedereen hier.

Er is dus helemaal geen sprake van niet volledig hardware gebruiken, want hij zit gewoon op max 1G met alles. Zet er een 2e apparaat in die ook 2,5G ondersteund en dan is testen pas zinvol, nu totaal niet.

Maar dat zie je vaak in netwerk onderwerpen..... enige praktische insteek gaat al snel het raam uit.

[ Voor 6% gewijzigd door CirclDigital op 20-03-2023 10:38 ]

[AzertyNL]

Toevallig ontdekte ik dit topic heel recent, en wil gezien hoe de discussie zich ontwikkelt een poging doen een constructieve bijdrage te leveren. (Want het werd er niet gezeliiger op recentelijk

CirclDigital schreef op maandag 20 maart 2023 @ 09:45:
[...]

We hebben hier te maken met iemand die welgeteld 1x een 2,5 nic heeft en dan een beetje data zijn infrastructuur in zit te pompen terwijl er nergens een ontvanger is die die snelheid aankan.

CirclDigital heeft mijn inziens wel een punt.

Hier wordt gemeten aan een sequentiele keten (de datapijp) die uit vele onderdelen bestaat (hardware en software (voor pppoe en allerlei softwarematige geheugenbuffermechanismes onderweg).
Het uitganspunt in de discussie lijkt dat de 1 gbit link de beperkende factor is, en dus de te verwachten (maximale) throughput is.

Maar als je deze keten een vuurdoop geeft door hem met 2.5gbit te 'voeren', creeer je allerlei (theoretische) rand effecten die het analyseren van de oorzaak heel moeilijk kunnen maken. Door meer data aan te leveren (2.5gbit/s) dan de pijp zo wie zo aankan (max 1gbit/s) zal je op allerlei plekken in de keten waar buffers gebruikt worden, deze waarschijnlijk doen vollopen. Het gedrag van de software (of firmware) die deze buffers beheren kan zich totaal anders gaan gedragen dan in de 'normale' situatie waar de datastroom niet tot buitensporig buffer 'management' gedrag leidt. Het kost meer rekenkracht van processoren en/of er wordt data gedropt omdat buffers vollopen en/of flow control mechanismes worden aan/uit geschakeld (kan soort van 'pendel'gedrag in de data stroom teweegbrengen).
Ik ken voorbeelden waar 'bufferbloat' (google de term eventueel als die niet bekend is) de 'gekste' effecten teweegbrengt, zoals toe- en afnemende snelheden, halveren van de maximaal theoretishc haalbare snelheid, starvation (0bit/s).

CirclDigital schreef op maandag 20 maart 2023 @ 09:45:
Wat test je dan? Helemaal niets.

Het punt wat ik wil maken is dit:
Als je wil ontdekken wat de oorzaak is dat de datapijp met een 2.5 gbit 'stuk' een lagere netto doorvoersnelheid oplevert dan een datapijp met enkel 1gbit is het huidige experiment (zoals CirclDigital betoogt) niet ideaal. Ja, het is prut dat een 2.5gbit component een lagere netto doorvoer tot gevolg heeft dan als je enkel 1gbit NICs, maar met de beperkte spullen (geen 2.5gbit in EN uit) is de puzzel om te vinden waar de oorzaak ligt wel heel moeilijk volgens mij.

Dus hoog over gezegd, als je een keten zwaar op de proef stelt door hem te overbelasten (2.5 gbit/s 'in'), ontdek je snel of je gewoon de logische doorvoersnelheid krijgt van de verwachtte zwakste keten in de component (1gbit/s), of dat er een verrassing opduikt (flink lagere snelheid dan 1gbit/s). En als dat laatste het geval is (zoals in deze threat gedemonstreerd) dan is het zoeken naar de oorzaak best vaak een enorme challenge waarbij je soms enorm veel zal ontdekken en leren over onzichtbare complexiteit. Het grootste plezier dat je jezelf kan doen om zo'n puzzel oplosbaar te maken (vinden van de 'echte' oorzaak) is vereenvoudigen van de keten. En beginnen met 2.5gbit in EN uit is m.i. een goede suggestie.

(een groot deel van mijn tijd van mijn ICT loopbaan is in een zwart gat verdwenen met trouble shooten van congestie issues in veel-laags (infiniband) netwerken )

[Workaholic]

Vanochtend nog wat interessante tests gedaan met een local iperf client en server op de UDM SE:

UDM SE -> public iperf server met optie -R (download)

code:

[SUM]   0.00-10.00  sec  1.17 GBytes  1.01 Gbits/sec  745             sender
[SUM]   0.00-10.00  sec  1.16 GBytes   996 Mbits/sec                  receiver

UDM SE -> public iperf server zonder optie -R (upload)

code:

[SUM]   0.00-10.00  sec   271 MBytes   227 Mbits/sec  317             sender
[SUM]   0.00-10.00  sec   269 MBytes   226 Mbits/sec                  receiver

PC 2.5G -> public iperf server met optie -R (download)

code:

[SUM]   0.00-10.00  sec  1.17 GBytes  1.01 Gbits/sec  148             sender
[SUM]   0.00-10.00  sec  1.17 GBytes  1.00 Gbits/sec                  receiver

PC 2.5G -> public iperf server zonder optie -R (upload)

code:

[SUM]   0.00-10.00  sec   389 MBytes   326 Mbits/sec                  sender
[SUM]   0.00-10.00  sec   387 MBytes   325 Mbits/sec                  receiver

PC 2.5G -> UDM SE local iperf server met optie -R (download)

code:

[SUM]   0.00-10.00  sec  2.55 GBytes  2.19 Gbits/sec  7572             sender
[SUM]   0.00-10.00  sec  2.54 GBytes  2.19 Gbits/sec                  receiver

PC 2.5G -> UDM SE local iperf server zonder optie -R (upload)

code:

[SUM]   0.00-10.00  sec  2.76 GBytes  2.37 Gbits/sec                  sender
[SUM]   0.00-10.00  sec  2.76 GBytes  2.37 Gbits/sec                  receiver

Bij de eerste twee tests gaat de traffic direct vanaf de firewall 2.5G WAN port naar > 2.5G ONT -> KPN.
Bij de PC test, test ik zowel de public als de local server vanaf de PC kant over 2.5G. Hier zie je duidelijk dat tussen PC -> Switch -> DAC -> Firewall het goed gaat (eens?) en pas bij de WAN port / internet het misgaat.

Nadat ik nog wat fora heb doorgelezen lijkt het mogelijk aan de brakke MTU implementatie van de UDM SE te liggen. Deze kun je niet wijzigen in de laatste versie, ook niet via CLI. Dus ik heb maar een MTU van 1492:

code:

ifconfig
ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1492
        inet 86.xx.xx.xx  netmask 255.255.255.255  destination 195.190.228.xx
        ppp  txqueuelen 3  (Point-to-Point Protocol)
        RX packets 11082256  bytes 14762828439 (13.7 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 8984727  bytes 7883876459 (7.3 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Straks even de Experia box er tussen zetten en dus PPPOE op de UDM SE uitschakelen. Enige uitdaging is dan dat de UDM SE niet meer op 2.5G connect aan de wan kant, maar op 1G omdat de Experia box helaas geen 2.5g porten heeft.

[laurens0619]

@Workaholic
mooi getest, dat je poort naar 1G gaat zou niet uit moeten maken want je postte eerder

- de WAN verbinding tussen UDM SE (WAN RJ45 2.5G) loopt direct naar de NTU en deze geeft een link van 2.5G. Als ik deze op 1G vastzet aan de UDM SE kant blijft het probleem aanwezig.

Benieuwd wat de performance gaat zijn met experiabox ertussen

[Workaholic]

laurens0619 schreef op maandag 20 maart 2023 @ 11:29:
@Workaholic
mooi getest, dat je poort naar 1G gaat zou niet uit moeten maken want je postte eerder

- de WAN verbinding tussen UDM SE (WAN RJ45 2.5G) loopt direct naar de NTU en deze geeft een link van 2.5G. Als ik deze op 1G vastzet aan de UDM SE kant blijft het probleem aanwezig.

Eens -> ik heb de WAN port even op 1G gezet en de iperf vanaf UDM SE -> public iperf server zijn gelijk. Dus dat lijkt geen verschil te maken.

Bovenstaande tests laten iig wel zien dat de DAC / switch en interne communicatie wel netjes 2.5G laat zien zonder problemen. Straks even de experiabox aansluiten.

[ Voor 13% gewijzigd door Workaholic op 20-03-2023 11:35 ]

[laurens0619]

Die reactie die je had op he ubiquiti forum begrijp ik trouwens niet helemaal, daar lijk ik te lezen "as intended".

@WorkaholicNL the issue is what I said it was. your connection from the client is trying to push more then 1g up on the path until it gets choked down at the wan. the tcp window closes, and does not open again for whatever reason (who knows what is in the speedtest code). the reason it works with the pc at 1g or the 10g dac at 1g is the path is choked to the wan speed before the wan so no congestion collapse. put something on the wan side that can push more then 1g and run a test and it will work fine.

this is the correct answer. if you want to verify hook a pc up to the wan port at 2.5g or above and run iperf.

there is no bug here. having an understanding of ethernet switching and tcp/ip behavior gives the answer.

Ik snap wat die zegt maar waarom heb ik dat issue dan niet bij bv mijn 100mbit internet verbinding?
Dan komt data toch ook, bij de upload, met een gigabit aan bij de router en hem daarna maar met 100mbit kwijt kan? Of komt dat omdat de link naar de ethernet converter ook 1gbit is?

[jadjong]

laurens0619 schreef op maandag 20 maart 2023 @ 11:42:
Die reactie die je had op he ubiquiti forum begrijp ik trouwens niet helemaal, daar lijk ik te lezen "as intended".


[...]


Ik snap wat die zegt maar waarom heb ik dat issue dan niet bij bv mijn 100mbit internet verbinding?
Dan komt data toch ook, bij de upload, met een gigabit aan bij de router en hem daarna maar met 100mbit kwijt kan? Of komt dat omdat de link naar de ethernet converter ook 1gbit is?

Ben(V) schreef op zaterdag 4 september 2021 @ 11:36:
Dit zou het moeten zijn:

MTU van PPPoE op 1500
Die van Vlan 6 op 1508
Die van de bovenliggende interface op 1512

Mogelijk dat de UDM zich verslikt in de combi van te veel data+omklussen MTU, maar dat eentje van de twee geen probleem is.
KPN rekent met 1492(data)+8(pppoe)+8(vlan)=1508
Ubitity lijkt te rekenen met 1492-8(pppoe)-8(vlan)=1476(data)

[Workaholic]

@jadjong interessant. Ik heb het volgende script gevonden op het Ubiquiti forum. MTU gegevens lijken hetzelfde te zijn als @Ben(V) heeft doorgegeven?:

code:

sed -i 's/ 1492/ 1500/g' /etc/ppp/peers/ppp0

ip link set dev eth8 mtu 1512 && ip link set dev eth8.6 mtu 1508

ifconfig eth8 down && ifconfig eth8 up

killall pppd

laurens0619 schreef op maandag 20 maart 2023 @ 12:12:
welke interface heb je niet?
In het script zie ik dat ze refereren aan eth 8.6 en via google begrijp ik dat op de udm pro eth 8 == wan1. KPN internet zit op vlan 6 dus die 8.6 klinkt logisch,

Ook kijkende naar de hoeveel traffic lijkt dat je wan poort. Of begrijp ik je niet?

Deze werkt wel - had een tikfout gemaakt. Excuses. Post aangepast. Script werkt maar nog steeds geen verschil in upload. Vraag is nu even of de MTU getallen in het script juist zijn.

[ Voor 247% gewijzigd door Workaholic op 20-03-2023 12:16 ]

[laurens0619]

welke interface heb je niet?
In het script zie ik dat ze refereren aan eth 8.6 en via google begrijp ik dat op de udm pro eth 8 == wan1 (neem aan hetzelfde op de se?). KPN internet zit op vlan 6 dus die 8.6 klinkt logisch,

Ook kijkende naar de hoeveel traffic lijkt dat je wan poort. Of begrijp ik je niet?

[ Voor 5% gewijzigd door laurens0619 op 20-03-2023 12:13 ]

[jadjong]

Workaholic schreef op maandag 20 maart 2023 @ 12:04:
@jadjong interessant. Ik heb het volgende script gevonden op het Ubiquiti forum. MTU gegevens lijken hetzelfde te zijn als @Ben(V) heeft doorgegeven?:

code:

sed -i 's/ 1492/ 1500/g' /etc/ppp/peers/ppp0

ip link set dev eth8 mtu 1512 && ip link set dev eth8.6 mtu 1508

ifconfig eth8 down && ifconfig eth8 up

killall pppd

Maar ik heb deze interface niet. Is anders op een UDM SE lijkt het. Wel staat PPP0 er tussen, maar de bovenliggende interface en vlan ontbreekt. Enige idee?


eth8.6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::72a7:41ff:fe62:e01 prefixlen 64 scopeid 0x20<link>
ether 70:a7:41:62:0e:01 txqueuelen 1000 (Ethernet)
RX packets 95034926 bytes 122249701489 (113.8 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 48545741 bytes 33010035402 (30.7 GiB)
TX errors 0 dropped 205 overruns 0 carrier 0 collisions 0

[Workaholic]

jadjong schreef op maandag 20 maart 2023 @ 12:13:
[...]

Dank - script werkt.

code:

eth8: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1512
        inet6 fe80::7xx  prefixlen 64  scopeid 0x20<link>
        ether 70:a7:xx  txqueuelen 1000  (Ethernet)
        RX packets 21369625  bytes 28922209058 (26.9 GiB)
        RX errors 0  dropped 4  overruns 0  frame 0
        TX packets 15326853  bytes 13111163322 (12.2 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 48

eth8.6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1508
        inet6 fe80::xx  prefixlen 64  scopeid 0x20<link>
        ether 70:a7:41xx  txqueuelen 1000  (Ethernet)
        RX packets 21369448  bytes 28623024396 (26.6 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 15326354  bytes 13111079617 (12.2 GiB)
        TX errors 0  dropped 65 overruns 0  carrier 0  collisions 0

ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 86.xx  netmask 255.255.255.255  destination 195.190.228.153
        ppp  txqueuelen 3  (Point-to-Point Protocol)
        RX packets 2457769  bytes 3153160515 (2.9 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1523420  bytes 1290866123 (1.2 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Helaas van UDM Se -> public iperf server nog steeds lage upload snelheid. Dus geen verschil.

UDM SE -> Public iperf zonder optie r (upload)

code:

[SUM]   0.00-10.00  sec   344 MBytes   289 Mbits/sec  104             sender
[SUM]   0.00-10.00  sec   342 MBytes   287 Mbits/sec                  receiver

UDM SE -> Public iperf met optie r (download)

code:

[SUM]   0.00-10.00  sec  1.11 GBytes   951 Mbits/sec  204             sender
[SUM]   0.00-10.00  sec  1.09 GBytes   933 Mbits/sec                  receiver

@Ben(V) heb jij nog suggesties? wat te doen met mss clamping? Uit of aan? Of naar custom en zo ja welk nummer met bovenstaande MTU aanpassingen?

Ga de experiabox maar is aansluiten zo dan weten we zeker dat het aan de PPPOE instellingen van de UDMSE ligt.

[ Voor 20% gewijzigd door Workaholic op 20-03-2023 14:39 ]

[nero355]

AzertyNL schreef op maandag 20 maart 2023 @ 10:50:
Dus hoog over gezegd, als je een keten zwaar op de proef stelt door hem te overbelasten (2.5 gbit/s 'in')

Je overbelast helemaal niks!

Volgens jullie logica zou ik vroeger mijn KPN xDSL lijntje overbelasten met mijn 1 Gbps netwerk en had ik alle Clients op een 60/30 Mbps snelheid vast moeten zetten of iets van Traffic Shaper ervoor moeten zetten

Kom op zeg...

Dit is gewoon het zoveelste voorbeeld van halvegare implementaties van Ubiquiti IMHO en de reactie die @laurens0619 quote vanaf hun forum is IMHO gewoon dikke onzin!
Allemaal grote bedrijven die het zich lekker makkelijk willen maken en gauw van hun klanten af willen...

Workaholic schreef op maandag 20 maart 2023 @ 11:24:
Straks even de Experia box er tussen zetten en dus PPPOE op de UDM SE uitschakelen.

Enige uitdaging is dan dat de UDM SE niet meer op 2.5G connect aan de wan kant, maar op 1G omdat de Experia box helaas geen 2.5g porten heeft.

Ik vraag me af of je een 2.5 Gbps WAN Poort goed zou simuleren door de boel via je Switch te laten lopen in een VLAN Only netwerkje

Je zit dan namelijk weer met een stukje buffering door weer een extra apparaat in de keten...

laurens0619 schreef op maandag 20 maart 2023 @ 11:42:
Die reactie die je had op he ubiquiti forum begrijp ik trouwens niet helemaal, daar lijk ik te lezen "as intended".

[...]

Dat is dus echt onzin praat vanuit Ubiquiti

Ik snap wat die zegt maar waarom heb ik dat issue dan niet bij bv mijn 100mbit internet verbinding?
Dan komt data toch ook, bij de upload, met een gigabit aan bij de router en hem daarna maar met 100mbit kwijt kan? Of komt dat omdat de link naar de ethernet converter ook 1gbit is?

Precies mijn punt!

Als een € 200 kostende xDSL Router het kan dan moet een € 400 kostende 10 Gbps Router dat ook gewoon kunnen!

Dit is gewoon het zoveelste halvegare probleem met die hele UDR/UDM/UXG reeks en ik geloof dat @Workaholic of iemand anders zelfs in het begin nog een USG Pro ervoor had staan puur omdat de PPPoE implementatie of meerdere IP's aan de WAN kant niet mogelijk was en tot op de dag van vandaag nog steeds niet mogelijk is!
Ronduit BELACHELIJK!!!

Workaholic schreef op maandag 20 maart 2023 @ 12:20:

code:

Haal effe alle MAC en IP adressen weg in dit blok!

Helaas van UDM Se -> public iperf server nog steeds lage upload snelheid. Dus geen verschil.

Wat te doen met mss clamping? Uit of aan?

Volgens mij was dat sowieso een workaround voor niet aanpasbare MTU waardes dus je zou het eens kunnen proberen

Ga de experiabox maar is aansluiten zo dan weten we zeker dat het aan de PPPOE instellingen van de UDMSE ligt.

Laten we het hopen...

[Workaholic]

Ok experia box aangesloten maar ik voel me nu echt een noob, maar krijg hem niet aan de praat icm de UDM SE. Om het topic niet verder te vervuilen zal ik dit even in het ubiquiti topic plaatsen.

Edit: krijg de experia box niet tussen de ONT - UDM SE omdat de ip range hetzelfde is en de experiabox ip mag je niet aanpassen (zucht )

Experiabox geeft geen issues zoals verwacht tussen client op 2.5G en Experiabox. Maar ik heb nu alle unify apparatuur er tussenuit.

[ Voor 17% gewijzigd door Workaholic op 20-03-2023 15:05 ]

[jadjong]

Workaholic schreef op maandag 20 maart 2023 @ 12:20:

@Ben(V) heb jij nog suggesties? wat te doen met mss clamping? Uit of aan? Of naar custom en zo ja welk nummer met bovenstaande MTU aanpassingen?

Ga de experiabox maar is aansluiten zo dan weten we zeker dat het aan de PPPOE instellingen van de UDMSE ligt.

Zie deze:
https://www.cisco.com/c/e...-MSS-Adjustment-Conc.html

Met MSS clamping kan je de payload(daadwerkelijke data) de goede richting op sturen.
Als je max MTU 1500 is en je zowel vlan als pppoe nodig hebt mag je van 1500 56 af trekken.

Echter hanteert KPN om die redenen al een hoge MTU waardoor je met 1492 (MSS 1452) prima uit komt. Het is dus de kunst om de MTU van de UDM pppoe&vlan interface op te rekken zodat die boven de standaard 1500 uit komt. Dat heb je al gedaan en lijkt niet te werken.

Workaholic schreef op maandag 20 maart 2023 @ 14:43:
Ok experia box aangesloten maar ik voel me nu echt een noob, maar krijg hem niet aan de praat icm de UDM SE. Om het topic niet verder te vervuilen zal ik dit even in het ubiquiti topic plaatsen.

Experiabox geeft geen issues zoals verwacht tussen client op 2.5G en Experiabox. Maar ik heb nu alle unify apparatuur er tussenuit.

Zit je vlan tag nog op de WAN? MTU weer terug gezet op 1500?

[Workaholic]

Ok experia box getest met UDM SE er tussen. Dus Experia box pakt het PPPOE deel op.
Ik haal hier gewoon 1GB up/down mee via de unify infrastructuur.

code:

[SUM]   0.00-10.00  sec  1.11 GBytes   950 Mbits/sec   10             sender
[SUM]   0.00-10.00  sec  1.09 GBytes   936 Mbits/sec                  receiver

code:

[SUM]   0.00-10.00  sec  1.11 GBytes   950 Mbits/sec   10             sender
[SUM]   0.00-10.00  sec  1.09 GBytes   936 Mbits/sec                  receiver

Het zit hem dus in de PPPOE en/of MTU combinatie eens?

[ Voor 7% gewijzigd door Workaholic op 20-03-2023 15:46 ]

[laurens0619]

Dan moet ik @nero355 toch gelijk geven
Ik weet dat ubiquiiti en PPPOE geen beste combinatie is maar ik had niet verwacht dat op 1gbit pppoe wel goed zou functioneren maar op 2.5 niet. Je zou verwachten dat die buffering of wat dan ook los van pppoe staat.

Weet je heel zeker dat deze test goed was gegaan?

- de WAN verbinding tussen UDM SE (WAN RJ45 2.5G) loopt direct naar de NTU en deze geeft een link van 2.5G. Als ik deze op 1G vastzet aan de UDM SE kant blijft het probleem aanwezig.

Je zou deze test nog kunnen herhalen door er een simpele 1gbit switch tussen te zetten, dan weet je zeker dat de interface op gigabit zit.

[Workaholic]

@laurens0619 ik moet je toch (Deels) gelijk geven.

Indien ik de RJ45 WAN port op 1G vastzet i.p.v. 2.5G auto is het probleem (deels) weg (upload snelheid lijkt in het begin goed, daarna stort het weer in). Voor alle duidelijkheid ik heb dan de client op 2.5 staan en is de enige aanpassing dus de WAN kant.

Dan kom ik nu uit op drie conclusies, benieuwd of jullie het met mij eens zijn en of er nog aanvullingen zijn, dan kan dit naar Unify support.

1) 2.5G or auto-negotiation set on UDM SE in combination with PPPOE provides issues with upload. Flow control or change of MTU does not solve the issue. Not sure what the cause is here, but when limiting the WAN interface to 1G FDX I have less issues (but am capped to 1G with my 1000/1000 fiber connection). Only when going back to 1g on the client side the issue is solved.

2) The issue is not between the 24 POE enterprise, DAC cable + UDM SE or with the local clients. Running iperf on the UDM SE and doing test to 2.5G clients show no issues and full bandwidth available up/down. Limiting the RJ45 on the WAN interface to 1G seems to be the best temporary solution to allow 2.5G traffic on the LAN side.

3) not being able to configure the MTU size is something that Unify should add as a setting. I am seeing dropped packets unless I change the MTU via CLI, but this doesn't remain after reboot.

_JGC_ schreef op maandag 20 maart 2023 @ 16:04:
@Workaholic Uit je startpost:

[...]
Spreek je jezelf nu niet een beetje tegen met je laatste reactie?

Ja - of ik heb hier niet goed getest (excuses) of het ging toen echt ook mis. Kan ik nu niet reproduceren.

Punt blijft wel staan dat ik mede dankzij jullie hulp nu zeker weet dat het aan de PPPOE implementatie ligt en alle toekomstige KPN fiber users handmatig de RJ45 port moeten terugschroeven als ze dus de nieuwe ONT modellen hebben (die op 2.5G staan).

[ Voor 40% gewijzigd door Workaholic op 20-03-2023 16:22 ]

[_JGC_]

@Workaholic Uit je startpost:

- de WAN verbinding tussen UDM SE (WAN RJ45 2.5G) loopt direct naar de NTU en deze geeft een link van 2.5G. Als ik deze op 1G vastzet aan de UDM SE kant blijft het probleem aanwezig.

Spreek je jezelf nu niet een beetje tegen met je laatste reactie?

[Workaholic]

Zie aanvulling hierboven.

Ik zie nu dat de upload snelheid weer terugloopt na meerdere keren testen. Ik denk toch dat er iets niet goed zit met die buffers/MTU settings - gaat dus zelfs met 1G niet helemaal soepel.

Conclusie is in iedere geval dat de PPPOE implementatie nog niet helemaal goed werkt icm 1000/1000 fiber op een UDM SE en ik nu dus weer terug bij af ben en alleen bij het terugschakelen naar 1G op mijn desktop - het probleem volledig weg is.

Ik geef het maar op voor nu.. Dank voor jullie geduld en inzet in iedere geval!

[ Voor 45% gewijzigd door Workaholic op 20-03-2023 16:20 ]

[nero355]

Workaholic schreef op maandag 20 maart 2023 @ 16:02:
Indien ik de RJ45 WAN port op 1G vastzet i.p.v. 2.5G auto is het probleem weg. Voor alle duidelijkheid ik heb dan de client op 2.5 staan en is de enige aanpassing dus de WAN kant.

Volgens mij was je daar al achter maar is het een beetje verzopen tussen de rest van de reacties

Dan kom ik nu uit op twee conclusies, benieuwd of jullie het met mij eens zijn en of er nog aanvullingen zijn, dan kan dit naar Unify support.

1) 2.5G or auto-negotiation set on UDM SE in combination with PPPOE provides issues with upload. Flow control or change of MTU does not solve the issue. Not sure what the cause is here, but when limiting the interface to 1G FDX I have no issues (but am capped to 1G with my 1000/1000 fiber connection).

Deels eens :
- Flow Control is volgens @stormfly een verhaal apart en op meerdere manieren in te stellen dus kijk dat nog eens goed na!
- Wat doet MSS Clamping nou wel/niet in dit hele verhaal ?!

2) The issue is not between the 24 POE enterprise, DAC cable + UDM SE or with the local clients. Running iperf on the UDM SE and doing test to 2.5G clients show no issues and full bandwidth available up/down. Limiting the RJ45 on the WAN interface to 1G seems to be the best temporary solution to allow 2.5G traffic on the LAN side.

Ook deels eens :
- Ik vind de 2,5 Gbps meetingen niet helemaal betrouwbaar, want 2,19 Gbps i.p.v. 2,49 Gbps of zo vind ik eigenlijk wel te laag...
- Je zou eigenlijk nog steeds een keer moeten testen i.c.m. een 2,5/5/10 Gbps LAN NIC die een andere chipset heeft dan de huidige RealTek om dat ook uit te sluiten!
Daarom noemde ik eerder die Aquantia NIC

Als je bovenstaande zou kunnen doen dan heb je denk ik echt alles afgedekt en heeft Ubiquiti geen poot meer om op te staan!

[Workaholic]

nero355 schreef op maandag 20 maart 2023 @ 16:12:
[...]


Ook deels eens :
- Ik vind de 2,5 Gbps meetingen niet helemaal betrouwbaar, want 2,19 Gbps i.p.v. 2,49 Gbps of zo vind ik eigenlijk wel te laag...
- Je zou eigenlijk nog steeds een keer moeten testen i.c.m. een 2,5/5/10 Gbps LAN NIC die een andere chipset heeft dan de huidige RealTek om dat ook uit te sluiten!
Daarom noemde ik eerder die Aquantia NIC

Als je bovenstaande zou kunnen doen dan heb je denk ik echt alles afgedekt en heeft Ubiquiti geen poot meer om op te staan!

Vanavond komt er wat nieuwe hardware binnen - dan kan ik een iperf test doen tussen twee volwaardige pc's ipv op de UDM SE zelf. Maar ik denk dat er dus geen issues zijn aan de lan / switching kant.

PPPOE / buffers / mtu moet de boosdoener zijn hier. Vrees dat unify er weinig tot niets mee gaat doen.

[laurens0619]

@Workaholic
Ik zou de UDM SE link naar je switch forceren op 1gbit, dan kan je interne netwerk 2.5gbit blijven.
Ja dan stroomt er max 1gbit naar je router mrja de internet verbinding erachter is toch ook "maar" 1gbit.

[stormfly]

Workaholic schreef op maandag 20 maart 2023 @ 16:02:
@laurens0619 ik moet je toch (Deels) gelijk geven.

Indien ik de RJ45 WAN port op 1G vastzet i.p.v. 2.5G auto is het probleem (deels) weg (upload snelheid lijkt in het begin goed, daarna stort het weer in). Voor alle duidelijkheid ik heb dan de client op 2.5 staan en is de enige aanpassing dus de WAN kant.

Dan kom ik nu uit op drie conclusies, benieuwd of jullie het met mij eens zijn en of er nog aanvullingen zijn, dan kan dit naar Unify support.

1) 2.5G or auto-negotiation set on UDM SE in combination with PPPOE provides issues with upload. Flow control or change of MTU does not solve the issue. Not sure what the cause is here, but when limiting the WAN interface to 1G FDX I have less issues (but am capped to 1G with my 1000/1000 fiber connection). Only when going back to 1g on the client side the issue is solved.

2) The issue is not between the 24 POE enterprise, DAC cable + UDM SE or with the local clients. Running iperf on the UDM SE and doing test to 2.5G clients show no issues and full bandwidth available up/down. Limiting the RJ45 on the WAN interface to 1G seems to be the best temporary solution to allow 2.5G traffic on the LAN side.

3) not being able to configure the MTU size is something that Unify should add as a setting. I am seeing dropped packets unless I change the MTU via CLI, but this doesn't remain after reboot.


[...]


Ja - of ik heb hier niet goed getest (excuses) of het ging toen echt ook mis. Kan ik nu niet reproduceren.

Punt blijft wel staan dat ik mede dankzij jullie hulp nu zeker weet dat het aan de PPPOE implementatie ligt en alle toekomstige KPN fiber users handmatig de RJ45 port moeten terugschroeven als ze dus de nieuwe ONT modellen hebben (die op 2.5G staan).

Wat je beter kunt doen is op de UI community een topic openen, met onderbouwing. Als mensen je daar dan bijvallen kan je ui-team taggen. Via support zie ik het niet goed komen eerlijk gezegd, het is toch vaak dat een moderator hem doorzet naar de dev's om tot een oplossing te komen.

[stormfly]

Er is geen verschil in IPv6 en IPv4 toch?

MSS = MTU minus 40 voor IPv4 of MTU minus 60 voor IPv6.

[Ben(V)]

Verschillen of verkeerde mtu zal normaal gesproken dit grote verschil nooit kunnen verklaren dus in die hoek hoef je het niet te zoeken.
Her enige wat er dan gebeurd is dat de data pakketjes opgebroken worden

Ik denk dat het gewoon de bagger frmware van Ubiquity is.

Je kunt nog proberen om in de netwerk settings van die 2,5 Gb nic de flow control uit te zetten (xon/xoff).
Dat is een overblijfsel uit de tijd dat er nog andere netwerkstacks dan tcp gebruikt werden.
Die functionaliteit zit al standaard in de tcp stack ingebouwd en is overbodige overhead en als die door de Ubiquity software verkeerd gebruikt wordt kan dat contra productief werken.

[stormfly]

https://gathering.tweakers.net/forum/view_message/74821130

Geen tijd om het uit te diepen maar lijkt gelijkwaardig.

[jadjong]

stormfly schreef op dinsdag 21 maart 2023 @ 07:30:
https://gathering.tweakers.net/forum/view_message/74821130

Geen tijd om het uit te diepen maar lijkt gelijkwaardig.

T-Mobile gebruikt voor zover ik weet geen pppoe. Gewoon stekker er in steken en DHCP doet de rest.

[nero355]

jadjong schreef op dinsdag 21 maart 2023 @ 20:12:
T-Mobile gebruikt voor zover ik weet geen pppoe. Gewoon stekker er in steken en DHCP doet de rest.

Klopt, maar daarmee is er dus ook gezeik, want 2,5 Gbps ONT aan de WAN kant van de UDM Pro in dit specifiek geval!

Lees effe alle gerelateerde reacties eens door voor de grap!

[nelizmastr]

jadjong schreef op dinsdag 21 maart 2023 @ 20:12:
[...]

T-Mobile gebruikt voor zover ik weet geen pppoe. Gewoon stekker er in steken en DHCP doet de rest.

Geen PPPoE inderdaad, alleen VLAN tag 300 op WAN en dan klopt het

Hier ook draaien op een UDMP, maar op GPON met de standaard 1Gbit Heuwwiuuiwiu ONT

[Mr. Jinx]

@Workaholic ik weet niet of je nog iets wilt proberen, maar ik had hetzelfde probleem met KPN en de inzakkende upload op een UDM SE.

Kun je eens proberen om 'Smart Queues' aan te zetten, en deze op 0 Mbps in te stellen? (Internet instellingen in de UDM SE)
Het is een bizar probleem, want Smart Queues kun je beter uit laten omdat het de boel alleen maar meer zou vertragen op hoge snelheden. Maar door deze op 0 te zetten gebeurd er iets vreemds in de UDM waardoor de upload opeens wel maximaal wordt gehaald.

Unifi zelf geeft hier helaas geen verklaring voor, maar er zijn al meerdere mensen waarbij dit DE oplossing was.

Zie ook: https://community.ui.com/...d7-4b69-8e6e-65fb3b5dc1ee

[Workaholic]

Mr. Jinx schreef op dinsdag 31 oktober 2023 @ 09:22:
@Workaholic ik weet niet of je nog iets wilt proberen, maar ik had hetzelfde probleem met KPN en de inzakkende upload op een UDM SE.

Kun je eens proberen om 'Smart Queues' aan te zetten, en deze op 0 Mbps in te stellen? (Internet instellingen in de UDM SE)
Het is een bizar probleem, want Smart Queues kun je beter uit laten omdat het de boel alleen maar meer zou vertragen op hoge snelheden. Maar door deze op 0 te zetten gebeurd er iets vreemds in de UDM waardoor de upload opeens wel maximaal wordt gehaald.

Unifi zelf geeft hier helaas geen verklaring voor, maar er zijn al meerdere mensen waarbij dit DE oplossing was.

Zie ook: https://community.ui.com/...d7-4b69-8e6e-65fb3b5dc1ee

Ik ga dit is proberen thanks! Het issue heb ik nu kunnen tackelen door de port te locken op 1g ipv 2,5g. Bij de client kant (dus niet de fw).

Ik heb zelf het idee dat het ligt aan de verschillende port speeds en de buffer die hierbij hoort. Zie ook andere toelichting hierboven.

Ook pas ik de mtu aan met een script, wat out of the box anders niet goed staat met kpn PPOE. Heb je dit ook geprobeerd @Mr. Jinx ?

Mogelijk heb ik dus dus een ander issue dan jij. Gebruik jij ergens een 2.5g ethernet aansluiting aan de pc / laptop kant?

Blijft vervelend dat unify geen oplossing heeft hiervoor (support heeft ticket geclosed)

[ Voor 23% gewijzigd door Workaholic op 31-10-2023 19:45 ]

[Mr. Jinx]

Ik had eerst ook 2.5Gbit maar inmiddels heb ik m'n hele netwerk weer op 1 Gbps. Dat werkt gewoon prima eigenlijk, maar dan nog had ik problemen met de upload. Dus wellicht niet helemaal hetzelfde probleem.

Aanpassen van de MTU doe ik ook met een script, alleen merk ik daar in de praktijk totaal geen verschil. Het is alleen efficiënter.

Om het helemaal goed te doen zou je ook nog MSS clamping moeten disablen omdat hier ook een limiet opzit vanuit Unifi die je niet kunt aanpassen.

Kun je hier eventueel checken:
https://www.speedguide.net/analyzer.php
Als MTU hier nog niet op 1500 staat, dan gaat het nog mis doordat MSS verkeerd staat.

PPPoE en Unifi blijft een matige combi vrees ik

[ Voor 3% gewijzigd door Mr. Jinx op 31-10-2023 20:51 ]

[Workaholic]

@Mr. Jinx Woot! dank voor de tip. Vandaag weer even 2.5G enabled op mijn netwerk adapter op mijn PC.
Ik krijg +- 1000Mbps down en 500Mbps upload.

Als ik mijn netwerk adapter op 1G zet -> probleem weg. Maar een work around want ik heb dan niet de volledige 2.5G beschikbaar (Lan en Wan).

Nu jouw aanpassing getest (smartqueues op 0) en voila volledige 1G up/down. Door 2.5G interface zie je dat ik zelfs boven de 1G uitkom . Nu is KPN de bottleneck.

[ Voor 8% gewijzigd door Workaholic op 03-11-2023 18:42 ]

[Mr. Jinx]

@Workaholic echt mooi om te horen! Helaas dat Ubiquity hier geen ruk mee doet. Ik heb dit al meerdere malen geprobeerd aan te kaarten maar ze geven geen enkele reactie.
Lijkt me toch echt een vreemde bug in de PPPoE / smart queue implementatie.

[makooy]

@Workaholic hou deze topic ook even in de gaten: [KPN XGS-PON] Eigen router/ONT gebruiken

[nero355]

@makooy
Dat is wel heel algemeen dus leg effe uit wat je precies bedoelt

[makooy]

nero355 schreef op donderdag 11 januari 2024 @ 17:57:
@makooy
Dat is wel heel algemeen dus leg effe uit wat je precies bedoelt

Er wordt in die topic onderzocht hoe je zonder ONT kan werken met KPN glas, dus de glas direct in de UDM-Pro

[Workaholic]

makooy schreef op donderdag 11 januari 2024 @ 11:07:
@Workaholic hou deze topic ook even in de gaten: [KPN XGS-PON] Eigen router/ONT gebruiken

DAnk! Vraag mij af hoeveel dat zwarte kastje nu gebruikt in de meterkast. Ik denk dat het niet heel veel gaat opleveren? Daarnaast ook de vraag -> bliksem inslag -> direct UDM Se (risico?) en met zwart kastje er tussen minder een risico?