PFsense + ExtraIP + Tweak = lage snelheid?

[Operations]

Ik gebruik hier PFSense 2.4.5 op een ESX 7 machine. Gekozen NIC's zijn allemaal VMX NET 3. (E1000 ook geprobeerd)
Op zich werkt het allemaal, m.b.v. van de HowTo op kragt-ict.nl.

Ik haal alleen niet mijn volledige snelheid, nu snap ik uiteraard dat er wat verlies zal zijn door de ExtraIP tunnel. Maar ik kom maar tot 500Mbps/800Mbps dl/ul (ongeveer). en vooral het verschil vind ik zo vreemd.

Ik vermoed dat er iets aan de MTU/MSS moet gebeuren, maar daar heb ik ook al verschillende waardes getest. Momenteel heb ik geen MTU/MSS ingevuld. MSS 1472 (conform handleiding) maakt geen verschil.

Of zit hem in deze opties wellicht?

Hardware Checksum Offloading
Hardware TCP Segmentation Offloading
Hardware Large Receive Offloading

Onder Advanced en dan Networking

Heeft iemand enig idee hoe dit te verbeteren?

[ Voor 17% gewijzigd door Operations op 07-06-2020 15:49 ]

[MrNGm]

Waarmee test je? Weet je zeker dat de sturende/ontvangende kant ook minstens gigabit aankan?

Optie is om met publieke iperf-servers te testen: https://iperf.fr/iperf-servers.php

[Operations]

Ik down een 1GB bestand van transip en gebruik speedtest.net.

Ja alles is gigabit hier. Als ik vanaf binnenkomst glas (dus met een computer aangesloten ipv glas )naar server toe een bestand download haal ik 110MB/s.

En dan nog dat zou toch niet het verschil tussen up en down verklaren?

Edit:

Enig idee waarom dit niet werkt?

Iperf3 -c ping-ams1.online.net

Ik krijg connection reset bij peers. Ook wanneer ik andere public servers probeer.

[ Voor 98% gewijzigd door Operations op 07-06-2020 19:20 ]

[Verwijderd]

Connection Reset by Peer impliceert dat er ergens tussen jou en de iPerf server een netwerkdevice/firewall tussen zit die de connectie verbreekt/reset.

Doe je dit vanaf je pfSense machine? er is een iperf package beschikbaar (werkt bij mij alleen vanaf de terminal) .

