Automation with Catalyst Center

0:00Welcome to the content on working with Cisco Catalyst Center APIs. This is really something that used to be called Cisco DNA Center. They've just rebranded it and re-marketed it as Cisco Catalyst Center. Now, this is all about how we manage a large campus or a large enterprise. I really like to think of this as a university campus where it's large geographically. It's got lots of buildings. It could be two or three or four miles wide and 10 miles long covered with buildings and people and there's people roaming and moving all over the place.

0:38This is a big task for a network engineer. How do we actually manage this enterprise environment? Well, that's what Cisco Catalyst Center does. It actually brings a very unique technology stack to the table. We are going to spend some time just understanding Cisco Catalyst Center. Again, because this is a Cisco DevNet associate level exam, there's a very good chance that most of you have never talked with or interacted with a Cisco Catalyst Center appliance. Now, this is an incredibly advanced topic.

1:09This is a huge tool to undertake. What we're really focused in on is what the exam wants us to focus in on. Just understanding what the capabilities of this API are. Now, very importantly, Cisco Catalyst Center brings to the table a wonderful SDK. So what we're going to focus in on ultimately is how we can leverage the SDK to work with Catalyst Center. We're also going to be using the Cisco DevNet sandbox to interact with the Catalyst Center box and have an API that we can actually interact with.

1:44So without further ado, let's spend some time understanding what it is that Catalyst Center really does and where does the API fit in? Then that will highlight how we can actually work with that API and understanding what those capabilities are.

0:00So what I want you to do is I want you to see a Cisco Catalyst Center, formerly known as Cisco DNA Center before we jump into this. My first really big experience working with DNA Center came when I was studying for my CCIE exam. And that is actually on the CCIE exam is how to actually build a campus, design , implement, provision, a campus with policies on the exam. That's part of the lab exam. So you have to know how to do it. But they don't make you, Cisco doesn't make you know how to do it until you get to the CCIE. So the concepts of working with Catalyst Center are very abstract.

0:42So I want you to see it. I think that's where I feel very strong about seeing it. Now why the rebrand from Cisco DNA Center to Cisco Catalyst Center? Look, I wasn't in the room when they chose to do that. But my hunch is, is that it wasn't very clear the name DNA Center wasn't very clear when that it was for enterprises. Cisco DNA Center, aka now Catalyst Center, relies heavily on the Catalyst 9000 series of devices.

1:12Similar to how ACI relies on the Nexus 9000 series and it's a controller that controls your fleet of infrastructure in a data center. We're now talking about the Catalyst series and on the enterprise side of things. So very similar, but how the enterprise is actually used, what actually goes on , the types of traffic in an enterprise, there's no comparison to a data center at this point. So what a campus needs is very different from say what a data center needs and the Catalyst 9000 series solves that problem.

1:48So right here, I've got the always on Catalyst Center box up. You see, here's the go to link. It is a web based GUI, just like most software defined networking controllers are now. And here's the credentials. So when I log into this, we're going to accept the self signed certificate. And then we're going to get prompted with the DNA Center credentials here. I'm going to come back here. I'm going to grab the username is DevNet user and the password is Cisco 123 X. So what I'm going to do here is I'm going to type DevNet user paste in the password and hit log in.

2:26And from here, I'll be able to better explain what the DNA center, AKA Catalyst Center is really all about. So we're logged into Cisco DNA Center. And what I want to do is I want to talk about what this thing actually is supposed to do and what it brings to the table that's so incredible and unique. With a large global enterprise or even a large campus, let's say this is your geographic area that your campus exists in.

2:56This could be a college campus. And you've got a building here. Maybe you've got a building here, a building here, a building here. Maybe you've got a restaurant right here, you know, and maybe a little amphithe ater right here. You've got something over here. I don't know. And let's say you, you work on this campus, you work right here. So your desk is here, you sit down, you've got a laptop and you sit there. And let's say you are in the accounting department.

3:28And this is really great because as an accounting professional, you know, there 's going to be some applications that you log into. There's probably going to be a file share that you need access to. There's basically just all of the things that you would use to collaborate with for your department and your cost center, your silo. All of these things are going to be specific to you in your box. You're going to have policies. Maybe those are, you know, group policies from Windows Active Directory. And maybe, you know, you plug in and you're going to be attached to a certain V LAN, like VLAN 23 to make up something.

