CDRouter Support

CDRouter User Guide

user-guide version 10.4

Introduction

Welcome!

Welcome to the Cable/DSL Router test suite CDRouter! CDRouter is a comprehensive test tool for Cable/DSL/SOHO/Edge and wireless routers and other similar IP devices. The test suite contains several types of tests including functional, conformance, negative, denial of service, and scaling.

The CDRouter test suite simulates a networking environment by creating LAN clients, providing an ISP connection to the device under test, and exercising different protocol and traffic flows. CDRouter can create IP hosts and services that appear to be operating out in the Internet. The test suite covers a wide range of protocols and applications that you would expect to find in a CPE router environment.

Test Organization

CDRouter is organized into several test modules of related functionality. Each test module contains several test cases. Tests can be executed using CDRouter’s web interface (called BuddyWeb) or through the command line interface (called buddy).

Before any tests are run, CDRouter attempts to set up a testing environment that is common to all tests. The initial setup phase includes starting a LAN client and establishing the WAN connection. Once the initial test setup is established, CDRouter moves on to executing specific test cases.

Test Coverage

This release of CDRouter tests the following areas of a Cable/DSL Router device:

  • Ethernet and IEEE 802.11a/b/g/n wireless interfaces
  • DHCP client (WAN side)
  • PPPoE client (WAN side)
  • PPPoA client (WAN side)
  • PPTP client (WAN side)
  • L2TP client (WAN side)
  • DHCP server (LAN side)
  • Bridge mode
  • 802.1q and 802.1p VLANs on the LAN interface
  • 802.1q, 802.1p, and 802.1ad VLANs on the WAN interface
  • ISP Renumbering Scenarios
  • NAT for TCP/UDP/ICMP/SCTP, Static NAT hosts
  • MSS Clamping for TCP sessions
  • 802.1X including EAPOL, EAP-MD5, EAP-TLS, EAP-TTLS, EAP-PEAP, EAP-SIM, EAP-AKA
  • WPA-PSK, WPA-RADIUS, Dynamic WEP using supported EAP types
  • Firewall/Security
  • DMZ host configurations
  • IGMP proxy/multicast pass through
  • IPSEC, PPTP, and PPPoE pass through
  • ALGs - FTP, DNS, ICMP, H.323, MSN, RTSP
  • DNS Proxy and Failover
  • mDNS
  • SIP ALG
  • LLDP
  • LAN side MAC filtering
  • IP Forwarding
  • DHCP Client Scaling
  • Dynamic IP Routing (RIPv1/v2)
  • Virtual Services
  • URL Filtering
  • Port Triggers
  • Universal Plug and Play (UPnP)
  • Hotspot login via HTTP/HTTPS
  • DynDNS client verification
  • Xbox Live compatibility testing
  • Nmap integration (various Nmap scans are provided for information only)

Additional Add-Ons

Additional add-ons that extend CDRouter’s testing capability into other specific protocol areas are also available. Add-ons are currently available for:

Please refer to our website for more information.

Installing CDRouter

System Requirements

For complete listing of current hardware and software requirements for CDRouter, please see this article in our Knowledge Base.

Installation Procedure

Please see the complete installation instructions for CDRouter in our Knowledge Base.

Test Setup

CDRouter runs on a standard Linux PC using a combination of Ethernet, ATM, and wireless network interfaces. Three network interfaces are typically required for a CDRouter test system:

  • One management interface
  • One WAN test interface (Ethernet, wireless, or ATM)
  • One LAN test interface (Ethernet or wireless)

Finding Available Interfaces

You can find the available network interfaces on your Linux system using the /sbin/ifconfig command. From this list of interfaces, you can select two available network interfaces.

# -- example ifconfig output for eth1
eth1      Link encap:Ethernet  HWaddr 00:1b:21:01:20:1c
          UP BROADCAST  MTU:1500  Metric:1
          RX packets:1285 errors:0 dropped:0 overruns:0 frame:0
          TX packets:125 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:253489 (253.4 KB)  TX bytes:22574 (22.5 KB)

Linux Configuration of Test Interfaces

The interfaces selected for testing should not be connected to a real network; they should only be connected to the test setup or to the DUT directly. The test interfaces must be administratively up (or active), but they should not have any IP configuration within the Linux operating system.

Most modern Linux systems use a utility called Network Manager to configure and control installed network interfaces. For information on how to properly configure CDRouter test interfaces on systems with Network Manager, please see this Knowledge Base article. For information on setting up CDRouter test interfaces on older systems or system that do not have Network Manager installed, see this Knowledge Base article.

MAC Addresses

CDRouter’s LAN and WAN stacks use the MAC addresses specified by the testvars lanMac and wanMac, respectively. These values must be unique and cannot be set to the MAC address of the underlying physical interface specified by the testvars lanInterface and wanInterface respectively. If either of these testvars are not specified, a random MAC address will be generated using the OUI specified by the cdrouterOui testvar, which defaults to QA Cafe’s IEEE OUI prefix of B0-75-C0.

Any additional LAN hosts that are created during test cases will also automatically generate a MAC address using the cdrouterOui value.

For multiport configurations on the WAN side the default value of the wanMac testvar for each defined interface is computed using the WAN interface group number. For example, if wanMac is b0:75:0c:01:00:01 in the main testvar group, then wanMac would default to b0:75:0c:02:00:01 in the testvar group wan2, b0:75:0c:03:00:01 in the testvar group wan3, etc..

Connecting the Test Setup

CDRouter’s LAN and WAN test interfaces should be connected directly to the test setup. In addition, the test setup should be isolated and include only the DUT and in certain cases additional required network components such as a DSLAM, CMTS, or OLT.

CDRouter can connect to the LAN side of the DUT using wired Ethernet or 802.11 a/b/g/n/ac wireless LAN interfaces. Likewise, CDRouter can connect to the WAN side of the DUT using Ethernet, 802.11 a/b/g/n wireless, or ATM interfaces. Some common CDRouter test setups are detailed below.

Wired Test Setup

This is the most common setup for CDRouter testing. CDRouter’s LAN test interface is connected directly to one of the LAN ports on DUT via Ethernet. Likewise, CDRouter’s WAN test port is connected directly to the DUT’s WAN test interface via Ethernet.

wired lan.png

Wireless Test Setup

Another common test setup involves wireless on the LAN. In this setup CDRouter is configured to connect to the DUT’s LAN via an 802.11 a/b/g/n/ac wireless interface. CDRouter’s WAN test interface is still directly connected to the DUT via Ethernet.

wireless lan.png

On certain systems running CDRouter 9.2 and later, support for testing multiple wireless clients on a single interface may be possible. Please see the LAN Wireless Setup section for more information.

multi station wireless lan.png

ATM WAN Test Setup

In most cases CDRouter will connect to the test setup via Ethernet on the WAN. However, when testing routers with built in DSL interfaces, a DSLAM must be included in the test setup. The DSLAM will have either an ATM or Ethernet uplink port. If the DSLAM being used has an ATM uplink, CDRouter’s WAN can be connected directly to the DSLAM uplink port using an installed ATM network interface.

atm wan.png

