Table of Contents
– Why Zero Touch Provisioning?
– What is Arista ZTP
– Typical Zero Touch Deployment
Cloud computing has rapidly evolved over the last few years. From humble origins rooted in virtualization and concepts of service-oriented architectures, it continues to emerge as a favored operational model of next generation data center deployments. The business theory and cost savings of on-demand capacity models is sound. With virtualized hardware and operating systems production ready, what’s the next step to creating a a fully automated data center environment?
Why is Zero Touch Provisioning (ZTP) Needed?
- Eighty percent of all downtime attributed to human error
- Manual configuration is slow and prone to error
- People and travel are expensive
What is Arista ZTP?Simply stated, ZTP is used to configure a switch without user intervention. Built to fully leverage the power of Arista’s Extensible Operating System (EOS), ZTP provides a flexible solution, provisioning the network infrastructure without requiring a network engineer present at install. A true ‘must have’ feature to contain costs and increase reliability when deploying scalable clouds and data centers.
Simplify your installation process from hundreds of manual steps to three simple steps:
- Requires no CLI interaction from the user
- Automates the provisioning of both the switch configuration and software image
- Supports multiple file transfer methods for fetching scripts, configuration files, and images
- Supports scripting for intelligent provisioning
- Can fetch configuration on all ports with a link (including the management port)
- Does not bridge packets when the switch is in the process of being ZTP initialized
- Provides unique switch identifiers to enable custom automation
- Allows the user to cancel ZTP via the CLI at any time, and/or enable ZTP at every boot cycle
Incomplete auto-configuration solutions can be disruptive to your network and its security posture. Bridging packets between switch ports before the switch is configured allows packets to traverse the network prior to security policies being configured. In addition the integrity of the network can be jeopardized due to unnecessary protocol churn burdening the control plane with erroneous data. ZTP avoids this by initializing the switch to only use its ports to find and download the required software and configuration data.
A Typical Zero Touch DeploymentIn this scenario a new rack is being deployed. A new rack with an Arista 7100 switch being used at the ToR and vmWare enabled servers connected via 10GbE interfaces. Using Arista’s ZTP and VM-Tracer, the entire deployment can be automated, reducing the operational burden and speeding time to production. Once the switch is racked, connected, and powered on, ZTP takes care of the rest.
As ToR-1 starts to boot the process of automatic provisioning begins. First all bridging and link layer protocols are disabled to minimize disruption caused by protocol churn. A DHCP discovery packet is sent and offer received providing ToR-1 with the required networking and boot configuration server information - this is set in DHCP Option 66 and 67.
After the network stack is initialized, and an SVI created with the IP address specified in the DHCP response ToR-1 contacts the boot server specified in DHCP Option 67. ToR-1 downloads the appropriate start-up configuration or script based on the switch’s unique identifier.
If the switch downloads a ‘startup-config’ file it loads that specific configuration. If the switch downloads a boot script it will execute this boot script which generally includes upgrading the EOS image, downloading extension packages, and dynamically building a startup-config file.
In addition to the network related information the configuration contains the required data to provision VM Tracer. VM Tracer enables the switch to establish connectivity with VMware vCenter and to collect information information on attached physical and virtual servers including the ability to automatically provision VLANs within specified ranges on-demand and automatically.
Once the switch is provisioned, it is time to bring up a vSphere 4.x enabled server. The server downloads the vSphere hypervisor from the boot IP server, which could be resident on the ToR switch as well via Linux PXE boot extensions.
Once the switch has established connectivity with vCenter, the required VLANs can be dynamically auto-provisioned based on the requirements of the attached virtual machines. With no user intervention, not only was the switch provisioned the attached vSphere based server’s networking needs are met.