4:05Now, here's the kicker. What happens when you need to go visit someone in this building and work on something and show them something that you have access to in the accounting? And then later, you've got to go over here. And then you've got to go over here . And then you've got to come back here. Do you see where the problem lies in? The way the current infrastructure works, the way current, you know, environments work, is you're usually siloed to your physical location.

4:39Your physical location determines what VLAN you can attach to. And therefore, what policies or accesses you can get. And when you move away from that physical location to somewhere else, you lose that. This is the problem that DNA center, aka catalyst center, solves. What they've created is now for groups of employees or people or guests, basically any users on your campus, we can attach policies to their computer, to their MAC address.

5:16And as they roam throughout the campus, that MAC address obviously goes with them. And so do things like their VLAN configurations. And therefore, all of the connectivity that they have. So if I had a file share, let's say this is my data center right here. And out here is how we get, you know, to the internet, that's where our WAN connectivity is. Let's say this machine, me right here, I'm the machine or my laptop is the machine, needs access to a file share that's in the data center. If I go down here to visit my friend and need to show them that file, my connectivity can still reach that data center.

6:03Because it's not about my physical location anymore. It's about my identity and the policies that grant me access wherever I go. Now still, how does this seem possible? Because how would a VLAN possibly follow me wherever I go? Well, it uses a fabric, much like how Nexus and ACI use the fabric. We are, again, typically having ISIS as our underlay. And we've got VXLAN as our overlay.

6:42But the difference is in the data center, we discovered where applications were using BGP. Using BGP. We're not using BGP, which is really EVPN, like we were in the data center in DNA center. Instead, we use something called LISP, location, identity separation protocol. So the idea is your identity and your location can be separated.

7:13And wherever you go, your identities and your current location can be updated. And therefore, we can say, okay, when you want to tunnel layer two packets to this device, this is their new location. So make sure you give them their connectivity and it follows their identity. This is wildly complex. And I don't fully think that, you know, as you're going through your beginners, DevNet Associate Journey, I don't think you need to memorize this. Okay. I'm just giving you context as to what DNA center can do or what catalyst center can do and what its purpose is. Its purpose is to allow people to freely move throughout a campus and still maintain their same connectivity that they have at their desk.

8:05Now take it a step further. Your campus can be global. Let's say this was all happening in San Francisco. What happens when I fly to London and work on our campus in London? Well, if that London site is, you know, basically adopted to our catalyst center controller, then the policies go with me. And I still maintain the same connectivity. That's a really powerful thing to understand.

8:40So in the next video, we're going to break down very basically what the components of catalyst center are that we can, that way we can understand how this campus and this connectivity and all All this stuff comes to be. [ Silence ]

0:00So the idea of implementing such a complex fabric across a very large ecosystem , a very large enterprise, a very large, potentially global campus sounds daunting. And I'm not going to lie to you. It's not simple. But Cisco DNA Center, aka catalyst center, I'm never going to get that right is definitely one of the ways that makes it a lot easier. And they break it down into really four stages that they call applications.

0:32Each one is considered a separate application. But in my opinion, they're just stages or guidelines or a workflow. If I hit the hamburger menu in the top right, this is actually the four applications. We have design, which is where we identify. Hang on, let me change my color. So this one's going to be a little bit easier to see. I'll do something kind of in the middle. Yeah, there we go. This is where we design our global layout. And I mean quite literally we put in a building name and address.

1:11And it generates a actual map using, I think, Bing Maps or Google Maps. I can't remember which one it is. But it shows you basically what your global layout is going to be. You can go ahead, click on this. You're not going to hurt anything. If you do something like network hierarchy, you might be able to see kind of, well, you just got the global site right here. They haven't actually added any subsights to it, if you will. But this is where you would see, obviously, a global map right here. And if we had sites or subsights here in this, you know, public DNA center box, you would see them right here.

1:47So the design is really just talking about what sites we have and maybe identifying, you know, hey, this is how they're going to talk together. This is step number one is just understanding what your buildings are and where they go. Step number two is when we start to map out policies. Now, policies are kind of interesting, especially right here, where we see group-based access controls versus IP and URLs-based access controls.

2:20This is identity, quite literally setting up usernames and passwords, as well as groups that those users belong to. Then you identify the applications that they're allowed to reach, all in these policy sections. If that doesn't work for you, if that doesn't work by identifying usernames or passwords, maybe because you have an application that is really more like a service application, definitely something like an AI agent, then you would just identify what it is based on its IP address. It'll have a static IP address. It'll always be there to serve, you know, whatever it is that it's supposed to serve.

