Bug 204735 - [net] [flowtable] Outgoing packets being sent via wrong interface
Summary: [net] [flowtable] Outgoing packets being sent via wrong interface
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.0-STABLE
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-net (Nobody)
URL: http://lists.freebsd.org/pipermail/fr...
Depends on:
Reported: 2015-11-22 11:58 UTC by Daniel Bilik
Modified: 2019-02-01 22:30 UTC (History)
3 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Bilik 2015-11-22 11:58:26 UTC
For details, see the thread on freebsd-net mailing list, starting here:

Comment 1 Daniel Bilik 2016-05-19 13:32:12 UTC
I think I may have found a culprit - flowtable.

When comparing netinet/ip_output.c between 9-stable and 10-stable, I noticed the flowtable call is different. And looking into net/flowtable.c revealed that it was almost completely rewritten between 9.x and 10.x.

Flowtable is not included in GENERIC kernel, but our problematic host runs custom kernel with "options FLOWTABLE" defined (we had this in our kernel for 9.x and kept it when upgrading to 10.x). I've just disabled flowtable on the host via sysctl to check whether it helps (though it will take weeks to be sure, because the issue strikes just occasionally).

BTW, there are some fixes to flowtable in HEAD, specifically r292978 and r290276, both several months old. The latter was even scheduled to "MFC after 3 days", but it doesn't seem to be applied to 10-STABLE yet.
Comment 2 ykirill 2016-05-27 11:06:18 UTC
I faced the same problem. After some time some outgoing connections starts to balance on all available interfaces. Clearing and then applying default route helps for some time. I removed pf and rewrite all my rules for ipfw but problem is reappearing after some time.

 My kernels are mostly copied from 9 STABLE with additions from 10 STABLE and have too:
 options         FLOWTABLE               # per-cpu routing cache

Now i disabled it with:
sysctl net.flowtable.enable=0

I'll look if this problem happens again
Comment 3 Daniel Bilik 2016-06-22 11:16:59 UTC
After moving flowtable out of the picture, the affected router has been running with no problems for more than a month now. So I guess that described problem can be definitely considered flowtable-related (with r290276 - still not MFCed - being a fix candidate).
Comment 4 Oleksandr Tymoshenko freebsd_committer freebsd_triage 2019-02-01 22:30:51 UTC
flowtable feature was removed in base r321618, closing as OBE. If there are any plans to fix this in 11-STABLE, please reopen PR.