当社には約200ノードの中規模ネットワークがあり、現在、デイジーチェーン接続された古いスイッチをスタック可能なスイッチまたはシャーシスタイルのスイッチに置き換えるプロセスが進んでいます。
現在、ネットワークは、製造、管理、知的財産(IP)などのサブネットを介して分割されており、それぞれ別のサブネットにあります。サブネットの代わりにVLANを作成する方が有益でしょうか?
私たちの一般的な目標は、ボトルネックを防ぎ、セキュリティのためにトラフィックを分離し、より簡単にトラフィックを管理することです。
[〜#〜] vlan [〜#〜] sおよび subnet sは、さまざまな問題を解決します。 VLANは Layer 2 で機能するため、ブロードキャストドメインが変更されます(たとえば)。一方、サブネットは現在のコンテキストでは Layer です。
1つの提案は、実際に両方を実装することです
たとえば、VLAN 10-15をさまざまなデバイスタイプ(開発、テスト、本番、ユーザーなど)で用意します)
VLAN 10、サブネット192.168.54.x/24 VLAN 11、サブネット192.168.55.x/24
等々
ただし、ネットワーク内にルーターが必要です。
どのような経路をたどるのかは、あなた次第です(ネットワークは私がこれまでよりもよく知っています)。ブロードキャストドメインのサイズが何らかの問題になると思われる場合は、VLANを使用してください。ネットワーク管理ドメイン(たとえば、管理ネットワーク)のサイズを考えている場合は、おそらく / 16 over/24 に近いネットワークを使用してください。
200ノードは/ 24に収まりますが、これでは明らかに拡張の余地があまりありません。
その音で、あなたはすでにさまざまなデバイスタイプに対してさまざまなサブネットを使用しています。だから、それにこだわってみませんか?必要に応じて、各サブネットをVLANに関連付けることができます。レイヤ2セグメンテーションにより、ネットワークの動作が現在の動作から変化します
その潜在的な影響を調査する必要があります
(私は一日中外出していて、これにジャンプするのを逃していました...それでも、ゲームに遅れて、私は何ができるか見ていきます。)
通常、イーサネットでVLANを作成し、IPサブネットを1対1でそれらにマッピングします。これを行わない方法がありますが、厳密に「単純なバニラ」の世界に固執してVLANを作成し、VLANで使用するIPサブネットを考え、ルーターにそのVLANのIPアドレスを割り当て、そのルーターをVLAN(ルーターの物理インターフェイスまたは仮想サブインターフェイスのいずれかを使用)、一部のホストをVLANに接続し、サブネット内のIPアドレスを割り当てます定義し、VLANの内外にトラフィックをルーティングします。
十分な理由がない限り、イーサネットLANのサブネット化を開始しないでください。最良の2つの理由は次のとおりです。
パフォーマンスの問題の軽減。イーサネットLANは無制限に拡張できません。不明な宛先への過度のブロードキャストまたはフレームのフラッディングは、それらのスケールを制限します。これらの条件のいずれかは、イーサネットLANの単一のブロードキャストドメインを大きくしすぎることによって引き起こされる可能性があります。ブロードキャストトラフィックは理解しやすいですが、不明な宛先へのフレームのフラッディングはもう少しあいまいです。デバイスの数が多すぎてスイッチのMACテーブルがオーバーフローしている場合、フレームの宛先がMACテーブルのエントリと一致しないと、スイッチは非ブロードキャストフレームをすべてのポートにフラッディングします。イーサネットLANに、ホストトークの頻度が低い(つまり、スイッチのMACテーブルからエントリが期限切れになるほどまれに)トラフィックプロファイルのある十分に大きな単一のブロードキャストドメインがある場合、フレームの過剰なフラッディングが発生する可能性もあります。 。
レイヤー3以上のホスト間を移動するトラフィックを制限/制御したい。レイヤー2(ala Linux ebtables)でトラフィックを調べるハッカーを実行できますが、これは管理が困難です(ルールがMACアドレスに関連付けられており、NICを変更するとルールの変更が必要になるため)、実際には非常に奇妙な動作(たとえば、レイヤー2でのHTTPの透過プロキシは奇妙で楽しいですが、まったく不自然であり、トラブルシューティングするのが非常に直感的ではない場合があります)、一般に下位レイヤーで行うことは困難です(レイヤー2ツールはスティックのようなものであるため)レイヤー3+の問題への対処に大きな影響を与えました。レイヤー2の問題を攻撃するのではなく、ホスト間のIP(またはTCP、UDPなど)トラフィックを制御する場合は、サブネット化して、ファイアウォール/ルーターをサブネット間のACLで固定する必要があります。
帯域幅枯渇の問題(ブロードキャストパケットやフレームのフラッディングが原因でない場合)は、通常、VLANおよびサブネット化では解決されません。これらは物理接続の欠如(サーバー上のNICが少なすぎる、アグリゲーショングループ内のポートが少なすぎる、より速いポート速度に移行する必要がある)が原因で発生し、VLANをサブネット化またはデプロイすることで解決できない利用可能な帯域幅の量を増やしません。
MRTGがスイッチ上でポートごとのトラフィック統計のグラフを実行するような単純なものさえない場合、それは潜在的に開始する前の実際のビジネスの最初のオーダーです導入意図的だが情報のないサブネット化のボトルネック。生のバイト数は適切な出発点ですが、トラフィックプロファイルの詳細を取得するには、対象を絞ったスニッフィングでフォローアップする必要があります。
トラフィックがLAN上でどのように移動するかがわかったら、パフォーマンス上の理由からサブネット化について考え始めることができます。
「セキュリティ」に関する限り、次に進む前に、アプリケーションソフトウェアとそれがどのように機能するかについて多くのことを知る必要があります。
数年前に、医療関係のお客様向けに適切なサイズのLAN/WANの設計を行いました。アクセスリストをレイヤ3エンティティ(Cisco Catalyst 6509スーパーバイザモジュール)に配置して、サブネット間を移動するトラフィックを「実際に必要なレッグワークについてはほとんど理解していなかったが、「セキュリティ」に非常に興味を持っていたエンジニア。必要なTCP/UDPポートと宛先ホストを特定するためのeachアプリケーションを検討する提案が戻ってきたとき、「エンジニア」からショックを受けて、それほど難しいことではないとの返答がありました。最後に、すべてのソフトウェアを確実に機能させることができなかったため、アクセスリストなしでレイヤー3エンティティを実行していると聞きました。
教訓:VLAN間のパケットレベルおよびストリームレベルのアクセスを実際に試してボタンダウンする場合は、アプリケーションソフトウェアを使用して多くのレッグワークを実行し、有線で通信する方法を学習/リバースエンジニアリングする準備をしてください。ホストからサーバーへのアクセスを制限することは、多くの場合、サーバーのフィルタリング機能で実現できます。ネットワーク上でのアクセスを制限すると、誤った安心感がもたらされ、管理者が「まあ、アプリを安全に設定する必要はありません。アプリと通信できるホストは、通信網'。"ネットワーク上のホスト間の通信を制限する前に、サーバー構成のセキュリティを監査することをお勧めします。
99%の時間、サブネットはVLANに相当する必要があります(つまり、各アクセスサブネットは1つだけのVLANにマップする必要があります)。
同じVLANに複数のIPサブネットからのホストがある場合、2つ(またはそれ以上)のサブネットが同じブロードキャストドメイン上にあるため、VLANの目的に反します。
または、1つのIPサブネットを複数のVLANに配置すると、IPサブネット上のホストは、他のホストと通信できなくなりますVLANルーターに proxy ARP がない限り、 =有効。