home *** CD-ROM | disk | FTP | other *** search
/ PC World 1999 August / PCWorld_1999-08_cd.bin / doc / HOWTO / unmaintained / mini / Proxy-ARP < prev    next >
Text File  |  1998-01-14  |  14KB  |  326 lines
  1. [ 15 January 1998
  2.   The Linux Proxy-ARP mini-HOWTO is not being maintained by 
  3.   the author any more.  If you are interested in maintaining the 
  4.   Proxy-ARP mini-HOWTO, please get in touch with me at 
  5.   <gregh@sunsite.unc.edu>. ]
  6.  
  7.                A small treatise on the use of ProxyARP
  8.                  by Al Longyear <longyear@netcom.com>
  9.                            December 5, 1994
  10.  
  11. I. Introduction
  12.  
  13. This document is written to help those who are considering using the
  14. proxy ARP (Address Resolution Protocol) logic within Linux in the aid
  15. of PPP and SLIP server devices. Proxy ARP is also called 'gracious
  16. ARP' in some sources of documentation. There have been numerous
  17. requests for the use of proxy ARP. When it is not able to be used,
  18. some people deem this as a flaw in the software and wonder why it is
  19. broken.
  20.  
  21. I hope that with the aid of this document, people will understand
  22. more about proxy ARP as well as when it is and is not useful.
  23.  
  24. The use of proxy ARP is useful when you have a server. It will allow
  25. the dynamic connection of remote systems without the need for the
  26. update of the routing tables on other system but the one associated
  27. as the 'server'.
  28.  
  29. The term 'server' is somewhat of a misnomer. TCP/IP is a peer-to-peer
  30. networking environment. It does not have a client to server relation
  31. as other systems do in that resources are offered or 'shared' on
  32. servers while clients 'use' them. However, it is convenient to call the
  33. 'system which answers the telephone' a server; while the 'system
  34. which dials the telephone to connect to the server' a client.
  35.  
  36. Linux's networking software directly supports proxy ARP. There is
  37. no need for a special daemon process such as proxyarpd used in some
  38. systems.
  39.  
  40. Both the PPP protocol support code, pppd, and at least one of the SLIP
  41. support code, dip-uri, will support proxy ARP. In addition, the
  42. networking program, arp, will manage and display the table.
  43.  
  44. To understand how Proxy ARP works and when it may be used, you need to
  45. have a basic understanding of how networking is performed in general.
  46. The next three sections of this document will describe in the
  47. briefest of terms how TCP/IP networking is performed and how routing
  48. works.
  49.  
  50.  
  51.  
  52. II. The Hardware side of Networking
  53.  
  54. All networking using ethernet or token ring is performed using a MAC
  55. (Media Access Control) address. This is a hardware address associated
  56. with a specific controller. Each MAC address is unique. They are
  57. assigned by the manufacturer of the controller. While they may be
  58. overridden in software, this is not the general rule.
  59.  
  60. IP addresses are translated to MAC addresses using a special table
  61. within the networking software called the `ARP cache'. When the
  62. networking software wishes to send an IP frame to the specified
  63. address, it will consult this cache to determine the MAC address. If
  64. the entry is not found in the cache, a special request is made of all
  65. systems attached to the network to resolve the IP address to a MAC
  66. address. This is called an ARP request.
  67.  
  68. The response to the ARP request is a reply with the MAC address. This
  69. MAC address is then added to the cache so that the translation may be
  70. performed subsequently without the aid of ARP.
  71.  
  72. It is this ARP request which is used by the proxy ARP logic to aid
  73. in the support of remote connections.
  74.  
  75. There are rules by which the entries in the cache are removed. Those
  76. rules are not germane to this document and are best left to a
  77. technical description of ip networking.
  78.  
  79. (While token ring is under development, and is available on a test
  80. basis, the common networking transport media for Linux is ethernet. I
  81. will use the term 'ethernet' from now on. Similar facilities are
  82. available for token ring, irrespective of token ring's source routing.)
  83.  
  84.  
  85.  
  86. III. Reason for the use of Proxy ARP
  87.  
  88. The purpose of proxy ARP is to allow the assignment of more than one
  89. IP address to a single network adapter.
  90.  
  91. The manner in which it does this is to create an entry in the ARP
  92. cache of Linux which associates the additional IP address with the
  93. hardware address of the ethernet controller. This permits the Linux
  94. system to respond to an ARP request to translate an IP address to a
  95. hardware address.
  96.  
  97.  
  98.  
  99. IV. TCP/IP Routing
  100.  
  101. [A small preface is in order at this time. This describes the
  102. 'spanning-tree' routing. It does not describe 'source-routing' of IP
  103. frames. The source routing performed by token ring is not IP source
  104. routing but is performed at the MAC layer. The use of IP source
  105. routing is discouraged. Token ring MAC source routing is a
  106. requirement of that transport.]
  107.  
  108. To understand more about proxy ARP, you need to understand how IP
  109. frames are routed on the network. I do not plan to go into great
  110. detail. If you wish additional information, there are many books
  111. available which will offer more in-depth information. (If you don't
  112. wish the books, then look at the RFC documents.)
  113.  
  114. IP frames are routed at each stage of their passage through the
  115. network. Each host, router, and gateway decides for itself and based
  116. upon its own copy of the routing tables where the specific IP frame is
  117. to be transmitted.
  118.  
  119. The routing is performed using the term which I will call an
  120. 'IP network'. Each network interface is assigned an unique IP network.
  121. Each is given an IP address. Each is given a netmask. The 'IP network'
  122. is simply the logical conjunction of the IP address with the netmask.
  123. For example, the IP address of 10.124.35.40 and the netmask of
  124. 255.255.0.0 would have an 'IP network' of 10.124.0.0. While I am using
  125. byte netmasks, the same logic would apply to the non-byte boundary
  126. netmasks.
  127.  
  128. Linux associates the netmask with the route entry. When you add a
  129. route into the system, you specify a IP address and the associated
  130. destination device. If you don't specify a netmask, the netmask is
  131. taken from the destination device's default netmask which is set when
  132. the device is configured with ifconfig.
  133.  
  134. To better understand routing, consider the following configuration of
  135. a sample system.
  136.  
  137. Destination     Netmask          Gateway       Flags    Device
  138. 10.124.0.0      255.255.0.0      0.0.0.0       U        eth0
  139. 10.125.0.0      255.255.0.0      0.0.0.0       U        eth1
  140. 10.126.0.0      255.255.0.0      10.125.31.1   UG       eth1
  141. 10.124.12.5     255.255.255.255  0.0.0.0       UH       ppp0
  142. 0.0.0.0         0.0.0.0          10.124.25.1   U        eth0
  143.  
  144. This is a system with three network devices. It has two ethernet
  145. controllers and one PPP device. IP frames may come into this system
  146. from any one of the three sources. In addition, frames are forwarded
  147. through this system to any one of the three destination devices.
  148.  
  149. The default route is to the gateway device at 10.124.25.1 as
  150. demonstrated by the last entry. To reach that gateway, the frame is
  151. to be transmitted by the eth0 controller.
  152.  
  153. There is one PPP device connected. Its IP address is 10.124.12.5.
  154.  
  155. The eth0 device is on the IP network of 10.124.0.0 while the eth1
  156. device is on the IP network 10.125.0.0.
  157.  
  158. In addition, there is a net route to the IP network 10.126.0.0
  159. available at the gateway associated with 10.125.31.1.
  160.  
  161. To understand how routing is performed, consider an IP frame for the
  162. destination of 10.125.45.1.
  163.  
  164. Linux will go through the route table and for each entry, take the
  165. netmask, perform a logical conjunction (and) with the netmask and
  166. then compare it to the entry's destination IP address. If the result
  167. matches, the frame is sent to the device indicated.
  168.  
  169. The result is that the frame for the IP address of 10.125.45.1 will
  170. be sent to the eth1 device.
  171.  
  172. Likewise a frame for the IP address of 10.124.12.5 will go to the
  173. ppp0 device while the IP address of 10.124.12.6 will go to the eth0
  174. device since the ppp0 device will only accept its one IP address of
  175. 10.124.12.5.
  176.  
  177. Frames for 10.126.31.4 are different. They have a 'gateway'
  178. associated with them. They are found in the similar manner. However,
  179. instead of just sending them to the eth1 device, they are sent to the
  180. one system which is associated with the IP address of 10.125.31.1. It
  181. is this IP address which is translated to a MAC address, rather than
  182. the destination address, 10.126.31.4.
  183.  
  184. When they arrive at the 10.126.31.1 system, that system will forward
  185. them on to the final destination of 10.126.31.4 by using its routing
  186. table which may say to send it on its eth3 interface.
  187.  
  188. There are many error conditions which are caught by this form of
  189. routing. I don't want to go into all of them, however, if for
  190. example, 10.126.31.1 did not have a path to reach the .4 address,
  191. then it would send back a ICMP (Internet Control Message Protocol)
  192. frame to the original sender that it does not have a 'route to the
  193. host' condition.
  194.  
  195.  
  196.  
  197. V. Routing with Proxy ARP
  198.  
  199. Finally, we are getting to the focus of this document now that all of
  200. the foundation has been described.
  201.  
  202. Remember that Linux will put an entry into the ARP cache for the IP
  203. address and the associated hardware MAC address when it is to do proxy
  204. ARP. Remember that this cache is used to translate IP addresses to
  205. MAC addresses.
  206.  
  207. When the remote connects at IP address 10.124.12.5, the Linux system
  208. will add this IP address and the MAC address associated with the eth0
  209. controller to the ARP cache.
  210.  
  211. When it receives a request to translate the IP address 10.124.12.5 to
  212. a MAC address, it will send the entry from its tables to the
  213. requester. The result is that frames to this IP address will be sent
  214. to the server and the server may then forward them to the remote
  215. system.
  216.  
  217. This is how proxy ARP works. The server is a proxy (an agent, an
  218. inter-lopper, a 'front' person, etc.) for the remote IP address. It is
  219. saying to the network that it can accept frames for the remote IP
  220. address and deliver them by responding to the ARP requests.
  221.  
  222. So, for proxy ARP to work, the IP address of the remote (10.124.12.5
  223. in my example) needs to be on one of the IP networks for a network
  224. adapter.
  225.  
  226. There are two reasons for this requirement.
  227.  
  228. The first reason is that the MAC address of the controller is entered
  229. into the ARP cache to be associated with the IP address. A MAC
  230. address is required for the ARP assignment since the ARP cache is a
  231. translation from IP addresses to MAC addresses.
  232.  
  233. The second reason is that all systems on the network do their own
  234. routing. They know that to send a IP frame to the remote's IP address
  235. that they must 'put it on the same wire' which is connected to the
  236. server's network adapter.
  237.  
  238.  
  239.  
  240. VI. When Proxy ARP will not work
  241.  
  242. Consider what would happen if the remote's IP address was 10.200.3.1
  243. rather than 10.124.12.5.
  244.  
  245. 1. The remote systems would not know where to send this address.
  246.  
  247. They all know that to reach the IP network 10.124.0.0 that the frames
  248. should go on the cable attached to eth0. However, there is no IP
  249. network for 10.200.0.0. They would not know where to send frames to
  250. this destination.
  251.  
  252. 2. The server would not know what controller to use for the
  253.    appropriate MAC address when it made the ARP entry.
  254.  
  255. This is the most common reason why proxy ARP will not work for people
  256. who wish to use it. They have a different IP network associated with
  257. the remote IP address than one of their own network interfaces.
  258.  
  259.  
  260.  
  261. VII. Problems with Proxy ARP and what must be avoided
  262.  
  263. 1. Do not have more than one system respond to the proxy ARP entry for
  264.    a specific IP address. In the case of BSD, this will may mean that
  265.    since proxy ARP for a range of addresses, ensure that that the
  266.    address ranges do not conflict. For a network based upon BSD networking,
  267.    this means that you should dedicate the entire network to one server.
  268.  
  269. Again, BSD systems will bitterly complain if it receives more than one
  270. reply for its ARP request.
  271.  
  272. 2. Do not attempt to perform Proxy ARP for an address which is already
  273.    present on the network.
  274.  
  275. This is a slight variation of the above problem. If you attempt to
  276. perform proxy ARP for an IP address which is presently available on
  277. the network, then two replies will be generated. This may mean that
  278. you should not take IP addresses from one network and move them to a
  279. remote connection which may cause the server to attempt to perform
  280. Proxy ARP.
  281.  
  282.  
  283.  
  284. VII. What to do if you can't use Proxy ARP but want the same
  285. functionality.
  286.  
  287. There are several choices available if you are unable to use proxy
  288. ARP.
  289.  
  290. The easiest is to subnet the remote IP addresses so that all of the
  291. remote addresses are on their own IP network. Then add a network route
  292. on each of the routers (those devices which are indicated by the
  293. 'gateway' addresses of all of your hosts) so that the IP network is to
  294. be sent to the server to which the remote IP addresses connect.
  295.  
  296. Alternately, you could use gated on the server and the routers.
  297.  
  298. Alternately, you could put a host route if you don't wish to subnet
  299. the IP network. You would put entries in each of the routers for all
  300. of the remote IP addresses.
  301.  
  302. You need to update only the gateways and routers. You do not need to
  303. change all of the hosts in your network. The default routes which the
  304. hosts use to send frames to routers will cause what is called a "ICMP
  305. re-direct" frame to be sent to the host making the request. This will
  306. automatically add a 'host' route to the appropriate server.
  307.  
  308.  
  309.  
  310. VIII. Conclusion
  311.  
  312. I hope that I have explained a little more about the proxy ARP and
  313. how it works. Fortunately, if you use pppd or dip-uri, you do not
  314. need to know how the mechanical steps in using it. It is
  315. automatically performed for you by these pieces of software.
  316.  
  317. Proxy ARP is not for everyone. It is a workable solution in some
  318. cases. Hopefully, you can determine for yourself whether this will
  319. help you with your networking problems.
  320.  
  321. Additional information may be found in the book 'TCP/IP Illustrated,
  322. volume 1' "The protocols" by W. Richard Stevens and published by
  323. Addison Wessley.
  324.  
  325. Thank you.
  326.