xy - Fotolia
The last five years ushered in significant changes to the data center network: exponentially faster link speeds, 10 gigabit connectivity at the access layer, oversubscription catching up to port density and line-rate forwarding in switches.
Data center network switch configuration, however, hasn't changed since the advent of the Ethernet switch.
The command-line interface still reigns as king of network device configuration. Some vendor-created alternatives -- Web-based graphical interfaces or device managers -- attempt to handle the network from one central control point, but none excel.
Many enterprise IT shops developed in-house tools or administrators manually managed the thousands of physical network ports.
This might not seem like much of a problem. When the data center team provisions a device, they also must configure the network port to which it is attached to the appropriate interface specifications. In most cases, the network engineer enables the port and puts it in the right virtual local area network. Blade chassis systems provide connectivity to many physical hosts, and even more virtual guests, through just a few high-speed links.
The problem, however, isn't access port configuration. What happens when your internal network time protocol (NTP) server or authentication server changes? In most cases, network administrators manually log into each device and reconfigure the settings on a switch-by-switch basis. Some pros script these changes, but end up introducing a new set of problems. Changes can occur across multiple platforms, which configure the NTP server via different methods. A common framework, such as Chef, solves the manual and script-based network switch configuration problem.
A recipe for network provisioning
Automation framework tools like Chef allow administrators to orchestrate server configuration from end to end. Once a server comes up on the network, Chef handles the rest of the provisioning process, from configuration and package installation to updates.
Chef is an automation technology based around a policy engine. The policy comes from a "recipe," which is stored on the Chef server and then applied to a node by attaching it to the node's run list. The Chef client executes on the node, following one recipe at a time from the run list. If the recipe says to install Apache, for example, the client checks if Apache is present. If it is, the client moves on to the next recipe. If the server doesn't have Apache, Chef installs it. This provides a model for configuration automation and for device policy compliance.
With policy-based automation following network provisioning and configuration management, some of our problems are more easily solved. If the network team from the previous example learns of the NTP changes, and updates a recipe for NTP configuration to point to new servers, then no one has to manually reconfigure each switch.
Write it once, use it again
Successful automation requires the appropriate amount of abstraction. As with the scripting scenario, a Chef recipe that says to enter some new configuration encounters different syntaxes across different platforms. Rather, the NTP server should be a configuration attribute that Chef supplies to each node. The node must implement the configuration the way that the platform requires.
With judiciously applied abstraction, network configuration becomes easier. One of the major benefits of Chef is configuration reusability. For example, a recipe configures open shortest path first (OSPF) on an access layer switch. In many data centers, the same interfaces occur across a set of switches, so a network engineer could create an OSPF network switch configuration recipe that executes across several switches. Write the recipe once; use it over and over again.
Despite the payoff, running Chef for network configuration is an intimidating prospect. While having a centralized policy for data center switch management sounds appealing, it requires special considerations, such as single-device changes. For example, high packet loss causes the administrator to manually shut down an uplink. In traditional data center network management scenarios, IT teams check the fiber and then re-enable the interface. What happens if that link was configured with a centralized tool like Chef? The uplink is manually shut down, but the client runs just minutes later and sees that the link is out of compliance. The client re-enables the uplink, unaware of the fiber issue.
The correct approach is to shut down the link using an automated tool. But that uplink recipe may be used across multiple switches. Modifying the recipe for that one problematic uplink would impair multiple devices. With any automation technology, pay attention to how you architect policies.
Framework automation is still a new feature on network appliances. As with any new technology, most implementations won't start with full-scale deployment, letting the client manage the entire device. Network engineers can use Chef to manage software baselines, or repetitive configuration tasks like NTP or authentication mechanisms.
Results also depend on what attributes the switch vendor opens up to Chef or a similar network configuration management tool, and if these attributes are pertinent to your network provisioning and configuration needs. Either way, it's about time networking started catching up with automation.
About the author:
Jon Langemak, CCNP/IP, is a network engineer at a Minnesota-based corporation. He works primarily on Cisco network solutions and enjoys dabbling in other fields. He runs the blog Das Blinken Lichten to document new technologies and testing concepts.