コアスイッチ集中設計がボトルネック化する理由

ネットワーク設計でよく採用される「コアスイッチ集中型アーキテクチャ」。

• すべてのVLANをコアに集約
• 全ルーティングをコアで実施
• FW・LB・インターネット出口もコア直下

一見シンプルで管理しやすい構成ですが、一定規模を超えると必ず性能ボトルネックや障害集中ポイントになります。

本記事では、なぜコア集中設計がボトルネック化するのかを技術的に分解し、 さらに判断基準・診断方法・具体的な解決策まで体系的に解説します。

1. コア集中設計とは何か

典型的な構成：

• 全アクセススイッチ → コアへ集約
• 全VLAN SVIをコアに設定
• デフォルトゲートウェイはコア
• FW・LBもコア直結

トラフィックのすべてがコアを通過する設計です。

2. ボトルネック化する5つの技術的理由

① East-Westトラフィックの集中

サーバ間通信（East-West）が増えると、

• 同一ラック内通信でもコア経由
• 仮想基盤内通信もコア経由

不要な往復が発生します。

結果：帯域消費＋遅延増加

判断基準

• コアの内部VLAN間通信が総トラフィックの大半
• サーバ間通信が急増している

解決策

• ディストリビューション層でのL3分散
• Leaf-Spine構成へ移行
• 同一ゾーン内ローカルルーティング

② ARP / MACテーブル肥大化

全VLANをコアで持つと、

• ARPエントリ急増
• MACアドレステーブル肥大

ハードウェア上限に近づくと、

• フラッディング増加
• CPU上昇
• 断続的通信断

確認方法

• show mac address-table count
• show arp summary
• TCAM使用率

解決策

• VLAN設計見直し
• セグメント分割
• 不要ネットワーク削減

③ CPU依存機能の集中

コアで以下を実施すると危険：

• ACL大量設定
• NetFlow出力
• QoS制御
• IP SLA監視

ASIC処理外はCPU処理。 高負荷でドロップ発生。

診断方法

• CPU使用率ピーク確認
• Control plane policingログ
• ドロップカウンタ

対策

• 機能分散
• 監視は専用機へ
• ACLは最小限

④ 冗長性の幻想

コア2台構成でも、

• 上位経路依存
• FW依存
• スタック障害で全断

単一障害点になりがち。

判断基準

• コア停止で全セグメント停止
• メンテナンス時に全体影響

改善策

• Spine分散構成
• アグリゲーション分割
• L3 at access設計

⑤ 帯域の物理限界

アップリンク帯域は有限。

アクセス→コア間が：

• 10G×2でも
• 40Gでも

サーバ増加で必ず限界到達。

確認ポイント

• インターフェース使用率80%以上
• マイクロバースト
• ドロップ増加

解決策

• リンク増設
• ECMP分散
• Leaf-Spine化

3. ボトルネック診断フロー

Step1：トラフィック分析

• North-South vs East-West比率
• ピーク帯域

Step2：リソース確認

• CPU
• TCAM
• ARP数
• MAC数

Step3：障害影響範囲確認

• コア停止時の影響範囲
• フェイルオーバーテスト実施済みか

4. 解決アーキテクチャ例

① L3 at Access

アクセス層でルーティング。 コアは純粋転送。

② Leaf-Spine構成

全LeafがSpineに等価接続。 水平スケール可能。

③ セグメント分散型設計

業務系・仮想基盤系・DMZを分割。

5. 設計判断基準まとめ

状況	推奨アクション
サーバ増加中	Leaf-Spine検討
East-West増大	L3分散
CPU高負荷	機能分散
帯域逼迫	ECMP/増設

6. 結論

コア集中設計は「小規模では最適」ですが、

規模拡大と共に必ず限界が来ます。

ボトルネックの本質は：

• トラフィック集中
• テーブル肥大
• CPU依存機能集中
• 単一障害点

対策は分散設計です。

今ボトルネックが発生しているなら、 本記事の診断フローで原因を特定し、 段階的に分散化へ移行してください。