Library: Test Plans

BGP Testing

This test plan includes conformance, functional, and performance/stress tests designed for network and QA engineers who are testing BGP-enabled devices and networks, creating a baseline performance metric for assessing and achieving network quality objectives.

1. BGP Conformance Test
2. BGP Functional Test - Route Dampening
3. BGP Functional Test - Multi-Homing
4. BGP Functional Test - Graceful Restart
5. BGP Performance Test - Route Capacity
6. BGP Performance Test - Route Convergence

1. BGP Conformance Test

Objective.
This test verifies the Device Under Test's (DUT's) compliance with the following capabilities defined in various BGP specifications: RFC 1771, RFC 1772, draft-ietf-idr-bg p. 4-12, draft-ietf-idr-bg p. 4-17.

Figure 1. BGP conformance test setup

Setup.
A minimum of two test ports are required from the test tool to the DUT - one for stimulus packets and one for response packets. Ixia's IxANVL conformance test system is run from a Linux workstation either connected directly to the DUT, or via Ixia test hardware (see Figure 1). IxANVL emulates various BGP topologies, depending on the configuration of each test case.

Input parameters.
Two sets of parameters are required prior to running conformance tests: one for test tool configuration and one for DUT configuration. The test tool configuration describes the interface and protocol configuration, while the DUT configuration describes the BGP commands sent to the DUT using Expect scripts (see Table 1)

Parameter	Description
Test Tool Configuration	Tester Test IP Addresses, DUT IP Address, BGP protocol parameters (AS number, authentication, and timer values)
DUT Configuration	BGP features (TOS Routing, timers, AS number, peer configuration, etc.) via Expect scripts

Table 1. Conformance test input parameters.

Methodology.
Conformance testing is an important tool to verify how a DUT complies with specific protocol standards. Conformance test tools perform their tests as a dialog: they send stimulus packets to the router being tested, receive the packets sent in response, and then analyze the response to determine the next action to take. This methodology allows conformance test tools to test complicated scenarios much more intelligently and flexibly than achievable by simple packet generation and capture devices. Conformance testing also includes negative test cases to help validate device response to improper or inaccurate packets.

For BGP conformance testing, a number of test cases are run against the DUT based on the direct interpretation of various BGP RFCs.

1. Enter parameters to describe both the Conformance Tester and DUT configuration.
2. Select all or a set of test cases to run (see Figure 2).
3. Run the conformance tests from the user interface or in a batch mode via command scripts, reconfiguring the DUT as required between test cases to match the test setup.

Figure 2. BGP test case selection.

Result.
Number of tests passed/failed, including reasons for failed cases. IxANVL also keeps a history of each passed or failed test case in the Test Journal (see Figure 3).

Figure 3. BGP conformance result.

2. BGP Functional Test - Route Dampening

Objective.
This test verifies a router's policy for BGP dampening of unstable routes that have experienced periodic withdrawal and re-advertisement. This test confirms the proper operation of BGP dampening timers.

Setup.
This test requires two test ports - one to transmit traffic to both the stable and the unstable routes and the other one to emulate BGP routes with flapping capabilities. At least two prefixes are advertised, one that is stable and the another that is unstable. The device's BGP dampening policy is tested for proper suppression and re-use.

Figure 4. BGP dampening test topology

Input parameters

Parameter	Description
Penalty	Increasing number assigned to a route every time it flaps
Half Time	Amount of time that must pass to reduce the Penalty by half. It determines how fast the penalty timer decays
Suppress Limit	Numeric number compared to the Penalty whenever a route is received. If the Penalty is larger than the Suppress Limit, the route is suppressed (i.e.: no longer advertised to BGP peers).
Reuse Limit	Numeric number compared to the Penalty whenever a route is received. If the Penalty is less than the Reuse Limit, the route will be unsuppressed or re-used (i.e.: re-advertised to BGP peers).

Table 2. BGP dampening test parameters

Methodology

