Network configuration management
Outline
• Network overview
• Current solution: cfmgr
• Overview of open-source platforms
• Evolution plan
• Around 4,4 k network devices
• Network at CERN
Multi-vendor network (CERN procures equipment with open call for tenders)
• Specific configuration for each environment.
4000 switches
400 routers
Network configuration automation workflow at
CERN
CFMGR
LanDB
CFMGR – configuration management tool
What is cfmgr?
• Perl-based command-line tool
• Helps to ensure consistent configuration for the network
• Uses central DB as a source of truth
• Features:
• Multi-vendor support
• Supports multiple operations
• Basic configuration management (load, align)
• Automatic configuration of ACLs and PoE
• Large scale firmware management
• etc…
• Integration with Spectrum CA
• Sends cron job status notifications
CFMGR architecture
Evolution motivation
• Need to support a new router platform
• different configuration workflow
• Decrease in popularity of Perl
• Most network automation libraries (vendor or open-source) use Python
• Large code base with non-uniform/outdated coding practices
• No clear separation between different modules of the system
Open-source automation solutions
Network automation stack
• A network automation stack comprises multiple
layers:
• Orchestration: triggering the action of
reconfiguring network devices
• Model: device independent network
configuration data
• Driver and device Interface: translate the
model to the appropriate device specific
format and enforce it on the device
N.A.P.A.L.M.
• N.A.P.A.L.M. (Network Automation and Programmability Abstraction Layer with
Multivendor support)
• Python library that implements a set of functions to interact with different network device Operating Systems using a unified
API.
• N.A.P.A.L.M. API covers two aspects:
• Configuration management
• Getters (getting information from the device)
• Python-based tool • For every device type, vendor,
• All orchestration is based on generation separate set of
playbooks: programs, written in playbooks should be written
human readable language • Only one node controls whole
network, which can cause
• Generates configuration using
concurrency issues during
template language (jinja2) and
multiprocessing operations
yaml data files
• Simple set of operations
• No need to install additional supported
software on the network devices
• Generation of the
configuration using
• templates
Master-slave architecture
• • Python-based
Works over SSH in “headless”
mode
• Reactive behaviour
• Provide layer of abstraction over
• Scalable architecture
N.A.P.A.L.M.
• Supports ACL
generation out of the box
• Python based. • No multi-vendor support
• StackStorm is a IFTTT(if-this- • Was created to orchestrate
then-that) orchestration platform servers, but not real network
• There are basic workflows for devices.
network configuration based on • N.A.P.A.L.M. is the main source
N.A.P.A.L.M. of network device automation
Open-source platform applicability
• There is no perfect automation platform which can
cover full network automation stack.
• All network configuration capabilities are build on top of
N.A.P.A.L.M.
• Some of them have scalability issues
• Lack of multi-vendor support
• Generation of the configuration is still our duty
• Configuration models are vendor specific
• Partial cover of configuration generation with OpenConfig
Evolution plan
CFMGR – current state
Evolution plan (1)
Not covered by any automation platform.
Should be developed
N.A.P.A.L.M.
Python libraries, provided by vendors
Evolution plan (2)
Configuration
Reuse CFMGR generator
logic forshould be
created
creatingusing Python
general and templates
configuration in Use N.A.P.A.L.M. for diff
(eventually) for creating
universal format (YAML, device
XML, operation and interaction with
specific
JSON) configuration from generic the network device
one
Evolution plan (3)
• Decouple concerns:
• Configuration generation: in-house
• Generate vendor independent configuration (Perl Python)
• Gradually use REST interface for retrieving database information
• Generate vendor specific configuration (use XSD/YANG schemas if available)
• Configuration enforcement
• Use N.A.P.A.L.M. and vendor libraries (Python)
Evolution plan (4)
• Transition phase, need Perl – Python interaction
• Use ‘system’ to call full programs
• Structured input/output data (JSON and/or YAML)
• Proxy server for communicating to devices:
• Expose methods via XML-RPC
• Start with new vendor support
• Back-port to vendors still in production once the platform becomes complete
Timeline
Autumn 2018: Early 2019: End of 2019: 2020+
Beginning of the NAPALM driver and Python Full Python-based
development. vendor specific implementation configuration
configuration of core vendor generation
generator. Support of independent Additional features
Juniper configuration configuration (e.g. VLANs) Integrate
workflow elements other vendors
Summary
Network configuration automation is a must
Due to the scale and diversity of CERN’s networks
Today there is no commercial or open-source product, capable of replacing cfmgr
We are evolving the tool in order to leverage open-source tools with multi-vendor support:
Faster and easier integration of the new vendors
Easier maintenance of the tool
Faster implementation of new features
New calls for tender will most likely require programmatic configuration APIs
Questions?
Things to improve
• Make use of open-source libraries for automation and integrate them to
the existing system
• Switch to modern programming language
• Integrate vendor specific APIs for generation of the configuration
• Clear border between different modules of the cfmgr
Update plan
• Different parts of cfmgr will be replaced with the new ones
• Python-based modules which are going to interact with Perl cfmgr using XML RPC
mechanism
• Initial plan is to have support only for new vendors (Juniper)
• Once architecture is clear and robust – implement support for other vendors
Update plan
• Use NAPALM to organize communication between cfmgr and network
device
• Using RPC calls from perl to python
• Generation of the configuration
• Using XSD or yang schemas provided by vendors, to generate appropriate classes
• Convert class based configuration to text version
• Replacement of the platform, which communicates with LANDB
• Rest API is available for deriving required data from LANDB
