Sticky

Gebruik een eigen router i.p.v. de Experia Box

  • 8 September 2018
  • 8570 reacties
  • 565433 keer bekeken
Gebruik een eigen router i.p.v. de Experia Box

Toon eerste bericht

8570 reacties

Deze switch config was op zich nog niet genoeg. Maar toen ik mijn ER-X xonfig aanpaste, op basis van https://kpn.wjb4all.nl/EdgeRouter-X-KPN-zonder-VoIP-met-vlan4-voor-TV.zip , met een tweede subnet en DHCP server voor 192.168.4.x werkte het!

Geen idee precies waarom…..

Reputatie 7

Dat ziet er goed uit.

Heb je de TV ontvanger opnieuw opgestart?

Wat is het IP adres dat de TV ontvanger krijgt? Je hoeft bij lokale IP adressen (192.168.x.x) geen stukjes weg te poetsen, niemand kan daar wat mee.

Reputatie 7

Deze switch config was op zich nog niet genoeg. Maar toen ik mijn ER-X xonfig aanpaste, op basis van https://kpn.wjb4all.nl/EdgeRouter-X-KPN-zonder-VoIP-met-vlan4-voor-TV.zip , met een tweede subnet en DHCP server voor 192.168.4.x werkte het!

Geen idee precies waarom…..

Logisch immers elk vlan moet zijn eigen subnet hebben.

Die DHCP server zit al sinds jaar en dag in die config dus vraag ik me af waarom die bij jou niet opgenomen was. Heb je jouw EdgeRouter oorspronkelijk ook op basis van dat configuratiescript ingericht?

TV ontvanger IP is 192.168.4.2 dus uit het verwachte subnet.

Ehm, ik ben absoluut op basis van jouw config begonnen, maar dat was dus 2020…  In de tussentijd zelf edits gemaakt (en in git gecommit), maar nooit een tweede DHCP server en een 192.168.4.x subnet aangemaakt.

Kan best zijn dat dat dom/fout was van me… maar tot vorige week, drie a vier jaar lang dus, had ik geen enkel probleem en dus ook geen reden om hier op het forum te zijn of nieuwere/andere scripts te downloaden.

 

Anyway, ik ben je veel dank verschuldigd, in eerste plaats al sinds 2020 voor je scripts en in de tweede plaats voor de aandacht en support van afgelopen week. Top!

Voor allen met een op Linux gebaseerde router hebben in combinatie met een Intel netwerk adapter (igb, ixgbe, i40e, ice), die er achter lopen dat er met PPPOE een bottleneck kan ontstaan doordat al het ontvangen verkeer verwerkt wordt door een enkele core, hierbij een simpele oplossing.

Waar dit over gaat; Wanneer je op Linux een Intel netwerk adapter gebruikt met PPPOE zal een enkele core een bottleneck kunnen vormen. (BSD heeft dit probleem ook) Dat kan voorkomen met een trage processor, maar ook met een snelle processor in combinatie met SuperFiber 4. Het symptoom is dat verkeer vanaf het internet niet de maximale bandbreedte gebruikt en dat op de router een ksoftirqd proces tijdens een snelheidstest tot 100% van een enkele core gebruikt.

Het is noodzakelijk om de standaard configuratie waarbij de netwerkkaart een queue per core gebruikt aan te passen zodat al deze queues van alle cores gebruik kunnen maken.

Dat kan door een aanpassing in de kernel configuratie via sysfs (/sys/class/net/<adapter>/queues/rx-*/rps_cpus) waar de toekenning via een bitmap gedaan wordt (f voor 4 cores, ff voor 8 cores, bijvoorbeeld).
Ik gebruik er een scriptregel voor:

find /sys/class/net/naam_van_netwerkadapter/queues -iname rps_cpus -exec bash -c 'echo ff > {}' \;

Voor een netwerk adapter met de naam 'enp7s0f0' en 8 cores (binair 11111111) 'ff' zou een configuratie het volgende kunnen omvatten, waarin ook diverse andere opties uitgezet worden die toch niet in de hardware geoffload kunnen worden wanneer PPPOE gebruikt wordt:

/etc/network/interfaces

