Ok, in our next module, we will talk about analyzing data transfer
which is probably one of the common things that you'll do on a network.
Obviously, if you do anything on a network, you're using it to access resources of some kind.
Normally, people do not just set-up networks for show.
Their primary purpose is to give you access to resources.
And it's our job as engineers and analysts and experts,
to be able to go in and answer the tough questions as to why is my data
or my access to my application, or my querying of my database -
why is it problematic?
Why did I just spend a tremendous amount of money
on this enterprise solution or solutions, and it does not perform as per expectations?
Well, there is no easy answer to that one because obviously, if you were to set up
a network from scratch and you were to keep it locked down,
and basically do one thing with it, and have everything baseline
and you have all your answers to all your questions that you may have then, yes.
I'm sure that the, the network will operate at the best possible performance.
It will perform optimally, every application will, will hum and everything will be great.
But here's the problem. When people are using the network,
they're moving things, they're doing things, and through that
it causes all these devices to be put on different loads, there's different stresses.
As the networks grow and people are trying to use them more,
they outgrow the initial design. As new applications deployed and as
things change and they're upgraded, there's new requirements.
So essentially, there's a lot of concerns
revolving around the simple fact that data transfer,
and the, the fact of the matter is,
is that it could be anything that impacts data transfer.
So I've listed a few here, some of them are common ones, there's latency.
So if I'm going to try to access something and it's taking quite, quite some time to do that,
then it may be deemed latent and what in my network or
what from my system source to my destination is causinig this latency.
I can have a bandwidth issue. I could have basically made my entire LAN segment
backbone of 10 gig and a 1 gigabit connections out to every computer
and then connected to another office or another data center and you know,
I'll have a 30k link which is basically going to not allow me in today's day and age
to transfer any data or do any back ups
or anything of that matter over that WAN connection.
What if I didn't have an internet connection
in my office and I was actually going over the WAN link
to access the internet out of a central site or data center or a core?
What if that bandwidth, that WAN connection
is undersized and it's not allowing me to transfer data from the internet to my client fast enough?
So as you could see, there's a lot of different things involved here with data transfer.
I/O is another basic concern. So, disc reads and writes, it could be very slow
causing the transfer of data into memory to be used and transferred across the network.
That may take an amount of time that is not considerably something that I am accepting
and there's others. You could have networks that were
currently on a 100 meg, fast ethernet and as it's growing to gigabit,
it may be using applications and things that just need that to be upgraded.
So, as you can see, there's a lot of concerns
revolving around specific, specific issues with data transfer.
So, what can Wireshark do to help you solve this problem?
Last we got through all the modules up til now,
we've covered a lot of reasons why things may be slow,
or causing performance issues and you've learned ways
to use Wireshark so that you can capture the data.
Again, place it correctly, capture the data,
review it, analyze it and use the tools within Wireshark
and external to Wireshark to come to some of these conclusions.
However, with Wireshark specifically, you can capture the data
from the source to that destination and you can look at
things that we've already reviewed such as timestamps, how long is it taking to get
from one place to another, the roundtrip time.
What's the time deltas? What's the throughput?
And other key data to help me analyze and figure out why
the transfer of data is seemingly slow.
So as an example with here I was trying to send data across the network and
there was quite a few things that took place.
One of the things was I was trying to switch modes
and it was causing a delay in the transfer or transferring of the data.
So it doesn't which protocol you use.
It doesn't matter specifically what action you take.
When you capture the data in Wireshark, you can start to sift through and look for clues.
As we've mentioned earlier in another module, you can pull up the flow graph.
And take a look at how long it's taking for certain things to happen on the network here.
And here, you can see that specifically, when it talks to one IP to another
there may be many factors as to why something may be slow.
An example here is we've got a bunch of zero windows. So, it may have, yup
right here, it was a re-transmission because of the problem with the window.
So there's certain things that will delay our ability to transfer data.
And looking specifically at the TCP communications, we were able to determine
that when at this point in time we thought that we're going to be sending the data,
there's quite a few things that took place in between it that delayed it.
So this period of time basically gave us a delay.
So, some of the things that we look for in Wireshark
when we're analyzing data transfer issues is you want to remember
that you can only see what the client in the server sees
and you can really, you can't really see anything in the middle unless you run Wireshark.
So, yes you can run a ping, you can run a trace, you can look at I/O on the boxes,
but what's the packets really saying?
You will need Wireshark to figure that out.
And once you capture that data, you can look at certain things.
You can say, alright well, I have some timing issues.
What's causing that and then flip back to the fact that
you may have a bandwidth problem,
you may have a congestion problem,
you may have a series of re-transmissions that may show that.
You may have dropped or lost data.
Again, no cause for immediate alarm because
that doesn't necessarily mean that it's the problem.
As we've mentioned in earlier segments, that just means that
Wireshark did capture that and one re-transmission
as an example is not a big deal but
if you see, for example, a hundred of them trying to get to an IP
in a short amount of time, it's quite possible that you have a communications issue.
And again, these devices when they get the data, they buffer them
and if you're flooding it with small-sized packets,
it's going to work a lot harder, it's going to fill up the buffers
and you're going to have issues where you could potentially see dropped data.
Again, you could also see a large amount of broadcast data
doing interrupts on your devices which is slowing them down.
You can look at the CPU's of the devices and see that they're working very hard.
And it may not be able to perform as optimally as you like.
And again, you can use other tools like the flow graph,
then the stream graph and other plotting tools
to take a look at the data over time and see exactly
what's spiking and what you need to address.
You can also do a flow analysis where you can have a clear view.
You can do this from flow and stream graphs which will allow you to take a look at
the overall communication from start to finish
and give you a bird's eyeview into what may be
delaying or causing the delay of a data transfer.
And just to summarize, again I believe that
when you're having a problem with a higher layer protocol,
it always makes sense to know whether that protocol is using UDP or TCP.
You can drill down into the TCP layer communications and it will give you
a closer look into the handshake and what,
what's actually taking place and what could also be causing
slowness of performance issues on your network.