Independent Submission Y. Nachum
Request for Comments: 7586
Category: Experimental L. Dunbar
ISSN: 2070-1721 Huawei
I. Yerushalmi
T. Mizrahi
Marvell
June 2015
Independent Submission Y. Nachum
Request for Comments: 7586
Category: Experimental L. Dunbar
ISSN: 2070-1721 Huawei
I. Yerushalmi
T. Mizrahi
Marvell
June 2015
The Scalable Address Resolution Protocol (SARP) for Large Data Centers
大型数据中心的可扩展地址解析协议（SARP）
Abstract
摘要
This document introduces the Scalable Address Resolution Protocol (SARP), an architecture that uses proxy gateways to scale large data center networks. SARP is based on fast proxies that significantly reduce switches' Filtering Database (FDB) table sizes and reduce impact of ARP and Neighbor Discovery (ND) on network elements in an environment where hosts within one subnet (or VLAN) can spread over various locations. SARP is targeted for massive data centers with a significant number of Virtual Machines (VMs) that can move across various physical locations.
本文档介绍可扩展地址解析协议（SARP），这是一种使用代理网关来扩展大型数据中心网络的体系结构。在一个子网（或VLAN）内的主机可以分布在不同位置的环境中，SARP基于快速代理，可显著减少交换机的过滤数据库（FDB）表大小，并减少ARP和邻居发现（ND）对网络元素的影响。SARP面向具有大量虚拟机（VM）的大型数据中心，这些虚拟机可以跨各种物理位置移动。
Independent Submissions Editor Note
独立意见书编者注
This is an Experimental document; that experiment will end two years after the RFC is published. At that point, the RFC authors will attempt to determine how widely SARP has been implemented and used.
这是一份实验性文件；该实验将在RFC出版两年后结束。届时，RFC作者将试图确定SARP的实施和使用范围。
IESG Note
IESG注释
The IESG notes that the problems described in RFC 6820 can already be addressed through the simple combination of existing standardized or other published techniques including Layer 2 VPN (RFC 4664), proxy ARP (RFC 925), proxy Neighbor Discovery (RFC 4389), IGMP and MLD snooping (RFC 4541), and ARP mediation for IP interworking of Layer 2 VPNs (RFC 6575).
IESG指出，RFC 6820中描述的问题已经可以通过现有标准化或其他已发布技术的简单组合来解决，包括第2层VPN（RFC 4664）、代理ARP（RFC 925）、代理邻居发现（RFC 4389）、IGMP和MLD窥探（RFC 4541）以及用于第2层VPN IP互通的ARP中介（RFC6575）。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见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/rfc7586.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7586.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................3
1.1. SARP Motivation ............................................4
1.2. SARP Overview ..............................................7
1.3. SARP Deployment Options ....................................8
1.4. Comparison with Existing Solutions .........................9
2. Terms and Abbreviations Used in This Document ..................10
3. SARP: Theory of Operation ......................................11
3.1. Control Plane: ARP/ND .....................................11
3.1.1. ARP/NS Request for a Local VM ......................11
3.1.2. ARP/NS Request for a Remote VM .....................12
3.1.3. Gratuitous ARP and Unsolicited Neighbor
Advertisement (UNA) ................................13
3.2. Data Plane: Packet Transmission ...........................13
3.2.1. Local Packet Transmission ..........................13
3.2.2. Packet Transmission between Sites ..................13
3.3. VM Migration ..............................................14
3.3.1. VM Local Migration .................................14
3.3.2. VM Migration from One Site to Another ..............14
3.3.2.1. Impact on IP-to-MAC Mapping Cache
Table of Migrated VMs .....................16
3.4. Multicast and Broadcast ...................................17
3.5. Non-IP Packet .............................................17
3.6. High Availability and Load Balancing ......................17
3.7. SARP Interaction with Overlay Networks ....................18
4. Security Considerations ........................................18
5. References .....................................................19
5.1. Normative References ......................................19
5.2. Informative References ....................................20
Acknowledgments ...................................................21
Authors' Addresses ................................................21
1. Introduction ....................................................3
1.1. SARP Motivation ............................................4
1.2. SARP Overview ..............................................7
1.3. SARP Deployment Options ....................................8
1.4. Comparison with Existing Solutions .........................9
2. Terms and Abbreviations Used in This Document ..................10
3. SARP: Theory of Operation ......................................11
3.1. Control Plane: ARP/ND .....................................11
3.1.1. ARP/NS Request for a Local VM ......................11
3.1.2. ARP/NS Request for a Remote VM .....................12
3.1.3. Gratuitous ARP and Unsolicited Neighbor
Advertisement (UNA) ................................13
3.2. Data Plane: Packet Transmission ...........................13
3.2.1. Local Packet Transmission ..........................13
3.2.2. Packet Transmission between Sites ..................13
3.3. VM Migration ..............................................14
3.3.1. VM Local Migration .................................14
3.3.2. VM Migration from One Site to Another ..............14
3.3.2.1. Impact on IP-to-MAC Mapping Cache
Table of Migrated VMs .....................16
3.4. Multicast and Broadcast ...................................17
3.5. Non-IP Packet .............................................17
3.6. High Availability and Load Balancing ......................17
3.7. SARP Interaction with Overlay Networks ....................18
4. Security Considerations ........................................18
5. References .....................................................19
5.1. Normative References ......................................19
5.2. Informative References ....................................20
Acknowledgments ...................................................21
Authors' Addresses ................................................21
This document describes a proxy gateway technique, called the Scalable Address Resolution Protocol (SARP), which reduces switches' Filtering Database (FDB) size and ARP/Neighbor Discovery impact on network elements in an environment where hosts within one subnet (or VLAN) can spread over various access domains in data centers.
本文档描述了一种称为可扩展地址解析协议（SARP）的代理网关技术，该技术可以在一个子网（或VLAN）内的主机可以分布在数据中心的各个访问域的环境中，减少交换机的过滤数据库（FDB）大小和ARP/邻居发现对网络元素的影响。
The main idea of SARP is to represent all VMs (or hosts) under each access domain by the MAC address of their corresponding access node (or aggregation node). For example (Figure 1), when host A in the west site needs to communicate with host B, which is on the same VLAN but connected to a different access domain (east site), SARP requires host A to use the MAC address of SARP proxy 2, rather than the address of host B. By doing so, switches in each domain do not need
SARP的主要思想是通过其相应的访问节点（或聚合节点）的MAC地址来表示每个访问域下的所有VM（或主机）。例如（图1），当west站点中的主机A需要与主机B通信时，主机B位于同一VLAN上，但连接到不同的访问域（east站点），SARP要求主机A使用SARP proxy 2的MAC地址，而不是主机B的地址。这样，每个域中的交换机就不需要
to maintain a list of MAC addresses for all the VMs (hosts) in different access domains; every switch only needs to be familiar with MAC addresses that reside in the current domain, and addresses of remote SARP proxy gateways. Therefore, the switches' FDB size is limited regardless of the number of access domains.
维护不同访问域中所有VM（主机）的MAC地址列表；每个交换机只需要熟悉驻留在当前域中的MAC地址，以及远程SARP代理网关的地址。因此，无论访问域的数量如何，交换机的FDB大小都是有限的。
+-------+ +-------+ _ __ +-------+ +-------+
| | | SARP | / \_/ \_ | SARP | | |
|host A |<===>| proxy |<=>\_ \<==>| proxy |<===>|host B |
| | | 1 | / _/ | 2 | | |
+-------+ +-------+ \__ _/ +-------+ +-------+
\_/
<------West Site------> <------East Site------>
+-------+ +-------+ _ __ +-------+ +-------+
| | | SARP | / \_/ \_ | SARP | | |
|host A |<===>| proxy |<=>\_ \<==>| proxy |<===>|host B |
| | | 1 | / _/ | 2 | | |
+-------+ +-------+ \__ _/ +-------+ +-------+
\_/
<------West Site------> <------East Site------>
Figure 1: A Brief Overview of SARP
图1:SARP的简要概述
[RFC6820] discusses the impacts and scaling issues that arise in data center networks when subnets span across multiple Layer 2 / Layer 3 (L2/L3) boundary routers.
[RFC6820]讨论了当子网跨越多个第2层/第3层（L2/L3）边界路由器时，数据中心网络中出现的影响和扩展问题。
Unfortunately, when the combined number of VMs (or hosts) in all those subnets is large, it can lead to an explosion of the size of the switches' MAC address table and a heavy impact on network elements.
不幸的是，当所有这些子网中的VM（或主机）的总数很大时，可能会导致交换机MAC地址表的大小爆炸，并对网络元素造成严重影响。
There are four major issues associated with subnets spanning across multiple L2/L3 boundary router ports:
跨越多个L2/L3边界路由器端口的子网存在四个主要问题：
1) Explosion of the size of the intermediate switches' MAC address table (FDB).
1) 中间交换机MAC地址表（FDB）大小的爆炸。
When hosts in a VLAN (or subnet) span across multiple access domains and each access domain has hosts belonging to different VLANs, each access switch has to enable multiple VLANs. Thus, those access switches are exposed to all MAC addresses across all VLANs.
当VLAN（或子网）中的主机跨多个访问域，并且每个访问域都有属于不同VLAN的主机时，每个访问交换机必须启用多个VLAN。因此，这些访问交换机暴露于所有VLAN中的所有MAC地址。
For example, for an access switch with 40 attached physical servers, where each server has 100 VMs, the access switch has 4,000 attached MAC addresses. If hosts/VMs can indeed be moved anywhere, the worst case for the Access Switch is when all those 4,000 VMs belong to different VLANs, i.e., the access switch has 4000 VLANs enabled. If each VLAN has 200 hosts, this access switch's MAC address table potentially has 200 * 4,000 = 800,000 entries.
例如，对于连接有40台物理服务器的接入交换机，其中每台服务器有100个VM，接入交换机有4000个连接的MAC地址。如果主机/虚拟机确实可以移动到任何地方，那么访问交换机的最坏情况是，所有这些4000个虚拟机都属于不同的VLAN，即，访问交换机启用了4000个VLAN。如果每个VLAN有200台主机，则此访问交换机的MAC地址表可能有200*4000=800000个条目。
It is important to note that the example above is relevant regardless of whether IPv4 or IPv6 is used.
需要注意的是，无论使用IPv4还是IPv6，上面的示例都是相关的。
The example illustrates a scenario that is worse than what today's L2/L3 gateway has to face. In today's environment, where each subnet is limited to a few access switches, the number of MAC addresses the gateway has to learn is of a significantly smaller scale.
该示例演示了一个比当前的L2/L3网关所面临的情况更糟糕的场景。在当今的环境中，每个子网仅限于几个接入交换机，网关必须学习的MAC地址数量要小得多。
2) ARP/ND processing load impact on the L2/L3 boundary routers.
2) ARP/ND处理负载影响L2/L3边界路由器。
All VMs periodically send NDs to their corresponding gateway nodes to get gateway nodes' MAC addresses. When the combined number of VMs across all the VLANs is large, processing the responses to the ND requests from those VMs can easily exhaust the gateway's CPU utilization.
所有虚拟机定期向其对应的网关节点发送NDs，以获取网关节点的MAC地址。当跨所有VLAN的虚拟机总数很大时，处理来自这些虚拟机的ND请求的响应很容易耗尽网关的CPU利用率。
An L2/L3 boundary router could be hit with ARP/ND twice when the originating and destination stations are in different subnets attached to the same router and when those hosts do not communicate with external peers very frequently. The first hit is when the originating station in subnet 1 initiates an ARP/ND request to the L2/L3 boundary router. The second hit is when the L2/L3 boundary router initiates an ARP/ND request to the target in subnet 2 if the target is not in the router's ARP/ND cache.
当始发站和目的站位于连接到同一路由器的不同子网中时，以及当这些主机不经常与外部对等方通信时，L2/L3边界路由器可能会被ARP/ND击中两次。第一次命中是当子网1中的始发站向L2/L3边界路由器发起ARP/ND请求时。第二个命中是，如果目标不在路由器的ARP/ND缓存中，二级/三级边界路由器向子网2中的目标发起ARP/ND请求。
3) In IPv4, every end station in a subnet receives ARP broadcast messages from all other end stations in the subnet. IPv6 ND has eliminated this issue by using multicast.
3) 在IPv4中，子网中的每个终端站都从子网中的所有其他终端站接收ARP广播消息。IPv6 ND通过使用多播消除了这个问题。
However, most devices support a limited number of multicast addresses, due to the scaling of multicast filtering. Once the number of multicast addresses exceeds the multicast filter limit, the multicast addresses have to be processed by the devices' CPUs (i.e., the slow path).
然而，由于多播过滤的可伸缩性，大多数设备支持有限数量的多播地址。一旦多播地址的数量超过多播过滤器限制，多播地址必须由设备的CPU处理（即，慢路径）。
It is less of an issue in data centers without VM mobility, since each port is only dedicated to one (or a small number of) VLANs. Thus, the number of multicast addresses hitting each port is significantly lower.
在没有虚拟机移动性的数据中心，这不是什么问题，因为每个端口只专用于一个（或少数）VLAN。因此，到达每个端口的多播地址的数量显著减少。
4) The ARP/ND messages are flooded to many physical link segments that can reduce the bandwidth utilization for user traffic.
4) ARP/ND消息被淹没到许多物理链路段，这会降低用户流量的带宽利用率。
ARP/ND flooding is, in most cases, an insignificant issue in today's data center networks, as the majority of data center servers are shifting towards 1G or 10G Ethernet ports. The bandwidth used by ARP/ND, even when flooded to all physical links,
在大多数情况下，ARP/ND洪泛在当今的数据中心网络中是一个无关紧要的问题，因为大多数数据中心服务器正在转向1G或10G以太网端口。ARP/ND所使用的带宽，即使在淹没到所有物理链路时，
becomes negligible compared to the link bandwidth. Furthermore, IGMP and Multicast Listener Discovery (MLD) snooping [RFC4541] can further reduce the ND multicast traffic to some physical link segments.
与链路带宽相比变得微不足道。此外，IGMP和多播侦听器发现（MLD）侦听[RFC4541]可以进一步将ND多播流量减少到某些物理链路段。
Statistics gathered by Merit Network [ARMDStats] have shown that the major impact of a large number of VMs in data centers is on the L2/L3 boundary routers, i.e., issue 2 above. An L2/L3 boundary router could be hit with ARP/ND twice when 1) the originating and destination stations are in different subnets attached to the same router, and 2) those hosts do not communicate with external peers often enough.
Merit Network[ARMDStats]收集的统计数据表明，数据中心中大量虚拟机的主要影响在于L2/L3边界路由器，即上文第2个问题。当1）始发站和目的站位于连接到同一路由器的不同子网中，以及2）这些主机与外部对等方通信不够频繁时，L2/L3边界路由器可能会被ARP/ND击中两次。
Overlay approaches, e.g., [RFC7364], can hide addresses of hosts (VMs) in the core, but they do not prevent the MAC address table explosion problem (issue 1) unless the Network Virtualization Edge (NVE) is on a server.
覆盖方法（例如[RFC7364]）可以在核心中隐藏主机（VM）的地址，但它们不能防止MAC地址表爆炸问题（问题1），除非网络虚拟化边缘（NVE）位于服务器上。
The scaling practices documented in [RFC7342] can only reduce some ARP impact on L2/L3 boundary routers in some scenarios, but not all.
[RFC7342]中记录的扩展实践只能在某些情况下减少对L2/L3边界路由器的一些ARP影响，但并非全部。
In order to protect router CPUs from being overburdened by target resolution requests, some routers rate-limit the target MAC resolution requests to the router's CPU. When the rate limit is exceeded, the incoming data frames are dropped. In traditional data centers, this issue is less significant, since the number of hosts attached to one L2/L3 boundary router is limited by the number of physical ports of the switches/routers. When servers are virtualized to support 30+ VMs, the number of hosts under one router can grow by a factor of 30+. Furthermore, in traditional data center networks, each subnet is neatly bound to a limited number of server racks, i.e., switches only need to be familiar with MAC addresses of hosts that reside in this small number of subnets. In contemporary data center networks, as subnets are spread across many server racks, switches are exposed to VLAN/MAC addresses of many subnets, greatly increasing the size of switches' FDB tables.
为了保护路由器CPU不因目标解析请求而负担过重，一些路由器将目标MAC解析请求限制在路由器的CPU上。超过速率限制时，将丢弃传入的数据帧。在传统数据中心中，这个问题不太重要，因为连接到一个L2/L3边界路由器的主机数量受到交换机/路由器物理端口数量的限制。当服务器虚拟化以支持30多个虚拟机时，一个路由器下的主机数量可以增加30多个。此外，在传统的数据中心网络中，每个子网都被整齐地绑定到数量有限的服务器机架上，即交换机只需要熟悉驻留在这少量子网中的主机的MAC地址。在当代数据中心网络中，由于子网分布在许多服务器机架上，交换机暴露于许多子网的VLAN/MAC地址，从而大大增加了交换机的FDB表的大小。
The solution proposed in this document can eliminate or reduce the likelihood of inter-subnet data frames being dropped and reduce the number of host MAC addresses that intermediate switches are exposed to, thus reducing switches' FDB table sizes.
本文档中提出的解决方案可以消除或降低子网间数据帧被丢弃的可能性，并减少中间交换机暴露的主机MAC地址的数量，从而减少交换机的FDB表大小。
The SARP approach uses proxy gateways to address the problems discussed above.
SARP方法使用代理网关来解决上述问题。
Note: The guidelines to proxy developers [RFC4389] have been carefully considered for SARP. Section 3.3 discusses how SARP works when VMs are moved from one segment to another.
注：SARP已仔细考虑代理开发人员指南[RFC4389]。第3.3节讨论了当虚拟机从一个网段移动到另一个网段时，SARP是如何工作的。
In order to enable VMs to be moved across servers while ensuring their MAC/IP addresses remain unchanged, the Layer 2 network (e.g., VLAN) that interconnects those VMs may spread across different server racks, different rows of server racks, or even different data center sites.
为了使虚拟机能够跨服务器移动，同时确保其MAC/IP地址保持不变，互连这些虚拟机的第2层网络（如VLAN）可能分布在不同的服务器机架、不同的服务器机架行，甚至不同的数据中心站点。
A multisite data center network is comprised of two main building blocks: an interconnecting segment and an access segment. While the access network is, in most cases, a Layer 2 network, the interconnecting segment is not necessarily a Layer 2 network.
多站点数据中心网络由两个主要构建块组成：互连段和接入段。虽然接入网络在大多数情况下是第2层网络，但互连段不一定是第2层网络。
The SARP proxies are located at the boundaries where the access segment connects to its interconnecting segment. The boundary node can be a hypervisor virtual switch, a top-of-rack switch, an aggregation switch (or end-of-row switch), or a data center core switch. Figure 2 depicts an example of two remote data centers that are managed as a single, flat Layer 2 domain. SARP proxies are implemented at the edge devices connecting the data center to the transport network. SARP significantly reduces the ARP/ND transmissions over the interconnecting network.
SARP代理位于接入段与其互连段连接的边界处。边界节点可以是虚拟机监控程序虚拟交换机、机架顶部交换机、聚合交换机（或行末交换机）或数据中心核心交换机。图2描述了两个远程数据中心的示例，它们作为一个单一的平面第2层域进行管理。SARP代理在连接数据中心和传输网络的边缘设备上实现。SARP显著减少了互连网络上的ARP/ND传输。
*-------------------*
| |
+-------| Interconnecting |-------+
| | network | |
| *-------------------* |
| |
*-----------------* *----------------*
| SARP Proxies | | SARP Proxies |
*-----------------* *----------------*
| | | |
*-------* *-------* *-------* *-------*
|Access | |Access | |Access | |Access |
*-------* *-------* *-------* *-------*
|
*----------*
|Hypervisor|
*----------*
|
*--------*
|Virtual |
|Machine |
*--------*
*-------------------*
| |
+-------| Interconnecting |-------+
| | network | |
| *-------------------* |
| |
*-----------------* *----------------*
| SARP Proxies | | SARP Proxies |
*-----------------* *----------------*
| | | |
*-------* *-------* *-------* *-------*
|Access | |Access | |Access | |Access |
*-------* *-------* *-------* *-------*
|
*----------*
|Hypervisor|
*----------*
|
*--------*
|Virtual |
|Machine |
*--------*
(West Site) (East Site)
（西址）（东址）
Figure 2: SARP: Network Architecture Example
图2:SARP：网络架构示例
SARP deployment is tightly coupled with the data center architecture. SARP proxies are located at the point where the Layer 2 infrastructure connects to its Layer 2 cloud using overlay networks. SARP proxies can be located at the data center edge (as Figure 2 depicts), data center core, or data center aggregation (denoted by "Agg" in the figure). SARP can also be implemented by the hypervisor (as Figure 3 depicts).
SARP部署与数据中心体系结构紧密耦合。SARP代理位于第2层基础设施使用覆盖网络连接到其第2层云的位置。SARP代理可以位于数据中心边缘（如图2所示）、数据中心核心或数据中心聚合（图中用“Agg”表示）。SARP也可以由hypervisor实现（如图3所示）。
To simplify the description, we will focus on data centers that are managed as a single, flat Layer 2 network, where SARP proxies are located at the boundary where the data center connects to the transport network (as Figure 2 depicts).
为了简化描述，我们将重点介绍作为单个平面第2层网络管理的数据中心，其中SARP代理位于数据中心连接到传输网络的边界处（如图2所示）。
*-------------------*
| |
+-------| TRANSPORT |-------+
| | | |
| *-------------------* |
| |
*-----------------* *----------------*
| Edge Device | | Edge Device |
*-----------------* *----------------*
| |
*-----------------* *----------------*
| Core | | Core |
*-----------------* *----------------*
| | | |
*-------* *-------* *-------* *-------*
| Agg | | Agg | | Agg | | Agg |
*-------* *-------* *-------* *-------*
|
*----------*
|Hypervisor|
*----------*
*-------------------*
| |
+-------| TRANSPORT |-------+
| | | |
| *-------------------* |
| |
*-----------------* *----------------*
| Edge Device | | Edge Device |
*-----------------* *----------------*
| |
*-----------------* *----------------*
| Core | | Core |
*-----------------* *----------------*
| | | |
*-------* *-------* *-------* *-------*
| Agg | | Agg | | Agg | | Agg |
*-------* *-------* *-------* *-------*
|
*----------*
|Hypervisor|
*----------*
(West Site) (East Site)
（西址）（东址）
Figure 3: SARP Deployment Options
图3:SARP部署选项
The IETF has developed several mechanisms to address issues associated with Layer 2 networks over multiple geographic locations, for example, Layer 2 VPN [RFC4664], proxy ARP [RFC925] [ProxyARP], proxy Neighbor Discovery [RFC4389], IGMP and MLD snooping [RFC4541], and ARP mediation for IP interworking of Layer 2 VPNs [RFC6575].
IETF开发了几种机制来解决与多个地理位置上的第二层网络相关的问题，例如，第二层VPN[RFC4664]、代理ARP[RFC925][ProxyARP]、代理邻居发现[RFC4389]、IGMP和MLD窥探[RFC4541]以及第二层VPN的IP互通的ARP中介[RFC6575]。
However, all those solutions work well when hosts within one subnet are placed together under one access domain, so that the intermediate switches in each access domain are only exposed to host addresses from a limited number of subnets. SARP is to provide a solution when hosts within one subnet are spread across multiple access domains, and each access domain has hosts from many subnets. Under this environment, the intermediate switches in each access domain are exposed to combined hosts of all the subnets that are enabled by the access domain.
但是，当一个子网内的主机放在一个访问域下时，所有这些解决方案都能很好地工作，因此每个访问域中的中间交换机只暴露于有限数量子网的主机地址。当一个子网内的主机分布在多个访问域中，并且每个访问域都有来自多个子网的主机时，SARP提供了一种解决方案。在这种环境下，每个接入域中的中间交换机将暴露给接入域启用的所有子网的组合主机。
ARP: Address Resolution Protocol [ARP]
地址解析协议
FDB: Filtering Database, which is used for Layer 2 switches [802.1Q]. Layer 2 switches flood data frames when the Destination Address (DA) is not in the FDB, whereas routers drop data frames when the DA is not in the Forwarding Information Base (FIB). That is why the FDB is used for Layer 2 switches.
FDB：筛选数据库，用于第2层交换机[802.1Q]。当目标地址（DA）不在FDB中时，第2层交换泛洪数据帧，而当DA不在转发信息库（FIB）中时，路由器丢弃数据帧。这就是为什么FDB用于第2层交换机的原因。
FIB: Forwarding Information Base
转发信息库
Hypervisor: a software layer that creates and runs virtual machines on a server
Hypervisor：在服务器上创建和运行虚拟机的软件层
IP-D: IP address of the destination virtual machine
IP-D：目标虚拟机的IP地址
IP-S: IP address of the source virtual machine
IP-S：源虚拟机的IP地址
MAC-D: MAC address of the destination virtual machine
MAC-D：目标虚拟机的MAC地址
MAC-E: MAC address of the East Proxy SARP Device
MAC-E:East代理SARP设备的MAC地址
MAC-S: MAC address of the source virtual machine
MAC-S：源虚拟机的MAC地址
NA: IPv6 ND's Neighbor Advertisement
NA:IPv6 ND的邻居广告
ND: IPv6 Neighbor Discovery Protocol [ND]. In this document, ND also refers to Neighbor Solicitation, Neighbor Advertisement, and Unsolicited Neighbor Advertisement messages defined by RFC 4861.
ND:IPv6邻居发现协议[ND]。在本文档中，ND还指RFC 4861定义的邻居请求、邻居公告和未经请求的邻居公告消息。
NS: IPv6 ND's Neighbor Solicitation
NS:IPv6 ND的邻居请求
SARP Proxy: The components that participate in SARP
SARP代理：参与SARP的组件
UNA: IPv6 ND's Unsolicited Neighbor Advertisement [ND]
UNA:IPv6 ND的主动邻居广告[ND]
VM: Virtual Machine
虚拟机
This section describes the ARP/ND procedure scenarios. The first scenario addresses a case where both the source and destination VMs reside in the same access segment. In the second scenario, the source VM is in the local access segment and the destination VM is located at the remote access segment.
本节介绍ARP/ND过程场景。第一个场景解决了源VM和目标VM都位于同一访问段中的情况。在第二个场景中，源VM位于本地访问段，目标VM位于远程访问段。
In all scenarios, the VMs (source and destination) share the same L2 broadcast domain.
在所有场景中，VM（源和目标）共享相同的L2广播域。
When source and destination VMs are located at the same access segment (Figure 4), the address resolution process is as described in [ARP] and [ND]; host A sends an ARP request or an IPv6 Neighbor Solicitation (NS) to learn the IP-to-MAC mapping of host B, and it receives a reply from host B with the IP-D to MAC-D mapping.
当源和目标VM位于同一个访问段（图4）时，地址解析过程如[ARP]和[ND]所述；主机A发送ARP请求或IPv6邻居请求（NS）以了解主机B的IP到MAC映射，并从主机B接收具有IP-D到MAC-D映射的回复。
+-------+ _ __ +-------+ _ __
|host A | / \_/ \_ | SARP | / \_/ \_
| IP-S |<--->\_access \<==>| proxy |<===>\_interc.\
| MAC-S | /network_/ | 1 | /network_/
+-------+ +->\__ _/ +-------+ \__ _/
| \_/ \_/
+-------+ |
|host B |<-+
| IP-D |
| MAC-D |
+-------+
+-------+ _ __ +-------+ _ __
|host A | / \_/ \_ | SARP | / \_/ \_
| IP-S |<--->\_access \<==>| proxy |<===>\_interc.\
| MAC-S | /network_/ | 1 | /network_/
+-------+ +->\__ _/ +-------+ \__ _/
| \_/ \_/
+-------+ |
|host B |<-+
| IP-D |
| MAC-D |
+-------+
<--------------West Site------------>
<--------------West Site------------>
Figure 4: SARP: Two Hosts in the Same Access Segment
图4:SARP：同一接入段中的两台主机
When the source and destination VMs are located at different access segments, the address resolution process is as follows.
当源和目标VM位于不同的访问段时，地址解析过程如下所示。
+-------+ +-------+ _ __ +-------+ +-------+
|host A | | SARP | / \_/ \_ | SARP | |host B |
| IP-S |<===>|proxy 1|<=>\_ \<==>|proxy 2|<===>| IP-D |
| MAC-S | | MAC-W | / _/ | MAC-E | | MAC-D |
+-------+ +-------+ \__ _/ +-------+ +-------+
\_/
<------West Site------> <------East Site------>
+-------+ +-------+ _ __ +-------+ +-------+
|host A | | SARP | / \_/ \_ | SARP | |host B |
| IP-S |<===>|proxy 1|<=>\_ \<==>|proxy 2|<===>| IP-D |
| MAC-S | | MAC-W | / _/ | MAC-E | | MAC-D |
+-------+ +-------+ \__ _/ +-------+ +-------+
\_/
<------West Site------> <------East Site------>
Figure 5: SARP: Two Hosts That Reside in Different Segments
图5:SARP：驻留在不同段中的两台主机
In the example illustrated in Figure 5, the source VM is located at the west access segment and the destination VM is located at the east access segment.
在图5所示的示例中，源VM位于西部访问段，目标VM位于东部访问段。
When host A sends an ARP/NS request to find out the IP-to-MAC mapping of host B:
当主机A发送ARP/NS请求以查找主机B的IP到MAC映射时：
1. If SARP proxy 1 does not have IP-D in its ARP cache, the ARP/NS request is propagated to all access segments that might have VMs in the same virtual network as the originating VM, including the east access segment.
1. 如果SARP proxy 1在其ARP缓存中没有IP-D，ARP/NS请求将传播到所有可能在与原始VM相同的虚拟网络中具有VM的访问段，包括east访问段。
2. As SARP proxy 1 forwards the ARP/NS message, it replaces the source MAC address, MAC-S, with its own MAC address, MAC-W. Thus, all switches that reside in the interconnecting segment are not exposed to MAC-S.
2. 当SARP proxy 1转发ARP/NS消息时，它将源MAC地址MAC-S替换为自己的MAC地址MAC-W。因此，位于互连段中的所有交换机不会暴露于MAC-S。
3. The ARP/NS request reaches SARP proxy 2.
3. ARP/NS请求到达SARP proxy 2。
4. If SARP proxy 2 does not have IP-D in its ARP cache, the ARP/NS request is forwarded to the east access network. Host B responds with an ARP reply (IPv4) or a Neighbor Advertisement (IPv6) to the request with MAC-D.
4. 如果SARP proxy 2在其ARP缓存中没有IP-D，则ARP/NS请求被转发到east接入网络。主机B使用MAC-D以ARP应答（IPv4）或邻居公告（IPv6）对请求进行响应。
5. When the response message reaches SARP proxy 2, it replaces MAC-D with MAC-E; thus, the response reaches SARP proxy 1 with MAC-E.
5. 当响应消息到达SARP proxy 2时，用MAC-E替换MAC-D；因此，响应通过MAC-E到达SARP代理1。
6. As SARP proxy 1 forwards the response to host A, it replaces the destination address from MAC-W to MAC-S.
6. 当SARP proxy 1将响应转发给主机A时，它将目标地址从MAC-W替换为MAC-S。
SARP Proxy ARP/ND Cache
SARP代理ARP/ND缓存
SARP proxies maintain a cache of the IP-to-MAC mapping. This cache is based on ARP/ND messages that are sent by hosts and traverse the SARP proxies.
SARP代理维护IP到MAC映射的缓存。该缓存基于主机发送的ARP/ND消息并遍历SARP代理。
In steps 1 and 4 above, if the SARP proxy has IP-D in its ARP cache, it responds with MAC-E, without forwarding the ARP/NS request.
在上面的步骤1和4中，如果SARP代理在其ARP缓存中具有IP-D，则它使用MAC-E进行响应，而不转发ARP/NS请求。
This caching approach significantly reduces the volume of the ARP/ND transmission over the network and reduces the round-trip time of ARP/ND requests.
这种缓存方法显著减少了ARP/ND在网络上的传输量，并减少了ARP/ND请求的往返时间。
When the west SARP proxy caches the IP-to-MAC mapping entries for remote VMs, the expiration timers should be set to relatively low values to prevent stale entries due to remote VMs being moved or deleted. In environments where VMs move more frequently, it is not recommended for SARP proxies to cache the IP-to-MAC mapping entries of remote VMs.
当west SARP代理缓存远程VM的IP到MAC映射条目时，应将过期计时器设置为相对较低的值，以防止由于移动或删除远程VM而导致过时条目。在虚拟机移动更频繁的环境中，不建议SARP代理缓存远程虚拟机的IP到MAC映射项。
Hosts (or VMs) send out Gratuitous ARP (IPv4) [TcpIp] and Unsolicited Neighbor Advertisement (UNA) (IPv6) messages to allow other nodes to refresh IP-to-MAC entries in their caches.
主机（或VM）发送免费的ARP（IPv4）[TcpIp]和未经请求的邻居播发（UNA）（IPv6）消息，以允许其他节点刷新其缓存中的IP到MAC条目。
The local SARP proxy processes the Gratuitous ARP or UNA message in the same way as the ARP reply or IPv6 NA, i.e., replaces the MAC addresses in the same manner.
本地SARP代理以与ARP应答或IPv6 NA相同的方式处理免费ARP或UNA消息，即以相同的方式替换MAC地址。
When a VM transmits packets to a destination VM that is located at the same site (Figure 4), the data plane is unaffected by SARP; packets are sent from (IP-S, MAC-S) to (IP-D, MAC-D).
当VM向位于同一站点的目标VM发送数据包时（图4），数据平面不受SARP的影响；数据包从（IP-S，MAC-S）发送到（IP-D，MAC-D）。
Packets that are sent between sites (Figure 5) traverse the SARP proxy of both sites.
在站点之间发送的数据包（图5）遍历两个站点的SARP代理。
A packet sent from host A to host B undergoes the following procedure:
从主机A发送到主机B的数据包经历以下过程：
1. Host A sends a packet to IP-D, and based on its ARP table, it uses the MAC addresses {MAC-E, MAC-S}.
1. 主机A向IP-D发送一个数据包，并根据其ARP表，使用MAC地址{MAC-E，MAC-S}。
2. SARP proxy 1 receives the packet and replaces the source MAC address, such that the packet includes {MAC-E, MAC-W}.
2. SARP代理1接收分组并替换源MAC地址，使得分组包括{MAC-E，MAC-W}。
3. SARP proxy 2 receives the packet and replaces the destination MAC address, and the packet is sent to host B with {MAC-D, MAC-W}.
3. SARP代理2接收该分组并替换目的地MAC地址，并且该分组被发送到主机B与{MAC-D，MAC-W}。
SARP proxy 1 replaces the source MAC address with its own, since switches in the interconnecting segment are only familiar with SARP proxy MAC addresses and are not familiar with host addresses.
由于互连段中的交换机只熟悉SARP代理MAC地址，而不熟悉主机地址，因此SARP代理1将源MAC地址替换为自己的MAC地址。
Note: it is a common security practice in data center networks to use access lists, allowing each VM to communicate only with a list of authorized peer VMs. In most cases, such access control lists are based on IP addresses and, hence, are not affected by the MAC address replacement in SARP.
注意：在数据中心网络中，使用访问列表是一种常见的安全做法，允许每个VM仅与授权对等VM列表通信。在大多数情况下，此类访问控制列表基于IP地址，因此不受SARP中MAC地址替换的影响。
When a VM migrates locally within its access segment, SARP does not require any special behavior. VM migration is resolved entirely by the Layer 2 mechanisms.
当VM在其访问段内本地迁移时，SARP不需要任何特殊行为。VM迁移完全由第2层机制解决。
This section focuses on a scenario where a VM migrates from the west site to the east site while maintaining its MAC and IP addresses.
本节重点介绍虚拟机在维护其MAC和IP地址的同时从西站迁移到东站的场景。
VM migration might affect networking elements based on their respective locations:
VM迁移可能会根据网络元素各自的位置影响它们：
- origin site (west site)
- 原点（西点）
- destination site (east site)
- 目的地（东址）
- other sites
- 其他网站
+-------+ +-------+ _ __ +-------+ +-------+
|host A | | SARP | / \_/ \_ | SARP | |host A |
| IP-D |<===>|proxy 1|<=>\_ \<==>|proxy 2|<===>| IP-D |
| MAC-D | | MAC-W | / _/ | MAC-E | | MAC-D |
+-------+ +-------+ \__ _/ +-------+ +-------+
\_/
<------West Site------> <------East Site------>
Origin Site Destination Site
+-------+ +-------+ _ __ +-------+ +-------+
|host A | | SARP | / \_/ \_ | SARP | |host A |
| IP-D |<===>|proxy 1|<=>\_ \<==>|proxy 2|<===>| IP-D |
| MAC-D | | MAC-W | / _/ | MAC-E | | MAC-D |
+-------+ +-------+ \__ _/ +-------+ +-------+
\_/
<------West Site------> <------East Site------>
Origin Site Destination Site
Figure 6: SARP: Host A Migrates from West Site to East Site
图6:SARP：主机A从西站点迁移到东站点
Origin Site
发源地
The origin site is the site where the VM resides before the migration (west site).
源站点是VM在迁移之前驻留的站点（西站点）。
Before the VM (IP=IP-D, MAC=MAC-D) is moved, all VMs at the west site that have an ARP entry of IP-D in their ARP table have the IP-D -> MAC-D mapping. VMs on other access segments have an ARP entry of IP-D -> MAC-W mapping where MAC-W is the MAC address of the SARP proxy on the west access segment.
在移动VM（IP=IP-D，MAC=MAC-D）之前，位于west站点且其ARP表中的ARP条目为IP-D的所有VM都具有IP-D->MAC-D映射。其他接入段上的虚拟机具有IP-D->MAC-W映射的ARP条目，其中MAC-W是西部接入段上SARP代理的MAC地址。
After the VM (IP-D) in the west site moves to the east site, if a Gratuitous ARP (IPv4) or an Unsolicited Neighbor Advertisement (IPv6) message is sent out by the destination hypervisor on behalf of the VM (IP-D), then the IP-to-MAC mapping cache of the VMs in all access segments is updated by IP-D -> MAC-E, where MAC-E is the MAC address of the SARP proxy on the east site. If no Gratuitous ARP or UNA message is sent out by the destination hypervisor, the IP-to-MAC cache on the VMs in the west site (and other sites) is eventually aged out.
在西站点中的VM（IP-D）移动到东站点后，如果目标虚拟机监控程序代表VM（IP-D）发送免费的ARP（IPv4）或未经请求的邻居播发（IPv6）消息，则所有访问段中的VM的IP-to-MAC映射缓存将由IP-D->MAC-E更新，其中MAC-E是east站点上SARP代理的MAC地址。如果目标虚拟机监控程序没有发送免费的ARP或UNA消息，则西部站点（和其他站点）的虚拟机上的IP到MAC缓存最终会老化。
Until the IP-to-MAC mapping cache tables are updated, the source VMs from the west site continue sending packets locally to MAC-D, and switches at the west site are still configured with the old location of MAC-D. This transient condition can be resolved by having the VM manager send out a fake Gratuitous ARP or UNA message on behalf of the destination Hypervisor. Another alternative is to have a shorter aging timer configured for the IP-to-MAC cache table.
在更新IP到MAC映射缓存表之前，来自west站点的源VM继续本地向MAC-D发送数据包，west站点的交换机仍然配置了旧的MAC-D位置。通过让VM管理器代表目标虚拟机监控程序发送一个虚假的免费ARP或UNA消息，可以解决这种暂时情况。另一种选择是为IP到MAC缓存表配置较短的老化计时器。
Destination Site
目的地
The destination site is the site to which the VM migrated, i.e., the east site in Figure 6.
目标站点是VM迁移到的站点，即图6中的east站点。
Before any Gratuitous ARP or UNA messages are sent out by the destination hypervisor, all VMs at the east site (and all other sites) might have an IP-D -> MAC-W mapping in their IP-to-MAC mapping cache. The IP-to-MAC mapping cache is updated by aging or by a Gratuitous ARP or UNA message sent by the destination hypervisor. Until the IP-to-MAC mapping caches are updated, VMs from the east site continue to send packets to MAC-W. This can be resolved by having the VM manager send out a fake Gratuitous ARP or UNA message immediately after the VM migration or by redirecting the packets from the SARP proxy of the east site back to the migrated VM by updating the destination MAC of the packets to MAC-D.
在目标虚拟机监控程序发送任何免费的ARP或UNA消息之前，east站点（和所有其他站点）的所有VM可能在其IP到MAC映射缓存中都有IP-D->MAC-W映射。IP到MAC映射缓存通过老化或目标虚拟机监控程序发送的免费ARP或UNA消息进行更新。在更新IP到MAC映射缓存之前，来自east站点的VM继续向MAC-W发送数据包。这可以通过让VM管理器在VM迁移后立即发送虚假的免费ARP或UNA消息，或者通过将数据包的目标MAC更新到MAC-D，将数据包从east站点的SARP代理重定向回迁移的VM来解决。
Other Sites
其他网站
All VMs at the other sites that have an ARP entry of IP-D in their ARP table have the IP-D -> MAC-W mapping. The ARP mapping is updated by aging or by a Gratuitous ARP message sent by the destination hypervisor of the migrated VM and modified by the SARP proxy of the east site to an IP-D -> MAC-E mapping. Until ARP tables are updated, VMs from other sites continue sending packets to MAC-W.
在其ARP表中具有IP-D ARP条目的其他站点的所有VM都具有IP-D->MAC-W映射。ARP映射通过老化或由迁移VM的目标虚拟机监控程序发送的免费ARP消息进行更新，并由east站点的SARP代理修改为IP-D->MAC-E映射。在ARP表更新之前，来自其他站点的虚拟机继续向MAC-W发送数据包。
When a VM (IP-D) is moved from one site to another, its IP-to-MAC mapping entries for VMs located at other sites (i.e., neither the east site nor the west site) are still valid, even though most guest OSs (or VMs) will refresh their IP-to-MAC cache after migration.
当虚拟机（IP-D）从一个站点移动到另一个站点时，其位于其他站点（即东站点和西站点）的虚拟机的IP到MAC映射条目仍然有效，即使大多数来宾操作系统（或虚拟机）在迁移后将刷新其IP到MAC缓存。
The migrated VM's IP-to-MAC mapping entries for VMs located at the east site, if not refreshed after migration, can be kept with no change until the ARP aging time, as these entries are mapped to MAC-E. All traffic originated from the migrated VM in its new location to VMs located at the east site traverses the SARP proxy of the east site. That SARP proxy can redirect the traffic back to the corresponding destinations on the east site. Furthermore, an ARP/UNA message sent by the SARP proxy of the east site or by the VMs on the east site can refresh the corresponding entries in the migrated VM's IP-to-MAC cache.
如果迁移后未刷新位于east站点的VM的已迁移VM的IP到MAC映射条目，则在ARP老化时间之前，这些条目可以保持不变，因为这些条目映射到MAC-E。从位于east站点的新位置的已迁移VM到位于east站点的VM的所有流量都会穿过east站点的SARP代理。该SARP代理可以将流量重定向回east站点上的相应目的地。此外，east站点的SARP代理或east站点上的VM发送的ARP/UNA消息可以刷新迁移VM的IP到MAC缓存中的相应条目。
The migrated VM's ARP entries for VMs located at the west site remain unchanged until either the ARP entries age out or new data frames are received from the remote sites. Since all MAC addresses of the VMs located at the west site are unknown at the east site, all unknown traffic from the VM is intercepted by the SARP proxy of the east site and forwarded to the SARP proxy of the west site (during the transient period before the ARP entries age out). This transient behavior is avoided if the SARP proxy has the destination IP address in its ARP cache, and, upon receiving a packet with an unknown destination MAC address, it could send a Gratuitous ARP or UNA message to the migrated VM.
在ARP条目老化或从远程站点接收到新的数据帧之前，位于西站点的虚拟机的迁移虚拟机ARP条目保持不变。由于位于西部站点的虚拟机的所有MAC地址在东部站点是未知的，因此来自虚拟机的所有未知流量都被东部站点的SARP代理截获并转发到西部站点的SARP代理（在ARP条目过期之前的过渡期内）。如果SARP代理在其ARP缓存中具有目标IP地址，并且在接收到具有未知目标MAC地址的数据包时，它可以向迁移的VM发送免费的ARP或UNA消息，则可以避免这种瞬态行为。
Note that overlay networks providing Layer 2 network virtualization services configure their edge-device MAC aging timers to be greater than the ARP request interval.
请注意，提供第2层网络虚拟化服务的覆盖网络将其边缘设备MAC老化计时器配置为大于ARP请求间隔。
Multicast and broadcast traffic is forwarded by SARP proxies as follows:
多播和广播流量由SARP代理转发，如下所示：
o SARP proxies modify the source MAC address of multicast and broadcast packets as described in Section 3.2.
o SARP代理修改多播和广播数据包的源MAC地址，如第3.2节所述。
o SARP proxies do not modify the destination MAC address of multicast and broadcast packets.
o SARP代理不会修改多播和广播数据包的目标MAC地址。
The L2/L3 boundary routers in the current document are capable of forwarding non-IP IEEE 802.1 Ethernet frames (Layer 2) without changing the MAC headers. When subnets span across multiple ports of those routers, they are still under the category of a single link, or a multi-access link model recommended by [RFC4903]. They differ from the "multi-link" subnets described in [MultLinkSub] and [RFC4903], which refer to a different physical media with the same prefix connected to a router, where the Layer 2 frames cannot be natively forwarded without changing the headers.
当前文档中的L2/L3边界路由器能够在不更改MAC报头的情况下转发非IP IEEE 802.1以太网帧（第2层）。当子网跨越这些路由器的多个端口时，它们仍然属于单链路或[RFC4903]推荐的多访问链路模型的类别。它们不同于[MultLinkSub]和[RFC4903]中所述的“多链路”子网，后者指的是连接到路由器的具有相同前缀的不同物理介质，其中第2层帧不能在不更改报头的情况下本机转发。
The SARP proxy is located at the boundary where the local Layer 2 infrastructure connects to the interconnecting network. All traffic from the local site to the remote sites traverses the SARP proxy. The SARP proxy is subject to high-availability and bandwidth requirements.
SARP代理位于本地第2层基础设施连接到互连网络的边界处。从本地站点到远程站点的所有流量都会通过SARP代理。SARP代理受高可用性和带宽要求的约束。
The SARP architecture supports multiple SARP proxies connecting a single site to the transport network. In the SARP architecture, all proxies can be active and can back up one another. The SARP architecture is robust and allows network administrators to allocate proxies according to bandwidth and high-availability requirements.
SARP体系结构支持将单个站点连接到传输网络的多个SARP代理。在SARP体系结构中，所有代理都可以是活动的，并且可以相互备份。SARP体系结构非常健壮，允许网络管理员根据带宽和高可用性要求分配代理。
Traffic is segregated between SARP proxies by using VLANs. An SARP proxy is the Master SARP proxy of a set of VLANs and the Backup SARP proxy of another set of VLANs.
通过使用VLAN在SARP代理之间隔离通信量。SARP代理是一组VLAN的主SARP代理和另一组VLAN的备份SARP代理。
For example, assume the SARP proxies of the west site are SARP proxy 1 and SARP proxy 2. The west site supports VLAN 1 and VLAN 2, while SARP proxy 1 is the Master SARP proxy of VLAN 1 and the Backup SARP proxy of VLAN 2, and SARP proxy 2 is the Master SARP proxy of VLAN 2 and the Backup SARP proxy of VLAN 1. Both proxies are members of VLAN 1 and VLAN 2.
例如，假设西部站点的SARP代理为SARP代理1和SARP代理2。west站点支持VLAN 1和VLAN 2，而SARP proxy 1是VLAN 1的主SARP代理和VLAN 2的备份SARP代理，SARP proxy 2是VLAN 2的主SARP代理和VLAN 1的备份SARP代理。这两个代理都是VLAN 1和VLAN 2的成员。
The Master SARP proxy updates its Backup SARP proxy with all the ARP reply messages. The Backup SARP proxy maintains a backup database to all the VLANs that it is the Backup SARP proxy of.
主SARP代理使用所有ARP回复消息更新其备份SARP代理。备份SARP代理为其作为备份SARP代理的所有VLAN维护一个备份数据库。
The Master and the Backup SARP proxies maintain a keepalive mechanism. In case of a failure, the Backup SARP proxy becomes the Master SARP proxy. The failure decision is per VLAN. When the Master and the Backup SARP proxies switch over, the Backup SARP proxy can use the MAC address of the Master SARP proxy. The Backup SARP proxy sends locally a Gratuitous ARP message with the MAC address of the Master SARP proxy to update the forwarding tables on the local switches. The Backup SARP proxy also updates the remote SARP proxies on the change.
主SARP代理和备份SARP代理维护一个keepalive机制。如果出现故障，备份SARP代理将成为主SARP代理。故障决策是按VLAN进行的。当主SARP代理和备份SARP代理切换时，备份SARP代理可以使用主SARP代理的MAC地址。备份SARP代理在本地发送带有主SARP代理MAC地址的免费ARP消息，以更新本地交换机上的转发表。备份SARP代理也会在更改时更新远程SARP代理。
SARP can be used over overlay networks, providing L2 network virtualization (such as IP, Virtual Private LAN Service (VPLS), Transparent Interconnection of Lots of Links (TRILL), Overlay Transport Virtualization (OTV), Network Virtualization using GRE (NVGRE), and Virtual eXtensible Local Area Network (VXLAN)). The mapping of SARP to overlay networks is straightforward; the VM does the mapping of the destination IP to the SARP proxy MAC address. The mapping of the proxy MAC to its correct tunnel is done by the overlay networks.
SARP可以在覆盖网络上使用，提供二级网络虚拟化（如IP、虚拟专用LAN服务（VPLS）、大量链路的透明互连（TRILL）、覆盖传输虚拟化（OTV）、使用GRE的网络虚拟化（NVGRE）和虚拟可扩展局域网（VXLAN））。将SARP映射到覆盖网络是简单的；VM将目标IP映射到SARP代理MAC地址。代理MAC到其正确隧道的映射由覆盖网络完成。
SARP significantly scales down the complexity of the overlay networks and transport networks by reducing the mapping tables to the number of SARP proxies.
通过将映射表减少到SARP代理的数量，SARP显著降低了覆盖网络和传输网络的复杂性。
SARP proxies are located at the boundaries of access networks, where the local Layer 2 infrastructure connects to its Layer 2 cloud. SARP proxies interoperate with overlay network protocols that extend the Layer 2 subnet across data centers or between different systems within a data center.
SARP代理位于接入网络的边界，本地第2层基础设施连接到其第2层云。SARP代理与覆盖网络协议互操作，覆盖网络协议跨数据中心或数据中心内不同系统扩展第2层子网。
SARP does not expose the network to security threats beyond those that exist whether or not SARP is present.
无论是否存在SARP，SARP都不会使网络暴露于现有安全威胁之外的安全威胁。
SARP proxies may be exposed to denial-of-service (DoS) attacks by means of ARP/ND message flooding. Thus, SARP proxies must have sufficient resources to support the SARP control plane without making the network more vulnerable to DoS than it was without SARP proxies.
通过ARP/ND消息泛滥，SARP代理可能会受到拒绝服务（DoS）攻击。因此，SARP代理必须有足够的资源来支持SARP控制平面，而不会使网络比没有SARP代理时更容易受到DoS攻击。
SARP adds security to the data plane in terms of network reconnaissance, by hiding all the local Layer 2 MAC addresses from potential attackers located at the interconnecting network and significantly limiting the number of addresses exposed to an attacker at a remote site.
SARP通过隐藏所有本地第2层MAC地址以防互连网络中的潜在攻击者，并显著限制远程站点中暴露给攻击者的地址数量，从而在网络侦察方面增加了数据平面的安全性。
[ARP] 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, DOI 10.17487/RFC0826, November 1982, <http://www.rfc-editor.org/info/rfc826>.
[ARP]Plummer，D.，“以太网地址解析协议：或将网络协议地址转换为48位以太网地址以便在以太网硬件上传输”，STD 37，RFC 826，DOI 10.17487/RFC0826，1982年11月<http://www.rfc-editor.org/info/rfc826>.
[ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.
[ND]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 4861，DOI 10.17487/RFC48612007年9月<http://www.rfc-editor.org/info/rfc4861>.
[ProxyARP] Carl-Mitchell, S. and J. Quarterman, "Using ARP to implement transparent subnet gateways", RFC 1027, DOI 10.17487/RFC1027, October 1987, <http://www.rfc-editor.org/info/rfc1027>.
[ProxyARP]Carl Mitchell，S.和J.Quarterman，“使用ARP实现透明子网网关”，RFC 1027，DOI 10.17487/RFC1027，1987年10月<http://www.rfc-editor.org/info/rfc1027>.
[RFC925] Postel, J., "Multi-LAN address resolution", RFC 925, DOI 10.17487/RFC0925, October 1984, <http://www.rfc-editor.org/info/rfc925>.
[RFC925]Postel，J.，“多局域网地址解析”，RFC 925，DOI 10.17487/RFC0925，1984年10月<http://www.rfc-editor.org/info/rfc925>.
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 2006, <http://www.rfc-editor.org/info/rfc4389>.
[RFC4389]Thaler，D.，Talwar，M.，和C.Patel，“邻居发现代理（ND代理）”，RFC 4389，DOI 10.17487/RFC4389，2006年4月<http://www.rfc-editor.org/info/rfc4389>.
[RFC4541] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, <http://www.rfc-editor.org/info/rfc4541>.
[RFC4541]Christensen，M.，Kimball，K.，和F.Solensky，“互联网组管理协议（IGMP）和多播侦听器发现（MLD）窥探交换机的注意事项”，RFC 4541，DOI 10.17487/RFC4541，2006年5月<http://www.rfc-editor.org/info/rfc4541>.
[RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, DOI 10.17487/RFC4664, September 2006, <http://www.rfc-editor.org/info/rfc4664>.
[RFC4664]Andersson，L.，Ed.，和E.Rosen，Ed.，“第二层虚拟专用网络（L2VPN）框架”，RFC 4664，DOI 10.17487/RFC4664，2006年9月<http://www.rfc-editor.org/info/rfc4664>.
[RFC6575] Shah, H., Ed., Rosen, E., Ed., Heron, G., Ed., and V. Kompella, Ed., "Address Resolution Protocol (ARP) Mediation for IP Interworking of Layer 2 VPNs", RFC 6575, DOI 10.17487/RFC6575, June 2012, <http://www.rfc-editor.org/info/rfc6575>.
[RFC6575]Shah，H.，Ed.，Rosen，E.，Ed.，Heron，G.，Ed.，和V.Kompella，Ed.，“第2层VPN IP互通的地址解析协议（ARP）调解”，RFC 6575，DOI 10.17487/RFC6575，2012年6月<http://www.rfc-editor.org/info/rfc6575>.
[802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks -- Bridges and Bridged Networks", IEEE Std 802.1Q.
[802.1Q]IEEE，“局域网和城域网的IEEE标准——网桥和桥接网络”，IEEE标准802.1Q。
[ARMDStats] Karir, M., and J. Rees, "Address Resolution Statistics", Work in Progress, draft-karir-armd-statistics-01, July 2011.
[ARMDStats]Karir，M.和J.Rees，“解决分辨率统计”，正在进行的工作，草稿-Karir-armd-Statistics-012011年7月。
[MultLinkSub] Thaler, D., and C. Huitema, "Multi-link Subnet Support in IPv6", Work in Progress, draft-ietf-ipv6-multi-link-subnets-00, June 2002.
[MultLinkSub]Thaler，D.和C.Huitema，“IPv6中的多链路子网支持”，正在进行的工作，草稿-ietf-IPv6-Multi-link-subnets-00，2002年6月。
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, DOI 10.17487/RFC4903, June 2007, <http://www.rfc-editor.org/info/rfc4903>.
[RFC4903]Thaler，D.，“多链路子网问题”，RFC 4903，DOI 10.17487/RFC4903，2007年6月<http://www.rfc-editor.org/info/rfc4903>.
[RFC6820] Narten, T., Karir, M., and I. Foo, "Address Resolution Problems in Large Data Center Networks", RFC 6820, DOI 10.17487/RFC6820, January 2013, <http://www.rfc-editor.org/info/rfc6820>.
[RFC6820]Narten，T.，Karir，M.，和I.Foo，“解决大型数据中心网络中的解决方案问题”，RFC 6820，DOI 10.17487/RFC6820，2013年1月<http://www.rfc-editor.org/info/rfc6820>.
[RFC7342] Dunbar, L., Kumari, W., and I. Gashinsky, "Practices for Scaling ARP and Neighbor Discovery (ND) in Large Data Centers", RFC 7342, DOI 10.17487/RFC7342, August 2014, <http://www.rfc-editor.org/info/rfc7342>.
[RFC7342]Dunbar，L.，Kumari，W.，和I.Gashinsky，“大型数据中心中扩展ARP和邻居发现（ND）的实践”，RFC 7342，DOI 10.17487/RFC7342，2014年8月<http://www.rfc-editor.org/info/rfc7342>.
[RFC7364] Narten, T., Ed., Gray, E., Ed., Black, D., Fang, L., Kreeger, L., and M. Napierala, "Problem Statement: Overlays for Network Virtualization", RFC 7364, DOI 10.17487/RFC7364, October 2014, <http://www.rfc-editor.org/info/rfc7364>.
[RFC7364]Narten，T.，Ed.，Gray，E.，Ed.，Black，D.，Fang，L.，Kreeger，L.，和M.Napierala，“问题陈述：网络虚拟化覆盖”，RFC 7364，DOI 10.17487/RFC7364，2014年10月<http://www.rfc-editor.org/info/rfc7364>.
[TcpIp] Stevens, W., "TCP/IP Illustrated, Volume 1: The Protocols", Addison-Wesley, 1994.
[TcpIp]Stevens，W.，“TCP/IP图解，第1卷：协议”，Addison-Wesley，1994年。
Acknowledgments
致谢
The authors thank Ted Lemon, Eric Gray, and Adrian Farrel for providing valuable comments and suggestions for the document.
作者感谢Ted Lemon、Eric Gray和Adrian Farrel为本文提供了宝贵的意见和建议。
Authors' Addresses
作者地址
Youval Nachum EMail: youval.nachum@gmail.com
Youval Nachum电子邮件：Youval。nachum@gmail.com
Linda Dunbar Huawei Technologies 5430 Legacy Drive, Suite #175 Plano, TX 75024 United States Phone: (469) 277 5840 EMail: ldunbar@huawei.com
Linda Dunbar Huawei Technologies 5430 Legacy Drive，德克萨斯州普莱诺175号套房75024美国电话：（469）277 5840电子邮件：ldunbar@huawei.com
Ilan Yerushalmi Marvell 6 Hamada St. Yokneam, 20692 Israel EMail: yilan@marvell.com
Ilan Yerushalmi Marvell 6 Hamada St.Yokneam，20692以色列电子邮件：yilan@marvell.com
Tal Mizrahi Marvell 6 Hamada St. Yokneam, 20692 Israel EMail: talmi@marvell.com
Tal Mizrahi Marvell 6 Hamada St.Yokneam，20692以色列电子邮件：talmi@marvell.com