You have a network that is the life-line of your business. It features powerful hardware, connectivity, redundancy, resiliency and probably parts of it are automated as well. The question is.. do you run testing in production? Actually, why not? Do you get PTSD from hitting "enter" on the command line? Why do you still use the command line, anyway?
The eternal balance of testing/production and trust in your network to perform as it should when you commit changes.
Bonus points if your CMDB is not an excel sheet. But is it up to date? Read on for some examples...
Add a VLAN - provide a firewall rule - set up multicast for a network stub, do you want to do write a new playbook every time or just work
An ansible playbook is easily written but to automate an entire network you need to bring out the big guns and have a clear plan how to orchestrate all the changes.
Closed-Loop verification makes sure not only the configuration has been deployed but it also works as intended (and has been verified)
Adding a VLAN here - what will be the impact to the rest of the network?
Removing a firewall rule from all devices - which flows will change?
Adding a subnet to a service - will it be reachable from the outside?
Intent-based networking needs a closed-loop verification so you can deploy without fear.
How do you define "intent-based" networking? How do you verify the desired intent is being deployed? Is your automation solution really that smart?
Between Infoblox, Prime and Ansible.. who checks they all work together as intended? is the VLAN really present on all STP instances? Is that ACL named the same everywhere?
Any change in the network is validated against a working copy of the network and provides feedback to the orchestration layer. Start defining expectations instead of pushing configuration.
What happened 3 days ago? Why did that session drop? What neighbour caused this route to flap? You can become a time traveller in your own network and reverse time.
Having a model also allows you to predict the future. Will the change have the intended outcome?
Will upgrading the software break our automation platform? Who will be impacted by this change?
Nobody likes writing documentation. But outdated/not available documentation is even worse. Let us help you automate this tedius task.
The only true documentation is what is in the network. But how to read this? How to get this information out and use it for another purpose?
You can use smart software to read the current state of your network and provide "live documentation" - and if you so desire it can also create a document for you to give to the consultant.
Can you imagine your automation layer is talking directly to your monitoring server and the changes that you just performed are automatically added to the monitoring platform?
The VLAN you just added, the Firewall that just came online, the Service you just provisioned, you name it. Its like magic. All you need is an API (and smart software).
Changes in the network will be detected and the monitoring will be adjusted accordingly.
Find all devices affected by a certain vulnerability and plan upgrading them. Make sure you can predict who will be affected/impacted by the update.
This should not be done using spreadsheets but automatically - so you can focus on patching, not finding out who and what is affected.
Read all about this awesome piece of software on https://ipfabric.io