via Ziggo
[[2.4.5-RELEASE][[e-mail]]/root: iperf3 -4 -c ping-ams1.online.net -f m
Connecting to host ping-ams1.online.net, port 5201
[ 5] local xxx.xxx.xxx.xxx port 55263 connected to 163.172.208.7 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 3.76 MBytes 31.5 Mbits/sec 0 146 KBytes
[ 5] 1.00-2.00 sec 5.07 MBytes 42.5 Mbits/sec 0 190 KBytes
[ 5] 2.00-3.00 sec 5.22 MBytes 43.8 Mbits/sec 0 226 KBytes
[ 5] 3.00-4.00 sec 5.11 MBytes 42.9 Mbits/sec 0 257 KBytes
[ 5] 4.00-5.00 sec 5.17 MBytes 43.4 Mbits/sec 0 284 KBytes
[ 5] 5.00-6.00 sec 5.14 MBytes 43.2 Mbits/sec 0 310 KBytes
[ 5] 6.00-7.00 sec 5.17 MBytes 43.4 Mbits/sec 0 333 KBytes
[ 5] 7.00-8.00 sec 5.15 MBytes 43.2 Mbits/sec 0 354 KBytes
[ 5] 8.00-9.00 sec 5.11 MBytes 42.8 Mbits/sec 0 374 KBytes
[ 5] 9.00-10.00 sec 5.19 MBytes 43.5 Mbits/sec 0 394 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 50.1 MBytes 42.0 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 49.4 MBytes 41.4 Mbits/sec receiver

iperf Done.

via ExtraIP
[2.4.5-RELEASE][[e-mail]]/root: iperf3 -4 -c ping-ams1.online.net
Connecting to host ping-ams1.online.net, port 5201
[ 5] local 37.148.196.145 port 56737 connected to 163.172.208.7 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.01 sec 78.3 KBytes 635 Kbits/sec 8 4.24 KBytes
[ 5] 1.01-2.01 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[ 5] 2.01-3.00 sec 116 KBytes 957 Kbits/sec 17 4.24 KBytes
[ 5] 3.00-4.00 sec 216 KBytes 1.78 Mbits/sec 15 12.8 KBytes
[ 5] 4.00-5.00 sec 250 KBytes 2.05 Mbits/sec 17 18.5 KBytes
[ 5] 5.00-6.00 sec 137 KBytes 1.12 Mbits/sec 23 9.96 KBytes
[ 5] 6.00-7.00 sec 228 KBytes 1.86 Mbits/sec 24 9.95 KBytes
[ 5] 7.00-8.01 sec 112 KBytes 906 Kbits/sec 15 2.83 KBytes
[ 5] 8.01-9.00 sec 59.4 KBytes 490 Kbits/sec 9 5.67 KBytes
[ 5] 9.00-10.00 sec 146 KBytes 1.19 Mbits/sec 22 7.08 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.31 MBytes 1.10 Mbits/sec 151 sender
[ 5] 0.00-10.00 sec 1.25 MBytes 1.05 Mbits/sec receiver

Zoals je ziet is er bij iperf3 ook een substantieel verschil te zien ( sowieso zie ik daar niet mijn verwachtte internet snelheid terug zoals die bij bv Ookla wordt gerapporteerd).

[Operations]

Verwijderd schreef op maandag 8 juni 2020 @ 09:39:
Connection Reset by Peer impliceert dat er ergens tussen jou en de iPerf server een netwerkdevice/firewall tussen zit die de connectie verbreekt/reset.

Doe je dit vanaf je pfSense machine? er is een iperf package beschikbaar (werkt bij mij alleen vanaf de terminal) .

via Ziggo
[[2.4.5-RELEASE][[e-mail]]/root: iperf3 -4 -c ping-ams1.online.net -f m
Connecting to host ping-ams1.online.net, port 5201
[ 5] local xxx.xxx.xxx.xxx port 55263 connected to 163.172.208.7 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 3.76 MBytes 31.5 Mbits/sec 0 146 KBytes
[ 5] 1.00-2.00 sec 5.07 MBytes 42.5 Mbits/sec 0 190 KBytes
[ 5] 2.00-3.00 sec 5.22 MBytes 43.8 Mbits/sec 0 226 KBytes
[ 5] 3.00-4.00 sec 5.11 MBytes 42.9 Mbits/sec 0 257 KBytes
[ 5] 4.00-5.00 sec 5.17 MBytes 43.4 Mbits/sec 0 284 KBytes
[ 5] 5.00-6.00 sec 5.14 MBytes 43.2 Mbits/sec 0 310 KBytes
[ 5] 6.00-7.00 sec 5.17 MBytes 43.4 Mbits/sec 0 333 KBytes
[ 5] 7.00-8.00 sec 5.15 MBytes 43.2 Mbits/sec 0 354 KBytes
[ 5] 8.00-9.00 sec 5.11 MBytes 42.8 Mbits/sec 0 374 KBytes
[ 5] 9.00-10.00 sec 5.19 MBytes 43.5 Mbits/sec 0 394 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 50.1 MBytes 42.0 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 49.4 MBytes 41.4 Mbits/sec receiver

iperf Done.

via ExtraIP
[2.4.5-RELEASE][[e-mail]]/root: iperf3 -4 -c ping-ams1.online.net
Connecting to host ping-ams1.online.net, port 5201
[ 5] local 37.148.196.145 port 56737 connected to 163.172.208.7 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.01 sec 78.3 KBytes 635 Kbits/sec 8 4.24 KBytes
[ 5] 1.01-2.01 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[ 5] 2.01-3.00 sec 116 KBytes 957 Kbits/sec 17 4.24 KBytes
[ 5] 3.00-4.00 sec 216 KBytes 1.78 Mbits/sec 15 12.8 KBytes
[ 5] 4.00-5.00 sec 250 KBytes 2.05 Mbits/sec 17 18.5 KBytes
[ 5] 5.00-6.00 sec 137 KBytes 1.12 Mbits/sec 23 9.96 KBytes
[ 5] 6.00-7.00 sec 228 KBytes 1.86 Mbits/sec 24 9.95 KBytes
[ 5] 7.00-8.01 sec 112 KBytes 906 Kbits/sec 15 2.83 KBytes
[ 5] 8.01-9.00 sec 59.4 KBytes 490 Kbits/sec 9 5.67 KBytes
[ 5] 9.00-10.00 sec 146 KBytes 1.19 Mbits/sec 22 7.08 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.31 MBytes 1.10 Mbits/sec 151 sender
[ 5] 0.00-10.00 sec 1.25 MBytes 1.05 Mbits/sec receiver

Zoals je ziet is er bij iperf3 ook een substantieel verschil te zien ( sowieso zie ik daar niet mijn verwachtte internet snelheid terug zoals die bij bv Ookla wordt gerapporteerd).

Wanneer ik poort 5201 openzet krijg ik inderdaad niet meer die melding.. Maar wel een andere
Control socket has closed unexpectedley.

Is even kijken waardoor dat komt.

Edit:

Andere server pakt hij wel:

C:\Iperf3>iperf3 -4 -c iperf.volia.net -f m
Connecting to host iperf.volia.net, port 5201
[ 4] local 192.168.100.49 port 52131 connected to 77.120.3.236 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.01 sec 6.25 MBytes 51.9 Mbits/sec
[ 4] 1.01-2.01 sec 6.88 MBytes 57.7 Mbits/sec
[ 4] 2.01-3.01 sec 5.25 MBytes 43.9 Mbits/sec
[ 4] 3.01-4.00 sec 512 KBytes 4.24 Mbits/sec
[ 4] 4.00-5.01 sec 384 KBytes 3.14 Mbits/sec
[ 4] 5.01-6.02 sec 256 KBytes 2.08 Mbits/sec
[ 4] 6.02-7.01 sec 384 KBytes 3.16 Mbits/sec
[ 4] 7.01-8.00 sec 384 KBytes 3.18 Mbits/sec
[ 4] 8.00-9.01 sec 384 KBytes 3.13 Mbits/sec
[ 4] 9.01-10.01 sec 256 KBytes 2.09 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.01 sec 20.9 MBytes 17.5 Mbits/sec sender
[ 4] 0.00-10.01 sec 20.7 MBytes 17.4 Mbits/sec receiver

Maar dit lijkt mij dan ook niet veelzeggend, aangezien ik andere "bewijzen" heb dat de verbinding sneller gaat dan dit... toch?

[ Voor 15% gewijzigd door Operations op 08-06-2020 12:55 ]

[Verwijderd]

Mijn idee, maar ik ben geen iperf3 kenner, dus ik zou zo maar niet de optimale settings kunnen gebruiken of die getallen verkeerd kunnen interpreteren, maar zoals ik ze nu zie, hebben we niet veel in de info van iperf3 om conclusies aan te verbinden.

Wat mij wel opvalt aan de sessie die ik had, is dat er veel retries plaatsvinden, wat uiteraard erg ten koste gaat van de snelheid. In de sessie van jou zie ik de retries niet, maar wellicht dat die bij jou ook hoog zijn

[Operations]

Verwijderd schreef op maandag 8 juni 2020 @ 12:53:
Mijn idee, maar ik ben geen iperf3 kenner, dus ik zou zo maar niet de optimale settings kunnen gebruiken of die getallen verkeerd kunnen interpreteren, maar zoals ik ze nu zie, hebben we niet veel in de info van iperf3 om conclusies aan te verbinden.

Wat mij wel opvalt aan de sessie die ik had, is dat er veel retries plaatsvinden, wat uiteraard erg ten koste gaat van de snelheid. In de sessie van jou zie ik de retries niet, maar wellicht dat die bij jou ook hoog zijn

Nieuw testje levert trouwens wat beter resultaat op:

C:\Iperf3>iperf3 -4 -c iperf.volia.net -f m
Connecting to host iperf.volia.net, port 5201
[ 4] local 192.168.100.21 port 60401 connected to 77.120.3.236 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 6.12 MBytes 51.3 Mbits/sec
[ 4] 1.00-2.00 sec 6.75 MBytes 56.7 Mbits/sec
[ 4] 2.00-3.00 sec 6.75 MBytes 56.6 Mbits/sec
[ 4] 3.00-4.00 sec 6.88 MBytes 57.7 Mbits/sec
[ 4] 4.00-5.00 sec 6.75 MBytes 56.6 Mbits/sec
[ 4] 5.00-6.00 sec 7.00 MBytes 58.7 Mbits/sec
[ 4] 6.00-7.00 sec 6.75 MBytes 56.6 Mbits/sec
[ 4] 7.00-8.00 sec 6.75 MBytes 56.7 Mbits/sec
[ 4] 8.00-9.00 sec 7.00 MBytes 58.7 Mbits/sec
[ 4] 9.00-10.00 sec 6.75 MBytes 56.6 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 67.5 MBytes 56.6 Mbits/sec sender
[ 4] 0.00-10.00 sec 67.5 MBytes 56.6 Mbits/sec receiver

iperf Done.

Dit komt meer in de buurt van mijn 1GB file download test.

[Proc]

Zet LRO eens uit en test het dan nog eens. Het is een issue die bekend is i.c.m. met een ESXi FreeBSD VM. pfSense geeft een wat onduidelijke waarschuwing (zie laatste link) om terughoudend te zijn met LRO.

Ik zou trouwens ook de overige NIC opties goed testen voordat ik een pfSense VM in productie zou nemen (Zeker als de NIC geen Intel is).

[ Voor 51% gewijzigd door Proc op 08-06-2020 13:30 ]

[Operations]

Proc schreef op maandag 8 juni 2020 @ 13:26:
Zet LRO eens uit en test het dan nog eens. Het is een issue die bekend is i.c.m. met een ESXi FreeBSD VM. pfSense geeft een wat onduidelijke waarschuwing (zie laatste link) om terughoudend te zijn met LRO.

Ik zou trouwens ook de overige NIC opties goed testen voordat ik een pfSense VM in productie zou nemen (Zeker als de NIC geen Intel is).

Deze "Disable hardware large receive offload" is al aangevinkt. Die bedoel je toch?
Het zijn Intel® 82574L GbE LAN NICs

[ Voor 3% gewijzigd door Operations op 08-06-2020 13:33 ]

[MuVo]

Heb gekeken of de Open VM Tools package verbetering bied (ook al zijn de VMXNET2/3 drivers ingeboud in the PFsense kernel)?

[Proc]

Operations schreef op maandag 8 juni 2020 @ 13:31:
[...]


Deze "Disable hardware large receive offload" is al aangevinkt. Die bedoel je toch?
Het zijn Intel® 82574L GbE LAN NICs

Die bedoelde ik inderdaad. Het handigste is om de overige offload opties ook uit te zetten en door te testen.

Edit: ik zou ook even de MTU checken. Bij Ziggo bijvoobeeld wordt i.c.m. een Sophos UTM de MTU hardnekkig verkeerd doorgegeven door Ziggo waardoor downloadsnelheid, maar vooral ook uploadsnelheid een flinke hit (denk aan factor 2 en hoger) kregen.

[ Voor 26% gewijzigd door Proc op 08-06-2020 23:05 ]

[Operations]

Proc schreef op maandag 8 juni 2020 @ 13:42:
[...]


Die bedoelde ik inderdaad. Het handigste is om de overige offload opties ook uit te zetten en door te testen.

Huidige status:
Hardware Checksum Offloading UITGEVINKT
Hardware TCP Segmentation Offloading AANGEVINKT
Disable hardware large receive offload AANGEVINKT

Alle drie uitvinken maakt geen verschil en dan krijg ik wat interne netwerkproblemen. Outlook wil dan bijvoorbeeld niet meer open.

@MuVo Open VM-Tools package is geïnstalleerd.

EDIT:

Van 2 naar 4 vCPU's en 6000 Mhz gereserveerd haalt ook niks uit. (clock snelheid cpu x 2) idee van @Vorkie

[ Voor 10% gewijzigd door Operations op 08-06-2020 17:18 ]

[Kabouterplop01]

Als je een MTU hebt van 1472 dan moet je IN GEVAL VAN PPPOE een MSS van 1452 gebruiken.
Dat heeft te maken met de overhead; 8 bytes voor pppoe, 20 bytes van de tcp header en 20 bytes van ip header. Aangezien je met 1472 komt gok ik dat je pppoe hebt.

[Operations]

Kabouterplop01 schreef op maandag 8 juni 2020 @ 23:18:
Als je een MTU hebt van 1472 dan moet je IN GEVAL VAN PPPOE een MSS van 1452 gebruiken.
Dat heeft te maken met de overhead; 8 bytes voor pppoe, 20 bytes van de tcp header en 20 bytes van ip header. Aangezien je met 1472 komt gok ik dat je pppoe hebt.

Ik gebruik geen PPPOE. En ik gebruik 1472 als MSS waarde. Tussen MTU en MSS moet minimaal 40 zitten. Dat geeft PFSense zelf aan.

[noskill]

Een bericht als Kabouterplop schreef probeerde ik ook te reageren op je DM, @Operations. Ik ben echter geen specialist... Maar je hebt een MTU op je WAN verbinding, dan heb je een GRE tunnel naar ExtraIP, dan heb je een GIF tunnel voor de IPv6 adressen. Dat zijn allemaal protocollen die (waarschijnlijk) een stukje van alle packets nodig hebben om door te geven naar de ontvanger. In dat geval wil je je MSS waarde waarschijnlijk nog een tandje naar onder bijstellen. En if worse comes to worst, PCI-passthrough van je Intel NIC naar je pfSense bak?

[Operations]

noskill schreef op dinsdag 9 juni 2020 @ 09:52:
Een bericht als Kabouterplop schreef probeerde ik ook te reageren op je DM, @Operations. Ik ben echter geen specialist... Maar je hebt een MTU op je WAN verbinding, dan heb je een GRE tunnel naar ExtraIP, dan heb je een GIF tunnel voor de IPv6 adressen. Dat zijn allemaal protocollen die (waarschijnlijk) een stukje van alle packets nodig hebben om door te geven naar de ontvanger. In dat geval wil je je MSS waarde waarschijnlijk nog een tandje naar onder bijstellen. En if worse comes to worst, PCI-passthrough van je Intel NIC naar je pfSense bak?

Wat voor MSS waarde zou ik dan kunnen proberen? Stappen van 48 aanhouden, nav het verhaal van @Kabouterplop01 ?

Passthrough is misschien wel een goed idee om is te proberen inderdaad

[ Voor 4% gewijzigd door Operations op 09-06-2020 09:55 ]

[noskill]

Nou tis gokken natuurlijk... Maar als je het idee hebt dat er fragmenting plaats vindt, probeer eens 1452. Wat is je uitgaande IP? IPv4 of IPv6? Hoeveel van die tunnels moeten je clients overbruggen etc.

En om even terug naar de OP te gaan - ben je de pfSense firewall en de ExtraIP subnetten gelijktijdig gaan gebruiken? Heb je de downloadsnelheid gemeten direct na het installeren/configureren van pfSense, maar voordat je met ExtraIP aan de slag ging? Want als de downloadsnelheid toen ook al lager was dan voorheen, zonder dat je verkeer over ExtraIP tunnels loopt, dan is er natuurlijk iets anders mis.

[Vorkie]

WAN = Tweak, MTU 1500
EXTRAIP = GRE tunnel
EXTRAIPv6 = GIF tunnel

GRE en GIF tunnel gebruiken WAN interface als datadrager (dus niet stapelend)

Snelheid Default Gateway Tweak = de 1Gbit/s minus overheads
Snelheid Default Gateway EXTRAIP = halve download + iets lagere upload.

Door spelen met MTU/MSS op de ExtraIP interface kwam hij wat sneller uit, maar deed DHCP op WAN het niet goed.

CPU reservering gemaakt in vSphere
MEM reservering gemaakt in vSphere

Het lijkt zich te richten op de ExtraIP interface, misschien i.c.m. PFsense GRE. Zal eens Mikrotik proberen met hem als er tijd is.

[noskill]

Het is niet super onrealistisch om te denken dat het een CPU limiet is... Los van het CPU verbruik van de VM zelf, moet al het netwerk verkeer van VMXNET naar fysieke kaart vertaald worden. Dat is ook allemaal CPU power. Helemaal als je geen hardware offload kan gebruiken (ivm performance impact, is volgens mij een bekend probleem voor vmware + unix vm's?).

[Operations]

noskill schreef op dinsdag 9 juni 2020 @ 11:02:
Het is niet super onrealistisch om te denken dat het een CPU limiet is... Los van het CPU verbruik van de VM zelf, moet al het netwerk verkeer van VMXNET naar fysieke kaart vertaald worden. Dat is ook allemaal CPU power. Helemaal als je geen hardware offload kan gebruiken (ivm performance impact, is volgens mij een bekend probleem voor vmware + unix vm's?).

Dat zou dan toch zichtbaar moeten zijn? Plus het is best een stevige CPU (Xeon 2690 v2 @3Ghz 10c/20t).

[Wim-Bart]

Je MSS kan je testen door te pingen met een packet size en df bit aan te zetten. Zo kan je de meest optimale waarde bepalen voor buiten je tunnel en daarna het hele testen in je tunnel.

Door df bit te zetten zal een pakket geweigerd worden wanneer een pakket niet past.

[Kabouterplop01]

Operations schreef op dinsdag 9 juni 2020 @ 09:55:
[...]
Wat voor MSS waarde zou ik dan kunnen proberen? Stappen van 48 aanhouden, nav het verhaal van @Kabouterplop01 ?

de header voor PPPOE is maar 8 bytes, bij een PPPOE verbinding is de effectieve mtu 1492 en mss 40 bytes lager. Maar je hebt blijkbaar gewoon ethernet zonder pppoe dus niet van toepassing.

Kijk eens hier:
https://community.cisco.c...s%20less%20the%20physical.

[ Voor 20% gewijzigd door Kabouterplop01 op 11-06-2020 18:09 ]

[MrNGm]

Operations schreef op dinsdag 9 juni 2020 @ 09:55:
[...]


Wat voor MSS waarde zou ik dan kunnen proberen? Stappen van 48 aanhouden, nav het verhaal van @Kabouterplop01 ?

Voor de IPv6-tunnel gebruik ik MTU 1480, MSS 1460. De waardes heb ik gekopieerd van m'n Hurricane Electric-tunnel. Dat is als volgt opgebouwd (zie ook deze tool):

• WAN (Ethernet) MTU 1500
• GIF-tunnel (IPv6-in-IPv4) MTU 1480 (IPv4), MSS 1460*

MSS van 1460* is gebaseerd op TCP (20 bytes) + IPv6 (40 bytes). Normaal zou je (in pfSense) 1480 invullen, en dan trekt pfSense er 40 bytes vanaf, maar dat is gebaseerd op TCP (20 bytes) + IPv4 (20 bytes).

[Operations]

MrNGm schreef op vrijdag 3 juli 2020 @ 21:26:
[...]


Voor de IPv6-tunnel gebruik ik MTU 1480, MSS 1460. De waardes heb ik gekopieerd van m'n Hurricane Electric-tunnel. Dat is als volgt opgebouwd (zie ook deze tool):

• WAN (Ethernet) MTU 1500
• GIF-tunnel (IPv6-in-IPv4) MTU 1480 (IPv4), MSS 1460*

MSS van 1460* is gebaseerd op TCP (20 bytes) + IPv6 (40 bytes). Normaal zou je (in pfSense) 1480 invullen, en dan trekt pfSense er 40 bytes vanaf, maar dat is gebaseerd op TCP (20 bytes) + IPv4 (20 bytes).

Ik gebruik de IPv6 tunnel nog niet. Maar dank voor de tip Wat voor waardes gebruik je voor je IPv4 tunnel?

[MrNGm]

Operations schreef op vrijdag 3 juli 2020 @ 22:35:
Ik gebruik de IPv6 tunnel nog niet. Maar dank voor de tip Wat voor waardes gebruik je voor je IPv4 tunnel?

Die waardes heb ik zo te zien nog niet ingesteld, dus dat staat nu nog op de default van 1500. Ik heb er nog geen snelheidstest mee gedaan, maar het vergelijken wordt ook lastig met een 100/100-lijn.