3:10So we've got our places, we've got our people and our applications identified. What comes next are the network devices that stitch it all together. The network devices will quite literally be given all of the fabric as well as configured with the policies, like understanding what MAC address is allowed to talk to water, whatever. All of that happens in provisioning. So when I go to provision, we really begin with inventory discovery, that's supposed to be a C discovery, automating the discovery of these devices and onboarding these devices, as well as understanding the software to find access layer.

4:01That's what are the devices that belong to this fabric, and how are they allowed to transit from one campus to the next. That happens in the provisioning stage. So, if you're thinking about it, think about it as step one is geography. Where is my campus? Two. Who is allowed to access it? Three. The devices and network infrastructure.

4:32Very important to understand wireless. Definitely the biggest part of a college campus absolutely comes under this territory. The provisioning of wireless infrastructure. I mean, that's really the whole point of the roaming, isn't it? You know, all of our devices these days are mobile phones, tablets, laptops. I mean, desktop machines are becoming increasingly uncommon. Something like 75% of all network traffic in the world happens over wireless.

5:03So, all of this is not just catalyst 9000 switches making it happen. You got to plug into an access port. No, like, this is where wireless comes into play. And the mobility comes into play. And this is when it comes to life. Now, once it's brought to life, the fourth application, DNA center assurance, this is where the network team actually monitors the going on in the environment. So, if you want, go ahead and click on assurance and go to something like health.

5:35And you can see things like, here's my access layer where I've got four healthy access switches. The distribution layer, the core layer, the routers themselves, which would probably sit on the edge. We've also got our wireless controller, our access points. We would identify AAA and authentication servers, DNS servers, and DHCP servers . Now, how all of these things work together, we're going to talk about that in the next video. Because that sets up a very big new concept about APIs that we haven't talked about yet.

6:10Okay, we're going to talk about how all of these pieces come together and communicate to each other. But for right now, just understand that. We can identify issues that could be going on with our DNA center. We see what device this is happening on, where it's happening, how many times it's happened. And that's pretty interesting stuff. We can take a look at the network tab and see the network devices. You can take a look at the client tab. This would be understanding the people who are connecting in the network services, which would be AAA DHCP and DNS.

6:41And the applications that they would have access to, all happens on the assurance dashboards. So it's a big thing to have people, places, network devices, applications, wireless. All of these pieces are coming together in the Cisco DNA center, aka catalyst center, which I'm never going to get right. But there it is. It'll always be DNA center to me. Okay. Now, I did say there was a fifth tool, and this is the one that for the DevNet associate exam, you want to focus in on the most.

7:14And that is the platform. The platform is the API brains of the system. And the cool thing about the platform is it's not just, you know, you writing a script to ping the API and getting a result back. Note the API or platform goes in four different directions. And in the next video, we're going to talk about what it means for an API to have directionality.

7:44Thank you.

0:00So let's now take a brief moment to understand how the APIs work and how Cisco catalyst center Gets its communication straight because there's a lot of pieces that actually make catalyst center work What I'm gonna do is I'm gonna click on the hamburger menu And I'm gonna click on platform and here you've got all sorts of things you got overview Manage developer toolkit, which is where you want to live and then the runtime dashboard look I'm gonna go to overview and there's really not much here It kind of just gives you a link to the other four pieces really But I want you to use this white space or at least I'm gonna use this white space to understand this diagram that I drew last time at the center of it all is the catalyst center platform That is the application that we're working with and this is specifically APIs So if I draw a circle around it, you can almost think about this like a compass to the north is Us Smile here's our laptop Any client machine that's going to interact with client or catalyst center

1:15Basically from the front end or via an API. This is known as the northbound API And down to the south you have the infrastructure. So these are switches these are routers These are wireless APs and more So you can kind of see how it can go from north to south Almost every API that we've interacted with so far is a north south API when we were interacting with ACI which ultimately interacts with Nexus switches. That was a north south API Responses coming back to us are northbound Requests or responses going towards the network devices are southbound So we break these this flow of communication apart. We break the APIs apart You have a northbound API and you have a southbound API now we also have an east west API and There are a lot of opinions about what the directionality of these arrows looks like to the east you can kind of think about this as outgoing

