home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / protocol / appletal / 3112 < prev    next >
Encoding:
Internet Message Format  |  1992-08-18  |  3.0 KB
  1. Path: sparky!uunet!dtix!darwin.sura.net!mips!swrinde!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!proteon.com!jas
  2. From: jas@proteon.com (John A. Shriver)
  3. Newsgroups: comp.protocols.appletalk
  4. Subject: token ring/appletalk questions
  5. Message-ID: <9208181449.AA01399@sonny.proteon.com>
  6. Date: 18 Aug 92 14:49:27 GMT
  7. References: <1992Aug17.234607.22822@samba.oit.unc.edu>
  8. Sender: daemon@ucbvax.BERKELEY.EDU
  9. Organization: The Internet
  10. Lines: 47
  11.  
  12. AppleTalk Phase 2 packets simply cannot be bridged by the 8209.  (Nor
  13. do I know of any bridge that can bridge them.)  The reason is the
  14. crazy business of hashing the Zone Name down to compute a multicast
  15. destination for ZIPGetNetInfo requests.  You take the 16 bit DDP
  16. checksum of the Zone Name, and pass that to the data link.  It then
  17. does a modulus operation on this by the number of multicast addresses
  18. on that datalink, and uses the remainder to index the destination
  19. address.  For EtherTalk, there are 253 different multicast addresses,
  20. while on TokenTalk, there are 19 functional multicast addresses.  (19
  21. is prime, and 253 is 11 * 23, so they are relatively prime.)  Thus,
  22. you can't do any sort of mapping between the two sets of multicast
  23. addresses, a Ethernet to Token-Ring bridge would have to reach into
  24. the ZIP packet and re-checksum the name to compute the correct
  25. multicast destination.  The bridge could not even map them to the
  26. appropriate AppleTalk broadcast address (also a multicast), since
  27. there are hosts (VAX/VMS?) that are picky about the destination being
  28. the right multicast.
  29.  
  30. I would also note that the 8209 would get extremely confused with the
  31. various mixtures of 802.2 and 802.2 with SNAP that AppleTalk uses.  It
  32. does not have any way to handle the fact that the SNAP PID for
  33. AppleARP Phase 2 is 00-00-00-80-F3 on 802.3 and 802.5.  The 8209 will
  34. insist on mapping that to Ethernet type 80-F3, which is AppleARP Phase
  35. 1, which will totally break everything.  (AppleARP Phase 1 is SNAP PID
  36. 00-00-F8-80-F3 on 802.5, due to bridging conventions.)
  37.  
  38. The 8209 would also go crazy if there are any Apples on the Ethernet
  39. side speaking both EtherTalk over 802.3, and IP over Ethernet.  It
  40. assumes that any one host speaks only Ethernet or 802.3.  (As I noted,
  41. it is not standards conformant.)
  42.  
  43.  
  44. You could possibly put an Apple Internet Router in parallel with the
  45. 8209, and configure the 8209 to block the AppleTalk packets to prevent
  46. looping.  I'm not going to assert this would work very well, there are
  47. a lot of risks getting it all configured right.
  48.  
  49.  
  50. The other approach is to throw the 8209 in the dustbin (it is not a
  51. standards-conforming device, and it is quite slow), and replace it
  52. with a bridge-router.  These can continue to bridge any SNA and
  53. NETBIOS traffic, route (or bridge) IP, and route AppleTalk.  Among the
  54. vendors of such devices are Proteon, Cisco, and Wellfleet.
  55.  
  56. If you have a truly slavishly Blue shop, I suppose you could wait and
  57. wait for IBM to release the 6611 with enough functionality, but it
  58. will sure cost a lot more, whenever it ships at all...
  59.