10G×2 LAGと1G×4 LACPをどう使い分けたか #5｜UniFi・RSTP・L2ループ対策
この記事で分かること
10G×2 LAGと1G×4 LACPを別の場所で使う理由
LACPで単一通信が速くならない理由
RSTPのRootを固定する意味
STP Edge / BPDU Guardをどう考えるか
10Gでは設定だけでなく物理部材の互換性まで疑う理由
（※前回の【ルーティング設計編】をまだ読んでいない方は、ぜひそちらから！）
⏪ 前の記事：10Gを殺さずFortiGateを使うルーティング/NAT設計 #4
#4では 、10Gの速度を残しながらFortiGateを内部Security Boundaryとして使うために、UCG-FiberとFortiGateの役割を分けた。
その設計を成立させるには、下のL2が安定していることが前提になる。
ここで使ったのがLAG / LACPとRSTPだった。
太くしたい場所と、守りたい場所は同じではない
現在の主要Linkは、かなり単純化するとこうなる。
UCG-Fiber
│ 10G × 1
USW-Aggregation
║ 10G × 2 LAG
USW Pro Max 16
║ 1G × 4 LACP
FortiGate 60FU7 ProはUCG-FiberのPoE Portへ直接接続している。
10G×2を使うのは、Server / VM / k3s / StorageのEast-West通信を受けるCore側。
1G×4を使うのは、FortiGateへ渡す境界側。
全部を同じ速度に揃えるのではなく、役割に合わせて帯域を置く。
LACPは「足し算した帯域を1本の通信で使う」仕組みではない
10Gを2本束ねても、通常1本のTCP Flowが20Gbpsになるわけではない。
1Gを4本束ねても、1本のFlowが4Gbpsになるわけではない。
LACP/LAGは、FlowをHashでMember Linkへ振り分ける。
だから価値が出るのは、複数通信が同時に流れる時だ。
VM A ─┐
VM B ─┼─> LAG ─> 複数Memberへ分散
PC ─┤
k3s ──┘一本の高速道路を作るというより、複数車線を用意する感覚に近い。
さらにMemberが一本落ちても、残ったLinkで通信を継続できる可能性がある。
だからLAGの価値は、単一Flow高速化ではなく、複数Flowの分散と冗長性にある。
RSTPは「事故が起きたら止める」ためだけではない
Linkを増やすと、次に怖いのがL2 Loopだ。
LoopするとBroadcastが増え、最悪Network全体が巻き込まれる。
そこでRSTPを使う。
ただし「RSTPをONにしたから安心」ではない。
どのSwitchをRootにするかも決める。
我が家では、
USW-Aggregation : Priority 4096
USW Pro Max 16 : Priority 8192として、Core側のAggregationをRootに寄せている。
Default Priorityのままだと、機器追加や交換時に想定外のSwitchがRootになる可能性がある。
家庭内でも、Coreの役割を偶然に任せない方が分かりやすい。
LAGを組む前に複数Linkを刺さない
構築時に気を付けたのは、論理設定が完成する前に並行Linkを増やさないこと。
まず1本で疎通
↓
両端でLAG設定
↓
Member追加
↓
LAG状態確認この順にする。
先に複数本を刺してから設定を始めると、意図しないParallel Pathができる。
RSTPがBlockしてくれるかもしれないが、作業手順そのものをRSTP任せにはしない。
STP EdgeとBPDU Guardは役割が違う
Endpoint Portでは、接続後すぐForwardingへ移したい。
そこでSTP Edgeを使う。
一方BPDU Guardは、Edge PortへSwitch等がつながってBPDUが来た時に、そのPortを保護するためのもの。
STP Edge
└─ Endpoint向けのForwarding最適化
BPDU Guard
└─ 想定外のSwitch接続から守るHardening似ているようで目的は違う。
Networkの安全性は、一つの機能を全部ONにすれば完成するわけではない。
Portの役割に合わせて使う。
そして10Gは、設定が正しくても不安定になった
L2設計で一番時間を食ったのは、LACPでもRSTPでもなかった。
一部の10G Linkで、1G設定なら安定するのに、10Gへ変更した途端に不安定になる症状が出た。
Switch LEDは赤。
UniFi Web UIではAnomaly 70〜80。
Linkは見えるのに通信が安定しない。
抜き差し。
Switch初期化。
電源OFF。
放電。
設定の見直し。
それでも直らなかった。
最終的に効いたのは、Twinax/DACとSFP+ Moduleを互換性の確認できる製品へ買い直すことだった。
手元にあったHP製Twinaxが粗悪だったわけではない。
問題は、10GではSwitch / NIC / SFP+ / DACの組み合わせまで含めて一つのSystemになることだった。
この切り分けだけで、体感ではほぼ1週間使った。
詳しくは#7で書く。
L2は「Green表示」ではなく、経路として見る
管理画面がGreenでも、それだけでは足りない。
見るのは、
Memberが想定本数Upしているか
Link Speedが想定通りか
LAGとして認識されているか
RSTP Rootが想定通りか
Error / Drop / Link flapが増えていないか
実通信が安定しているか
だ。
特に10Gでは、Link Upと安定通信は同義ではない。
次は「作ったNetworkへ、動いているSystemを移す」
物理、VLAN、Routing、LACP、RSTP。
ここまでで新しいNetworkの器はできた。
でも一番怖いのはここからだった。
既に動いているESXi、vCenter、k3s、DB、DNS/DHCP、NASを、そのNetworkへ移す。
家族のInternetを止めずに、足元の道路だけを入れ替える。
次回は、その移行でESXiのARPが死に、VLAN Taggingまで戻って切り分けた実例を書く。
【連載インデックス】
⏪ ごく普通の一般家庭（物理10G・k8s 8台）のネットワークを大更改した話 #4 【ルーティング設計編】
⏩ 次の記事：稼働中の自宅インフラを新ネットワークへ移した話 #6｜ESXiのARPが死んで、VLANまで戻った
