-: Network troubleshooting methodology. 2 2
In this lesson, we're going to discuss 3 3
the official CompTIA Network troubleshooting methodology. 4 4
This is the first thing that we need to cover 5 5
in this overall section, 6 6
on troubleshooting physical networks. 7 7
Now we're going to cover domain five network troubleshooting, 8 8
specifically objectives, 5.1 and 5.2 in this section. 9 9
Objective 5.1 states that you must explain 10 10
the network troubleshooting methodology, 11 11
which we're going to fully cover in this lesson. 12 12
Then in this section, we're going to move through 13 13
and talk about objective 5.2, 14 14
which states that given a scenario, 15 15
you must troubleshoot common cable connectivity issues 16 16
and select the appropriate tools. 17 17
We're going to spend the rest of this section 18 18
focused on that objective, but for now, 19 19
let's focus our attention 20 20
on the network troubleshooting methodology. 21 21
After all, much of your day as a network technician 22 22
is going to be spent entering trouble tickets 23 23
or fixing problems that are found inside of your networks. 24 24
To help us with this, we have a seven-step 25 25
troubleshooting methodology that we can use 26 26
to solve any problem inside of our network. 27 27
There are seven steps here, 28 28
the first is to identify the problem. 29 29
Second, establish a theory of probable cause. 30 30
Third, test the theory to determine the cause. 31 31
Fourth, establish a plan of action to resolve the problem 32 32
and identify potential effects. 33 33
Fifth, implement the solution or escalate as necessary, 34 34
sixth, verify full system functionality and if applicable, 35 35
implement preventative measures, 36 36
and seventh, document findings, actions, outcomes, 37 37
and lessons learned. 38 38
All right, let's take a look at each of these seven steps 39 39
in a little bit more depth. 40 40
Step one, identify the problem. 41 41
This is our first step in the troubleshooting process, 42 42
and it's used to clearly understand what the issue is 43 43
that you're trying to solve. 44 44
This problem may have been reported to you by an end user, 45 45
an administrator or through some automated alert. 46 46
It really doesn't matter, 47 47
whatever the original report method used, 48 48
your goal now is to get more information 49 49
so you can fully understand that issue 50 50
that you're trying to solve and get things back to normal. 51 51
As we attempt to identify the problem, 52 52
we have to gather additional information, 53 53
question our users, to gather more details, 54 54
identify symptoms of the issue and determine 55 55
if anything has changed. 56 56
Then we're going to try to duplicate or reproduce 57 57
the problem if possible, sometimes though, 58 58
you may have multiple problems occurring at the same time. 59 59
And if this is the case, you should approach 60 60
each of those problems individually 61 61
and not bundle them together as a single problem 62 62
or shared problem, unless you figure out 63 63
that they are clearly linked, 64 64
because sometimes they're not clearly linked. 65 65
All right, let's take a look at what this might look like 66 66
in the real world. 67 67
Let's pretend you're sitting at the service desk 68 68
and an end user calls up and states, 69 69
"The internet is down, the internet is down. 70 70
"I can't do anything right now, I need your help." 71 71
Well, what are you going to do? 72 72
As a network technician, you probably know 73 73
the internet is not down completely, 74 74
but it's really just a problem with a user's connection 75 75
to the internet that may be slow, unresponsive, 76 76
or simply not connected. 77 77
But maybe the user was trying to open Facebook 78 78
and they got an error message and told them 79 79
there is no internet connection, 80 80
so to them, the internet is down, but we all know 81 81
the internet is made up of millions of different 82 82
computer networks, and the chances of the entire internet 83 83
being down is pretty darn slim. 84 84
So what are you going to do about this? 85 85
Well, first you should ask some additional questions 86 86
to the user, let's ask them things like, 87 87
what were you doing at the time of the error, 88 88
or what websites are you trying to access? 89 89
As you ask them questions, you might also ask 90 90
what type of connection they have. 91 91
Are they using a wired connection, wifi, cellular 92 92
or something else entirely. 93 93
As you ask more questions, you're gaining more information 94 94
and this can help you identify the symptoms 95 95
and determine if anything has changed. 96 96
For example, you might ask, when was the last time 97 97
you connected to that website? 98 98
And if their answer was an hour ago, then you should ask, 99 99
did you install, remove any programs since then, 100 100
or has anything changed in the last hour? 101 101
As you gather more information, it's going to help you 102 102
figure out what's going on. 103 103
All of this falls under that first step 104 104
of identifying the problem. 105 105
Step two is to establish a theory of probable cause. 106 106
This is the second step in our troubleshooting process, 107 107
and it's used to come up with a possible solution 108 108
to the problem you clearly identified back in step one. 109 109
When we establish a theory of probable cause, 110 110
we need to question the obvious first, for example, 111 111
if the end user said they normally connect to the internet, 112 112
using a wifi connection on their laptop, you may want to check 113 113
that they haven't turned off the wifi card, 114 114
using the toggle switch on that laptop by accident. 115 115
If they did, then of course the internet is going to be down 116 116
because they've turned off all wireless capability 117 117
on that laptop at the physical layer of the OSI model. 118 118
Also, when you're establishing your theory of probable cause 119 119
you should use multiple approaches to solving the issue. 120 120
This could be a top-to-bottom approach, 121 121
a bottom-to-top approach or a divide and conquer approach. 122 122
A top-to-bottom approach relies on troubleshooting 123 123
from layer seven of the OSI model down to layer one. 124 124
So we start the application layer and we work our way down. 125 125
A bottom-to-top approach, instead relies 126 126
on troubleshooting from layer one of the OSI model 127 127
up to layer seven of the OSI model. 128 128
Here we start at the physical layer by checking our cables 129 129
and wireless radio-frequency connections 130 130
and then we work our way up to layer two, switching, 131 131
layer three, routing, and continue all the way up 132 132
through four, five, six, until we get to seven 133 133
at the application layer. 134 134
Now the divide and conquer approach is used when we split 135 135
the network or the layers of the OSI model in half 136 136
and troubleshoot from there. 137 137
Early in my career, I used to work 138 138
as a nuclear reactor operator, 139 139
and when I was troubleshooting electrical circuits, 140 140
we often used this divide and conquer approach. 141 141
We called it half-splitting, 142 142
but it's essentially the same concept. 143 143
Essentially, we would figure out what the halfway point was 144 144
in the electrical circuit, and then we tested 145 145
the connection there. 146 146
If it worked, it meant the first half of the circuit 147 147
was good and I didn't have to look at the first half anymore 148 148
because everything was working properly. 149 149
Then I could focus on the second half. 150 150
Now I could half-split again between the halfway point 151 151
and the end and I could troubleshoot again 152 152
until I found where the problem was. 153 153
We kept doing this over and over until we found the error 154 154
and it really was a quick way to figure things out. 155 155
Now, we can do the exact same thing in our networks. 156 156
If I'm trying to troubleshoot the internet is down issue 157 157
for this end user, I could figure out 158 158
what the halfway point is between their computer 159 159
and the internet, which would probably be 160 160
our default gateway. 161 161
I could then try to send a ping from the end-user's computer 162 162
to the default gateway. 163 163
If it works, that means my internal network 164 164
is functioning fully, and the problem exists 165 165
between my default gateway and the internet connection 166 166
or the distant web server. 167 167
Now, this is my halfway point and with a single ping, 168 168
I already verified the entire internal network is working 169 169
from the end user, all the way up to the gateway. 170 170
This is my divide and conquer approach at work, 171 171
also known as half-splitting if you use my terminology. 172 172
Now at this point in step two, we're just coming up 173 173
with a theory of what might be going wrong, 174 174
such as I think the default router is down 175 175
and preventing the end user from accessing the internet, 176 176
but we're not trying to solve it yet, 177 177
that will come in step three. 178 178
So step three is test the theory to determine the cause. 179 179
So now we've looked at the problem in step two 180 180
and we've created our theory, we need to actually test 181 181
that theory here in step three. 182 182
This is where we actually begin to take some actions 183 183
such as pinging the default gateway 184 184
from the end user's workstation or checking 185 185
network configuration on a particular router, 186 186
switch or firewall. 187 187
If the theory is confirmed, then we're going to determine 188 188
what our next steps are going to be 189 189
to solve the bigger issue. 190 190
If the theory remains unconfirmed, 191 191
then we're going to have to reestablish a new theory 192 192
or escalate the issue to a higher tier 193 193
or more senior technician, 194 194
who may have additional privileges or more knowledge 195 195
on how to fix this issue. 196 196
Step four, we're going to establish a plan of action 197 197
to resolve the problem and identify the potential effects. 198 198
At this point, we now want to build out a plan of action 199 199
to resolve this issue. 200 200
Let's go back to our internet is down issue. 201 201
We found that the default router was causing the issue, 202 202
we pinged it, and in step three, we found that traffic 203 203
was not getting out of the network 204 204
and going past this default router. 205 205
Now we can log into that modem from the ISP and verify 206 206
it had a good connection to the internet, 207 207
so we know the issue is definitely something 208 208
to do with the router. 209 209
Some reason that router is not passing traffic 210 210
to the internet, but the modem and the connection is up. 211 211
So we're going to look at that router, and we find out 212 212
that the CPU utilization is between 90% and 100%. 213 213
We now have a theory that if we reboot the router, 214 214
we could clear this high CPU utilization and the traffic 215 215
would again, start to flow through this router. 216 216
Now, as you establish your plan of action here in step four, 217 217
to reboot this router, we also need to identify 218 218
the potential effects. 219 219
This is an enterprise level router, 220 220
so it'll take at least 10 to 15 minutes to reboot it. 221 221
During that time, traffic will be unable to be routed 222 222
through this router from the internal network 223 223
to the internet. 224 224
Now, that's not really a big deal here 225 225
because the internet was down, right? 226 226
And so all of our users can't access the internet anyway, 227 227
because the router's not passing traffic to it. 228 228
But this router may also be used to pass traffic 229 229
to, and from your DMZ, your data center 230 230
and other client villains. 231 231
So during that reboot, the entire network, 232 232
internal and external, will be essentially down. 233 233
Now you need to weigh this potential effect 234 234
with the action you want to take. 235 235
And in most cases, you're going to have to get approval 236 236
from your supervisors or the IT director 237 237
to reboot this router, to solve the internet issue, 238 238
even though in the next 10 to 15 minutes, 239 239
you're going to cause a network wide outage 240 240
by rebooting this router. 241 241
All right, next step five, implement the solution 242 242
or escalate as necessary. 243 243
At this point, we've briefed our plan 244 244
and we've gotten permission, 245 245
now we're going to implement the solution. 246 246
In our example, that would be rebooting the gateway router. 247 247
Now, if you don't have administrative rights to do this, 248 248
or the solution is beyond the scope of your abilities, 249 249
you may escalate this to the next higher level technicians 250 250
to deal with this problem. 251 251
For example, you may be a level one network technician, 252 252
and you simply don't have the proper permissions 253 253
to reboot this enterprise grade router, 254 254
or maybe the router was completely dead 255 255
and need to be replaced, so you need a level two 256 256
or level three engineer to put a new router in the rack, 257 257
cable it up, load up the baseline configurations 258 258
and get it working again. 259 259
This would require an escalation of this problem 260 260
to get it solved by these level two 261 261
or level three technicians. 262 262
All right, next step six, verify full system functionality 263 263
and if applicable, implement preventative measures. 264 264
Now, the solution has been implemented here either by you 265 265
or the higher level technicians, now, we need to verify 266 266
it actually solved the initial problem. 267 267
So maybe we rebooted the router and then we try to connect 268 268
to the website again from the end-user's computer. 269 269
Did it work? 270 270
If so, great, we've solved the issue. 271 271
If not, we need to return to establishing a new theory 272 272
and then we're going to go through the whole troubleshooting 273 273
process again, to figure out how to solve it. 274 274
Again, if there was some kind of cause or outage 275 275
to this problem, we also want to implement 276 276
preventative measures to prevent it from happening again. 277 277
For example, maybe this router was having 278 278
this excessively high CPU utilization 279 279
because there was a routing loop. 280 280
If this is the case, we need to go in 281 281
and change the configurations to prevent a routing loop 282 282
from occurring again in the future. 283 283
Also, we may need to go back and train 284 284
our network administrators who have caused that routing loop 285 285
so we can show them how to avoid them in the future. 286 286
This is all considered methods to prevent a recurrence 287 287
of this particular issue. 288 288
Finally, step seven, document findings, actions, 289 289
outcomes, and lessons learned. 290 290
Now that the crisis is behind us and the problem is solved, 291 291
we want to document what went wrong and what we did about it 292 292
and what those results were, and anything else 293 293
that we learned so we can share this with others, 294 294
so this problem doesn't happen again. 295 295
All right, I know this was a lot of steps, 296 296
but if you're using the standard network 297 297
troubleshooting methodology, it will really help you 298 298
to ensure you're thinking through all the possible issues, 299 299
developing a theory, creating a plan of action 300 300
and implementing it to successfully solve 301 301
challenging issues when you're in the field. 302 302
For the exam, you need to memorize these seven steps 303 303
in the order that they're listed, 304 304
it would be very fair for CompTIA to ask you on test day, 305 305
what these seven steps are, and they can place them 306 306
in a random order and ask you to drag and drop them 307 307
into the right order for those seven steps. 308 308
Or you can get a question that says, 309 309
you're troubleshooting a network issue, 310 310
and you just establish a theory of probable cause, 311 311
what is your next step? 312 312
And you'd have to say, 313 313
test the theory to determine the cause. 314 314
Now remember, these seven steps of network troubleshooting 315 315
are the methodology that we're going to use 316 316
and you have to memorize them. 317 317
One, identify the problem, two, establish a theory 318 318
of probable cause, three, test the theory 319 319
to determine the cause, four, establish a plan of action 320 320
to resolve the problem and identify potential effects. 321 321
Five, implement the solution or escalate as necessary, 322 322
six, verify full system functionality, 323 323
and if applicable implement preventative measures 324 324
and seven, document findings, actions, 325 325
outcomes, and lessons learned. 326 326
(upbeat music)