Very slow traffic from other VM's through pfSense on XenServer
-
This helped me too. I only did this for my LAN port.
In my setup it seemed to be sufficient to execute:
xe vif-param-set uuid=VIFUUID other-config:ethtool-tx="off"
xe vif-param-set uuid=VIFUUID other-config:ethtool-rx="off" -
This helped me too. I only did this for my LAN port.
In my setup it seemed to be sufficient to execute:
xe vif-param-set uuid=VIFUUID other-config:ethtool-tx="off"
xe vif-param-set uuid=VIFUUID other-config:ethtool-rx="off"I can confirm that the LAN port should be enough. On a related note, did someone install the XenServer Tools in the VM?
-
Hi,
updated my XenServer 6.2 to 6.5 a few day ago with my VM pfsense 2.1.5 with no issue
updated pfsense to 2.2 WITH XENTOOLS (xe-guest-utilties 6.0.2_3) and got the same issue !
installed xentool using that method http://blog.feld.me/posts/2014/07/pfsense-on-citrix-xenserver/ (Thanks feld !)
look like issue remain even with Xentools :/
anyone can confirm ?
-
Yes. It's broken.
-
damn !
but a quesiton remain … was it working well in snapshot ? was it working well with previous version of xentool ?
in this thread
https://forum.pfsense.org/index.php?topic=86827.0
it look like to be an issue with xn nic …
maybe a previous version should work ? -
No.
Just disable the tx/rx like in the above until FreeBSD and/or Citrix fixes it.
-
Ok
didi the above fix and it finally work.
Thanks folks !
-
My Internet speed normally is 20 Mb/s down and 2 Mb/s up.
I deployed pfSense 2.2-RELEASE X64 in XenServer 6.5
Without modification, the pfSense 2.2 would only muster 5 Mb/s down, and 0.06 Mb/s up. Painful.
I applied the changes to the LAN side VIF and the upload speed went back to full 2 Mb/s. The WAN speed did not improve.
I applied the changes to the WAN side VIF and the upload speed went back up to 20 Mb/s.
Eureka!
-
It's just the tx-offload setting that needs to be changed, rx-offload is fixed-on.
I can confirm the problem and fix with Debian Wheezy/Xen 4.1.4 dom0.
ethtool -K ${dev} tx off in vif-bridge online did the trick.
The issue wasn't submitted to freebsd-bugs so far, now it is:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197344 -
Interesting - only appears to apply to virtual interfaces.
My pfSense VM is running in xen 4.2 (Centos 6.6 dom0) and has no speed issues, but I'm using pci-passthrough to give 2 dedicated hardware NICs (off a dual-port Intel card) to pfSense for LAN/WAN (so that DMZ/intranet are physically separate too).
-
Thanks johnkeats for putting that up here. It really helped me sort this out.
One thing to note is disabling tx offload using ethtool -K does not persist across guest reboots or live migration because the dom-id and assigned vif changes, while xe vif-param-set other-config:ethtool-tx="off" does.
Is there any downside to using the vif-param-set option, or are the two basically equivalent?
-
@johnkeates:
You only need to disable checksum offloading on the hypervisor side of pfSense's interface.
Any interface that does DomU-DomU communication on pfSense's side produces un-checksummed packets which get dropped by PF in BSD.
sudo ethtool -K $interface tx off
where $interface is the VIF on the Xen Dom0 side is enough. Setting TX off on the bridge forces the Dom0 to calculate ALL checksums on ALL packets no matter where the come from or where they are going. This is not a smart idea since it creates a lot of calculations where they might not be needed. So if the pfSense DomU is on vif123.0 you run: sudo ethtool -K vif123.0 tx off
Sorry noob question here,
I am using a Xen implementation on a unraid distribution, when you say Dom0 side are you talking about the VIF that is spun up with the PFsense VM ? Like when i ifconfig to list my interfaces I just don't really know how to identify the interface you are referring to.
Sorry for the noob question again
-
It's all here:
https://forum.pfsense.org/index.php?topic=85797.msg475906#msg475906
I recently just rebuilt my test stack and all I did was the tx and rx on every NIC which is still probably more than is necessary but it worked.
-
@johnkeates:
You only need to disable checksum offloading on the hypervisor side of pfSense's interface.
Any interface that does DomU-DomU communication on pfSense's side produces un-checksummed packets which get dropped by PF in BSD.
sudo ethtool -K $interface tx off
where $interface is the VIF on the Xen Dom0 side is enough. Setting TX off on the bridge forces the Dom0 to calculate ALL checksums on ALL packets no matter where the come from or where they are going. This is not a smart idea since it creates a lot of calculations where they might not be needed. So if the pfSense DomU is on vif123.0 you run: sudo ethtool -K vif123.0 tx off
Thank you for taking the time to explain this, i turned the TX off on the pfsense vif and all was good. Happy days
-
Hello all…
Thanks for the information - sure helped us solve this but I have some more information that wasn't clear to me from all posted here.
This issue only seems to apply where Pf is communicating with hosts within the same xen host (dom0).
We use xenserver 6.2 fwiw. We have two xen dom0 - pf was natting for two services - one on dom0-a and one on dom0-b
pf itself was located on dom0-b
The dom0-a service worked perfectly after the update to 2.2.2 - the dom0-b service did not.For people new to xenserver / for completeness, we used:
xe vm-list
#then find the uuid of your pf vm
xe vif-list vm-uuid={uuid of the vm from above}
#note the uuid of the vif - not the network you want to change!
#for each vif you can check the status:
xe vif-param-get uuid={uuid of vif} param-name=other-config
xe vif-param-set uuid={uuid of vif} other-config:ethtool-tx="off"For what it's worth I was able to turn off tx on only the LAN interface (which nats for the dom0-b service).
I tried but did not need to keep offload off for the WAN interface which seems to get proper checksum as it leaves the dom0 through the physical nic.
Once complete you need to reboot the pf vm. the setting will persist across reboots.
Hope that helps someone else :-)
Mitch
-
I've been running pfsense 2.2 on XenServer 6.2 for a while with the mentioned offloads disabled and it's been working great. I believe since I upgraded to XenServer 6.5 (or when I upgraded to 6.5 SP1) pfsense only works as before on one specific host in the pool. I have 3 hosts in the pool and when pfsense is running on 2 of them it is very slow, but on the 3rd host it works fine.
How come..?? ???
-
Without knowing your network I can only guess… but see if this makes sense.
What I found was that if the pfsense was routing traffic for vm's on other systems (outside the xen box itself) then things worked - the offload worked as expected as the offload is added at the nic as the data leaves the xen server.
When I was routing traffic that was contained by the virtual network on the same xen host, that's when it didn't work - until I disabled the offloads - you only need to disable on the paths which you see the performance issues in my opinion - but you have to think it through.
Cheers.
-
The stack in the diagram in my sig is all on XenServer 6.5. Works fine as long as the checksumming is turned off.
-
Well, this issue is when traffic flows from external machines through pfsense wan-interface to resources on the internal lan.
The host on where this works has different hardware (including different NIC's) than the other two hosts in the pool. So when I migrate or restarts pfsense on host 1 or 2 I don't get through the firewall from the outside (ia its so slow that it dont work). But with pfsense on host 3 it works as expected.
Before it worked on all 3 hosts. Now the pfsense is not protected against host failure.
-
Well, this issue is when traffic flows from external machines through pfsense wan-interface to resources on the internal lan.
The host on where this works has different hardware (including different NIC's) than the other two hosts in the pool. So when I migrate or restarts pfsense on host 1 or 2 I don't get through the firewall from the outside (ia its so slow that it dont work). But with pfsense on host 3 it works as expected.
Before it worked on all 3 hosts. Now the pfsense is not protected against host failure.
What are the eth specs when it's failing? And is it a live migration or a shutdown-boot migration?
If you want to protect against failure, it's better to use pfSense's failover options instead of hypervisor-based failover.
