A device in the IP can have both a local address (which uniquely identifies the device on its local segment or LAN) and a network address (which identifies the network to which the device belongs). The local address is more properly known as a data link address, because it is contained in the data link layer (Layer 2 of the OSI model) part of the packet header and is read by data-link devices (bridges and all device interfaces, for example). The more technically inclined person will refer to local addresses as MAC addresses, because the MAC sublayer within the data link layer processes addresses for the layer.

To communicate with a device on Ethernet, for example, Cisco IOS XR software first must determine the 48-bit MAC or local data-link address of that device. The process of determining the local data-link address from an IP address is called address resolution.

The following process describes address resolution when the source and destination devices are attached to the same LAN:

1. End System A broadcasts an ARP request onto the LAN, attempting to learn the MAC address of End System B.

2. The broadcast is received and processed by all devices on the LAN, including End System B.

3. Only End System B replies to the ARP request. It sends an ARP reply containing its MAC address to End System A.

4. End System A receives the reply and saves the MAC address of End System B in its ARP cache. (The ARP cache is where network addresses are associated with MAC addresses.)

5. Whenever End System A needs to communicate with End System B, it checks the ARP cache, finds the MAC address of System B, and sends the frame directly, without needing to first use an ARP request.

The following process describes address resolution when the source and destination devices are attached to different LANs that are interconnected by a router (only if proxy-arp is turned on):

1. End System Y broadcasts an ARP request onto the LAN, attempting to learn the MAC address of End System Z.

2. The broadcast is received and processed by all devices on the LAN, including Router X.

3. Router X checks its routing table and finds that End System Z is located on a different LAN.

4. Router X therefore acts as a proxy for End System Z. It replies to the ARP request from End System Y, sending an ARP reply containing its own MAC address as if it belonged to End System Z.

5. End System Y receives the ARP reply and saves the MAC address of Router X in its ARP cache, in the entry for End System Z.

6. When End System Y needs to communicate with End System Z, it checks the ARP cache, finds the MAC address of Router X, and sends the frame directly, without using ARP requests.

7. Router X receives the traffic from End System Y and forwards it to End System Z on the other LAN.

Two forms of address resolution are supported by Cisco IOS XR software: Address Resolution Protocol (ARP) and proxy ARP, as defined in RFC 826 and RFC 1027, respectively. Cisco IOS XR software also supports a form of ARP called local proxy ARP.

ARP is used to associate IP addresses with media or MAC addresses. Taking an IP address as input, ARP determines the associated media address. After a media or MAC address is determined, the IP address or media address association is stored in an ARP cache for rapid retrieval. Then the IP datagram is encapsulated in a link-layer frame and sent over the network.

When proxy ARP is disabled, the networking device responds to ARP requests received on an interface only if one of the following conditions is met:

• The target IP address in the ARP request is the same as the interface IP address on which the request is received.

• The target IP address in the ARP request has a statically configured ARP alias.

When proxy ARP is enabled, the networking device also responds to ARP requests that meet all the following conditions:

• The target IP address is not on the same physical network (LAN) on which the request is received.

• The networking device has one or more routes to the target IP address.

• All of the routes to the target IP address go through interfaces other than the one on which the request is received.

When local proxy ARP is enabled, the networking device responds to ARP requests that meet all the following conditions:

• The target IP address in the ARP request, the IP address of the ARP source, and the IP address of the interface on which the ARP request is received are on the same Layer 3 network.

• The next hop for the target IP address is through the same interface as the request is received.

Typically, local proxy ARP is used to resolve MAC addresses to IP addresses in the same Layer 3 network such as, private VLANs that are Layer 2-separated. Local proxy ARP supports all types of interfaces supported by ARP and unnumbered interfaces.

ARP establishes correspondences between network addresses (an IP address, for example) and Ethernet hardware addresses. A record of each correspondence is kept in a cache for a predetermined amount of time and then discarded.

You can also add a static (permanent) entry to the ARP cache that persists until expressly removed.

From Release 6.5.1 onwards, the supported ARP scale has been increased from 128K to 256K entries per LC CPU. This increase in scale improves performance while multiple ARP operations are being processed on the device.

Direct Attached Gateway Redundancy (DAGR) allows third-party redundancy schemes on connected devices to use gratuitous ARP as a failover signal, enabling the ARP process to advertise an new type of route in the Routing Information Base (RIB). These routes are distributed by Open Shortest Path First (OSPF).

Sometimes part of an IP network requires redundancy without routing protocols. A prime example is in the mobile environment, where devices such as base station controllers and multimedia gateways are deployed in redundant pairs, with aggressive failover requirements (subsecond or less), but typically do not have the capability to use native Layer 3 protocols such as OSPF or Intermediate System-to-Intermediate System (IS-IS) protocol to manage this redundancy. Instead, these devices assume they are connected to adjacent IP devices over an Ethernet switch, and manage their redundancy at Layer 2, using proprietary mechanisms similar to Virtual Router Redundancy Protocol (VRRP). This requires a resilient Ethernet switching capability, and depends on mechanisms such as MAC learning and MAC flooding.

DAGR is a feature that enables many of these devices to connect directly to Cisco ASR 9000 Series Routers without an intervening Ethernet switch. DAGR enables the subsecond failover requirements to be met using a Layer 3 solution. No MAC learning, flooding, or switching is required.

Note

Since mobile devices' 1:1 Layer 2 redundancy mechanisms are proprietary, they do not necessarily conform to any standard. So although most IP mobile equipment is compatible with DAGR, interoperability does require qualification, due to the possibly proprietary nature of the Layer 2 mechanisms with which DAGR interfaces.

You can configure an interface or a sub-interface to learn only the ARP entries from its local subnet.

