IP Prefix Advertisement in EVPN (Draft 11)
はじめに
この文書は IP Prefix Advertisement in EVPN (ドラフト11版) (draft-ietf-bess-evpn-prefix-advertisement-11) の翻訳です。この文書ではEVPNのRoute Type 5 (IP Prefix)とサブネット間転送のための利用方法とユースケースの例が記述されています。
翻訳者はデータセンターネットワークの専門家ですが翻訳の専門家ではありません。技術的な意味を維持した上でなるべく読みやすい日本語になるようにしているため、英文の直訳ではなく一部のニュアンスがかけている場合がありますのでご了承ください。オリジナルの目次、謝辞、参考文献、RFC2119のやつ等は省略しています。
この文書はドラフトであるため、用語や表記が統一されていなかったり、仕様の内容について曖昧な部分がありますが、原文に忠実になるように訳しています。
免責
この翻訳を信用して不利益を被っても責任取れません的なやつ。
目次
- はじめに
- 目次
- Abstract
- 1. はじめに
- 2. 問題提起
- 3. BGP EVPN IP Prefix経路
- 4. Overlay Indexのユースケース
- 5. セキュリティに関する考察
- 6. IANAに関する考察
Abstract
BGP MPLSベースのEthernet VPN(EVPN) RFC7432 の仕組みは柔軟なコントロールプレーンを提供して、MPLSと/またはNVO (Network Virtualization Overlay) [RFC7365] のネットワークのサブネット内の接続性を可能にします。いくつかのネットワークにおいては、テナントシステムとエンドデバイスが物理的なものと仮想的なもののいずれかでありつつ、ダイナミックルーティングプロトコルに参加する必要がない状態で、これらにまたがった動的かつ効率的なサブネット間の接続性を必要とします。この文書ではIPプレフィックスを広告するための新しいEVPN経路タイプを定義し、この新しい経路タイプを使用するユースケースの例を説明します。
1. はじめに
RFC7365 ではレイヤー3越しのデータセンター(DC)ネットワーク仮想化を提供し、ネットワーク仮想化エッジ(NVE)がレイヤー2とレイヤー3の仮想化されたネットワークサービスをマルチテナントのDCで提供しなければならないことについて仕様化しました。 RFC8365 ではこうしたDCにおいてEVPNをレイヤー2やサブネット内のサービスとして提供するための技術的な選択肢としてEVPNの利用を議論しています。この文書では、 EVPN-INTERSUBNET に沿った形で、レイヤー3やサブネット間の接続性のサービスのためにEVPNを使用する方法について明示します。
[EVPN-INTERSUBNET] では、TSがリモートのサブネットに位置するTSに対してパケットを交換することができるように、かなり一般的なサブネット間フォワーディングのシナリオについて定義しています。これを実現するために、[EVPN-INTERSUBNET]ではTS RT-2経路にエンコードされたMAC/IPが、MAC-VRFとオーバーレイARPテーブルだけでなく、エンコードされたTSホスト経路(/32または/128)にともなうIP-VRFテーブルについても、どのように生成するのかを記述しています。いくつかのケースにおいてEVPNはIP Prefixを広告することができ、そのため個別のホスト経路を伝搬させる代わりにIP-VRFテーブル内での集約を行うことができます。この文書では [EVPN-INTERSUBNET] で記述されたシナリオを保管して、EVPNがIP Prefixを広告するためにどのように使用されるのかについて定義します。EVPNとL3VPN RFC4364 IP Prefix経路の間の相互運用性はこの文書の範囲外とします。
2.1節ではデータセンターにおけるサブネット間の接続性の要件について記述します。2.2節ではIP Prefixの広告のためになぜ新しいEVPN経路タイプが必要なのかを説明します。3、4、5節ではこの経路タイプとこれが特定のユースケースについてどのように使用されるのかを記述します。
1.1 用語
（いつものRFC2119, RFC8174の定義）
AC: Attachment Circuit、接続回線。
ARP: Address Resolution Protocol
BD: Broadcast Domain、ブロードキャストドメイン。RFC7432のとおり、EVIは単一または複数のブリッジドメインで構成されています。VLAN-bundleとVLAN-basedサービスモデル(RFC7432参照)の場合、DBはEVIと等価です。VLAN-aware bundleサービスモデルの場合、EVIは複数のBDを含んでいます。また、この文書では、BDとサブネットは等価な用語です。
BD Route Target: ブロードキャストドメインに対して割り当てられたRoute Target(RFC4364)のことを指します。VLAN-aware bundleサービスモデルの場合、MAC-VRF内のすべてのBDインスタンスは同じRoute Targetを共有しています。
BT: Bridge Table、ブリッジテーブル。RFC7432のとおり、MAC-VRFにおけるBDのインスタンス。
DGW: Data Center Gateway、データセンターゲートウェイ。
Ethernet A-D経路: RFC7432の通り、Ethernet Auto-Discovery (A-D)経路
Ethernet NVOトンネル: イーサネットペイロードのNetwork Virtualization Overlayトンネルを指す。このタイプのトンネルの例はVXLANやGENEVE。
EVI: RFC7432のとおり、参加しているNVE/PE機器にまたがるEVPNインスタンス。
EVPN: RFC7432のとおり、Ethernet Virtual Private Networks。
GRE: Generic Routing Encapsulation
GW IP: Gateway IP Address
IPL: IP Prefix Length
IP NVOトンネル: (ペイロードにMACヘッダがない)IPペイロードのNetwork Virtualization Overlayトンネルを指す。
IP-VRF: あるNVE/PEにおけるIP経路のためのVPN Routing and Forwardingテーブル。IP経路はEVPNとIP-VPNアドレスファミリーによって生成することができる。IP-VRFはNVE/PEにおいてレイヤー3VPNのインスタンスでもある。
IRB: Integrated Routing and Bridgingインターフェイス。IRBはIP-VRFをBD(またはサブネット)に接続する。
MAC-VRF: RFC7432のとおり、NVE/PEにおけるMedia Access Control (MAC)アドレスのためのVirtual Routing and Forwardingテーブル。MAC-VRFはNVE/PEにおいてEVIのインスタンスでもある。
ML: MACアドレス長
ND: Neighbor Discovery Protocol
NVE: Network Virtualization Edge
GENEVE: Generic Network Virtualization Encapsulation
NVO: Network Virtualization Overlays
RT-2: EVPN経路タイプ2、つまりRFC7432に定義されているように、MAC/IP Advertisement経路
RT-5: EVPN経路タイプ5、つまりIP Prefix経路。3節で定義されている。
SBD: Supplementary Broadcast Domain。ACを一つももたず、IRBインターフェイスだけをもち、そのテナントのすべてのIP-VRF間で接続性を提供するために使用されるBD。SBDはIP-VRF to IP-VRFのユースケース(4.4節参照)でのみ必要とされます。
SN: Subnet
TS: Tenant System
VA: Virtual Appliance
VNI: Virtual Network Identifier。RFC8365にあるように、この用語は24ニットのNVOインスタンス識別子の表現方法として使用され、特別に言及がない限り、VXLANにおいてはVXLAN Network Identifier、GENEVEにおいてはVirtual Network Identifierを指します。
VTEP: RFC7348のとおり、VXLAN Termination End Point
VXLAN: RFC7438のとおり、Virtual Extensible LAN
この文書ではRFC7432、RFC8365、RFC7465の用語についても馴染みがあるものと仮定しています。
2. 問題提起
この節ではデータセンターにおけるサブネット間の接続性の要件と、IP Prefixを広告するための特定の経路タイプがなぜ必要になるのかについて述べます。
2.1. データセンターにおけるサブネット間接属性の要件
RFC7432は、データセンター(DC)におけるNetwork Virtualization Overlay(NVO)のためのコントロールプレーンとして使用され、RFC8465に記載されているように、Network Virtualization Edge(NVE)機器はハイパーバイザやTop of Rackスイッチ(ToR)に設置することができます。
MACアドレス、場合によってはIPアドレスによって識別され、Attachment CircuitによってBDに接続される物理的または仮想的なシステムであるTenant System(TS)には次の考察が当てはまります。
Tenant Systemは自身のMACアドレスとIPアドレスからトラフィックを生成する仮想マシン(VM)である場合があります
Tenant Systemは背後にある異なるエンドデバイスのIPアドレスへ/からトラフィックを転送する仮想アプライアンスのエンティティ(VA)である場合があります
これらのVAはファイアウォール、ロードバランサ、NAT機器、その他アプライアンス、または仮想ルーティングインスタンスを持つ仮想ゲートウェイである可能性があります
これらのVAはダイナミックルーティングプロトコルに必ずしも参加していません。そのためEVPN NVEが代理でその経路を広告することに頼ります。
これらのすべての場合において、VAは自身の送信元MACアドレスを使いながら、送信元IPには背後にあるエンドデバイスに関連するものや、VAがNATを行っている場合は変換されたIPアドレス(パブリックなNATプールの一部)を使用してトラフィックを他のTSに転送するでしょう。
これらのTSのうち2つの背後に同じIPアドレスとエンドポイントが存在しうることに留意してください。一つの例として特定のアプライアンスの回復機構が挙げられます。2つのVAのうちの1つ(マスターVA)が回復プロトコルを動作させていて、仮想IPまたはFloating IPを持っているケースです。RFC5798のVirtual Router Redundancy Protocol (VRRP)がこれの例の一つです。その他の例としてマルチホームのサブネットが挙げられます。同じサブネットが2つのVAに接続されている場合です。
これらのVAが背後にあるVMやサブネットへのIP接続性を提供している一方で、これらのVAは必ずしもEVPN NVEに接続するIPインターフェイスを持つわけではありません。例えばレイヤー2のファイアウォールなどがIPインターフェイスをサポートしないVAの例として挙げられます。
図1は上記の例のうちいくつかを記載したものです。
NVE1
+-----------+
TS1(VM)--| (BD-10) |-----+
IP1/M1 +-----------+ | DGW1
+---------+ +-------------+
| |----| (BD-10) |
SN1---+ NVE2 | | | IRB1\ |
| +-----------+ | | | (IP-VRF)|---+
SN2---TS2(VA)--| (BD-10) |-| | +-------------+ _|_
| IP2/M2 +-----------+ | VXLAN/ | ( )
IP4---+ <-+ | GENEVE | DGW2 ( WAN )
| | | +-------------+ (___)
vIP23 (floating) | |----| (BD-10) | |
| +---------+ | IRB2\ | |
SN1---+ <-+ NVE3 | | | | (IP-VRF)|---+
| IP3/M3 +-----------+ | | | +-------------+
SN3---TS3(VA)--| (BD-10) |---+ | |
| +-----------+ | |
IP5---+ | |
| |
NVE4 | | NVE5 +--SN5
+---------------------+ | | +-----------+ |
IP6------| (BD-1) | | +-| (BD-10) |--TS4(VA)--SN6
| \ | | +-----------+ |
| (IP-VRF) |--+ ESI4 +--SN7
| / \IRB3 |
|---| (BD-2) (BD-10) |
SN4| +---------------------+
図1 DCサブネット間のユースケース
NVE1, NVE2, NVE3, NVE4, NVE5, DGW1, DGW2は特定のテナントのために同じBDを共有しています。BD-10が、全てのNVEで定義されたBDインスタンスの集合で構成されています。BD-10に接続している全てのホストが同じIPサブネットに所属しています。BD-10に接続しているホストは次のとおりです:
TS2とTS3は仮想アプライアンス(VA)で、背後にあるホストやサブネット(SN1, SN2, SN3, IP4, IP5)のトラフィックを送信したり受信したりします。これらのIPアドレス(IP2とIP3)はBD-10のサブネットに所属していて、このIPアドレスでもトラフィックを生成したり受信したりします。これらのVAが自身のMACアドレス(M2とM3)宛のパケットを受信したとき、適切なサブネットまたはホストにパケットをルーティングします。これらのVAは接続しているサブネットを広告するためのルーティングプロトコルをサポートしておらず、Cloud Management Systemの決定に基づいて異なるサーバやNVEに移動することが可能です。これらのVAはサブネットに対してVRRPのような冗長機構をサポートすることもできます。Floating IPがマスターVAに所有されていて、マスターVAだけが与えられたサブネットへのトラフィックを転送します。例えば図1のvIP23がFloating IPでTS2またはTS3のうちマスターであるどちらかによって所有されています。マスターだけがトラフィックをSN1に転送します。
Integrated Routing and BridgingインターフェイスであるIRB1, IRB2, IRB3はBD-10に所属するIPアドレスを持っています。これらのIRBインターフェイスはDB-10のサブネットをVirtual Routing and Forwarding (IP-VRF)インスタンスに接続し、トラフィックを同じテナントの他のサブネットに(DC内部で、またはWANの他の終端で)ルーティングすることができるようにします。
TS4はレイヤー2 VAでサブネットSN5, SN6, SN7への接続性を提供しますが、それ自身はBD-10のIPアドレスを持っていません。TS4はNVE5のEthernet Segment Identifierが4であるポートに接続しています。
Ingress NVEが接続されているBDに対して、リモートサブネットに存在するサブネットやホストにパケットを転送するためにIngress EVPN NVEが必要とする識別子を「Overlay Index(オーバーレイインデックス)」として定義します。例としてvIP23(図1)はBD-10に接続されているいずれのNVEがSN1にパケットを転送するために知る必要があるOverlay Indexです。IRB3のIPアドレスはSN4に到達するためのOverlay Indexで、ESI4(Ethernet Segment Identifier 4)はSN5にトラフィックを転送するために必要なOverlay Indexです。言い換えると、Overlay Indexはオーバーレイのアドレス空間におけるネクストホップであり、IPアドレスやMACアドレスまたはESIを使うことができます。IP Prefixとともに広告されるとき、どのEgress NVEに対してEVPNパケットを送る必要があるかを見つけ出すためにOverlay Indexは再帰的な解決を必要とします。
図1の全てのDCのユースケースではサブネット間転送を必要とし、そのために個別のホスト経路やサブネットは:
a) (VAとVMはダイナミックルーティングプロトコルに参加しないため)NVEから広告されなくてはなりませんし、
b) VAのIPアドレス、Floating IPアドレス、MACアドレス、またはESIであるOverlay Indexと関連付けることができます。このOverlay Indexは3.2節でさらに議論します。
2.2 EVPN IP Prefix経路の必要性
RFC7432ではMAC/IP経路(RT-2)について定義しており、MACアドレスをIPアドレス長とIPアドレス(IP)とともに広告することができます。経路タイプ2においてIPプレフィックスの存在を示すために可変長のIPアドレス長を使うことができる一方で、IP Prefixを運ぶためにこの経路タイプを使用することが適切でないいくつかのユースケースが存在します
このようなケースの1つの例として、2.1節で記述した「Floating IP」が挙げられます。この例ではプレフィックスの広告をM2またはM3のいずれかであるMACアドレスの広告から分ける必要があります。そうしなければEVPNソリューションは非効率性が高くなりスケールしなくなります。
例えば1,000個のプレフィックスがM2から(RT-2を使用して)広告されていて、Floating IPの所有者がM2からM3に変わったとき、1,000経路がM2からwithdrawされて、M3から1,000経路が再広告されます。しかしもし別の経路タイプを使用すると、Floating IPアドレス(vIP23)に関連付けた1,000経路を広告することができ、Floating IPの所有者を広告するために1つのRT-2、つまりvIP23とM2を経路タイプ2で広告することができます。Floating IPの所有者がM2からM3に変わったとき、その変更を示すために1つのRT-2のwithdrawとupdateだけが必要となります。リモートのDGWはvIP23に関連付けられた1,000プレフィックスのいずれも変更することはありませんが、(M3になっている)vIP23のARP解決エントリーだけを更新するでしょう。
IP Prefixの広告のためのEVPN(タイプ5)経路についてこの文書で記述します。この新しい経路タイプはRT-2経路と異なる役割を持っていて、この文書で説明するデータセンター（またはNVOベースの一般的なネットワーク）のサブネット間接続性のシナリオを解決します。新しいRT-5を使用することで、IP PrefixをOverlay Indexとともに広告することができます。Overlay IndexはGW IPアドレスやMACまたはESIです。Overlay Indexを伴わずに広告される場合は、BGPネクストホップがegress NVE/ASBR/ABRを指し、ルータMAC拡張コミュニティのMACが使用するべき内側の宛先MACアドレスを提供するでしょう。この文書を通して議論されるように、EVPN RT-2は全てのDCユースケースを満たすものではありません。そのためEVPN経路タイプ5が必要となります。
EVPN経路タイプ5はIP Prefixの広告をEVPNのMAC/IP経路広告から分離します。そのため:
a) IPv4プレフィックスやIPv6プレフィックスをNLRI(Network Layer Reachability Informationメッセージ)でMACアドレスを伴わずにきれいで明確な広告することを可能にします。
b) 経路タイプがMAC/IP Advertisement経路と異なるため、現在のRFC7432の手順を修正する必要はありません。
c) プレフィックスをオーバーレイIPアドレス、オーバーレイMACアドレス、オーバーレイESI、アンダーレイBGPネクストホップなどの 異なるタイプのOverlay/Underlay Indexにリンクできるような柔軟な実装が可能になります。
d) IP Prefixを必要としないEVPN実装は、単に経路タイプ値を見ることで経路を破棄することができます。
これからの節ではIP Prefixを広告するための経路タイプによってEVPNがどのように拡張されるのかと、データセンターに存在するサブネット感接続性の要件を解決するためにこの経路がどのように使用されるのかについて記載します。
3. BGP EVPN IP Prefix経路
RFC7432に定義されているBGP EVPN NLRIは以下のとおりです
+-----------------------------------+
| Route Type (1 octet) |
+-----------------------------------+
| Length (1 octet) |
+-----------------------------------+
| Route Type specific (variable) |
+-----------------------------------+
図2 BGP EVPN NLRI
この文書ではIANAのEVPN Route Typesレジストリにおいて追加の経路タイプ(RT-5)を定義します。この経路タイプはIP Prefixを使用したEVPN経路の広告のために使用されます。
Value: 5 Description: IP Prefix Route
RFC7606の5.4節によると、Route Type 5(RT-5)を認識しないノードはこの経路を無視します。そのためこの文書に従うNVEは、RT-5を無視するNVEが接続しているBDにも依然として接続することが可能です。RFC7432の正規の手順はこれらの両方のNVEに適用されるでしょう。2つ以上のNVEが同じテナントの異なるBDに接続しているとき、これらのNVEはのテナントのサブネット間転送を適切に動作させるためにRT-5をサポートしなければなりません(MUST)。
この経路の詳細なエンコーディングと関連する手順は以降の節で記述します。
3.1 IP Prefix経路のエンコーディング
IPv4のIP Prefix経路タイプはLengthフィールドを34に設定し、次のフィールドで構成されます:
+---------------------------------------+
| RD (8 octets) |
+---------------------------------------+
|Ethernet Segment Identifier (10 octets)|
+---------------------------------------+
| Ethernet Tag ID (4 octets) |
+---------------------------------------+
| IP Prefix Length (1 octet, 0 to 32) |
+---------------------------------------+
| IP Prefix (4 octets) |
+---------------------------------------+
| GW IP Address (4 octets) |
+---------------------------------------+
| MPLS Label (3 octets) |
+---------------------------------------+
図3 IPv4のEVPN IP Prefix経路のNLRI
IPv6のIP Prefix経路タイプはLengthフィールドを58に設定し、次のフィールドで構成されます:
+---------------------------------------+
| RD (8 octets) |
+---------------------------------------+
|Ethernet Segment Identifier (10 octets)|
+---------------------------------------+
| Ethernet Tag ID (4 octets) |
+---------------------------------------+
| IP Prefix Length (1 octet, 0 to 128) |
+---------------------------------------+
| IP Prefix (16 octets) |
+---------------------------------------+
| GW IP Address (16 octets) |
+---------------------------------------+
| MPLS Label (3 octets) |
+---------------------------------------+
図4 IPv6のEVPN IP Prefix経路のNLRI
ここで:
EVPN IP Prefix経路のBGP EVPN NLRIのLengthフィールドは(IPv4アドレスが伝達されるときの)34または(IPv6アドレスが伝達されるときの)58でなければなりません(MUST)。IP PrefixとGateway IP Addressは同じIPアドレスファミリーでなければなりません(MUST)
Route Distinguisher (RD)とEthernet Tag IDはRFC7432とRFC8365で定義されているように使用しなければなりません(MUST)。特に、RDはMAC-VRF(またはIP-VRF)ごとに一意です。MPLS LabelフィールドはMPLSラベルか、他のEVPN経路タイプのためにRFC8365で記述されているようにVNIのいずれかに設定されます。
ESIがOverlay Index(定義については3.2節を参照)に使用される場合、Ethernet Segment Identifierは0でない10オクテットの識別子でなければなりません(MUST)。そうでなければESIは全てのバイトが0でなければなりません(MUST)。ESIのフォーマットはRFC7432に記載されています。
IP Prefix LengthはIPv4アドレスでは0から32ビットの間、IPv6では0から128ビットの間で設定できる値で、Prefixのビットの数を示します。この値は128より大きくてはいけません(MUST NOT)。
GW(Gateway) IP Addressフィールドは4オクテットまたは16オクテット(IPv4またはIPv6)のフィールドで有効なIPアドレスがこのIP Prefixに対するOverlay Indexとしてエンコードされます。GW IPフィールドはOverlay Indexを使用しない場合は全てのバイトが0でなければなりません(MUST)。Overlay Indexの定義と使用方法は3.2節を参照してください。
MPLS Labelフィールドは3オクテットでエンコードされ、RFC7432のとおり上位20ビットにラベル値を含んでいます。送信時はOverlay Indexに基づいて再帰的な解決が行われる場合ラベル値はゼロにするべきです(SHOULD)。もし受信したMPLS Labelの値がゼロである場合、その経路はOverlay Indexを含んでいなければならず(MUST)、Ingress NVE/PEはEgress NVE/PEを発見するために再帰的解決を行わなければなりません(MUST)。もしLabelがゼロで経路にOverlay Indexが含まれていない場合、この経路はtread-as-withdrawRFC7606でなければなりません(MUST)。
RD、Ethernet Tag ID、IP Prefix Length、IP Prefixは経路を比較するためにBGPで使用される経路キーの一部です。残りのフィールドは経路キーの一部ではありません。
IP Prefix経路はOverlay Indexとして使用されるMACアドレスを運ぶためにRouter's MAC拡張コミュニティ(EVPN-INTERSUBNETで定義されています)と一緒に送信することができます。MACアドレスはTSのものであることも可能であることに留意してください。
3.2節で記載するように、受信した経路における特定のデータの組み合わせはRFC7606の経路の「tread-as-withdraw」処理を暗に示しているかもしれません。
3.2 Overlay Indexと再帰的ルックアップ解決
Overlay Indexを使うことによってRT-5では再帰的なルックアップによる解決を次のようにサポートしています:
Overlay IndexにはESI、テナントのアドレス空間のIPアドレス、またはMACアドレスを使用することができ、NVEが与えられたIP Prefixのネクストホップとして使用します。NVEがパケットを転送するために必要なEgress NVE/PEを知るために、Overlay IndexはIP-VRFにRT-5をインストールするNVE/PEにおいて常に再帰的な経路解決が必要です。Overlay Indexの再帰的解決はIP-VRFへのインストールに適用されるものであり、BGP伝搬(たとえばASBR)には適用されないことに留意することは重要です。また、再帰的解決の結果としてEgress NVE/PEがRT-5を生成したNVEと同じである必要はありません。
Overlay IndexはRT-5に加えて、IP PrefixのネクストホップがESIとテナント空間のIPアドレスやMACアドレスのいずれであるのかに応じて、ESIフィールド、GW IPフィールドまたはRouter's MAC拡張コミュニティで指定されます。与えられたIP Prefixに対するOverlay IndexはそのIP Prefixに対するRT-5を生成するNVEのローカルのポリシー(典型的にはCloud Management Systemで管理されます)によって設定されます。
Ingress NVEにおいて再帰的ルックアップによる解決を可能にするため、与えられたOverlay Indexに対するEgress NVEになりうるNVEは、Overlay Indexによって示されるシステムへのパスにおいて自分自身をBGPネクストホップとして広告する経路を生成しなければなりません。たとえば:
あるNVEがOverlay Indexを指定したRT-5を受け取った場合、そのOverlay Indexが再帰的に解決できない限り、そのNVEはIP-VRFでこのRT-5を使うことができません。
RT-5がOverlay IndexとしてESIを指定する場合、NVEがそのESIについてのRT-1(Auto-Discovery per-EVI)経路を受信してインストールしているの場合にのみ再帰的な解決が可能です。
RT-5がOverlay IndexとしてGW IPアドレスを指定する場合、NVEがそのIPアドレスをNLRIのIP Addressフィールドに含んだRT-2(MAC/IP経路)を受信してインストールしている場合にのみ再帰的な解決が可能です。
RT-5がOverlay IndexとしてMACアドレスを指定する場合、NVEがそのMACアドレスをNLRIのMAC Addressフィールドに含んだRT-2)MAC/IP経路)を受信してインストールしている場合にのみ再帰的な解決が可能です。
与えられたRT-5の経路を受信する前後でその再帰的な解決に必要となるRT-1またはRT-2は受信する可能性があることに留意してください。
再帰的な解決に関わらず、そのRT-5のBGPネクストホップに対するIGPまたはBGPの経路がない場合、BGPはそのRT-5がOverlay Indexを解決できるものであったとしてもインストールしてはいけません(MUST NOT)。
ESIフィールドとGW IPフィールドは両方とも同時にゼロにすることができます。しかし同時に非ゼロにしてはいけません(MSUT NOT)。非ゼロのGW IPと非ゼロのESIを(同時に)含んだ経路はRFC7606のtreat-as-withdrawであるべきです(SHOULD)。
ESIとGW IPのいずれかが非ゼロである場合、Router's MAC拡張コミュニティやLabelの値が存在しているかどうかに関わらず、非ゼロのものがOverlay Indexです。GW IPがOverlay Index(ESIがゼロ)である場合、Router's MAC拡張コミュニティは存在していても無視されます。
ESI、GW IP、MAC、Labelが同時に全てゼロであるような経路はtreat-as-withdrawであるべきです(SHOULD)。
Overlay Indexとその再帰的ルックアップによる解決は遠回りに見えますが、Overlay Indexによって表現される対象が障害を起こした場合に高速な収束を達成するために必要なものです(2.2節に記述した例を見てください)。
表1はこの仕様で許可されるRT-5のフィールドの組み合わせと、それぞれの場合で受信側のNVE/PEによってどのOverlay Indexが使用されなければならないかを示しています。表1においてOverlay Indexが存在しないケースは「None」として示されています。Overlay Indexが存在しない場合、受信側のNVE/PEはいかなる再帰的解決も実行せず、実際のネクストホップはRT-5のBGPネクストホップによって与えられます。
+----------+----------+----------+------------+----------------+ | ESI | GW IP | MAC* | Label | Overlay Index | |--------------------------------------------------------------| | Non-Zero | Zero | Zero | Don't Care | ESI | | Non-Zero | Zero | Non-Zero | Don't Care | ESI | | Zero | Non-Zero | Zero | Don't Care | GW IP | | Zero | Zero | Non-Zero | Zero | MAC | | Zero | Zero | Non-Zero | Non-Zero | MAC or None** | | Zero | Zero | Zero | Non-Zero | None*** | +----------+----------+----------+------------+----------------+
表1 - RT-5フィールドとOverlay Index
表注:
*) ゼロ値のMACはRouter's MAC拡張コミュニティがRT-5に無いことを意味しています。非ゼロはこの拡張コミュニティが存在して有効なMACアドレスが伝達されているということを示します。MACアドレスのエンコーディングは802.1Qと802.1D-REVで定義されている6オクテットのMACアドレスでなければなりません(MUST)。有効でないMACアドレスの例はブロードキャストやマルチキャストのMACアドレスです。有効でないMACアドレスである場合はその経路はtreat-as-withdrawでなければなりません(MUST)。Router's MAC拡張コミュニティだけが存在する場合、MACアドレスをOverlay Indexとして使用することを示すためには不十分です。そのためこの拡張コミュニティはその他の目的のために使用することができます。
**) この場合、Overlay Indexは受信側のNVE/PEのローカルポリシーに基づいてRT-5のMACアドレスかNoneとすることができます。そのMACをOverlay Indexとして使用するように設定されている受信側のNVE/PEが存在する場合、このOverlay Indexを設定する広告側のNVE/PEはそのMAC Overlay Indexに対するRT-2を広告するべきです(SHOULD)。表1のこのケースは4.4.1と4.4.3で説明するIP-VRF-to-IP-VRFの実装において使用されます。このモデルにおいてMAC Overlay IndexをサポートするかどうかはOPTIONALです。
***) Overlay IndexはNoneです。これはNVE/PEがEthernet NVOトンネルとは対照にIP NVOトンネルによって接続されているようなIP-VRF-to-IP-VRFのために使用される特別なケースです。
もし受信したRT-5のESI、GW IP、MAC、Labelの組み合わせが表1に示されている組み合わせのいずれにも該当しない場合、ルータはその経路をこの節(3.2)の冒頭に記述したルールに従って処理するでしょう。
表2はこの文書に記載されているそれぞれのサブネット間のユースケースと、それに対応する経路タイプ5(RT-5)のOverlay Indexのコーディングを示しています。
+---------+---------------------+----------------------------+ | Section | Use-case | Overlay Index in the RT-5 | +-------------------------------+----------------------------+ | 4.1 | TS IP address | GW IP | | 4.2 | Floating IP address | GW IP | | 4.3 | "Bump in the wire" | ESI or MAC | | 4.4 | IP-VRF-to-IP-VRF | GW IP, MAC or None | +---------+---------------------+----------------------------+
表2 - ユースケースと再帰的解決のためのOverlay Index
上記のユースケースはRT-5でサポートされるそれぞれのOverlay Index(GW IP、ESI、MACまたはNone)の代表例です。
4. Overlay Indexのユースケース
この節ではIP Prefix経路とともに使用されるOverlay Indexのタイプについていくつかのユースケースを紹介します。これらの例ではIpv4 Prefixとサブネットを使用していますが、RT-5についての記述はIP Prefix、IPL、GW IPを対応するIPv6の値に置換すればIPv6でも同様のケースで有効です。
4.1 TS IPアドレスOverlay Indexのユースケース
図5は仮想アプライアンス(TS2とTS3の背後に存在するサブネットに対する)サブネット間転送の例を描いています。
IP4---+ NVE2 DGW1
| +-----------+ +---------+ +-------------+
SN2---TS2(VA)--| (BD-10) |-| |----| (BD-10) |
| IP2/M2 +-----------+ | | | IRB1\ |
-+---+ | | | (IP-VRF)|---+
| | | +-------------+ _|_
SN1 | VXLAN/ | ( )
| | GENEVE | DGW2 ( WAN )
-+---+ NVE3 | | +-------------+ (___)
| IP3/M3 +-----------+ | |----| (BD-10) | |
SN3---TS3(VA)--| (BD-10) |-| | | IRB2\ | |
| +-----------+ +---------+ | (IP-VRF)|---+
IP5---+ +-------------+
24ビットのIPプレフィックスを使用するサブネットSN1(以降SN1/24と記します)とWANに存在するサブネットの間のサブネット間転送の例を以下に記します。NVE2、NVE3、DGW1、DGW2はBGP EVPNを動作させています。TS2とTS3はダイナミックルーティングプロトコルに参加しておらず、WANにトラフィックを転送するためにスタティックルートだけを使用しています。SN1/24はNVE2とNVE3にデュアルホームしています。
このケースにおいてGW IPがOverlay Indexとして使用されます。異なるOverlay Indexタイプを使用することも可能でしょうが、このユースケースでは運用者がVAのIPアドレスを予め知っていて、VAのMACアドレスが分かっておらず、VAのESIがゼロであることを仮定します。この場合はGW IPがRT-5で使用するOverlay Indexとして適切です。NVEはポリシーによって与えられたプレフィックスのために使用されるGW IPを知っています。
(1) NVE2が次のBGP経路をTS2に変わって広告します
経路タイプ2(MAC/IP経路)を: ML=48 (MAC Address Length)、M=M2 (MAC Address)、IPL=32 (IP Prefix Length)、IP=IP2、対応するトンネルタイプのRFC5512のBGP Encapsulation拡張コミュニティ。MACアドレスとIPアドレスはARPスヌーピングで学習することができます。
経路タイプ5(IP Prefix経路)を: IPL=24、IP=SN1、ESI=0、GW IPアドレス=IP2。プレフィックスとGW IPはポリシーによって学習されます。
(2)同様にNVE3が次のBGP経路をTS3に変わって広告します
経路タイプ2(MAC/IP経路)を: ML=48、M=M3、IPL=32、IP=IP2(とBGP Encapuslation拡張コミュニティ)
経路タイプ5(IP Prefix経路)を: IPL=24、IP=SN1、ESI=0、GW IPアドレス=IP3
(3) DGW1とDGW2は両方の受信した経路をRoute Targetに基づいてインポートします:
DGW1とDGW2においてBD-10のRoute Targetに基づいて、上記のMAC/IP経路がインポートされ、M2がBD-10に対応するトンネル情報とともに追加されます。たとえばVXLANが使用されている場合、VTEPがMAC/IP経路のBGPネクストホップから得られ、VNIがMPLS Label 1フィールドから得られます。IP2 - M2がARPテーブルに追加されます。同様にM2がBD-10に追加され、IP3-M3がARPテーブルに追加されます。
DGW1とDGW2においてBD-10のRoute Targetに基づいて、上記のIP Prefix経路がインポートされ、SN1/24がローカルのBD-10を指し示すOverlay Index IP2とともにIP VRFに追加されます。この例ではNVE4からのRT-5よりもNVE2からのRT-5の方が優先されることを仮定します。もし両方の毛色が同等の優先度でECMPが有効であれば、SN1/24はOverlay Index IP3でもルーティングテーブルに追加されます。
(4) DGW1がWANからSN1/24に属するIPx宛のパケットを受け取ったとき:
DGW1のIP-VRFのルーティングテーブルで宛先IPルックアップが実行され、Overlay Index = IP2が発見されます。IP2はOverlay Indexであるため、再帰的な経路解決がIP2に必要になります。
IP2はARPテーブルにおいてM2に解決がされ、M2はBD FIBによって与えられるトンネル情報(たとえばVXLANの場合はリモートVTEPとVNI)に解決されます。
IPx宛のIPパケットは次のようにカプセル化されます
(5) このパケットがNVE2に到着したとき:
(6) NVE2からNVE3にTS2が動くとき、RFC7432に定義されているようにMACモビリティの手順がMAC経路IP2/M2に適用されます。経路タイプ5のプレフィックスはMACモビリティの手順には従いません。そのためDGW IP-VRFのルーティングテーブルにおいてはTS2のモビリティに対して何の変更も発生しません。つまり全てのプレフィックスはOverlay IndexとしてIP2を指したままになるでしょう。、Overlay IndexのIP2をルーティングテーブルで指し続けているたとえばSN1/24について、遠回しになりますが、IP2/M2のMAC/IP経路に対するMACモビリティ手順の結果としてIP2はシンプルに別のトンネルに解決されるでしょう。
反対方向についてはTS2はトラフィックをそのスタティックルートのネクストホップの情報(IRB1と/またはIRB2)に基づいて転送され、通常のEVPNの手順が適用されるでしょう。
4.2 Floating IPのOverlay Indexのユースケース
テナントシステム(TS)はActive/Standbyモードで動作して、ActiveなTSによって所有される上流のFloating IPがその背後にあるサブネットに到達するためのOverlay Indexとして使用されることがあります。この冗長モードは2.1節と2.2節ですでに紹介していますが図6に描いています。
NVE2 DGW1
+-----------+ +---------+ +-------------+
+---TS2(VA)--| (BD-10) |-| |----| (BD-10) |
| IP2/M2 +-----------+ | | | IRB1\ |
| <-+ | | | (IP-VRF)|---+
| | | | +-------------+ _|_
SN1 vIP23 (floating) | VXLAN/ | ( )
| | | GENEVE | DGW2 ( WAN )
| <-+ NVE3 | | +-------------+ (___)
| IP3/M3 +-----------+ | |----| (BD-10) | |
+---TS3(VA)--| (BD-10) |-| | | IRB2\ | |
+-----------+ +---------+ | (IP-VRF)|---+
+-------------+
図6 冗長なTSのためのFloating IP Overlay Index
このユースケースでは4.1と同じ理由でGW IPがOverlay Indexとして使用されます。しかしこのGW IPはFloating IPでありActive TSに所属するものです。TS2がActiveなTSで、vIP23を所有していると仮定します。
(1) NVE2がTS2のBGP経路を次のように広告します:
経路タイプ2(MAC/IP経路)を: ML=48、M=M2、IPL=32、IP=vIP23(とBGP Encapuslation拡張コミュニティ)。MACアドレスとIPアドレスはARPスヌーピングによって学習することができます。
経路タイプ5(IP Prefix経路)を: IPL=24、IP=SN1、ESI=0、GW IPアドレス=vIP23。プレフィックスとGW IPはポリシーによって学習されます。
(2) NVE3はTS3のBGP経路を次のように広告します(vIP23/M3のRT-2を広告しません)
(3) DGW1とDGW2は両方の受信した経路をRoute Targetに基づいてインポートします:
M2がBD-10のFIBに対応するトンネル情報とともに追加されます。VXLANのユースケースではVTEPはMAC/IP経路のBGPネクストホップから得られ、VNIはVNIフィールドから得られます。vIP23 - M2がARPテーブルに追加されます。
SN1/24がDGW1とDGW2のIP-VRFに追加され、Overlay IndexのvIP23がローカルのBD-10のM2を指し示します。
(4) DGW1がWANからSN1/24に属するIPx宛のパケットを受け取ったとき:
DGW1のIP-VRFのルーティングテーブルで宛先IPルックアップが実行され、Overlay Index = vIP23が発見されます。vIP23はOverlay Indexであるため、再帰的な経路解決がvIP23に必要になります。
vIP23はARPテーブルにおいてM2に解決がされ、M2はBD FIBによって与えられるトンネル情報(たとえばVXLANの場合はリモートVTEPとVNI)に解決されます。
IPx宛のIPパケットは次のようにカプセル化されます
(5) このパケットがNVE2に到着したとき
(6) TS2とTS3の間で動作している冗長プロトコルがSN1のActiveなTSをTS3としたとき、TS3がFloatingのvIP23を所有することになり、Gratutious ARP REPLYメッセージ(RFC5227で説明されています)や類似のメッセージで新しい所有権を伝えます。この新しい所有者の通知を受け取って、NVE3はM3-vIP23の経路タイプを発行し、NVE2はM2-vIP23のRT-2をwithdrawするでしょう。DGW1とDGW2はこのFloating IPを解決して新しいMACでARPテーブルを更新するでしょう。
4.3 Bunp-in-the-Wireのユースケース
図7はサブネットSN1を運ぶIP Prefix経路についてのサブネット間転送の例を描いています。このユースケースではTS2とTS3はレイヤー2のVA機器で、IP Prefix経路のGW IPフィールドにOverlay Indexとして含めることができるIPアドレスを持っていません。これらのMACアドレスはそれぞれM2とM3であり、BD-10に接続されています。(それぞれDGW1とDGW2にある)IRB1とIRB2はSN1とは異なるサブネットのIPアドレスをもっていることに留意してください。
NVE2 DGW1
M2 +-----------+ +---------+ +-------------+
+---TS2(VA)--| (BD-10) |-| |----| (BD-10) |
| ESI23 +-----------+ | | | IRB1\ |
| + | | | (IP-VRF)|---+
| | | | +-------------+ _|_
SN1 | | VXLAN/ | ( )
| | | GENEVE | DGW2 ( WAN )
| + NVE3 | | +-------------+ (___)
| ESI23 +-----------+ | |----| (BD-10) | |
+---TS3(VA)--| (BD-10) |-| | | IRB2\ | |
M3 +-----------+ +---------+ | (IP-VRF)|---+
+-------------+
TS2とTS3のいずれもダイナミックルーティングプロトコルに参加することができず、IPアドレスも割り当てられていないため、SN1を広告するときに使用できるOerlay Indexタイプとして2つの可能性があります:
ESI。つまりESI23。図7で示されているようにNVE2とNVE3のポートの接続ポートに作成することができるものです。
Overlay IndexとしてVAのMACアドレスを使用することに比べてESIを使うことの有利な点は、Egress NVEへの転送が(Ethernet A-D per EVI経路で通知される)ESにあるACの状態だけに基づいて行われることと、全てのEVPNマルチホーミング冗長化の仕組みを再利用することができることです。たとえばRFC7432の高速な障害検知と通知のためのMass Withdrawal機構などを使うことができます。この節ではESI Overlay Indexが使用されることを仮定しますが、VAのMACアドレスをOverlay Indexとして使用することを阻止するものではありません。もしMACがOverlay Indexとして使用される場合、4.4.3節に記述される手順にコントロールプレーンは従わなければなりません。
このモデルはVAの冗長性を4.2節のFloating IPのOverlay Indexのユースケースで説明したものと似たような方法でサポートします。ただしOverlay Indexの場所を広告するためにMAC Advertisement経路の代わりにEVPN Ethernet A-D per EVI経路を使用する点が異なります。この手順の説明は以下のとおりです:
(1) TS2がESI23でActiveなTSだと仮定すると、NVE2が次のBGP経路を広告します:
経路タイプ1(BD-10のEthernet A-D経路)を: ESI=ESI23、対応するトンネル情報(VNIフィールド)、(RFC8365に従って)BGP Encapsulation拡張コミュニティ
経路タイプ5(IP Prefix経路)を: IPL=24、IP=SN1、ESI=ESI23、GW IPアドレス=0。[EVPN-INTERSUBNET]で定義されるRouter's MAC拡張コミュニティが追加されて、SN1の背後にあるTSに関連付けられるMACアドレス(M2)を伝えます。M2はポリシーによって学習することができますが、拡張コミュニティ内のMACが経路とともに送信されるのであればそちらが好ましいです。
(2) NVE3は次のBGP経路をTS3のために広告します(AD per-EVI経路は広告されません):
- 経路タイプ5(IP Prefix経路)を: IPL=24、IP=SN1、ESI=ESI23、GW IPアドレス=0。Router's MAC拡張コミュニティが追加されて、SN1の背後にあるTSに関連付けられるMACアドレス(M3)を伝えます。M3はポリシーによって学習することができますが、拡張コミュニティ内のMACが経路とともに送信されるのであればそちらが好ましいです。
(3) DGW1とDGW2は両方の受信した経路をRoute Targetに基づいてインポートします:
ESI23に到達するためのトンネル情報がDGW1とDGW2にインストールされます。VXLANのユースケースではVTEPはEthernet A-D経路のBGPネクストホップで得られ、VNIはVNI/VSIDフィールド(RFC8365を参照してください)から得られます。
RT-1を広告するNVEから送信されたRT-5が選択され、SN1/24がDGW1とDGW2のIP-VRFにOverlay Index ESI23とMAC = M2でインストールされます。
(4) DGW1がWANからSN1/24に属するIPx宛のパケットを受け取ったとき:
DGW1のIP-VRFのルーティングテーブルで宛先IPルックアップが実行され、Overlay Index = ESI23が発見されます。ESI23はOverlay Indexであるため、再帰的な経路解決を行ってESI23が存在するEgress NVEを発見することが必要になります。
IPx宛のIPパケットは次のようにカプセル化されます
(5) パケットがNVE2に到着したとき:
トンネル解除の情報(VXLANの場合はVNI)に基づいて、
トンネル情報(VXLANの場合はVNI)に基づいてBD-10のコンテキストがMACルックアップ(Egress NVEにおいてMACベースの配送を仮定します)のために特定されるか、またはVNIによって直接Egressインターフェイスが特定されます(MPLSベースの配送モデル、この文脈ではVNIベースの配送モデル)。
カプセル化が取り除かれ、MACルックアップ(Egress NVEにおいてMAC転送を仮定します)、またはVNIルックアップ(VNI転送の場合)に基づいて、パケットはTS2に転送され、SN1に転送されます。
(6) もしTS2とTS3の間でActive-Standbyモデルの冗長プロトコルが動作していて、障害が発生し、TS3がSN1のActiveなTSとなったとき、TS3はSN1への接続性を持ち、新しい所有権を伝えるでしょう。この新しい所有者の通知を受け取って、NVE3のACはアクティブになり、ESI23のための経路タイプ1を発行するでしょう。一方でNVE2はESI23のEthernet A-D経路をwithdrawするでしょう。DGW1とDGW2はESI23を解決するためのトンネル情報を更新するでしょう。内側の宛先MACはM3に変わるでしょう。
4.4 IP-VRF-to-IP-VRFモデル
このユースケースは[EVPN-INTERSUBNET]の「テナントシステムのためのNVE上でのIRB転送」で記述したシナリオに似ています。しかしここでの新しい要件はホスト経路だけを広告するのと異なり、IP Prefixを広告することです。
4.1、4.2、4.3節で記載した例においてはBDインスタンスはIRBインターフェイスやそこに接続している他のいずれのテナントシステムとも接続可能でした。EVPNが接続性を提供するのは:
(1)に対して接続性を提供するためには、IRBまたはTSのMACやIPが配布されることができるようにMAC/IP経路(RT-2)が必要です。接続タイプ(2)は、GW IPやESIやTS MACなどの特定のOverlay Indexの背後にあるIPとサブネットのIP Prefix経路(RT-5)の交換によって達成されます。
いくつかのケースではIP Prefix経路はIRBの背後にあるサブネットやIPのために広告されることがあります。このユースケースをIP-VRF-to-IP-VRFモデルと呼びます。
[EVPN-INTERSUBNET]では、Ingress NVEとEgress NVEにおいて必要なルックアップに基づいて、非対称IRBモデルと対称IRBモデルを定義しています。非対称モデルではIPルックアップとMACルックアップがIngress NVEで求められるのに対し、Egress NVEではMACルックアップだけが求められます。対称モデルではIngress NVEとEgress NVEの療法でIPルックアップとMACルックアップの療法が必要になります。この観点からこの節で記述されるIP-VRF-to-IP-VRFユースケースは対称IRBモデルです。
IP-VRF-to-IP-VRFのシナリオ位において、1つのテナントが所有するたくさんのサブネットとはことなり、数個のサブネットだけが与えられたNVE/PEのIP-VRFに接続されることに留意してください。テナントが接続されている一連のNVE/PEの間でサブネット間の接続性を提供するために、もし再帰的解決が必要であれば新しいSDBが全てのNVE/PEk上に作成されます。このSBDは、それぞれのNVE/PEの内部で(ACのない)正規のBDとしてインスタンス化されます。そしてIRBインターフェイスによってSBDはIP-VRFに接続されます。このIRBインターフェイスのIPアドレスまたはMACアドレスは再帰的解決のためのOverlay Indexとしてしようされます。
SBDとそのIP-VRFに対するIRBインターフェイスの存在と特徴に基づいて、3つの異なるIP-VRF-to-IP-VRFのシナリオが存在し、この文書で記述します。
1) インターフェイスレスモデル: SBDもOverlay Indexも必要としない 2) SBD IRBモデルのインターフェイスフルモデル: SDBに加えてGW IPアドレスがOverlay Indexとして必要 3) Unnumbered SBD IRBのインターフェイスフルモデル: SBDに加えてMACアドレスがOverlay Indexとして必要
4.4.1 インターフェイスレスIP-VRF-to-IP-VRFモデル
図8がこのモデルの説明に使用できるでしょう。
NVE1(M1)
+------------+
IP1+----| (BD-1) | DGW1(M3)
| \ | +---------+ +--------+
| (IP-VRF)|----| |-|(IP-VRF)|----+
| / | | | +--------+ |
+---| (BD-2) | | | _+_
| +------------+ | | ( )
SN1| | VXLAN/ | ( WAN )--H1
| NVE2(M2) | GENEVE/| (___)
| +------------+ | MPLS | +
+---| (BD-2) | | | DGW2(M4) |
| \ | | | +--------+ |
| (IP-VRF)|----| |-|(IP-VRF)|----+
| / | +---------+ +--------+
SN2+----| (BD-3) |
+------------+
図8 インターフェイスレスIP-VRF-to-IP-VRFモデル
このケースでは:
a) NVEとDGWはSN1、SN2、IP1にあるホストとWANの反対側にあるホスト、例えばH1の間での接続性を提供しなければなりません。DGWはIPと/またはVPN-IP経路をWANから/へインポート/エクスポートすると仮定します。
b) NVE/DGWのIP-VRFインスタンス間は直接NVOトンネルを経由して接続され、IP-VRF同士を接続するためにIRBやBDインスタンスがインスタンス化されることはありません。
c) ソリューションはIP-VRF間のレイヤー3接続性を、たとえばVXLANやGENEVEなどのイーサネットNVOトンネルのために提供しなければなりません。
d) ソリューションはIP-VRF間のレイヤー3接続性を、たとえば(IPペイロードの)GENEVEなどのIP NVOトンネルのために提供することがあります。
上記の要件を満たすために、広告側のNVE/DGWがEthernet NVOトンネルを使用する場合は、[EVPN-INTERSUBNET]で定義されている通り、IP PrefixをRouter's MAC拡張コミュニティを伴って広告するために、EVPN経路タイプ5が使用されます。それぞれのNVE/DGWはRT-5をそれぞれのプレフィックスに対して次のフィールドを設定して広告するでしょう:
Ethernet Tag ID = 0
IP Prefix LengthとIPアドレスは前節で説明したとおり
GW IPアドレス = 0
ESI = 0
MPLSラベルまたはVNIはIP-VRFに対応するもの
それぞれのRT-5はテナント(IP-VRF)を識別するRouter Targetとともに送信されるでしょう。そして次の2つのBGP拡張コミュニティ:
最初の一つはBGP Encapsulation拡張コミュニティで、RFC5512の通りトンネルタイプを識別します
二つ目はRouter's MAC拡張コミュニティで[EVPN-INTERSUBNET]の通り経路を広告するNVEに関連付けられたMACアドレスを含んでいます。このMACアドレスはNVE/DGWを識別し、NVEのすべてのIP-VRFにおいて再利用されることがあります(MAY)。もし経路がVXLANなどのEthernet NVOトンネルと関連付けられる場合、Router's MAC拡張コミュニティが送信されなければなりません。もし毛色がIPペイロードのGENEVEなどのIP NVOトンネルと関連付けられる場合、Router's MAC拡張コミュニティは送信されるべきではありません。
次の例では広告してパケットをSN1/24(NVE1から広告されるIPv4プレフィックス)手順を記述しています:
(1) NVE1は次のBGP経路を広告します:
経路タイプ5(IP Prefix経路)を
- IPL=24、IP=SN1、Label=10
- GW IP=0に設定する
- RFC5512のBGP Encapsulation拡張コミュニティ
- M1を含むRouter's MAC拡張コミュニティ
- テナント(IP-VRF)を識別するRoute Target
(2) DGW1はNVE1から受信した経路をインポートします:
DGW1はSN1/24をRT-5のRoute Targetで識別されたIP-VRFにインストールします
GW IP = ESI = 0、Labelが0でない値、ローカルポリシーがインターフェイスレスモデルであるため、DGW1はこのLabelとRT-5のネクス値ホップを使用するでしょう。またRouter's MAC拡張コミュニティで(内側の宛先MACアドレスとして)伝達されたMACアドレスを使用して転送状態を設定しルーティングされたIPパケットをカプセル化します。
(3) DGW1がWANからSN1/24に属するIPx宛のパケットを受け取ったとき:
宛先IPのルックアップがDGW1のIP-VRFルーティングテーブルで実行されます。このルックアップでSN1/24が導かれます。
SN1/24のRT-5ではGW IP = ESI = 0、ゼロでないLabelとネクストホップ、モデルがインターフェイスレスであるため、DGW1は経路を解決するために再帰的なルックアップを行わないでしょう。
IPx宛のIPパケットは次のようにカプセル化されます: 内側の送信元MAC = DGW1 MAC、内側の宛先MAC = M1、外側の送信元IP(トンネル送信元IP) = DGW1 IP、外側の宛先IP(トンネル宛先IP) = NVE1 IP。内側の送信元・宛先MACアドレスはIP NVOトンネルが使用される場合は必要ありません。
(4) このパケットがNVE1に到着したとき:
NVE1はLabelに基づいてIPルックアップのためのIP-VRFを識別するでしょう(内側の宛先MACはIP-VRFを識別するために必要ありません)。
このルーティングコンテキストでIPルックアップが実行され、SN1がBD-2に関連付けられたローカルサブネットであることが分かります。ARPテーブルとBD FIBでの次のルックアップによち、BD-2でのパケットの転送情報が得られます。
上記のモデルはインターフェイスレスモデル(Interface-less model)と呼ばれます。IP-VRFがトンネルを経由して直接され、4.4.2節や4.4.3節のようにこれらのトンネルがSBDで終端される必要がないからです。
4.4.2 SBD IRBのインターフェイスフルIP-VRF-to-IP-VRF
図9はこのモデルの説明に使用することができます。
NVE1
+------------+ DGW1
IP10+---+(BD-1) | +---------------+ +------------+
| \ | | | | |
|(IP-VRF)-(SBD)| |(SBD)-(IP-VRF)|-----+
| / IRB(IP1/M1) IRB(IP3/M3) | |
+---+(BD-2) | | | +------------+ _+_
| +------------+ | | ( )
SN1| | VXLAN/ | ( WAN )--H1
| NVE2 | GENEVE/ | (___)
| +------------+ | MPLS | DGW2 +
+---+(BD-2) | | | +------------+ |
| \ | | | | | |
|(IP-VRF)-(SBD)| |(SBD)-(IP-VRF)|-----+
| / IRB(IP2/M2) IRB(IP4/M4) |
SN2+----+(BD-3) | +---------------+ +------------+
+------------+
このモデルにおいて:
a) 4.4.1節のように、NVEとDGWは、SN1、SN2、IP10とWANの反対側に存在するホストの間で接続性を提供しなければなりません。
b) しかし今回NVE/DGWはSBDインスタンスで終端されるEthernet NVOトンネルで接続されています。IP-VRFはSBDへの接続性のためにIRBインターフェイスを使用します。
c) それぞれのSBD IRBはIPアドレスとMACアドレスを持ち、IPアドレスは他のNVEやDGWから到達可能でなければなりません。
d) テナントドメインBDにおいてSBDは全てのNVE/DGWに接続されていなければなりません。
e) ソリューションはレイヤー3接続性をVXLANや(Ethernetペイロードの)GENEVEなどのEthernet NVOトンネルのために提供しなければなりません。
EVPNタイプ5の経路がIP Prefixを広告するために使用され、EVPN RT-2経路がそれぞれのSBD IRBインターフェイスのMAC/IPアドレスを広告するでしょう。それぞれのNVE/DGWは次のフィールドでそれぞれのプレフィックスのためのRT-5を広告するでしょう:
RDをRFC7432の通り
Etherent Tag ID = 0
IP Prefix LengthとIPアドレスを以前の節で説明したとおり
ESI = 0
Labelの値はゼロであるべきです。なぜならRT-5経路はRT-2経路への再帰的なルックアップ解決が必要だからです。受信時には無視されます。パケットを転送するときはRT-2のMPLS Label1フィールドから得たMPLSラベルまたはVNIが使用されます。
それぞれのRT-5はテナント(IP-VRF)を識別するRoute Targetとともに送信されます。Router's MAC拡張コミュニティはこの場合送信するべきではありません。
次の例では広告してパケットをSN1/24(NVE1から広告されるIPv4プレフィックス)手順を記述しています:
(1) NVE1は次のBGP経路を広告します:
経路タイプ5(IP Prefix経路)を:
- IPL=24、IP=SN1、Label=0に設定するべきです(SHOULD)
- GW IP=IP1 (SBD IRBのIP)
- テナント(IP-VRF)を識別するRoute Target
-
- ML-48、M=M1、IPL=32、IP=IP1、Label=10
- RFC5512のBGP Encapsulation拡張コミュニティ
- SBDを識別するRoute Target。このRoute TargetはRT-5と同じものが使われることがあります。
(2) DGW1はNVE1から受信した経路をインポートします:
DGW1はSN1/24をRT-5のRoute Targetで識別されたIP-VRFにインストールします
- GW IPがゼロでないため、GE IP(IP1)がIP1を伝達するRT-2に再帰的な経路解決をするためのOverlay Indexとして使用されるでしょう。
(3) DGW1がWANからSN1/24に属するIPx宛のパケットを受け取ったとき:
宛先IPのルックアップがDGW1のIP-VRFルーティングテーブルで実行されます。このルックアップでOverlay Index IP1に関連付けられたSN1/24が導かれます。転送情報はIP1のために受信されたRT-2から得られます。
IPx宛のIPパケットが次のようにカプセル化されます。内側の送信元MAC = M3、内側の宛先MAC = M1、外側の送信元IP(送信元VTEP) = DGW1 IP、外側の宛先IP(宛先VTEP) = IP1
(4) このパケットがNVE1に到着したとき:
NVE1はLabelと内側の宛先MACアドレスに基づいてIPルックアップのためのIP-VRFを識別するでしょう。
このルーティングコンテキストでIPルックアップが実行され、SN1がBD-2に関連付けられたローカルサブネットであることが分かります。ARPテーブルとBD FIBでの次のルックアップによち、BD-2でのパケットの転送情報が得られます。
上記のモデルは「SBD IRBのインターフェイスフルモデル(Interface-ful with SBD IRB model)」と呼ばれます。DGWとNVEを接続するトンネルがSBDに終端される必要があるからです。SBDはSBD IRBインターフェイスを通じてIP-VRFに接続され、RT-5をGW IPアドレスに再帰的に解決することが可能になります。
4.4.3 Unnumbered SBD IRBのインターフェイスフルIP-VRF-to-IP-VRF
図10はこのモデルの説明に使用することができます。このモデルは4.4.2節に記述したモデルと似ていますが、SBD IRBインターフェイスにIPアドエスが無い点が異なることに留意してください。
NVE1
+------------+ DGW1
IP1+----+(BD-1) | +---------------+ +------------+
| \ | | | | |
|(IP-VRF)-(SBD)| (SBD)-(IP-VRF) |-----+
| / IRB(M1)| | IRB(M3) | |
+---+(BD-2) | | | +------------+ _+_
| +------------+ | | ( )
SN1| | VXLAN/ | ( WAN )--H1
| NVE2 | GENEVE/ | (___)
| +------------+ | MPLS | DGW2 +
+---+(BD-2) | | | +------------+ |
| \ | | | | | |
|(IP-VRF)-(SBD)| (SBD)-(IP-VRF) |-----+
| / IRB(M2)| | IRB(M4) |
SN2+----+(BD-3) | +---------------+ +------------+
+------------+
図10 Unnumbered SBD IRBのインターフェイスフルモデル
このモデルにおいて:
a) 4.4.1節や4.4.2節のように、NVEとDGWは、SN1、SN2、IP10とWANの反対側に存在するホストの間で接続性を提供しなければなりません。
b) 4.4.2節のように、NVE/DGWはSBDインスタンスで終端されるEthernet NVOトンネルで接続されています。IP-VRFはSBDへの接続性のためにIRBインターフェイスを使用します。
c) しかしそれぞれのSBD IRBはMACアドレスだけを持ち、IPアドレスを持ちません(このためこのモデルが「Unnumbered」SBD IRBと言われています)このモデルではSBD IRBインターフェイス自身へのIP到達性をもつ必要がなく、使用されるIPアドレスの数の制約についての要件があります。
d) 4.4.2節のように、SBDはサブネット間転送を必要とするテナントの全てのNVE/DGW BDから構成されます。
e) 4.4.2節のように、ソリューションはレイヤー3接続性をVXLANや(Ethernetペイロードの)GENEVEなどのEthernet NVOトンネルのために提供しなければなりません。
このモデルはRT-5の再帰的解決を活用するでしょう。EVPNタイプ5の経路が再帰的ルックアップに使用されるRouter's MAC拡張コミュニティとともにIP Prefixを広告します。EVPN RT-2経路がそれぞれのSBD IRBインターフェイスのMACアドレスを(今回はIPなしで)広告するでしょう。
それぞれのNVE/DGWはそれぞれのプレフィックスごとに4.4.2節に記述されたものと以下を除いて同じフィールドでRT-5を広告します:
- GW IPアドレス = 0に設定する
それぞれのRT-5はテナント(IP-VRF)を識別するRoute TargetとSBD IRBインターフェイスに関連付けられたMACアドレスを含むRouter's MAC拡張コミュニティとともに送信されるでしょう。このMACアドレスはNVEの全てのIP-VRFに対して再利用されることがあります。
この例は4.4.2節のものと類似しています:
(1) NVE1は次のBGP経路を広告します:
経路タイプ5(IP Prefix経路)を以下を除いて4.4.2節と同じように:
経路タイプ2(SBD IRBのMAC/IP経路)を以下を除いて4.4.2節と同じように:
- ML-48、M=M1、IPL=0、Label=10
(2) DGW1はNVE1から受信した経路をインポートします:
DGW1はSN1/24をRT-5のRoute Targetで識別されたIP-VRFにインストールします
(3) DGW1がWANからSN1/24に属するIPx宛のパケットを受け取ったとき:
宛先IPのルックアップがDGW1のIP-VRFルーティングテーブルで実行されます。このルックアップでOverlay Index M1に関連付けられたSN1/24が導かれます。転送情報はM1のために受信されたRT-2から得られます。
IPx宛のIPパケットが次のようにカプセル化されます。内側の送信元MAC = M3、内側の宛先MAC = M1、外側の送信元IP(送信元VTEP) = DGW1 IP、外側の宛先IP(宛先VTEP) = NVE1 IP
(4) このパケットがNVE1に到着したとき:
NVE1はLabelと内側の宛先MACアドレスに基づいてIPルックアップのためのIP-VRFを識別するでしょう。
このルーティングコンテキストでIPルックアップが実行され、SN1がBD-2に関連付けられたローカルサブネットであることが分かります。ARPテーブルとBD FIBでの次のルックアップによち、BD-2でのパケットの転送情報が得られます。
上記のモデルは(4.4.2節のように)Unnumbered SBD IRBのインターフェイスフルモデル(Interface-ful with unnumbered SBD IRB model)と呼ばれ、今回はSBD IRBがIPアドレスを持っていないだけです。
5. セキュリティに関する考察
この文書では同じテナント(またはVPN)に所属するブリッジドメインのグループに接続されたNVEやPEの間のサブネット間転送を実現するための一連の手順を提供しています。RFC7432で議論されたセキュリティに関する考察はサブネット間転送やこれらのBDの内部での通信に適用できます。加えて、RFC4364におけるセキュリティに関する考察についても理解されておくべきです。なぜならこの文書とRFC4364は類似したアプリケーションで使用されることがあるからです。
RFC4374とは逆に、この文書ではPE/CE経路配布のテクニックについて記述しておらず、むしろCEをダイナミックルーティングプロトコルを動作させないTSやVAとして考えています。これはセキュリティで優位であると考えることができます。なぜならダイナミックルーティングプロトコルをNVE/PEのACでブロックすることができ、テナントをインフラストラクチャのダイナミックルーティングプロトコルと相互作用させないようにすることができるからです。
この文書では、RT5-を通常のBGP Next Hopをその解決や異なるEVPN経路(RT-2またはRT-1)に再帰的に解決することが必要なOverlay Indexのために使用することがあります。後者のケースにおいて、Overlay Indexを伝達するにあたって使用されるRT-2/RT-1経路をフィルタリングしたり修正することになるような行為はいずれも、RT-5の解決、そしてリモートサブネットへのパケットの転送を修正するであろうことを述べておく価値があるでしょう。
6. IANAに関する考察
この文書ではRFC7432で定義された [EVPNRouteTypes] レジストリに値5を要求します。
Value Description Reference 5 IP Prefix route [this document]
