Thursday, February 20, 2020

Proxy ARP Explained

Most networking students are familiar with ARP (Address Resolution Protocol) but Proxy ARP doesn’t always ring a bell. In this tutorial I will explain how proxy ARP works, we’ll use the following topology for this:
Proxy Arp Topology
In the example above we have two subnets: 10.1.1.0 /24 and 10.2.2.0 /24. The router in the middle is connected to both subnets. On the bottom you see two hosts (H1 and H2) and on top we have a server (S1).
When you take a close look at the hosts you can see that H1 has a /24 subnet mask and H2 has a /8 subnet mask. When H1 tries to reach the server at 10.2.2.100 the following will happen:
  1. H1 compares its IP address and subnet mask to the IP address of the server (10.2.2.100) and decides that the server is in another subnet.
  2. H1 decides to send the packet for the server to its default gateway (10.1.1.254).
  3. H1 checks its ARP table to see if there is an entry for 10.1.1.254, if not it will send an ARP request.
  4. The router will respond to the ARP request, sending its MAC address of its FastEthernet 0/0 interface.
This is how ARP works normally, when H2 tries to send an IP packet towards the server something else will happen:
  1. H2 compares its IP address and subnet mask to the IP address of the server (10.2.2.100) and decides that the server is in the same subnet.
  2. H2 checks its ARP table to see if there is an entry for 10.2.2.100, if not it will send an ARP request.
The server however is not on the 10.1.1.0 /24 subnet and routers do not forward broadcast traffic so the ARP request never makes it to the server. All hope is not lost however….this is where proxy ARP comes to the rescue!
When proxy ARP is enabled on the router, this is what happens:
  1. The router sees the ARP request from H2 on the 10.1.1.0 /24 subnet and sees that this is an ARP request for something in the 10.2.2.0 /24 subnet.
  2. The router realizes that it knows how to reach the 10.2.2.0 /24 subnet and decides to respond to the ARP request in order to help H2.
  3. The router sends an ARP reply to H2 with its MAC address on the FastEthernet 0/0 interface.
Are you following me so far? Let me show you what this looks like on a real router.

Configuration

I will use the following topology to demonstrate proxy ARP:
Proxy Arp Lab Topology
It’s the same as the picture as I just showed you but I am using the routers in my lab. By disabling “ip routing” I can turn the routers into ordinary host devices. Let’s start by disabling routing on R1, R2 and the server:
H1, H2 & S1(config)#
no ip routing
Let’s configure the default gateway on those devices:
H1 & H2(config)#
ip default-gateway 10.1.1.254
S1(config)#ip default-gateway 10.2.2.254
Let’s configure all the IP addresses that we require:
H1(config)#interface fastEthernet 0/0
H1(config-if)#ip address 10.1.1.1 255.255.255.0
H2(config)#interface fastEthernet 0/0
H2(config-if)#ip address 10.1.1.2 255.0.0.0
S1(config)#interface FastEthernet 0/0
S1(config-if)#ip address 10.2.2.100 255.255.255.0
Note that I used the /8 subnet mask on H2 here. Here’s the router:
R1(config)#interface FastEthernet 0/0
R1(config-if)#ip address 10.1.1.254 255.255.255.0
R1(config-if)#interface FastEthernet 0/1
R1(config-if)#ip address 10.2.2.254 255.255.255.0
That’s all we have to configure…let’s verify our work!

Verification

To test proxy ARP I will first send some traffic from H1 to the server so you can see what normal ARP looks like, and then we will send some traffic from H2 to the server.
Proxy ARP is enabled by default as you can see here:
R1#show ip interface FastEthernet 0/0 | include Proxy
  Proxy ARP is enabled
