So let's begin by talking about DNA Center. So what is DNA Center? We've mentioned it a lot
of times already. It's our centralized management solution for building and operating a fabric. So
this goes really well with the SD access solution, DNA Center. Now you can use DNA Center without an
SD access solution. So many Cisco devices you can control, manage, monitor, maintain
using Cisco DNA Center. So you don't have to set up an SD access solution to use DNA Center.
And it's really nice that Cisco gives us the opportunity to use devices either with or
without DNA Center. And so even modern equipment you can buy and it's just an upgrade of the
operating system or turning on this feature or that feature with licensing that would then give
you the ability to use DNA Center with it or not. So that's really good. But it's a controller-based
solution. So anytime you're asked what is a controller-based solution for managing your
network or for automation or for policy enforcement or for assurance or for integration, I want you
to pick Cisco DNA Center as your answer. So responsible for forwarding, configuration,
policy distribution, device management, analytics, any of those buzzwords you see on a certification
exam and are talking about centralized management of your networking equipment, then I want you to
pick DNA Center. So when you think about our traditional networks, especially what we were
doing last week, last week, we were configuring ASW1, DSW1, ASW2, DSW2, R1, R2, branch, right?
All of these routers individually. We had to do each and every single one individually. So when
you look at the traditional network, what do we have? We have a physical, we have a control plane,
a data plane, a management plane on every single one of these devices. We have the brain, the
power, and the management side of things on all of them. So even down here, you can see this would
be a standalone solution, standalone solution, whereby we have to manage every single access
point individually, right? So already we have solutions here that gives us a controller-based
solutions for those. But what about all this stuff, right? We want a controller-based solution
for that as well. So the new network is about doing what? It's about separating the control
plane from the data plane. So instead of having a control and data, control and data, control and
data, control and data, control and data, control and data, right? And even management, management,
management, management, management, management, management, right? What do we want to have
instead? We want to centralize the control plane, the brains, the management, all of that stuff.
And that's what Cisco DNA Center gives us, right? So traditional network, new network,
traditional network, new network. So that's what it's all about. It's really what it's all about.
Controller makes the decisions. So Cisco DNA, so now we can log into our controller,
and we can go ahead and do the configuration changes we need. We can have our devices talking
to the controller, so it can be updated with whatever else, whatever they see on the network.
And then we can get notified about it, or even the controller can be set up to make adjustments
on the fly as it needs to. So the controller can tell our data plane devices what to do.
We can centralize policy, centralize control, manage multiple devices at the same time
as a single entity. Can we upgrade our devices all at the same time?
Especially if they, you know, have a single operating system here, meaning upload the
operating system that needs to be sent, and then any devices that are going to use that operating
system, click, click, click, click, click, boom, boom, boom, they can all get updated for us
as an example, right? So our entire network can be modified, and our policies can be adjusted,
and everything can be provisioned as we need to using essentially clicks of buttons.
A true, true, true, true, true software-defined networking solution, folks,
with a centralized controller is going to have routers and switches that have
no ability to make decisions on their own. They are simply going to be forwarding devices,
essentially interfaces that can access tables to forward. So how do those tables
get populated? The tables get populated based on the controller.
So all that means is that these would need RAM and a processor, interfaces,
so not a whole lot going into them. They need the power to move packets, move frames,
and store tables. They don't have to make any decisions on their own except for, oh,
it came in this interface based on this table, send it out that interface. So that would be a
true software-defined networking solution, folks. So that's what we're going to be talking about
software-defined networking device. And then all the power and brains and management would all be
done from here. But Cisco doesn't really believe in that. Cisco still believes in having some brains
here, having some management here as well. One, it's so that way there you can have a hybrid
solution if you need it. Two, it's so that way there if anything really happens with the controller
solution you have, you can still log into your devices and do what you need to do.
You get a lot more flexibility, better scalability. So Cisco's software-defined
networking solution that you see here is not a true, true, true software-defined networking
solution because it's more of a hybrid approach where you still have brains in all of your
devices as well. And that's why Cisco products are expensive. That's why Cisco products are
some of the top-end products that are in the market because
you'll find products out there that are very, very cheap for SD
software-defined networking solutions. But you got to realize that they are just there to do that one
thing. And so they have tables that are designed just for forwarding and they get it from the
controller. Whereas Cisco devices, you got flexibility and you got a lot of different
and you got a lot of different options at your disposal.
So it's hard to compare one company to another company, one product to another product when it
comes to that. One thing that's great about Cisco though in this case is that it is a more open
solution than previous solutions they've had. Meaning that DNA Center will work with other
vendors' products. Absolutely. Yep. So that's a wonderful thing. Now some of the principles,
so keywords, buzzwords, in case you take the exam. When they talk about policy or security
or automation or analytics, it's an open platform, as I said, cloud and non-cloud solutions,
physical and virtual. Look at the scenario as a whole. And if they're talking about centralized
management of any of this stuff, just pick Cisco DNA Center as your answer. It's your best bet.
Benefits, agility and scale, reduction in risk, improve user experience,
investment protection. Geez, this sounds like a marketing video from Cisco. But down here,
this is amazing. This is true ease of updates. Because you can do partial updates, full updates
for applications and systems. And you can perform these updates from a centralized location.
So no longer do you have to go to device to device to device to device to do your updates.
You can do it all from the centralized location. So how is communication happening though in this
part? How do we communicate? For example, if I make a change on the controller,
how is that updated on all the devices? Well, we're using what are called APIs.
So what is an API? API is how software talks to other software. And if you're a developer,
you know what an API is. If you're not a developer, you may not know what an API is.
That's okay. But you'll know after today what an API is if you don't. So think about this for a
second. If you want to talk to your computer, how do you talk to your computer, folks?
You talk to your computer with a keyboard, right? So that's an API.
It's an API. The API stands for Application Programming Interface. But in reality,
how are you communicating with a computer? You're communicating with a keyboard. That's your API,
essentially. And how does the computer talk to you? The computer talks to you with a monitor.
So there's another example of an API in this type of scenario. But do we need keyboards and monitors
when one computer is trying to talk to another computer? No. No, we don't. We don't. We don't
talk to another computer. No. No, we don't. In this case, we have what? We have APIs, right?
So this is more like human management interfaces. But I'm trying to just give you that visual
representation. What is an API? A way to talk. A way to talk. So when you have your controller
needing to talk to the device, we can use these APIs, Application Programming Interfaces, to do
that. All right. And we'll see some examples here shortly. But you can also think of it this way.
When you go to your favorite restaurant, folks. So right now, everybody chat in your favorite
restaurant. Right now. Chat it in. Quick, quick, quick. Whatever it is. It doesn't matter. It can
be McDonald's if you want it to be today. I'm okay with that. Maybe it's A&W. When's the last
time you went to A&W? Or maybe it's something I've never heard of because we don't have it here.
All right. Excellent. So whether it's the steakhouse, or whether it's IHOP,
or whether it's A&W, or McDonald's, or whatever. Do you get to talk directly to the kitchen?
There's you. There's the kitchen.
You need an API. Who's your API? Who's your API?
It could be a waiter. It could be a waitress. In a lot of places nowadays, there's a digital kiosk
where you can go up to the kiosk, put in your order,
tap your credit card, move on. It could have been your phone. You could have done a mobile order.
Whatever it is, that's the API as an example. So just so you get a better idea of the API,
it's how you're going to talk to the back end. Front end, back end. Front end, back end.
How do you talk? You need an API. So we have what are called self-bound APIs
when we're dealing with DNA Center. And so the self-bound APIs are how we're going to talk
between the controller and the nodes. Doesn't matter whether it's controller to the node or
node to the controller. We're talking about self-bound APIs here. And so here's some examples
of self-bound APIs. OpenFlow, NetConf, OpFlex, SNMP. That's right. SNMP can be used from here
to here if we want to. The command line interface. You have an option in DNA Center to connect to the
command line interface. So that would actually be your self-bound API in that case. FTPS, FTP,
Telnet, SSH, Resconf. We're going to talk a little bit more about this later because you'll get
tested on it. And we'll talk a little bit more about this later because you're going to get
tested on it. But those are examples of self-bound APIs. It's how the controller and the network
devices talk to each other. But we also have to remember that we might have an application
that can talk to the controller. So for example, when you think about this application here,
what might that be? It might be your web browser, your web site, your web interface
talking to the controller. So how do we talk there? Well, that's northbound APIs.
So between the controller and whatever apps you have, it could be custom apps, it could be
whatever it is. There's a lot of customization here. You can build your own application
applications that can talk to DNA Center. So that's what we call northbound APIs.
Communication between the application and the controller. So here's some examples of what you
could use to communicate between an application and the controller. This is very, very, very common,
REST APIs, REST APIs. Let me say that one more time and start again, REST APIs for northbound APIs
between the application and the controller using what? Verbs. More on this later. Verbs.
It's the way we communicate on the internet. Verbs with a lot of REST APIs today. We got XML,
SNMP, Syslog, LDAP, Redis. There's just many different things. For example, we could have a
Syslog message that we use to talk. But the key here is REST APIs. It's a big one. It's the
big one. Not the only one though. So typically in a properly deployed environment where you're
using the best of the best of the best option, it would be REST APIs for northbound,
and it would be Netconf or RESTconf for southbound, even though there's a boatload of other options.
Those are what are supposed to be used to communicate between the application and the
supposed to be used based on the standard as the true, true options for software-defined networking.
All right. So speaking of REST APIs, let's talk about those a bit too. We're going to get tested
on them. So what is a REST API? So we're dealing here with a URL. That's what we're dealing with.
See this URL? What I want you to realize is that there are so many things today that are out there
on the internet, and how are they identified? They're identified by a URL. So you call that URL.
And so this is also now how we can call aspects of our networking devices as well.
What do I mean by that? Well, we will look a little bit deeper later on at RESTconf and the
concept of a URL for it, but you'll notice here there are different options. And based on these
different options and how you populate it, you could actually be pointing to a very specific
thing on your router, a statistic of your router, the CPU utilization of your router,
the interface state of your router. So yes, in modern networking equipment,
every single thing about your router, your switch, your firewall, your access point,
your controllers, your wireless, all of that, every tiny thing has the potential to have an
API associated with it, meaning that everything has its own URL. But before we get into that,
we'll get back to that later. The most popular way of doing this is with REST APIs, RESTful APIs.
And RESTful APIs use verbs. So when we are on the internet and you are trying to get a web page,
right, the HTTP verb is get. You want to create something, post. You want to update something,
put. You want to delete something, delete. Okay, that's what REST APIs use. Same thing.
So you want to retrieve all action movies from a movie database, get. Blah, blah, blah, blah,
blah, blah, blah, blah. You want to create a new movie entry in the movie database,
post. Blah, blah, blah, blah, blah, blah, blah, blah. So that gets filled in. So you're going to
say, how does that get filled in? Well, whoever created the application, when you fill in all the
fields, then those fields can populate the API. And then when you click submit,
when you click submit, that invokes post that.
So there's got to be coding behind the scenes here. It just doesn't happen magically.
No Harry Potter wand being waved here.
Would it be important for you to kind of remember get, post, put, delete? It might help. It might.
So let's look at DNA Center here, a screenshot of DNA Center. You'll see things like get, post,
delete in various aspects of DNA Center. Now you're going to have to know how to use DNA
Center for this exam. Not last time I checked. But understanding that REST APIs, northbound
communication, get, post, put, delete, and other verbs come into play.
So if we dig a little bit deeper here, you'll see here that we have this very specific API.
Here it is. Let me zoom in. Right there. HTTPS colon forward slash, forward slash,
the IP address of this specific DNA Center, and then other values, DNA intent, API version one,
network device. So what happens if I use this particular get? So use the get method, the get
verb, with that particular URL. It says, returns a list of network devices based on filter criteria
such as management IP address, MAC address, host name, location name, and a wide variety of
additional criteria. You can also use the asterisks in any value to conduct a wildcard search. So it's
even customizable. But if I went ahead and use this however I want to use it by executing this
get, then I'm going to get that particular result. All right. So there's the parameters we can use,
just host name, management IP address, MAC address, location name. So it's very specific
in this case what this one's particularly going to do. All right. So for example, if we go
out to my live environment, I'm going to go to Postman right now. So Postman is a tool that I
can use to create, test, work with APIs, REST APIs. So right now, I have some examples here. So
right now, I have this get one right here. So it says, HTTPS colon forward slash, forward slash,
sandbox dash iOS XE blah, blah, blah, blah, blah, blah, blah, blah, blah. And then it says
interfaces. So the point of this particular REST API is to get me all of the interfaces that are on
this particular device. So get me all of the interfaces and specifically any information
that corresponds with this particular data model. So we're going to talk about data models later
because that's part of the exam. So if I click Send, you'll see here now I can see that I have
gigabit ethernet one. It's a management interface. Don't touch me. So description.
It is an ethernet interface. It's enabled right now. There's its IP address. There's its subnet
mask. And then we have gigabit number two. And its description is network interface.
It's an ethernet interface. It is disabled right now. No IP address, no subnet mask.
Okay. Likewise, gigabit ethernet three. Somebody created a virtual port group on this particular
device with an IP address of 1.1 slash 24 subnet mask. It is enabled right now. And the type of
interface is a virtual interface. So as you can see, this particular REST API accomplished this
objective. This particular REST API accomplished this objective.
So what I'm going to do here is I'm going to grab – so I can show you this password. It's no big deal
because this is a public device out on the internet that Cisco has that people can play
around with. Okay. So here it is. Okay. Let me type in show IP interface brief.
Okay. There they are. Those are the interfaces we just looked at.
So when you think about it, right, this right here does something very specific. This particular
API does something very, very specific. And it gets me information like this. Whereas this
particular command gets me this information. Show IP interface gigabit one would get me
would get me this information. Show interface gig one would get me this information.
So notice here that in this case, it says up up right here. Well, that is defined here as
enabled true. Look at the description. The description is where? The description is
right here. So the COI displays information this way.
In this case, this particular REST API gives me this information. So somebody at some point in
time or something or some groups, some standardized body had to say, hey, if you do this,
then you return this. If you do this, then you return this. If you do this,
and we're going to talk about that later on, we're going to come back to that.
Just like whoever coded the Cisco CLI says if you type in this command,
this is what you get as a result.
So when we are dealing with REST APIs, what exactly are we truly dealing with in this case?
HTTP messages. So I'm sending HTTP messages in this case. And so when it comes to HTTP messages,
we have in those messages a start line, which tells us what's happening. Is it a get, a post,
what's happening? Is it a get, a post, a put, and the version of HTTP that's being used?
We have headers. They can be general headers, request headers, response headers, entity headers.
For example, content type. The content is JSON data, JSON information, as an example.
Data, Tuesday, whatever, whatever, whatever. We have an empty line, and then we have our body.
So what do we have? We have a start line, headers, empty line, body. Start line, headers,
empty line, body. And the body could be HTML, it could be XML. But when it comes to our headers,
the headers, you're going to have content type headers, accept headers, authorize headers,
accept headers, authorize headers, date headers, and more, more.
And so when it comes to the content type, it's about specifying the format of the data in the
body. Accept headers specifies the request format for any return data. So if I send you an HTTP
message, and I have an accept header in it, I would be saying, hey, send me back the data in
this format. And if I'm sending it to you in a certain format, then the content type header tells
you how I'm sending it to you. We can have authorization in there. So credentials to
authorize who can use it. So you're going to have the right credentials, and you cannot execute that
particular API. So for example, over here, under headers, you'll see there's a content type header
here for application Yang data JSON. And then under authorization, we have basic auth that is
happening with this username and password. So this authorization header, this authorization
is going to be part of the headers, this headers, these headers are going to be part of the headers.
And we're going to be sending that over with any information that's in the body.
So in my case, my body would be empty. And what's returned to me is what's in the body,
because I'm just requesting give me everything that this is supposed to give me.
All right, so the idea here is to recognize that you are going to have
these different fields in your HTTP header, and you're going to have this
section. So you're going to have your different fields in your HTTP message,
and then you're going to have a header section that can have content type in it, accept, authorize,
dates, and others. And so it's important that we secure our HTTP REST APIs. And so
typically, you're going to use HTTPS, that's how you secure, that's how you encrypt.
So if you're using HTTP, then it's not encrypted, you want to use HTTPS. And since you're using
HTTPS, you're using SSL slash TLS. Really, today, it's just TLS. But back in the day,
it was called SSL. And so most of the time when you're teaching or talking about it,
you say SSL TLS. So that way there, anybody who doesn't know it's called TLS still recognizes,
oh, we're talking about SSL here. So if you're using HTTP, it's not encrypted using HTTPS,
it's encrypted with SSL TLS. And then as I mentioned earlier, you can also do authentication.
So there's many different types of authentication. So none, basic HTTP, token, OAuth, and a whole
lot more. But if you look at it, none means what? It's public. Meaning that if I did not
require authentication, anybody could use this and get that information. If I use basic, it means
only those that know the username and password can use that and get the information. So you can
make the call all you want. You can call, call, call, call, call, call, call. But if you don't
have the right username and password, you'll never get a response. You have the right username
and password, you'll get a response. So this is something that's static, which means you have to
share with whoever needs that. So then that's not a really good production solution. Okay,
what about a token? A token is a static secret generated and retrieved from the API developer
portal. Okay, so this, right, is not all that great either in production environments because
of the fact that even though it is a secret generated and retrieved from the API developer
portal, it's still static, meaning it's not changing. So whoever gets their hand on that
static secret key can use it and get access to the data from that REST API. But the difference
is it's not a username and password, it is a static secret long key, like an access key,
an access code, something like that. It could be 37, 38, 100 characters long, you copy and paste it.
Somebody gets it though, they get access, right? OAuth is a lot better because OAuth is a dynamic
method of retrieving and using tokens from an identity provider. So you can connect to the
identity provider, you get the token, you get to use it, but it's a one-time token,
meaning that every time you do whatever it is you're doing, you reauthenticate and get a new
token. So if somebody captures your token, they can't use it again, it's a one-time token.
So that would be a better production solution. Now, because we're using HTTP,
we're going to be dealing with what type of codes? Oh, the good old HTTP codes here. Which one here,
folks, is your favorite code? Which one here have you seen like all your life and you used to make
fun of it 20 years ago? I'm pretty sure we'll all point to this one right here. Even my children,
my daughter the other day drew a picture with a big cloud on it and a 404 on it.
I'm like, why? Because it's funny. All right, fine, whatever.
So 404, but that's all we're dealing with here. So what do I want you to know for the exam?
I want you to know these because you never know what you could be tested on.
So you could be tested on something as simple as what does the code 200 mean?
It means everything's good. It means everything's okay. So look for the option
that looks as close as possible to everything is awesome. Something like that.
201, something was created. I can give you two examples of that right now.
Right here when I executed this one, so let's execute it again.
Code 200 right there. Everything's good. Everything's good. Okay, let's go ahead and
create something. So I have a put. So I have a put here for loopback 150. If we look at our body,
it says here, interface loopback 150 stormwind demo. So when I click send, this information is
going to get sent to this router, this router right here. So let's type in show IP interface
brief right now. All right, so the interface is not there. Let's go ahead and do this, send.
All right, we should see a 201, 201 created, 201 created. So if we go back to the router now,
there it is. And it's up, up, because I said in the code, make sure it's up. So did I have
to type all this out? Did I have to know how to format that? Yes, I did.
But I'm not telling you that in modern networks, you're going to be sitting there writing code
like this in JSON encoded format. No, no, no, no. Right? Applications that either you,
somebody custom makes in your organization, or you custom make that you fill in fields. Okay,
what's the name of the new information? What's this? What's this? What's this? What's this?
What's this? Is this? You can type it in. And then you click submit. And all of this
gets formatted properly by the application and get sent.
So it could be just a web based application. But there's an example of a 201 code.
Right? Let's say we make a mistake here with authentication. So let me just
accidentally change the password. So we do that and I click send 401, unauthorized 401
unauthorized. So let's go back to our page. There's an example of it 401 unauthorized,
authentication missing, or incorrect. If they can't find the resource, we should get a 404.
So let me try that one now. So if we say all interfaces, let's go back to this. Let me try
this. If we take off this, just trying to take off this click send, I should get a 404. Yay,
there it is. Right resource cannot be found because I didn't type that properly.
Okay. So just make sure you have a good idea of what these are, because you can be tested either
on what code are you going to get if authentication is missing? Or what code are you going to get if
the resource is not found? Or you could be asked, what is the result? Or why did you get a code like
this? Oh, because resource was not found or Oh, everything was fine. That's why I got 200.
So it's kind of strange that we have to learn these for an enterprise routing and switching
exam. But apparently, it's the way of the future. So even in DNA center, you can see here that we
have different response codes listed in DNA center. So I just my chart had a
my chart had a few as not all of them to some and you can use my chart for your study purposes.