[要約] 要約：RFC 6820は、大規模データセンターネットワークにおけるアドレス解決の問題についてのガイドラインを提供しています。 目的：このRFCの目的は、大規模データセンターネットワークでのアドレス解決の問題を理解し、解決策を提案することです。
Internet Engineering Task Force (IETF) T. Narten
Request for Comments: 6820 IBM Corporation
Category: Informational M. Karir
ISSN: 2070-1721 Merit Network Inc.
I. Foo
Huawei Technologies
January 2013
Address Resolution Problems in Large Data Center Networks
大規模なデータセンターネットワークにおけるアドレス解決の問題
Abstract
概要
This document examines address resolution issues related to the scaling of data centers with a very large number of hosts. The scope of this document is relatively narrow, focusing on address resolution (the Address Resolution Protocol (ARP) in IPv4 and Neighbor Discovery (ND) in IPv6) within a data center.
このドキュメントでは、非常に多数のホストを持つデータセンターのスケーリングに関連するアドレス解決の問題を調べます。このドキュメントの範囲は比較的狭く、データセンター内のアドレス解決（IPv4のアドレス解決プロトコル（ARP）およびIPv6の近隣探索（ND））に焦点を当てています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6820.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6820で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Background ......................................................4
4. Address Resolution in IPv4 ......................................6
5. Address Resolution in IPv6 ......................................7
6. Generalized Data Center Design ..................................7
6.1. Access Layer ...............................................8
6.2. Aggregation Layer ..........................................8
6.3. Core .......................................................9
6.4. L3/L2 Topological Variations ...............................9
6.4.1. L3 to Access Switches ...............................9
6.4.2. L3 to Aggregation Switches ..........................9
6.4.3. L3 in the Core Only ................................10
6.4.4. Overlays ...........................................10
6.5. Factors That Affect Data Center Design ....................11
6.5.1. Traffic Patterns ...................................11
6.5.2. Virtualization .....................................11
6.5.3. Summary ............................................12
7. Problem Itemization ............................................12
7.1. ARP Processing on Routers .................................12
7.2. IPv6 Neighbor Discovery ...................................14
7.3. MAC Address Table Size Limitations in Switches ............15
8. Summary ........................................................15
9. Acknowledgments ................................................16
10. Security Considerations .......................................16
11. Informative References ........................................16
This document examines issues related to the scaling of large data centers. Specifically, this document focuses on address resolution (ARP in IPv4 and Neighbor Discovery in IPv6) within the data center. Although strictly speaking the scope of address resolution is confined to a single L2 broadcast domain (i.e., ARP runs at the L2 layer below IP), the issue is complicated by routers having many interfaces on which address resolution must be performed or with the presence of IEEE 802.1Q domains, where individual VLANs effectively form their own L2 broadcast domains. Thus, the scope of address resolution spans both the L2 link and the devices attached to those links.
このドキュメントでは、大規模なデータセンターのスケーリングに関連する問題について説明します。具体的には、このドキュメントでは、データセンター内のアドレス解決（IPv4のARPおよびIPv6の近隣探索）に焦点を当てています。厳密に言えば、アドレス解決の範囲は単一のL2ブロードキャストドメインに限定されます（つまり、ARPはIPの下のL2レイヤーで実行されます）、アドレス解決を実行する必要がある多くのインターフェイスを持つルーター、またはIEEE 802.1Qドメイン。個々のVLANが独自のL2ブロードキャストドメインを効果的に形成します。したがって、アドレス解決の範囲は、L2リンクとそれらのリンクに接続されたデバイスの両方に及びます。
This document identifies potential issues associated with address resolution in data centers with a large number of hosts. The scope of this document is intentionally relatively narrow, as it mirrors the Address Resolution for Massive numbers of hosts in the Data center (ARMD) WG charter. This document lists "pain points" that are being experienced in current data centers. The goal of this document is to focus on address resolution issues and not other broader issues that might arise in data centers.
このドキュメントでは、多数のホストを持つデータセンターでのアドレス解決に関連する潜在的な問題を特定します。このドキュメントの範囲は、データセンター（ARMD）WG憲章における大量のホストのアドレス解決を反映しているため、意図的に比較的狭くなっています。このドキュメントには、現在のデータセンターで経験されている「問題点」がリストされています。このドキュメントの目的は、アドレス解決の問題に焦点を当てることであり、データセンターで発生する可能性のある他のより広範な問題には焦点を当てていません。
Address Resolution: The process of determining the link-layer address corresponding to a given IP address. In IPv4, address resolution is performed by ARP [RFC0826]; in IPv6, it is provided by Neighbor Discovery (ND) [RFC4861].
アドレス解決：特定のIPアドレスに対応するリンク層アドレスを決定するプロセス。 IPv4では、アドレス解決はARP [RFC0826]によって実行されます。 IPv6では、近隣探索（ND）[RFC4861]によって提供されます。
Application: Software that runs on either a physical or virtual machine, providing a service (e.g., web server, database server, etc.).
アプリケーション：物理マシンまたは仮想マシンで実行され、サービスを提供するソフトウェア（例：Webサーバー、データベースサーバーなど）。
L2 Broadcast Domain: The set of all links, repeaters, and switches that are traversed to reach all nodes that are members of a given L2 broadcast domain. In IEEE 802.1Q networks, a broadcast domain corresponds to a single VLAN.
L2ブロードキャストドメイン：特定のL2ブロードキャストドメインのメンバーであるすべてのノードに到達するために通過するすべてのリンク、リピーター、およびスイッチのセット。 IEEE 802.1Qネットワークでは、ブロードキャストドメインは単一のVLANに対応します。
Host (or server): A computer system on the network.
ホスト（またはサーバー）：ネットワーク上のコンピューターシステム。
Hypervisor: Software running on a host that allows multiple VMs to run on the same host.
ハイパーバイザー：同じホスト上で複数のVMを実行できるようにする、ホスト上で実行されるソフトウェア。
Virtual Machine (VM): A software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Applications (generally) do not know they are running on a VM as opposed to running on a
仮想マシン（VM）：物理的な非仮想化マシンでプログラムを実行しているかのようにプログラムを実行する物理マシンのソフトウェア実装。アプリケーションは（一般的に）VM上で実行されているのではなく、VM上で実行されていることを知りません。
"bare" host or server, though some systems provide a paravirtualization environment that allows an operating system or application to be aware of the presence of virtualization for optimization purposes.
「ベア」ホストまたはサーバー。ただし、一部のシステムは準仮想化環境を提供し、オペレーティングシステムまたはアプリケーションが最適化のために仮想化の存在を認識できるようにします。
ToR: Top-of-Rack Switch. A switch placed in a single rack to aggregate network connectivity to and from hosts in that rack.
ToR：トップオブラックスイッチ。単一のラックに配置され、そのラック内のホストとの間のネットワーク接続を集約するスイッチ。
EoR: End-of-Row Switch. A switch used to aggregate network connectivity from multiple racks. EoR switches are the next level of switching above ToR switches.
EoR：行末スイッチ。複数のラックからのネットワーク接続を集約するために使用されるスイッチ。 EoRスイッチは、ToRスイッチより上の次のレベルのスイッチングです。
Large, flat L2 networks have long been known to have scaling problems. As the size of an L2 broadcast domain increases, the level of broadcast traffic from protocols like ARP increases. Large amounts of broadcast traffic pose a particular burden because every device (switch, host, and router) must process and possibly act on such traffic. In extreme cases, "broadcast storms" can occur where the quantity of broadcast traffic reaches a level that effectively brings down part or all of a network. For example, poor implementations of loop detection and prevention or misconfiguration errors can create conditions that lead to broadcast storms as network conditions change. The conventional wisdom for addressing such problems has been to say "don't do that". That is, split large L2 networks into multiple smaller L2 networks, each operating as its own L3/IP subnet. Numerous data center networks have been designed with this principle, e.g., with each rack placed within its own L3 IP subnet. By doing so, the broadcast domain (and address resolution) is confined to one ToR switch, which works well from a scaling perspective. Unfortunately, this conflicts in some ways with the current trend towards dynamic workload shifting in data centers and increased virtualization, as discussed below.
大規模でフラットなL2ネットワークには、スケーリングの問題があることが長い間知られています。 L2ブロードキャストドメインのサイズが増加すると、ARPなどのプロトコルからのブロードキャストトラフィックのレベルが増加します。すべてのデバイス（スイッチ、ホスト、およびルーター）がそのようなトラフィックを処理し、場合によってはそれらに作用する必要があるため、大量のブロードキャストトラフィックは特定の負担となります。極端な場合、「ブロードキャストストーム」は、ブロードキャストトラフィックの量がネットワークの一部またはすべてを効果的に停止させるレベルに達する場合に発生する可能性があります。たとえば、ループの検出と防止または構成エラーの実装が不十分な場合、ネットワークの状態が変化するとブロードキャストストームが発生する状態が発生する可能性があります。そのような問題に対処するための従来の知恵は、「それをしないでください」と言うことでした。つまり、大きなL2ネットワークを複数の小さなL2ネットワークに分割し、それぞれが独自のL3 / IPサブネットとして動作します。多数のデータセンターネットワークがこの原則に従って設計されています。たとえば、各ラックは独自のL3 IPサブネット内に配置されています。そうすることで、ブロードキャストドメイン（およびアドレス解決）は1つのToRスイッチに限定され、スケーリングの観点からうまく機能します。残念ながら、これはいくつかの点で、以下で説明するように、データセンターでの動的なワークロードのシフトと仮想化の増加に向けた現在の傾向と矛盾しています。
Workload placement has become a challenging task within data centers. Ideally, it is desirable to be able to dynamically reassign workloads within a data center in order to optimize server utilization, add more servers in response to increased demand, etc. However, servers are often pre-configured to run with a given set of IP addresses. Placement of such servers is then subject to constraints of the IP addressing restrictions of the data center. For example, servers configured with addresses from a particular subnet could only be placed where they connect to the IP subnet corresponding to their IP addresses. If each ToR switch is acting as a gateway for its own subnet, a server can only be connected to the one ToR switch. This gateway switch represents the L2/L3 boundary. A similar constraint occurs in virtualized environments, as discussed next.
ワークロードの配置は、データセンター内では困難な作業になっています。理想的には、サーバーの使用率を最適化したり、需要の増加に応じてサーバーを追加したりするために、データセンター内のワークロードを動的に再割り当てできることが望ましいです。ただし、サーバーは特定のIPセットで実行するように事前設定されていることがよくあります。アドレス。そのようなサーバーの配置は、データセンターのIPアドレッシング制限の制約を受けます。たとえば、特定のサブネットのアドレスで構成されたサーバーは、IPアドレスに対応するIPサブネットに接続する場所にのみ配置できます。各ToRスイッチが独自のサブネットのゲートウェイとして機能している場合、サーバーは1つのToRスイッチにのみ接続できます。このゲートウェイスイッチは、L2 / L3境界を表します。次に説明するように、仮想化環境でも同様の制約が発生します。
Server virtualization is fast becoming the norm in data centers. With server virtualization, each physical server supports multiple virtual machines, each running its own operating system, middleware, and applications. Virtualization is a key enabler of workload agility, i.e., allowing any server to host any application (on its own VM) and providing the flexibility of adding, shrinking, or moving VMs within the physical infrastructure. Server virtualization provides numerous benefits, including higher utilization, increased data security, reduced user downtime, and even significant power conservation, along with the promise of a more flexible and dynamic computing environment.
サーバー仮想化は急速にデータセンターの標準になりつつあります。サーバーの仮想化では、各物理サーバーが複数の仮想マシンをサポートし、それぞれが独自のオペレーティングシステム、ミドルウェア、およびアプリケーションを実行します。仮想化は、ワークロードの俊敏性を実現する重要な要素です。つまり、任意のサーバーが（独自のVM上で）アプリケーションをホストできるようにし、物理インフラストラクチャ内でVMを追加、縮小、または移動する柔軟性を提供します。サーバーの仮想化は、利用率の向上、データセキュリティの向上、ユーザーのダウンタイムの削減、さらには大幅な省電力など、多くの利点を提供し、より柔軟で動的なコンピューティング環境の実現を約束します。
The discussion below focuses on VM placement and migration. Keep in mind, however, that even in a non-virtualized environment, many of the same issues apply to individual workloads running on standalone machines. For example, when increasing the number of servers running a particular workload to meet demand, placement of those workloads may be constrained by IP subnet numbering considerations, as discussed earlier.
以下の説明では、VMの配置と移行に焦点を当てています。ただし、仮想化されていない環境でも、スタンドアロンマシンで実行されている個々のワークロードに同じ問題の多くが当てはまることに注意してください。たとえば、需要を満たすために特定のワークロードを実行するサーバーの数を増やす場合、前述のように、それらのワークロードの配置はIPサブネットの番号付けの考慮事項によって制約される場合があります。
The greatest flexibility in VM and workload management occurs when it is possible to place a VM (or workload) anywhere in the data center regardless of what IP addresses the VM uses and how the physical network is laid out. In practice, movement of VMs within a data center is easiest when VM placement and movement do not conflict with the IP subnet boundaries of the data center's network, so that the VM's IP address need not be changed to reflect its actual point of attachment on the network from an L3/IP perspective. In contrast, if a VM moves to a new IP subnet, its address must change, and clients will need to be made aware of that change. From a VM management perspective, management is simplified if all servers are on a single large L2 network.
VMとワークロード管理の最大の柔軟性は、VMが使用するIPアドレスや物理ネットワークのレイアウトに関係なく、データセンターの任意の場所にVM（またはワークロード）を配置できる場合に発生します。実際には、データセンター内のVMの移動は、VMの配置と移動がデータセンターのネットワークのIPサブネット境界と競合しない場合に最も簡単です。そのため、VMのIPアドレスを変更して、実際の接続ポイントをL3 / IPの観点から見たネットワーク。対照的に、VMが新しいIPサブネットに移動する場合、そのアドレスを変更する必要があり、クライアントはその変更を認識する必要があります。 VM管理の観点からは、すべてのサーバーが単一の大規模なL2ネットワーク上にある場合、管理が簡素化されます。
With virtualization, it is not uncommon to have a single physical server host ten or more VMs, each having its own IP (and Media Access Control (MAC)) addresses. Consequently, the number of addresses per machine (and hence per subnet) is increasing, even when the number of physical machines stays constant. In a few years, the numbers will likely be even higher.
仮想化では、それぞれが独自のIP（およびメディアアクセス制御（MAC））アドレスを持つ10個以上のVMを単一の物理サーバーホストにすることは珍しくありません。その結果、物理マシンの数が一定のままであっても、マシンごと（したがってサブネットごと）のアドレス数は増加しています。数年後には、その数はさらに増えるでしょう。
In the past, applications were static in the sense that they tended to stay in one physical place. An application installed on a physical machine would stay on that machine because the cost of moving an application elsewhere was generally high. Moreover, physical servers hosting applications would tend to be placed in such a way as to facilitate communication locality. That is, applications running on servers would be physically located near the servers hosting the applications they communicated with most heavily. The network traffic patterns in such environments could thus be optimized, in some cases keeping significant traffic local to one network segment. In these more static and carefully managed environments, it was possible to build networks that approached scaling limitations but did not actually cross the threshold.
以前は、アプリケーションは1つの物理的な場所にとどまる傾向があったという意味で静的でした。物理マシンにインストールされたアプリケーションは、そのアプリケーションを他の場所に移動するコストが一般に高いため、そのマシンに残ります。さらに、アプリケーションをホストする物理サーバーは、通信の局所性を促進するような方法で配置される傾向があります。つまり、サーバーで実行されているアプリケーションは、物理的に、最も頻繁に通信するアプリケーションをホストしているサーバーの近くに配置されます。したがって、このような環境でのネットワークトラフィックパターンは最適化され、場合によっては、重要なトラフィックを1つのネットワークセグメントにローカルに保つことができます。これらのより静的で注意深く管理された環境では、スケーリングの制限に近づいたが実際にはしきい値を超えなかったネットワークを構築することが可能でした。
Today, with the proliferation of VMs, traffic patterns are becoming more diverse and less predictable. In particular, there can easily be less locality of network traffic as VMs hosting applications are moved for such reasons as reducing overall power usage (by consolidating VMs and powering off idle machines) or moving a VM to a physical server with more capacity or a lower load. In today's changing environments, it is becoming more difficult to engineer networks as traffic patterns continually shift as VMs move around.
今日、VMの急増に伴い、トラフィックパターンはより多様化し、予測可能性が低下しています。特に、アプリケーションをホストしているVMが（VMを統合してアイドル状態のマシンの電源をオフにすることで）全体的な電力使用量を削減したり、VMをより多くの容量またはより少ない容量の物理サーバーに移動したりするなどの理由で、ネットワークトラフィックの局所性を簡単に減らすことができます負荷。今日の変化する環境では、VMが移動するにつれてトラフィックパターンが継続的に変化するため、ネットワークを設計することがより困難になっています。
In summary, both the size and density of L2 networks are increasing. In addition, increasingly dynamic workloads and the increased usage of VMs are creating pressure for ever-larger L2 networks. Today, there are already data centers with over 100,000 physical machines and many times that number of VMs. This number will only increase going forward. In addition, traffic patterns within a data center are also constantly changing. Ultimately, the issues described in this document might be observed at any scale, depending on the particular design of the data center.
要約すると、L2ネットワークのサイズと密度の両方が増加しています。さらに、ワークロードの動的化とVMの使用量の増加により、L2ネットワークの規模はますます大きくなっています。現在、100,000台を超える物理マシンとその数倍のVMを備えたデータセンターがすでに存在しています。この数は今後増加するだけです。さらに、データセンター内のトラフィックパターンも常に変化しています。最終的に、このドキュメントで説明されている問題は、データセンターの特定の設計に応じて、あらゆる規模で観察される可能性があります。
In IPv4 over Ethernet, ARP provides the function of address resolution. To determine the link-layer address of a given IP address, a node broadcasts an ARP Request. The request is delivered to all portions of the L2 network, and the node with the requested IP address responds with an ARP Reply. ARP is an old protocol and, by current standards, is sparsely documented. For example, there are no clear requirements for retransmitting ARP Requests in the absence of replies. Consequently, implementations vary in the details of what they actually implement [RFC0826][RFC1122].
イーサネット上のIPv4では、ARPはアドレス解決の機能を提供します。特定のIPアドレスのリンク層アドレスを判別するために、ノードはARP要求をブロードキャストします。要求はL2ネットワークのすべての部分に配信され、要求されたIPアドレスを持つノードはARP応答で応答します。 ARPは古いプロトコルであり、現在の標準では、まばらに文書化されています。たとえば、応答がない場合にARP要求を再送信するための明確な要件はありません。その結果、実装は実際に実装するものの詳細が異なります[RFC0826] [RFC1122]。
From a scaling perspective, there are a number of problems with ARP. First, it uses broadcast, and any network with a large number of attached hosts will see a correspondingly large amount of broadcast ARP traffic. The second problem is that it is not feasible to change host implementations of ARP -- current implementations are too widely entrenched, and any changes to host implementations of ARP would take years to become sufficiently deployed to matter. That said, it may be possible to change ARP implementations in hypervisors, L2/L3 boundary routers, and/or ToR access switches, to leverage such techniques as Proxy ARP. Finally, ARP implementations need to take steps to flush out stale or otherwise invalid entries.
スケーリングの観点から見ると、ARPにはいくつかの問題があります。まず、ブロードキャストを使用します。多数のホストが接続されているネットワークでは、それに応じて大量のブロードキャストARPトラフィックが発生します。 2番目の問題は、ARPのホスト実装を変更することは現実的ではないということです。現在の実装はあまりにも広範囲に及びており、ARPのホスト実装を変更すると、問題が十分に展開されるまでに何年もかかります。つまり、プロキシARPなどの手法を活用するために、ハイパーバイザー、L2 / L3境界ルーター、ToRアクセススイッチのARP実装を変更することが可能になる場合があります。最後に、ARP実装は、古いエントリまたは無効なエントリをフラッシュするための手順を実行する必要があります。
Unfortunately, existing standards do not provide clear implementation guidelines for how to do this. Consequently, implementations vary significantly, and some implementations are "chatty" in that they just periodically flush caches every few minutes and send new ARP queries.
残念ながら、既存の標準は、これを行う方法について明確な実装ガイドラインを提供していません。その結果、実装は大きく異なり、一部の実装は数分ごとに定期的にキャッシュをフラッシュし、新しいARPクエリを送信するだけで「おしゃべり」です。
Broadly speaking, from the perspective of address resolution, IPv6's Neighbor Discovery (ND) behaves much like ARP, with a few notable differences. First, ARP uses broadcast, whereas ND uses multicast. When querying for a target IP address, ND maps the target address into an IPv6 Solicited Node multicast address. Using multicast rather than broadcast has the benefit that the multicast frames do not necessarily need to be sent to all parts of the network, i.e., the frames can be sent only to segments where listeners for the Solicited Node multicast address reside. In the case where multicast frames are delivered to all parts of the network, sending to a multicast address still has the advantage that most (if not all) nodes will filter out the (unwanted) multicast query via filters installed in the Network Interface Card (NIC) rather than burdening host software with the need to process such packets. Thus, whereas all nodes must process every ARP query, ND queries are processed only by the nodes to which they are intended. In cases where multicast filtering can't effectively be implemented in the NIC (e.g., as on hypervisors supporting virtualization), filtering would need to be done in software (e.g., in the hypervisor's vSwitch).
大まかに言うと、アドレス解決の観点から見ると、IPv6の近隣探索（ND）はARPとほとんど同じように動作しますが、いくつかの顕著な違いがあります。まず、ARPはブロードキャストを使用しますが、NDはマルチキャストを使用します。ターゲットIPアドレスを照会すると、NDはターゲットアドレスをIPv6要請ノードマルチキャストアドレスにマップします。ブロードキャストではなくマルチキャストを使用すると、マルチキャストフレームを必ずしもネットワークのすべての部分に送信する必要がないという利点があります。つまり、フレームは、送信請求ノードマルチキャストアドレスのリスナーが存在するセグメントにのみ送信できます。マルチキャストフレームがネットワークのすべての部分に配信される場合でも、マルチキャストアドレスに送信すると、ほとんどの（すべてではないにしても）ノードがネットワークインターフェースカード（ NIC）は、このようなパケットを処理する必要があるホストソフトウェアに負担をかけません。したがって、すべてのノードはすべてのARPクエリを処理する必要がありますが、NDクエリは、それらが意図されているノードによってのみ処理されます。マルチキャストフィルタリングをNICに効果的に実装できない場合（仮想化をサポートするハイパーバイザーなど）、フィルタリングはソフトウェア（ハイパーバイザーのvSwitchなど）で行う必要があります。
There are many different ways in which data center networks might be designed. The designs are usually engineered to suit the particular workloads that are being deployed in the data center. For example, a large web server farm might be engineered in a very different way than a general-purpose multi-tenant cloud hosting service. However, in most cases the designs can be abstracted into a typical three-layer model consisting of an access layer, an aggregation layer, and the Core. The access layer generally refers to the switches that are closest to the physical or virtual servers; the aggregation layer serves to interconnect multiple access-layer devices. The Core switches connect the aggregation switches to the larger network core.
データセンターネットワークの設計には、さまざまな方法があります。設計は通常、データセンターに展開されている特定のワークロードに適合するように設計されています。たとえば、大規模なWebサーバーファームは、汎用のマルチテナントクラウドホスティングサービスとはまったく異なる方法で設計されている場合があります。ただし、ほとんどの場合、デザインは、アクセスレイヤー、アグリゲーションレイヤー、およびコアで構成される典型的な3レイヤーモデルに抽象化できます。アクセスレイヤーは、通常、物理サーバーまたは仮想サーバーに最も近いスイッチを指します。アグリゲーションレイヤは、複数のアクセスレイヤデバイスを相互接続する役割を果たします。コアスイッチは、集約スイッチをより大きなネットワークコアに接続します。
Figure 1 shows a generalized data center design, which captures the essential elements of various alternatives.
図1は、さまざまな選択肢の重要な要素を捉えた一般的なデータセンター設計を示しています。
+-----+-----+ +-----+-----+
| Core0 | | Core1 | Core
+-----+-----+ +-----+-----+
/ \ / /
/ \----------\ /
/ /---------/ \ /
+-------+ +------+
+/------+ | +/-----+ |
| Aggr11| + --------|AggrN1| + Aggregation Layer
+---+---+/ +------+/
/ \ / \
/ \ / \
+---+ +---+ +---+ +---+
|T11|... |T1x| |TN1| |TNy| Access Layer
+---+ +---+ +---+ +---+
| | | | | | | |
+---+ +---+ +---+ +---+
| |... | | | | | |
+---+ +---+ +---+ +---+ Server Racks
| |... | | | | | |
+---+ +---+ +---+ +---+
| |... | | | | | |
+---+ +---+ +---+ +---+
Typical Layered Architecture in a Data Center
データセンターの典型的なレイヤードアーキテクチャ
Figure 1
図1
The access switches provide connectivity directly to/from physical and virtual servers. The access layer may be implemented by wiring the servers within a rack to a ToR switch or, less commonly, the servers could be wired directly to an EoR switch. A server rack may have a single uplink to one access switch or may have dual uplinks to two different access switches.
アクセススイッチは、物理サーバーと仮想サーバーとの間で直接接続を提供します。アクセスレイヤーは、ラック内のサーバーをToRスイッチに配線することで実装できますが、あまり一般的ではありませんが、サーバーをEoRスイッチに直接配線することもできます。サーバーラックには、1つのアクセススイッチへの単一のアップリンクがある場合と、2つの異なるアクセススイッチへの二重のアップリンクがある場合があります。
In a typical data center, aggregation switches interconnect many ToR switches. Usually, there are multiple parallel aggregation switches, serving the same group of ToRs to achieve load sharing. It is no longer uncommon to see aggregation switches interconnecting hundreds of ToR switches in large data centers.
一般的なデータセンターでは、集約スイッチは多くのToRスイッチを相互接続します。通常、複数の並列集約スイッチがあり、同じグループのToRを処理して負荷分散を実現します。大規模なデータセンターで数百のToRスイッチを相互接続する集約スイッチが見られることは、もはや珍しくありません。
Core switches provide connectivity between aggregation switches and the main data center network. Core switches interconnect different sets of racks and provide connectivity to data center gateways leading to external networks.
コアスイッチは、集約スイッチとメインデータセンターネットワーク間の接続を提供します。コアスイッチは、ラックのさまざまなセットを相互接続し、外部ネットワークにつながるデータセンターゲートウェイへの接続を提供します。
In this scenario, the L3 domain is extended all the way from the core network to the access switches. Each rack enclosure consists of a single L2 domain, which is confined to the rack. In general, there are no significant ARP/ND scaling issues in this scenario, as the L2 domain cannot grow very large. Such a topology has benefits in scenarios where servers attached to a particular access switch generally run VMs that are confined to using a single subnet. These VMs and the applications they host aren't moved (migrated) to other racks that might be attached to different access switches (and different IP subnets). A small server farm or very static compute cluster might be well served via this design.
このシナリオでは、L3ドメインはコアネットワークからアクセススイッチまで拡張されます。各ラックエンクロージャは、ラックに限定された単一のL2ドメインで構成されます。一般に、L2ドメインは非常に大きくなることができないため、このシナリオではARP / NDスケーリングの重大な問題はありません。このようなトポロジには、特定のアクセススイッチに接続されたサーバーが、通常、単一のサブネットの使用に限定されたVMを実行するシナリオでの利点があります。これらのVMとそれらがホストするアプリケーションは、別のアクセススイッチ（および別のIPサブネット）に接続されている可能性のある他のラックに移動（移行）されません。小規模なサーバーファームまたは非常に静的な計算クラスターは、この設計を介して十分に機能する可能性があります。
When the L3 domain extends only to aggregation switches, hosts in any of the IP subnets configured on the aggregation switches can be reachable via L2 through any access switches if access switches enable all the VLANs. Such a topology allows a greater level of flexibility, as servers attached to any access switch can run any VMs that have been provisioned with IP addresses configured on the aggregation switches. In such an environment, VMs can migrate between racks without IP address changes. The drawback of this design, however, is that multiple VLANs have to be enabled on all access switches and all access-facing ports on aggregation switches. Even though L2 traffic is still partitioned by VLANs, the fact that all VLANs are enabled on all ports can lead to broadcast traffic on all VLANs that traverse all links and ports, which has the same effect as one big L2 domain on the access-facing side of the aggregation switch. In addition, the internal traffic itself might have to cross different L2 boundaries, resulting in significant ARP/ND load at the aggregation switches. This design provides a good tradeoff between flexibility and L2 domain size. A moderate-sized data center might utilize this approach to provide high-availability services at a single location.
L3ドメインが集約スイッチにのみ拡張される場合、アクセススイッチがすべてのVLANを有効にすると、集約スイッチで設定されたIPサブネットのホストは、アクセススイッチを介してL2経由で到達できます。このようなトポロジーでは、任意のアクセススイッチに接続されたサーバーが、集約スイッチで構成されたIPアドレスでプロビジョニングされた任意のVMを実行できるため、より高いレベルの柔軟性が可能になります。このような環境では、VMはIPアドレスを変更せずにラック間で移行できます。ただし、この設計の欠点は、すべてのアクセススイッチおよび集約スイッチのすべてのアクセス側ポートで複数のVLANを有効にする必要があることです。 L2トラフィックが引き続きVLANによって分割されている場合でも、すべてのVLANがすべてのポートで有効になっているため、すべてのリンクおよびポートを通過するすべてのVLANでブロードキャストトラフィックが発生する可能性があります。これは、アクセス側の1つの大きなL2ドメインと同じ効果があります集約スイッチの側面。さらに、内部トラフィック自体が異なるL2境界を越える必要があるため、集約スイッチでARP / NDの負荷が大幅に増加する可能性があります。この設計は、柔軟性とL2ドメインサイズの間の適切なトレードオフを提供します。中規模のデータセンターでは、このアプローチを利用して、単一の場所で高可用性サービスを提供できます。
In some cases, where a wider range of VM mobility is desired (i.e., a greater number of racks among which VMs can move without IP address changes), the L3 routed domain might be terminated at the core routers themselves. In this case, VLANs can span multiple groups of aggregation switches, which allows hosts to be moved among a greater number of server racks without IP address changes. This scenario results in the largest ARP/ND performance impact, as explained later. A data center with very rapid workload shifting may consider this kind of design.
より広い範囲のVMモビリティが必要な場合（つまり、IPアドレスを変更せずにVMが移動できるラックの数が多い場合）は、L3ルーテッドドメインがコアルーター自体で終了する場合があります。この場合、VLANは集約スイッチの複数のグループにまたがることができます。これにより、IPアドレスを変更することなく、ホストをより多くのサーバーラック間で移動できます。このシナリオは、後で説明するように、ARP / NDパフォーマンスに最大の影響をもたらします。ワークロードのシフトが非常に速いデータセンターでは、この種の設計を検討する場合があります。
There are several approaches where overlay networks can be used to build very large L2 networks to enable VM mobility. Overlay networks using various L2 or L3 mechanisms allow interior switches/routers to mask host addresses. In addition, L3 overlays can help the data center designer control the size of the L2 domain and also enhance the ability to provide multi-tenancy in data center networks. However, the use of overlays does not eliminate traffic associated with address resolution; it simply moves it to regular data traffic. That is, address resolution is implemented in the overlay and is not directly visible to the switches of the data center network.
オーバーレイネットワークを使用して非常に大規模なL2ネットワークを構築し、VMのモビリティを可能にするいくつかのアプローチがあります。さまざまなL2またはL3メカニズムを使用するオーバーレイネットワークにより、内部スイッチ/ルーターがホストアドレスをマスクできます。さらに、L3オーバーレイは、データセンターの設計者がL2ドメインのサイズを制御するのに役立ち、データセンターネットワークでマルチテナンシーを提供する機能も強化します。ただし、オーバーレイを使用しても、アドレス解決に関連するトラフィックは排除されません。通常のデータトラフィックに移動するだけです。つまり、アドレス解決はオーバーレイに実装されており、データセンターネットワークのスイッチから直接見ることはできません。
A potential problem that arises in a large data center is that when a large number of hosts communicate with their peers in different subnets, all these hosts send (and receive) data packets to their respective L2/L3 boundary nodes, as the traffic flows are generally bidirectional. This has the potential to further highlight any scaling problems. These L2/L3 boundary nodes have to process ARP/ND requests sent from originating subnets and resolve physical (MAC) addresses in the target subnets for what are generally bidirectional flows. Therefore, for maximum flexibility in managing the data center workload, it is often desirable to use overlays to place related groups of hosts in the same topological subnet to avoid the L2/L3 boundary translation. The use of overlays in the data center network can be a useful design mechanism to help manage a potential bottleneck at the L2/L3 boundary by redefining where that boundary exists.
大規模なデータセンターで発生する可能性のある問題は、多数のホストが異なるサブネットのピアと通信する場合、これらのすべてのホストがデータパケットをそれぞれのL2 / L3境界ノードに送信（および受信）することです。通常は双方向です。これは、スケーリングの問題をさらに強調する可能性があります。これらのL2 / L3境界ノードは、発信元のサブネットから送信されたARP / ND要求を処理し、一般的に双方向のフローであるターゲットサブネットの物理（MAC）アドレスを解決する必要があります。したがって、データセンターのワークロードを最大限に柔軟に管理するには、オーバーレイを使用して関連するホストのグループを同じトポロジサブネットに配置し、L2 / L3境界変換を回避することが望ましい場合があります。データセンターネットワークでオーバーレイを使用することは、境界が存在する場所を再定義することにより、L2 / L3境界での潜在的なボトルネックを管理するのに役立つ設計メカニズムとして役立ちます。
Expected traffic patterns play an important role in designing appropriately sized access, aggregation, and core networks. Traffic patterns also vary based on the expected use of the data center.
予想されるトラフィックパターンは、適切なサイズのアクセス、集約、およびコアネットワークを設計する上で重要な役割を果たします。トラフィックパターンは、データセンターの予想される使用状況によっても異なります。
Broadly speaking, it is desirable to keep as much traffic as possible on the access layer in order to minimize the bandwidth usage at the aggregation layer. If the expected use of the data center is to serve as a large web server farm, where thousands of nodes are doing similar things and the traffic pattern is largely in and out of a large data center, an access layer with EoR switches might be used, as it minimizes complexity, allows for servers and databases to be located in the same L2 domain, and provides for maximum density.
大まかに言えば、アグリゲーションレイヤーでの帯域幅の使用を最小限に抑えるために、アクセスレイヤーでできるだけ多くのトラフィックを維持することが望ましいです。データセンターの予想される用途が大規模なWebサーバーファームとして機能することであり、何千ものノードが同様のことを行っており、トラフィックパターンが大規模なデータセンターに出入りしている場合は、EoRスイッチを備えたアクセスレイヤーが使用される場合があります。は、複雑さを最小限に抑え、サーバーとデータベースを同じL2ドメインに配置できるようにし、最大の密度を提供します。
A data center that is expected to host a multi-tenant cloud hosting service might have some completely unique requirements. In order to isolate inter-customer traffic, smaller L2 domains might be preferred, and though the size of the overall data center might be comparable to the previous example, the multi-tenant nature of the cloud hosting application requires a smaller and more compartmentalized access layer. A multi-tenant environment might also require the use of L3 all the way to the access-layer ToR switch.
マルチテナントクラウドホスティングサービスをホストすることが期待されるデータセンターには、完全に固有の要件がいくつかある場合があります。顧客間のトラフィックを分離するためには、L2ドメインが小さい方が望ましい場合があります。データセンター全体のサイズは前の例と同等であるかもしれませんが、クラウドホスティングアプリケーションのマルチテナントの性質により、より小さく、より区分されたアクセスが必要です。層。マルチテナント環境では、アクセスレイヤーのToRスイッチまでL3を使用する必要がある場合もあります。
Yet another example of a workload with a unique traffic pattern is a high-performance compute cluster, where most of the traffic is expected to stay within the cluster but at the same time there is a high degree of crosstalk between the nodes. This would once again call for a large access layer in order to minimize the requirements at the aggregation layer.
独自のトラフィックパターンを持つワークロードのさらに別の例は、高性能の計算クラスターです。この場合、ほとんどのトラフィックはクラスター内にとどまると予想されますが、同時にノード間に高度のクロストークがあります。これは、集約層での要件を最小限に抑えるために、再び大きなアクセス層を必要とします。
Using virtualization in the data center further serves to increase the possible densities that can be achieved. However, virtualization also further complicates the requirements on the access layer, as virtualization restricts the scope of server placement in the event of server failover resulting from hardware failures or server migration for load balancing or other reasons.
データセンターで仮想化を使用すると、達成可能な密度をさらに高めることができます。ただし、仮想化はアクセスレイヤーの要件もさらに複雑にします。仮想化は、ハードウェア障害やロードバランシングなどの理由によるサーバーの移行に起因するサーバーのフェイルオーバーが発生した場合のサーバー配置の範囲を制限するためです。
Virtualization also can place additional requirements on the aggregation switches in terms of address resolution table size and the scalability of any address-learning protocols that might be used on those switches. The use of virtualization often also requires the use of additional VLANs for high-availability beaconing, which would need to span the entire virtualized infrastructure. This would require the access layer to also span the entire virtualized infrastructure.
仮想化では、アドレス解決テーブルのサイズと、それらのスイッチで使用される可能性のあるアドレス学習プロトコルのスケーラビリティの観点から、集約スイッチに追加の要件を課すこともできます。多くの場合、仮想化を使用すると、高可用性ビーコンのために追加のVLANを使用する必要があり、仮想化インフラストラクチャ全体にまたがる必要があります。これには、仮想化インフラストラクチャ全体にもまたがるアクセスレイヤーが必要です。
The designs described in this section have a number of tradeoffs. The "L3 to access switches" design described in Section 6.4.1 is the only design that constrains L2 domain size in a fashion that avoids ARP/ND scaling problems. However, that design has limitations and does not address some of the other requirements that lead to configurations that make use of larger L2 domains. Consequently, ARP/ND scaling issues are a real problem in practice.
このセクションで説明する設計には、いくつかのトレードオフがあります。セクション6.4.1で説明されている「L3からアクセススイッチへ」の設計は、ARP / NDスケーリングの問題を回避する方法でL2ドメインサイズを制約する唯一の設計です。ただし、その設計には制限があり、より大きなL2ドメインを使用する構成につながる他のいくつかの要件には対応していません。したがって、ARP / NDスケーリングの問題は、実際には実際の問題です。
This section articulates some specific problems or "pain points" that are related to large data centers.
このセクションでは、大規模なデータセンターに関連する特定の問題または「問題点」について説明します。
One pain point with large L2 broadcast domains is that the routers connected to the L2 domain may need to process a significant amount of ARP traffic in some cases. In particular, environments where the aggregate level of ARP traffic is very large may lead to a heavy ARP load on routers. Even though the vast majority of ARP traffic may not be aimed at that router, the router still has to process enough of the ARP Request to determine whether it can safely be ignored. The ARP algorithm specifies that a recipient must update its ARP cache if it receives an ARP query from a source for which it has an entry [RFC0826].
大規模なL2ブロードキャストドメインの問題点の1つは、L2ドメインに接続されているルーターが、場合によっては大量のARPトラフィックを処理する必要があることです。特に、ARPトラフィックの集約レベルが非常に大きい環境では、ルーターのARP負荷が高くなる可能性があります。 ARPトラフィックの大部分がそのルーターを対象としていない場合でも、ルーターは十分にARP要求を処理して、安全に無視できるかどうかを判断する必要があります。 ARPアルゴリズムは、受信者がエントリ[RFC0826]を持つソースからARPクエリを受信した場合、受信者がARPキャッシュを更新する必要があることを指定します。
ARP processing in routers is commonly handled in a "slow path" software processor, rather than directly by a hardware Application-Specific Integrated Circuit (ASIC) as is the case when forwarding packets. Such a design significantly limits the rate at which ARP traffic can be processed compared to the rate at which ASICs can forward traffic. Current implementations at the time of this writing can support ARP processing in the low thousands of ARP packets per second. In some deployments, limitations on the rate of ARP processing have been cited as being a problem.
ルーターでのARP処理は、パケットを転送する場合のようにハードウェアの特定用途向け集積回路（ASIC）で直接処理されるのではなく、「スローパス」ソフトウェアプロセッサで一般的に処理されます。このような設計では、ASICがトラフィックを転送できる速度と比較して、ARPトラフィックを処理できる速度が大幅に制限されます。この記事の執筆時点での現在の実装では、毎秒数千ものARPパケットでのARP処理をサポートできます。一部の展開では、ARP処理の速度の制限が問題として挙げられています。
To further reduce the ARP load, some routers have implemented additional optimizations in their forwarding ASIC paths. For example, some routers can be configured to discard ARP Requests for target addresses other than those assigned to the router. That way, the router's software processor only receives ARP Requests for addresses it owns and must respond to. This can significantly reduce the number of ARP Requests that must be processed by the router.
ARP負荷をさらに削減するために、一部のルーターは転送ASICパスに追加の最適化を実装しています。たとえば、一部のルーターは、ルーターに割り当てられたもの以外のターゲットアドレスに対するARP要求を破棄するように構成できます。このようにして、ルーターのソフトウェアプロセッサは、自身が所有し応答する必要のあるアドレスに対するARP要求のみを受信します。これにより、ルーターで処理する必要のあるARP要求の数を大幅に減らすことができます。
Another optimization concerns reducing the number of ARP queries targeted at routers, whether for address resolution or to validate existing cache entries. Some routers can be configured to broadcast periodic gratuitous ARPs [RFC5227]. Upon receipt of a gratuitous ARP, implementations mark the associated entry as "fresh", resetting the aging timer to its maximum setting. Consequently, sending out periodic gratuitous ARPs can effectively prevent nodes from needing to send ARP Requests intended to revalidate stale entries for a router. The net result is an overall reduction in the number of ARP queries routers receive. Gratuitous ARPs, broadcast to all nodes in the L2 broadcast domain, may in some cases also pre-populate ARP caches on neighboring devices, further reducing ARP traffic. But it is not believed that pre-population of ARP entries is supported by most implementations, as the ARP specification [RFC0826] recommends only that pre-existing ARP entries be updated upon receipt of ARP messages; it does not call for the creation of new entries when none already exist.
もう1つの最適化は、アドレス解決であれ、既存のキャッシュエントリの検証であれ、ルーターをターゲットとするARPクエリの数を減らすことです。一部のルーターは、定期的な無償ARP [RFC5227]をブロードキャストするように構成できます。不必要なARPを受信すると、実装は関連するエントリを「フレッシュ」としてマークし、エージングタイマーを最大設定にリセットします。その結果、定期的に無料のARPを送信することで、ノードがルーターの古いエントリを再検証することを目的としたARP要求を送信する必要がなくなります。その結果、ルーターが受信するARPクエリの数が全体的に減少します。 L2ブロードキャストドメイン内のすべてのノードにブロードキャストするGratuitous ARPは、場合によっては隣接デバイスのARPキャッシュに事前入力され、ARPトラフィックをさらに削減します。ただし、ARP仕様[RFC0826]は、ARPメッセージの受信時に既存のARPエントリを更新することのみを推奨しているため、ほとんどの実装でARPエントリの事前入力がサポートされているとは考えられていません。まだ存在しない場合は、新しいエントリの作成を要求しません。
Finally, another area concerns the overhead of processing IP packets for which no ARP entry exists. Existing standards specify that one or more IP packets for which no ARP entries exist should be queued pending successful completion of the address resolution process [RFC1122] [RFC1812]. Once an ARP query has been resolved, any queued packets can be forwarded on. Again, the processing of such packets is handled in the "slow path", effectively limiting the rate at which a router can process ARP "cache misses", and is viewed as a problem in some deployments today. Additionally, if no response is received, the router may send the ARP/ND query multiple times. If no response is received after a number of ARP/ND requests, the router needs to drop any queued data packets and may send an ICMP destination unreachable message as well [RFC0792]. This entire process can be CPU intensive.
最後に、別の領域は、ARPエントリが存在しないIPパケットの処理のオーバーヘッドに関係しています。既存の標準では、ARPエントリが存在しない1つまたは複数のIPパケットを、アドレス解決プロセス[RFC1122] [RFC1812]が正常に完了するまで待機するように指定しています。 ARPクエリが解決されると、キューに入れられたパケットを転送できます。繰り返しになりますが、このようなパケットの処理は「低速パス」で処理され、ルーターがARPの「キャッシュミス」を処理できる速度を効果的に制限し、現在の一部の展開では問題と見なされています。さらに、応答が受信されない場合、ルーターはARP / NDクエリを複数回送信することがあります。多数のARP / ND要求の後に応答が受信されない場合、ルーターはキューに入れられたデータパケットをすべてドロップする必要があり、ICMP宛先到達不能メッセージも送信する可能性があります[RFC0792]。このプロセス全体がCPUに負荷をかける可能性があります。
Although address resolution traffic remains local to one L2 network, some data center designs terminate L2 domains at individual aggregation switches/routers (e.g., see Section 6.4.2). Such routers can be connected to a large number of interfaces (e.g., 100 or more). While the address resolution traffic on any one interface may be manageable, the aggregate address resolution traffic across all interfaces can become problematic.
アドレス解決トラフィックは1つのL2ネットワークに対してローカルのままですが、一部のデータセンター設計は、個々の集約スイッチ/ルーターでL2ドメインを終端します（たとえば、セクション6.4.2を参照）。このようなルーターは、多数のインターフェース（100以上など）に接続できます。 1つのインターフェイス上のアドレス解決トラフィックは管理可能かもしれませんが、すべてのインターフェイスにわたる集約アドレス解決トラフィックは問題になる可能性があります。
Another variant of the above issue has individual routers servicing a relatively small number of interfaces, with the individual interfaces themselves serving very large subnets. Once again, it is the aggregate quantity of ARP traffic seen across all of the router's interfaces that can be problematic. This pain point is essentially the same as the one discussed above, the only difference being whether a given number of hosts are spread across a few large IP subnets or many smaller ones.
上記の問題の別の変形では、個々のルーターが比較的少数のインターフェースを処理し、個々のインターフェース自体が非常に大きなサブネットを処理します。繰り返しになりますが、問題となる可能性があるのは、ルーターのすべてのインターフェースで見られるARPトラフィックの総量です。この問題点は、基本的に上記で説明した問題と同じです。唯一の違いは、特定の数のホストが少数の大きなIPサブネットに分散しているか、多数の小さなサブネットに分散しているかです。
When hosts in two different subnets under the same L2/L3 boundary router need to communicate with each other, the L2/L3 router not only has to initiate ARP/ND requests to the target's subnet, it also has to process the ARP/ND requests from the originating subnet. This process further adds to the overall ARP processing load.
同じL2 / L3境界ルーターの下にある2つの異なるサブネットのホストが相互に通信する必要がある場合、L2 / L3ルーターはターゲットのサブネットへのARP / ND要求を開始するだけでなく、ARP / ND要求を処理する必要もあります。元のサブネットから。このプロセスにより、全体的なARP処理負荷がさらに増加します。
Though IPv6's Neighbor Discovery behaves much like ARP, there are several notable differences that result in a different set of potential issues. From an L2 perspective, an important difference is that ND address resolution requests are sent via multicast, which results in ND queries only being processed by the nodes for which they are intended. Compared with broadcast ARPs, this reduces the total number of ND packets that an implementation will receive.
IPv6のネイバー探索はARPのように動作しますが、いくつかの顕著な違いがあり、潜在的な問題のセットが異なります。 L2の観点からの重要な違いは、NDアドレス解決要求がマルチキャストを介して送信されることです。その結果、NDクエリは、意図されたノードによってのみ処理されます。ブロードキャストARPと比較して、これは実装が受信するNDパケットの総数を減らします。
Another key difference concerns revalidating stale ND entries. ND requires that nodes periodically revalidate any entries they are using, to ensure that bad entries are timed out quickly enough that TCP does not terminate a connection. Consequently, some implementations will send out "probe" ND queries to validate in-use ND entries as frequently as every 35 seconds [RFC4861]. Such probes are sent via unicast (unlike in the case of ARP). However, on larger networks, such probes can result in routers receiving many such queries (i.e., many more than with ARP, which does not specify such behavior). Unfortunately, the IPv4 mitigation technique of sending gratuitous ARPs (as described in Section 7.1) does not work in IPv6. The ND specification specifically states that gratuitous ND "updates" cannot cause an ND entry to be marked "valid". Rather, such entries are marked "probe", which causes the receiving node to (eventually) generate a probe back to the sender, which in this case is precisely the behavior that the router is trying to prevent!
もう1つの重要な違いは、古いNDエントリの再検証に関するものです。 NDでは、ノードが使用しているすべてのエントリを定期的に再検証して、TCPが接続を終了しないように不正なエントリがタイムアウトになるようにする必要があります。その結果、一部の実装では、「プローブ」NDクエリを送信して、使用中のNDエントリを35秒ごとに検証します[RFC4861]。このようなプローブは、ユニキャスト経由で送信されます（ARPの場合とは異なります）。ただし、大規模なネットワークでは、このようなプローブにより、ルーターがこのようなクエリを多数受け取る可能性があります（つまり、ARPの場合よりもはるかに多く、そのような動作を指定しません）。残念ながら、（セクション7.1で説明されている）gratuitous ARPを送信するIPv4軽減技術はIPv6では機能しません。 ND仕様では、NDの「更新」が不要な場合、NDエントリに「有効」のマークを付けることはできないと明記されています。むしろ、そのようなエントリは「プローブ」とマークされ、これにより受信ノードが（最終的に）プローブを送信側に生成し直します。この場合、これはまさにルーターが回避しようとしている動作です。
Routers implementing Neighbor Unreachability Discovery (NUD) (for neighboring destinations) will need to process neighbor cache state changes such as transitioning entries from REACHABLE to STALE. How this capability is implemented may impact the scalability of ND on a router. For example, one possible implementation is to have the forwarding operation detect when an ND entry is referenced that needs to transition from REACHABLE to STALE, by signaling an event that would need to be processed by the software processor. Such an implementation could increase the load on the service processor in much the same way that high rates of ARP requests have led to problems on some routers.
Neighbor Unreachability Discovery（NUD）を実装するルーター（近隣の宛先の場合）は、REACHABLEからSTALEへのエントリの移行など、近隣のキャッシュ状態の変更を処理する必要があります。この機能の実装方法は、ルーターのNDのスケーラビリティに影響を与える可能性があります。たとえば、1つの可能な実装は、ソフトウェアプロセッサで処理する必要のあるイベントを通知することにより、REACHABLEからSTALEに遷移する必要があるNDエントリが参照されたときに転送操作を検出することです。このような実装では、一部のルーターでARP要求が頻繁に発生して問題が発生したのと同じように、サービスプロセッサの負荷が増加する可能性があります。
It should be noted that ND does not require the sending of probes in all cases. Section 7.3.1 of [RFC4861] describes a technique whereby hints from TCP can be used to verify that an existing ND entry is working fine and does not need to be revalidated.
NDはすべてのケースでプローブの送信を必要としないことに注意してください。 [RFC4861]のセクション7.3.1は、TCPからのヒントを使用して、既存のNDエントリが正常に機能しており、再検証する必要がないことを確認できる手法について説明しています。
Finally, IPv6 and IPv4 are often run simultaneously and in parallel on the same network, i.e., in dual-stack mode. In such environments, the IPv4 and IPv6 issues enumerated above compound each other.
最後に、IPv6とIPv4は多くの場合、同じネットワーク上で同時に実行されます（つまり、デュアルスタックモード）。このような環境では、上記で列挙されたIPv4とIPv6の問題が互いに複雑になります。
L2 switches maintain L2 MAC address forwarding tables for all sources and destinations traversing the switch. These tables are populated through learning and are used to forward L2 frames to their correct destination. The larger the L2 domain, the larger the tables have to be. While in theory a switch only needs to keep track of addresses it is actively using (sometimes called "conversational learning"), switches flood broadcast frames (e.g., from ARP), multicast frames (e.g., from Neighbor Discovery), and unicast frames to unknown destinations. Switches add entries for the source addresses of such flooded frames to their forwarding tables. Consequently, MAC address table size can become a problem as the size of the L2 domain increases. The table size problem is made worse with VMs, where a single physical machine now hosts many VMs (in the 10's today, but growing rapidly as the number of cores per CPU increases), since each VM has its own MAC address that is visible to switches.
L2スイッチは、スイッチを通過するすべての送信元と宛先のL2 MACアドレス転送テーブルを維持します。これらのテーブルは学習を通じて入力され、L2フレームを正しい宛先に転送するために使用されます。 L2ドメインが大きいほど、テーブルを大きくする必要があります。理論的には、スイッチはアクティブに使用しているアドレス（「会話型学習」と呼ばれることもあります）を追跡するだけでよく、フラッドブロードキャストフレーム（ARPなど）、マルチキャストフレーム（近隣探索など）、およびユニキャストフレームを未知の目的地。スイッチは、このようなフラッディングされたフレームの送信元アドレスのエントリを転送テーブルに追加します。したがって、L2ドメインのサイズが大きくなると、MACアドレステーブルのサイズが問題になる可能性があります。テーブルサイズの問題はVMで悪化します。VMは1つの物理マシンで多数のVMをホストするようになりました（現在は10ですが、CPUあたりのコア数が増えるにつれて急速に増加しています）。スイッチ。
When L3 extends all the way to access switches (see Section 6.4.1), the size of MAC address tables in switches is not generally a problem. When L3 extends only to aggregation switches (see Section 6.4.2), however, MAC table size limitations can be a real issue.
L3がスイッチにアクセスするまで伸びている場合（セクション6.4.1を参照）、スイッチ内のMACアドレステーブルのサイズは一般的に問題になりません。ただし、L3が集約スイッチのみに拡張される場合（セクション6.4.2を参照）、MACテーブルサイズの制限が実際の問題になることがあります。
This document has outlined a number of issues related to address resolution in large data centers. In particular, this document has described different scenarios where such issues might arise and what these potential issues are, along with outlining fundamental factors that cause them. It is hoped that describing specific pain points will facilitate a discussion as to whether they should be addressed and how best to address them.
このドキュメントでは、大規模なデータセンターでのアドレス解決に関連する多くの問題について概説しました。特に、このドキュメントでは、このような問題が発生する可能性のあるさまざまなシナリオと、これらの潜在的な問題が何であるか、およびそれらを引き起こす基本的な要因について概説しました。特定の問題点を説明することで、それらに対処する必要があるかどうか、およびどのように対処するのが最善であるかについての議論が容易になることが期待されます。
This document has been significantly improved by comments from Manav Bhatia, David Black, Stewart Bryant, Ralph Droms, Linda Dunbar, Donald Eastlake, Wesley Eddy, Anoop Ghanwani, Joel Halpern, Sue Hares, Pete Resnick, Benson Schliesser, T. Sridhar, and Lucy Yong. Igor Gashinsky deserves additional credit for highlighting some of the ARP-related pain points and for clarifying the difference between what the standards require and what some router vendors have actually implemented in response to operator requests.
このドキュメントは、Manav Bhatia、David Black、Stewart Bryant、Ralph Droms、Linda Dunbar、Donald Eastlake、Wesley Eddy、Anoop Ghanwani、Joel Halpern、Sue Hares、Pete Resnick、Benson Schliesser、T。Sridhar、およびルーシー・ヨン。 Igor Gashinskyは、ARP関連のいくつかの問題点を強調し、標準に必要なものと一部のルーターベンダーがオペレーターの要求に応じて実際に実装したものとの違いを明確にするための追加のクレジットに値します。
This document does not create any security implications nor does it have any security implications. The security vulnerabilities in ARP are well known, and this document does not change or mitigate them in any way. Security considerations for Neighbor Discovery are discussed in [RFC4861] and [RFC6583].
このドキュメントは、セキュリティに影響を与えることも、セキュリティに影響を与えることもありません。 ARPのセキュリティの脆弱性はよく知られており、このドキュメントはそれらを変更したり緩和したりすることはありません。近隣探索のセキュリティに関する考慮事項は、[RFC4861]および[RFC6583]で説明されています。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792] Postel、J。、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、1981年9月。
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982.
[RFC0826] Plummer、D。、「イーサネットアドレス解決プロトコル：またはネットワークプロトコルアドレスを48ビットのイーサネットアドレスに変換してイーサネットハードウェアで送信する」、STD 37、RFC 826、1982年11月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R。、「インターネットホストの要件-通信層」、STD 3、RFC 1122、1989年10月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]ベイカー、F。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、2007年9月。
[RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, July 2008.
[RFC5227] Cheshire、S。、「IPv4 Address Conflict Detection」、RFC 5227、2008年7月。
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational Neighbor Discovery Problems", RFC 6583, March 2012.
[RFC6583] Gashinsky、I.、Jaeggli、J。、およびW. Kumari、「Operational Neighbor Discovery Problems」、RFC 6583、2012年3月。
Authors' Addresses
著者のアドレス
Thomas Narten IBM Corporation 3039 Cornwallis Ave. PO Box 12195 Research Triangle Park, NC 27709-2195 USA
Thomas Narten IBM Corporation 3039 Cornwallis Ave. PO Box 12195 Research Triangle Park、NC 27709-2195 USA
EMail: narten@us.ibm.com
Manish Karir Merit Network Inc.
マニッシュカリルメリットネットワーク
EMail: mkarir@merit.edu
Ian Foo Huawei Technologies
Ian Foo Huawei Technologies
EMail: Ian.Foo@huawei.com