To see in realtime what is going on, I will use the following debug on R1:
R1#debug arp
ARP packet debugging is on
Let’s send some pings from host A to the server:
H1#ping 10.2.2.100

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.2.100, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 44/311/1068 ms
The ping is working, the first one failes because of some ARPs, you can see them in the debug below:
R1#
IP ARP: rcvd req src 10.1.1.1 c204.07ec.0000, dst 10.1.1.254 FastEthernet0/0
IP ARP: sent rep src 10.1.1.254 c206.13b8.0000,
                 dst 10.1.1.1 c204.07ec.0000 FastEthernet0/0
R1 receives an ARP request from H1 who is looking for the IP address of its default gateway and replies with its MAC address.
R1#
IP ARP: creating incomplete entry for IP address: 10.2.2.100 interface FastEthernet0/1
IP ARP: sent req src 10.2.2.254 c206.13b8.0001,
                 dst 10.2.2.100 0000.0000.0000 FastEthernet0/1
IP ARP: rcvd rep src 10.2.2.100 c207.13b8.0000, dst 10.2.2.254 FastEthernet0/1
Before R1 can deliver the packet to the server it has to know the MAC address of the server, so R1 does an ARP request and receives a reply from the server.
R1#
IP ARP: rcvd req src 10.2.2.100 c207.13b8.0000, dst 10.2.2.254 FastEthernet0/1
IP ARP: sent rep src 10.2.2.254 c206.13b8.0001,
                 dst 10.2.2.100 c207.13b8.0000 FastEthernet0/1
R1 also receives an ARP request from the server who is looking for the MAC address of its default gateway, a reply is sent with the MAC address of FastEthernet 0/1. Here’s what the ARP table of H1 looks like now:
H1#show ip arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.1.1.1                -   c204.07ec.0000  ARPA   FastEthernet0/0
Internet  10.1.1.254              3   c206.13b8.0000  ARPA   FastEthernet0/0
H1 has saved the MAC address of its default gateway in the ARP table. What you have seen so far is just regular ARP.
Now we’ll see how proxy ARP works by looking at H2. To see the logic of H2 in action I will enable ARP debugging:
H2#debug arp
ARP packet debugging is on
Let’s ping the server:
H2#ping 10.2.2.100

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.2.100, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/249/1076 ms
Our ping is working and here’s the debug of H2:
H2#
IP ARP: creating incomplete entry for IP address: 10.2.2.100 interface FastEthernet0/0
IP ARP: sent req src 10.1.1.2 c205.07ec.0000,
                 dst 10.2.2.100 0000.0000.0000 FastEthernet0/0
IP ARP: rcvd rep src 10.2.2.100 c206.13b8.0000, dst 10.1.1.2 FastEthernet0/0
H2 sends an ARP request, looking for 10.2.2.100 and receives an ARP reply. Here’s what you will see on R1:
R1#
IP ARP: rcvd req src 10.1.1.2 c205.07ec.0000, dst 10.2.2.100 FastEthernet0/0
IP ARP: creating entry for IP address: 10.1.1.2, hw: c205.07ec.0000
IP ARP: sent rep src 10.2.2.100 c206.13b8.0000,
                 dst 10.1.1.2 c205.07ec.0000 FastEthernet0/0
R1 receives the ARP request, adds the MAC address / IP address of H2 to its own ARP table and sends an ARP reply to H2. This ARP reply contains its own MAC address and the IP address of the server. Let’s see what the ARP table of H2 looks like now:
H2#show ip arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.1.1.2                -   c205.07ec.0000  ARPA   FastEthernet0/0
Internet  10.2.2.100              0   c206.13b8.0000  ARPA   FastEthernet0/0
You see the IP address of the server and the MAC address of R1, to verify this you can check the interface of R1 like this:
R1#show interface FastEthernet 0/0 | include address
  Hardware is Gt96k FE, address is c206.13b8.0000 (bia c206.13b8.0000)
  Internet address is 10.1.1.254/24
That’s all there is to it! I hope this example has been useful to you. If you have any questions feel free to leave a comment.

No comments:

Post a Comment