2:32information Whenever something happens in catalyst center and it needs to tell external applications About what just happened that's known as the eastbound API So what you often have here is something called web hooks Now, what is a web hook? basically any event That happens in catalyst center or something like that. Let's say an issue Happens a network device goes down an issue gets created in the catalyst center platform What we want to do is we want that event the creation of an issue or a ticket in catalyst center We want that event to be pushed out to some other application Maybe this is a very commonly known one like pager duty The network just went down wake up the engineers because it's 130 a.m This is known as a web hook whenever an event triggers an API call to another application. That's a web hook This event uses this API payload and pings that application. That's a web hook

3:51so eastbound Application or eastbound API's are usually web hooks But it's really informing any external application or integrating any external application to stuff that's going on in catalyst center the westbound API are Applications that catalyst center relies on this would be AAA like Cisco ice this would be DHCP an IPAM server this would be DNS servers The catalyst center While it can do a lot of the work for us When we're setting up network devices when we're telling it okay, this person belongs in VLAN 10 Where does the DHCP lease come from when that person roams from one spot to the next?

4:53Catalyst Center isn't really built to handle running DHCP services Nor is it really built to handle the AAA and the authentication and authorization? It relies on external applications to make that part work So what I would actually do this is my argument Let me actually clear the screen like this what I would actually do is I would draw the arrow like this Even though there is two-way communication in all of these directions I would say the eastbound application feeds data into catalyst center that it needs Though or did I say east? I meant the west the west bound API actually feeds data into catalyst center that it actually needs the eastbound API feeds data out of catalyst center to our other applications The northbound API talks to us and the southbound API talks to the network devices So it's really important to understand the catalyst center is a full spectrum API It's a little bit different from our other device resources that we've worked

6:09with in the past that we're basically just north south now we have to have east west as well and This is a really important factor for you to understand especially for your exam environment Now beyond that the platform gives us the ability to explore the API So from here go into platform and then go to developer toolkit and you get this really really cool browser experience for understanding what all the rest API requests are and What that workflow is you can even test the requests right here on the left hand side?

6:45You have the categories of the things that you want to work with Know your network is probably going to be the big one especially for your exam environment You may be asked to what is a script that gets a list of devices look like or gets a list of clients look like or gets a list of applications look like This is the area that you really want to focus in on For your exam environment know your network, but none of that works without authentication right here at the top So right here you can see you will send a post request to this endpoint auth.token and it even tells you this token remains valid for one hour The token obtained using this API is required to be set as the value x auth token Well, I'll be that's really familiar, isn't it?

7:37Yeah, exactly. It's the exact same workflow as in X API rest It's the exact same workflow as the ACI API that we worked with when we were interacting with the APIC machines now you can click on the try button right here and It will bring up this kind of interesting pattern for you to test it out The authorization isn't super clear because we are using basic authentication with a username and password So this authorization is really saying if you're gonna post it into us You need a base was a base 64 encoded we can hover over this and see The little eye right there. Maybe it's not gonna let me over there Well, I had it for one second if I just leave them out alone there it is it is looking for Okay, I can't move my mouse. This is really killing me right here base 64 encoded strings like right in the middle of that text Don't worry about the base 64 encoded string. Okay, we're gonna show you way easier ways to authenticate and handle this starting with Python with Postman But of course the big thing to know is DNA Center comes with an SDK so if you're gonna write Python code to interact with this That's definitely gonna be the way to do it Just use their SDK to log in manage the session and then perform subsequent

8:57requests Now in the next video We will fire up Postman and take a look at what is it like to actually explore this API? Bye. [ Pause ]

0:00So I've got an idea. In my head, I'm thinking it would be really cool to actually demonstrate how I would go about learning an API for the first time. Ultimately, what I'm thinking I would like to do is something along the lines of using cursor to write a script for me that can authenticate to the Catalyst Center platform and then get a list of devices. Just do something as simple as that.

0:30So if I'm doing this from scratch, I know the first thing I need to do is authenticate. So what I'm gonna do is I'm gonna explore this API with Postman first. So what I think I should do is I should look at this right here and attempt to perform this authentication process. So I'll bring up Postman, I've got a collection right here. I'm gonna add a request and I'm gonna make this a Post request because it tells me right there that that is a Post request. So I've got my request, it's a Post request. I'm gonna rename this to be login or something like this.

1:03And what I have to do now is build the URL. So this is what the URL is gonna look like. We're gonna grab this URL, sandboxdnac.cisco.com and put it right here like this. Then we're gonna do this, we're gonna do forward slash. And then what we're gonna do is we're gonna put DNA system, API V1. Now, how did I know this was gonna be that? Well, I just kind of did because I remember studying the heck out of this thing.