For more information on testing DSL routers with CDRouter, please see this Knowledge Base article.

LTE WAN Test Setups

LTE routers or hotspots can be tested with CDRouter provided the necessary infrastructure is available. To test LTE routers, CDRouter will connect via Ethernet or wireless to the LAN side of the DUT, and then via Ethernet to the LTE network simulator.

lte setup.png

Other WAN Test Setups

In some cases additional network components may be required and present on the WAN between CDRouter and the DUT. This is the true when testing DOCSIS cable gateways and GPON ONTs which require a CMTS or OLT, respectively, to properly terminate the WAN connections on the DUT. In these setups CDRouter’s WAN test interface will connect to the CMTS or OLT via Ethernet.

other wan.png

For more information on testing DOCSIS cable gateways, please see this Knowledge Base article. For information on testing GPON ONTs, please see this Knowledge Base article. To test a travel router that employs wireless on the WAN, please see this Knowledge Base article.

Configuration Overview

Before running tests with CDRouter, a configuration file must be created. The configuration file describes the test setup, general test or protocol behavior, and the configuration of the device under test (DUT). A configuration file can be generated from CDRouter’s web interface or from the command line using the cdrouter-cli -new-config option.

The configuration file contains several test variables that are specified using the testvar keyword. The format of each testvar is as follows:

testvar keyword value

If a testvar value contains whitespace characters, it must be enclosed in double quotes. For example:

testvar myname “This is my name”

The configuration file is organized into sections which contain all of the testvars associated with a particular CDRouter add-on, protocol, or aspect of the test setup. The CDRouter configuration file may also contain Tcl style comments by beginning a line with the ‘#’ character.

Existing configuration files can be upgraded from an older format to the current format directly from CDRouter’s web interface or from the command line using the buddy -upgrade-config option. The upgrade-config option preserves all testvar values from the source configuration value and carries them forward to a new configuration file. The resulting configuration file will be identical to the source configuration file but will include any new testvars that have been added since the source configuration file was originally created. Please see this Knowledge Base article for more information on upgrading configs.

LAN Configuration

CDRouter supports wired (Ethernet) and wireless (802.11 a/b/g/n/ac) interfaces on the LAN. For a complete list of the interfaces supported by CDRouter, please see this Knowledge Base article. Note that CDRouter automatically detects the type of interface (Ethernet or wireless) when the testvar lanInterface is defined by the user.

In certain scenarios it may be helpful to disable CDRouter’s LAN interface. This can be accomplished by setting the testvar lanInterface to the keyword none. This is most often used when testing endpoints such as STBs, VoIP ATAs, or NAS devices that do not have a LAN interface. This can also be helpful for simplifying the test setup when the primary focus is on WAN specific functionality such as TR-069 or Nmap. Any test cases that require end-to-end connecitivity or LAN specific functionality will be automatically skipped when lanInterface is set to none.

CDRouter supports many different security modes on the LAN for both wired and wireless interfaces. The security type used by CDRouter is specified by the testvar lanSecurity, which was introduced in CDRouter 8.1 and deprecates the testvars wirelessAuthType, eapDynamicWep, and lanUseEAPOL. Some security modes require 802.1X authentication. CDRouter includes a built-in RADIUS server for 802.1X authentication on the LAN. Please see the LAN RADIUS Setup section for more information.

For wireless interfaces, CDRouter supports the following security modes:

  • WPA-802.1X = aka WPA Enterprise or WPA-RADIUS
  • WPA-PSK = aka WPA Personal
  • 802.1X-WEP = aka dynamic WEP
  • WEP = static WEP
  • NONE = no security

For wired interfaces CDRouter supports the following security modes:

  • 802.1X = wired 802.1X
  • NONE = no security

Additional configuration options for wireless interfaces can be found in the LAN Wireless Setup section.

LAN Interface Configuration

LAN 802.1q VLAN

DHCP Client Configuration

The following testvars describe the configuration of the DUT’s LAN DHCP server and CDRouter’s LAN DHCP clients.

DHCP Client Reservations

DHCP Client Extra Parameters

DHCP Client Extra Options

LAN RADIUS Setup

CDRouter includes a built-in RADIUS server for hotspots and 802.1X authentication on the LAN. CDRouter’s RADIUS server will automatically respond to all Access-Request messages from the DUT and process the embedded EAP messages or PAP login requests. CDRouter’s RADIUS server supports all of the EAP types allowed by the testvar eapType.

The RADIUS server user database is automatically configured based on the EAP identities defined in the LAN 802.1X Setup section of the configuration file. In order to use CDRouter’s RADIUS server, the DUT must be configured with the remoteHostIp address as the RADIUS server address on port 1812. In addition the DUT must be configured with the RADIUS secret specified by the radiusSecret testvar.

Additional RADIUS server attributes may also be defined. Each RADIUS attribute will be returned in any Access-Accept message sent to the DUT by CDRouter’s RADIUS server.

Note that CDRouter Multiport users can optionally move the RADIUS server from the WAN to an unused LAN interface. Please see this Knowledge Base article for more information on how to set up the RADIUS server on the LAN.

LAN 802.1X Setup

CDRouter supports 802.1X Port-Based Network Access Control for wired and wireless LAN interfaces. When running CDRouter with 802.1X enabled on the LAN, CDRouter will use its built-in supplicant to authenticate the wired or wireless port before running any test cases. CDRouter also contains several test modules with specific tests cases for EAPOL, RADIUS, and various EAP types.

To test with 802.1X authentication on the LAN, the DUT must be configured with CDRouter’s RADIUS server IP, port, and pre-shared key. Please see LAN RADIUS Setup section of the configuration file for information on configuring CDRouter’s built-in RADIUS server for 802.1X testing.

CDRouter supports a number of common EAP types for 802.1X testing on the LAN. The LAN EAP type is specified using the testvar eapType. For security modes that require 802.1X, certain EAP types may or may not be supported. Please see this Knowledge Base article for more information.

LAN EAP Credentials

For EAP-TLS, EAP-TTLS, and EAP-PEAP testing, you must configure CDRouter with valid X.509 certificates in PEM format. CDRouter includes 20 example PEM certificates in the /usr/share/doc/cdrouter directory that can be used as EAP credentials for 802.1X testing. Up to 16 sets of credentials can be configured per LAN interface.

Depending on the EAP type that is selected, only some of the EAP identity and certificate information needs to be configured. If a testvar entry is not required for the specific EAP Type, it will be ignored.

  • EAP-MD5 - For EAP-MD5, the eapIdentity and eapPassword entries must be configured for each EAP Identity in use.

  • EAP-TLS - For EAP-TLS, the eapIdentity entry must be configured. The eapPassword entry is not required. Additionally, the eapUserCertPath, eapUserCertPassword, and eapUserPrivateKey entries must be configured.

  • EAP-TTLS - For EAP-TTLS, the eapIdentity and eapPassword entries must be configured for each EAP Identity in use. The EAP-TTLS supplicant does not use a user certificate.

  • EAP-PEAP - For EAP-PEAP, the eapIdentity and eapPassword entries must be configured for each EAP Identity in use. The EAP-PEAP supplicant does not use a user certificate. By default, the PEAP supplicant will use EAPMSCHAPv2 as the inner EAP authentication method.

  • EAP-SIM - For EAP-SIM, the eapIdentity and eapPassword entries must be configured for each EAP Identity in use.

  • EAP-AKA - For EAP-AKA, the eapIdentity and eapPassword entries must be configured for each EAP Identity in use.

