Understanding Frame-Relay Inverse-ARP

• By Joe Astorino
• June 15, 2011
• 15 Comments

Introduction

Ah, frame-relay inverse-ARP…one of those topics that makes most network engineers cringe, and one that can make CCIE candidates plain dizzy and frustrated. When I was studying for the CCIE lab exam, I found that the actual concept of inverse-ARP was simple, but the semantics of the what where and why is what confuses everybody. In this blog we are going to break down frame-relay inverse-ARP. We’ll start out with an introduction to the technology, and then dig into how it is used on each of our possible frame-relay interfaces: Physical, multipoint subinterfaces, and point-to-point subinterfaces.

Frame-Relay Basics

Frame-relay is a layer 2 WAN protocol that uses a concept of permanent virtual circuits (PVC) (and technically switched virtual circuits known as SVCs but we won’t be going there).  A PVC is basically a predefined layer 2 path through a service provider network that sort of “emulates” a point-to-point leased line for the customer.  Essentially, your router connects into a cloud of frame-relay switches at the ISP and the ISP switches your frames from one end of the cloud to the other where it pops out to a remote router.  The fun part is that all the cloud stuff is invisible to the end routers for the most part.  These PVCs, and their paths through the network are defined by data-link connection identifiers (DLCIs).  The DLCI is stored in the frame-relay header.  Basically what happens is this:  When a router sends a frame into the frame-relay cloud it puts the DLCI into the frame-relay header and sends it to the frame switch.  The frame switch switches the frame by doing a lookup on this DLCI and passes it to another frame switch.  The same thing repeats in the cloud until the frame is switched all the way to the other side. In the sense that frames are switched by looking at something other than the IP header, it is similar to MPLS technology.

Inverse-ARP Basics

Most of our modern day networks use the IP protocol for layer 3 addressing and routing. Because frame-relay operates strictly at layer 2 of the OSI model using DLCIs, frame-relay routers need a way to resolve IP addresses to DLCI numbers.  That way, when a frame-relay router wants to send an IP packet to say 100.100.100.4 it can encapsulate the packet into a frame-relay frame and send it out the proper circuit tagged with the proper DLCI.  In short, we need layer 3 to layer 2 address resolution.

In frame-relay we can do this two ways — static or dynamic.  The static method typically involves the frame-relay interface-dlci command or the frame-relay map command depending on exactly what is going on.  The dynamic method is where inverse-ARP comes into play.  Inverse-ARP is a way we can automate this layer 3 to layer 2 address resolution.  Essentially what happens is that an inverse-ARP request is sent out a particular DLCI saying “I have IP address x”.  Since the receiving router knows the incoming DLCI, it now knows that whoever sent the inverse-ARP request is reachable at IP address x out the DLCI the request was received on.  The remote router than sends an inverse-ARP reply that contains his IP address.  Now at the originating router we have a DLCI and an IP address pair. The inverse part of the term stems from the fact that in traditional ethernet ARP a host has a layer 3 IP address that it wants to resolve to a layer 2 MAC address.  With inverse-ARP the opposite is true — a router has a layer 2 DLCI assigned to an interface and it needs to find which layer 3 IP addresses are reachable out that interface.

The biggest confusion with Inverse-ARP in the Cisco world has to do with the defaults on different interfaces.  We will cover the rules of each type of interface as they relate to inverse-ARP now.

Physical Interfaces

Physical interfaces have inverse-arp enabled by default.  Remember, every single DLCI the frame-relay router learns about via LMI from the frame-relay switch is going to be mapped to the physical frame-relay interface by default.  You can see this with the show frame-relay pvc command.

• IF you have an IP address on the interface, the router will send an Inverse-ARP request out every single DLCI associated with the interface.  If you have no other sub-interfaces with DLCIs assigned via frame-relay interface-dlci or frame-relay map commands this means ALL of them!

• Adding the command frame-relay interface-dlci does nothing because all the DLCIs learned from the frame switch are already associated with the interface. Therefore adding this command on a physical interface does not disable inverse-ARP in any way

• Adding the command frame-relay map for a manual IP/DLCI mapping will disable inverse-ARP for that particular DLCI on the interface.  Note that inverse-ARP requests will still be sent on any other DLCIs associated with the physical interface

• You can disable inverse-ARP completely by issuing the no frame-relay inverse-arp interface command.  However, if your router receives an inverse-arp request from another router, it will always respond to the request. You can validate this by looking at debug frame-relay packet as well as debug frame-relay events. Disabling inverse-ARP is usually the preferred thing to do, especially in the CCIE study world as rumor has had it for years that it is not allowed in the lab.

• You can disable inverse-ARP on a per-DLCI basis with the no frame-relay inverse-arp ip command

Multipoint Subinterfaces

Multipoint sub-interfaces have inverse-arp enabled by default…sort of, given the right conditions : )

• By default no inverse-ARP requests will be sent UNLESS you utilize the frame-relay interface-dlci command, and you have an IP address on the interface.  If you put this command on your subinterface for one or more DLCIs, inverse ARPs will indeed be sent for those DLCIs.  The somewhat confusing thing for people here is that typically the frame-relay interface-dlci command is not used on multipoint subinterfaces for this purpose.  It’s only real purposes on this type of interface are for using inverse-ARP and for QoS (traffic shaping and such on a particular DLCI).

• frame-relay interface-dlci enables Inverse-ARP for that particular DLCI on the subinterface

• frame-relay interface-dlci mixed with frame-relay map will result in no inverse-ARP requests being sent on that DLCI.  You might see this in the case where you are doing your L3/L2 address resolution with frame-relay map but you are also applying a DLCI specific QoS policy via frame-relay interface-dlci

• You can disable inverse-ARP completely by issuing the no frame-relay inverse-arp interface command. Same rules apply for replying to requests as on the physical — you always reply.

• You can disable inverse-ARP on a per-DLCI basis with the no frame-relay inverse-arp ip command

Point-To-Point Subinterfaces

The rules here are generally pretty simple.  The frame-relay map command is not allowed on a point-to-point subinterface so it narrows down the confusion.  The reason is because the link is by definition point-to-point so there is no need for a mapping of any kind.  The router basically says “anything that gets routed out this subinterface is going out the DLCI assigned to the subinterface via the frame-relay interface-dlci command” because there is only one possible place the frame can go — to the other side of the point-to-point connection.

• frame-relay map command not allowed or useful

• frame-relay interface-dlci used on the subinterface to assign a DLCI to the subinterface

• No inverse-ARP is sent out regardless if it is enabled on the physical interface.  Inverse-ARP requests are simply not sent on a point-to-point subinterface.

• Remember that inverse-ARP requests are ALWAYS answered.  If your point-to-point sub-interface receives a request it WILL reply

Summary

Inverse-ARP is a way to automate layer 3 to layer 2 address resolution in a frame-relay network.  It is enabled by default on physical interfaces.  It can be used on multipoint subinterfaces given that the frame-relay interface-dlci command is used to tell the router what DLCI to send the requests out of.  Requests are not sent out point-to-point subinterfaces.  Inverse-ARP replies are always sent on all interface types.

If you are struggling with or studying this topic the best advice I can possibly give you is to lab this up.  That is the key to understanding most things like this in my experience.