1:35So the DNA API endpoints, you've got your fully qualified domain name, then you're gonna have DNA something API V1. In the login case, we're logging into the system. But usually when we interact with the platform, the holder there is actually intent. When we think about this, we're saying, "Hey, we want these policies to work together with these network devices because it is our intention that groups, that the people in this group should have these levels of access."

2:13So they call it the intent based API. And that's what we're looking at here. So we're logging into the system, but when we actually interact with platform, we're working with the intent based API. So that's gonna scaffold that part of my URL. But now what I have to do is I have to come back to Cisco DNA Center and look at the final endpoint, auth/token. So jumping back to Postman, I'll put auth/token and I'll save my URL here.

2:45Authorization, we can use basic authentication right here. And I'm gonna go ahead and put the username, DevNetUser, and the password, which was Cisco 123 exclamation mark. Now at this point, I could post this in and just see if it works, that would be a great way to explore. And boom, it does. Look, immediately I see that all this really contains is token and then the actual token itself. Just like we did with ACI, isn't it?

3:17So I can build a script right here. I can say something like var, JSON data, equals, and then we gotta get the response and parse out that token item. So here we'll say JSON.parse and grab that response body right there. Now it is telling me it's deprecated, but you know what, this works. I'm gonna say postman.setenvironment variable, we wanna set an environment variable called token, equal to JSON data dot token, just like that.

3:51Wait, hold up that token with a capital T, make sure you get that part right. So we've got, we're gonna set an environment variable called token equal to the JSON data dot token response. So what I do need to make sure is that I actually have an environment for this to go in. So I'll create a new environment, I'll call this DNA 2025. And I can do things like set a variable called token equal to blah, and that'll just be its current value, but we're gonna override it.

4:22So let's do this. Let's send our post requests in. We see we got the response back. If I now look in the environment variable, we're currently holding that token. Awesome. So immediately I understand the authentication workflow, and I have a workflow that I can work with. What I'm gonna do to help cursor learn this is I'm gonna copy this response body into a new cursor project. So let me launch into the correct cursor environment, closing that remote connection.

4:55And we'll go to my network automation section, I'll create a new folder called DNA, even though I know it's catalyst center. I'll create a new file, and we'll call this token response.json, and I'm gonna paste in the token payload like this. That way I can tell cursor, hey, we're gonna log in using these credentials to this endpoint, and the payload is going to look something like the response in this file.

5:25So that's what you can begin scaffolding. I'll do a new file here and say DNAHTTP.py. And I can add both of these to the token response right here. I want to build a script that logs in to Cisco Catalyst Center and holds the token response for subsequent requests. I do not want to use the SDK.

6:03The sample authentication response is provided. The auth credentials are like so. So what I'm gonna do now is I'm gonna grab this URL. You can watch me, this is the first time I'm doing this in cursor. So this is all kind of new to me. You're watching me do what I would do live if I were being tasked with building this on my own. So it looks like this URL, it just wants to use it kind of embedded.

6:35It's not gonna let me unlink that right there. There we go, great, unlink. And then username, devnet, user, password, is Cisco 123 exclamation park. But that is a lowercase I, make sure we get that right. So at this point, it should, in the DNAHTTP file, perform this work. Let's make sure we explicitly say that. I want to build a script in DNAHTTP.py that logs in to Cisco Cattle Center.

7:09It looks good. Let's send it and see what it comes back with. So it's gonna scaffold my credentials and log in and parse the token response format, which you can see it just read that file right there to do that, which is pretty cool. So now it's generating the code in DNAHTTP.py should only take a second or two. Okay, I was wondering what was taking it so long to actually generate this code for me. And this is absolutely hilarious to me of how, if I wasn't sure the machines are listening to me, now I am.

7:43Look, you can see right here, I haven't typed anything into the composer aside from our initial message right here, where I ended with username and password. All I asked it to do, I said I don't want to use an SDK and all I wanted it to do was hold my auth credentials. My intention was to come back and ask it, okay, now I want to get network devices so I could explore the network device API in Postman and see what it does. But it actually took it a step further for me and just did it.

8:14And that's what I'm looking at right here, right there on that line. So what I'm gonna do is I'm gonna accept this to get rid of the syntax highlighting and we're gonna look at what cursor actually did, which I think is actually really fascinating. So when I scroll up, it's not using any SDKs, it's using the request library. For some reason it imported JSON and base64 but never actually used them. It imported time, that way we could actually keep track of the token expiration.

