ソリューションアーキテクチャ

概念実証 非実稼働グレードのDHCPサーバー統合アプローチ

このアプローチでは、DHCPサーバーはファブリックのサービスブロック機能にローカルで接続されます。冗長性のために、ファブリック側にESI-LAG、サーバー側に通常のLAGが設定されています。可能なすべての4,000+ VLANが設定され、このリンク上でDHCPサーバーに向けて公開されます。すべてのアクセスVLANのレイヤー2ブブロードキャストドメインがDHCPサーバーに拡張されるため、ファブリック自体にDHCPリレーの追加設定は必要ありません。一致するサブインターフェイスをリッスンするように設定することで、DHCP サーバーはクライアントが送信する MAC ブロードキャストパケットをリッスンしてリースを割り当てることができます。これは昔ながらの方法で機能し、多くのDHCPサーバー(Junos OSを含む)がこのトラフィックに応答できます。

注:

これは、実稼働グレードの設計や展開には明らかに推奨されません。ネットワークの迅速な稼働には役立つかもしれませんが、このような設計には重大なセキュリティリスクが伴います。

実稼働グレードの設計でこれを推奨しない理由は、ファブリック設計の基本的なセキュリティ機能を迂回するためです。通常、すべてのファブリックVRFは互いに分離されています。これにより、異なるVRF内のVLAN間のすべてのトラフィックが、ファイアウォールなどのセキュリティ機能を実装できるWANルーターを通過することが強制されます。サービスブロック内のDHCPサーバーへのリンク上にすべてのVLANを配置することで、WANルーターをバイパスして、セキュリティ機能をバイパスします。攻撃者がオープンな管理者ログインや設定ミスなどのセキュリティホールを見つけた場合、攻撃者はすべてのVLAN間を移動したり、VRF間のWANルーターベースのスクリーニングをバイパスしたりする可能性があります。 このトレードオフにご注意ください。

推奨される実稼働グレードのDHCPサーバー統合アプローチ

推奨される実稼働グレードのソリューションは、 IETF RFC 2131 および RFC 3046 標準ベースのアプローチに従い、ファブリック内でDHCPリレーを活用して、顧客管理のDHCPサーバーに転送することです。

キャンパスファブリックでは、DHCPリレーは通常、レイヤー3ゲートウェイVRFが接続されたアクセススイッチからノースバウンド機能に向けてトラフィックを送信する場所に配置されます。これは、これがレイヤー2ブブロードキャストドメインとネットワーク内の残りのレイヤー3転送の間の境界であるためです。リースを要求するDHCPクライアントは、常にこのレイヤー2ドメインのブロードキャストMACアドレスであるFF:FF:FF:FF:FFアドレスに対応します。このようなメッセージがVRFに到達すると、VRFのDHCPリレー機能(RFC 2131ではBOOTPリレーエージェントと呼ばれています)によって、ファブリックに接続されたDHCPサーバーまたはファブリック外部のDHCPサーバーに向けてIP UDPパケットとして転送されます。これに伴い、DHCPサーバーへの転送追加情報は常にUDPパケットに埋め込まれます。

• ゲートウェイIP(RFC 2131ではこれを「giaddr」と呼びます)は、DHCPパケットの送信元IPアドレスです。DHCP サーバーは、すべての応答パケットをこの埋め込み IP アドレスに送り返します。したがって、応答パケットがこのIPアドレスに到達できることが重要です。この報告された送信元IPは、ファブリックタイプとWANルーターの統合方法によって異なる場合があります。このJVDで説明されている最も一般的な2つの方法は次のとおりです。
  • 仮想ゲートウェイアドレッシングを使用する小規模ファブリックの場合、各ファブリックVRFでローカルに設定された各オーバーレイVLANの静的IPアドレスがゲートウェイIPとして使用されます。
  • エニーキャストアドレッシングが使用されている大規模なファブリックでは、ファブリック全体に分散されたVRFがオーバーレイループバックIPの追加範囲を使用します。このファブリックでVRFが設定されているすべてのノードの各VRFは、ゲートウェイIPとして使用する固有のIPアドレスを取得します。したがって、追加のオーバーレイネットワークがありますが、それはVRF全体で共有されます。この場合、ループバックIPアドレスの使用には2種類あることに注意してください。
    • 各EVPNファブリックスイッチのlo0.0インターフェイスにバインドされた既存のアンダーレイループバックIPアドレスが常に存在します。これらは、VXLAN VTEPおよびEVPN BGPシグナリングに使用されます。通常、オーバーレイトランスポートでは見えません。
    • DHCPリレーに使用される新しいループバックIPアドレスがオーバーレイVLANに表示されます。このオーバーレイループバックプールを定義する際、この範囲がオーバーレイVLANによって他の場所では使用されないように注意してください。また、このオーバーレイループバックプールのIPアドレスは、VRFが配置されているEVPNファブリックのノードにのみバインドする必要があります。
