Figure 1: Physical Test Topology

+-------------+           +-------------+           +-------------+
|             +           +             +           +             |
|   TESTER-   +    10G    +             +    10G    +   TESTER-   |
|   DEVICE1   +-----------+     DUT     +-----------+   DEVICE2   |
|             +           +             +           +             |
|             +           +             +           +             |
+-------------+           +-------------+           +-------------+
           

Figure 1

3. Issues to consider when testing

BGP is a protocol based on TCP. As such it uses the inherent features available in TCP to ensure transmission of information such as TCP windowing. The understanding of this is important when creating a testing setup and methodology which accurately tests the DUT as opposed to being hampered by any limitations in testing equipment or other underlying protocols.

With the introduction of virtualized route-reflector running on servers, the DUT can outgrow in some scenarios traditional hardware-based testing devices which emulate numerous route-reflector clients simultaneously. So, it is necessary to ensure that the tester devices have adequate processing capacity and resources not to slow down the DUT and impair the tests results.

When testing a Route-reflector, a limited testing equipment will typically slow down the distribution of BGP Routing Updates by reducing the TCP Window sizes during the test. This mis-behavior can typically be observed by monitoring the TCP-Window sizes variations for the BGP peering sessions in-between the DUT and the testing devices. The testing devices should allow this monitoring.

All tests described must be performed at maximum supported TCP-MSS value in a number of predefined IP-MTU Size on all interfaces between the DUT and the testers, specifically:

• The maximum supported IP MTU value
• The pre-defined IP MTU value of 9000 Bytes.

Another important consideration is the behavior of any testing devices being utilized to obtain the benchmarking figures. In order to provide clear and unambiguous guidance this document will detail the requirements on the testing devices as well.

Test devices should be able to support the following features:

• The ability to bring multiple BGP peering sessions into an ESTABLISHED state without advertising any prefix/path information
• The ability to advertise all BGP prefix/path information immediately and simultaneously without grouping advertisements into smaller sections of ramping up the advertisements over time.
• The ability to count the number of prefixes advertised.
• The ability to count the number of prefixes received. Best-path processing or FIB installation are not required on the tester devices.
• The ability to start the test when the prefixes are advertised and to end the test when all prefixes are received, providing a time between these two points
• The ability to monitor Test devices internal BGP computing resources as well as TCP-Window sizes variations for the BGP peering sessions in-between the DUT and the testing devices

4. Route Profiles

The profile of the routing information that is used may result in wildly different results. In order to provide meaningful results that can be used for accurate benchmarking of Route-Reflector implementations against one and other and to provide results capable of relating to real world deployments of the DUT there are a number of specific route profiles that should be tested. Broadly these profiles fall into two categories: Synthetic Prefixes with a realistic distribution of prefixes and BGP attributes (BGP-PATH,…) and, Real Prefixes with real BGP attributes such as the Global Internet Table.

4.1. Synthetic Prefixes

All of the described tests SHOULD be configurable and performed at a number of realistic prefixes distribution generated according to an algorithm within the tester.

The algorithm SHOULD allow building prefixes according to a number of predefined route profiles. Route profiles defined with as parameters:

• The number of prefixes
• The distribution of prefixes per prefix length
• The number of BGP-PATHs
• The number of AS numbers per AS-PATH (min, max, avg)
• The number of BGP Communities per prefixes (min, max, avg)

4.1.1. Predefined route profiles

[TBD]

4.2. Global Internet Routing Table

A recording of the current Global Internet Routing table should be played back as the source feed providing a realistic prefix distribution, AS_PATH distribution, a realistic next-hop distribution and a realistic number of communities per prefix. It is expected that this sample-set will change with each test as the Global Internet Table will change, in time and per internet region, however, the same sample-set must be used for every route-reflector taking part in a comparative benchmarking activity.

4.3. Routes Testing

The profiles that should be tested are

• IPv4
• - Synthetic
• - Global Internet Table
• IPv6
• - Synthetic
• - Global Internet Table
• VPNv4
• - Synthetic with RD per ASN
• - Synthetic with RD per Router-ID
• VPNv6
• - Synthetic with RD per ASN
• - Synthetic with RD per Router-ID

The profiles should be tested individually and then in groups where the groupings are as follows

• - IPv4+IPv6
• - VPNv4+VPNv6
• - IPv4+IPv6+VPNv4+VPNv6

5. Test Scenarios

Route-Reflectors typically operate in three situations. In these three situations testing should be performed for a representative number of iBGP route-reflector clients: 100, 250, 500, and 1,000.

5.1. Route-Reflection one to all

Test1 - Where they are processing a set of updates from a single iBGP peer and reflecting it to all iBGP route-reflector clients.

+-------------+           +-------------+           +-------------+
|             +           +             +           +             |
|   TESTER-   +    10G    +             +    10G    +   TESTER-   |
|   DEVICE1   +-----------+     DUT     +-----------+   DEVICE2   |
|   1 Peer    +           +             +           +   X Clients |
|             +           +             +           +             |
+-------------+           +-------------+           +-------------+
                 

+----------+          +-------------+          +------------+
|          +          +             +          +            |
| TESTER   +   10G    +             +    10G   +   TESTER   |
| DEVICE1  +----------+     DUT     +----------+   DEVICE2  |
| X Peers  +          +             +          +  X Clients |
|          +          +             +          +            |
+----------+          +-------------+          +------------+
                 

+-------------+           +-------------+
|             +           +             +
|   TESTER    +    10G    +             +
|   DEVICE1   +-----------+     DUT     +
|   X Clients +           +             +
|             +           +             +
+-------------+           +-------------+