鯖缶

8.1.4 インタフェースの MTU の設定

実際にはこの設定が適用されるのは IP パケットだけである。他のプロトコルには適用されず、それらではデフォルトのまま 1500 の MTU となる。

微妙に気になるが…… IP パケット以外というと arp とか rarp とか PPP とかそういう話か。
ICMP は IP に含んで良いのだったっけ？

まあとにかく実用上の問題はたぶんないと信じることにしておく。

• 設備・備品 #283: Router: chima (2代目) (YAMAHA, RTX1300) で LAN 向けの I/F の MTU を 10218 (最大値) に設定。
• 設備・備品 #214: Switch: charon (MikroTik, CRS326-24S+2Q+) は「L2MTU」が最初から 10218 でスイッチとして利用しているので、設定変更は不要。
• 設備・備品 #211: Switch: asumi (NETGEAR, MS510TXUP) は「フレームサイズ」を 10000 (最大値) に設定済なので、これ以上の変更は不要。

……と、ここまでやって気付いたが、 mgmt VLAN 用に使っている 設備・備品 #334: Switch: (NETGEAR, GS324-200JPS) が MTU を弄れないやつだった。
どうせ 1GbE なのでそれで良いのだが、末端側でうっかり MTU を上げないように注意する必要がある。
ルータではこちらも MTU=10218 にしてしまったが、末端同士のネゴシエーションの結果 1500 になるなら問題なかろう (ほんまか)。

中継機器類はこれで全部だと思うので (無線 AP は無視して良いはず)、次は末端の機器。

The use of 9000 bytes as preferred payload size for jumbo frames arose from discussions within the Joint Engineering Team of Internet2 and the U.S. federal government networks.^[7] Their recommendation has been adopted by all other national research and education networks.[citation needed] Manufacturers have in turn adopted 9000 bytes as the conventional MTU size, with a total jumbo frame size of between 9014 and 9022 bytes with Ethernet headers included.^[8] Most Ethernet equipment can support jumbo frames up to 9216 bytes.^[9]

— Jumbo frame - Wikipedia

べつにもっとデカくとも良いのだが米政府の推奨として9000ということになっており、機器もそれに対応できる程度で実装されるため、だいたいの機器が大丈夫なラインは 9216 bytes (= 9 KiB ちょうど) だろうとのこと。

chima で ip lan1 mtu 10218 してから show status lan1 しても Maximum Transmission Unit(MTU): 1500 octets と言われるのだが。

nop_thread さんは #note-6 で書きました:

chima で ip lan1 mtu 10218 してから show status lan1 しても Maximum Transmission Unit(MTU): 1500 octets と言われるのだが。

どうもこれは L3 の MTU 設定のようで、 L2 MTU は lan type lan1 mtu=10218 とかのようだ。
これで無事に Maximum Transmission Unit(MTU): 10218 octets になった。

コマンド実行後数秒間通信が詰まったのでマズいことをしたかとビビったが、すぐに復旧したので問題なかったようだ。

追記:

本コマンドの実行後、LAN インターフェースのリセットが自動で行われ、その後に設定が有効となる。
RTX3510、RTX1300 では、このコマンドを実行すると、すべての LAN インタフェースが同時にリセットされる。

— 4.50 LAN インターフェースの動作タイプの設定

ルータまでは問題なく jumbo frame で疎通するようになったが、 設備・備品 #214: Switch: charon (MikroTik, CRS326-24S+2Q+) で MTU=1500 になっている模様。
bridgeLocal に ether1 (RJ45, Max L2 MTU = 2028) が参加しているせいで bridgeLocal の Actual MTU が 1500 になっているので、たぶんこれのせい。
ただ bridgeLocal から ether1 を除外することってできたっけ……？

いや設定を確認してみたところ ether1 は bridgeLocal に参加している気配がない。
一体何なんだ……

bridgeLocal から生やしている VLAN interface をすべて MTU=10218 にしたところ bridgeLocal の Actual MTU も 10218 になったが、まだ charon への ping は mtu = 1500 と伝えてくる。

• sakuno (lab) → charon → millicent (lab): OK
• sakuno (lab) → charon → nagisa (lab): OK
• sakuno (lab) → charon → chima (lab): OK
• sakuno (lab) → charon → chima → atri (gadgets): NG (mtu=1500)
• atri (gadgets) → chima → charon → sakuno (lab): NG (mtu=1500)
• atri (gadgets) → chima → charon → nagisa (lab): NG (mtu=1500)
• atri (gadgets) → chima → charon → millicent (lab): NG (mtu=1500)
• millicent (lab) → charon → chima → charon → sakuno (trusted-old): NG (mtu = 1500)

こうして見てみると、やはりルータ (chima) の方の怪しさが勝ってくる気もする。
特に同一 VLAN 内での sakuno, nagisa, millicent の通信は charon のみを経由しているはずなのだが、これがうまく通っている。

chima に #334 (SOHO/家庭向け 300シリーズ - GS324v2) が繋がっているせいかとも思ったが、こちらはデータシートにしっかり「Jumbo Frame Support 9,216 bytes」と書いてある。

Does the GS324 support jumbo frames?¶

Yes, it supports jumbo frames up to 9,216 bytes.

— GS324 FAQs - NETGEAR Support

しかし charon を通る必要のない mgmt VLAN 内での jumbo frame はうまく通っていない様子。
いったん chima から外して確認してみるか。
→外しても変わらなかった。

• chima → asumi (mgmt): OK
• chima → (GS324v2) → millicent (mgmt): NG

おっと。やはりこいつか？

millicent の mgmt 用のインターフェースを確認したところ、どうも MTU は 9194 が最大らしく、 9216 を設定しようとして dmesg で「mtu greater than device maximum」と言われていた。そんなこともあるのか。

……もしかしてこれ payload size の話してる？

