3 つ目の設計課題 - パート 2(Virgilio Spaziani)

    本ページは英語ドキュメントを翻訳したものです。

     


     

     3 つ目の設計課題 - パート 2(Virgilio Spaziani)

    設計課題パート 1 では、4 つの少しずつ異なる要件セットのシナリオと、8 つの設計ソリューションを紹介しました。パート 2 では、要件を分析してソリューションを比較し、各要件セットに「最適」なソリューションを決定します。ここで注意すべき点は、ベスト プラクティスではなく、ソリューションのカスタマイズを重視していることです。

     

     

     

     

    すべての設計ソリューション(再掲)

    Blog36-All+solutions.png

    分析

     

    要件セット 1 の分析

    • プライベート WAN に単一のルーティング アルゴリズム:同じルーティング プロトコルにする必要はありません。たとえば OSPFv2 と OSPFv3、RIPv2 と RIPng は、同じアルゴリズムを共有しています。ただし、RIPng はデュアル スタックをサポートせず、VRF で IPv4 アドレス ファミリのみを管理するので、対応していません。
    • IPv4 および IPv6 に対するディスタンス ベクター ルーティング プロトコルの希望:ディスタンス ベクター プロトコルは、RIPv2、RIPng、EIGRP for IPv4、EIGRP for IPv6 です。
    • ヨーロッパ ブランチから SWR サービスへ安全に接続する:サーバには、SSL ベースのセキュアな HTTP 経由で到達できる必要があります。これは、NAT-PT(廃止されているため、通常は候補にない)、または GW-1 上の NAT64 静的変換とブランチの NAT64 動的プール、または任意の推奨トンネリング メカニズム(DMVPN、6to4、または 6RD)のいずれかを使用して達成できます。
    • トンネリングの回避:この要件によって DMVPN、6to4、6RD ソリューションは除外されます。
    • ヨーロッパ支社から IPv4 インターネットへの直接アクセス:ピュア IPv6 ネットワークから直接 IPv4 インターネットにアクセスするには、支社に NAT64 および DNS64 が必要です。

     


    単一ルーティング アルゴリズム、デュアル スタック IPv4 および IPv6 向けディスタンス ベクター RPSWR サービスへの安全な接続
    トンネリングの回避IPv4 インターネットへの直接アクセス
    設計ソリューション 1非対応対応対応対応対応
    設計ソリューション 2対応非対応対応非対応対応
    設計ソリューション 3対応対応対応非対応対応
    設計ソリューション 4対応対応対応対応対応
    設計ソリューション 5対応非対応対応非対応非対応
    設計ソリューション 6非対応対応対応非対応対応
    設計ソリューション 7対応非対応対応非対応非対応
    設計ソリューション 8対応非対応対応非対応非対応

     

    Rising Sun 社の要件セット 1 に対して最適なソリューションは「設計ソリューション 4」です。

     

    要件セット 2 の分析

    • プライベート WAN の IPv4 と IPv6 の両方に対応する単一ルーティング プロトコル:RIPv2 と RIPng、EIGRP for IPv4 と IPv6 は、別のルーティング プロトコルであることを確認します。顧客はディスタンス ベクター プロトコルを希望していますが(つまり必須ではない)、単一の RP 要件を満たすソリューションは OSPFv3 だけなので、ここでは妥協する必要があります。
    • ヨーロッパの支社数が 8 から 50 に増加:デバイスの CPU と帯域幅は、ブランチ数の増加だけでなく、運用面での拡張性にも対応する必要があります。NAT64 を双方向にするには静的変換が必要ですが、50 個のスポークには不向きで維持も困難です。
    • GW-2 による IPv6 インターネット アクセス:GW-2 にアクセスするにはトンネルが必要です。
    • ヨーロッパ ブランチの IPv6 のみによるインターネット アクセス:ヨーロッパ ブランチを統合するトンネリング機能で十分です。NAT64 は IPv4 インターネット アクセスのためのものではありません。ソリューション 1 と 4 では、変換ルールによっては、IPv4 インターネットに完全な到達可能性を与えることなく、ヨーロッパ支社からプライベート WAN に到達できます。ソリューション 2、3、6 は、DMVPN を NAT64 と併用するため、IPv4 インターネット アクセスがネットワークと統合されます。

     


    IPv4 と IPv6 に単一の RP50 のヨーロッパ支社に拡張GW-2 による IPv6 インターネット アクセスIPv6 のみを使用したインターネット アクセス
    設計ソリューション 1非対応非対応非対応対応
    設計ソリューション 2非対応対応対応非対応
    設計ソリューション 3非対応対応対応非対応
    設計ソリューション 4非対応非対応非対応対応
    設計ソリューション 5非対応対応対応対応
    設計ソリューション 6非対応対応対応非対応
    設計ソリューション 7非対応対応対応対応
    設計ソリューション 8対応対応対応対応

     

    Rising Sun 社の要件セット 2 に対して最適なソリューションは「設計ソリューション 8」です。ディスタンス ベクターの希望に沿うソリューションはありませんが、設計ソリューション 8 はすべての必須要件を満たします。

     

    要件セット 3 の分析

    • プライベート WAN に単一のルーティング アルゴリズム:同じルーティング プロトコルにする必要はありません。たとえば OSPFv2 と OSPFv3、RIPv2 と RIPng は、同じアルゴリズムを共有しています。ただし、RIPng はデュアル スタックをサポートせず、VRF で IPv4 アドレス ファミリのみを管理するので、対応していません。
    • IPv4 および IPv6 に対するディスタンス ベクター ルーティング プロトコルの希望、RIPng は希望しない:この要件からは、EIGRP for IPv4 と IPv6 が候補に残されます。
    • ダイナミック ブランチ IP アドレッシング:GW-1 と支社との間にルーティング プロトコルが必要です。
    • ヨーロッパの支社数が 8 から 50 に増加:デバイスの CPU と帯域幅は、ブランチ数の増加だけでなく、運用面での拡張性にも対応する必要があります。NAT64 を双方向にするには静的変換が必要ですが、50 個のスポークには不向きで維持も困難です。
    • ヨーロッパ支社から IPv4 インターネットへの直接アクセス:ピュア IPv6 ネットワークから直接 IPv4 インターネットにアクセスするには、支社に NAT64 および DNS64 が必要です。

     

    単一ルーティング アルゴリズム、デュアル スタックIPv4 と IPv6 に対するディスタンス ベクター RP(RIPng は対象外)ダイナミック ブランチ IP アドレッシング50 のヨーロッパ支社に拡張IPv4 インターネットへの直接アクセス
    設計ソリューション 1非対応非対応非対応非対応対応
    設計ソリューション 2対応非対応対応対応対応
    設計ソリューション 3対応対応対応対応対応
    設計ソリューション 4対応非対応非対応非対応対応
    設計ソリューション 5対応非対応非対応対応非対応
    設計ソリューション 6非対応非対応対応対応対応
    設計ソリューション 7対応非対応対応対応非対応
    設計ソリューション 8対応非対応非対応対応非対応

     

    Rising Sun 社の要件セット 3 に対して最適なソリューションは「設計ソリューション 3」です。

     

    要件セット 4 の分析

    • IPv4 および IPv6 に対するディスタンス ベクター ルーティング プロトコルの希望:ディスタンス ベクター プロトコルは、RIPv2、RIPng、EIGRP for IPv4、EIGRP for IPv6 です。
    • 隣接関係またはネイバー関係メカニズムなしに、プライベート WAN でヨーロッパ ブランチを 8 から 200 に増加:デバイスの CPU と帯域幅は、ブランチ数の増加だけでなく、運用面での拡張性にも対応する必要があります。NAT64 では双方向の静的変換が必要ですが、維持が困難で、200 個のスポークには不向きです。RIPng は要件を満たしますが、スタティック ルートの拡張性は限られています。自動トンネル 6to4 と 6RD も、アドレッシング計画によっては拡張できます。隣接関係なし・ネイバー関係なしの要件から、OSPF と EIGRP は除外されます。
    • ヨーロッパ支社から IPv4 インターネットへの直接アクセス:ピュア IPv6 ネットワークから直接 IPv4 インターネットにアクセスするには、支社に NAT64 および DNS64 が必要です。
    • GW-2 による IPv6 インターネット アクセス:GW-2 に到達するトンネルが必要です。

     

    ディスタンス ベクターの希望200 のヨーロッパ ブランチに増加(隣接関係なし・ネイバー関係なし)IPv4 インターネットへの直接アクセスGW-2 による IPv6 インターネット アクセス
    設計ソリューション 1対応非対応対応非対応
    設計ソリューション 2非対応非対応対応対応
    設計ソリューション 3対応非対応対応対応
    設計ソリューション 4対応非対応対応非対応
    設計ソリューション 5非対応対応非対応対応
    設計ソリューション 6対応対応対応対応
    設計ソリューション 7非対応非対応非対応対応
    設計ソリューション 8非対応対応非対応対応

     

    Rising Sun 社の要件セット 4 に対して最適なソリューションは「設計ソリューション 6」です。

     

    まとめ

    どのソリューションが「最適」でしょうか。なぜネットワーク設計者がよく「場合による」と返答するのか、おわかりになったでしょう。ここまで見てきたように、シナリオの要件が変わると、「最適」なソリューションも変化します。CCDE 実技試験でも、あるいは実際のネットワーク設計の場面でも、すべての要件と制約を把握して、多様な設計ソリューションに対して分析すると、提案する設計について理由を説明しやすくなります。どのソリューションも制約内の全要件は満たせないことがありますが、このような場合、お客様と共に妥協点を探ります。

     

    著者について

    pic Virgilio.png

     

     

    Virgilio Spaziani は CCDE 認定(#20140003)および、3 つの CCIE 認定(R&S、SP、セキュリティ)の保有者(#35471)です。スイスでシスコの公式インストラクタも務めるネットワーク設計者です。簡単なネットワーク設計で複雑なネットワーク要件を解決し、簡単な例を用いて複雑なテクノロジーを教えることを得意としています。

     

     

     

     

    次の方法で、このテーマについてさらに学んだり情報を交換したりすることができます。

    CLNBanner