鯖缶

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

• SSH client config で IPQoS 0 すると、長い長い待ち時間 (2分以上) ののち SSH でログインできた。

$ time ssh honoka exit
Job: ssh honoka exit
User: 0.01s
Kernel: 0.00s
Elapsed: 135.65s
CPU: 0%
$

atri (クライアント側) の再起動とルータの再起動、どちらも試したが状況に変化なし。

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

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

• SSH client config で IPQoS 0 すると、長い長い待ち時間 (2分以上) ののち SSH でログインできた。

$ time ssh honoka exit
Job: ssh honoka exit
User: 0.01s
Kernel: 0.00s
Elapsed: 135.65s
CPU: 0%
$

IPv6 でも繋がる場合があると思っていたが、どうやらそうではなかった。
以下 ssh -vvv のログ抜粋。

debug2: resolving "<HOST>" port <PORT>
debug3: resolve_host: lookup <HOST>:<PORT>
debug3: channel_clear_timeouts: clearing
debug3: ssh_connect_direct: entering
debug1: Connecting to <HOST> [<IPv6Addr>] port <PORT>.
debug3: set_sock_tos: set socket 3 IPV6_TCLASS 0x00
debug1: connect to address <IPv6Addr> port <PORT>: Connection timed out
debug1: Connecting to <HOST> [<IPv4Addr>] port <PORT>.
debug3: set_sock_tos: set socket 3 IP_TOS 0x00
debug1: Connection established.

内容を見るに、約2分かかっていたのは単に IPv6 での接続試行が約2分でタイムアウトしていたせいであって、 IPv6 接続自体は失敗している。
その後 IPv4 で再試行 (できる場合は) されて接続が成功していたというのが「接続できることもある」に見えていたということだった。

portage が ftp.iij.ad.jp に接続するときにも IPv6 でタイムアウトして IPv4 で成功しているのを見てしまった。
もしかして SSH とか関係なく IPv6 接続ができなくなっている？
(そのくらい最初に確認しておくべきだった……)

ip a を確認すると IPv6 アドレス (らしきもの) がグローバルなもの含めちゃんと降ってきているが。
ip -6 route を見てもルータの同 VLAN 向けの /64 prefix のエントリは存在しているものの、 default route は fe80:: 始まりの見覚えのないアドレスになっている。
これが原因か？

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

よく見たら同じサブネット ((略)::/64) のアドレスが2つ降ってきてないか？

$ ip -6 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
3: {{ifname}}: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9216 state UP qlen 1000
    inet6 {{IPv6GlobalAddr1}}/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 14385sec preferred_lft 12585sec
    inet6 {{IPv6GlobalAddr2}}/64 scope global temporary dynamic
       valid_lft 14385sec preferred_lft 12585sec
    inet6 {{IPv6LinkLocal}}/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever

そういえば /etc/systemd/networkd/motherboard-ether.network で IPv6PrivacyExtensions=true したのだった。
2つあること自体にはたぶん問題がない？ (ほんまか？？)

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

よく見たら同じサブネット ((略)::/64) のアドレスが2つ降ってきてないか？

どちらのアドレスも宅内サーバ (IPv6 疎通確認済) から ping -6 が返ってこない。
ルータからの ping6 では両方とも問題なく応答があった。

同じ VLAN と subnet にいる arco からは ipv6 test が通っているので、ルータやスイッチではなく atri 側の問題の可能性が高い。

default route になっている2つのうち、少なくとも一方が arco のデフォルトゲートウェイとして使われていることを確認した。
で、もうひとつはどこから来たのか……。

ip -6 route del default via fe80::<SNIP2> して default route を1つにしたら ipv6 test が通るようになった。
てことは kernel か systemd-networkd で何かやらかしている？
問題発生前後で設定を変更した覚えはないが…… (privacy extension の設定はもう少し前だし、もう戻したし)。

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

ip -6 route del default via fe80::<SNIP2> して default route を1つにしたら ipv6 test が通るようになった。
てことは kernel か systemd-networkd で何かやらかしている？

default route を1つ削除しても2つ削除しても、時間経過 (5〜10分くらいの例を観測したが、一定ではなさそうだし範囲は不明) で2つとも復活してしまう。

