From nobody Fri Jan 05 12:22:01 2024 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T62dn6nHFz56yQV for ; Fri, 5 Jan 2024 12:22:21 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from mail.punkt.de (mail.punkt.de [IPv6:2a00:b580:8000:11:1c6b:7032:35e9:5616]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T62dn2NvNz4SP3 for ; Fri, 5 Jan 2024 12:22:21 +0000 (UTC) (envelope-from hausen@punkt.de) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hausen@punkt.de designates 2a00:b580:8000:11:1c6b:7032:35e9:5616 as permitted sender) smtp.mailfrom=hausen@punkt.de Received: from smtpclient.apple (unknown [IPv6:2003:a:d59:3800:c103:e4c0:559f:1a39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.punkt.de (Postfix) with ESMTPSA id 2C71650093 for ; Fri, 5 Jan 2024 13:22:12 +0100 (CET) From: "Patrick M. Hausen" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Odd performance problems with many vnet jail on a bridge and (possibly) ipfw Message-Id: <7ADA08DC-3EEA-415B-98BD-CA292584C55B@punkt.de> Date: Fri, 5 Jan 2024 13:22:01 +0100 To: FreeBSD Net X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Spamd-Bar: - X-Spamd-Result: default: False [-1.13 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.93)[-0.929]; NEURAL_SPAM_LONG(0.60)[0.597]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:b580::/32]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:16188, ipnet:2a00:b580::/32, country:DE]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; DMARC_NA(0.00)[punkt.de]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_DKIM_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; TO_DN_ALL(0.00)[]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4T62dn2NvNz4SP3 Hi all, we have that single host with the largest number of jails - about 250 = active. All jails are bridged to the external interfaces (lagg + vlan) and also have a private bridge not connected to any hardware or network. The jails run a CMS and the database server is centralised. Today the customer called in and told me that he could finally spot a problem they had noticed for quite some time but where never able to really diagnose. RTT across the private bridge - again, not connected to any = infrastructure - and with 250 hosts not really an overpopulated broadcast domain is way to high and highly fluctuating: root@vpro0742:~ # ping dbhost PING6(56=3D40+8+8 bytes) fd31:4159:96::742 --> fd31:4159:96::472 16 bytes from fd31:4159:96::472, icmp_seq=3D0 hlim=3D64 time=3D140.344 = ms 16 bytes from fd31:4159:96::472, icmp_seq=3D1 hlim=3D64 time=3D166.879 = ms 16 bytes from fd31:4159:96::472, icmp_seq=3D2 hlim=3D64 time=3D158.025 = ms 16 bytes from fd31:4159:96::472, icmp_seq=3D3 hlim=3D64 time=3D111.139 = ms 16 bytes from fd31:4159:96::472, icmp_seq=3D4 hlim=3D64 time=3D124.974 = ms 16 bytes from fd31:4159:96::472, icmp_seq=3D5 hlim=3D64 time=3D137.521 = ms ^C --- dbhost ping6 statistics --- 6 packets transmitted, 6 packets received, 0.0% packet loss round-trip min/avg/max/std-dev =3D 111.139/139.813/166.879/18.762 ms For the external bridge things look similar but due to other factors at = play (larger broadcast domain, real infrastructure etc.) I'll concentrate on = the private bridge first. When the host system is booted at first the performance is as expected. The more jails are brought online the worse it seems to get. I have found various discussions concerning pf NAT and LRO and similar problems with hardware offloading. Needless to say it's all disabled on the external network interfaces (igb), but the private bridge of course = does not even have any of this. Also we do not use pf anywhere but we do use ipfw in every single jail for our inbound SNI proxy connections. So for a quick test I changed these rules to firewall_type=3D"open" in = rc.conf in two of the jails but that seemed not to change much although the = numbers seem to be slightly lower: root@vpro0742:~ # ping dbhost PING6(56=3D40+8+8 bytes) fd31:4159:96::742 --> fd31:4159:96::472 16 bytes from fd31:4159:96::472, icmp_seq=3D0 hlim=3D64 time=3D67.275 ms 16 bytes from fd31:4159:96::472, icmp_seq=3D1 hlim=3D64 time=3D69.677 ms 16 bytes from fd31:4159:96::472, icmp_seq=3D2 hlim=3D64 time=3D65.679 ms 16 bytes from fd31:4159:96::472, icmp_seq=3D3 hlim=3D64 time=3D75.663 ms 16 bytes from fd31:4159:96::472, icmp_seq=3D4 hlim=3D64 time=3D66.416 ms 16 bytes from fd31:4159:96::472, icmp_seq=3D5 hlim=3D64 time=3D92.396 ms 16 bytes from fd31:4159:96::472, icmp_seq=3D6 hlim=3D64 time=3D103.968 = ms 16 bytes from fd31:4159:96::472, icmp_seq=3D7 hlim=3D64 time=3D84.832 ms 16 bytes from fd31:4159:96::472, icmp_seq=3D8 hlim=3D64 time=3D71.411 ms 16 bytes from fd31:4159:96::472, icmp_seq=3D9 hlim=3D64 time=3D73.255 ms 16 bytes from fd31:4159:96::472, icmp_seq=3D10 hlim=3D64 time=3D50.535 = ms 16 bytes from fd31:4159:96::472, icmp_seq=3D11 hlim=3D64 time=3D51.770 = ms The rules in action look like this: --------- add 2000 fwd ::1,57 tcp from 2a00:b580:8000:12:deaf:beef:dead:beef to = me6 443 in add 2100 fwd ::1,87 tcp from 2a00:b580:8000:12:deaf:beef:dead:beef to = me6 80 in --------- The IPv6 address is our SNI proxy. We have special vhosts configured in = the web servers listening on 57 and 87, respectively, with proxy protocol = enabled for the connections via IPv4 and proxy, while 80 and 443 are regular vhosts = listening on the public IPv6 address. Any ideas would be greatly appreciated. Thanks, Patrick --=20 punkt.de GmbH Patrick M. Hausen .infrastructure Sophienstr. 187 76185 Karlsruhe Tel. +49 721 9109500 https://infrastructure.punkt.de info@punkt.de AG Mannheim 108285 Gesch=C3=A4ftsf=C3=BChrer: Daniel Lienert, Fabian Stein