Note	From Release 6.5.1 onwards, the supported ARP scale has been increased from 128K to 256K entries per LC CPU. This increase in scale improves performance while multiple ARP operations are being processed on the device.

Use the following procedure to configure local ARP learning on an interface.

1. Enter the interface configuration mode.

   Router(config)# interface GigabitEthernet 0/0/0/1

2. Configure the IPv4/IPv6 address for the interface.

   Router(config-if)# ipv4 address 12.1.3.4 255.255.255.0

3. Configure local ARP learning on the interface.

   Router(config-if)# arp learning local

4. Enable the interface and commit your configuration.

   Router(config-if)# no shut
   Router(config-if)# commit
   RP/0/0/CPU0:Dec 12 13:41:16.580 : ifmgr[397]: %PKT_INFRA-LINK-3-UPDOWN : interface GigabitEthernet 0/0/0/1, changed state to Down 
   RP/0/0/CPU0:Dec 12 13:41:16.683 : ifmgr[397]: %PKT_INFRA-LINK-3-UPDOWN : interface GigabitEthernet 0/0/0/1 changed state to Up 

5. Confirm your configuration.

   Router(config-if)# show running-configuration 
   ..
   Building configuration...
   !! IOS XR Configuration 0.0.0
   !! Last configuration change at Mon Dec 12 13:41:16 2016
   !interface GigabitEthernet 0/0/0/1
    ipv4 address 12.1.3.4 255.255.255.0
    arp learning local
   !

6. Verify if local ARP learning is working as configured on the interface.

   Router(config-if)# do show arp idb gigabitEthernet 0/1/0/0 location 0/1/CPU0
   Mon Nov 26 14:09:38.898 IST
   
   interface GigabitEthernet 0/1/0/0 (0x00804060):
     IDB Client: default
     IPv4 address 1.1.1.1, Vrf ID 0x60000000
     VRF Name default
     Dynamic learning: Enable
     Dynamic entry timeout: 14400 secs
     Drop adjacency timeout: 3600 secs
     Purge delay: off
     IPv4 caps added (state up)
     MPLS caps not added
     Interface not virtual, not client fwd ref,
     Proxy arp not configured, not enabled
     Local Proxy arp not configured
     Packet IO layer is SPIO
     Srg Role : DEFAULT
     Idb Flag : 49292
     IDB is Complete
     IDB Flag Description:
     [CAPS | COMPLETE | IPV4_CAPS_CREATED | SPIO_ATTACHED |
      SPIO_SUPPORTED]
     

7. (Optional) You can monitor the ARP traffic on the interface.

   Router(config-if)# do show arp traffic gigabitEthernet 0/1/0/0 location 0/1/CPU0
   Mon Nov 26 14:08:34.403 IST
   
   ARP statistics:
     Recv: 0 requests, 0 replies (0 unsolicited)
     Sent: 5 requests, 1 replies (0 proxy, 0 local proxy, 1 gratuitous)
     Subscriber Interface: 
            0 requests recv, 0 replies sent, 0 gratuitous replies sent
     Resolve requests rcvd: 1
     Resolve requests dropped: 0
     Errors: 0 out of memory, 0 no buffers, 0 out of sunbet
   
   ARP cache:
     Total ARP entries in cache: 2
     Dynamic: 0, Interface: 1, Standby: 0
     Alias: 0,   Static: 0,    DHCP: 0,    DropAdj: 1
   
     IP Packet drop count for GigabitEthernet0_1_0_0: 1
   

You can delete the drop adjacencies on an interface, location, or an IP address by using the command clear arp-cache drop-adjacency interface ip-address location. This command deletes the drop adjacencies from the ARP database and AIB. To get more information, see the clear arp-cache command in the chapter ARP Commands of the IP Addresses and Services Command Reference for Cisco ASR 9000 Series Routers.

If ARP throttling is configured on an interface and ARP fails to resolve a dynamic entry on that interface, then ARP marks that entry as drop adjacency entry for the interface in its database and in AIB. The drop adjacency timeout starts for that entry at that interface or hardware as per the configured timeout value. Once the timeout period is over, drop adjacency for that entry is removed from the ARP database and AIB.

If ARP throttling is configured over a virtual interface, drop adjacencies are synced with other interfaces like BVI or Bundle Interfaces over Group Service Process (GSP). This synching occurs in the member line cards in case of Bundles and in all the line cards in case of BVIs. Therefore, when an entry state is changed to drop adjacency or removed from drop adjacency, ARPs running on all the line cards have the same drop adjacency state for a particular entry. The drop adjacency state for an entry is updated in AIB as well.

ARP stores all adjacencies in the shared memory. Hence, after a process restart or an AIB disconnect followed by an AIB connect, ARP restores all drop adjacencies along with dynamic entries to the AIB.

Note	The timers for ARP entries, including timeout for drop adjacencies, is reset after a process restart. Therefore, the duration for drop adjacency entries for timeout is increased.

During ISSU, the drop adjacencies in the ARP database are not synched from the earlier version of the router to the upgraded version of the router. The drop adjacencies are recreated in the refreshed ARP database and AIB of the upgraded router.

Similarly, if ARP throttling and Geo Redundancy are configured for an interface of a router, the drop adjacencies are not synched across the active and backup routers. Once the backup router becomes the active router, the drop adjacencies are revreated in the refreshed ARP database and AIB of the newly active router.

In there is an interface flap, the purge delay feature allows the retention of dynamic entries in the ARP database up to a configured timeout period. The dynamic entries are not deleted from the ARP database if the interface comes up within the configured timeout period. However, the entries for drop adjacencies are not retained in the ARP database if there is an interface flap.