Load Balancing and NAT Router Test Suite User Guide

Release 1.0
$Id: UserGuide.htm,v 1.13 2003/01/14 11:30:52 joe Exp $
2002 QA Cafe http://qacafe.com
support@qacafe.com

LICENSE AGREEMENT

By installing and running this test suite, you are agreeing to the terms outlined in the LICENSE AGREEMENT. See LICENSE.txt. For more information contact support@qacafe.com.

Table of Contents


Welcome

Welcome to the Load Balancing and NAT Router test suite (lbrouter).

This release of lbrouter tests the following areas:




Requirements




Installation

You are now ready to run the test suite. The lbrouter test suite requires root access in order to use pktsrc. You can either run the test suite directly as root or setup sudo for buddy. However, before you begin, you must edit the configuration file 'local.conf' to match your test environment.


Basic Configuration

lbrouter can be run on a standard linux PC with 2 ethernet interfaces. The interfaces selected should not be connected to a 'real' network. These interfaces must be configured 'up', but they should not have any IP configuration.

Finding available interfaces

You can find the available network interfaces on your system using the 'ifconfig' command. From this list of interfaces, you can select 2 available network interfaces.


      # -- example of interface configuration
      # ifconfig eth2

      eth2      Link encap:Ethernet  HWaddr 00:D0:B7:79:8C:DE  
             UP BROADCAST PROMISC MULTICAST  MTU:1500  Metric:1
             RX packets:755666 errors:0 dropped:0 overruns:0 frame:6
             TX packets:39955 errors:0 dropped:0 overruns:201 carrier:0
             collisions:0 txqueuelen:100 
             Interrupt:9 Base address:0xdd00 

Cabling the test setup

The networks connecting the lbrouter linux PC to the router should be isolated networks with no other network devices. Generally, the ports can be directly cabled together using an Ethernet cross-over cable or cabled into a hub/switch so that other sniffer tools can be used.

The following is the typical configuration:

Configuring 'local.conf'

The 'local.conf' file lives in the top level directory of the lbrouter test suite. This file contains all the configuration information needed by the test suite to test the router. The configuration must match your actual test setup and configuration of your device under test.

The public and private sides for your test setup must be configured in the local.conf file. Note: The actual IPv4 addresses used for the public and private sides do not have to be public or private as far as IPv4 addresses are concerned (rfc1918). These terms are only used to describe the follow of connections. NAT connections originate on the private side, while load balacing connections originate on the public side. There are no restrictions on actual addresses.

The following parameters must be configured for the private and public interfaces.



The lbrouter test suite supports two different modes of NAT operation - basic NAT and NAPT (Network Adress Port Translation). The 'natMode' variable must be configured to match the NAT mode expected on the device. You can also set the 'natMode' to none, if you want to skip all the NAT tests.

Basic NAT Configuration

When the natMode is configured to natAdress, basic NAT will be tested. The following parameters must be configured.

NAPT Configuration

When the natMode is configured to natPort, NAPT will be tested. The following parameters must be configured.

Load Balancing Configuration

For the load balancing tests, you must configure the IP address that is load balanced and the pool of servers. The following parameters must be configured.

Multiple Configurations

You can also use multiple configuration files. By default, buddy looks for a file names 'local.conf' in the current directory, but a different configuration file may be specified using the -config option of buddy.


Running the Tests

Once the test setup has been configured, the tests may be run using buddy. With no arguments, buddy will run all the tests. NOTE: buddy needs to be run with root privilage in order to access the network interfaces of the Linux host.


qacafe:/lab/lbrouter# buddy         

INFO(setup): starting buddy ...
INFO(setup): loaded Tcl Package 'buddy'
INFO(setup): loaded Tcl Package 'pktsrc'
INFO(setup): pktsrc version is 1.2.18



Understanding Test Messages

Depending on the tracing level used during a test run, various messages will be reported. Most test messages have a simple format. The general format is as follows:


   Message-Type ( Location ): Timestamp| Text of message

The Message-Type can be either INFO, WARNING, PASS or FAIL. Most messages reported are INFO messages to explain what is happening during the test. WARNING messages are reported by the protocol state machines when an error or unexpected event happens. The PASS and FAIL Message-Types are use to indicate that some part of a test passed or failed.

The Location indicates where the message originated. Messages are associated with different parts of the test. During the initial setup of the test suite, messages will be associated with 'setup'. For example,


   INFO(setup): 14:01:07| starting DHCP client on LAN interface eth1

During an actual test, messages that originate from the test case themselves are associated directly with the test case number.


   INFO(cdrouter-3): 14:08:44| starting new DHCP client