1. Configure a single BGP session on Test Port 2 (BGP port) and advertise two different prefixes, one that is stable and the other to represent unstable (flapping) behavior.
2. Configure the dampening/damping policy on the DUT. The objective is to test timed parameters such as Penalty and Half Time for route damping.
3. Start the BGP session on Test Port 2 and ensure that both the stable and unstable routes are advertised successfully to the DUT.
4. Configure Test Port 1 (transmit port) to send traffic to both advertised routes. Set the tester to track by destination IP address. Two flows will be created, and per-flow stats will be tracked and reported in real time. Send the traffic at a low frame rate (e.g., 5000 fps for each flow) for easy observation of the route dampening effect.
5. Carefully design a flap scheduler to start the dampening process. For easy prediction of the route suppression time, flap the route quickly (e.g., withdraw it in 2 seconds and re-advertise in another 2 seconds). Start the traffic and activate the real-time graphing tools to monitor port receiving rate. Flap the route enough times to see what route is being suppressed and re-used in a reasonably short time. See Figure 5 for an example of a flapping schedule using Ixia's IxNetwork Test Scheduler. The unstable route is flapped three times - the second time it flaps causes the DUT to suppress the route.

Figure 5. BGP flapping configuration example

Results.
These test results display the traffic received on the BGP test port where BGP route flapping occurred. Figure 6 shows sample test results that illustrate how the dampening policy is applied correctly after only the second route flap. Note the exact behavior of route dampening depends on the input parameters.

In this particular example, half-time is set as 1 minute; the suppress limit is set as 2000 units; and the re-use limit is set as 1000 units. Penalty is the default value (1000). As it's indicated in the following diagram, route suppression starts immediately after only the second flap. The third flap will raise the Penalty to be approximately 3000 units. The route will remain suppressed until approximately two times the half-time (120 seconds) when the penalty time finally decays to a value lower than re-use limit.

Figure 6. BGP dampening test results

3. BGP Functional Test - Multi-Homing

Objective.
This test verifies the influence of the BGP optional non-transitive MED (Multi-Exit Discriminator) attribute on several paths established with EBGP. Traffic is sent from multiple peers (established via a single test port or different test ports), each containing a route with a pre-configured MED metric, and then the impact on IP forwarding is observed.

Setup.
Even though two test ports are sufficient for proof-of-concept testing for this test case, we recommend the use of three test ports so that the traffic forwarding impact can be better observed when manipulating the MED value. The first test port is used to transmit frames sent to the same prefix that was advertised by all BGP peers (i.e., via a single test port or different test ports). The other two (or more) ports will be EBGP peers to the DUT that advertise exactly the same prefix but with a different MED value. These ports also act as traffic receivers for verification.

As traffic is sent from Test Port 1, the DUT will select the best path corresponding to lowest MED value, and then forward the traffic to the right BGP peer/port. You can alter the MED value on the fly, and observe how the traffic is being switched to a new port that now has the lowest MED value. Ixia's IxNetwork can be used to execute this test.

Figure 7. BGP multi-homing test logical topology

Input parameters

Parameter	Description
MED Metric	A 32-bit integer representing the non-transitive BGP metric
Optional Non-transitive	An optional capability in BGP that is commonly used to influence route decisions from EBGP into a network

Table 3. BGP MED-related input parameters

Methodology.
This methodology can be executed manually or by script. The key to determining an accurate convergence time is in understanding the DUT's capabilities and manipulating the test parameters properly.

1. Configure an EBGP emulation on Test Port 2, and 3 as applicable. Each port should be configured with one or more external BGP peers and each peer should advertise the same prefix but a different MED. Figure 8 shows an sample configuration of the MED metric using Ixia's IxNetwork BGP emulation module.
2. Verify on the control plane that all routes are in the BGP table of the DUT with the configured MEDs. Verify also that the best path shown in the DUT corresponds to the lowest MED value. This value should also the default data forwarding path.
3. Configure Test Port 1 with traffic destined to the one prefix advertised by all peers.
4. Begin transmitting traffic on the data plane to obtain results.
5. Change the MED value on the fly and observe new traffic results.

Figure 8. MED configuration example

