cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

Community Helping Community

Proxy ARP VS Gratuitous ARP

18339
Views
15
Helpful
6
Comments
Cisco Employee

It was a beautiful Saturday morning a few weeks ago. As I was enjoying a cup of coffee on the porch, I quickly realized it was time to get ready to go to work.  It was an extremely hectic day with many high severity cases that rang in. One of them was very interesting that I decided to discuss it with everyone today.

 

In this case the problem was that the Iron-port server that was off the Email interface was not reachable from the outside.

Kureli_proxy-blog.jpg

Partial config on the ASA:


   Static (Email,Outside) 14.36.10.138 10.10.10.10 net 255.255.255.255

Route Outside 0.0.0.0 0.0.0.0 14.36.10.142

 

  1. ASA's default route was pointing to R1
  2. Packets destined to 14.36.10.138 did not arrive on the ASA's outside interface. Verified that with the capture command:          
      1. cap capout int outside match ip any host 14.36.10.138
      2. sh cap capout det
      
  3. I was able to ssh to the ASA's outside address. These packets arrived – obviously!
  4. All other statics configured worked as expected except for this IP address 14.36.10.138.
  5. Customer does not have access to R1.
  6. R1 belonged to the ISP and they put in a call to the ISP and no response from them.
  7. There is no way they will allow us to reboot R1.
      

So, how do we resolve this issue? My suggestion to change the translated IP address to another unused address quickly went out the window for obvious name resolution issues.  ARP timeout is usually set for 14400 which is 4 hours. No one has the patience to wait it out.

Proxy arp: Well, the ASA proxy arps for all its global addresses, meaning, we will answer who we are if someone asked us.  When an ARP request is made for the global IP address of the Iron-port server, 14.36.10.138, the security appliance responds with its own MAC address.


   If the router were to ask the ASA, it would reply as below:

 

28: 04:09:44.939007 arp who-has 14.36.10.138 tell 14.36.10.142

29: 04:09:44.939053 arp reply 14.36.10.138 is-at 0:16:c7:9f:73:ef

 

Gratuitous arp: In this case we needed the ASA to send a gratuitous arp meaning we wanted the ASA to announce to everyone that it owns this IP address 14.36.10.138. An ARP announcement is not intended to solicit a reply; instead it updates any cached entries in the ARP tables of other hosts that receive the packet.

 

1: 03:38:35.873840 0016.c79f.73ef ffff.ffff.ffff 0x0806 42: arp who-has 14.36.10.138 tell 14.36.10.138

 

We don't do this for the global addresses that we own but only for the interface addresses.  Once we get this enhancement defect resolved CSCsy85614 we would be able to remove the static line and add it back again and force the ASA to grat arp and R1 will automatically update its arp cache to the correct MAC address; assuming it wasn't programmed with a static arp for this IP address.

 

Now, with no visibility to R1 how could we (Cisco) solve this problem?  How do we make R1 learn the ASA's outside interface MAC address for this IP address 14.36.10.138?

 

Fortunately, there were no tunnels terminated on this ASA. With their permission, I changed the ASA's outside interface IP address to 14.36.10.138 and pinged R1. Once I got a reply I knew R1 has learned the ASA's outside interface MAC for the IP address 14.36.10.138 and immediately changed the interface IP on the ASA outside interface back to what it was 14.36.10.132.  Iron-port server was reachable from the internet. Packets arrived ! Problem solved!

 

Whew ! everyone was finally happy.

 


  

6 Comments
Beginner

When packets arrived from the outside to 14.36.10.138 - wouldn't R1 just send an arp request to the ASA anyways? Is it possible that R1 just had an incorrect entry?

Beginner

It sounds like either R1 had an incorrect ARP entry or ProxyARP was disabled on the outside interface of the ASA.

Cisco Employee

If R1 had an incorrect arp entry, it would continue to send the traffic to the incorrect MAC address. A clear arp on the router would have cleared that and it would have sent an arp request for subsequent packets and the firewall would have responded. My guess was that someone statically configured the same IP address on a laptop or PC or the server had a second NIC configured with that IP and put on the outside briefly and must have unplugged it.

Cisco Employee

Yes. You are correct. R1 must have had an incorrect ARP entry. Proxy ARP was not disabled on the ASA - I had control of the ASA. Remember? All other statics worked.

That was smart , Great work

To scale the performance of firewalls and to provide high reliability, Cisco has a new feature called ITD. Please see ITD (Intelligent Traffic Director) White Paper.

Also, recent blog : Intelligent Traffic Director @ Cisco Live Milan

 

ITD Provides CAPEX and OPEX Savings for Customers

ITD (Intelligent Traffic Director) is a hardware based multi-Tbps Layer 4 load-balancing, traffic steering and clustering solution on Nexus 5K/6K/7K series of switches. It supports IP-stickiness, resiliency, NAT, (EFT), VIP, health monitoring, sophisticated failure handling policies, N+M redundancy, IPv4, IPv6, VRF, weighted load-balancing, bi-directional flow-coherency, and IPSLA probes including DNS.

ITD is much superior than legacy solutions like PBR, WCCP, ECMP, port-channel, layer-4 load-balancer appliances.

 

CreatePlease to create content
Content for Community-Ad
FusionCharts will render here