Hello Stephane,
You have a wonderful question here.
Regarding the InverseARP, the situation is simple: InverseARP must first know which DLCIs are available. Only then it can try to find out what IP is located at the other hand of the VC identified by the respective DLCI.
The DLCIs can be learned in two ways: either by the LMI (the usual situation), or using the frame-relay interface-dlci command. If you do not run LMI but enumerate the DLCIs statically, the InverseARP will work as you have found yourself. From this viewpoint, the FAQ entry is not correct - the LMI is not strictly required for the InverseARP to work. If there are workable DLCIs configured manually, the InverseARP will run happily.
The FAQ entry you have quoted perhaps refers to the fact that if you deactivate the LMI on your FR DTE device (your router) then no LMI communication with the FR DCE (the FR switch at the CO) will take place. However, a FR switch depends on the LMI communication to discover the state of your DLCIs (it is very uncommon to deactivate LMI on the FR switch as well). If no LMI communication takes place, the FR switch will believe that all your DLCIs are inactive and it will refuse to switch frames to and from these DLCIs. Even if you define your DLCIs using the frame-relay interface-dlci command and your InverseARP will try to send queries through these DLCIs, the FR switch will drop all frames including InverseARP queries because it considers your DLCIs currently inactive. So, in effect, without LMI, the InverseARP would indeed not work, although this is an effect of a longer chain of consequences.
Best regards,
Peter