8:46It wanted to suppress the self-signed certificate warning. So we've got these items right here, auth being brought in to use basic authentication and the insecure request warning that we can disable that warning specified right there. These are all things that we've seen and done up now until this point. Now what's interesting to me is it actually built a class for handling authentication and then subsequent methods like getting the list of APIs. So if we look at the authenticate method as part of that class, it establishes a base URL, which we already know DNA system API V1 auth token.

9:27It creates the post request with the basic authentication class, specifying the username and the password and self-signed certificate verification, which in this case, verify is well set to verify. So that's just what it is. So we're actually not gonna worry about the self-signed certificate verification that's coming up here. I have a feeling this might actually blow up. I have a feeling that we actually don't want to verify the self-signed certificate and we'll have to come back and fix that.

9:57We've got the token data that comes back from the response. We then parse that token out right there and set it as a token on the class object. So right now the token is none, but after this line runs right here, it will set that token equal to be the token object coming back from that class. It then starts keeping track of the token expiration time. That way, ultimately, if we try and do something and the token is expired, it will prompt to get a re-expiration.

10:35So look at this class right here, like, or this method like get headers. Immediately, it looks at if the token expiration time is coming, it needs to go and re-authenticate. This will handle re-authentication workflows for us. This is actually pretty advanced. This is something that you would see on the Dev Core exam, not necessarily on the DevNet Associate exam, but it's good that you're seeing it right now of what a expiring token and re-authentication workflow looks like.

11:06So if self.token is none, or the time remaining is still approaching the token expiration, re-authenticate. Then it sets up the headers right here, where we're setting the token header in ex-off token. So we've got get headers, which can return the headers, that includes the most up-to-date token. So when we scroll down here, we look at how to build a get request. This is a generic get request against this endpoint.

11:39In particular, the big thing it does is it uses the get headers method to set the headers. That's the real big thing that it does here, and then returns the JSON response. Same thing with a post request, if you wanna make changes. Again, we pass in data right here to this post request, which then makes its way into the request post request. It sets the headers, sets the data, it even sets JSON data, if we need to convert it to JSON.

12:10So you can pass in data like this as a dictionary or JSON data as JSON string. And it can handle either one of these, which is pretty cool. Scrolling down some more, same thing with a put request, a delete request, we're not really looking at anything here. What they've made essentially is we have the ability to pass in a get request, a post request, a put request, or a delete request to a given URL, to a given endpoint.

12:43So it's got the base URL set, we pass in the endpoint that we want it to do, it gets the headers, and then executes the request that we want. So if you look at it, it does the authentication, prints the token out, then immediately it can run a DNAC, that's our class, get request to this endpoint that you pass in. So if I'm looking at sending in DNA intent, API V1 network device to the get method, if I scroll up to get, it takes that endpoint, passes it right here to the URL, which then gets sent to the get request, which then returns the JSON response.

13:26So scrolling back to the bottom, it'll be able to hold that response in the devices variable. If there are devices, print out how many devices you found. Then for each device in the list of devices, print out that device's host name and management IP address. Pretty cool. So if I actually run the script, let's see what it does. Again, I think it's gonna blow up because of the self-signed certificate, but let's see.

13:57Oh, no, it actually worked, it worked great. Okay, authentication was successful. It printed out the full token. Here are the four network devices that it found, switch one through switch four, illustrated right there. Wow, this AI stuff is pretty incredible if you ask me, the ability to just infer what it was that I was trying to do or give me a sample. All I really had to do was get it started by telling it how to authenticate.

14:28Again, this is the type of thing. You just saw me do this basically live. This is the type of thing that would have taken me, ah, you know, this is a relatively basic request. It would have taken me 20 minutes, 30 minutes, maybe an hour longer than this thing just did right here, but that's time back in my pocket and time is money at the end of the day. And that's gonna be time back in your pocket, time back in your employer's pocket, and more value that you bring to the table when you use these kinds of tools.

15:00So interestingly, this has been how we could leverage something like cursor and quad to scaffold an authenticated request and follow it up with a Git request to get a list of client devices. So now what we're gonna do is look at how using an SDK could of course make this easier.