auto enp7s0f0
iface enp7s0f0 inet manual
pre-up ethtool --set-priv-flags enp7s0f0 disable-fw-lldp on
pre-up ethtool --set-priv-flags enp7s0f0 flow-director-atr off
pre-up ethtool --set-eee enp7s0f0 eee off
pre-up find /sys/class/net/enp7s0f0/queues -iname rps_cpus -exec bash -c 'echo ff > {}' \;
pre-up ethtool -C enp7s0f0 adaptive-rx off adaptive-tx off rx-usecs 250 tx-usecs 250
pre-up ethtool -A enp7s0f0 rx off tx off
pre-up ethtool -K enp7s0f0 hw-tc-offload off
pre-up ethtool -s enp7s0f0 speed 10000 autoneg off
mtu 1512
auto enp7s0f0.6
iface enp7s0f0.6 inet manual
mtu 1508

En voor de compleetheid de rest van de mogelijk relevante configuraties voor een handmatig gebouwde Linux router (op basis van pppd en wide-dhcpv6-client, LAN DHCP / RA / DHCPv6 configuraties niet inbegrepen):

/etc/ppp/peers/provider

linkname pppoe
ifname ppp0

plugin rp-pppoe.so nic-enp7s0f0.6

+ipv6
ipv6cp-accept-local
noipdefault
defaultroute
defaultroute6
replacedefaultroute

persist
maxfail 0
holdoff 5
lcp-echo-interval 20
lcp-echo-failure 3

mtu 1500
mru 1500
noaccomp
nodeflate
nopcomp
novj
novjccomp

user "kpn"
password "kpn"
noauth
hide-password
/etc/wide-dhcpv6/dhcp6c.conf (in dit voorbeeld met meerde VLANs op een netwerk interface 'enp7s0f1'):

interface ppp0 {
send ia-pd 0;
};

id-assoc pd 0 {
prefix-interface enp7s0f1 {
sla-id 1;
sla-len 16;
};
prefix-interface enp7s0f1.2 {
sla-id 2;
sla-len 16;
};
prefix-interface enp7s0f1.3 {
sla-id 3;
sla-len 16;
};
};

 

Een kleine update voor het voorgaande over multiqueue netwerk adapters onder linux. Die informatie is nog zeker relevant voor degenen met een oudere Intel netwerk adapter (igb, ixgbe) of andere multiqueue netwerk adapters, maar voor de nieuwste Intel netwerk adapters is er een betere oplossing.

 

Beide generaties van netwerk adapters kunnen een profiel inladen waarmee PPPOE door de adapter herkend wordt en alle functionaliteit van de adapter ook werkt op die verkeersstromen. Geen beperkingen, de performance schaalt gewoon mee met het aantal processor-cores.

 

Voor Intel X710/XXV710/XL710 adapters:

https://www.intel.com/content/www/us/en/download/19306/intel-ethernet-controller-x710-xxv710-xl710-adapters-dynamic-device-personalization-pppoe-package.html

Voor de 700 serie adapters dient de ppp-oe-ol2tpv2.pkg in /lib/firmware/intel/i40e/ddp/ geplaatst te worden en moet bij boot deze ingeladen worden, bijvoorbeeld door ‘pre-up ethtool -f enp7s0f0 ppp-oe-ol2tpv2.pkg 100’ in /etc/network/interfaces te zetten (en mogelijk een geactualiseerde initram te maken).

Voor Intel 800 serie adapters:

https://www.intel.com/content/www/us/en/content-details/785722/intel-ethernet-800-series-dynamic-device-personalization-ddp-for-telecommunications-package.html

Voor de 800 serie adapters voldoet het om de ice-1.3.26.0.pkg en ice_comms-1.3.20.0.pkg in /lib/firmware/intel/ice/ddp en /lib/firmware/intel/ice/ddp-comms te plaatsen, deze worden door de driver automatisch ingeladen.

 

 

 

Na mijn onderzoek met problemen met de upload op de edgerouter x:

  • 910 mbs download, lage cpu load
  • 500 mbs download, HOGE cpu load
  • offload is enabled
  • mtu 1500 , 1508 , 1512 zoals in script 
  • speedguide tcp analyzer says: mtu 1500 and mss 1460 (but max package size is 1448)
  • geen analyzer / packet inspection aan

 

