Test Bed Configuration

A Testbed parameter file is a Python script which defines the testbed parameters as variables. Testbed files are available in the ~/testbeds folder.

Full Mesh 4 DUTs Topology

All test scripts except Chaos can be run with full mesh 4 DUTs topology

Figure 6

Use the following sample script and steps to create your own testbed file.

  • Replace anything in "<...>" with your DUTs - DUT connections, Management IP address, Login credentials, Link Speed etc.

  • The "name" parameter is very important. Provide a string to identify the respective for this parameter. This name is displayed in logs for easy identification of devices.

  • Refer to the topology diagram to find the link variables and update their values

  • All testbed files can be found in the folder "~/testbeds/"

Testbed file variables

There are two variables to control the cleanup after each test run in the testbed file.

They are CLEANUP_BY_REBOOT and CLEANUP_BY_CFG_RELOAD:

  • CLEANUP_BY_REBOOT = True, The script will restore the switch's configuration from the /etc/sonic/clean_config.json file and then reboot the switch. This takes more execution time and DUTs always have a clean and proper configuration for the next test scripts.

  • CLEANUP_BY_CFG_RELOAD = True, The script will restore the switch's configuration from the /etc/sonic/clean_config.json file and then issue the sudo config load command to load the clean config file. This method takes less time to have a clean configuration on switches but may not work correctly sometimes

  • If both CLEANUP_BY_REBOOT and CLEANUP_BY_CFG_RELOAD are set to False, The scripts use the SONiC CLI procedure to un-configure whatever was configured on the switches by the scripts.

  • Ideally, all three parameters should be set to False.

Apart from these following variables are specified in the testbed file.

  • CFG_RELOAD_BY_REBOOT = True, The scripts reboot the devices wherever the config reload command is supposed to be used. This is for the cases when the config reload command is failing on the DUT due to some reason.

  • NTP_SERVER = <FTAS VM IP>,FTAS VM serves as NTP server

  • INTF_UP_WAIT_TIME = 30, specifies the time the script should wait after starting up an interface to check the interface status.

  • SYSLOG_SRVS = {"Servers": ["FTAS VM IP", "10.4.5.6"], "Log_Folder": "/var/log/sonic_logs"}, first list member should be set to the FTAS VM IP

Configuring Ixia Variables

For UHD Chassis:

  • Specify the port connected to the DUT like this: "s1_p1": "8" , where the port number 8 is connected to Spine01_Port01 for Ixia traffic.

  • For example, Ixia port 8 can be configured like this: "localuhd/8", where localuhd refers to the Ixia chassis and 8 is the UHD port number.

For Novus Chassis:

  • Specify the port connected to the DUT like this: "s1_p1": "1;8" , where the port number 8 on Ixia card 1 is connected to Spine01_Port01 for Ixia traffic.

  • For example, Ixia port 1;8 can be configured like this: "<chassis_ip>;<card_no>;<Port_no>", where <chassis_ip> refers to the Ixia chassis IP and 1;8 is the port with the card number.

circle-info

The FTAS VM has been extensively tested with UHD version 1.3.3003.118, It is recommended to use UHD with the same version for smooth operations.

circle-exclamation

Control Ixia traffic rate globally

For the testbeds where links between DUTs have less bandwidth than Ixia ports traffic tests may fail due to traffic drops on the least bandwidth links (i.e. DUTs may be connected with 1G ports and the Ixia link maybe 100G).

To avoid this situation a global parameter for the ixia traffic rate "global_traffic_rate" in percentage could be used to enforce traffic rate in all tests.

When the global_traffic_rate parameter is defined as a sub-parameter in the "Ixia_Ports" all traffic streams in all test scripts would override their own rate value with global_traffic_rate value configured.

When global_traffic_rate is not defined all traffic streams in all test scripts would use their own static values for the traffic rate.

Here the "global_traffic_rate": 25 referrers to 25% speed for all Ixia ports

2 DUTs Topology

If you don't have 4 DUTs topology and want to run scripts that require only 2 DUTs, You can use ftas_2duts_topo.py testbed parameter file

Figure 8: Links variables for full mesh 4 DUTs

There are two physical DUTs in the topology but the script might pick the name Spine and Leaf interchangeably. So in the testbed file, we should define parameters for both but they point to the same physical Spine and Leaf DUTs.

Full Mesh 4 DUTs Topology for Chaos

ftas_chaos_topo.py testbed parameter file is used for Chaos test scripts only

Figure 9: Link variables for Chaos testbed

Last updated