Welcome to Jeremy’s IT Lab. This is a complete course for the CCNP ENCOR, Enterprise Core, exam. This course will cover all topics you need to know to pass the ENCOR exam. In the previous few videos we looked at Layer 2 and Layer 3 forwarding. In this video we will look at the bridge between them: ARP, Address Resolution Protocol. Of course, ARP is something you should know already from your CCNA studies. However, even though ARP is a fairly simple protocol there is still some depth to it that we didn’t cover in the CCNA course. So, in this video let’s dig a little deeper into ARP, which is an essential protocol in modern networks. Here’s what we’ll cover in this video. First, I’ll give a brief overview of why we need Layer 2 and Layer 3 addresses. Then I’ll introduce ARP, originally defined in 1982 and still in use today. Then I’ll introduce the ARP message format, as well as the basic ARP process. I will then introduce proxy ARP, a type of ARP I didn’t mention in the CCNA course, and gratuitous ARP, which I did mention in the CCNA course but we will review it here. Then we will take a look at how ARP is implemented in Cisco IOS, and we’ll learn some configuration and SHOW commands. So, why do we need addressing at Layer 2 and Layer 3? Layer 2 and Layer 3 addressing provide different functionality, and both are essential for modern networks to function. Layer 3 provides end-to-end addressing, from the source host to the destination host. The Layer 3 address, typically an IPv4 or IPv6 address, is a logical address configured by a network admin, whether it is manually configured or dynamically assigned via DHCP. Layer 3 addressing deals with indirectly, as well as directly, connected devices. At Layer 3 you can address a packet to destinations in the same network, for example another host connected to the same switch, as well as to destinations in different networks, for example a host somewhere over the Internet. Layer 2 provides hop-to-hop addressing within each network segment, for example the hop from the source to its default gateway, then the hop from that router to the next router, then the hop from that router to the next router, etc. The Layer 2 address is the physical address of each NIC, Network Interface Card, as assigned by the manufacturer, although it is possible to configure a different MAC address, but that’s rare. Layer 2 deals with directly connected devices, not necessarily connected with the same cable but connected to the same Layer 2 domain, for example hosts connected to the same switch. The Layer 3 packet is destined for the end host, and Layer 2 addressing is used to pass the packet to the next hop in the path to the end host. So, as shown in the previous video when PC1 in the below diagram communicates with PC2, the source and destination IP addresses remain the same throughout the journey. However, at this first hop the frame is from PC1 to R1 G0/1, then at the second hop the frame is from R1 G0/0 to R2 G0/0, then at the third hop the frame is from R2 G0/1 to R3 G0/0, and finally at the final hop it is from R3 G0/1 to PC2. Layer 2 and Layer 3 work together to successfully deliver the packet to the destination host. Now let’s get into ARP, first a brief one-slide review of what ARP is. ARP is the bridge between Layer 2 and Layer 3; it is used to map a known Layer 3 address to an unknown Layer 2 address. Now, how is the Layer 3 address known? For example, an end host will know the IP address of its default gateway either via DHCP or manual configuration. A router will know the next hop IP address by checking its routing table, etc. ARP was originally defined in RFC 826 back in 1982, the title was An Ethernet Address Resolution Protocol, or Converting Network Protocol Addresses to 48 bit Ethernet Address for Transmission on Ethernet Hardware. As these titles suggest, the ARP protocol was designed for Ethernet, but actually it can be used with a variety of Layer 2 and Layer 3 address types. However, for this video we will be talking about mapping IPv4 addresses to Ethernet MAC addresses, because that is by far the most common use of ARP. In ARP, the sending device will use ARP to learn the MAC address of the next hop IP address, and note that that isn’t necessarily the destination IP address of the packet it wants to send. For example, in the network below when PC1 wants to send a packet destined for PC2’s IP address, it won’t use ARP to learn PC2’s MAC address. It will use ARP to learn the MAC address of R1’s G0/1 interface, its default gateway. And note that ARP information is stored in a cache so ARP doesn’t have to be done for every single packet. If ARP had to be done for each individual packet, that would add a lot of unnecessary overhead, an ARP request and reply for each packet. Instead, after ARP is used to learn a MAC address, that information is stored in the device’s ARP table for quick lookup for future packets. So let’s look at the process of PC1 sending a message to PC2 once more, this time with ARP included. PC1 wants to send this packet to 10.0.3.10, PC2. It knows PC2 is in a different subnet, so it must send the packet to its default gateway R1 for routing. It knows R1’s IP address either because it learned it via DHCP or it was manually configured on PC1, so PC1 sends an ARP request asking ‘what is the MAC of 10.0.1.1?’, to which R1 replies with its MAC address. PC1 is then able to populate the destination MAC field of the frame with R1’s G0/1 MAC address and send the frame to R1. Note that, as I mentioned before, PC1 didn’t use ARP to learn the MAC address of the destination IP of the packet it wants to send, PC2’s IP, but rather to learn the MAC address of the next hop, which is its default gateway. Now R1 has the responsibility of sending the frame to the next hop. It looks up the destination IP in its routing table. There it learns that the next hop IP address is that of R2’s G0/0, so it sends an ARP request to learn the MAC address of 10.0.12.2, to which R2 replies. R1 can then populate the destination MAC field of the frame and forward it to R2. Now R2 has the packet and needs to forward it to the next hop, R3. By checking its routing table it knows the IP address of the next hop, that of R3’s G0/0 interface. It uses ARP to learn the MAC address associated with that IP address, uses that MAC as the destination of the frame and forwards it to R3. Now the frame is at R3. When checking its routing table, R3 notices it has a directly connected route to the 10.0.3.0/24 subnet, which includes the destination of 10.0.3.10, PC2. So it uses ARP to learn the MAC address of PC2, and then forwards the frame to the final destination, PC2. Okay, now let’s dig deeper into ARP and cover some things you might not know about it yet. Let’s look at the ARP message format. ARP messages are encapsulated directly within an Ethernet header and trailer, as you can see in this diagram. So there is no IP header when sending an ARP message, just the ARP message inside an Ethernet frame. The EtherType, meaning the Type field of the Ethernet header, will be hexadecimal 0806 to indicate ARP. Some other common EtherTypes are 0800 for IPv4 and 86DD for IPv6. Note that ARP messages are variable in length because ARP can be used for various Layer 2 and Layer 3 protocols, not just IPv4 and Ethernet. But note that an IPv4 and Ethernet ARP message is 28 bytes in length. So, what are the actual contents of an ARP message? Let’s take a look. This is the format of an ARP message, thanks to Wikipedia for the diagram. It’s actually quite simple so let’s go through each field, although keep in mind you don’t have to memorize these fields, just understanding them is enough. First up is the Hardware Type field, which indicates the Layer 2 protocol type. A value of 1 in this field indicates Ethernet. Then there is the Protocol Type field, which indicates the Layer 3 protocol. Typically you’ll see hexadecimal 0800, which you can also write as decimal 2048, to indicate IPv4. Note that this was designed to align with the EtherType value for IPv4, which is also hex 0800. The Hardware Address Length field indicates the length of the Layer 2 address in bytes. For example MAC Addresses are 6 bytes in length, so the value of this field will be 6. The Protocol Address Length field indicates the length of the Layer 3 address in bytes. IPv4 addresses are 4 bytes in length, so usually you’ll see a value of 4 here. Then the Operation field indicates the type of ARP message. There are multiple different types but the only ones you need to know are 1 for ARP Request and 2 for ARP Reply. All ARP messages use this same message format, so it’s this field that says exactly what type of ARP message it is. Then the Sender Hardware Address field indicates the Layer 2 address of the sender, and the Sender Protocol Address field indicates the sender’s Layer 3 address. Finally we have the Target Hardware Address field indicating the Layer 2 address of the intended receiver and the Target Protocol Address field indicating the intended receiver’s Layer 3 address. And that’s it, as I just mentioned all ARP messages have this same format. You don’t need to memorize the fields or their length and order, but understanding them definitely helps you understand ARP itself. We will review these fields again when we look at ARP packet captures in a few minutes. Now let’s move on and look at the ARP process in greater detail. When a host wants to send a packet, it needs to encapsulate it in a frame. To learn the appropriate destination MAC address it must check the ARP cache, which is just another way to say the ARP table, for an entry matching the ARP Destination Host’s IP. Note that ‘ARP Destination Host’ means the destination of the ARP Request, not necessarily the actual destination host that the source wants to send a packet to. If there is already an appropriate entry in the ARP cache, there’s no need to proceed with ARP. The source host can encapsulate the packet and send the frame. But if there is no entry, it will first create an ‘incomplete’ entry in the ARP cache. Incomplete means that an entry has been made, but the MAC address hasn’t actually been learned yet. Then it will generate and broadcast the ARP Request message. In the example network below only R2 will receive that broadcast, but like any broadcast message if there are more hosts on the segment all will receive it. R2 receives and processes the ARP Request message, and then updates its own ARP cache. If R2 has no entry for R1, it will create a new one. If it has an entry, it will reset the timeout to 0. I’ll talk more about the ARP timeout later. Then the destination host will generate and send an ARP Reply message, this time unicast directly to the source host. Then the source host will process the ARP reply message and update its ARP cache, meaning the incomplete entry above will now be complete. Now let’s use DEBUG to see what Cisco IOS tells us about this process. I used the command DEBUG ARP on R1 and R2. Note that I will make a dedicated video about how to use debugs, since we will be using them throughout the course. I then pinged R2 from R1, but note that I omitted the actual ping output here. So, I get a debug message on R1 saying ‘IP ARP: creating incomplete entry for IP address 192.168.1.2 interface gigabitethernet0/0’. So, R1 made an ARP entry for R2, but it doesn’t actually know the MAC address yet. Then here is the actual ARP request message. ‘IP ARP: sent request, source 192.168.1.1, followed by R1’s MAC, then destination 192.168.1.2, followed by all 0s for the destination MAC, since it doesn’t know R2’s MAC yet, gigabitethernet0/0’. Note that the destination MAC address of the Ethernet frame encapsulating this ARP request is all F’s, meaning broadcast. However, as it says here the MAC address in the Target Hardware Address field of the ARP message is all 0’s, meaning unknown. Then this debug message appears on R2, indicating that it received that ARP Request from R1. Then there is another debug message: ‘IP ARP: Creating entry for IP address 192.168.1.1, then R1’s MAC address.’ So, as I said in the previous slide the host receiving the ARP request will use the info in the request message to make an entry in its own ARP table. Then there is a third debug message on R2, ‘IP ARP: sent reply, source 192.168.1.2, R2’s MAC, destination 192.168.1.1, R1’s MAC, gigabitethernet0/0’. So R2 has sent the ARP reply and then R1 shows this debug message, indicating that it received the ARP reply from R2. Note that there isn’t a message on R1 indicating that the ‘incomplete’ ARP entry for R2 is now ‘complete’, but when we check the ARP table soon you’ll see that it does have a complete entry now. I captured that ARP exchange between R1 and R2, let’s take a look at the contents to review the fields of an ARP message. The first field is Hardware Type, and the value here is 1 meaning Ethernet. Then the protocol type, indicating the Layer 3 protocol. The value here is hex 0800, so IPv4. Then the hardware size field, with a value of 6. This means the size of the Layer 2 addresses is 6 bytes, as expected for MAC addresses. And then the protocol size, the size of the Layer 3 addresses. The value here is 4, because IPv4 addresses are 4 bytes in length. Then the Opcode, this is the operation field indicating the type of ARP message. In the ARP request message the value is 1, and in the ARP reply message the value is 2. Then we have the sender MAC Address field, and then sender IP address field. I think these are self-explanatory. In the target MAC address field, notice as I pointed out before that the target MAC address of the ARP request is all 0’s, even though the destination MAC of the Ethernet header is all F’s. And finally the target IP address. Like I said, the contents of ARP messages are pretty simple, nothing complicated here. Now let’s take a look at the ARP table of R1 and R2, you can view them with SHOW ARP. So let me point out some things in this output. The first two columns, Protocol and Address, indicate the Layer 3 protocol and address. Of course, Internet means Internet Protocol, IP. Then there is the Age column. This indicates the time elapsed since the entry was learned or refreshed. Note that Cisco devices will refresh an ARP entry every time they receive an ARP message from the device. So, R1’s ARP messages will refresh R2’s ARP entry for R1 and reset the timer to 0, and R2’s ARP messages will reset R1’s ARP entry for R2 and reset the timer to 0. However, regular non-ARP messages will not refresh an ARP entry. For example, if the timer for an entry is currently at 5 minutes, pinging that IP address will not refresh the entry and reset the timer to 0, because ping messages are ICMP, not ARP. Okay, the next two columns are hardware address, which is the MAC address, and Type, which indicates the Layer 2 encapsulation. ARPA in these entries means Ethernet 2, the type of Ethernet encapsulation used by Cisco devices. There are actually a few versions of Ethernet out there, if you’re curious you can try a google search but its not relevant for this video. Okay, the last thing I want to point out is that a static ARP table entry is automatically added for the router’s own IP and MAC address. So, that’s why in the age column there is just a hyphen for these entries, they don’t have a timer. Since I mentioned ‘Incomplete’ ARP entries earlier, let’s see how they look in the ARP table. Usually you won’t see the incomplete entries because the ARP process finishes too quickly. However, if you for example try to ping an IP address that doesn’t exist in the subnet, an incomplete ARP entry will be made and remain in that state because the ARP process can’t finish. So, on R1 I tried to ping 192.168.1.3, .4, and .5, all addresses that aren’t present, only R1 and R2 are on that segment. Note that I didn’t show the ping outputs here. Then I checked R1’s ARP table with SHOW ARP, and you can see the three incomplete entries here. Note that incomplete ARP table entries will age out much faster, in 1 minute, compared to complete ARP entries which have a default aging time of 4 hours in Cisco IOS. To demonstrate that I waited a minute and viewed the ARP table again, and the incomplete entries are gone. Let me point out that I used a different command to view the ARP table, SHOW IP ARP instead of SHOW ARP. SHOW ARP shows all ARP entries, and SHOW IP ARP shows only ARP entries using IP, Internet Protocol. Remember, ARP supports a variety of protocols. However, since these days we almost always use IP, in reality these two commands will have the same output, so feel free to use either one. It doesn’t make a difference. Now let’s move on to Proxy ARP. It was originally defined in RFC 1027. By the way, because this is a CCNP-level course, when I name RFCs throughout the course I recommend searching for them and reading them, along with other related RFCs. These are the official documents that define the network protocols we use, and they are amazing study tools. Proxy ARP allows a device, usually a router, to respond to ARP requests for IP addresses that are not its own. If you want to know the original use case, check out RFC 1027 to find out why it was originally used. Modern use cases for Proxy ARP involve end hosts with incorrect subnet masks, directly connected static routes, and also some NAT scenarios. For the sake of time I will address the first two use cases in this video. Note that Proxy ARP is enabled globally and on each router interface by default in Cisco IOS. Let’s see how to configure proxy ARP. First, to enable or disable it globally the command is IP ARP PROXY DISABLE, which disables it, and then you can add NO to that command to re-enable it. To enable or disable it on an interface the command is IP PROXY-ARP, which enables it, and adding NO disables it. The command to check the status of proxy ARP on an interface is SHOW IP INTERFACE, then the interface name. In green I’ve highlighted the statement Proxy Arp is enabled. This is the default setting. And I want to point out the line below it also, Local Proxy ARP is disabled. By default, routers will only perform proxy ARP for hosts in different subnets, so hosts connected to different interfaces on the router. However, local proxy ARP allows the router to respond to ARP Requests on behalf of devices in the same subnet as the device that sent the ARP request. This means that instead of traffic going directly between hosts in the same subnet, traffic will be sent to the router first. I won’t get into local proxy ARP or its use cases in this video, but feel free to google for it if you’re curious. And if you want to enable it on an interface, the command is IP LOCAL-PROXY-ARP. Anyway, now let’s look at a couple uses for proxy ARP. Here is the first use case, a mismatched or misconfigured subnet mask. Notice that PC1 has a /16 subnet mask, whereas the other PCs have a /24 subnet mask. So, PC1 believes that PC1, PC2, PC3, and PC4 are all in the same subnet, 192.168.0.0/16. What implications does this have for communications in the network? When PC1 tries to communicate with PC3, it will send an ARP Request directly to the IP address of PC3, not the default gateway R1. The same applies if its trying to communicate with PC4 or any other device in the 192.168.1.0/24 subnet. But, the ARP Request will not reach PC3 because R1 will not forward the broadcast message. It’s not a switch, it doesn’t flood broadcast messages out of other interfaces. However, with proxy ARP enabled R1 will think like this. I received an ARP Request for 192.168.1.13 on my G0/0 interface, even though the 192.168.1.0/24 subnet is not connected to G0/0 and is in a different subnet than the source. This is odd, usually devices will only send ARP requests for IP addresses in the same subnet. It will then think, 192.168.1.13 is not my IP address, but I do have a route for its network in my routing table. So, I will reply to PC1’s ARP Request on behalf of 192.168.1.13, using my MAC address. So, when PC1 sends packets destined for 192.168.1.13 to my MAC address, I will forward them to PC3. PC1 thinks it is communicating directly with PC3, but really R1 is acting as a middle-man. PC1 will send a packet with PC3’s IP as the Layer 3 destination and R1’s MAC as the Layer 2 destination, and R1 will forward the packet on to PC3. So, that’s one use case of proxy ARP. Even though PC1 and PC3 are in different subnets, PC1 believes it is in the same subnet as PC3. Proxy ARP allows them to communicate despite that inconsistency. Here’s another use case, directly connected static routes. For example, on R1 I configured a route to 192.168.34.0/24, specifying the exit interface of gigabitethernet0/0, to allow it to reach the segment between R3 and R4. For this demonstration, assume the other devices already have the necessary routes configured. Now, this kind of static route in which you specify only the exit interface, but not the next-hop IP address, is called a directly connected static route. Why is that? Take a look at the output of SHOW IP ROUTE on R1. It says 192.168.34.0/24 is directly connected to gigabitethernet0/0. So, the router will treat this destination network as a directly connected network, not a remote network. When R1 tries to send messages to hosts in that network, it will try to send the messages directly to the destination host, not to the next-hop router. Let me demonstrate. I issued three pings, one to 192.168.12.2, which is R2, a device that is actually directly connected to R1. Also I pinged R3 and R4’s IP addresses in the 34.0/24 subnet. Now let’s take a look at R1’s ARP cache. As expected, it has entries for 192.168.12.2, .34.3, and .34.4, but look at the MAC address for each entry. They are all the same, and that’s because they are all the MAC address of R2’s G0/0 interface. Because R1 thinks the 34.0/24 subnet is directly connected, it tries to send ARP requests directly to R3 or R4. Neither R3 nor R4 receive those ARP requests, but because R2 has a route for the 34.0/24 subnet in its routing table, it uses Proxy ARP to reply on their behalf, telling R1 to use R2’s MAC address for those destinations. So, let’s summarize. A directly-connected static route is a route in which you specify the exit interface, but not the next hop IP. I’ll review the different static route types like recursive, directly-connected, and fully-specified in a later video, by the way. The router will treat the destination of the static route as a directly-connected network, and will try to send packets directly to destinations in that network instead of sending them to the next hop router. That means that it will ARP for the destination IP, not for the next-hop router IP. But, if the next-hop router has an entry for the destination in its routing table, it will use Proxy ARP to respond to ARP Requests on behalf of the destination device. If I disable proxy ARP on R2’s G0/0 interface like this, what would happen? Let’s see. As you can see, R1 has that directly connected route to the 34.0/24 subnet. I tried to ping R3 at 192.168.34.3, but it doesn’t work, all 5 ICMP echo requests time out. Then I checked R1’s ARP table, and the entry for 34.3 is incomplete. R1 sent an ARP Request destined for 34.3 like in the previous example, but this time R2 didn’t respond on behalf of R3 because I disabled proxy ARP on R2’s G0/0 interface. Okay, so that’s another use case of proxy ARP, it plays a role in directly-connected static routes. Before moving on, one thing I want to mention about proxy ARP messages is that they have the same format as regular ARP messages, using an Operation code of 1 for the request and 2 for the response. It’s still an ARP Request and ARP Reply exchange, but the request is for a destination in a different network than the sender. The final type of ARP I will cover in this video is gratuitous ARP. A gratuitous ARP message is an ARP Reply message sent without receiving an ARP Request. There are a few reasons for sending gratuitous ARP messages. I mentioned one of them in the CCNA course, see if you can remember. The first is announcing when an interface is enabled. A Cisco router, for example, will send a gratuitous ARP message when an interface comes online. The second reason is announcing a change in MAC address, for example if an admin manually configures a MAC address, the device might send a gratuitous ARP to announce that its MAC address has changed. And the third reason is during failover between redundant devices, for example when using a First-Hop Redundancy Protocol like HSRP or VRRP. Note that I will cover this use case in the FHRP section of the course, not this video. So, the ultimate purpose of gratuitous ARP is to update switches’ MAC address tables and hosts’ ARP tables. When a switch receives the gratuitous ARP message, it will use the source MAC in the Ethernet header to update its MAC table. And when a host receives the gratuitous ARP message, it will use the info in the ARP message to update its ARP table. Note that exactly how a device reacts to gratuitous ARP messages can vary. Cisco IOS devices will refresh an existing ARP Table entry if they receive a gratuitous ARP message, so they will reset the timer to 0 and update the MAC address if it is different than the current entry. However, they will not create a new ARP table entry if they receive a gratuitous ARP. So, if there is no entry for that IP address in the ARP table, the gratuitous ARP will be ignored. Let’s look at one example of gratuitous ARP. In this example, R1’s G0/0 interface is currently disabled. I use NO SHUTDOWN on the interface to enable it, and notice the log messages indicating that it is now up. So, R1 sends a gratuitous ARP message. Notice the source and destination IPs, both are R1’s own IP of 192.168.1.1. And the destination MAC is all F’s. Note that the destination MAC of all F’s is used for both the Ethernet header and in the Target Hardware Address field of the ARP message itself. So, R1 is announcing its presence and its MAC address to the network. The switch will use the source MAC address of the Ethernet header to update its MAC address table, and R2 and R3 will refresh their ARP table entry for 192.168.1.1, if it already exists. If not, they won’t create a new entry for 1.1 in their ARP tables until they actually have to communicate with R1. Let’s take a look at that ARP message from R1. There are just a few things I want to point out. First, notice that the Operation code is 2, for ARP reply. And as I mentioned before both the destination of the Ethernet frame and the Target MAC of the ARP message are the broadcast MAC of all F’s. Also both the sender and target IP address are set to R1’s own IP address. And notice that it says ‘Is gratuitous: True’. Note that this isn’t actually a field in the ARP message, there’s no ‘gratuitous’ field to indicate a gratuitous ARP message. This is just a statement from Wireshark meaning that it was able to identify this as a gratuitous ARP message. Okay, that’s all we’ll look at regarding gratuitous ARP for now. We will revisit this topic when studying First Hop Redundancy Protocols later in the course. For the final part of this video, let’s look at some more aspects of ARP as it relates to Cisco IOS. First, how to manually configure ARP entries. Now, just like MAC addresses in a switch’s MAC table, we usually don’t manually configure ARP entries, but you should know how to do it. So, on R1 I manually configured an entry for R2. ARP 192.168.1.2 followed by R2’s MAC address, and then ARPA. Here’s the format of the command, ARP, ip-address, mac-address, then ARPA. There are other options than ARPA, but since we are using Ethernet you’ll probably never have to configure anything else. Remember, in Cisco IOS ARPA means Ethernet 2. By the way, ARPA stands for Advanced Research Projects Agency, a part of the American Department of Defense that played a major role in early network development. I then checked R1’s ARP table, and here is the manual entry. Note that I didn’t specify the interface of the entry in the configuration command, and it isn’t displayed here. However, I used the command SHOW ARP 192.168.1.2 DETAIL to view more information about this entry, and as I’ve highlighted note that R1 does know which interface the entry is attached to. Because of the IP address of the ARP entry, the router knows which interface it is connected to without stating it in the ARP configuration command. Now let’s look at how to clear dynamic ARP entries from the table. It works a bit different than you probably think. First, here is R1’s ARP table, I removed the static entry from the previous example. Notice the dynamic entry for R2. Then I used the command CLEAR ARP to clear the ARP table, let’s see what happens next. So, here’s a debug message indicating that R1 is flushing ARP entries for all interfaces, that’s what you’d expect when clearing the ARP table. Then this message appears, which is a gratuitous ARP message from R1 for its own IP address. Source IP 192.168.1.1, and the same destination. Then this ARP message, a unicast ARP message sent to R2, destination IP 192.168.1.2 and R2’s MAC as the destination, and then the response from R2. I check the ARP table again, and the entry for R2 is still there. So what happened? Did the CLEAR ARP command not work? Here’s what happened. When you use the CLEAR ARP command, the device will send a unicast ARP Request to try to refresh each entry before removing it from the table. If there is no reply after three attempts, the entry is cleared. In this case R2 responded to the first ARP Request, so the entry was not cleared, it was just refreshed. That’s how the CLEAR ARP command works, it doesn’t just immediately clear all dynamic ARP entries. Note that this is different than the CLEAR MAC ADDRESS-TABLE DYNAMIC command, which does simply clear out all dynamic MAC addresses. The final thing we’ll look at is dynamic ARP aging. Like dynamic MAC address table entries, dynamic ARP entries have a timer after which they will be cleared from the table, however the process is a bit different than with MAC addresses. First, I cleared R1’s ARP table to refresh the timers. And now look at the ARP entry. It says the entry will be refreshed in 254 minutes and 9 seconds. Also notice the statement below, it has 2 chances to be refreshed before it is purged. I then cleared the ARP table again. And once again used SHOW ARP DETAIL. Notice that the ‘entry will be refreshed’ timer is now at 265 minutes, quite different than above. So, what’s happening here? Let me explain. The default ARP cache timeout is 4 hours, so 240 minutes, or 14400 seconds. Note that when you configure this timer you configure it in seconds. However, Cisco IOS devices add a random jitter between 0 seconds and 30 minutes to the timeout counter of each ARP entry. How long the jitter is seems to depend on the timer. If the timer is 4 hours like default, the jitter might add up to 30 minutes. However if you configure a shorter timer like 5 minutes, the jitter won’t be 30 minutes, but maybe around 1 minute or so. The purpose of this jitter is to prevent all ARP entries from expiring at the same time, triggering what Cisco calls an ‘ARP storm’. That just means flooding the network with a bunch of ARP traffic all at the same time. So, that’s why when I refreshed this ARP entry, this ‘entry will be refreshed’ time isn’t the same. And regarding the statement I’ve highlighted in green, when this timer reaches 0, the device will try twice to refresh the entry. However, if both attempts fail, before clearing the entry a third Request will be sent, so there are actually 3 chances, even though it says 2 chances in the output here. It goes like this. This timer reaches 0. A unicast ARP request is sent. If there is no response, it will wait an additional minute. It will then send another unicast ARP request. If there is no response, it will wait another minute. Then a third unicast ARP request is sent, and finally the entry is cleared if there is no response. So, in total it will send three ARP requests to try to refresh the entry before finally clearing it. Now, you can configure the ARP timeout per interface. For example, I used the command ARP TIMEOUT 180 on R1’s G0/0 interface. By the way, that is 180 seconds, not 180 minutes. So, I configured it as 3 minutes. I then checked the entry, and it says entry will be refreshed in 1 minute and 3 seconds. Now, this raises another question. I configured 3 minutes, and a random jitter value is supposed to be added to the timer. So why is it shorter now, just over 1 minute? I can’t find clear documentation on this, but after some experimentation this seems to be how it works. This ‘entry will be refreshed’ timer is different than the actual timeout timer. So, we have the configured timeout, 3 minutes. A random jitter value is added by IOS. It seems be a few seconds in this case, because the configured timeout is quite short. Then, the refresh attempts begin before the actual configured timeout. So, that’s why the ‘entry will be refreshed’ timer is actually shorter than the configured timeout in this case. It’s referring to when the first refresh attempt will be done, not when the entry will actually be cleared from the table. Okay, here are the main commands we looked at in this video. I won’t repeat them here, but if you don’t remember any of these commands go back in the video to review. We will practice using some of these commands in the next lab video, and I also recommend experimenting with them in your own lab. Here’s what we covered in this video. ARP is a fairly simple protocol compared to others we’ll cover in this course like OSPF, BGP, etc. However, as you probably noticed there’s a lot more depth to it than what we covered in the CCNA course. Actually, there is still more to learn about ARP, but for the purpose of the CCNP, what we covered in this video should be more than enough. Now let’s move on to the quiz to test your understanding of some of these topics. Here’s quiz question 1. R1 sends an ARP request to learn the MAC address of R2’s G0/0 interface. What field is used to specify R2’s G0/0 interface? Pause the video now to think about the answer. Okay, the answer is D, the Target Protocol Address field of the ARP message. Here’s an example ARP Request message. A is incorrect because the destination MAC address of the ethernet header is all F’s, broadcast. R1 doesn’t know R2’s G0/0 MAC address yet, that’s why it has to send an ARP Request. B is incorrect because there is no IP header, ARP messages are encapsulated directly in an Ethernet frame. C is incorrect because the Target Hardware Address identifies the destination MAC of an ARP message, but R1 doesn’t know R2’s MAC so it has to leave this field blank, all 0s. D is correct, the Target Protocol Address field is how R2 knows that this ARP request is for R2, because R2’s G0/0 IP address will be present here. Okay, let’s go to question 2. What value would you expect to find in the Operation field of a gratuitous ARP message? Pause the video now to think about the answer. Okay, the answer is B, 2. A gratuitous ARP message is an ARP reply that is sent without first receiving an ARP Request. ARP replies use a value of 2 in the Operation field, so that is what you will find in the same field of a gratuitous ARP message. Okay, let’s go to question 3. You notice an ‘Incomplete’ entry in a router’s ARP cache. What does this output mean? Pause the video now to think about the answer. Okay, the answer is A, the ARP process could not complete. Before sending an ARP request, a router first creates an ‘incomplete’ entry in the ARP table for the target address. If the ARP process is successful, the entry will be updated to make a complete entry. If ARP cannot complete, for example because the target IP address doesn’t exist on the network, the incomplete entry will remain in the ARP table for a minute before being cleared. Okay, let’s go to question 4. R1 learned R2’s MAC address via ARP Request/Response. You issue the CLEAR ARP command, but after checking R1’s ARP table you notice R2’s entry is still there. Which of the following is the most likely reason for this? Pause the video now to think about the answer. Okay, the answer is B, CLEAR ARP attempts to refresh ARP entries before clearing them. The command does not immediately remove all dynamic ARP entries, but rather it sends unicast ARP requests to try to refresh each entry in the table, and if an ARP reply is received the entry is refreshed and not cleared. That is probably why, after issuing the CLEAR ARP command, R2’s entry in R1’s ARP table remained. Okay let’s go to question 5. Which of the following configurations is the same as the default setting on Cisco IOS? Pause the video now to think about the answer. Okay, the answer is A, ARP TIMEOUT 14400. The default ARP timeout in Cisco IOS is 4 hours, configured as 14400 seconds on the interface. B, IP ARP PROXY DISABLE globally disables proxy ARP, however in Cisco IOS proxy ARP is globally enabled by default, so this command does not reflect the default setting. C, IP LOCAL-PROXY-ARP, enables local proxy ARP on an interface. It is disabled by default, so this is not a default setting. And D, NO IP PROXY-ARP, disables proxy ARP on an interface, but it is enabled by default so it is also not a default setting. Okay, that’s all for the quiz and today’s video. I hope you learned something new.