Inside the Briefcase

The 5 Most Common Application Bottlenecks

The 5 Most Common Application Bottlenecks

Application bottlenecks can lead an otherwise functional computer or...

How Machine Learning Helps Improve the Security Industry

How Machine Learning Helps Improve the Security Industry

We’ve been moving more and more towards computerized processes...

Transformation on a Global Scale

Transformation on a Global Scale

Necessity may be the mother of invention, but it’s...

IT Briefcase Exclusive Interview: As Container Adoption Swells, So Do Security Concerns

IT Briefcase Exclusive Interview: As Container Adoption Swells, So Do Security Concerns

Fei Huang, NeuVector
In this Fresh Ink interview segment,...

6 Marketing Strategies for Your Small Business

6 Marketing Strategies for Your Small Business

One of the main problems facing small businesses is...

A New Method for Today’s Network Infrastructure

April 26, 2016 No Comments

Featured article by Dr. Stefan Dietrich, Vice President of Product Strategy, Glue Networks Inc.

Network infrastructure today is under increasing pressure from the shifting bandwidth and latency requirements of modern applications. Wide area networks (“WANs”) in particular must address this demand, especially when they use many technologies from a variety of providers, are distributed geographically and suffer strain from the ever-expanding popularity of video and cloud application services. That’s why hybrid WAN architectures with advanced application-level traffic routing are an attractive option; they marry the cost savings of broadband/Internet connectivity for non-critical traffic with the reliability of private lines for critical business applications.

Currently, many network management tools don’t have what it takes to deploy such architectures at scale over the existing network. Most of them still apply blocks of configuration data to network devices to enable features that in turn enable an overall network policy. To allow adjustment of configuration data to address differences in hardware and OS/firmware levels, those scripts are using “wildcards” replacing certain configuration data. These scripts are heavily tested, carefully curated and subject to stringent change management procedures. The tiniest mistake can bring a network down, resulting in potentially disastrous business losses.

The limitations to this approach are becoming evident to network operations teams as hybrid WAN architectures and application-specific routing are deployed. Even if the existing hardware already supports all the functionality required, existing network configurations that reflect past user requirements are rarely well understood. As each business unit is asking for specific requirements to ensure that their applications run optimally on the network, networks need to be continuously updated and optimized. Such tasks range from a simple adjustment of the configuration parameters to more complex changes of the underlying network architecture, such as removing and installing upgraded circuits, replacing hardware or even deploying new network architectures.

Senior network architects need to be heavily involved for these tasks because they need to determine potential risk of unintentional consequences on the existing network. However, waiting for the next change maintenance window may no longer be an acceptable option. Businesses are not concerned with the details; they want the networks to simply “work.”

Moving Forward

What is the next step, then? Network architects and implementation teams are familiar with traditional network management tools. They are mature and well understood, including all of the limitations and difficulties, and any potential change of these tools is immediately vetted against the additional learning curve required vis-à-vis potential benefits in managing the network.

Implementation or operational concerns should not factor into how network policies are defined, ideally. It starts with mapping of the required functionality into a logical model, assembling these models into one overall network policy, verifying interdependencies and inconsistencies, and deploying and maintaining them consistently throughout the network life cycle.

The industry is working to address this changing landscape by creating multiple activities to improve network management, but those initiatives are still maturing. For example, YANG is a data modeling language for the NETCONF network configuration protocol. OpenStack Networking (Neutron) is providing an extensible framework to manage networks and IP addresses within the larger realm of cloud computing, focusing on network services such as intrusion detection systems (IDS), load balancing, firewalls and virtual private networks (VPN) to enable multi-tenancy and massive scalability. But neither approach can pro-actively detect interdependencies or inconsistencies, and both require network engineers to dive into programming, for example, to manage data entry and storage.

Consequently, fully integrated solutions are on offer from some vendors, built on appliances managed through a proprietary network management tool. This approach allows businesses to deploy solutions quickly, at the cost of additional training, limited capability for customization and new hardware purchases.

The real need of the hour is for network management capabilities that are focused on assembling complete network policies from individual device-specific features, detecting inconsistencies and dependencies, and allowing deployment and ongoing network management. Simply updating wildcards in custom configuration templates and deploying them onto devices is no longer sufficient.