• DHCP リレー機能には、RFC 3046 に従って DHCP オプション 82 で追加された情報などの追加情報が組み込まれていることが想定されています。これにより、DHCP サーバーはクライアント要求のソースを特定し、リース配布の決定をより適切に管理できるようになります。これは、DHCPサーバーがUDPパケットを受信するIPアドレスのソケットインターフェイスでリッスンするように設定されているため、ローカルVLANからのDHCPリース要求を受信できなくなるためです。DHCP サーバー ベンダーがオプション 82 に埋め込むことができる属性はさまざまであり、常にファブリックとの統合の対象となります。

すでに述べたように、ファブリックは、ファブリック内のVRFが配置されている場所にDHCPリレー機能を設定します。スイッチ上でこれを手動で変更しようとしないでください。ファブリック設定フィールド内には、ネットワークとVRFを設定するペインにDHCPリレー設定オプションがあります。残りは、下の図に示すように、ジュニパーMist™クラウドによって必要なノードに自動的に導入されます。

ファブリックの種類	DHCPリレーの設定:	サポートされているノードの数
EVPNマルチホーミング	コラプストコアスイッチ	最大 4
CRB	コアスイッチ	最大 4
ERB	分散型スイッチ	多数
エッジでルーティングされたIP Clos	アクセススイッチ	多数

仮想ゲートウェイファブリックとエニーキャストファブリックの比較

ファブリックの種類によっては、オーバーレイVLAN(クライアントトラフィックがある場所)で内部目的で追加のIPアドレスが必要になる場合があります(仮想ゲートウェイファブリックの場合がこれに該当します)。ジュニパーMistキャンパスファブリックは、以下のファブリックタイプを設定します。

ファブリックの種類	仮想ゲートウェイファブリック		エニーキャストファブリック
EVPNマルチホーミング		はい	---
CRB		はい	---
ERB		---	はい
IP Closファブリック		---	はい

仮想ゲートウェイファブリックでは、通常、VRFの数は非常に限られています。これらはコアスイッチまたはコラプストコアスイッチに配置されています。ジュニパー Mist キャンパス ファブリックでサポートされるコア スイッチまたはコラプストコア スイッチの最大数は 4 つです。つまり、特定のVRFをファブリック内の各冗長コアスイッチまたはコラプストコアスイッチに最大4回複製できます。仮想ゲートウェイファブリックではなく、エニーキャストファブリックは、より拡張性の高い設計に適しています。したがって、VRF の場所は、分散型スイッチ(ERB)またはアクセス スイッチ(IP Clos ファブリック)のいずれかです。仮想ゲートウェイファブリックの性質上、ファブリックにあるVLANごとにVRFごとに一意の追加の静的IPアドレスが必要となります。そのため、各VLANの共有ゲートウェイIPアドレスに加えて、そのサブネット上に最大4つの固有のIPアドレスが追加される必要があります。

なぜそのようなデザインなのでしょうか?DHCPリレーなど、ファブリック上の特定のトラフィックにはメリットがあります。DHCPリレーでは、DHCPクライアント要求を転送する際に、ゲートウェイIPアドレスではなく静的IPアドレスを使用します。静的IPアドレスはVLAN/コアスイッチに固有であるため、この動作によりDHCP応答パケットが正しいVRFに送返されます。