LAN 802.1X Configuration Options

LAN Wireless Setup

Starting with CDRouter 8.0, the Linux kernel’s wpa-supplicant is utilized for wireless interfaces; this significantly enhances the stability and robustness of CDRouter when testing with wireless. This also allows for a much wider range of supported adapters - most adapters natively supported by the Linux kernel will work with CDRouter.

CDRouter 9.2 introduced support for wireless virtualization on the LAN. This feature allows multiple wireless clients to be created on the LAN using a single wireless interface which enables CDRouter to run all tests, including the scaling test modules over wireless interfaces. Prior to CDRouter 9.2, all tests that required the creation of additional clients on the LAN were skipped by CDRouter automatically. This limitation has now been removed on select systems that meet the hardware and software requirements needed to support this new feature.

CDRouter will automatically determine at run-time if a system and configured wireless interface support virtualization. If virtualization is supported, CDRouter will create multiple wireless clients as needed, up to a maximum limit defined by the testvar lanWirelessMaxClients. If virtualization is not supported CDRouter will only be able to create a single client per wireless interface. If no other LAN interfaces are available, any test that requires multiple clients will be automatically skipped. Please see this Knowledge Base article for a list of test modules and test cases that may be skipped.

In CDRouter Multiport configurations multiple wireless LAN interfaces may be configured. Each wireless interface has its own independent set of configuration options. This allows for testing of DUTs that support multiple simultaneous SSIDs, such as a simultaneous dual band routers or routers points that offer a separate guest network.

The lanSSID testvar specifies the SSID of the DUT. CDRouter will perform a wireless scan on the configured lanInterface and search for this SSID.

WPA Encryption Configuration Options

CDRouter supports the concept of ‘auto mode’ for wireless interfaces that are using WPA security. See this Knowledge Base article for a description of WPA ‘auto- mode’.

WEP Encryption Configuration Options

CDRouter supports 64 or 128 bit WEP keys.

Advanced Wireless Settings

Static Host Entries

WAN Configuration

CDRouter supports several main modes of operation depending on the WAN side configuration of the router. The testvar wanMode must be set to one of the following:

  • static - The router is configured with a static IP address on the WAN.
  • DHCP - The router is configured to run on a DHCP client on the WAN.
  • PPPoE - The router is configured to run a PPPoE client on the WAN.
  • PPPoA - The router is configured to run a PPPoA client on the WAN.
  • PPTP - The router is configured to run a PPTP client on the WAN.
  • L2TP - The router is configured to run a L2TP client on the WAN.
  • dslite - The router is configured to DS-Lite on the WAN.
  • none - The router does not support IPv4 on the WAN.

CDRouter 7.0 and newer releases support a new mode of operation for testing bridging devices. This mode is useful for verifying the basic forwarding functionality of wireless access points, smart switches, and bridged DSL CPE. Bridge mode is enabled by setting the testvar forwardingMode to bridge. By default bridge mode is disabled within CDRouter.

Note that CDRouter TR-069 can also be used in bridge mode to test the DUT’s TR-069 client, if present. Please see this Application Note for more information on bridge mode testing with CDRouter.

WAN Interface Configuration

DHCP Configuration

PPPoE Configuration

The PPPoE configuration on your Cable/DSL router must match CDRouter’s expected PPPoE configuration. There are several PPPoE and PPP related configuration parameters you can control. If your router uses a Connect-On-Demand type connection, you must configure the pppoeConnectOnDemand testvar to yes. When the Connect-On-Demand mode is in use, CDRouter will automatically send traffic from the LAN to the WAN when trying to establish a PPPoE session.

PPPoA Configuration

The PPPoA configuration on your Cable/DSL router must match CDRouter’s expected PPPoA configuration. In order to run PPPoA, the wanMode testvar must be set to PPPoA. Additionally, an ATM PVC must be configured using PPPoA- LLC or PPPoA-VC encapsulations. There are several PPPoA and PPP related configuration parameters you can control. If your router uses a Connect-On- Demand type connection, you must configure the pppoaConnectOnDemand testvar to yes. When the Connect-On-Demand mode is in use, CDRouter will automatically send traffic from the LAN to the WAN when trying to establish a PPPoA session.

PPTP Configuration

If your router is running a PPTP client connection on the WAN interface, you can configure the wanMode to PPTP. The following PPTP testvars must be enabled in your configuration file.

When configuring your router for PPTP, the PPTP server address should be the same address as the wanIspIp address. The local WAN side address of the router should be the same as the wanIspAssignIp address.

L2TP Configuration

If your router is running a L2TP client connection on the WAN interface, you can configure the wanMode to PPTP. The following PPTP testvars must be enabled in your configuration file.

When configuring your router for L2TP, the L2TP server address should be the same address as the wanIspIp address. The local WAN side address of the router should be the same as the wanIspAssignIp address.

DS-Lite Configuration

Global PPP Configuration

WAN 802.1q VLAN

WAN 802.1ad VLAN

The testvars below enable 802.1ad VLAN stacking support. By default, CDRouter will use standard 802.1ad TPID tag values for the outer S-tag (0x88a8) and inner C-tag (0x8100) VLANs. Setting the wanOuterVlanQinQ testvar to “yes” will enable “QinQ” style tagging, causing CDRouter to use 0x8100 for both the outer and inner tag. Please see this Knowledge Base article for more details.

When enableVlanStacking is set to “yes”, CDRouter will ignore the wanVlanId and wanVlanPriority WAN 802.1q VLAN testvar settings and use the settings below instead.

WAN ATM Interface Setup

CDRouter supports direct ATM connections using a PVC. The following testvars are used to configure the ATM interface on the WAN.

WAN RADIUS Setup

CDRouter supports 802.1X authentication on the WAN starting with Release 6.2. For more information on testing with 802.1X port based authentication on the WAN, please see this Application Note.

WAN 802.1X Setup

CDRouter supports 802.1X authentication on the WAN starting with Release 6.2. For more information on testing with 802.1X port based authentication on the WAN, please see this Application Note.

WAN EAP Credentials

WAN 802.1X Configuration Options

DNS Setup

User Configurable DNS Entries

NTP Setup

The following testvars describe the configuration of CDRouter’s integrated NTP servers on the WAN.

Dynamic DNS Setup

CDRouter supports the Dynamic DNS protocol created by Dynamic Network Services, Inc.. The dyndns.tcl test module verifies that a client complies with the DynDNS.org update syntax and specifications.

There are several configuration settings that control the DynDNS test setup.

WINS Server Configuration

WAN DHCP Relay Setup

IPSec Tunnel Configuration

CDRouter can terminate IPSEC ESP tunnel mode connections from the device under test. In order to test IPSEC tunnels on your device, you must configure the IPSEC tunnels on your device and create a corresponding IPSEC tunnel configuration in the CDRouter configuration file.

