Well, this was a lot to cover,
and it might take a few times going through configuration examples,
as well as making references to some of the config examples that we gave,
but also making sure that we go through this set of lab tasks probably a handful of times,
just to make sure we're really comfortable with CLI configuration.
We've talked at the very start of this why there are some very good reasons for CLI,
learning the CLI, even if we're planning to use manager UI as our primary means of creating configs.
And so just to kind of rehash that real quick, we know that, first of all,
we can verify our configuration via the CLI a little bit easier than we can sometimes with manager.
Now, manager is good for a lot.
We've seen that we can do troubleshooting via tools like the traffic simulator.
That's fantastic.
There's a lot of verification we can do with the SD-WAN manager,
but there's something special about being able to log into a controller and seeing exactly what policy has been pushed out,
maybe to our edges.
We can log into the edges and take a look, as we saw, or at least via OMP filtering and the like,
but we can see what's happening at the CLI.
The second very good reason is because it really cements for us and brings together all of these concepts as far as how they end up working.
So we saw, for example, like if I want to deploy a centralized policy, it has to be via the controller.
But if it's going to be localized, it has to go on the edge.
And for that matter, if it's centralized but affecting the data plane,
then it has to get pushed kind of out of band via OMP because our controllers don't have NetConf configuration or API access to the edges,
and therefore it can't push config natively.
It has to push it via OMP.
There's just so much going on that if we just click buttons on a UI, sometimes we miss those details.
Whereas if I'm configuring things at the CLI and I'm manually punching in commands and I see where it goes and I see how it gets deployed,
I can see a whole lot more and I can start to piece a lot of those puzzle pieces together to make sure that I fully understand what's happening.
And the last reason, which is always a very good reason, is that, simply put, Cisco expects us to know it.
And if we're preparing for an exam and that exam has CLI being in scope, then that's something that we need to know.
And so if it's in scope for the exam, you know it's going to be in scope for the course.
So if you haven't already done so, absolutely take the time to go through the lab tasks that we just covered.
Those lab tasks are going to really cement a lot of these concepts.
It'll get the flow of the CLI down.
Again, if you don't have access to a lab, then just spend some time reviewing the configuration examples that we gave and make sure that you feel comfortable.
Number one, analyzing a configuration.
But number two, maybe even pull up a notepad and say, OK, well, how would I configure this if I did have access to a lab environment?
I mean, even in our examples, we weren't committing any changes.
We were just practicing CLI commands.
And so, yeah, it's nice to have the feedback if we don't enter a command correctly.
But we can always kind of type out commands in a notepad and then compare it to what it should have been based on the solutions provided.
So do the lab tasks, whether you have access to a lab or not.
I hope this has been informative for you, and I'd like to thank you for viewing.