Provided by: manpages-zh_1.5-1_all bug

NAME

       arp - Linux的ARP核心模塊

yz
       這荇痐艅鬎頃珔藿窶{RFC826中定義的     Address    Resolution    Protocol
       [譯注:即TCP/IP的第三層到第一層的地址轉換協議],
       用於在直接相連的網路中換第二層硬體地址和    Ipv4   協議地址之間的轉換。
       使用者除非想對其進行配置,否則一般不會直接操作這蚍珔禲C

       實際上,它提供對核心中其它協議的服務。

       使用者進程可以使用      packet(7)      的       sockets,收到       ARP
       包(譯注:一譯分組)。           還有一種機制是使用          netlink(7)
       sockets,在使用者空間管理  ARP  緩存的機制。  我怳]可以通過  ioctl  (2)
       控制任意 PF_INET socket上的 ARP 表

       ARP      模塊維護一茧w體地址到協議地址映射的緩存。這蚑w存有大小制,所以
       不常用的和舊的記錄(Entry)將被垃圾收集器清除(garbage-collected),
       垃圾收集器永遠不能刪除標為永久的記錄。我怚i以使用ioctls直接操縱緩沖,
       並且其性狀可以用下惟w義的 sysctl 調節。

       如果在定的時間(見下悸漳ysctl)內,一條現存映射沒有肯定反饋時,
       則認為相鄰層的緩存記錄失效。             為了再次向目標發送數據,ARP將-
       漸試著詢問本地arp進程           app_solicit           次,獲取更新了的
       MAC(介質訪問控制)地址。     如果失敗,並且舊的MAC地址是已知的,則發送
       ucast_solicit   次的   unicast   probe。如果仍然失敗,則將向網路廣播一-
       虓s的ARP請求,此時n 有待發送數據的隊列

       如果    Linux    接到一茼a址請求,而且該地址指向   Linux   轉發的地址,
       並且接收接口打開了代理 arp 時,Linux  將自動添加一條非永久的  代理  arp
       記錄;如果存在拒絕到目標的路由,則不添加代理 arp 記錄。

