128 Technology has a software-driven framework for rapid and dynamic deployment of network nodes across the enterprise using One Touch Provisioning (OTP). The software has been architected to enable automated deployment across a large set of scenarios, including simple, repeatable branch deployments and dynamic, scalable data center/cloud deployments. The solution may be deployed with minimal configuration using the default 128T installation process, or customized and integrated with 3rd party tools.
An important aspect of the 128 Technology OTP solution is its flexibility. When the product is deployed using the standard 128T images, many customers appreciate the simplicity of enabling an enterprise-wide SessionSmart™ routing fabric without investing additional time to customize the deployment. Rapid deployment of session-enabled routing, security and network visibility is the key objective.
In this deployment model, the 128T node is deployed into the production environment with no site-specific configuration during shipment of units and initial on-line state. A site configuration file is directed via the 128T for initial provisioning.
Software Delivery Options
The simplest deployment of the 128 Technology OTP solution is highly automated and leverages just two components, the 128T Conductor and at least one 128T SessionSmart™ Router. For many customers, the 128T platform is ordered and delivered as a pre-integrated, off-the-shelf solution through the 128T partner network. An image leveraging QuickStart provisioning can also be deployed into a VM or cloud environment, though consideration must be made to the mechanism of injecting the file. Virtual environments may be better suited for cloud automation tools to assist in automated, dynamic deployment.
The OTP installation process produces a Router installed with 128T software set to factory defaults. Upon completing the OTP installation process, the default behavior is to provision the device to be configured with a DHCP client on the first ethernet port and DHCP server listening on all other ports. A user then connects to the 128T via ethernet cable and use the QuickStart file generated by the Conductor to finalize the 128T configuration. After performing the QuickStart operation, the 128T will have connectivity to its Conductor and can download the latest configuration (if necessary) and begin operation. These defaults can be changed to suit your needs.
Basic configuration parameters are encoded within an encrypted file. For each node, a custom file can be exported from the Conductor and minimally contains the following configuration encoded parameters:
- WAN IP address, subnet mask and gateway
- Conductor IP address
- Asset ID
Disk Cloning allows you to create a generic router platform image that can be used to perform multiple installations quickly and efficiently. After the initial ISO installation and power off, the platform is generic and can be cloned to a disk to create a master copy of that platform.
When using cloned images, an identical hardware platform must be used. Create a new master disk image for each hardware variation.
The cloned platform disk is then used to install the filesystem and 128T software on any number of other identical hardware platforms.
The general process for disk cloning is as follows:
- The platform is installed using an ISO image which powers down on success.
- Use Clonezilla or other Live USB to make a copy of the platform.
- Distribute the cloned disk using USB, multicast, or other technique.
- Start each platform after installation.
- Allow each platform to bootstrap and then reboot.
- Verify the platform validation report.xs
Before you Begin
Before beginning the Router installation, you must have a 128T Conductor operationally deployed and reachable by the router.
This diagram is one possible topology for a standalone 128T deployed at the edge of the network.
Installing 128T with the ISO
Follow the instructions for installing the OTP ISO from bootable media. After installation, the platform will power off.
After the initial installation and poweroff, the system is generic - it has no specific configuration. Once the platform is started again, an automated script performs bootstrapping of the platform. This script is a single run service unit that executes once during the first bootup, and performs the following steps:
1. Configure Hostname and Salt Minion Identifier
The hostname and salt minion identifier are set to the same value during the bootstrapping process.
If the system serial number is provisioned (seen by
dmidecode --string system-serial-number) this value will be used. Otherwise use the first MAC address found in the format of:
2. Configure the 128T and Network Interfaces
The Bootstrapper sets the 128T configuration via the QuickStart file found in one of the following locations:
The root of an attached USB drive. i.e.
/bootstrap.quickstart. The USB drive MUST be named "BOOTSTRAP" in all caps.
If no file source is present in either location, the Bootstrapper executes HTTP GET requests to the following endpoints to download the QuickStart File from a server. The REST response is explained in REST details.
<identifier> is the minion-id as determined by the algorithm discussed in Configure Hostname and Salt Minion Identifier. Typically, it is the system serial number.
If none of the above are successful, the OTP defaults are used. This configures the DHCP client on the first ethernet port and a DHCP server listening on all other ports.
3. Enable 128T and Salt-Minion Service
The quickstart file configures and enables the 128T Router and the associated salt-minion service.
4. Write a Result Report
Once the platform is rebooted after bootstrapping, the bootstrap validation report can be found at the root filesystem (
/root/128T-bootstrap.txt) containing details about the steps taken. The
/root/128T-bootstrap.json file contains the same information in JSON format. The report contains a message that includes additional details for each step.
Shown below is the location of the bootstrap report as well as an example of the contents.
After reboot, the 128T service will be configured and running.
It is important to note that after the OS installation the dhclient is configured across all network interfaces until the platform has completed Bootstrapping.
In addition to the above steps, the Bootstrap utility supports executing pre- and post- scriptlets on a USB drive for further customization of the platform. The scriptlets will be executed as the first and last steps in the bootstrap process.
The names and locations for the scriptlets are:
- If scriptlet exists at the root of USB drive and is called “/pre-bootstrap”, it will be the first step. Otherwise use /etc/128technology/pre-bootstrap.
- If scriptlet exists at the root of USB drive and is called “/post-bootstrap”, it will be the last step. Otherwise use /etc/128technology/post-bootstrap.
The scriptlets must have executable permissions to be executed properly.
Any stdout/stderr output generated from the scriptlets is logged in
Bootstrapping Flow Chart
The diagram below shows the procedure the Bootstrap utility follows during the first bootup of the platform after the ISO installation completes.
QuickStart File via REST
If no bootstrap file is present on the USB device or disk, the Bootstrapper will execute HTTP GET requests in an attempt to download the QuickStart file from a server.
The server must respond to the HTTP GET request with valid JSON data that is of format:
The response must be URL-encoded, otherwise the client will not decode the data correctly.
The password data within the JSON is required if the QuickStart file was encrypted when exported from the 128T Conductor.
The Bootstrap utility provides an entrypoint to test your QuickStart Server. By executing the command below, the client makes requests to URLs and attempts to download and decode the QuickStart file. It will NOT apply the QuickStart to the platform - only test the process.
Or, if you want to test a specific url: