BreakingPoint Controller Shell

[Quali-Community]

BreakingPoint Controller Shell

This is BreakingPoint controller shell.

Before using it, make sure that you have installed the BreakingPoint Chassis shell and executed the Autoload command. The BreakingPoint Chassis shell can be found at:

breakingpoint-chassis-shell

Repository	Latest Release	README.md
Name BreakingPoint-Controller-Shell Owner QualiSystems Type 1st Gen Shell Category Traffic Generators Min. Compatible CloudShell Version 7.0 7.1 8.0 Total Downloads (All Releases) 270	Link 1.2.3 (Version / Tag) TAR / ZIP 1.2.3 (TAR) 1.2.3 (ZIP) Author alexquali Published On 08/13/2018 05:55 AM Assets bp-offline-package-1.0.7.zip [980 KB] breaking_point_controller_shell.zip [16 KB] Cleanup.Reservation.zip [11 KB]	Ixia BreakingPoint 1G Shells Release date: October 2017 Shell version 1.2.2 Document version 1.0 In This Guide Overview Downloading the Shell Importing and Configuring the Shell Updating Python Dependencies for Shells Associating a CloudShell Service to a Non-Global Domain Typical Workflows References Release Notes Overview A shell integrates a device model, application or other technology with CloudShell. A shell consists of a data model that defines how the device and its properties are modeled in CloudShell, along with automation that enables interaction with the device via CloudShell. Note: We recommend using a 2nd gen shell where possible. Using a 1st gen shell may limit some shell management capabilities. For more information, see Shell Overview – “Our Shell”. Traffic Generator Shells CloudShell's traffic generator shells enable you to conduct traffic test activities on Devices Under Test (DUT) or Systems Under Test (SUT) from a sandbox. In CloudShell, a traffic generator is typically modeled using a chassis resource, which represents the traffic generator device and ports, and a controller service that runs the chassis commands, such as Load Configuration File, Start Traffic and Get Statistics. Chassis and controllers are modeled by different shells, allowing you to accurately model your real-life architecture. For example, scenarios where the chassis and controller are located on different machines. For additional information on traffic generator shell architecture, and setting up and using a traffic generator in CloudShell, see the Traffic Generators Overiew online help topic. Ixia BreakingPoint 1G Shells To model an Ixia BreakingPoint device in CloudShell, use the following shells: ▪ BreakingPoint Chassis 1G Shell, which provides data model and autoload functionality to model and load the BreakingPoint Chassis to resource management. ▪ BreakingPoint Controller 1G Shell (service), which provides functionality to load test configuration, run tests, get test results, etc. Standard version The BreakingPoint 1G shells are based on the Traffic Shell standard version 2.0.0. For detailed information about the shell’s structure and attributes, see the Traffic Shell standard in GitHub. Certified models ▪ BreakingPoint VE Requirements Release: Ixia BreakingPoint 1G shells ▪ CloudShell version: 7.0 and above ▪ BreakingPoint application: 8.20 and above Data Model The shell's data model includes all shell metadata, families, and attributes. BreakingPoint Chassis Families and Models The chassis families and models are listed in the following table: Family Model Description Traffic Generator Chassis BreakingPoint Chassis BreakingPoint Chassis Module Generic Traffic Generator Module Modules located on the chassis Port Group Generic Port Group Generic Port Group Port Generic Traffic Generator Port Generic Traffic Generator Port BreakingPoint Chassis Attributes The chassis attribute names and types are listed in the following table: Attribute Type Default Description Name String CloudShell resource display name. Address String Resource address (address of the device). Folder String Root CloudShell folder in which to place the resource. Use the search bar to quickly find the desired folder. Visibility Lookup Family Default (Everyone) Visibility determines who can see the resource in the diagram, search pane, and Inventory dashboard. By default, visibility is defined in the resource family and can be changed for a specific resource. Possible values: Family Default (Everyone), Admin only, and Everyone. Remote Connection Lookup Family Default (Enable) Remote connection determines if you can remotely connect to the resource. By default, the remote connection is defined in the resource family and can be changed for a specific resource. Possible values: Family Default (Enable), Enable, and Disable. User String Admin user on the device. Password Password Password for Admin user on the device. Client Install Path String Path in which the traffic client is installed on the Execution Server. For example C:/Program Files (x86)/Ixia/IxOS/6.90-EA. Controller Group String Name of the controller group that the traffic generator is associated with or the group(s) (comma-separated) the traffic controller is part of. Model String Device model. This information is typically used for abstract resource filtering. Power Management Boolean Enabled Used by the power management orchestration, if enabled, to determine whether to automatically manage the device power status. Serial Number String Serial number of the device. Server Description String Full description of the server. Usually includes the OS, exact firmware version, and additional characteristics of the device. Supported Applications String Comma-separated list of traffic applications supported by this traffic generator. For example IxLoad,IxNetwork. Vendor String Vendor name. Version String Firmware version of the resource. BreakingPoint Controller Attributes The controller attribute names and types are listed in the following table: Attribute Type Description Test Files Location String Location for test related files. Automation This section describes the automation (drivers) associated with the data model. The shell’s driver is provided as part of the shell package. There are two types of automation processes, Autoload and Resource. Autoload is executed when creating the resource in the Inventory dashboard, while resource commands are run in the sandbox. For Traffic Generator shells, commands are configured and executed from the controller service in the sandbox, with the exception of the Autoload command, which is executed when creating the resource. The following commands are associated with a model inside the shell: BreakingPoint Chassis 1G Shell Command Description Autoload Discovers the chassis, its hierarchy and attributes when creating the resource. The command can be rerun in the Inventory dashboard and not in the sandbox, as for other commands. BreakingPoint Controller 1G Shell Command Description Load Configuration Loads the configuration file prepared by your Admin. The load configuration file includes the settings to run the traffic test, for example, packet size, number of packets to send in parallel, interval at which to send packet batches, etc. The file also reserves the necessary ports. Note: The load configuration file must be accessible from the Execution Server, see Traffic Generators Overview. Start Traffic Starts a test to generate and send traffic to the DUT, according to the settings provided in the configuration file. Stop Traffic Stops running the test to stop sending traffic from the traffic generator. Get Result Gets the test result file and attaches it to the sandbox. Get Statistics Gets real time statistics of the traffic test in either JSON or CSV format. Set the command's inputs as follows: ▪ View Name: Type of statistics to return. For example, Port Statistics, Traffic Item Statistics, Flow Statistics, etc. The types may differ depending on the traffic generator. ▪ Output Type (Enum): JSON or CSV. JSON prints the statistics to the sandbox's output, which is useful for API calls that can use the output; while CSV attaches a CSV file with the test's statistics to the sandbox. Get Test File Downloads the test file to the location specified in the Test Files Location attribute defined when you added the service to your blueprint. Downloading the Shell The BreakingPoint 1G shells are available from the Quali Community Integrations page. Download the files into a temporary location on your local machine. The shells comprise: File name Description breaking_point_controller_shell.zip BreakingPoint Controller Shell package breaking_point_chassis_shell.zip BreakingPoint Chassis Shell package bp-offline-package-1.0.6.zip Shell Python dependecies (for offline deployments only) Ixia-B reakingPoint-Shell.pdf Teardown script for cleaning reservation Importing and Configuring the Shell This section describes how to import the BreakingPoint 1G shells and configure and modify the shell’s devices. Importing the shells into CloudShell Note: You will need to repeat these procedures, once for the controller shell and once for the chassis shell. To import the shell into CloudShell: Make sure you have the shell’s zip package. If not, download the shell from the Quali Community's Integrations page. Backup your database. Log in to CloudShell Portal as administrator of the relevant domain. In the User menu select Import Package. Browse to the location of the downloaded shell file, select the relevant .zip file and Click Open. Alternatively, drag the shell’s .zip file into CloudShell Portal. The shell is displayed in the Shells page and can be used by domain administrators in all CloudShell domains to create new inventory resources, as explained in Adding Inventory Resources. Offline installation of a shell Note: Offline installation instructions are relevant only if CloudShell Execution Server has no access to PyPi. You can skip this section if your execution server has access to PyPi. For additional information, see the online help topic on offline dependencies. In offline mode, import the shell into CloudShell and place any dependencies in the appropriate dependencies folder. The dependencies folder may differ, depending on the CloudShell version you are using: For CloudShell version 8.3 and above, see Add Shell and script packages to the local PyPi Server repository. For CloudShell version 8.2, perform the appropriate procedure: Add Shell and script packages to the local PyPi Server repository or Set the python pythonOfflineRepositoryPath configuration key. For CloudShell versions prior to 8.2, see Set the python pythonOfflineRepositoryPath configuration key. Adding shell and script packages to the local PyPi Server repository If your Quali Server and/or execution servers work offline, you will need to copy all required Python packages, including the out-of-the-box ones, to the PyPi Server's repository on the Quali Servercomputer (by default C:\Program Files (x86)\QualiSystems\CloudShell\Server\Config\Pypi Server Repository). For more information, see Configuring CloudShell to Execute Python Commands in Offline Mode. To add Python packages to the local PyPi Server repository: If you haven't created and configured the local PyPi Server repository to work with the execution server, perform the steps in Add Python packages to the local PyPi Server repository (offlinemode). For each shell or script you add into CloudShell, do one of the following (from an online computer): Connect to the Internet and download each dependency specified in the requirements.txt file with the following command: pip download -r requirements.txt. The shell or script's requirements are downloaded as zip files. In the Quali Community's Integrations page, locate the shell and click the shell's Download link. In the page that is displayed, from the Downloads area, extract the dependencies package zip file. Place these zip files in the local PyPi Server repository. Setting the python PythonOfflineRepositoryPath configuration key Before PyPi Server was introduced as CloudShell’s python package management mechanism, the PythonOfflineRepositoryPath key was used to set the default offline package repository on the Quali Server machine, and could be used on specific Execution Eerver machines to set a different folder. To set the offline python repository: Download the bp-offline-package-1.0.7.zip file, see Downloading the Shell. Unzip it to a local repository. Make sure the execution server has access to this folder. On the Quali Server machine, in the ~\CloudShell\Server\customer.config file, add the following key to specify the path to the default python package folder (for all Execution Servers): <add key="PythonOfflineRepositoryPath" value="repository full path"/> If you want to override the default folder for a specific Execution Server, on the Execution Server machine, in the ~TestShell\Execution Server\customer.config file, add the following key: <add key="PythonOfflineRepositoryPath" value="repository full path"/> Restart the Execution Server. Configuring a new resource In CloudShell, the component that models the device is called a resource. It is based on the shell that models the device and allows the CloudShell user and API to remotely control the device from CloudShell. You can also modify existing resources, see Managing Resources in the Inventory. To create a resource for the chassis device: In CloudShell Portal, Inventory dashboard, click Add New. From the list, select the Breaking Point Chassis. Enter the BreakingPoint chassis Name and IP address. Click Create. In the Resource dialog box, enter all the fields relevant for this device: Attribute Type Description User String Admin user on the device. Password Password Password for Admin user on the device. Client Install Path String Path in which the traffic client is installed on the Execution Server. For example C:/Program Files (x86)/Ixia/IxOS/6.90-EA. Controller Group String Name of the controller group that the traffic generator is associated with or the group(s) (comma-separated) the traffic controller is part of. Power Management Boolean Used by the power management orchestration, if enabled, to determine whether to automatically manage the device power status. Enabled by default. Supported Applications String Comma-separated list of traffic applications supported by this traffic generator. For example IxLoad,IxNetwork. Click Continue. This command discovers the device, fills in its attribute values and creates the device’s structure in CloudShell (if the device has a structure). Updating Python Dependencies for Shells This section explains how to update your Python dependencies folder. This is required when you upgrade a Shell that uses new/updated dependencies. It applies to both online and offline dependencies. Updating offline Python dependencies To update offline Python dependencies: Download the latest Python dependencies package zip file locally. Extract the zip file to the suitable offline package folder(s). Terminate the shell’s instance, as explained here. Updating online Python dependencies In online mode, the execution server automatically downloads and extracts the appropriate dependencies file to the online Python dependencies repository every time a new instance of the driver or script is created. To update online Python dependencies: If there is a live instance of the shell's driver or script, terminate the shell’s instance, as explained here. If an instance does not exist, the execution server will download the Python dependencies the next time a command of the driver or script runs. Associating a CloudShell Service to a Non-Global Domain In order to expose a service to users of a domain that is not the Global domain, you must associate the service to the domain. To do this, you need to associate the service to a category that is assigned to the domain. When you import a service shell, most shells are automatically assigned a default service category which is associated with the Global domain. For custom shells, this may not be true. To associate the BreakingPoint Controller 1G service to a non-global domain: Note: The association process differs depending on the type of shell - second generation (2G) shell or first generation (1G) shell. The instructions below detail the steps for a 1G service shell. (Optional) You can associate the service to a service category that already exists in CloudShell or associate the service to a new category. Note: If you do not want to change the category(s) of this shell, you can use the default category that comes out-of-the-box (if it exists). Associate the service family to an existing category(s). In Resource Manager Client, open the Resource Families explorer and click the relevant service family. From the right pane, open the Categories tab. Click Add. The Select Category dialog box is displayed. Select a category from the catalog and click OK. or Modify the 1G category(s) in the shell project’s configuration files to add a new category(s). See Associating categories to 1st Gen Service Shells. Associate the shell’s service category to a domain. In the Manage dashboard, click Categories from the left sidebar, or Domains if you are a domain admin. Select Services Categories. Click the service category that is associated with your service shell. In the Edit Category dialog box, from the Domains drop-down list, select the desired domain(s). Click Save. Typical Workflows Workflow 1 - Creating a new blueprint Create a new blueprint. Log in to CloudShell Portal and create a new blueprint Blueprint Catalog>Create Blueprint. Give the blueprint a name. Add resources and services to the blueprint. Click the Resource button and add the BreakingPoint Chassis resource and all needed ports into the diagram. Associate the port's sub resources with the BreakingPoint Network Neighborhood Interfaces, by specifying the port's attribute Logical Name with the BP interface ID. Click the App/Services tab and add the BreakingPointController service. Specify the attribute Test Files Location, where test files will be downloaded. Add a teardown script, which runs the driver command cleanup_reservation when the reservation ends. This command releases ports which were used by the sandbox. Go to the Scripts management page Manage>Scripts>Environment. Click Add New Script and choose the Cleanup Reservation.zip file. Click Edit for the new added script and change Script Type to Teardown. Return to the blueprint and open properties, Blueprint>Properties. In the Driver section, select Python Setup & Teardown, add Estimated teardown duration 1 min. Click Add Script and chose Cleanup Reservation from the list. Click Update to save changes. Workflow 2 - Getting a test file with network configuration You cannot change predefined Tests and Network Neighborhoods. Predefined Network Neighborhoods will not be included in Test files. This scenario helps you use predefined Tests and Network Neighborhoods. Duplicate the BreakingPoint Network Neighborhood configuration. Open the BreakingPoint UI. Go to Control Center>Open Neighborhood. Find and select Network Neighborhood from the list. Click Save As and enter New Network Neighborhood Name. Click Ok. Duplicate the BreakingPoint Test. Go to Test>Open Test. Find and select the Test from the list. Press Save As and save it with a new name. Change the Network Neighborhood in the duplicated test. Find and select the duplicated test from the list and open it. In the Network Neighborhood section, click ‘…’, find and select the duplicated Network Neighborhood. Click Save. Run the GetTestFile BreakingPointController command. Enter CloudShell Portal, and reserve the newly created blueprint. Run the BreakingComandController service command GetTestFile with the duplicated test name. Open the folder specified in the attribute Test Files Location+<reservation_id> to view the file with the name of your duplicated test (extension “bpt”). Workflow 3 - Running a test Enter your blueprint. Run the BreakingPointController service Load Configuration command. Click BreakingPointController Commands and enter the service commands. Find the Load Configuration command and enter the run menu. Specify the Breaking Point config file with the path of your test configuration file. It can be a full path, or relative path under the location specified in the attribute Test Files Location, such as <reservation_id>/test_name.bpt, or only test_name.bpt, if it is a current sandbox. Click Run, to load the test and network configuration from this file and reserve necessary ports. Run Start Test. Click the BreakingPointController Commands and enter the service commands. Find the Start Traffic command and click Enter to run the menu. Set Blocking to True, if you want subsequent commands to wait until the test finishes, or False to allow additional commands to run during the command's execution. Click Run. Run Stop Test. If you ran the test with Blocking equals False, you can immediately stop the test. Run the Stop Traffic command. Get the test result file. Run the Get Result command. The test result file is attached to the sandbox. References To download and share integrations, see Quali Community's Integrations. For instructional training and documentation, see Quali University. To suggest an idea for the product, see Quali's Idea box. To connect with Quali users and experts from around the world, ask questions and discuss issues, see Quali's Community forums. To use traffic generator ports as abstract resources, see CloudShell's Online Help. Release Notes What's New Added support for the Virtual Traffic Generator.
* Updated Weekly	* Update Now	* Repository, release and asset info is updated weekly. * Please allow 30-60 seconds for manual update changes to take effect.

---

 ofir eldar 04/24/2017 05:10 PM

·  1300  ·