home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / dcom / lans / ethernet / 2859 < prev    next >
Encoding:
Text File  |  1992-12-23  |  3.0 KB  |  59 lines
  1. Newsgroups: comp.dcom.lans.ethernet
  2. Path: sparky!uunet!grebyn!daily!rich
  3. From: rich@grebyn.com (Richard Lawrence)
  4. Subject: Followup: TR<->8209<->Ethernet bootp/tftp problem
  5. Message-ID: <1992Dec23.075617.7142@grebyn.com>
  6. Organization: Grebyn Timesharing
  7. Date: Wed, 23 Dec 1992 07:56:17 GMT
  8. Lines: 49
  9.  
  10. A few people have asked for the results of this, so I'm going to post a
  11. followup to my posting of a couple of weeks ago concerning bootp/tftp
  12. problems across an 8209 translational bridge (I forgot! so shoot me! :-)
  13. ).
  14.  
  15. The basic problem as stated was that bootp never worked, and tftp
  16. sporadically, across an 8209 bridge at a customer site. I spent a little
  17. time with a protocol analyzer and came to the following conclusions:
  18.  
  19. 1) bootp will never work across an 8209. Reference RFC 1951 (check that,
  20. it's off the top of my head) for the bootp protocol definition. The
  21. basic answer is that a bootp broadcast request contains *within* the
  22. datagram the MAC address of the requestor. There is no ARP or similar
  23. resolution from IP to MAC layer, it is assumed that the bootp server
  24. will respond to the MAC address contained in the bootp request. I
  25. suppose this was done so that you could have proxy bootp requests (ie, a
  26. machine with an intelligent device attached could request that it be
  27. booted, even if the device itself wasn't smart enough to send the
  28. request).
  29.  
  30. In any case, the 8209 will never see the embedded MAC address (it's just
  31. data to the 8209) and therefore won't work it's translation voodoo on
  32. it. The only solution here is to use a router with bootp helper, which
  33. *will* modify the embedded MAC address if appropriate.
  34.  
  35. 2) As I suspected, the tftp problems were related to ARP difficulties.
  36. Since the 8209 is a bridge and cannot perform proxy ARP, we run into
  37. much the same problem as above with bootp. Take this example: machine A
  38. is a token ring Unix station, machine B is an ethernet station. B makes
  39. a tftp read request. A broadcasts an ARP for B's IP address. Said ARP
  40. crosses the 8209, reaches B, and B correctly responds "that's my IP
  41. address, here is my MAC address". When this response crosses the 8209,
  42. again it modifies the send/receive appropriately for the packet itself,
  43. but the contained MAC address is left untouched. So machine A receives a
  44. response to its ARP with an embedded MAC address, *but the embedded
  45. address is the correct ethernet MAC, not the translated one*.
  46. Afterwords, A attempts to send data to B using the ethernet MAC address,
  47. and the 8209 takes that MAC and crunches it up because it assumes it's a
  48. Token Ring address that needs to be modified.
  49.  
  50. Anyway, that's that. The two solutions available were to turn off
  51. translation in bridging (not feasible) or replace with a router in the
  52. same configuration. Eventually a router will be put in place, for now
  53. the customer is using a bootp server on the ethernet side.
  54. -- 
  55. Rich Lawrence, Synoptics Systems Engineer  DOD#9630  rich@grebyn.com
  56.      '92 Seca II "Yuri"  CI$:71101,2272  GEnie:R.LAWRENCE14
  57.    216 years ago my government gave me certain inalienable rights.
  58.      Since then, they've been trying to correct their mistake.
  59.