稼働中の自宅インフラを新ネットワークへ移した話 #6｜ESXiのARPが死んで、VLANまで戻った

10G×2 LAGと1G×4 LACPをどう使い分けたか #5｜UniFi・RSTP・L2ループ対策

この記事で分かること

• 設計が終わっても、移行は別の仕事になる理由

• 稼働中のESXi / k3s / DB / DNS・DHCPを抱えた状態で、どう移行範囲を切ったか

• 「pingが通らない」から、ARP → VLAN Taggingまで戻って原因を絞った実例

• ESXiのPort Groupと、Switch側のnative / untagged VLANが噛み合わないと何が起きるか

• 一括切替ではなく、層ごとに確認点と戻り場所を作る考え方

⏪ 前の記事：10G×2 LAGと1G×4 LACPをどう使い分けたか #5｜UniFi・RSTP・L2ループ対策

新しいNetworkを作ることより怖かったのは、今動いている環境をそこへ移すことだった。

図の上では、VLANもRoutingもLACPも完成している。

でも自宅では、その上ですでにESXi、vCenter、Windows Server、Linux Server、k3s、DB、NASが動いている。

止めて作り直せるLabだけではない。

家族のInternetも、仕事用端末も、そのNetworkの上にいる。

我が家には、移行前からESXi、vCenter、Windows Server、Linux Server、k3s、DB、NASが動いていた。

ネットワークだけを新しく作って、

「はい、今日から全部こっちです」

とはできない。

家族は普通にInternetを使っている。

仕事用端末もある。

自宅サーバも止めたくない。

そして何より、変更対象が多すぎる。

ネットワークを作り直すことと、稼働中の環境をそこへ移すことは、完全に別の仕事だった。

[画像案：旧ネットワークと新ネットワークを左右に並べ、ESXi / k3s / DB / DNS・DHCPを一つずつ新側へ移していく図]

一気に切り替えない

当時の移行手順で最初に決めたのは、

全部を同時に変えない

ことだった。

大まかな移行単位はこう考えた。

物理配線 / LAG
      ↓
VLAN / Gateway
      ↓
DHCP / DNS
      ↓
ESXi / vCenter
      ↓
VM / k3s
      ↓
DB / Proxy
      ↓
外部公開サービス

これは「この順番なら絶対安全」という意味ではない。

重要なのは、一つ変えたら、その層が正常だと確認してから次へ行くことだった。

物理Linkが怪しい状態でVLANを疑わない。

ARPが解決していない状態でFirewall Policyを触らない。

Default Gatewayまで届いていないのに、k3sのIngressを疑わない。

今なら当たり前に見える。

でも移行中は、複数箇所を同時に変えるほど「どこで壊れたのか」が分からなくなる。

だから、変更範囲をできるだけ小さくした。

家庭内ネットワークは「本番」

Labなら壊してもいい。

VMなら作り直せる。

k3sも最悪再構築できる。

でも、家庭のInternetはそうはいかない。

テレビ、スマホ、PC、仕事用端末。

自分にとっては検証環境でも、家族から見れば普通の生活インフラだ。

だからHome側を巻き込む変更と、Server / Lab側の変更を同じ感覚で扱わないようにした。

この考え方は、ネットワークをHome / Work / Server / Guest / IoT / DMZへ分けた理由にもつながっている。

壊していい場所と、壊してはいけない場所を分ける。

移行でも同じだった。

そしてESXiで止まった

実際に移行を進めている時、Linux VMの管理系インターフェースからGatewayへ通信できない状態になった。

最初に見えた症状は単純だった。

Gatewayへpingが通らない

こういう時、ついRoutingやFirewallを疑いたくなる。

FortiGateのPolicyか。

Static Routeか。

PBRか。

でもARPを確認すると、GatewayのMAC Addressが解決できていなかった。

Gateway → FAILED

`arping`を打っても応答がない。

ここで見る場所が変わる。

ARPが解決していないなら、まだL3の問題ではない。

Routing TableやFirewall Policyをいくら眺めても、その前段で止まっている。

疑うべきはL2。

NIC。

vSwitch。

Port Group。

VLAN Tagging。

物理SwitchのPort設定。

ここまで戻った。

原因は「VLAN 1」と「VLAN 0」

原因はESXi側のPort Groupだった。

ESXiのPort Groupには、VLAN IDとして「1」が設定されていた。

一方、接続先のネットワークでは、そのManagement系ネットワークをnative / untaggedとして扱っていた。