9194 にしたら sakuno (mgmt) ←→ GS324v2 ←→ chima ←→ millicent (mgmt) も普通に通るようになった。そうか……
(millicent は一時的に chima に直結している。)

atri (gadgets) → chima → millicent (mgmt) と atri (gadgets) → chima → GS324v2 → sakuno (mgmt) も無事通っている。
なんだかいけそうな気がしてきた。つまり SFP+ の方も MTU がデカすぎるか確認すればよさそう。

→maxmtu 9600 だった。じゃあ大丈夫なはずじゃん……

• millicent (lab) → charon → sakuno (lab): OK
• millicent (mgmt) → GS324v2 → chima → charon → sakuno (lab): OK
• millicent (lab) → charon → chima → GS324v2 → sakuno (mgmt): OK

どうやら経路には問題なさそう。となると、あとは atri 側の問題か……
といっても atri は仮にも 10GbE なのもあり maxmtu 16334 なので余裕のはず。

• atri (gadgets, mtu=9194) → asumi → charon → sakuno (lab, mtu=9212): NG

asumi か……？ #note-3 のとおりフレームサイズ 10000 になっているが……

• atri (mgmt) → GS324v2 → chima → charon → sakuno (lab): NG
• atri (mgmt) → GS324v2 → sakuno (mgmt): OK
• chima → GS324v2 → atri (mgmt): OK
• chima → charon → sakuno (lab): OK
• chima → charon → sakuno (mgmt): OK

うん？？？？？

• GS324v2 は #note-15, #note-17, #note-18 から問題ない
• charon は #note-17, #note-18 から問題ない
• chima の同 VLAN 間は #note-15 から問題ない
• chima の別 VLAN 間は #note-16, #note-17 (millicent/mgmt - sakuno/lab) から問題ない
• sakuno/lab は #note-17 から問題ない
• atri は #note-18 から問題ない、はずだが……

誰が悪いのかさっぱりわからん。

• atri/mgmt → GS324v2 → chima → charon → sakuno/lab: NG
• atri/mgmt → GS324v2 → chima → charon → millicent/lab (ping: local error: message too long, mtu=1500): NG
• sakuno/lab → charon → chima → GS324v2 → atri/mgmt: OK
• millicent/lab → charon → chima → GS324v2 → atri/mgmt: OK

なぜ！？

• atri/mgmt → chima → charon → sakuno/lab: NG
• atri/mgmt → chima → charon → sakuno/millicent: NG
• sakuno/lab → charon → chima → atri/mgmt: OK
• millicent/lab → charon → chima → atri/mgmt: OK
• atri/mgmt → chima → GS324v2 → sakuno/mgmt: OK
• atri/mgmt → chima → GS324v2 → millicent/mgmt: OK
• atri/mgmt → chima → GS324v2 → nagisa/mgmt (MTU=1500): OK ←なぜ！！？！？！？？？

ここに来て新展開が……
もしかして受け取ってレスポンスを返すだけなら MTU は低くてもいい？ →んなわけあるか

• nagisa/lab (MTU=9216) → charon → chima → atri/mgmt (MTU=9194): OK

• naigsa/mgmt (MTU=1500) → chima → atri/mgmt (MTU=9194): NG (ping: local error: message too long, mtu=1500 )

• ping -I(lab) -v -M do -s 9188 -c1 (atri): OK

  • 9188+28 =9216

• ping -I(lab) -v -M do -s 9189 -c1 (atri): NG (ping: local error: message too long, mtu=9216)

ping が出している mtu に関する数値は送信側の値を使っている雰囲気がある。

• millicent/lab (MTU=9216) → charon → chima → atri/mgmt (MTU=8800): OK (ping -s 9188)
• millicent/lab (MTU=9216) → charon → chima → asumi → chelsea/lab (MTU=1500): NG (ping -s 9188) (メッセージなし)
• millicent/lab (MTU=9216) → charon → chima → asumi → chelsea/lab (MTU=1500): NG (ping -s 1491) (メッセージなし)
• millicent/lab (MTU=9216) → charon → chima → asumi → chelsea/lab (MTU=1500): OK (ping -s 1490)

わからんな……

• chima → atri/mgmt (MTU=8800): OK (ping -s 9000)
• atri/mgmt (MTU=8800) → chima: OK (ping -s 8772)

一旦状況を整理する。

• 環境
  • chima: router
  • GS324v2: switch
  • charon: switch
  • atri/mgmt (MTU=9216) ←→ chima ←→ charon ←→ millicent/lab (MTU=9216)
  • atri/mgmt (MTU=9216) ←→ chima ←→ GS324v2 ←→ millicent/mgmt (MTU=9194)
  • atri/mgmt (MTU=9216) ←→ chima ←→ charon ←→ sakuno/lab (MTU=9212)
  • atri/mgmt (MTU=9216) ←→ chima ←→ GS324v2 ←→ sakuno/mgmt (MTU=9194)
• ping
  • atri/mgmt → millicent/lab (-s 8000): ping: local error: message too long, mtu=1500
  • millicent/lab → atri/mgmt (-s 8000): OK
  • atri/mgmt → sakuno/lab (-s 8000): ping: local error: message too long, mtu=1500
  • sakuno/lab → atri/mgmt (-s 8000): OK
  • millicent/mgmt → atri/mgmt (-s 8000): OK
  • atri/mgmt → millicent/mgmt (-s 8000): OK
  • sakuno/mgmt → atri/mgmt (-s 8000): OK
  • atri/mgmt → sakuno/mgmt (-s 8000): OK

説明としては、「atri から millicent や sakuno への jumbo frame だけはうまく飛んでいないように見えるが、実のところ #23 の実験 (millicent/lab → atri/mgmt) を見ると ping の報告する OK が信用ならない」という感じか。

traceroute の結果。