There are several testvar entries that must be created for each tunnel to define the remote gateway, destination network, inbound and outbound SPI numbers, security policy, and associated keys. NOTE: The base version of CDRouter only supports manual IPSEC keys. The CDRouter IKE add-on supports IKEv1 dynamic keys.

The picture below shows the logical topology that CDRouter uses for testing IPSEC tunnels. CDRouter emulates one end of each IPSEC tunnel. CDRouter is also able to emulate a remote network that is reachable through the tunnel and hosts on the remote network.

IpsecDiagram.jpg

The following IPSEC tunnel configuration parameters must be configured in your CDRouter config file for each tunnel that will be tested. Each tunnel parameter ends with a number that identifies the tunnel. Each testvar shown in the IPSEC ESP Tunnel Configuration table should be appended with the actual number of the tunnel such as 1, 2, 3, etc. CDRouter’s default config template contains an example in the “IPsec Tunnel Configuration” section.

IPSEC Testing and NAT

The ipsec-esp.tcl test module does not require that the device apply NAT to outgoing packets before they enter the IPSEC tunnel. This test module can be used with devices that do apply NAT and devices that do not. Many of the test cases in the ipsec-esp.tcl test module will attempt to establish connections to the hosts specified in the ipsecTunnelHost entry. The device does not need to apply NAT to these packets in order for these tests to run.

If your device does support NAT over IPSEC tunnels, you can configure the remoteHostIp address inside of a configured IPSEC tunnel. When configured this way, many of the existing test modules for NAT, forwarding, applications, etc can be used to verify NAT over IPSEC. NOTE: If you configure the remoteHostIp address inside of an IPSEC tunnel, your device must apply NAT before packets from the LAN are forwarded in the IPSEC tunnel.

Example NAT over IPSEC configuration

The following is an example configuration where the remoteHostIp is placed within an IPSEC tunnel. This allows many of the test cases that use the remoteHostIp address to verify NAT over IPSEC.

# IPSEC tunnel to 5.0.0.0/255.255.255.0
testvar ipsecTunnelEndpoint1 5.0.0.1
testvar ipsecTunnelRemoteNetwork1 5.0.0.0
testvar ipsecTunnelRemoteMask1 255.255.255.0
# (continued tunnel config for SPI, keys, etc...)

# emulated host on network 5.0.0.0/255.255.255.0 
testvar ipsecTunnelHost1 5.0.0.12 

# emulated remoteHost on network 5.0.0.0/255.255.255.0 
testvar remoteHostIp 5.0.0.15 

Layer 3 GRE Tunnel Configuration

There are a few different types of GRE tunnels commonly found in modern CPE and wireless gear. Initial support for what are known as layer 3 IPv4 GRE tunnels, as defined in RFC 2784, was added in CDRouter 10.4. PPTP also relies on a slightly different flavor of GRE, as defined in RFCs 1701, 1702, and 2683.

Another common type of GRE tunnel is what is referred to as L2oGRE. L2oGRE is layer 2 type tunnel that is more commonly used in managed wireless networks as a control link between APs and wireless controllers. CDRouter does not support L2oGRE at this time, but may in the future.

Layer 3 GRE tunnels are lightweight and have no inherent security or authentication. Layer 3 GRE tunnels connect two subnets - typically between the LAN subnet and a remote subnet on the WAN.

IP packets that are forwarded over the GRE tunnel are encapsulated/decapsulated by the tunnel endpoints, ie the CPE and a remote endpoint on the WAN. Encapsulation consists of adding an RFC 2784 style GRE header to all forwarded IP packets. At the remote end the GRE header is stripped by the tunnel endpoint and the packets are forwarded to the remote subnet.

There is typically no NAT or firewall on layer 3 GRE tunnels. As a result, CDRouter assumes that there is no NAT or firewall on any defined GRE tunnels.

Within CDRouter one or more layer 3 GRE tunnels can be defined in the “GRE IPv4 Tunnels” portion of the config file:

        SECTION "GRE IPv4 Tunnels" {

            testvar greDFflag                        on

            IGNORE testvar_group greTunnel1 {

                testvar greEndpoint                      5.5.5.5
                testvar greLocalNet                      192.168.1.0
                testvar greLocalMask                     255.255.255.0
                testvar greRemoteNet                     3.0.0.0
                testvar greRemoteMask                    255.0.0.0
                testvar greHost                          3.0.0.1

            }

        }

For each layer 3 GRE tunnel the local subnet (greLocalNet / greLocalMask), remote subnet (greRemoteNet / greRemoteMask), remote GRE tunnel endpoint (greEndpoint), remote GRE host (greHost), and expected fragmentation behavior (greDFflag) must be defined. The remote GRE host is used as an endpoint for the various tests included in the gre test module.

The gre test module has a number of basic tests that verify traffic forwarding over the tunnel in the upstream and downstream directions with and without valid (and invalid) checksums, fragmentation, etc.

WAN Wireless Setup

Beginning with CDRouter 9.1, it is possible to use a wireless interface for CDRouter’s WAN.

wifiwan.png

As usual, the WAN interface can be set with the wanInterface testvar.

If a wireless interface is specified, CDRouter’s internal Access Point (AP) will be enabled. Further configuration of CDRouter’s AP can be done in the “Wireless Access Point (AP)” section of the configuration file.

If wireless authentication is desired on the WAN, this can be enabled by setting the wanAuthenticator testvar to yes. In this case, CDRouter will provide all authentication services on its AP.

If a wireless interface is specified and a WAN authenticator is used, further configuration of CDRouter’s AP can be done in the “WPA Authenticator” section of the configuration file.

When setting up the DUT to use CDRouter’s WAN interface as its wireless AP, it is often necessary to have CDRouter’s AP up and running so that the DUT can see it and be configured to use it. Starting the test package can accomplish this. During the start process, CDRouter’s wireless AP will be running, allowing the DUT to be configured. If the start process ends too quickly to allow time to configure the DUT, the startTimeout testvar can be increased.

Please note that if a wireless connection is desired on both the LAN and WAN, then two physical wireless cards are required by CDRouter.

NAT and Firewall Configuration

The following testvars define the expected NAT behavior of the DUT.

CDRouter 7.3+ allow NAT to be disabled for testing CPE devices with public IP LAN clients. See the Application Note, “Testing LAN clients with Public IP addresses in CDRouter” for more information and configuration examples.

NAT Setup

NAT Timer Configuration

Protocol Pass Through Setup

IPSEC Pass Through Configuration

PPTP Pass Through Configuration

L2TP Pass Through Configuration

PPPoE Pass Through Configuration

Special Application Port Triggers Setup

Application Layer Gateway Setup

H.323 (NetMeeting) ALG Configuration

MSN Messenger ALG Configuration

RTSP ALG Configuration

SIP ALG Configuration

If the DUT supports a SIP ALG the following testvars should be configured.

FTP ALG Configuration

Virtual Services Setup (TCP and UDP)

TCP Virtual Services Configuration

UDP Virtual Services Configuration

Denial of Service Configuration

Deprecated SSL Protocol and Cipher Configuration

DMZ Configuration

