3.1.a (ii) ARP

From within the same LAN we need a reliable way to map IP addresses to MAC addresses.

The way ARP works is we send out a request which goes out as an ethernet broadcast, to all hosts on the broadcast domain.
The dst mac this is sent to is ffff.ffff.ffff.

This request is heard by all hosts and read. The host which has the address we are looking for will reply with his MAC address.
This completes the bindings for IP to MAC and we can communicate with the host in a unicast fashion.

When a host first comes up on the LAN he will first send out a gratuitous ARP, which basically says to everyone hey I am x.x.x.x on this mac address.

This gratuitous arp looks like a regular ARP request, except the sender and target IP address are the same. This broadcast in turn allows all of the hosts on the broadcast domain to obtain this IP to arp mapping and avoid having to ARP and wait for a response when they actually need to communicate with the host.

This is what that looks like.

This is the PDU contents.

A normal ARP request would look something like those, pay attention to the sender ip address vs the target ip address. Notice we want to find out who is 192.168.1.3, and thus the target mac address is ffff.ffff.ffff.

The reply looks like this. You should be aware that the ARP reply is actually a unicast message, while the ARP request was a broadcast.

Notice here in this message the code is reply, and the original destination sets him self now as the sender mac and sender ip. This information allows the receiver to complete their ARP entry.

In the back end what this also does is populate the CAM tables for our switches and router. The gratuitous arp populates the ARP table of the gateway on the LAN. While it traverses the network the switches check the source mac address and learn it on ports. Thus we should not have unicast flooding as long as the 5 min for the mac don’t expire, and the 4 hours for the arp don’t expire in the caches.

Even without the gratuitous arp these tables would still be populated, it just would not be as efficient and could result in a little more delay when we want real time communication initially. The gratuitous arp is not necessary, but it speeds things up.

ARP and leaving the network:

This leads to the next question, when we need to leave the network, do we arp for the gateway or for the host on the other subnet?
The answer to this question is that as long as our default gateway is an IP and not an outgoing interface, then we will arp for the default gateway and send the packet there. If our default route pointed out of an interface, then we would arp for that IP address and then would rely on the gateway’s proxy arp to handle that.

What does that mean?
Well on a router we are used to doing this.
en
conf t
ip route 192.168.2.0 255.255.255.0 10.0.0.2
#
#BUT WE CAN ALSO DO THIS
#
ip route 192.168.2.0 255.255.255.0 g0/1

Here is proof of the above statement. My default gateway on this host was 192.168.1.1, and I am 192.168.1.2.
I pinged a host on another subnet (192.168.2.2), notice I just arp’d for my gateway.
This is the most standard way of doing this, and actually the most efficient.

You will very very very RARELY see someone routing a network on an outgoing interface. They almost always use the IP.

That leads to the next question, when is it okay to route to an interface vs layer 3 address?
When you have a P2P l2 connection like a p2p gre tunnel, ppp link.

Let’s look at a topology…

Here I have implemented this on R1
en
conf t
ip route 192.168.2.0 255.255.255.0 10.0.0.2

I have implemented this on R2
en
conf t
ip route 192.168.1.0 255.255.255.0 10.0.0.2

Now when PC1, 192.168.1.2 pings PC2, 192.168.2.2. You normally would expect PC1 to arp for 192.168.1.1 his GW, and then send the packet there for routing. From there R1 will check his routing table for a route to 192.168.2.0/24 and and find out the next hop of 10.0.0.2. He will then ARP for that address if he does not have it, he will regenerate the packet with new src mac and dst mac addresses, then finally send the packet there. Finally R2 get’s the packet and looks at the destination ip address and finds he is directly connected so he arps for PC2 if he does not have that IP and then he regenerates the packet, changes the src and dst mac then sends it to PC2.

here is that arp exchange between R1 and R2

That is the only one that ever needs to happen between those two.

Now assume we did this configuration on the routers instead…

Here I have implemented this on R1
en
conf t
ip route 192.168.2.0 255.255.255.0 g0/1

I have implemented this on R2
en
conf t
ip route 192.168.1.0 255.255.255.0 g0/1

What happens differently now? Well now between R1 and R2, instead of arping for the next hop address, what the routers instead do is arp for the destination of the IP packet, and then because the other side router is running proxy arp by default, they will respond to that IP with their mac address to facilitate the routing. This is what the packet exchange looks like between R1 and R2.

Notice something else, let’s look into R1’s arp table.

He now has ARP entries for EVERY destination IP packet that passes through him, even though he is not directly connected. Right now it’s not a problem. But as we communicate to more networks towards the internet, we will have an ARP entry for each destination IP. Naturally you can see why this is a problem. It will totally eat all of our memory. Hence why in these situations, what we should do instead is always route to a destination IP address.

Now let’s go back to something I said earlier, this routing towards an outgoing interface is facilitated by proxy arping.

Proxy ARP

What is proxy arp?
Proxy arp is a feature on devices which allows them to answer an ARP request on behalf of another to facilitate communication. If a router sees an ARP on a connected segment for a prefix/subnet that is not local to that network, AND that it has a route to, or is directly connected to, it will send out a reply to that arp known as a proxy arp. This proxy arp says hey to get to that destination IP just use my mac address. Here’s another example. If Router A has an interface, g0/1 with an Ip of 192.168.1.1/24, and it somehow receives an ARP for 192.168.2.10 on that interface, AND it has a route to t hat 192.168.2.0 network, it will proxy arp by default (unless you turn off the feature) to facilitate communication.

Proxy arp is enabled by default on IOS and IOSXE.
How can we verify it? By using “show ip int <interface>” look for “Proxy ARP is enabled”

Side tangent…
The most common scenario for proxy arp is when NATing a subnet that an ISP gives you to a host on the inside. For example if Comcast gave you a /29 and your gateway was in that /29, normally without proxy arp your host would have to have an IP on that subnet. However if you NAT an IP on that subnet to a host on the inside, and then proxy arp for that IP, you can now facilitate communication for that host.

Let’s turn that off between the two routers and see what happens.

If we ping again between PC1 and PC2 we notice it does not work.

Thus routes using a destination interface rather than IP require proxy arp on both ends to facilitate communication.

Here’s another way to remember it:
When routing using a next hop ip address, we will arp for the next hop.
When routing using a next hop interface, we will arp for the destination IP.