atri$ traceroute (sakuno/lab) --mtu
traceroute to (sakuno/lab) ((sakuno/lab)), 30 hops max, 65000 byte packets
 1  _gateway ((chima/mgmt))  0.345 ms F=9216  0.258 ms  0.251 ms
 2  (sakuno/lab) ((sakuno/lab))  0.508 ms F=1500  0.463 ms  0.253 ms

atri$ traceroute (sakuno/lab) --mtu
traceroute to (millicent/lab) ((millicent/lab)), 30 hops max, 65000 byte packets
 1  _gateway ((chima/mgmt))  0.302 ms F=9216  0.319 ms  0.260 ms
 2  (millicent/lab) ((millicent/lab))  0.686 ms F=1500  0.565 ms  0.550 ms

atri$ traceroute (millicent/mgmt) --mtu
traceroute to (millicent/mgmt) ((millicent/mgmt)), 30 hops max, 65000 byte packets
 1  (millicent/mgmt) ((millicent/mgmt))  0.597 ms F=9216  0.942 ms  0.574 ms

atri$ traceroute (sakuno/mgmt) --mtu
traceroute to (sakuno/mgmt) ((sakuno/mgmt)), 30 hops max, 65000 byte packets
 1  (sakuno/mgmt) ((sakuno/mgmt))  0.981 ms F=9216  0.591 ms  0.586 ms

millicent$  traceroute -n (sakuno/lab) --mtu
traceroute to (sakuno/lab) ((sakuno/lab)), 30 hops max, 65000 byte packets
 1  (sakuno/lab)  0.746 ms F=9216  0.531 ms  0.499 ms

millicent$ traceroute -i (mgmt) -n (sakuno/lab) --mtu
traceroute to (sakuno/lab) ((sakuno/lab)), 30 hops max, 65000 byte packets
 1  (sakuno/lab)  0.619 ms F=9194  0.573 ms  0.398 ms

millicent$  traceroute -i (lab) -n (sakuno/mgmt)--mtu
traceroute to 192.168.10.26 (192.168.10.26), 30 hops max, 65000 byte packets
 1  (chima/lab)  0.143 ms F=9216  0.093 ms  0.097 ms
 2  (sakuno/mgmt)  0.587 ms  0.550 ms  0.546 ms

millicent$ traceroute -i (mgmt) -n (sakuno/mgmt) --mtu
traceroute to (sakuno/mgmt) ((sakuno/mgmt)), 30 hops max, 65000 byte packets
 1  (sakuno/mgmt)  0.415 ms F=9194  0.395 ms  0.387 ms

millicent$ traceroute -i (lab) -n (atri/mgmt) --mtu
traceroute to (atri/mgmt) ((atri/mgmt)), 30 hops max, 65000 byte packets
 1  (chima/lab)  0.274 ms F=9216  0.090 ms  0.094 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  *^C

millicent$ traceroute -i (mgmt) -n (atri/mgmt) --mtu
traceroute to (atri/mgmt) ((atri/mgmt)), 30 hops max, 65000 byte packets
 1  * F=9194 * *
 2  * * *
 3  * * *
 4  * * *
 5  *^C

sakuno$ traceroute -n (millicent/lab) --mtu
traceroute to (millicent/lab) ((millicent/lab)), 30 hops max, 65000 byte packets
 1  (millicent/lab)  0.791 ms F=9212  0.820 ms  0.518 ms

sakuno$ traceroute -i (mgmt) -n (atri/mgmt) --mtu
traceroute to (atri/mgmt) ((atri/mgmt)), 30 hops max, 65000 byte packets
 1  * F=9194 * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  *^C

9216 は millicent/lab の MTU で、9212 は sakuno/lab の MTU なので、 traceroute では送信側の MTU が見えている様子。
かと思えば millicent/mgmt → sakuno/lab ではちゃんと F=9194 になっている。

millicent → atri はインターフェースに関係なく traceroute --mtu が結論を出してくれていない。

追加実験。

atri$ traceroute -n (chima/lab) --mtu
traceroute to (chima/lab) ((chima/lab)), 30 hops max, 65000 byte packets
 1  (chima/lab)  0.620 ms F=9216  0.396 ms  0.386 ms

atri$ traceroute -n (chima/mgmt) --mtu
traceroute to (chima/mgmt) ((chima/mgmt)), 30 hops max, 65000 byte packets
 1  (chima/mgmt)  0.452 ms F=9216  0.381 ms  0.370 ms

millicent$ traceroute -i (lab) -n (chima/lab) --mtu
traceroute to (chima/lab) ((chima/lab)), 30 hops max, 65000 byte packets
 1  (chima/lab)  0.297 ms F=9216  0.233 ms  0.232 ms

millicent$ traceroute -i (lab) -n (chima/mgmt) --mtu
traceroute to (chima/mgmt) ((chima/mgmt)), 30 hops max, 65000 byte packets
 1  (chima/mgmt)  0.429 ms F=9216  0.251 ms  0.235 ms

millicent$ traceroute -i (mgmt) -n (chima/lab) --mtu
traceroute to (chima/lab) ((chima/lab)), 30 hops max, 65000 byte packets
 1  (chima/lab)  0.574 ms F=9194  0.401 ms  0.407 ms

millicent$ traceroute -i (mgmt) -n (chima/mgmt) --mtu
traceroute to (chima/mgmt) ((chima/mgmt)), 30 hops max, 65000 byte packets
 1  (chima/mgmt)  0.536 ms F=9194  0.394 ms  0.403 ms

charon を挟んでいてもルータまでは問題ない。
どうにも atri に問題がありそうな気はするのだが。

一番妙なのは、 millicent や sakuno の mgmt VLAN のインターフェース (access port 経由) から atri (同じく mgmt VLAN, vlan タグなし) への traceroute がうまくいかないところ。
この経路は VLAN タグもないし、経由している GS324v2 はスマートスイッチ等ではなく管理画面を持たない素朴なスイッチで、 chima もルータではあるものの同一 VLAN 同士であればインターフェースがスイッチとして機能するはずなのでそうそう妙なことは起きないはず。
これで atri/mgmt から millicent/mgmt まで (F=9216 を維持して) 疎通して millicent/mgmt から atri/mgmt には通らないというのは明らかにおかしい。

