Network Working Group INTERNET-DRAFT Expires in: January 2006 Scott Poretsky Reef Point Systems Shankar Rao Qwest Communications July 2005 Methodology for Benchmarking Accelerated Stress with Operational EBGP Instabilities Intellectual Property Rights (IPR) statement: By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. ABSTRACT Routers in an operational network are simultaneously configured with multiple protocols and security policies while forwarding traffic and being managed. To accurately benchmark a router for deployment it is necessary that the router be tested in these simultaneous operational conditions, which is known as Stress Testing. This document provides the Methodology for performing Stress Benchmarking of networking devices when subjected to instability with eBGP-4. Descriptions of Test Topology, Benchmarks and Reporting Format are provided in addition to procedures for conducting various test cases. This methodology is based upon the accelerated stress methodology guidelines [6] and is to be used with the companion terminology document [4]. Poretsky and Rao [Page 1] INTERNET-DRAFT Methodology for Accelerated Stress Benchmarking July 2005 Table of Contents 1. Introduction ............................................... 2 2. Existing definitions ....................................... 2 3. Test Setup.................................................. 2 4. Test Cases.................................................. 3 4.1 Failed Primary EBGP Peer................................... 3 4.2 Establish New EBGP Peer.................................... 3 4.3 BGP Route Explosion........................................ 4 4.4 BGP Policy Configuration................................... 4 4.5 Persistent BGP Flapping.................................... 5 4.6 BGP Route Flap Dampening................................... 6 4.7 Nested Convergence Events.................................. 6 5. IANA Considerations..................................... 7 6. Security Considerations..................................... 7 7. References........................................ 7 8. Author's Address............................................ 8 1. Introduction Routers in an operational network are simultaneously configured with multiple protocols and security policies while forwarding traffic and being managed. To accurately benchmark a router for deployment it is necessary that the router be tested in these simultaneous operational conditions, which is known as Stress Testing. This document provides methodologies based upon the accelerated stress methodology guidelines [6] and is to be used with the companion terminology document [4]. This document provides the methodologies for performing Stress Benchmarking of networking devices when subjected to instability with eBGP-4. Test cases are provided for such conditions as a failed EBGP peer, establishing a new EBGP peer, BGP Route Explosion, BGP Policy Configuration, Persistent BGP Flapping, Route Flapping with BGP Dampening enabled, Nested Convergence Events, and secure BGP. Descriptions of Test Topology, Benchmarks and Reporting Format are provided in addition to the procedures to be used for conducting various test cases. 2. Existing definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [7]. RFC 2119 defines the use of these key words to help make the intent of standards track documents as clear as possible. While this document uses these keywords, this document is not a standards track document. Terms specific to Accelerated Stress Benchmarking are defined in [4]. 3. Test Setup Test Setup, Test Topologies, Considerations, and Reporting Format MUST be as described in [6]. Poretsky and Rao [Page 2] INTERNET-DRAFT Methodology for Accelerated Stress Benchmarking July 2005 4. Test Cases 4.1 Failed Primary EBGP Peer Objective The purpose of this test is to benchmark the performance of the DUT during stress conditions when losing an EBGP Peer from which most FIB routes have been learned. Procedure 1. Report Configuration Set 2. Begin Startup Conditions with the DUT 3. Establish Configuration Sets with the DUT 4. Report benchmarks (for stability) 5. Apply Instability Conditions 6. Remove link to EBGP peer with most FIB routes. This SHOULD be achieved by losing physical layer connectivity with a local fiber pull. Loss of the peering session SHOULD cause the DUT to withdraw 100,000 or greater routes. 7. Report benchmarks (for instability) 8. Stop applying all Instability Conditions 9. Report benchmarks (for recovery) 10. Optional - Change Configuration Set and/or Instability Conditions for next iteration Results It is expected that there will be significant packet loss until the DUT converges from the lost EBGP link. Other DUT operation should be stable without session loss or sustained packet loss. Recovery time should not be infinite. 4.2 Establish New EBGP Peer Objective The purpose of this test is to benchmark the performance of the DUT during stress conditions when establishing a new EBGP Peer from which routes are learned. Procedure 1. Report Configuration Set 2. Begin Startup Conditions with the DUT 3. Establish Configuration Sets with the DUT 4. Report benchmarks (for stability) 5. Apply Instability Conditions 6. Configure a new EBGP peering session at DUT and peering router. Physical and Data Link Layer connectivity SHOULD already exist to perform this step. Establishment of the peering session MUST result in the DUT learning X routes from the BGP peer and advertising X routes to the BGP peer. NOTE 1: Number X of BGP Routes MUST be recorded. NOTE 2: X routes MUST be installed in the FIB and MUST be verified installed in the FIB by sending data to each NLRI. 7. Report benchmarks (for instability) Poretsky and Rao [Page 3] INTERNET-DRAFT Methodology for Accelerated Stress Benchmarking July 2005 8. Stop applying all Instability Conditions 9. Report benchmarks (for recovery) 10. Optional - Change Configuration Set and/or Instability Conditions for next iteration Results It is expected that there will be zero packet loss as the DUT learns the new routes. Other DUT operation should be stable without session loss or sustained packet loss. 4.3 BGP Route Explosion Objective The purpose of this test is to benchmark the performance of the DUT during stress conditions when there is BGP Route Explosion experienced in the network. Procedure 1. Report Configuration Set 2. Begin Startup Conditions with the DUT 3. Establish Configuration Sets with the DUT 4. Report benchmarks (for stability) 5. Apply Instability Conditions 6. Advertise X BGP routes to the DUT from a single EBGP neighbor. NOTE 1: Number X of BGP Routes MUST be recorded. NOTE 2: X routes MUST be installed in the FIB and MUST be verified installed in the FIB by sending data to each NLRI. 7. Report benchmarks (for instability) 8. Stop applying all Instability Conditions, including BGP route advertisement. 9. Report benchmarks (for recovery) 10. Optional - Change Configuration Set and/or Instability Conditions for next iteration Results It is expected that there will be no additional packet loss from the advertisement of routes from the BGP neighbor. Other DUT operation should be stable without session loss. 4.4 BGP Policy Configuration Objective The purpose of this test is to benchmark the performance of the DUT during stress conditions when there is continuous reconfiguration of BGP Policy at the DUT. Procedure 1. Report Configuration Set 2. Begin Startup Conditions with the DUT Poretsky and Rao [Page 4] INTERNET-DRAFT Methodology for Accelerated Stress Benchmarking July 2005 3. Establish Configuration Sets with the DUT 4. Report benchmarks (for stability) 5. Apply Instability Conditions 6. Configure BGP Policy on the DUT for each established neighbor. The BGP Policy SHOULD filter X% of the routes learned from that neighbor. NOTE 1: Note that the specific policy configuration to achieve the filtering may be device specific. NOTE 2: Number X% of BGP Policies MUST be recorded. NOTE 3: The policies MUST be applied so that routes in the FIB are impacted. 7. Every 30 minutes remove the BGP Policy configuration and then configure it gain so that it is reapplied. 8. Report benchmarks (for instability) 9. Stop applying all Instability Conditions, including Policy changes 10. Report benchmarks (for recovery) 11. Optional - Change Configuration Set and/or Instability Conditions for next iteration Results It is expected that there will be no packet loss resulting from the continuous configuration and removal of BGP Policy for BGP neighbors. Other DUT operation should be stable without session loss. 4.5 Persistent BGP Flapping Objective The purpose of this test is to benchmark the performance of the DUT during stress conditions when flapping BGP Peering sessions for an infinite period. Procedure 1. Report Configuration Set 2. Begin Startup Conditions with the DUT 3. Establish Configuration Sets with the DUT 4. Report benchmarks (for stability) 5. Apply Instability Conditions 6. Repeatedly flap an IBGP and an EBGP peering session. This SHOULD be achieved by losing physical layer connectivity via a local interface shutdown/no shutdown every 180 seconds with a delay of 10 seconds between the shut and no shut. The loss of the EBGP peering session MUST cause the DUT to withdraw 100,000 routes that are re-learned when the session re-establishes. Route Flap Dampening SHOULD NOT be enabled. 7. Report benchmarks (for instability) 8. Stop applying all Instability Conditions, including flapping 9. Report benchmarks (for recovery) 10. Optional - Change Configuration Set and/or Instability Conditions for next iteration Poretsky and Rao [Page 5] INTERNET-DRAFT Methodology for Accelerated Stress Benchmarking July 2005 Results It is expected that there will be significant packet loss from repeated Convergence Events. Other DUT operation should be stable without session loss. Recovery time should not be infinite. 4.6 BGP Route Flap Dampening Objective The purpose of this test is to benchmark the performance of the DUT during stress conditions when flapping BGP Peering sessions for an infinite period and route flap dampening is enabled. Procedure 1. Report Configuration Set 2. Configure Route Flap Dampening on the DUT with DEFAULT parameter values. 3. Begin Startup Conditions with the DUT 4. Establish Configuration Sets with the DUT 5. Report benchmarks (for stability) 6. Apply Instability Conditions 7. Repeatedly flap an IBGP and an EBGP peering session. This SHOULD be achieved by losing physical layer connectivity via a local interface shutdown/no shutdown every 180 seconds with a delay of 10 seconds between the shut and no shut. The loss of the EBGP peering session MUST cause the DUT to withdraw 100,000 or greater routes that are re-learned when the session re-establishes. 8. Report benchmarks (for instability) 9. Stop applying all Instability Conditions 10. Report benchmarks (for recovery) 11. Optional - Change Route Flap Dampening parameter values 12. Optional - Change Configuration Set and/or Instability Conditions for next iteration Results It is expected that there will be significant packet loss from repeated Convergence Events and flap dampening. Other DUT operation should be stable without session loss. Recovery time should not be infinite. 4.7 Nested Convergence Events [5] Objective The purpose of this test is to benchmark the performance of the DUT during stress conditions when flapping BGP Peering sessions causes Nested Convergence Events. Procedure 1. Report Configuration Set 2. Begin Startup Conditions with the DUT 3. Establish Configuration Sets with the DUT 4. Report benchmarks (for stability) Poretsky and Rao [Page 6] INTERNET-DRAFT Methodology for Accelerated Stress Benchmarking July 2005 5. Apply Instability Conditions 6. Repeatedly flap an IBGP and an EBGP peering session. This SHOULD be achieved by losing physical layer connectivity via a local interface shutdown/no shutdown every 10 seconds with a delay of 1 second between the shut and no shut. The loss of the EBGP peering session MUST cause the DUT to withdraw 100,000 or greater routes that are re-learned when the session re-establishes. Route Flap Dampening SHOULD NOT be enabled. 7. Report benchmarks (for instability) 8. Stop applying all Instability Conditions, including flapping 9. Report benchmarks (for recovery) 10. Optional - Change Configuration Set and/or Instability Conditions for next iteration Results It is expected that there will be significant packet loss from Nested Convergence Events. New Other DUT operation should be stable without session loss. Recovery time should not be infinite. 5. IANA Considerations This document requires no IANA considerations. 6. Security Considerations Documents of this type do not directly affect the security of the Internet or of corporate networks as long as benchmarking is not performed on devices or systems connected to operating networks. 7. References 7.1 Normative References [1] Bradner, S., Editor, "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, July 1991. [2] Mandeville, R., "Benchmarking Terminology for LAN Switching Devices", RFC 2285, June 1998. [3] Bradner, S. and McQuaid, J., "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999. [4] Poretsky, S. and Rao, S., "Terminology for Accelerated Stress Benchmarking", draft-ietf-bmwg-acc-bench-term-05, work in progress, July 2005. [5] Poretsky, S., "Benchmarking Terminology for IGP Data Plane Route Convergence", draft-ietf-bmwg-igp-dataplane-conv-term-05, work in progress, July 2005. [6] Poretsky, S. and Rao, S., "Methodology Guidelines for Accelerated Stress Benchmarking", draft-ietf-bmwg-acc-bench-meth-03, work in progress, July 2005. [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. Poretsky and Rao [Page 7] INTERNET-DRAFT Methodology for Accelerated Stress Benchmarking July 2005 7.2 Informative References [RFC3871] RFC 3871 "Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure. G. Jones, Ed.. IETF, September 2004. [NANOG25] "Core Router Evaluation for Higher Availability", Scott Poretsky, NANOG 25, June 8, 2002, Toronto, CA. [IEEECQR] "Router Stress Testing to Validate Readiness for Network Deployment", Scott Poretsky, IEEE CQR 2003. [CONVMETH] Poretsky, S., "Benchmarking Methodology for IGP Data Plane Route Convergence", draft-ietf-bmwg-igp-dataplane-conv-meth-05, work in progress, July 2005. [NANOG30] Poretsky, S. and Imhoff, B., "BGP Testing: Why be so Negative?", NANOG 30, Miami, Feb 2004. 8. Author's Address Scott Poretsky Reef Point Systems 8 New England Executive Park Burlington, MA 01803 USA Phone: + 1 781 395 5090 EMail: sporetsky@reefpoint.com Shankar Rao 1801 California Street 8th Floor Qwest Communications Denver, CO 80202 USA Phone: + 1 303 437 6643 Email: shankar.rao@qwest.com Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Poretsky and Rao [Page 8] INTERNET-DRAFT Methodology for Accelerated Stress Benchmarking July 2005 Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Poretsky and Rao [Page 9]