shaffer@hamlet.ctd.anl.gov (06/21/91)
We have a large campus area network that has grown up as a bridged (YUK!) 1Mbit/sec. point to point ethernet. We are in the process of moving to an FDDI routed network but the usual controversy over non-routable protocols has arisen (you know the users who think that the local in local area transport means anywhere you can drive to in an afternoon). Soooo... we can... 1. Bridge the brain-dead protocols (there are several). 2. Buy a bunch of seperate protocol converters. 3. Give them their own bridged FDDI ring. 4. Let them continue to use the old bridged system(minimal support) while we move on. 5. Refuse to support them. 6. Go on a crusade to convert the heathens :-) 1&3&4 seem like a management nightmare. 2&3 are expensive. 4&5 have grave political implications and 6 is not even worth considering. At first glance it would seem that the ciscos could (with proper software) encapsulate the non-routable protocol (NRP?) packets in IP but since timing is critical (at least in LAT) that could be a problem. Also I don't see how this could be implemented in a generic way (i.e. user discovers new wildcat protocol and configures cisco to encapsulate it). So to the questions... question for cisco...have you looked into the possibility of doing this kind of thing? Is it possible/practical? How would you handle this situation? Question for the rest of the world...Any advice on setting up and administering mega-multiprotocol networks esp. with regard to the NRP? mike shaffer@achilles.ctd.anl.gov Argonne National Laboritories
ercm20@castle.ed.ac.uk (Sam Wilson) (06/26/91)
shaffer@hamlet.ctd.anl.gov writes: > [ Bridged network -> routers: what to do with the Non Routable > Protocols (tm) ] > > Soooo... we can... > 1. Bridge the brain-dead protocols (there are several). > 2. Buy a bunch of seperate protocol converters. > 3. Give them their own bridged FDDI ring. > 4. Let them continue to use the old bridged system(minimal support) while we > move on. > 5. Refuse to support them. > 6. Go on a crusade to convert the heathens :-) > > 1&3&4 seem like a management nightmare. 2&3 are expensive. 4&5 have grave > political implications and 6 is not even worth considering. We do 1 with traces of 5 and 6 - Ciscos will of course bridge what they cannot route so there's no extra equipment cost. [Thinks: does he not know that the Ciscos bridge as well, and is that why the next paragraph?] > [ Couldn't a Cisco encapsulate NRPs in IP? ] Doesn't need - it bridges them. > So to the questions... > > question for cisco...have you looked into the possibility of doing this > kind of thing? Is it possible/practical? How would you handle this situation? > > Question for the rest of the world...Any advice on setting up and > administering mega-multiprotocol networks esp. with regard to the NRP? At this site bridged protcols include LAN Manager over NBP, the various DEC protocols (LAT, LAVC, MOP - yes, perverts that we are we boot a VAXStation through a Cisco, but not through 8.2(3) :-(, but we should be able to with 8.2(4) :-) ) and, until Cisco come up with the promised OSI CONS routing, the UK's private version of CONS known as Pink Book. Managing it isn't a particular problem - you just turn on the bridging and away it goes. The spanning tree sorts itself out and you've got a network. You might of course want to fiddle things, depending on the shape of your network, but it's not absolutely necessary. I mentioned 5 and 6 above. We provide bridging but we guarantee to support only a subset of protocols that happen to be bridged, namely NBP and CONS. If they want to run LAVC or LAT across our network then that's their own problem - we don't support it. In fact we're planning to explicitly block LAVC - all those nasty multicasts. They can get terminal service via other protocols if they need to. Anyway, the usual reason for LAT breaking is the stupid timeouts and that's adjusted in the hosts, there's nothing the network provider can do about it. Oh, yes. You can't yet (I don't think) run AppleTalk over FDDI. If you've got Apples you'll need to watch that. A large bridged AppleTalk network could be a real pain to manage... Sam Wilson Network Services, Edinburgh University Computing Service, Scotland, UK