So that last Nugget was pretty cool, right?
Troubleshooting client health is pretty awesome.
We can actually narrow down specific events
to an exact client or user name that was
used to log into our network.
But that showed us what's going on
with maybe a specific client.
It didn't really tell us what could
be happening with our network.
So now what we're going to do is we're
going to look at a different dashboard in assurance
where we can monitor either the network's health or our named
applications that we have running within our network.
So let's jump back into the dCloud environment WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So let's jump back into the dCloud environment
and explore the network and application health dashboard.
So jumping back into dCloud, I'm going
to hop over to the assurance workflow again.
We're greeted with the same overall health section
that we were looking at before.
We did explore a lot of client issues in the client dashboard.
Now it's time to take a look at the other dashboards.
You see there's a dropdown here, and we've
got, well, a lot of dashboards.
So from the health section, we're
ready to now jump into the network health.
Let's go into network health.
And now we can see our overall score
for the network over time. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
for the network over time.
Just like before, you need to focus in on,
what is the time range that we're looking at first?
You need to know what we're looking at.
Right here, during this time range,
it's showing that 84% of our clients
were healthy, which, to me, means 16% of them are not.
If I scroll down just a hair, we can
see how many devices we have--
97-- how many of them are unhealthy, and how many of them
are unmonitored-- none of them.
Then we can look at, basically, a filtering
of what kind of devices and where they fit
in our enterprise architecture. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
in our enterprise architecture.
So we have routers.
We have the core switching layer, the distribution layer,
the access layer, our wireless controller,
and then the APs themself.
The distribution layer does have the biggest red section,
but it contains 10 devices, whereas the access
layer has 32 devices.
If I clear the screen, I can also click on view details
here, and it can tell us to select an element
to dig into what's going on here.
So if I click on distribution, I can scroll down
and I can see what my distribution layer devices WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and I can see what my distribution layer devices
consist of--
9300s and 3850s.
And if I scroll down further, we can
take a look at the individual devices themselves
and their overall health.
Just like before, I can also look
at a trend of what each of these device categories
look like over time.
So what I would be looking for here
is, say, something in the red that has a spike up.
That would tell me an event occurred
that took down a large chunk of, say, my wireless controller.
Let's jump out of this for a moment
and explore what goes on further in the networking dashboard. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and explore what goes on further in the networking dashboard.
I can look at a count of why some APs are up and down.
I can look at my APs that have the highest client count here.
And I can look at some APs' specific interface statistics.
Again, remember that these devices are all streaming
counters into DNA Center.
Then I can scroll down further and take a look
at each one of my network devices,
and it's, by default, sorted by their overall health.
So AP4800, that was the one above, I think,
that was having some decent issues.
It looks like it's got an overall health score of 1. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It looks like it's got an overall health score of 1.
And simply by just hovering over that health score,
I can see things like, well, memory utilization
and CPU's not bad, but it looks like just the overall air
quality and noise in that area is really dragging it down.
So just by hovering over that, I get a pretty good snapshot
of why that device health was given.
The same thing can be given for, say, the switches here.
Well, these counters here don't look very good to me,
and I'm also seeing some issues going on in the data plane.
We've got some link errors, so maybe I want to dig into that. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We've got some link errors, so maybe I want to dig into that.
What's going on with this device?
I'll give it a click.
And just like before when we had the user 360, now
I've got the Device 360.
And immediately, my eye is drawn to this right here.
What happened in that time frame?
So what I may want to do, just to filter out
the results that are sent here, I
may want to keep this like this.
I'll just drag my time frames below
to focus on just the red sections here.
I can see that this issue happened right around 4:30 AM
and ran until roughly 7:00 or 7:30 AM. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and ran until roughly 7:00 or 7:30 AM.
And when I hover over these red bars,
it pops out and gives me more details
again like what's happening with utilization and data plane.
Jumping down further, I can see my issue list here.
I've got a flapping interface gig 1/1,
and I'm not synchronized with NTP.
Well, those, particularly NTP instance,
that could be a big deal.
I see there have been 65 instances where it's not
able to communicate to the NTP server,
and it also makes me wonder if that has something to do
with the flapping interface. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
with the flapping interface.
If the interface goes down, is that why we
can't talk to the NTP server?
So I can dig into these actions right here.
And isn't this great?
The suggested actions, again, shows me things like verify
that the port is error-free.
Well, if I click this down here, I can click run.
And I get some green check marks, but look at this.
Isn't this cool?
It runs the commands and then spits out the output.
So for each of these, I can run these and verify
the output that's given here.
And maybe this will tell me something WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And maybe this will tell me something
about what's going on with this particular port.
Beyond that, I can scroll down and take a look
at what's going on with my physical neighbor topology.
So here's my device here.
I can look at the downstream switches as well as
the upstream switches.
We can even click on them to look at the actual devices
themselves.
So hmm, OK, well, there's a health score problem here
on my Catalyst 9404 device.
I can look at all of the events that have occurred here.
Again, this is all narrowed down to what happened in the time
frame that I specified above. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
frame that I specified above.
And then, just like before, we could run a path trace.
This would be a great way to validate that our network
device was trying to reach the NTP server or the path
that it was trying to take to reach it.
Now, we know that this device is having some particular issues
with the interfaces themselves.
So if I scroll down, I can look at, say,
the device statistics-- this would be things like the CPU--
or I can click on the interfaces tab
and I can look at each of the interfaces.
My operational status right now is showing that it's down.
I can see things like this is a routed interface. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I can see things like this is a routed interface.
It's set to only 100 megabits per second.
If it were part of a aggregated port,
there's the port channel ID.
And I can scroll down.
And I do see it says that there are three other interfaces that
are down, so I can scroll down and I
can identify which of those devices are down as well.
So using assurance, we can not only
troubleshoot what's going on with our users,
we can also troubleshoot what's going on with our network
topology and our network devices themselves
and figure out exactly what's going on with our SD-Access
fabric very simply from one beautiful front-end GUI. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
fabric very simply from one beautiful front-end GUI.
So that's been troubleshooting a DNA Center environment.
I hope this has been informative for you,
and I'd like to thank you for viewing.