home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / dcom / lans / ethernet / 2889 < prev    next >
Encoding:
Text File  |  1992-12-30  |  2.8 KB  |  49 lines
  1. Newsgroups: comp.dcom.lans.ethernet
  2. Path: sparky!uunet!paladin.american.edu!howland.reston.ans.net!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!unixhub!unixhub.SLAC.Stanford.EDU!streater
  3. From: streater@unixhub.SLAC.Stanford.EDU (Tim Streater)
  4. Subject: Re: Dec and IEEE Spanning Tree differences
  5. Message-ID: <C03FEt.CMv@unixhub.SLAC.Stanford.EDU>
  6. Sender: news@unixhub.SLAC.Stanford.EDU
  7. Organization: Stanford Linear Accelerator Center
  8. References: <C01pny.4Kp@unixhub.SLAC.Stanford.EDU> <1992Dec30.023337.17569@netcom.com>
  9. Date: Wed, 30 Dec 1992 22:20:53 GMT
  10. Lines: 37
  11.  
  12. Thanks to those who responded about this; I think I have the information I need.
  13.  
  14. A word about why I might want to use more than one algorithm. We have a
  15. subnetted LAN here, with some of the subnets being *very* critical, even to
  16. the point that anything other than a minor intervention would need to wait
  17. several months before being implemented. Such subnets will typically have a
  18. redundant path *within* the subnet, implemented by bridges in a loop. They will
  19. also be connected at two points to routers on the backbone. The routers are 
  20. routing IP, Decnet, and AppleTalk. They are also bridging LAT and MOP.
  21.  
  22. Now, if the routers and the bridges use the same spanning tree protocol, then
  23. from the bridges point of view, the whole LAN is seen, and should a bridge or
  24. router go down in one part of the network then potentially it could have an
  25. impact elsewhere on another subnet. Actually, trying to think this through as
  26. I write this, it seems it shouldn't, but we were getting ELMS messages about
  27. topology changes until last night, when we made the LAN150's we have use the
  28. IEEE Spanning Tree. Those messages have stopped now, and we couldn't figure
  29. out what was causing them. It was as if each Bridge said, "I heard a rumor that
  30. there was a topology change". Only the routers are using the DEC Spanning Tree
  31. now, whereas before we made the change both the routers and the bridges were.
  32.  
  33. We think this approach will give us greater flexibility, but I would like to
  34. hear from anyone who thinks this is a bad idea.
  35.  
  36. We also have NAT bridges; they have a proprietary Spanning Tree, but are 
  37. planning a new firmware version which will support DEC and IEEE. We are happy
  38. with their existing algorithm, which has one advantage as we see it: if a
  39. topology change occurs because power goes off in some building (say), and a
  40. backup bridge takes over, then once the power comes back the bridges do *not*
  41. automatically switch back. This means we can schedule when the switch back 
  42. occurs. This is important for our important subnets, which typically have
  43. large VAX clusters on them, which run continuously. They don't like running
  44. with a long cluster-timout, so there is the potential for a cluster break if a
  45. bridge goes down. One such they don't like; to have two looks like
  46. carelessness.
  47.  
  48. Tim Streater / SLAC Network Development.
  49.