Thank you, Edison.

I sure I won't see dynamic entries if I disable inverse-arp on both routers.

How can I additionaly "delete" this dynamic mapping when I have no access to the other router?

Your router sends an ARP request to the remote router while remote router responds with an ARP reply.

The request can't be disabled with no frame-relay inverse-arp, it only disables the reply.

On this case, the remote router needs to stop responding to ARP request, hence in a proper configuration, both routers must have inverse-arp disabled if you don't want dynamic mappings.

I wonder why documentation says just "no frame-relay inverse-arp protocol dlci" = "Disables Frame Relay Inverse ARP for a specific protocol and DLCI pair."

Nothing about request/reply!

Then, Edison, thank you very much, I have inverstigated the issue, and it seems to me the opposite is true. I mean "no frame-relay inverse-arp protocol dlci" disables inarp requests on the router. But when the router gets a request, it replies to it anyway. I saw it in "debug frame-relay packet".

Please, check me and fix me if I wrong.

It's the definition of inverse ARP.

What does regular ARP do? It sends requests to devices on its segment.

What does inverse ARP do? It sends replies to ARP requests.

You are disabling inverse ARP (arp replies), not just ARP (arp requests).

What you saw, it exactly proves my point. If you have a router without no frame-relay inverse-arp, it will request and reply to ARP while if you have a router with no frame-relay inverse-arp, it will only request but not reply to it.

Your remote router is sending dynamic entries to your local router because it's replying and requesting ARP. I'm sure the remote router doesn't have any dynamic entries from your local router because you have frame-relay inarp disabled.

Well, yes and no :)

ARP and Inverse ARP are the same protocol. Inverse doesn't mean "replies only", instead it means, tell me the L3 address, as I know the L2 one already.

To do so, inverse ARP adds two "types" of request and reply:

http://tools.ietf.org/html/rfc2390

Then, the semantic of the cisco implementation can be confusing. Say "no" to a protocol, disables both request and replies, or replies only? The answer varies by protocol!

At the end, to be practical one can take a shortcut like I always recommend to do: use only point-to-point subinterfaces with FR, and say goodbye to inARP and a ton of other issues!

Cool tidbit, Paolo. Thanks for your contribution to this thread. Happy Holidays !

Hi, that was just a professorial way to say "I don't really know why isn't working" :)

Happy Holidays to you Edison!