仮想ゲートウェイファブリックについて考える別の方法は、VRRPなどの従来のレイヤー2ゲートウェイフェイルオーバー設計と比較することです。そこでは、ゲートウェイ(VRF)の間に常にVIPがフローティングしており、各ゲートウェイにはVLANごとに固有の静的IPが追加されます。ジュニパー Mist キャンパスファブリックでは、EVPNコントロールプレーンがVRRPプロトコルを引き継ぐため、VRRPプロトコルは必要ありません。

各サブネットでこれらの追加の静的IPアドレスを切り取るために必要な小さな犠牲は、エニーキャストファブリックでは不要になります。これは、VRF がインストールされている分散/アクセス スイッチの拡張性が高いため、VLAN を作成する際には、将来の成長を適切に計画する必要があります。DHCPリレーなどのシステムサービスは、エニーキャストファブリックでは少し異なる動作をし、内部的にはより複雑です。

報告されたゲートウェイIPアドレスとしてどのIPアドレスを選択しますか?

通常、ファブリック内のDHCPリレー機能によって転送されるパケットにどのゲートウェイIPアドレスが埋め込まれているかを決定するには、以下のいずれかのアプローチを選択する必要があります。

• EVPNマルチホーミングファブリックの場合、UIに選択肢がないため、ゲートウェイIPには常に仮想ゲートウェイIPアドレスを使用します。これにより、DHCPサーバーは、転送されたパケットに埋め込まれたゲートウェイIPアドレスのみを分析することで、リクエストが発信されたVLANを識別できます。
• CRBファブリックの場合、キャンパスファブリックダイアログの「Loopback per-VRF subnet」にIPプレフィックスを入力する際に、「Loopback per-VRF subnet」フィールドを空白のままにするか、ファブリック内の各VRFに割り当てられたオーバーレイループバックIPアドレスを持つ設計を使用することで、仮想ゲートウェイの静的IPアドレス設計を選択できます。
• ERBやIP Closなどの大規模なファブリックについては、キャンパスファブリック設定の一部として「VRFごとのループバックサブネット」にIPプレフィックスを入力することをお勧めします。これにより、ファブリックは、このプール範囲外の一意のオーバーレイループバックIPをファブリック内の各VRFに自動的に割り当てます。この場合、オーバーレイループバックIPを使用すると、WANルーターから各ゲートウェイIPにどのように到達できるかを予測することが困難になる可能性があるため、ファブリックへのWANルーター統合にOSPFやBGPなどのルーティングプロトコルを活用することを強くお勧めします。

これらのファブリックでは、「Loopback per-VRF subnet」フィールドを空白のままにしておくことは技術的には可能ですが、これは推奨されません。空白のままにすると、エニーキャストゲートウェイIPは、転送されたパケットに埋め込まれた報告されたゲートウェイIPになります。これにより、DHCP サーバーに向かう途中で問題が発生することはありません。ただし、DHCPサーバーの応答が返された場合、エニーキャストIPはファブリック内の複数のスイッチで共有されるため、応答パケットはリクエストを発信していないスイッチにルーティングされる可能性があり、別のPoDまたは建物にある可能性があります。この場合、要求を開始していないスイッチにパケットが到着すると、DHCP リレー機能が応答のカプセル化を解除し、クライアントの MACアドレスに基づいて、パケットをリモート スイッチに転送する必要があると判断します。そのために、VXLAN トンネルを使用して、クライアントが実際に接続されているスイッチにパケットを東西方向に再送信します。これにより、非効率的な設計が生じます。

DHCPサーバーの場所

当社が推奨するアプローチは、ファブリック自体の一部としてのローカル統合です。

キャンパスファブリックの場合、サービスリーフはサービスブロック機能と呼ばれ、次の例では、DHCPサーバーが接続されている場所の北にある一対の物理スイッチがファブリックの不可欠な部分となっています。

DHCP サーバーは、自身と同じ VRF にないクライアントのリースを管理することもできます。ただし、ファブリック内では常にVRF間の分離が存在するため、パケットはWANルーターを介して交換する必要があります。

このようなローカル統合が不可能な場合は、DHCPサーバーをファブリックに対する外部要素として統合することもできます。次の図の左上隅に表示されている内容です。

考慮すべきこと外部のDHCPサーバーを使用していますか?

外部DHCPサーバーをファブリックに統合する場合、このアプローチを成功させるためには、以下の2つの重要な点に留意する必要があります。