次におかしいのは、 atri/mgmt → millicent/mgmt でルータ (_gateway) までは F=9216 なのに millicent/lab や sakuno/lab に行く際に F=1500 にされているところ。

tcptraceroute を使ってみているが、 millicent から tcptraceroute -i (mgmt) (sakuno/mgmt) (port) 9194 は通るのに tcptraceroute -i (lab) (sakuno/mgmt) (port) 9000 は通らない。

• millicent/mgmt -> sakuno/mgmt (9194): OK
• millicent/lab -> sakuno/lab (9216): OK
  • 9217 だと NG
• millicent/lab -> sakuno/mgmt (9000): NG
• millicent/mgmt -> sakuno/lab (9000): NG
• millicent/lab -> atri/mgmt (9000): NG
• millicent/mgmt -> atri/mgmt (9194): OK
  • 9195 だと NG
• sakuno/mgmt -> millicent/lab (9000): NG
• sakuno/lab -> millicent/mgmt (9000): NG
• sakuno/mgmt -> millicent/mgmt (9194): OK
• sakuno/lab -> millicent/lab (9000): OK
• sakuno/mgmt -> atri/mgmt (9194): OK
  • 9195 だと NG
• sakuno/lab -> atri/mgmt (9000): NG
• atri/mgmt -> millicent/mgmt (9216): OK
  • 9217 だと NG
• atri/mgmt -> millicent/lab (9216): OK
  • 9217 だと NG
• atri/mgmt -> sakuno/mgmt (9216): OK
  • 9217 だと NG
• atri/mgmt -> sakuno/lab (9216): OK
  • 9217 だと NG

どうも sakuno と millicent が送信側の状況で VLAN を跨ぐと駄目らしいというのが見えてきた。
atri が受信側だと駄目なのかと思っていたが、 sakuno と millicent が受信側でも駄目な場合があるというのは予想外だった。
一方で atri が送信側の場合だと何をしても OK となっている。

とりあえず VLAN インターフェースの MTU は 9216 と 9212 で違いがなさそうなので 9212 に合わせる。

念のため sakuno を再起動してみたが tcptraceroute の結果に変化はない。

PVE の管理画面のポートを宛先にしているので firewall のせいということはないと思うが……
一応無効化して試してみるか。

→ノードとクラスタの firewall を無効化したが結果は変わらず。

念のためルータも再起動してみたが変化なし。

charon の /ping コマンド (Manual:Tools/Ping - MikroTik Wiki) を試してみた。

• charon/mgmt → sakuno/lab, millicent/lab (1501): NG
  • 1500 は OK
  • 192.168.0.1 (chima) で status が「fragmentation needed and DF set」になっている
• charon/mgmt → sakuno/mgmt (9982): OK
  • 9983 は NG (timeout)
  • 9982+28=10000 なので、たぶん sakuno ではなく asumi のフレームサイズ制限 (10000) に反応している
• charon/mgmt → millicent/mgmt (10214): OK
  • 10215 は NG (timeout)
  • 10214+4=10218 なので、やっぱり millicent ではなく charon 側での VLAN の L2 MTU (10214) に反応している
• charon/mgmt → chima/mgmt (20214): OK
  • 10215 は NG (timeout)
• charon/mgmt → chima/lab (20214): OK
  • 10215 は NG (timeout)

経路にしか反応していないが、やはり charon/mgmt → sakuno/lab が 1500 で限界になっているのが目立つ。

こうなるときと、

> /ping (sakuno/lab) do-not-fragment size=9216    
  SEQ HOST                                     SIZE TTL TIME       STATUS                                 
    0 (chima/mgmt)                               56 255 883us      fragmentation needed and DF set        
    1                                                              packet too large and cannot be fragm...
    2                                                              packet too large and cannot be fragm...
    3                                                              packet too large and cannot be fragm...
    4                                                              packet too large and cannot be fragm...
    5                                                              packet too large and cannot be fragm...
    sent=6 received=0 packet-loss=100% 

こうなるときがある:

> /ping (sakuno/lab) do-not-fragment size=9216
  SEQ HOST                                     SIZE TTL TIME       STATUS                                          
    0                                                              packet too large and cannot be fragmented       
    1                                                              packet too large and cannot be fragmented       
    2                                                              packet too large and cannot be fragmented       
    3                                                              packet too large and cannot be fragmented       
    4                                                              packet too large and cannot be fragmented       
    sent=5 received=0 packet-loss=100% 

どうして差がついたのか…… (マシン、環境の違い (ではない))

• “インターフェース”: 8.1.4 インタフェースの MTU の設定
  • LAN1〜LAN8
• “LAN インターフェース”: 4.50 LAN インターフェースの動作タイプの設定
  • lan1.1 とか vlan1 とか。 (例示されてはいないが lan1/1 とかも。)

インターフェースの mtu を設定して、かつ、ip mtu コマンドまたは ipv6 mtu コマンドの設定が初期値のままの場合、IPv4 や IPv6 での MTU にはインターフェースの mtu が利用される。一方、ip mtu コマンドまたは ipv6 mtu コマンドが設定されていて、かつ、その設定値がインターフェースの mtu より小さい場合、ip mtu コマンドまたはipv6 mtu コマンドの設定値が MTU として利用される。インターフェースの mtu も含めてすべて設定されていない時には、初期値である 1500 が利用される。

— 4.50 LAN インターフェースの動作タイプの設定 (2024-08-02 09:49 JST)

