For about the last month and a half I've run into some fairly-serious IPv6 performance issues, only to certain places, characterized by things like this (pkg upgrade):
Proceed with this action? [y/N]: y [1/3] Fetching nettle-3.4.1.txz: 100% 1 MiB 1.2MB/s 00:01 [2/3] Fetching mDNSResponder-878.200.35.txz: 100% 389 KiB 398.0kB/s 00:01 [3/3] Fetching dovecot-2.3.4_3.txz: 0% 8 KiB 8.2kB/s 01:29:36 ETA^C And there it sits. An "svn checkout" or "svn update" will hang, eventually failing. Before it fails it runs /very /slowly. If I "ifconfig .... inet6 ifdisabled" on the pulling source and force the IPv4 connection to be used instead everything works at normal speed. It's not consistent, however, across all sites. I have a fairly large database at a Colo in NY and run ~30gb copies from there to here over ssh -6 on a regular basis as part of my backup strategy. They work fine and produce throughput numbers right near my wire speed (50Mbps) running over the space of an hour or more. But attempts to grab material quantities of anything from the project's machines over IPv6 run into this performance issue consistently and make a full svn checkout essentially impossible. The architecture here looks like this: <S (FreeBSD 11.1-STABLE #1 r329071:)> ------ <F/W (FreeBSD 11.0-STABLE #0 r312669M: )> -- Internet (Cox Cable) Both are AMD64; the firewall is a PCEngines apu2c0, the server is a large dual-Xeon machine. Enabling verbose logging on the firewall and looking in the logs shows nothing that could be at-issue and neither box has any issues I can find with the network card or performance itself (e.g. no interface errors, the switch they're plugged into doesn't have anything interesting in terms of throttling, packet drops, mbufs are fine, etc.) and nothing has been changed in terms of software on either box related to the kernel or similar since, as you can see, quite some time ago (early 2018 for the server, mid 2017 for the firewall.) The issue itself was a "step function" change that I can peg at roughly the start of November; prior to that there's been no issue at all and I regularly keep my local repo up to date for code since I cross-build for the Pi series regularly, including stuff that was on -HEAD until 12-RELEASE came out. I get my IPv6 from Cox as a /60 using DHCP6c and use SLAAC internally (which also appears to be working fine; it hasn't had any changes made to it either.) My /suspicion /is that Cox has screwed the pooch somewhere internally when it comes to IPv6 routing. When it comes up on a specific connection the data rate doesn't immediately go to zero; it instead drops to /very /slow transfers, frequently right around 8kbps, where it stays until there's an eventual timeout -- or the initiation of the next file transfer times out with a "no response" complaint. Since I can't find evidence of a FreeBSD problem internally this is more of a "is anyone else seeing this on Cox?" sort of request; what I find especially interesting, however, is that it /always /happens when talking to Project machines for updates whether for packages or SVN, which is why I'm bringing it here. -- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/
smime.p7s
Description: S/MIME Cryptographic Signature