CDRouter can test routers with a DMZ configuration. In order to test with a DMZ configuration, an IP address for a DMZ host on the LAN must be configured. This address must be on the same subnet as the router’s LAN IP address.

As part of the DMZ testing, CDRouter will scan a range of TCP and UDP ports to verify that the router forwards these entries to the DMZ host. These port scans skip any virtual services that are configured on the router. There is also an option to specify other ports that should be skipped. These may be specific ports that have been configured to drop packets or reject connections regardless of the DMZ configuration. For example, port 113 (ident) is commonly configured to reject connections.

All of the existing test modules can be run when the router has a DMZ configuration except the firewall module. When a DMZ host is configured, the firewall module is automatically skipped since the DMZ setting defeats any general firewall setting.

The following DMZ configuration parameters are available:

URL Filtering Configuration

MAC Filtering Configuration

CDRouter 8.0 added support for LAN side mac filtering. Please see this Knowledge Base article for more information.

XBox Configuration

Advanced Protocols Configuration

RIP Setup

The following testvars describe the RIPv1 or RIPv2 configuration of the DUT.

Static Route Setup

The following testvars describe any LAN or WAN static routes that may be configured on the DUT.

UPnP Setup

The following testvars describe the UPnP configuration of the DUT.

LLDP Setup

CDRouter 8.0 added support for LLDP. Please see this Knowledge Base article for more information.

Multicast Setup

CDRouter can test routers with IGMP proxy or multicast pass through support. CDRouter will act as an IGMPv2 or IGMPv3 client on the LAN side of the router. CDRouter will also act an as a multicast router on the WAN side of the router and deliver multicast streams.

If the router supports IGMP proxy, it must be configured to run an IGMPv2 or IGMPv3 client on the WAN interface. Please see this CDRouter University article for more information on multicast testing with CDRouter.

The following multicast configuration options are available:

IGMP Timer Configuration

IPTV Configuration

Additional Features Configuration

General Purpose HTTP Server Configuration

Free Network Range Configuration

During a test run, CDRouter will simulate different hosts on both the LAN side of the network and the WAN side of the network. In some cases, CDRouter may need to find an unused IP network or IP address to use in a test. Some of the tests also use a host IP on the WAN interface that can be configured with remoteHostIp. This IP address should not conflict with any addresses in the free network range. Also, it should not be on the same IP network as the router’s WAN IP address. The following diagram shows logically how the remoteHostIp address is used.

LogicalTopology.jpg

TCP MSS Clamping Configuration

TCP/UDP Scaling Configuration

Test Execution Options and Auto-Reboot Configuration

The following testvars can be used to various aspects of how tests are executed, including auto-reboot.

At the start of each test run, CDRouter will automatically pause and prompt the user to reboot the DUT.

IMPORTANT(setup): 13:53:56.857| Restarting DUT ...

>>> Please restart the device under test
>>> Then PRESS <enter> to continue: 

CDRouter is paused.

Rebooting the DUT is recommended to ensure that the device is in a “known state” and helps to avoid inconsitent behavior during testing.

To avoid having to manually reboot the DUT and unpaus CDRouter to proceed with the test run, you can define the RestartDut testvar to launch a custom script that is able to reboot the DUT automatically.

Similarly, the ShutdownDut testvar will call a custom script that can power off the DUT.

Your custom scripts may be written in any language you choose so long as it can be executed from the Linux command line shell.

The RestartDut testvar takes a single TCL string representing the script name and any optional arguments that you may want to be passed in with the script. If you are passing arguments to the script, you need to put the entire testvar value within quotes so that it is treated as a single string:

testvar RestartDut       "/home/qacafe/myScript arg1 arg2"

You can execute multiple commands by separating them with a semicolon ( ; ):

testvar RestartDut       "/home/qacafe/myScript arg1 arg2 ; /usr/local/bin/myScriptTwo a1 a2 a3"