0:00Now comes the really fun part where we are going to leverage the DNA center SDK . And that is quite literally what it's called. To install it, you fire up your terminal and you give it a PIP 3 install. See, look right here. DNA center SDK. Take a look at that. DNA center SDK. All one word. I press enter here and it installs the DNA center SDK. That is it when it comes to installing the DNA center SDK. Now it's going to tell you a lot of these things are required or it's going to fail, but it actually does successfully install the DNA center SDK and some of the tooling that is required in order to use it.

0:40Don't freak out if you see a lot of red text on here. There's a good chance it's still going to work. So what I'm now going to do is I'm going to fire up cursor. And again, you can just let cursor build these things for you. You really should. That's what you would do in the real world. So I'm going to, first of all, clear out all of the work that I've done and open up a new composer chat right here. And I'm going to create a new file and we'll call this DNA SDK dot py.

1:13And I'll say from DNA C SDK. Hmm. Wait a minute. That doesn't seem right. In fact, my environment sees DNA center SDK. So how do I know which one's right? Is my environment right suggesting DNA center SDK or is cursor right suggesting DNA C underscore SDK. It's only one way to find out.

1:44And that's in the documentation itself. Let's fire up the documentation. I've gone to DNA center SDK dot read the docs.io. And from here, I've jumped on a quick start and get your DNA center access token. What I'm really looking to do is scroll down here and look at my first lines from DNA center SDK, import DNA center API. So that's what I'm going to do. I'm going to copy this documentation right here and paste it in.

2:16This is using a DNA center class object, very similar to the one that cursor cleverly built for me in the previous skill where we've got we declared our own class called catalyst center API and it built its own methods. The fact of the matter is the SDK already did that for us. All right, they've already specified all of these things. So if I really want to, I can tell cursor here specifically use the DNA center SDK with the DNA center API class to build out our request.

2:56Use the DNA center SDK library to import DNA center API class object. Get authenticated to the catalyst center devnet sandbox and get a list of devices, then print them to the terminal press center.

3:26So when it comes up, it's going to list all of these things out. It actually does browse through our directory to find the credentials we used in our last skill. It does things like that to learn about what's going on in our environment like reading DNA HTTP dot py. And then, oh, well, look, it's creating its own file right now. Get devices dot py. Interesting. Okay. Well, you do you then, I guess I wanted you to use this file. But if it wants to use its own file, that's fine.

3:59And we'll take a look at what it comes up with. They want me to run this command right here, but I'd rather look at the code and see what it's doing first. So I'll accept this file to look at what it's doing. Yes, it is using DNA center SDK and the DNA center API. It declared variables for the base URL, the username and the password. When I scroll down here, look at what it does. It instantiates the class by giving it the username password base URL and setting self signed certificate verification of false.

4:35Now this doesn't log you in. Does it? Well, hold up. Actually, it does. That's one of the more interesting things about the DNA center SDK is that when you instantiate this class object, you are logged in. This stands in direct contrast to ACI, doesn't it? When I look at ACI, just flipping back to the ACI script for a second, we instantiated the session object, but it didn't do anything until we explicitly told it to log in . Then from there, we could use our session object to do things.

5:09We would say something like tenant pushed to APIC using this session. DNA center SDK kind of goes in the opposite direction. We establish a, this one right here. We establish a connection to DNA center. Then we use that object to make changes or query any of the things that are going on. So it's interesting if I'm looking at the script that we just made and I'm looking at authentication right here from 38 down to really the get header section all the way down to 86.

5:46That's what? 50. 48 lines of code right there. If my math is right, 48 lines of code, just got really summed up into basically one line. They just put this on multiple lines because it's pretty, cursor did, but this could all go on one line to establish a connection to DNA center. Then when I want to get a list of devices, that's just one line two. We can take our established connection held in this API variable, go into the devices class and then run the get device list method.

6:23If you want to explore the other things you can do, do API dot and then just beginning going down. Things like clients are here. We've got devices that are here. Scroll up a little bit. Applications are here. So if I wanted to look at clients, I could do dot, then just type get. We can do get client details, get enrichment details, overall client health is a method that you could run. Probably a good idea to run that.

6:54And that's the types of things that you can do with an SDK. And again, the documentation here, that's really going to be your friend. You can look at the quick start of what types of things that you can do, but there's a lot of stuff that you could dig into when it comes to actually using this SDK. The documentation definitely going to be your friend. So when I want to look at this, it gets the list of devices. It prints how many devices that it found. And then it prints things like device name type, management IP, platform, serial number, software version, uptime status.

