Cisco Cisco ASA 5525-X Adaptive Security Appliance 문제 해결 가이드

다운로드
페이지 3
This change can manifest itself immediately after upgrading the ASA to version 8.4(3). In some cases,
Internet users cannot connect to the global address of a translated server through the ASA.
This message is 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.
Conditions / Environment
In order 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.
Cause / Problem Description
In order to understand the full ramifications of this issue, it is important to get a complete understanding of
how this issue can appear and the best way to mitigate the problem.
These are some instances where this situation can be encountered:
Upstream device has IP routes configured with no next−hop IP address
This is probably the most common cause of this situation. 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:
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:
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
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 does not 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 configuration:
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 can be
black−holed when sent to an incorrect device.
• 
The route will cause the device to send an ARP request for every unique destination address in the
packets that match the route. This can 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.
•