When event happens on a specific interface, the message is associated with the specific protocol stack on that interface. For example, if an ARP packet is received on the LAN interface, you might see the following message.


   INFO(lan): 14:08:45| ARP request, who is 192.168.1.3, tell 192.168.1.3



Protocol Decodes

To see full protocol decodes of the packets sent and received, you can specify the -trace2 option of the command line. The fully decoded packet will be displayed along with the sending or receiving interface.


   PACKET-IN(eth1): received eth proto type 0800 
   ETH: ---- Ethernet Packet (length = 590) ----
   ETH: 
   ETH: Source                     = 00:20:78:d2:bf:a5
   ETH: Destination                = ff:ff:ff:ff:ff:ff
   ETH: Type                       = IPv4 (0x0800)
   ETH:
   IPv4: ---- IPv4 Header ----
   IPv4: 
   IPv4: Version                   = 4
   IPv4: Header Length             = 5
   IPv4: TOS byte                  = 0x00
   IPv4: Total Length              = 576
   IPv4: ID                        = 0x0001
   IPv4: Flags/Offset              = 0x0000
   IPv4:   Don't Fragment          = 0
   IPv4:   More Fragments          = 0
   IPv4:   Offset                  = 0
   IPv4: TTL                       = 150
   IPv4: Protocol                  = UDP (0x11)
   IPv4: Checksum                  = 0x6103
   IPv4: Src                       = 192.168.1.1
   IPv4: Dest                      = 255.255.255.255
   IPv4:
   UDP: ---- UDP Packet ----
   UDP: 
   UDP: Source Port                = 67 
   UDP: Destination Port           = 68 
   UDP: Length                     = 556
   UDP: Checksum                   = 0x525a
   UDP:
   DHCP: ---- DHCP Packet ----
   DHCP: 
   DHCP: Type                      = Reply (0x02)
   DHCP: Hardware Type             = 0x01
   DHCP: Hardware Address Len      = 0x06
   DHCP: Hops                      = 0x00
   DHCP: Transaction ID            = 0x00408289 (xid)
   DHCP: Seconds                   = 0x0000
   DHCP: Flags                     = 0x0000
   DHCP: Client IP                 = 0.0.0.0 (ciaddr)
   DHCP: Your IP                   = 192.168.1.2 (yiaddr)
   DHCP: Server IP                 = 0.0.0.0 (siaddr)
   DHCP: Relay IP                  = 0.0.0.0 (giaddr)
   DHCP: Client HW Addr            = 00:d0:b7:6b:04:2c (chaddr)
   DHCP: ---- Options ----
   DHCP:
   DHCP: Magic Cookie              = 99.130.83.99
   DHCP: Message Type              = DHCPACK
   DHCP: Mask                      = 255.255.255.0
   DHCP: Routers
   DHCP:   Router 1                = 192.168.1.1
   DHCP: DNS Servers
   DHCP:   DNS Server 1            = 1.1.1.1
   DHCP: IP Address Lease Time     = 86400 seconds (24.0 hours)
   DHCP: Server Identifier         = 192.168.1.1
   DHCP:
   DHCP: ---- End DHCP Packet ----



End to End Testing

Normally, the lbrouter test suite is used to test a single IP device. However, the test suite can be configured to test through a network that contains additional IP devices.


  
linux host --/public/-- router 1 -- router 2 --- LB device
w/lbrouter                                            |
    |                                                 |
    +--------/private/--------------------------------+

If multiple IP routers are connected between the LB Router and the public interface on the test host, the publicIp and publicNextIp addresses should be set based on the IP addresss of the first router connected to the public side of the test suite. In the topology above, 'publicIp' would be set to router 1's IP address on the public side and 'publicNextIp' would be set to an available IP address on the same network. The 'publicNatIP' or 'loadBalanceIp' variable should be set to the expected public side address of the load balancing device.

Since the additional IP routers change the expected IPv4 hop count between the private and public interfaces, the 'IPv4HopCount' variable should be set to the number of IPv4 hops. Normally, this is set to 1.


Getting More out of the test suite

There are several techniques that can be used to increase your testing mileage with the lbrouter test suite.

Repeat a single test or repeat multiple tests

You can setup a test run that repeats a single test or collection of tests. This is helpful to verify that the router continues to function correctly over time.

Capture test output

It is often useful to save the test output for later analysis. There are several ways of doing this, but one useful technique is 'tee'.

Use trace options

There are three tracing options that can display different levels of output.

Combine with other tools

It is often useful to combine 'lbrouter' with other tools to get different views of events as they happen. tcpdump or ethereal are good examples.


More Information

More information on buddy's test execution control options can be found in the buddy README file. On redhat and debian systems, this is included in the /usr/share/doc/buddy directory.


Getting Help

Help is available through support@qacafe.com.