Going forward, routing protocol changes or network architectures may need to be changed on live production networks. Managing such changes at large scale is difficult or even unfeasible. Especially in large organizations where any change will always have to be validated by e.g. security. This creates unacceptable delays for implementation.

Mapping Network Features and Policies

Network features and related policies can be mapped using these four constructs:

- Domains – Configuration settings should consistently be applied across multiple devices. A good example is a QoS configuration which may be different by business units, hence, different QoS domains would allow network engineers to assign QoS policies across all devices associated with specific business units in each region.

- Features – Give the configuration settings for one device at a time, enabling functionality that the device can provide by itself. A good example is the configuration of a device-specific routing table where the device should forward incoming traffic.

- Globals – These are configuration settings that are the same for every device in the network and apply throughout the network. A good example is NTP (network time protocol) where the central architecture team is defining the only NTP servers permissible for the network.

- Custom – Not everything may be practical to model in a general feature or domain concepts, especially specific exceptions to single devices only – for example, a specific set of Access Control Lists (ACLs) needed on a single device. For these cases where no other dependencies with other features exists, just applying configuration data to a device may be acceptable.

Organizations can build any network policy using a combination of these constructs. Inherent interdependencies can be flagged by network engineers early, so that a network management system can deploy them in the correct sequential order, optimally applying these features to individual devices as well as across the network to create the target policy. Abstracting network functionality into these types of models allows network engineers to re-focus on the actual network architecture and focus less on the mechanics of the management of configuration data.

Technical and Non-technical Considerations

A sophisticated network-aware orchestration engine is needed to create a next-generation network management tool – one that is able to detect any interdependencies, resolve them and deploy network policies automatically over the network.

In order for this to work, several non-technical challenges must be considered:

- User confidence and acceptance that the logical network model will indeed result in the correct configuration of all devices in the network. Many network engineers are still most comfortable with command line interface (CLI) created from scripts and templates.

- Make sure to get buy-in from NetOps and DevOps teams, who may be skeptical to trust device configuration to a new management tool.

- Network engineers usually aren’t programmers – and they don’t want to be. Their primary focus is on proper device configurations and ensuring the device is performing as intended. Many next-generation tools have been designed with a network engineering focus in mind, allowing network engineers to use the system with a much shorter learning curve and minimal programming expertise.

The new breed of management tools, from a technical perspective, should include:

- Management for the high degree of customization needed.

- Zero-touch provisioning to make the onboarding of new devices into the system as fluid as possible, allowing generalist IT staff to install routers and trigger device provisioning automatically.

- Step-by-step verification of device provisioning actions with automatic revert on errors.

- Functionality that limits or flags unauthorized manual device configuration changes with automatic remediation when needed.

- Configuration preview, allowing dry runs of new configurations to understand all changes that may have to be performed, even on other network devices when needed.

A Next-generation Network

A good example of how enterprises can truly transform their networks is delivered by tools that provide complete abstraction of network functions and include deeply integrated model interdependency verification, deployment previews and layer-by-layer provisioning. For example, replacing an existing device with a newer model, even if it’s from a different vendor, can be detected and automatically provisioned. Such solutions that can resolve any potential conflicts and interdependencies, even across vendors, are becoming increasingly important as network devices are virtualized on common platforms and the individual strength of vendor-specific solutions are combined into one multi-vendor solution.

Better integration with clear roles for implementation and architecture roles are the result of this model. It results in higher reliability, elimination of configuration errors, faster identification and recovery from network outages, and faster implementation of business requirements. Consider the challenges and needs, both technical and non-technical, before building a transformed network.

Stefan Dietrich A New Method for Today’s Network Infrastructure

About the Author

Dr. Stefan Dietrich brings to Glue Networks more than 20 years of experience defining innovative strategies and delivering complex technology solutions. Before joining Glue Networks, Stefan was Managing Director of Technology Strategy at AXA Technology Services, introducing advanced new technologies to AXA globally, and held senior IT management positions at Reuters and Deutsche Bank. Stefan received a Ph.D. in Aerospace Engineering and Computer Science from the University of Stuttgart and served as a Postdoctoral Fellow and faculty member at Cornell University.


Leave a Reply




UC Expo



ITBriefcase Comparison Report