Results.
Verify traffic flows on Test Port 2 or 3 as applicable, and ensure that traffic is received only on the port that has the lowest MED value. Change the advertised route to a different MED value and observe traffic being switched over to another receive port that now has the lowest MED value. Reset the MED to the original value and ensure traffic again flows along the original path. You can repeat the process a few times to ensure that the results are repeatable and consistent.

Figure 9. BGP multi-homing test results

4. BGP Functional Test - Graceful Restart

Objective.
This test verifies BGP graceful restart capabilities using traffic flows. For maximum effect, two separate BGP sessions, each with one distinct prefix, are recommended, where one is configured for graceful restart and the other is not. By flapping both BGP peers and observing the traffic impact on both flows, you can easily determine if the BGP graceful restart function works as expected.

Setup.
This test requires a minimum of two test ports - one to transmit and the other to receive and represent BGP neighbor adjacencies. Two EBGP sessions will be established between Test Port 2 and the DUT: one session will advertise graceful restart capabilities, which include restart and stale timers, and the other will not. Each EBGP peer will contain a single prefix to represent an IP destination.
When no BGP session flapping occurs, the traffic will enter the DUT from Test Port 1 and will be received without loss by Test Port 2. The test then introduces session flapping for both the graceful restart session and the non-graceful restart session. You should see traffic continuity in the graceful restart session; whereas, traffic should be dropped continuously in the non-graceful restart session. Ixia's IxNetwork can be used for to assess the flap scheduler and BGP session capabilities with graceful restart configured.

Figure 10. BGP graceful restart test topology

Input parameters

Parameter	Description
Restart Time	The estimated time, following a restart operation, allowed re-establishing a BGP session
Stale Path Time	The maximum time to maintain stale paths of a gracefully restarted peer. All stale paths are deleted after the expiration of this value

Table 4. BGP graceful restart test parameters.

Methodology

1. Test Port 2 emulates the control plane for BGP and establishes two separate BGP sessions with the DUT. The BGP graceful restart function is configured for both the first BGP session and the DUT. See Figure 11 for a sample to setup with graceful restart configured on the Ixia test port.
   
   Figure 11. Ixia graceful restart configuration
   
   
2. Confirm that the DUT forwarding table has learned both prefixes via BGP sessions. Configure Test Port 1 to send continuous traffic at a given rate (e.g., 10000 frames/second) to both prefixes.
3. Use the real-time graphing tool to monitor the receiving rate of Test Port 2. No frame loss should be observed before the flap.
4. Design the test scheduler to flap both BGP sessions. The session flap timer should be less than the graceful restart timer to observe traffic continuity.
5. Manipulate the event flap on different sessions, each with a different time, and observe the traffic rate change. Be sure the results are clearly derived from the graceful restart timers set on both the DUT and the first BGP session.

Figure 12. Ixia Test Scheduler allows complex flap scheduling

Results.
The primary goal of this test is to verify traffic flows in BGP even though adjacencies are flapped. When both sessions are under flap, only the session that is configured with graceful restart enabled will continue to receive traffic. The other session will have no traffic when the session is down. This is evident in the following result diagram where a total of 10,000 frames per second were sent from Test Port 1 to both prefixes that were advertised through two separate sessions. When a flap occurred, only 5,000 frames-per second were received. When both sessions resume normal status, so does the traffic.

Figure 13. BGP graceful restart statistical results

5. BGP Performance Test - Route Capacity

Objective.
This test determines the number of routes that a BGP-enabled DUT can sustain at a single time. This scalability test is designed to help network and test engineers:

• Evaluate devices to be purchased or used in a network based on the ability to scale with BGP.
• Test network capacity and understand network performance limitations before actual implementation or deployment of the live network.

Setup.
The test requires two test ports - one to transmit traffic and one to receive. The transmit direction of traffic is unidirectional. Test Port 2 is used to advertise the BGP4 routes, while Test Port 1 sends traffic to verify the advertised prefixes (see Figure 14).

During the test, Test Port 2 increases the number of advertised routes using a pre-defined "route step" until the maximum sustainable route capacity can be determined. Ixia's IxScriptMate application can be used to configure, control, and execute this test. IxScriptMate also provides comprehensive test results showing frame loss percentages based on the device's ability to forward traffic under maximum route capacity conditions.