Since CDRouter executes the script using the TCL “exec” command, you need to be careful to avoid any special characters (like ‘$’ and ‘[’ ) that might be interpreted by the TCL parser.

If you want to pass the value of a CDRouter testvar from your config file into the script, you need to use the following CDRouter TCL syntax:

testvar RestartDut       "/home/qacafe/myScript [buddy::getvar wanIspIp] arg2"

It is important to note that when using this syntax, CDRouter resolves the expression immediately as it parses the RestartDut testvar value. CDRouter replaces this syntax with the resulting value, and then continues to parse the rest of the config file. So in the example above, the wanIspIp testvar must be defined earlier in the config file than the RestartDut testvar. Otherwise, the buddy::getvar syntax will return a default value for wanIspIp.

CDRouter provides default values for most testvars. If a default value is not available, an empty string (“”) is returned. Please see the Testvars documentation page for more details on default values assigned by CDRouter.

To see a practical example of how the RestartDut and ShutdownDut testvars might be used to control a managed power supply to power the DUT on and off, please see this Knowledge Base article.

Nmap Configuration

CDRouter Nmap is new add-on that is automatically included in the base version of CDRouter beginning with CDRouter 7.0. The CDRouter Nmap add-on includes four test modules, nmap.tcl, nmap-wan.tcl, nmap-v6.tcl, and nmap- wan-v6.tcl, which are designed to provide additional information about the DUT and how it behaves and appears on the network using the popular Nmap network scanner. The Nmap test modules perform various nmap port scans on the DUT’s LAN and WAN interfaces over both IPv4 and IPv6. Please see the Nmap test case summaries for details on the tests included.

Note that CDRouter’s Nmap test modules ire based on the 6.00 version of Nmap and require a 2.6.35 or newer Linux kernel. Also note that the IPv6 Nmap tests can only be run if the CDRouter IPv6 add-on is installed.

Minimal configuration is required to run the Nmap tests. By default Nmap support is disabled within CDRouter. To enable Nmap the testvar supportsNmap must be set to yes. The testvar nmapScanTimeout is provided which defines the amount of time to wait for an Nmap scan to complete. If the timeout is reached, the scan will be stopped and the test will be marked as a FAIL. This testvar defaults to a value of 900 seconds. The testvar nmapTimingTemplate selects the timing profile that will be used for each scan. Nmap has 6 built in timing templates that adjust retries and timeouts. The values range from 0 to 5. CDRouter uses a default value of 5 which runs the scan as fast as possible. Lowering this value will produce slower scans. Please see Nmap’s manual for more information on the timing template option.

The following testvars enable Nmap support within CDRouter.

End to End Testing

Normally, CDRouter is used to test a single Cable/DSL router device. However, the test suite can be configured to test through a network that contains additional IP devices. Typically, this is used to test a Cable/DSL router connected to a DSLAM device through a cable/xDSL modem. This can also be used to test routers that have built in xDSL connections.

DSLSetup.jpg

CDRouter supports DSLAM devices that have an Ethernet or ATM uplink. In the case of ATM, you must have an ATM card installed in your Linux host.

If multiple IP routers are connected between the Cable/DSL Router and the WAN interface on the test host, the WAN mode can be configured to ‘static’ or ‘DHCP’. In order to use DHCP on the WAN in this type of topology, a DHCP-relay agent is required.

Multiple Routers on the WAN: Static Mode

The wanIspIp and wanIspGateway addresses should be set based on the IP address of the first router connected to the WAN side of CDRouter. The wanNatIp variable should be set to the expected WAN side address of the Cable/DSL router.

RelaySetup.jpg

Example:

The following example configuration could be used on the WAN side to enable CDRouter to run in the example topology above.

# -- set WAN interface to static mode
testvar wanMode static

# -- the ISP’s IP address
testvar wanIspIp 10.0.0.2
testvar wanIspMask 255.255.255.0
testvar wanIspGateway 10.0.0.1

# -- the expected NAT address of the router under test
testvar wanNatIp 4.0.0.2

# -- the expected number of IPv4 hops in the topology
testvar IPv4HopCount 3

Multiple Routers on the WAN: DHCP-Relay Mode

To run in DHCP-relay mode, two additional configuration parameters are needed. The wanIspIp and wanIspGateway addresses should be set based on the IP address of the first router connected to the WAN side of the test suite. The additional testvars wanIspAssignIp and wanIspAssignGateway should be included and configured to the IP address and IP gateway address that should be assigned to the Cable/DSL router. The wanNatIp variable should be set to the expected WAN side address of the Cable/DSL router.

Please see this Knowledge Base article for more information on DHCP relay testing.

IPv4 Hop Count

The IPv4HopCount testvar specifies the number of IPv4 hops between the LAN and WAN interfaces. In the default setup where CDRouter is directly connected to the DUT, this is set to 1. In the configurations above where there are multiple routers connecting CDRouter’s WAN interface to the DUT, this testvar should be increased to account for the additional router hops.

Hotspot Routers

CDRouter supports hotspot routers that require a user to login before full access is granted to the WAN interface. The hotspot support allows a DHCP client to login into a web service using HTTP or HTTPS. Each DHCP client has an associated user name and password that can be configured or automatically assigned.

The router may be configured to use internal authentication or some other authentication scheme such as RADIUS. If the router uses RADIUS authentication for hotspot clients, CDRouter can also act as a RADIUS server and handle authentication and accounting requests from the router. The RADIUS server currently handles PAP style authentication.

Configuration

The HTTP or HTTPS login can be enabled by defining a list of URLs that should be accessed once the DHCP client on the LAN is active. Normally, more than one URL is required to login. The first URL triggers HTTP redirection and typically sets up a HTTP session cookie. The next URL may send a HTTPS GET that includes a username and password.

In scenarios where the login and logout process is more complex, you may define a HTTP login and logout Tcl procedures to handle the login and logout. Example login and logout Tcl scripts are included in the /usr/share/doc/cdrouter /helper-scripts directory.

HTTP Login Examples:

To enable HTTP login using a simple URL list, a testvar for each URL may be defined.

testvar browserLoginUrl1 http://www.yahoo.com/
testvar browserLoginUrl2 https://192.168.1.1/login?user=%USERNAME%&passwd=%PASSWORD%

The browserLoginUrl* testvar entries may contain 3 different keywords surrounded by the “%” character that are dynamically substituted for each clients specific values before the URL is accessed.

  • %USERNAME% is translated to the client’s user name.
  • %PASSWORD% is translated to the client’s password.
  • %IPADDRESS% is translated to the clients IPv4 address on the LAN.

HTTP Logout Example

To enable HTTP logout using a simple URL list, a testvar for each URL may be defined.

testvar browserLogoutUrl1 http://192.168.1.1/logout?username=%USERNAME%

Advanced HTTP Login

If a Tcl procedure is required to handle the HTTP login, it may be defined using the browserLoginProc testvar.

Tcl Procedure Example:

source /usr/share/doc/cdrouter/helper-scripts/hotspot-login.tcl
testvar browserLoginProc example_login
testvar browserLogoutProc example_logout

Client User Names and Passwords

Client usernames and passwords default to client<N> and admin<N> for each client where <N> is the client number. For example, the first DHCP client will have a username of “client1” with a password of “admin1”. You may also configure specific usernames and passwords for each client using the following testvars.

testvar clientLoginName1 qacafe
testvar clientLoginPassword1 qacafe123
testvar clientLoginName2 fish
testvar clientLoginPassword2 secret123

Hotspot Configuration Reference

Example Scripts

The following example script shows an example Login and Logout procedure that could be used on a hotspot router. For more examples please see /usr/share/doc/cdrouter/helper-scripts.

#
# This file contains example login and logout scripts that can be used
# with a hotspot router service. These scripts are intended to be 
# an example only. Depending on the hotspot router, you may need to
# customize this script or develop your own.
#

#
# Login procedure
#
# The login procedure takes the client stack as its only argument.
#
# In this example, the client sends an initial HTTP GET to a
# web page in order to start the HTTP redirection process. During
# the redirection, a session cookie will be established. The client
# then sends a HTTP GET to load a login page using the username
# and password.
# 

proc example_login { stack } {
    upvar $stack s

    set router [ testvar lanIp ]
    set username [ Stack_get_client_name s ]
    set password [ Stack_get_client_password s ]
    set remoteIp [ testvar remoteHostIp ]
    
    # -- load a dummy URL to trigger the redirection
    HTTP_get s http://$remoteIp/dummy.htm page1

    # -- load the login page
    set urlbase https://$router/loginpages/userlogin.shtml?myusername
    set status [ HTTP_get s $urlbase=$username&mypassword=$password page2 ]

    # -- check the result
    if { $status < 0 } {

        pktsrcWarn s "Client $name failed to login"

    } elseif { "$page2(response-code)" != "200" } {

        pktsrcWarn s "Received response $page2(response-code), expecting 200"

    } 

    # -- done with login
}
 
#
# Logout procedure
#
# The logout procedure takes the client stack as its only argument.
#
#
# In this example, the client needs to use the session id to send
# an HTTP GET to the router. The logoff page takes the session id
# as an argument. The web server stores the session id in a cookie
# that is sent to the client.
#
 
proc example_logout { stack } {
    upvar $stack s
 
    # -- find the routers IP address on the LAN
    set router [ testvar lanIp ]
 
    # -- get the cookie for the session, this is the same as the session id
    set session [ HTTP_get_cookie s $router ]
 
    # -- make sure we have a session cookie
    if { "$session" == "" } {
        pktsrcWarn s "Can not find session cookie, can't logoff"
        return
    }
 
    # -- get the client's username
    set name [ Stack_get_client_name s ]
 
    # -- open the logoff URL
    HTTP_get s https://$router/loginpages/logoff.shtml?uid=$name&$session page
}

Using CDRouter Multiport

CDRouter Multiport supports DUTs with multiple WAN and/or LAN interfaces. Each additional WAN interface may be a separate physical interface such as Ethernet or ATM, or a separate logical interface on the same physical card. For ATM WAN interfaces a logical interface is a unique ATM PVC; for Ethernet WAN interfaces a logical interface is a unique VLAN. Additional LAN interfaces may be separate Ethernet or 802.11a/b/g/n wireless interfaces. Up to 64 additional WAN and/or LAN interfaces can be configured with CDRouter Multiport.

CDRouter Multiport includes all of the test modules available with the base CDRouter package. In addition, there are several multiport specific test modules included that look at multiple WAN failover and inter-LAN behavior.

For more information on multi-service gateway testing with CDRouter please see this CDRouter University article.

Using Multiple WAN Interfaces

Multiple WAN interfaces on a DUT can be grouped into two categories - backup WAN interfaces and always-on WAN interfaces. Backup WAN interfaces do not normally connect when the DUT is restarted. If the primary WAN interface goes down, the backup WAN interface is started. Always-on interfaces connect when the DUT is restarted. Traffic may be sent over these interfaces based on load balancing policies, IP routing, or other configured policies. DUTs with always-on interfaces can send traffic over multiple WAN links simultaneously. However, DUTs with backup WAN interfaces usually send traffic over a single interface at a time.

CDRouter Multiport supports both types of WAN interface. The number of test cases available for backup WAN interfaces is more limited since generally only one interface is active at a time. The multiport configuration sections below describe how to configure additional WAN interfaces as backup or always-on interfaces.

Multiport WAN Configuration

The configuration of the first WAN interface is done in the same manner as the base version of CDRouter. Refer to the Basic Configuration section for an overview of the base configuration.

In order to configure additional WAN interfaces beyond the first WAN interface, the CDRouter Multiport version uses the testvar_group keyword in the configuration file. The testvar_group keyword works similar to the testvar variable. However, testvar_group allows you to define several testvar entries that all apply to the same interface. The format for the testvar_group keyword is as follows:

testvar_group wan2 {

    testvar wanInterface eth3
    testvar wanNatIp 4.4.4.4
    ...
    ...

}

All of the additional WAN interface variables are defined inside of a group.

Creating testvar_group Names

Additional WAN interface groups must be created using well known group names. Each additional WAN interface must be named wan2, wan3, wan4, etc. Up to 64 different WAN interfaces may be defined. The group names do not have to be in order.

New Multiport Configuration Options for the WAN

The CDRouter Multiport has some additional testvar options that can be set on a global basis or on a per interface basis. The following options are available.

Within each group, several of the WAN related configuration options can be specified. The following list defines all of the WAN configuration options that can be specified for each additional WAN interface.

WAN Interface Configuration

DHCP Configuration

PPPoE Configuration

PPPoA Configuration

PPTP Configuration

L2TP Configuration

Global PPP Configuration

WAN 802.1q VLAN

WAN 802.1ad VLAN

WAN ATM Interface Setup

WAN DHCP Relay Setup

Multiport with Connect-on-Demand Configurations

Connect-on-Demand options are not available on a per WAN interface basis. If a global Connection-On-Demand option is configured, CDRouter will use this to bring up the first WAN interface. There is no Connect-on-Demand option that can be enabled for additional WAN interfaces.

WAN Failover and Load Balancing Issues

CDRouter supports routers using load balancing techniques. However, traffic to the remoteHostIp address should always be forwarded out the first WAN interface when that interface is active.

Using Multiple LAN Interfaces

CDRouter Multiport supports multiple interfaces on the LAN as well using additional Ethernet or wireless interfaces. Among other things, this allows CDRouter to test both wireless and wired interfaces at the same time. Additionally, when CDRouter is running with multiple LAN interfaces, it will cycle test cases through each LAN interface to allow all physical interfaces to be utilized.

Just like the single LAN version of CDRouter, the multiple LAN version will create a DHCP client on each physical interface. During the startup phase, CDRouter will bring up each LAN interface before starting any tests.

Multiport LAN Configuration

The configuration of the first LAN interface is done in the same manner as the base version of CDRouter. Refer to the Basic Configuration section for an overview of the base configuration.

In order to configure additional LAN interfaces beyond the first LAN interface, the CDRouter multiport version uses the testvar_group keyword in the configuration file. The testvar_group keyword works similar to the testvar variable. However, testvar_group allows you to define several testvar entries that all apply to the same interface. The format for the testvar_group keyword is as follows:

testvar_group lan2 {

    testvar lanInterface eth3
    ...
    ...

}

All of the additional LAN interface variables are defined inside of a group.

Additional LAN interfaces may be placed in the same LAN subnet or different subnet or VLAN.

Creating testvar_group Names

Additional LAN interface group names must be created using well known group names. Each additional LAN interface must be named lan2, lan3, lan4, etc. Up to 64 different LAN interfaces may be defined. The group names do not have to be in order.

LAN Interface Configuration

When additional LAN interfaces are created, CDRouter Multiport has some additional testvar options that can be set on a global basis or on a per interface basis. The following options are available.

LAN Host IP Configuration

LAN 802.1q VLAN

DHCP Client Configuration

DHCP Client Reservations

LAN 802.1X Setup

LAN EAP Credentials

LAN Wireless Setup

WPA Encryption Configuration Options
WEP Encryption Configuration Options
Advanced Wireless Settings

NAT and Firewall Setup

Static NAT Setup
Special Application Port Triggers Setup
Virtual Services Setup (TCP and UDP)
TCP Virtual Services Configuration
UDP Virtual Services Configuration

Commenting out Additional Interfaces

An additional LAN or WAN interface may be commented out of the configuration file by placing the keyword IGNORE before the testvar_group name of the applicable interface. For example:

IGNORE testvar_group lan2 {

    testvar lanInterface eth3
    testvar lanType ethernet
    ...
    ...

}

Configuring a RADIUS Server on the LAN

With CDRouter Multiport, an additional LAN interface may be configured to run a RADIUS server. The additional LAN interface must have a static IP address configured using the hostIp configuration. The global testvar radiusHost is used to enable the RADIUS server on this interface.

If the main CDRouter LAN interface is wireless and the RADIUS server will also be on the LAN, the testvar startOtherLanFirst should be configured to yes to force CDRouter to bring up the additional LAN interfaces before starting the main LAN interface. This allows the built-in RADIUS server to become operational before any wireless LAN interfaces are started.

Configuration example (NOTE: The radiusHost address must match the testvar_group name on one of the additional LAN interfaces):

testvar radiusHost lan2
testvar enableRADIUSserver yes
testvar radiusSecret qacafe123
testvar startOtherLanFirst yes

# -- configure additional LAN interface for RADIUS server
testvar_group lan2 {
 
        # -- specify the physical interface
        testvar lanInterface eth3

        # -- configure a different MAC address
        testvar lanMac 00:00:cc:cc:01:02
 
        # -- mark the interface as ethernet
        testvar lanType ethernet

        testvar hostIp 192.168.1.220
        testvar hostMask 255.255.255.0

}

Static NAT Hosts on the LAN

With CDRouter-Multiport, static NAT hosts on the LAN can be configured using the additional LAN interface configuration. In order to designate the additional LAN interface as a static NAT host, the public side IP address and specific LAN side IP address must be specified.

Additionally, static NAT hosts can have unique virtual services, port triggers, NAT mode, and firewall configuration.

**Basic static NAT example:

The following example shows a basic static NAT host with a public IPv4 address of 68.1.2.18 and a private side IPv4 address of 192.168.1.100 on physical interface eth3.

testvar_group lan2 {

        testvar lanInterface                    eth3
        testvar lanType                         ethernet
        testvar hostIp                          192.168.1.100
        testvar staticNatIp                     68.1.2.18
        testvar lanMac                          00:01:22:33:44:55

}

The following list defines the additional options that are possible for a static NAT host.

Advanced static NAT example:

The following example shows a more advanced static NAT host with a public IPv4 address of 68.1.2.18 and a private side IPv4 address of 192.168.1.100 on physical interface eth3. The static NAT host also contains unique virtual services and port triggers.

testvar_group lan2 {

        testvar lanInterface                    eth2
        testvar lanType                         ethernet
        testvar hostIp                          192.168.1.100
        testvar staticNatIp                     68.1.2.18
        testvar lanMac                          00:07:07:07:07:01
        testvar firewallTcpOpenPorts            "22"
        testvar firewallUdpOpenPorts            "22"

        testvar virtualTcpServices              yes
        testvar virtualTcpServicePort1          21
        testvar virtualTcpServiceHost1          192.168.1.100
        testvar virtualTcpServiceName1          ftp
        testvar virtualTcpServiceLanPort1       21

        testvar virtualUdpServices              yes
        testvar virtualUdpServicePort1          69
        testvar virtualUdpServiceHost1          192.168.1.100
        testvar virtualUdpServiceName1          ftp
        testvar virtualUdpServiceLanPort1       69

        testvar portTriggers                    yes
        testvar triggerName1                    AIMtalk
        testvar triggerPort1                    4099
        testvar triggerType1                    tcp
        testvar triggerPublic1                  5190
        testvar triggerPublicType1              tcp

}

Adding New Test Cases

NOTE: QA Cafe now has a separate Developer’s Guide. Please refer to the QA Cafe Developer’s Guide for an overview of the test development process. The Developer’s Guide is available in the Development Resources section.

Upgrades

Upgrading CDRouter is an easy process – just follow the steps below.

Upgrading an Existing Installation

Upgrade to a New Release of CDRouter:

If you would like to upgrade to a newer release of CDRouter or CDRouter Multiport, there is no need to re-install the license file. To upgrade, simply download the new release from the Customer Lounge and follow the installation instructions provided in the installation section of this User Guide, omitting the steps related to installing a license file.

Install New Add-ons or Update the License File for an Existing Installation:

If you have purchased additional CDRouter add-ons or extended your Maintenance and Service Agreement, you must update your license file. Updating your license file will upgrade the system and enable any new add-ons or functionality. CDRouter does not need to be reinstalled. To update your license file, please follow the license file installation instructions, or issue the following command as root:

$ cdrouter-cli –update-license

Note that the cdrouter-cli -update-license command will automatically download and install the latest license file for your system. This command requires an active internet connection on the Linux host machine.

Upgrading from the Demo Version

Before installing the full version of CDRouter on a system that was previously running the CDRouter Demo, you should delete the demo version and license file completely.

You can use the -e flag to automatically delete the demo version:

$ rpm -e cdrouterdemo pktsrc buddy

To remove the license file use the rm command:

$ rm –rf /etc/cdr-DEMO.lic

Test Notes

DHCP Client

The default DHCP lease time used by CDRouter is 300 seconds (5 minutes). If several of the dhcp-c.tcl module tests are failing, it could be that the router does not deal gracefully with a short DHCP lease time when setting up the T1 and T2 timers for DHCP. When a DHCP lease is starting to expire, some DHCP clients will drop directly into DHCP discovery mode without attempting to send any DHCP request packets. This can cause several test failures in the dhcp-c.tcl module. You can adjust the DHCP lease time by setting the dhcpLeaseTime variable in your configuration file.

NOTE: Some test cases will wait an entire DHCP lease interval. Setting the dhcpLeaseTime to a large value will slow down test execution dramatically. We recommend trying to find the smallest value that will work with your DHCP client.

NAT

All the CDRouter NAT tests verify that the router is using Network Address Port Translation (NATP).

Trigger Ports and Special Applications

CDRouter can test up to 4096 different trigger port configurations on a router. Each trigger port can be configured with a single outbound port number and one or more ports that should be open on the inbound side of the router.

Trigger Port Example

testvar triggerName1 My-Special-Application
testvar triggerPort1 10003
testvar triggerType1 tcp
testvar triggerPublic1 7501-7502
testvar triggerPublicType1 tcp

If the application has multiple outbound ports that will trigger the same inbound port range, you must configure multiple triggerPort entries for each outbound port number. In this case, QA Cafe recommends that you test each trigger port individually. Once the port mapping is created by the router, there is no conclusive way for CDRouter to verify that other outbound port connections will also open the same inbound port range.

UPnP

CDRouter’s UPnP test module supports versions 1.0 and 1.1 of the Universal Plug and Play Device architecture defined by the UPnP Forum as well as both InternetGatewayDevice:1 (IGDv1) and InternetGatewayDevice:2 (IGDv2) device protocols.

Please see the UPnP testing guide for more information.

TCP

CDRouter uses its own version of TCP for verification of TCP traffic through the router and for TCP connections directed to the router for UPnP. When the TCP session is between two hosts across the router, any packet loss from the router will cause the TCP session to fail. The endpoints will not retransmit any lost TCP segments. This allows CDRouter to quickly determine packet loss by the router under test.

When the TCP connection is directed to the router (UPnP), CDRouter does use a retransmission timer on the TCP session. This allows the TCP session to recover from any packet loss from the router. Any packet loss detected by TCP will still be logged as a WARNING but will not cause a test to fail.

WARNING(lan) 12:40:00| TCP Retransmission timer fired for session *:10377 -> 192.168.1.1:80

IPSEC Pass Through

Some vendors have implemented an IPSEC pass through technique that attempts to associate inbound and outbound SPI values in the IPSEC ESP header to support multiple pass through connections to the same destination IP address. This allows a router to multiplex inbound IPSEC packets to the correct LAN host. Similar techniques also exist for ISAKMP packets using the initiator and responder cookies. The CDRouter test cases for IPSEC/ESP and IKE/ISAKMP use unique SPI and ISAKMP cookie values to allow these types of techniques to be verified.

H.323 ALG Testing

CDRouter uses H.225 Version 2 during the H.323 ALG tests. This is the same version used by Microsoft Netmeeting. The device under test must support H.225 Version 2 or higher.

802.1x/EAP

CDRouter contains example X.509 certificates in PEM format that can be used for EAP-TLS. The password used to generate all certificates is qacafe123. If you are generating your own certificates, CDRouter should be configured to use PEM formats for the root and user certificates.

The example certificates are installed under:

/usr/share/doc/cdrouter/root.pem
/usr/share/doc/cdrouter/server.pem
/usr/share/doc/cdrouter/user1.pem
/usr/share/doc/cdrouter/user2.pem

Dynamic WEP

When using the built-in RADIUS server, the EAPOL test suite uses the MS-MPPE- Send-Key and MS-MPPS-Receive-Key attributes to relay dynamic key information to the authenticator device.

Contents

×

About CDRouter

CDRouter is made by QA Cafe, a technology company based in Portsmouth, NH.

Get in touch via our Contact page or by following us on your favorite service: