From the blog.

Managing Digital Racket
The more I tune out, the less I miss it. But that has presented me with some complex choices for a nuanced approach to curb
Complexity – My Friend, My Enemy
Over my years of network engineering, I've learned that the fewer features you can implement while still achieving a business goal, the better. Why? Fewer

OECG – Chapter 7 “IP Forwarding” ARP + Inverse ARP + Frame Relay Inverse ARP

495 Words. Plan about 3 minute(s) to read this.

This section of the chapter discusses how the router will build adjacency information, and also discusses details about frame-relay inverse ARP.

In order for the router to build his adjacency table, he uses ARP regularly. We know what ARP is all about, right? It’s the protocol used by a device that knows the IP of a remote host, but not the layer 2/data link information. An ARP gets put out on the wire, and the appropriate host sees the ARP and responds. The information in the response is used so that the device knows how to frame the packet. Okay, simple enough – we know all about this on our ethernet networks. Throw a sniffer on the wire, and you can see ARP’s on any segment all the time.

Fair enough. But the author makes a special point to discuss the ARP and inverse ARP scenarios that arise in frame-relay environments. So let’s talk through these considerations.

  • Inverse ARP (InARP) is used in frame networks to determine what IP to use when trying to forward to that adjacent host. The router already knows the DLCI, but needs the IP, thus “inverse” ARP. This is the opposite of ARP on an ethernet, where you know the IP, but need the data link information.
  • On a frame network, the InARP process is triggered by an LMI status message. This again differs from a LAN, where an ARP will be triggered if a packet is received, but the data link information is unknown. In a frame cloud, the IP is sorted out ahead of time. When the routers receive an LMI PVC Up message, they will announce their IP addresses over the virtual circuit using an InARP message (RFC1293). No LMI, no InARP.
  • When typing a “show frame-relay map” command, interfaces on point-to-point links will not have the word “dynamic” in the output. Point-to-point frame interfaces do not learn about each other’s IP’s with InARP. In fact, InARP information received on point-to-point interfaces is ignored.
  • InARP only works over a virtual circuit. In addition, InARP messages are not forward – they dead-end at a receiving frame router. So…say you’ve got 3 routers. One with a physical connection to the frame (no subinterface), one with a multipoint subinterface and one with a point to point interface. How will the router with the physical connection be able to get IP traffic to the router with a point to point subinterface? There’s no VC between the 2, plus the remote ignores InARP anyway. The way is by statically mapping a connection between the 2 routers using a “frame-relay map ip 12.13.14.15 DLCI broadcast” statement on the router with the physical interface. The router with the point-to-point connection is only going to forward across his point-to-point VC anyway, so no need to static map anything there.
  • You can shut off InARP with the “no frame-relay inverse-arp” interface command. The router will stop sending InARP messages, and will ignore received ones on that interface as well.