Figure 14. BGP route capacity test topology

Input parameters

Parameter	Description
Max Rate	Rate at which frames will be sent to advertised routes
Tolerance	Percentage of traffic loss tolerance
Route Step	Number of routes to increase per iteration
Routes Per Peer	Number of route prefixes to generate at the beginning of the test
Delay	Maximum time in seconds the router is allowed to absorb the advertised routes

Table 5. BGP route capacity test input parameters

Figure 15. BGP route capacity test example configuration

Methodology

1. Test Port 2 advertises the initial number of routes defined by the parameter "Routes Per Peer."
2. After waiting an amount of time specified by the "Delay" parameter, which is the time allowed for DUT to learn routes, Test Port 1 sends traffic targeting each advertised route by Test Port 2. The traffic throughput rate is set by the parameter "Max Rate."
3. Test Port 2 verifies packets received within the defined loss "Tolerance."
4. Test Port 2 incrementally advertises more routes, increasing the number by the amount defined by "Route Step."
5. Repeat Step 2 through Step 4 until Test Port 2 receives no packets or packet loss is above the "Tolerance" level.

Results.
When the test completes and the tolerance has been exceeded, the test results will show the maximum number of routes learned by the DUT. Figure 16 shows a sample results page in PDF format created by IxScriptMate. The results are broken down per frame size and show results for "Max Routes Verified," "Total Loss Percentage." The "Max Routes Verified" value shows the maximum number of routes that could be sustained at that particular traffic rate and frame size. This test can be executed manually with Ixia's IxExplorer application, but the automation capability of Ixia's IxScriptMate helps to simplify and speed the testing process.

Figure 16. BGP route capacity test report

6. BGP Performance Test - Route Convergence

Objective.
This test verifies the ability of a router to switch between preferred and less-preferred routes when the preferred routes are withdrawn and re-advertised. The test calculates convergence by taking an average convergence latency of multiple topological changes.

Setup.
This test uses three test ports - one to transmit and two to receive (see Figure 17). Both receive ports emulate BGP networks. The transmit direction of the traffic is unidirectional. The DUT must have three ports utilized with two enabled for BGP. All three ports should be configured for IP and have unique subnets to communicate with the test ports. Ixia's IxScriptMate application can be used to configure, control, and execute this test automatically.

Figure 17. BGP convergence test topology

Input parameters

Parameter	Description
Max Rate	The rate at which frames are transmitted
Routes Per Peer	The number of route prefixes to generate at the start of the test per peer
Delay	Maximum time in seconds the router is allowed to absorb the advertised routes
Advertise Delay Per Route	The maximum time, in seconds, to allow the router to absorb each route

Table 6. BGP convergence test input parameters

Figure 18. Example BGP convergence test configuration

Methodology
This methodology can be executed manually or by automated script. The key to determining an accurate convergence time is in understanding the DUT's capabilities and proper manipulation of the test parameters.

1. Receive Test Ports 1 and 2 advertise the same BGP prefixes with one path preferred with a lower AS-path count. The path via Receive Port 1 is used as the preferred route, while the path via Receive Port 2 is used as the alternate route.
2. After waiting an amount of time indicated by "Delay," the Transmit Test Port sends one packet to each advertised route. The DUT should route the traffic via the preferred AS-path to Receive Test Port 1.
3. Routes are withdrawn from Receive Test Port 1 (the preferred path). Traffic should reroute to arrive at Receive Test Port 2 (the alternate path).
4. The number of packets lost or transmitted in the incorrect direction is measured after the routes are withdrawn for each configured route. The packet loss is converted to time.
5. Repeat step 3 and 4 to obtain convergence time results for all withdrawn routes. Calculate the average convergence across all routes.

Results.
The test results provide an average convergence time for all routes. Figure 19 displays sample results for the automated BGP convergence test in IxScriptMate. In addition to convergence time, this test also identifies the number of lost packets caused by the controlled flap in BGP.

Figure 19. BGP route convergence test report

[ back | top of page | back to test plans ]