つまり、

ESXi側
VLAN 1としてTag付与
       ↓
Switch側
native / untaggedを想定

という食い違いが起きていた。

VLAN番号としては同じ「1」に見える。

でも、

VLAN 1 tagged

と

native VLAN 1 / untagged

は同じではない。

ここが今回の罠だった。

ESXi側のPort GroupをVLAN ID 1から0へ変更した。

VMware側でVLAN ID 0は、ESXi側で802.1Q Tagを付けずに送る構成として使える。

変更後、もう一度ARPを確認する。

今度はGatewayのMAC Addressが取得できた。

そしてpingも復旧した。

Packet Lossは0%。

Latencyは約0.2ms。

ようやく「ネットワークが戻った」。

[画像案：左に「VLAN 1 tagged → ARP FAILED」、右に「VLAN 0 / untagged → ARP OK → ping 0% loss」の比較図]

一番役に立ったのは、設定画面ではなくARPだった

この時に改めて思ったのが、

管理画面が正常に見えることと、通信経路が正常であることは別

ということだった。

ESXiもSwitchもLink自体は上がる。

NICも見える。

Port Groupも存在する。

IP Addressも設定されている。

それでも通信はできない。

もし「Link UpしているからL2は大丈夫」と決めつけていたら、FortiGateやRouting側を延々触っていたと思う。

でもARPがFAILEDだった。

そこで、

Application
  ↓
TCP/IP
  ↓
Routing
  ↓
ARP  ← ここで止まっている
  ↓
Ethernet / VLAN

と戻れた。

障害対応で大事なのは、高度なコマンドを知っていることより、

今どのレイヤーまで正常なのかを一つずつ確認すること

なんだと思う。

「同じVLAN番号だから同じ」は危ない

今回のような移行では、旧環境と新環境で同じVLAN番号を使っていても安心できない。

確認する必要があるのは番号ではなく、

• taggedなのか

• untaggedなのか

• native VLANなのか

• ESXiでTagを付けるのか

• Physical SwitchでTagを付けるのか

• TrunkなのかAccessなのか

という境界ごとの責任分担だ。

特に仮想化環境では、

VM
↓
vNIC
↓
Port Group
↓
vSwitch
↓
Physical NIC
↓
Switch Port

と、L2だけでも複数の設定点がある。

物理Switchだけ正しくても駄目。

ESXiだけ正しくても駄目。

境界の両側が一致して初めて通る。

移行計画に「確認点」が必要だった理由

この経験から、移行手順は単なる作業一覧では足りないと感じた。

例えば、

ESXiのVLANを変更する

だけでは弱い。

必要なのは、

変更
  ↓
ARPが解決するか
  ↓
Default Gatewayへ到達できるか
  ↓
DNSが引けるか
  ↓
管理経路が維持されているか
  ↓
次へ進む

という確認点だ。

もっと言えば、

どこで失敗したら、どこまで戻すか

も必要になる。

複数箇所を一気に変更すると、戻す範囲も大きくなる。

一つずつ動かせば、切り戻す範囲も小さい。

移行で一番役に立ったのは「確認点」を決めること

移行では、作業手順よりも「どこまで正常か」を確認する方が重要だった。

ESXiの件なら、

Link Up
  ↓
ARP解決
  ↓
Default Gateway到達
  ↓
DNS
  ↓
管理経路

と一段ずつ見る。

ARPがFAILEDなら、まだFirewallやPBRを疑う段階ではない。

この順番があるだけで、変更箇所が多い移行でも調査範囲を狭められる。

そして、各段階に戻り場所を用意する。

一気に切り替えないことは、障害をゼロにするためではなく、壊れた時に戻れる範囲を小さくするためだった。

移行して終わりではなかった

ネットワークは、新しい構成へ切り替わった。

でも、本当に知りたかったのはここからだった。

設計した通りに通信できるのか。

10Gは必要なところで速度が出るのか。

Client PCからInternetは安定しているのか。

Server間通信は揺れないか。

DNSの応答は安定しているか。

Packet LossやLatencyはどうか。

「つながった」だけでは、家庭内インフラとして完成とは言えない。

次回は、移行後のネットワークをClient PCとServerの両側から測り、

この大更改、本当にやった意味があったのか

を確認していく。

⏩ 次の記事：#7 1Gなら安定するのに10Gにすると赤LED｜Twinax/DACとSFP+の互換性