見出し画像

アップリンクの帯域不足で全体の通信が遅延『トラブル事例の話⑦』

nobu.ai.design

ネットワークは生きているのに、全体的に遅い・重い・時々切れる──。
ログも安定、CPUも低負荷、ループもない。
それでも通信が詰まるときは、アップリンク帯域の飽和を疑うべき。
特定の誰かの大容量通信が、全社の帯域を食い潰している典型的なケースだ。

何が起きる？（症状）

  • 社内全体で通信が遅くなる（Web表示が極端に重い）

  • Pingは通るが遅延がバラつく／時々タイムアウト

  • 無線LANも有線も同様に遅い

  • モニタリング上はトラフィック常時90〜100％近く

  • 夜間やバックアップ時だけ異常に遅くなる

  • クラウド接続やリモート会議が頻繁に切断

なぜ起きる？（原因）

  • 上位スイッチ／ルータへのアップリンクが細い（1G×1本など）

  • 一部端末・サーバがバックアップ／同期で帯域を独占

  • QoS（優先制御）未設定で全通信が同一優先度

  • P2P／動画配信／クラウドストレージの利用増加

  • トラフィック監視なしで飽和が長期間気付かれない

  • スイッチ間LAGの片側ダウンで実効帯域が半減している

図：アップリンクが細く詰まる典型構成

[Access Switch群]
       │ (多数)
       │
   ┌───┴───┐
   │ 1G uplink│ ← 飽和
   └───┬───┘
       │
   [Core / FW / Router]

切り分け（最短ルート）

  1. トラフィック量を定量確認
    　→ SNMP/NetFlow/sFlow で上位ポートの帯域使用率を確認

  2. ピーク時間帯を特定
    　→ 毎日同じ時間に遅くなるなら定常負荷

  3. 該当VLAN・ポートの通信内容を把握
    　→ トップトーカー分析（上位通信先／プロトコル）

  4. リンクダウン／LAG不一致を確認
    　→ show interface status / show etherchannel summary

  5. QoS有無・設定状態の確認
    　→ 優先制御なしならベストエフォート競合状態

今すぐできる対処（テンプレ）

  • 一時的に大容量通信（バックアップ・同期）を夜間限定運用に変更

  • 上位リンクを2本に増設しLAG化（負荷分散）

  • **帯域上限設定（Rate Limit）**を端末・VLAN単位で適用

  • QoSポリシーを導入し、業務通信を優先

  • トラフィック可視化（sFlow/NetFlow）を有効化して常時監視

恒久対策／再発防止チェックリスト

  • アップリンク容量を定期的に見直し（利用率80％超を目安に拡張）

  • QoS設計で業務系通信を優先

  • LAG構成の健全性監視（片系ダウン検知）

  • トップトーカー分析を自動化

  • 定期的に帯域レポートを作成・共有

  • バックアップ・動画配信など高負荷アプリの時間帯制御

  • 新規VLAN追加時は帯域影響を事前評価

  • 上位回線の契約帯域を“余裕を持って”設定

落とし穴（よくあるミス）

  • Pingが通るので「物理は正常」と判断して放置

  • QoSを入れてもキュー設定が不適切で逆に詰まる

  • LAGが片側死んでいても気づかず“半分帯域”で運用

  • クラウド同期アプリ（OneDrive, Dropbox）が常時帯域を消費

  • 社内で動画ストリーミングを許可したまま帯域枯渇

変更後の確認ポイント

  • 帯域使用率がピークでも70％以下で安定

  • Ping／Webレスポンスが改善

  • 会議・VPNが安定し、切断が減少

  • トップトーカーが可視化され、異常トラフィックがすぐ判別可能

  • QoS統計で優先通信が正常に処理されている

まとめ

ネットワークの“重さ”は、
機器ではなく 上位帯域の詰まり であることが多い。
ハード障害でもバグでもなく、単なる容量オーバー。

「まだ1G空いてるはず」ではなく、
「80％超えたら拡張」──それが健全な運用設計。
帯域は目に見えない“回線の血管”。
詰まる前に、広げておくのが正解だ。

いいなと思ったら応援しよう！