Alright, so why is protocol analysis important?
Well specifically, once we start getting into
more detailed, you know, learning environments
and or production networks,
you're going to use Wireshark to
to capture the data and
start looking within it and finding anomalies
and troubleshooting problems.
So, why are these things relevant?
So, specifically when you're,
when you're capturing the data,
you may find some specific stuff
in there that will give you a clue.
This is where you may
not know anything about the problem
and you're trying to figure it out
completely from scratch or
you may know some hints such as
collecting the information from the clients
and or the administrative staff
or the help desk in trying to do some
preliminary analysis of what
the problem may be.
So, it's a recommendation
that when you're called in to use Wireshark
you put on the detective hat
and you take a complete report
on everything that you can before you even
light Wireshark up and start capturing data.
For example, it's been in the past,
I've seen where desk support or field
services teams are very savvy in what they do.
They're masterful at knowing
the client work station
and some of these tools like Wireshark
and they've already ran and
captured some data for you.
Sometimes, they can give you the data
and it might be your baseline
that you were looking for to know
how this machine operates normally.
When I say, machine, I should drill down on that
how when it's using the network-used
resources, what that view looks like normally.
And let's say, from if it's a 24 by 7 operation
normally all the time, or within
normal production operating hours.
So, that is the first thing that we want to do
is start looking around this and saying
if we're going to start doing this from analysis
where - what's already been captured,
what's already been done?
And what's kind of the problem?
What has been reported and is that actually
something that we can use
Wireshark to troubleshoot?
So as an example,
let's say, you have a problem where
a data base server is, is operating horribly.
And it's causing clients
to have application issues.
So, a lot of times what we'll do is
we, we go to the client machine.
And we may see, well, the internet works great,
their email looks fine.
And we've isolated it to this application.
So what we want to do is we want to
specifically look down that path, so
you know, you want to run a general capture,
you want to look at things, you know,
you know, everything very quickly.
But you want to say,
"Alright, I want to do some detective work
and I want to start streamlining
my troubleshooting path down into
specifically what is wrong with this application."
Now, you don't know
to deal with this problem yet.
We will find that out.
But you know, at least specifically,
it's this application.
Alright, so let's drill down a little bit further.
Let's say, you're troubleshooting
the application and you find that
everything works pretty well
except for when they log in.
That's the problem, very slow log in.
Or they're using an application
and one of the modules or components
within the application is problematic.
The reason why we mention this
before getting deep, deep, deep
into Wireshark and how it works is because
that's the whole key to using Wireshark.
The key to using wireshark is
to figure out specifically what
it is you that you want to drill down to.
Otherwise, you're just collecting
data and sifting through it.
You can do that, too,
but to be masterful with it, you want to
really, really try to put the detective
hat on and try to figure out a few things first.
You want to figure out things I had,
like I had just mentioned.
Is it specific to an application?
Now, alright, so let's say you don't know
to drill into the components of the application
and maybe you didn't know that
you would drill down to the log
and is being an issue, but
you at least knew that it was
that application and why is that important.
Well, the destination from the source, maybe
that application server, and that
maybe an end to your application.
We have 3 tiers, you have
the application front end which is on a
load balanced webservers.
It may have a middleware tier,
where a lot of, you know, cam components
flowing around and it may have a database tier.
Each one of those tiers may be
firewalled in ACL.
So it's very important that when you
you're doing analysis work. You're not
just looking at it from the client,
and you're just running a capture
because the client said that they had
bad performance but they actually
kind of drilled down more
into what traffic you're going to try to filter.
Yes, we will learn how to build filters.
Yes, we will learn how to
drill down to the traffic.
Look for specific ports,
Look for specific time to live,
specific offsets, specific everything.
But if you have to understand
what application is the problem,
maybe that gives you a clue as to what
protocol you need to start drilling down into.
And again from earlier, you may want to
do the other checks as well.
Send some data downstream,
via ping or traceroute, maybe something is slow.
That may not be the problem with log in
but it may be the problem where it's the
overall application itself has bad performance.
If all the applications have bad performance,
what does that mean?
So again, just in sum, analyzing 101 is not
just lighting up Wireshark, capturing data,
and go, it's let's look at everything.
Let's look, let's put on the detective hat
and look at everything that we can.
So, what does this mean when we,
when we do this and
we try this now and start drilling down.
So, let's say you have a problem where
a specific device wasn't registering correctly with
the network monitoring tool.
What could that be? Alright, well, we knew
enough to say,
I am going to start capturing data
to show SNMP traffic from source to destination
and specifically, what, what is going on at that
at that capture point.
What is happening here?
So a couple of things that we found
is we found the string and in this
particular incident, we were finding that
there were some data, some hosts
that weren't configured correctly via SNMP.
And there was an access control list cofigured,
so, certain things weren't happening.
And we were able to figure that out
with Wireshark. But again,
what's important to remember is that
we wouldn't have known to look for that,
filter down to that, drill down to that
and look for those specific things without
understanding one, the network and
the fundamentals of it,
two, the protocol - what's being used,
three, doing some detective work
around all these to figure out
that my problem is not email,
it wasn't web browsing and a
you know, it wasn't accessing a file share.
It was specifically, this device
connecting from one to the other
and trying to communicate the SNMP.
This is why it's important to remember
that specifically, you want to have
a lot of knowledge behind you
when you're troubleshooting.
Alright, so next,
when you're doing protocol analysis,
you're capturing data to and from source
to destination, sources to destinations,
or through hops, you're going to
it's going to reveal some specific things.
Just to recap, you may have
some bandwidth issues,
data may be corrupted.
In a, things may be configured incorrectly.
You may have some in, latency issues.
The client itself, or the destination
may have some I/O issues.
The database need, may need to be re-indexed.
There may be an asynchronous route.
The firewall may be blocking it.
There may be some proxy server
issue where it's not allowed,
allowing something and it's
manifesting as a different issue.
You may have a routing issue.
You may have a storm-causing performance.
So just remember, when you're doing analysis
this data captured is going to reveal,
reveal what those issues are but you may need
to really figure out and drill down to
essentially what it is you're looking for.
Which again, forces you, and I,
and I wholeheartedly say, forces you
because if you really want to learn and
dig deep into this tool,
you're going to have to really start looking
at how does TCP operate particularly.
Most, if not all of you, may know the handshake.
We'll cover it in a later module for those
that may not know it, but that is
going to be the predominant thing
that when we do a flow graph,
when we pull flow graph to Wireshark,
those are the things that
you're going to need to look for.
You're going to need to see, ok well,
I've had duplicate ACK's.
So what does that mean?
What is an ACK, right?
So those are the things that
will require you to dig deeper
into understanding the protocols. And again,
the different layers of the OSI model.
So, we're just going to briefly talk about
some of the analysis tools.
One of the key things with analysis tools
is that there are many tools
within Wireshark itself.
Wireshark itself has analysis tools within it.
There are analysis tools outside of Wireshark.
There are analysis tools that are handheld
that you can plug in to your network.
There's analysis tools that are
enterprise-wide that require probes
and all the types of devices.
Whatever those devices are, just remember
these tools are, are simply for the form
to help you analyze
what a potential problem can be.
And the reason I put the Expert up here,
which is a tool within Wireshark
and we will have a whole module
dedicated directly to it.
This tool will give you some specific
information, but it will not in particularly
tell you exactly what the problem is,
and, and that's, that's been a concern
for many in the past is
will this really tell me what the problem is.
When I install Wireshark,
well, it'll immediately say -bing-bing-bing.
Here's the problem, you need to do this,
you need to do that. No.
And that's why to start off this
foundation's course, I really wanted to drill
into and get, get some awareness around
the fundamentals of how these tools
are really used and what, what information
you will need to be successful with it.
This tool is going to tell you that a
retransmission is suspected,
and if you really think about it,
what does that really mean to you?
And worst, it's telling you it's suspected, so
that's what the Expert and
other analysis tools do.
They allow you to view things and
do some deeper diving into them.
So what will we find?
We're going to do some deep packet inspection.
We're going to review the data packets.
We're going to look at timestamps.
We're going to look at communications patterns.
We're going to look at a whole bunch of stuff
in the next 2 days, 2 to 3 days,
and really dig deep into this data
and start seeing some specific stuff.
And that should be interesting
to everybody, and exciting.
Because a lot of times, you get
really good at configuring devices,
you get really good at designing devices,
but what's really good is when you know
how to solve problems with them.
Because what we will find is, and, and I
I've seen this many times in the past.
We spend a lot of time, put a lot of effort
into designing a perfect network,
or augmenting it perfectly.
We spend a ton of time looking to engineer
the best solution, the most secure,
the most flexible, one with the most a
and a bandwidth, and one that's
to deliver optimal results.
And you know what winds up happening,
this is what we've seen.
Networks are augmented
and a lot of times the staff turns over
and new people come in.
Maybe it wasn't documented well.
Mistakes are made. And this is no fault
to anybody. This is just how we live our lives
in an enterprise networking world.
Things change. New solutions are put in place.
Sometimes they don't the time to lab them up
correctly or staff with a, they don't have the exact
skill sets needed but they give it the best try.
Sometimes things just go in.
You have other groups.
So, their servers are getting added.
Maybe they didn't turn things off like, you know.
Zero config on printers and
and what ends up happening is
there's just so much stuff in a big network
that the more we lab up, and the more
we learn about the design-build-run
and the more that we learn about Wireshark
and how to troubleshoot and dig
deep into the networks,
the better off we will be to solve problems.
And that is the key to solve issues.
The fire alarm goes off, things are broken,
the application's down.
It's a critical application. People are panicking.
And you come in, very calm, cool and
collected and you strategize
the exact way to solve or fix this issue
and that's what we're striving for.