Chapter 3 - The Address Resolution Protocol


SummaryThe Address Resolution Protocol provides a mechanism for IP devices to locate the hardware addresses of other devices on the local network. This service is required in order for IP-enabled systems to communicate with each other.
Relevant STDs2 (http://www.iana.org/);
3 (includes RFCs 1122 and 1123);
37 (RFC 826, republished);
38 (RFC 903, republished)
Relevant RFCs826 (Address Resolution Protocol);
903 (Reverse ARP);
1122 (Host Network Requirements);
1433 (Directed ARP);
1868 (UnARP Extension);
2131 (DHCP and DHCP ARP);
2390 (Inverse ARP)

When two IP-enabled devices on the same network segment want to communicate, they do so using the low-level protocols and addressing mechanisms defined for the specific medium in use.

For example, Ethernet devices use Ethernet-specific addresses when they communicate with each other, while Frame Relay networks use Frame Relay-specific addresses.

In order for IP systems to communicate with each other, they must first be able to identify the hardware addresses of the other devices on the same network segment that the local device is on. This service is provided by the Address Resolution Protocol.

The ARP Standard

ARP is defined in RFC 826, which has been republished as STD 37 (ARP is an Internet Standard protocol). However, RFC 826 contained some vagaries which were clarified in RFC 1122 (Host Network Requirements). As such, ARP implementations need to incorporate both RFC 826 and RFC 1122 in order to work reliably and consistently with other implementations.

RFC 826 introduced the concept of an Address Resolution Protocol as a useful way for devices to locate the Ethernet hardware address of another IP host on the same local network. As it turns out, ARP is also useful for many network topologies—not just Ethernet—and has since become incorporated into most of the other network topologies. All LAN media—and many WAN media—now use ARP to locate the hardware addresses of other IP devices on the local network.

When a device needs to send an IP packet to another device on the local network, the IP software will first check to see if it knows the hardware address associated with the destination IP address. If so, then the sender just transmits the data to the destination system, using the protocols and addressing appropriate for whatever network medium is in use by the two devices. However, if the destination system's hardware address is not known, then the IP software has to locate it before any data can be sent. At this point, IP will call on ARP to locate the hardware address of the destination system.

ARP achieves this task by issuing a low-level broadcast onto the network, requesting that the system that is using the specified IP address respond with its hardware address. If the destination system is powered up and on the network, it will see this broadcast (as will all of the other devices on the local network), and it will return an ARP response back to the original system. Note that the response is not broadcast back over the network, but is instead sent directly to the requesting system.

This process is illustrated in Figure 3-1. In that example, Ferret issues an ARP request for the hardware address associated with 192.168.10.40 to the network-specific broadcast address in use on that LAN. When Froggy sees the ARP request, it unicasts an ARP reply (containing Froggy's hardware address) to Ferret directly. Having gained the information it needed, Ferret can then send whatever data it has for Froggy to that host's hardware address, using the protocols that are specific to the underlying network medium.

ARP packets work at the data-link layer, the same as IP packets. As such, ARP packets are completely separate from IP packets; they even have a different protocol ID of 0806, instead of 0800 as used with IP.

ARP packets contain several fields, although only five of them are used to provide the bulk of ARP's functionality: the hardware address of the source, the IP address

0099-01.gif
Figure 3-1.
An overview of ARP

of the source, the hardware address of the destination, the IP address of the destination, and a message-type field that indicates whether the current ARP packet is a request or a response to a request.

When a device issues an ARP request, it fills in three of the four address-related fields, providing its own hardware and IP address, as well as the IP address of the target (the target's hardware address is unknown, so that field is filled with zeroes). In addition, it will set the message-type field to indicate that the current packet is an ARP request, and then broadcast the request onto the local network for all devices to see.

All of the local devices should monitor the network for ARP broadcasts, and whenever they see a request for themselves (as indicated in the destination IP address field of the ARP request), they should generate a response packet and send it back to the requesting system. The response packet will consist of the local device's IP and hardware addresses (placed into the sender fields), and the IP and hardware address of the original sender (placed in the destination fields of the response packet). The response will also be marked as such, with the message-type field indicating that the current packet is an ARP response. The new ARP packet is then unicast directly to the original requester, where it is received and processed.

Note that there is no timeout for an ARP request. The packet is sent and that's all there is to it. If a response comes back, that's great. If not, then ARP itself does not care, although the IP stack itself probably does care, and will continue to issue ARP lookups. However, this is also dependent upon the implementation of ARP,

and how it deals with queuing. Many implementations only have room in the ARP lookup queue for a single packet for each of the hosts being queried. If an ARP request is not satisfied and another packet arrives from IP for the host being queried, then the first query will likely be aborted, and a second query will be issued. If the host is not responding to the ARP queries—but IP is trying to send multiple datagrams to that host—then there will be multiple queries for that host.

In this model, a higher-layer protocol such as TCP may notice that a problem has occurred and attempt a retransmission, which would in turn generate another IP packet (and another ARP request). Other protocols (such as UDP and ICMP) will not do this, however, and will simply treat a failed ARP lookup as a general timeout error (if a timer is being kept).

For example, if you try to use the ping program to test a host that is powered off, that host will not be able to respond to ARP broadcasts, and as such the local ICMP software will not be able to send an ICMP Echo Request message to the destination system. However, ping may continue generating ICMP Echo Request messages, which will result in multiple ARP lookups. ping may report timeout errors to the user for each of the failed lookups (since no response was received to the ICMP Echo Request message that was never actually sent over the network), although these errors will be generated by ping, and not by ARP.

The ARP Cache.

When the requesting system gets an ARP response, it will store the hardware and IP address pair of the requested device into a local cache. The next time that system needs to send data, it will check the local cache, and if an entry is found it will go ahead and use it, eliminating the need to broadcast another request.

Likewise, the system that responded to the ARP broadcast will store the hardware and IP addresses of the system that sent the original broadcast. If it did not do so, it would have to issue an ARP broadcast to find out where to send the ARP response.

Since all of the systems on the network will see the ARP broadcast, they could go ahead and capture the IP and hardware addresses of the sender, storing this information in their own caches. However, doing this might cause existing entries in the cache to be flushed (an especially problematic issue with systems that have small caches), so only those systems who already have the sender's IP address in their cache should update their entries. Hosts that do not already have the device in their cache should ignore the broadcast.

Cache size issues

Most systems have a very limited ARP cache, with only enough room for a few entries. These entries will be overwritten as needed—a problem for busy networks.

For example, if a client system frequently accesses a variety of different servers (one for mail, one for web, one for routing, one for database, etc.), and its ARP cache was smaller than the number of systems it was connecting to, then it would have to overwrite entries in the cache on a continual basis. It would issue an ARP broadcast, cache the result, and then overwrite that entry with the results from another ARP broadcast for a different system a few moments later. If this problem were multiplied by hundreds of devices, the network could theoretically become saturated with ARP broadcasts.

Likewise, if many clients are accessing a single server, and if the ARP cache on that server is too small to hold entries for all of the clients, then the ARP cache on the server may get flushed continually. This would require the server to issue ARP requests whenever it needed to send data back to the clients. This in turn would flush even more entries, forcing the cycle to be repeated endlessly.

Note that many large, multiuser systems and network routers have very large ARP caches to prevent these types of problems from occurring in the first place. For example, high-end Cisco routers have an ARP cache that is large enough to hold several hundred entries, since the router is likely to exchange data with each PC on the local network quite frequently. Having a large cache on these types of devices is essential to smooth operation, since otherwise the servers and routers could communicate with only a few PCs simultaneously.

Cache timeout issues

Systems should flush entries from the ARP caches after they have been unused for a while. This allows well-known IP addresses to be moved to a different machine—or for a well-known machine to be given a new IP address—without communication problems coming about due to stale (and invalid) address mappings. ARP cache timeout values that are too high will cause problems whenever a host is assigned a different IP address, since the other hosts who have an older entry in their caches will still try to send data to the old (and invalid) hardware address.

Conversely, an ARP timeout that is too short will also result in problems, especially on busy networks with lots of devices. If network clients are constantly flushing their ARP caches due to short timeout values, then many broadcasts will be required. This hurts performance, since the IP software will not be able to send any data until an ARP broadcast has been sent and responded to.

RFC 826 does not give a specific timeout value for ARP cache entries, so each vendor implements this value differently. On desktop PCs, the timeout value can be quite low, with entries expiring after just 120 seconds on Windows 95 systems. Conversely, many server-class systems will set the timeout value to be ten minutes or more, while some routers set the timeout as high as four hours. These types of systems typically benefit from having high timeout values, since the client systems do not change addresses very often, and provide their new hardware address whenever they switch to a new IP address (by issuing ARP queries).

You may need to ask your system vendor for the default ARP timeout value, or for instructions on how to change it. However, RFC 826 does state that if a device sees an ARP packet whose IP address is already in the cache, then any timeout clocks for that entry should be reset. This helps the already-cached data to survive for as long as possible.

Static caching

To get around some of the problems encountered with entries expiring and being over-written, many products provide tools for adding static entries to the cache that never expire. On some systems, static entries are cleared from the cache when the system is restarted, requiring they be added again, while on other systems the static entries are more or less permanent, remaining until they are manually purged or until space is needed in the cache.

There are some benefits that come from using static ARP entries. Some network administrators incorporate static entries into an overall network security strategy. By adding static ARP entries for every device on the network, an administrator can prevent someone from using somebody else's IP address to access a sensitive host. Another benefit of static cache entries comes from the elimination of frequent lookups, since clients will always have ARP cache entries for the servers they use most frequently.

However, this benefit can also cause management headaches if systems are moved or renumbered frequently. If the network adapter is changed on a server—or if a well-known IP address is moved to another computer—then the static cache entry for that device will be invalid on all of the systems that have it. Systems will be unable to communicate until the static entries have been purged.

Proxy ARP

Sometimes it is useful to have a device respond to ARP broadcasts on behalf of another device. This is particularly useful on networks with dial-in servers that connect remote users to the local network. In such a scenario, a remote user might have an IP address that appears to be on the local network, although the user's system would not be physically present (it would be at a remote location, connected through the dial-in server).

Systems trying to communicate with this node believe that the device was local, and would use ARP to try and find the associated hardware address. However, since the system is remote, it would not see (nor respond to) the ARP lookups.

Normally, this type of problem is handled through Proxy ARP, which allows a dial-in server to respond to ARP broadcasts on behalf of any remote devices it services.

Figure 3-2 shows a dial-up client connected to an Ethernet network using an IP address that is associated with the local Ethernet network. Whenever another device on the network needed to locate the hardware address of the remote user, it would issue an ARP Request for that IP address (as shown in step one in the figure), and expect an Ethernet address back in the ARP Response.

However, since the dial-up client is actually on a remote network, it would not see the ARP request (unless bridging were enabled over the connection, which is highly unlikely). Instead, Sasquatch should respond to the ARP Request on behalf of the dial-up system, providing its own Ethernet address in the ARP Response packet (as shown in step two in the figure). Essentially, Sasquatch would trick the other hosts into thinking that it was the remote system.

0103-01.gif
Figure 3-2.
An overview of Proxy ARP

Having gained the necessary information, the other devices on the local network could then start communicating directly with the communications server (using the low-level protocols appropriate for the medium). The communications server would accept the packets on behalf of the dial-up user, see that they were intended for the dial-up host (as shown in the destination address field of the IP header), and forward them on.

Some interesting problems can occur with Proxy ARP, especially in regards to mobile users who frequently connect and disconnect with multiple dial-in servers that share a modem pool or ISDN line. Whenever a client connects to an application server on the local LAN, ARP entries are stored in the server's cache, and if the user were to disconnect from the dial-up server and reconnect to another dial-up server on the same LAN (negotiating the same IP address for both connections), the application server's ARP cache entry for the client would still point to the first dial-up server's hardware address. This situation would prevent the application server from being able to communicate with the client, at least until the Proxy ARP entry in the server's cache was flushed. This particular problem can be resolved in a variety of ways, however, with the most common solution being the use of Gratuitous ARP on the dial-up servers in the pool.

Variations on the ARP Theme

Just as an IP device can locate the hardware address for a specific IP address, so can a device locate the IP address associated with a known hardware address. Two variations on ARP take advantage of this capability, although for very different purposes:

Inverse ARP
Inverse ARP works exactly the opposite of regular ARP. Rather than a device needing to find the hardware address associated with a known IP address, Inverse ARP is used to find the IP address for a known hardware address.

Reverse ARP
Reverse ARP is used to allow a diskless workstation to request its own IP address, simply by providing its hardware address in an ARP request broadcast. A Reverse ARP server will see this request, assemble an ARP response that contains an IP address for the requester to use, and then send it back to the requesting device. The workstation will then use this IP address for its networking activity.

In addition, three other variations on ARP have been developed that attempt to overcome some of the problems that have proven to be common on IP networks:

DHCP ARP
DHCP ARP is used by devices that obtain an IP address using an address-allocation protocol such as DHCP. The purpose of DHCP ARP is to allow the device to probe the network for any other device that may be using the assigned IP address already, prior to actually trying to use the address. This process helps prevent problems with duplicate or overlapping address assignments, as the requester can just reject the assignment if another device responds to the DHCP ARP query.

Gratuitous ARP
Gratuitous ARP is used when a device issues an ARP broadcast for the sole purpose of keeping other devices informed of its presence on the network.

There is no information gained by the requesting device in this scenario. However, other devices that already know about this device will update their cache entries, keeping them from expiring too quickly.

UnARP
Similarly, UnARP provides a mechanism for de-registering ARP entries. When a device wishes to leave the network, it can issue an UnARP broadcast, causing the other devices to clear their ARP caches of entries for this device.

DHCP ARP, Gratuitous ARP, and UnARP can each be extremely useful when managing networks that change frequently.

Inverse ARP (InARP)

The design goal for ARP was to allow an IP system to locate the hardware address associated with the (known) IP address of another system on a local network. Inverse ARP—which is documented in RFC 2390—works in the exact opposite manner, instead allowing a system to locate the IP address associated with a known data-link address. This feature is necessary when the devices are known to each other at the data-link layer, but the IP addresses of those systems are not known, which will prevent the two systems from being able to communicate with each other using IP. This is a common scenario on networks that share data-link addresses across different physical networks, such as Frame Relay and ATM.

Frame Relay networks are somewhat different from traditional networks in that the devices themselves do not have hardware addresses. Instead, the devices have addresses for each of the circuits that they are connected to (known as data-link connection identifiers, or DLCI addresses). Whenever a device needs to send data to another device, it sends the data to the DLCI address that is associated with the specific circuit that the destination device is available through.

From IP's point of view, if a device wants to send IP packets to another device on the Frame Relay network, then the sender must have an ARP cache of sorts that maps destination IP addresses to specific circuit identifiers, allowing the sender to transmit data for a known IP address through the correct Frame Relay circuit. Typically, Frame Relay access devices must be manually configured with this mapping information, showing that DLCI 153 is associated with the IP address of 192.168.30.122, for example. In this model, the sender is using a static ARP entry for each of the circuits that it is connected to. This scenario does not scale well, to say the least, particularly with Frame Relay networks that have hundreds of circuits (and therefore hundreds of IP-to-DLCI mappings).

This is the problem that Inverse ARP solves: by sending a query to each of the circuits that a device is attached to, a device can automatically build circuit-to-IP address mappings on a somewhat-automated basis. Once the destination systems on the far end of those circuits receive the Inverse ARP requests, they will respond with the IP address they are using on that specific circuit, allowing the sender to build these maps automatically.

Figure 3-3 provides a rough illustration of how this concept works. In that example, one of the devices wants to know the IP address of the other device at the far end of circuit 153, so it sends an Inverse ARP request through that circuit. The remote system sees the incoming request and responds with an Inverse ARP response that shows the IP address that is associated with that virtual circuit. Note that if the remote system were connected to multiple circuits, it would need to have different IP addresses for each of the circuits it were connected to (per-interface IP addresses are required in order for basic IP routing to work across the network).

0106-01.gif
Figure 3-3.
An overview of Inverse ARP

Every device on the Frame Relay network can go through this process, sending Inverse ARP requests through every circuit defined on the network, until all of the devices discover the IP addresses in use by all of the other devices. This information can then be used to build workable ARP caches for each of the systems. Note that these ARP entries should be treated the same as any other type of ARP data, with address pairs getting flushed or updated as needed by the system

owl.gif An interesting aside here is that Frame Relay circuits can have different circuit identifiers at each end, depending upon the number of switches in between the two end-points. In that scenario, the two end-points will have different circuit identifiers for the IP addresses in their ARP caches. For example, the sending router shown in Figure 3-3 may see the circuit as DLCI 153, while the recipient may see the circuit as DLCI 298. However, since the end-points only communicate with the circuit (and not with the remote system directly), the hardware address associated with the remote IP address is somewhat irrelevant.

Although the model put forth by Inverse ARP could be incorporated into Ethernet and other LAN-based topologies, it has not yet been done so to my knowledge. Generally speaking, there is no need for these services on a local network where every device shares the same physical medium. Frame Relay and ATM networks are unique in that devices can share a data-link connection while not being connected to the same physical network medium.

For more information on Inverse ARP, refer to RFC 2390. For more information on using IP with Frame Relay networks, refer to RFC 2427. For more information on using IP with ATM networks, refer to RFC 2225.

Reverse ARP (RARP)

Reverse ARP (RARP) is most often used with diskless workstations that do not have a permanent IP address, or that do not have sufficient resources for storing a permanent IP address. Whenever such a device needs to obtain an IP address for its own use (generally at boot time), it issues an ARP broadcast that contains its own hardware address in both the Sender and Recipient Hardware Address fields. Note that the Sender and Recipient Protocol Address fields would be zeroed out.

A special host (called a RARP server) watches for RARP broadcasts (RARP packets have their own unique ethertype of 8035). When one is seen, the server attempts to find an entry for the requesting device's hardware address in a local table of IP-to-hardware address mappings. If a match is found, it returns a RARP response to the requesting device, providing it with the IP address needed to continue the boot process. This process is illustrated in Figure 3-4.

0107-01.gif
Figure 3-4.
An overview of Reverse ARP

Although RARP was functional enough to be useful, it did not offer much in the way of comprehensive resource configuration. RARP did not provide for automatically determining the subnet mask in use on the network, the routers available, or much of anything else. For this reason, RARP is used much less frequently today than it has been in the past, with most devices having long ago moved to the BOOTP or DHCP configuration protocols for address-assignment and configuration services. You probably won't see it in use except on networks that have lots of older equipment.

For more information on RARP, refer to RFC 903.

DHCP ARP

One of the key differences between DHCP and RARP is that DHCP uses a shared pool of addresses when assignments are made, rather than using fixed entries like RARP does. This allows a network manager to share a limited number of IP addresses among a large number of hosts, instead of having to assign fixed addresses to each host. Although this makes life a little easier for the administrator in one sense, it can also make life more difficult, particularly when it comes to making sure that more than one device is not trying to use the same address at the same time. This is particularly problematic when users do not release the address they have been assigned and another device starts trying to use it, or when a user has manually configured his system to use a specific address that is also being assigned out of the DHCP pool.

In order to minimize the opportunity for this problem to occur, RFC 2131 (the DHCP RFC) stated that devices should verify the integrity of the address they are getting from the DHCP server before they accept the assignment. RFC 2131 also defined a specific ARP request format to be used for this purpose, in order to keep other systems from getting confused by the ARP request.

With DHCP ARP, the requesting device issues a normal ARP request, except that instead of putting its own IP address in the Source Protocol Address field, it puts in 0.0.0.0 . The rest of the packet looks like a normal ARP request, with the local hardware address in the Source Hardware Address field, the questionable IP address in the Destination Protocol Address field, and the Destination Hardware Address field containing zeroes.

This combination of fields serves two purpose. First of all, by providing the local hardware address in the Source Hardware Address field, a device that is already using the questionable address will see the ARP request and will be able to respond to it (ARP does not use IP for delivery, so it does not need an IP address for responses to work). At the same time, the lack of an IP address in the Source Protocol Address field prevents the other systems on the network from updating their ARP caches. Otherwise, the IP address provided in the Source Protocol

Address field would cause the other network devices to update any existing entry in their caches, even though another system may be using that IP address.

This process is demonstrated in Figure 3-5. In that example, Greywolf has been assigned an IP address from the DHCP server, but it tests the assignment using a DHCP ARP request before attempting to use it. In that case, it would create an ARP request packet, and set the Destination Protocol Address field to the address that it had been assigned by the DHCP server. Then it would fill the Destination Hardware Address and Source Protocol Address fields with zeroes.

0109-01.gif
Figure 3-5.
An overview of DHCP ARP

If Greywolf does not receive a response to the query, then it can assume that no other device on the local network is using that IP address, and start using it. If Greywolf did receive a response, however, then it should reject the IP address offered by the DHCP server, and restart the assignment process.

It is important to note that just because a client does not receive a response from a DHCP ARP request does not mean that the IP address is safe to use. For example, another device may have that address permanently configured, but may also be powered off at the moment the DHCP ARP was issued. When that device was powered back on, it would try to use the permanently assigned address, resulting in addressing conflict problems (such as reset TCP connections, unexpected ICMP messages, and other such problems). Furthermore, not every device understands the DHCP ARP format, and many older systems will just ignore an ARP request that has zeroes in the Source Protocol Address field. In fact, the UnARP protocol explicitly uses ARP responses instead of requests for just that reason.

RFC 2131 also suggests that clients should broadcast an ARP reply to announce the client's new IP address and clear any outdated ARP cache entries in hosts on the client's subnet. However, there is some confusion in regards to this clause. Most systems implement this type of functionality using the Gratuitous ARP mechanism, which uses a broadcast ARP request message (rather than an ARP reply)._. Although RFC 2131 clearly states that devices should issue ARP replies, many implementations will use an ARP request for this service.

For more information on DHCP ARP, refer to RFC 2131.

Gratuitous ARP.

Simply put, Gratuitous ARP is where a device broadcasts its own hardware and IP address pair, solely for the purpose of causing other devices to update their ARP caches. Remember that systems will not add new devices that they see in a broadcast (as this may cause the cache to flush more important entries). However, they will gladly update any entries that are already in the cache.

When a Gratuitous ARP request is broadcast, the sender puts its hardware and IP address information into the appropriate sender fields, and also places its IP address in the destination IP address field. It does not put its hardware address in the destination hardware field, however. Other devices on the network see this broadcast, and if they have the sender's information in their cache already, they either restart the cache entry's countdown timers or modify the entry to use the new hardware address (in case the network adapter on the sending host has been changed).

This process can be particularly useful with servers that communicate with many different clients frequently; the frequent use of Gratuitous ARP messages causes those clients to update their cache entries frequently, thereby keeping the clients from having to constantly reissue queries whenever they want to connect to this server. Furthermore, Gratuitous ARP messages can also be useful when a system frequently dials into a modem pool that is served by multiple communications servers, and the user has pre-selected an IP address to use for her connection. In that environment, the address being used may be associated with a different hardware address from one of the other communications servers (from one of the previous connections). By using Gratuitous ARP, the active dial-up server will ensure that all of the hosts on the LAN have the right hardware address in their ARP caches.

This process is illustrated in Figure 3-6, which shows Ferret issuing an ARP Request for its own IP address (192.168.10.10).

Nobody should reply to the ARP request, since nobody else should have the IP address listed in the destination field. If anybody does reply to the Gratuitous ARP

0111-01.gif
Figure 3-6.
An overview of Gratuitous ARP

broadcast, it would be because the responding host was also using the same IP address of the sending system. In this case, both systems should notice that there is an addressing conflict, and may choose to display a warning message on the system console stating that another host is using the local host's IP address.

In fact, many hosts use Gratuitous ARP whenever they come online just for this purpose, since it offers a cheap way to test for address conflicts on startup. Unfortunately, the use of Gratuitous ARP in this way can actually cause some problems to occur, and is not always a good idea. For example, if a misconfigured host issues a Gratuitous ARP for an IP address that is already in use by another device, then any clients who see that broadcast will update their ARP caches to use the new hardware address being published, even though the new mapping may point to the wrong host. From that moment on—or at least until the cache entries are updated—those clients will try to send data to the misconfigured host, rather than to the original (proper) host.

DHCP ARP is probably a better mechanism to use when testing for addressing conflicts on startup, since it allows the sender to detect whether or not another device is using the IP address before it actually tries to use it. Furthermore, the use of zeroes in the Source Protocol Address field prevents the other systems from updating their ARP caches with this host's information, which may be the more prudent choice.

UnARP

As discussed in The ARP Cache earlier in this chapter, there are no Time-to-Live mechanisms defined in the ARP standard. Each vendor implements its own ARP timers, ranging anywhere from two minutes to twenty minutes and more. This wide diversity can cause several problems.

For example, a DHCP client may be assigned an IP address, use it for a while, and then release it. Moments later, another client may be assigned the same IP address from the DHCP server. If any systems had the first DHCP client's hardware address stored in their cache, they would not be able to communicate with the new DHCP client.

One possible solution to this problem that has been proposed is UnARP, another variation on the ARP theme as defined in RFC 1868. UnARP dictates that a special ARP packet should be broadcast whenever a node disconnects from the network, explicitly telling other devices that the node is going away, and that the cache entry for that host should be flushed. This warning would allow another device (such as another DHCP client) to reuse the IP address immediately, without having to worry about stale caches causing any problems.

Essentially, UnARP is an unsolicited ARP response with zeroes in the Source and Destination Hardware Address fields that get broadcast across the network, as illustrated in Figure 3-7.

0112-01.gif
Figure 3-7.
An overview of UnARP

There are some key concepts to UnARP that are subtle enough to be easily missed:

Zeroes are used in the Source and Destination Hardware Address fields to indicate that no hardware address is associated with the IP address provided in the Source Protocol Address field. In addition, the Hardware Address Length field is also set to zero.

UnARP uses an ARP response packet rather than an ARP request packet. This is because UnARP uses zeroes in the hardware address fields, which could break lesser-bred ARP implementations that were expecting data in those fields. Since devices do not typically monitor for unsolicited ARP responses, support for UnARP would therefore require special code within the device, helping to minimize problems that might result from using zeroes in the hardware address fields.

Note that RFC 1868 is defined as an experimental RFC, and therefore many vendors do not support it. You should check with your vendor to see if it is among those that do.

For more information on UnARP, refer to RFC 1868.

The ARP Packet

An ARP packet works at approximately the same layer as IP. It communicates with the data-link services provided by the physical medium, and as such, ARP is a separate protocol than IP (and is identified separately by any network that both categorizes the protocols being carried in the low-level frames and supports ARP directly). The ethertype for ARP is 0806 as opposed to the ethertype for IP, which is 0800.

According to RFC 826, an ARP packet is made up of nine fields. The total size of the packet will vary according to the size of the physical addresses in use on the local network medium.

The fields in an ARP packet are listed in Table 3-1.

Table 3-1. The Fields in an ARP Packet
Header FieldBytesUsage Notes
Hardware Type2Identifies the medium-specific address type being requested.
Protocol Type2Identifies the higher-layer protocol information being discussed (which is always IP as far as we're concerned).

Table 3-1. The Fields in an ARP Packet (continued)
Header FieldBytesUsage Notes
Hardware Address Length1Specifies the size of the physical medium's hardware address, in bytes. Since each network uses different physical addressing mechanisms, this field is required for other fields further in the ARP packet.
Protocol Address Length1Specifies the size of the higher-layer protocol's address, in bytes. This is always 4 (32 bits) for IP.
Message Type2Identifies the purpose for this ARP packet ( request or response ).
Source Hardware AddressvariesIdentifies the hardware address of the system issuing the ARP broadcast.
Source IP AddressvariesIdentifies the higher-layer protocol address of the system issuing the ARP broadcast. This field's value will be 4 when IP is in use.
Destination Hardware AddressvariesIdentifies the hardware address of the system responding to the ARP broadcast.
Destination IP AddressvariesIdentifies the higher-layer protocol address of the system responding to the ARP broadcast. This field's value will be 4 when IP is used.

Notice that the ARP packet's format does not provide Time-to-Live or Version fields. This deficiency has caused a considerable amount of difficulty. Since there is no Time-to-Live field, every implementation uses its own cache timeout mechanisms, which results in inconsistent views of the network. Also, since there is no Version field, it is not possible to change the protocol's structure (such as adding a Time-to-Live field) without causing incompatibilities between the different implementations.

Figure 3-8 shows a capture of two ARP packets: an ARP Request from Ferret to the local broadcast address, and an ARP Response from Krill back to Ferret. These two packets will be used to illustrate the ARP packet throughout the rest of this section.

The following sections discuss the fields of the ARP packet.

Hardware Type

Identifies the hardware address type being requested, in decimal format. This would be 1 for DIX-Ethernet, 6 for IEEE 802.x Ethernet, 7 for ARCnet, etc.

Size
Sixteen bits.

Notes
Since ARP is used for getting the hardware address associated with an IP address—and some systems allow an IP address to be associated with multiple types of hardware—there must be a way to request the specific type of

0115-01.gif
Figure 3-8.
Two ARP packets
hardware address desired. Two devices on the same Ethernet LAN would want to communicate using the Ethernet-specific addresses, and the ARP request needs to be able to ask for that kind of address specifically.
The Hardware Type field uses decimal codes to indicate the address type being requested. Some of the more common hardware types are listed in Table 3-2. For a detailed listing of all of the known hardware types that are currently registered for ARP, refer to the IANA's online registry (accessible at http://www.isi.edu/in-notes/iana/assignments/arp-parameters).
Table 3-2. The Hardware Types Listed in RFC 1700 (Internet Assigned Numbers)
Hardware TypeDecimal Code
DIX-Ethernet and FDDI1
IEEE 802 (includes 802.3 Ethernet and 802.5 Token Ring)6
ARCnet7
LocalTalk11
SMDS (Switched Multimegabit Data Service)14
Frame Relay15
ATM (Asynchronous Transfer Mode)19
Serial Line20

Capture Sample
In the capture shown in Figure 3-9, the Hardware Type field is set to hexadecimal 0001, the code for DIX-Ethernet.

0116-01.gif
Figure 3-9.
The Hardware Type field

See Also
Hardware Address Length

Source Hardware Address
Destination Hardware Address

Protocol Type (IP)

Identifies the higher-level protocol in use. For the purpose of this book, this field always contains the topology-specific identifier for the IPv4 protocol.

Size
Sixteen bits.

Notes
Since ARP talks to the physical medium's data-link interface directly, it is not tied specifically to IP and can be used by any higher-level protocol seeking the hardware address associated with a higher-level protocol address (such as IPX, or DECnet, or whatever). For this reason, the Protocol Type field must

define the higher-level protocol the request is referring to (which is always IP, as far as this book is concerned).
For Ethernet networks, the value for IP would be hexadecimal 0800 (which equates to the decimal value of 2048, the Protocol Type for IP).

Capture Sample
In the capture shown in Figure 3-10, the Protocol Type is set to hexadecimal 0800, the code for IP.

0117-01.gif
Figure 3-10.
The Protocol Type field

See Also
Protocol Address Length

Source Protocol (IP) Address
Destination Protocol (IP) Address

Hardware Address Length

Specifies the length (in bytes) of the hardware addresses provided in the Source and Destination Hardware Address fields.

Size
Eight bits.

Notes
Since each network uses different physical addressing mechanisms, this field is required in order to make sense of the Source and Destination Hardware Address fields further in the ARP packet. Table 3-3 shows some of the most common hardware types and the sizes of their hardware addresses (in bytes).

Table 3-3. The Address Sizes of Some Hardware Types
Hardware TypeSize (Bytes)
Digital-Intel-Xerox (DIX) Ethernet6
IEEE 802.3 Ethernet6
IEEE 802.5 Token Ring6
ARCnet1
FDDI6
Frame Relay2, 3, or 4
SMDS8

Capture Sample
In the capture shown in Figure 3-11, the Hardware Address Length field is set as hexadecimal 06, which indicates that the Source and Destination Hardware Address fields are six bytes (or 48 bits) long, the norm for DIX-Ethernet.

0118-01.gif
Figure 3-11.
The Hardware Address Length field

See Also
Hardware Type

Source Hardware Address
Destination Hardware Address

Protocol Address Length

Specifies the length (in bytes) of the higher-level protocol address found in the Source and Destination Protocol Address fields. For IP, this value is always 4 (32 bits / 8 = 4 bytes).

Size
Eight bits.

Notes
ARP can be used with many different higher-level protocols (ARP isn't restricted to IP), and since each higher-level protocol uses different addressing mechanisms (IP addresses are considerably different from IPX and DEC-net addresses), this field is required in order to make sense of the Source and Destination Protocol Address fields further in the ARP packet.

When IPv4 is specified in the Protocol Type field, the value of the Protocol Address Length field is always 4, since IP addresses are 32 bits (four bytes) long.

Capture Sample
In the capture shown in Figure 3-12, the Protocol Address Length field is set to hexadecimal 04, indicating that the Source and Destination Protocol Address fields are four bytes (or 32 bits) long, the norm for IP.

See Also
Protocol Type (IP)

Source Protocol (IP) Address
Destination Protocol (IP) Address

Message Type

Identifies the purpose for this ARP packet.

Size
Sixteen bits.

Notes
ARP by itself supports two basic operations: a request for the hardware address associated with a protocol address, and a response to an earlier request. Similarly, RARP also supports the notion of request and response operations, as does Inverse ARP.

0120-01.gif
Figure 3-12.
The Protocol Address Length field
The Message Type field is used to inform other systems on the local network which of these operations are being called upon. Table 3-4 lists the Message Type codes and their uses.
Table 3-4. ARP Message Type Codes and Their Meanings and Uses
Message TypeUsage Notes
1ARP Request
2ARP Response
3Reverse ARP Request
4Reverse ARP Response
8Inverse ARP Request
9Inverse ARP Response

If an ARP packet contains an ARP request (or if the packet is for a Gratuitous ARP), then the Message Type field will be set to 1. If the ARP packet contains an ARP response (or if the packet is for an UnARP operation), then the Message Type field will be set to 2. RARP uses 3 for requests and 4 for responses, while Inverse ARP uses 8 and 9, respectively.

Capture Sample
In the capture shown in Figure 3-13, the Message Type field is set to hexadecimal 0001, which indicates that this packet is an ARP Request.

0121-01.gif
Figure 3-13.
The Message Type field

Source Hardware Address

Identifies the hardware address of the system issuing the ARP packet. The packet may be either a request or a response.

Size
Varies according to the physical medium in use. Refer back to Table 3-3 for a listing of the most common hardware addresses and their lengths.

Notes
Every ARP exchange consists of two distinct packets: the original request and a response to the request. The Source Hardware Address field indicates the sender of this specific ARP packet. If the ARP packet is a request, then this field contains the hardware address of the device that is sending the request. If the ARP packet is a response, then this field contains the hardware address of the device that is sending the response.

Capture Sample
In the capture shown in Figure 3-14, the Source Hardware Address field is set to 00:20:af:eb:63:56, which is the 48-bit Ethernet address of the sender, in hexadecimal.

0122-01.gif
Figure 3-14.
The Source Hardware Address field

See Also
Hardware Type

Hardware Address Length
Destination Hardware Address

Source Protocol (IP) Address.

Identifies the higher-level address of the system issuing the ARP packet. The packet may be either a request or a response.

Size
Varies according to higher-level protocol in use. With IP, this field is four bytes (32 bits) long.

Notes
Every ARP exchange consists of two distinct packets: the original request and a response to the request. The Source Protocol Address field indicates the

sender of this specific ARP packet. If the ARP packet is a request, then this field contains the IP address of the device that is sending the request. If the ARP packet is a response, then this field contains the IP address of the device that is sending the response.

Capture Sample
In the capture shown in Figure 3-15, the Source Protocol Address shows the 32-bit IP address of 192.168.10.10.

0123-01.gif
Figure 3-15.
The Source Protocol Address field

See Also
Protocol Type (IP)

Protocol Address Length
Destination Protocol (IP) Address

Destination Hardware Address

Identifies the hardware address of the ARP packet's destination, which could be either a broadcast (as used in requests) or a specific system (as used in responses).

Size
Varies according to the physical medium in use. Refer back to Table 3-3 for a listing of the most common hardware addresses and their lengths.

Notes
Every ARP exchange consists of two distinct packets: the original request and a response to the request. The Destination Hardware Address field indicates the recipient of this specific ARP packet. If the ARP packet is a request, then this field will probably be empty, since the hardware address is unknown. If the ARP packet is a response, then this field contains the hardware address of the device that sent the original request.

Capture Sample
In the capture shown in Figure 3-16, the Destination Hardware Address is set to hexadecimal 00:00:00:00:00:00, indicating that the sender does not know the destination system's hardware address (as is normal with ARP request packets).

0124-01.gif
Figure 3-16.
The Destination Hardware Address field

See Also
Hardware Type

Hardware Address Length
Source Hardware Address

Destination Protocol (IP) Address

Identifies the higher-level protocol address of the ARP packet's destination. The packet may be either a request or a response.

Size
Varies according to higher-level protocol in use. With IP, this field is four bytes (32 bits) long.

Notes
Every ARP exchange consists of two distinct packets: the original request and a response to the request. The Destination IP Address field indicates the recipient of this specific ARP packet. If the ARP packet is a request, then this field will contain the IP address of the device being looked up. If the ARP packet is a response, then this field will contain the IP address of the device that sent the original request.

Capture Sample
In the capture shown in Figure 3-17, the Destination Protocol Address field is set to the IP address of 192.168.10.80.

0125-01.gif
Figure 3-17.
The Destination Protocol Address field

See Also
Protocol Type (IP)

Protocol Address Length
Source Protocol (IP) Address

ARP in Action

ARP is an extremely simple protocol. There are no headers or timers or anything else. Nor is there any negotiation or identification management: ARP packets get sent but they aren't tracked or managed in any shape or form.

A Typical Exchange

The ARP captures shown in Figure 3-18 and Figure 3-19 represent a typical ARP exchange.

0126-01.gif
Figure 3-18.
An ARP request from Ferret, seeking Krill's hardware address

The packet shown in Figure 3-18 is an ARP request from Ferret, seeking the hardware address associated with 192.168.10.80. The devices are on a DIX-Ethernet segment, and are so identified by the Hardware Type field being set to 1. Furthermore, the Hardware Address Length field is set to 6, which equals the 48-bit hardware addresses used by DIX-Ethernet. In addition, the devices are using IP for their higher-level protocol, so the Protocol Type field is set to hexadecimal 0800 while the Protocol Address Length field is set to 4, which represents the 32-bit addresses used by the IP protocol.

Since the packet shown in Figure 3-18 is an ARP request, the sender puts its IP address (192.168.10.10) and Ethernet address (00:20:af:eb:63:56) into the Sender-related fields, puts the destination system's IP address (192.168.10.80) into the Destination IP Address field, and puts zeroes into the Destination Ethernet Address.

The packet shown in Figure 3-19 is the ARP response that was returned for the ARP Request shown in Figure 3-18. This packet is coming from Krill (Ethernet address of 08:00:2b:2f:ef:78) and is being sent directly to Ferret.

0127-01.gif
Figure 3-19.
An ARP response from Krill back to Ferret

Notice that the response message has taken the source-related data from the original packet and has placed it into the destination-specific fields of the response packet. In addition, the ARP response also has the 48-bit DIX-Ethernet address associated with the requested IP address, as well as the IP address itself. Once this packet arrived back to Ferret, it would update its local ARP cache with this mapping, and keep it there until it was updated by another ARP packet, had expired, or the cache space was needed by another mapping.

Notes on DHCP ARP

RFC 2131 (the DHCP specification) defined a special type of ARP request that could be used to probe the network whenever an IP address had been assigned from DHCP, in case another device on the network was already using that IP address. This is an important service, since DHCP allows multiple devices to share an IP address, although those devices are not supposed to use the same IP address at the same time. In order to keep problems to a minimum, the use of the DHCP ARP probe allows a device to verify that no other devices are using the IP address before this device starts to do so.

The DHCP ARP packet looks like a regular ARP request packet, except that the Source Protocol Address field of the request is set to 0.0.0.0. This is done to prevent the ARP caches on other devices from being updated with any new information, since that only happens when the Source Protocol Address field contains an IP address that is already in the cache. If the DHCP client issued a regular ARP request (or a Gratuitous ARP request) for the assigned IP address using that same address in the Source Protocol Address field, then the other network devices would update their ARP caches to show the sender's hardware address, which would cause problems if another device on the network was still using that IP address (whether or not such usage was legitimate).

Figure 3-20 shows the host Fungi issuing a DHCP ARP request to the network for the IP address of 192.168.20.60 (which is the IP address it has been assigned by the DHCP server). Notice that the Source Protocol Address field is set to 0.0.0.0 (as specified by RFC 2131), while the Destination Hardware Address field is filled with zeroes, and the Destination Protocol Address field is set to the IP address being probed (as specified by the ARP specification).

Since the DHCP ARP request packet contains a Source Hardware Address field that points to Fungi's own Ethernet address, any device that was using the IP address specified in the Destination Hardware Address field could respond to the request with a unicast ARP response packet. If such a response were received, then RFC 2131 states that Fungi should reject the DHCP lease, and then restart the address-assignment procedure.

If no response was received, then Fungi could assume that no other hosts were using this IP address, and could begin using it for its networking services. However, this can be a fatal assumption, since responses may have failed to be sent (or received) for a variety of different reasons, ranging from physical-layer bridges that do not forward broadcasts, to the conflicting device being powered off at the moment the ARP request was issued.

In addition, RFC 2131 states that upon successfully completing the DHCP ARP process, Fungi should broadcast an ARP response to its own DHCP ARP message. By

0129-01.gif
Figure 3-20.
A DHCP ARP request packet

broadcasting the ARP response, other devices on the network would see the new Source Hardware Address and Source Protocol Address mapping, and update any entries in their ARP caches for that IP address, thereby preventing any other problems from occurring as a result of stale ARP entries.

However, most implementations do not broadcast an ARP response, but instead broadcast a new Gratuitous ARP. This is because many older systems do not process an ARP response that is not intended for the local machine directly. Therefore, the use of the broadcast request form that is typical of Gratuitous ARP packets is more widely accepted and offers a better chance of the intended operation succeeding.

For more information on DHCP ARP, refer to DHCP ARP earlier in this chapter. For more information on Gratuitous ARP, refer back to Gratuitous ARP also in this chapter, and refer ahead to the next section, Notes on Gratuitous ARP (the latter of which shows a Gratuitous ARP being issued by Fungi after the DHCP ARP shown in Figure 3-20 was sent).

Notes on Gratuitous ARP

As we discussed in The ARP Cache earlier in this chapter, one of the biggest problems that come from devices that maintain hardware-to-IP address mappings in their local ARP caches for long periods of time is the fact that devices can and do change hardware or IP addresses. But the other devices will not be able to communicate with those systems until the ARP cache entries have expired or been replaced.

This process is particularly problematic for systems that act as servers for a network (perhaps sharing email or database services), since many clients may be trying to communicate with that system but will not be able to, due to stale ARP cache entries. Another problem that can occur quite frequently comes from dial-up clients who always negotiate a fixed IP address, regardless of the dial-up server they connect to. In that situation, the servers on the network may still have ARP cache entries for the last dial-up server that the user connected through, and will therefore be unable to communicate with the client through the new connection.

In both of these examples, stale ARP cache entries are causing fundamental communication problems, as the network devices try to send IP packets to the old hardware address associated with the destination IP address. Gratuitous ARP offers a solution to this problem by allowing devices to broadcast an ARP query for their own IP address. When this happens, other devices on the network will see the Source Hardware Address and Source Protocol Address fields in the request, and will update any entries for that IP address that are already in their ARP caches. Devices who do not already have a mapping in their cache will simply ignore the packet.

This concept is illustrated in Figure 3-21. In that example, Fungi is issuing a Gratuitous ARP to the local network, providing its own IP address in both the Source and Destination Protocol Address fields, as well as providing its own hardware address in the Source Hardware Address field.

Notice also that the Destination Hardware Address field contains the topology-specific broadcast address (FF:FF:FF:FF:FF:FF for DIX-Ethernet in this example), rather than the all-zeroes address that is normally used with ARP requests. This is a common feature found with implementations that use Gratuitous ARP whenever they are initialized.

Any device that sees this broadcast—and that also has a cache entry for the IP address of 192.168.20.60—updates its ARP cache to reflect the hardware address being provided in the Source Hardware Address field. Devices that do not have an entry for that IP address in their caches will simply ignore the packet.

A point worth making here is devices that have this Source Hardware Address in their ARP caches—but that do not have the Source Protocol Address in their cache—will still ignore the message. The ARP specification does not make any provisions for devices to update their ARP caches based on an existing hardware

0131-01.gif
Figure 3-21.
A Gratuitous ARP advertisement

address. Instead, if this device has been given a new IP address, then it is to be treated as a new entry in the ARP cache.

Although some implementations also use Gratuitous ARP broadcasts to detect addressing conflicts, this is not a particularly good idea, since it causes any existing entries in the ARP caches to be overwritten with the new data. Since the new device may be the one that is misconfigured, this updating action causes any other devices on the network that have rightfully updated their caches to have entries for the wrong device.

For this reason, devices should use the DHCP ARP mechanism for the purpose of detecting IP address conflicts, rather than using Gratuitous ARP broadcasts. Since DHCP ARP broadcasts only use 0.0.0.0 in the Source Protocol Address field, they do not cause other devices to update their ARP caches.

For more information on Gratuitous ARP, refer to Gratuitous ARP earlier in this chapter. For more information on DHCP ARP, refer to DHCP ARP and Notes on DHCP ARP , both found earlier in this chapter (the latter of which shows Fungi issuing a DHCP ARP request in an effort to detect any other devices that are already using the IP address of 192.168.20.60).

Debugging ARP Problems

Since ARP is such a simple protocol, there aren't many problems that can crop up with it. Most of the problems that do arise are exhibited elsewhere. You probably wouldn't know that a problem was directly related to ARP unless you knew what some of the common symptoms were.

In addition, it is important to keep in mind that ARP can fail on its own, yet not appear to be an ARP-related problem. If the destination host specified in the original ARP request were down or otherwise unreachable, then it obviously would not receive (nor respond to) the original request. In such a case, the original sender would be unable to get a hardware address and would therefore be unable to send any IP packets to the destination device.

This is a substantially different concept from the host being able to send data to the recipient, even if that data is being ignored. While it may seem irrelevant (we can't send data in either case), it is an important distinction.

If a host wanted to send data to another system, then it would first have to get the hardware address. If it could not get the hardware address, then no IP data would get sent at all. Under normal circumstances, it would be able to get the hardware address although IP delivery might still fail. An application should be able to tell the difference between these two types of failures, as they may have different ramifications for the end user.

For example, if you try to use the ping program to test a host that is powered off, that host will not be able to respond to ARP broadcasts, and as such the local ICMP software will not be able to send an ICMP Echo Request message to the destination system. So, the ICMP software may return timeout errors to the user through the ping application. This is a different failure from the host taking too much time to respond, from routing errors preventing the ICMP packets from being sent or returned successfully, or from any other form of errors that may be keeping ping from working properly. Instead of ICMP failing (as the results might indicate), the truth would be that the sending system was the one having problems. This is a subtle but important difference, and one that should be kept in mind when diagnosing connectivity problems.

Lots of ARP Requests from Network Clients

If you have a lot of ARP requests from network clients, then you probably have too small of a cache on the client systems. Most client systems have a very small ARP cache, and will gladly flush through it on a continuous basis if you force them to connect to a multitude of servers. Either refer to your system documentation for instructions on how to increase the ARP cache, or else replace the IP software you have with something better.

Increasing the size of ARP cache may cause other problems for the client, due to an increased demand for memory, CPU time, and other resources. Another option for you to consider is to consolidate a multitude of servers into a single large system.

Frequent flushing of cache data at the client can also result when ARP timeout values are set too low. If your clients only check email every thirty minutes, but the ARP timers expire after twenty minutes, then the clients will have to issue ARP requests every time they check their mail. On a large network with hundreds of devices per segment, this activity can generate a substantial amount of traffic. You may want to either lengthen the cache timeout values or implement a periodic Gratuitous ARP process on the servers.

Bursted Duplicate ARP Requests.

Whenever a system tries to send data to a local destination system that does not have an entry in the sender's ARP table, the ARP module on the sender will try to locate the device's hardware address using an ARP query. If the sender tries to send a lot of packets to that destination system in a burst, then the ARP module may end up issuing several queries in a burst as well.

Although RFC 1122 recommends that ARP not issue duplicate lookups at a rate faster than once per second, some systems ignore this recommendation and cause each of the generated IP packets to also trigger an immediate ARP request. Some systems will wait for at least one second before issuing a subsequent ARP lookup, although those systems still may lose data as the higher-layer protocol continues to submit data faster than this.

Most ARP agents can only keep track of one lookup to any given host at a time. As such, if they receive an IP packet for a device while an ARP lookup for that device is already in progress, then the first packet in the ARP queue will get destroyed, and another lookup may get generated for the second packet. If the end-point applications are not using TCP or some other reliable protocol, then the packet will be lost forever. This situation is particularly problematic with ICMP-and UDP-based applications that generate many IP packets in a single operation. For more information on those scenarios, refer to First Packet from ping Always Fails in Chapter 5, The Internet Control Message Protocol, and Datagrams Are Corrupted or Never Sent in Chapter 6, The User Datagram Protocol.

Clients can't Connect to Network Resources

If your DHCP clients are coming and going frequently (due to short DHCP lease timers or due to clients releasing their leases when they aren't needed), then it is likely that you will encounter connectivity problems due to old entries in other systems' ARP caches.

You may also encounter this problem with users who frequently connect and disconnect from multiple dial-in servers on the same Ethernet LAN, and who always use the same IP address regardless of the dial-in server that they connect to. Since these servers will provide Proxy ARP services to the remote users, it is highly likely that the ARP caches on the various network devices will get out-of-synch at some point.

One solution to this problem would be to cut back on your DHCP or dial-in lease activity. Essentially, this solution suggests that you try to minimize the hardware and IP address changes, and do your best to keep them synchronized for as long as possible.

Another option would be to seek out DHCP and dial-in servers that support UnARP or Gratuitous ARP. UnARP would cause the cache entries on the local devices to get flushed when the DHCP or dial-in addresses were released, while Gratuitous ARP would update any devices on the local network with the new hardware address associated with the dial-up system's IP address.

ARP Tables Are Fine, but Still No Connections

It is entirely possible that a device has responded to an ARP request packet, but that the device is not on the network. How can this be? Proxy ARP. Check to see if a device is responding to ARP requests on behalf of a non-local system.




Internet Core Protocols. The Definitive Guide with Cdrom
Internet Core Protocols: The Definitive Guide: Help for Network Administrators
ISBN: 1565925726
EAN: 2147483647
Year: 1999
Pages: 17
Authors: Eric Hall

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net