ip lan1/1 mtu などと lan type lan1 mtu= の両方を指定してる状態で上のログのとおりの状況。
一応 lan1/1 などの vlan 向けの “インターフェース” MTU 設定を消して “LAN インターフェース” の MTU 設定のみを (つまり lan type lan1 mtu=10218 を) 残したうえで実験してみたが、 charon/mgmt → sakuno/lab の ping は相変わらず 1500 までしか通らない。

• charon/lab -> sakuno/lab, millicent/lab (9216): OK
  • 9217 は NG (timeout)
• charon/lab -> sakuno/mgmt, millicent/mgmt (9216): OK
  • 9217 は NG (timeout)
• charon/mgmt -> sakuno/mgmt (9982): OK (#note-33 と同じ)
  • 9983 は NG (timeout)
• charon/mgmt -> millicent/mgmt (20214): OK (#note-33 と同じ)
  • 20215 は NG (timeout)
• charon/mgmt -> atri/mgmt (10214): OK
  • 10215 は NG (timeout)
• charon/lab -> atri/mgmt (64): NG (timeout)
  • ！？
• charon/lab -> chima/lab, chima/mgmt (10214): OK
  • 10215 は NG ("packet too large and cannot be fragmented")

iperf3 で atri/mgmt -> sakuno/mgmt を試しているが、 -M 1400 にしてもたまに Retr が発生する (20秒で25ほど)。

• atri/mgmt -> sakuno/mgmt (-M 1400): ?
  • Retr 25回/20秒
• sakuno/mgmt -> atri/mgmt (-M 8000): OK
• sakuno/lab -> atri/mgmt (-M 9216): OK
• atri/mgmt -> sakuno/lab (-M 1400): OK
• atri/mgmt -> sakuno/lab (-M 8000): OK
• atri/mgmt -> sakuno/lab (-M 9216): ?
  • Retr 31回/20秒 (2-3秒で15回、12-13秒で16回)
• sakuno/lab -> millicent/lab (-M 8000): OK
• sakuno/mgmt -> millicent/lab (-M 8000): OK
• sakuno/lab -> millicent/mgmt (-M 8000): OK
• sakuno/mgmt -> millicent/mgmt (-M 8000): OK
• atri/mgmt -> millicent/mgmt (-M 9216): ?
  • Retr 34回/20秒 (まんべんなく)
• atri/mgmt -> millicent/mgmt (-M 1400): ?
  • Retr 48回/20秒 (まんべんなく)
• atri/mgmt -> millicent/lab (-M 1400): OK
• atri/mgmt -> millicent/lab (-M 8000): ?
  • Retr 24回/20秒 (0-1秒で24回)
  • かと思ってもう一度試すと Retr 0 だったりする

……これ1Gスイッチとか1Gポートを通って fragmentation してるからあまり意味ないか。

トポロジーを元に戻した。

• chima
  • -> charon (10G)
    • -> sakuno/lab (10G)
    • -> millicent/lab (10G)
    • -> asumi (10G×2 LACP)
      • atri/gadgets (10G)
  • -> GS324v2 (1G)
    • -> sakuno/mgmt (1G)
    • -> millicent/mgmt (1G)

• atri/gadgets -> millicent/lab (-M 1400): OK
• atri/gadgets -> millicent/lab (-M 8500): ?
  • Retr 135回/20秒 (0-1秒 67, 1-2秒 33, 16-17秒 35)
• atri/gadgets -> millicent/mgmt (-M 8500): NG
  • Retr 1550回/20秒 (毎秒55回以上)
  • 10G→1G 帯域
• atri/gadgets -> millicent/mgmt (-M 1400): NG
  • Retr 1410回/20秒 (毎秒40回以上)
  • 10G→1G 帯域
• sakuno/mgmt -> millicent/mgmt (-M 8500): OK
• sakuno/mgmt -> millicent/lab (-M 8500): OK
• sakuno/lab -> millicent/lab (-M 8500): OK
• atri/gadgets -> millicent/lab (-M 8000): OK
• atri/gadgets -> millicent/lab (-M 8500): ?
  • Retr 10回/20秒 (0-1秒 10)
• atri/gadgets -> millicent/lab (-M 8000): ?
  • Retr 2回/20秒 (12-13秒 2)
• atri/gadgets -> sakuno/lab (-M 8800): NG
  • Retr 14547/20秒 (毎秒480以上)
  • あまりにおかしい
• atri/gadgets -> sakuno/lab (-M 1400): NG
  • Retr 13704/20秒 (毎秒500以上)

なんというか…… atri がおかしいのか atri - sakuno 間がおかしいのかわからないが、とにかく正常でないことは明らか。
このまま使い続けるのは流石に駄目か。

• millicent/lab -> atri/gadgets (-M 8800): ?
  • Retr 61/20秒 (毎秒2以上)
• millicent/mgmt -> atri/gadgets (-M 8800): ?
  • Retr 58/20秒 (毎秒1以上)
  • 1G→10G 帯域
• millicent/mgmt -> atri/gadgets (-M 1400): ?
  • Retr 28/20秒 (前半19, 後半9)
  • 1G→10G 帯域
• sakuno/lab -> atri/gadgets (-M 8800): ?
  • Retr 44/20秒 (毎秒1以上)
  • 1G→10G 帯域
• sakuno/mgmt -> atri/gadgets (-M 8800): ?
  • Retr 42/20秒 (毎秒1以上)
  • 1G→10G 帯域
• sakuno/mgmt -> atri/gadgets (-M 1400): ?
  • Retr 207/20秒 (前半11, 後半196)
  • 1G→10G 帯域

atri が受け側のときは概ね問題なさそうか (Retr 0 でないのはどうしようもないとして)。
パケットサイズを減らすとマシになるかというとそれも若干怪しい。

sakuno/mgmt -> atri/gadgets へ -M 1400 でテストしていると、 chima の CPU のうち1コアに74%くらいまで負荷がかかっている。
理由は不明だがたぶんパケットフィルタまわり？ (gadgets VLAN が相手なのでたぶん何かしらのフィルタがあってもおかしくない。確認しないとわからないが。)

nop_thread さんは #note-42 で書きました:

LACP の線のどちらか一方が腐っているせいというわけではないらしい。

よく考えたら millicent -> sakuno が 9.3 Gbps 出ているのだから sakuno の線が腐っているわけがないか。
そして atri → millicent も安定して 8.0 Gbps 出ており Retr も平均で毎秒4程度だから、 atri の線が特別におかしいというわけでもない。
millicent と sakuno は NIC のカードもネットワークの経路も VLAN も何もかもほぼ同じなのに、どこで差がついているのか (マシン、環境の違い……)

ぐぬぬ……

nagisa からもテスト。

• nagisa/lab -> sakuno/lab: OK (9.9 Gbps, Retr 0)
• sakuno/lab -> nagisa/lab: ? (4.4 Gbps, Retr 0)
  • なに？
• nagisa/lab -> millicent/lab: OK (9.9 Gbps, Retr 0)
• millicent/lab -> nagisa/lab: OK (9.88 Gbps, Retr 0)

わからん。やっぱり sakuno がどこか変なようだが……

nop_thread さんは #note-44 で書きました:

• sakuno/lab -> nagisa/lab: ? (4.4 Gbps, Retr 0)
  • なに？

sakuno$ iperf3 -c (nagisa/lab) -t 20 -P 1 -B (sakuno/lab)
Connecting to host (nagisa/lab), port 5201
[  5] local (sakuno/lab) port 36459 connected to (nagisa/lab) port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   532 MBytes  4.46 Gbits/sec    0    550 KBytes
[  5]   1.00-2.00   sec   545 MBytes  4.57 Gbits/sec    0    550 KBytes
[  5]   2.00-3.00   sec   546 MBytes  4.58 Gbits/sec    0    550 KBytes
[  5]   3.00-4.00   sec   535 MBytes  4.49 Gbits/sec    0    550 KBytes
[  5]   4.00-5.00   sec   529 MBytes  4.44 Gbits/sec    0    550 KBytes
[  5]   5.00-6.00   sec   538 MBytes  4.51 Gbits/sec    0    550 KBytes
[  5]   6.00-7.00   sec   548 MBytes  4.59 Gbits/sec    0    550 KBytes
[  5]   7.00-8.00   sec   539 MBytes  4.52 Gbits/sec    0    550 KBytes
[  5]   8.00-9.00   sec   536 MBytes  4.50 Gbits/sec    0    550 KBytes
[  5]   9.00-10.00  sec   544 MBytes  4.56 Gbits/sec    0    550 KBytes
[  5]  10.00-11.00  sec   531 MBytes  4.46 Gbits/sec    0    550 KBytes
[  5]  11.00-12.00  sec   526 MBytes  4.41 Gbits/sec    0    550 KBytes
[  5]  12.00-13.00  sec   546 MBytes  4.58 Gbits/sec    0    550 KBytes
[  5]  13.00-14.00  sec   534 MBytes  4.48 Gbits/sec    0    550 KBytes
[  5]  14.00-15.00  sec   520 MBytes  4.36 Gbits/sec    0    550 KBytes
[  5]  15.00-16.00  sec   532 MBytes  4.47 Gbits/sec    0    550 KBytes
[  5]  16.00-17.00  sec   546 MBytes  4.58 Gbits/sec    0    550 KBytes
[  5]  17.00-18.00  sec   541 MBytes  4.54 Gbits/sec    0    550 KBytes
[  5]  18.00-19.00  sec   542 MBytes  4.55 Gbits/sec    0    550 KBytes
[  5]  19.00-20.00  sec   542 MBytes  4.55 Gbits/sec    0    550 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-20.00  sec  10.5 GBytes  4.51 Gbits/sec    0             sender
[  5]   0.00-20.00  sec  10.5 GBytes  4.51 Gbits/sec                  receiver

iperf Done.

sakuno 上で ethtool を使うと、(もちろん) SFP+ のインターフェースは Speed: 10000Mb/s で bond, vmbr, vlan は 20000Mb/s と出る。
4.5 Gbps で “安定” する理由が見当たらない。

nop_thread さんは #note-46 で書きました:

sakuno 上で ethtool を使うと、(もちろん) SFP+ のインターフェースは Speed: 10000Mb/s で bond, vmbr, vlan は 20000Mb/s と出る。
4.5 Gbps で “安定” する理由が見当たらない。

まさかと思って sakuno 側に jumbo frame を設定したら、ちゃんと 9.89 Gbps 出るようになった。
マジかよ。

結論としては「sakuno-atri 間でのエラーレートの高さは原因不明だけど jumbo frame 使わなくても変わりないから使う方が得だし、 sakuno,nagisa,millicent -> atri での traceroute --mtu が 1500 を報告してくる理由も不明だけど小さく検出される分には問題ないだろうからやっぱり jumbo frame 使っとけ」ということになるか。

最終構成: ぜんぶ TTL=9216 (あるいは VLAN なら 9212)

iperf3 (-M 9000) の結果:

• atri/gadgets -> millicent/lab: 8.3 Gbps (Retr 0/20s)
  • sender: 19.4 GBytes, 8.33 Gbits/sec
  • receiver: 2.00 GBytes, 859 Mbits/sec
• millicent/lab -> atri/gadgets: 9.1 Gbps (Retr 23/20s)
  • sender: 21.3 GBytes, 9.13 Gbits/sec
  • receiver: 21.3 GBytes, 9.13 Gbits/sec
  • chima の CPU0 使用率が最大 98％ に (SNMP 向けの、15秒ごとの最大 39% 程度の負荷も込み)
• atri/gadgets -> sakuno/lab: 1.9 Gbps (Retr 15529/20s)
  • sender: 4.47 GBytes, 1.92 Gbits/sec
  • receiver: 2.00 GBytes, 859 Mbits/sec
• sakuno/lab -> atri/gadgets: 9.3 Gbps (Retr 38/20s)
  • sender: 21.6 GBytes, 9.29 Gbits/sec
  • receiver: 21.6 GBytes, 9.28 Gbits/sec
  • chima の CPU2 使用率が最大 73％ に
• atri/gadgets -> nagisa/lab: 4.5 Gbps (Retr 0/20s)
  • sender: 10.7 GBytes, 4.57 Gbits/sec
  • receiver: 2.00 GBytes, 859 Mbits/sec
• nagisa/lab -> atri/gadgets: 9.3 Gbps (Retr 53/20s)
  • sender: 21.6 GBytes, 9.29 Gbits/sec
  • receiver: 21.6 GBytes, 9.29 Gbits/sec
  • chima の CPU2 使用率が最大 71% に
• millicent/lab -> sakuno/lab: 9.8 Gbps (Retr 40/20s)
  • sender: 23.0 GBytes, 9.88 Gbits/sec
  • receiver: 23.0 GBytes, 9.88 Gbits/sec
• millicent/lab -> nagisa/lab: 9.8 Gbps (Retr 0/20s)
  • sender: 23.0 GBytes, 9.88 Gbits/sec
  • receiver: 23.0 GBytes, 9.88 Gbits/sec
• sakuno/lab -> millicent/lab: 9.8 Gbps (Retr 0/20s)
  • sender: 23.0 GBytes, 9.88 Gbits/sec
  • receiver: 23.0 GBytes, 9.88 Gbits/sec
• sakuno/lab -> nagisa/lab: 9.8 Gbps (Retr 0/20s)
  • sender: 23.0 GBytes, 9.88 Gbits/sec
  • receiver: 23.0 GBytes, 9.88 Gbits/sec
• nagisa/lab -> millicent/lab: 9.9 Gbps (Retr 0/20s)
  • sender: 23.0 GBytes, 9.90 Gbits/sec
  • receiver: 23.0 GBytes, 9.89 Gbits/sec
• nagisa/lab -> sakuno/lab: 9.8 Gbps (Retr 133/20s)
  • sender: 23.0 GBytes, 9.87 Gbits/sec
  • receiver: 23.0 GBytes, 9.87 Gbits/sec

傾向:

• chuable の各ノードから atri へのデータ転送は高負荷
  • nagisa/lab -> atri/gadgets の -M 1400 の実験でも chima の CPU3 使用率が 81% に到達したので、そういうものらしい。
  • いずれは filter の大掃除なども必要かもしれない。不慣れなうちに書いたので、まとめられるはずのルールが別々になっていたりなどは結構あるはず。
• atri から chuable の各ノードへの転送速度はバラバラ、しかも信頼性が低い
  • millicent: 8.3 Gbps (エラーなし)、 sakuno 1.9 Gbps (エラーだらけ)、 nagisa 4.5 Gbps (エラーなし) と、完全にバラバラ。
    • 原因不明なのでこの傾向が持続するかさえ不明。特定のノードへの接続が今後も高速かつ安定であると期待するのは危険かもしれない。
  • そもそも送信はそれでもマルチギガ相当に見えるが、受信を見てみるといずれも 2.00 GBytes 859Mbits/sec となっており、どう考えてもまともに通信できていない。
    • 1 Gbps とかでなく 2.00 GBytes がぴったりに見えるのは、どこかで制限がかかっている？
• chuable のノード間での転送は十全な性能が出ている
  • 速度は十分。
  • 再送もないではないが、許容範囲だろう。 TCP なら特に。 UDP なら……利用を避けるのがよさそうだ。どうせ chuable 外への転送は悲惨だろうし。
• atri → sakuno だけ特別に状況がひどいので、今後も警戒が必要。

asumi で atri を繋いだポートの統計を確認していたが、 fragementation が発生している。
atri から millicent への iperf3 テストでは「受信パケット 1024～1518オクテット」の数字がモリモリ増えていたのに「受信パケット 1518より大きいオクテット」は増えなかった。

atri から ping -v -M do -s 8000 -c1 (millicent/lab) を実行したところ、最初の1回は「DFフラグがセットされています」で「1518より大きい」が1だけ増えた (50→51) が、それ以降は「内部エラー: メッセージが長すぎます: mtu=1500」で送信もさせてもらえないしカウンタも増えない。
OS のネットワークスタックが経路の MTU をキャッシュしてエラーを返している？
(nagisa と sakuno でも再現できたので、たぶんそう。)

atri → millicent で今度は asumi の LAGG ポートを確認している。

物理ステータス 	10 Gbps Full Duplex
リンクステータス 	リンクアップ
リンクTrap 	有効
送受信パケット 64オクテット 	78
送受信パケット 65～127オクテット 	318775
送受信パケット 128～255オクテット 	79
送受信パケット 256～511オクテット 	84
送受信パケット 512～1023オクテット 	767
送受信パケット 1024～1518オクテット 	3214
受信オクテット 	23793646
受信パケット 64オクテット 	53
受信パケット65～127オクテット 	318524
受信パケット 128～255オクテット 	39
受信パケット 256～511オクテット 	19
受信パケット 512～1023オクテット 	18
受信パケット 1024～1518オクテット 	11
受信パケット 1518より大きいオクテット 	115
受信したエラーなしパケット合計 	318779
受信ユニキャストパケット 	318669
受信マルチキャストパケット 	104
受信ブロードキャストパケット 	6
破棄された受信パケット 	0
受信したMACエラーありパケット合計 	0
受信ジャバー 	0
受信フラグメント 	0
受信アンダーサイズ 	0
アライメントエラー 	0
Rx FCSエラー 	0
未転送の受信パケット合計 	12
受信802.3x PAUSEフレーム 	0
送信パケット合計 (オクテット) 	3278529799
送信パケット 64オクテット 	25
送信パケット65～127オクテット 	251
送信パケット 128～255オクテット 	40
送信パケット 256～511オクテット 	65
送信パケット 512～1023オクテット 	749
送信パケット 1024～1518オクテット 	3203
送信パケット 1518より大きいオクテット 	13438879
最大フレームサイズ 	10000
正常に送信されたパケット合計 	13443212
送信ユニキャストパケット 	13443176
送信マルチキャストパケット 	23
送信ブロードキャストパケット 	13
破棄された送信パケット 	0
送信エラー合計 	0
破棄された送信パケット合計 	0
単一のコリジョンフレーム 	0
複数のコリジョンフレーム 	0
超過コリジョンフレーム 	0
破棄された送信フレーム 	12
受信したSTP BPDU 	0
送信したSTP BPDU 	0
受信したRSTP BPDU 	0
送信したRSTP BPDU 	0
受信したMSTP BPDU 	0
送信したMSTP BPDU 	0
送信802.3x PAUSEフレーム 	0
受信EAPoLフレーム 	0
送信EAPoLフレーム 	0
前回カウンターがクリアされてからの時間 	0 日 0 時間 0 分 24 秒

millicent -> atri。

物理ステータス 	10 Gbps Full Duplex
リンクステータス 	リンクアップ
リンクTrap 	有効
送受信パケット 64オクテット 	71
送受信パケット 65～127オクテット 	452884
送受信パケット 128～255オクテット 	68
送受信パケット 256～511オクテット 	48
送受信パケット 512～1023オクテット 	45
送受信パケット 1024～1518オクテット 	37
受信オクテット 	3096140080
受信パケット 64オクテット 	46
受信パケット65～127オクテット 	216
受信パケット 128～255オクテット 	42
受信パケット 256～511オクテット 	29
受信パケット 512～1023オクテット 	22
受信パケット 1024～1518オクテット 	22
受信パケット 1518より大きいオクテット 	16143817
受信したエラーなしパケット合計 	16144194
受信ユニキャストパケット 	16144086
受信マルチキャストパケット 	102
受信ブロードキャストパケット 	6
破棄された受信パケット 	0
受信したMACエラーありパケット合計 	0
受信ジャバー 	0
受信フラグメント 	0
受信アンダーサイズ 	0
アライメントエラー 	0
Rx FCSエラー 	0
未転送の受信パケット合計 	12
受信802.3x PAUSEフレーム 	0
送信パケット合計 (オクテット) 	33552824
送信パケット 64オクテット 	25
送信パケット65～127オクテット 	452668
送信パケット 128～255オクテット 	26
送信パケット 256～511オクテット 	19
送信パケット 512～1023オクテット 	23
送信パケット 1024～1518オクテット 	15
送信パケット 1518より大きいオクテット 	0
最大フレームサイズ 	10000
正常に送信されたパケット合計 	452776
送信ユニキャストパケット 	452741
送信マルチキャストパケット 	22
送信ブロードキャストパケット 	13
破棄された送信パケット 	0
送信エラー合計 	0
破棄された送信パケット合計 	0
単一のコリジョンフレーム 	0
複数のコリジョンフレーム 	0
超過コリジョンフレーム 	0
破棄された送信フレーム 	12
受信したSTP BPDU 	0
送信したSTP BPDU 	0
受信したRSTP BPDU 	0
送信したRSTP BPDU 	0
受信したMSTP BPDU 	0
送信したMSTP BPDU 	0
送信802.3x PAUSEフレーム 	0
受信EAPoLフレーム 	0
送信EAPoLフレーム 	0
前回カウンターがクリアされてからの時間 	0 日 0 時間 0 分 24 秒

#note-50 と #note-51 からすると、破棄されたフレームにそこまで差異は見られず、かつ問題なく jumbo frame が送受信されていそうな感じがする。
エラーや破棄が目立った数字でないので、 asumi に問題はないと考えてよいだろう。

[適用モデル]
vRX シリーズ, RTX5000, RTX3510, RTX3500

— 8.6.1 受信パケットの統計情報を記録するか否かの設定

そっすか……

atri → millicent へのテスト。

• sfpplus11 Tx&Rx 1024-max: 13798054
• sfpplus12 Tx&Rx 1024-max: 146
• sfpplus19 Tx&RX 1024-max: 27598445

リセットとコピペしたタイミングはズレるが、概ねこんな感じ。
11と12が LACP の bond なのでほぼ 11 に流れているのは想定通り。
で、問題はなぜ2倍近くの差がついているのか……と思ったけど、これ 1500 のものもカウントされていそうだし、よくわからんな。
せめて jumbo frame かそうでないかで分離されていたらもう少し得るものがあったのだが。
sfpplus19 (chima - charon の接続) なんてテストを走らせているのでもないのに毎秒100パケットとかの勢いで増えている。

atri → sakuno のテスト。

• sfpplus3 Tx&Rx 1024-max: 3287127
• sfpplus4 Tx&Rx 1024-max: 5
• sfpplus19 Tx&Rx 1024-max: 6576986

傾向は変わらない。
ただ、sfpplus3 の Rx Pause カウンタがモリモリ増えて 27664 とかになった。
Tx Pause はどちらのインターフェースも0。
しかし普通帯域制御が入るとしても atri が送信側なので sfpplus19 の方な気がするのだが、こちらは Tx, Rx ともに Pause なし。

atri → millicent で見てみたが、 Rx Pause も Tx Pause もゼロだった。
やはり sakuno の受け取り側で何かあったと考えるべきか？

何かあったときに備えて、 chuable の PVE ノードの mgmt インターフェースは MTU 指定なし (つまりデフォルトの 1500) のままにしてある。
そもそも 1GbE なので恩恵も小さいだろうし。