nu:

  • ben ik er achter dat ik de mss clamping moet aanzetten op 1452 en 1432 op de pppoe interface. (ipv4 en ipv6)
  • 910 mbs download, lage cpu load 
  • 910 mbs upload, lage cpu load
  • offload is enabled
  • mtu 1500 , 1508 , 1512 zoals in script 
  • speedguide tcp analyzer says: mtu 1492 and mss 1452 (zonder extra meldingen)
  • geen analyzer / packet inspection aan

 

 

nu heb ik dus t idee dat ik met mn edgerouter x ergens niet mtu 1500 kan halen.

ik vond ook het eea over mss clamping settings op de pagina van freedom. Zij gebruiken ook net wat andere waarden voor MTU.
https://helpdesk.freedom.nl/category-detail/algemene-instellingen-eigen-modem

https://www.kpn.com/service/eigen-apparatuur

 

Mensen met een edgerouter x:

 

Reputatie 7

nu heb ik dus t idee dat ik met mn edgerouter x ergens niet mtu 1500 kan halen.

Jouw EdgeRouter X haalt prima die MTU van 1500 bytes.

De IP header bij IPv4 communicatie is 40 bytes en dus kan voor IPv4 een MSS clamping van 1460 bytes ingesteld worden (1500 - 40)

De IP header bij IPv6 communicatie is 60 bytes en daarom is de voor IPv6 een MSS clamping van 1440 bytes het maximum.

Overigens zouden die MSS clamping waarden niet ingesteld hoeven te worden immers deze zouden automatisch goed gezet moeten worden o.b.v. de “path MTU recovery”.

Ik neem aan dat jij hardware offloading aan hebt staan op jouw EdgeRouter X, klopt dat?

Op een EdgeRouter X wordt bij hardware offloading geen onderscheid gemaakt tussen IPv4 en IPv6 terwijl je dit op bijvoorbeeld de EdgeRouter 4 expliciet IPv6 offloading kunt instellen op de pppoe verbinding. De vraag is of de EdgeRouter X überhaupt wel hardware offloading doet bij IPv6 communicatie. Dat zou namelijk het hoge CPU verbruik verklaren.

Ik heb zelf een EdgeRouter 4 en ook mijn abonnement is momenteel “maar” 200Mbps dus kan ik dat niet voor je controleren.

Nu heb ik eergisteren een brief van KPN ontvangen dat mijn glasvezelabonnement ergens in de komende maand kosteloos naar 1Gbps omgezet zal gaan worden. Als dat gebeurd is, dan zal ik eens kijken wat de resultaten op mijn EdgeRouter 4 zijn.

nu heb ik dus t idee dat ik met mn edgerouter x ergens niet mtu 1500 kan halen.

Jouw EdgeRouter X haalt prima die MTU van 1500 bytes.

De IP header bij IPv4 communicatie is 40 bytes en dus kan voor IPv4 een MSS clamping van 1460 bytes ingesteld worden (1500 - 40)

De IP header bij IPv6 communicatie is 60 bytes en daarom is de voor IPv6 een MSS clamping van 1440 bytes het maximum.

Overigens zouden die MSS clamping waarden niet ingesteld hoeven te worden immers deze zouden automatisch goed gezet moeten worden o.b.v. de “path MTU recovery”.

Ik neem aan dat jij hardware offloading aan hebt staan op jouw EdgeRouter X, klopt dat?

 

Thanks voor je antwoord.

de hardware offload werkt voor ipv4 en ipv6. Dat zie ik omdat de cpu load gewoon laag blijft.

Ik vind het zelf ook een vreemd verhaal dat ik die mss clamp moet gebruiken maar als ik die instel op 1460 en 1440 heb ik dus bij zowel ipv4 en ipv6 upload een hoge cpu load en een max snelheid van 500mbs (vanwege die cpu load). 

Dus ik ben het met je eens dat 1460 en 1440 zouden moeten werken. Maar dat is dus niet het geval als in: mijn hardware offload werkt niet meer bij de upload. De download gaat overigens nog steeds prima en ik krijg dan deze waarden op speedguide:

daar is het ook maf dat er maximaal 1448 byte in een package past. 
 

 

Ik vind het zelf ook een vreemd verhaal dat ik die mss clamp moet gebruiken maar als ik die instel op 1460 en 1440 heb ik dus bij zowel ipv4 en ipv6 upload een hoge cpu load en een max snelheid van 500mbs (vanwege die cpu load). 

