pfsense latency spikes in ESXi
-
@rod-it But if you do nat at the isp router(it doesn't have to be double), then the corrected firmware "covers" the issue.
When in bridge mode, it does/can not.Unless there is a situation when another router is being used in bridge mode and not experiencing the lags, then it can be attributed to pf.
I doubt 2.5 can solve this.
-
While i agree with you, there are videos showing that for some 2.5 does fix the issue - the forum linked above also shows people using pf with SH3 and not facing the issues. Perhaps it's related to the NICs in the Pf box and how the SH3 is talking to it.
While i know Puma is the cause, based on what you say above, if we rule out Pf completely, there is no fix, other than downgrading broadband to a SH2 or moving ISP, which in some cases is not an option, the only other option is to remove Pf completely and go back to a physical router (My Nighthawk didn't show these symptoms) or just use the SH3 directly, which is a bad choice for anyone who wants to do more than basic internet. I can also tell you that if i leave the modem in bridged mode and connect a laptop or PC directly, i also do not have these issues.
I can also tell you that my issues spiked (no pun intended) back in Feb/March of 2020, and you'll see this posted all over the place too, I believe this was the date VM put the fix described above in place for anyone in router mode, but sadly this made things worse for those of us who use bridged mode.
To be clear, i am not saying this is a Pf or BSD issue directly, but something not gelling well between the sH3 and Pf/BSD
I, like many others would just love to know a solution, replacing the modem or changing ISPs is not an option, reverting to a hardware router and not using Pfsense is an option, but not one i'd like to have to choose.
Appreciate everyone input and help though
-
@cool_corona completely different subnets, in bridge mode
-
If we start doubting things like how ethernet works at the hardware level, then we have a multitude of options we can't really control. to blame too.
For example, if traffic for the bridged modem passes through a l2 switch which gets it from a tagged trunked port and feeds it untagged to the bridged modem , it also adds a store and forward buffer and a few microseconds of delay.It should be neglicible and hard to measure.
However a faulty receiving end on the bridged modem could be positively or negatively affected with this buffering.
I'm wild guessing here, lets hope someone stumbles upon a combination that will work for the rest of us.
-
Happy new year everyone!
Now I have brand new hardware box - 6 port Qotom Q555G6 with i5-7200U, 8GB RAM, 64 GB SSD.
Installed pfsense, set it up manually from scratch. In general, latency decreased a bit but latency spikes and packet drops are the same as they were before (1-30%).
Installed opnsense, set it up manually again, from scratch. Same latency spikes with packet drops (20-30 % at times).
Both used in Fail-safe 2 WAN configuration as per configuration with one gateway group and dpinger enabled.
Direct connection to the router doesn't have such issues. Ping spikes and packet loss happen on both WAN interfaces even when ISP modems connected directly to pfsense/opnsene hw box (one is puma6 affected with firmware patches installed, the other one is not affected).No idea what else to do here, it's annoyed the hell out of me already.
It looks like it's an issue with freebsd itself. Seems to be related to https://forum.netgate.com/topic/151819/2-4-5-high-latency-and-packet-loss-not-in-a-vm/
I also increased Firewall Maximum States to 1632000 and Firewall Maximum Table Entries to 2000000 but it didn't make any difference at all. -
2.4.5 had this issue and it was supposed to be fixed in p1 for anyone who used more than a single core, however it has not fixed it for me, i still suffer the same WAN issues. (notably, I didn't have them in 2.4.5)
I do not see this when directly connected to my ISPs router, but part of the reason for moving away from it was it's very basic and Pfsense does a lot for me.
I've still yet to find the time to install a 2.5 and play with it, but with it being not so far off it's possible final release, I've waited this long, a little longer wont hurt.
I still think something else is going on under the hood and I've offered logs, I just wouldn't know where to start to troubleshoot this.
-
@rod-it FYI, on the opnsense roadmap for 21.1 which is due to be released at the end of January (hopefully) very first bullet is "Fix stability and reliability issues with regard to vmx(4), vtnet(4), ixl(4), ix(4) and em(4) ethernet drivers." Hope they'll manage to eliminate this issue.
I went through alternatives and about to give openwrt a try. The rest opensource/free firewalls are far behind pf/opnsense functionality wize.With 2.4.5 I had way too high CPU load.
-
I have no issues with my Qotom , see signature
-
I'm running ESXi with lots of VM's similar to OP and also using a Virgin Media Superhub 3 in Bridged mode connected to a virtualised pfSense box 4vCPU's and 6GB of RAM assigned.
@Rod-It On 2.4.5 I experienced some issues with unbound crashing and pfBlockerNG DNSBL, however 2.4.5-P1 resolved most of these problems. I'm using FQ_Codel which has helped keep my latencies more in check, but the underlying issues with the SH3 and the ISP Virgin media as a whole still exist. Only recently my area got upgraded to Docsis 3.1, despite the modem not being able to support it I suspect the upgrades helped out with congestion/latency in the area.
Here's a quick screenshot of the latencies mapped out by Grafana on my monitoring stack:
Few spikes here and there, but nothing too major.I had a quick skim read through the thread, but does taking pfSense out the equation help at all? @oiyae
PS: I'm on Vivid 350 package HUB firmware: 9.1.1912.302
-
@pfsensation it does, when I got PC connected directly into SH3 router running for a good few hours with MTR to 8.8.8.8 there were no issues whatsoever. At the same time laptop connected over the wire to pfsense box shown packet drops and latency spikes with MTR to 8.8.8.8 and google.com
Docsis 3.0
HW version 5.01
SW version 6.12.18.26 -
@oiyae said in pfsense latency spikes in ESXi:
@pfsensation it does, when I got PC connected directly into SH3 router running for a good few hours with MTR to 8.8.8.8 there were no issues whatsoever. At the same time laptop connected over the wire to pfsense box shown packet drops and latency spikes with MTR to 8.8.8.8 and google.com
Docsis 3.0
HW version 5.01
SW version 6.12.18.26Call up VM and get the SH3 replaced, yours seems to be a much older revision and it's running software a lot older compared to mine. I would start there as in the newer firmware versions they have improved the latency issues quite a bit by offloading tasks off to the WiFi SoC.
Here's the info on mine below
Standard specification compliant : DOCSIS 3.0 Hardware version : 10 Software version : 9.1.1912.302 -
@pfsensation they'll send me a replacement that supports 1Gb, will see how it goes
-
As far as i know they'll only send a SH4 if you buy the gig1 package or specifically ask for one and the rep is kind enough to honour it, but even so they still use the Puma chipset.
They do mask the problem better, but it's still there.
If they do send you a SH4 though I'm going to try that also
-
@rod-it said in pfsense latency spikes in ESXi:
As far as i know they'll only send a SH4 if you buy the gig1 package or specifically ask for one and the rep is kind enough to honour it, but even so they still use the Puma chipset.
They do mask the problem better, but it's still there.
If they do send you a SH4 though I'm going to try that also
For the time being, yeah. They're only giving it out to gig1 customers or anyone in a severely high utilisation area that makes enough noise.
I've asked several times, bypassed the Indian customer service and spoke to someone in the UK. The general gist I got is, only their Level 2 and higher technical team can order a SH4 in specific circumstances (low supply?). However, getting through to one of those guys right now is near impossible.
Do let us know how it goes! I've recently signed up to extend my virgin media contract because no one else in my area supplies more than 60meg. Being a network engineer myself, not a great fan of their network or their hardware as you can imagine...
-
For ESXi deployments, note that FreeBSD and hence pfsense disables MSX-I interrupt handling per default and thus causes substantially higher CPU load. This could lead to spikes.
Try inserting the following into your /boot/loader.conf.local:
hw.pci.honor_msi_blacklist=0
References:
- https://forum.netgate.com/topic/157688/remove-vmware-msi-x-from-the-pci-blacklist
- further Google hits
-
That link talks about PCI passthrough, for me i am running the system fully virtual, no pass-through.
My issue was present in ESXi 6.7U2, U3 and I've since upgraded to ESXi 7.01 and the issue still persists, I also changed my storage from PCIe SSDs to NVMe SSDs.
CPU is less than 5% most of the time in my setup.
My spikes are only on the WAN too, not the LAN, and have never been LAN side.
Thanks for the article though.
-
@rod-it look at the netgate documentation -> tuning -> vmxnet, they have the same advice there (since a few months I believe).
https://docs.netgate.com/pfsense/en/latest/hardware/tune.html#vmware-vmx-4-interfaces
-
Thank you again, i will look at it more tomorrow, but one has to assume if this was the cause, both the LAN and the WAN would have these issues, no?
FYI, my server has 4 on-board NICs;
Broadcom NetXtreme BCM5719
In case it helps or is relevant.
I do also have a couple of spare 4 port Intel NICs, I'm half tempted to throw one in the server and see if this makes any difference moving my settings over - specifically the WAN one for now.
My issues also didn't start until around March time of last year
-
If you are willing to experiment, try removing the VMX interfaces presented to your pfSense VM and replace them with E1000e.
Not the recommended solution, I know, but I had a lot of problems with VMX and FreeBSD (both my mail server and pfSense). Changing to E1000e worked for me.
I'm not sure if it's related to the problems I saw but pass-through is enabled automatically when adding VMX interfaces through the ESXi GUI.
-
I will try that later if I can, adding / removing and reconfiguring NICS can be done on the fly.
Note though that you are likely referring to DirectPath I/O, which passes through specific functions of the cards, not the cards themselves.
This can of course be disabled if needs be.
If I get the chance later today I will edit the WAN NIC to be E1000e and see how it goes over night.
