CDRouter Multiport User Guide
Overview
CDRouter test interfaces are attached to physical Ethernet or 802.11 wireless
network interface (ie eth1, eth2, wifi0-acn, wifi1-ax, etc.) within the
Linux operating system. The base version of CDRouter allows a maximum of one LAN
test interface and one WAN test interface to be enabled and used during a test
run.
CDRouter Multiport extends the base functionality by allowing up to 64 LAN and 64 WAN interface groups to be enabled and used during a test run. In addition, CDRouter Multiport enables network interface virtualization on all interface groups. This feature allows multiple, unique test interfaces and test clients to be created on a single physical interface. A maximum of 512 Ethernet test clients and up to 147 wireless test clients may be created per system on supported hardware.
With CDRouter Multiport you can:
- Simulate and test large LAN networks consisting of multiple Ethernet and/or wireless clients
- Test multi-service gateways (devices with VLAN separated logical WAN interfaces for voice, video data, and management)
- Test devices with multiple physical WAN interfaces operating in load-balancing or failover mode
- Connect and test all physical ports on a device with a single configuration
- Test wireless guest mode configurations and functionality
- Verify multi-client performance for up to 32 LAN clients
- Verify the performance of wireless to Ethernet traffic on the LAN and vice-versa
- Terminate and test L2GRE connections and functionality
Requirements and License
CDRouter supports virtualization of both Ethernet and wireless network interfaces. Ethernet virtualization is included with CDRouter. Wireless virtualization requires a supported NTA1000 hardware platform and the Wi-Fi Virtualization license.
Wireless Virtualization Hardware Support
Wireless virtualization is supported on all non-EoL NTA1000 versions. Please see the following data sheets for more information:
Please contact support@qacafe.com for more information on wireless virtualization support for older NTA1000 versions that are not listed above.
Licensing
CDRouter Multiport is a licensed expansion that must be purchased from QA Cafe. For information on upgrading a license to include CDRouter Multiport or any other expansions, please contact sales@qacafe.com.
CDRouter will report the status of all available expansions during the installation
process and during start-up. To verify that CDRouter Multiport is enabled on a
system, run the command cdrouter-cli -info and look for the line Multiport
is enabled, as shown below. If this line is present, CDRouter Multiport is
enabled and ready to use.
$ cdrouter-cli -info
Starting /usr/cdrouter/bin/cdrouter-cli Tue Dec 04 10:31:21 EST 2018
Copyright (c) 2001-2018 by QA Cafe
Version 11.0.5 (5bc22c9), built 2018-11-13 12:11:39 by build@cdr-forge6.lan (x86_64)
OS: CentOS Linux 7.5.1804 (4.14.84-1.el7.qacafe.x86_64)
CPU: Intel(R) Core(TM) i7-4790S CPU @ 3.20GHz
Current testpath: /usr/cdrouter/tests
Loaded modules from: '/usr/cdrouter/tests'
Start command: /usr/cdrouter/bin/cdrouter-cli -testpath /usr/cdrouter/tests -info
System ID: da515034731c9d770fd5a1a51b34ff05
Registered to: qacafe
Maintenance, support and upgrades until: 2020-09-16
Test suite: cdrouter
Multiport is enabled
IPv6 is enabled
Storage is enabled
IKE is enabled
TR69 is enabled
TR69-EDM is enabled
Nmap is enabled
BBF.069 is enabled
SNMP is enabled
Performance is enabled
ICS is enabled
DOCSIS is enabled
USP is disabled
NTA1000 serial number: NTA1000-10573
NTA1000 platform: 5
NTA1000 image: 5.3.19
Configuration
CDRouter Multiport supports up to 64 independently defined WAN and/or LAN test interfaces per configuration file.
The first, or primary, WAN and LAN interfaces are defined in the Base Configuration section of the configuration file. Additional WAN or LAN
interfaces are defined in the CDRouter Multiport Expansion section of the
configuration file.
Additional test interfaces must be defined using the testvar_group keyword. A
testvar_group is a collection of testvars that apply only to the test
interface(s) defined by that testvar_group.
The syntax for defining a testvar_group is as follows:
testvar_group wan2 {
testvar wanInterface eth3
testvar wanNatIp 4.4.4.4
...
...
}
Creating testvar_group Names
Additional WAN test interfaces 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.
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.
Enabling and Disabling Additional Test Interfaces
Any additional WAN or LAN test interfaces can be easily disabled by adding the
keyword IGNORE to the testvar_group name of the applicable interface. For
example:
IGNORE testvar_group lan2 {
testvar lanInterface eth3
...
...
}
Likewise, additional WAN or LAN test interfaces can be enabled removing the
keyword IGNORE from the testvar_group name:
testvar_group lan2 {
testvar lanInterface eth3
...
...
}
Multiport Architecture
Within CDRouter test interfaces must be uniquely defined and associated with Ethernet or 802.11 wireless Linux system devices, which are network interfaces within the underlying Linux operating system. A Linux system device can only be used on the WAN or the LAN (not both) within a single configuration file and must be directly connected to the device under test (DUT) in the case of Ethernet, or configured to associate to the DUT if wireless.
A Linux system device can be referenced by multiple WAN test interfaces provided that each test interface is defined with a unique VLAN ID. Likewise, a Linux system device can be referenced by multiple LAN test interfaces provided that each test interface is defined with a unique MAC address.
With the Multiport expansion additional LAN clients can be defined on LAN test interfaces. The combination of LAN test interfaces and additional LAN clients determine how many unique test clients will be created by CDRouter. CDRouter can create a maximum of 512 Ethernet test clients and 128 wireless test clients can be created per system on supported hardware. Please see the following table for more information:
| Hardware Platform | Max Test Interfaces | Max Test Clients |
|---|---|---|
| NTA1000v5 | 64 LAN, 64 WAN | 512 Ethernet, 65 wireless |
| NTA1000v6-S | 64 LAN, 64 WAN | 512 Ethernet, 192 wireless |
| NTA1000v6-10G | 64 LAN, 64 WAN | 512 Ethernet, 2 wireless |
| NTA1000v6-10GV | 64 LAN, 64 WAN | 512 Ethernet, 128 wireless |
| NTA1000v7-S | 64 LAN, 64 WAN | 512 Ethernet, 3 wireless (129 with virtualization expansion) |
| NTA1000v7-10G | 64 LAN, 64 WAN | 512 Ethernet, 2 wireless (65 with virtualization expansion) |
| NTA1000v7M-S | 64 LAN, 64 WAN | 512 Ethernet, 3 wireless (147 with virtualization expansion) |
| NTA1000v7M-10G | 64 LAN, 64 WAN | 512 Ethernet, 2 wireless (83 with virtualization expansion) |
| Non-NTA1000 | 64 LAN, 64 WAN | 512 Ethernet, one per wireless adapter |
Transient vs Persistent Test Clients
CDRouter will automatically create transient test clients as needed in test cases that require them. Transient test clients exist for the duration of the test in which they were created.
Persistent test clients can be created using the CDRouter Multiport expansion using the lanClients testvar. Persistent test clients exist for the duration of the test run and are used for testing and thus subject to the multiport ‘LAN client rotation’ feature in the same manner as traditional test interfaces.
Both transient and persistent test clients will be automatically assigned a unique MAC address upon creation by CDRouter.
Note that virtualization support is required to create more than one transient or persistent test client per test interface. Test cases that require additional transient test clients will be automatically skipped if there are no test interfaces with virtualization support available.
Persistent test clients are named using a sub-interface type convention, ie
lan.1, lan.2, lan2.1, lan2.2, etc. Test interfaces that have no
persistent test clients attached to them use the traditional interface based
naming convention, ie lan3, lan4, etc.
Example Multiport Configuration Architecture
A block diagram of an example CDRouter Multiport configuration is provided below.
In this example three different WAN test interfaces are defined in a
multi-service gateway style configuration. Each WAN test interface has a
unique VLAN ID and is bound to the same system device, eth1.
Four LAN test interfaces are defined. Two wireless test interfaces, lan and
lan3, which are bound to the system device wifi0-acn, and two Ethernet test
interfaces, lan2 and lan4, which are bound to the system device eth2.
Two of the four LAN test interfaces that are defined, lan and lan2 have two
additional LAN clients each configured. This results in a total of six LAN test
clients: lan.1, lan.2, lan3, lan2.1, lan2.2, and lan4. All six of
these clients are persistent and will exist for the duration of the test run.
Capture Files
CDRouter automatically generates capture files for all tests and test interfaces used during a test run. For every test interface or test client a master capture file, which is a journal of all packets sent to and from that test interface or test client, is created.
Master capture files are used to display the packet decodes in a log file, and
have a -m appended to the file name on disk. Master capture file names are
composed as follows:
<test name>-<test interface or test client>-m.cap
In addition to master capture files, individual device capture files are also created. Device capture files contain all of the packets sent to and from a Linux system device on the system. Device capture files are generated differently for Ethernet and wireless interfaces due to the way that each interface type is treated within the kernel.
For Ethernet interfaces, a single device capture file is created per Linux system device. Each device capture file contains all of the packets sent to and from all test interfaces and test clients bound to that interface.
For wireless interfaces, a device capture file is created for every test interface or test client that is defined. This means that multiple device capture files may be created for each wireless interface in use, whereas for Ethernet interfaces there is always a single device capture file per Linux system device.
Note that the naming convention for device capture files was updated in release 11.1. Prior to CDRouter 11.1, device capture files were named using this convention:
<test name>-<test interface>.cap
Starting with CDRouter 11.1 device capture files are named according to the following convention.
If wireless test interface:
<test name>-<test interface or test client>.cap
If Ethernet test interface:
<test name>-<lan or wan>-<device name>.cap
As an example, referring to the full Multiport architecture diagram displayed above, the following master capture files will be created on disk (only the capture files associated with start are shown here):
- start-wan-m.cap
- start-wan2-m.cap
- start-wan3-m.cap
- start-lan.1-m.cap
- start-lan.2-m.cap
- start-lan.3-m.cap
- start-lan2.1-m.cap
- start-lan2.2-m.cap
- start-lan4-m.cap
And the following device capture files will be created:
- start-eth1.cap
- start-lan.2.cap
- start-lan.3.cap
- start-eth2.cap
And in the Files dropdown within the web UI for the start test, the following capture files will be displayed:
- wan-eth1.cap
- lan.2.cap
- lan.3.cap
- lan-eth2.cap
In addition, CDRouter can be optionally configured to create 802.11 wireless device capture files with full radiotap header information for each wireless interface used during a test run.
When wireless capture is enabled, an additional device capture file will be generated for each wireless interface in use. In the example above, the following device capture file will be created:
- start-lan-wifi0-acn.cap
This capture file will also be available in Files dropdown within the web UI as:
- lan-wifi0-acn.cap
Multiport Test Methodology
All LAN test clients will be fully initialized during start. However, CDRouter will not use all available LAN test clients simultaneously within a given test case unless the test case explicitly requires multiple test clients.
When multiple LAN test clients are enabled, CDRouter will automatically select a single client from the list of available clients at the start of each test and use that client for the duration of the test. If there are no test clients available that meet the requirements of the test, the test will be skipped.
Any additional virtual clients that are required within a specific test case will be derived from the test client selected at the start of the test. If a test requires an additional test client with specific properties, CDRouter will automatically select an appropriate client from the list of available clients.
CDRouter will rotate through the list of available test clients at the start of each test. LAN client rotation is discussed in more detail below.
LAN Client Rotation
When multiple LAN test interfaces and test clients are configured, CDRouter will select one of them to use at the start of each test and automatically rotate through the list of available test interfaces and test clients for each subsequent test.
For example, four LAN test clients will be created and managed by CDRouter using the following configuration utilizing two Linux system devices:
main {
testvar lanInterface wifi1-ax
testvar lanClients 2
}
testvar_group lan2 {
testvar lanInterface eth2
testvar lanClients 2
}
Running a test package that contains only the basic test module with the above configuration, results in the following test sequence:
| Test | Sequence | Selected LAN Test Interface |
|---|---|---|
| start | 1 | All four test clients initialized |
| cdrouter_basic_1 | 2 | lan.1 |
| cdrouter_basic_2 | 3 | lan.2 |
| cdrouter_basic_10 | 4 | lan2.1 |
| cdrouter_basic_20 | 5 | lan2.2 |
| final | 6 | All four test clients removed |
Setting the useSameLanInterface testvar to “yes” will cause CDRouter to prefer the first LAN client defined in the Base Configuration section of the config file for all tests. Other LAN clients will still be created, but will only be used if a test case requires additional clients or if the main LAN client does not meet the requirements of the test (for example, if the main LAN client is on an Ethernet interface and a test requires a wireless client).
Repeating Tests
To run each test against all configured LAN test clients, the repeat option must be enabled within the test package. The number of repeats should match the number of LAN test clients defined.
In the example above, repeating each test four times would result in the following test sequence:
| Test | Sequence | Selected LAN Test Interface |
|---|---|---|
| start | 1 | All four test clients initialized |
| cdrouter_basic_1 | 2 | lan.1 |
| cdrouter_basic_1 | 3 | lan.2 |
| cdrouter_basic_1 | 4 | lan2.1 |
| cdrouter_basic_1 | 5 | lan2.2 |
| cdrouter_basic_2 | 6 | lan.1 |
| cdrouter_basic_2 | 7 | lan.2 |
| cdrouter_basic_2 | 8 | lan2.1 |
| cdrouter_basic_1 | 9 | lan2.2 |
| cdrouter_basic_10 | 10 | lan.1 |
| cdrouter_basic_10 | 11 | lan.2 |
| cdrouter_basic_10 | 12 | lan2.1 |
| cdrouter_basic_1 | 13 | lan2.2 |
| cdrouter_basic_20 | 14 | lan.1 |
| cdrouter_basic_20 | 15 | lan.2 |
| cdrouter_basic_20 | 16 | lan2.1 |
| cdrouter_basic_1 | 17 | lan2.2 |
| final | 18 | All four test clients removed |
Using the repeat option ensures that every test case is run against all configured interfaces. This makes it very easy to identify differences in behavior based on the LAN interface(s) used.
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.
During start, CDRouter will automatically initialize all configured and enabled WAN interfaces.
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.
testvar_group wan2 {
SECTION "IPv4 WAN" {
SECTION "WAN Interface" {
# testvar wanInterface eth2
# testvar wanMode DHCP
# testvar wanIspIp 202.254.3.1
# testvar wanIspAssignIp 202.254.3.2
# testvar wanIspAssignMask 255.255.255.0
# testvar wanNatIp 202.254.3.2
# testvar wanIspNextIp 202.254.3.3
# testvar wanIspMask 255.255.255.0
# testvar wanDomainName cdroutertest.com
# testvar wanDnsServer 202.254.103.1
# testvar wanBackupDnsServer 202.254.103.2
# testvar wanBackupDnsServer2 0.0.0.0
# testvar wanBackupDnsServer3 0.0.0.0
# testvar wanAlwaysOn yes
}
SECTION "DHCP Server" {
# testvar dhcpLeaseTime 300
# testvar dhcpServerBroadcast no
# testvar dhcpServerOptionCode1 69
# testvar dhcpServerOptionData1 04040404
}
SECTION "PPPoE Server" {
# testvar pppoeUser qacafe
# testvar pppoePassword qacafe123
# testvar pppoeAcName qacafe-ac
# testvar pppoeServiceName any
}
SECTION "PPTP Server" {
# testvar pptpUser qacafe
# testvar pptpPassword qacafe123
# testvar pptpServerIp 202.254.203.1
# testvar pptpClientIp 202.254.203.2
}
SECTION "L2TP Server" {
# testvar l2tpUser qacafe
# testvar l2tpPassword qacafe123
# testvar l2tpServerIp 202.254.203.1
# testvar l2tpClientIp 202.254.203.2
}
SECTION "PPP Options" {
# testvar pppAuthType PAP
# testvar pppForceLcpMRU 1500
# testvar pppMagicNumber yes
}
SECTION "WAN 802.1q VLAN" {
# testvar wanVlanId 100
# testvar wanVlanPriority 0
}
SECTION "WAN 802.1ad VLAN" {
# testvar enableVlanStacking no
# testvar wanInnerVlanId 100
# testvar wanInnerVlanPriority 0
# testvar wanOuterVlanId 100
# testvar wanOuterVlanPriority 0
# testvar wanOuterVlanQinQ no
}
SECTION "WAN DHCP Relay" {
# testvar wanIspGateway 10.0.0.2
# testvar wanIspAssignGateway 4.0.0.1
}
SECTION "WAN Static Routes" {
# testvar staticRouteWanNetwork1 7.1.1.0/255.255.255.0
# testvar staticRouteWanNextHop1 wan
}
}
SECTION "IPv6 WAN" {
# testvar ipv6WanMode DHCP
# testvar ipv6PPPoEAddressMode DHCP
# testvar ipv6WanIspIp 3001:0:0:3::1
# testvar ipv6WanIspAssignIp 3001:0:0:3::2
# testvar ipv6WanIspNextIp 3001:0:0:3::3
# testvar ipv6WanIspPrefixLen 64
SECTION "WAN IPv6 DNS" {
# testvar ipv6WanDnsServer 3001:51a:cafe:3::2
# testvar ipv6WanBackupDnsServer 3001:51a:cafe:3::3
# testvar ipv6WanBackupDnsServer2 ::
# testvar ipv6WanBackupDnsServer3 ::
}
SECTION "DHCPv6 Prefix Delegation" {
# testvar dhcpv6WanEnablePD no
# testvar dhcpv6WanEnablePDExclude no
# testvar dhcpv6WanAssignPrefix 3001:dddd:3::
# testvar dhcpv6WanAssignNextPrefix 3001:ddde:3::
# testvar dhcpv6WanAssignPrefixLen 48
}
SECTION "WAN IPv6 Static Routes" {
# testvar staticIpv6RouteWanNetwork1 3001::/64
# testvar staticIpv6RouteWanNextHop1 wan
}
}
}
}
Multiport with WAN Connect-on-Demand
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.
Multi-service Gateway Testing
For more information on multi-service gateway testing with CDRouter Multiport, please see this article.
L2GRE Testing
For more information on L2GRE test with CDRouter Multiport please refer to CDRouter User Guide.
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 base version of CDRouter, the Multiport expansion will create a DHCP client on each LAN test client. During the startup phase, CDRouter will bring up each LAN test client before starting any tests.
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.
SECTION "Additional LAN Interface Setup" {
# testvar useSameLanInterface no
testvar_group lan2 {
SECTION "IPv4 LAN" {
SECTION "LAN Interface" {
# testvar lanInterface eth1
# testvar lanClients 1
# testvar lanMode DHCP
# testvar lanIp 192.168.1.1
# testvar lanMask 255.255.255.0
# testvar lanSecurity NONE
# testvar lanGuestMode no
SECTION "LAN Host IP" {
# testvar hostIp 192.168.1.203
# testvar hostMask 255.255.255.0
# testvar hostGateway 192.168.1.1
}
}
SECTION "LAN DNS" {
# testvar lanDnsServer 192.168.1.1
# testvar lanStaticDns no
}
SECTION "LAN 802.1q VLAN" {
# testvar lanVlanId 100
# testvar lanVlanPriority 0
}
SECTION "DHCP Client Configuration" {
# testvar dhcpClientStart 192.168.1.2
# testvar dhcpClientEnd 192.168.1.7
# testvar dhcpClientLeaseTime 86400
# testvar dhcpClientExclude "192.168.1.47 192.168.1.48"
# testvar dhcpClientVendorClass myIpDevice
# testvar useDHCPpadding yes
# testvar lanDhcpClientOptionCode1 60
# testvar lanDhcpClientOptionData1 04040404
# testvar dhcpClientOptionCode1 124
# testvar dhcpClientOptionData1 000000000401020304
# testvar dhcpExtraClientParams "69 70"
}
SECTION "802.11 Wireless" {
# testvar lanSSID qa-net
SECTION "WPA Encryption Configuration Options" {
# testvar wpaMode auto
# testvar wpaCipher auto
# testvar wpaGroupCipher auto
# testvar wpaKey qacafe123
}
SECTION "WEP Encryption Configuration Options" {
# testvar lanWEPKey off
# testvar lanWEPKeyIndex 0
}
SECTION "Advanced Wireless Settings" {
# testvar lan80211Phy auto
# testvar lanBSSID auto
# testvar lanChannel auto
}
SECTION "Expected Beacon Information" {
# testvar wifiBeaconWpaMode none
# testvar wifiBeaconWpaKeyMgmt PSK
# testvar wifiBeaconWpaCipher AES-CCMP
# testvar wifiBeaconWpaGroupCipher AES-CCMP
# testvar wifiBeaconPhy n
}
}
SECTION "LAN 802.1X" {
# testvar eapType eap-tls
SECTION "LAN Supplicant Credentials" {
# testvar eapIdentity1 user1
# testvar eapPassword1 qacafe123
# testvar eapUserCertPath1 /usr/cdrouter/tests/user1.pem
# testvar eapUserCertPassword1 qacafe123
# testvar eapUserPrivateKey1 ""
}
}
SECTION "IPv4 Firewall and NAT" {
SECTION "Static NAT" {
# testvar staticNatIp 0.0.0.0
# testvar staticNatFirewall yes
# testvar natMode port-restricted
}
SECTION "Special Application Port Triggers" {
# testvar portTriggers no
# testvar triggerName1 net2phone-1
# testvar triggerAddrType1 ipv4
# testvar triggerPort1 6801
# testvar triggerType1 udp
# testvar triggerPublic1 30000
# testvar triggerPublicType1 both
}
SECTION "TCP and UDP Virtual Services (Port Mappings)" {
# testvar virtualWANTransType none
# testvar virtualLANTransType public
SECTION "TCP Virtual Services" {
# testvar virtualTcpServices no
# testvar virtualTcpServicePort1 21
# testvar virtualTcpServiceHost1 192.168.1.200
# testvar virtualTcpServiceName1 ftp
# testvar virtualTcpServiceLanPort1 21
}
SECTION "UDP Virtual Services" {
# testvar virtualUdpServices no
# testvar virtualUdpServicePort1 53
# testvar virtualUdpServiceHost1 192.168.1.203
# testvar virtualUdpServiceName1 dns
# testvar virtualUdpServiceLanPort1 53
}
}
}
SECTION "LAN Static Routes" {
# testvar staticRouteLanNetwork1 2.0.0.0/255.255.255.0
# testvar staticRouteLanNextHop1 192.168.1.18
}
}
SECTION "IPv6 LAN" {
# testvar ipv6LanMode autoconf
# testvar ipv6LanPrivacyAddresses no
# testvar ipv6LanStaticDns no
SECTION "LAN IPv6 Static Routes" {
# testvar staticIpv6RouteLanNetwork1 2001::/64
# testvar staticIpv6RouteLanNextHop1 3001:dddd::1a
}
SECTION "LAN IPv6 DHCP Client" {
# testvar dhcpv6ClientOptionRequest "21 22"
# testvar dhcpv6ClientOptionCode1 39
# testvar dhcpv6ClientOptionData1 000671616361666503636f6d00
}
}
}
}
Virtual LAN Test Interfaces
The virtual LAN test interfaces feature allows a user to define multiple test interfaces that utilize the same system device, as long as the MAC addresses are unique. The conceptual model looks like this:
Virtual LAN test interfaces are defined with testvar_groups just like traditional test interfaces in the pre 11.1 configuration world. Any test interface that supports virtualization can have virtual LAN test interfaces attached to it. For example:
main {
testvar lanInterface wifi0-acn
}
testvar_group lan2 {
testvar lanInterface eth2
}
testvar_group lan3 {
testvar lanInterface wifi0-acn
}
testvar_group lan4 {
testvar lanInterface eth2
}
Additional LAN Clients
Additional LAN clients can also be easily configured on each non-unique test interface (ie any test interface that doesn’t have a hard-coded MAC address) using the lanClients testvar. This extends the virtual LAN test interface concept even further. The model with additional LAN clients enabled now looks like this:
This makes it possible to easily create a large number of additional, persistent ‘test clients’ without having to define LAN test interfaces or virtual LAN test interfaces using individual testvar_groups. For example, a simple (but very powerful) configuration that incorporates both the virtual LAN test interfaces and additional LAN clients features to create six test clients looks like this:
main {
testvar lanInterface wifi0-acn
testvar lanClients 2
}
testvar_group lan2 {
testvar lanInterface eth2
testvar lanClients 2
}
testvar_group lan3 {
testvar lanInterface wifi0-acn
}
testvar_group lan4 {
testvar lanInterface eth2
}
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
# -- specify the IP and mask
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 hostIp 192.168.1.100
testvar staticNatIp 68.1.2.18
}
The following list defines the additional options that are possible for a static NAT host.
- staticNatIp
- hostIp
- natMode
- staticNatFirewall
- firewallTcpOpenPorts
- firewallUdpOpenPorts
- virtualTcpServicePort
- virtualTcpServiceHost
- virtualTcpServiceName
- virtualTcpServiceLanPort
- virtualUdpServicePort
- virtualUdpServiceHost
- virtualUdpServiceName
- virtualUdpServiceLanPort
- triggerName
- triggerPort
- triggerType
- triggerPublic
- triggerPublicType
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 eth2. The static NAT host also contains unique virtual services and port triggers.
testvar_group lan2 {
testvar lanInterface eth2
testvar hostIp 192.168.1.100
testvar staticNatIp 68.1.2.18
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
}
Guest Mode Testing on the LAN
CDRouter Multiport includes a number of tests for verifying what is commonly referred to as guest networks. Guest networks typically provide isolation between clients connected via the primary LAN and typically a wireless guest network. For more information, please see this Knowledge Base article.
MAC Addresses Assignments
Ethernet Test Interfaces
For all test interfaces CDRouter will automatically configure a MAC address for each LAN test client by appending a unique 24-bit client identifier to the 24-bit OUI defined by the testvar cdrouterOui :
<24-bit OUI><24-bit Client ID>
Wireless Test Interfaces and Test Clients
When selecting MAC addresses for wireless test clients, CDRouter ensures that a unique 32-bit MAC prefix is used for each test interface and all test clients derived from that interface. The 32-bit MAC prefix is composed by appending an 8-bit random interface identifier to the 24-bit cdrouterOui .
CDRouter appends a 16-bit random client identifier to the unique 32-bit MAC prefix for each interface to determine the MAC address for a particular wireless test client:
<24-bit OUI><8-bit Interface ID><16-bit Client ID>