Dus ik ben het met je eens dat 1460 en 1440 zouden moeten werken. Maar dat is dus niet het geval als in: mijn hardware offload werkt niet meer bij de upload. De download gaat overigens nog steeds prima en ik krijg dan deze waarden op speedguide:

iemand met t zelfde probleem :
https://community.ui.com/questions/ER-X-slower-upload-vs-download-via-ISP-FTTH/776842fd-18fb-432b-b4a0-67c1bb832054?page=2 
(er zijn veel meer mensen met hetzelfde probleem)

Reputatie 7

Voordat ik aanpassingen ga doen in de configuratiescripts wil ik eerst vaststellen of die fenomeen ook optreedt op mijn EdgeRouter 4. Ik heb namelijk het gevoel dat dit issue zich beperkt tot de EdgeRouter met een MediaTek CPU maar dat ga ik zien.

Heb jij overigens ook een MSS camping gedefinieerd voor IPv6?

Kan je ook screenshots tonen van de aanpassingen die je gedaan hebt op jouw ER-X.

Mijn vermoeden is dat de edgerouter4 het allemaal wel aan kan. Die is een stuk sneller en zal waarschijnlijk hoe dan ook die snelheid wel halen

 

jazeker:
 

 

 

Reputatie 7

Het blijft vreemd dat er MSS clamping nodig is met een waarde die laher is dan de MTU size - 40 (IPv4) of MTU size - 60 (IPv6). KPN henteert een MTU size van 1500 bytes en dus zou een IPv4 MSS clamping van 1460 bytes mogelijk moeten zijn.

@rickdehoop, Zou jij die MSS clamping instellingen weer eens weg kunnen gooien en de MTU size van de pppoe interface op 1492 kunnen zetten? Heb je dan ook nog de volle upload snelheid?

pppoe op 1492,

en eth0 1508 en eth0.6 1500?

Reputatie 7

pppoe op 1492,

en eth0 1508 en eth0.6 1500?

Ja, alleen pppoe op 1492, de rest ongewijzigd.

als ik dat doe dan is mijn internet haast onbruikbaar ...

Reputatie 7

Dat maakt het dan zeer vreemd immers het resultaat zou eigenlijk hetzelfde moeten zijn.

Ik vermoed een bug in de hardware offload bij een mtu van 1500 icm pppoe verbinding.

Reputatie 1

Is dat niet 1512 - 1508 - 1500?

Reputatie 7

De overhead van een pppoe verbinding is 8 bytes en aangezien de pppoe verbinding een MTU van 1500 bytes heeft zal de MTU van vlan 6 dus 1508 moeten zijn. De overhead van een vlan is 4 bytes en daarom heeft de bovenliggende ethernet poort een MTU van 1512. 

Is dat niet 1512 - 1508 - 1500?

Dat is idd hoe t nu staat en hoe t in de scripts staat
Modem ethernet port 1512

Internet vlan 1508

pppoe 1500

Ik heb nu een edgerouter x en denk dat ik iets wil hebben dat net even wat meer aankan. Raden jullie een edgerouter 4 aan of iets anders?

ik ben benieuwd!

Reputatie 7

Van de EdgeRouter serie is er maar één die ik zou kiezen en dat is de EdgeRouter 4.

Een ingebouwde switch heeft geen zin als je ook TV van KPN hebt aangezien die ingebouwde switch van EdgeRouters geen IGMP snooping ondersteunt. Hoe minder LAN poorten hoe beter.

 

Ik ben een enorme fan van de EdgeRouter. Het is een betaalbare router met zeer zeer veel functionaliteit.

Helaas denkt Ubiquiti daar anders over en lijkt de Unifi serie het te winnen van de EdgeRouter serie.

Zelf heb ik dus een EdgeRouter 4 en als spare heb ik nog een EdgeRouter Lite 3 staan.

 

Overigens zou ik dolgraag de UXG Lite een keer willen gaan testen en kijken of deze geschikt (te maken) is voor TV van KPN maar om daar nu een kleine €150,- uit te gaan geven gaat me iets te ver.

Ik heb geen tv meer van KPN :)

NLziet is echt een verademing op de appletv. Geen reclame en een super fijn eco system met tvos.

denk je dat de ux gateway lite dan een beter optie is?

Reputatie 7

Als je geen KPN TV hebt dan zou ik serieus een UXG Lite of eventueel een UXG Max overwegen.

Reageer