Everything Penguin

Focusing on Linux-based Operating Systems
htDig Search:

Operating Systems
  • /pub/OS/Linux

  • Storage
  • File Systems
  • HPC
  • /pub/Storage

  • Networking
  • /pub/Networking

  • Network Services
  • /pub/NetworkServices

  • Security
  • /pub/Security
  • Keytool/OpenSSL

  • Clustering
  • HA
  • DRM

  • Development
  • Design
  • C/C++
  • Java
  • Perl
  • Python
  • Shell
  • Web / J2EE

  • Not Linux ?
  • BSD
  • HP-UX
  • Mac
  • Solaris
  • VM
  • Windows
  • /pub/OS

  • Other
  • /pub
  • /pub/3rdParty
  •  Parent Directory

    ARP cache - Why don't my entries expire?
    Brett Lee
    You should know that ARP is the communication protocol used to obtain a 
    MAC address.  MAC addresses are used in addressing an Ethernet
    frame so that it will go from host to host.  MAC addresses are used on
    a single subnet and are not routable.
    You should also know that ARP entries are maintained in a cache so that
    they do not have to be obtained every time a transmission occurs.  The
    entries do not stay there forever, but instead they expire and are removed
    from the cache.
    But some seem to expire faster than others.  In this brief we'll look at
    some of the reasons why this might occur.
    This is my ARP cache:
    [root@linux test]# arp -vni eth1
    Address                  HWtype  HWaddress           Flags Mask            Iface            ether   00:1B:24:0C:C4:F6   C                     eth1              ether   00:10:4F:07:6A:9B   C                     eth1            ether   00:E0:29:84:5C:AB   C                     eth1           ether   00:1B:24:0C:C4:F3   C                     eth1            ether   00:1B:24:5B:DA:27   C                     eth1           ether   00:1B:24:5B:DA:24   C                     eth1          ether   00:1B:24:0C:C6:BA   C                     eth1           ether   00:1B:24:0C:C6:B7   C                     eth1
    Entries: 9      Skipped: 1      Found: 8
    The eight eth1 entries are displayed.  The lone eth0 entry is not.
    The ARP entries will expire and be removed when "gc_stale_time" is reached.
    That is, the "timeout counter" begins for each entry in the ARP cache after
    it is last used.  This makes sense as you don't want to have to keep ARPing
    for a MAC address of a host that you are in constant communication.  Its like
    talking to your friend and saying, BTW, who are you again?
    So lets say you don't talk to your "friend" for longer than "gc_stale_time"
    (typically 60 seconds).  The ARP entry does not just disappear, but instead
    a garbage collection process must reap the entry from the cache.  This reaper
    also has a timer (gc_interval) associated with it, so the first run of
    the reaper after gc_stale_time is reached would remove the entry.
    What am I talking about?  Well, not all of the "expired" ARP cache entries will
    get removed by the reaper.  One reason might be that your system uses a route
    cache.  If the expired entry in the ARP cache is also an entry in the route cache,
    it will not be removed from the ARP cache.  It first must expire from the
    routing cache, be reaped from it, and then they can be reaped from the ARP
    So how do we look at the route cache.  A couple ways:
    [root@linux test]# ip -s route show cache from dev eth1  src
        cache <src-direct,redirect>  users 1 used 2 age 80sec mtu 1500 advmss 1460 iif eth1
    [root@linux tmp]# route -Cn
    Kernel IP routing cache
    Source          Destination     Gateway         Flags Metric Ref    Use Iface        0      0        0 eth1  il    0      0       98 lo         0      0       86 eth1   ri    0      0        2 eth1  ibl   0      0        1 lo  il    0      0       33 lo
    Yeah, so if the address is a gateway and it is expired from the routing cache,
    is past the gc_stale_time and the reapers' gc_interval has been reached, the
    entry is gonna be deleted for sure, right?
    One more gotch is that the entry MIGHT just be a permanent entry in the ARP
    cache.  Yep, you can add a fixed, unremovable entry using the "ip" command:
    [root@linux tmp]# ip neigh add lladdr 0:0:0:0:0:1 dev eth0 nud perm
    [root@linux tmp]# ip neigh chg dev eth0 reachable
    OK, So finally we're ready to delete the ARP cache, right?
    Here we go:
    [root@linux tmp]# arp -d *
    arpcache: Unknown host
    Arrgh, it doesn't work.  Lets try this:
    [root@linux tmp]# arp -d; arp -vn
    Address            HWtype  HWaddress        Flags Mask      Iface              (incomplete)                     eth1        ether   00:10:4F:07:6A:9B   C            eth1      ether   00:E0:29:84:5C:AB   C            eth1     ether   00:1B:24:0C:C4:F3   C            eth1      ether   00:1B:24:5B:DA:27   C            eth1       ether   00:07:B4:02:7F:02   C            eth0     ether   00:1B:24:5B:DA:24   C            eth1    ether   00:1B:24:0C:C6:BA   C            eth1     ether   00:1B:24:0C:C6:B7   C            eth1
    Entries: 9      Skipped: 0      Found: 9
    Arrgh2, I don't want to do that for each one!
    Lets try try this:
    [root@linux tmp]# ip neigh flush all; arp -vn; cat /proc/net/arp
    Address            HWtype  HWaddress        Flags Mask      Iface              (incomplete)                     eth1                (incomplete)                     eth1              (incomplete)                     eth1             (incomplete)                     eth1              (incomplete)                     eth1               (incomplete)                     eth0             (incomplete)                     eth1            (incomplete)                     eth1             (incomplete)                     eth1
    IP address       HW type     Flags       HW address            Mask     Device    0x1         0x0         00:1B:24:0C:C4:F6     *        eth1      0x1         0x0         00:10:4F:07:6A:9B     *        eth1    0x1         0x2         00:E0:29:84:5C:AB     *        eth1   0x1         0x0         00:1B:24:0C:C4:F3     *        eth1    0x1         0x0         00:1B:24:5B:DA:27     *        eth1     0x1         0x0         00:07:B4:02:7F:01     *        eth0   0x1         0x0         00:1B:24:5B:DA:24     *        eth1  0x1         0x0         00:1B:24:0C:C6:BA     *        eth1   0x1         0x0         00:1B:24:0C:C6:B7     *        eth1
    Well, thats a little bit better, but we see two things:
    1) The cache didn't actually flush (according to "arp -vn").  Instead,
    all we saw was that the MAC addresses were deleted.
    2) The ARP entries in the /proc filesystem didn't change.
    Deleting these ARP entries is pretty tough row to hoe. :)
    Good luck!
    IP Command Reference - Alexey N. Kuznetsov

    Other Sites

  • FAQ's
  • IETF
  • RFC Sourcebook

  • Linux
  • Linux - Intro
  • Linux Kernel
  • Linux Kernel (LKML)
  • Bash - Intro
  • Bash - Advanced
  • Command Line
  • System Administration
  • Network Administration
  • Man Pages (& more)
  • More Guides
  • Red Hat Manuals
  • HOWTO's

  • Reference/Tutorials
  • C++ @ cppreference
  • C++ @ cplusplus
  • CSS @ echoecho
  • DNS @ Zytrax
  • HTML @ W3 Schools
  • Java @ Sun
  • LDAP @ Zytrax
  • Linux @ YoLinux
  • MySQL
  • NetFilter
  • Network Protocols
  • OpenLDAP
  • Quagga
  • Samba
  • Unix Programming

  • This site contains many of my notes from research into different aspects of the Linux kernel as well as some of the software provided by GNU and others. Thouugh these notes are not fully comprehensive or even completetly accurate, they are part of my on-going attempt to better understand this complex field. And, they are your to use.

    Should you wish to report any errors or suggestions, please let me know.

    Should you wish to make a donation for anything you may have learned here, please direct that donation to the ASPCA, with my sincere thanks.

    Brett Lee
    Everything Penguin

    The code for this site, which is just a few CGI scripts, may be found on GitHub (https://github.com/userbrett/cgindex).

    For both data encryption and password protection, try Personal Data Security (https://www.trustpds.com).

    "We left all that stuff out. If there's an error, we have this routine called 'panic', and when its called, the machine crashes, and you holler down the hall, 'Hey, reboot it.'"

        - Dennis Ritchie on Unix (vs Multics)

    [ Powered by Red Hat Linux ] [ Powered by Apache Server] [ Powered by MySQL ]

    [ Statistics by AWStats ]