Netgate 2100 inexplicable slow internet problem
-
Mmm, I'm not sure anything in pfSense could produced throttling like that. Do you have any traffic shaping enabled?
This feels like something upstream.
-
@stephenw10 said in Netgate 2100 inexplicable slow internet problem:
Do you have any traffic shaping enabled?
No traffic shaping configured.
The more time passes, the worse it gets, I even struggle to connect to this forum, everything is very slow... it's absurd... if I didn't know that with any other device everything works perfectly I'd say it's a connection problem, but it's pfSense that causes all this.
I also thought about some blocking on the provider side, but when I tested with another device I was forced to spoof the Netgate mac address (because my provider only enabled that one). So on the provider side they always see the same device, but this problem only occurs with Netgate.
I would have liked to buy the Netgate 4200 more suitable for a gigabit connection but if I don't find the solution I'm afraid of having the same problem.
-
Guys I can't believe it, maybe I found the problem! Or at least the temporary solution....
I inserted a small unmanaged switch between the Netgate WAN interface and the ZTE F6005 ONT and it seems to magically solve everything.
But what kind of incompatibility could it be and how does it cause such a particular problem?
Thinking of a hardware problem in the past I had also tried to disable "Hardware checksum offloading" which I had read caused some problems... but I hadn't solved
Do you have any ideas if there anything else I can try on the Netgate side?
-
@federacco horrible speeds like 1mbps when should have 100s screams duplex mismatch.. Which could be corrected sometimes with a switch between 2 devices that are having the mismatch..
But looking at what you posted this jumped out at me.. This sure and the hell doesn't seem right
A /32 on single interface... This is the mask companies and ISPs get when they get IPv6 from say arin... That sure and the hell shouldn't be the mask on your interface..
Did you maybe try disable IPv6 and see what you get for speeds to different connections?
For reference a /32 = 65K /48s, 16Million /56s or 4 Billion /64s.. You think such a mask should be on a single interface? ;)
There is no possible way your ipv6 is correct that is for sure.. Not with that mask.
-
If it's PPPoE that's pretty standard. But that isn't!
If it was a duplex mismatch you'd be (very) unlikely to see the 150Mbps value for the local server.
It could be flow-control mismatch. The switch would also potentially correct that. I don't think I've ever seen that be an issue on a 2100 but there's always a first time!
It's disabled by default:
[24.03-RELEASE][admin@2100-3.stevew.lan]/root: sysctl dev.mvneta.0.flow_control dev.mvneta.0.flow_control: 0 -
@johnpoz said in Netgate 2100 inexplicable slow internet problem:
A /32 on single interface... This is the mask companies and ISPs get when they get IPv6 from say arin... That sure and the hell shouldn't be the mask on your interface..
I understand your surprise but this is correct... This is an IPv6 configuration via 6RD, my provider only provides me with a /64 via 6RD tunnel. What you see is only the prefix assigned by the ISP.
This is the 6RD configuration on the WAN interface:
And this is the real IPv6 on one internal interface,:
I have only one /64 assigned so only devices under this interface have IPv6 but I'm fine with that.
However, in the thousand tests I did I had completely disabled IPv6 and the problem was not resolved.
@stephenw10 said in Netgate 2100 inexplicable slow internet problem:
If it was a duplex mismatch you'd be (very) unlikely to see the 150Mbps value for the local server.
I agree, on the servers of main Italian ISPs or in any case on my own ISP I even reached 500 Mbit, whereas on the servers of other foreign ISPs always 1-7 Mbit, a duplex mismatch I don't think can cause this.
@stephenw10 said in Netgate 2100 inexplicable slow internet problem:
It could be flow-control mismatch. The switch would also potentially correct that. I don't think I've ever seen that be an issue on a 2100 but there's always a first time!
If so, how can I solve it? I confirm that it is disabled.
Sorry guys, but could the problem be due to the interface on the ONT side which is a 2.5G Ethernet?
-
@federacco said in Netgate 2100 inexplicable slow internet problem:
Sorry guys, but could the problem be due to the interface on the ONT side which is a 2.5G Ethernet?
No. It should still link correctly at 1G.
Try running:
[24.03-RELEASE][admin@2100-3.stevew.lan]/root: sysctl dev.mvneta.0.flow_control=1 dev.mvneta.0.flow_control: 0 -> 1It's more common to have to disable flow-control but I have seen the opposite case be true.
-
@federacco said in Netgate 2100 inexplicable slow internet problem:
What you see is only the prefix assigned by the ISP.
which still makes zero sense.. that is insane to assign a /32 to any interface.. They put all their clients on big giant network? That seems insane..
Yet another example of isps not having freaking clue one on how to actually correctly deploy IPv6.. Mapping all of IPv4 space under the /32 is just plain stupid way to deploy ipv6
-
I tried turning on flow-control, no difference.
I agree that the gigabit WAN interface connected to the 2.5G interface of the ONT should negotiate the speed to 1G without problems but something on the Netgate side is not working as it should, and at this point it is definitely a problem at the connection level.
I confirm that with the unmanaged gigabit switch inserted between ONT and Netgate everything works perfectly.
Removing the switch the problem returns immediately: speedtest on Italian ISP servers: 200/300 mbit - speedtest on other foreign ISPs: 1/7 mbit
I struggle to understand how this situation can be created but the problem is in this ethernet connection. -
It's a 1G switch? When it was in-line did it show both sides linked at 1G-FD?
-
@stephenw10 yes i'ts a simple Netgear GS105, both interface linked at 1G.
-
Does the ONT (LEDs) show as linked at 1G when connected to 2100 directly?
-
Now I can't verify by reconnecting the Netgate directly, but this is the state of the ONT and I'm pretty sure it was the same with the Netgate directly connected... I'll check back later to be sure.
-
I would check the LEDs on the port too just to be sure.
-
The ONT does not have ethernet status LEDs, however I confirm that from web interface on both Netgate side and ONT side speed is 1000 full duplex.
-
Hmm. That sort of throttling feels like it's latency related. Do you see packet loss too when testing? Like if you run a continuous ping whilst testing?
-
@stephenw10 yes, I confirm. With Netgate directly connected to the ONT I had a constant packet loss of around 2-5% with periodic higher spikes.
The pfSense gateway monitoring is set to my ISP's public DNS and here too it reports packet loss...
Now with the switch there is no packet loss. 0% constant. -
Hmm. One thing you could try here would be to separate one of the LAN ports as a different interface and then use that as WAN. Since that's connected via the internal switch it may well link correctly.
https://docs.netgate.com/pfsense/en/latest/solutions/netgate-2100/configuring-the-switch-ports.html
-
I have all interfaces busy, but i was able to swap my backup WAN which was on a interface of the internal switch with that of the fiber WAN on the separate single interface.
Obviously I had to make some changes for VLANs, configuration etc...
I didn't like it much because I preferred to have the main fiber WAN on the single interface for some reason... but it actually works without problems, you were right to recommend this test because at this point the "incompatibility" problem with the ONT is only on the single separate interface of the Netgate. I don't understand what he doesn't like, it really drove me crazy.
At least this way I could remove the workaround with the external switch.
The only thing that consoles me is that in any case I had planned to replace the Netgate with a new appliance with 2.5G interfaces and with adequate performance for the throughput, so I don't think I'll have this problem again.
-
Mmm, that's something low level in the link negotiation. Hard to say exactly what. It's not something I've seen on the 2100.
