Aug 30, 2011

Router Testing with BGP and Application Traffic: Part 2

by Eric Reeves

In my last post, I started our conversation about router testing using the Border Gateway Protocol (BGP). As we discussed, BGP is an important routing protocol used in the Internet core by service providers and other large organizations. Its implementation is complex, and BGP routers must be tested under accurate real-world conditions to make sure they’re configured correctly.

Read Part 1 for some important test scenarios for BGP Version 4, as well as how to use BreakingPoint CTM products to peer with a BGP router, advertise routes, and keep the session active throughout a test. But we still have some ground to cover—which we’ll do by setting up a Network Neighborhood and Client Simulator test in the BreakingPoint CTM.

Setting Up a BGP Network Neighborhood

Let’s pick up right where we left off and configure a Network Neighborhood for use in our test. First, let’s take a look at the network I’ve set up in our lab for this demonstration:

With the above diagram in mind, some requirements for our Network Neighborhood are:

The “virtual” BGP router represented by the BreakingPoint CTM must have the same IP and MAC address for the duration of the test.
All traffic from the BreakingPoint CTM to the BGP router must appear to be routed through our “virtual” BGP router. This includes any traffic from the 10.0.0.0/24 and 172.31.0.0/16 networks advertised in the Super Flow (that is, the preconfigured application data flow) we created in the last post.

In order to achieve this, we’ll need to configure two interfaces—one of which is external. To do this, we create a new Network Neighborhood within the BreakingPoint CTM called “Virtual BGP Router.” The default domain on the first interface is configured as follows:

Here we configure the domain for our BGP router. Notice that we’ve configured a single, static IP address (192.168.0.2/30) and Ethernet address. Also notice that this domain is set to “Host” mode. Next we must add a domain for each route that we advertised in our BGP Super Flow.

This domain represents the hosts from our 10.0.0.0/24 network. Notice that the virtual router address and Ethernet address are the same as those in the default domain we configured prior to this one. Finally, we must add an additional domain for the 172.31.0.0/16 network. This domain is configured similarly to the one directly above, except the “Minimum IP Address” and “Maximum IP Address” fields are 172.31.0.2 and 172.31.255.254, respectively.

By comparison, the domains for the external interface are simple. We configure one domain for our BGP neighbor and one domain for the HTTP server. While the “HTTP Server” domain is not pictured, it is the single host 172.16.42.2.

Now we can begin designing the test that will use our Super Flow and Network Neighborhood. First, create a new test and assign to it the “Virtual BGP Router” Network Neighborhood.

Building and Running a BGP Test in Client Simulator

This test will require three separate Client Simulator components. One component will be our BGP session, while the other two are our pools of HTTP clients. We begin with the BGP component. This component will use the default settings in the “Parameters” tab, with the following exceptions:

Session Ramp Distribution.Steady-State Time Interval: 00:05:00
Session Ramp Distribution.Ramp Down Time Interval: 00:01:00
Session/Super Flow Configuration.Maximum Simultaneous Super Flows: 1
Session/Super Flow Configuration.Maximum Super Flows Per Second: 1
App Configuration.Streams Per Super Flow: 1
Super Flow: BGP External AS 30000 (This is the Super Flow we created in the previous post.)

These settings ensure that the BreakingPoint CTM will make only one connection to the BGP router for the duration of the test.

Switch to the “Interfaces” tab and confirm that the “default” domain is assigned to both Interface 1 and the external interface. From here, the Super Flow can be saved at any time. I’ve saved mine with the name “ClientSim BGP AS 30000 HTTP Clients.” Next, add a new ClientSim component for each of the advertised networks. For each component, assign the specific domains to Interface 1 and the external interface. Use the screenshot below as a guide.

Switch to the “Parameters” tab and configure the following:

Session Ramp Distribution.Ramp Up Time Interval: 00:00:10
Session Ramp Distribution.Steady-State Time Interval: 00:05:00
Session Ramp Distribution.Ramp Down Time Interval: 00:00:10
Delay Start: 00:00:02 (This can be adjusted based on expected convergence time.)
Super Flow: ClientSim HTTP

Repeat these steps to create a component for the 172.31.0.0/16 network. The finished test should look similar to what is shown below.

After starting the test, I log in to the Cisco 2503 and check the routes.

The Cisco 2501 route table looks similar, with an updated AS path for each of the routes that the CTM advertised to the 2503:

And of course, the access log for our Apache2 HTTP server shows GET requests from our client networks:

Finally, we export the packet capture from the BreakingPoint CTM and observe the list of conversations in Wireshark, as shown below. Our test has met the requirements I set out at the start. This was a successful test!

You can enhance this simulation with variations to test the following scenarios:

Advertise More Routes: Use the settings in our BGP UPDATE action to advertise exponentially more routes. Doing so would test resource utilization and convergence time.
Withdraw Routes: Withdraw routes or end the BGP ClientSim component early to test redundancy and failover scenarios.
High Application Traffic Volume: Add more components, increase sessions per second, increase maximum simultaneous sessions, and/or use different Super Flows to test resource utilization, bandwidth utilization, quality of service, and so on.

This overview has given you what you need to start testing BGP equipment and networks.

Related Content:

Tags: