CDRouter is the ideal tool for testing the higher layer functionality of DSL based CPE. With a few additions to the basic test setup, CDRouter can be used to test CPE utilizing any type of DSL or G.fast devices.
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
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).
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. 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.
