Ok, for our next module, we will be talking about capturing IP resolution.
And when we discuss capturing IP resolution, what we're saying is
how does the basics of ARPing work and how does that look in Wireshark,
and what can we do to find out or troubleshoot these types of problems with Wireshark.
And Wireshark will capture the basics and show you, however, some underlying
information about ARP is necessary so that
you understand what you are looking at and why.
So, what is IP resolution and what does ARP do?
Well essentially, computer systems operate on networks.
And for them to communicate, they need to be uniquely identified
and we generally do that with a IP address.
So, how does ARP tie in is that if you're going to request
to go somewhere in a network and you don't know what it is,
ARP or address resolution protocol is the protocol that is going to try to help you
find what that information is.
So when you configure IP on a source host,
an IP on a destination host, ultimately the data would need to be sent
from that one IP to the other and we need to route there.
And if it's a remote segment, it's going to need to traverse the network multiple hops.
This is obviously handled through the routing table and so on.
But locally, these IP packets ultimately resolve to the MAC address configured
on your machine. And this is the unique address.
And if you look at it from an entire source to destination concept,
it's really going from your machine address
all the way through the network using all different types of protocols,
IP addresses, going through route tables,
using ports and so on and so forth to ultimately get to the target -
MAC address and that is also called the burn in address.
So the IP, the IP resolution will take place when the address resolution protocol,
ARP maps that layer to data link layer,
hardware address to the IP address.
So, when we troubleshoot this with
Wireshark, what are we actually seeing?
So, we can capture that resolution process
pretty quickly and easily just by running a simple query, which we'll look at now.
So basically, what we did was we just ran a generic capture.
And now we want to filter for ARP and take a look at what's going on here.
So if we look at the ARP packets,
we see that there's an IP address asking here, for some information.
So we have a sender MAC address and the IP address
looking for a target and it's trying to resolve that information.
So this a simple view of what ARP, ARP is essentially doing
and you can see your source and destination which is your hardware addresses.
And what's in the packet is, it's looking for the IP information
so that it can resolve that information.
So that's essentially what we mean by IP resolution.
What can we find?
With this we can see issues with the, table instability can be an issue.
If you just run a simple ARP on your local machine,
you could see the ARP cache, it may be corrupted.
It may have incorrect entries. You may have, for example,
on a switch's memory, you may have things that have changed on the network.
It hasn't timed out or refreshed in the, in the cache.
So essentially, as network engineers, a lot of times what we can do,
is if we have a high time out on cache, we can come in
and we can log into the device and clear the ARP table.
Or clear the MAC address table. It's a completely kick-off the process again
which will essentially set up the ARP's to go out and try to resolve
the IP addresses again as the queries come in.
You have ARP spoofing to send data from one machine to another.
That was unintended, you can spoof that.
So, there's a lot of reasons why
capturing ARP could benefit you as a network engineer or network analyst because
you could find problems with broadcast storms.
Maybe there's a chattering NIC.
Again, maybe you have some table instability and you see constant requests.
Maybe something hasn't timed out and that's why you can't resolve the IP address
'cause it might have a different one assigned at that moment.
Something may be spoofed so at the, at the layer of security
you may be able to capture that data and see the spoofing attempts.
So as you could see there's, there's quite a few reasons
why you would want to capture this data and review it.
So what's really happening?
When ARP functions, it allows TCP/IP to resolve to hardware addresses,
the IP to resolve to IP addresses.
Reversed ARP or RARP is the opposite.
It's allowing the hardware to resolve the other way.
Adn essentially, when you set up a lag LAN segment for the first time,
nothing is known. The devices are boot up. They boot up and then they want to talk
to other devices on the network so it has to do this resolution process to start
communicating with other devices.
So essentially, what's going to happen there
is that the switch is going to learn this and keep them in the CAM table.
And allow you to go from one port to the other.
If not, it's going to broadcast at all ports.
But essentially, this process starts off with
nobody knowing anything and having to do this process to learn.
So, as you could see on the diagram,
the ARP request is the first function
then the device tries to find the hardware address
for a node based on the IP address it knows.
If you're going to go to a website,
basically that, even if it's a DNS name, it's going to resolve to an IP address
which essentially is going to allow you to go out on the network.
You can communicate with it however,
the request will go out if it doesn't know it, that IP address is.
And then the reply, the correct device will respond,
with the, the needed hardware address.
So essentially, that is what you are seeing when you look at the capture.
You're seeing this process of requests and replies going back and forth.
You know, I need to get to something, I need to know how to get there.
Ok well, this is how you get there. You need to know this address.
So, at it's most fundamental layer, that's what ARP is doing.
So again, ARP fundamental, fundamentally will resolve an IP to a MAC.
Remember, the RARP will do the, the opposite.
It's broadcast based so that's where these storms come into place.
If you have a problem, broken or damaged or
incorrectly working hardware on your network,
it could generate a storm scenario,
where it just constantly sends the data out.
Quickly and easily captured by Wireshark, you span a port, you check it out,
you see all these back and forth storm, storm-like activity with ARP.
Very quickly figure out that you have some kind of problem
and then you could try to map it back down to the MAC address.
Maybe you can get into the switch if it's not overwhelmed
and see what port that MAC address is mapped to.
Maybe shut the port or unplug the cable,
and get that machine off the network, as an example.
Possible issues, stickiness when you're using port security.
That could be something that, that creates an issue.
Storms, chattering NIC cards, spoofing,
proxy ARP could be an issue.
And as we mentioned before, cache issues where something is known,
the time out didn't expire yet,
and you need to either refresh or release that information so that it can broadcast back out
and build that information back up.
This way that you can get your devices functioning on the network again.
And lastly, we showed it on Wireshark just previously.
But as you could see from the diagram,
very simply, this is what a ARP request reply looks like at it's most basic format.