Date: Sun, 9 Dec 2018 10:47:47 -0600 From: Karl Denninger <karl@denninger.net> To: freebsd-net@freebsd.org Subject: IPv6 issues? Message-ID: <65c2e315-4106-dd57-b149-45f127b1056b@denninger.net>
next in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
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@denninger.net <mailto:karl@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
[-- Attachment #2 --]
0 *H
010
`He 0 *H
00 H^Ōc!5
H0
*H
01 0 UUS10U Florida10U Niceville10U
Cuda Systems LLC10U Cuda Systems CA1!0 U Cuda Systems LLC 2017 CA0
170817164217Z
270815164217Z0{1 0 UUS10U Florida10U
Cuda Systems LLC10U Cuda Systems CA1%0#U Cuda Systems LLC 2017 Int CA0"0
*H
0
h-5B>[;olӴ0~͎O9}9Ye*$ g !ukvʶLzN`jL>MD'7U 45CB+kY`bd~b*c3Ny-78ju]9H euέsӬDؽmgwER?&UURj'}9nWD i`XcbGz \gG=u%\Oi13ߝ4
K44pYQr]Ie/r0+eEޝݖ0C15Mݚ@JSZ(zȏ NTa(25DD5.l<g[[Z arQQ%Buȴ~~`IohRbʳڟu2MS8EdFUClCMaѳ !}ș+2k/bųE,n当ꖛ\(8 WV8 d]b yXw ܊:I39
00 U ]^§Q\ӎ0U #0T039N0b01 0 UUS10U Florida10U Niceville10U
Cuda Systems LLC10U Cuda Systems CA1!0 U Cuda Systems LLC 2017 CA @Ui0U 0 0U 0
*H
:P U!>vJ n io -#ן]Wyu jǑR̀Q
nƇ!G ѦF g\ yLx gw=OPycehf[ }ܷ['4ڝ\[p 6\o.B&JF" ZC{;*o*mcCcLY߾`
t*S!(` ]DHP5A~/NPp6=mhk밣'doA$86hm5ӚS@ j ެEgl
)0JG`%k35PaC?σ
׳HEt}!P㏏%*BxbQwaKG$6 h¦Mve; [o-Iی&
I,Tc ߎ#t wPA@l0P+KXBպT zGv;NcI3&J ĬUPNa?/%W6G۟N000 k#Xd\ =0
*H
0{1 0 UUS10U Florida10U
Cuda Systems LLC10U Cuda Systems CA1%0#U Cuda Systems LLC 2017 Int CA0
170817212120Z
220816212120Z0W1 0 UUS10U Florida10U
Cuda Systems LLC10U karl@denninger.net0"0
*H
0
T[I-ΆϏ dn;Å@שy.us~_ZG%<MYd\gvfnsa1'6Egyjs"C [{~ _K Pn+<*pv#Q+H/7[-vqDV^U>f%GX)H.|l`M(Cr >е͇6#odc"YljҦln8@5SA0&ۖ"OGj?UDWZ5 dDB 7k-)9Izs-JAv
J 6L$Ն1SmY.Lqw*SH;EF'DĦH]MOgQQ|Mٙג2Z9y@ y]}6ٽeY9Y2xˆ$T=e CǺǵbn֛{j |@LLt1[Dk5:$= ` M 00<+00.0,+0 http://ocsp.cudasystems.net:88880 U 0 0 `HB0U 0 U %0++03 `HB
&$OpenSSL Generated Client Certificate0 U %՞V =;bzQ0U #0]^§Q\ӎϡ01 0 UUS10U Florida10U Niceville10U
Cuda Systems LLC10U Cuda Systems CA1!0 U Cuda Systems LLC 2017 CA H^Ōc!5
H0 U 0karl@denninger.net0
*H
۠A0-j%--$% g2#ޡ1^>{K+uGE v1ş7Af&b&O; .;A5* U)ND2bF|\= ]<sˋL!wrw٧> YMÄ3\mWR hSv!_zvl? 3_ xU%\^#O*Gk̍YI_&Fꊛ@&1n } ͬ:{hTP3B.;bU8:Z=^Gw8 !k-@xE@i,+'Iᐚ:f hztX7/(hY` O.1}a`%RW^akǂpCAufgDix UTЩ/7}%=jnVZvcF<M=
2^GKH5魉
_O4ެByʈySkw=5@h.0z>
W1000{1 0 UUS10U Florida10U
Cuda Systems LLC10U Cuda Systems CA1%0#U Cuda Systems LLC 2017 Int CA k#Xd\ =0
`He E0 *H
1 *H
0 *H
1
181209164747Z0O *H
1B@>uei#|V.yVgy}[ErcuꜚPc@@˫ `L0l *H
1_0]0 `He*0 `He0
*H
0*H
0
*H
@0+0
*H
(0 +7100{1 0 UUS10U Florida10U
Cuda Systems LLC10U Cuda Systems CA1%0#U Cuda Systems LLC 2017 Int CA k#Xd\ =0 *H
10{1 0 UUS10U Florida10U
Cuda Systems LLC10U Cuda Systems CA1%0#U Cuda Systems LLC 2017 Int CA k#Xd\ =0
*H
3 ?>ja["~.c #TF!0Ka(T@ϕE$} \r~ M?/x61 _F7<?<b~ ɛr,t18F2jBr*"Ad{Ik!0kE I y_Nm {hVe{k [~Q\闇
q.Ii^{>- 2Q": |5r9"-ٛn;kL r#cc-
P3B b(Q>mLXg1l&E@:H<pEB'
R-{_<W.\.HC TK# \,{0
;"Ef~ 0XV=ԏiYXK=aCUc mGU_ m'v[(>'5! sowv
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?65c2e315-4106-dd57-b149-45f127b1056b>