Hello, I already have two servers (10.1 release, i386) with Intel gigabit dual port cards (82546GB and 82571EB) with very strange behavior regarding routing. For example, default gateway is on em0, but after some time after server restart, traffic for random ip (1.2.3.4) goes out through em1. Reset helps but only until some other ip(s) has been put on wrong interface. 'netstat -nr' is as it should be, everything worked fine on FreeBSD 9.1. Regards, Vladimir
(In reply to vladimir.nikolic from comment #0) Everything works until "server restart" and then it switches to wrong default gateway? What do you mean by "server restart"? Also, "Reset helps" as you said. What do you mean by that? Reboot? or kldloading/unloading drivers? Adding Eric from Intel.
By 'reset' I meant reboot of server. We have 'em' driver compiled into kernel, so unloading driver is not an option. I've already downgrade one server to FreeBSD 9.3 and virtualized the other one on VMware esxi host (FreeBSD 10.1 remained). It's interesting that vmware 'emulate' em driver, but 'routing' error has disappeared. Maybe I need to upgrade firmware on network cards? Regards, Vladimir Nikolic
(In reply to vladimir.nikolic from comment #0) Please post your configuration for your router/server here. Its hard to tell what you are setting up here. Also, I doubt that em(4) is in itself routing the packets incorrectly. It almost sounds like the network stack is getting confused.
Exactly the same issue here on one host. Problems started after upgrading from 9.x to 10.x, and have persisted after migrating the host to a newer hardware. Previously, it was a machine with re(4) interfaces, while the new one uses em(4), so I can confirm the problem is very probably not hardware related. I had disscussed the problem on freebsd-net@ and later reported here as PR 204735. Sorry for duplicate, I've found this bugreport just now. :) Note: I'm currently testing revisions 286028, 286037 and 286242 from HEAD, manually applied to 10-STABLE, to see whether it changes this unpleasent behaviour.
Vladimir, in case you still (after several months) have some of the misbehaving servers at hand, would you please check the kernel - is it GENERIC or some custom? And in case it's custom, could you find out whether it was compiled with "options FLOWTABLE" defined?
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
Feedback timeout (2 years).