私はネットワークをオーバーホールしている最中ですが、私が繰り返し返してきた問題は、ファイアウォールを集中化したまま、レイヤー3をコアに持ち込もうとすることです。

ここでの主な問題は、これまで見てきた「ミニコア」スイッチでは、ハードウェア内のACLの制限が常に低く、現在のサイズでもすぐにヒットする可能性があることです。現在、コア用に1組のEX4300-32Fを（うまくいけば）購入しようとしていますが、他のモデルや、ジュニパーとBrocadeのICXシリーズの他のオプションも検討しました。それらはすべて同じ低いACL制限を持っているようです。

コアスイッチはワイヤ​​スピードルーティングを維持できる必要があるため、これは完全に理にかなっているため、ACL処理によってあまり犠牲にしないでください。したがって、コアスイッチ自体ですべてのファイアウォールを実行することはできません。

ただし、主に完全に管理されたサーバーを使用しており、集中型（ステートフル）ファイアウォールを使用すると、顧客と直接対話することができないため、その管理に非常に役立ちます。できればそれを維持したいのですが、ほとんどのISPネットワークはこのようなことを行わないように感じます。そのため、ほとんどの場合、コアでルーティングを行うのは簡単です。

参考までに、ここに私が理想的に実行したいトポロジーを示します（ただし、FWをどこに当てはめるかは明らかではありません）。

現在のソリューション

現在、ルーターオンスティック構成です。これにより、NAT、ステートフルファイアウォール、VLANルーティングをすべて1か所で行うことができます。とても簡単です。

L2をネットワークの「最上部」、つまり境界ルーターまで拡張することで、（ほぼ）同じソリューションを続行できます。しかし、それからコアが提供できるワイヤスピードルーティングのすべての利点を失います。

IIRCコアスイッチは464 Gbpsのルーティングを実行できますが、運が良ければ、ボーダールーターはおそらく10または20 Gbpsを提供できます。これは現時点では技術的に問題ではなく、成長の問題です。今、コアルーティングキャパシティを活用するアーキテクチャを設計していないと、大きくなり、そのキャパシティを活用する必要がある場合、すべてをやり直すのは苦痛になるでしょう。私はそれを最初に正しくしたいです。

可能な解決策

アクセスするレイヤー3

L3をアクセススイッチに拡張し、ファイアウォールルールをより小さなセグメントに分割して、アクセススイッチのACLのハードウェア制限に合わせることができると思いました。だが：

• 私の知る限り、これらはステートフルACLではありません
• L3 to Accessは、私にとってははるかに柔軟性に欠けるようです。サーバーを移動したり、VMを他のキャビネットに移行したりすると、さらに苦痛になります。
• 各ラックの上部（そのうち6つのみ）でファイアウォールを管理する場合は、とにかく自動化が必要です。したがって、その時点では、ホストレベルでファイアウォールの管理を自動化することはそれほど大きな進歩ではありません。したがって、問題全体を回避できます。

アクセス/コア間の各アップリンクのブリッジ/透過ファイアウォール

これには複数のファイアウォールボックスが必要であり、必要なハードウェアを大幅に増やす必要があります。そして、ファイアーウォールとして古いLinuxボックスを使用していても、大きなコアルーターを購入するよりも高価になる可能性があります。

ジャイアントコアルーター

必要なファイアウォールを実行でき、ルーティング容量がはるかに大きい、より大きなデバイスを購入できます。しかし、実際にはそのための予算がありません。デバイスに設計されていない何かを実行させようとしている場合は、おそらくもっと高いスペックに行かなければならないでしょう。それ以外の場合よりも。

一元化されたファイアウォールなし

私はフープを飛び越えているので、これは努力する価値がないかもしれません。これは常に良いものであり、「ハードウェア」ファイアウォールを必要とする顧客にとってセールスポイントになることもあります。

ただし、「ネットワーク全体」に集中型ファイアウォールを設定することは不可能であるようです。では、何百、何千ものホストがある場合に、専用のサーバーを使用する顧客に、どのように大規模なISPがハードウェアファイアウォールソリューションを提供できるのでしょうか。

誰もがこの問題を解決する方法を考えることができますか？私が完全に見逃したものか、上記のアイデアのバリエーションですか？

更新2014-06-16：

@Ronの提案に基づいて、私が直面している問題をかなりよく説明し、問題を解決するための良い方法を説明するこの記事を偶然見つけました。

他に提案がない限り、これは製品推奨タイプの問題だと思うので、それで終わりだと思います。

http://it20.info/2011/03/the-93-000-firewall-rules-problem-and-why-cloud-is-not-just-orchestration/

次の2つの選択肢のいずれかを選択します。

テナントごとの仮想ファイアウォール

長所：

• 水平方向に拡張可能
• スピンアップとスピンダウン
• 将来のトポロジ/設計変更の影響を比較的受けにくい
• 完全な顧客の分離/分離

短所：

• 標準テンプレートを適用しない限り、管理するファイアウォールはn個になりました
• 監視するファイアウォールがn個あります
• これで、パッチを適用するファイアウォールがn個あります

テナントごとのルーティングインスタンス/コンテキストを持つ大規模なファイアウォールシャーシ/クラスター

コアの側面にぶら下がっている大規模な中央ファイアウォール（クラスター）を展開し、内部および外部ルーティングインスタンスを使用してトラフィックをルーティングしてルーティングします（例：内部インスタンスのデフォルトゲートウェイはファイアウォール、デフォルトゲートウェイはファイアウォールはコア上の外部インスタンスであり、外部インスタンスのデフォルトは境界です。

長所：

• 管理および構成する単一のボックス
• 監視する単一のボックス
• パッチを適用する単一のボックス
• 顧客の分離

短所：

• 初日費用が高くなります
• 縮小なし
• 構成によっては、顧客間トラフィックが境界ルーターを介してルーティングを開始する場合があります

どのコアスイッチを実行していますか？通常、ポリシーはディストリビューションレイヤーで行われます。コアの設計を折りたたむ場合は、コアで要件を処理できます。また、ステートフルインスペクションとACLのどちらが好きですか。従う必要があるコンプライアンスがある場合は、ACLだけでは不十分な場合があります。

個人的には、ファイアウォールを使用します。クラスター化できるものを探して、それぞれをクラスター化して、sourcefireファイアウォールなどの集中管理されたルールベースを維持できるようにします。