Search results

Thanks for the hint, I'm aware of this. Upgrading to 13.0 is currently not an option, so I'll have to use 12/STABLE for the time being.

The solution was to upgrade to FreeBSD 12/STABLE, so apparently there was a bug somewhere.

Could you please elaborate further on this?

OK, so I've replaced the Intel X540 NIC with a Chelsio T520-BT NIC, just to be sure that it's not a driver issue. And yes, it's not a driver issue. The outage also occurs with the Chelsio NIC. I've already mentioned that this issue does also affect LACP (which was only enabled for testing...

The FreeBSD server is at no point "overloaded" in that sense that CPU or RAM is a bottleneck, it's in fact ~70% idle. Mind you, this server is just a load balancer, the application is running on a different server. My expectation is that any reasonable sized server should be able to handle...

It looks like I'm already using a newer version of the driver: $ sysctl -a | grep driver_version dev.ix.1.iflib.driver_version: 4.0.1-k dev.ix.0.iflib.driver_version: 4.0.1-k All HW offloading features are already turned off. Thanks for your suggestions! Regards - Frank

OK, tested this on the spare server and changed hw.ix.enable_msix from 1 to 0. After a reboot, the server immediately had networking issues, even without any networking load. I've reverted the change and the networking was again working as expected. I couldn't find much information about the...

Yes, that was the first thing I've already double checked. I took great measures to ensure that it's not the switch that is causing this, and I'm pretty confident the switch is not to blame. LAGG active/passive is working perfectly fine. LACP would in theory also work fine, it just does not play...

I was considering this too, so I've double-checked and it's definitely this FreeBSD server that is to blame. Everything else in the network is fully operational, only this server goes down. Unfortunately no log messages, no kernel errors, etc. (Except the "listen queue overflow", but that was...

Unfortunately, even after disabling all HW offloading features, the server is still unreachable when hit by many TCP connections. A ping during this situation nicely demonstrates this: icmp_seq=62 ttl=59 time=1.37 ms icmp_seq=63 ttl=59 time=1.20 ms icmp_seq=64 ttl=59 time=1.23 ms icmp_seq=65...

Yes, PF is in use but states limit is not reached (usually only 1% usage). Oh yes, good idea! I was under the impression that I've already disabled everything, but I've missed some features: ix0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500...

Sure, that's on my list. But a server shouldn't be completely unreachable in this situation.

Hi, I'm running FreeBSD 12 as a load balancer (HAProxy). However, when my application slows down and TCP connections cannot be processed fast enough, the server becomes completely unreachable – TCP, ICMP, CARP, everything IP-related is 100% down. At first I've discovered the usual messages...

OK, this was easy to solve. My KVM Hypervisor is oVirt... I wasn't aware that they introduced the network-filters feature which prevents guests from spoofing other mac-addresses than these which were assigned by the oVirt engine. I just needed to disable this anti-spoofing feature. Now uCARP...

Hi, I'm running two FreeBSD 9.1 VMs on a KVM Hypervisor. While this basically works quite well, I can't get uCARP to work. First I thought it must be a multicast issue (because I consider multicast to be black magic), but a quick test shows (I assume) that multicast is working: On VM 1 I...

Folks, the poll for march was invalid. Please vote for FreeNAS on the april poll: http://sourceforge.net/blog/vote-for-the-april-potm/

Hi, I think FreeNAS is doing a good job to spread the word about FreeBSD. That said I think it is reasonable to support FreeNAS: SourceForge Project Of The Month The poll ends in 5 days. FreeNAS is at 44%... not bad, but more is needed :-) Bye - Frank

Hi, FreeBSD 9.0 is out and ships with bsdinstall. So I wonder how to do an unattended/scripted installation? With sysinstall we had the install.cfg to do it, but I couldn't find any information on how to do it with bsdinstall. Bye - Frank

This is an acceptable *hack* to get the job done quickly, but I don't think it's a *reasonable* fix. The patch files in devel/pecl-intl should be fixed or removed. Let's see if my PR gets some attention... bye - Frank

Did you file a PR? I couldn't find one... so I just filed a new PR, since the problem still exists: ports/156660 (may take a few hours to be clickable). I would appreciate any useful input or follow-ups to my PR. Bye - fraenki