10-23-2007 10:44 AM - edited 03-03-2019 07:18 PM
Hi, does anyone know the difference between
no arp frame-relay
and
no frame-relay inverse arp?
Thanks,
Lisa G
10-23-2007 11:21 AM
Hi Lisa,
Yes, the difference is fairly simple, but has interesting consequences.
no frame-relay inverse arp says that I shall not ask the other end what his IP address is.
no arp frame-relay means that if the other end asks me my IP address, I shall not answer him.
In a CCIE practice lab, they usually do no frame-relay inverse-arp, but the other on can be useful too.
Kevin Dorrell
Luxembourg
10-23-2007 01:40 PM
no frame-relay inverse would also disable sending unsolicited announcement of router's own mapping, but nevertheless there's still remains one issue against neither of those commands protects - router will still happily accept unsolicited announcement from remote side and use them.
I've just checked this in the lab:
*Oct 23 14:15:51.181: Serial6/0:0(i): dlci 205(0x30D1), pkt encaps 0x0300 0x8000 0x0000 0x806 (ARP), datagramsize 34
*Oct 23 14:15:51.181: Serial6/0:0.1: frame relay INARP received
*Oct 23 14:15:51.181: FR-ADJ: dlci 205: 192.168.100.2: adding adjacency
*Oct 23 14:15:51.181: FR: Sending INARP Reply on interface Serial6/0:0.1 dlci 205 for link 7(IP)
while interface config has both commands:
Current configuration : 275 bytes
!
interface Serial6/0:0.1 multipoint
ip address 192.168.100.1 255.255.255.224
ip ospf network broadcast
no arp frame-relay
no frame-relay inverse-arp
end
And here is the mapping:
Serial6/0:0.1 (up): ip 192.168.100.2 dlci 205(0xCD,0x30D0), dynamic,
broadcast,
CISCO, status defined, active
Also looks like router was provoked to send InARP reply even if 'no arp fr' configured.
Did I miss something?
10-23-2007 02:49 PM
It sounds like you configured that interface while active. When changing to no frame-relay inverse-arp, you need to shutdown the interface, then make the change.
Based on your frame map, your router is learning its mapping dynamically.
10-23-2007 10:25 PM
Indeed, the mapping is dynamic and that's what I wanted to show - that 'no frame-relay inv' and 'no arp fr' do not protect router from accepting dynamic mapping.
I've shut the interface, I tried to reboot the router. As long as the other side doesn't send anything, the router doesn't create dynamic mapping. But as soon as the router receives uncolicited InARP reply (note that it's not INARP request, but InARP reply) from the other side, the router creates dynamic mapping and send InARP reply.
It might be that commands were intended to block InARP completely, but during past 12 years I haven't seen any IOS release where it would have been working. Since workaround is rather simple, there's hardly any chance that such behaviour will be changed.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide