home *** CD-ROM | disk | FTP | other *** search
/ BURKS 2 / BURKS_AUG97.ISO / BURKS / LINUX / HOWTO / mini / proxyarp.txt < prev    next >
Text File  |  1997-07-07  |  14KB  |  321 lines
  1.                A small treatise on the use of ProxyARP
  2.                  by Al Longyear <longyear@netcom.com>
  3.                            December 5, 1994
  4.  
  5. I. Introduction
  6.  
  7. This document is written to help those who are considering using the
  8. proxy ARP (Address Resolution Protocol) logic within Linux in the aid
  9. of PPP and SLIP server devices. Proxy ARP is also called 'gracious
  10. ARP' in some sources of documentation. There have been numerous
  11. requests for the use of proxy ARP. When it is not able to be used,
  12. some people deem this as a flaw in the software and wonder why it is
  13. broken.
  14.  
  15. I hope that with the aid of this document, people will understand
  16. more about proxy ARP as well as when it is and is not useful.
  17.  
  18. The use of proxy ARP is useful when you have a server. It will allow
  19. the dynamic connection of remote systems without the need for the
  20. update of the routing tables on other system but the one associated
  21. as the 'server'.
  22.  
  23. The term 'server' is somewhat of a misnomer. TCP/IP is a peer-to-peer
  24. networking environment. It does not have a client to server relation
  25. as other systems do in that resources are offered or 'shared' on
  26. servers while clients 'use' them. However, it is convenient to call the
  27. 'system which answers the telephone' a server; while the 'system
  28. which dials the telephone to connect to the server' a client.
  29.  
  30. Linux's networking software directly supports proxy ARP. There is
  31. no need for a special daemon process such as proxyarpd used in some
  32. systems.
  33.  
  34. Both the PPP protocol support code, pppd, and at least one of the SLIP
  35. support code, dip-uri, will support proxy ARP. In addition, the
  36. networking program, arp, will manage and display the table.
  37.  
  38. To understand how Proxy ARP works and when it may be used, you need to
  39. have a basic understanding of how networking is performed in general.
  40. The next three sections of this document will describe in the
  41. briefest of terms how TCP/IP networking is performed and how routing
  42. works.
  43.  
  44.  
  45.  
  46. II. The Hardware side of Networking
  47.  
  48. All networking using ethernet or token ring is performed using a MAC
  49. (Media Access Control) address. This is a hardware address associated
  50. with a specific controller. Each MAC address is unique. They are
  51. assigned by the manufacturer of the controller. While they may be
  52. overridden in software, this is not the general rule.
  53.  
  54. IP addresses are translated to MAC addresses using a special table
  55. within the networking software called the `ARP cache'. When the
  56. networking software wishes to send an IP frame to the specified
  57. address, it will consult this cache to determine the MAC address. If
  58. the entry is not found in the cache, a special request is made of all
  59. systems attached to the network to resolve the IP address to a MAC
  60. address. This is called an ARP request.
  61.  
  62. The response to the ARP request is a reply with the MAC address. This
  63. MAC address is then added to the cache so that the translation may be
  64. performed subsequently without the aid of ARP.
  65.  
  66. It is this ARP request which is used by the proxy ARP logic to aid
  67. in the support of remote connections.
  68.  
  69. There are rules by which the entries in the cache are removed. Those
  70. rules are not germane to this document and are best left to a
  71. technical description of ip networking.
  72.  
  73. (While token ring is under development, and is available on a test
  74. basis, the common networking transport media for Linux is ethernet. I
  75. will use the term 'ethernet' from now on. Similar facilities are
  76. available for token ring, irrespective of token ring's source routing.)
  77.  
  78.  
  79.  
  80. III. Reason for the use of Proxy ARP
  81.  
  82. The purpose of proxy ARP is to allow the assignment of more than one
  83. IP address to a single network adapter.
  84.  
  85. The manner in which it does this is to create an entry in the ARP
  86. cache of Linux which associates the additional IP address with the
  87. hardware address of the ethernet controller. This permits the Linux
  88. system to respond to an ARP request to translate an IP address to a
  89. hardware address.
  90.  
  91.  
  92.  
  93. IV. TCP/IP Routing
  94.  
  95. [A small preface is in order at this time. This describes the
  96. 'spanning-tree' routing. It does not describe 'source-routing' of IP
  97. frames. The source routing performed by token ring is not IP source
  98. routing but is performed at the MAC layer. The use of IP source
  99. routing is discouraged. Token ring MAC source routing is a
  100. requirement of that transport.]
  101.  
  102. To understand more about proxy ARP, you need to understand how IP
  103. frames are routed on the network. I do not plan to go into great
  104. detail. If you wish additional information, there are many books
  105. available which will offer more in-depth information. (If you don't
  106. wish the books, then look at the RFC documents.)
  107.  
  108. IP frames are routed at each stage of their passage through the
  109. network. Each host, router, and gateway decides for itself and based
  110. upon its own copy of the routing tables where the specific IP frame is
  111. to be transmitted.
  112.  
  113. The routing is performed using the term which I will call an
  114. 'IP network'. Each network interface is assigned an unique IP network.
  115. Each is given an IP address. Each is given a netmask. The 'IP network'
  116. is simply the logical conjunction of the IP address with the netmask.
  117. For example, the IP address of 10.124.35.40 and the netmask of
  118. 255.255.0.0 would have an 'IP network' of 10.124.0.0. While I am using
  119. byte netmasks, the same logic would apply to the non-byte boundary
  120. netmasks.
  121.  
  122. Linux associates the netmask with the route entry. When you add a
  123. route into the system, you specify a IP address and the associated
  124. destination device. If you don't specify a netmask, the netmask is
  125. taken from the destination device's default netmask which is set when
  126. the device is configured with ifconfig.
  127.  
  128. To better understand routing, consider the following configuration of
  129. a sample system.
  130.  
  131. Destination     Netmask          Gateway       Flags    Device
  132. 10.124.0.0      255.255.0.0      0.0.0.0       U        eth0
  133. 10.125.0.0      255.255.0.0      0.0.0.0       U        eth1
  134. 10.126.0.0      255.255.0.0      10.125.31.1   UG       eth1
  135. 10.124.12.5     255.255.255.255  0.0.0.0       UH       ppp0
  136. 0.0.0.0         0.0.0.0          10.124.25.1   U        eth0
  137.  
  138. This is a system with three network devices. It has two ethernet
  139. controllers and one PPP device. IP frames may come into this system
  140. from any one of the three sources. In addition, frames are forwarded
  141. through this system to any one of the three destination devices.
  142.  
  143. The default route is to the gateway device at 10.124.25.1 as
  144. demonstrated by the last entry. To reach that gateway, the frame is
  145. to be transmitted by the eth0 controller.
  146.  
  147. There is one PPP device connected. Its IP address is 10.124.12.5.
  148.  
  149. The eth0 device is on the IP network of 10.124.0.0 while the eth1
  150. device is on the IP network 10.125.0.0.
  151.  
  152. In addition, there is a net route to the IP network 10.126.0.0
  153. available at the gateway associated with 10.125.31.1.
  154.  
  155. To understand how routing is performed, consider an IP frame for the
  156. destination of 10.125.45.1.
  157.  
  158. Linux will go through the route table and for each entry, take the
  159. netmask, perform a logical conjunction (and) with the netmask and
  160. then compare it to the entry's destination IP address. If the result
  161. matches, the frame is sent to the device indicated.
  162.  
  163. The result is that the frame for the IP address of 10.125.45.1 will
  164. be sent to the eth1 device.
  165.  
  166. Likewise a frame for the IP address of 10.124.12.5 will go to the
  167. ppp0 device while the IP address of 10.124.12.6 will go to the eth0
  168. device since the ppp0 device will only accept its one IP address of
  169. 10.124.12.5.
  170.  
  171. Frames for 10.126.31.4 are different. They have a 'gateway'
  172. associated with them. They are found in the similar manner. However,
  173. instead of just sending them to the eth1 device, they are sent to the
  174. one system which is associated with the IP address of 10.125.31.1. It
  175. is this IP address which is translated to a MAC address, rather than
  176. the destination address, 10.126.31.4.
  177.  
  178. When they arrive at the 10.126.31.1 system, that system will forward
  179. them on to the final destination of 10.126.31.4 by using its routing
  180. table which may say to send it on its eth3 interface.
  181.  
  182. There are many error conditions which are caught by this form of
  183. routing. I don't want to go into all of them,