既存の学内LANが抱える問題は、不適切かつ誤っているうえに効果がないどころか「100害あって1000害あり」という状態です。ここでは代表的な5つを取り上げます。

問題1: /16 の過大なサブネット

すべての症状の根本原因です。

  • サブネットが /16 で切られているため、建物全体が1本のL2(同一ブロードキャストドメイン)になっている
  • 通常なら /24 程度で閉じるべきブロードキャストが建物全体に到達する
  • 結果、クライアントに届くパケットの 75% が自分とは無関係

これは体感ではなく実測です。同じ場所・同じクライアントで、既存LAN(左)と本PoC(右)のキャプチャを並べると差は一目瞭然です。

フィルタ表示の割合(=無関係なパケットの割合)は、既存LANが 73〜79% で推移するのに対し、PoC 側は 7〜8% に収まっています。

問題2: 大量の DHCP サーバー

  • 同一ブロードキャストドメインに、確認できただけで DHCP サーバーが10台 並列でレース応答している
  • 最速で応答した1台の設定で GW が決まり、出口ルーターも ISP(NURO / ぷらら)も接続ごとに変動する
  • 1台のクライアントが接続するだけで10台が応答し、そのやり取りが問題1のとおり建物全体に波及するため、新規接続が増える朝昼の時間帯は特にひどくなる

問題3: 誤った無線設計と運用

利用開始時の案内にはこうあります——「当たり前ですが教室を移動したら繋ぎ変えましょう」。

何が当たり前やねん。当たり前ではありません。 接続先APの切り替えは本来 WLC(無線LANコントローラ)の仕事です。あなたは USJ のフリーWi-Fiで、エリアを移動するたびに設定画面を開きましたか?

SSID で接続制御をするべきではありません。部屋ごとに SSID を分けて人間に繋ぎ替えさせるのは、設計の不在を運用で利用者に押し付けているだけです。

問題4: 効果のない負荷分散と冗長化

出口には計3台のルーターが設置されています。

機器 アドレス 上流 ISP
YAMAHA RTX1210 192.168.0.254 ぷらら
YAMAHA RTX830 192.168.0.253 NURO
YAMAHA RTX830 192.168.0.252 NURO

しかし VRRP 等の冗長プロトコルは一切ありません。10台の DHCP サーバーが配る GW はバラバラで、大半が NURO 系(RTX830 ×2)を指し、ぷらら(RTX1210)へ向くのは2台だけでした。「割り当てアドレスによって負荷分散」をしたかったのだと思われますが、完全な誤りです。どのルーターに向かうかはリースの運任せで、障害時の自動切り替えもありません。冗長化なら VRRP、負荷分散なら GLBP を用いて構築するべきです。

問題5: 脆弱なセキュリティと運用

  • SNMPv1/public で機器情報が認証なしに読み取り可能だった
    • 機種・ファームウェアの特定が容易
    • ファームウェアの更新は RTX830 ×2 が4年前、RTX1210 が7年前で止まっている。どちらの機種も直近2年以内に新しいファームウェアがリリースされており、更新できるのに放置されている状態
  • Telnet が開放 されている
  • 管理用VLANが存在せず、同一L2上のすべての端末から上記の管理面に到達できる

これらの問題に対する PoC の設計は トップページの対応表無線設計とローミングL2/L3 設計・DNS・オブザーバビリティ を参照してください。