Configuration Management In Heterogeneous IP-Networks. Juho Rockas Supervisor: Heikki Hämmäinen , Espooo

Transcription

1 Configuration Management In Heterogeneous IP-Networks Juho Rockas Supervisor: Heikki Hämmäinen , Espooo

2 Table of contents Motivation Background Research Objectives and Questions Why Configuration Management? Challenges Research Features, Protocols and Systems Tests Results Conclusions and further study 2

3 Motivation Configuration Management: How to maintain, change and manage network device configurations Both physical (PNF) and virtual (VNF) devices Heterogeneous Different vendors and operating systems IP-networks Physical connections, not mobile 3

4 Motivation - Background Network configuration management has been lacking behind other parts of network development Most of configuration changes are still done by logging into the device with SSH and changing configurations with CLI The next version is to do scripts in various languages (Bash, Python, Perl...) or copy paste templates No standard way to do changes between different vendors or even with same vendor s different operating systems Case company: ~ Internet connection users and two data-centers 4

5 Motivation - Background 5

6 Motivation Research Objectives and Questions What are the challenges/benefits of configuration management? Why there should be a configuration management system? What solutions there already are for configuration management? What features are needed in the configuration management system? Can our solution be used with SDN and NFV? Is there a flexible, futureproof and cost-effective configuration management solution, which can be used in multi-vendor networks and is based on standards, for our case company? 6

7 Why Configuration Management? It is an essential part of network management Network management makes sure that networks are always up and running as they should Network engineers have the right tools to operate networks FCAPS (Fault, Configuration, Accounting, Performance and Security) ITIL (Configuration management & Change Management) 7

8 Why Configuration Management? Configuration changes can be done by: CLI (various), GUI (Various), SNMP (Standard), Netconf (Standard), REST APIs (Various)... -> Standardize the model to make changes to the devices Centralized point for changes, for management and for history Less configuration change failures, faster fix times Downtimes costly 58

9 Challenges Shear amount of different device vendors and operating systems Building a system which supports all of them is a major challenge Rapid development of networks and services New firmwares, devices, services, user requirements... The lack of common network configuration protocol SNMP is not good enough Netconf and YANG were developed, their problem is support 9

10 Research - Features Centralized Database Support for multivendor environments Common markup language preferable Network change tracking Who changed, what changed, when changed Network-wide transactions Rollbacks and Backups Documentation and firmware upgrades User-interfaces 10

11 Research - Protocols Command Line Interface (CLI) Every vendor has their own CLI s, Cisco example have 5 SNMP Mostly used as monitoring protocol Netconf Developed to tackle SNMP s shortcomings A lot of potential but support still lacking Scripts (Python, Perl, Bash...) 11

12 Research - Protocols HTTP based configuration Graphical User Interfaces (GUI) Usually do not support all commands REST APIs 12

13 Research - Systems Division to free (Open Source) and commercial tools Big enterprise solutions like Solarwinds, Alterpoint... Usually part of bigger network management or even IT management systems Couple of commercial Netconf products like YumaPro, MG- Soft Netconf Browser Pro Free open source Netconf products like Netopeer Simple free database solutions like Rancid Scripting tools like Trigger or NAPALM 13

14 Research - Systems DevOps tools Ansible, Salt, Puppet... More and more implementations from device vendors Service Orchestration like Cisco NSO Common markup language Service lifecycle management SDN idealogy for both Physical and Virtual devices 14

15 Research - Tests Three different tools Netopeer Free Open source Netconf client/server program CLI and GUI Ansible DevOps meets network automation, CLI version free Network modules from version 2.0 (winter 2016) Cisco Network Service Orchestration (NSO) Previously Tail-f NCS, commercial product YANG based multivendor service orchestration system 15

16 Research - Tests Laboratory network: 2 Cisco IOS devices (switch) 1 Cisco IOS XE device (router) 1 Cisco IOS XR device (router) 1 Alcatel Lucent SR device (router) 1 Alcatel Lucent Switch 16

17 Research - Tests 17

18 Results From bibliographical research we found out that configuration management is still an open field No standard procedures as in many different types of protocols, standards, systems and tools No standard protocol yet YANG is getting more and more traction with service orchestration, SDN and NFV solutions and its model count is growing all the time However the feature list is clear: Multivendor support, common language, centralized database, central point to all configurations, rollback and backup features, management features (AAA) and usable user interfaces 18

19 Results From tests we found out: Netopeer was not production grade system Installation is difficult, no manuals, problems connection to the devices... Ansible has a lot of potential as an automation tool for network management Especially in data-center world where Ansible can be used in server and network automation Device support is not as good as it should be Not necessarily a configuration management system 19

20 Results Cisco NSO is a feature rich software which has almost all the features which are wanted from configuration management system It excels in multivendor environments, especially with service creation and its lifecycle management Its user interfaces, CLI (Juniper and Cisco style) and GUI, are versatile and easy to learn Straight comparison between Ansible and Cisco NSO goes clearly to Cisco NSO However Cisco NSO has a cost and Ansible s network modules were just developed so the scale might change in time 20

21 Conclusions and further study Cisco NSO has all the features which were looking for Further testing still required to see what it else can it offer Cost analysis To look into other service orchestration systems and generally to research that area more Service orchestration could replace basic configuration management Maintain an intrest on Ansible How does it modules develop and to see how does its device support grow 21