TP-LinkのOmada SDNで社内ネットワークを管理しています。今回、新しく買った48ポートのL2+スイッチ「SG3452」を、上位のスイッチとTagged VLANでつないで、管理VLANの上でOmadaソフトウェアコントローラの管理下に置こうとしたところ、丸3日ハマりました。
結論から書くと、原因は「VLAN名に日本語（と全角カッコ）を使っていたこと」でした。コントローラは普通に受け付けてくれるし、既存のスイッチやAPは全部その名前で動いている。ところが新しく買ったSG3452だけが、その名前を拒否していたのです。しかもエラーは画面には出ず、イベントログを掘って初めて分かりました。
「設定できないものは設定させちゃだめでしょ」というのが、3日目の夕方に私の口から出た言葉です。同じところで詰まる人が一人でも減るように、経緯をなるべく一次情報のまま残します。
※ IPアドレス・VLAN ID・機器名などは、そのままだと身元が分かるのでブログ用に書き換えています。構成の関係性は実際のままです。
・Omada Software Controller（Windows Server上で稼働。NICが2枚あり、管理VLAN側 10.90.0.250 と、事務PC側 192.168.10.250）
・上位スイッチ：TP-Link ES224G（Easy Managedシリーズ。以下「上位SW」）
・新しいスイッチ：TP-Link SG3452 v1.30（以下「SG3452」）
・管理VLAN：VLAN 900、サブネット 10.90.0.0/24、ゲートウェイ 10.90.0.254。DHCPサーバもこのVLAN上にあります
・そのほかのVLANは「【本館】PC」「【共通】管理」「【共通】監視カメラ」のように、建屋名を全角カッコで頭に付けた日本語名で運用していました
・やりたいこと：SG3452のポート48 ⇔ 上位SWのポート9 をトランク（ネイティブVLAN 1、Tagged で VLAN 900 ほか）で接続し、SG3452 を VLAN 900 上の静的IP 10.90.0.151 で管理する
つまり、既に同じ形で管理できているPoEスイッチがもう1台あるので、「同じことをもう一台やるだけ」のはずでした。
最初は上位SWの「アクセスポート（ネイティブ VLAN 900）」にSG3452を挿してみました。これは一発で採用（Adopt）できて、DHCPで 10.90.0.195 を取りました。
で、ケーブルを本番のトランクポート（Tagged 900）に差し替えると、いきなり通信できなくなる。ハートビートミスのまま戻ってこない。
これは今思えば当然で、SG3452側の管理IPは「VLAN 1（タグなし）」に付いていて、アクセスポートだから上位SWがタグなしフレームをVLAN 900に入れてくれていただけです。Taggedのポートに挿せば、両端でVLANの設定が一致していないので通りません。
じゃあコントローラの画面から、SG3452の管理VLANを「VLAN 900」に変えればいいはず。デバイス → 設定 → VLANインターフェース で管理VLANを 900 にして、静的IP 10.90.0.151 を入れて適用。
……すると、VLAN 1 のIPが 0.0.0.0 になって、VLAN 900 にはIPが載らない。切断されたまま。CLIで show ip interface を見ると、VLAN 1 に旧IPが残っていて VLAN 900 は空、というパターンもありました。
この時点では「Omadaの管理VLAN変更の仕様を自分が理解できてないんだろう」と思って、ひたすらCLIで試し始めます。
SG3452のコンソールはUSB-Cです。Tera Termで開くと、初期値の9600bpsだと文字化けして何も読めません。スピードを 38400 にすると正常に表示されました。マニュアルにも書いてありますが、最初はケーブルを疑って時間を無駄にしたので書き残しておきます。
Tera Term の設定：ポート COM3／スピード 38400／データ 8bit／パリティ none／ストップビット 1bit／フロー制御 none
コントローラからの変更がうまくいかないので、いったん初期化して最初からやり直そうと、CLIで reset を打ちました。
SG3452> enable
SG3452# reset
ここからが本当のハマりです。
reset 後、SG3452 はDHCPでIPを取ってこなくなりました。IPは 192.168.0.1 の静的。調べると、SG3452の工場出荷状態は「静的 192.168.0.1、DHCPオフ」です。最初に採用できたときはDHCPで取れていたので、あれは工場出荷状態ではなく、何かの拍子にDHCPが有効になっていた状態だったのだと思います。
さらに、show logging buffer にこんな行が出ます。
[ECS] used mgmt-vlan information from the previous connection in Discover state.
「前回接続時の管理VLAN情報を使っています」。つまり reset しても、Omadaエージェントは前回の管理VLANの記憶を持ったままです。工場出荷時に戻ったわけではない。
ネットで検索しても、AIに聞いても、「本体のリセットボタンを5秒以上長押しして初期化してください」と言われます。ところが、SG3452には物理のリセットボタンがありません。筐体の前面・背面を何度も見ましたが、ないものはない。CLIの reset か、Web UIからの初期化しかありません。そして、その reset がエージェントの状態を残す。ここで「一般論の初期化手順」は使えないと分かりました。
しかたなく、CLIで手動でIPを付けて採用し直します。
SG3452# configure
SG3452(config)# interface vlan 1
SG3452(config-if)# ip address 10.90.0.152 255.255.255.0
SG3452(config-if)# exit
SG3452(config)# ip route 0.0.0.0 0.0.0.0 10.90.0.254
SG3452(config)# end
SG3452# copy running-config startup-config
途中で ip address 10.9.0.152 と1桁打ち間違えて、Destination Host Unreachable を眺めて10分溶かしたのも書いておきます。パスワードを admin にしようとして「length out of range」で弾かれたのも（8文字以上必要です）。
採用はできました。で、また管理VLANを900に変更 → また切断。同じ場所で止まる。
「コントローラからの変更が効かないなら、CLIで直接VLAN 900にIPを付けて、ポートもTaggedにすればいいだろう」と考えました。
SG3452(config)# interface vlan 1
SG3452(config-if)# no ip address
SG3452(config-if)# exit
SG3452(config)# interface vlan 900
SG3452(config-if)# ip address 10.90.0.151 255.255.255.0
SG3452(config-if)# exit
SG3452(config)# interface gigabitEthernet 1/0/48
SG3452(config-if)# switchport general allowed vlan 900 tagged
SG3452(config-if)# switchport pvid 1
これで本番のトランクポートに挿すと、
・SG3452 → ゲートウェイ 10.90.0.254：Ping OK
・SG3452 → コントローラ 10.90.0.250：Ping OK
・コントローラサーバ → SG3452（ping -S 10.90.0.250 10.90.0.151）：OK、TTL=64
・サーバの arp -a にSG3452のMACが正しく載っている
L2もL3も完璧に通っています。なのに、コントローラの画面には出てこない。「保留中」にも出ない。デバイスを「忘れる」してもダメ。再起動してもダメ。
ついでに分かったのが、Windowsサーバ側のファイアウォールです。管理VLAN側のNICが「パブリック」プロファイルになっていて、SG3452からのPingが Defender を無効にしたときだけ通る。これも一つの壁でしたが、無効にしても状況は変わらなかったので、本命ではありませんでした。
サーバ側で netstat -ano | findstr 29814 を見ると、他のスイッチはみんな 10.90.0.250:29814 に ESTABLISHED しているのに、SG3452からの接続だけが一本もない。SG3452は「つなぎに来ていない」。
SG3452 の show logging buffer を見ると、起動直後にこう出て、そのあと17時間ずっと沈黙していました。
[ECS] get netif-info failed. Failure count is 1 when state is Discover.
[ECS] used mgmt-vlan information from the previous connection in Discover state.
[ECS] get netif-info failed. Failure count is 5 when state is Prelink.
[ECS] ssl connect failed. Failure count is 5 when state is Prelink.
[HEALING] L3 Intf VLAN1 Heal Check Start.
「get netif-info failed」＝自分の管理インターフェイスの情報が取れない。最後の行が答えで、エージェントは「管理インターフェイス＝VLAN 1」だと思い込んでいます。私がCLIでVLAN 900に付けたIPは、エージェントから見れば関係のないL3インターフェイスで、VLAN 1にIPがないから検出パケットそのものを送れていなかった、ということです。
ここで理解しました。Omadaの管理VLANは、コントローラからの投入でしか変わらない。CLIでどれだけVLAN 900にIPを付けても、エージェントの管理VLANは動かない。だから「Pingは通るのに見えない」が起きる。
3日目の朝、コントローラのログ → イベントを、対象のMACアドレスで検索して、ようやく本当の原因が出てきました。
VLAN Configuration Fail
VLAN name configuration on XX-XX-XX-XX-XX-XX failed.
The length should be 1-128, and it only allows letters, numbers and
some special symbols: -@_:/. , please configure it again!
VLAN名は英数字と「- @ _ : / .」だけ。日本語も全角カッコも使えない。
うちのサイトのVLAN名は「【本館】PC」「【共通】管理」……全部これに引っかかります。コントローラはSG3452にサイトのVLAN一式を流し込むのですが、名前で弾かれてVLAN設定の投入が丸ごと失敗していた。VLAN 900 自体がSG3452の中に作られないので、管理VLANを900に変えろと言われても変えられず、IPが消える。1日目に見た症状は、全部これで説明がつきました。
既存のスイッチやAPで問題が出ていなかったのは、機種やファームウェアによってこの制限がないからです。実際、上位SWのES224Gはコントローラの「非互換」一覧に「VLAN名に対応していません」と出ていて、名前を受け取ってすらいません。SG3452 v1.30 の新しいファームだけが、律儀にチェックしていた。
だから、タイトルの言葉になります。コントローラ側で名前を入力する時点で「この文字は一部の機種で使えません」と弾いてくれれば、3日はかからなかった。設定できないものは設定させちゃだめでしょ。
VLAN名を全部半角英数字に変えました。「【本館】PC」→「HonkanPC」、「【共通】管理」→「ComMGMT」、という具合。ポートプロファイルの名前も念のため英数字に。名前はラベルでしかなく、VLAN IDやポート割当はIDで紐付いているので、通信への影響はありません。
ただし副作用が一つ。上位SWのES224Gは、コントローラ本体がそのポート1に直結しています。VLAN名を1つ変えるたびにコントローラが上位SWにVLAN設定を送り、上位SWが自分のVLANテーブルを書き換える瞬間に、コントローラとの管理セッションが一瞬途切れて「デバイスの応答がタイムアウトしました（switch_-6）」→ ステータスが「構成中」のまま固まる、という現象が出ました。これは デバイス → 設定 → デバイスの管理 → 強制プロビジョニング で解消します。こういう機種への設定変更は、まとめて行って最後に一回プロビジョニングし直すのが吉です。
そのうえで、SG3452 を次の順番で設定しました。「一度アクセスポートでつないで採用し、コントローラから管理VLANを変え、配線を切り替える」というOmadaの流儀どおりです。
0. SG3452 の空きポート ⇔ 上位SWのアクセスポート（ネイティブ VLAN 900）を接続
1. CLI で VLAN 1 に作業用の静的IP 10.90.0.152 を付けて、コントローラで採用
2. デバイス名を英数字に変更
3. ポート48 にトランク用プロファイル（ネイティブ 1、Tagged に 900 を含む）を割当
4. 管理VLANを 900 に変更。ただしIPは いったん DHCP
→ ここで静的 10.90.0.151 を入れると「IPアドレスが同じ範囲」と拒否されます。VLAN 1 に同じサブネットの静的IPが残っているからです
→ 適用直後に「切断されました」になるのは正常。Taggedになった管理フレームをアクセスポートが捨てるだけなので、慌てて戻さない
5. ポート48 ⇔ 上位SWのトランクポート（Tagged 900）に配線を切り替える。1〜2分で再接続
6. VLAN 1 の静的IPを DHCP に変更（これで同一サブネットの静的IPがVLAN 1から外れる）
7. VLAN 900 を静的 10.90.0.151 / 255.255.255.0 / GW 10.90.0.254 に変更
これで、Tagged VLAN 900 の 10.90.0.151 で「接続しました」になりました。show ip interface で VLAN 900 に .151、show vlan でポート48が VLAN 900 の Tagged メンバー、イベントログに VLAN Configuration Fail なし。3日かかった割に、正しい順番でやれば30分です。
・Omadaの管理VLANはコントローラからの投入でしか変わらない。CLIで別のVLANインターフェイスにIPを付けても、エージェントは前回の管理VLANを見続ける。「Pingは通るのにコントローラに現れない」はこれ
・SG3452 の CLI reset は工場出荷状態には戻らない。Omadaエージェントの管理VLAN情報が残る（ログに used mgmt-vlan information from the previous connection と出る）。そしてSG3452には物理のリセットボタンがないので、「ボタン長押し」という一般的な助言は使えない
・SG3452 の工場出荷値は静的 192.168.0.1・DHCPオフ。初期化後にDHCPで取れないのは正常
・シリアルコンソールは 38400bps。9600 では化ける
・VLAN名に日本語・全角記号を使わない。英数字と - @ _ : / . だけ。1台でもフルマネージドのスイッチが混ざるなら、サイト全体を英数字にしておく
・原因は画面ではなくログに出ている。コントローラの ログ → イベント をMACアドレスで検索する、サーバの server.log を grep する、スイッチの show logging buffer を読む。この3つを最初にやっていれば1日で終わっていた
・同一サブネットの静的IPは2つのVLANインターフェイスに同時に付けられない。管理VLANを移すときは DHCP を経由するか、先に旧側を外す
・コントローラ本体が直結しているスイッチのVLAN設定を触ると「構成中」で固まりやすい。強制プロビジョニングで復旧
「設定できないものは設定させちゃだめでしょ」。TP-Linkさん、コントローラ側でVLAN名のバリデーションをお願いします。
（おわり）
Windows環境で構築された…