With the DOCSIS add-on, CDRouter is perfectly suited for testing and verifying the higher layer network functionality of a DOCSIS-based device under test (DUT). The basic CDRouter test setup for cable gateways is very similar to the test setup for DSL-based gateways.
Like the DSL test setup, CDRouter does not have the ability to terminate a cable gateway’s HFC WAN connection directly. As a result, a CMTS must be included in a cable gateway test setup, as opposed to a DSLAM for DSL gateways. In either setup, the function of the CMTS or DSLAM is essentially the same - to terminate the gateway DUT’s WAN connection (DOCSIS or DSL, respectively) and transparently bridge all traffic onward.
The most straightforward way to test both Cable Modems and eRouters in the same test setup is with the CDRouter DOCSIS add-on. This allows CDRouter to directly simulate the DOCSIS provisioning steps including DHCP options, TFTP delivered config files, ToD, and more.
CDRouter DOCSIS still requires the use of a CMTS, best configured in bridge mode.
In many service provider test environments, there is often a single, large CMTS shared amongst several groups and it cannot be isolated for exclusive use by CDRouter. Many times, the CMTS is also used within the production environment.
Here’s a method where test traffic from the DUT is routed through the CMTS (and potentially also the corporate or test LAN) to reach CDRouter’s WAN interface and vice versa.
In the example test setup below, the CMTS is a shared resource somewhere within the local network and cannot be isolated for exclusive use by CDRouter.
Note that this diagram shows the DUT(GW) and Cable Modem as seperate devices, but this configuration also applies to devices that have this functionality combined into one physical device.
To configure CDRouter for this type of setup, you will need to ensure that testvar values in your CDRouter configuration file match your specific environment. The following subsections will highlight the required tetsvars for each relevant portion of your network environment.
The values for the testvars in the following sections will match the diagram above.
One of the key testvar values to define is the IP address of the DUT’s WAN interface, which is desginated by
testvar wanIspAssignIp in the CDRouter configuration file.
The IP address of the DUT’s WAN interface is either:
The diagrams below further illustate both typical options that may describe your particular setup.
In most cases, the testvar
testvar wanMode should be set to DHCP. Note that in this setup, CDRouter’s DHCP server is only able to assign an IP address to the DUT’s WAN interface (either one of the above). The Cable Modem must already be running and configured by your own provisioning DHCP server (for HFC and MTA/E-MTA) before testing can start.
It may also be necessary to configure your internal network to exclude giving out a specific address. Then this excluded address may be given out by CDRouter’s DHCP server. Additionally, you can configure CDRouter’s DHCP server to only respond to the MAC address of the DUT’s gateway address with
When wanMode is set to DHCP, you will also have to specify the address of the next-hop router that will forward the DUT’s traffic to and from CDRouter’s WAN interface. This is designated by the testvar
If you are not able to segregate your DHCP server traffic from CDRouter’s, you may need to configure CDRouter to be in “static” mode (wanMode set to static) and then allow your existing network infrastructure to provision both the Cable Modem’s HFC/MTA address as well as the DUT’s Gateway address. In this case, wanDutMac and wanIspAssignGateway do not need to be specified. In this case, you must know ahead of time what the address of the DUT’s gateway is, and use that IP for the testvar wanIspAssignIp.
In the configuration file, CDRouter’s WAN address is desginated by
testvar wanIspIp. This IP is likely an address on your local corporate/test LAN and should be excluded from being used by other systems on your network. It should be allocated for CDRouter use only. CDRouter will assign this value to the WAN interface on its own, but you may want to be sure the DHCP server used on your corporate/test LAN excludes it from use.
You will also need to ensure that the CMTS (and any other intermediate routers) are configured to forward test traffic to CDRouter’s WAN interface. This usually means adding static routes to treat wanIspIp as the next-hop router for any of CDRouter’s emulated WAN services, like DNS, NTP, ACS(TR-069).
Another testvar you also have to specify is the gateway address that CDRouter’s WAN interface should use to get traffic to and from the DUT. This is very likely the corporate (or test) router/gateway that routes traffic between the local network and the CMTS. The testvar
testvar wanIspGateway is used to designate this address.
In the diagram above, the servers (DNS, NTP, ACS) and endpoints (HTTP, NAT, etc.) are emulated by CDRouter and must be assigned addresses that are logically “upstream” of CDRouter’s WAN interface. This means that the CMTS (and other intermediate routers) will also need to have static routes configured for these servers so that traffic to them is forwarded using CDRouter’s WAN interface wanIspIp as the next-hop router.
Each emulated server will have its own testvar(s). They are listed in the sample configuration below.
A sample of the relevant CDRouter configuration, based on the test setup above, is provided below. Note, there are differences between the DHCP and static setups.
# -- Sample CDRouter configuration for routed CMTS setup # -- The Gateway address is provided by CDRouter's DHCP server testvar wanMode DHCP # CDRouter "side" testvar wanIspIp 126.96.36.199 testvar wanIspGateway 188.8.131.52 testvar wanIspMask 255.255.255.0 # DUT "side" testvar wanIspAssignIp 184.108.40.206 testvar wanIspAssignGateway 220.127.116.11 testvar wanNatIp 18.104.22.168 testvar wanIspNextIp 22.214.171.124 testvar wanDutMac b0:75:0c:01:00:01 testvar IPv4HopCount 2 # Simulated services 'behind' CDRouter's WAN interface testvar wanDnsServer 126.96.36.199 testvar wanBackupDnsServer 188.8.131.52 testvar ntpServer1 184.108.40.206 testvar ntpServer2 220.127.116.11 testvar remoteHostIp 18.104.22.168 testvar acsIp 22.214.171.124 testvar FreeNetworkStart 126.96.36.199 testvar FreeNetworkMask 255.255.255.0 testvar FreeNetworkStop 188.8.131.52
# -- Sample CDRouter configuration for routed CMTS setup # -- The Gateway address is provided by the ISP's DHCP server testvar wanMode static # CDRouter "side" testvar wanIspIp 184.108.40.206 testvar wanIspGateway 220.127.116.11 testvar wanIspMask 255.255.255.0 # DUT "side" testvar wanIspAssignIp 18.104.22.168 testvar wanNatIp 22.214.171.124 testvar IPv4HopCount 2 # Simulated services 'behind' CDRouter's WAN interface testvar wanDnsServer 126.96.36.199 testvar wanBackupDnsServer 188.8.131.52 testvar ntpServer1 184.108.40.206 testvar ntpServer2 220.127.116.11 testvar remoteHostIp 18.104.22.168 testvar acsIp 22.214.171.124 testvar FreeNetworkStart 126.96.36.199 testvar FreeNetworkMask 255.255.255.0 testvar FreeNetworkStop 188.8.131.52
In some cases, the number of subnets that are available to allocate for testing with CDRouter is constrained. It is possible to further edit CDRouter’s configuration so that less subnets are required.
The values used above are the default ones. If, for example, you can only allocate a single /24 (255.255.255.0) subnet for use with CDRouter, you would have to ensure that all the defined servers and endpoints are defined within that one subnet.
Assuming that only 10.0.1.x/24 may be allocated for a static route, then a configuration of the severs and endpoints may look something like the following:
# -- Sample CDRouter configuration for routed CMTS setup, where # -- only the a single subnet (10.0.1.x/24) may be used as a staic route # IPv4 DNS Servers testvar wanDnsServer 10.0.1.1 testvar wanBackupDnsServer 10.0.1.2 # IPv4 NTP Servers testvar ntpServer1 10.0.1.3 testvar ntpServer2 10.0.1.4 # IPv4 Remote Host testvar remoteHostIp 10.0.1.5 # ACS testvar acsIp 10.0.1.6 # IPv4 Free Network Range testvar FreeNetworkStart 10.0.1.16 testvar FreeNetworkMask 255.255.255.240 testvar FreeNetworkStop 10.0.1.254
The above setup is also posssible in an IPv6 environment and there are similar testvars that exist for IPv6:
# -- Sample CDRouter DHCP relay configuration testvar ipv6WanMode DHCP # CDRouter "side" testvar ipv6WanIspIp 3001::1 testvar ipv6WanIspGateway 3001::2 testvar ipv6WanIspPrefixLen 64 # DUT "side" testvar ipv6WanIspAssignIp bbbb::10 testvar ipv6WanIspNextIp bbbb::11 testvar IPv6HopCount 2 # Simulated services 'behind' CDRouter's WAN interface testvar ipv6WanDnsServer 3001:51a:cafe::2 testvar ipv6WanBackupDnsServer 3001:51a:cafe::3 testvar ipv6NtpServer1 4321::23 testvar ipv6NtpServer2 4321::24 testvar ipv6RemoteHost 3001:051a:cafe::1 testvar acsIp 3001::3 testvar ipv6FreeNetworkStart 3001:cafe:1:: testvar ipv6FreeNetworkPrefixLen 64 testvar ipv6FreeNetworkStop 3001:cafe:ffff::
For IPv6 configurations the relay must send router advertisements on the downstream interface so that the DUT can obtain a default route. In addition, the relay must be configured with a static route so that packets received on the upstream interface that are destined for the DUT’s LAN network, bbbb::/64 in this example, are forwarded to the downstream interface connected to the DUT’s WAN.