Your trusted partner for Network Automation

We offer our expertise in architecture and implementation to work with your network operations and engineering team to develop and roll out a customized automation solution.

Network automation is multi-faceted

The automation of current network products and software-defined networking (SDN) has large overlaps with automation tasks in other IT domains in terms of requirements and procedures. This is particularly true of generated automation artifacts (the configurations or code used to generate them) and their management. The state of the art is outlined by DevOps, NetOps (Continuous Integration/Continuous Delivery), SDN (Software Defined Networking) and related keywords.

However, large networks usually contain important inventory hardware and software which is at the end of the product life cycle, as well as special regulatory requirements and high demands on security, as well as traceability and auditing.

Ansible Automation Plattform – multi-vendor network automation

foundata uses Red Hat Ansible and its ecosystem to implement network automation. The purely open source versions can be used without vendor support, but from a compliance perspective, the Ansible Automation Platform (AAP) offered by Red Hat is usually the more sensible option in enterprise environments, even if the open source upstream components are not functionally restricted.

AAP currently offers vendor-supported versions of seventeen open source components such as AWX (Orchestrator) or Automation Hub (Galaxy). In addition, Red Hat has automation collections certified in partnership with numerous well-known suppliers such as Cisco, Juniper and VMware. Among other things, these also make it easier to automate legacy Cisco IOS hardware, for example, without losing support from the vendor. AAP also offers support for legacy devices and those with an open network infrastructure in virtual and physical multi-vendor environments to automate the network with a single tool.

For network administrators, Ansible uses easy-to-read and easy-to-version YAML as the primary declaration language and fits into versioning workflows. This facilitates the implementation of GitOps approaches as well as CI/CD and traceability (and thus compliance in general).

The dynamic inventories (which can be thought of as scripts for retrieving information with the output of lists to Ansible) usually save the effort of writing dedicated middleware for communication between different data heaps and inventory systems (e.g. FNT Command or NetBox).

The ability to specifically expand Ansible core functionality with little Python knowledge can also be useful for environment-specific edge cases, since these extensions are usually inexpensive and tie up considerably less development capacity than having to develop wrappers or middleware without an Ansible environment.

Machen Sie den nächsten Schritt, sprechen wir über Ihren Automation-Use-Case

Problems

Traditionally monolithic and proprietary environments

Network technologies and products have evolved, but more often than not the way networks are managed hasn’t improved at the same rate. Networks have traditionally been characterized by monolithic, proprietary platforms with no automation capabilities. Network suppliers often focus more on individual product functions. This is also reflected in tooling for network administrators: Network vendor-related tools for manual administration (also of large hardware inventories) are usually there to at least simplify repetitive tasks or to generate overviews – as a rule, however, they are bound to the respective vendor and product lines. These solutions thus represent administrative silos and are not aimed at sustainable, general operational improvements. This also applies to the direct administration of modern SDN platforms, which could be better integrated into overall automation.

Directly visible effects of these circumstances can usually be found easily. For example, it is usually the case that the origin and the technical reasons for the current configuration on routers and firewalls can no longer be fully traced, which is particularly problematic with regard to auditing and the proof of congruence between the target and the actual state, although large organizations usually have specifications and elaborate, mature processes for managing changes, source code, tests and platforms for the controlled delivery of code (here: configuration)..

No overview without automation

The status quo also poses an operational challenge, even with automated SDN islands and product-specific help. Without comprehensive network automation, it can be difficult to roll out or roll back changes in a controlled and traceable manner across the entirety of the real and virtual network hardware, inventories with cross-connections, to derive the right conclusions or necessary application sequences from them (knowledge of topology), or to maintain minimum configuration standards across network platforms and borders.

This is also problematic for productive environments because of the far-reaching impact of network failures, malfunctions, or security issues, creating very high demands on network operations personnel. Added to this are the requirements arising from increasing containerization, cloud applications and software-defined networking in general. The volatility of container environments, for example, often requires an automated procedure at the network level, since manual releases, inventories or the like are inevitably stretched to their limits when faced with huge amounts of changes.

Must-haves for a modern network automation

Manufacturer-independent automation with inventories, versioning and CI/CD (Continuous Integration/Continuous Delivery) and their inherent continuous improvement can significantly reduce expenses. This applies in particular to reporting, auditing, operation, emergency/restart or ITIL service design and the service transition to the operation of new platforms under a well-defined target configuration and compliance. Modern network automation must take these circumstances into account:

• Comprehensive usability, independent of the network manufacturer or supplier:
  • Agentless: The installation of agents should not be a requirement, since agents limit the possible target platforms, therefore cause interoperability problems and, depending on the implementation, increase the attack surface.
  • Maintain minimum configuration standards across individual network platforms
  • If needed, with capabilities to target legacy hardware with command line interface (CLI) dependencies.
• Declarative work: The use of common DevOps standards to describe TARGET states is expedient, preferably using techniques that have also been able to establish themselves in non-network IT use cases:
  • Established format (YAML, JSON) or at least a common Domain Specific Language (DSL)
  • Ability to use processes and tooling that are likely to already exist (e.g. test frameworks within a CI/CD pipeline)
  • Easier implementation of the ITILv4 service value system, which follows a holistic and thus cross-departmental approach.
• Enabling idempotence: repeatable executions must deliver the same result on the target system. In this way, constant execution can keep the TARGET and ACTUAL state the same and, in the event of deviations, automatic convergence against the TARGET state can be achieved without manual intervention.
• Use and preparation of existing inventories. A solution that makes it possible to control existing systems and their APIs without additional middleware (e.g. through easy integration of RESTful APIs) is advantageous. Existing data sources should be able to be used and integrated (e.g the well-known FNT Command or NetBox).
• Simple mapping of necessary change controls and insertion into related frameworks such as ITILv4-Continual Improvement or the ITILv3 Service-Lifecycle
• Providing an API to provide automated tasks and processes for peripheral systems:
  • As RESTful as possible:
    • API layering support (to blend into concepts, e.g. for higher-level orchestrators)
    • Stateless operation
  • Abstraction from manufacturer-specific downstream REST APIs (e.g. SDN controllers)
  • Insertion into enterprise security environments with regard to authentication (e.g. LDAP, AD) and authorization (e.g. RBAC (Role Based Access Control) for individual processes)