• ファブリックとDHCPサーバー間の遅延をできるだけ低く保ちます。遅延への影響がわからない場合は、パブリック クラウド環境での DHCP サーバーの運用を検討しないでください。一部のDHCPクライアントは、リースを要求する際に非常に攻撃的になることがあります。これにより、応答のないDHCPリース要求が高遅延環境で積み重なり、DHCPサーバーに過負荷がかかる可能性があります。DHCPクライアントの動作はファブリックレベルでほとんど影響を受けないため、ファブリックを本番環境に移行する前に、ラウンドトリップの遅延時間全体に焦点を当てて設計をテストすることをお勧めします。
• ファブリックとDHCPサーバーの間では、いかなる形式のネットワークアドレス変換(NAT)もサポートされていません。この理由は、DHCPサーバーがクライアント要求に応答する必要がある方法を説明したIETF RFC 2131からの次の抜粋で説明されています。「giaddr」は埋め込みゲートウェイのIPアドレスであることを覚えておいてください:

この RFC の説明が何を意味するのかご存じないかもしれませんので、RFC に従って SNAT された DHCP 要求に応答しない Microsoft DHCP サーバーを使用するトラフィックの例を示しました。

リレーパケット用に作成されたアクセススイッチの元の送信元IPとポートを次に示します。

WAN ルーターが転送された検出メッセージに SNAT を適用すると、送信元 IP とポートが次のように変更されます。

ただし、DHCP サーバーの応答は、SNAT が適用される前のファブリック内の元の送信元 IP であったポート 67 の元の組み込みゲートウェイ IP に応答します。

このパケットが SNAT ファイアウォールに到着することはありません。

DHCPリレー設計に役立つJunos OSの最適化

Junos OS設定では、いくつかのステートメントが設計の最適化に役立ちます。ファブリックが自動的に設定する理由を知りたい場合に備えて、ここでは重要な要素を紹介します。

Junos OSの設定では、デバイスが制御されていないDHCPトラフィックを監視できないようにするために、「forward-only」ステートメントが必要です。

Junos OS設定では、「relay-option-82 circuit-id vlan-id-only」ステートメントは、オプション82のDHCPトラフィックを転送する際のQFXスイッチとEXスイッチの動作を同期させます(デフォルトでは、異なる属性を使用します)。また、この属性によって、「IRB-irb.1099:ae10.0」や「IRB-irb.1099:vtep.32769」などの不要なインターフェイス情報は追加されなくなります。この設定を追加すると、VLAN ID のみが報告されるため、このフィールドでの文字列解析が容易になり、Linux KEA DHCP サーバーが適切なリースを割り当てるためにこのフィールドを活用します。

ここでは、Junos OSの設定ステートメント「relay-option-82 server-id override」について説明します。この説明は、当社の環境で必要とされています。これは、サブオプション5を使用してMicrosoft DHCPサーバーがパケットの送信元を特定し、割り当てる適切なプールを選択するのに役立ちます。

ループバックIPをゲートウェイIPとして使用する場合、Junos OS設定ステートメントの「ルート抑制宛先」が必要です。ゲートウェイIPとしての仮想ゲートウェイアドレス静的IPには使用されません。

Junos OS設定では、ファブリックはすべてのIRBインターフェイスを「no-dhcp-flood」オプションで設定するようになりました。これにより、クライアントのMACブロードキャストを制限し、すべてのDHCPリレーデバイスが、重複したクライアントから同じリクエストを受信しないようにすることができます。このオプションを設定しないと、すべてのクライアント要求がVLAN内のブロードキャストパケットであるため、元の要求はVXLANを介して複製され、そのVRFが設定されているすべてのファブリックノードに送信され、ファブリックノードはWANルーターに向けてDHCPリレーを実行します。

注:

ラボで vJunosスイッチ を仮想スイッチインスタンスとして使用する場合、「no-dhcp-flood」オプションは仮想スイッチ上で設定できますが、現在は実装されていないことが知られています。そのため、フラッディングや間違ったゲートウェイIPアドレスが使用されている場合があります。ただし、それをテストする能力には影響しません。これはvJunosスイッチの既知の制限にすぎません。