Practices for Scaling ARP and Neighbor Discovery (ND) in Large Data Centers
RFC 7342
Document | Type |
RFC - Informational
(August 2014; No errata)
Was draft-dunbar-armd-arp-nd-scaling-practices (individual)
|
|
---|---|---|---|
Authors | Linda Dunbar , Warren Kumari , Igor Gashinsky | ||
Last updated | 2015-10-14 | ||
Stream | ISE | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
IETF conflict review | conflict-review-dunbar-armd-arp-nd-scaling-practices | ||
Stream | ISE state | Published RFC | |
Consensus Boilerplate | Unknown | ||
Document shepherd | Adrian Farrel | ||
Shepherd write-up | Show (last changed 2014-03-13) | ||
IESG | IESG state | RFC 7342 (Informational) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) | ||
IANA | IANA review state | Version Changed - Review Needed | |
IANA action state | No IANA Actions |
Independent Submission L. Dunbar Request for Comments: 7342 Huawei Category: Informational W. Kumari ISSN: 2070-1721 Google I. Gashinsky Yahoo August 2014 Practices for Scaling ARP and Neighbor Discovery (ND) in Large Data Centers Abstract This memo documents some operational practices that allow ARP and Neighbor Discovery (ND) to scale in data center environments. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. 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. 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/rfc7342. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. 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. Dunbar, et al. Informational [Page 1] RFC 7342 Scaling ARP and ND in Large DCs August 2014 Table of Contents 1. Introduction ....................................................2 2. Terminology .....................................................4 3. Common DC Network Designs .......................................4 4. Layer 3 to Access Switches ......................................5 5. Layer 2 Practices to Scale ARP/ND ...............................5 5.1. Practices to Alleviate APR/ND Burden on L2/L3 Boundary Routers ...........................................5 5.1.1. Communicating with a Peer in a Different Subnet .....6 5.1.2. L2/L3 Boundary Router Processing of Inbound Traffic .............................................7 5.1.3. Inter-Subnet Communications .........................8 5.2. Static ARP/ND Entries on Switches ..........................8 5.3. ARP/ND Proxy Approaches ....................................9 5.4. Multicast Scaling Issues ...................................9 6. Practices to Scale ARP/ND in Overlay Models ....................10 7. Summary and Recommendations ....................................10 8. Security Considerations ........................................11 9. Acknowledgements ...............................................11 10. References ....................................................12 10.1. Normative References .....................................12 10.2. Informative References ...................................13 1. Introduction This memo documents some operational practices that allow ARP/ND to scale in data center environments. As described in [RFC6820], the increasing trend of rapid workload shifting and server virtualization in modern data centers requires servers to be loaded (or reloaded) with different Virtual Machines (VMs) or applications at different times. Different VMs residing on one physical server may have different IP addresses or may even be in different IP subnets. In order to allow a physical server to be loaded with VMs in different subnets or allow VMs to be moved to different server racks without IP address reconfiguration, the networks need to enable multiple broadcast domains (many VLANs) on the interfaces of L2/L3 boundary routers and Top-of-Rack (ToR) switches and allow some subnets to span multiple router ports. Note: L2/L3 boundary routers as discussed in this document are capable of forwarding IEEE 802.1 Ethernet frames (Layer 2) without a Media Access Control (MAC) header change. When subnets span multiple ports of those routers, they still fall under the category of "single-link" subnets, specifically the multi-access link model Dunbar, et al. Informational [Page 2] RFC 7342 Scaling ARP and ND in Large DCs August 2014 recommended by [RFC4903]. They are different from the "multi-link"Show full document text