Friday, October 11, 2013

Frame-relay Inverse-ARP caveats

Hello, long time no see!
Today I have come across a very interesting examples of Inverse-ARP.

1
Suppose we have a "hub and spoke" topology where hub uses multipoint interface with the following configuration:
interface Serial0/0.200 multipoint
  ip address 155.1.200.5 255.255.255.0
  frame-relay interface-dlci 503
  frame-relay interface-dlci 504

 Spokes have the following config under their respective interfaces:
interface Serial1/0
  ip address 155.1.200.3 255.255.255.0
  encapsulation frame-relay
  frame-relay map ip 155.1.200.5 305 broadcast
This configuration is working. And the reason lies in the fact that "frame-relay map" command effectively disables Inverse-ARP on the particular DLCI, but it's important to understand that it disables only Inverse-ARP requests but not Inverse-ARP responses!

It means that "spoke" has static map to reach the "hub" that disable Inverse-ARP requests. However, it still replies to the requests coming from the "hub", so the "hub" will have dynamic mappings from Inverse-ARP!

2

Imagine that we have the exact same topology but now "spokes" have static mappings to reach each other, however static mapping to reach the "hub" has been removed.

interface Serial0/0.200 multipoint
  ip address 155.1.200.5 255.255.255.0
  frame-relay interface-dlci 503
  frame-relay interface-dlci 504

Spokes have the following config under their respective interfaces:
Spoke 1
interface Serial1/0
  ip address 155.1.200.3 255.255.255.0
  encapsulation frame-relay
  frame-relay map ip 155.1.200.4 305 broadcast

Spoke 2
interface Serial1/0
  ip address 155.1.200.4 255.255.255.0
  encapsulation frame-relay
  frame-relay map ip 155.1.200.3 405 broadcast

Since "spokes" use the same DLCI to reach "hub" and other "spokes" Inverse-ARP now can't be used to discover "hub's" IP to Layer-2 mapping. The interesting thing is that this configuration works because "hub" still sends Inverse-ARP requests and even though it's disabled on "spokes", they are still able to add dynamic mappings to reach "hub" (while responding to Inverse-ARP requests, spokes also add dynamic mappings to reach "hub")!




P.S. It wouldn't change anything if I added "no frame-relay inverse-arp" under the "spoke's" serial interfaces.
P.P.S. I hate Frame-Relay :D