7:30And then of course, just some closing lines to make it look pretty. So if I want to run this, let's go ahead and just do start debugging. Python, look at the code down here, connecting successfully connected. Look at those devices right there. Just as simple as that. This is understanding the DNA center, aka catalyst center platforms and capabilities, the things that it really can do and bring to the table. And now it exposes a northbound API to us where we can actually use an SDK to very quickly establish a connection and then perform all sorts of important operations, getting lists of devices, getting lists of applications, getting lists of clients.

8:17Those are definitely the things that you will want to know about going into the DevNet associate exam. I hope this has been informative for you and I'd like to thank you for viewing.

0:00So I'm gonna be honest with you this one is a border line unfair one But it's not a question that I came up with it's actually from the exam blueprint It's I'm laughing because you'll see why if you haven't already seen why in 3.9.c the challenges obtain a list of clients Seen on a network Using Cisco DNA center that that you are here and that's what you're supposed to do So you're like great. There's a few different ways that I could know how to do that The first thing I'm gonna do this is where my head goes is I'm gonna explore The actual API Documentation on the platform and I know right here under know your network.

0:44There is a client section So I go to the client section and I only see Four methods here that I could actually call to get this and none of them are get a list of clients There's get a list of client health and that would tell me like how all of my wireless clients are doing and then how all of my Wired clients are doing there's client Proximity which is really only for wireless users. It's not the full list There's enrichment details, which is if I know someone's user ID or MAC address I could get more details about them and their policies or if I just know their MAC address I could do get client detail but nowhere in this API doesn't say anything about getting the list of clients So immediately my head goes to okay. I wonder if it's buried in the SDK somewhere so I jumped back to my SDK and If I'm looking here, I can just go tab over API Dot clients dot and then I'm gonna do get No, it's the exact same API endpoints that it said before overall client health Client details and client enrichment details, but none of these are actually get a list of clients

2:00So where does one go to get a list of clients? Well the unfair part about this is there is an API endpoint that can actually give you the list of clients It is just not documented or published anywhere from a Cisco official documentation You would have to Google this and go down rabbit holes like I did to find how to actually do this and where you'll actually end up is on github.com slash Cisco devnet slash dna c hyphen assurance and in there there is a script called all clients dot py and From there you can actually see the function that they define called git hosts Where you can say raw wired or wireless or basically all of them if you want raw?

2:53And you can see the URL that it targets ah This isn't an intent-based configuration at all. This comes from the assurance platform So if we wanted to get the list of clients We would have to go to assurance to get it and hilariously. That's not documented anywhere beyond that notice that it requires a payload And that payload requires a start time and an end time So this way we're saying give me a list of clients that existed on a network Between this time, but even more you can see even trickier than that This happens using epoch Time what is epoch time?

3:35Sometimes also known as Unix time This is basically counting the number of seconds or milliseconds Starting from I for honestly I forget the exact date I want to say it's like something like either 1980 or 1900 or something like that. There's a specific date and time that it begins counting from and it counts one second all the way to the present So if you counted one second starting at this date from 40 or 50 or 100 years ago What to the exact moment that we're in right now just looks like a gigantic number and that's how we denote What the start time and the end time is for this now the interesting thing about this is you don't actually have to give it Specific times you just have to provide a payload with it So ultimately if I want to test this if I want to explore this I'm going to start with postman and if I jump over to postman. I'm going to log in Now I've got a token set in my environment, right?

4:39And then I can build my request to get this information now notice the next thing Right here on this line. This is a post request to this URL with this data payload So if I'm building my request, I'm building a post request To the URL that's API assurance v1 host I'm specifying my exoth token header and My body includes this start time and in time, but I'm leaving it blank So it just returns to me whatever data it finds when I send this in Boom, let me go full screen here if I can go full screen if it'll let me go full screen Look at let me drag this up You can see now the responses for all of our health objects we see Mac addresses IPV6 addresses Connected devices what devices are connected in it? What's their ID?

5:40What's the name of this device that switch for and so on so you can see there's a device connected to switch for right now So ultimately if you needed to get a list of devices From Cisco DNA Center. There is not a clean and easy way to do it It's not baked into the platform API or the intent API at all It's not documented at all, but it does exist It just comes from the assurance API and with a lot of Googling and digging you too can find these answers out there If you didn't don't worry don't feel frustrated Don't feel defeated. This is definitely This is definitely a tricky one. All right. This is definitely a doozy. So that 's the end of our challenge today