Now in the official search guide that Wendell wrote, he spent a lot of time going over XDA or software
defined access.
Now just software defined could be software defined coffee.
I mean, there's so many terms with this word of software defined networking got abused.
We had software defined networking that was open flow.
Then we had software defined networking.
They were using APIs, we had software defined networking, there was overlays.
So we spoke about overlays and under laser ready basically became software defined, whatever you like,
but software defined access or XDA.
Is Cisco solution of changing the way a enterprise network works?
So traditionally in an enterprise network, we would have spanning tree that causes a whole bunch of
issues because we have to match up forwarding of ports to HSP.
Default gateways causes a whole lot of issues.
So we want to do away with spanning tree and what we do is we just run routing protocols everywhere.
So the default gateway of your PCs will be the local access switch.
So the switch on the edge, the switch that they connect to rather than a call switch or a distribution
switch, we run OSPF everywhere or routing protocol everywhere.
So we do away with spanning tree, we do away with port blocking that kind of stuff.
But in my experience of the CCNA exam, I think it was overkill, the SDA stuff in the OCG.
Now, if I hear otherwise, I'll change this course.
But I wouldn't spend too much time on SDA.
Basically, the idea is the network gets managers of fabric, so we have all these routers and switches
that are controlled by a controller and then similar to NSX from VMware, what we do is we building
tunnels automatically VXLAN Tunnels once again where we build an overlay across the underlay network.
So the core underlay network can be fairly basic rather than configuring a whole bunch of access lists
on the core devices.
We can do everything as a policy on the SDA server and then apply a policy on the network devices and
DNA center will basically build stuff automatically.
So it will build the VXLAN tunnels, it will apply the policies.
So we have this concept once again of intent based networking and intent is I want to do something,
but I don't want to have to explicitly write everything down to make that happen.
So as an example, I want to stop PCA talking to PCB.
In a traditional environment, you have to create access lists that stop those devices from talking
to each other, but with an intent based scenario and, and some of the other controller based implementations,
I would basically say, okay, this guy can't talk to this guy, put a cross there.
So that's all done through a GBE as an example.
And then that applies a policy to the network that basically stops that.
So you as a network engineer don't have to go and configure access lists manually.
Your intent is stop this guy talking to this guy and the network just makes that happen automagically,
which is quite scary in some ways because what happens if it goes wrong?
So the whole idea of this stuff is fantastic and I don't want to blow it out of the water straight away,
but just be aware that you should kind of understand what's going on under the hood because what happens
if something goes wrong?
But the principle is we have an underlay network, then we put VXLAN tunnels over it, which allows
us to apply policies on the overlay network rather than on the underlay network.
So we can stop this guy talking to this guy much more easily using these tunnels then to try and have
a single access list on an interface of a router that blocks people across the entire network.
A much better way of doing things.
It's basically the way it's going.
So we have a controller that manages a whole bunch of devices in the enterprise.
Now, just stepping back a second, sorry to jump around.
Software defined networking was more for the data center so it was NSX was a fantastic success in the
data center.
Cisco have ACI also data center product, but what about enterprises?
So SDA is an enterprise solution where we take software defined principles and apply it to an enterprise
and we apply policies on that network rather than in a data center.
So basically simple things like, okay, let's get rid of spanning tree.
So we run OSPF or routing protocol everywhere.
Everything's layer three rather than layer two.
But how do we get this device to talk to this device?
We can apply a policy through a GOOEY or a management station or a controller if you want to use the
the right term.
That applies the policy onto the network without you having to manually configure a whole bunch of stuff.
The idea is, is this term of abstraction?
Abstraction is used everywhere.
As an example, if I want to write a piece of Python code, I don't have to know how to make that do
something on a hard drive.
I'm abstracted from the low level programming.
The operating system abstracts me from the hardware operating system, abstracts me from network cables,
stuff like that.
I'm programming in a high level programming language python that goes all the way down through the stack
and actually make something happen.
Something happen on the the network.
So I'm extracted from assembly language as an example.
I'm abstracted from low level stuff.
I use my brain for doing high level stuff rather than low level stuff.
So very real world.
Example Pilots.
A pilot today doesn't fly from the UK to the US manually the whole way.
What do they use?
They use autopilot.
So the idea is autopilot allows the pilot to take care of high level tasks while the low level stuff
is taken care of using autopilot.
Now the airplane has all of these sensors that give information about altitude, stuff like that, and
then the plane can guide the pilot.
But autopilot can cause problems where the pilot tries to manage the network, or should I say the plane
through autopilot by adjusting various high level parameters rather than just grabbing the plane and
flying it.
And there was a really interesting video where they were talking about this issue where automation has
actually caused crashes because pilots no longer fly the plane like physically fly it.
They try and adjust the planes flying through autopilot.
So they they try and feed information to autopilot that then flies the plane and adjusts adjusts the
plane.
But if you've got a plane flying at you, you as a pilot should grab the airplane and fly it out of
the way rather than trying to adjust autopilot.
And I think that's the same thing that we as network engineers need to be careful of, is don't rely
on the autopilot or the cleverness of all of these applications.
When the network is burning or there's a fire, you need to jump in and fix the problems.
So automation has its place, but it's still important to understand how networks work because automation
will allow you to break a network very, very quickly if you don't understand what your automation is
doing.
I mean, if a programmer just writes a script that sends a whole bunch of beeps into a network running
spanning tree, it could mess up your whole network.
So you need to understand what your program is doing, what these applications are doing.
So there's huge advantages to abstraction, huge advantages to automation, but you still need to understand
networking.
So I think Cisco have done a good thing here.
10% of the CNA is automation and programming or programmability.
90% is a lot of traditional network stuff.
You still a network person, it's still a network engineer.
You still need to understand protocols like spanning tree, OSPF, etc. But I think for me the programming
side is very exciting because Cisco now have this dev network, so you have this world in front of you
which didn't exist.
I'm recording this, you know, not long after the CCMA was released.
You've got this world now where you can go traditional networking with a bit of programming, or you
can go programming with a bit of networking.
So I think if you're starting in your career, you have two wonderful choices.
And I mean, you just got to decide what you enjoy.
Do you enjoy programming with a touch of networking or do you enjoy networking with a touch of programming?
I think those are going to actually become closer and closer in future.
So five or ten years from today, the line between networking and programming will just draw closer
and closer.
Networking is changing, and I've been saying this for many years.
I mean, now we're going more to the cloud.
So cloud stuff is becoming more important, but.
To think that if you put it in the cloud, it's going to solve your network problems.
It's still a network.
You still have to manage the network cloud as in your network.
I mean, if you put a VM in in the cloud, it's cool.
It's just a VM.
But what happens if you have virtual machines in Asia and in America and in Europe, suddenly you start
working with load balancers, you start working with firewalls, you start working with access control
lists, you start working with VLANs, not call that, but you start working with all the traditional
networking stuff.
So just because it's in the cloud doesn't mean that you can ignore networking.
Still going to be a lot of work for network engineers.
It's just the roles may change rather than typing on the CLI.
You might be working in a controller or in the cloud, but you still need to understand networking principles.
Okay, so that was quite a long ramble, a hope that kind of discussion was valuable to add to the course.
I'm going to show you some more practical stuff now in the rest of the course, but hopefully that gives
you a good idea of what's important for the exam and kind of sets the, the 10,000 foot view and overview
of of programming and network automation.