Now in the official cert guide that Wendell wrote he spent a lot of time going over SDI 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 and we had software defined networking that was
using API.
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 SDK Cisco's 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 you know forwarding of ports to a just IP default gateways causes a whole
lot of issues so we want to do away with spending tree and what we do is we just run writing protocols
everywhere.
So the default gateway of your pieces 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 SPF everywhere or writing 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 CCMA exam I think it was overkill.
The FDA stuff in the O.C. gee now if I hear otherwise I'll change this course.
But I wouldn't spend too much time on SGA.
Basically the idea is the network gets managers of fabric.
So we have all these writers and switches that are controlled by a controller and then similar to NSX
from the Amway what we do is we building tunnels automatically the X land tunnels once again where we
build an overlay across the underlying network.
So the core underlying network can be fairly basic rather than configuring a whole bunch of Axis lists
on the core devices we can do everything as a policy on the SDK server and then apply a policy on the
network devices and DNA center will basically blast off automatically.
So it will build the excellent 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 PCH talking to PTB in a traditional environment you have to create access
lists that stop those devices from talking to each other but if an intent based scenario and and some
of the other it's controller based implementations I would basically say OK this guy can talk to this
guy put across there so that's all done through.
Give me 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 to stop this guy talking to this guy and the network just makes that happen automatically.
Which is quite scary in some ways because what happens if it goes wrong.
So the whole idea of this SD n 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 underlying network.
Then we put vehicles land tunnels over it which allows us to apply policies on the overlay network rather
than on the underlying network so we can stop this guy talking to this guy much more easily using these
tunnels than to try and have a single access list on an interface of a router that blocks people across
the entire network.
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 third to jump around software defined networking was more for the datacenter
so it was NSX was a fantastic success in the data center.
Cisco have ECI also data center product.
But what about enterprises.
So FDA 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 datacenter.
So basically simple things like OK let's get rid of spanning tree.
So we run 0 SPF or writing protocol everywhere.
Everything's layer 3 rather than layer 2.
But you know 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 use 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 an abstracted from a low level programming the operating system abstracts me from the hardware operating
system abstracts me from network cable 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 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 why the low level stuff is
taken care of using autopilot.
Now the aeroplane 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 it was a really interesting video where they were talking about this issue where automation has
actually caused the crashes because pilots no longer fly the plane like physically fly it they try and
adjust the planes flying through autopilot so that they try and feed information to autopilot that then
flies the plane and adjusts adjusts the plane.
But if you got a plane flying at you you as a pilot you'd grab the aeroplane 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 automation is doing.
I mean if a programmer just writes a script that sends a whole bunch of BP to use it to a network running
spending 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 has done a good thing here.
Ten percent of the CCMA is automation and programming or program ability 90 percent is a lot of traditional
network stuff useful and network person is still a network engineer you still need to understand protocols
like spending 3 0 SPF etc. But I think for me the programming side is very exciting because Cisco now
have this definite track 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 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 close in future.
So five 10 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 are going more to the cloud.
So cloud stuff is becoming more important.
But don't 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 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 low balances you start working with firewalls you start working with
access control lists you start working with villains 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 gonna be a lot of
work for network engineers.
It's just the roles may change rather than typing on the CLIA.
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 10000 foot view and overview of
programming and network automation.