qacafe - ip test solutions
Application Notes > DSL CPE testing with CDRouter

Overview

The test setup for DSL CPE devices is similar to the test setup for typical Ethernet-to-Ethernet routers, with one exception. Since CDRouter does not have the ability to terminate the CPE device’s DSL connection directly, a dedicated DSLAM must be included in the test setup. The primary function of the DSLAM is to terminate the CPE’s DSL connection and transparently bridge all traffic from the CPE to its WAN/uplink interface. This allows CDRouter to be connected to the CPE’s Ethernet or wireless LAN interface(s) and also to the DSLAM’s ATM or Ethernet WAN/uplink interface creating an end-to-end test network.

There are two keys to this type of setup. The first is that the DSLAM used for testing must support the DSL type implemented by the CPE. Furthermore, it is assumed that the CPE device is able to establish and maintain a stable DSL connection with the DSLAM. If these conditions are met, the exact type and configuration of the DSL physical layer is irrelevant as far as CDRouter is concerned. In essence, CPE utilizing any type of DSL-based WAN interface can be tested with CDRouter provided a DSLAM capable of terminating that CPE device is also included in the test setup.

The second key is the Layer 2/3 configuration of the DSLAM. The DSLAM must be configured to bridge all traffic from the port being used for testing to the WAN interface. Bridging allows CDRouter to communicate directly with the CPE by simply connecting to the DSLAM’s WAN interface. In this type of configuration all other CPE not being tested should be turned off, disconnected, or administratively disabled. This minimizes the possibility of CDRouter receiving unwanted packets which may alter test results.

Test Setup

There are two basic test setups for DSL CPE devices - one involving an IP/Ethernet based DSLAM and another involving an ATM DSLAM. The exact make, model, and type of DSLAM chosen in either test setup should have absolutely no impact on the CPE's test results. In many cases it is easiest to simply use whatever DSLAM is on-hand or readily available. In cases where a DSLAM must be purchased specifically for CDRouter testing, we recommend IP/Ethernet DSLAMs which are typically less expensive and do not require an additional ATM interface adapter.

The configuration of CDRouter will be slightly different for each setup, as will the configuration of the DSLAM. The following sections discuss each setup in detail.

Using CDRouter with an IP/Ethernet Based DSLAM

The basic test setup for testing a DSL based CPE device with an IP/Ethernet based DSLAM is shown below.



Here CDRouter's LAN test interface connects directly to one of the CPE's LAN interfaces via Ethernet. CDRouter's WAN test interface connects via Ethernet also to the WAN interface on the DSLAM. The CPE is connected to port 1 of the DSLAM via DSL, and both the CPE and DSLAM (port 1) are configured to use ATM PVC 0/35. The CPE is also configured to use PPPoE on its WAN/DSL interface.

The configuration of CDRouter in this example is fairly straightforward, since only Ethernet interfaces are used. The test setup and configuration resembles that of an Ethernet-to-Ethernet router, where the DSLAM and CPE together can be viewed as the device under test. A few of the basic testvars that must be configured for this example are:

  testvar lanInterface eth1
  testvar lanType ethernet
  testvar lanIp 192.168.1.1

  testvar wanInterface eth2
  testvar wanIspIp 192.168.200.1  
  testvar wanIspAssignIp 192.168.200.2
  testvar wanNatIp 192.168.200.2
  testvar wanIspNextIp 192.168.200.254

  testvar wanMode PPPoE
  testvar pppoeConnectOnDemand no
  testvar pppoeUser qacafe
  testvar pppoePassword qacafe123

Using CDRouter with an ATM Based DSLAM



When using an ATM based DSLAM, the LAN side connections remain the same as in the IP DSLAM case above, while CDRouter's WAN test interface connects via ATM (typically OC-3 using multi-mode or single-mode fiber) to the WAN interface of the DSLAM. As in the IP DSLAM case above, the CPE is connected to port 1 of the DSLAM via DSL, and both the CPE and DSLAM (port 1) are configured to use ATM PVC 0/35. The CPE is also configured to use PPPoE on its WAN/DSL interface, and the DSLAM is configured to use RFC1483/2684 LLC encapulation for bridged protocols.

The major difference when using an ATM based DSLAM is that an appropriate ATM interface card must be installed in the CDRouter host system. Information about installing and setting up an ATM interface can be found in the ATM section of our Knowledge Base.

The configuration of CDRouter in this example involves two ATM specific testvars - wanAtmInterface and wanAtmEncap. The format of wanAtmInterface is interface.VPI.VCI. Note that many Linux ATM drivers have limitation on the VPI that restricts it to 0. The testvar wanAtmEncap can be one of six different modes:

  • 1483Bridged-LLC
  • 1483Bridged-VC
  • PPPoA-LLC (only supported if wanMode is PPPoA)
  • PPPoA-VC (only supported if wanMode is PPPoA)
  • 1483Routed-LLC
  • 1483Routed-VC

For more information on either of these testvars, see the CDRouter User Guide. The basic CDRouter setup when using an ATM based DSLAM is:

  testvar lanInterface eth1
  testvar lanType ethernet
  testvar lanIp 192.168.1.1

  testvar wanInterface eth2
  testvar wanAtmInterface 0.0.100
  testvar wanAtmEncap 1483Bridged-LLC
  testvar wanIspIp 192.168.200.1  
  testvar wanIspAssignIp 192.168.200.2
  testvar wanNatIp 192.168.200.2
  testvar wanIspNextIp 192.168.200.254

  testvar wanMode PPPoE
  testvar pppoeConnectOnDemand no
  testvar pppoeUser qacafe
  testvar pppoePassword qacafe123

Test Ideas

One advantage to using an IP DSLAM is that it allows multiple CPE to be easily connected to a single CDRouter host system using a single Ethernet WAN interface, as shown in the test setup below. Furthermore, an Ethernet switch can be used to aggregate all LAN side CPE connections to a single Ethernet LAN interface. As a result, a single CDRouter host with two Ethernet test interfaces can drive testing against any number of individual CPE (provided a remotely controllable power strip is used to turn on or off individual CPE). This type of setup lends itself to automated regression testing as described in this Application Note.



In this type of setup involving multiple CPE, it is important to note that only a single CPE should be powered on or active at any point time, if you plan to use an Ethernet switch to aggregate LAN side connections (if this is not handled properly CDRouter will be receiving packets from two devices on the same LAN interface which may result in test failure). Alternatively, using static IP addresses on the LAN side of each CPE (and disabling DHCP for CDRouter's LAN side test interface) should prevent unwanted packets from altering test results. Yet another approach would be to give each CPE is given its own dedicated LAN interface on the CDRouter host system. Doing this allows the untested CPE to be completely removed from the test setup by simply disabling the DSL connection (administratively via the DSLAM's management interface).

Similar care must be taken with the WAN side connections of the CPE as well. One way to avoid any conflicts is to use static IP addresses on the WAN connections for each CPE. By using static IP addresses, the need to power off or disable all other CPE during testing is eliminated. Alternatively, PPPoE can be used for each CPE, but it is critical that all other CPE not being tested be administratively disabled or powered off in these cases.

Perhaps the best solution to is to use a remotely controllable power strip to turn on/off select CPE for testing, as outlined in this Knowledge Base article. This allows each CPE to have any configuration and eliminates the need to properly isolate the CPE under test from all other CPE via static IP addresses or other schemes mentioned above. This also provides a mechanism for automatically rebooting a CPE before each test run ensuring that results are consistent from one test run to the next.

Questions or comments about this article?

Please contact QA Cafe Support: support@qacafe.com
www.qacafe.com
© 2008 QA Cafe