"no-neighbor-learn" under "family inet"

m4rtinm4rtin Member Posts: 170
With "no-neighbor-learn" under "family inet" one can disable ARP address learning by not sending arp-requests and ignoring gratuitous-arps for IPv4 traffic. How can the interface operate properly if ARP address learning is disabled? In which situations "no-neighbor-learn" is used?

Comments

  • Forsaken_GAForsaken_GA Member Posts: 4,024
    just because you can't talk doesn't mean you can't listen
  • AhriakinAhriakin SupremeNetworkOverlord Member Posts: 1,799 ■■■■■■■■□□
    I imagine this is primarily for use where you want to manually specify ARP mappings. It's not that you don't want or need ARP, just that you want 100% manual control of the IP/MAC map.
    We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place?
  • m4rtinm4rtin Member Posts: 170
    Ahriakin wrote: »
    I imagine this is primarily for use where you want to manually specify ARP mappings. It's not that you don't want or need ARP, just that you want 100% manual control of the IP/MAC map.

    Ok, I see. I made a following setup:

    PC[eth0] <-> [ge-1/1/0]M10i

    ..and I specified "no-neighbor-learn" under ge-1/1/0 configuration in router, cleared ARP tables in router and PC and tried to ping PC eth0 interface IP address from the router and router ge-1/1/0 interface IP address from the PC. PC eth0 MAC address wasn't learned by router and router MAC address wasn't learned by PC. If I tried to ping PC from router I received "ping: sendto: Operation not supported" error message. Once I made a static ARP entry to the router I was able to reach PC from router and vice-versa.

    Is "no-neighbor-learn" usually used in strick secure environments where such static mapping should provide additional layer of security? Or what is the main user-case for "no-neighbor-learn"?
  • AhriakinAhriakin SupremeNetworkOverlord Member Posts: 1,799 ■■■■■■■■□□
    Yup it's usually for high security zones. It's common in Colo's where any of your interfaces may be sharing a vlan with other customers talking to the same peer service. To make sure you completely ignore them, and any attempts at arp spoofing (either deliberately or more likely through bad IP configs) you could use something like this.
    We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place?
Sign In or Register to comment.