Address Resolution: ARP, Reverse ARP, and Inverse ARP

The higher-layer protocol encapsulation in Frame Relay formats raises the issue of resolving the upper-layer addresses to Frame Relay addressing schemes. Especially in point-to-multipoint connections, where the hub side has many Layer-3 addresses (typically IPs) assigned, you need to resolve the Layer-2 address (regardless if it is a DLCI or Q.922 address) to the Layer-3 address (IP). The problem can be resolved by polling all subinterfaces for hardware and protocol address resolution, but this method does not seem appropriate. The Frame Relay network provides several virtual circuits that form the basis for connections between stations that are attached to the same Frame Relay network. Every DTE in Frame Relay can have a DLCI, which is the Frame Relay equivalent of a hardware address that is associated with an established PVC, but DTE does not know the protocol address of the other party.


Address resolution can be accomplished by using the standard ARP encapsulated within a SNAP. DLCIs have a local significance for the Frame Relay networks, but they have no significance whatsoever for the end station (for example, a computer) connected to the Frame Relay router. Therefore, such a station does not have an address to put into the ARP request or reply. The DLCI carried within the Frame Relay header is modified as it traverses the network. When the packet arrives at its destination, the DLCI has been set to the value that, from the standpoint of the receiving station, corresponds to the sending station, but when an ARP message reaches a destination, all hardware addresses are invalid. However, the address found in the frame header is correct. It looks like Frame Relay can use this address in the header as the sender hardware address and still perfom ARP. However, the problem is that the target hardware address in both the ARP request and reply will be also invalid.

Reverse ARP

Could Reverse Address Resolution Protocol (RARP) be a solution? RARP works the same way as ARP. The response to a request returns the protocol address of the requesting station, not the address of the station receiving the request. IP-specific mechanisms are designed to only support the IP protocol.

Obviously, ARP and RARP are not a solution, and a new address resolution variation was developed. This variation is called Inverse ARP (InARP), which is essentially an expanded ARP.

Inverse ARP

InARP enables a Frame Relay station to discover the protocol address of a station that is associated with the virtual circuit. It is more efficient than sending ARP messages over every virtual circuit for every address that the system wants to resolve, and it is more flexible than relying on a static configuration. Basic InARP operates essentially the same as ARP, with the exception that InARP does not broadcast requests. This is because the hardware address of the destination station is already known. A requesting station simply formats a request by inserting its source hardware, protocol addresses, and the known target hardware address. It then zero fills the target protocol address field. Finally, it encapsulates the packet for the specific network and sends it directly to the target station.

In a Frame Relay interface that supports data-link management, an InARP-equipped station that is connected to such an interface sends an InARP request and addresses it to the new virtual circuit. If the other side supports InARP, it can return a response that provides the requested protocol address. In a Frame Relay environment, InARP packets are encapsulated using the NLPID/SNAP format. For more information on the InARP protocol format, see In Cisco routers, the InARP is established by default and does not show up in the configuration. From a configuration point of view, using InARP is referred to as dynamic mapping—see Chapter 16 for more details. InARP does not work without LMIs because it uses LMI messages to determine which PVC to map (remember that LMI carries information for all configured PVCs). If the DLCI is down, the Cisco router still processes and maps an InARP, but does not use it until DLCI is reported as active.

+ Share This