いつ/なぜネットワークのサブネット化を開始するのですか？
どのような条件下で、ネットワークのサブネット化を検討し始めますか？
いくつかの一般的な経験則、または検討すべき何かをサブネット化する測定可能なメトリックに基づくトリガーを探しています。
興味深い質問。
歴史的に、完全に切り替えられたネットワークが登場する前は、ネットワークをサブネットに分割するための主な考慮事項は、単一の衝突ドメイン内のノード数を制限することでした。つまり、ノードの数が多すぎると、ネットワークのパフォーマンスがピークに達し、過度の衝突による高負荷のもとで最終的には崩壊します。展開できるノードの正確な数は多くの要因に依存しましたが、一般的に言えば、利用可能な総帯域幅の50％をはるかに超える衝突ドメインを定期的にロードできず、ネットワークを常に安定させることができませんでした。ネットワーク上の50ノードは、当時の多くのノードでした。頻繁に使用するユーザーの場合、サブネット化を開始する必要がある前に、20ノードまたは30ノードで上限を超えている可能性があります。
もちろん、完全に切り替えられた全二重サブネットでは、衝突はもはや問題ではなく、一般的なデスクトップタイプのユーザーを想定すると、通常は何の問題もなく、単一のサブネットに数百のノードを展開できます。他の回答が示唆しているように、大量のブロードキャストトラフィックがあることは、ネットワーク上で実行しているプロトコル/アプリケーションによっては問題になる可能性があります。ただし、ネットワークのサブネット化は、必ずしもブロードキャストトラフィックの問題に役立つわけではないことを理解してください。プロトコルの多くは、理由のためにブロードキャストを使用します。つまり、ネットワーク上のすべてのノードが実際にそのようなトラフィックを見て、必要なアプリケーションレベルの機能を実装する必要がある場合です。ブロードキャストされたパケットも他のサブネットに転送して再度ブロードキャストする必要がある場合は、単にネットワークをサブネット化しても実際には何も購入されません。実際、これを考えれば、実際には両方のサブネットに余分なトラフィック（および待機時間）が追加されます。
一般的に言って、今日、ネットワークをサブネット化する主な理由は、組織、管理、およびセキュリティの境界に関する考慮事項と他の何よりも関係があります。
元の質問では、サブネットの考慮事項をトリガーする測定可能なメトリックが求められます。特定の数に関しては何かあるかわかりません。これは関係する「アプリケーション」に大きく依存し、一般的に適用されるトリガーポイントは実際にはないと思います。
サブネットを計画する際の経験則に関連して：
- 特に重要でない（50以上のノード！？）サイズになるので、各組織部門/部門のサブネットを検討してください。
- 他のユーザーまたはノードタイプ（開発者、VoIPデバイス、製造現場）とは異なる共通のアプリケーションセットを使用するノード/ユーザーのグループのサブネットを検討する
- セキュリティ要件が異なるユーザーグループのサブネットを検討します（経理部門の保護、Wifiの保護）
- ウイルスの発生、セキュリティ違反、および被害の封じ込めの観点からサブネットを検討してください。公開/侵害されるノードの数-組織で許容される公開レベルはどれくらいですか？この考慮事項は、サブネット間の制限的なルーティング（ファイアウォール）ルールを前提としています。
以上のことから、サブネットを追加すると、ある程度の管理オーバーヘッドが追加され、1つのサブネットのノードアドレスが不足し、別のプールに多くのアドレスが残っているなどの問題が発生する可能性があります。ルーティングとファイアウォールのセットアップ、および共通サーバーの配置ネットワークなどはもっと複雑になります。確かに、各サブネットすべきが存在する理由は、より洗練された論理トポロジを維持するオーバーヘッドよりも重要です。
それが単一のサイトである場合は、数十を超えるシステムがない限り、気にしないでください。それでも、おそらくそれは不要です。
最近、すべてのユーザーが少なくとも100 Mbpsのスイッチ、より頻繁には1 Gbpsを使用している場合、ネットワークをセグメント化する唯一のパフォーマンス関連の理由は、過剰なブロードキャストトラフィックに悩まされている場合です（つまり、2％を超える、頭上から）。
その他の主な理由はセキュリティです。つまり、DMZ、財務の場合は別のサブネット、VoIPシステムの場合は別のVLAN /サブネットです。
必要なコンプライアンス要件（PCIなど）の範囲を制限することは、ネットワークの一部を分離するための非常に優れた触媒です。支払いの承認/処理システムと金融システムを分割することで、費用を節約できます。しかし、一般的に、小さなネットワークをサブネット化しても、パフォーマンスの点でそれほどメリットはありません。
もう1つの理由は、サービスの品質に関連しています。音声とデータVLANを別々に実行するため、VoIPトラフィックにQoSを簡単に適用できます。
ご存知のように、私はこの質問についてもっと考えてきました。異なるネットワークを使用して新しいネットワークを設計する理由はたくさんあります（パフォーマンス、セキュリティ、QoS、DHCPスコープの制限、ブロードキャストトラフィックの制限（セキュリティとパフォーマンスの両方に関連する可能性があります））。
しかし、サブネットだけに再設計するための測定基準と、過去に処理しなければならなかったネットワークについて考えるとき、私が思いつくことができるすべては、「すごい、それは私を完全に再設計させるために本当にめちゃくちゃなネットワークでなければならないだろう」 サブネット化 "の場合。他にも多くの理由があります-帯域幅、インストールされているデバイスのCPU使用率などです。しかし、純粋なデータネットワークでサブネット化するだけでは、通常、大量のパフォーマンスを購入できません。
ほとんどの場合、セキュリティと品質（問題のネットワークセグメントが問題のノードをサポートできる限り）。プリンタートラフィック、音声/電話、IT Opsのような独立した部門、そしてもちろんサーバーセグメント、インターネットに直接接続するセグメント（「インターネットに面するサービスごとに1つ」、「1つのdmzが行う」だけではない）などの個別のネットワークなど。
個人的には、レイヤー3のセグメンテーションをアクセススイッチにできるだけ近づけることが好きです。
- 私はスパニングツリーが好きではありません（悪意がある場合は、非常に面白いことができます）
- 特にWindozeネットワークでは、ブロードキャストが実際の問題です。
- プライベートネットワークでは、無駄になるIPスペースがたくさんあります:)
- さらに安価なスイッチには、現在ワイヤスピードルーティング機能があります。なぜそれらを使用しないのですか？
- セキュリティ（egでのAuthとACLなど）に関して、人生を楽にします
- VoIPとリアルタイムのもののためのより良いQoSの可能性
- あなたはそのIPからクライアントの場所を知ることができます
2つのコアスイッチ/ルーターでは不十分な、より大きく/より広いスプレッドネットワークの場合、VRRPのような通常の冗長メカニズムには多くの欠点があります（トラフィックがアップリンクを複数回通過するなど）OSPFにはありません。
se-small-broadcast-domains-approachをサポートする理由は他にもたくさんあるでしょう。
スケールアップを期待している場合（5つのサーバーだけでなく、ネットワークを構築していて、それで実現します）、できるだけ早くルーティングを開始します。あまりにも多くのネットワークが不安定であり、それらが有機的に成長し、あまりに多くのレイヤー2のものを持っているため、成長するのが困難です。
例：
- 同じネットワークセグメントに2つのネームサーバーがある。これらのいずれかを別の都市に移動することはできません。そのため、そのNice/24を分割するか、DNSの番号を付け直す必要があるためです。異なるネットワーク上にある場合ははるかに簡単です。私は、これらが世界に対して別々のBGPアナウンスになることについて必ずしも話しているわけではありません。この例は、全国規模のISPの場合です。また、サービスプロバイダーの領域では、「レジストラで新しいDNSを登録する」ほど簡単ではないこともあります。
- レイヤー2ループはお尻を吸います。スパニングツリー（およびVTP）と同様です。スパニングツリーに障害が発生すると（多くの場合は失敗します）、スイッチ/ルーターのCPUにフラッディングが発生するため、すべてがダウンします。 OSPFまたはIS-IS（または他のルーティングプロトコル）に障害が発生しても、ネットワーク全体がクラッシュすることはなく、一度に1つのセグメントを修正できます。誤った隔離。
つまり、スパニングツリーが必要だと思う場所にスケールアップする場合は、代わりにルーティングを検討してください。
組織の範囲はとても重要だと思います。ネットワーク上に合計200以下のホストがあり、トラフィックを何らかの理由でセグメント化する必要がない場合、なぜVLANとサブネットの複雑さを追加するのですか？ただし、スコープが大きくなるほど、意味が大きくなります。
ただし、通常は必要のないネットワークを分割すると、いくつかのことが簡単になります。たとえば、サーバーに電力を供給するPDUは、サーバーと同じVLANまたはサブネットにあります。これは、サーバーの範囲で使用される脆弱性スキャンシステムもPDUをスキャンすることを意味します。しかし、PDUをスキャンする必要はありません。また、PDUを構成するのは面倒なので、DHCPを使用すると便利ですが、現在、サーバーと同じVLANであるため、それはあまり現実的ではありません。
PDUに別のVLAN=は必要ありませんが、いくつかのことを簡単にすることができます。そして、これは、ずっと続くVLANの全体的または全体的な議論に入ります。
私、それが意味のあるVLANがあると思います。たとえば、PDUに独自のVLAN=を与えた場合、それは常にデバイスの小さなグループに独自のVLANを与える必要があることを意味するわけではありません。むしろ、この場合は意味があるかもしれません。デバイスはそれ自身を持っている必要はありませんVLANそしてそうすることには利点がありません、それからあなたは物事をそのままにしておくことを検討したいかもしれません。