home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / protocol / appletal / 2881 < prev    next >
Encoding:
Internet Message Format  |  1992-07-23  |  4.1 KB
  1. Path: sparky!uunet!mcsun!uknet!cthq!paul
  2. From: paul@cthq.UUCP (Paul G. Smith)
  3. Newsgroups: comp.protocols.appletalk
  4. Subject: Proteon AppleTalk Router problem
  5. Message-ID: <D2150057.99d7td@cthq.UUCP>
  6. Date: 23 Jul 92 18:15:09 GMT
  7. Reply-To: paul@cthq.uucp
  8. Organization: CommsTalk HQ
  9. Lines: 74
  10. X-Mailer: uAccess - Macintosh Release: 1.5v4
  11.  
  12. Hi folks,
  13.  
  14. My friends have a new problem with their network (previously I reported
  15. problems installing the Apple Internet Router, now solved). This one is
  16. pretty bizarre, so I'm hoping someone out there has a useful suggestion.
  17.  
  18. The network is a medium sized Ethernet, mostly running non-AppleTalk protocols,
  19. but the building in question contains a single thin EtherTalk bus,
  20. and a single LocalTalk bus (recently bridged using the Apple Router: _not_
  21. the subject of this new problem). Another building on the same site contains
  22. another EtherTalk network, which needs to be connected to the first one
  23. so that Macs can communicate using FileShare.
  24.  
  25. The problem only concerns the first (original) EtherTalk network, btw.
  26. Note that all the Macs experiencing problems, including the file server,
  27. are on the same EtherTalk cable and in the same zone, with the same
  28. network number (1).
  29.  
  30. They have several (40 or 50) Proteon Routers on the site, which are used
  31. to route other protocols. One of these is already in place between the two
  32. EtherTalk cables. The IS people decided it would hence be appropriate to
  33. use the Proteon Router to route AppleTalk traffic between the two
  34. networks. Accordingly, they turned on the AT Phase 2 routing component in
  35. the Proteon Router (both the EtherTalk networks are phase 2).
  36.  
  37. Immediately, the EtherTalk network #1's performance dropped by several orders
  38. of magnitude. Access to the file server took from 5 to 20 times longer.
  39. Turning the AT2 Router off again solved this.
  40.  
  41. Interestingly, connections (eg to the file server) made _before_ the Proteon
  42. router was 'turned on', in a session, did not suffer the performance drop.
  43.  
  44. This is the point at which they asked me for some help.
  45.  
  46. My friends have a license for EtherPeek, and they also have a Spider Ethernet
  47. traffic analyser. Looking at both, it became clear that when a new network
  48. connection was opened up whilst the Proteon Router was routing AT2 traffic,
  49. all the network packets for that connection would be sent first to the router,
  50. and then on to the original destination. If the router was taken down mid-session,
  51. packets would thereafter be sent direct to their true destination.
  52.  
  53. The higher-level (ie DDP & higher) portions of the packets showed the correct
  54. AppleTalk network/node pairs for the true source and destination of each
  55. packet, but the ELAP headers proved that transmission was taking place in
  56. two steps: first to the router, and then on to the destination.
  57.  
  58. When the Apple Internet Router was brought on-line (connecting the
  59. LocalTalk cable to the network) as a 'control' I found that: {i} if the
  60. Proteon router was disabled, but the Apple router was running, the above
  61. problem did not happen; {ii} if the Proteon Router was active, the
  62. slowed-down two-step connections would only happen some of the time, and
  63. that in each case they only occurred when the original NBP lookup/response
  64. transactions (searching for the file server, or printer, or whatever) was
  65. answered first by the Proteon router: when the Apple router answered first
  66. a 'proper' connection would be set up.
  67.  
  68. At the AppleTalk protocol level, the NBP responses and the RTMP packets
  69. emitted by the Proteon Router appear correct. Presumably the problem is
  70. at the ELAP level? I'm not sure I am qualified to identify what/how etc.
  71.  
  72. Can anyone cast any light on this? Proteon only have one other user who
  73. runs the AppleTalk routing software in the UK, and they are a government
  74. establishment and hence not open to questioning. Proteon UK can't help.
  75.  
  76. Apologies for the length of this message...
  77.  
  78.  
  79. best regards, Paul
  80.  
  81. ----------------------------------------------------------------
  82. Paul G Smith @ CommsTalk HQ       INTERNET:  "paul@cthq.uucp"   
  83. AppleLink: "commstalk.hq" ("commstalk.hq@applelink.apple.com")
  84. tel/fax:   + 44 491 574295  (dial 11 on 2nd dial tone for fax)
  85. snail:    40 St Marks Road, Henley-on-Thames, Oxon. RG9 1LW. UK
  86.