IPv6 issues?

[Karl Denninger]

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
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4897 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20181209/1d0aa067/attachment.bin>