2つの IP アドレスのうち一方が chima (YAMAHA ルータ) でもう一方が charon (MikroTik スイッチ) であることがわかった。
てことはやっぱりネットワーク機器ですか？

arco がデフォルトゲートウェイとして参照していたのは charon の方だった。
それはそれでよくわからない。こういうのって最寄りノードとかではなくルータを指定するものではなかったのか？

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

arco がデフォルトゲートウェイとして参照していたのは charon の方だった。
それはそれでよくわからない。こういうのって最寄りノードとかではなくルータを指定するものではなかったのか？

正常に通信できる nagisa の方で確認してみると、やっぱり vlan301 には default route が2つ (ルータとスイッチ) あったが、 vlan305 には1つ (スイッチ) だけだった。
最初の VLAN だけ異常になるの、 RTX830 を使っていた頃にもあった気がするな……。

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

最初の VLAN だけ異常になるの、 RTX830 を使っていた頃にもあった気がするな……。

これ https://mastodon.cardina1.red/@lo48576/109735935579513540 か。
このときは IPv6 アドレスが複数という状況で default route への言及がないため同じ症状かはわからない。

そもそもこの時点では privacy extensions については意識していなかった気がするので、スマホを見てアドレスが2つあること自体は正常なのに勘違いして異常と思い込んでいた可能性もある。
とはいえ勘違いの有無をさておいて、うまく動いていなかったものを “修正” できたことは事実なので、同じワークアラウンドを試してみる価値はありそう。
(なお該当のワークアラウンドは RTX1300 に交換した時点で無効化していた。)

直近で何かしたことといえば ToR スイッチ (not ルータ) のアップデート。
charon (#214) の RouterOS を 7.22.x から 7.23.0 へ更新した。
若干の怪しさはあるが、 long term channel へのダウングレードは 7.21 にまで下げてしまうし、面倒なのであまり気が乗らない。
最後の手段として考えておく。

以下 7.23 の changelog (https://mikrotik.com/download/changelogs?channelFilter=stable, 2026-05-29 参照) からの抜粋:

*) ipv6 - added from-pool-policy address property that controls how address is acquired from the pool;
*) ipv6 - added without-acquire address property;
*) ipv6 - always ensure that prefix length matches the one given by the pool even if address was set to 0;
*) ipv6,ra - added option to ignore MTU and DNS servers;
*) ipv6,ra - added router-advertisement-route-distance setting;
*) ipv6,ra - allow receiving DNS servers over multiple interfaces;
*) ipv6,ra - clamp valid-lifetime to minimum of 2h on deprecation;
*) ipv6,ra - extend processed RA logging;
*) ipv6,ra - fixed advertised DNS parameter logging;
*) ipv6,ra - fixed changing default "all" interface configuration;
*) ipv6,ra - fixed DNS and pref64 property unset;
*) ipv6,ra - fixed sending only DNS or MTU when prefix is set to "none";
*) ipv6,ra - improved service stability;
*) ipv6,ra - warn when interface is under the bridge;

ip -6 neigh の出力は次のようになっていた。

$ ip -6 neigh
fe80::<ROUTER> dev enp18s0 lladdr ac:44:f2:b9:03:4b router STALE
<GLOBAL_PREFIX>::1 dev enp18s0 lladdr ac:44:f2:b9:03:4b router STALE
fe80::<SWITCH> dev enp18s0 lladdr 48:a9:8a:b4:c4:f1 router REACHABLE

よく考えると switch が router として出てくるのは明らかにおかしいので、 charon (スイッチ) が何らかの正しくない広告か何かをしている可能性が高くなってきた。
RouterOS をロールバックしてみるのが良さそうだ。

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

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

arco がデフォルトゲートウェイとして参照していたのは charon の方だった。
それはそれでよくわからない。こういうのって最寄りノードとかではなくルータを指定するものではなかったのか？

正常に通信できる nagisa の方で確認してみると、やっぱり vlan301 には default route が2つ (ルータとスイッチ) あったが、 vlan305 には1つ (スイッチ) だけだった。

nagisa の方を確認してみたところ、 default route は vlan301 にひとつ (ルータ) だけになっており、スイッチもなければ vlan305 側での指定もなかった。
症状の説明としては「すべての VLAN で charon (スイッチ) が default gateway として追加されていた」というのが適当か。

RouterOS 7.24beta2 を試してみたが、やはり駄目。