IOCTLS

       有三  ioctl  可以用於所有  PF_INET  的 sockets 中。它怚H一茷向 struct
       arpreq 的指針作為它怐滌捊C

       struct arpreq
       {
       struct sockaddr arp_pa; /* 協議地址(protocol address)*/
       struct sockaddr arp_ha; /* 硬體地址(hardware address) */
       int arp_flags; /* 標誌(flags) */
       struct sockaddr arp_netmask;
       /* 協議地址的網路掩碼(netmask of protocol address)*/
       char arp_dev[16];
       };

       SIOCSARP,   SIOCDARPSIOCGARP    可分貝設置、刪除和獲取    ARP
       映射。設置和刪除   ARP   映射是特許操作,  只有擁有  CAP_NET_ADMIN  權-
       的進程或有效UID為0的進程可以執行。

       arp_pa   必須是   AF_INET   socket,並且   arp_ha   必須有和   arp_dev.
       指定的設備相同的類型。 arp_dev 是茈Hnull結束的設備名字符串。

       +------------------------------------------------------+
       |                      arp_flags                       |
       +----------------+-------------------------------------+
       |標誌(flag)      | 含義(meaning)                       |
       +----------------+-------------------------------------+
       |ATF_COM         | 查找完成(Lookup complete)           |
       +----------------+-------------------------------------+
       |ATF_PERM        | 永久記錄(Permanent entry)           |
       +----------------+-------------------------------------+
       |ATF_PUBL        | 張貼記錄(Publish entry)             |
       +----------------+-------------------------------------+
       |ATF_USETRAILERS | n求使用延伸檔名(Trailers requested) |
       +----------------+-------------------------------------+
       |ATF_NETMASK     | 使用網路掩碼(Use a netmask)         |
       +----------------+-------------------------------------+
       |ATF_DONTPUB     | 不回復(Don't answer)                |
       +----------------+-------------------------------------+

       如果設置了  ATF_NETMASK  標誌,那麼  arp_netmask  必須有效。  Linux 2.2
       不支持代理網路          ARP          記錄,因此,n設成0xffffffff或者0,
       以刪除現存代理arp記錄。這裏不使用   現存代理arp記錄。   ATF_USETRAILERS
       已經過時了,不應該繼續使用。

SYSCTLS

       ARP 支持一 sysctl  接口,可以用以配置全局參數或逐蚨蘢翿竣f地進行配制。
       該  sysctl 可以通過 /proc/sys/net/ipv4/neigh/*/* 檔案或者使用 sysctl(2)
       接口來訪問。系統中每荓竣f都在                /proc/sys/net/ipv4/neigh/.
       中有自己的目錄。`default'目錄中的設置用於所有新建的設備。        sysctl
       相關的時間是以秒為單位,除非特別聲明過.

       anycast_delay
              對    IPv6    相鄰請求信息的回復的最大延遲時間;    目前還不支持
              anycast。預設1秒。

       app_solicit
              這是在使用多路廣播探測(multicast                      probe)前,
              經過網路連接送到使用者間隙ARP端口監控程式的探測(probe)
              最大數目(見 mcast_solicit )。 預設0。

       base_reachable_time
              一旦發現相鄰記錄,至少在一段介於
              base_reachable_time/2和3*base_reachable_time/2
              之間的隨機時間內,該記錄是有效的。如果收到上層協議的肯定反饋,
              那麼記錄的有效期將延長。 預設O30秒。

       delay_first_probe_time
              發現某茯蛨F層記錄無效(stale)後,發出第一荓斐n等待的時間。 預設-
              O5秒。

       gc_interval
              收集相鄰層記錄的無用記錄的垃圾收集程式的運行周期,預設為30秒。

       gc_stale_time
              決定檢查一次相鄰層記錄的有效性的周期。
              當相鄰層記錄失效時,將在給它發送數據前,再解析一次。       預設-
              O60秒。

       gc_thresh1
              存在於ARP高速緩存中的最少層數,如果少於這蚍A
              垃圾收集器將不會運行。預設O128。

       gc_thresh2
              保存在             ARP              高速緩存中的最多的記錄軟制。
              垃圾收集器在開始收集前,允許記錄數超過這蚍r   5  秒。  預設O
              512。

       gc_thresh3
              保存在             ARP              高速緩存中的最多記錄的硬制,
              一旦高速緩存中的數目高於此, 垃圾收集器將馬上運行。預設O1024。

       locktime
              ARP  記錄保存在高速緩存內的最短時間(jiffy數),   以防止存在多-
              茈i能的映射(potential    mapping)時,   ARP   高速緩存系統的顛簸
              (經常是由於網路的錯誤配置而引起)。 預設O 1 秒。

       mcast_solicit
              在把記錄標記為不可抵達的之前,
              用多路廣播/廣播(multicast/broadcast)方式解析地址的最大次數。
              預設O3。

       proxy_delay
              當接收到有一蚑虼D已知的代理    ARP    地址的    ARP     請求時,
              在回應前可以延遲的                jiffy(時間單位,見BUG)數目。
              這樣,以防止網路滂氶C預設O0.8秒。

       proxy_qlen
              能放入代理                ARP                 地址隊列(proxy-ARP
              addresses)的數據包最大數目。預設O64。

       retrans_time
              奏o一蚑虼D前的等待 jiffy(時間單位,見BUG)的數目。預設O1秒。

       ucast_solicit
              詢問ARP端口監控程式前,試圖發送單探測(unicast   probe)的次數。
              (見 app_solicit).  預設O3秒。

       unres_qlen
              每茖S有被其它網路層解析的地址,在隊列中可存放包的最大數目。預設-
              O3.

BUGS

       時鐘設置的時間單位  jiffy,跟硬體體系有關。  在  Alpha 上,一 jiffy 是
       1/1024 秒,而在其它機器上,是 1/100 秒。

       目前還沒有辦法從使用者空間發送肯定反饋。    這意味著在使用者空間實現的-
       惘V連接的協議  (connection oriented protocols)將產生大量的 ARP 通訊。
       因為ndisc將奐s探測MAC地址。核心 NFS 的實現也存在同樣的問題。

       這茪漭U階Dn講 IPv4 規範並且共享 IPv4 和 IPv6 的功能.

本
       Linux   2.0中的   struct   arpreqarp_dev   ,同時   ioctl
       數目也改變了。在 Linux 2.2 中將不再支持舊的ioctl。

       在          Linux          2.2         中,取消了對網路代理         arp
       記錄(網路掩碼不是0xffffffff)的支持。 這茈\能被核心設置的一茼菾吤N理 arp
       取代,這茼菾吤N理                    arp                   用於所有位於
       其它接上的可到達的主機(如果該接口的轉發和代理 arp 打開了)。

t見
       ip(7)

       RFC826 了解 ARP 描z.
       RFC2461 描z了IPv6使用的近鄰查找以及基本算法

[]
       Alan Yao <Alan_Yao@163.net>

[]
       2000/10/23

mlinuxan:
       http://cmpp.linuxforum.net