NFD16 day two - Apstra
Intent concept is not as broad as SDN but still vendors have different views of this meaning.
According to Apstra an intent is “the definition of the expected outcome”. The sum of the intents of a network is the source of truth.
That’s quite a leap from today’s networks where the intent is distributed on the configuration of the devices and there’s no easy way to have a global view or validate the intents (see my Veriflow post).
Apstra’s input is the intent, it applies semantic validation to prevent errors, verifies rules and constrains are respected.
After this there’s the expectation rendering phase where the actual device configuration is generated, automatic unit tests are created, and the configuration is pushed to the devices.
Sounds cool uh? Yes it is!
Apstra solution is powerful but it’s architecture has usability in mind so it’s simple. A total of 6 configuration files generate up to 300 lines of python code to start automating the network.
For every line of code Apstra generates 3 lines of testing to validate the intent, they don’t really want to mess with the network.
It is possible to extend the schema of the model of the network to add further information and create new intents.
The approach of the backup is different than Veriflow’s and other similar solutions. Apstra doesn’t backup devices configurations but it creates a snapshot of intent that can be used to generate all the configuration on the fly.
The snapshot can be used to rollback the network to a previous state.
Intent is not pushed immediately to the network when a change is made. There’s a staging area that can be verified and inspected before committing configurations to the devices.
Wrap up Apstra
Pushing intents generated configuration changes on a live network requires a blind trust of the product.
It is possible to inspect the changes before they are applied but it doesn’t make sense to insert an human-validated step in between an automated process. It simply doesn’t scale.
The snapshot feature allows what DevOps call fail fast to be applied to the network.
Fail fast is not promoting fail but the focus is on the fast. Can we detect a failure/outage fast after it happens? Can we recover fast to the previous state?
With tools like Apstra a Network Engineer has the ability to perform a fast recovery with intent snapshot rollback if network telemetry notices something was wrong in the intent deployment.
Final note: I strongly suggest to use an OOB management channel, there’s no chance to recover the network if connectivity is lost (or use “reload in” but it doesn’t scale)*.
Tech Field Day (TFD) is a commercial activity for TFD and the presenting companies. When I attend TFD events my travel and accommodation expenses are usually paid for by TFD. At the events, most of my meals are provided by TFD. In addition, the companies that present at TFD usually give the delegates gifts. At TFD the presenting companies engage with delegates to educate us about their products and services. The smart companies also want to learn from delegates (a few are very smart about this). The aim of the event is to help the presenting companies connect with delegates. Ultimately get the company’s message spread by delegates. Usually, delegates will write about some or all of the presenting companies.
Neither the TFD staff nor the presenting companies get to review what the delegates write. There is no obligation on delegates to write about any or all presenters. Nor is there an obligation to write nice things about presenters. In fact, the greatest expectation is that delegates will be honest in any writing that they do.
This (ifconfig.it) is my personal blog. Everything I write here is my thoughts and opinions. None of it is reviewed by the organizations I write about before publication. I could get corrections from the companies I write about and may incorporate the parts I agree with into my posts here.