The next topic that I want to speak about is the Address Resolution Protocol which we normally refer to it as ARP.
ARP is a very important protocol because without it we wouldn’t be able to have our network working.
Every time a network device wants to send a data to another network device, it need to know the following:
- Its own MAC address and IP Address
- The remote device MAC address and IP Address
Surely it knows its own MAC and IP, but it may happen that it knows the remote IP but not the MAC. In this way, it cannot send the data unless it gets the remote MAC address.
To get the remote MAC address, it needs to issue an ARP request. This ARP request will be sent as a broadcast and will ask the one who has that remote IP address to send him his MAC address. Let me illustrate it in a graphic:
Say that the PC wants to send something to the router. The PC knows his own MAC and IP, but it only knows the IP of the router. It still needs the MAC of the router to be able to send him the data.
For this reason, it will issue an ARP request saying: the one who has the IP of 192.168.88.1, please give me your MAC address because I want to send you some data. The ARP request is always sent as a broadcast. The router sees the request coming and will answer with an ARP reply giving his MAC address. This way the PC will have the MAC of the router, and it has already the IP of the router, then it can send him the data. That’s how ARP works.
Let’s compile that in a LAB and see how this works with MikroTik RouterOS.
My LAB is left as it was from the DCHP LAB.
Let’s check the ARP Table on R1:
[mepr-show rules=”319″ unauth=”message”]
You can see that R1 has in his ARP table an entry of my PC IP mapped to my PC MAC address. That means if my router wants to send something to my PC, he has the full information needed and no need for him to make an ARP request.
What about my PC? Does he have the entry in his ARP table for my router IP and MAC address? Let’s check:
Also, my PC has an entry in his ARP table having my router IP and MAC addresses. So now there is 2-way communication between my PC and router.
I would like to disable now the ARP protocol on my router interface Ether2. Will check if they can still communicate to each other. Let’s do that:
Now the ARP has been disabled on Ether2 of the router. Let’s check the ARP table of the PC if it still has the entry of the IP/MAC of the router:
It is gone ☹ – will my PC still able to ping 192.168.88.1? let’s try:
Of course not. Because my PC is sending an ARP request asking for the one who has the IP of 192.168.88.1 to send him his MAC address, but my router has ARP disabled so he doesn’t send the ARP reply, thus my PC cannot get the MAC of Ether2 of the router. Got it?
Let’s bring ARP enabled again on Ether2 of the router and see if the ping would work:
ARP is enabled on the router. Let’s do now the ping from the PC:
Now it is working again.
Another thing that I want to show you, is making the ARP entry on the router as static. Similar to what we have done on the DHCP lease, you can also make the ARP entry on the router as static. Let me show you how you can do that:
Now the ARP is static on my router for the entry of the PC. Let me disable now again the ARP on Ether2:
Can the PC still able to ping to the router IP. Let’s try:
Yes, it still able. But how come? We have disabled the arp. Well think of it. The router has the MAC and IP of the PC saved as a static entry. The PC has still the MAC and IP of the router because it has made previously the ARP request and got the MAC from the router as you see below:
That’s why you can still ping from the PC to the router. However, once the ARP entry for the router which is on the PC is expired, then they will not be able to reach each other. To make it fast, I will remove the cable from Ether2 and put it back. Then this way, the PC will issue again an ARP request requesting for the MAC of the router and he will fail to get.
Now I have removed the cable and put it back.
Let’s check the ARP table now on the PC:
Indeed, the ARP entry for the router is not there anymore. So now if I try to ping to 192.168.88.1 it shouldn’t work. Let’s try:
Our logic is correct, it is not working.
The last thing that I want to show you here is about the option of reply-only on ARP. This goes hand in hand with the static ARP.
As you know we have made a static ARP entry on our router for the PC addresses. If I want that my PC answer to ARP requests but doesn’t add any ARP entries automatically, all I need to do is to set the ARP to Reply-Only. This way, I use the ARP static entries on the router, and my interface will answer to ARP request coming from other network devices. That means, if I set now arp-reply on Ether2, would my PC be able to ping the router IP again? Let’s check:
Now that I have set it as reply-only, let’s ping from the PC to 192.168.88.1:
It is working. – But why is it working? Well, think of it. My router knows about the IP and MAC address of the PC because it has it saved as a static entry on its ARP table.
My PC does not know the MAC address of the router, so it has sent an ARP request as a broadcast saying the one of has the IP 192.168.88.1, then send me your MAC address.
The router has received that broadcast and he has replied with his MAC address back to the PC because we have set the ARP to be as reply-only, but at the same time it hasn’t learned anything dynamically from that ARP request. Got it? That’s why the ping is working.
If you want, we can look at the ARP table of the PC, we should be able to see the entry for the router:
Here it is, the ARP entry is there.
That’s all what I wanted to show you in this LAB and in this chapter, I hope you enjoyed it and I see you in the upcoming one.