ASA 8.4.3: ARP response behavior change

Document

Thu, 08/20/2015 - 20:22
May 21st, 2012

Introduction

Starting with ASA version 8.4(3), the ASA will not respond to ARP  requests received on an interface, for IP addresses that are not a part  of that interface's IP subnet. Prior to version 8.4(3), the ASA would  respond to ARP requests that were not in the IP subnet of the ASA's  interface.


This change might manifest itself immediately after upgrading  the ASA to version 8.4(3). In some cases, internet users might be unable  to connect to the global address of a translated server through the  ASA.


The following message will be displayed if this situation is encountered, and 'debug arp' is enabled on the ASA's CLI:

arp-in: Arp packet received from 192.168.10.1 which is in different subnet than the connected interface 192.168.11.1/255.255.255.0


The root cause of  this issue is not a bug; see the information below to learn more about  potential causes and solutions to the issue.


Condition

To  encounter this situation, the ASA must receive an ARP request for an IP  address that matches a global address in a configured NAT translation;  the global IP address must reside in an IP subnet that is different from  the IP subnet configured on the ASA's interface.


Problem

To  understand the full ramifications of this issue, it is important to get  a complete understanding of how this issue could appear, and what is  the best way to mitigate the problem.


Below are some situations where this situation could be encountered:


Upstream device has IP routes configured with no next-hop IP address

This is probably the most common cause of this situation, and it is  due to a non-optimal configuration of an upstream device. It is  preferred to configure IP routes such that the next hop of the IP route  is an IP address in the same subnet as that interface's address, like  this:


ip route 10.1.2.0 255.255.255.0 192.168.1.2


However, sometimes network administrators configure an interface, instead of an IP address, as the next hop, like this:


ip route 10.1.2.0 255.255.255.0 FastEthernet0/1


This causes the router to route traffic destined to the 10.1.2.0/24  network to the FastEthernet0/1 interface, and then send an ARP request  for the destination IP address in the IP packet. It is assumed that some  device will respond to the ARP request, and the router then forwards  the packet to the MAC address that was resolved due to the ARP process.  The benefits of this type of configuration is that it is very easy to  configure and administer; the administrator doesn't have to explicitly  configure a next hop IP address for the route, and they assume that an  adjacent device will have proxy-ARP enabled and will respond to the ARP  request if it is capable of routing the packets to the destination IP  address.


However, there are serious problems with this type of ip route config:


  1. By sending an ARP request to determine the next hop for IP traffic,  the router is exposed to problems caused by other devices that might  incorrectly respond to that ARP request. The result is traffic could be  black-holed when sent to an incorrect device.
  2. The route will cause the device to send an ARP request for every  unique destination address in the packets that match the route. This  could cause a large amount of ARP traffic on the subnet and negatively  affect performance as well as the memory space required to hold a  potentially large amount of ARP entries.
  3. Since ARP table space is a memory bound resource, an excessive  number of entries may negatively impact the router's performance and  stabilty.


Therefore, it is absolutely a best practice to configure all routes  with explicit IP next-hop addresses, and not use routes that have an  interface name by itself to identify the outgoing interface. If the  interface is needed to tie the route to the egress interface for  failover enter both the egress interface name and the next hop in the  static route.


Mismatched IP subnet masks on adjacent devices

Mismatched IP subnet masks configured on the ASA's interface and the  adjacent device's interface could cause a similar situation. If the  adjacent device had a subnet mask that was a supernet (255.255.240.0) of  the ASA's interface IP subnet mask (255.255.255.0), the adjacent device  would ARP for IP addresses that are not in the ASAs interface IP  subnet. Ensure that the subnet masks are correct.


Transparent Mode Implications

Another side effect of this change is the inability to learn MAC  addresses from non-directly-connected subnets in Transparent mode. This  will break communication in the following scenarios:


1. The ASA does not have a management IP address configured or the configuration is incorrect.

2. The ASA is using secondary subnets on the same segment.


There is no workaround for this issue in Transparent mode aside from the downgrade.


Resolution

The  solution to this problem (in the case that the IP address in question  is not in the same layer-3 subnet as the ASA's interface IP)  is to make  the changes necessary to ensure that devices adjacent to the ASA route  traffic directly to the ASA's interface IP address as the next hop  device, instead of relying on a device to proxy-ARP on behalf of the IP  address.

-

Author

The author of this document are Aaron S Mcquaid (amcquaid) and Derek Lynch (delynch).

Loading.
CSCO11377298 Sat, 06/30/2012 - 02:55

Does anyone know if this also affects 8.6 onwards as i have this an issue with secondary outside subnets on a pair of 5515-X's

Johan van Bruksvoort Mon, 07/09/2012 - 07:45

We have a problem with this as many seemed to have, since we have 3 IP subnets assigned by our provider how are we supposed to make this work, we want to use the 3 subnets on one outside interface and use static NAT to use the IP addresses of the other subnets that don't have and IP assigned to the outside interface. We can't change the routing of the upstream providers router.


What to do? isn't there a workaround?

MINGJU YU Tue, 02/26/2013 - 19:07

Hi All


If your ASA image is the 8.6,maybe you can try to upgrade to the 9.0. The Command Reference has the "arp non-connected-subnet" ,it's behavior is just like the before  "arp permit-nonconnected"! But this version is published very lately(10/29......).SO...Take care.


See Command Reference---

http://www.cisco.com/en/US/docs/security/asa/asa90/command/reference/a3.html#wp1824414


- See more at: https://supportforums.cisco.com/message/3781445#3781445

MSS Operations Thu, 02/20/2014 - 13:13

arp non-connected-subnet has been added in the versions 8.4(5)+.

Cisco recommends however to set static routes (w/ ip as next hop to the ASA) on the upstream router.

Actions

This Document